[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RAM] Request to advance RFC4214 to Proposed Standard
On Mar 25, 2007, at 11:43 AM, Brian E Carpenter wrote:
Speaking as a long time participant in ngtrans/v6ops, I believe
this request should only be addressed via v6ops, which, if I recall
correctly, has as its established consensus to progress no more
IPv6 coexistence techniques.
I'm not saying that consensus can't be changed, but until it is,
I'd be against AD sponsoring of this request (without any comment
on the merits of this or other proposed additional coexistence
Fred, Brian, Jari, Ron:
Fred, let me start out by saying I don't want to give you a run-
around, which I have a hunch you might feel you are getting.
IPv6 Operations' charter (http://www.ietf.org/html.charters/v6ops-
charter.html) states that "The main focus of the v6ops WG is to look
at the immediate deployment issues; more advanced stages of
deployment and transition are a lower priority." My instructions from
Ron's predecessor are that discussion of flavor-of-the-month
transition/coexistence strategies had the effect of rat-holing all
progress in v6ops, and "low priority" should be read "out of scope".
Ron is free to tell me that he has a different interpretation.
I think that if IPv6 Operations were to take the matter of bringing
ISATAP to Proposed Standard up, I would want to know more than that
"we coded it up and it seemed to mostly work", which is formally the
requirement of RFC 2026:
The IESG may require implementation and/or operational experience
prior to granting Proposed Standard status to a specification that
materially affects the core Internet protocols or that specifies
behavior that may have significant operational impact on the
A Proposed Standard should have no known technical omissions with
respect to the requirements placed upon it. However, the IESG may
waive this requirement in order to allow a specification to advance
to the Proposed Standard state when it is considered to be useful
necessary (and timely) even with known technical omissions.
noting that ISATAP becomes a way to dynamically create topology of a
type and becomes an interesting way to hide various things, I would
wonder about the operational impact along the lines of the first
As a result, I would want to know who had implemented it, whether
interoperability had been established, whether (as is routinely done
with routing protocols) there has been field testing that establish
the operational utility of the technology, and so on. In short, this
is not just "an" approach to coexistence; if the IPv6 Operations
Working Group is going to put its imprimatur on a technology, I would
want to know that we were recommending the *right* one. Note that we
have just gotten through saying that NAT-PT was actually *not* the
right one although the IETF previously said it was, and Teredo has
been given that imprimatur by someone other than this working group.
This is in the context of comments previously made to the effect that
if ISATAP goes to Proposed Standard, then there are a list of
protocols that want to make the same status change. From my
perspective, I would rather say nothing than say the wrong thing. I
don't get any more gumdrops in my Christmas stocking for producing
Proposed Standards, but when I do I get more questions from the press
and from customers regarding why the status is there. I need to be
able to clearly answer the questions.