[db-wg] Decision on NWI-4 INETNUM status values
- Previous message (by thread): [db-wg] Decision on NWI-4 INETNUM status values
- Next message (by thread): [db-wg] Decision on NWI-4 INETNUM status values
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nick Hilliard
nick at foobar.org
Mon Apr 4 22:19:24 CEST 2022
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
- Previous message (by thread): [db-wg] Decision on NWI-4 INETNUM status values
- Next message (by thread): [db-wg] Decision on NWI-4 INETNUM status values
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]