[address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hi Jan,

On 09/01/24 10:51, Jan Ingvoldstad wrote:
> On Sat, Dec 16, 2023 at 7:55 PM Tore Anderson <tore at 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/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.

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 at 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