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/[email protected]/
[address-policy-wg] Assignments from a /24 allocation
- Previous message (by thread): [address-policy-wg] Assignments from a /24 allocation
- Next message (by thread): [address-policy-wg] Suggestion to replace IPv4 waiting list with auctions
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Carsten Schiefner
ripe-wgs.cs at schiefner.de
Wed Nov 24 10:26:25 CET 2021
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 <db-wg at ripe.net> Reply-To: Carsten Schiefner <ripe-wgs.cs at schiefner.de> To: DB-WG <db-wg at ripe.net> 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://mailman.ripe.net/
- Previous message (by thread): [address-policy-wg] Assignments from a /24 allocation
- Next message (by thread): [address-policy-wg] Suggestion to replace IPv4 waiting list with auctions
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]