Hello Denis,
In my opinion, not having the feature forces us to implement the workaround you
mention, which hurts data quality because it causes our entries not to reflect
the reality of our allocations anymore.
So the proposed feature is, in my opinion, needed.
Best regards
Stéphane Dodeller
----------------------------------------------------------------------
Message: 1
Date: Mon, 16 Nov 2020 12:57:02 +0000 (UTC)
From: "[email protected]" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [address-policy-wg] NWI-4 - role of status: field in
multivalued status context -- Last call
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Colleagues
We have not had enough comment on this to make a decision if any change is
needed. So can we have a last round of comment to decide if this is a
sufficiently important issue to make a change or if we just close this action
item?
In brief: when assigning a whole allocation should we be able to give the
INET(6)NUM object 2 status values to reflect it being both an allocation and an
assignment, rather than splitting it into two smaller assignment objects?
cheersdenis
co-chair DB-WG
On Monday, 5 October 2020, 16:48:34 CEST, ripedenis--- via
address-policy-wg <[email protected]> wrote:
Colleagues
I was about to post this to the DB-WG but it may be more appropriate to
include it as part of this discussion...
Yet another 4 year old NWI that needs to be progressed or closed. The
details are
here:https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.net%2Fripe%2Fmail%2Farchives%2Fdb-wg%2F2016-May%2F005242.html&data=04%7C01%7CStephane.Dodeller%40swisscom.com%7Cfd27bf19ebea497dfa4608d88ae80632%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637412076422235127%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=z7uZHxIdqZA2ScztbCALI2P91DNN%2BdQKyRZw1MY4qBI%3D&reserved=0
In summary it concerns the assignment of a whole allocation. Because the
range is the primary key (pkey) in the database you cannot have an allocation
object and an assignment object with the same pkey. A common work around is to
split the allocation and make two assignments. The suggestion is to allow
"status:" to be a multiple attribute.
This could be done quite easily and constrained in it's use by business
rules in the database software. So the syntax could be changed in INET(6)NUM
objects to:status:? ? ? ? ?[mandatory]? [multiple]? ? ?[ ]
The business rules could make this multiple option only allowed in very
limited situations. For example if an INETNUM object has 'status: ALLOCATED PA'
it could be possible to add a second value 'status: ASSIGNED PA' or 'status:
SUB-ALLLOCATED PA'. If the status in an INET6NUM object is 'status:
ALLOCATED-BY-RIR' it could be possible to add a second value 'status:
ALLOCATED-BY-LIR' or 'status: ASSIGNED'. The business rules could prevent any
other multiple status values.
The "descr:" attribute is already multiple so it can describe both the
allocation and the assignment.
Is this still considered to be an issue?
cheersdenis
co-chair DB-WG
On Monday, 5 October 2020, 16:13:53 CEST, Erik Bais
<[email protected]> wrote:
Dear WG,?
I want to bring the following email and questions of our PDO - Petrit
Hasani to your attention that might have slipped over the vacation period.?
Please have a look at this discussion again and provide input if you can.?
Regards,
Erik Bais
Co-chair AP-WG. ( on behalf of the AP-WG Chair collective )
?On 02/07/2020, 13:36, "address-policy-wg on behalf of Petrit Hasani"
<[email protected] on behalf of [email protected]> wrote:
? ? Dear colleagues,
? ?
? ? Thank you to everyone who responded to our earlier questions on the
intent of the policy regarding IPv4 status hierarchies.
? ?
? ? While this was helpful, it would be great if we could have input from a
wider group of people:
? ?
? ? - Should inetnums with these statuses be allowed to be created inside
one another?
? ? - Should there be a limit on the minimum size of a sub-allocation?
? ? - Do we need a policy update?
? ?
? ?
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.net%2Fripe%2Fmail%2Farchives%2Faddress-policy-wg%2F2020-June%2F013195.html&data=04%7C01%7CStephane.Dodeller%40swisscom.com%7Cfd27bf19ebea497dfa4608d88ae80632%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637412076422235127%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=HVgzH1dFV1jYiJEK44rKy9zk%2BJ9gPIiw7oTyaRbF56s%3D&reserved=0
? ?
? ? We look forward to hearing from you.
? ?
? ? Cheers,
? ? --
? ? Petrit Hasani
? ? Policy Officer
? ? RIPE NCC
? ?
? ?
? ?
? ?
? ?
? ? > On 16 Jun 2020, at 15:36, Petrit Hasani <[email protected]> wrote:
? ? >
? ? > Dear colleagues,
? ? >
? ? > We are reviewing IPv4 status hierarchies in the RIPE Database
(looking at objects with the same status as their less-specifics).
? ? >
? ? > Some cases are clear - "ASSIGNED PA" shouldn't be allowed under
"ASSIGNED PA", for example. Other statuses might need a closer look and we
would like guidance from this working group.
? ? >
? ? > The RIPE Database does not currently have any limitations on creating
inetnums that have the status "SUB-ALLOCATED PA" or "LIR-PARTITIONED PA" under
inetnums with the same status. This often results in chains of inetnums that
have the same status, sometimes ending with the sub-allocation of a single IP
address.
? ? >
? ? > Although this might not seem useful at first glance, there might be
practical uses for a few levels of sub-allocation. For example, a global
company could give sub-allocations to its national branches, which make smaller
sub-allocations to their multiple daughter companies. These daughter companies
could then create and maintain assignments for their actual networks.
? ? >
? ? > However, this is not allowed under a strict reading of the policy, as
only the LIR itself can make sub-allocations, and these must be used for
assignments.
? ? >
? ? > Section 5.3 "Sub-allocations" of the IPv4 Address Allocation and
Assignment Policies (ripe-733) states:
? ? >
? ? > "Sub-allocations are intended to aid the goal of routing aggregation
and can only be made from allocations with a status of "ALLOCATED PA".
? ? >
? ? > [...]
? ? >
? ? > LIRs may make sub-allocations to multiple downstream network
operators."
? ? >
? ? >
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.net%2Fpublications%2Fdocs%2Fripe-733%2354&data=04%7C01%7CStephane.Dodeller%40swisscom.com%7Cfd27bf19ebea497dfa4608d88ae80632%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637412076422235127%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BHBQ2Uc3Or7fdd33XY8sCzyeCbcRSTDTsKvOooz1dHg%3D&reserved=0
? ? >
? ? > Before making any changes, we want to be sure that we understand the
intent of the policy and what the community wants us to do. Thus, we would like
to hear from the Address Policy Working Group:
? ? >
? ? > - Should inetnums with these statuses be allowed to be created inside
one another?
? ? > - Should there be a limit on the minimum size of a sub-allocation?
? ? > - Do we need a policy update?
? ? >
? ? > We look forward to your guidance.
? ? >
? ? > Kind regards,
? ? > --
? ? > Petrit Hasani
? ? > Policy Officer
? ? > RIPE NCC
? ? >
? ? >
? ? >
? ? >
? ? >
? ?
? ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe.net%2Fripe%2Fmail%2Farchives%2Faddress-policy-wg%2Fattachments%2F20201116%2F1dc71c62%2Fattachment-0001.html&data=04%7C01%7CStephane.Dodeller%40swisscom.com%7Cfd27bf19ebea497dfa4608d88ae80632%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637412076422235127%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JkQX1eOG%2FbljtY7EsJervD%2B7T3TTdMmCZFrYbFQnF0E%3D&reserved=0>
End of address-policy-wg Digest, Vol 109, Issue 1
*************************************************
