[arin-ppml] Policy Proposal: Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries

[David Williamson]

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.