Colleagues

Over the years we have made many changes to the status values. For the
INETNUM status we added 'LIR-PARTITIONED PA' and 'LIR-PARTITIONED PI',
then later removed 'LIR-PARTITIONED PI'. We added and then later
removed another status similar to the partitioned (can't remember the
name now). We deprecated 'ALLOCATED PI'. We changed the rules on
'LEGACY' so that the whole hierarchy became 'LEGACY'. We changed the
rules on assignments to prevent hierarchies of assignments. For the
INET6NUM I think 'ASSIGNED PI' was not available originally and was
added later. We added "status:" as a new attribute to the AUT-NUM
object with three values.

I don't remember discussions about anything breaking with any of these
changes we made over the years. So can Nick, or anyone, tell us what
will break now, that didn't break before, if we add a new status value
'ALLOCATED-ASSIGNED PA'?

cheers
denis
co-chair DB-WG

On Mon, 4 Apr 2022 at 22:19, Nick Hilliard via db-wg <db-wg@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://lists.ripe.net/mailman/listinfo/db-wg

-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/db-wg

Reply via email to