Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt

[Erik Nordmark <Erik.Nordmark@sun.com>]

> OK, but that could simply be in the changes section, not in the definitions
> section, as if the 3.6 reference is removed IPv4 compatibles are then only
> mentioned in the changes section.   having them in the defs kind of suggests
> they are valid.

I misspoke - strictly speaking this document doesn't deprecate them - it
just no longer uses them. The doc contains this in the changes section:
	Removed automatic tunneling and use of IPv4-compatible addresses.

We could make this document deprecate them, but it would make
more sense to perform such an action in draft-ietf-ipv6-addr-arch-v4-00.txt

> > > 3. Section 2 starts "the most straightforward way", though this
> > >    is the only way in this document? 
> > 
> > Yes. Is that confusing? Suggestions for different way to start things off?
> 
> I guess if we said "the recommended way" that might get some objection.
> I think part of the "problem" is that the draft doesn't set context anywhere,
> e.g. it doesn't state why automatic methods such as 6to4 are not cited, or
> why NAT-PT isn't mentioned as a "less straightforward" way of having
> compatibility.   Perhaps "The only way for IPv6 nodes to remain fully
> compatible with IPv4-only nodes is by...", and then make some comment that
> without that translation is needed? (a quick grep shows not one instance of
> the word "translation" so again I think some text near the start setting the
> scope here would really help).

I agree that this document describes how implementors can build car
engines; it does not teach people to drive cars.
Hence providing an overview of all possible transition or even tunneling
mechanisms is out of scope. We can have other RFCs do that.

"The only way ... fully ..." is an even more questionable opinion than
"the most straightforward way ..." - a http proxy can be argued to
be fully compatible from the perspective of http applications.

So I'm still not seeing how you would like to edit the document on the table
to make it more clear; you seem to be mixing this clarifying task with
wanting a different, more overview'ish, document on the table.

> In short, the first line of the abstract would suggest that translation
> methods should be cited, but in fact the document really focuses on tunnel
> methods that IPv6 hosts/routers can use to communicate over IPv4 networks.
> Maybe this focus changed over the three iterationbs of this RFC?

I think the abstract contains marketing - maybe time to get rid of that.


> See above - I think the first sentence of the abstract suggests otherwise,
> and this sentence I think is used in the intro text at least too.  If you
> just want to make one change, then a statement in the asbtract and after
> paragraph 1 of the intro to say that translation techniques are not in
> scope would help, I think.

"first"? I assume you mean that 3rd sentence in the abstract which says:
	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.

I suggest just dropping that sentence.

It is easier to say that dual stack and configured tunnels are in scope than
trying to first define what "translation" is for the sole purpose of
saying that it is out of scope. FWIW I think the definitional problem
is a hard one; is a http proxy (on a dual stack node) a "translation" or not.

  Erik