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

--

To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg