Hi Tore, I'm conscious you've gone to a great deal of effort to respond back to me promptly and I've not come back to you sooner. Sorry to keep you waiting for at least an acknowledgement. Firstly, thank you for taking us through this example. I can see yourself and Dennis have developed this converdation further. Rather than tread on that, I'll perhaps offer a slightly different spin on this which is neither in support or against your proposal, but in respect to how a LIR is supposed to determine what they should or shouldn't do. I'll be honest and say that I'm a relative newcomer to this having taken on the adminsitrative responisbility and compliance here less than 12 months ago. Whilst there is a degree of "This is the way" (from an internal & external perspective) with what I or anyone else takes on, I did want to audit and review as many aspects of what we should be doing as per policies, terms and conditions, RIPE DB Training, assumed best practice etc. What is apparent to me is that whilst a policy may describe a "must", it isn't nessecarily prescriptive on the "how" and is sufficiently narrow leaving how the end result is achieved. Certaintly I don't think this how the policies are intended to be written but there are some leaps you need to make as to what you should perhaps do or not do. A policy alone, in the case of RIPE-733 is a good example of this, in particular when you also consider clause 3.0 bullet 4. I know this isn't a unique problem but:- - Within quick succession I had two end business customers reach out to us to remove their business name from the description of the relevant INET ASSIGNED PA entry. Reasons cited were security. Whilst I looked at what we could possibly do, on balance we determined that it wasn't an option because of policy, other obligations and objectives. To also help support this view, we could see other LIRs providing service for the same end business who have taken the same approach as us, so at least we are collectively consistent! - On the other side, there was another new end business reaching out asking why the assignment with their details hadn't been published yet! Clearly two competing interests! Where does this lead me? Well, clearly we want administrative simplicity. Not only that, a clear way to explain internally and externally downstream to end customers but also up to RIPE NCC why we do it the way we do. Referencing clear policies is important to help justify why we take a certain approach and explain any limitations we may have. With the proposal you have presented, whilst I understand the rationale of it, I'm not quite seeing how without some of the discussion being had here, someone can read it and proceed as intended or take our explanation / interpretation of our obligations and apply them consistently. I recognise the latter part is part of the challenge now and a goal to be addressed. The path of least resistance starts to become very attractive! Perhaps I'm going down a rabbit hole with this. Ultimately I'm looking to make sure I understand how to remain on the right side of things! 😊. With regard to AGGREGATED-BY-LIR and its existence with IPV6; yes, it's something which drew some interest when I first started and the different approaches. Feels like there is a bit more subtly to this though. Many thanks, Brian -----Original Message----- From: Tore Anderson <tore@fud.no> Sent: Tuesday, September 12, 2023 7:52 AM To: Brian Storey <Brian.Storey@gamma.co.uk>; address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) Hi Brian, * Brian Storey
Thanks for explaining this particular use case.
Reading the proposed New Policy Text, it provides the LIR with an adminsitrative choice. Whilst I understand this choice, the rantionale behind the proposal is to find a reasonable way to fill the gap for the Provider Allocations not registered for the specific exception documented: "IP addresses used solely for the connection of an End User to a service provider... can be registered as part of the service provider's internal infrastructure".
Given the choice provided in the proposal, it seems to me like I could go the other way with this and aggregate everything? The end user allocation size distinction no longer looks to apply and I could interprete that the "purpose" of the whole aggregate is consistent (they are all used to reach "stuff") and therefore chose to not register any end user assigned /29s, 28s, /27s etc.
It depends on whether or not all your assignments are completely uniform (apart from the prefix value and length). If they are, you will be able to aggregate them. This means that they need to share a single common point of contact, which is often the case for assignments associated with fully managed Internet services provided to private individuals and small businesses. Such assignments would be possible to aggregate. If on the other hand they are not uniform (for example if your customers operate their own NOCs and therefore have different contact information), you will not be able to aggregate them. I will try to explain by example here as well. Let's say you currently have two customer assignments as follows: Customer 1: inetnum: 192.0.2.0 - 192.0.2.128 netname: BRIAN-ISP country: GB admin-c: BRIAN-RIPE tech-c: BRIAN-RIPE status: ASSIGNED PA mnt-by: BRIAN-MNT source: RIPE Customer 2: inetnum: 192.0.2.128 - 192.0.2.192 netname: BRIAN-ISP country: GB admin-c: BRIAN-RIPE tech-c: BRIAN-RIPE status: ASSIGNED PA mnt-by: BRIAN-MNT source: RIPE As you can see, except for the 'inetnum' value, they are completely identical. That means you will be able aggregate them into a single object: inetnum: 192.0.2.0 - 192.0.2.192 netname: BRIAN-ISP country: GB admin-c: BRIAN-RIPE tech-c: BRIAN-RIPE status: AGGREGATED-BY-LIR mnt-by: BRIAN-MNT source: RIPE The second example concerns the case where the assignments are not uniform. Let's say your customers operate their own NOCs, so your starting point instead is having these two assignments: Customer 1: inetnum: 192.0.2.0 - 192.0.2.128 netname: BRIAN-ISP country: GB admin-c: BRIAN-RIPE tech-c: CUST1-RIPE status: ASSIGNED PA mnt-by: BRIAN-MNT source: RIPE Customer 2: inetnum: 192.0.2.128 - 192.0.2.192 netname: BRIAN-ISP country: GB admin-c: BRIAN-RIPE tech-c: CUST2-RIPE status: ASSIGNED PA mnt-by: BRIAN-MNT source: RIPE Note how the 'tech-c' attribute differs between the two assignments. That means that not be able to replace them with an AGGREGATED-BY-LIR object.
Does this not contradict other purposes / objectives of the registry, including the principles of registering public networks or am I missing something?
We do not believe so. As demonstrated above, only highly redundant data can be aggregated, so very little actual information lost in the process. Finally, please keep in mind that AGGREGATED-BY-LIR is not a novel idea, it has been around in the IPv6 policy for many many years. If it was indeed the case that it contradicted the purposes and/or objectives of the registry, someone ought to have noticed and attempted to fix that problem by now. That has not happened, as far as we know, which we take as a sign that there is no such problem in the first place. Tore