RE: Request to Publish ISATAP

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

Margaret,

I concur with Christian Huitema's comments and agree.  This work should
be moved to Experimental RFC so the code can be solidified and tested.
As Christian stated the bar should be far less than standards track.  I
do not support your mail stating Fred wanted to go to standards track
but only experimental.

I also did not see anything in draft -08 that alters Neighbor Discovery
or our base Transitioin Mechanism for auto-tunnels (which I support
being removed).

ISATAP is being deployed in the v6 test beds currently and lets get all
to do the latest experimental RFC and see what develops.  

Regards,
/jim

 


> -----Original Message-----
> From: Margaret Wasserman [mailto:mrw@windriver.com] 
> Sent: Monday, December 23, 2002 7:13 PM
> To: v6ops@ops.ietf.org
> Cc: itojun@iijlab.net; Bob Fink; Randy Bush
> Subject: Request to Publish ISATAP
> 
> 
> 
> Hi All,
> 
> On December 13th, the OPS and Internet area directors 
> received a request to sponsor ISATAP as a standards track 
> RFC, obsoleting the automatic tunneling mechanism specified 
> in RFC 2893 (see attached).  ISATAP would be submitted to the 
> RFC editor for publication as an individual submission.
> 
> Since that time, ISATAP has been updated.  The newest version 
> can be found at:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-08.txt
> 
> Consistent with IESG policy, our area director has asked the 
> chairs of the v6ops WG whether the publication of this 
> document would constitute an end-run around the v6ops WG.
> 
> The v6ops chairs do believe that the publication of this 
> document would represent an end-run for two reasons:
> 
> 	(1) It is proposed that ISATAP would obsolete a portion
> 		of RFC 2893.  The v6ops WG is currently updating
> 		RFC 2893, and it will be our decision whether or
> 		not to remove the automatic tunneling mechanism.
> 		ISATAP does not, and should not, obsolete that
> 		mechanism.
> 
> 	(2) The v6ops WG is currently undergoing a process
> 		to enumerate and analyze the expected scenarios
> 		for IPv4 -> IPv4/IPv6 transition, with the
> 		goal of producing a single, coordinated set
> 		of transition mechanisms, each of which will
> 		include appropriate applicability information.
> 		The publication of a transition mechanism via
> 		another track, before its applicability is
> 		analyzed, would undermine this effort.
> 
> The v6ops chairs will be expressing this opinion to the IESG
> in one week.  We wanted the WG to be aware of this situation, 
> and we would welcome your feedback regarding our position.
> 
> Thanks,
> Margaret and Itojun
> v6ops Chairs
> 
> ---
> 
> From: Fred Templin <osprey67@yahoo.com>
> To: randy@psg.com, bwijnen@lucent.com, narten@us.ibm.com,
>    erik.nordmark@sun.com
> Cc: harald@alvestrand.no, tgleeson@cisco.com, mohitt@microsoft.com,
>    dthaler@microsoft.com, osprey67@yahoo.com
> Subject: Plea to ADs to sponsor isatap-07 for standards track
> Date: Fri, 13 Dec 2002 21:32:48 -0800 (PST)
> 
> 
> To the Operations & Management, and Internet Area Directors,
> 
> 
> Today (12/13/02), 'draft-ietf-ngtrans-isatap-07.txt' was 
> submitted to the Internet Draft registrar. The document is 
> available for immediate perusal at:
> 
> 
   http://www.geocities.com/osprey67/isatap-07.txt


In the spirit of Harald Alvestrand's 11/19/02 message to v6ops entitled
"On NGTRANS, transition mechanisms and consortia", I am issuing a plea
to the ADs to sponsor this document for standards track based on the
obvious merit that it obsoletes the automatic tunneling mechanisms
specified in RFC 2893.


I look forward to receiving your feedback and guidance
in this matter,


Sincerely,


Fred L. Templin
osprey67@yahoo.com