[address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
- Previous message (by thread): [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
- Next message (by thread): [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Carlos Friaças
cfriacas at fccn.pt
Fri Apr 5 17:30:42 CEST 2024
Greetings, After reading your message, i had to go search if i expressed an opinion on 2023-04 or not. It seems i did (back in September), but perhaps i wasn't 100% clear about my opposition to this proposal. So in order to make it clear for the co-chairs, i do oppose this proposal, on the grounds that the quality of publicly available registration data is likely to decrease if this proposal is approved. Best Regards, Carlos On Fri, 5 Apr 2024, 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 at 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 >
- Previous message (by thread): [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
- Next message (by thread): [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]