Hello, First, let me note that this is not a comment on the policy discussion, which has now concluded, but a separate response regarding how we ensure compliance with RIPE Policy. We would like to clarify some aspects that may be unclear to the community. The RIPE NCC has always emphasised the importance of documenting networks through assignments, and we are consistent in what we consider valid contact information for End User/customer assignments. This stance has not changed because of IPv4 runout. We do consider the member’s contact details to be valid contact information for the customer if this is what the member and their customer have agreed suits their business needs. There are a number of policies we follow for ensuring correct contact information. The policy on IPv4 allocation, RIPE-804, requires that contact information in the database must be correct [1]. The same policy also mentions that an LIR can be closed if it “consistently violates the RIPE community’s policies” [2]. We build on this in our public closure procedure, where we state that incorrect registration in the RIPE Database can lead to termination of a membership [3]. Together, this means the RIPE NCC is empowered to close down a member for incorrect contact information in the database, and this includes incorrect data about a member’s customers. When we discover incorrect information, our practice is to follow a collaborative approach in which we help our members correct the errors. This is in line with our overall mission to support the broader Internet community, not through punitive measures, but through educating members in our processes for requests, ARCs and training courses so that we can collectively work to create an accurate registry. See also our impact analysis for policy proposal 2017-02 (“Regular abuse-c Validation”) for a detailed description of how we work with resource holders to correct information before considering closure, in this case regarding “abuse-c:” contacts [4]. We do not consider it beneficial to the Internet community or our members to immediately terminate memberships. However, if a member submits repeated and intentionally incorrect contact information, this will result in stronger actions on our end. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC [1] IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region: https://www.ripe.net/publications/docs/ripe-804/#4 [2] Idem: https://www.ripe.net/publications/docs/ripe-804/#9 [3] Closure of Members, Deregistration of Internet Resources and Legacy Internet Resources: https://www.ripe.net/publications/docs/ripe-808/#a1211c [4] Regular abuse-c Validation: https://www.ripe.net/membership/policies/proposals/2017-02/#relevant-ripe-po... On 05/04/2024 16:51, denis walker wrote:
Colleagues
I am not surprised this policy proposal (2023-04) has gone to last call. I expected this from the start, no matter what anyone said. And I won't be surprised when it is approved. I used to wonder why no one would even talk about bringing the RIPE Database into the modern world. Why continue to use an ancient, broken tool that is barely fit for purpose? It is quite obvious now. Playing on the complexity and difficulties with using the database allows people to justify changing the purpose and the rules, to make it more convenient. That is simpler and cheaper than fixing the tool. It is easy for a small vocal group to sell 'simple and cheap' to a silent majority. Convenience is easier to do than right. But it may have consequences.
The proposers have assured us all that this proposal is about nothing more than introducing this optional, minor, inconsequential feature that changes nothing. They have argued that the RIPE NCC has "repeatedly" verified their claim that this proposal changes nothing 'of significance'. This is based on the RIPE NCC legal team's confusing impact analysis and the comments made once and referred to once by the RIPE NCC Registration Services through messages passed on by the policy officer. The legal team declined to clarify the confusing wording of their impact analysis. No one from Registration Services was willing to discuss the claims that they have been wrongly applying the policy for a number of years, or the reason why and when they stopped correctly applying the policy. I thought RIPE NCC staff were being encouraged to be more involved in community discussions?
It has been said and confirmed recently by several people from the community that we no longer understand what some of the registration data in the RIPE Database means, why it is there and why we have these rules about it. This is despite the actual, current wording of these rules having been written into a version of the policy published in October 2003 that was authored by some people who are still leading members of this community, and at the time were RIPE NCC staff. The infamous line being removed by this proposal was a re-wording of earlier rules introduced in address policy with a long list of early authors, again including some people who are still leading members of this community. I asked if any one of these community leaders would offer some background information to the community on this, now poorly understood, registration data and the rules governing it. That may have helped with our current understanding. If we actually understood the data and rules that we are about to change, we might have more confidence in doing so. But nothing was said on this background.
Europol has expressed serious concerns about these changes. They have stated that it takes time for them to consult with national LEAs, the EU commision and other partners. If someone had informed them earlier of the changes being considered that may affect them, they may have had sufficient time to do these consultations. Or perhaps they would have been able to express their deep concerns at an early stage, before the minds of the vocal few were made up. I did suggest early on in the discussion that the RIPE NCC contacts stakeholders of the RIPE Database and invite them to join the discussion. I was quickly told by other community members on the mailing list that this was not part of the policy development process. [Maybe it should be...]
It is extraordinary that we have now reached a position where the convenience of a handful of vocal operators in this community is considered so important that we must proceed with all haste to introduce this optional, minor, inconsequential feature that changes nothing, without delay. That is without even a delay to allow Europol to complete it's consultations and report back to the working group. I saw references recently on the ripe.net website and LinkedIn about some productive meeting between the RIPE NCC and some internet governance groups. I hope the attitude of the technical community over this proposal won't undermine those meeting achievements. A technical community that clearly has not watched John Curran's keynote speech at NANOG that covers this very situation involving internet governance, the technical community and civil society. I would advise you all to watch it: https://www.youtube.com/watch?v=U1Ip39Qv-Zk
You may question my comments about the vocal few. But the details of the who and how many are there for everyone to see in the public archive of these mailing lists. Only 22 people commented during the months of discussion over 2023-04. Of those, 6 people only made one comment and another 6 only two comments. Some of those 22 also opposed this proposal. So the number of people who actually expressed support is quite small. When you analyse these details for proposals across multiple WGs in recent years, and cross reference the who and how many, you see that there is a very small number of vocal people who tend to dominate these discussions. It is basically this small group of people whose voices dictate RIPE policy. The problem there is that we may find policy, accidentally or intentionally, following an agenda that suits the needs of these people, rather than the wider, silent community. Unfortunately, we don't have any other way to do this at the moment. However, when a change is controversial, has many serious objections and offers so few benefits, to push it through with so few supporters is very questionable. Especially as it has been well established during the long discussions that we (collectively) do not even understand the registration data and governing rules that we are about to substantially change. Nor do we have any firm evidence that even the minor benefits claimed by the proposers are likely to occur.
I could go on and dispute the co-chairs' reasoning for declaring a rough consensus. But I have said it all before and it has been disregarded. Although I don't believe I have yet asked them for the evidence or statistical reasoning why they assert that this change will encourage those who don't declare any End User data now, will suddenly decide to provide it after this change.
It is of course total nonsense to suggest that this change will end up offering more accurate data on assignments to End Users. It is quite possible that those resource holders that currently don't declare End User assignment data now, will simply create two appropriately sized, anonymous, aggregated objects below each of their allocations. That is 'job done' as far as operations is concerned. Those objects will never need to be updated again. No one has any clue how much, if any, of that address space is in use, by how many End Users with how many addresses each, or who the End Users are, or even if the same block of address space has been assigned to more than one End User by mistake. All that information will be lost. Including one of the basic functions of the registry, to ensure uniqueness of address usage.
Quoting statistics on the number of allocations with no assignments is of course simply playing with numbers. It adds nothing to this discussion, but is intended to look like a supporting argument. A perceived problem that needs to be solved, but may not even exist on the implied scale. We don't know how many of those allocations are the /22 and /24 allocations made during the final stages of runout. These were 'intended' to be for new entrants into the industry who planned to provide LIR services. They would not be expected to have assignments if they were used for their infrastructure. (Or maybe they were not allocated as intended?) Many allocations are also made to organisations who do not provide LIR services and have no End Users. The address space is simply used by their organisation.
Leo's final comment is a good one to end on. "Those LIRs that want to share data are already doing so. Those who would like to share some data if it were easier to do so will be accommodated if this proposal becomes policy." This basically sums up everything. ['want' 'like'] The RIPE NCC stopped enforcing address policy after runout because they did not believe they had any power to do so. Here Leo is suggesting that complying with policy is a choice. Some LIRs will choose to comply, others will choose not to comply with RIPE policy. Neither this community nor the RIPE NCC has any power to enforce any policy on operators. We can agree or disagree on any policy we like, but it cannot be enforced. RIPE policy has no teeth.
The proposers have assured us that their focus is on providing this aggregation feature. So we must be able to assume that they, and the co-chairs, have deeply considered the implications of this change to the "status:'' attribute. So there shouldn't be any unintended consequences...
Hopefully common sense will prevail and we will pause this process to assess where we have been, where we are and where we are going. (I think that is unlikely to happen...)
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. ========================================================
On Mon, 11 Mar 2024 at 09:30, Leo Vegoda <leo@vegoda.org> wrote:
Dear Address Policy WG,
There was a consensus on this proposal and we are moving it forward to Last Call. The RIPE NCC will publish an announcement with dates.
There was a request, in Rome, for clarity over whether aggregated assignments needed to have a fixed size or could vary. The proposers suggested that a fixed size should be optional.
We extended the list discussion by a month and the two issues raised have been addressed.
One was End User sites not having the End User's own admin-c instead of the LIR's. There has been extensive discussion of this. One key reason given is that it is common and acceptable to outsource a part of an organisation's operations to another, more skilled, operator. The RIPE NCC's impact analysis noted that the proposal "simply leaves the status quo unchanged." It would not need to update its operational processes.
Concerns were also raised that aggregating assignments would impact criminal investigations. But this proposal is intended to improve the quality of data registered by offering LIRs a less arduous way to share registration data. At the end of 2023 there were over 19,000 PA allocations without any assignments. Those LIRs that want to share data are already doing so. Those who would like to share some data if it were easier to do so will be accommodated if this proposal becomes policy.
Kind regards,
Leo Vegoda, for the Address Policy WG co-chairs
--
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