The field is OPTIONAL in the schema. Therefore the maintainer surely has "consented" to publication of the URL to geo, if the field exists: It isn't pre-filled. The consent question here, is the maintainer and their obligations in law, and the role of the RIPE NCC in offering a publication service to the maintainer. The downstream consent question, is about a CSV format file held elsewhere. The field is not PII. The contents of the geofeed file, which is NOT in the RIPE NCC service might or might not be, but this is at worst, an indirect pointer. The field is about addresses, it contains no necessary PII in abstract. if I publish http://some.where/~ggm/geofeed.csv then the URL has PII, Is that really held to be a problem? Remember, I consented to posting the URL, I had to hold the maintainer password, the NCC didn't make me do it. The field is operationally helpful to operators of IP address services, BGP speakers, network operators. If a delegate of an address has a concern, their first port of call is the publisher of the geofeed file itself, not the RIPE NCC. I don't understand why the T&C have been interpreted to demand re-writing to fix something, when this is a field which has obvious utility, and low risk, given it is voluntary, and not prefilled or mandated, and does not actually represent any PII breach in and of itself. Truly, I think that a process has driven down a one-way street which wasn't on the route plan, and isn't helping forward progress. I think the wrong question has been posed, and very probably answered correctly, but in the wrong context by legals. I think that if they understood context, they might re-consider. I do not see why explicit language change process burdens are needed to understand the operational utility of this field in the schema. -George