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

On Tue, Jan 9, 2024 at 1:23 PM Tore Anderson <tore at fud.no> wrote:

> Hi Jan,
>

Hi Tore and thanks for coming back so quickly.


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

The current interpretation of this part of the GDPR is that "Farmer Fred"
is permissible to publish.


>
> 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).
>

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.

Similarly, that requirement must be there for *any* contact object, not
just End Users.

You cannot know if the LIR's phone numbers are personal or not, or can you?


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


No, that is not what I wrote.

This is about an automatic email forwarding scheme, not about a
registration by proxy scheme.

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 at privacy.example, which is a valid email
address that is automatically forwarded to e.g. tore+ripe-example at fud.no.


> 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. :-)
>

I was kindof trying to avoid that argument again.

But sure, as you bring it up again.

This opinion is obviously a logical impossibility.

There is no way that you can change something and at the same way
legitimately claim that the change is not a change.

If it is true that the current practice is both widespread and accepted,
then *no change is necessary*.

If a change is necessary, it is logically because there is a widespread and
accepted practice of publishing End Users' contact information.

The argument is therefore nonsensical, sorry.

You have not actually addressed this concern and objection, you have merely
restated claims and opinions that do not actually do so.

I therefore again urge you to resubmit the proposal *without* this removal.

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.
-- 
Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20240109/44237ae1/attachment.html>