This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] 2013-03: Summary of amendments for version 3.0
- Previous message (by thread): [address-policy-wg] 2013-03 Review Period extended until 14 August (No Need - Post-Depletion Reality Adjustment and Cleanup)
- Next message (by thread): [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tore Anderson
tore at fud.no
Wed Aug 7 15:24:05 CEST 2013
Hi APWG, As you all know, during the Review phase a couple of potentially problematic issues in the proposal was brought up, which I've offered to improve on by amending the proposal. I want to detail the individual amendments and how they impact the proposal, so that you can all review them before we send the new version of the proposal back to the NCC. I welcome your opinions on the amendments, but please also realise it is not an invitation to bikeshedding - I'm trying to find a middle ground the WG will find acceptable, not necessarily perfect. In doing so I hope that we can ensure that we won't be sending Emilio off on a wild goose chase when we ask him to create a new Impact Analysis - so if you are completely unable to live with any of this, then do speak now or forever hold your peace. I'd like to especially thank Filiz Yilmaz and Malcom Hutty for highlighting and elaborating on the issues that resulted in the first two amendments, and to Andrea, Emilio, and Marco from the NCC for collaborating with me on writing the texts of the last two amendments and confirming that there will be no misunderstandings as to their intent and interpretation. Amendment 1: Retain "Fairness" goal =================================== This amendment retains our community's overall philosophical and moral goal of fair distribution of IPv4 address space to end users operating networks. Our current IPv4 policy lumps together a "Fairness" and a "Conservation" goal (unlike our IPv6 policy, which separates the two). Seeking only to remove the latter, the current version of 2013-03 accidentally removed the former as well. The amendment makes no attempt to define what constitutes "fair distribution" in our current environment of scarcity - this will remain a value judgement each LIR has to make for themselves, just like it is today. The benefits of this amendment include: * Avoids throwing the baby out with the bathwater. * Guides LIRs to assign address space to end users who are operating networks, as well as to base any value judgement they would need to make related to this on their own notion of fairness. * Ensures that we keep the door open for a potential future discussion on how to define and possibly enforce fair distribution in an environment of scarcity. * Provides "ammunition" for the NCC in their talks and interactions with critical governments, regulators, or similar entities. The exact amendment, which is to be inserted into section 3.0 of the proposed policy, reads: «Fairness: Public IPv4 address space must be fairly distributed to the End Users operating networks.» Note that except for the title, this is the exact same phrase as is found in our current policy. This is fully intentional, as 2013-03 has no ambition to alter previously agreed upon consensus in this regard. I chose the title "Fairness" to match the one used in the IPv6 policy document (ripe-589). Amendment 2: Retain "Need" for final /22 allocations ==================================================== This amendment retains the current practice of requiring the LIRs that seek to obtain their final /22 from the austerity ("last /8") allocation pool to use it for making assignments to their end users or their own infrastructure. This is not in conflict with 2013-03's "No Need" moniker, as changing the "last /8 policy" is not its ambition. That the current version of the proposal does so was only due to a layer of indirection, in which the "last /8" policy made a reference to the "old policy" which 2013-03 did remove as part of its overall clean-up efforts. In practical terms, the amendment will result in a "check box" or a "yes/no" question in the allocation request form, where LIRs would be required to declare this to be their intent in order to receive the allocation. This interpretation has been confirmed by the NCC. The benefits of this amendment include: * Ensures our RIR-to-LIR allocation policy remains pursuant to the "Fairness" goal described in amendment 1. * Avoids any confusion leading to an impression that 2013-03 would make the RIPE NCC start to "sell IPv4 addresses". This in turn leads to the following benefits: -- Alleviates concerns that the RIPE NCC may lose its status as a non-profit membership association with the Dutch tax authorities, -- Shields the NCC from some of the legal concerns and impacts noted in the current Impact Analysis' EU Competition Law report, -- Provides "ammunition for the NCC in their talks and interactions with critical governments, regulators, or similar entities. * Ensures the proposed policy remains as much in line with RFC 2050bis' Allocation Pool Management goal as our current policy is. * Prevents LIRs from obtaining their last /22 for other purposes than "networking"; in particular re-sale, stockpiling, or hoarding. This amendment reads as follows, and is to be inserted as a new bullet point in the proposed policy's section 5.1: «The LIR must confirm it will make assignment(s) from the allocation» Amendment 3: Clarify criteria for IXP assignment expansions =========================================================== The NCC noted in its Impact Analysis for the current version of the proposal that the precise criteria for when an IXP may request an expansion of its peering LAN assignment from "last /8 IXP assignments" was lost and thus left undefined. This was unintentional and happened due to the exact same "layer of indirection" problem described above. As 2013-03 has no ambition to change the "last /8 policy", including the parts specific to IXPs, and the proposed amendment seeks only to document and uphold the status quo. The argument in favour of this amendment is of course to ensure we continue to provide the NCC and its hostmasters with clear guidance on how our policies should be implemented. The amendment will be inserted into section 6.1, replacing the fourth bullet point, and reads as follows: «New IXPs will be assigned a /24. Should they require a larger assignment, they must return their current assignment (or existing PI used as an IXP peering LAN) and receive a replacement /23 or /22. After one year the utilisation of the new assignment must be at least 50%, unless special circumstances are defined» The RIPE NCC has confirmed that this text accurately describes today's practice, and that it will merely uphold the current status quo. The amendments are also attached in unified diff format. Best regards, Tore Anderson -------------- next part -------------- --- 2013-03-v2.txt 2013-08-06 21:25:31.425520553 +0200 +++ 2013-03-v3pre.txt 2013-08-07 15:15:44.614150212 +0200 @@ -127,7 +127,9 @@ 2. Aggregation: Distributing IPv4 addresses in an hierarchical manner permits the aggregation of routing information. This helps to ensure proper operation of Internet routing. - 3. Registration: The provision of a public registry documenting address + 3. Fairness: Public IPv4 address space must be fairly distributed to + the End Users operating networks. + 4. Registration: The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels. @@ -178,7 +180,8 @@ 2. The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof). - 3. Allocations will only be made to LIRs if they have already received an + 3. The LIR must confirm it will make assignment(s) from the allocation. + 4. Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC. @@ -313,9 +316,11 @@ * IXPs holding other PI IPv4 space for their peering LAN (i.e. they are seeking a larger assignment), must return their old peering LAN resources back to this pool within 180 days of assignment. - * New IXPs will be assigned a /24. IXPs may return this /24 (or existing - PI used as an IXP peering LAN) should they run out of space and - receive a larger (/23, or /22 if utilisation requires) assignment. + * New IXPs will be assigned a /24. Should they require a larger + assignment, they must return their current assignment (or existing PI + used as an IXP peering LAN) and receive a replacement /23 or /22. After + one year the utilisation of the new assignment must be at least 50%, + unless special circumstances are defined. * IP space returned by IXPs will be added to the reserved pool maintained for IXP use. * Assignments will only be made to IXPs who have already applied for, or
- Previous message (by thread): [address-policy-wg] 2013-03 Review Period extended until 14 August (No Need - Post-Depletion Reality Adjustment and Cleanup)
- Next message (by thread): [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]