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
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@ripe.net> Reply-To: Carsten Schiefner <ripe-wgs.cs@schiefner.de> To: DB-WG <db-wg@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://lists.ripe.net/mailman/listinfo/address-policy-wg
participants (2)
-
Carsten Schiefner -
denis walker