* 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.
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. 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.» 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: «…changing this interpretation would be a major departure of many years of accepted practice and potentially involve updating thousands of RIPE DB objects» 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».
2) Is the publication of a prefix assignment boundary between end users important?"
We address this question in the proposal itself, see https://www.ripe.net/membership/policies/proposals/2023-04/#12-differences-f.... The gist of it is that since IPv4 assignments tend to be right-sized (rather than gigantic "one size fits all" prefixes like in IPv6), and that there is no HD-Ratio that needs calculating, we found it more appropriate to leave the assignment-size attribute optional.
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». Best regards, Jeroen & Tore