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

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-policies-and-ripe-ncc-procedures

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 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://mailman.ripe.net/