Re: [DNA] REVIEW of draft-ietf-dna-network

[Nicolas Montavont <nicolas.montavont@enst-bretagne.fr>]

Dear John and Julien,

Thank you very much for your comments on the routers BCP.
Find inline some other comments.

We'll send a new version of the document in few days, just the time to 
check with you if you have other concern / suggestions.

john.loughney@nokia.com wrote:

[skip]

>3) Also:
>
>   Such hosts need to determine if they have moved to a new IPv6 link
>   rapidly, ...
>
>As the attachment is fairly binary, I don't think that the movement can
>be
>rapid, but it is more that the rate of change in re-attaching to
>different
>links may be rapid or not.  I think this should be re-worded.
>  
>
You're right, but here we wanted to say that the determination of the 
link (re) attachment must be quite rapid. We replaced with Julien's 
suggestion.

>5) Question on this definition:
>
>   Reachability Detection: Determination that a device (such as a
>      router) is currently reachable, over both a wireless medium, and
>      any attached fixed network.  This is typically achieved using
>      Neighbor Unreachability Detection procedure [1].
>
>Is there a reason why it must be both wireless and wired?  Could you
>have
>only wireless links on the router?  I think reachability detection
>doesn't
>specifically require such a configuration.
>  
>
This is right. We just wanted to have some detail, and say that if the 
node is connected to an AP (through wireless), which AP is connected to 
the AR (through wire), both links should be working.

Anyway, this might be obvious, so we remove "over both a wireless 
medium, and any attached fixed network."

>9) Appendicies are always non-normative in RFCs, I assume this document
>is meant
>to be informational, so maybe it is a non-issue. I found that having the
>recommendations
>as a non-normative appendicies is a little strange. I think it might
>make sense if
>this were in the body of the text.
>  
>
We had them in the body of the text in the begining and then decided to 
move it because of some feedback we recieved. Somebody thought that the 
information is a little too much detail and better off in the appendix. 
We could move it back in, if more people thought that it is better.

>John
>  
>
And comments from Julien:

Julien Laganier wrote:

>On Wednesday 05 July 2006 00:25, Suresh Krishnan wrote:
>  
>
[skip]

>>
>>   Link-Change: Link-Change occurs when a host moves from a
>>      point-of-attachment on a link, to another point-of-attachment
>>      where it is unable to reach devices belonging to the previous
>>      link, without being forwarded through a router.
>>    
>>
>
>Why not simply have:
>
>    Link-Change: Link-Change occurs when a host moves from a
>       point-of-attachment on a given link to another 
>       point-of-attachment on a different link.
>  
>
Your decription makes it sounds like there will be link-change every 
time you change AP - thats not true - only if change needs a new router 
to forward data to the old link. Our text is more precise in that sense, 
isn't it?

>  
>
>>  When a host solicits and attempts to schedule a multicast RA
>>    
>>
>
>=>  When a host solicits and the router attempts to schedule a
>   multicast RA
>  
>
Our formulation seems good: it is indirectly that the host intends to 
schedule a RA.

>>[...]
>>
>>5.1  Providing Router Authorization
>>
>>  In DNA, some hosts will begin configuration procedures based on a
>>  single message transmitted by a router.  As such the ability of
>>  routing infrastructure to prove its authenticity and authorization
>>  is important to support correct operation of hosts. Authentication
>>  and authorization mechanisms exist which allow hosts to check
>>  security of routers when they receive Router Advertisements
>>  indicating link change.
>>    
>>
>
>The mechanisms mentionned above are SEND, or there are others? If this 
>is SEND only I suggest citing SEND here, by e.g. rephrasing as:
>
>   In DNA, some hosts will begin configuration procedures based on a
>   single message transmitted by a router.  As such the ability of
>   routing infrastructure to prove its authenticity and authorization
>   is important to support correct operation of hosts. Secure
>   Neighbor Discovery (SEND) [4] defines authentication and
>   authorization mechanisms which allow hosts to check security of
>   routers when they receive Router Advertisements indicating link
>   change.
>  
>
We don't want to be too specific, and we don't believe that we loose 
anything by not mentionning SEND here. Just in case someting else shows up

>That's it.
>
>Best,
>
>--julien
>
>  
>

Nicolas, Sathya and Greg.