Re: I-D ACTION:draft-ietf-multi6-functional-dec-00.txt

Personal comments:

Substantive:
------------

I think this is OK to hand over to the proposed successor WG as it
is, but I have a few small comments anyway...

> 4.  Locator set management
...
>    There are two possible approaches to the addition and removal of
>    locators: atomic and differential approaches.  Atomic approaches
>    essentially send the complete locators set each time that a variation
>    in the locator set occurs.  In this case, there is only one message
>    exchange defined i.e.  a message that informs about the new locator
>    set and an acknowledgment message.  Differential messages send the
>    differences between the existing locator set and the new one.  In
>    this case, a message for adding a new locator and another message for
>    deleting locators have to be defined.  Both messages can be
>    acknowledged.  The atomic approach imposes additional overhead, since
>    all the locator set has to be exchanged each time...

On the other hand, the atomic approach doesn't need acknowledgement
messages, since it can work like soft state - you simply repeat the
atomic message at suitable intervals. That makes it quite a bit
simpler.

> 6.  Removal of M6 session state
...
>    In the unilateral approach, each node discards the information about
>    the other node without coordination with the other node based on some
>    local timers and heuristics.  No packet exchange is required for
>    this.  In this case, it would be possible that one of the nodes has
>    discarded the state while the other node still hasn't.  In this case,
>    an error message may be required to inform about the situation.

Again, this is like soft state. I don't think you need an error message
when state is lost - you just need to systematically restart the whole
M6 procedure, just like when a session is initiated.

Editorial:
----------

> 2.1  Initial contact
...
>    ...then the M6 protocol has to be used even to perform the
>    initial contact between the two nodes, starting by the capabilities
>    detection procedure described in section 2.1.2.

Do you mean section 3.1?

> 3.1.3  Host-Based Dynamic Discovery
...
>    For instance, lets assume hosts A and B communicate over two separate
>    links without going through the Internet.  Lets further assume the

s/let us/lets/

> 3.1.4  Timing
> 
>    Capability detection needs to occurr prior to or at the same time as

s/occur/occurr/

> 5.  Re-homing procedure
...
>    the Reachability Test is also a mechanism to prevent thrid-party
>    flooding attacks.

s/third/thrid/

> 
>    The Reachability Test exchange includes the following packets:
> 
>       Reachability Test (RT) packet: including the random nonce and
>       maybe information related to the initial key/cookie/hash chain

s/a random nonce/the random nonce/
[since this is the first time you mention the nonce]

> 7.  Security considerations
> 
>    The security requirements of each message exchange considered in this
>    note are detailed in the same section where the message exchange is
>    analyzed.

Add something like:

The security threats to be considered are described in [XXX].

      Brian