NWI-4 - role of status: field in multivalued status context - reprise
Dear all - after a quick chat with Dennis on this, he encouraged me to toss this into the seemingly stalled, but not yet dead debate: Right now, only the "inet[6]num:" attribute is the primary key to, of or for inet[6]num objects. I wonder if it would be possible to make the tuple ("inet[6]num:","status:") the primary key instead: that should solve the challenge to have an assignment that shall have the size of an allocation. In case this has been exhaustedly discussed here already, please excuse my ignorance - I then obviously have failed to spot the respective contribution in the archives. All the best, -C.
On Fri, May 21, 2021 at 12:45:35PM +0200, Carsten Schiefner via db-wg wrote: Hi Carsten,
after a quick chat with Dennis on this, he encouraged me to toss this into the seemingly stalled, but not yet dead debate:
Right now, only the "inet[6]num:" attribute is the primary key to, of or for inet[6]num objects.
I wonder if it would be possible to make the tuple ("inet[6]num:","status:") the primary key instead: that should solve the challenge to have an assignment that shall have the size of an allocation.
This is very good idea.
In case this has been exhaustedly discussed here already, please excuse my ignorance - I then obviously have failed to spot the respective contribution in the archives.
I do not recall such discussion. Best, Piotr -- Piotr Strzyżewski
Dear all, maybe someone from the NCC would feel inclined to comment on the feasibility of the below? Thanks & best, -C. On 21.05.2021 12:55, Piotr Strzyzewski via db-wg wrote:
On Fri, May 21, 2021 at 12:45:35PM +0200, Carsten Schiefner via db-wg wrote:
Hi Carsten,
after a quick chat with Dennis on this, he encouraged me to toss this into the seemingly stalled, but not yet dead debate:
Right now, only the "inet[6]num:" attribute is the primary key to, of or for inet[6]num objects.
I wonder if it would be possible to make the tuple ("inet[6]num:","status:") the primary key instead: that should solve the challenge to have an assignment that shall have the size of an allocation.
This is very good idea.
In case this has been exhaustedly discussed here already, please excuse my ignorance - I then obviously have failed to spot the respective contribution in the archives.
I do not recall such discussion.
Best, Piotr
Hi Carsten, The DB team will create a proof of concept to see if this is feasible, and I will report our findings to you and the DB-WG. Regards Ed Shryane RIPE NCC
On 8 Jun 2021, at 12:03, Carsten Schiefner via db-wg <db-wg@ripe.net> wrote:
Dear all,
maybe someone from the NCC would feel inclined to comment on the feasibility of the below?
Thanks & best,
-C.
On 21.05.2021 12:55, Piotr Strzyzewski via db-wg wrote:
On Fri, May 21, 2021 at 12:45:35PM +0200, Carsten Schiefner via db-wg wrote:
Hi Carsten,
after a quick chat with Dennis on this, he encouraged me to toss this into the seemingly stalled, but not yet dead debate:
Right now, only the "inet[6]num:" attribute is the primary key to, of or for inet[6]num objects.
I wonder if it would be possible to make the tuple ("inet[6]num:","status:") the primary key instead: that should solve the challenge to have an assignment that shall have the size of an allocation.
This is very good idea.
In case this has been exhaustedly discussed here already, please excuse my ignorance - I then obviously have failed to spot the respective contribution in the archives.
I do not recall such discussion.
Best, Piotr
Hi, I would just like to say that I would also like this to be implemented if the DB team determines it to be feasible. :) -Cynthia On Tue, Jun 8, 2021 at 1:31 PM Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Hi Carsten,
The DB team will create a proof of concept to see if this is feasible, and I will report our findings to you and the DB-WG.
Regards Ed Shryane RIPE NCC
On 8 Jun 2021, at 12:03, Carsten Schiefner via db-wg <db-wg@ripe.net> wrote:
Dear all,
maybe someone from the NCC would feel inclined to comment on the feasibility of the below?
Thanks & best,
-C.
On Fri, May 21, 2021 at 12:45:35PM +0200, Carsten Schiefner via db-wg wrote:
Hi Carsten,
after a quick chat with Dennis on this, he encouraged me to toss this into the seemingly stalled, but not yet dead debate:
Right now, only the "inet[6]num:" attribute is the primary key to, of or for inet[6]num objects.
I wonder if it would be possible to make the tuple ("inet[6]num:","status:") the primary key instead: that should solve
On 21.05.2021 12:55, Piotr Strzyzewski via db-wg wrote: the
challenge to have an assignment that shall have the size of an allocation.
This is very good idea.
In case this has been exhaustedly discussed here already, please excuse my ignorance - I then obviously have failed to spot the respective contribution in the archives.
I do not recall such discussion.
Best, Piotr
Hi guys Just out of interest why do people think having a dual attribute primary key pair is better than allowing multiple "status:" attributes in very specific cases? Multiple status attributes is probably far simpler to implement and maybe easier to parse. Changing the pkey affects the way millions of objects are handled. Adding a second status affects (tens of) thousands of objects. In both cases multiple objects may be returned in a query for address space which all existing user scripts will have to accomodate. Changing the pkey will require more business rules to (dis)allow certain status combinations. Unless it is OK to have an ALLOCATED PA, :LIR-PARTITIONED PA, SUB-ALLOCATED PA, ASSIGNED PA all with the same prefix. Changing the pkey also means changes to the query code to allow a query for a specific object using the prefix/status pair or a more general query on just the prefix to return possibly multiple objects. cheers denis co-chair DB-WG On Tue, 8 Jun 2021 at 16:22, Cynthia Revström via db-wg <db-wg@ripe.net> wrote:
Hi,
I would just like to say that I would also like this to be implemented if the DB team determines it to be feasible. :)
-Cynthia
On Tue, Jun 8, 2021 at 1:31 PM Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Hi Carsten,
The DB team will create a proof of concept to see if this is feasible, and I will report our findings to you and the DB-WG.
Regards Ed Shryane RIPE NCC
On 8 Jun 2021, at 12:03, Carsten Schiefner via db-wg <db-wg@ripe.net> wrote:
Dear all,
maybe someone from the NCC would feel inclined to comment on the feasibility of the below?
Thanks & best,
-C.
On 21.05.2021 12:55, Piotr Strzyzewski via db-wg wrote:
On Fri, May 21, 2021 at 12:45:35PM +0200, Carsten Schiefner via db-wg wrote:
Hi Carsten,
after a quick chat with Dennis on this, he encouraged me to toss this into the seemingly stalled, but not yet dead debate:
Right now, only the "inet[6]num:" attribute is the primary key to, of or for inet[6]num objects.
I wonder if it would be possible to make the tuple ("inet[6]num:","status:") the primary key instead: that should solve the challenge to have an assignment that shall have the size of an allocation.
This is very good idea.
In case this has been exhaustedly discussed here already, please excuse my ignorance - I then obviously have failed to spot the respective contribution in the archives.
I do not recall such discussion.
Best, Piotr
On 08.06.2021 13:30, Edward Shryane via db-wg wrote:
The DB team will create a proof of concept to see if this is feasible, and I will report our findings to you and the DB-WG.
Lovely, Ed - thanks a lot! :-)
On 8 Jun 2021, at 12:03, Carsten Schiefner via db-wg <db-wg@ripe.net> wrote:
Dear all,
maybe someone from the NCC would feel inclined to comment on the feasibility of the below?
Thanks & best,
-C.
there is no proof of termination of hacking long deployed specs and software to fix the bugs in someone's program where they diod not read the specs. randy --- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header butchery
participants (6)
-
Carsten Schiefner -
Cynthia Revström -
denis walker -
Edward Shryane -
Piotr Strzyzewski -
Randy Bush