[ppml] Metric for rejecting policy proposals: AC candidate question
>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:
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;
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"
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
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.