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

Hi Tore and others

New year, but same old story. So much miss information, endlessly
repeated. Selective quotes from other documents to support your
argument where a full quote might show a different picture. Carefully
chosen examples to again support your argument, where other examples
will negate it. But I won't give up.

I put forward a proposal on privacy 1 1/2 years ago, 2022-01. In the
end I withdrew it for two main reasons. It became apparent that my
proposal would significantly change the basis under which personal
data is entered into the RIPE Database.  Secondly it was suggested
that my proposal covered multiple areas that should have been proposed
separately. Your proposal has the same two issues. Firstly it will
also make changes to the way personal (contact) data is used in the
database. Secondly it is claimed to be about aggregating End User
assignments but as a side issue 'slips in' the biggest change to
address policy in 20 years. In your own words you have repeatedly said
this policy is all about aggregation. So keep it strictly about
aggregating assignment objects that have the same contact details.
Again, in your own words you have repeatedly said this will not make
any practical change to the current practise of defining contact
details. So take that out. That is where the contentious arguments
exist. If you really believe what you are saying over and over again,
that there will be no material change in this area, then drop it. Make
this proposal about what the title suggests, aggregation. Drop every
other change. It will probably then get support without objections.

The other changes, that you repeatedly claim are not material changes,
can be the subject of a separate proposal. I and some others in this
community do not believe these other changes are incidental. In fact I
believe that is the real goal of this proposal. I suspect it is the
aggregation that is incidental. A means to achieve the goal of
dropping the mandatory requirement to document assignments with End
User contact details. That is without doubt the bigger change being
pushed by this proposal. As it is, this proposal should not, and must
not, be approved with such a big change slipped in and complete denial
that it is even a change. Separate the two then we can have a full and
open discussion on the other change, if you want to put that forward
as a proposal.

Working on the assumption that you have no intention of doing that, I
will continue to argue against your mis-information below, again.

You have referenced GDPR so many times in this discussion. Let's look
at that in more detail.

Article 6 Lawfulness of processing
1.   Processing shall be lawful only if and to the extent that at
least one of the following applies:
(a) the data subject has given consent to the processing of his or her
personal data for one or more specific purposes;
...
(e) processing is necessary for the performance of a task carried out
in the public interest or in the exercise of official authority vested
in the controller;
(f) processing is necessary for the purposes of the legitimate
interests pursued by the controller or by a third party, except where
such interests are overridden by the interests or fundamental rights
and freedoms of the data subject which require protection of personal
data, in particular where the data subject is a child.

Note in the opening sentence it says "at least one of the following
applies". So personal data does not always need consent of the data
subject. But you only ever refer to (a) consent. If you look back at
the discussion on 2022-01 my privacy proposal you will see this was
heavily discussed:
https://www.ripe.net/ripe/mail/archives/db-wg/2022-October/007630.html
I also discussed it a lot privately with the RIPE NCC legal team.
Frank Breedijk from divd.nl was very concerned about the loss of
contact data as my proposal was suggesting we move to a full consent
model. (I have CCed Frank as he may not be aware of this proposal that
may lead to the removal of a lot of contact information from the
database.) This was one of the final points that led me to drop my
proposal. It was concluded that much of the personal data is entered
into the RIPE Database on the basis of 6.1 (e) - public interest.
Especially as so much of this data is used by LEAs and other
investigators looking into cyber crime, security incidents and abuse.

Then if we look at the legal impact analysis (IA) for 2022-01
https://www.ripe.net/participate/policies/proposals/2022-01?version=3#impact-analysis
"Currently, the processing of personal data relating to resource
holders is necessary for the performance of registry function. This
function is carried out in the legitimate interest of the RIPE
community and supports the smooth operation of the Internet globally
(and is therefore in accordance with Article 6.1.f of the GDPR)."

Then if we look at the legal impact analysis for 2023-04
https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis
"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."

So the RIPE NCC legal team, at different times, has said that we
process PII for resource holders on the basis of 6.1 (f), End Users on
the basis of 6.1 (e), but now they say ALL PII is on the basis of 6.1
(a), ie consent. This is total confusion!!! The RIPE NCC legal team
now needs to explain what the basis is for entering PII into the RIPE
Database for at least the following situations:
-Resource Holders
-End Users
-admin and tech contacts
-abuse contacts

If we take the latest revelation in the IA  on 2023-04, ALL PII needs
consent, this has HUGE implications for the RIPE NCC and RIPE policy
generally. We MUST have a good understanding of the legal basis for
entering PII into the RIPE Database. Consent cannot be conditional. So
if a resource holder who is a natural person withdraws their consent
to have their PII in the database, it MUST be removed. That may leave
an allocation and organisation with no identity or contacts. That
would be a policy violation. BUT the resource cannot be reclaimed as
that would have made the consent conditional. Also we have an abuse
policy that requires all resources to have an abuse contact. If that
contact is a natural person and they withdraw their consent their
details must be deleted. Again that creates a policy violation. But
the resource cannot be reclaimed again as that would have made the
contact details consent conditional. There is also the question of 2
million person objects in the database. It says in the IA for 2022-01
"Although the resource holders themselves are responsible for the
registration details they add to the RIPE Database, the RIPE NCC is
responsible for operating it. Under GDPR, that creates shared
responsibilities on the RIPE NCC’s side with regards to the personal
data added and processed in the RIPE Database."
So the RIPE NCC is jointly responsible for the consent given (and
maybe withdrawn) by these 2m people. This is a separate can of worms
but related to this proposal 2023-04. The legal team has to sort this
out.

On Tue, 9 Jan 2024 at 15:12, Tore Anderson <tore at fud.no> wrote:
>
> 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:

Again you have selected just one example that can support your
argument, Farmer Fred. I could have used KPN or Apple Inc as an
example which would negate your argument. We have no statistics on how
many contacts in the database have corporate data or personal data and
there is no way to determine this from the data. Even Farmer Fred may
be a clever guy. He may have set up a separate business email and
phone number for business purposes. You don't know that. Also as I
said above, consent is not the only option for a lawful basis to enter
personal data.

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

This depends on the legal team's answer to what basis the PII is
entered into the database.

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

And I have provided a mountain of evidence that this interpretation by
the RIPE NCC  is so clearly wrong. So your proposal makes a
significant change in this area, no matter how many times you claim it
doesn't.

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

and subject to the legal team's answer to the basis on which it is
entered into the database.

>
>
>> Precisely. The LIR, like a domain name registrar, can simply serve as a
>> proxy between the wider Internet community and its End Users.

In other words hide the End User data so it doesn't comply with
current policy and requires a court order to obtain by the wider
internet community.

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

There is nothing alleged here. Jan is correct. You ARE removing that
infamous statement
"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."
You cannot describe this as anything other than the fact that you ARE
changing the policy requirements to publish End User contact
information.

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

If this is the actual intention then keep the proposal to this. DO NOT
make other changes to the policy on the side.

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

Then don't change it. SIMPLE!!! The IA does NOT say it doesn't change this.

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

You are removing this line
"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."
This is a 'publishing requirement'. You ARE removing it. To keep
saying you are NOT changing anything is not a joke anymore.

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

It has been said once by the RIPE NCC and disputed. It is YOU who is
repeating it on multiple occasions.

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

cheers
denis

>
> Tore & Jeroen
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/