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

On Tue, Jan 9, 2024 at 3:12 PM Tore Anderson <tore at 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 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.
>
> 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 at privacy.example, which is a valid email
> address that is automatically forwarded to e.g. tore+ripe-example at 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.
>
Again, drop the part of the proposal that people have a beef with.

Don't make the change that you claim is not a change.

That is all, and I believe you will not only have rough consensus, but near
100% consensus.

-- 
Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20240110/45145fee/attachment.html>