[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: I-D ACTION:draft-ietf-v6ops-addcon-03.txt



Jim,

> > 3.3.3.  ISATAP addresses
> > 
> 
> This is an IETF Experimental RFC and should not be part of 
> this spec and
> if it is kept requires health warnings that this spec was not accepted
> as a Proposed Standard.

You know I respect you, and that goes way back to when I was
hearing good things about you from the folks at LTN, LJO and
BXB before you arrived at ZKO. But, let's quit pretending about
this; ISATAP is in widely-deployed implementations and is useful
for automatic tunneling within sites both large and small, both
static and mobile, and both managed and ad-hoc. In fact, I was
demonstrating ISATAP in MANETs in 2000/2001, and I know that
the predecessors of ISATAP were demonstrated long before that.

About standards-track for ISATAP, that is long overdue, and
we are working to fix that as we speak.

About health warnings, if there were anything unhealthy about
ISATAP we would have heard about it long before now. I think
it's high time we deem this "experiment" a success, declare
victory and move on.

Based on what I saw in Prague, IMHO we are doing a new breed
of Internet engineers a disservice by leading them to believe
there is still a problem to be solved when we already have
the solution at hand.  

> But I do not see the point of adding Section
> 3.3.3 it is an IPv6 Transition issue.

1,$ s/transition/coexistence/g

> In addition there is precedence
> within the IESG to not declare non proposed standard transition
> mechanisms in our v6ops specs.

We already have a specification for the use of embedded IPv4
addresses in the IETF OUI of "00-00-5e" and I don't see that
going away; "ISATAP addresses" is just a convenient and
well-recognized way to call them. 

> It also assumes a wide deployed IPv4
> multicast network and that is not the norm either and we 
> should not add
> new IPv4 requirements where they don't exist for IPv6 when possible.

About multicast, I think you have this mixed up with RFC2529
which is more or less superceded by ISATAP.

Thanks - Fred
fred.l.templin@boeing.com