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

* 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/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».


> 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-from-ipv6-aggregated-by-lir-status.

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