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

Colleagues

I wasn't going to say anything else on this issue for now. BUT there
has been so much false and mis-information put out today I cannot
leave that unanswered, as the last word on this topic. Also people
need to understand what this discussion over the last 6 months has
done.

On Mon, 8 Apr 2024 at 14:38, Tore Anderson <tore at fud.no> wrote:
>
> * Brian Storey:
> > There is a subtly here which I don't think is fully appreciated.
> >
> > I previously highlighted my surprise to the RIPE NNCs interpretation
> > of the existing policy; as have others. Why is that? I think it's very
> > important to recognise that LIRs act and publish certain End User data
> > because it was deemed that this was a requirement and that not doing
> > so could see a breach of policy, therefore leading to Allocated PAs
> > being reclaimed - not good with scarce resources! They did this
> > because they understood they HAD to not because they WANTED to.
> >

You are right Brian. It IS still a requirement, but as we have
learned, it has not been enforced by the RIPE NCC for about 10 years.
The ONLY way the RIPE NCC could enforce this is the nuclear
option...reclaim address space and close an LIR. Could you imagine the
RIPE NCC doing that to a large and powerful LIR? There would be an
immediate legal challenge and ensuing court case. I have often
commented on the state of RIPE documents. Many of them are poorly
written, have contradictions within them and conflicts between
documents in a linked set. So many things are not defined ANYWHERE.
Many of these documents are open to interpretation. That leads to a
litigation nightmare and is great news for lawyers and barristers who
can spend days in court arguing over the precise meaning of a
document. I would not want to go to court building a defence on this
document set. Obviously, neither does the RIPE NCC, as they have
failed to enforce policy, as mandated, for 10 years. If the RIPE NCC
was to lose the first legal challenge that would set a legal
precedent. At that point you can tear up all RIPE policies. (But maybe
you can do that anyway...read on.)

> > If this school of thought no longer applies, then it is reasonable to
> > expect that some will reevaluate how much effort they continue to put
> > in and the consequences of that.
>
> Hi Brian,
>
> We have certainly no difficulty understanding that you and others might
> have not been aware of this before. But now you are, and so is anyone
> else that are following the RIPE policy development process. The cat is
> out of the bag, so to speak. Withdrawing 2023-04 would not undo this,
> because this is not a property of the proposal itself, but knowledge of
> the of the RIPE NCC's interpretation of the *current* address policy.
>

Tore you are absolutely right, the cat is out of the bag...but which
cat? You seem fine about how the RIPE NCC has been mis-interpreting
policy for 10 years and how they have no power to enforce it other
than the nuclear option, which we all know they will not use. The
revelations from this discussion have completely changed the landscape
for RIPE policy. It has been totally undermined. I agree that
wirdrawing 2023-04 now makes no difference. The damage is already done
and there is no way back. The final decision on 2023-04 is now
irrelevant. When the reality of what has been said really sinks in, it
may be devastating for RIPE policy and the RIPE Database as a public
registry. More on that later...

> Or as the working group chairs put it:
>
> «It is fact that the RIPE NCC has interpreted the current policy to not
> require a PA Assignment in the RIPE DB to include the actual name and
> email address of the end-user since at leas the late 1990s. Registering
> a PA Assignment with something like "CUSTOMER-1234" and an email address
> pointing to the LIR has been acceptable for all this time.»

This is just unbelievable nonsense. One of the chairs, Leo, knows this
for sure as he was responsible for this. Let's consider the real facts
here. Consider that infamous policy statement:
"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."
This exact statement was written into the address policy published in
October 2003. The authors were 4 RIPE NCC staff members. These
included Leo, at the time he was the operations manager of
Registration Services (RS), and Paul Rendek, the senior manager
responsible for RS. This statement was a re-write of rules that had
been in place for many years. Now anyone who has written specs or
regulations knows that, if you change the wording of a rule, you need
to understand what it means so you get the new wording correct. So in
2003 we have the RS manager and senior manager writing the address
policy and really understanding what these rules actually mean. There
was no misunderstanding or misinterpretation then. I will not believe
anyone who tries to tell me now that the manager and senior manager
responsible for RS, having just written the address policy containing
this rule, did not enforce it in 2003. In fact I know from talking to
ex RS staff that it was enforced until runout. So it is about 10 years
since the RIPE NCC decided it no longer had any power to enforce
policy. To say the RIPE NCC interpreted the policy wrongly since the
late 1990s is simply NOT TRUE. This gives a very different view on
when the policy was enforced and when and why it stopped being
enforced.

>
> Furthermore, it is clear that this comes as no surprise at all to many
> LIRs, who have done this for a long time. Again quoting the working
> group chairs:

Many LIRs who have been in violation of policy for a long time, who
know they are in violation. Who will all suddenly become policy
compliant again if this proposal is accepted, and they know that.

