[address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
- Previous message (by thread): [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
- Next message (by thread): [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Brian Storey
Brian.Storey at gamma.co.uk
Mon Apr 8 14:03:40 CEST 2024
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 at 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 at 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 at ripe.net> On Behalf Of Tore Anderson Sent: Monday, April 8, 2024 11:42 AM To: Carlos Friaças <cfriacas at fccn.pt> Cc: address-policy-wg at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20240408/28dc7811/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image409557.jpg Type: image/jpeg Size: 60772 bytes Desc: image409557.jpg URL: <https://lists.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20240408/28dc7811/attachment-0003.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image507479.jpg Type: image/jpeg Size: 14534 bytes Desc: image507479.jpg URL: <https://lists.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20240408/28dc7811/attachment-0004.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image329462.jpg Type: image/jpeg Size: 91601 bytes Desc: image329462.jpg URL: <https://lists.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20240408/28dc7811/attachment-0005.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image648658.png Type: image/png Size: 18443 bytes Desc: image648658.png URL: <https://lists.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20240408/28dc7811/attachment-0001.png>
- Previous message (by thread): [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
- Next message (by thread): [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]