[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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