Danis and all - may I here in this WG point to my suggestion of May this year, too?
Thread starts in May: https://www.ripe.net/ripe/mail/archives/db-wg/2021-May/006976.html and continues (and finally stalls) in June: https://www.ripe.net/ripe/mail/archives/db-wg/2021-June/007015.html Best, -C. -------- Forwarded Message -------- Subject: [db-wg] NWI-4 - role of status: field in multivalued status context - reprise Date: Fri, 21 May 2021 12:45:35 +0200 From: Carsten Schiefner via db-wg <[email protected]> Reply-To: Carsten Schiefner <[email protected]> To: DB-WG <[email protected]> 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 23.11.2021 19:33, denis walker wrote: > Colleagues > > The issue came up again today at the AP-WG session at RIPE-83 about > making assignments from a /24 allocation. People are forced to create > two 'artificial' /25 assignments. Again this is used as one argument > against having to register assignments in the RIPE Database. > Regardless of the bigger picture about registering assignments, there > is a simple solution to the /24 allocation issue. Make the "status:" > attribute multiple. Then this /24 INETNUM object can have: > status: ALLOCATED PA > status: ASSIGNED PA > > Business rules can restrict the use of multiple status to very > specific use cases. Maybe only allow a second status of 'ASSIGNED PA' > in an object with status 'ALLOCATED PA'. The normal rules then apply > to an assignment, so there can be no more specifics. Then any > allocation of any size can be assigned in its entirety without having > to create more specific pseudo assignment objects. Business rules > could also allow this option for 'SUB-ALLOCATED PA'. > > cheers > denis > co-chair 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/address-policy-wg To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
