Subject: (ngtrans) I-D ACTION:draft-ietf-ngtrans-mech-v2-00.txt

From: [email-masked]
Date: Thu, 25 Jul 2002 08:07:50 -0400

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: Fri, 26 Jul 2002 10:17:21 -0700

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]

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 27 Jul 2002 04:42:22 +0200 (CEST)

Thanks for the comments. I've applied the suggested editorial fixes.

> Section 3.9:

Part of the reason for the split into "common" and "configured" is
of course for historical reasons (from when the document had a "automatic" 
section). The reason I kept it that way in this version is because I wasn't
sure whether there are other tunneling mechanisms that refer to the
"common" part of this specification. A survey of 6over4, 6to4, isatap, etc
would be useful.

> tunneling techniques should be added. Reasons:

Do others have other arguments. If not we can resolve that question by
not adding any mention of other tunneling schemes.

  Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Jul 2002 09:14:09 +0200

Erik Nordmark wrote:
...
> not adding any mention of other tunneling schemes.

I agree with Fred, but I think there are some changes needed to tidy this
up in the text.

1. The document title is currently 

>    Transition Mechanisms for IPv6 Hosts and Routers

This may set false expectations about the scope of the document.
I suggest changing it to

   Basic Transition Mechanisms for IPv6 Hosts and Routers

2. Just before section 1.1 we find: 

>    ...This document defines the
>    initial core set of transition mechanisms, but these are not expected
>    to be the only tools available.  Additional transition and
>    compatibility mechanisms are expected to be developed in the future,
>    with new documents being written to specify them.

This was written years ago. I think it needs to be updated:

   ...This document defines the
   basic core set of transition mechanisms, but these are not
   the only tools available.  Additional transition and compatibility 
   mechanisms have been specified, and others are expected to be specified 
   in the future.
   
       Brian

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 29 Jul 2002 09:56:03 -0700

Brian,

I mostly agree with your comments. One small alternate wording
suggestion appears below:

>    mechanisms have been specified, and others are expected to be specified 

The above proposed wording is accurate at this particular point in
time. But, the use of the future-tense could lead one to believe
there will be no end in sight for the IPv4-to-IPv6 transition. I
suggest the following minor re-word for the final sentence:

   "Additional transition and compatibility mechanisms are specified
    in other documents."

The above statement is true today and will be true at any point in
the future regardless of any future works that take place outside
the scope of this document.

Fred
[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 30 Jul 2002 02:35:59 +0200 (CEST)

Thanks. I've applied these suggested edits.

  Erik

>----- Begin Included Message -----<

Date: Mon, 29 Jul 2002 09:14:09 +0200
From: "Brian E Carpenter" <[email-masked]>
Subject: Re: (ngtrans) Comments on 'draft-ietf-ngtrans-mech-v2-00.txt'
To: "Erik Nordmark" <[email-masked]>
Cc: "Fred L. Templin" <[email-masked]>, [email-masked]

Erik Nordmark wrote:
...

   
       Brian

>----- End Included Message -----<

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 30 Jul 2002 02:44:55 +0200 (CEST)

> the scope of this document.

Even better!

  Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jul 2002 09:26:52 +0200

> > the scope of this document.

Fine by me.

   Brian