Hi Jeroen & Tore,

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.

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?
2) Is the publication of a prefix assignment boundary between end users
important?"

A response agreeing with these questions and reflecting surprise at the policy interpretation is also here (apologies Nick, I missed it at the time):-

https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013864.html

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.

Many thanks,
Brian



Brian Storey
IP Network Capacity Planning Manager
Tel: 
0333 240 3481
Mobile: 
07436 101 378
Email: 
Brian.Storey@gamma.co.uk
This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster@gamma.co.uk​​​​

Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at The Scalpel, 18th Floor, 52 Lime Street, London EC3M 7AF and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
-----Original Message-----
From: address-policy-wg <address-policy-wg-bounces@ripe.net> On Behalf Of Tore Anderson
Sent: Monday, April 8, 2024 11:42 AM
To: Carlos Friaças <cfriacas@fccn.pt>
Cc: address-policy-wg@ripe.net
Subject: Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status

* Carlos Friaças via address-policy-wg:
> So in order to make it clear for the co-chairs, i do oppose this
> proposal, on the grounds that the quality of publicly available
> registration data is likely to decrease if this proposal is approved.

Hi Carlos,

This concern has been addressed at length in the previous phases of the policy development process, so for the full answer we will refer you back to those discussions. We will however summarise our position briefly below:

We do not believe the registration data will degrade as a result of this proposal. It does in no way encourage or compel LIRs to remove any End User registration data currently found in the database, nor does it stop them from adding more End User registration data in the future. In other words, any LIR that today chooses to publish detailed information about their individual End User assignments is free to continue to do so after this proposal is implemented.

Furthermore, there is no reason to expect that the acceptance of this proposal will entice LIRs to replace detailed individual assignments with aggregated assignments en masse. This has not happened with IPv6, where there are currently over twelve times as many ASSIGNED inet6num objects as there are AGGREGATED-BY-LIR objects. Many of those are rife with optional End User details shared voluntarily by the issuing LIRs.
We see no reason to believe that LIRs will use AGGREGATED-BY-LIR for
IPv4 inetnum objects in a materially different way.

Finally, we would like to point out that the proposal explicitly restricts the scope of AGGREGATED-BY-LIR, by stating that «the purpose and the contact details must be consistent throughout the whole assignment». That means that the End User registration data that can be aggregated must be redundant in the first place.

Best regards,
Jeroen & Tore


--

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