>
> «…changing this interpretation would be a major departure of many years
> of accepted practice and potentially involve updating thousands of RIPE
> DB objects»

This practice has never been 'accepted'. It has never even been
discussed in detail until now. The RIPE NCC never came to the
community and said they can no longer enforce the current policy, what
should we do?

>
> https://www.ripe.net/ripe/mail/archives/address-policy-wg/2024-January/013980.html
>
>
> > The two questions I previously posed here:
> > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013863.html
> > were:-
> >
> > "For me it comes down to this. As a community & considering the permitted
> > exceptions (individuals & P2P assignments):-
> >
> > 1) Is the publication of End User entities for an assignment important?
>
> Perhaps, perhaps not. That is for the working group to decide. It is
> however outside the scope of 2023-04. Again quoting the working group
> chairs from the previously linked-to message:
>
> «…we feel this discussion would be best served by an independent policy
> proposal that clarifies the issue and would like to invite the working
> group to enter one».

To approve a policy now that allows End User details to be deleted,
then consider a proposal that requires End User details to be
published, makes no sense. But then none of this makes any sense.

>
> > Now, I've not commented since (for various reasons), however I have
> > followed the discussion of this closely. Internally, I've been
> > highlighting that a Business Risk item based on previous
> > interpretation could evolve and how we manage our exposure changes if
> > this proposal become policy. What this means in reality is that we can
> > choose how much effort we continue to place on updating our
> > Assignments as the end user customer base churns. There are end
> > customers who like their association to a PA Assignment to be
> > published and there are those who don't. It may well be easier for me
> > only publish by exception. I'm still thinking it through pending what
> > happens next with a few other indirect considerations.
> >
> > I don't believe I'll be the only one doing this.
>
> You and everyone else can do this right now. You do not need to wait for
> the possible acceptance of 2023-04. As mentioned above, you have in fact
> been free to do this «since at leas [sic] the late 1990s».

You are not free to do this now and haven't been for a very long time.
But that hasn't stopped many people from doing it in violation of
policy.

On Mon, 8 Apr 2024 at 15:53, Tore Anderson <tore at fud.no> wrote:
> Below you will find an example of a complete inetnum object representing an
> assignment to the End User «CarFactory GmbH» by the LIR «SuperLIR GmbH»,
> which RIPE NCC explicitly confirmed to be compliant with current address
> policy (see

Which we all now know is a misinterpretation of current policy and is wrong.

> https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013856.html):
>
>     inetnum:  192.0.2.0 - 192.0.2.128
>     netname:  ABCDEFGHIJKLMNOPQRSTUVWXYZ
>     country:  DE
>     admin-c:  SUPERLIR-NOC-RIPE
>     tech-c:   SUPERLIR-NOC-RIPE
>     status:   ASSIGNED PA
>     mnt-by:   SUPERLIR-MNT
>     source:   RIPE
>
> If you, or anyone else, want to "minimise" your assignments as shown in
> the above example, you can do so already today. It is already considered
> accepted practice and has been for decades. 2023-04's fate is totally
> irrelevant as to whether or not you or any other LIR can adopt this
> practice, assuming you want to.

Very few people actually consider this to be 'accepted' practice.

On Mon, 8 Apr 2024 at 10:10, Jeroen Lauwers <jlauwers at a2b-internet.com> wrote:
>
> Hi Emmanuel,
>
> > The matter is the loss of opportunities of identification that will vanish for investigators...
>
>
> This is a subject that has been covered extensively during the previous two phases of the policy development process and is as such is already addressed, but we will summarise the main points below for your convenience.

addressed by dismissal

>
> During the previous discussion of 2023-04 it has been made adamantly clear by the RIPE NCC that any information inserted into the RIPE database that identifies the End User is inserted voluntarily by the LIR. There exists no policy requirement that compels LIRs to publish the identities of their End Users, this is simply an option that some LIRs avail themselves of.

Totally untrue. Totally false.
Most LIRs actually do understand the current policy. They are aware
that the policy requires an assignment to include contact details of
the End User organisation. In many cases that is taken to mean the
email address referenced via the "admin-c:" attribute. Where the LIR
handles the tech issues for the End User it has become common practice
to replace both the tech-c and admin-c with the LIR's contact details.
When this is done, many LIRs then add the End User name and address
into the optional "descr:" attributes. Just because this is an
optional attribute does not mean the data it contains is optional.
Name and address is one format for contact details. If the LIR has
replaced the tech-c and admin-c in the assignment with their own
details, they remain policy compliant by adding the required End User
contact details (name and address) in the optional descr attributes. I
am sure most LIRs do not do this extra administration because they
enjoy the extra workload of voluntarily providing additional
information that is not required by policy.

