You are here: Home > Participate > Join a Discussion > RIPE Forum
RIPE Forum v1.4.2

Address Policy Working Group

Threaded
Collapse

[address-policy-wg] Assignments from a /24 allocation

denis walker

2021-11-23 19:33:55 CET

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

Carsten Schiefner

2021-11-24 10:26:25 CET

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 _dot_ net>
Reply-To: Carsten Schiefner <ripe-wgs.cs _at_ schiefner _dot_ de>
To: DB-WG <db-wg _at_ ripe _dot_ 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