From ripedenis at gmail.com Sat Feb 10 08:49:45 2024 From: ripedenis at gmail.com (denis walker) Date: Sat, 10 Feb 2024 08:49:45 +0100 Subject: [address-policy-wg] RIPE Code of Conduct and discussion on this list In-Reply-To: References: Message-ID: Just checking if I am back.... From ripedenis at gmail.com Sat Feb 10 09:10:13 2024 From: ripedenis at gmail.com (denis walker) Date: Sat, 10 Feb 2024 09:10:13 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <4aefc5f8-1109-4cef-a6e0-7efd28fd6a00@sebastian-graf.at> References: <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> <5c457b41-b9f4-4942-8e27-181e73726001@fud.no> <8a01f7df-390b-4928-bf7c-6584c80587dd@fud.no> <0358e4da-f314-4eaa-8c84-56bea25ff5f0@sebastian-graf.at> <4aefc5f8-1109-4cef-a6e0-7efd28fd6a00@sebastian-graf.at> Message-ID: Colleagues I am back!! Thanks to those who agreed I should never have been away. I am not going to focus on that for now. I do have a lot to say around that issue. But that is for another day, on another mailing list. I won't discuss it here and I will wait until we conclude the discussion on this proposal. I want people to focus on the message rather than the messenger. There hasn't been much conversation while I have been away, but still several significant points that seemed to have been missed by most observers. I have answered all points raised by several people in this single email. In these days of uncertainty, who knows how long any of us will be around. So it is more of an article than an email. But I do end with a positive recommendation. Let's start with a comment by Leo: "We encourage everyone to focus comments on the proposal and its potential impact. Do not comment on individuals, their characteristics, or motivations." The co-chairs have no authority to determine what constitutes part of this discussion. If individuals use tactics that may confuse the community or repeatedly make comments that are not true, they make themselves part of the discussion. The co-chairs have no right to try to prevent these issues from being highlighted and discussed. People need to understand that personal criticism is not a personal attack, even if it is strong criticism. When an individual repeatedly says something that is not true, to highlight this issue and ask them why they keep saying this is not a personal attack. Criticism is part of life, especially in business. Throughout this discussion there has been lots of criticism thrown at me. My characteristics have been heavily criticised and commented on. Even who I speak for has been questioned. No one has questioned if an employee speaks on behalf of their employer. My motivations have also been questioned. It was suggested that I should not talk about the RIPE Database on the Address Policy WG. Even though the old design and technology of the database is one of the key elements used to support the need for aggregation. So much criticism aimed at me and yet the co-chairs saw no reason to intervene. They only intervene when I criticise someone. Then there is motivation. Is it questionable? A lot of the discussion on policy is political, commercial and self interest based. In these contexts I believe it is acceptable to question motivation. The co-chairs never asked what I meant by what I said. Of course the proposal is about aggregation. It's in the title and the text. But it is about a lot more than that. There are two main aspects to this proposal. An inconsequential, minor feature change that people may or may not use. And a major change to the handling of End User details, which people also may or may not take advantage of. The two aspects combined can make a massive change to the available information in the RIPE Database. But the proposal did not even mention the change to End User details. Is it important? Well after I pointed it out, some people who had said "+1 I agree with this proposal" changed their mind and withdrew their support. So for them it was highly relevant. There are sections in the proposal template for supporting and opposing issues relating to the proposal. Depending on your point of view this major change should have been listed in one of those sections. But it wasn't. So did the proposers fully understand the implications of this change or not? I must be allowed to ask that question as part of this discussion. If they did understand it, why did they not mention it? Did they overlook it, or was there some other reason? Again I have to be able to ask these questions. This is all about motivation. To ask these questions and understand what happened is not a personal attack. It is a reasonable line of inquiry. Enough about the messenger, let's get back to the message. ------------------------ On Mon, 18 Dec 2023 at 16:49, Edwin Verheul via address-policy-wg < address-policy-wg at ripe.net> wrote: > > I support this proposal. > > Since this policy introduces convenience for LIR by aligning ipv4 object policy to the ipv6 policy, unclear usage of the admin contact should not prevent this improvement in policy. This pretty much sums up a lot of people's view of this proposal. It is 'convenient' for the operators. Who cares if it is the right thing to do or not, it is convenient. It doesn't align v4 and v6, there are significant differences in the defined aggregations. Never mind if we don't understand what the data means, let's just change it anyway as it is convenient. Maybe a few of you should watch John Curran's keynote speech at NANOG on internet governance: https://www.youtube.com/watch?v=U1Ip39Qv-Zk He talks about phases of the internet and how we are now moving from the 'commercial' internet to the 'public' internet. With this public internet, civil society has/wants a much bigger say in how things work. Organisations that represent civil society and civil order are more concerned about how things work. Politicians are concerned about what their voters think. Do you think civil society cares about operator convenience? They are more likely to think 'it's your job, do it. That's what we pay you for'. I think civil society will be more interested in knowing who is spamming them or attacking their network and can the police catch them, rather than operator convenience. Now let's think a bit more about what this data means and how to interpret it. ------------------------ On Fri, 12 Jan 2024 at 08:56, Alex Le Heux wrote: > > During the discussion about AGGREGATED-BY-LIR status for IPv4 PA assignments the argument has been raised that this proposal would substantially change the registration requirements for end-user assignments in the RIPE DB and the discussion has been going around in circles ever since. > > We would like to point out the following: > > From the RIPE NCC Impact Analysis: > > Acceptance of this proposal will not change the fact that the RIPE NCC cannot enforce which contact details members add to their IPv4 PA assignments in the RIPE Database; this will remain their decision. > This is completely out of context. I have asked the RIPE NCC legal team to clarify what this means but I guess by their silence they declined. To me this sentence says the member can choose to enter the details of Contact A or Contact B and choose what the details are. Which one (A or B) and the details (email or phone) they enter will be their decision. The RIPE NCC cannot enforce if they enter A or B or email or phone. WHO these contacts represent is a matter of policy. The current policy says they MUST be representatives of the End User. That can be enforced by the RIPE NCC, but they choose not to enforce it. > > As well as: > > It is fact that the RIPE NCC has interpreted the current policy to not require a PA Assignment in the RIPE DB to include the actual name and email address of the end-user since at leas the late 1990s. Registering a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR has been acceptable for all this time. > This is completely false. I know Alex well and will give him the benefit of the doubt that he has not picked up on the detail here. He signed this email 'for the Address Policy WG co-chairs'. A lot was said about who I speak for, so I assume Alex was speaking 'for' all the chairs. I was told that signing as 'co-chair DB-WG' gives what I say more weight and has more influence on the community. The same must apply when the co-chairs of this WG collectively sign an email. The community will assume that statement carries more validity. Let's look at the detail. Address policy from the early 1990s has made it clear that assignments must include contact details of the End User. But ripe-288, 28 Oct 2003 is particularly interesting. The authors of this version of the address policy were: Mirjam K?hne, Paul Rendek, Sabrina Wilmot, Leo Vegoda At that time they were all current or former NCC staff. Leo was the operations manager of the RIPE NCC Registration Services (RS). Paul was the senior manager responsible for RS. In this version, these authors added the exact wording that we have today: "When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End User's." The wording was very different before this. The document was restructured and the wording changed. So they must have thought about what this meant. I cannot believe that when these words were added to the policy by the RS manager and RS senior manager they were not enforced by RS. Maybe Leo can give some background to this. Nothing in this industry changes quickly. So if these newly worded requirements were enforced just 20 years ago, they must have been enforced for at least 5 to 10 years. That means the RIPE NCC's interpretation of this wording, written by the RS manager, has only changed in the last 5 to 10 years. I have been told by some former members of RS that they stopped enforcing these requirements at runout of IPv4. They told me that when they had no more address space to allocate, they had no power to enforce these rules. So they simply stopped enforcing them. This paints a very different picture. We are not changing policy to match a common practice. We are dropping policy because it is difficult to enforce, regardless of the reasons why the policy was introduced. It is also interesting that, no matter how many times you read something, you don't always see what it says. A lot has been said about replacing the admin-c and tech-c contacts in an assignment with the contacts of the LIR. It has been said that the RIPE NCC now considers this acceptable. But look at what the current policy actually says: "Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End User's." So this substitution is only allowed by policy where the End User is an individual. You cannot do it for all End Users. This actually makes sense to me. If I want to contact the LIR's tech or admin contacts, they are already available in the RIPE Database in the allocation object. Why duplicate the data in the assignment. The policy says the assignment must have the End User's contacts. So that is another misinterpretation of the current policy. > > > In its impact analysis the RIPE NCC has indicated that this proposal does not change this interpretation. > > It should therefore be clear that 2023-04 does not in fact change anything regarding how end-user details will actually be registered in PA Assignments. Interesting choice of words. It may not change how some End User details 'will' actually be registered, but it changes how they 'should' be registered enormously. > > However, is has been argued that this interpretation is wrong and that PA Assignments in the RIPE DB must include the actual end-user details. And even though this is out of scope for the 2023-04 discussion, it is still something that is worth resolving. As changing this interpretation would be a major departure of many years of accepted practice and potentially involve updating thousands of RIPE DB objects, we feel this discussion would be best served by an independent policy proposal that clarifies the issue and would like to invite the working group to enter one. > I agree this needs further clarification. But you can't write a policy proposal on something you don't understand. We don't know what much of the data means now or in the past, or why we have these rules, or what we need now. Until we have the business requirements for the RIPE Database as a public registry any such policy proposal, including this one, is just a dangerous stab in the dark. > Kind regards, > > Alex Le Heux, for the Address Policy WG co-chairs It is interesting that this email was signed 'for' all the co-chairs of this WG. How can the co-chairs approve this policy proposal (2023-04) while accepting that another proposal is needed to clarify if the RIPE Database must include the actual End User contact details? Are they going to approve a policy proposal that potentially removes this End User detail requirement and then consider a policy proposal that would require them to put this detail back into the RIPE Database? ------------------------ On Thu, 11 Jan 2024 at 09:40, Tore Anderson wrote: > > Hello Denis, > > On 11/01/24 01:40, denis walker wrote: > > So personal data does not always need consent of the data > > subject. But you only ever refer to (a) consent. > > There are indeed other possible lawful bases than consent, and this fact > is precisely why I wrote (emphasis added): > > ?Publishing this information requires *a* lawful basis, *e.g.*, consent.? > > Consent is however the only lawful basis singled out by the RIPE NCC in > the RIPE Database Terms and Conditions and in the 2023-04 Impact > Analysis, so it seems reasonable to assume that some LIRs will seek consent. I wrote the T&C before GDPR was in place. That's why it doesn't refer to any of the other lawful options. I questioned the IA but the legal team chose not to respond. > > Therefore we need to examine what that actually means in practice. You > sum it up quite accurately below: > > > > 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. > > Your conclusion that this situation results in a policy violation, is > however entirely contingent on your interpretation of the current policy > as mandating the publication of the End User's (non-delegated) contact > information. You did not read what I wrote. I was talking about LIR contacts in allocation objects. If that is PII (and a lot of it is) the subjects can now ask for it to be removed. That may leave allocation objects with no LIR contacts. That is syntactically not possible in the RIPE Database. > > Under the RIPE NCC's interpretation of the current policy, on the other > hand, this situation is entirely unproblematic. Under their > interpretation, the LIR has, quote, ?freedom to take over the > responsibility as the point of contact for their End User?. No PII, no > GDPR, no problem. But if the LIR has NO contacts because they have asked for their details to be removed then you can't replace the End User contacts with non-existent LIR contacts. You and the legal team have started a chain reaction here by declaring that ALL contacts in the RIPE Database are there by consent. The RIPE NCC, as joint data controller for the RIPE Database, now has joint responsibility, and I presume therefore joint liability, for 2 million people having given their consent to their details being added into a PERSON object in the database. > > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013892.html > > > 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. > > KPN or Apple would not be relevant examples, as they (presumably) would > use non-personal NOC roles which are not PII, and thus out of scope of > the GDPR. The RIPE NCC is a corporate body and yet it has many PERSON objects in the database relating to individual staff members as contacts for their resources. ------------------------ On Thu, 11 Jan 2024 at 09:45, Tore Anderson wrote: > > Hi Denis, > > On 11/01/24 03:20, denis walker wrote: > > On Wed, 10 Jan 2024 at 13:02, Tore Anderson wrote: > >> > >> On 10/01/24 11:25, Jan Ingvoldstad wrote: > >>> 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. > >> Exactly. LIRs may (but are not required to) chose this approach already > >> *today*. This is a common and long-standing practice which the RIPE NCC > >> has repeatedly clarified as compliant with today's policy. > > This is one of your biggest false statements. The ONLY person > > repeatedly saying this is YOU. Let's do a fact check here. > > Yes, let us indeed do a fact check: > Your fact checking is not very accurate. > Exhibit 1: > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013856.html > This is the one time the RIPE NCC made this argument, which I have disputed. > Exhibit 2: https://www.ripe.net/participate/policies/proposals/2023-04 > (specifically the ?counter-argument?, which the RIPE NCC Policy Officer > confirmed to the proposers and the WG chairs as correctly representing > the RIPE NCC's interpretation) > This 'counter argument' is your argument and is completely false. > Exhibit 3: > https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis > I have explained this above. This is the argument about LIRs adding Contact A or Contact B or email or phone. THAT is their decision. Who these contacts represent is set in the current policy and is not the LIR's choice. > Exhibit 4: > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013892.html > All the talk about maintainers, descr attributes, DB T&C and documentation has nothing to do with address policy. All they say here is that this proposal won't influence how the RIPE NCC currently carries out ARCs. They are doing it wrong now and will continue to do it wrong. > Four repetitions so far, all saying the same thing. How many more do you > need? > One statement and no repetitions. They all say something different, which most people can clearly see. > > >> As the RIPE NCC writes in the Impact Analysis (emphasis added): > >> > >> ?Acceptance of this proposal **will not change** the fact that the > >> RIPE NCC cannot enforce which contact details members add to their IPv4 > >> PA assignments in the RIPE Database; this **will remain** their decision.? > >> Same repetitive argument again and again. Yes it IS the LIR's decision to enter Contact A or Contact B or email or phone. It is the POLICY that determines who those contacts represent. How many more times are we going to have this same discussion? (Which the legal team will not clarify.) > >> So, once again: which End User contact details LIRs publish (if any) is > >> their decision today, and it will be continue to be their decision if > >> 2023-04 passes. YES AGAIN the LIR can always choose between Contact A and Contact B, email or phone. They cannot choose to not enter any End User contact details. > >> Hence, 2023-04 does not effect any change in this regard. But as everyone else can see, this makes a huge change. > > This really does make me cry. The wording in the IA is poor. You have > > applied an interpretation to this which I do not believe is what was > > meant. Then the RIPE NCC legal team has remained silent. So I am > > asking the RIPE NCC legal team to clearly explain what they meant by > > this wording. > > The explanation you request was posted two days after the Impact > Analysis was: > > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013892.html > > ?LIRs are free to choose how to provide services and to who, this > includes their freedom to take over the responsibility as the point of > contact for their End User as well as having their maintainer in the > IPv4 PA assignments they register.? > > This explanation aligns perfectly with our interpretation of the > statement in the Impact Analysis. > Wrong again. Yes the LIR is free to take over responsibility for technical matters. You can always find their contact details in the allocation object. So the public, civil society, LEAs, and other LIRs can choose who they want to contact...the LIR or the End User. Between the allocation and assignment objects you have all the contact details you need...according to current policy. The LIR does NOT have the freedom, according to current policy, to replace the admin-c and tech-c contacts in the assignment object with their own contact details in all situations. Again the current policy wording is clear and not interpretable: "Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End User's." So you can ONLY replace the assignment contacts with those of the LIR IF the End User is an individual. Again this is simple, plain English, originally written by Leo and Mirjam. > >> Given that, it is hard to see how we could possibly amend the proposal > >> to change this particular point to an even lesser extent than what is > >> already the case? > > Let me help you. Do NOT remove a sentence that has nothing to do with > > the stated goal of the proposal to aggregate assignments and that you > > claim does not change anything. > > This sentence also has a lot to do with the stated goal of aggregating > assignments, because it mandates that assignments must be ?registered > separately?. That is clearly incompatible with aggregation. > **** Finally, FINALLY you have admitted that this change that is not a change and that changes nothing does actually change something. **** It changes the registration requirements for assignments, which I have been saying all along and which you have been denying for months. ------------------------ On Thu, 11 Jan 2024 at 10:19, Jan Ingvoldstad wrote: > > > On Thu, Jan 11, 2024 at 9:45AM Tore Anderson wrote: >> If our ulterior goal was to remove the End User contacts from our own >> assignments we can just go ahead and do so, right now. The RIPE NCC is >> already on the record saying that's totally OK, and we would be >> following in the footsteps of many other LIRs who have already done so. > While you seem to argue that the RIPE NCC is both omniscient and omnicompetent, I do not think it is that easy. > > I simply think that the RIPE NCC and you are mistaken. > After talking to former members of RS I am beginning to think that the RIPE NCC is not mistaken. They know exactly what the current policy says and they know what it means. After all, it was written by former RS managers. BUT they don't believe they have any power to enforce it. This is why they quietly ignore what the policy says. I'll say more about that in my conclusion at the end of this email. > Continously appealing to RIPE NCC as the authority of policy and policy interpretation is not a good thing. > > It undermines the community drive behind policies. > > If this is where we are going, it seems that we would be just as well off by letting EU politicians run the show. > If you have watched John Curran's keynote speech at NANOG and think about the way a handful of operators are pushing this proposal through, the EU politicians WILL be running the show in the near future. https://www.youtube.com/watch?v=U1Ip39Qv-Zk > -- > Jan ------------------------ On Thu, 11 Jan 2024 at 13:11, Tore Anderson wrote: > > On 11/01/24 10:19, Jan Ingvoldstad wrote: > > > > Continously appealing to RIPE NCC as the authority of policy and > > policy interpretation is not a good thing. > > The RIPE NCC is the secretariat of the RIPE Community and is delegated > the task of implementing and enforcing the RIPE Community policies, as > well as to providing training to the LIRs on how to operationalise said > policies. If that is not an authority worth paying attention to, I do > not know what is. > Exactly, the RIPE NCC is the secretariat, not the policy decision maker. They are supposed to enforce community derived policy. IF they don't think they have the powers to enforce a policy they should raise that issue with the community and seek guidance. They should not just quietly ignore the policy, or part of it. > After all, any LIR which prefers the RIPE NCC interpretation of the > policy in this regard is may simply adhere to it and act accordingly, > and this is commonly done today. Thus the RIPE NCC's interpretation of > the policy ? mistaken or not ? ends up becoming the (de facto) way the > policy is implemented anyway. > If a policy has unintentional interpretations it is badly written. LIRs should not be in a position to choose between a community view and the RIPE NCC's view of a policy. A RIPE NCC interpretation of a policy that conflicts with a community view should not become a de facto implementation. If such a situation arises the conflict must be resolved. ------------------------ On Thu, 11 Jan 2024 at 14:11, Tore Anderson wrote: > > Hi Jan, > > On 11/01/24 13:27, Jan Ingvoldstad wrote: > > On Thu, Jan 11, 2024 at 1:11PM Tore Anderson wrote: > > > > After all, any LIR which prefers the RIPE NCC interpretation of the > > policy in this regard is may simply adhere to it and act accordingly, > > and this is commonly done today. Thus the RIPE NCC's > > interpretation of > > the policy ? mistaken or not ? ends up becoming the (de facto) way > > the > > policy is implemented anyway. > > > > This statement basically renders the point of a policy working group moot. > I totally agree. > Not at all. Any working group member who is of the opinion that the RIPE > NCC is interpreting a RIPE Community policy incorrectly, is free to at > any point submit a policy proposal that clarifies the allegedly > misinterpreted policy text with the aim to make the RIPE NCC change its > procedures accordingly. > A policy proposal would only be needed if the policy is so badly written it needs clarity. When the policy is clear and simple, but the RIPE NCC is either misinterpreting it or doesn't believe it has the power to enforce it, we don't need a policy change. We need an interpretation change. > The RIPE NCC's Impact Analysis will then reveal whether or not the > proposed new policy text does attain its goal and that the RIPE NCC will > change its procedures as desired, should the proposal pass. > > Finally, the proposal will need to reach (rough) consensus in order to > confirm that the RIPE Community does indeed concur with the proposer's > opinion that the old policy was interpreted incorrectly, and that the > RIPE NCC's procedures ought to change. > You do not write policy proposals to change the RIPE NCC's interpretation of existing policy. > Absent this, the RIPE NCC's operationalisation of the policy will stay > as-is. > ------------------------ On Thu, 11 Jan 2024 at 14:35, Sebastian Graf wrote: > > Dear Tore/Denis: > > If we are looking at the Policy Language, then i'm not certain we are reading the same things into it. > Or maybe i missed something. Feel free to point out the corresponding section of the policy to me. I'm more than happy to update my views if strong evidence is presented. > As a small LIR ... I may not see all edge cases.... but...... So feel free to point out anything important that i may have missed. > > Lets look at the actual language in the policy: > > > "All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations." > > The way i read it, this point is filled both with the current state of things, and also if we have an aggregated status. Space would still be registered. So the question is what kind of data needs to accompany it. > Actually this point is not satisfied by aggregation. When you have all assignments separately registered, as current policy requires and the proposers of this policy update have finally agreed is the case, you can see that each assignment is unique. You cannot assign the same space to two End Users as you cannot create two assignment objects with the same or overlapping prefix. With an aggregation object, all you know is that some part(s) of this aggregated block may be assigned to one or more End Users. You do not know how much is in use, or even if any of the aggregated space is currently in use. It does not satisfy the uniqueness condition as you can't be sure some of the space has not been multiply assigned. > So lets look at what needs to be documented: > > > "Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained)." > > I think you are arguing what both of you are considering "contact information". It does NOT say we state to put personally identifyable information into it. > You are totally correct here. I have never argued for putting PII into the database. > If we read the text literally, then only putting enough information to establish a contact (ie: contact information) would theoretically be sufficient. > So theoretically, a "proxy" type of setup for email/postal mail/... could be permissiable as long as any communication/... is forwarded to the the actual responisble party. > > In fact i would argue for most businesses (End-User or ISP) this is already the case if they make use of "role" contacts for their admin/noc/abuse/... handling. > Also correct. > > "Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained)." > > The other thing that i do not read from the statement is where it asks to put "contact information" for the End-User. It simply reads contact information (one could theoretically interpret this as "contact information for the party that is responsible for managing the space....). > You are missing the infamous lines this proposal wants to delete from the current policy: "When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End User's." > ANYWAY.... > > I still do not feel anything of significance would be lost, if something could be lost at all. I guess you don't accept that the registration details of End Users is significant. >My personal opinion goes the other way.....I suspect, if anything aggregated status could potentially lead to more accurate data. Let me explain: With the aggregation we gain better understanding of the network usage. PLUS the ability to create more specific assignments (under the aggregated). So This way, i feel more usable data would be int the database, compared to now. > With an aggregated block all/some/none of the space covered by this block may be in use by one/many/no End Users. You have no idea about network usage. All that detail may be lost. > This would also be in line with the goals in Section 3.0 - Point 2 "Agregation: Distributing IPv4 addresses in an hierarchical manner permits the aggregation of routing information.". > Aggregating address space registration details has nothing at all to do with routing aggregation. > If we look at the goal for registration: "Registration: The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels.". > Aggregating assignment data does not guarantee uniqueness, or provide information for Internet troubleshooting at ALL levels. > If we consider the usefulnes of data entered into the ripe-db for this purpose, then most useful will be the ISP contact information. Contact information for End-Users (could be an ISP as well) would also be useful in some cases. Personal Information for "individual" type end users (ie: Fred Testuser's DSL Line that comes with a Public IPv4 Address)....to a lesser extend. > > If we look at Section 3.1 ...it reads "Internet Registries (IRs) have a duty of confidentiality to their registrants. Information passed to an IR must be securely stored and must not be distributed wider than necessary within the IR.". > > So i am not certain why you are trying to force more data than actually required/useful into the db. And yes in this context i would consider LIR's in this to be part of this as some type of "local" IR's. > There is always a balance between privacy and the needs of civil society. It was decided many years ago that anyone operating a network using public address space should have contact details available in a public registry. That is still what the current policy says with wording written by Leo (AP WG co-chair, former RS manager) and Mirjam (RIPE chair). The original source of this requirement goes back to address policy written in the 1990s by many varied authors including Daniel (RIPE NCC founder) and Hans Petter (RIPE NCC CEO and former AP WG and LIR WG chair). Unfortunately no one is willing to provide any background information to the current RIPE community about why these rules were originally imposed. That makes it difficult to discuss if those original conditions still apply to the current stakeholders of the RIPE Database, who we also can't easily identify. > During the writing of this email, i realised that you (denis/tore) may consider the need/usecase for adding a "restricted" flag into the DB, that would allow adding information, that is only shown to a select audience (ie: law enforcment, ripe staff and Ripe-Members) - wich could be used to publish PII data. HOWEVER doing something like that would "extend" the existing usecase(s) of the DB and dataentry required - as such this should be in a different Policy Proposal/wg-discussion. Feel free to put one forward, that we can discuss.... > I did consider this option when I put forward my RIPE Database Privacy policy proposal some time ago. The idea of multi level access was not very popular. ------------------------ On Fri, 12 Jan 2024 at 08:12, Tore Anderson wrote: > > Good morning Jan, > > On 12/01/24 07:25, Jan Ingvoldstad wrote: > > I also do not understand what makes it so hard to say that: "Yes, the > > current policy does state something else than NCC's interpretation of > > it does, (?) > > We do not make statements that we do not believe to be true. > > In our opinion, the RIPE NCC implements current policy correctly. > How can you keep saying this when everyone knows it is not true. Regardless of whether or not you support the way the RIPE NCC currently implements the policy, it is NOT what the policy says. We have been over this so many times. The policy is so clear in simple, plain English. For whatever reason, the way the RIPE NCC implements the policy today is NOT what the current policy so clearly says, as written by a co-chair of this WG. You even admitted it yourself in an earlier email (listed above) where you said (and these are YOUR words): > After all, any LIR which prefers the RIPE NCC interpretation of the > policy in this regard is may simply adhere to it and act accordingly, > and this is commonly done today. Thus the RIPE NCC's interpretation of > the policy ? mistaken or not ? ends up becoming the (de facto) way the > policy is implemented anyway. ------------------------ On Fri, 12 Jan 2024 at 08:57, Sebastian Graf wrote: > > Dear Jan! > > As mentioned in my previous e-mail: Would you please post the section of > the policy that you belive has the NCC's interpretation differ from the > actual wording/language used? > > Because i have yet to find a section that states explicitly what is > considered valid vs invalid contact information (other than being out of > date or information that does not provide a contact to the user in a > timely manner). Or a section that restricts what kind of data is > permissable for "contact information". > It is not a question of what is (in)valid contact information. It is about who the contact details refer to. End User or LIR. ------------------------ On Fri, 12 Jan 2024 at 09:28, Sebastian Graf wrote: > > Dear Jan! > > Thank you for your reply. But you have not answerred my question. > > We are all clear/well aware on the fact that the policy states (paraphrasing here: resources need to be registered and the registions need to have contact information). > > We are looking for the DEFINITION of "contact details of the End User.". This is not directly defined (as far as i can tell) and is therefore open for interpretation. > > Unless i missed something? > Yes you have missed something. Take your sentence above "contact details of the End User". This can be split into two parts: "contact details" "of the End User." You are right, there is no definition of "contact details". So it doesn't matter if this is email, phone, fax, postal address or if it is in a role or person object or if it is corporate or personal data. Much of this does matter when it comes to privacy concerns, but that is another discussion. What we are primarily discussing here is the other part "of the End User." So the contact details don't matter for this discussion as long as they collectively refer to the End User. And this reference is not open to any interpretation according to the current policy. ------------------------ On Fri, 12 Jan 2024 at 10:35, Sebastian Graf wrote: > > Dear Jan! > > You and Denis are arguing that registration/user data needs to include certain (sometimes sensitive details (ie: PII)) that need to be put in the database. Your Argument is that this is a policy requirement. > That is NOT what we are arguing. There is no policy requirement regarding the nature of the contact details. The policy states who the contact details should refer to, ie End User or LIR, for example. > When I tried to get both of you to spell out what this "user data"/"contact information" is exactly and where that is defined - We do not get a clear answer. > Because it is not what we are arguing and it is not defined anywhere. > I have read every single of denis replies/comments. > > When asked, neither of you cannot reference a policy section that actually spells out what is considered "contact details". > Because the policy doesn't define this and it is not relevant to this discussion. > According to your own e-mail - your opinion is based on a software interface/implementation (ripe-db). This interface itself is an interpretation of what the policy could mean. > The Interface of the DB also does not specify what kind of Information (regular address, proxy address,...) needs to be inserted. Just that some fields need to be filled out (and its open to interpret what goes into them to a certain extent - wich is the point of this discussion). > Sorry but you have missed the point again. The discussion has nothing to do with RIPE Database interfaces, forms or attribute contents. It is about WHO these details refer to. > The relationship is policy -to- database. Not Database -to- Policy. > > And yet, we have no document or reference that defines what kind of contact information (direct only, or indirect via proxy/masking/....) is permissable. Correct, and it is not relevant. > Just that it needs to be maintained (meaning "if it works" -> OK). All data in the RIPE Database should be maintained and kept up to date. > In my previous e-mail i did argue that in some scenarios working witout"proxy" data is impossible (think: Role/NOC Contacts). > ROLE or PERSON object is also irrelevant to this discussion. > I have also read your reference https://www.ripe.net/publications/docs/ripe-705 . It defines an abuse inbox is mandatory for certain objects. And that it has to be an email address. - Nothing else. Also irrelevant to this discussion. ------------------------ So where does all this leave us? During this discussion we have established that: -We do not understand what many elements of data in the RIPE Database mean. -There are some historical definitions in old documents. These definitions have never been updated, so technically they are the only current definition available. But some of these definitions do not map exactly into the modern world. -Some registration requirements were written in the early 1990s. Some were re-written in 2003. Much of this was written by people who still have a high profile in the RIPE community or RIPE NCC today. -We do not know what the reasoning was for why these requirements were introduced. -We do not know who the major stakeholders are who use the data in the RIPE Database or what information they want and need or what they use it for. -We have no business requirements for the RIPE Database as a public registry. -We do not know what data needs to be registered in the RIPE Database or what information it needs to serve to who for what purpose. -An unknown amount of assignment data in the RIPE Database does not comply with current address policy. -The RIPE NCC does not enforce the current address policy. This may be because the RIPE NCC does not believe they have the power to enforce current policy. -Some members have made it clear they will not enter any of their customer's details into a public registry no matter what policy says for commercial sensitivity reasons. While there are interpretations of current policy they may be considered in violation of policy. So there are other reasons why some people may want to push through this change in End User registration. -We do not know what the potential consequences may be for some stakeholders by making this change. So given all these unknowns, should we go ahead and make this change? It seems like this has been a long and intense discussion. Some people may think we have had sufficient input from the community to be able to make a decision on consensus. But as is often the case, statistics beat perception. So let's look at some numbers. Excluding the chairs, proposers and RIPE NCC staff there have been 22 people who commented on this discussion over the last 6 months. Of these 6 people only made 1 comment and another 6 made 2 comments. Then 8 people made 3 to 6 comments. One person made 12 and one made 24 comments. Also 5 people made up the '+1' brigade. These numbers cover both supporters and objectors. This is quite typical of policy discussion. Many of the 'regular' vocal community members who are involved in almost all policy discussions are included in these numbers. So we are looking at a very small number of people who actually support this proposal. Given all the unknowns we have identified during this discussion and the very small number of supporters, should we still approve this proposal? Bear in mind also that the proposal is basically about adding an inconsequential, minor, optional feature change for the convenience of some operators. It also makes a huge change to the registration requirements of End User assignments which will have an unknown impact on the public registry and some major stakeholders. Now let's add in some other factors. I really do recommend that you all watch John Curran's keynote speech to NANOG about internet governance. https://www.youtube.com/watch?v=U1Ip39Qv-Zk He makes some very interesting points that are highly relevant to this discussion. He talks about 3 phases of the internet. The first one was the early development, done largely by universities and other early adopters of the technology, but largely paid for by governments. Then we went into the commercial phase that covers much of the last 20 years or so. But now we are moving into a public phase where civil society is more knowledgeable and is much more heavily involved. During the commercial phase the tech community could pretty much do what they wanted. If questioned by any parts of civil society or regulators they could just fob them off with No No No No... In the new public phase politicians, regulators, organisations involved in public order are much more aware of the interest by civil society (people who vote in elections). The public is aware of the dangers of the internet as well as the benefits. Politicians and regulators must be seen to be in control. So the days of the tech community saying No No No No to them are over. Now it must be at least No No No Maybe. The Maybe allows the tech community to write something down that they can live with, that politicians can refer to in regulations and everyone is happy. So how does this relate to 2023-04? We have a public registry that we built and maintain. But there are so many things we don't understand now in the 2020s. We all know what the registry was. My research has reminded you of some of the early details. But what is it now and what should it be tomorrow? We don't have answers to these questions. In the face of all these unknowns we want to add an inconsequential feature that could have a massive impact in other areas that we don't fully understand. We know LEAs have serious concerns. But we have just brushed them aside. This very small group of operators that took part in this discussion have prioritised their own convenience over anything else. They have turned that Maybe back into a No. If you approve this proposal with all these unknowns I think you will find that train full of regulators that is rumbling down the line, heading straight for you, will pick up speed. Think of the LEAs sitting in a room behind two doors. One of those doors opens up to the tech community. You are about to slam that door in their face. The other door opens up to the politicians. We still have the option to invite them into our room and talk seriously with them about their needs. Once you slam that door shut, they will walk through the other door and you lose control. Yes I know I am a drama queen. But I am trying to illustrate to you that actions have consequences. Today's consequences may be very different to those of yesterday in a similar situation. Nothing stays the same forever. So is it worth risking the wrath of the politicians for what has been described as a minor, optional feature change that some will find convenient? Let me end by suggesting an alternative path. I have said all this before and been ignored or insulted. But I will say it again anyway. I am used to being insulted on these lists with no one protecting me. 1/ Withdraw this proposal 2023-04 2/ Set up a new Task Force with these primary goals: a/ Determine the business requirements for the RIPE Database as a public registry, looking forwards. b/ Identify the major stakeholders for the RIPE Database public registry. c/ Identify the needs/wants of these stakeholders. d/ Based on the above, determine the registration needs of the public registry, taking account of privacy concerns. 3/ Once we know what we want, design a new data model for the RIPE Database. 4/ Slowly move from where we are now to where we want to be. Yes I know this is a long term project and yes it will cost money. But the RIPE Database is so old, with so many things lost in the mists of time, so many things not applicable to the modern world. If you continue turning your back on all this, you may find the regulators will tell you what they want in the registry. That may be far more costly. I don't think there is anything more I can say on this issue now. cheers denis ======================================================== DISCLAIMER Everything I said above is my personal, professional opinion. It is what I believe to be honest and true to the best of my knowledge. No one in this industry pays me anything. I have nothing to gain or lose by any decision. I push for what I believe is for the good of the Internet, in some small way. Nothing I say is ever intended to be offensive or a personal attack. Even if I strongly disagree with you or question your motives. Politicians question each other's motives all the time. RIPE discussion is often as much about politics and self interest as it is technical. I have a style of writing that some may not be familiar with, others sometimes use it against me. I also have OCD. It makes me see the world slightly differently to others. It drives my mind's obsessive need for detail. I can not change the way I express my detailed opinions. People may choose how to interpret them. ======================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From Emmanuel.Kessler at europol.europa.eu Tue Feb 13 13:17:18 2024 From: Emmanuel.Kessler at europol.europa.eu (Kessler, Emmanuel) Date: Tue, 13 Feb 2024 12:17:18 +0000 Subject: [address-policy-wg] @EXT: RE: URGENT 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) Message-ID: <3d258614e8934ce2a43b9009cb8625f2@europol.europa.eu> Dear partners and chairs of the Address policy working group of RIPE, Please find more clarifications from EUROPOL and Law enforcement agencies, about how the 2023-04 measure would impact the capacity of investigators in identifying cybercriminals. First, I would inform you that we had to open a large consultation with various European services and EU authorities, cybersecurity authorities, that indeed showed an interest on the measure. It has taken some time to collect inputs, ?of course. While we worked on providing concrete inputs as much as possible, we coped with some limits, as we cannot share some information that are under the secrecy of law or judicial cases, we cannot share information in public/open access that could in the end, inform cybercriminals on how countering our activities,?. and as a last point, omniscient statistics do not exist anywhere? Thank you for considering it. Having said that , lets jump with the points... In our assessment, the 2023-04 measure would impact at 2 levels. The first level of impact is that it would complicate the process to access the information. Some European services have confirmed they do use on daily basis, the RIPE data basis to get directly the end user information. It is an easy access for them. They also use support-tools whose results would be weakened through the new configuration. At national level, capacities would be preserved in some extend for some services, but would it would become heavier, as court order would become systematic. At International level, identification of IPs would become far more complicated on digital investigations (from some general assessment, about 80% of investigations have a digital dimension now !),?and especially on cyber cases.... Most of investigations rely on a swift IP identification, that may involve external LIRs and various ISPs that regularly give an IP to others.. An European service gave me the example of a Child sexual abuse material case : an investigator would have to send a mutual legal agreement request to a LIR, to receive as an answer, 4-6 months later, that the IP is handled by an ISP (sometimes in the same country as the investigator)..we will here lose time, with less capacity in the end to identify victims, accomplices, perpetrators, (because of some data retention limits in many countries)? on this situation, it would be for the best interest of all parties if for example, a measure would ensure that, "in any case, LIRs and ISPs that transfer/give any IP or IP block to another legal entity, must declare this information to the RIPE database". It would also become more time consuming in getting the identification, meaning less cases processed by investigators. Judicial proceeding has got more and more complex for many reasons, and the new measure would not help the daily job. The capacity of investigation services is asymmetric with the large volumes of ransomwares attacks, online scams, child sexual abuses materials sharing,? In the end, the new measure could foster by design, a ?bullet proof hosting? like-situation. Here is a point to be also considered. RIPE covers not only the European Union, but also other countries outside the EU. The cooperation level with these countries may vary in a large extend and across time. With some of them, getting a swift answer on the sole court order is not an option, and it may be the most uncertain/long with a mutual legal agreement request. Here again, it would loudly impact us,...as the location of some of these countries are regularly used in a consequent number cyberattacks. Some will say that criminals have not waited for anybody to use bullet proof hosting capacities,?yes,?.but we consider that a measure that may hide their mistakes, clearly does not help us, ....but them?. International cooperation relies on processes, that are still largely humanly tailored by legal authorities (not automatized), linked with sovereignty, respect of fundamental laws and rights, safeguards. ?I believe we all respect that,? but it means consequences on the way the global flow of judicial cooperation may work and some balance is needed in maintaining some efficiency in the processes. The second level of impact would be linked with the quality of the data hosted in an aggregated environment. ?Aggregating multiple IPv4 End User assignments that have consistent contact information and purpose into a single database object? : which impact on cross-matching the information of IPV4???? IPV4 identification is far more challenging than IPV6 one....the matter has become well identified... From our assessment, the measure would impact the granularity of the data, as already said. Through aggregating assignments, it will have as a consequence, the loss of various end users details, preventing cross-matching efforts by investigators, that are essential. While individual assignments offer specific and detailed information about each IP address's usage, aggregated data may obscure such details, potentially complicating investigations that rely on precise IP address information. In the end, the less detailed information will, either require additional steps or inquiries to ascertain the specifics of an IP address's usage, potentially delaying investigative processes?.either identification may not be possible as it was previously? To give you an idea of the extend of impact, Lets? take the example of the CGN-NAT matter. The mutualisation of IPV4 addresses, is here fully considered as a big challenge for investigation. EUROPOL has worked for long on that, especially on this CGN-NAT matter that raises a similar question as the 2023-4 proposal. various reports are publicly available online (IOCTA, or other publications) CGN-NAT configuration greatly helps criminals to get anonymous as the ISP cannot locate the subscriber. Numerous cases have been reported by investigators. Europol met this challenge in important operations, covering for example cases of traffic of arms, or child sexual exploitation (CSAM sharing forum with 62000 members, 10 children victims) in big cases, we may have to process hundreds of IPV4, sometimes thousands in the biggest ones : because of aggregation, we may lose some cross matching/identification opportunities that are essential to solve a case. As an example, on some big cases, the CGN use impacted up to 70% of identifications of perpetrators or accomplices. we observe that the 2023-4 proposal could generate a similar ?fog? with the same extend of impact. The CGN-NAT is so hampering that in answer, some EU countries had to limit the number of subscribers per IP. As another point, the measure observe some inconsistencies in Registration Practices: it acknowledges that some LIRs already apply exceptions to the current policy, leading to inconsistencies in how IPv4 addresses are registered. This inconsistency can pose challenges for law enforcement in tracking and mapping IP addresses to specific users or activities, as the registration practices may not be uniform across different LIRs. However, standardisation should not mean further weaken the quality of data. The expected decreased granularity of the data would raise a question in the context of the EU NIS2 DIRECTIVE, that aims to provide an improved quality of the data available for cybersecurity/legal needs. NIS2 covers identification of DNS, but it would be paradox that while we are progressing on the identification of DNS, we may decrease on identification of IPs,? It is right that so far, EU regulatory efforts have focused on the DNS identification need rather than the IP one, as DNS matter was clearly identified as a urgent need, after the evolution linked with GDPR. the 2023-4 proposal would raise indeed a new concern... To our assessment, ensuring reliable registration requirements for end user contact information (providing the necessary information, without any drafting interpretation) remains here essential to prevent progressive anonymization/losses of data. The way, each ISP will aggregate its data, is a real and complex question, with huge potential impact on investigations. In deep analysis, we still consider that there is a risk of progressive anonymization of data of end users information, with the 2023-4 proposal... For these reasons, the 2023-4 proposal remains at EU level, a matter of concerns and question. As such, it could practically result in being a technical evolution hampering in practice the legal obligation (in many countries) for ISPs to identify end user subscriber information, ....as long as it cannot be proved that the previous identification granularity is maintained. I hope that these information will help you on better understanding our concern. we do understand the business need, however the support of private partners is essential for us on protecting people. Thanks for your cooperation Regards Emmanuel Kessler -----Original Message----- From: Leo Vegoda Sent: 17 January 2024 18:01 To: Kessler, Emmanuel Cc: address-policy-wg at ripe.net; ?ileris, Edvardas ; BAUER-BULST Cathrin ; Tore Anderson ; Azofra Mart?nez, ?lvaro ; Frank Breedijk ; Maria Stafyla Subject: Re: [address-policy-wg] @EXT: RE: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) This email originated from outside Europol. Do not click links or open attachments unless you recognize the sender and know the content is safe. The external address that sent the message is: leo at vegoda.org Dear Emmanuel Kessler, It would help the co-chairs tremendously if your arguments gave some specific numbers or other details. We are aware of your concerns but phrases like "large potential impact" are vague. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs On Mon, 15 Jan 2024 at 02:32, Kessler, Emmanuel wrote: > > Dear all, > > we keep analysing the possible consequences of the measure on our LEA > capacity to identify IPV4 It takes time as it interests various EU official partners and Law enforcement services, ...thanks for your understanding. > > We still identify two issues in the measure > > - about the process to access to data : as ending the direct access at RIPE level, it will not ease the work for some investigators who uses it as a convenient tool, although accessing the data at LIR level still remains partly an option. > > - about the granularity of the data as aggregated, and we think there is here a very strong question, with a large potential impact. > > As you know, EUROPOL has worked for years on the CGN-NAT challenge on IPV4, advocating for limiting this mutualisation of IPV4 addresses that regularly hampers investigation capacities. > we observe the aggregation measure as having a real negative impact on the granularity of the answers that will be collected. > it is also linked with internal practices in the companies that remain various...we know that. > Situation with IPV4 is different than the one with IPV6. > Consequently, we keep all our reserve about the proposal that raises concerns amongst many colleagues. > > We fully understand the code of conduct in RIPE debate, and still appreciate good discussion with constructive and realistic people... > However, getting all the truth of the situation requires contradictory debate that can progress through the exchange of still more detailed explanations,.... > As the matter is of real importance, we hope that the measure would not be adopted without this clarification with all opinions/arguments around the table,... > > We would be also in favour of postponing the deadline of the debate, to take time to exchange and check all the explanations as necessary. > > Thank you for your exchange and cooperation > > Regards > > Emmanuel Kessler > European Cybercrime centre > EUROPOL > > -----Original Message----- > From: denis walker > Sent: 11 January 2024 03:21 > To: Tore Anderson ; Maria Stafyla > Cc: Jan Ingvoldstad ; address-policy-wg at ripe.net; > Frank Breedijk ; Kessler, Emmanuel > > Subject: Re: [address-policy-wg] 2023-04 Review Phase (Add > AGGREGATED-BY-LIR status for IPv4 PA assignments) > > > > This email originated from outside Europol. Do not click links or open attachments unless you recognize the sender and know the content is safe. > The external address that sent the message is: denis1 at gmail.com > > > Hi Tore and others > > On Wed, 10 Jan 2024 at 13:02, Tore Anderson wrote: > > > > Hello again Jan, > > > > On 10/01/24 11:25, Jan Ingvoldstad wrote: > > > Basically, any public company register would be illegal according > > > to the interpretation you lean on here. > > > > Public company registries also need a lawful basis for processing. > > The Norwegian public company registry, for example, uses the lawful > > basis ?exercise of official authority? ? Article 6(1)(e) GDPR ? as > > its lawful basis, see https://www.brreg.no/en/privacy-statement/. I > > would assume that to be the case in most other countries as well. > > > > (Most) LIRs are not official authorities, so unlike public company > > registries LIRs cannot use this lawful basis for publishing PII in > > the RIPE Database. > > As I explained in the previous email, you only quoted half the GDPR > condition here. It actually says, > (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; As I also pointed out, during the discussion of > 2022-01 (privacy) > https://www.ripe.net/ripe/mail/archives/db-wg/2022-October/007630.html > it was accepted that there is a 'public interest' basis here. > > > > > In any case, all of this is rather off-topic. 2023-04 does not > > change the legal obligations on the LIRs relating to the publication > > of End User contact information, > > It does not matter how many times you repeat this, it is still NOT true. You remove the 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. > Removing this line DOES change the LIR's obligations relating to the publication of End User contact information. No matter how many times you repeat this false information I will repeat the reply. > > > nor does it change the RIPE Database Terms and > > Conditions. If you want to publish PII in the RIPE Database, you > > need a lawful basis. That's true today, and that will continue to be > > true if > > 2023-04 passes. > > > > > > > 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. > > > > Exactly. LIRs may (but are not required to) chose this approach > > already *today*. This is a common and long-standing practice which > > the RIPE NCC has repeatedly clarified as compliant with today's policy. > > This is one of your biggest false statements. The ONLY person repeatedly saying this is YOU. Let's do a fact check here. You asked a question to the RIPE NCC about publishing End User contact details in an assignment object. The RIPE NCC PDO, policy officer Angela, consulted with registration services and made a reply. She confirmed, once, it is compliant with current policy to not publish the End User contact details. I have disputed that by quoting the famous line (which you want to remove): > 'When an End User has a network using public address space this must be registered separately with the contact details of the End User.' > I have provided a mountain of supporting evidence that the RIPE NCC's interpretation of this statement is incorrect. Angela's one time answer was incorrect. Since then the RIPE NCC has said exactly NOTHING. No one from registration services has come to this list and expanded, qualified or explained their one time response. But since then you have endlessly repeated that one time response from the RIPE NCC. You have claimed so many times that the RIPE NCC has repeated this many times. That is NOT true. Please STOP saying what is NOT TRUE. It was said once by the RIPE NCC and then disputed. You are still hiding behind this false premise. > > > > > It will continue to be compliant with the policy after 2023-04 > > passes, as well. Thus, 2023-04 effects no change on the LIRs' > > obligations in this regard. > > It has a massive change on the LIR's obligations, by removing a line of text from the current policy, which you have admitted yourself does not need to be removed for your aggregation proposal. You keep repeating that this change has no real, practical impact, so don't remove it. Then we can all get on with our lives. > > > > > > > > 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. > > Then limit the proposal to exactly this!!! > > > > > > > 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. > > This is total madness. You keep saying you have no intention of changing anything else. You keep saying the wording change actually changes nothing in practice. Some other people don't agree with you. > Just don't change wording that you claim changes NOTHING and has nothing to do with aggregation and everyone is happy. The fact that you are pushing so hard to make this wording change, you refuse to back down or compromise, you insist on changing wording that changes nothing and has nothing to do with aggregation...proves that you don't believe that yourself. The fact is, I suspect that this is the real change you want. You want to drop the current policy requirement to define assignments with End User contacts. It is the aggregation that is the side issue here. There is no other explanation for why you are insisting so strongly on changing wording that changes nothing. > > > > > > > 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*. > > > > We are not making the claim that the policy text does not change. > > That it clearly does ? in order to achieve the desired change > > described in item 1 above. > > > > We are however claiming that the *meanings* of the old and the new > > policy texts are exactly the same, with regards to how they > > translate into operational procedures and requirements for the > > publication of End User contact information (item 2). > > You must think that WE are the crazy people. You cannot remove the 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.' > and then say the meaning is exactly the same. I know it is a common tactic now, especially in politics, to keep repeating mis-information that makes no sense over and over again, refusing to listen to objections, until a mass of people start to believe your mis-information. I am one of those free thinkers who doesn't go with the masses. I will keep pointing out the mis-information here. > > > > > As the RIPE NCC writes in the Impact Analysis (emphasis added): > > > > ?Acceptance of this proposal **will not change** the fact that > > the RIPE NCC cannot enforce which contact details members add to > > their > > IPv4 PA assignments in the RIPE Database; this **will remain** their > > decision.? > > > > So, once again: which End User contact details LIRs publish (if any) > > is their decision today, and it will be continue to be their > > decision if > > 2023-04 passes. Hence, 2023-04 does not effect any change in this regard. > > This really does make me cry. The wording in the IA is poor. You have applied an interpretation to this which I do not believe is what was meant. Then the RIPE NCC legal team has remained silent. So I am asking the RIPE NCC legal team to clearly explain what they meant by this wording. Is the legal team actually saying here that the RIPE NCC cannot enforce RIPE policy? The current policy is clear on the 'type' > of contact details. That 'line' says an assignment MUST include an End User contact. It is true the policy does not say the LIR must add Person A as the contact rather than Person B. So in this context the RIPE NCC cannot enforce which (Person A or B) contact details members add to their IPv4 PA assignments. The choice of Person A or Person B will remain the LIR's decision. But when the policy says an assignment MUST include 'an' End User contact, the RIPE NCC can and should enforce that 'a' contact for the End User is added. So I ask the legal team, which interpretation did you mean? > > > > > > > > So maybe we could discuss 1) instead of 2) going forward? :-) > > > > > > I have no problem with 1), as already stated. > > > > We're happy to hear that! > > > > > > > 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. > > > 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. > > > > This ?beef? is based on reading current policy to mean that which > > End User contact details LIRs publish in the database (if any) is > > *not* the LIRs' decision today. > > It is based on reading the current policy and understanding what a very clear sentence written in plain English means. > > > > > But the RIPE NCC has repeatedly clarified that that is simply not > > the > > case: it *is* the LIRs' decision today, and it will continue to be LIRs' > > decision should 2023-04 pass. > > You are doing it again. The RIPE NCC has said something ONCE and refused to clarify it ever since, despite it being contested. It is YOU who repeatedly claims something. > > > > > Given that, it is hard to see how we could possibly amend the > > proposal to change this particular point to an even lesser extent > > than what is already the case? > > Let me help you. Do NOT remove a sentence that has nothing to do with the stated goal of the proposal to aggregate assignments and that you claim does not change anything. > > 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/ > -- > > To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://mailman.ripe.net/ From erik at bais.name Tue Feb 13 16:56:02 2024 From: erik at bais.name (Erik Bais) Date: Tue, 13 Feb 2024 15:56:02 +0000 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> <5c457b41-b9f4-4942-8e27-181e73726001@fud.no> <8a01f7df-390b-4928-bf7c-6584c80587dd@fud.no> <0358e4da-f314-4eaa-8c84-56bea25ff5f0@sebastian-graf.at> <4aefc5f8-1109-4cef-a6e0-7efd28fd6a00@sebastian-graf.at> Message-ID: <60CDFA71-8EA6-4940-8130-DBBA28425303@a2b-internet.com> Dear Denis, Thank you for your long email. I have a couple comments that I like to make on it, especially about what you state in regards to what our ?mandate? is as WG Chairs, on the WG ML and the PDP discussions. As AP-WG chairs we aim to facilitate fruitful discussions on topics that are within the scope of Address Policy, as this is the Address Policy WG. As such, we like to keep the discussion, civil, on topic and hope to see PDP related discussions about the policy that is proposed. We will moderate the discussions, to stay on topic of the said policy, to avoid having very long discussion that are not related to the policy itself. This policy in particular is quite clear and although it proposes on how to change/register assignments in the database, it doesn?t talk about a complete database redesign or overhaul. If you like to create a full TF or alike to have a discussion about the state of the DB, please do so in the correct WG for it. ( please read this as . . . not in AP-WG ) So, yes we?ve read your email and we will note your objection. Regards, Erik Bais on behalf of the Co-Chair collective of the AP-WG. From: address-policy-wg on behalf of denis walker Date: Saturday, 10 February 2024 at 09:10 To: "address-policy-wg at ripe.net" Cc: Tore Anderson , Jan Ingvoldstad Subject: Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) Colleagues I am back!! Thanks to those who agreed I should never have been away. I am not going to focus on that for now. I do have a lot to say around that issue. But that is for another day, on another mailing list. I won't discuss it here and I will wait until we conclude the discussion on this proposal. I want people to focus on the message rather than the messenger. There hasn't been much conversation while I have been away, but still several significant points that seemed to have been missed by most observers. I have answered all points raised by several people in this single email. In these days of uncertainty, who knows how long any of us will be around. So it is more of an article than an email. But I do end with a positive recommendation. Let's start with a comment by Leo: "We encourage everyone to focus comments on the proposal and its potential impact. Do not comment on individuals, their characteristics, or motivations." The co-chairs have no authority to determine what constitutes part of this discussion. If individuals use tactics that may confuse the community or repeatedly make comments that are not true, they make themselves part of the discussion. The co-chairs have no right to try to prevent these issues from being highlighted and discussed. People need to understand that personal criticism is not a personal attack, even if it is strong criticism. When an individual repeatedly says something that is not true, to highlight this issue and ask them why they keep saying this is not a personal attack. Criticism is part of life, especially in business. Throughout this discussion there has been lots of criticism thrown at me. My characteristics have been heavily criticised and commented on. Even who I speak for has been questioned. No one has questioned if an employee speaks on behalf of their employer. My motivations have also been questioned. It was suggested that I should not talk about the RIPE Database on the Address Policy WG. Even though the old design and technology of the database is one of the key elements used to support the need for aggregation. So much criticism aimed at me and yet the co-chairs saw no reason to intervene. They only intervene when I criticise someone. Then there is motivation. Is it questionable? A lot of the discussion on policy is political, commercial and self interest based. In these contexts I believe it is acceptable to question motivation. The co-chairs never asked what I meant by what I said. Of course the proposal is about aggregation. It's in the title and the text. But it is about a lot more than that. There are two main aspects to this proposal. An inconsequential, minor feature change that people may or may not use. And a major change to the handling of End User details, which people also may or may not take advantage of. The two aspects combined can make a massive change to the available information in the RIPE Database. But the proposal did not even mention the change to End User details. Is it important? Well after I pointed it out, some people who had said "+1 I agree with this proposal" changed their mind and withdrew their support. So for them it was highly relevant. There are sections in the proposal template for supporting and opposing issues relating to the proposal. Depending on your point of view this major change should have been listed in one of those sections. But it wasn't. So did the proposers fully understand the implications of this change or not? I must be allowed to ask that question as part of this discussion. If they did understand it, why did they not mention it? Did they overlook it, or was there some other reason? Again I have to be able to ask these questions. This is all about motivation. To ask these questions and understand what happened is not a personal attack. It is a reasonable line of inquiry. Enough about the messenger, let's get back to the message. ------------------------ On Mon, 18 Dec 2023 at 16:49, Edwin Verheul via address-policy-wg > wrote: > > I support this proposal. > > Since this policy introduces convenience for LIR by aligning ipv4 object policy to the ipv6 policy, unclear usage of the admin contact should not prevent this improvement in policy. This pretty much sums up a lot of people's view of this proposal. It is 'convenient' for the operators. Who cares if it is the right thing to do or not, it is convenient. It doesn't align v4 and v6, there are significant differences in the defined aggregations. Never mind if we don't understand what the data means, let's just change it anyway as it is convenient. Maybe a few of you should watch John Curran's keynote speech at NANOG on internet governance: https://www.youtube.com/watch?v=U1Ip39Qv-Zk He talks about phases of the internet and how we are now moving from the 'commercial' internet to the 'public' internet. With this public internet, civil society has/wants a much bigger say in how things work. Organisations that represent civil society and civil order are more concerned about how things work. Politicians are concerned about what their voters think. Do you think civil society cares about operator convenience? They are more likely to think 'it's your job, do it. That's what we pay you for'. I think civil society will be more interested in knowing who is spamming them or attacking their network and can the police catch them, rather than operator convenience. Now let's think a bit more about what this data means and how to interpret it. ------------------------ On Fri, 12 Jan 2024 at 08:56, Alex Le Heux > wrote: > > During the discussion about AGGREGATED-BY-LIR status for IPv4 PA assignments the argument has been raised that this proposal would substantially change the registration requirements for end-user assignments in the RIPE DB and the discussion has been going around in circles ever since. > > We would like to point out the following: > > From the RIPE NCC Impact Analysis: > > Acceptance of this proposal will not change the fact that the RIPE NCC cannot enforce which contact details members add to their IPv4 PA assignments in the RIPE Database; this will remain their decision. > This is completely out of context. I have asked the RIPE NCC legal team to clarify what this means but I guess by their silence they declined. To me this sentence says the member can choose to enter the details of Contact A or Contact B and choose what the details are. Which one (A or B) and the details (email or phone) they enter will be their decision. The RIPE NCC cannot enforce if they enter A or B or email or phone. WHO these contacts represent is a matter of policy. The current policy says they MUST be representatives of the End User. That can be enforced by the RIPE NCC, but they choose not to enforce it. > > As well as: > > It is fact that the RIPE NCC has interpreted the current policy to not require a PA Assignment in the RIPE DB to include the actual name and email address of the end-user since at leas the late 1990s. Registering a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR has been acceptable for all this time. > This is completely false. I know Alex well and will give him the benefit of the doubt that he has not picked up on the detail here. He signed this email 'for the Address Policy WG co-chairs'. A lot was said about who I speak for, so I assume Alex was speaking 'for' all the chairs. I was told that signing as 'co-chair DB-WG' gives what I say more weight and has more influence on the community. The same must apply when the co-chairs of this WG collectively sign an email. The community will assume that statement carries more validity. Let's look at the detail. Address policy from the early 1990s has made it clear that assignments must include contact details of the End User. But ripe-288, 28 Oct 2003 is particularly interesting. The authors of this version of the address policy were: Mirjam K?hne, Paul Rendek, Sabrina Wilmot, Leo Vegoda At that time they were all current or former NCC staff. Leo was the operations manager of the RIPE NCC Registration Services (RS). Paul was the senior manager responsible for RS. In this version, these authors added the exact wording that we have today: "When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End User's." The wording was very different before this. The document was restructured and the wording changed. So they must have thought about what this meant. I cannot believe that when these words were added to the policy by the RS manager and RS senior manager they were not enforced by RS. Maybe Leo can give some background to this. Nothing in this industry changes quickly. So if these newly worded requirements were enforced just 20 years ago, they must have been enforced for at least 5 to 10 years. That means the RIPE NCC's interpretation of this wording, written by the RS manager, has only changed in the last 5 to 10 years. I have been told by some former members of RS that they stopped enforcing these requirements at runout of IPv4. They told me that when they had no more address space to allocate, they had no power to enforce these rules. So they simply stopped enforcing them. This paints a very different picture. We are not changing policy to match a common practice. We are dropping policy because it is difficult to enforce, regardless of the reasons why the policy was introduced. It is also interesting that, no matter how many times you read something, you don't always see what it says. A lot has been said about replacing the admin-c and tech-c contacts in an assignment with the contacts of the LIR. It has been said that the RIPE NCC now considers this acceptable. But look at what the current policy actually says: "Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End User's." So this substitution is only allowed by policy where the End User is an individual. You cannot do it for all End Users. This actually makes sense to me. If I want to contact the LIR's tech or admin contacts, they are already available in the RIPE Database in the allocation object. Why duplicate the data in the assignment. The policy says the assignment must have the End User's contacts. So that is another misinterpretation of the current policy. > > > In its impact analysis the RIPE NCC has indicated that this proposal does not change this interpretation. > > It should therefore be clear that 2023-04 does not in fact change anything regarding how end-user details will actually be registered in PA Assignments. Interesting choice of words. It may not change how some End User details 'will' actually be registered, but it changes how they 'should' be registered enormously. > > However, is has been argued that this interpretation is wrong and that PA Assignments in the RIPE DB must include the actual end-user details. And even though this is out of scope for the 2023-04 discussion, it is still something that is worth resolving. As changing this interpretation would be a major departure of many years of accepted practice and potentially involve updating thousands of RIPE DB objects, we feel this discussion would be best served by an independent policy proposal that clarifies the issue and would like to invite the working group to enter one. > I agree this needs further clarification. But you can't write a policy proposal on something you don't understand. We don't know what much of the data means now or in the past, or why we have these rules, or what we need now. Until we have the business requirements for the RIPE Database as a public registry any such policy proposal, including this one, is just a dangerous stab in the dark. > Kind regards, > > Alex Le Heux, for the Address Policy WG co-chairs It is interesting that this email was signed 'for' all the co-chairs of this WG. How can the co-chairs approve this policy proposal (2023-04) while accepting that another proposal is needed to clarify if the RIPE Database must include the actual End User contact details? Are they going to approve a policy proposal that potentially removes this End User detail requirement and then consider a policy proposal that would require them to put this detail back into the RIPE Database? ------------------------ On Thu, 11 Jan 2024 at 09:40, Tore Anderson > wrote: > > Hello Denis, > > On 11/01/24 01:40, denis walker wrote: > > So personal data does not always need consent of the data > > subject. But you only ever refer to (a) consent. > > There are indeed other possible lawful bases than consent, and this fact > is precisely why I wrote (emphasis added): > > ?Publishing this information requires *a* lawful basis, *e.g.*, consent.? > > Consent is however the only lawful basis singled out by the RIPE NCC in > the RIPE Database Terms and Conditions and in the 2023-04 Impact > Analysis, so it seems reasonable to assume that some LIRs will seek consent. I wrote the T&C before GDPR was in place. That's why it doesn't refer to any of the other lawful options. I questioned the IA but the legal team chose not to respond. > > Therefore we need to examine what that actually means in practice. You > sum it up quite accurately below: > > > > 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. > > Your conclusion that this situation results in a policy violation, is > however entirely contingent on your interpretation of the current policy > as mandating the publication of the End User's (non-delegated) contact > information. You did not read what I wrote. I was talking about LIR contacts in allocation objects. If that is PII (and a lot of it is) the subjects can now ask for it to be removed. That may leave allocation objects with no LIR contacts. That is syntactically not possible in the RIPE Database. > > Under the RIPE NCC's interpretation of the current policy, on the other > hand, this situation is entirely unproblematic. Under their > interpretation, the LIR has, quote, ?freedom to take over the > responsibility as the point of contact for their End User?. No PII, no > GDPR, no problem. But if the LIR has NO contacts because they have asked for their details to be removed then you can't replace the End User contacts with non-existent LIR contacts. You and the legal team have started a chain reaction here by declaring that ALL contacts in the RIPE Database are there by consent. The RIPE NCC, as joint data controller for the RIPE Database, now has joint responsibility, and I presume therefore joint liability, for 2 million people having given their consent to their details being added into a PERSON object in the database. > > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013892.html > > > 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. > > KPN or Apple would not be relevant examples, as they (presumably) would > use non-personal NOC roles which are not PII, and thus out of scope of > the GDPR. The RIPE NCC is a corporate body and yet it has many PERSON objects in the database relating to individual staff members as contacts for their resources. ------------------------ On Thu, 11 Jan 2024 at 09:45, Tore Anderson > wrote: > > Hi Denis, > > On 11/01/24 03:20, denis walker wrote: > > On Wed, 10 Jan 2024 at 13:02, Tore Anderson > wrote: > >> > >> On 10/01/24 11:25, Jan Ingvoldstad wrote: > >>> 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. > >> Exactly. LIRs may (but are not required to) chose this approach already > >> *today*. This is a common and long-standing practice which the RIPE NCC > >> has repeatedly clarified as compliant with today's policy. > > This is one of your biggest false statements. The ONLY person > > repeatedly saying this is YOU. Let's do a fact check here. > > Yes, let us indeed do a fact check: > Your fact checking is not very accurate. > Exhibit 1: > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013856.html > This is the one time the RIPE NCC made this argument, which I have disputed. > Exhibit 2: https://www.ripe.net/participate/policies/proposals/2023-04 > (specifically the ?counter-argument?, which the RIPE NCC Policy Officer > confirmed to the proposers and the WG chairs as correctly representing > the RIPE NCC's interpretation) > This 'counter argument' is your argument and is completely false. > Exhibit 3: > https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis > I have explained this above. This is the argument about LIRs adding Contact A or Contact B or email or phone. THAT is their decision. Who these contacts represent is set in the current policy and is not the LIR's choice. > Exhibit 4: > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013892.html > All the talk about maintainers, descr attributes, DB T&C and documentation has nothing to do with address policy. All they say here is that this proposal won't influence how the RIPE NCC currently carries out ARCs. They are doing it wrong now and will continue to do it wrong. > Four repetitions so far, all saying the same thing. How many more do you > need? > One statement and no repetitions. They all say something different, which most people can clearly see. > > >> As the RIPE NCC writes in the Impact Analysis (emphasis added): > >> > >> ?Acceptance of this proposal **will not change** the fact that the > >> RIPE NCC cannot enforce which contact details members add to their IPv4 > >> PA assignments in the RIPE Database; this **will remain** their decision.? > >> Same repetitive argument again and again. Yes it IS the LIR's decision to enter Contact A or Contact B or email or phone. It is the POLICY that determines who those contacts represent. How many more times are we going to have this same discussion? (Which the legal team will not clarify.) > >> So, once again: which End User contact details LIRs publish (if any) is > >> their decision today, and it will be continue to be their decision if > >> 2023-04 passes. YES AGAIN the LIR can always choose between Contact A and Contact B, email or phone. They cannot choose to not enter any End User contact details. > >> Hence, 2023-04 does not effect any change in this regard. But as everyone else can see, this makes a huge change. > > This really does make me cry. The wording in the IA is poor. You have > > applied an interpretation to this which I do not believe is what was > > meant. Then the RIPE NCC legal team has remained silent. So I am > > asking the RIPE NCC legal team to clearly explain what they meant by > > this wording. > > The explanation you request was posted two days after the Impact > Analysis was: > > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013892.html > > ?LIRs are free to choose how to provide services and to who, this > includes their freedom to take over the responsibility as the point of > contact for their End User as well as having their maintainer in the > IPv4 PA assignments they register.? > > This explanation aligns perfectly with our interpretation of the > statement in the Impact Analysis. > Wrong again. Yes the LIR is free to take over responsibility for technical matters. You can always find their contact details in the allocation object. So the public, civil society, LEAs, and other LIRs can choose who they want to contact...the LIR or the End User. Between the allocation and assignment objects you have all the contact details you need...according to current policy. The LIR does NOT have the freedom, according to current policy, to replace the admin-c and tech-c contacts in the assignment object with their own contact details in all situations. Again the current policy wording is clear and not interpretable: "Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End User's." So you can ONLY replace the assignment contacts with those of the LIR IF the End User is an individual. Again this is simple, plain English, originally written by Leo and Mirjam. > >> Given that, it is hard to see how we could possibly amend the proposal > >> to change this particular point to an even lesser extent than what is > >> already the case? > > Let me help you. Do NOT remove a sentence that has nothing to do with > > the stated goal of the proposal to aggregate assignments and that you > > claim does not change anything. > > This sentence also has a lot to do with the stated goal of aggregating > assignments, because it mandates that assignments must be ?registered > separately?. That is clearly incompatible with aggregation. > **** Finally, FINALLY you have admitted that this change that is not a change and that changes nothing does actually change something. **** It changes the registration requirements for assignments, which I have been saying all along and which you have been denying for months. ------------------------ On Thu, 11 Jan 2024 at 10:19, Jan Ingvoldstad > wrote: > > > On Thu, Jan 11, 2024 at 9:45AM Tore Anderson > wrote: >> If our ulterior goal was to remove the End User contacts from our own >> assignments we can just go ahead and do so, right now. The RIPE NCC is >> already on the record saying that's totally OK, and we would be >> following in the footsteps of many other LIRs who have already done so. > While you seem to argue that the RIPE NCC is both omniscient and omnicompetent, I do not think it is that easy. > > I simply think that the RIPE NCC and you are mistaken. > After talking to former members of RS I am beginning to think that the RIPE NCC is not mistaken. They know exactly what the current policy says and they know what it means. After all, it was written by former RS managers. BUT they don't believe they have any power to enforce it. This is why they quietly ignore what the policy says. I'll say more about that in my conclusion at the end of this email. > Continously appealing to RIPE NCC as the authority of policy and policy interpretation is not a good thing. > > It undermines the community drive behind policies. > > If this is where we are going, it seems that we would be just as well off by letting EU politicians run the show. > If you have watched John Curran's keynote speech at NANOG and think about the way a handful of operators are pushing this proposal through, the EU politicians WILL be running the show in the near future. https://www.youtube.com/watch?v=U1Ip39Qv-Zk > -- > Jan ------------------------ On Thu, 11 Jan 2024 at 13:11, Tore Anderson > wrote: > > On 11/01/24 10:19, Jan Ingvoldstad wrote: > > > > Continously appealing to RIPE NCC as the authority of policy and > > policy interpretation is not a good thing. > > The RIPE NCC is the secretariat of the RIPE Community and is delegated > the task of implementing and enforcing the RIPE Community policies, as > well as to providing training to the LIRs on how to operationalise said > policies. If that is not an authority worth paying attention to, I do > not know what is. > Exactly, the RIPE NCC is the secretariat, not the policy decision maker. They are supposed to enforce community derived policy. IF they don't think they have the powers to enforce a policy they should raise that issue with the community and seek guidance. They should not just quietly ignore the policy, or part of it. > After all, any LIR which prefers the RIPE NCC interpretation of the > policy in this regard is may simply adhere to it and act accordingly, > and this is commonly done today. Thus the RIPE NCC's interpretation of > the policy ? mistaken or not ? ends up becoming the (de facto) way the > policy is implemented anyway. > If a policy has unintentional interpretations it is badly written. LIRs should not be in a position to choose between a community view and the RIPE NCC's view of a policy. A RIPE NCC interpretation of a policy that conflicts with a community view should not become a de facto implementation. If such a situation arises the conflict must be resolved. ------------------------ On Thu, 11 Jan 2024 at 14:11, Tore Anderson > wrote: > > Hi Jan, > > On 11/01/24 13:27, Jan Ingvoldstad wrote: > > On Thu, Jan 11, 2024 at 1:11PM Tore Anderson > wrote: > > > > After all, any LIR which prefers the RIPE NCC interpretation of the > > policy in this regard is may simply adhere to it and act accordingly, > > and this is commonly done today. Thus the RIPE NCC's > > interpretation of > > the policy ? mistaken or not ? ends up becoming the (de facto) way > > the > > policy is implemented anyway. > > > > This statement basically renders the point of a policy working group moot. > I totally agree. > Not at all. Any working group member who is of the opinion that the RIPE > NCC is interpreting a RIPE Community policy incorrectly, is free to at > any point submit a policy proposal that clarifies the allegedly > misinterpreted policy text with the aim to make the RIPE NCC change its > procedures accordingly. > A policy proposal would only be needed if the policy is so badly written it needs clarity. When the policy is clear and simple, but the RIPE NCC is either misinterpreting it or doesn't believe it has the power to enforce it, we don't need a policy change. We need an interpretation change. > The RIPE NCC's Impact Analysis will then reveal whether or not the > proposed new policy text does attain its goal and that the RIPE NCC will > change its procedures as desired, should the proposal pass. > > Finally, the proposal will need to reach (rough) consensus in order to > confirm that the RIPE Community does indeed concur with the proposer's > opinion that the old policy was interpreted incorrectly, and that the > RIPE NCC's procedures ought to change. > You do not write policy proposals to change the RIPE NCC's interpretation of existing policy. > Absent this, the RIPE NCC's operationalisation of the policy will stay > as-is. > ------------------------ On Thu, 11 Jan 2024 at 14:35, Sebastian Graf > wrote: > > Dear Tore/Denis: > > If we are looking at the Policy Language, then i'm not certain we are reading the same things into it. > Or maybe i missed something. Feel free to point out the corresponding section of the policy to me. I'm more than happy to update my views if strong evidence is presented. > As a small LIR ... I may not see all edge cases.... but...... So feel free to point out anything important that i may have missed. > > Lets look at the actual language in the policy: > > > "All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations." > > The way i read it, this point is filled both with the current state of things, and also if we have an aggregated status. Space would still be registered. So the question is what kind of data needs to accompany it. > Actually this point is not satisfied by aggregation. When you have all assignments separately registered, as current policy requires and the proposers of this policy update have finally agreed is the case, you can see that each assignment is unique. You cannot assign the same space to two End Users as you cannot create two assignment objects with the same or overlapping prefix. With an aggregation object, all you know is that some part(s) of this aggregated block may be assigned to one or more End Users. You do not know how much is in use, or even if any of the aggregated space is currently in use. It does not satisfy the uniqueness condition as you can't be sure some of the space has not been multiply assigned. > So lets look at what needs to be documented: > > > "Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained)." > > I think you are arguing what both of you are considering "contact information". It does NOT say we state to put personally identifyable information into it. > You are totally correct here. I have never argued for putting PII into the database. > If we read the text literally, then only putting enough information to establish a contact (ie: contact information) would theoretically be sufficient. > So theoretically, a "proxy" type of setup for email/postal mail/... could be permissiable as long as any communication/... is forwarded to the the actual responisble party. > > In fact i would argue for most businesses (End-User or ISP) this is already the case if they make use of "role" contacts for their admin/noc/abuse/... handling. > Also correct. > > "Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained)." > > The other thing that i do not read from the statement is where it asks to put "contact information" for the End-User. It simply reads contact information (one could theoretically interpret this as "contact information for the party that is responsible for managing the space....). > You are missing the infamous lines this proposal wants to delete from the current policy: "When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End User's." > ANYWAY.... > > I still do not feel anything of significance would be lost, if something could be lost at all. I guess you don't accept that the registration details of End Users is significant. >My personal opinion goes the other way.....I suspect, if anything aggregated status could potentially lead to more accurate data. Let me explain: With the aggregation we gain better understanding of the network usage. PLUS the ability to create more specific assignments (under the aggregated). So This way, i feel more usable data would be int the database, compared to now. > With an aggregated block all/some/none of the space covered by this block may be in use by one/many/no End Users. You have no idea about network usage. All that detail may be lost. > This would also be in line with the goals in Section 3.0 - Point 2 "Agregation: Distributing IPv4 addresses in an hierarchical manner permits the aggregation of routing information.". > Aggregating address space registration details has nothing at all to do with routing aggregation. > If we look at the goal for registration: "Registration: The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels.". > Aggregating assignment data does not guarantee uniqueness, or provide information for Internet troubleshooting at ALL levels. > If we consider the usefulnes of data entered into the ripe-db for this purpose, then most useful will be the ISP contact information. Contact information for End-Users (could be an ISP as well) would also be useful in some cases. Personal Information for "individual" type end users (ie: Fred Testuser's DSL Line that comes with a Public IPv4 Address)....to a lesser extend. > > If we look at Section 3.1 ...it reads "Internet Registries (IRs) have a duty of confidentiality to their registrants. Information passed to an IR must be securely stored and must not be distributed wider than necessary within the IR.". > > So i am not certain why you are trying to force more data than actually required/useful into the db. And yes in this context i would consider LIR's in this to be part of this as some type of "local" IR's. > There is always a balance between privacy and the needs of civil society. It was decided many years ago that anyone operating a network using public address space should have contact details available in a public registry. That is still what the current policy says with wording written by Leo (AP WG co-chair, former RS manager) and Mirjam (RIPE chair). The original source of this requirement goes back to address policy written in the 1990s by many varied authors including Daniel (RIPE NCC founder) and Hans Petter (RIPE NCC CEO and former AP WG and LIR WG chair). Unfortunately no one is willing to provide any background information to the current RIPE community about why these rules were originally imposed. That makes it difficult to discuss if those original conditions still apply to the current stakeholders of the RIPE Database, who we also can't easily identify. > During the writing of this email, i realised that you (denis/tore) may consider the need/usecase for adding a "restricted" flag into the DB, that would allow adding information, that is only shown to a select audience (ie: law enforcment, ripe staff and Ripe-Members) - wich could be used to publish PII data. HOWEVER doing something like that would "extend" the existing usecase(s) of the DB and dataentry required - as such this should be in a different Policy Proposal/wg-discussion. Feel free to put one forward, that we can discuss.... > I did consider this option when I put forward my RIPE Database Privacy policy proposal some time ago. The idea of multi level access was not very popular. ------------------------ On Fri, 12 Jan 2024 at 08:12, Tore Anderson > wrote: > > Good morning Jan, > > On 12/01/24 07:25, Jan Ingvoldstad wrote: > > I also do not understand what makes it so hard to say that: "Yes, the > > current policy does state something else than NCC's interpretation of > > it does, (?) > > We do not make statements that we do not believe to be true. > > In our opinion, the RIPE NCC implements current policy correctly. > How can you keep saying this when everyone knows it is not true. Regardless of whether or not you support the way the RIPE NCC currently implements the policy, it is NOT what the policy says. We have been over this so many times. The policy is so clear in simple, plain English. For whatever reason, the way the RIPE NCC implements the policy today is NOT what the current policy so clearly says, as written by a co-chair of this WG. You even admitted it yourself in an earlier email (listed above) where you said (and these are YOUR words): > After all, any LIR which prefers the RIPE NCC interpretation of the > policy in this regard is may simply adhere to it and act accordingly, > and this is commonly done today. Thus the RIPE NCC's interpretation of > the policy ? mistaken or not ? ends up becoming the (de facto) way the > policy is implemented anyway. ------------------------ On Fri, 12 Jan 2024 at 08:57, Sebastian Graf > wrote: > > Dear Jan! > > As mentioned in my previous e-mail: Would you please post the section of > the policy that you belive has the NCC's interpretation differ from the > actual wording/language used? > > Because i have yet to find a section that states explicitly what is > considered valid vs invalid contact information (other than being out of > date or information that does not provide a contact to the user in a > timely manner). Or a section that restricts what kind of data is > permissable for "contact information". > It is not a question of what is (in)valid contact information. It is about who the contact details refer to. End User or LIR. ------------------------ On Fri, 12 Jan 2024 at 09:28, Sebastian Graf > wrote: > > Dear Jan! > > Thank you for your reply. But you have not answerred my question. > > We are all clear/well aware on the fact that the policy states (paraphrasing here: resources need to be registered and the registions need to have contact information). > > We are looking for the DEFINITION of "contact details of the End User.". This is not directly defined (as far as i can tell) and is therefore open for interpretation. > > Unless i missed something? > Yes you have missed something. Take your sentence above "contact details of the End User". This can be split into two parts: "contact details" "of the End User." You are right, there is no definition of "contact details". So it doesn't matter if this is email, phone, fax, postal address or if it is in a role or person object or if it is corporate or personal data. Much of this does matter when it comes to privacy concerns, but that is another discussion. What we are primarily discussing here is the other part "of the End User." So the contact details don't matter for this discussion as long as they collectively refer to the End User. And this reference is not open to any interpretation according to the current policy. ------------------------ On Fri, 12 Jan 2024 at 10:35, Sebastian Graf > wrote: > > Dear Jan! > > You and Denis are arguing that registration/user data needs to include certain (sometimes sensitive details (ie: PII)) that need to be put in the database. Your Argument is that this is a policy requirement. > That is NOT what we are arguing. There is no policy requirement regarding the nature of the contact details. The policy states who the contact details should refer to, ie End User or LIR, for example. > When I tried to get both of you to spell out what this "user data"/"contact information" is exactly and where that is defined - We do not get a clear answer. > Because it is not what we are arguing and it is not defined anywhere. > I have read every single of denis replies/comments. > > When asked, neither of you cannot reference a policy section that actually spells out what is considered "contact details". > Because the policy doesn't define this and it is not relevant to this discussion. > According to your own e-mail - your opinion is based on a software interface/implementation (ripe-db). This interface itself is an interpretation of what the policy could mean. > The Interface of the DB also does not specify what kind of Information (regular address, proxy address,...) needs to be inserted. Just that some fields need to be filled out (and its open to interpret what goes into them to a certain extent - wich is the point of this discussion). > Sorry but you have missed the point again. The discussion has nothing to do with RIPE Database interfaces, forms or attribute contents. It is about WHO these details refer to. > The relationship is policy -to- database. Not Database -to- Policy. > > And yet, we have no document or reference that defines what kind of contact information (direct only, or indirect via proxy/masking/....) is permissable. Correct, and it is not relevant. > Just that it needs to be maintained (meaning "if it works" -> OK). All data in the RIPE Database should be maintained and kept up to date. > In my previous e-mail i did argue that in some scenarios working witout"proxy" data is impossible (think: Role/NOC Contacts). > ROLE or PERSON object is also irrelevant to this discussion. > I have also read your reference https://www.ripe.net/publications/docs/ripe-705 . It defines an abuse inbox is mandatory for certain objects. And that it has to be an email address. - Nothing else. Also irrelevant to this discussion. ------------------------ So where does all this leave us? During this discussion we have established that: -We do not understand what many elements of data in the RIPE Database mean. -There are some historical definitions in old documents. These definitions have never been updated, so technically they are the only current definition available. But some of these definitions do not map exactly into the modern world. -Some registration requirements were written in the early 1990s. Some were re-written in 2003. Much of this was written by people who still have a high profile in the RIPE community or RIPE NCC today. -We do not know what the reasoning was for why these requirements were introduced. -We do not know who the major stakeholders are who use the data in the RIPE Database or what information they want and need or what they use it for. -We have no business requirements for the RIPE Database as a public registry. -We do not know what data needs to be registered in the RIPE Database or what information it needs to serve to who for what purpose. -An unknown amount of assignment data in the RIPE Database does not comply with current address policy. -The RIPE NCC does not enforce the current address policy. This may be because the RIPE NCC does not believe they have the power to enforce current policy. -Some members have made it clear they will not enter any of their customer's details into a public registry no matter what policy says for commercial sensitivity reasons. While there are interpretations of current policy they may be considered in violation of policy. So there are other reasons why some people may want to push through this change in End User registration. -We do not know what the potential consequences may be for some stakeholders by making this change. So given all these unknowns, should we go ahead and make this change? It seems like this has been a long and intense discussion. Some people may think we have had sufficient input from the community to be able to make a decision on consensus. But as is often the case, statistics beat perception. So let's look at some numbers. Excluding the chairs, proposers and RIPE NCC staff there have been 22 people who commented on this discussion over the last 6 months. Of these 6 people only made 1 comment and another 6 made 2 comments. Then 8 people made 3 to 6 comments. One person made 12 and one made 24 comments. Also 5 people made up the '+1' brigade. These numbers cover both supporters and objectors. This is quite typical of policy discussion. Many of the 'regular' vocal community members who are involved in almost all policy discussions are included in these numbers. So we are looking at a very small number of people who actually support this proposal. Given all the unknowns we have identified during this discussion and the very small number of supporters, should we still approve this proposal? Bear in mind also that the proposal is basically about adding an inconsequential, minor, optional feature change for the convenience of some operators. It also makes a huge change to the registration requirements of End User assignments which will have an unknown impact on the public registry and some major stakeholders. Now let's add in some other factors. I really do recommend that you all watch John Curran's keynote speech to NANOG about internet governance. https://www.youtube.com/watch?v=U1Ip39Qv-Zk He makes some very interesting points that are highly relevant to this discussion. He talks about 3 phases of the internet. The first one was the early development, done largely by universities and other early adopters of the technology, but largely paid for by governments. Then we went into the commercial phase that covers much of the last 20 years or so. But now we are moving into a public phase where civil society is more knowledgeable and is much more heavily involved. During the commercial phase the tech community could pretty much do what they wanted. If questioned by any parts of civil society or regulators they could just fob them off with No No No No... In the new public phase politicians, regulators, organisations involved in public order are much more aware of the interest by civil society (people who vote in elections). The public is aware of the dangers of the internet as well as the benefits. Politicians and regulators must be seen to be in control. So the days of the tech community saying No No No No to them are over. Now it must be at least No No No Maybe. The Maybe allows the tech community to write something down that they can live with, that politicians can refer to in regulations and everyone is happy. So how does this relate to 2023-04? We have a public registry that we built and maintain. But there are so many things we don't understand now in the 2020s. We all know what the registry was. My research has reminded you of some of the early details. But what is it now and what should it be tomorrow? We don't have answers to these questions. In the face of all these unknowns we want to add an inconsequential feature that could have a massive impact in other areas that we don't fully understand. We know LEAs have serious concerns. But we have just brushed them aside. This very small group of operators that took part in this discussion have prioritised their own convenience over anything else. They have turned that Maybe back into a No. If you approve this proposal with all these unknowns I think you will find that train full of regulators that is rumbling down the line, heading straight for you, will pick up speed. Think of the LEAs sitting in a room behind two doors. One of those doors opens up to the tech community. You are about to slam that door in their face. The other door opens up to the politicians. We still have the option to invite them into our room and talk seriously with them about their needs. Once you slam that door shut, they will walk through the other door and you lose control. Yes I know I am a drama queen. But I am trying to illustrate to you that actions have consequences. Today's consequences may be very different to those of yesterday in a similar situation. Nothing stays the same forever. So is it worth risking the wrath of the politicians for what has been described as a minor, optional feature change that some will find convenient? Let me end by suggesting an alternative path. I have said all this before and been ignored or insulted. But I will say it again anyway. I am used to being insulted on these lists with no one protecting me. 1/ Withdraw this proposal 2023-04 2/ Set up a new Task Force with these primary goals: a/ Determine the business requirements for the RIPE Database as a public registry, looking forwards. b/ Identify the major stakeholders for the RIPE Database public registry. c/ Identify the needs/wants of these stakeholders. d/ Based on the above, determine the registration needs of the public registry, taking account of privacy concerns. 3/ Once we know what we want, design a new data model for the RIPE Database. 4/ Slowly move from where we are now to where we want to be. Yes I know this is a long term project and yes it will cost money. But the RIPE Database is so old, with so many things lost in the mists of time, so many things not applicable to the modern world. If you continue turning your back on all this, you may find the regulators will tell you what they want in the registry. That may be far more costly. I don't think there is anything more I can say on this issue now. cheers denis ======================================================== DISCLAIMER Everything I said above is my personal, professional opinion. It is what I believe to be honest and true to the best of my knowledge. No one in this industry pays me anything. I have nothing to gain or lose by any decision. I push for what I believe is for the good of the Internet, in some small way. Nothing I say is ever intended to be offensive or a personal attack. Even if I strongly disagree with you or question your motives. Politicians question each other's motives all the time. RIPE discussion is often as much about politics and self interest as it is technical. I have a style of writing that some may not be familiar with, others sometimes use it against me. I also have OCD. It makes me see the world slightly differently to others. It drives my mind's obsessive need for detail. I can not change the way I express my detailed opinions. People may choose how to interpret them. ======================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripedenis at gmail.com Tue Feb 13 17:37:44 2024 From: ripedenis at gmail.com (denis walker) Date: Tue, 13 Feb 2024 17:37:44 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <60CDFA71-8EA6-4940-8130-DBBA28425303@a2b-internet.com> References: <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> <5c457b41-b9f4-4942-8e27-181e73726001@fud.no> <8a01f7df-390b-4928-bf7c-6584c80587dd@fud.no> <0358e4da-f314-4eaa-8c84-56bea25ff5f0@sebastian-graf.at> <4aefc5f8-1109-4cef-a6e0-7efd28fd6a00@sebastian-graf.at> <60CDFA71-8EA6-4940-8130-DBBA28425303@a2b-internet.com> Message-ID: Hi Erik On Tue, 13 Feb 2024 at 16:56, Erik Bais wrote: > > Dear Denis, > > > > Thank you for your long email. > > This policy in particular is quite clear and although it proposes on how to change/register assignments in the database, it doesn?t talk about a complete database redesign or overhaul. > > If you like to create a full TF or alike to have a discussion about the state of the DB, please do so in the correct WG for it. ( please read this as . . . not in AP-WG ) > You are right that such a discussion is better suited to the DB-WG. However I will make one last point here. The boundaries of WG topics are not black and white. There is often overlap between WGs. Throughout this discussion, the fact that the database is such a difficult tool to use and requires considerable manual effort on the part of LIRs to maintain the registration data within, has been used as justification for changing the registration requirements. When we clearly don't understand the reasoning behind the registration requirements we have today, I still argue it is wrong to change registration requirements just for the convenience of making a historic tool easier to use. The correct approach is to fix the tool. cheers denis > So, yes we?ve read your email and we will note your objection. > > Regards, > > Erik Bais > > on behalf of the Co-Chair collective of the AP-WG. > > > > From: address-policy-wg on behalf of denis walker > Date: Saturday, 10 February 2024 at 09:10 > To: "address-policy-wg at ripe.net" > Cc: Tore Anderson , Jan Ingvoldstad > Subject: Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) > > > > Colleagues > > I am back!! Thanks to those who agreed I should never have been away. I am not going to focus on that for now. I do have a lot to say around that issue. But that is for another day, on another mailing list. I won't discuss it here and I will wait until we conclude the discussion on this proposal. I want people to focus on the message rather than the messenger. > > There hasn't been much conversation while I have been away, but still several significant points that seemed to have been missed by most observers. I have answered all points raised by several people in this single email. In these days of uncertainty, who knows how long any of us will be around. So it is more of an article than an email. But I do end with a positive recommendation. > > Let's start with a comment by Leo: > "We encourage everyone to focus comments on the proposal and its potential impact. Do not comment on individuals, their characteristics, or motivations." > The co-chairs have no authority to determine what constitutes part of this discussion. If individuals use tactics that may confuse the community or repeatedly make comments that are not true, they make themselves part of the discussion. The co-chairs have no right to try to prevent these issues from being highlighted and discussed. People need to understand that personal criticism is not a personal attack, even if it is strong criticism. When an individual repeatedly says something that is not true, to highlight this issue and ask them why they keep saying this is not a personal attack. Criticism is part of life, especially in business. Throughout this discussion there has been lots of criticism thrown at me. My characteristics have been heavily criticised and commented on. Even who I speak for has been questioned. No one has questioned if an employee speaks on behalf of their employer. My motivations have also been questioned. It was suggested that I should not talk about the RIPE Database on the Address Policy WG. Even though the old design and technology of the database is one of the key elements used to support the need for aggregation. So much criticism aimed at me and yet the co-chairs saw no reason to intervene. They only intervene when I criticise someone. > > Then there is motivation. Is it questionable? A lot of the discussion on policy is political, commercial and self interest based. In these contexts I believe it is acceptable to question motivation. The co-chairs never asked what I meant by what I said. Of course the proposal is about aggregation. It's in the title and the text. But it is about a lot more than that. There are two main aspects to this proposal. An inconsequential, minor feature change that people may or may not use. And a major change to the handling of End User details, which people also may or may not take advantage of. The two aspects combined can make a massive change to the available information in the RIPE Database. But the proposal did not even mention the change to End User details. Is it important? Well after I pointed it out, some people who had said "+1 I agree with this proposal" changed their mind and withdrew their support. So for them it was highly relevant. There are sections in the proposal template for supporting and opposing issues relating to the proposal. Depending on your point of view this major change should have been listed in one of those sections. But it wasn't. So did the proposers fully understand the implications of this change or not? I must be allowed to ask that question as part of this discussion. If they did understand it, why did they not mention it? Did they overlook it, or was there some other reason? Again I have to be able to ask these questions. This is all about motivation. To ask these questions and understand what happened is not a personal attack. It is a reasonable line of inquiry. > > Enough about the messenger, let's get back to the message. > > ------------------------ > > On Mon, 18 Dec 2023 at 16:49, Edwin Verheul via address-policy-wg wrote: > > > > I support this proposal. > > > > Since this policy introduces convenience for LIR by aligning ipv4 object policy to the ipv6 policy, unclear usage of the admin contact should not prevent this improvement in policy. > > This pretty much sums up a lot of people's view of this proposal. It is 'convenient' for the operators. Who cares if it is the right thing to do or not, it is convenient. It doesn't align v4 and v6, there are significant differences in the defined aggregations. Never mind if we don't understand what the data means, let's just change it anyway as it is convenient. > > Maybe a few of you should watch John Curran's keynote speech at NANOG on internet governance: > https://www.youtube.com/watch?v=U1Ip39Qv-Zk > > He talks about phases of the internet and how we are now moving from the 'commercial' internet to the 'public' internet. With this public internet, civil society has/wants a much bigger say in how things work. Organisations that represent civil society and civil order are more concerned about how things work. Politicians are concerned about what their voters think. Do you think civil society cares about operator convenience? They are more likely to think 'it's your job, do it. That's what we pay you for'. I think civil society will be more interested in knowing who is spamming them or attacking their network and can the police catch them, rather than operator convenience. > > Now let's think a bit more about what this data means and how to interpret it. > > ------------------------ > > On Fri, 12 Jan 2024 at 08:56, Alex Le Heux wrote: > > > > During the discussion about AGGREGATED-BY-LIR status for IPv4 PA assignments the argument has been raised that this proposal would substantially change the registration requirements for end-user assignments in the RIPE DB and the discussion has been going around in circles ever since. > > > > We would like to point out the following: > > > > From the RIPE NCC Impact Analysis: > > > > Acceptance of this proposal will not change the fact that the RIPE NCC cannot enforce which contact details members add to their IPv4 PA assignments in the RIPE Database; this will remain their decision. > > > > This is completely out of context. I have asked the RIPE NCC legal team to clarify what this means but I guess by their silence they declined. To me this sentence says the member can choose to enter the details of Contact A or Contact B and choose what the details are. Which one (A or B) and the details (email or phone) they enter will be their decision. The RIPE NCC cannot enforce if they enter A or B or email or phone. WHO these contacts represent is a matter of policy. The current policy says they MUST be representatives of the End User. That can be enforced by the RIPE NCC, but they choose not to enforce it. > > > > > As well as: > > > > It is fact that the RIPE NCC has interpreted the current policy to not require a PA Assignment in the RIPE DB to include the actual name and email address of the end-user since at leas the late 1990s. Registering a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR has been acceptable for all this time. > > > > This is completely false. I know Alex well and will give him the benefit of the doubt that he has not picked up on the detail here. He signed this email 'for the Address Policy WG co-chairs'. A lot was said about who I speak for, so I assume Alex was speaking 'for' all the chairs. I was told that signing as 'co-chair DB-WG' gives what I say more weight and has more influence on the community. The same must apply when the co-chairs of this WG collectively sign an email. The community will assume that statement carries more validity. > > Let's look at the detail. Address policy from the early 1990s has made it clear that assignments must include contact details of the End User. But ripe-288, 28 Oct 2003 is particularly interesting. The authors of this version of the address policy were: > Mirjam K?hne, Paul Rendek, Sabrina Wilmot, Leo Vegoda > At that time they were all current or former NCC staff. Leo was the operations manager of the RIPE NCC Registration Services (RS). Paul was the senior manager responsible for RS. In this version, these authors added the exact wording that we have today: > "When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End User's." > The wording was very different before this. The document was restructured and the wording changed. So they must have thought about what this meant. I cannot believe that when these words were added to the policy by the RS manager and RS senior manager they were not enforced by RS. Maybe Leo can give some background to this. > > Nothing in this industry changes quickly. So if these newly worded requirements were enforced just 20 years ago, they must have been enforced for at least 5 to 10 years. That means the RIPE NCC's interpretation of this wording, written by the RS manager, has only changed in the last 5 to 10 years. I have been told by some former members of RS that they stopped enforcing these requirements at runout of IPv4. They told me that when they had no more address space to allocate, they had no power to enforce these rules. So they simply stopped enforcing them. This paints a very different picture. We are not changing policy to match a common practice. We are dropping policy because it is difficult to enforce, regardless of the reasons why the policy was introduced. > > It is also interesting that, no matter how many times you read something, you don't always see what it says. A lot has been said about replacing the admin-c and tech-c contacts in an assignment with the contacts of the LIR. It has been said that the RIPE NCC now considers this acceptable. But look at what the current policy actually says: > "Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End User's." > So this substitution is only allowed by policy where the End User is an individual. You cannot do it for all End Users. This actually makes sense to me. If I want to contact the LIR's tech or admin contacts, they are already available in the RIPE Database in the allocation object. Why duplicate the data in the assignment. The policy says the assignment must have the End User's contacts. So that is another misinterpretation of the current policy. > > > > > > > In its impact analysis the RIPE NCC has indicated that this proposal does not change this interpretation. > > > > It should therefore be clear that 2023-04 does not in fact change anything regarding how end-user details will actually be registered in PA Assignments. > > Interesting choice of words. It may not change how some End User details 'will' actually be registered, but it changes how they 'should' be registered enormously. > > > > > However, is has been argued that this interpretation is wrong and that PA Assignments in the RIPE DB must include the actual end-user details. And even though this is out of scope for the 2023-04 discussion, it is still something that is worth resolving. As changing this interpretation would be a major departure of many years of accepted practice and potentially involve updating thousands of RIPE DB objects, we feel this discussion would be best served by an independent policy proposal that clarifies the issue and would like to invite the working group to enter one. > > > > I agree this needs further clarification. But you can't write a policy proposal on something you don't understand. We don't know what much of the data means now or in the past, or why we have these rules, or what we need now. Until we have the business requirements for the RIPE Database as a public registry any such policy proposal, including this one, is just a dangerous stab in the dark. > > > Kind regards, > > > > Alex Le Heux, for the Address Policy WG co-chairs > > It is interesting that this email was signed 'for' all the co-chairs of this WG. How can the co-chairs approve this policy proposal (2023-04) while accepting that another proposal is needed to clarify if the RIPE Database must include the actual End User contact details? Are they going to approve a policy proposal that potentially removes this End User detail requirement and then consider a policy proposal that would require them to put this detail back into the RIPE Database? > > > ------------------------ > > On Thu, 11 Jan 2024 at 09:40, Tore Anderson wrote: > > > > Hello Denis, > > > > On 11/01/24 01:40, denis walker wrote: > > > So personal data does not always need consent of the data > > > subject. But you only ever refer to (a) consent. > > > > There are indeed other possible lawful bases than consent, and this fact > > is precisely why I wrote (emphasis added): > > > > ?Publishing this information requires *a* lawful basis, *e.g.*, consent.? > > > > Consent is however the only lawful basis singled out by the RIPE NCC in > > the RIPE Database Terms and Conditions and in the 2023-04 Impact > > Analysis, so it seems reasonable to assume that some LIRs will seek consent. > > I wrote the T&C before GDPR was in place. That's why it doesn't refer to any of the other lawful options. I questioned the IA but the legal team chose not to respond. > > > > > Therefore we need to examine what that actually means in practice. You > > sum it up quite accurately below: > > > > > > > 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. > > > > Your conclusion that this situation results in a policy violation, is > > however entirely contingent on your interpretation of the current policy > > as mandating the publication of the End User's (non-delegated) contact > > information. > > You did not read what I wrote. I was talking about LIR contacts in allocation objects. If that is PII (and a lot of it is) the subjects can now ask for it to be removed. That may leave allocation objects with no LIR contacts. That is syntactically not possible in the RIPE Database. > > > > > Under the RIPE NCC's interpretation of the current policy, on the other > > hand, this situation is entirely unproblematic. Under their > > interpretation, the LIR has, quote, ?freedom to take over the > > responsibility as the point of contact for their End User?. No PII, no > > GDPR, no problem. > > But if the LIR has NO contacts because they have asked for their details to be removed then you can't replace the End User contacts with non-existent LIR contacts. You and the legal team have started a chain reaction here by declaring that ALL contacts in the RIPE Database are there by consent. The RIPE NCC, as joint data controller for the RIPE Database, now has joint responsibility, and I presume therefore joint liability, for 2 million people having given their consent to their details being added into a PERSON object in the database. > > > > > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013892.html > > > > > 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. > > > > KPN or Apple would not be relevant examples, as they (presumably) would > > use non-personal NOC roles which are not PII, and thus out of scope of > > the GDPR. > > The RIPE NCC is a corporate body and yet it has many PERSON objects in the database relating to individual staff members as contacts for their resources. > > > ------------------------ > > On Thu, 11 Jan 2024 at 09:45, Tore Anderson wrote: > > > > Hi Denis, > > > > On 11/01/24 03:20, denis walker wrote: > > > On Wed, 10 Jan 2024 at 13:02, Tore Anderson wrote: > > >> > > >> On 10/01/24 11:25, Jan Ingvoldstad wrote: > > >>> 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. > > >> Exactly. LIRs may (but are not required to) chose this approach already > > >> *today*. This is a common and long-standing practice which the RIPE NCC > > >> has repeatedly clarified as compliant with today's policy. > > > This is one of your biggest false statements. The ONLY person > > > repeatedly saying this is YOU. Let's do a fact check here. > > > > Yes, let us indeed do a fact check: > > > > Your fact checking is not very accurate. > > > Exhibit 1: > > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013856.html > > > > This is the one time the RIPE NCC made this argument, which I have disputed. > > > Exhibit 2: https://www.ripe.net/participate/policies/proposals/2023-04 > > (specifically the ?counter-argument?, which the RIPE NCC Policy Officer > > confirmed to the proposers and the WG chairs as correctly representing > > the RIPE NCC's interpretation) > > > > This 'counter argument' is your argument and is completely false. > > > Exhibit 3: > > https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis > > > > I have explained this above. This is the argument about LIRs adding Contact A or Contact B or email or phone. THAT is their decision. Who these contacts represent is set in the current policy and is not the LIR's choice. > > > Exhibit 4: > > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013892.html > > > > All the talk about maintainers, descr attributes, DB T&C and documentation has nothing to do with address policy. All they say here is that this proposal won't influence how the RIPE NCC currently carries out ARCs. They are doing it wrong now and will continue to do it wrong. > > > Four repetitions so far, all saying the same thing. How many more do you > > need? > > > > One statement and no repetitions. They all say something different, which most people can clearly see. > > > > > >> As the RIPE NCC writes in the Impact Analysis (emphasis added): > > >> > > >> ?Acceptance of this proposal **will not change** the fact that the > > >> RIPE NCC cannot enforce which contact details members add to their IPv4 > > >> PA assignments in the RIPE Database; this **will remain** their decision.? > > >> > > Same repetitive argument again and again. Yes it IS the LIR's decision to enter Contact A or Contact B or email or phone. It is the POLICY that determines who those contacts represent. How many more times are we going to have this same discussion? (Which the legal team will not clarify.) > > > >> So, once again: which End User contact details LIRs publish (if any) is > > >> their decision today, and it will be continue to be their decision if > > >> 2023-04 passes. > > > YES AGAIN the LIR can always choose between Contact A and Contact B, email or phone. They cannot choose to not enter any End User contact details. > > > > >> Hence, 2023-04 does not effect any change in this regard. > > But as everyone else can see, this makes a huge change. > > > > This really does make me cry. The wording in the IA is poor. You have > > > applied an interpretation to this which I do not believe is what was > > > meant. Then the RIPE NCC legal team has remained silent. So I am > > > asking the RIPE NCC legal team to clearly explain what they meant by > > > this wording. > > > > The explanation you request was posted two days after the Impact > > Analysis was: > > > > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013892.html > > > > ?LIRs are free to choose how to provide services and to who, this > > includes their freedom to take over the responsibility as the point of > > contact for their End User as well as having their maintainer in the > > IPv4 PA assignments they register.? > > > > This explanation aligns perfectly with our interpretation of the > > statement in the Impact Analysis. > > > > Wrong again. Yes the LIR is free to take over responsibility for technical matters. You can always find their contact details in the allocation object. So the public, civil society, LEAs, and other LIRs can choose who they want to contact...the LIR or the End User. Between the allocation and assignment objects you have all the contact details you need...according to current policy. > > The LIR does NOT have the freedom, according to current policy, to replace the admin-c and tech-c contacts in the assignment object with their own contact details in all situations. Again the current policy wording is clear and not interpretable: > "Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End User's." > So you can ONLY replace the assignment contacts with those of the LIR IF the End User is an individual. Again this is simple, plain English, originally written by Leo and Mirjam. > > > >> Given that, it is hard to see how we could possibly amend the proposal > > >> to change this particular point to an even lesser extent than what is > > >> already the case? > > > Let me help you. Do NOT remove a sentence that has nothing to do with > > > the stated goal of the proposal to aggregate assignments and that you > > > claim does not change anything. > > > > This sentence also has a lot to do with the stated goal of aggregating > > assignments, because it mandates that assignments must be ?registered > > separately?. That is clearly incompatible with aggregation. > > > > **** Finally, FINALLY you have admitted that this change that is not a change and that changes nothing does actually change something. **** > It changes the registration requirements for assignments, which I have been saying all along and which you have been denying for months. > > ------------------------ > > On Thu, 11 Jan 2024 at 10:19, Jan Ingvoldstad wrote: > > > > > > On Thu, Jan 11, 2024 at 9:45AM Tore Anderson wrote: > > >> If our ulterior goal was to remove the End User contacts from our own > >> assignments we can just go ahead and do so, right now. The RIPE NCC is > >> already on the record saying that's totally OK, and we would be > >> following in the footsteps of many other LIRs who have already done so. > > > While you seem to argue that the RIPE NCC is both omniscient and omnicompetent, I do not think it is that easy. > > > > I simply think that the RIPE NCC and you are mistaken. > > > > After talking to former members of RS I am beginning to think that the RIPE NCC is not mistaken. They know exactly what the current policy says and they know what it means. After all, it was written by former RS managers. BUT they don't believe they have any power to enforce it. This is why they quietly ignore what the policy says. I'll say more about that in my conclusion at the end of this email. > > > Continously appealing to RIPE NCC as the authority of policy and policy interpretation is not a good thing. > > > > It undermines the community drive behind policies. > > > > If this is where we are going, it seems that we would be just as well off by letting EU politicians run the show. > > > > If you have watched John Curran's keynote speech at NANOG and think about the way a handful of operators are pushing this proposal through, the EU politicians WILL be running the show in the near future. > https://www.youtube.com/watch?v=U1Ip39Qv-Zk > > > > -- > > Jan > > ------------------------ > > On Thu, 11 Jan 2024 at 13:11, Tore Anderson wrote: > > > > On 11/01/24 10:19, Jan Ingvoldstad wrote: > > > > > > Continously appealing to RIPE NCC as the authority of policy and > > > policy interpretation is not a good thing. > > > > The RIPE NCC is the secretariat of the RIPE Community and is delegated > > the task of implementing and enforcing the RIPE Community policies, as > > well as to providing training to the LIRs on how to operationalise said > > policies. If that is not an authority worth paying attention to, I do > > not know what is. > > > > Exactly, the RIPE NCC is the secretariat, not the policy decision maker. They are supposed to enforce community derived policy. IF they don't think they have the powers to enforce a policy they should raise that issue with the community and seek guidance. They should not just quietly ignore the policy, or part of it. > > > After all, any LIR which prefers the RIPE NCC interpretation of the > > policy in this regard is may simply adhere to it and act accordingly, > > and this is commonly done today. Thus the RIPE NCC's interpretation of > > the policy ? mistaken or not ? ends up becoming the (de facto) way the > > policy is implemented anyway. > > > > If a policy has unintentional interpretations it is badly written. LIRs should not be in a position to choose between a community view and the RIPE NCC's view of a policy. A RIPE NCC interpretation of a policy that conflicts with a community view should not become a de facto implementation. If such a situation arises the conflict must be resolved. > > ------------------------ > > On Thu, 11 Jan 2024 at 14:11, Tore Anderson wrote: > > > > Hi Jan, > > > > On 11/01/24 13:27, Jan Ingvoldstad wrote: > > > On Thu, Jan 11, 2024 at 1:11PM Tore Anderson wrote: > > > > > > After all, any LIR which prefers the RIPE NCC interpretation of the > > > policy in this regard is may simply adhere to it and act accordingly, > > > and this is commonly done today. Thus the RIPE NCC's > > > interpretation of > > > the policy ? mistaken or not ? ends up becoming the (de facto) way > > > the > > > policy is implemented anyway. > > > > > > This statement basically renders the point of a policy working group moot. > > > > I totally agree. > > > Not at all. Any working group member who is of the opinion that the RIPE > > NCC is interpreting a RIPE Community policy incorrectly, is free to at > > any point submit a policy proposal that clarifies the allegedly > > misinterpreted policy text with the aim to make the RIPE NCC change its > > procedures accordingly. > > > > A policy proposal would only be needed if the policy is so badly written it needs clarity. When the policy is clear and simple, but the RIPE NCC is either misinterpreting it or doesn't believe it has the power to enforce it, we don't need a policy change. We need an interpretation change. > > > The RIPE NCC's Impact Analysis will then reveal whether or not the > > proposed new policy text does attain its goal and that the RIPE NCC will > > change its procedures as desired, should the proposal pass. > > > > Finally, the proposal will need to reach (rough) consensus in order to > > confirm that the RIPE Community does indeed concur with the proposer's > > opinion that the old policy was interpreted incorrectly, and that the > > RIPE NCC's procedures ought to change. > > > > You do not write policy proposals to change the RIPE NCC's interpretation of existing policy. > > > Absent this, the RIPE NCC's operationalisation of the policy will stay > > as-is. > > > > ------------------------ > > On Thu, 11 Jan 2024 at 14:35, Sebastian Graf wrote: > > > > Dear Tore/Denis: > > > > If we are looking at the Policy Language, then i'm not certain we are reading the same things into it. > > Or maybe i missed something. Feel free to point out the corresponding section of the policy to me. I'm more than happy to update my views if strong evidence is presented. > > As a small LIR ... I may not see all edge cases.... but...... So feel free to point out anything important that i may have missed. > > > > Lets look at the actual language in the policy: > > > > > "All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations." > > > > The way i read it, this point is filled both with the current state of things, and also if we have an aggregated status. Space would still be registered. So the question is what kind of data needs to accompany it. > > > > Actually this point is not satisfied by aggregation. When you have all assignments separately registered, as current policy requires and the proposers of this policy update have finally agreed is the case, you can see that each assignment is unique. You cannot assign the same space to two End Users as you cannot create two assignment objects with the same or overlapping prefix. With an aggregation object, all you know is that some part(s) of this aggregated block may be assigned to one or more End Users. You do not know how much is in use, or even if any of the aggregated space is currently in use. It does not satisfy the uniqueness condition as you can't be sure some of the space has not been multiply assigned. > > > So lets look at what needs to be documented: > > > > > "Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained)." > > > > I think you are arguing what both of you are considering "contact information". It does NOT say we state to put personally identifyable information into it. > > > > You are totally correct here. I have never argued for putting PII into the database. > > > If we read the text literally, then only putting enough information to establish a contact (ie: contact information) would theoretically be sufficient. > > So theoretically, a "proxy" type of setup for email/postal mail/... could be permissiable as long as any communication/... is forwarded to the the actual responisble party. > > > > In fact i would argue for most businesses (End-User or ISP) this is already the case if they make use of "role" contacts for their admin/noc/abuse/... handling. > > > > Also correct. > > > > "Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained)." > > > > The other thing that i do not read from the statement is where it asks to put "contact information" for the End-User. It simply reads contact information (one could theoretically interpret this as "contact information for the party that is responsible for managing the space....). > > > > You are missing the infamous lines this proposal wants to delete from the current policy: > "When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End User's." > > > ANYWAY.... > > > > I still do not feel anything of significance would be lost, if something could be lost at all. > > I guess you don't accept that the registration details of End Users is significant. > > >My personal opinion goes the other way.....I suspect, if anything aggregated status could potentially lead to more accurate data. Let me explain: With the aggregation we gain better understanding of the network usage. PLUS the ability to create more specific assignments (under the aggregated). So This way, i feel more usable data would be int the database, compared to now. > > > > With an aggregated block all/some/none of the space covered by this block may be in use by one/many/no End Users. You have no idea about network usage. All that detail may be lost. > > > This would also be in line with the goals in Section 3.0 - Point 2 "Agregation: Distributing IPv4 addresses in an hierarchical manner permits the aggregation of routing information.". > > > > Aggregating address space registration details has nothing at all to do with routing aggregation. > > > If we look at the goal for registration: "Registration: The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels.". > > > > Aggregating assignment data does not guarantee uniqueness, or provide information for Internet troubleshooting at ALL levels. > > > If we consider the usefulnes of data entered into the ripe-db for this purpose, then most useful will be the ISP contact information. Contact information for End-Users (could be an ISP as well) would also be useful in some cases. Personal Information for "individual" type end users (ie: Fred Testuser's DSL Line that comes with a Public IPv4 Address)....to a lesser extend. > > > > If we look at Section 3.1 ...it reads "Internet Registries (IRs) have a duty of confidentiality to their registrants. Information passed to an IR must be securely stored and must not be distributed wider than necessary within the IR.". > > > > So i am not certain why you are trying to force more data than actually required/useful into the db. And yes in this context i would consider LIR's in this to be part of this as some type of "local" IR's. > > > > There is always a balance between privacy and the needs of civil society. It was decided many years ago that anyone operating a network using public address space should have contact details available in a public registry. That is still what the current policy says with wording written by Leo (AP WG co-chair, former RS manager) and Mirjam (RIPE chair). The original source of this requirement goes back to address policy written in the 1990s by many varied authors including Daniel (RIPE NCC founder) and Hans Petter (RIPE NCC CEO and former AP WG and LIR WG chair). Unfortunately no one is willing to provide any background information to the current RIPE community about why these rules were originally imposed. That makes it difficult to discuss if those original conditions still apply to the current stakeholders of the RIPE Database, who we also can't easily identify. > > > During the writing of this email, i realised that you (denis/tore) may consider the need/usecase for adding a "restricted" flag into the DB, that would allow adding information, that is only shown to a select audience (ie: law enforcment, ripe staff and Ripe-Members) - wich could be used to publish PII data. HOWEVER doing something like that would "extend" the existing usecase(s) of the DB and dataentry required - as such this should be in a different Policy Proposal/wg-discussion. Feel free to put one forward, that we can discuss.... > > > > I did consider this option when I put forward my RIPE Database Privacy policy proposal some time ago. The idea of multi level access was not very popular. > > ------------------------ > > On Fri, 12 Jan 2024 at 08:12, Tore Anderson wrote: > > > > Good morning Jan, > > > > On 12/01/24 07:25, Jan Ingvoldstad wrote: > > > I also do not understand what makes it so hard to say that: "Yes, the > > > current policy does state something else than NCC's interpretation of > > > it does, (?) > > > > We do not make statements that we do not believe to be true. > > > > In our opinion, the RIPE NCC implements current policy correctly. > > > > How can you keep saying this when everyone knows it is not true. Regardless of whether or not you support the way the RIPE NCC currently implements the policy, it is NOT what the policy says. We have been over this so many times. The policy is so clear in simple, plain English. For whatever reason, the way the RIPE NCC implements the policy today is NOT what the current policy so clearly says, as written by a co-chair of this WG. > > You even admitted it yourself in an earlier email (listed above) where you said (and these are YOUR words): > > > After all, any LIR which prefers the RIPE NCC interpretation of the > > policy in this regard is may simply adhere to it and act accordingly, > > and this is commonly done today. Thus the RIPE NCC's interpretation of > > the policy ? mistaken or not ? ends up becoming the (de facto) way the > > policy is implemented anyway. > > ------------------------ > > On Fri, 12 Jan 2024 at 08:57, Sebastian Graf wrote: > > > > Dear Jan! > > > > As mentioned in my previous e-mail: Would you please post the section of > > the policy that you belive has the NCC's interpretation differ from the > > actual wording/language used? > > > > Because i have yet to find a section that states explicitly what is > > considered valid vs invalid contact information (other than being out of > > date or information that does not provide a contact to the user in a > > timely manner). Or a section that restricts what kind of data is > > permissable for "contact information". > > > > It is not a question of what is (in)valid contact information. It is about who the contact details refer to. End User or LIR. > > ------------------------ > > On Fri, 12 Jan 2024 at 09:28, Sebastian Graf wrote: > > > > Dear Jan! > > > > Thank you for your reply. But you have not answerred my question. > > > > We are all clear/well aware on the fact that the policy states (paraphrasing here: resources need to be registered and the registions need to have contact information). > > > > We are looking for the DEFINITION of "contact details of the End User.". This is not directly defined (as far as i can tell) and is therefore open for interpretation. > > > > Unless i missed something? > > > > Yes you have missed something. Take your sentence above "contact details of the End User". This can be split into two parts: > "contact details" > "of the End User." > You are right, there is no definition of "contact details". So it doesn't matter if this is email, phone, fax, postal address or if it is in a role or person object or if it is corporate or personal data. Much of this does matter when it comes to privacy concerns, but that is another discussion. What we are primarily discussing here is the other part "of the End User." So the contact details don't matter for this discussion as long as they collectively refer to the End User. And this reference is not open to any interpretation according to the current policy. > > ------------------------ > > On Fri, 12 Jan 2024 at 10:35, Sebastian Graf wrote: > > > > Dear Jan! > > > > You and Denis are arguing that registration/user data needs to include certain (sometimes sensitive details (ie: PII)) that need to be put in the database. Your Argument is that this is a policy requirement. > > > > That is NOT what we are arguing. There is no policy requirement regarding the nature of the contact details. The policy states who the contact details should refer to, ie End User or LIR, for example. > > > When I tried to get both of you to spell out what this "user data"/"contact information" is exactly and where that is defined - We do not get a clear answer. > > > > Because it is not what we are arguing and it is not defined anywhere. > > > I have read every single of denis replies/comments. > > > > When asked, neither of you cannot reference a policy section that actually spells out what is considered "contact details". > > > > Because the policy doesn't define this and it is not relevant to this discussion. > > > According to your own e-mail - your opinion is based on a software interface/implementation (ripe-db). This interface itself is an interpretation of what the policy could mean. > > The Interface of the DB also does not specify what kind of Information (regular address, proxy address,...) needs to be inserted. Just that some fields need to be filled out (and its open to interpret what goes into them to a certain extent - wich is the point of this discussion). > > > > Sorry but you have missed the point again. The discussion has nothing to do with RIPE Database interfaces, forms or attribute contents. It is about WHO these details refer to. > > > The relationship is policy -to- database. Not Database -to- Policy. > > > > And yet, we have no document or reference that defines what kind of contact information (direct only, or indirect via proxy/masking/....) is permissable. > > Correct, and it is not relevant. > > > Just that it needs to be maintained (meaning "if it works" -> OK). > > All data in the RIPE Database should be maintained and kept up to date. > > > In my previous e-mail i did argue that in some scenarios working witout"proxy" data is impossible (think: Role/NOC Contacts). > > > > ROLE or PERSON object is also irrelevant to this discussion. > > > I have also read your reference https://www.ripe.net/publications/docs/ripe-705 . It defines an abuse inbox is mandatory for certain objects. And that it has to be an email address. - Nothing else. > > Also irrelevant to this discussion. > > ------------------------ > > So where does all this leave us? During this discussion we have established that: > > -We do not understand what many elements of data in the RIPE Database mean. > > -There are some historical definitions in old documents. These definitions have never been updated, so technically they are the only current definition available. But some of these definitions do not map exactly into the modern world. > > -Some registration requirements were written in the early 1990s. Some were re-written in 2003. Much of this was written by people who still have a high profile in the RIPE community or RIPE NCC today. > > -We do not know what the reasoning was for why these requirements were introduced. > > -We do not know who the major stakeholders are who use the data in the RIPE Database or what information they want and need or what they use it for. > > -We have no business requirements for the RIPE Database as a public registry. > > -We do not know what data needs to be registered in the RIPE Database or what information it needs to serve to who for what purpose. > > -An unknown amount of assignment data in the RIPE Database does not comply with current address policy. > > -The RIPE NCC does not enforce the current address policy. This may be because the RIPE NCC does not believe they have the power to enforce current policy. > > -Some members have made it clear they will not enter any of their customer's details into a public registry no matter what policy says for commercial sensitivity reasons. While there are interpretations of current policy they may be considered in violation of policy. So there are other reasons why some people may want to push through this change in End User registration. > > -We do not know what the potential consequences may be for some stakeholders by making this change. > > So given all these unknowns, should we go ahead and make this change? It seems like this has been a long and intense discussion. Some people may think we have had sufficient input from the community to be able to make a decision on consensus. But as is often the case, statistics beat perception. So let's look at some numbers. Excluding the chairs, proposers and RIPE NCC staff there have been 22 people who commented on this discussion over the last 6 months. Of these 6 people only made 1 comment and another 6 made 2 comments. Then 8 people made 3 to 6 comments. One person made 12 and one made 24 comments. Also 5 people made up the '+1' brigade. These numbers cover both supporters and objectors. This is quite typical of policy discussion. Many of the 'regular' vocal community members who are involved in almost all policy discussions are included in these numbers. So we are looking at a very small number of people who actually support this proposal. Given all the unknowns we have identified during this discussion and the very small number of supporters, should we still approve this proposal? Bear in mind also that the proposal is basically about adding an inconsequential, minor, optional feature change for the convenience of some operators. It also makes a huge change to the registration requirements of End User assignments which will have an unknown impact on the public registry and some major stakeholders. > > Now let's add in some other factors. I really do recommend that you all watch John Curran's keynote speech to NANOG about internet governance. > https://www.youtube.com/watch?v=U1Ip39Qv-Zk > > He makes some very interesting points that are highly relevant to this discussion. He talks about 3 phases of the internet. The first one was the early development, done largely by universities and other early adopters of the technology, but largely paid for by governments. Then we went into the commercial phase that covers much of the last 20 years or so. But now we are moving into a public phase where civil society is more knowledgeable and is much more heavily involved. During the commercial phase the tech community could pretty much do what they wanted. If questioned by any parts of civil society or regulators they could just fob them off with No No No No... In the new public phase politicians, regulators, organisations involved in public order are much more aware of the interest by civil society (people who vote in elections). The public is aware of the dangers of the internet as well as the benefits. Politicians and regulators must be seen to be in control. So the days of the tech community saying No No No No to them are over. Now it must be at least No No No Maybe. The Maybe allows the tech community to write something down that they can live with, that politicians can refer to in regulations and everyone is happy. > > So how does this relate to 2023-04? We have a public registry that we built and maintain. But there are so many things we don't understand now in the 2020s. We all know what the registry was. My research has reminded you of some of the early details. But what is it now and what should it be tomorrow? We don't have answers to these questions. In the face of all these unknowns we want to add an inconsequential feature that could have a massive impact in other areas that we don't fully understand. We know LEAs have serious concerns. But we have just brushed them aside. This very small group of operators that took part in this discussion have prioritised their own convenience over anything else. They have turned that Maybe back into a No. If you approve this proposal with all these unknowns I think you will find that train full of regulators that is rumbling down the line, heading straight for you, will pick up speed. Think of the LEAs sitting in a room behind two doors. One of those doors opens up to the tech community. You are about to slam that door in their face. The other door opens up to the politicians. We still have the option to invite them into our room and talk seriously with them about their needs. Once you slam that door shut, they will walk through the other door and you lose control. > > Yes I know I am a drama queen. But I am trying to illustrate to you that actions have consequences. Today's consequences may be very different to those of yesterday in a similar situation. Nothing stays the same forever. So is it worth risking the wrath of the politicians for what has been described as a minor, optional feature change that some will find convenient? > > Let me end by suggesting an alternative path. I have said all this before and been ignored or insulted. But I will say it again anyway. I am used to being insulted on these lists with no one protecting me. > > 1/ Withdraw this proposal 2023-04 > > 2/ Set up a new Task Force with these primary goals: > > a/ Determine the business requirements for the RIPE Database as a public registry, looking forwards. > > b/ Identify the major stakeholders for the RIPE Database public registry. > > c/ Identify the needs/wants of these stakeholders. > > d/ Based on the above, determine the registration needs of the public registry, taking account of privacy concerns. > > 3/ Once we know what we want, design a new data model for the RIPE Database. > > 4/ Slowly move from where we are now to where we want to be. > > Yes I know this is a long term project and yes it will cost money. But the RIPE Database is so old, with so many things lost in the mists of time, so many things not applicable to the modern world. If you continue turning your back on all this, you may find the regulators will tell you what they want in the registry. That may be far more costly. > > I don't think there is anything more I can say on this issue now. > > cheers > denis > > ======================================================== > DISCLAIMER > Everything I said above is my personal, professional opinion. It is what I believe to be honest and true to the best of my knowledge. No one in this industry pays me anything. I have nothing to gain or lose by any decision. I push for what I believe is for the good of the Internet, in some small way. Nothing I say is ever intended to be offensive or a personal attack. Even if I strongly disagree with you or question your motives. Politicians question each other's motives all the time. RIPE discussion is often as much about politics and self interest as it is technical. I have a style of writing that some may not be familiar with, others sometimes use it against me. I also have OCD. It makes me see the world slightly differently to others. It drives my mind's obsessive need for detail. I can not change the way I express my detailed opinions. People may choose how to interpret them. > ========================================================