>
> It is important to realize that the policy proposed by 2023-04 does not in any way whatsoever restrict or prohibit LIRs from voluntarily publishing the identities of their End Users in the RIPE database. LIRs that have a policy to do so today, will be able to continue to do so in the future in the exact same way after 2023-04 is implemented. Indeed, these LIRs are free to ignore 2023-04 completely – 2023-04 does not deprecate or remove the ASSIGNED PA inetnum status, it may still be used as before.

It DOES remove the policy requirement to provide a contact with the
End User in ALL cases. So even a small LIR has no fear of being in
violation of address policy and the NCC using the nuclear option on
them. NO ONE will be required to provide ANY contact with the End User
within the RIPE Database.

>
> It follows logically that 2023-04 does not cause any loss of End User identification. Investigators may continue to look up IP addresses in the RIPE database, but whether or not it will yield the End User's identity (as opposed to «a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR», as the working group chairs put it) will depend entirely on the issuing LIR's policies and procedures, just as it does under today.

NO NO NO
2023-04 allows for the complete removal of any End User contact
details whether there is an assignment object or not. You are
specifically removing the infamous line that requires a way to contact
the End User. This is a policy violation today, which some LIRs ignore
with impunity.

>
> For a demonstration of this taking place in practice, take a look at the IPv6 part of the RIPE database. The AGGREGATED-BY-LIR status has been available for inet6num objects since forever, but this has not prevented LIRs from to registering their End User assignments using the ASSIGNED status instead, often including the End User's identity, contact information, and other optional details. There is no reason to expect that this will be any different in IPv4 following the implementation of 2023-04, as we see it.
>

Conclusion
Now let's conclude with the more serious aspects of what has happened
in the last 6 months. The co-chairs of the Address Policy Working
Group have declared that address policy is optional. LIRs can choose
if they want to comply with it or they don't want to comply with it.
The chairs said:
"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 regarding policy. ['want' 'like'].
If you don't want, don't like, just don't do. The chairs seem to be
fine with this. The RIPE NCC has shown by it's actions over the last
10 years that it will not use the nuclear option for a policy
violation and they have no other power. So we have shown to LIRs that
they can now do whatever they like with impunity.

The proposers have made lots of references to IPv6 "allocated-by-lir:"
and "assigned:". They talk about how well things work in the IPv6
world. Maybe that is all about to change. If the NCC has no power to
enforce policy then, according to the chairs it is optional. Why is
IPv6 policy any different? If you have a /29 IPv6 block, maybe you
won't need any more for a few years, if ever. Or you can always rent a
block from one of the brokers who have huge stockpiles. So the NCC
still has no power over you. Why bother to register those /48s as
required by policy. Policy is optional, the chairs said. Those LIRs
that enter optional details about the End User in an IPv6 assignment
may simply follow the same process as they do for IPv4. Maybe using
the same script to generate the object. If they change this for IPv4
they may make the same change for IPv6 as well. As many people say,
they want to handle IPv4 and IPv6 the same way.

LIRs may now be looking at all that has been said during this
discussion and thinking how they can use this information to reduce
their workload and costs. Many LIRs also say they don't want to
publish any details of their customers in a public database. They have
only done so in the past because they correctly believed it was a
policy requirement. Now they know it is either no longer a requirement
or not enforceable, why would they do it? Things will probably not
change overnight. But gradually these objects, this data will
disappear. It makes no difference now if 2023-04 is approved or not.
ALL LIRs now know this policy requirement is not enforceable. No
action will be taken against them if they stop entering End User
details or even start removing it.

This is the cat you have let out of the bag. This is the change to the
policy landscape you have made and you cannot go back. Another aspect
is how to change policy. If LIRs decide to ignore some other aspect of
policy, they again know there is no action that can be taken against
them. Over time people will say this is now accepted behaviour. Then
it will be normalised by changing the policy to match the behaviour.
So who is in control now? The 'community' can make any policy it
likes. The LIRs can choose to ignore it because the chairs say it is
optional. The RIPE NCC has no power to do anything. Certainly not
against the bigger LIRs. The operator community that has driven this
proposal through, for their convenience, has shown an indifferent and
uncompromising attitude to anyone outside of their group. I am sure
this has not gone unnoticed. Civil society (ie voters) and law
enforcement have far more influence over politicians than this
operator community has. EU politicians are not averse to making
regulations in this area. Don't be surprised if they write regulations
specifying what a public registry of Internet number resources should
look like (Nis3?). After all, we don't have our own specification. An
industry that has an impact on the lives of just about everyone on the
planet, is critical to government, industry, commerce and society, can
only expect to be self regulating if it is willing to cooperate and
compromise with other groups in society. If you want to live in your
own little bubble, do everything your way as you have for the last 20
years, don't be surprised when change comes and is enforced on you.

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.
========================================================