<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Dec 16, 2023 at 7:55 PM Tore Anderson <<a href="mailto:tore@fud.no" target="_blank">tore@fud.no</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Jan,<br></blockquote><div><br></div><div>Hi Tore, thanks for responding, and sorry for the extreme response lag on my part.</div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The second – alleged – change is the one that has been discussed the<br>
most on the mailing list. The argument here is that your two ASSIGNED<br>
PA objects above are actually in violation of *current* policy, because<br>
they delegate all the contact information to you (the ISP/LIR). The<br>
claim is that current policy requires non-delegated contact information<br>
for the End User to be published in the object (not necessarily in<br>
admin-c/tech-c, but “somewhere”).<br>
<br>
If 2023-04 passes, your two ASSIGNED PA assignments above will<br>
definitely be policy compliant (even before they are possibly replaced<br>
with an AGGREGATED-BY-LIR object). There is no disagreement about this,<br>
as far as we know.<br>
<br>
So the question is whether or not your two ASSIGNED PA objects are<br>
permitted under *current* policy. If they are, then 2023-04 does not<br>
change anything in this regard; the “legal status” of your objects will<br>
remain the same – i.e., they are not violating policy – after 2023-04<br>
passes (or fails) as it is under current policy.<br>
<br>
We believe your two objects are not in violation of today’s policy,<br>
which means 2023-04 will exact no change to their “legal status”. We<br>
have elaborated on why in this message, under the heading «Does 2023-04<br>
change the contact registration requirements for assignments?»:<br>
<br>
<a href="https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/013913.html" rel="noreferrer" target="_blank">https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/013913.html</a><br>
<br>
We hope this provides the clarification you requested.<br></blockquote><div><br></div><div>Regrettably it does not, and it also raises the question of whether you have forgotten the definition of "end user" and confused it with "private person". <br></div></div><br clear="all"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">  4.<br>An obligation to publish the End User’s contact information in the RIPE database will constitute a violation of Article 6(3) of the RIPE Database Terms and Conditions[5] and Article 6(1)(a) of the GDPR[6], if the End User’s contact person has not given explicit consent to such publication. We believe that the RIPE policy cannot reasonably be interpreted to require LIRs to break EU law (and even if it explicitly did require that, EU law would still take precedence).</blockquote><div><br></div><div>This is misleading, as posting the contact details of an end user **does not necessarily require that you post PII** (person identifying information). You can use a company role and a company role's email address. This is also quite common in the RIPE database today, as far as I can tell.</div><div><br></div><div>Additionally, this is what we in the registrar business consider a solved problem. In the event that the end user is a private person, you instead by default post anonymized information and e-mail addresses. In the case of e-mail addresses, the typical solution is to post a randomized e-mail address that acts as a forwarding address, and that this address is rotated according to the registrar's internal criteria. In the case of RIPE, it would be the LIR's responsibility, I guess.</div><div><br></div><div>So this argument regarding publication of PII is void.<br></div><div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Jan</div></div></div>