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=F3:

> 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=20
>> 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=20=

>> for
>>    deleting locators have to be defined.  Both messages can be
>>    acknowledged.  The atomic approach imposes additional overhead,=20
>> 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=20
set. If an ack is used, there is no need to resend the locator set=20
unless there is a change on the set.
But in anycase, at this point the draft is just describing options, so=20=

i guess we could also discuss these tow options (periodic refresh vs.=20
ack)

>> 6.  Removal of M6 session state
> ...
>>    In the unilateral approach, each node discards the information=20
>> about
>>    the other node without coordination with the other node based on=20=

>> 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=20
>> 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=20
discarded?
i guess that we should consider how this would affect the path=20
exploration procedure, for instance... i mean, how the end that still=20
has the session state would differentiate the case of a path outage=20
from the case of lack of session state.... i mean , the end that still=20=

has the session state may attempt to explore all the possible paths=20
before giving up, or even may retry several rounds will al the=20
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=20
>> 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=20=

>> 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=20=

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