[DNA] RE: Review of link-information from Pekka Savola

[Alper Yegin <alper.yegin@samsung.com>]

Thanks Pekka.... 
My response is inlined below...
 
>  1. 3GPP/3GPP2 network architecture discussion is very useful for the
>  uninitiated, but hopefully it has been reviewed by 3GPP/3GPP2 folks
> that
>  it's correct so that there's no need to iterate over it later?

Co-authors who contributed to the respective sections are involved with
3GPP/2 work. But of course, we wouldn't mind more reviews. We can seek
out further 3G* reviews at the latest during the WG LC.

>  2. The document's category and the approach is not clear.  The
charter
>  says Informational, but the document has MUST keywords (in an
>  inconsistant manner; some link layers use uppercase, some don't).
>  This needs to be rethought.  I personally don't have a big problem
>  with upper keywords in non-Standards track document, but in case they
>  are here, they should be used consistently and well.  There are also
a
>  few "shoulds" which should probably be musts or the like.

OK, we'll go over them and make them all uppercase. 

>  3. Does 802.1x change the situation with WiFi or wired ethernet?

IEEE 802.11i discussion covers that for WiFi. Ethernet text is not
included in the I-D yet.

>  4. Discussion of wired Ethernet would be extermely useful...

Yes, I agree. We'll be incorporating Greg's text for that.

 
>  5. Some implementations may also support more extensive notifications
> (e.g.,
>  about the signal strength).  Are these explicitly out of scope (might
> make
>  sense, but might also make sense to state that explicitly) ?

They are explicitly outside the scope of DNA. 

   The document limits itself to the minimum set of information that is
   necessary for solving the DNA problem [I-D.ietf-dna-goals].  A
   broader set of information may be used for other problem spaces
   (e.g., anticipation-based Mobile IP fast handovers
   [I-D.ietf-mobileip-lowlatency-handoffs-v4]
   [I-D.ietf-mipshop-fast-mipv6]).  Separate documents that are
   backward-compatible with this one can be generated to discuss further
   enhancements.

The above text meant to capture that. We can add explicit examples like
yours to make it clearer.


>  semi-editorial
>  --------------
> 
>      Node's establishment of a link-layer connection with an
attachment
>      point that signifies the availability of IP service (i.e., being
> able
>      to send and receive IP packets) between the two is considered a
> link
>      up event.
> 
>  ==> a physical link is a link which can carry any media.  Maybe you
> should
>  reword this slightly -- for example, a host does not know about
> availability
>  of IP (or anything else).  Maybe "availability of IP service" is
> specific to
>  some link types which can only carry IP service, not any L3 protocol?

Not sure if I understood this. Could you please elaborate a bit more? 

>  4.  Security Considerations
> 
>      A faked link-layer event notification can be used to launch a
>      denial-of service attack on the node and the associated network.
>      Secure generation and delivery of these notifications must be
>      ensured.  This is a subject for link-layer and network stack
> designs
>      and therefore it is outside the scope of this document.
> 
>  ==> this may call for a bit more analysis.  Who can forge those
> link-layer
>  notifications?  

We are not getting into these details in the text, but... in some
technologies remote nodes may be able to forge them.

> The stack itself?  

Sure, the stack can too. But this is uninteresting. I mean, if the stack
below is not trustworthy, what can you do?

> Can someone else (e.g., a
> Disassociate L2
>  message)?  Is there more than shooting yourself in the foot here?

Imo, once L2 tells L3 that the link is up or down, there is not much for
L3 to do but believe it. 

>  editorial
>  ----------

We'll take care of the editorials.

Thanks again.

Alper