This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
[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 ]