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 <[email protected]> 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
