[ppml] Metric for rejecting policy proposals: AC candidate question

Heather,

>Last spring we looked at 2005-9 (4 Byte AS Numbers)   The policy 
>gives clear dates over the next 3 years and starting in January of 
>2007, for when ARIN should begin handing out 32 bit AS's and cease 
>to make a distinction between 32 bit and 16 bit AS's.  However there 
>is no RFC and only a Internet draft created last fall, that 
>discusses the creation of 4byte AS's.


You may find the following a helpful commentary on the IETF process, 
as it uses precisely this draft as its example: 
http://www.isoc.org/tools/blogs/ietfjournal/?p=66#more-66

The first internet draft on the topic, by Rekhter and Chen was 
submitted to the drafts editor back in September 2001. The current 
draft is at version 12. The IDR working group has had this on their 
agenda for 5 years, and 12 sets of revisions were made to the 
document over this period.

This is a document with a rich history of IETF peer review, and in 
the larger scheme of things, one of the few documents that has 
accumulated a very extensive review over the years.


>  It seemed to me that having the policy go through the local 
> registrar's process, was a bit premature considering that the draft 
> has not gone through the RFC process in IETF

The document was submitted to the Routing Area ADs back in December 
2005. It was an expectation at the time that publication would take 
months rather than years. Yes, it is most unfortunate that the 
document's progress through the IESG has been glacial, or even 
geological. IETF last call  was made in August and now its a case of 
awaiting the AD's write up. I do hope that this will occur within 
weeks rather than consuming further months of what I see as needless delay.

The run out date for AS numbers has been a pretty constant projection 
of October 2010 for some years now 
(http://www.potaroo.net/tools/asns/), and the industry appears to be 
competing with this IETF Routing Area AD as to who can be slower in 
getting things done these days. We have around three years. If we are 
forced to wait for everything to happen in serial fashion then I'm 
concerned that we will be caught out.

>  and that no hardware supports it.


Please see http://www.ietf.org/IESG/Implementations/bgp4_impleme.txt

The vendors whose hardware supports 4 byte AS numbers in BGP are;

Juniper
Redback

If your vendor is not in the above list then you should talk to them 
and ask why not.


>  This is a case, where I would have liked to see the AC refer the 
> author to the IETF process to flesh things out a bit more,


The policy proposal's author has some knowledge of the IETF process, 
having been an active participant in the IETF since 1989, although 
not even the author truly appreciated how long a period can elapse 
these days between working group sign off (October 2005) and 
publication of an RFC (nothing yet in 12 months) with the document 
sitting in the Routing Area Director's lap throughout most of that 
time. Obviously, anyone claiming that the IETF process is fast and 
efficient these days has not tried to publish a document using its 
processes. Despite this geological pace of progress in the IETF, that 
does not negate the overall intention of the policy proposal to 
provide industry with good advance notice of a change in AS number 
syntax, and allow folk to plan ahead for this, rather than run around 
in a paniced blame-shift mode after the exhaustion event wondering 
what went wrong  - again.


>  and if necessary with a nod that "we support this idea" ..

Experience suggest that such a nod  would appear to have little 
impact on the speed of the IETF process, nor the outcome.

>As it is now, ARIN can start handing out 32 bit AS's in a little 
>more than 3 months and the draft is still a "proposed standard" 
>"waiting for write up"
>
><https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=6498>https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=6498

I agree that it would be strongly preferable to see this document 
published as a Proposed Standard rather than a draft. And it would be 
strongly preferable for this to have already been published yesterday 
rather than some vague and uncommitted "tomorrow."

Working with the document authors to produce the implementation 
report, and advocating within the working group at the start of 2005 
that the document was ready for publication as a Proposed Standard, 
were the activities undertaken by the proposal's author that were 
intended to ensure that this IETF publication step was completed well 
before the present time.

I'm appalled at the apparent moribund state of parts of the IETF such 
that you now have to allow up to a 24 month lead time after IETF 
working group consensus to get a relatively innocuous document, with 
a three year working group review period, published through the 
Routing Area of the IETF. It was not what I had anticipated. Nor, 
might I add, would many others anticipate, or truly appreciate,  such 
protracted delays within the IETF process these days.

>
>The AC, ARIN and the NRPM are just one part of community that guides 
>the use of number resources.  It seems a responsible thing to do, to 
>evaluate policy proposals with consideration for the 
>responsibilities of other resources involved, whether it's IETF, 
>IANA, ICANN, other registrar's, the Board of Trustees, or ARIN 
>staff, and to refer the author or policy to another organization 
>when appropriate.


The author of the policy proposal was, and is, mindful of all of 
these considerations. The author is also mindful of the finite nature 
of the 16 bit AS number pool. The author is mindful of the rate of 
consumption of this resource. The author is mindful of the advance 
notice to vendors required to get any new functionality into deployed 
BGP, particularly so when the new functionality has marginal 
relevance to MPLS signalling. And the author is mindful of the 
critical role of the Internet today and the natural desire of network 
operators not to make changes to the infrastructure without careful 
testing and evaluation to ensure that such changes will not bring the 
entire structure, or even a small part of this structure, down.

When I proposed this policy around a year ago it seemed that the 
policy's timelines allowed more than ample time to consider the 
policy and more than ample time for the IESG to consider, and 
publish, the 4 byte AS number draft. At the time both were relatively 
conservative expectations, based on previous direct experience of 
having RFCs published through this process.

But, alas, the best of intentions and the most careful planning are 
sometimes just not sufficient, as you have observed.

kind regards,

   Geoff Huston