[ppml] Policy Proposal 2005-9: 4-Byte AS Number - revised text

[David Williamson]

I generally don't like posts of the "me too!" variety, but in this case
I think it's important to give a sense of the community's reaction.
So...I agree: I support this as re-written.

Thanks!

-David

On Sat, Feb 04, 2006 at 07:28:30PM -0500, Marshall Eubanks wrote:
> Thanks. (I knew there weren't many, which is why I wanted a diff.)
> 
> I support this as written.
> 
> Regards
> Marshall
> 
> On Feb 4, 2006, at 3:43 PM, Geoff Huston wrote:
> 
> > At 06:04 AM 4/02/2006, Marshall Eubanks wrote:
> >> Dear Geoff;
> >>
> >> Could you possibly send to the list a diff with the previous  
> >> version ?
> >>
> >> Regards
> >> Marshall
> >
> >
> > sure
> >
> > There are only 4 changes that have been applied - as noted below
> >
> >    Geoff
> >
> > ==========================================
> >
> > Policy Proposal 2005-9: 4-Byte AS Number
> >
> > Author: Geoff Huston
> >
> > Proposal Version: Revision 1 (February 3, 2006)
> >
> > Proposal type: modify
> >
> > Policy term: temporary
> >
> > Policy statement:
> >
> >       This policy proposal nominates 3 dates for changes to the
> >       current AS Number allocation policy for the registry:
> >
> > |     - Commencing 1 January 2007 the registry will process
> >
> > Global change "On 1 January" to "Commencing 1 January
> >
> > |       applications that specifically request 32-bit only AS Numbers
> >
> > Global change "4-byte" to "32-bit"
> >
> >         and allocate such AS numbers as requested by the applicant. In
> >         the absence of any specific request for a 32-bit only AS
> > |        Number, a 16-bit only AS Number will be allocated by the
> >
> > global change "2-byte" to "16-bit"
> >
> >         registry.
> >
> >       - Commencing 1 January 2009 the registry will process
> >         applications that specifically request 16-bit only AS Numbers
> >         and allocate such AS Numbers as requested by the applicant. In
> >         the absence of any specific request for a 16-bit only AS
> >         Number, a 32-bit only AS Number will be allocated by the
> >         registry.
> >
> >       - Commencing 1 January 2010 the registry will cease to make any
> >         distinction between 16-bit only AS Numbers and 32-bit only AS
> >         Numbers, and will operate AS number allocations from an
> >         undifferentiated 32-bit AS Number allocation pool.
> >
> >       Nomenclature
> >
> >       It is proposed to identify 32-bit AS Numbers using a syntax of
> > |     "<high order 16 bit value in decimal>.<low order 16 bit value in
> >
> > global change ":" to "."
> >
> >       decimal>". Accordingly, a 32-bit AS number of value 65546
> >       (decimal) would be identified as "1.10".
> >
> >
> >       Terminology
> >
> >       "16-bit only AS Numbers" refers to AS numbers in the range 0 -
> >       65535
> >
> >       "32-bit only AS Numbers" refers to AS Numbers in the range 1.0 -
> >       65535.65535 (decimal range 65,536 - 4,294,967,295)
> >
> >       "32-bit AS Numbers" refers to AS Numbers in the range 0.0 -
> >       65535.65535 (decimal range 0 - 4,294,967,295)
> >
> >
> > Rationale:
> >
> >       Recent studies of AS number consumption rates indicate that the
> >       existing 16-bit pool of unallocated AS Numbers will be exhausted
> >       sometime in the period between 2010 and 2016, absent of any
> >       concerted efforts of recovery of already-allocated AS Numbers
> >       [1] [2].  Standardization work in the IETF has produced a
> >       document that is currently being submitted as a Proposed
> >       Standard that will expand the AS Number space to a 32-bit field
> >       [3].
> >
> >       It is noted that some advance period may be required by network
> >       operators to undertake the appropriate procedures relating to
> >       support of 32-bit AS numbers, and while no flag day is required
> >       in the transition to the longer AS Number field, it is
> >       recognised that a prudent course of action is to allow for
> >       allocation of these extended AS numbers well in advance of an
> >       anticipated 16-bit AS Number exhaustion date.
> >
> >       This policy proposal details a set of actions and associated
> >       dates for RIR AS Number allocation policies to assist in an
> >       orderly transition to use of the 32-bit AS Number space.
> >
> >       The essential attributes of this policy proposal are to
> >       facilitate the ease of transitional arrangements by equipment
> >       vendors, network managers and network operations staff, to
> >       provide the industry with some predictability in terms of dates
> >       and associated actions with respect to registry operational
> >       procedures for AS Number allocations.
> >
> >       References
> >
> >       [1] Daily AS Number Report, http://www.potaroo.net/tools/asns
> >       [2] ASNs MIA: A Comparision of RIR Statistics and RIS Reality,
> >           http://www.nanog.org/mtg-0510/wilhelm.html
> >       [3] BGP Support for Four-octet AS Number Space,
> >           draft-ietf-idr-as4bytes-12.txt
> >
> >
> > Timetable for implementation:
> >
> >       Procedures to support this proposal need to be implemented by 1
> >       January 2007
> >
> >
> >
> 
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml