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

From: Thomas Narten <[email-masked]>
Date: Fri, 25 Aug 2006 14:52:10 -0400

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

Going back through some older mail, I see that this thread started as:

> From: Suresh Krishnan <[email-masked]>
> To: Dna <[email-masked]>
> Cc: Greg Daley <[email-masked]>
> Date: Tue, 04 Jul 2006 18:25:50 -0400
> Subject: [DNA] REVIEWS NEEDED: draft-ietf-dna-network
> Reply-to: [email-masked]

> Hi Folks,
>    The DNA routers draft (renamed to draft-ietf-dna-network-00) is ready
> to be last called before being sent to the IESG for publication. Please
> take some time to read the draft and respond to the mailing list with
> your reviews.

> Thanks
> Suresh & Greg

Just skimming this document quickly, I'm immediately wondering how it
relates to the other dna documents, and the "merged" document in
particular. The introduction includes:

   It should be noted that many already deployed routers will not
   support these recommendations, and that hosts SHOULD NOT rely on
   their being in place, unless they have particular reason to do so.

This to me implies that this document actual defines changes. But I
thought that is what the other "merged" document was doing. So I'm
immediately confused about how this document relates to the merged
one.

I'd suggest that we suspend work on this document until the merged
document is available. IMO, it's not possible to properly review this
document without knowing what is in the other document and how to
scope the topic of this one. (Indeed, I continue to wonder why there
is a need for multiple documents in this space at all, but that's a
separate discussion).

Chairs, could we temporarily suspend work on this document (and not
forward it to the IESG) until the other document is available and both
can be reviewed together?

Thomas

---

From: Nicolas Montavont <[email-masked]>
Date: Fri, 25 Aug 2006 19:08:45 +0200

Dear John and Julien,

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

[email-masked] 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.

---

From: Julien Laganier <[email-masked]>
Date: Thu, 31 Aug 2006 14:56:52 +0200

Hi Nicolas,

> Find inline some other comments.

Some more comments below...

<snip>

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

Well, as I read my description it says that a link change occurs when 
the node attach to a *different* link, it doesn't says anything about 
changing APs. From an IP point of view if you change APs but stay in 
the same DS under one router then you're still on the same link.

But anyway that's not so important.

> Our formulation seems good: it is indirectly that the host intends
> to schedule a RA.

Ok I got it. It might be clearer if explicitly written down: "When a 
host solicits and attempts to make the router schedule a multicast 
RA"

Thanks.

--julien