Hi Jan, On 09/01/24 10:51, Jan Ingvoldstad wrote:
On Sat, Dec 16, 2023 at 7:55 PM Tore Anderson <tore@fud.no> wrote:
The second – alleged – change is the one that has been discussed the most on the mailing list. The argument here is that your two ASSIGNED PA objects above are actually in violation of *current* policy, because they delegate all the contact information to you (the ISP/LIR). The claim is that current policy requires non-delegated contact information for the End User to be published in the object (not necessarily in admin-c/tech-c, but “somewhere”).
If 2023-04 passes, your two ASSIGNED PA assignments above will definitely be policy compliant (even before they are possibly replaced with an AGGREGATED-BY-LIR object). There is no disagreement about this, as far as we know.
So the question is whether or not your two ASSIGNED PA objects are permitted under *current* policy. If they are, then 2023-04 does not change anything in this regard; the “legal status” of your objects will remain the same – i.e., they are not violating policy – after 2023-04 passes (or fails) as it is under current policy.
We believe your two objects are not in violation of today’s policy, which means 2023-04 will exact no change to their “legal status”. We have elaborated on why in this message, under the heading «Does 2023-04 change the contact registration requirements for assignments?»:
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/0139...
We hope this provides the clarification you requested.
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".
4. 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).
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.
It is important to also consider the cases where the End Users are organisations that do not have non-PII role addresses. Consider for example a small one-person business, let's say a farm owned by «Farmer Fred». This End User would be a company, not an individual, yet the company is often given the same name as the person owning it (at least here in Norway). The e-mail address might well be farmer.fred@gmail and the phone number might be the Farmer Fred's personal mobile. This would mean that both the name and the contact information for this End User *is* PII and is in scope of the GDPR. Therefore, if Farmer Fred exercises his rights under the GDPR to object against / not give consent to the publishing of his PII in the RIPE DB, you (the LIR) have a problem. Proceeding to publish this contact information over Farmer Fred's objections opens you up to legal risk (not to mention souring the relationship with your customer).
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.
Precisely. The LIR, like a domain name registrar, can simply serve as a proxy between the wider Internet community and its End Users. This voids any policy requirement to (possibly illegally) publish Farmer Fred's PII in the RIPE DB. As stated in the Impact Analysis, the RIPE NCC is of the opinion that this (already widespread) practice is permitted by current policy, and will continue to be permitted after 2023-04 is implemented. In other words, just like in the registrar business, this is an already solved problem, which will continue to be solved after 2023-04 is implemented. It is in this respect that we say that 2023-04 will not bring about any change – it ain't broken, and we're not fixing it. The claim that has been made is that *current* policy does not allow LIRs to serve as proxies in this manner, and that the RIPE NCC has not been implementing current policy correctly by allowing it. It is further claimed that 2023-04 will bring about an (undesired) change in that it will allow LIRs to serve as proxies. However, for the reasons already discussed we are of the opinion the premise this argument rests on is incorrect, hence we do not believe 2023-04 will effect any change. We hope this clarifies the clarification. :-) Tore & Jeroen