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

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

Fred,

I will respond respectfully this weekend I cannot right now thanks for
the response good to get your input discussed  from my input to addcon.
One quick comment is things have changed in some markets since those old
days and that is IPv6 dominant deployment in the world we worked in you
describe below thus ISATAP is not seen as advantage and is asked not to
be used today. This all goes back to killing the NGNTRANS group which
was years ago IMHO I have always supported ISATAP as vehicle for
transition but the IETF sees it different the only reason 6to4 is PS
IMHO is because it came in under the radar before the new views on
transition mechanisms, and note 6to4 is also declared to not be used by
that market we worked in today either.  And as always this is business
not personal and I know you know that.

Best,
/jim 

> -----Original Message-----
> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] 
> Sent: Thursday, April 05, 2007 11:57 AM
> To: Bound, Jim
> Cc: v6ops@ops.ietf.org
> Subject: 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
>