Hi Tore Your claims are not correct. Your simple example hides a lot of detail. I have given a real life example below taken from the database to illustrate what I mean. My apologies to the resource holder, but it is a perfect example to illustrate several points.
On Tue, 12 Sept 2023 at 08:51, Tore Anderson <[email protected]> wrote: > > Hi Brian, > > * Brian Storey > > > 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. Your definition of 'completely uniform' seems to only apply to contact details, as you make clear in the next paragraph. Many assignment objects currently contain more information than just contact references. You are making the assumption that the RIPE Database is still nothing more than an operator's contact database for network operational issues. In which case all you need is the tech-c. > > 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: But your example is a bare bones 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. In real life lots of information may be lost. > > 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. This community has very little appetite to fix things properly if a quick fix will do or they can live with existing problems. The constant 'fight' to try to fix many problems with the RIPE Database illustrates this point very well. Now let's look at a real life example. whois -rBm 195.238.192.0 - 195.238.223.255 The first thing to note is that the admin-c and tech-c values are the same in all the more specific assignments. Even the mnt-by is the same, although you make no mention if that is a blokker for aggregation or not. So by your definition these are 'completely uniform' objects and can be aggregated. You will also note that all these objects contain optional descr attributes. These attributes contain name and address details of the end user. That is important information for many stakeholder groups using the RIPE Database public registry. That detail will be lost in an aggregation. Given that current policy requires these assignments to be registered in the public registry, many users do include this detail. Now we all know the RIPE Database design and technology is very old and it does currently require some effort to manage this data. (A problem that all users have noticed but no one has attempted to fix.) Given a 'short cut' option, human nature suggests people will use it, even if it is not the right thing to do for a public registry. So aggregating across the whole database, may result in a massive amount of detail being lost from the public registry. Also note that there are gaps in the more specific assignments for this allocation. For example 195.238.193.224 - 195.238.193.255 is not assigned. Can your aggregated objects span these gaps? If so then we lose sight of what address space is in use or available. It may no longer be needed for further allocations but people do still use that information. The assignments are all randomly sized. Which is why you have dropped the inet6num assignment-size attribute for inetnum objects. So if I am getting abuse from one specific IP address what should I do? I have no idea from the aggregated block what the block size is that includes this one IP address. Is there any other way to find this information, maybe from routing details? If not, should I block and blacklist the entire aggregated block? That could affect hundreds, maybe even thousands, of users in some cases. This is not a problem with IPv6 as you know the size of the block containing that address. cheers denis c0-chair DB-WG > > 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 -- 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
