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

Address Policy Working Group

Threaded
Collapse

[address-policy-wg] IPv4 status hierarchies

User Image

Petrit Hasani

2020-06-16 15:36:39 CET

RIPE NCC staff member

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://www.ripe.net/publications/docs/ripe-733#54

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





Sascha Luck [ml]

2020-06-16 15:57:29 CET

On Tue, Jun 16, 2020 at 03:36:39PM +0200, Petrit Hasani wrote:
>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://www.ripe.net/publications/docs/ripe-733#54
>
>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?
I think that may be useful, yes, especially for IPv6 allocations
which give far more scope for suballocations, and the use-case
obviously exists.

>- Should there be a limit on the minimum size of a sub-allocation?
Not for IPv4, *maybe* for IPv6. I don't think there is scope in
IPv4 for administrative address wasteage. It may be sensible in
IPv6 to prevent deaggregation of allocations into unmanageable bits
and database blowout. 

>- Do we need a policy update?
Yes, I think so. Policy is relatively unambiguous in stating that
only one level of sub-allocation is allowed and if there is a
desire to change this, the PDP should be required..

rgds,
Sascha Luck

ripedenis@yahoo.co.uk

2020-06-17 04:22:05 CET

 Hi guys
I'm either having a deja vu moment or I've had this conversation with someone recently. The policy wording here can be interpreted in different ways.
"Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA".

This could mean that the sub allocation must be one level more specific to the allocation resource object. But that may not make sense. A global organisation may want to use 'LIR-PARTITIONED PA' to split a resource allocation between national subsidiaries from which they may wish to make sub allocations.
However, this wording may also mean that a sub allocation must be made within a hierarchy where the less specific resource object has the status of 'ALLOCATED PA' rather than 'ALLOCATED PI' or 'ALLOCATED UNSPECIFIED', but the sub allocation is not constrained to be only one level more specific to the allocation object. So that would allow for a hierarchy of several levels of sub allocations and partitions.
cheersdenis
co-chair DB-WG

    On Tuesday, 16 June 2020, 15:57:51 CEST, Sascha Luck [ml] <apwg _at_ c4inet _dot_ net> wrote:  
 
 On Tue, Jun 16, 2020 at 03:36:39PM +0200, Petrit Hasani wrote:
>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://www.ripe.net/publications/docs/ripe-733#54
>
>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?
I think that may be useful, yes, especially for IPv6 allocations
which give far more scope for suballocations, and the use-case
obviously exists.

>- Should there be a limit on the minimum size of a sub-allocation?
Not for IPv4, *maybe* for IPv6. I don't think there is scope in
IPv4 for administrative address wasteage. It may be sensible in
IPv6 to prevent deaggregation of allocations into unmanageable bits
and database blowout. 

>- Do we need a policy update?
Yes, I think so. Policy is relatively unambiguous in stating that
only one level of sub-allocation is allowed and if there is a
desire to change this, the PDP should be required..

rgds,
Sascha Luck

  
User Image

Leo Vegoda

2020-06-17 23:07:22 CET

Hi,

Thanks for raising this.

On Tue, Jun 16, 2020 at 6:36 AM Petrit Hasani <phasani _at_ ripe _dot_ net> wrote:

[...]

> 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.

Casting my mind back to why this status exists, it is possible that
the original goals no longer need support in the RIPE Database. Nurani
quoted James Aldridge (then at EUnet) when describing the RIPE NCC
proposal:

https://www.ripe.net/ripe/mail/archives/db-wg/2001-September/001732.html

Since then, the RIPE NCC has deployed the LIR Portal and large ISPs
have (mostly) embraced IPAM. So, it would be good to know if the
original need still exists or has changed somewhat. If that need has
changed, how has it changed?

Is whatever functionality is required best deployed in the RIPE
Database or should it be deployed through the LIR Portal, simplifying
the allocation hierarchy shown over RDAP?

Kind regards,

Leo Vegoda

User Image

Petrit Hasani

2020-07-02 13:36:43 CET

RIPE NCC staff member

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://www.ripe.net/ripe/mail/archives/address-policy-wg/2020-June/013195.html

We look forward to hearing from you.

Cheers,
--
Petrit Hasani
Policy Officer
RIPE NCC





> On 16 Jun 2020, at 15:36, Petrit Hasani <phasani _at_ ripe _dot_ net> 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://www.ripe.net/publications/docs/ripe-733#54
> 
> 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
> 
> 
> 
> 
> 

User Image

Erik Bais

2020-10-05 16:13:11 CET

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" <address-policy-wg-bounces _at_ ripe _dot_ net on behalf of phasani _at_ ripe _dot_ net> 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://www.ripe.net/ripe/mail/archives/address-policy-wg/2020-June/013195.html
    
    We look forward to hearing from you.
    
    Cheers,
    --
    Petrit Hasani
    Policy Officer
    RIPE NCC
    
    
    
    
    
    > On 16 Jun 2020, at 15:36, Petrit Hasani <phasani _at_ ripe _dot_ net> 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://www.ripe.net/publications/docs/ripe-733#54
    > 
    > 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
    > 
    > 
    > 
    > 
    > 
    
    

ripedenis@yahoo.co.uk

2020-10-05 16:45:44 CET

 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://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005242.html
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 <ebais _at_ a2b-internet _dot_ com> 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" <address-policy-wg-bounces _at_ ripe _dot_ net on behalf of phasani _at_ ripe _dot_ net> 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://www.ripe.net/ripe/mail/archives/address-policy-wg/2020-June/013195.html
    
    We look forward to hearing from you.
    
    Cheers,
    --
    Petrit Hasani
    Policy Officer
    RIPE NCC
    
    
    
    
    
    > On 16 Jun 2020, at 15:36, Petrit Hasani <phasani _at_ ripe _dot_ net> 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://www.ripe.net/publications/docs/ripe-733#54
    > 
    > 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
    > 
    > 
    > 
    > 
    > 
    
    

  

