[db-wg] Decision on NWI-4 INETNUM status values

Hi Cynthia

On Mon, 4 Apr 2022 at 23:48, Cynthia Revström via db-wg <db-wg at ripe.net> wrote:
>
> I think the only thing that would really offer a proper solution here
> is to change the primary key to inetnum + status. (as mentioned in
> option 2 of Nick's email)

Forget this option. It cuts too deeply into the data model design. The
RIPE NCC has already waved many red flags about this and said it is
not feasible.

>
> Quite a few LIRs do lease out address space and some of them will
> probably be /24s that are leased out in their entirety.
>
> While there is the argument to not encourage this behaviour, I would
> say that it is going to happen anyways and we should instead try to
> make sure the database is as accurate as possible.

A large proportion of the /24 allocations made by the RIPE NCC went to
existing Members who set up multiple subsidiary (shell) companies,
each with multiple LIRs specifically to get as much of the available,
remaining IPv4 address space as possible. A lot of these allocations
are currently rented out to other LIRs. Some Members are now operating
as commercial RIRs below the level of the RIPE NCC. This rented
address space is not at all accurately represented in the RIPE
Database. The current system does not accommodate  commercial RIRs.
The status of these resources and the usage is all wrong in the
database and many of the contacts are pretty much useless.

> This would require the ability to also set the org attribute and
> possible admin-c/tech-c, and as such I think being able to have two
> different inetnum objects for the same prefix is the only solution to
> this case.

To do it right, accepting that there are now commercial RIRs operating
in the region with resources being 're-alllocated' from resource
holder to LIR, would be a very complex task. Adding the status value
'ALLOCATED-ASSIGNED PA' is just the low hanging fruit to cover one
situation.

cheers
denis
co-chair DB-WG

>
> Disclaimer: While I am writing this email in a personal capacity and
> think this is the right thing to do to ensure DB accuracy, sometimes I
> represent a LIR (towards the RIPE NCC) that would potentially benefit
> from the idea I am suggesting here.
>
> -Cynthia
>
> On Mon, Apr 4, 2022 at 10:19 PM Nick Hilliard via db-wg <db-wg at ripe.net> wrote:
> >
> > Leo Vegoda via db-wg wrote on 04/04/2022 20:50:
> > > Why do they need to register this
> > > assignment? Why can the allocation not be left as it is and assumed to
> > > be used by the organisation holding it?
> > >
> > > What am I missing?
> >
> > it's a fly in the ointment.
> >
> > There are three options to handle this situation, possibly more:
> >
> > 1. don't allow an allocation + an assignment to encompass exactly the
> > same space. This is a function of the data model, which states that
> > inetnum: is the primary key. This stops organisations from having a 1:1
> > mapping between their internal assignment databases and the public
> > ripedb view.  This is what we have at the moment.
> >
> > 2. change the ripedb data model to key on inetnum+status. This would
> > allow an assignment and an allocation to have the same inetnum, which
> > would allow organisations to have a 1:1 mapping between their internal
> > assignment databases and the public ripedb view.
> >
> > 3. use a different status: value for inetnum objects which are both
> > allocations and assignments. This is, I understand, what Denis was
> > proposing.
> >
> > I.e. the choice is about which fly in the ointment is the least
> > problematic, rather than whether there's a fly in the ointment.
> >
> > Nick
> >
> > --
> >
> > 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/