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... "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@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@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-perso...
«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@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:
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://lists.ripe.net/mailman/listinfo/address-policy-wg