Stephane.Dodeller@swisscom.com

2020-10-05 17:24:01 CET

Dear Denis,

Since the workaround you mention creates entries in the database that do not match in some cases the reality of what has been done (and allowed by the policy), especially during the ALLOCATED-UNSPECIFIED cleanup period, I support the change you mention.

Best regards

Stéphane Dodeller
Swisscom (ch.unisource)

Le 05.10.20 16:48, « address-policy-wg au nom de address-policy-wg-request _at_ ripe _dot_ net » <address-policy-wg-bounces _at_ ripe _dot_ net au nom de address-policy-wg-request _at_ ripe _dot_ net> a écrit :
    Date: Mon, 5 Oct 2020 14:45:44 +0000 (UTC)
    From: "ripedenis _at_ yahoo.co _dot_ uk" <ripedenis _at_ yahoo.co _dot_ uk>
    To: "address-policy-wg _at_ ripe _dot_ net" <address-policy-wg _at_ ripe _dot_ net>,  Erik
    	Bais <ebais _at_ a2b-internet _dot_ com>
    Subject: Re: [address-policy-wg] IPv4 status hierarchies
    Message-ID: <1260079472.3251832.1601909144595 _at_ mail.yahoo _dot_ com>
    Content-Type: text/plain; charset="utf-8"

     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=02%7C01%7CStephane.Dodeller%40swisscom.com%7C1824b65a8425487661aa08d8693dc293%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637375061263396078&sdata=nZJ18TdMGru4ajgL4qPbmyElMXw%2Fc%2FynnCNpPu2Rp9g%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 <ebais _at_ a2b-internet _dot_ com> 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" <address-policy-wg-bounces _at_ ripe _dot_ net on behalf of phasani _at_ ripe _dot_ net> 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=02%7C01%7CStephane.Dodeller%40swisscom.com%7C1824b65a8425487661aa08d8693dc293%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637375061263396078&sdata=5LGahksB3BwkFn0apTyFMGMg4tu4NSprj6AmdCpU0ek%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 <phasani _at_ ripe _dot_ net> 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=02%7C01%7CStephane.Dodeller%40swisscom.com%7C1824b65a8425487661aa08d8693dc293%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637375061263396078&sdata=vCq4%2B%2B0el3rtQXcDOhrtqCCt2cqt9HzBoPui4fc0Lyc%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: 

    End of address-policy-wg Digest, Vol 108, Issue 2
    *************************************************

ripedenis@yahoo.co.uk

2020-11-16 13:57:02 CET

 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 <address-policy-wg _at_ ripe _dot_ net> 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://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005242.html
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 <ebais _at_ a2b-internet _dot_ com> 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" <address-policy-wg-bounces _at_ ripe _dot_ net on behalf of phasani _at_ ripe _dot_ net> 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://www.ripe.net/ripe/mail/archives/address-policy-wg/2020-June/013195.html
    
    We look forward to hearing from you.
    
    Cheers,
    --
    Petrit Hasani
    Policy Officer
    RIPE NCC
    
    
    
    
    
    > On 16 Jun 2020, at 15:36, Petrit Hasani <phasani _at_ ripe _dot_ net> 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://www.ripe.net/publications/docs/ripe-733#54
    > 
    > 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
    > 
    > 
    > 
    > 
    > 
    
    

    

ripedenis@yahoo.co.uk

2020-11-17 15:20:38 CET

 Hi Lee

With the current data model it is not possible to have two independent objects with the same primary key. Creating 2 smaller objects is a work around. Having 2 status attributes is another work around. The question is, which work around is preferable?
cheersdenis
co-chair DB-WG
    On Tuesday, 17 November 2020, 14:25:35 CET, Howard, Lee <leehoward _at_ hilcostreambank _dot_ com> wrote:  
 
 
That sounds like it would be confusing to me.
 
I’d want to see both the allocation to the LIR and the assignment to the end user independently.
 
  
 
Lee
 
  
 
From: address-policy-wg <address-policy-wg-bounces _at_ ripe _dot_ net>On Behalf Of ripedenis--- via address-policy-wg
Sent: Monday, November 16, 2020 7:57 AM
To: address-policy-wg _at_ ripe _dot_ net
Subject: [address-policy-wg] NWI-4 - role of status: field in multivalued status context -- Last call
 
  
 
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?
 
  
 
cheers
 
denis
 
  
 
co-chair DB-WG
 
  
 
On Monday, 5 October 2020, 16:48:34 CEST, ripedenis--- via address-policy-wg <address-policy-wg _at_ ripe _dot_ net> 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://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005242.html
 
  
 
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?
 
  
 
cheers
 
denis
 
  
 
co-chair DB-WG
 
  
 
  
 
On Monday, 5 October 2020, 16:13:53 CEST, Erik Bais <ebais _at_ a2b-internet _dot_ com> 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" <address-policy-wg-bounces _at_ ripe _dot_ net on behalf of phasani _at_ ripe _dot_ net> 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://www.ripe.net/ripe/mail/archives/address-policy-wg/2020-June/013195.html
    
    We look forward to hearing from you.
    
    Cheers,
    --
    Petrit Hasani
    Policy Officer
    RIPE NCC
    
    
    
    
    
    > On 16 Jun 2020, at 15:36, Petrit Hasani <phasani _at_ ripe _dot_ net> 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://www.ripe.net/publications/docs/ripe-733#54
    > 
    > 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
    > 
    > 
    > 
    > 
    >