[arin-ppml] Policy Proposal: Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries
Stacy Hughes
ipgoddess.arin at gmail.com
Thu Jun 4 14:48:05 EDT 2009
It has already been submitted in the RIPE and APNIC regions with the
language I submitted here.Stacy
On Wed, Jun 3, 2009 at 1:35 PM, Owen DeLong <owen at delong.com> wrote:
> I don't believe this has been submitted to any of the other RIRs
> as yet, so, I think that the change I proposed would not slow it down.
> In fact, I think it might actually help it get through faster.
>
> Owen
>
>
> On Jun 1, 2009, at 8:52 AM, David Williamson wrote:
>
> I support the policy as written. I think Owen has a great idea, but
>> the timeline is a problem for changes. It would be possible to start a
>> new policy to correct this one with Owen's suggested changes, but let's
>> fast track this one *as is*.
>>
>> I'd even support this as written if it was declared to be a Board
>> response to an emergency. Unless there are compelling arguments in
>> dissent, this should simply move forward.
>>
>> -David
>>
>> On Fri, May 29, 2009 at 03:01:35PM -0500, Scott Leibrand wrote:
>>
>>> One thing to keep in mind here is that, because this is a Global Policy,
>>> and because of the extremely tight timeframe, we need to agree on the
>>> text of the proposal right away, and make sure the same text gets put
>>> forward in each region. Even if everyone approves it their first time
>>> around, and LACNIC approves it through their fast-track process (since
>>> it'll be exactly a year until their next meeting), we're still looking
>>> at sometime in 2010 before the policy can be ratified by the ASO-AC and
>>> ICANN. That will mean we will have several months (at least) of RIRs
>>> being unable to get more 16-bit ASNs from the IANA before this policy
>>> could go through and make it possible again. I've heard some very good
>>> arguments in the last week that the simpler we make the change, the less
>>> likely we are to run into problems that cause delays in getting this
>>> approved in time for it to be useful...
>>>
>>> How important do you think it is to preserve the 16bit/32bit ASN
>>> distinction past 1 Jan 2011? Is it worth the increased risk of delay in
>>> passing such a revised global policy?
>>>
>>> (As you probably figured out from my comments above, I personally
>>> support this policy.)
>>>
>>> -Scott
>>>
>>> Owen DeLong wrote:
>>>
>>>> While I do not support changing the RIR policy on the issuance of ASNs,
>>>> I do support this policy proposal. I think that modifying the IANA->RIR
>>>> distribution rules to accommodate the needs of RIRs to better serve
>>>> their
>>>> constituents makes sense. Further, having 16-bit ASNs trapped in the
>>>> IANA free pool because 32-bit ASNs are not being accepted by recipients
>>>> is absurd and poor stewardship. We should go ahead and issue 16-bit
>>>> ASNs until they run out.
>>>>
>>>> I would suggest that this proposal, rather than removing the distinction
>>>> in 2010 should be modified to extend the IANA->RIR duality until such
>>>> time as there are no more 16-bit ASN blocks in the IANA pool.
>>>>
>>>> Owen
>>>>
>>>> On May 29, 2009, at 8:11 AM, Member Services wrote:
>>>>
>>>> ARIN received the following policy proposal and is posting it to the
>>>>> Public Policy Mailing List (PPML) in accordance with Policy Development
>>>>> Process.
>>>>>
>>>>> This proposal is in the first stage of the Policy Development Process.
>>>>> ARIN staff will perform the Clarity and Understanding step. Staff does
>>>>> not evaluate the proposal at this time, their goal is to make sure that
>>>>> they understand the proposal and believe the community will as well.
>>>>> Staff will report their results to the ARIN Advisory Council (AC)
>>>>> within
>>>>> 10 days.
>>>>>
>>>>> The AC will review the proposal at their next regularly scheduled
>>>>> meeting (if the period before the next regularly scheduled meeting is
>>>>> less than 10 days, then the period may be extended to the subsequent
>>>>> regularly scheduled meeting). The AC will decide how to utilize the
>>>>> proposal and announce the decision to the PPML.
>>>>>
>>>>> In the meantime, the AC invites everyone to comment on the proposal on
>>>>> the PPML, particularly their support or non-support and the reasoning
>>>>> behind their opinion. Such participation contributes to a thorough
>>>>> vetting and provides important guidance to the AC in their
>>>>> deliberations.
>>>>>
>>>>> The ARIN Policy Development Process can be found at:
>>>>> https://www.arin.net/policy/pdp.html
>>>>>
>>>>> Mailing list subscription information can be found
>>>>> at:https://www.arin.net/mailing_lists/
>>>>>
>>>>> Regards,
>>>>>
>>>>> Member Services
>>>>> American Registry for Internet Numbers (ARIN)
>>>>>
>>>>>
>>>>> ## * ##
>>>>>
>>>>>
>>>>> Policy Proposal: Internet Assigned Numbers Authority (IANA) Policy for
>>>>> Allocation of ASN Blocks (ASNs) to Regional Internet Registries
>>>>>
>>>>> Proposal Originator: Stacy Hughes and Andrew de la Haye
>>>>>
>>>>> Proposal Version: 1.0
>>>>>
>>>>> Date: 29 May 2009
>>>>>
>>>>> Proposal type: modify
>>>>>
>>>>> Policy term: permanent
>>>>>
>>>>> Policy statement:
>>>>>
>>>>> Modification of NRPM section 10.3 extending the deadline for an
>>>>> undifferentiated ASN pool by 1 year to read:
>>>>>
>>>>> 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 2010,
>>>>> allocations of 16-bit and 32-bit only ASN blocks will be made
>>>>> separately
>>>>> and independent of each other [1].
>>>>>
>>>>> This means until 31 December 2010, RIRs can receive two separate ASN
>>>>> blocks, one for 16-bit ASNs and one for 32-bit only ASNs from the IANA
>>>>> under this policy. After this date, IANA and the RIRs will cease to
>>>>> make
>>>>> any distinction between 16-bit and 32-bit only ASNs, and will operate
>>>>> ASN allocations from an undifferentiated 32-bit ASN allocation pool.
>>>>>
>>>>> Rationale:
>>>>>
>>>>> a. Arguments supporting the proposal
>>>>>
>>>>> Due to operational issues external to the IANA/RIR policy process,
>>>>> 32-bit only ASNs are not being issued by the RIRs at the anticipated
>>>>> rate. As it stands, RIRs will likely not be able to justify a new block
>>>>> of ASNs from the IANA after 31 December 2009 due to a glut of free 32
>>>>> bit only ASNs in the RIR’s pool. This leaves available, essential
>>>>> 16-bit
>>>>> ASNs stranded in the IANA free pool. This proposal seeks to remedy the
>>>>> potential problem by extending the deadline for differentiation by one
>>>>> year.
>>>>>
>>>>> With this proposal the policy will be aligned with the actual reality
>>>>> in
>>>>> regards to 32-bit ASN deployment and usage.
>>>>>
>>>>> The subject was raised during RIPE 58 and a presentation was made:
>>>>>
>>>>> http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf
>>>>>
>>>>>
>>>>> The feedback in this session suggested that a global policy proposal
>>>>> should be developed and should be discussed.
>>>>>
>>>>> b. Arguments opposing the proposal
>>>>>
>>>>> Some may think that extending the previously set timeline can be
>>>>> perceived as some discouragement for the deployment of 32-bit ASNs. One
>>>>> counter argument to this is that RIRs and Internet community have some
>>>>> other mechanisms and activities to raise awareness for 32-bit ASN pool
>>>>> (via public presentations and trainings). These activities will
>>>>> continue
>>>>> while 16-bit ASN blocks are still allocated to RIRs by the IANA as they
>>>>> are available and they are needed.
>>>>>
>>>>> Timetable for implementation: Immediately upon ratification by ICANN
>>>>> Board
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> PPML
>>>>> You are receiving this message because you are subscribed to
>>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>>> Unsubscribe or manage your mailing list subscription at:
>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>>> Please contact info at arin.net if you experience any issues.
>>>>>
>>>>
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>>
>>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090604/20872f01/attachment.htm>
More information about the ARIN-PPML
mailing list