Hello Michael

> 
> 1) can you add a reference for "Routing Stretch"?
[PT>] done, pointing on RFC 6687

> 2) Alternatively, the 6LN may rely on its 6LR to perform routing and
>    forwarding on its behalf.  In the context of RPL, such a 6LN is
> 
>    -> if you want to give an example of such a node, I think that the window
>       smash sensor (alarm system), or the kinetically powered light switch,
>       are two good examples.
>    {I wish I had links to real products that actually ran RPL.}

[PT>] done

> section 3:
> s/      Upon the renewal of a registration, this specification changes the
>         behavior or the 6LR.
>  /      Upon the renewal of a 6lowPAN ND registration, this specification
> changes the
>         behavior of the 6LR. /
> 
> The rest of that paragraph is ver hard to parse.
> 
[PT>] reworded as follows:
"
   Upon the renewal of a 6lowPAN ND registration, this specification
   changes the behavior of the 6LR as follows.
   If the 'R' flag is set, the 6LR injects a DAO targeting the Registered
   Address, and refrains from sending a DAR message. 
   the DAR/DAC exchange that refreshes the state in the 6LBR happens instead 
   between the RPL Root and the 6LBR. In that flow, the RPL Root acts as a
   proxy on behalf of the 6LR upon the reception of the DAO propagation
   initiated at the 6LR.
"

> section 4:
> should:
>    This document specifies a new flag in the EARO option, the 'R' flag,
>    used by the registering node to indicate that the 6LN that performs
>    the registration is a router and that it handles its reachability.
> 
> say:
>    This document specifies a new flag in the EARO option, the 'R' flag,
>    used by a 6LN, when registering, to indicate that this 6LN
>    is a router and that it will handles its own reachability.
> 
[PT>] Moved to the RFC 6775 update draft and updated as follows
"
   This document makes use of the 'R' flag in the EARO option, used by
   a 6LN, when registering, to indicate that this 6LN is a leaf, not aware of
   the RPL operation in the network, and thus does not participate to it.
   The behavior defined in this specification whereby the 6LR that processes the
   registration advertises the Registered Address in DAO messages and bypasses
   the DAR/DAC process for the renewal of a registration, is  only triggered by
   an NS(EARO) that has the 'R' flag set. A RPL leaf SHOULD set the 'R' flag.
   
   If the 'R' flag is not set, then the Registering Node is expected to be a RPL
   router that handles the reachability of the Registered Address by itself.
   This document also specifies a keep-alive EDAR message that the RPL Root may
   use to maintain an existing state in the 6LBR upon receiving DAO messages. 
   The EDAR message may only act as a refresher and can only update the Lifetime
   and the TID of the state in the 6LBR.  A RPL router SHOULD NOT set the 'R' 
flag.
"
>    (...By sending a DAO)
> 
> The rest of the document has some difficult sentences too.
> 
> --
> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 

_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to