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.

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

Whose interpretation? According to the EU Commission: «Personal data is any information that relates to an identified or identifiable living individual. Different pieces of information, which collected together can lead to the identification of a particular person, also constitute personal data.»

https://commission.europa.eu/law/law-topic/data-protection/reform/what-personal-data_en

«Farmer Fred» – the name of an individual – clearly falls within this definition. So does his e-mail address and telephone number. Publishing this information requires a lawful basis, e.g., consent. If consent was refused, it is not permissible to publish. This is presumably the reason why the RIPE NCC states the following in the 2023-04 Impact Analysis:

«Inserting any personal data in the RIPE Database must be in compliance with the RIPE Database Terms and Conditions, even when it relates to the contact details of the member’s own contact person(s). In particular, before anyone updates the RIPE Database with personal data, they must obtain the contact person’s informed and expressed consent and ensure this data is kept accurate and up-to-date.»

https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis

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.

Indeed, and it is our opinion that this solution is already available today, as the RIPE NCC has confirmed that according to their current policy interpretation and procedures, not publishing Farmer Fred's PII in the RIPE DB is compliant with today's policy. This will continue to be the case after 2023-04 is implemented, so no change there.

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?

LIRs' contact information is definitively out of scope of 2023-04. 2023-04 only concerns itself with *assignments* (made by LIRs to End Users), not *allocations* (made by the RIPE NCC to LIRs).

(That said, LIRs' contact information is also subject to the RIPE Database Terms and Conditions.)

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

The policy is technology agnostic in this respect. An automatic e-mail forwarding scheme such as the one you describe is one example of a policy- (and presumably GDPR-) compliant way to do it, but that's not the only possible option. The LIR could instead opt for operating a human-staffed help desk that receives and forwards messages to End Users as appropriate.

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.

I think that because the WG discussion has almost exclusively revolved around this alleged changing of policy requirements to publish End User contact information (which may or may not be PII), it is easy to lose track of what this proposal is *actually* all about. We are talking about two different things:

1) The actual intention behind the proposal: Making it possible to aggregate multiple IPv4 End User assignments that have consistent contact information and purpose into a single database object. This is not possible today, and that is what we want to make that possible, in the same way it is already possible in IPv6.

2) The *alleged* change to what kind of End User contact information is required to be published in the RIPE database. We have never had any intention of changing this in any way, and the Impact Analysis and other statements from the RIPE NCC confirm that the proposal does not change it either.

In short: 1) is an intentional and desired change from today, while 2) is *not* a change from today – intentionally so.

So maybe we could discuss 1) instead of 2) going forward? :-)

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.

As noted in 2) above, the proposal in its current form does not cause any «removal» of any End User contact information publishing requirement compared to current policy. It merely upholds the status quo, which has been confirmed by the RIPE NCC on multiple occasions. However, if you are dismissing the RIPE NCC's clarifications on this subject in the Impact Analysis and elsewhere as not factual, then there is not much more to discuss and we would simply have to agree to disagree.

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.

Any effort to «clearing up the PII mess» has always been outside the scope of this proposal. This proposal is simply not about PII or contact information. That could be a subject for another policy proposal, of course, but one thing at a time.

Tore & Jeroen