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

Hi again Jan,

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


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


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