[address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status

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
>