[DNA] Review of link-information from Pekka Savola

[Greg Daley <Greg.Daley@eng.monash.edu.au>]

Dear Alper and WG,

Here is the review from Pekka Savola.

These issues will be captured on a new
issue tracking page.

Details will be available by thursday.

Greg


--
substantial
 -----------

 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?

 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.

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

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

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

 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?

 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?  The stack itself?  Can someone else (e.g., a
Disassociate L2
 message)?  Is there more than shooting yourself in the foot here?



 editorial
 ----------

 Abstract

     Certain network access technologies are capable of providing
various
     link-layer status information to IP.  Link-layer event
notifications
     can help IP expeditiously detect configuration changes.  This draft

 ==> s/draft/document/

   The attachment point is typically an access network
     element, such as an access point, a base station, or a wired switch
     [TO-DO: How about ad-hoc networks? Attached neighbors may be
     considered attachment points].

 ==> you already said "typically", should be good enough to remove the
TO-DO.

   Each
     one of these events must generate a notification in order they
occur.

 ==> s/in order/in the order/

     IPv6 subnet renumbering [RFC2461].  Therefore, there exists cases
     where IP-layer configuration may have to change even without the

 ==> s/exists/exist/

     A GPRS MT that wants to establish IP-level connections should first
     perform a GPRS attach to the SGSN.  This should be followed by a
     request the GPRS network to settle the necessary soft state
mechanism
     (GPRS tunneling protocol) between its serving SGSN and the GGSN.

 ==> s/request/request to/ ?

     external Packet Data Network such as Internet .  It is only after
the

 ==> s/ ././

     Successful establishment of a PDP Context on a GPRS signifies the
     availability of IP service to the MT.

 ==> s/GPRS/GPRS link/

     forwards them to the final receiver.  A STA must establish a IEEE

 ==> spell out "STA"

   An AP with a given BSSID can connect a STA to any
     one of more than one IP subnets.

 ==> "any one of more" -- something missing?

     Indepedant Basic Service Set.  In an IBSS, only station services
are

 ==> s/Indepedant/Independent/ ?

     available, i.e.  authentication, deauthentication, privacy and MSDU

 ==> spell out MSDU?

   Although a link up indication can be generated upon
     authentication, one may not be present per latter usage.  If
     authentication is performed,

 ==> s/one/the link/ ?