[6lowpan] #134: Editorial fixes for ND-15

["6lowpan issue tracker" <[e-mail]>]

#134: Editorial fixes for ND-15

 Editorial Comments from Colin :

 Section 1.3 ( Applicability, Assumption and Goals)
      Consolidation  or deletion of  a few redundant bullet points

 Comment:

 1)
      o  Optimize Neighbor Discovery with a mechanism that is minimal yet
      sufficient for the operation in both mesh-under and route-over
      configurations.

      o  Make the host to router interaction the same whether mesh-under or
      route-over is used.

 *These last two points could probably be consolidated into one point.

 Updated text: (Removed the 2nd bullet)
    o  Optimize Neighbor Discovery with a mechanism that is minimal yet
      sufficient for the operation in both mesh-under and route-over
      configurations.
 2)

      o  Minimize signaling by avoiding the use of multicast flooding and
      reducing the use of link-scope multicast messages.

      o  Optimize the interfaces between hosts and their default routers.

 *This could also also be fit in with the first two points I think

 ==> We like to keep the text as it is for clarity

 3)

             o  Support for sleeping hosts.

      o  Minimize the complexity of nodes.

 *Point can be deleted, nobody wants complex nodes, and it's already a goal
 to
 make the mechanism 'minimal', which implies to me the nodes are not as
 complex

 ==> Updated text: Deleted



 Section 6.5.4 : (Next hop Determination for the Routers)

 Current text:
 It is the responsibility of the routing protocol to maintain on-link
 information
 about its registered neighbors. Tentative NCEs MUST NOT be used to
 maintain on-link status.

 Comment: NCE undefined
 Comment: Refer to 5.6

 Proposed Change:

 It is the responsibility of the routing protocol of the router to maintain
 on-link information
 about its registered neighbors. Tentative NCEs MUST NOT be used to
 determine on-link status of the registered nodes.


 Section 8.2

 Current text : ( contains unnecessary bracketed text)

  (This is needed to
  handle the case when multiple hosts try to register the same IPv6 address
 at the same time.)
 If no Neighbor Cache entry exists, then

 Updated text: Removed brackets



 And more updates suggested by Erik as follows:
 It is true that we never define "NCE". But the first time we use that
 acronym is in section 1.3 hence a reference in 6.5.4 doesn't seem that
 useful.

 I'd suggest the following edits to make things flow better.

 In section 3.5 add "(NCE)" thus change FROM:
     The use of explicit registrations with lifetimes plus the desire to
     not multicast Neighbor Solicitation messages for hosts imply that we
     manage the Neighbor Cache entries slightly differently than in
     [RFC4861].  This results in three different types of NCEs and the
     types specify how those entries can be removed:
 TO:
     The use of explicit registrations with lifetimes plus the desire to
     not multicast Neighbor Solicitation messages for hosts imply that we
     manage the Neighbor Cache entries (NCE) slightly differently than in
     [RFC4861].  This results in three different types of NCEs and the
     types specify how those entries can be removed:

 We also need to cleanup the last bullet in section 1.3. It is a bit out of
 place since it says a lot more than a goal or an assumption. I observe
 that we have a sentence about mobility in section 3.3.
 Thus I suggest in section 1.3 change FROM
        If the
        node loses connectivity with the default router involunterily,
        then the default router does not know the node has moved until it
        runs the unreachability detection.  In order to optimize the time
        for detecting unreachability of a run-away node, a default-router
        may use link-layer indication or configure a lower NCE life-time
        value and low registration life-time value - so that it can remove
        the NCE of the run-away node as soon as possible.
 TO
        To handle the case when a
        node loses connectivity with the default router involunterily,
        the node should use a suitably low registration lifetime.

-- 
---------------------------------------------+------------------------------
 Reporter:  samita.chakrabarti@…             |       Owner:  zach@…            
     Type:  task                             |      Status:  new               
 Priority:  major                            |   Milestone:                    
Component:  format                           |     Version:                    
 Severity:  -                                |    Keywords:  editorial         
---------------------------------------------+------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/134>
6lowpan <http://tools.ietf.org/6lowpan/>