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@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/01398...
The two questions I previously posed here: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013... 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@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/013...):
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@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. ========================================================