On Tue, Jan 9, 2024 at 3:12 PM Tore Anderson <tore@fud.no> wrote:

Hi again Jan,

Hello again, Tore, and thanks yet again!

On 09/01/24 13:38, Jan Ingvoldstad wrote:

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

This is a fairly radical view of how GDPR regulates publishing of personal data, IMHO erring far to the side of misunderstood caution:

https://commission.europa.eu/law/law-topic/data-protection/reform/rules-business-and-organisations/application-regulation/do-data-protection-rules-apply-data-about-company_en

Does "Farmer Fred" alone "allow the identification of a natural person"? IMHO it does not, and this seems to be the accepted view in various publicly databases publishing data regarding companies containing parts of the name of natural persons.

Basically, any public company register would be illegal according to the interpretation you lean on here.

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.

The policy should be technology agnostic, and when requiring the publication of contact details for end users, require that such publication by a LIR conforms to regulations.

Or you could take the other stance and stop publishing *any* contact details regarding an object, because you cannot know whether the information is personal data or not.

The current stance is just not logical.

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.

This (regarding item 2) is simply not true. Any change in text *is a change*.

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

I have no problem with 1), as already stated.

I do agree with you that this is distracting from the proper meat of your proposal. Which is why I suggest that you drop this part of it.

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 is a removal of the text in question.

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.

I disagree that removing a piece of text is not removing a piece of text.

You can "agree to disagree" all you want, but this is starting to look dishonest.

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.