Re: [Roll] some comments / questions on dao-projection

Hi Michael,

thanks for the reactions to the now adopted document.

   I can open tickets as appropriate if chairs direct.

Please, proceed as you suggest with tickets.
Especially the security one needs a ticket of its own.

Many thanks,

Peter

> 
> Let me leave editorial comments to the end of this email.
> 
> 1) Didn't we have an errata about default lifetime units when there was 
> no
>    configuration option?
> 
> No, we didn't.  I wonder if this plagues us everywhere, that 6550 
> should
> have specified a default Lifetime units in the absense of a 
> Configuration
> option.
> 
> 
> 2) RFC6551 reference:
> 
>>   or the RPL routing extensions specified in Routing for Path
>>   Calculation in LLNs [RFC6551].  Based on that information, the root
> 
> huh? the title of 6551 is: Routing Metrics Used for Path Calculation in
>                            Low-Power and Lossy Networks
> 
> so, what exactly did you mean here?
> 
> 3) does dao-lifetime eclipse need for no path dao?
> 
> 4) resource calculations
> 
> "but how the root figures the amount of
>    resources that are available is out of scope."
> 
> I disagree. I would like some mechanism to be in scope.
>   And you suggest NMS and 6551 later on... which seems to make it in 
> scope.
>   I'm not sure how 6551 can be used here.
> 
> 5) section 4 needs subsections! Too many concepts in one heading.
> 
> 6) On the use of a new MOP.
> 
> Are we sure that we need a new MOP?  Could we use Non-Storing MOP, with
> some indication of which nodes speak DAO-Projection?  Could that work?
> 
> Or do you really want to force a forklift upgrade here?
> Why does the entire network need to be aware of this new mode?
> 
> 7) page 8 is too dense!
> 
> 8) I just didn't understand the english here.
>    I think that "last node" needs a better term.  Maybe colour
>    the nodes or otherwise mark them and use those terms?
> 
>    The last node in the segment may have another information to reach
>    the target(s), such as a connected route or an already installed
>    projected route.  If it does not have such a route then the node
> 
> 9) running out of resources:
> 
> it seems that it ought to be said that the new node might not be one 
> that the
> last node had previously talked to.  There is the issue of both routing
> storage (from storing mode), but also neighbor cache resources.
> 
> 10) more hard to understand statements...
> 
>>   For the targets that could be located, last node in the segment
>>   generates a DAO to its loose predecessor in the segment as indicated
>>   in the list of Via Information options.
> 
> woe!  What?
> 
> 11) create new section on route cleanup
> 
>>   A NULL lifetime in the Via Information option along the segment is
>>   used to clean up the state.
> 
> needs new 4.x section on cleanup.
> 
> 12) move / replicate diagrams into this section, and use numbered 
> diagrams
> 
>>   In the example below, say that there is a lot of traffic to nodes 55
> 
> new section, move diagram here.
> 
> make figure 5 and 6 more like figure 3, numbered, etc.
> 
> 13) Q: retransmission timers, etc. appropriate for these projected DAO 
> messages?
>     How do we handle packet loss?
> 
> 14) Security Considerations will need to be written.
> 
> The security threats documents details very specific threats, and 
> indicating
> if this protocol changes things is important.  Also, some consideration
> SHOULD be given to when A=1.  Are the affects of the new flow of
> control messages?
> 
> So for instance Security Considerations should probably consider how
> projected DAO messages could be abused by
>   a) rogue nodes
>   b) via replay of messages
>   c) if use of projected DAO messages could in fact deal with any 
> threats?
> 
> 
> ======== START of EDITORIAL comments
> 
> Change:
>    Additionally, RPL storing mode is optimized or Point-to-Multipoint
>    (P2MP), root to leaves and Multipoint-to-Point (MP2P) leaves to root
>    operations, whereby routes are always installed along the RPL DODAG.
> 
> To:
>    Additionally, RPL storing mode is optimized for Point-to-Multipoint
>    (P2MP), (..root to leaves and Multipoint-to-Point (MP2P) leaves to 
> root
>    operations), whereby routes are always installed along the RPL 
> DODAG.
> 
> the part () is worded too poorly for me to parse.  Can you fix this?
> 
>    Transversal Peer to Peer (P2P) routes in a RPL network will 
> generally
>    suffer from some stretch since routing between 2 peers always 
> happens
> 
> What means "stretch" here?
> 
> section 2: NSM -- I think this is a new term?
>         (it's not in RFC6550 or 7102. I'm all for this term)
> 
> section 3: I found the comments about factoring to be too soon.
>         Some explanation of mechanism should preceed this part of the
>         discussion.  Just let section 3 be about the formats/contents.
> 
> I suggest text like this:
>   In NSM the TIO option is used in the DAO message to indicate the 
> immediate
>   parent of a given path.  The TIO applies to the Target options that
>   immedially preceed it, and multiple TIOs may be present to indicate
>   multiple routes.
> 
>   This specification...
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll