<div dir="auto"><div>Hi George<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 29 Jul 2022, 16:12 George Michaelson via db-wg, <<a href="mailto:db-wg@ripe.net">db-wg@ripe.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The field is OPTIONAL in the schema. Therefore the maintainer surely<br>
has "consented" to publication of the URL to geo, if the field exists:<br>
It isn't pre-filled. The consent question here, is the maintainer and<br>
their obligations in law, and the role of the RIPE NCC in offering a<br>
publication service to the maintainer. The downstream consent<br>
question, is about a CSV format file held elsewhere.<br>
<br>
The field is not PII. The contents of the geofeed file, which is NOT<br>
in the RIPE NCC service might or might not be, but this is at worst,<br>
an indirect pointer. The field is about addresses, it contains no<br>
necessary PII in abstract. if I publish<br>
<a href="http://some.where/~ggm/geofeed.csv" rel="noreferrer noreferrer" target="_blank">http://some.where/~ggm/geofeed.csv</a> then the URL has PII, Is that<br>
really held to be a problem? Remember, I consented to posting the URL,<br>
I had to hold the maintainer password, the NCC didn't make me do it.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">The legal team will have to answer this question but is facilitating a service that leads to the identification of an individual the same (in law) as providing the PII directly?</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The field is operationally helpful to operators of IP address<br>
services, BGP speakers, network operators. If a delegate of an address<br>
has a concern, their first port of call is the publisher of the<br>
geofeed file itself, not the RIPE NCC.<br>
<br>
I don't understand why the T&C have been interpreted to demand<br>
re-writing to fix something, when this is a field which has obvious<br>
utility, and low risk, given it is voluntary, and not prefilled or<br>
mandated, and does not actually represent any PII breach in and of<br>
itself.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Does it do any harm to review the current wording of the purposes and how they can be interpreted and perhaps make them more explicitly cover how the database is used? </div><div dir="auto"><br></div><div dir="auto">Cheers</div><div dir="auto">denis </div><div dir="auto">Co-chair DB-WG </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Truly, I think that a process has driven down a one-way street which<br>
wasn't on the route plan, and isn't helping forward progress. I think<br>
the wrong question has been posed, and very probably answered<br>
correctly, but in the wrong context by legals. I think that if they<br>
understood context, they might re-consider. I do not see why explicit<br>
language change process burdens are needed to understand the<br>
operational utility of this field in the schema.<br>
<br>
-George<br>
<br>
-- <br>
<br>
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: <a href="https://mailman.ripe.net/" rel="noreferrer noreferrer" target="_blank">https://mailman.ripe.net/</a><br>
</blockquote></div></div></div>