Hi Denis, We have read through your message several times, but do not see any new arguments against proposal 2023-04 that have not already been discussed at length in the previous phases of the policy development process.
The main purpose of the Concluding phase is to provide an opportunity for people who have missed the previous two phases to oppose the proposal (see ripe-781), not to rehash discussions from the previous phases. Therefore, rather than repeat our answers in this thread, we chose to simply refer you back to our previous discussions in the previous two phases. Best regards, Jeroen & Tore > Op 5 apr 2024, om 16:51 heeft denis walker <ripede...@gmail.com> het volgende > geschreven: > > 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 <l...@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 > > -- > > 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 -- 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
