Re: [RAM] Request to advance RFC4214 to Proposed Standard

[Fred Baker <fred@cisco.com>]

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  
> techniques).

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
   Internet.

   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  
and
   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  
paragraph above.

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.