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

[Tim Chown <tjc@ecs.soton.ac.uk>]

On Thu, Nov 13, 2003 at 05:27:36PM +0100, Erik Nordmark wrote:
> 
> > 1. Why is IPv4 compatible addressing defined in the first section,
> >    if it is deprecated?  
> 
> To say that it is deprecated. But perhaps we should ask to do this
> in the ipv6 addressing architecture update.

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.
 
> > 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).

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?

> > 4. In 2.2 should we mention that that app may or may not be v6 aware or
> >    capable?  The shin-application-transition draft could be pointed to,
> >    although it is not a WG item ist looks very good work.
> 
> Already received a comment about not adding AAAAs until the apps/services
> on the node support IPv6. 
> Would that address your comment or should I add something slightly different?

I think one thing shin-application-transition captures well is the issue
of v4/v6 enabled on the host and v4/v6 application capability (and thus the
potential usage of mapped addresses for example).   I guess 2.2 talks
about the protocol used on the wire, so the presentation to the app as
a mapped address may be out of scope here.
 
> Isn't the current text sufficient? It says:
>    Other transition mechanisms, including other tunneling mechanisms,
>    are outside the scope of this document.

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.

Sorry if this seems a little pedantic :)

Tim