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

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

Thnaks for the comments.

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

> 2. IPv4 compatibles are mentioned in 3.6 - this should be removed
>    (aren't general multicast source addresses dropped anyway?)

I think dropping compatibles make sense because they shouldn't be used
any more.

> 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?

> 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?

> 5. In 2.3 there are 2 references to 6bone.  Should probably use something
> else
>    given 6bone is deprecated.

oops. I'll say something vague as "connected to the Internet using IPv6"
unless there is a better suggestion.

> 6. In section 3, or in the introduction,  some mention should probably be
> made 
>    as to why automatic tunneling (6to4, RFC3056) is not inlcuded in the
>    basic mechanisms (it postdates 2893 but is omitted).

Explicitly listing others is a potential slippery slope; we can argue for
a long time which ones to explicitly list as not being included :-(
Isn't the current text sufficient? It says:
   Other transition mechanisms, including other tunneling mechanisms,
   are outside the scope of this document.

  Erik