[address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

After reading denis's response I realized that I responded a bit too
hastily with my +1.
I am going to retract my support for this proposal as I really don't
get why you would need this without the "assignment-size" attribute.
I might have missed something but I can't see what possible benefit
"AGGREGATED-BY-LIR" has over "SUB-ALLOCATED PA" without it.
The only thing that I can think of is if you just want to just comply
with the policy without providing any additional info, in which case
the policy should just be updated to not require it if that is what
the community wants.

My reason for saying this is that some LIRs might choose to remove
specific inet(6)num objects that they have already created and just
create a big "AGGREGATED-BY-LIR" inet(6)num object as you can't have
inet(6)num objects under it.
Personally I would prefer it if an LIR just chose to document some of
their assignments while leaving some undocumented over "documenting"
them in a way that really doesn't specify any meaningful information.

If I have missed something and there actually is a true benefit[0] to
using "AGGREGATED-BY-LIR" without an "assignment-size" attribute then
do let me know.

I would really prefer if this was considered carefully before
implementing it due to the potential risk of losing data currently in
the database.

-Cynthia

[0]: "true benefit" here referring to something beyond just making it
compliant with RIPE policy as I think there are better solutions if
that is the case.

On Tue, Sep 12, 2023 at 4:56 PM denis walker <ripedenis at gmail.com> wrote:
>
> 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 <tore at fud.no> 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://mailman.ripe.net/
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/