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

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

Hi Brian,

thanks for the comments,

see below...

El 05/01/2005, a las 13:38, Brian E Carpenter escribió:

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.


yes but this would require the periodic exchange of the full locator set. If an ack is used, there is no need to resend the locator set unless there is a change on the set.
But in anycase, at this point the draft is just describing options, so i guess we could also discuss these tow options (periodic refresh vs. ack)

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.


so, any message related to a non existent session would be silently discarded?
i guess that we should consider how this would affect the path exploration procedure, for instance... i mean, how the end that still has the session state would differentiate the case of a path outage from the case of lack of session state.... i mean , the end that still has the session state may attempt to explore all the possible paths before giving up, or even may retry several rounds will al the locators....


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


will fix

thanks, marcelo

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