<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 9, 2024 at 1:23 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 and thanks for coming back so quickly.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On 09/01/24 10:51, Jan Ingvoldstad wrote:<br>
> 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>
><br>
> 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,<br>
> because<br>
> they delegate all the contact information to you (the ISP/LIR). The<br>
> claim is that current policy requires non-delegated contact<br>
> 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<br>
> 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<br>
> 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<br>
> 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>
><br>
><br>
> Regrettably it does not, and it also raises the question of whether <br>
> you have forgotten the definition of "end user" and confused it with <br>
> "private person".<br>
><br>
> 4.<br>
> An obligation to publish the End User’s contact information in the<br>
> RIPE database will constitute a violation of Article 6(3) of the<br>
> RIPE Database Terms and Conditions[5] and Article 6(1)(a) of the<br>
> GDPR[6], if the End User’s contact person has not given explicit<br>
> consent to such publication. We believe that the RIPE policy<br>
> cannot reasonably be interpreted to require LIRs to break EU law<br>
> (and even if it explicitly did require that, EU law would still<br>
> take precedence).<br>
><br>
><br>
> This is misleading, as posting the contact details of an end user <br>
> **does not necessarily require that you post PII** (person identifying <br>
> information). You can use a company role and a company role's email <br>
> address. This is also quite common in the RIPE database today, as far <br>
> as I can tell.<br>
<br>
It is important to also consider the cases where the End Users are <br>
organisations that do not have non-PII role addresses.<br>
<br>
Consider for example a small one-person business, let's say a farm owned <br>
by «Farmer Fred». This End User would be a company, not an individual, <br>
yet the company is often given the same name as the person owning it (at <br>
least here in Norway).<br>
<br>
The e-mail address might well be farmer.fred@gmail and the phone number <br>
might be the Farmer Fred's personal mobile. This would mean that both <br>
the name and the contact information for this End User *is* PII and is <br>
in scope of the GDPR.<br></blockquote><div><br></div><div>The current interpretation of this part of the GDPR is that "Farmer Fred" is permissible to publish.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Therefore, if Farmer Fred exercises his rights under the GDPR to object <br>
against / not give consent to the publishing of his PII in the RIPE DB, <br>
you (the LIR) have a problem. Proceeding to publish this contact <br>
information over Farmer Fred's objections opens you up to legal risk <br>
(not to mention souring the relationship with your customer).<br></blockquote><div><br></div><div>The solution here would be to not publish (and not require the publication of) personal phone numbers (or personal addresses), and to clearly make this a requirement in the policy regarding what End User information is published.</div><div><br></div><div>Similarly, that requirement must be there for *any* contact object, not just End Users.<br></div><div><br></div><div>You cannot know if the LIR's phone numbers are personal or not, or can you?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
> Additionally, this is what we in the registrar business consider a <br>
> solved problem. In the event that the end user is a private person, <br>
> you instead by default post anonymized information and e-mail <br>
> addresses. In the case of e-mail addresses, the typical solution is to <br>
> post a randomized e-mail address that acts as a forwarding address, <br>
> and that this address is rotated according to the registrar's internal <br>
> criteria. In the case of RIPE, it would be the LIR's responsibility, I <br>
> guess.<br>
<br>
Precisely. The LIR, like a domain name registrar, can simply serve as a <br>
proxy between the wider Internet community and its End Users.</blockquote><div><br></div><div>No, that is not what I wrote.</div><div><br></div><div>This is about an automatic email forwarding scheme, not about a registration by proxy scheme.</div><div><br></div><div>E.g. you register the domainname ripe-example.shop with a registrar within the EEA, your email address is published (for EEA-based domainnames, anyway) as e.g. qaobuaidbvsas@privacy.example, which is a valid email address that is automatically forwarded to e.g. <a href="mailto:tore%2Bripe-example@fud.no" target="_blank">tore+ripe-example@fud.no</a>.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> This voids <br>
any policy requirement to (possibly illegally) publish Farmer Fred's PII <br>
in the RIPE DB. As stated in the Impact Analysis, the RIPE NCC is of the <br>
opinion that this (already widespread) practice is permitted by current <br>
policy, and will continue to be permitted after 2023-04 is implemented. <br>
In other words, just like in the registrar business, this is an already <br>
solved problem, which will continue to be solved after 2023-04 is <br>
implemented. It is in this respect that we say that 2023-04 will not <br>
bring about any change – it ain't broken, and we're not fixing it.<br>
<br>
The claim that has been made is that *current* policy does not allow <br>
LIRs to serve as proxies in this manner, and that the RIPE NCC has not <br>
been implementing current policy correctly by allowing it. It is further <br>
claimed that 2023-04 will bring about an (undesired) change in that it <br>
will allow LIRs to serve as proxies. However, for the reasons already <br>
discussed we are of the opinion the premise this argument rests on is <br>
incorrect, hence we do not believe 2023-04 will effect any change.<br>
<br>
We hope this clarifies the clarification. :-)<br></blockquote><div><br></div><div><div>I was kindof trying to avoid that argument again.</div><div><br></div><div>But sure, as you bring it up again.</div><div><br></div><div>This opinion is obviously a logical impossibility.<br></div><div><br></div><div>There is no way that you can change something and at the same way legitimately claim that the change is not a change.</div><div><br></div><div>If it is true that the current practice is both widespread and accepted, then *no change is necessary*.</div><div><br></div><div>If a change is necessary, it is logically because there is a widespread and accepted practice of publishing End Users' contact information.<br></div><div><br></div></div></div><div>The argument is therefore nonsensical, sorry.</div><div><br></div><div>You have not actually addressed this concern and objection, you have merely restated claims and opinions that do not actually do so.</div><div><br></div><div>I therefore again urge you to resubmit the proposal *without* this removal.</div><div><br></div><div>Then, if this part of the policy change is of importance, resubmit it as a separate proposal, and preferably clearing up the PII mess a bit more. I have no beef with clearing that up.</div><div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Jan</div></div></div>