From phasani at ripe.net Tue Jun 9 10:33:18 2020 From: phasani at ripe.net (Petrit Hasani) Date: Tue, 9 Jun 2020 10:33:18 +0200 Subject: [address-policy-wg] RIPE 80 Address Policy WG Draft Minutes Message-ID: Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 80 have now been published: https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-80-address-policy-working-group-minutes Please let us know of any corrections or amendments. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From phasani at ripe.net Tue Jun 9 10:34:34 2020 From: phasani at ripe.net (Petrit Hasani) Date: Tue, 9 Jun 2020 10:34:34 +0200 Subject: [address-policy-wg] RIPE 80 Address Policy WG Draft Minutes Message-ID: Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 80 have now been published: https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-80-address-policy-working-group-minutes Please let us know of any corrections or amendments. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From gert at space.net Wed Jun 10 08:21:20 2020 From: gert at space.net (Gert Doering) Date: Wed, 10 Jun 2020 08:21:20 +0200 Subject: [address-policy-wg] RIPE 79 Address Policy WG Draft Minutes In-Reply-To: <634663B1-52EA-4301-B025-4691BADF97C0@ripe.net> References: <634663B1-52EA-4301-B025-4691BADF97C0@ripe.net> Message-ID: <20200610062120.GE2485@Space.Net> Dear Working Group, On Tue, May 12, 2020 at 03:12:06PM +0200, Petrit Hasani wrote: > The draft minutes from the Address Policy Working Group sessions at RIPE 79 have now been published: > > https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-79-address-policy-working-group-minutes > > > Please let us know of any corrections or amendments. Only one comment was received, and that was "looks good to me" :-) With that, I declare the minutes final. thanks, Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From phasani at ripe.net Tue Jun 16 15:36:39 2020 From: phasani at ripe.net (Petrit Hasani) Date: Tue, 16 Jun 2020 15:36:39 +0200 Subject: [address-policy-wg] IPv4 status hierarchies Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From apwg at c4inet.net Tue Jun 16 15:57:29 2020 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 16 Jun 2020 14:57:29 +0100 Subject: [address-policy-wg] IPv4 status hierarchies In-Reply-To: References: Message-ID: <20200616135729.GF2680@cilantro.c4inet.net> 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 From ripedenis at yahoo.co.uk Wed Jun 17 04:22:05 2020 From: ripedenis at yahoo.co.uk (ripedenis at yahoo.co.uk) Date: Wed, 17 Jun 2020 02:22:05 +0000 (UTC) Subject: [address-policy-wg] IPv4 status hierarchies In-Reply-To: <20200616135729.GF2680@cilantro.c4inet.net> References: <20200616135729.GF2680@cilantro.c4inet.net> Message-ID: <44738873.3296075.1592360525644@mail.yahoo.com> 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] 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo at vegoda.org Wed Jun 17 23:07:22 2020 From: leo at vegoda.org (Leo Vegoda) Date: Wed, 17 Jun 2020 14:07:22 -0700 Subject: [address-policy-wg] IPv4 status hierarchies In-Reply-To: References: Message-ID: Hi, Thanks for raising this. On Tue, Jun 16, 2020 at 6:36 AM Petrit Hasani 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