[ppml] Policy Proposal 2007-19 - Staff Assessment
Member Services
info at arin.net
Sun Oct 14 18:43:29 EDT 2007
- Previous message: [ppml] IPv6 assignment - proposal for change to nrpm
- Next message: [ppml] Policy Proposal 2007-19 - Staff Assessment
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Policy Proposal 2007-19 IANA Policy for Allocation of ASN Blocks to RIRs ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_19.html II. Understanding of the proposal ARIN staff understands that this proposal is a global proposal. It would create policy for IANA to RIR regarding allocations of ASNs. Block size is 1024. Allocations for 12 months need. Until 31 Dec 2009, allocations of 2-byte and 4-byte blocks are separate. RIRs request additional ASNs when either at 80% or at less than two months need. III. Comments A. ARIN Staff 1. The “Additional Allocations” section indicates an RIR can receive an additional ASN allocation when the RIR “has assigned/allocated 80% of the previously received ASN block”. After 12/31/2009, there will be no distinction made between 2 byte AS numbers and 4 byte AS numbers per policy. Does “previously received ASN block” literally mean the most recent ASN block (even if it was a 2 byte only block), or does it mean 80% of both the most recent 4 byte block and the most recent 2 byte block? If it’s the latter, one ASN block would never be audited, since it would never be “the most recent ASN block allocated”. 2. The policy will be inserted in Section 10 of the NRPM. B. ARIN General Counsel "Counsel has no legal concerns regarding this policy. Counsel believes policies allocating resources based on usage and need are consistent with the operating philosophy of the RIR Community. Other policy proposals, inconsistent with this philosophy should be subject to greater scrutiny." Resource Impact – Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 30 - 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Guidelines will be required - Staff training will be required Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-19 IANA Policy for Allocation of ASN Blocks to RIRs Author: Axel Pawlik Proposal type: New Policy term: renewable Policy statement: Abstract This document describes the policy governing the allocation of Autonomous System Numbers (ASNs) from the IANA to the Regional Internet Registries (RIRs). This policy document does not stipulate performance requirements in the provision of services by the IANA to an RIR. Such requirements will be specified by appropriate agreements between ICANN and the Number Resource Organization (NRO). 1. Allocation Principles IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2009, allocations of 2-byte only and 4-byte only ASN blocks will be made separately and independent of each other [1]. This means until 31 December 2009, RIRs can receive two separate ASN blocks, one for 2-byte only ASNs and one for 4-byte only ASNs from the IANA under this policy. After this date, IANA and the RIRs will cease to make any distinction between 2-byte only and 4-byte only ASNs, and will operate ASN allocations from an undifferentiated 4-byte ASN allocation pool. 2. Initial Allocations Each new RIR will be allocated a new ASN block. 3. Additional Allocations An RIR is eligible to receive (an) additional ASN block(s) from the IANA if one of the following conditions is met: 1. The RIR has assigned/allocated 80% of the previously received ASN block, or 2. The number of free ASNs currently held by the RIR is less than two months need. This projection is based on the monthly average number of ASNs assigned/allocated by the RIR over the previous six months. An RIR will be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months, based on their average assignment/allocation rate over the previous six months, unless the RIR specifically requests fewer blocks than it qualifies for. 4. Announcement of IANA Allocations The IANA, the NRO and the RIRs will make announcements and update their respective websites/databases when an allocation is made by the IANA to an RIR. ICANN and the NRO will establish administrative procedures to manage this process. [1. http://www.ripe.net/ripe/policies/proposals/2005-12.html] Policy Rationale Rationale: There are global policies governing the allocation of IPv4 and IPv6 blocks from the IANA to RIRs. At this point there is no specific policy regarding the allocation of Autonomous System Numbers from the IANA to the RIRs. This proposal will create a policy to fill this gap. The criteria being proposed has already been the practice between IANA and RIRs so far and it has been proven to work. It is designed to allow RIRs to request ASN blocks from the IANA in a timely fashion and maintain enough ASNs in holding to ensure that their registration services can be sustained. It is also proposed that the RIRs be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months. This will generally mean that each RIR will only need to make one ASN request from the IANA each year, thus lowering operational overhead for the RIRs. Timetable for implementation: Immediate
- Previous message: [ppml] IPv6 assignment - proposal for change to nrpm
- Next message: [ppml] Policy Proposal 2007-19 - Staff Assessment
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the PPML mailing list