[address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
- Previous message (by thread): [address-policy-wg] Minutes of the RIPE87 Rome meeting
- Next message (by thread): [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jan Ingvoldstad
frettled at gmail.com
Tue Jan 9 10:51:13 CET 2024
On Sat, Dec 16, 2023 at 7:55 PM Tore Anderson <tore at fud.no> wrote: > Hi Jan, > Hi Tore, thanks for responding, and sorry for the extreme response lag on my part. 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/013913.html > > 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. 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. So this argument regarding publication of PII is void. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20240109/7d0ad1d1/attachment.html>
- Previous message (by thread): [address-policy-wg] Minutes of the RIPE87 Rome meeting
- Next message (by thread): [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]