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

["Bound, Jim" <Jim.Bound@hp.com>]

Fred,

Responses in line. 

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

I did not say for the purposes of addcon it is not a widely implemented
transition mechansism. ISATAP as 6to4 are widely implemented.  But, I do
not agree that ISATAP or 6to4 are so widely deployed that they warrant
an interface identification note within addcon specification.  If addcon
wants to add a section to discuss transition interfaces it needs to add
these I agree but then there others that must be added for VPNs and
Tunneling semantics.

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

I have no comment at this time for this mail thread on that topic.  But,
I have had experience in the IETF recently where the norm is for the
IESG to not support references that state IETF support or imply that
support for Experimental RFCs.  If that is not the case then that would
be good to know for me.

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

Anytime a node tunnels packets to support a virtualized state such as
ISATAP does to support neighbor discovery has notes that should be
stated.  That is what I mean by health warnings.  For example nodes
should not be using this mechanism to subvert the addressing policy and
use of IPv6 communications without be authorized, etc.  

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

Again this is not the issue I raised for addcon.

> 
> > But I do not see the point of adding Section
> > 3.3.3 it is an IPv6 Transition issue.
> 
> 1,$ s/transition/coexistence/g

Nor coexistence.

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

Response to this is above.

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

Yes I made an assumption here from 2529 and ISATAP clearly states to not
use multicast.

Best,
/jim

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