Subject: Re: (ngtrans) Comments on 'draft-ietf-ngtrans-mech-v2-00.txt'

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 29 Jul 2002 11:57:23 -0700

Bound, Jim wrote:
> Fred,
> 
> Though I support ISATAP. It is not in the same league with wide implementation or IETF consensus to be mentioned in this core work.  ISATAP is on hold with other mechanisms till we get the scenarios done.  Implementors build it at their own risk and some are (as some are building DSTM and deploying it too).

Re-read my message; my arguement is that this document should not
mention *any* other tunneling techniques - ISATAP included.

> But I take your mail to assume ISATAP is a done deal?  Its is not.

I don't know how you were able to mis-interpret my message in this
way. Again, re-read the message; I am in no way claiming or assuming
that ISATAP is a done deal.

> And I do think ISATAP has uses as all mechanisms.
> 
> thanks
> /jim

Regards,

Fred
[email-masked]

>>-----Original Message-----
>>From: Fred L. Templin [mailto:[email-masked]]
>>Sent: Friday, July 26, 2002 1:17 PM
>>To: [email-masked]
>>Subject: (ngtrans) Comments on 'draft-ietf-ngtrans-mech-v2-00.txt'
>>
>>
>>Hello,
>>
>>Below are some initial comments on this draft:
>>
>>Section 3.8:
>>************
>>The statement: "Unidirectional configured tunnels are considered to be
>>"unidirectional!" seems self-obvious, but does not seem to convey any
>>useful information. In particular, it does not seem to 
>>support the next
>>statement beginning: "Thus the only aspects of Neighbor Discovery...".
>>This seems like just a minor wording issue that can be easily 
>>corrected.
>>
>>Section 3.8:
>>************
>>Minor wording issue in second line in the paragraph beginning:
>>"For the purposes of Neighbor Discovery...". The phrase:
>>
>>   ...as assumed to NOT have...
>>
>>should be:
>>
>>   ...are assumed to NOT have...
>>
>>Section 3.9:
>>************
>>This new subsection entitled "Ingress Filtering" has been added since
>>RFC 2893, but I don't understand why it is organized seperately from
>>section 4.1 (also called "Ingress Filtering"). Since the last sentence
>>in 3.9 ends with "...as specified in section 4.1", it seems 
>>to me these
>>two subsections could simply be combined into one. This would leave
>>section 4 as just the two paragraphs on "Configured Tunneling". But,
>>I don't see a reason why this couldn't just become another subsection
>>under "Common Tunneling Mechanisms".
>>
>>Sections 9 and 10:
>>******************
>>It seems to me that these two sections should either be
>>combined or given different names.
>>
>>Section 10:
>>***********
>>The first bullet poses the questions:
>>
>>   - Should 6to4 be mentioned? How complete should we make the list
>>     of tunneling techniques in section 1.1?
>>
>>It's not clear who these questions are intended for, but if you
>>are seeking opinions I don't think any references to 6to4 or other
>>tunneling techniques should be added. Reasons:
>>
>>   1. This document specifies mechanisms that are useful for other
>>      tunneling techniques, but I do not believe the converse is
>>      true. e.g., both 6to4 and ISATAP make normative references
>>      to RFC 2893, but there is no normative information in either
>>      of those documents for RFC 2893.
>>
>>   2. To list other tunneling techniques in this document would
>>      only be a current snapshot in time. There is no guarantee
>>      that the set techniques under active consideration today
>>      will be the same as those considered in the future.
>>
>>(end of comments)
>>
>>Regards,
>>
>>Fred Templin
>>[email-masked]
>>
>>
>>
>>[email-masked] wrote:
>>
>>>A New Internet-Draft is available from the on-line 
>>
>>Internet-Drafts directories.
>>
>>>This draft is a work item of the Next Generation Transition 
>>
>>Working Group of the IETF.
>>
>>>	Title		: Transition Mechanisms for IPv6 Hosts 
>>
>>and Routers
>>
>>>	Author(s)	: E. Nordmark, R. Gilligan
>>>	Filename	: draft-ietf-ngtrans-mech-v2-00.txt
>>>	Pages		: 23
>>>	Date		: 24-Jul-02
>>>	
>>>This document specifies IPv4 compatibility mechanisms that can be
>>>implemented by IPv6 hosts and routers.  These mechanisms include
>>>providing complete implementations of both versions of the Internet
>>>Protocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4
>>>routing infrastructures.  They are designed to allow IPv6 nodes to
>>>maintain complete compatibility with IPv4, which should greatly
>>>simplify the deployment of IPv6 in the Internet, and facilitate the
>>>eventual transition of the entire Internet to IPv6.
>>>
>>>A URL for this Internet-Draft is:
>>>
>>
>>http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mech-v2-00.txt
>>
>>>To remove yourself from the IETF Announcement list, send a 
>>
>>message to 
>>
>>>ietf-announce-request with the word unsubscribe in the body 
>>
>>of the message.
>>
>>>Internet-Drafts are also available by anonymous FTP. Login 
>>
>>with the username
>>
>>>"anonymous" and a password of your e-mail address. After logging in,
>>>type "cd internet-drafts" and then
>>>	"get draft-ietf-ngtrans-mech-v2-00.txt".
>>>
>>>A list of Internet-Drafts directories can be found in
>>>http://www.ietf.org/shadow.html 
>>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>>
>>>Internet-Drafts can also be obtained by e-mail.
>>>
>>>Send a message to:
>>>	[email-masked].
>>>In the body type:
>>>	"FILE /internet-drafts/draft-ietf-ngtrans-mech-v2-00.txt".
>>>	
>>>NOTE:	The mail server at ietf.org can return the document in
>>>	MIME-encoded form by using the "mpack" utility.  To use this
>>>	feature, insert the command "ENCODING mime" before the "FILE"
>>>	command.  To decode the response(s), you will need "munpack" or
>>>	a MIME-compliant mail reader.  Different MIME-compliant 
>>
>>mail readers
>>
>>>	exhibit different behavior, especially when dealing with
>>>	"multipart" MIME messages (i.e. documents which have been split
>>>	up into multiple messages), so check your local documentation on
>>>	how to manipulate these messages.
>>>		
>>>		
>>>Below is the data which will enable a MIME compliant mail reader
>>>implementation to automatically retrieve the ASCII version of the
>>>Internet-Draft.
>>
>>
>>
>>

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 29 Jul 2002 14:04:27 -0700

Bound, Jim wrote:
> You had stated:
> 6to4 can be used as normative reference and I believe 6to4 should be referenced for sure.
> 
> I did take your mail above implied ISATAP in momentum (as you only listed ISATAP and 6to4) was in the same category.

Again, re-read the message. It says: "e.g., both 6to4 and ISATAP..".
"e.g." means *for example*; not *exahaustive list*. Any other inference
you may have drawn from the statement is of your own making - not mine.

Fred
[email-masked]