Re: [address-policy-wg] 2023-04 The bigger picture
by Carlos Friaças
Greetings Denis, All,
Yes, it was a very long message :-)
Well, maybe not, if we keep in mind the time you have worked and thought
about and around the RIPE database.
I obviously don't agree with everything you wrote, while i can agree with
most of it.
2023-04 seems a bad idea to me, but at least it doesn't prevent anyone to
keep on the registration of their assignments if they wish to do so. This
proposal sounds like a "less effort for everyone" proposal, and for me,
even if it's unintended, a way to increase opacity.
Is it enough for a public registry to have just the association between
address space and its direct members? -- i don't believe so.
Some LIRs are not registering their assignments (violating current policy,
right?), so we change/update the policy to make their lack of action as
part of the policy? It sounds very wrong to increase compliance levels
artificially by changing the rules.
I see "arguments opposing the proposal" = none. I would like to disagree.
The quality of publicly available registration data is likely to decrease
if this proposal goes through.
Regards,
Carlos
On Mon, 25 Sep 2023, denis walker wrote:
> Colleagues
>
> I want to look at the bigger picture here. I apologise again for
> another long email. There are many issues here that this community has
> ignored for too long. So I hope some of you will at least read through
> to the end, think about what I say and comment...maybe even support
> the general idea...
>
> Although this has been a discussion with only a handful of people it
> has raised some interesting points. Many followers may have missed the
> significance of some of these points or perhaps not thought deeply
> about them. These include (in no particular order):
> -Different registration requirements for IPv4 and IPv6
> -Differences in the way IPv4 and IPv6 have been allocated and assigned over time
> -Block size (fixed or random)
> -Retro fitting of features
> -Different levels of adherence to policy by resource holders
> -Voluntary nature of supplying some details
> -No consistent approach to supplied data
> -Confusion for some resource holders about what data to publish
> -Effort required to maintain data in the RIPE Database
> -Volatility of some fast changing data
> -Privacy
> -Customer confidentiality
> -Public interest
> -Public registry
> -Registering public networks
> -Addresses defined as free text (sometimes including name)
>
> This is a lot of issues wrapped around one policy proposal. This
> proposal will not address all, or even most, of these issues. I don't
> believe this is the right way forward. But what is the root problem
> here and how can we address it?
>
> There are also some other points to consider. At recent RIPE Meetings
> some prominent members of this community have told me in the strongest
> possible terms that there is no way in hell that they are going to
> list any of their customer's details in the public RIPE Database. No
> matter what any policy says. Commercial confidentiality seems to be a
> very sensitive issue for some resource holders. Of course this is a
> valid concern. But it needs to be balanced. Policy needs consensus,
> but when we have a consensus all resource holders must follow it. That
> is the only way a self regulating industry can work.
>
> Another reason of concern is the alignment of handling both IPv4 and
> IPv6 registrations in the RIPE Database. Where we have two systems
> that are managed in different ways, there are of course two ways they
> can be aligned. We can dumb down the IPv4 data to the level of IPv6.
> Or we can raise the IPv6 data to the level of IPv4. Everyone is
> focused on the dumbing down option. No one has even considered moving
> in the other direction. I have never understood why the IPv6
> registration policy was not written with the same requirements in mind
> as the IPv4 in the first instance. Maybe at the time the automation
> options available then were not as extensive as they are today.
> Computer power and bandwidth were certainly not comparable to what
> they are today. Changes to the RIPE Database data model, interfaces,
> technology and design would make it possible to raise the level of
> IPv6 information available in the public registry to the same level as
> IPv4.
>
> At the heart of this issue is a public registry. But what is that in
> 2023? What does it mean? What should be in it? Who is it for? How do
> we achieve a three way balance between commercial sensitivity, public
> need and privacy? These are the sort of questions I was hoping the
> RIPE Database Requirements Task Force would answer when they started
> their work. The end result was a little disappointing. They didn't
> answer any of these questions. They focussed most of their attention
> looking backwards. Many of us know the history. We want to know how to
> move forwards. These types of proposals are not the right way forward.
> So where should we be heading? I believe we need a new Task Force to
> do what I thought the last one would do. To determine the business
> requirements for the RIPE Database as a public registry in the 2020s
> and beyond. To answer these fundamental questions. To establish the
> registration requirements for a public registry that we can have a
> consensus on and everyone will accept and apply.
>
> Daniel said at the BOFF in Iceland, "It's time to stop tinkering
> around the edges of the RIPE Database". But that is exactly what these
> policy proposals are doing. Here we are trying to retrofit an IPv6
> construct onto IPv4. Straight away assignment-size had to be dropped
> as it won't fit with the way IPv4 assignments are made or how they
> could be retrospectively aggregated. Knowing the blocksize has nothing
> to do with HD ratios and further allocations. It tells you nothing
> about how many assignments have been made from the aggregate, 1 or
> 100. It exists for IPv6 for other reasons. The same reasons we need
> for IPv4 but can't achieve, because the two systems are not the same.
>
> We need to start with a full, forward looking Business Requirements
> document for the RIPE Database, based on accepted business analysis
> procedures. We can follow that with a Technical Requirements document
> outlining how things should be done. Not at the level of defining
> technology or software design, that is for the NCC engineer's to
> determine. This should include the outline design of the data model
> and interfaces to commercial IPAM systems. Syncing bits of your
> internal data, as defined necessary for a public registry, with a
> database really isn't the problem in 2023. There should be no labour
> intensive work here. It doesn't matter if the RIPE Database has 5m or
> 50m or 500m assignment data sets in it. As long as they contain the
> data defined by the requirements to serve as a balanced public
> registry. No one should be manually entering this data. No one is
> going to read this data. We can build tools to provide information
> from this data in a human understandable format. In terms of
> registration requirements there should be little or no distinction
> between IPv4 and IPv6. But that doesn't mean we take the lowest common
> level.
>
> In case anyone is in any doubt, I am suggesting a redesign and rebuild
> of the RIPE Database, based on an updated understanding of what is
> needed to maintain and operate a public registry for all stakeholders.
> I know none of the RIPE community nor the RIPE WG chairs nor the RIPE
> NCC membership (who pay for it) nor the RIPE NCC executive board or
> senior management has any appetite for this. In the past whenever I
> have brought up this subject I have been totally ignored. Replying to
> emails where I have mentioned this, people have noticeably answered
> other points and cut out any reference to redesigning the RIPE
> Database. Many people have gone to extraordinary lengths to avoid even
> having this conversation. Seriously guys, the time has come to have
> this conversation. Daniel tried to start it at that BOFF. The RIPE
> community has just let it drop...again.
>
> The current design of the RIPE Database data model and software is
> about 25 years old. It was a big waterfall project with a big bang
> release and switch over from version 2 in April 2001. Aspects of the
> design, including having all data stored in untouched, human readable,
> text blocks, even predates this. We have had two major rewrites of the
> software in this time in C and then java. But the underlying design
> was not changed at all. Much of it is no longer fit for purpose. This
> attempt to retro fit aggregations from IPv6 to IPv4 highlights some of
> the cracks. It gets harder and harder to make significant changes to
> this system over time. Like assigning a whole allocation which cuts to
> the core of the software design and data model. Just to make this one
> change would be a very disruptive process for all users. Even if we
> decide today to set up a new task force to determine the business
> requirements, then the technical requirements, then redesign and
> rebuild in small agile chunks, we won't have a new system for at least
> 5 years. By then we are working with a 30 year old data model and
> system design. That is the age of dinosaurs in the IT world. Do we
> really want to wait until it breaks before we do anything? Calm,
> collective consideration is a better working model than panic,
> reactive mode. We are long overdue for this.
>
> It does not need to be done again in one huge step. It can be done
> incrementally. Use agile not waterfall methods. The whole system can
> be easily broken down into subsystems which can be worked on
> independently and deployed without massive disruption. I'll give some
> of my own thoughts and ideas on how some of this can be done.
>
> Task Force 1 to determine the business requirements of the RIPE
> Database as a public registry.
>
> Task Force 2 to determine the technical requirements of the RIPE
> Database as a public registry.
>
> Redesigned data model dropping the old fashioned requirement to have
> all data stored in untouched text blocks and be human readable. Stored
> data should be machine parsable and processable. Tools and interfaces
> can be provided to offer information based on the stored data or raw
> data for further machine processing.
>
> Accommodate new business models including the acceptance of investors
> and commercial RIRs operating below the RIPE NCC.
>
> Interfaces to commercial IPAM systems so all the required data can be
> uploaded and synced without human effort.
>
> Expand the LIR Portal to a system of user accounts for anyone who
> enters data into the database and identified/verified power users who
> consume the data.
>
> Notifications are basically an audit trail of changes to your data.
> This should be configured through the user accounts. No need for it to
> be spread throughout the entire database at the data set level. There
> are millions of attributes with duplicated email addresses all over
> the data. This has no public interest value at all and should not be
> public data.
>
> We should design a new authorisation and authentication scheme, also
> configured through the user accounts. Again details about the security
> of your data have no public interest value and should not be public
> data. I don't know of any other web based system that publishes so
> much information about how you secure and protect your data.
>
> The basic data is composed of hierarchical sets of IP addresses. But
> only abuse contacts use inheritance. All contact and management data
> should be inherited. That again could remove millions of items of
> duplicated, redundant data. Structure of contact and identification
> data should also be redesigned with privacy and confidentiality in
> mind.
>
> Resource holder and End User name and address details should be
> properly formatted rather than free text.
>
> Requirements for user registration details in a public registry could
> be re-evaluated and re-designed from the bottom up with a three way
> balance of privacy, confidentiality and public interest in mind.
>
> Language and characterisation of data can be re-evaluated for the
> whole data set.
>
> Routing data could be better structured with usage in mind. Tools
> could be built in to provide the structured data needed by those who
> use this data.
>
> Geolocation data could be built in rather than relying on external files.
>
> Basic, anonymous queries could be limited to bare bones data with no
> PII. More detailed data could be provided only to verified query
> users, with accounts, with different levels of detail.
>
> Historical data could be subject to a one time post processing to
> remove PII from public view but still allow anonymised cross
> referencing that researchers and investigators can do now with the PII
> data.
>
> The whole dataset should be organisation centric. Every piece of data
> entered into the database should be directly or indirectly linked to
> an organisation described in the dataset. There is no reason to allow
> anonymous or orphaned data to be entered.
>
> All changes of this nature could be made independently and gradually
> introduced. But we do need a road map based on a bigger picture so we
> know where we are heading. Especially for the core changes.
>
>
>
> If there is one thing I want you to consider from this message it is this:
> id nunc, aliquo tempore postea fit numquam
>
> I am not well know for my language skills so let me say it in English:
> do it now, sometime later becomes never
>
> cheers
> denis
> co-chair DB-WG
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
>
1 year, 8 months
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Erik Bais
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 <address-policy-wg-bounces(a)ripe.net> on behalf of denis walker <ripedenis(a)gmail.com>
Date: Saturday, 10 February 2024 at 09:10
To: "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net>
Cc: Tore Anderson <tore(a)fud.no>, Jan Ingvoldstad <frettled(a)gmail.com>
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 <address-policy-wg(a)ripe.net<mailto:address-policy-wg@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 <alexlh(a)funk.org<mailto:alexlh@funk.org>> 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 <tore(a)fud.no<mailto:tore@fud.no>> 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/013…
>
> > 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 <tore(a)fud.no<mailto:tore@fud.no>> wrote:
>
> Hi Denis,
>
> On 11/01/24 03:20, denis walker wrote:
> > On Wed, 10 Jan 2024 at 13:02, Tore Anderson <tore(a)fud.no<mailto:tore@fud.no>> 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/01…
>
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/013…
>
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/013…
>
> «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 <frettled(a)gmail.com<mailto:frettled@gmail.com>> wrote:
>
>
> On Thu, Jan 11, 2024 at 9:45AM Tore Anderson <tore(a)fud.no<mailto:tore@fud.no>> 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 <tore(a)fud.no<mailto:tore@fud.no>> 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 <tore(a)fud.no<mailto:tore@fud.no>> wrote:
>
> Hi Jan,
>
> On 11/01/24 13:27, Jan Ingvoldstad wrote:
> > On Thu, Jan 11, 2024 at 1:11PM Tore Anderson <tore(a)fud.no<mailto:tore@fud.no>> 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 <ripe-lists(a)sebastian-graf.at<mailto:ripe-lists@sebastian-graf.at>> 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 <tore(a)fud.no<mailto:tore@fud.no>> 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 <ripe-lists(a)sebastian-graf.at<mailto:ripe-lists@sebastian-graf.at>> 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 <ripe-lists(a)sebastian-graf.at<mailto:ripe-lists@sebastian-graf.at>> 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 <ripe-lists(a)sebastian-graf.at<mailto:ripe-lists@sebastian-graf.at>> 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.
========================================================
1 year, 3 months
Re: [address-policy-wg] 2023-04 Who do I speak for?
by denis walker
Colleagues
A question has been put to me privately asking if I am speaking for
the DB-WG because I sign my mails as 'co-chair DB-WG'. Now asking a
question like this to an analyst means you are going to get a detailed
answer.
Everything about RIPE (not RIPE NCC) is underpinned by the RIPE
community. This is a very loosely defined community. It is basically
anyone in the world who has an opinion on how the Internet is operated
and administered in the RIPE region. It is not tied to any specific
group of people and I don't think it carries any legal weight, even on
any consensual decisions it makes. I'm not sure if the relationship
between RIPE and the RIPE NCC is even written into the RIPE NCC's
corporate documents requiring the RIPE NCC to take instructions from a
RIPE community consensus, or just from its own membership and/or
executive board. So the whole concept of the RIPE community and
everything it does is voluntary and pretty much undefined.
So what is a Working Group vs a RIPE Working Group? A WG can be
established to be a specific, defined set of people, assigned a
specific task to investigate or work on. Such a WG can have an
opinion, viewpoint or a conclusive result. The chairs of such a WG can
express opinions, views or conclusions for or on behalf of the WG.
Similar to what we call a Task Force. A RIPE WG is basically a public
mailing list that anyone in the world can read and follow, but only a
random subset of the community subscribers to the list will comment on
for any specific issue. The WG, or mailing list, can't have a view or
opinion. Only the community members subscribed to the list, who choose
to comment, have views and opinions, which may be personal or
corporate. So a co-chair cannot speak 'for' a WG. At best they can
express a summary of the views held by the community members who
choose to comment on any specific issue. Another difference is that a
RIPE WG, unlike a TF, is not limited to one issue. It can have any
number of diverse issues under discussion at any moment. The only
consideration is that each issue vaguely fits the title of the WG.
Following a discussion the chairs can determine if there is a
consensus from the views expressed by those transient, community
members who commented. The chairs and anyone else can then refer to
that consensus. But this is a consensus of the views of the community
members, not of the WG. The WG itself, being so loosely defined,
cannot have a view.
Even though it says in ripe-692 RIPE Working Group Chair Job
Description and Procedures,
"When participating in RIPE discussions, WG Chairs and co-chairs
should endeavour to make it clear whether they speak on behalf of
themselves, the organisations they work for, or the WG for which they
are co-chair."
I think this is a generalised condition. With the structure of RIPE
WGs there is no meaning to speaking 'for' a WG. A RIPE WG is just a
collection of views expressed by individual, transient RIPE community
members which may or may not reach a consensus. Incidentally I don't
recall ever seeing a WG chair state that a view is that of their
business. I would be surprised if no chair has ever expressed a view
that is in the best interests of their business. Rather than this
constant dance with changing hats, I think it would make more sense to
assume any comment or view expressed by anyone, including a co-chair,
is a personal view unless they explicitly say it is the view of their
business or a collective or consensual view from a WG.
The web page https://www.ripe.net/participate/ripe/wg sums it up quite well,
"The responsibility of the chairs is to moderate discussions and
declare whether consensus is reached on a policy proposal...Most of
the working group’s activity is done via the mailing list"
As there has been no policy proposal or NWI on the DB-WG mailing list
on these issues there is no consensus and therefore nothing I could
refer to in a way of speaking 'for' the DB-WG.
Even on this page https://www.ripe.net/participate/ripe/wg/wg-chairs it says,
"The chairs are responsible for moderating discussions on the mailing
lists, chairing Working Group sessions and for declaring whether
consensus is reached on a policy proposal."
There is no concept of speaking 'for' the WG mentioned.
Of course I could start a parallel discussion on the DB-WG mailing
list about the content of the RIPE Database and it's future. But the
small subset of the RIPE community who comment on the DB-WG mailing
list is pretty much the same as the small subset of the RIPE community
who comment on the AP-WG mailing list. It is extremely hard to get
many people to comment on any discussion on any mailing list these
days. To ask the same people to express the same views in two
different places would be an impossible task. As the two mailing lists
do have such an overlap of contributors I see this discussion as a
RIPE Database discussion as much as an address policy discussion, even
though it is on the AP-WG list. It is generally discouraged to cross
post on multiple mailing lists. Obviously the co-chairs of the DB-WG
cannot declare a consensus on any discussion on this mailing list. But
if it looked like the discussion was leading to something tangible for
the RIPE Database we could summarise it on the DB-WG mailing list and
ask for final comments and declare a consensus there. As it is more or
less the same group of people commenting on the two lists, you know
you haven't had this discussion on the other list so there is no
consensus I could be referring to.
So why do I sign as co-chair of the DB-WG on posts on this mailing
list? As I have outlined above, I cannot speak 'for' the DB-WG as that
has no meaning. But I think it is important to show that this
discussion, to a large extent about the RIPE Database, is being
followed (some may say driven) by a co-chair of the DB-WG. Then if
anything of more concern to the DB-WG than the AP-WG is discussed or
suggested, but perhaps not concluded, you know it will be followed up
on the DB-WG mailing list. I also do it to indicate to anyone who may
not know me, that I am a person who does have some detailed knowledge
of the RIPE Database. I am retired so I don't have any job title or
corporate name to reference. IF this is a concern to anyone then I
could change my signature on future emails to:
denis
former RIPE NCC Business & Technical Analyst, Designer,
Developer, Administrator for the RIPE Database
In fact this may be more meaningful. Many people who have been chairs
of the DB-WG over the years have only had operator experience of using
the RIPE Database. I literally know it inside out, from almost every
possible angle for 20+ years. I was never 'just an engineer'. I was
even half the legal team for the database with Jochem, before the NCC
employed legal professionals. The only experience I don't have is
using it as an operator. But that is something most of the rest of you
have.
cheers
denis
former RIPE NCC Business & Technical Analyst, Designer,
Developer, Administrator for the RIPE Database
1 year, 8 months
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by denis walker
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(a)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 <alexlh(a)funk.org> 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 <tore(a)fud.no> 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/013…
>
> > 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 <tore(a)fud.no> wrote:
>
> Hi Denis,
>
> On 11/01/24 03:20, denis walker wrote:
> > On Wed, 10 Jan 2024 at 13:02, Tore Anderson <tore(a)fud.no> 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/01…
>
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/013…
>
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/013…
>
> «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 <frettled(a)gmail.com> wrote:
>
>
> On Thu, Jan 11, 2024 at 9:45AM Tore Anderson <tore(a)fud.no> 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 <tore(a)fud.no> 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 <tore(a)fud.no> wrote:
>
> Hi Jan,
>
> On 11/01/24 13:27, Jan Ingvoldstad wrote:
> > On Thu, Jan 11, 2024 at 1:11PM Tore Anderson <tore(a)fud.no> 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 <ripe-lists(a)sebastian-graf.at>
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 <tore(a)fud.no> 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 <ripe-lists(a)sebastian-graf.at>
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 <ripe-lists(a)sebastian-graf.at>
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 <ripe-lists(a)sebastian-graf.at>
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.
========================================================
1 year, 3 months
Re: [address-policy-wg] 2023-04 Are anonymised assignment objects valid?
by Brian Storey
Hi all,
Outside of the detail from Denis and Tore, the discussion on this one seems
quite limited, yet there is more than a hint that the proposed change
conflicts with some core fundamental goals of the registry and the
overarching purpose of the policy as is today. This is clearly an area of
contention.
I'm more than comfortable in saying that the policy interpretation by the
RIPE NCC as detailed in the dialog between Tore and Angela is VERY
surprising to me. It appears to go against conventional or widely accepted
interpretation of the current policy (and those before it) and as an example
the direction / sentiment set out within their own Database Training
materials or videos:-
https://www.youtube.com/watch?v=0RI5W3hqBug&list=PLC964CD89C4AE0337
https://www.youtube.com/watch?v=w6oUf7j4SME&list=PLC964CD89C4AE0337&index=7
As I've mentioned before, the policy as-is does appear open to
interpretation in terms of what CONTENT goes into an End User Assignment
INETNUM registration. I'm not saying that's wrong but I think it's important
to distinguish between that and those who choose not to register anything;
the latter being non-compliance or at least not able to adequately
demonstrate that their assignments are regularly maintained.
So whilst the policy isn't prescriptive in how you achieve the "must", it
does seems like many have found a common approach with using a blend of the
mandatory and optional attributes to satisfy the requirements of End user
registration, in particular for each non-individual & non-P2P assignments.
However contrary to this, it seems like there is a developing/developed view
that if the attribute isn't mandatory, it doesn't count in the wider
context. Whereas in reality the accepted convention is more a case of "if
this mandatory attribute is populated this way", "use this optional
attribute this way". It's not strict compliance but fulfils the objective.
Yet, if we aren't actually required to publish end user names (based on the
Q&A transcript provided by Tore), why are so many doing so? Rightly or
wrongly, it would suggest to me there is some form of compliance or
enforcement drift and therefore quite a gulf between the INTENT of the
policy and what the enforced minimum requirements actually are. Or perhaps
that same many have got it wrong, overreaching on what needs to be
published, yet they don't think they have which emphasises the problem (if
this discussion alone doesn't already prove that!).
For me it comes down to this. As a community & considering the permitted
exceptions (individuals & P2P assignments):-
1) Is the publication of End User entities for an assignment important?
2) Is the publication of a prefix assignment boundary between end users
important?
If the answer to either of those is yes, then I don't think this proposal
should go forward in its current form & the current RIPE NCC interpretation
of the current policy as shared by Tore should be challenged.
If the answer to both is no, then it has legs but only for those reasons.
Justifying it because some LIRs don't do what they are supposed to do isn't
sufficient. That's what the Assisted Audit is for right? I recognise that
the time between assignment & reassignment for some service providers is now
substantially shorter, but arguably the likes of Virtual Service providers
are better equiped than most to deal with that. Spinning things up and
tearing them down is afterall their day to day.
In either case, does consideration toward best practice & holding to higher
standards have any weight?
https://datatracker.ietf.org/doc/html/rfc3013#section-4.1
There is a side piece to this too & an area I commented on a couple of weeks
ago regarding End User interests on the publication or not of their Business
Name. Armed with the information now that publication of the End user names
isn't mandatory (although previously believed to be a requirement -
arguments challenging this aside) does explicit consent now need to be
obtained to continue with that practice, if the LIR choses to continue with
that approach? If the publication of an End User isn't backed up by a policy
which we are bound to comply with contract / Terms & Conditions then
continuing creates an exposure for new and existing entries? Given what is
being discussed, the proposal or even the existing policy should be modified
to be clear as to whether there is a condition here or not and in what
form(s) this must take. I say this because the discussion being had here and
the efforts made on those INETNUM entries which are there now (ours
included) would indicate it isn't as clear as we thought it was.
This discussion has made me feel uncertain about the existing policy but
also juding the proposal because of it. The answers to those 2 questions is
key.
Either way, I want to make sure I'm falling on the right side of the policy
& be able to justify how much or little effort we put in to the registry
entries. Referencing some of the detail in this discussion as a means to
determine that doesn't feel adequate.
Many thanks,
Brian
-----Original Message-----
From: address-policy-wg <address-policy-wg-bounces(a)ripe.net> On Behalf Of
denis walker
Sent: Thursday, September 28, 2023 11:31 AM
To: Tore Anderson <tore(a)fud.no>
Cc: address-policy-wg(a)ripe.net
Subject: Re: [address-policy-wg] 2023-04 Are anonymised assignment objects
valid?
Colleagues
I know this is a very long email and no one has the time to read it, but I
have at least put my points on record.
This proposal claims to only be about adding a new, optional status value.
It is claimed it doesn't permit anything else that isn't already possible
with the current address policy. In particular it is claimed you can already
have anonymous assignments in the RIPE Database. Some people do create such
objects. The RIPE NCC audits don't question such objects. But is that right?
There has been so much false and misleading information about this issue. I
am going to have one last attempt to put the record straight.
Then, if no one else cares, why should I? I have a bathroom to build...
We are talking about one sentence in the current address policy that this
proposal removes. A sentence that is the heart of assignment policy. The
core of the public registry of public IP addresses. An English sentence that
is so clear and obvious, it simply cannot be misunderstood or
(mis)interpreted. And yet I am having to write an essay to try to explain
what this clear sentence means.
"When an End User has a network using public address space this must be
registered separately with the contact details of the End User."
Let me break it down into smaller segments to explain it's meaning:
'End User has a network' - a network for an End User
'using public address space' - the address space for the network is
part of the public Internet
'must be' - MUST, not can, should, may, possibly, perhaps...MUST
'registered separately' - registered in the RIPE Database in a
separate object, all alone
'contact details' - information that allows you to make contact with
'of the End User' - the End User who you want to contact
This sentence only has one possible meaning. And that meaning says you
cannot have an End User assignment in the RIPE Database that does not allow
you to make contact with the End User (subject to the specified exceptions).
This sentence and meaning are so clear it is impossible to write it any
clearer.
What matters today is the actual wording of the current address policy. But
to understand some of that, we need to look at how we got here and some of
the early definitions that are no longer included in the policy. So let's
start with a history lesson. With my information archeologist's hat on, I've
gone all the way back to 1990 to understand what the terminology in the
address policy and the RIPE Database means.
In the first version of the address policy ripe-065 RIPE NCC Internet
Numbers Registration Procedures Publication date: 01 Jul 1992
It says:
"This document describes the procedures for the reassignment of IP network
numbers from blocks obtained from the RIPE Network Coordination Centre."
...
"Full information about reassigned network numbers must be reported back to
the RIPE NCC and the US NIC in full RIPE database format (ref ripe-13)."
Then in ripe-13
RIPE Databases
Publication date: 28 Aug 1990
It describes the network objects to include these attributes:
-----------
tc -name of technical contact.
This must be the same string as in the corresponding *pn entry.
There must be such a person entry!
ac -name of administrative contact.
This must be the same string as in the corresponding *pn entry.
There must be such a person entry!
de -description of the network.
Give organisation and place.
Postal address and country are not needed, they can be found via the
contacts.
The country is given in *cy.
-----------
Then in an example it includes:
-----------
*de: CWI Ethernet (Classical)
*de: Amsterdam
*de: Netherlands
-----------
So right from the start of registration we have had description attributes
giving information about the name and location of the assignment holder.
Then we move a few hops to ripe-136
European Internet Registry Policies And Procedures Publication date: 24 May
1996
This is starting to look a bit like modern address policy.
Interestingly it actually defines some of the terms we have lost touch with
over time. If you ask most people now what an admin-c contact is they don't
know. Which is why many objects have the same entry for both tech-c and
admin-c. But that is often wrong.
Some definitions:
End users are those organizations operating networks in which the address
space is used. End users must provide and update registration data for the
address space assigned to them.
Local IRs are typically operated by Internet Service Providers (ISPs).
Local IRs hold allocations of address space for assignment to end users. In
some cases, the local IR assigning the address space is not run by the ISP
that will provide connectivity. It is important to note that maintenance of
the administrative information regarding the assigned address space is the
responsibility of the IR that makes the assignment, and not of the ISP
providing the connectivity.
Requesters - In addition to these key players in the Internet Registry
System, there are often consultants who set up and manage networks for end
users.
netname - a short, but semantically meaningful name
descr - A short description of the organisation that will use the assigned
addresses, in one or more fields. Typically the name of the organisation.
admin-c - administrative contact persons. The administrative person
specified in the admin-c field must be physically located at the site of the
network.
[Clearly the original definition of the admin contact means it must be
someone at the site of the end user. This, with the descr fields, identifies
and provides contact information for the end user.]
tech-c - technical contact persons. The technical person specified in the
tech-c field may be a network support person located on site, but could also
be a consultant that maintains the network for the organisation.
Submission of objects to the database is the final and required step in
making an assignment. This step makes the assignment definite, and makes
public information regarding the assignment available to anyone seeking it.
[Again it is clear from the early days that the public registry was not only
an operators phone book for solving network issues. Maybe this will bring to
an end those endless arguments about whether LEAs have a right to access and
use the information in the RIPE Database.
"available to anyone seeking it"]
>From ripe-140
European Internet Registry Policies and Procedures Publication date: 06 Sep
1996
Just for further clarity it describes the admin-c of an aut-num object as:
"The administrative contact should be physically located at the enterprise
requesting the AS number."
which further clarifies the difference between the tech-c and admin-c
generally.
ripe-159 (29 Jul 1997) adds that the admin-c "The person does not have to
have technical knowledge of the network."
Then we get to ripe-234
IPv4 Address Allocation and Assignment Policies In The RIPE NCC Service
Region Publication date: 14 Jun 2002
This is where we first get the differentiation between DSL connections and
public networks.
"However, four or more addresses (e.g. /30 or more) used on the End User's
network need to be registered separately with the contact details of the End
User."
Almost the exact wording we still use today, 21 years later.
Then ripe-288
IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service
Region
Date: 28 October 2003
We now have the exact wording that we have today (it is even in paragraph
6.2):
"When an End User has a network using public address space this must be
registered separately with the contact details of the End User."
So we have had this principle with the exact same wording for 20 years.
Every version of the address policy since then has included this exact line.
(Incidentally one of the authors of this document was Leo, now co-chair of
this WG)
All these documents have been co-written by many people including the RIPE
NCC founder, RIPE NCC CEO, RIPE chair, RIPE co-chair, AP-WG co-chair, former
DB-WG co-chair, yet we seem to have collectively forgotten what many of
these terms mean.
So now let's come back to the present. How do these definitions change our
perspective? The first thing to note is that these definitions are no longer
written into the policy. They disappeared over 20 years ago.
But, in the absence of any definitions in the current policy, and no
community consensus over that time to change any of these definitions, it
seems reasonable to apply those definitions from earlier versions of the
same policy document. Especially as the database documentation still makes
the clear distinction between a tech-c and an admin-c in line with those
early definitions.
Let's again look at that typical company operating a network with public
address space. They may be technically competent, in which case the tech-c
will provide contact details for their own engineers. If they don't have the
technical skills someone else will manage the network for them. That could
be the LIR, or an ISP (seperate from the
LIR) who provides the connectivity services, or an independent consultant.
Whoever it is, they should be listed as the tech-c contact person. When it
comes to the admin-c, we now know who this is meant to be. It is someone,
with or without technical skills, who is physically located at the site of
the enterprise operating the network. Having that person's contact details,
combined with the descr attributes that optionally specify the name and
location of the organisation, we satisfy the current policy requirement
"registered separately with the contact details of the End User".
When an LIR manages the network for the End User, to replace both the tech-c
and admin-c with the LIR's contact details is wrong, according to the
current policy. The admin-c should always be a contact from the End User's
site. As many LIRs do get that bit wrong, they often compensate by adding
full name and address details of the End User in the descr attributes. That
makes them still compliant with current policy as the assignment object
still has the contact details of the End User. There are so many objects in
the database like this. If the labour intensity of maintaining this data is
one of the driving forces behind this proposal, why do so many LIRs put all
that optional data into their objects? That takes a lot of effort. If an
assignment is cancelled then re-assigned to another customer, they have to
change the object to update this optional data. Without the optional data
the same object would still be valid for the next customer without any
update. They do it because they read the policy and understand that 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 knew they must include contact details for the End User.
During this debate it has been said that the contacts are "the tech-c and
admin-c, nothing more, nothing less". That is just wrong. Nothing in the
current or any previous version of the address policy has ever said that.
You cannot just invent conditions like this, out of nowhere. The descr
attributes are contacts. A referenced organisation object provides contacts.
There are other options for contact information. But the bottom line is, the
assignment object MUST contain the End User's contacts (subject to the
specified exceptions).
So it is not policy compliant to have an assignment object that does not
have contact details of the End User. If the RIPE NCC does not question this
during an audit, they have got it wrong. They may have got it wrong for many
years, but it is still wrong. We should not change the policy just because
mistakes have not been corrected for a long time.
So the answer to the main question is (finally), this proposal makes
significant changes to assignment policy and allows the creation of
anonymised assignment objects that the current policy does not allow.
I will go further than this. If the current policy was correctly applied, it
is not possible to aggregate assignments as they will all have different
admin-c contacts.
That means the question the community needs to consider is if it is now
acceptable to allow anonymised assignment objects in the RIPE Database,
possibly in significant numbers? If this proposal is accepted and the
definition of admin-c is changed to what many people actually think it is,
then the only End Users who will be publicly contactable are those who
manage their own networks. Potentially ALL others can be anonymised, with or
without aggregation.
Now just to finish off I will address the Q&A.
On Tue, 26 Sept 2023 at 15:41, Tore Anderson <tore(a)fud.no> wrote:
>
> Hi Denis,
>
> It would appear to me that your opposition to 2023-04 is largely based
> on the premise that it introduces a new possibility for anonymous
> assignments, a change which you do not want to see happen. This
> premise also appears to underpin many of your musings in your <The
> bigger picture> message.
Then you didn't read it.
> I disagree with this premise, as I believe this possibility is already
> there in 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."
>
> Rather than decide to agree to disagree on that point, or endlessly
> quarrel about it, I realised that it does not really matter what you
> or I believe the policy requirements are - what matters is the RIPE
> NCC's understanding of the policy and how they are implementing it. So
> I simply asked their Policy Officer (Angela) to clarify this.
What matters is are they implementing it correctly?
>
> Her answers, which I with permission quote in full along with my
> questions below, unequivocally confirms that that current policy does
> indeed allow assignments to be registered anonymously in the RIPE
> database. Hence, your opposition to proposal 2023-04 in this regard
> appears to rest on a fundamentally flawed assumption.
"When an End User has a network using public address space this must be
registered separately with the contact details of the End User."
>
>
> Tore: <The context here is an IPv4 assignment that is not made to an
> individual and that is not used solely for the connection of an End
> User to a service provider.
>
> 1. Does current address policy as implemented by the NCC allow an End
> User to delegate/outsource the contact information represented by the
> mandatory "tech-c" and "admin-c" attributes to another entity,
> typically (but not necessarily) the issuing LIR? (There does not appear
> to be any disagreement on this point, but I include this question
> anyway in case we are both wrong.)>
>
> Angela: <Yes, you are correct. An End User is allowed to
> delegate/outsource the contact information represented by the mandatory
> "tech-c" and "admin-c" attributes to another entity, typically (but not
> necessarily) the issuing LIR.>
No it is not correct. The administrative person specified in the admin-c
field must be physically located at the site of the network.
Therefore it cannot be outsourced.
>
> Tore: <2. Assuming "yes" to question 1, for an assignment where the
> "tech-c" and "admin-c" has been delegated in this manner: Does current
> address policy require the corresponding "inetnum" database object to
> contain some additional contact information, that is not delegated to a
> third party, i.e., it must be refer to a point of contact that is
> handled in-house by the End User him/herself?>
>
> Angela: <The current address policy does not require the corresponding
> "inetnum" database object to contain some additional contact
> information that is not delegated to a third party.
> LIRs can use the "netname" attribute to link assignments to end users
> and their contact details in internal records.
"When an End User has a network using public address space this must be
registered separately with the contact details of the End User."
>
> There is a particular case: when the RIPE NCC receives a request for
> assigning an AS number to an End User using a PA assignment, the IPv4
> network to be announced by the requested AS must be registered in an
> "inetnum" object showing the End User's name. This can be in the
> "descr" attribute or recursively in the "org" object added as
> attribute.>
This does not apply to most of the assignments in the database where the
optional descr attributes have been added with name and address of the End
User
>
> Tore: <3. Assuming "yes" to question 2, what kind of other contact
> information is required, and in which "inetnum" database attribute(s)
> must it be located? Here are some possible examples off the top of my
> head, would any or all of these satisfy the policy requirement for an
> in-house non-delegated contact information?
> 1. A street address
> 2. A (snail) mail address
> 3. An e-mail address
> 4. A fax number
> 5. A phone number>
>
> Angela: <The answer to question 2 was "no', however one way to record
> End Users' contact details is to create an "org" object to be added as
> optional attribute in the "inetnum" object.
> In "org" objects name, address and email are mandatory.
> In "inetnum" objects the mandatory contact information are "admin-c"
> and "tech-c".>
"When an End User has a network using public address space this must be
registered separately with the contact details of the End User."
>
> Tore: <4. Assuming "yes" to question 2, is it mandatory to identify the
> End User by name, or would it be sufficient with, e.g., a street
> address without an organisation name (assuming there is only a single
> entity located at that address), a post box snail mail address, a
> generic user123(a)gmail.com e-mail address, or a phone/fax number that is
> not listed in the white or yellow pages?>
>
> Angela: <The answer to question 2 was "no',...>
"When an End User has a network using public address space this must be
registered separately with the contact details of the End User."
>
> Tore (in a new e-mail): <I will ask you a couple of follow-up questions
> just to make absolutely, 150%, certain I do not misunderstand you and
> end up misrepresenting you to the mailing list:
>
> 1. When you write <LIRs can use the "netname" attribute to link
> assignments to end users and their contact details in internal
> records>, this "can" is a MAY, not a MUST, to use IETF lingo? That
> is, the LIR is free to instead use the "inetnum" attribute, i.e.,
> the IP address(es), to link the assignment to the End User in their
> internal record? If that is the case, would it be correct to say
> that the LIR are free to set the "netname" attribute to essentially
> anything, including a meaningless string of random characters?>
>
> Angela: <Your interpretation is correct, the answer is yes to all
> three questions.
> Please also consider that the "netname" is not required to be
> unique, LIRs can use the same one for multiple assignments.>
>
> Tore: <2. When you write <one way to record End Users' contact
> details is to create an "org" object to be added as optional
> attribute in the "inetnum" object>, this is also a MAY, not a MUST?
> That is, the LIR is free to omit the "org" attribute, even though
> the only other contact information contained in the object is the
> (LIR-delegated) "tech-c" and "admin-c" attributes?>
>
> Angela: <Yes, the LIR is free to omit the "org" attribute, even
> though the only other contact information contained in the object is
> the (LIR-delegated) "tech-c" and "admin-c" attributes.
> If the LIR requests an AS number on behalf of an end user to
> announce a PA assignment, then the PA assignment MUST include the
> legal name of the end user in the "descr" attribute or in the '"org"
> object set as "org" attribute in the "inetnum" object.>
>
"When an End User has a network using public address space this must be
registered separately with the contact details of the End User."
The administrative person specified in the admin-c field must be physically
located at the site of the network.
> Tore: <3. To use a concrete example: Let's say <SuperLIR GmbH>
> delegated 192.0.2.0/25 to the End User <CarFactory GmbH>.
> (CarFactory GmbH is not an individual, and the assignment is not
> used solely for the connection to the provider, nor to justify an
> application for an AS number). SuperLIR inserts the following
> minimal database object:
>
> inetnum: 192.0.2.0 - 192.0.2.128
> netname: ABCDEFGHIJKLMNOPQRSTUVWXYZ
> country: DE
> admin-c: SUPERLIR-NOC-RIPE
> tech-c: SUPERLIR-NOC-RIPE
> status: ASSIGNED PA
> mnt-by: SUPERLIR-MNT
> source: RIPE
>
> In the event of an audit, SuperLIR GmbH will be able to inform the
> RIPE NCC auditors that this object has been delegated to CarFactory
> GmbH.
>
> Is the above registration compliant with current IPv4 address
> policy, or will the auditors demand any kind of changes be made?>
>
> Angela: <The above registration compliant with current IPv4 address
> policy. During an audit we could ask the LIR whether the assignment
> is still in use. It does not matter for the RIPE NCC who is using
> the assignment, as long as the LIR is maintaining the registration
> up to date and is able to contact the end user. This means that if
> the LIR moves the assignment delegation from CarFactory GmbH to
> another end user in the same country for which is acting as "admin-
> c" and "tech-c", the "inetnum" object would still be valid. It is
> the LIR's responsibility to keep their internal records up to date
> accordingly with the new end user.>
"When an End User has a network using public address space this must be
registered separately with the contact details of the End User."
The above object is not compliant and the audit should pick that up
>
>
> In light of the above, I hope that you will reconsider your opposing
> arguments and either withdraw them or restate them in a way that does
> not rely on this incorrect assumption. Anticipating this, I will only
> address your remaining points that are not based on the
> misunderstanding that 2023-04 opens up for anonymous assignments.
>
My assumption is correct.
cheers
denis
co-chair DB-WG
--
To unsubscribe from this mailing list, get a password reminder, or change
your subscription options, please visit:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe
.net%2Fmailman%2Flistinfo%2Faddress-policy-wg&data=05%7C01%7Cbrian.storey%40
gamma.co.uk%7C2da065f0adae46dcb9c308dbc00e1fc3%7C743a5d9f11234f3f8fcf5766b8a
d8bf9%7C0%7C0%7C638314939120399679%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fXEe
nEm7tmtgXCFJsgLGbcHyJMjOjghY%2F29nKvjUf5s%3D&reserved=0
1 year, 8 months
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by denis walker
Hi Erik
On Tue, 13 Feb 2024 at 16:56, Erik Bais <erik(a)bais.name> 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 <address-policy-wg-bounces(a)ripe.net> on behalf of denis walker <ripedenis(a)gmail.com>
> Date: Saturday, 10 February 2024 at 09:10
> To: "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net>
> Cc: Tore Anderson <tore(a)fud.no>, Jan Ingvoldstad <frettled(a)gmail.com>
> 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 <address-policy-wg(a)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 <alexlh(a)funk.org> 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 <tore(a)fud.no> 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/013…
> >
> > > 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 <tore(a)fud.no> wrote:
> >
> > Hi Denis,
> >
> > On 11/01/24 03:20, denis walker wrote:
> > > On Wed, 10 Jan 2024 at 13:02, Tore Anderson <tore(a)fud.no> 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/01…
> >
>
> 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/013…
> >
>
> 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/013…
> >
> > «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 <frettled(a)gmail.com> wrote:
> >
> >
> > On Thu, Jan 11, 2024 at 9:45AM Tore Anderson <tore(a)fud.no> 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 <tore(a)fud.no> 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 <tore(a)fud.no> wrote:
> >
> > Hi Jan,
> >
> > On 11/01/24 13:27, Jan Ingvoldstad wrote:
> > > On Thu, Jan 11, 2024 at 1:11PM Tore Anderson <tore(a)fud.no> 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 <ripe-lists(a)sebastian-graf.at> 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 <tore(a)fud.no> 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 <ripe-lists(a)sebastian-graf.at> 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 <ripe-lists(a)sebastian-graf.at> 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 <ripe-lists(a)sebastian-graf.at> 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.
> ========================================================
1 year, 3 months
Re: [address-policy-wg] 2023-04 The bigger picture
by denis walker
Colleagues
I want to look at the bigger picture here. I apologise again for
another long email. There are many issues here that this community has
ignored for too long. So I hope some of you will at least read through
to the end, think about what I say and comment...maybe even support
the general idea...
Although this has been a discussion with only a handful of people it
has raised some interesting points. Many followers may have missed the
significance of some of these points or perhaps not thought deeply
about them. These include (in no particular order):
-Different registration requirements for IPv4 and IPv6
-Differences in the way IPv4 and IPv6 have been allocated and assigned over time
-Block size (fixed or random)
-Retro fitting of features
-Different levels of adherence to policy by resource holders
-Voluntary nature of supplying some details
-No consistent approach to supplied data
-Confusion for some resource holders about what data to publish
-Effort required to maintain data in the RIPE Database
-Volatility of some fast changing data
-Privacy
-Customer confidentiality
-Public interest
-Public registry
-Registering public networks
-Addresses defined as free text (sometimes including name)
This is a lot of issues wrapped around one policy proposal. This
proposal will not address all, or even most, of these issues. I don't
believe this is the right way forward. But what is the root problem
here and how can we address it?
There are also some other points to consider. At recent RIPE Meetings
some prominent members of this community have told me in the strongest
possible terms that there is no way in hell that they are going to
list any of their customer's details in the public RIPE Database. No
matter what any policy says. Commercial confidentiality seems to be a
very sensitive issue for some resource holders. Of course this is a
valid concern. But it needs to be balanced. Policy needs consensus,
but when we have a consensus all resource holders must follow it. That
is the only way a self regulating industry can work.
Another reason of concern is the alignment of handling both IPv4 and
IPv6 registrations in the RIPE Database. Where we have two systems
that are managed in different ways, there are of course two ways they
can be aligned. We can dumb down the IPv4 data to the level of IPv6.
Or we can raise the IPv6 data to the level of IPv4. Everyone is
focused on the dumbing down option. No one has even considered moving
in the other direction. I have never understood why the IPv6
registration policy was not written with the same requirements in mind
as the IPv4 in the first instance. Maybe at the time the automation
options available then were not as extensive as they are today.
Computer power and bandwidth were certainly not comparable to what
they are today. Changes to the RIPE Database data model, interfaces,
technology and design would make it possible to raise the level of
IPv6 information available in the public registry to the same level as
IPv4.
At the heart of this issue is a public registry. But what is that in
2023? What does it mean? What should be in it? Who is it for? How do
we achieve a three way balance between commercial sensitivity, public
need and privacy? These are the sort of questions I was hoping the
RIPE Database Requirements Task Force would answer when they started
their work. The end result was a little disappointing. They didn't
answer any of these questions. They focussed most of their attention
looking backwards. Many of us know the history. We want to know how to
move forwards. These types of proposals are not the right way forward.
So where should we be heading? I believe we need a new Task Force to
do what I thought the last one would do. To determine the business
requirements for the RIPE Database as a public registry in the 2020s
and beyond. To answer these fundamental questions. To establish the
registration requirements for a public registry that we can have a
consensus on and everyone will accept and apply.
Daniel said at the BOFF in Iceland, "It's time to stop tinkering
around the edges of the RIPE Database". But that is exactly what these
policy proposals are doing. Here we are trying to retrofit an IPv6
construct onto IPv4. Straight away assignment-size had to be dropped
as it won't fit with the way IPv4 assignments are made or how they
could be retrospectively aggregated. Knowing the blocksize has nothing
to do with HD ratios and further allocations. It tells you nothing
about how many assignments have been made from the aggregate, 1 or
100. It exists for IPv6 for other reasons. The same reasons we need
for IPv4 but can't achieve, because the two systems are not the same.
We need to start with a full, forward looking Business Requirements
document for the RIPE Database, based on accepted business analysis
procedures. We can follow that with a Technical Requirements document
outlining how things should be done. Not at the level of defining
technology or software design, that is for the NCC engineer's to
determine. This should include the outline design of the data model
and interfaces to commercial IPAM systems. Syncing bits of your
internal data, as defined necessary for a public registry, with a
database really isn't the problem in 2023. There should be no labour
intensive work here. It doesn't matter if the RIPE Database has 5m or
50m or 500m assignment data sets in it. As long as they contain the
data defined by the requirements to serve as a balanced public
registry. No one should be manually entering this data. No one is
going to read this data. We can build tools to provide information
from this data in a human understandable format. In terms of
registration requirements there should be little or no distinction
between IPv4 and IPv6. But that doesn't mean we take the lowest common
level.
In case anyone is in any doubt, I am suggesting a redesign and rebuild
of the RIPE Database, based on an updated understanding of what is
needed to maintain and operate a public registry for all stakeholders.
I know none of the RIPE community nor the RIPE WG chairs nor the RIPE
NCC membership (who pay for it) nor the RIPE NCC executive board or
senior management has any appetite for this. In the past whenever I
have brought up this subject I have been totally ignored. Replying to
emails where I have mentioned this, people have noticeably answered
other points and cut out any reference to redesigning the RIPE
Database. Many people have gone to extraordinary lengths to avoid even
having this conversation. Seriously guys, the time has come to have
this conversation. Daniel tried to start it at that BOFF. The RIPE
community has just let it drop...again.
The current design of the RIPE Database data model and software is
about 25 years old. It was a big waterfall project with a big bang
release and switch over from version 2 in April 2001. Aspects of the
design, including having all data stored in untouched, human readable,
text blocks, even predates this. We have had two major rewrites of the
software in this time in C and then java. But the underlying design
was not changed at all. Much of it is no longer fit for purpose. This
attempt to retro fit aggregations from IPv6 to IPv4 highlights some of
the cracks. It gets harder and harder to make significant changes to
this system over time. Like assigning a whole allocation which cuts to
the core of the software design and data model. Just to make this one
change would be a very disruptive process for all users. Even if we
decide today to set up a new task force to determine the business
requirements, then the technical requirements, then redesign and
rebuild in small agile chunks, we won't have a new system for at least
5 years. By then we are working with a 30 year old data model and
system design. That is the age of dinosaurs in the IT world. Do we
really want to wait until it breaks before we do anything? Calm,
collective consideration is a better working model than panic,
reactive mode. We are long overdue for this.
It does not need to be done again in one huge step. It can be done
incrementally. Use agile not waterfall methods. The whole system can
be easily broken down into subsystems which can be worked on
independently and deployed without massive disruption. I'll give some
of my own thoughts and ideas on how some of this can be done.
Task Force 1 to determine the business requirements of the RIPE
Database as a public registry.
Task Force 2 to determine the technical requirements of the RIPE
Database as a public registry.
Redesigned data model dropping the old fashioned requirement to have
all data stored in untouched text blocks and be human readable. Stored
data should be machine parsable and processable. Tools and interfaces
can be provided to offer information based on the stored data or raw
data for further machine processing.
Accommodate new business models including the acceptance of investors
and commercial RIRs operating below the RIPE NCC.
Interfaces to commercial IPAM systems so all the required data can be
uploaded and synced without human effort.
Expand the LIR Portal to a system of user accounts for anyone who
enters data into the database and identified/verified power users who
consume the data.
Notifications are basically an audit trail of changes to your data.
This should be configured through the user accounts. No need for it to
be spread throughout the entire database at the data set level. There
are millions of attributes with duplicated email addresses all over
the data. This has no public interest value at all and should not be
public data.
We should design a new authorisation and authentication scheme, also
configured through the user accounts. Again details about the security
of your data have no public interest value and should not be public
data. I don't know of any other web based system that publishes so
much information about how you secure and protect your data.
The basic data is composed of hierarchical sets of IP addresses. But
only abuse contacts use inheritance. All contact and management data
should be inherited. That again could remove millions of items of
duplicated, redundant data. Structure of contact and identification
data should also be redesigned with privacy and confidentiality in
mind.
Resource holder and End User name and address details should be
properly formatted rather than free text.
Requirements for user registration details in a public registry could
be re-evaluated and re-designed from the bottom up with a three way
balance of privacy, confidentiality and public interest in mind.
Language and characterisation of data can be re-evaluated for the
whole data set.
Routing data could be better structured with usage in mind. Tools
could be built in to provide the structured data needed by those who
use this data.
Geolocation data could be built in rather than relying on external files.
Basic, anonymous queries could be limited to bare bones data with no
PII. More detailed data could be provided only to verified query
users, with accounts, with different levels of detail.
Historical data could be subject to a one time post processing to
remove PII from public view but still allow anonymised cross
referencing that researchers and investigators can do now with the PII
data.
The whole dataset should be organisation centric. Every piece of data
entered into the database should be directly or indirectly linked to
an organisation described in the dataset. There is no reason to allow
anonymous or orphaned data to be entered.
All changes of this nature could be made independently and gradually
introduced. But we do need a road map based on a bigger picture so we
know where we are heading. Especially for the core changes.
If there is one thing I want you to consider from this message it is this:
id nunc, aliquo tempore postea fit numquam
I am not well know for my language skills so let me say it in English:
do it now, sometime later becomes never
cheers
denis
co-chair DB-WG
1 year, 8 months
Re: [address-policy-wg] 2023-04 Are anonymised assignment objects valid?
by denis walker
Colleagues
I know this is a very long email and no one has the time to read it,
but I have at least put my points on record.
This proposal claims to only be about adding a new, optional status
value. It is claimed it doesn't permit anything else that isn't
already possible with the current address policy. In particular it is
claimed you can already have anonymous assignments in the RIPE
Database. Some people do create such objects. The RIPE NCC audits
don't question such objects. But is that right?
There has been so much false and misleading information about this
issue. I am going to have one last attempt to put the record straight.
Then, if no one else cares, why should I? I have a bathroom to
build...
We are talking about one sentence in the current address policy that
this proposal removes. A sentence that is the heart of assignment
policy. The core of the public registry of public IP addresses. An
English sentence that is so clear and obvious, it simply cannot be
misunderstood or (mis)interpreted. And yet I am having to write an
essay to try to explain what this clear sentence means.
"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."
Let me break it down into smaller segments to explain it's meaning:
'End User has a network' - a network for an End User
'using public address space' - the address space for the network is
part of the public Internet
'must be' - MUST, not can, should, may, possibly, perhaps...MUST
'registered separately' - registered in the RIPE Database in a
separate object, all alone
'contact details' - information that allows you to make contact with
'of the End User' - the End User who you want to contact
This sentence only has one possible meaning. And that meaning says you
cannot have an End User assignment in the RIPE Database that does not
allow you to make contact with the End User (subject to the specified
exceptions). This sentence and meaning are so clear it is impossible
to write it any clearer.
What matters today is the actual wording of the current address
policy. But to understand some of that, we need to look at how we got
here and some of the early definitions that are no longer included in
the policy. So let's start with a history lesson. With my information
archeologist's hat on, I've gone all the way back to 1990 to
understand what the terminology in the address policy and the RIPE
Database means.
In the first version of the address policy ripe-065
RIPE NCC Internet Numbers Registration Procedures
Publication date: 01 Jul 1992
It says:
"This document describes the procedures for the reassignment of IP
network numbers from blocks obtained from the RIPE Network Coordination
Centre."
...
"Full information about reassigned network numbers must be reported
back to the RIPE NCC and the US NIC in full RIPE database format (ref
ripe-13)."
Then in ripe-13
RIPE Databases
Publication date: 28 Aug 1990
It describes the network objects to include these attributes:
-----------
tc -name of technical contact.
This must be the same string as in the corresponding *pn entry.
There must be such a person entry!
ac -name of administrative contact.
This must be the same string as in the corresponding *pn entry.
There must be such a person entry!
de -description of the network.
Give organisation and place.
Postal address and country are not needed, they can be found via the contacts.
The country is given in *cy.
-----------
Then in an example it includes:
-----------
*de: CWI Ethernet (Classical)
*de: Amsterdam
*de: Netherlands
-----------
So right from the start of registration we have had description
attributes giving information about the name and location of the
assignment holder.
Then we move a few hops to ripe-136
European Internet Registry Policies And Procedures
Publication date: 24 May 1996
This is starting to look a bit like modern address policy.
Interestingly it actually defines some of the terms we have lost touch
with over time. If you ask most people now what an admin-c contact is
they don't know. Which is why many objects have the same entry for
both tech-c and admin-c. But that is often wrong.
Some definitions:
End users are those organizations operating networks in which the
address space is used. End users must provide and update registration
data for the address space assigned to them.
Local IRs are typically operated by Internet Service Providers (ISPs).
Local IRs hold allocations of address space for assignment to end
users. In some cases, the local IR assigning the address space is not
run by the ISP that will provide connectivity. It is important to note
that maintenance of the administrative information regarding the
assigned address space is the responsibility of the IR that makes the
assignment, and not of the ISP providing the connectivity.
Requesters - In addition to these key players in the Internet Registry
System, there are often consultants who set up and manage networks for
end users.
netname - a short, but semantically meaningful name
descr - A short description of the organisation that will use the
assigned addresses, in one or more fields. Typically the name of the
organisation.
admin-c - administrative contact persons. The administrative person
specified in the admin-c field must be physically located at the site
of the network.
[Clearly the original definition of the admin contact means it must be
someone at the site of the end user. This, with the descr fields,
identifies and provides contact information for the end user.]
tech-c - technical contact persons. The technical person specified in
the tech-c field may be a network support person located on site, but
could also be a consultant that maintains the network for the
organisation.
Submission of objects to the database is the final and required step
in making an assignment. This step makes the assignment definite, and
makes public information regarding the assignment available to anyone
seeking it.
[Again it is clear from the early days that the public registry was
not only an operators phone book for solving network issues. Maybe
this will bring to an end those endless arguments about whether LEAs
have a right to access and use the information in the RIPE Database.
"available to anyone seeking it"]
>From ripe-140
European Internet Registry Policies and Procedures
Publication date: 06 Sep 1996
Just for further clarity it describes the admin-c of an aut-num object as:
"The administrative contact should be physically located at the
enterprise requesting the AS number."
which further clarifies the difference between the tech-c and admin-c generally.
ripe-159 (29 Jul 1997) adds that the admin-c
"The person does not have to have technical knowledge of the network."
Then we get to ripe-234
IPv4 Address Allocation and Assignment Policies In The RIPE NCC Service Region
Publication date: 14 Jun 2002
This is where we first get the differentiation between DSL connections
and public networks.
"However, four or more addresses (e.g. /30 or more) used on the End
User's network need to be registered separately with the contact
details of the End User."
Almost the exact wording we still use today, 21 years later.
Then ripe-288
IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region
Date: 28 October 2003
We now have the exact wording that we have today (it is even in paragraph 6.2):
"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."
So we have had this principle with the exact same wording for 20
years. Every version of the address policy since then has included
this exact line.
(Incidentally one of the authors of this document was Leo, now
co-chair of this WG)
All these documents have been co-written by many people including the
RIPE NCC founder, RIPE NCC CEO, RIPE chair, RIPE co-chair, AP-WG
co-chair, former DB-WG co-chair, yet we seem to have collectively
forgotten what many of these terms mean.
So now let's come back to the present. How do these definitions change
our perspective? The first thing to note is that these definitions are
no longer written into the policy. They disappeared over 20 years ago.
But, in the absence of any definitions in the current policy, and no
community consensus over that time to change any of these definitions,
it seems reasonable to apply those definitions from earlier versions
of the same policy document. Especially as the database documentation
still makes the clear distinction between a tech-c and an admin-c in
line with those early definitions.
Let's again look at that typical company operating a network with
public address space. They may be technically competent, in which case
the tech-c will provide contact details for their own engineers. If
they don't have the technical skills someone else will manage the
network for them. That could be the LIR, or an ISP (seperate from the
LIR) who provides the connectivity services, or an independent
consultant. Whoever it is, they should be listed as the tech-c contact
person. When it comes to the admin-c, we now know who this is meant to
be. It is someone, with or without technical skills, who is physically
located at the site of the enterprise operating the network. Having
that person's contact details, combined with the descr attributes that
optionally specify the name and location of the organisation, we
satisfy the current policy requirement "registered separately with the
contact details of the End User".
When an LIR manages the network for the End User, to replace both the
tech-c and admin-c with the LIR's contact details is wrong, according
to the current policy. The admin-c should always be a contact from the
End User's site. As many LIRs do get that bit wrong, they often
compensate by adding full name and address details of the End User in
the descr attributes. That makes them still compliant with current
policy as the assignment object still has the contact details of the
End User. There are so many objects in the database like this. If the
labour intensity of maintaining this data is one of the driving forces
behind this proposal, why do so many LIRs put all that optional data
into their objects? That takes a lot of effort. If an assignment is
cancelled then re-assigned to another customer, they have to change
the object to update this optional data. Without the optional data the
same object would still be valid for the next customer without any
update. They do it because they read the policy and understand that
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 knew they must include contact details for the End User.
During this debate it has been said that the contacts are "the tech-c
and admin-c, nothing more, nothing less". That is just wrong. Nothing
in the current or any previous version of the address policy has ever
said that. You cannot just invent conditions like this, out of
nowhere. The descr attributes are contacts. A referenced organisation
object provides contacts. There are other options for contact
information. But the bottom line is, the assignment object MUST
contain the End User's contacts (subject to the specified exceptions).
So it is not policy compliant to have an assignment object that does
not have contact details of the End User. If the RIPE NCC does not
question this during an audit, they have got it wrong. They may have
got it wrong for many years, but it is still wrong. We should not
change the policy just because mistakes have not been corrected for a
long time.
So the answer to the main question is (finally), this proposal makes
significant changes to assignment policy and allows the creation of
anonymised assignment objects that the current policy does not allow.
I will go further than this. If the current policy was correctly
applied, it is not possible to aggregate assignments as they will all
have different admin-c contacts.
That means the question the community needs to consider is if it is
now acceptable to allow anonymised assignment objects in the RIPE
Database, possibly in significant numbers? If this proposal is
accepted and the definition of admin-c is changed to what many people
actually think it is, then the only End Users who will be publicly
contactable are those who manage their own networks. Potentially ALL
others can be anonymised, with or without aggregation.
Now just to finish off I will address the Q&A.
On Tue, 26 Sept 2023 at 15:41, Tore Anderson <tore(a)fud.no> wrote:
>
> Hi Denis,
>
> It would appear to me that your opposition to 2023-04 is largely based
> on the premise that it introduces a new possibility for anonymous
> assignments, a change which you do not want to see happen. This premise
> also appears to underpin many of your musings in your «The bigger
> picture» message.
Then you didn't read it.
> I disagree with this premise, as I believe this
> possibility is already there in 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."
>
> Rather than decide to agree to disagree on that point, or endlessly
> quarrel about it, I realised that it does not really matter what you or
> I believe the policy requirements are - what matters is the RIPE
> NCC's understanding of the policy and how they are implementing it. So
> I simply asked their Policy Officer (Angela) to clarify this.
What matters is are they implementing it correctly?
>
> Her answers, which I with permission quote in full along with my
> questions below, unequivocally confirms that that current policy does
> indeed allow assignments to be registered anonymously in the RIPE
> database. Hence, your opposition to proposal 2023-04 in this regard
> appears to rest on a fundamentally flawed assumption.
"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."
>
>
> Tore: «The context here is an IPv4 assignment that is not made to an
> individual and that is not used solely for the connection of an End
> User to a service provider.
>
> 1. Does current address policy as implemented by the NCC allow an End
> User to delegate/outsource the contact information represented by the
> mandatory "tech-c" and "admin-c" attributes to another entity,
> typically (but not necessarily) the issuing LIR? (There does not appear
> to be any disagreement on this point, but I include this question
> anyway in case we are both wrong.)»
>
> Angela: «Yes, you are correct. An End User is allowed to
> delegate/outsource the contact information represented by the mandatory
> "tech-c" and "admin-c" attributes to another entity, typically (but not
> necessarily) the issuing LIR.»
No it is not correct. The administrative person specified in the
admin-c field must be physically located at the site of the network.
Therefore it cannot be outsourced.
>
> Tore: «2. Assuming "yes" to question 1, for an assignment where the
> "tech-c" and "admin-c" has been delegated in this manner: Does current
> address policy require the corresponding "inetnum" database object to
> contain some additional contact information, that is not delegated to a
> third party, i.e., it must be refer to a point of contact that is
> handled in-house by the End User him/herself?»
>
> Angela: «The current address policy does not require the corresponding
> "inetnum" database object to contain some additional contact
> information that is not delegated to a third party.
> LIRs can use the “netname” attribute to link assignments to end users
> and their contact details in internal records.
"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."
>
> There is a particular case: when the RIPE NCC receives a request for
> assigning an AS number to an End User using a PA assignment, the IPv4
> network to be announced by the requested AS must be registered in an
> “inetnum” object showing the End User’s name. This can be in the
> "descr” attribute or recursively in the "org" object added as
> attribute.»
This does not apply to most of the assignments in the database where
the optional descr attributes have been added with name and address of
the End User
>
> Tore: «3. Assuming "yes" to question 2, what kind of other contact
> information is required, and in which "inetnum" database attribute(s)
> must it be located? Here are some possible examples off the top of my
> head, would any or all of these satisfy the policy requirement for an
> in-house non-delegated contact information?
> 1. A street address
> 2. A (snail) mail address
> 3. An e-mail address
> 4. A fax number
> 5. A phone number»
>
> Angela: «The answer to question 2 was “no’, however one way to record
> End Users’ contact details is to create an “org” object to be added as
> optional attribute in the “inetnum” object.
> In “org” objects name, address and email are mandatory.
> In “inetnum” objects the mandatory contact information are “admin-c”
> and “tech-c”.»
"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."
>
> Tore: «4. Assuming "yes" to question 2, is it mandatory to identify the
> End User by name, or would it be sufficient with, e.g., a street
> address without an organisation name (assuming there is only a single
> entity located at that address), a post box snail mail address, a
> generic user123(a)gmail.com e-mail address, or a phone/fax number that is
> not listed in the white or yellow pages?»
>
> Angela: «The answer to question 2 was “no’,...»
"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."
>
> Tore (in a new e-mail): «I will ask you a couple of follow-up questions
> just to make absolutely, 150%, certain I do not misunderstand you and
> end up misrepresenting you to the mailing list:
>
> 1. When you write «LIRs can use the “netname” attribute to link
> assignments to end users and their contact details in internal
> records», this "can" is a MAY, not a MUST, to use IETF lingo? That
> is, the LIR is free to instead use the "inetnum" attribute, i.e.,
> the IP address(es), to link the assignment to the End User in their
> internal record? If that is the case, would it be correct to say
> that the LIR are free to set the "netname" attribute to essentially
> anything, including a meaningless string of random characters?»
>
> Angela: «Your interpretation is correct, the answer is yes to all
> three questions.
> Please also consider that the "netname" is not required to be
> unique, LIRs can use the same one for multiple assignments.»
>
> Tore: «2. When you write «one way to record End Users’ contact
> details is to create an “org” object to be added as optional
> attribute in the “inetnum” object», this is also a MAY, not a MUST?
> That is, the LIR is free to omit the "org" attribute, even though
> the only other contact information contained in the object is the
> (LIR-delegated) "tech-c" and "admin-c" attributes?»
>
> Angela: «Yes, the LIR is free to omit the "org" attribute, even
> though the only other contact information contained in the object is
> the (LIR-delegated) "tech-c" and "admin-c" attributes.
> If the LIR requests an AS number on behalf of an end user to
> announce a PA assignment, then the PA assignment MUST include the
> legal name of the end user in the "descr" attribute or in the '"org"
> object set as "org" attribute in the "inetnum" object.»
>
"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."
The administrative person specified in the admin-c field must be
physically located at the site of the network.
> Tore: «3. To use a concrete example: Let's say «SuperLIR GmbH»
> delegated 192.0.2.0/25 to the End User «CarFactory GmbH».
> (CarFactory GmbH is not an individual, and the assignment is not
> used solely for the connection to the provider, nor to justify an
> application for an AS number). SuperLIR inserts the following
> minimal database object:
>
> inetnum: 192.0.2.0 - 192.0.2.128
> netname: ABCDEFGHIJKLMNOPQRSTUVWXYZ
> country: DE
> admin-c: SUPERLIR-NOC-RIPE
> tech-c: SUPERLIR-NOC-RIPE
> status: ASSIGNED PA
> mnt-by: SUPERLIR-MNT
> source: RIPE
>
> In the event of an audit, SuperLIR GmbH will be able to inform the
> RIPE NCC auditors that this object has been delegated to CarFactory
> GmbH.
>
> Is the above registration compliant with current IPv4 address
> policy, or will the auditors demand any kind of changes be made?»
>
> Angela: «The above registration compliant with current IPv4 address
> policy. During an audit we could ask the LIR whether the assignment
> is still in use. It does not matter for the RIPE NCC who is using
> the assignment, as long as the LIR is maintaining the registration
> up to date and is able to contact the end user. This means that if
> the LIR moves the assignment delegation from CarFactory GmbH to
> another end user in the same country for which is acting as "admin-
> c" and "tech-c", the "inetnum" object would still be valid. It is
> the LIR's responsibility to keep their internal records up to date
> accordingly with the new end user.»
"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."
The above object is not compliant and the audit should pick that up
>
>
> In light of the above, I hope that you will reconsider your opposing
> arguments and either withdraw them or restate them in a way that does
> not rely on this incorrect assumption. Anticipating this, I will only
> address your remaining points that are not based on the
> misunderstanding that 2023-04 opens up for anonymous assignments.
>
My assumption is correct.
cheers
denis
co-chair DB-WG
1 year, 8 months
Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Tore Anderson
Hi Denis,
> This is where the implications get interesting. Each of the objects
> in the example I gave is in itself individually aggregatable. There
> is nothing in your policy proposal that says an aggregate must cover
> multiple assignments to multiple End Users. You say:
> "In case of an audit, the LIR must be able to present statistics
> showing the number of individual assignments made in all objects with
> a status of 'AGGREGATED-BY-LIR."
Yes, this requirement is copied verbatim from the IPv6 policy.
> So the number 1 is valid. You don't require the block size of the
> individual assignments to be specified in the audit. So that 1 could
> be the same size as the aggregate or a single IP address.
Correct, just as in the IPv6 policy. Though I fail to see the point in
"aggregating" only a single assignment.
> For every one of the assignments in this example allocation you can
> change the status to AGGREGATED-BY-LIR and remove all the
> identification and contact information for the actual end user. Your
> proposal has dropped the requirement:
> "When an End User has a network using public address space this must
> be registered separately with the contact details of the End User."
Correct, as we are copying the wording from the IPv6 policy, which does
not contain that specific sentence.
> It is not specified in the current policy if those contact details
> must be the tech-c/admin-c or the address of the company. So the
> objects in my example comply with the current policy.
We might have to agree to disagree on this one, but to me it seems
clear that the mandatory contact details referred to by policy *are*
admin-c and tech-c, nothing more, nothing less. This follows from the
inetnum object template, where admin-c/tech-c are the only mandatory
attributes that relates to contact information.
In your examples, the LIR included street addresses of the assignees in
the unstructured descr fields. This is essentially useless for trying
to get in touch with someone about solving operational problems - I
mean, when was the last time you physically travelled to someone's
office or sent them snailmail in order to troubleshoot a network issue?
When reading the requirement to register the End User's contact details
with the goal of registration stated in section 3.0.4 of the policy in
mind - «to ensure uniqueness and **to provide information for Internet
troubleshooting at all levels**» (emphasis mine) - it seems clear to me
that the mandatory contact information referred to by policy must be
more immediate and long-distance forms of contact, such as 'phone' in a
person object or 'e-mail' from a role object. These are mandatory
attributes, and can be used as tech-c/admin-c in inetnum objects, which
are also mandatory.
Thus, the registration goal and requirement in the policy and the chain
of mandatory attributes in the RIPE database ties together very nicely
in a structured, machine-readable and logical way:
inet[6]num→tech/admin-c→person→phone, alternatively:
inet[6]num→tech/admin-c→role→e-mail.
> With the current policy only when an End User is a natural person can
> you replace the contact details with that of the LIR. With your
> policy ANY or even ALL End Users can replace their contact details
> with that of the LIR by changing the status to AGGREGATED-BY-LIR. In
> theory every ASSIGNED PA object in the RIPE Database can become an
> AGGREGATED-BY-LIR object with only LIR contact details. Now that
> won't happen as a lot of responsible End Users will want their
> contact details in the database for network problem resolution.
Well, it depends. Is the LIR' NOC the correct point of contact for
network problem resolution, i.e., is there already a single value used
for tech-c and admin-c across a set of adjacent assignments?
If yes, then the LIR could aggregate those objects.
If no, e.g., if the End Users operate their own NOCs, then those
objects can not be aggregated.
This is of course all the same as in the IPv6 policy today.
> But we all know there are LIRs who provide services to spammers and
> othe abusers, knowingly or otherwise. You can be sure these End
> Users' details will disappear from the database.
Are you certain that updated and working contact information of
spammers and abusers are correctly registered in the RIPE database
today? (Rhetorical question, no answer sought.)
> > Thus the LIR in question already has a 'short cut' option available
> > to them, should they feel managing the assignees' address
> > information in the RIPE database is too burdensome - they can
> > simply chose to not include that information in the first place.
> >
> > I want to emphasise that this policy proposal does not grant them
> > this option, it is already there today.
>
> This again is misleading. The LIR CANNOT do what you suggest with the
> current policy. The current policy says:
> "When an End User has a network using public address space this must
> be registered separately with the contact details of the End User."
> As I said above, It is not specified if those contact details must be
> the tech-c/admin-c or the address of the company. In the example I
> gave the admin-c/tech-c are the details of the LIR. But they comply
> with the policy by including the address of the companies. They are
> the End User contact details. If they chose to remove this optional
> information then they no longer comply with current policy. But you
> drop this policy condition. Therefore with your policy proposal you
> allow them to remove this optional info and still comply with the
> policy. Netname is just a string of LIR defined characters and does
> not need to be unique. So they can all be set to the same string.
> Country is also LIR defined and generally meaningless so they can all
> be set to the same pointless value. So your proposal allows this LIR
> to make all these assignments 'the same' and replace them all with a
> single AGGREGATED-BY-LIR object. This is a very significant change to
> the public registry. With this proposal ANY set of data can be
> anonymised. There is no longer any requirement for End Users running
> public networks to be identifiable or contactable.
>
> This IS an option granted by this proposal that is NOT there today.
Here are three randomly selected assignments that demonstrates how this
option is there today:
inetnum: 213.174.234.0 - 213.174.234.31
inetnum: 62.213.192.208 - 62.213.192.223
inetnum: 213.162.203.0 - 213.162.203.255
All of them have netnames à la «LIRNAME-CUSTOMER-NUMBER-1234», strongly
suggesting this is a downstream assignment to a specific customer and
not made to the LIRs own infrastructure or DHCP pools, and the only
thing resembling contact information are the admin-c and tech-c
attributes, which refer to the LIR itself.
> I can see a follow up question to the DB-WG, "How do I aggregate a
> whole allocation?" Which may well replace the current question, "How
> do I assign a whole allocation?" The consequence of this proposal is
> the same as a previous suggestion to make assignments optional. Both
> allow for the mass anonymisation of End Users.
This possibility, as demonstrated above, is already there today - both
in the IPv4 and IPv6 policies.
> Are you suggesting that abusers generally work with single IP
> addresses, rather than cycling through a block of addresses?
Not really, but I would rather suggest that spammers and abusers are
not likely to faithfully and correctly publish their assignments and
contact information in the RIPE database in the first place.
If you are building your anti-spam/abuse methodology on the assumption
that otherwise bad actors are behaving as good actors when it comes to
maintaining the RIPE database, I don't think that methodology would
work very well.
>From the proposal: «As of August 2023, there were 19,221 PA allocations
without any child PA assignments held by 10,052 LIRs». What do you do,
exactly, if you start receiving abusive traffic from any of these
ranges?
> > Note that this is not really much different than what you have to
> > do today for abuse coming from customer assignments that are
> > «registered as part of the service provider's internal
> > infrastructure», cf. ripe-708 section 6.2.
>
> Just a note that ripe-708 was the address policy of 2018. There have
> been 5 updates since then.
My mistake, a Google-snafu there. That particular sentence is unchanged
as of ripe-804, though, so the points stands.
> > That said, AGGREGATED-BY-LIR would here have made it
> > clear that the abusive address is indeed assigned to a downstream
> > customer and is not part of the service provider's internal
> > infrastructure.
>
> Take a look at these two examples of real data:
> 82.116.118.0 - 82.116.119.255
> 88.149.40.0 - 88.149.40.255
>
> One is listed in a remarks as "dynamic DSL address pool" and the
> other as "DHCP Customers". They are already aggregated. What do we
> gain by changing the status on these objects from ASSIGNED PA to
> AGGREGATED-BY-LIR? Suppose one LIR changes the status and the other
> does not. As you said it is optional. Nothing changes for either LIR
> in terms of what they must create, modify or delete in the database.
> They are already aggregates. What can a casual viewer of this data in
> the database deduce from these two new objects with different status
> values? Without parsing the remarks they cannot deduce anything.
> Either could be a single End User or multiple End Users. The status
> doesn't distinguish either option. Why do we need a new status value?
> We end up with two values that are completely interchangeable with no
> way to interpret their different meanings without parsing remarks.
If you are a machine, and not a human, free-text remarks such as
"dynamic DSL address pool" are essentially meaningless. They are
optional too, the LIRs could easily have omitted them. If they had, it
would have impossible to tell whether those addresses had been assigned
to one or more downstream customers or if they had been assigned to the
LIR itself.
Furthermore, there is a chance that at least one of the customers in
those pools are using his or her assigned address for some purpose like
running a MineCraft server, let's say. If, so, that single IP customer
assignment is no longer «used solely for the connection of an End User
to a service provider» and would need to registered as a separate
assignment.
Everybody ignores that requirement, of course, because otherwise the
result would have been complete and utter mayhem. Nevertheless, it is a
de jure policy violation. AGGREGATED-BY-LIR solves that.
> The bottom line is that this new status value adds no new benefit,
> but can be seriously mis-used to cause considerable damage to the
> RIPE Database as a public registry. It WILL be misused by those
> operating public networks who wish to keep their details hidden from
> public view.
We do not propose to do anything that hasn't already been done in the
IPv6 policy and database for years and years and years, and the sky has
not fallen. The End Users that want anonymity for whatever reason have
ample opportunity to remain anonymous today, even while staying policy
compliant (not that bad actors would care about that).
Finally, there *is* a benefit to this proposal, an actual itch we're
trying to scratch, specifically where there are many identical small
assignments being made and removed in a rapid and automated fashion, to
End Users that don't operate their own NOCs. I've mentioned the cloud
VPS provider example before here.
Tore
1 year, 8 months
Re: 2024-02 Review Phase (IPv6 Initial Allocations /28)
by Jeroen Massar
Hola,
Sounds to me that 91% of the prefixes could previously not justify that they needed more space.
Checking a nice tool like https://bgp.tools to see how many hosts are actually active give a good indicator per prefix how that is the case.
The LIR vs Member part also makes this a lot more work for the NCC.
On top of that though there seem to be many LIRs setup for 'companies', that then after the time has passed are merged with other similar ones. One can already see many ASNs with multiple (in some cases 20+!) /32s from a single ASN and often a related (eg upstream or side-ASN under that same upstream) with the same name/description of the /32 or bigger (depending on when they registered).
As such, of those 91% that could 'grow' to a /28, how many will suddenly take more space and upgrade it. RIPE NCC cannot say which companies are the same 'member', thus all would be valid.
As the text says itself: "Note that the 91% is calculated including presumable stock-pilers."
(no idea why people are trying to stock pile IPv6 prefixes.... there is soooo much of it...)
Please let people justify their needs, even if lightly. Being able to show that you have more than 2^(48-29) customers, or even close to that and that your currently used address space is 'well used' should not be tricky, it means that you will have a LOT of customer Atlas probes in your network ;)
Yes, there is "enough", and yes, if we cock up this first 2000::/3 we can do that problem another 5 times. But when that was worded, some 20+ years ago, the initial allocations were /32, not /29 let alone /28. And indeed, most of those /32s can be upgraded in the same slot to a /26.
Any LIR that needs 'more space' can grow that upto the /26 by filing the paper work, in the same routing slot. Many will chose (as can be checked in current routing tables) to separately announce a /29 as multiple /32s though, thus a /28 will take 16 slots. Thus if routing slots is the concern, then one should justify the need for that space.
Considering that only a few have done so, either says nobody really needs it; or that the process is to tricky (if the latter, which the NCC can say if that is the case of how many attempts have failed and thus a ratio of rejected/allowed) then that needs to be adjusted.
And checking the 'very large ASNs' they already get big and often multiple allocations from multiple RIRs and... they can justify it easily (they also have the #hosts or customers to do so).
Thus for which people is this policy change meant:
- it does not seem to help workload in NCC: 15k+ could then 'freely' request upgrade without justification or actual need.
- it does not help the few that can actually justify it: they already did
Thus, why bother going with this change?
I think it would be better for the NCC to spend time on validating that the "company" behind an LIR is a real entity, and not just another incarnation of another company. The routing tables tell us quite adifferent story where address space is "used" and how it is used...
Regards,
Jeroen
> On 13 May 2025, at 10:38, Angela Dall'Ara <adallara(a)ripe.net> wrote:
>
> Dear colleagues,
>
> Policy proposal 2024-02, "IPv6 Initial Allocations /28 ", is now in the Review Phase.
>
> This proposal aims to change the initial IPv6 allocation size from /29 to /28 and allow one IPv6 allocation extension per member to /28 without justification.
>
> This proposal has been updated and it is now at version 3.0. The main difference from version 2.0 is that one IPv6 allocation extension up to /28 without justification is allowed per member instead of per LIR.
>
> The RIPE NCC has prepared an impact analysis on this proposal to support the community’s discussion.
>
> You can find the proposal and impact analysis at:
> https://www.ripe.net/community/policies/proposals/2024-02/
> https://www.ripe.net/participate/policies/proposals/2024-02#impact-analysis
> And the draft document at:
> https://www.ripe.net/participate/policies/proposals/2023-04/draft
>
> As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue the discussion of the proposal taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.
>
> At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus.
> It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.
>
> We encourage you to read the proposal, impact analysis and draft document and to send any comments to address-policy-wg(a)ripe.net before 11 June 2025.
>
> Kind regards,
> Angela Dall'Ara
> Policy Officer
> RIPE NCC
>
> -----
> To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/
> As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
3 weeks, 4 days