Re: I-D ACTION:draft-ietf-multi6-functional-dec-00.txt
Brian E Carpenter <brc <at> zurich.ibm.com>
2005-01-05 12:38:34 GMT
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
RSS Feed