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 -- 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
