Re: [Roll] IOTdir Review of draft-ietf-roll-dao-projection-19

["Pascal Thubert (pthubert)" <[e-mail]>]

> -----Original Message-----
> From: Roll <[e-mail]> On Behalf Of Michael Richardson
> Sent: jeudi 2 septembre 2021 17:14
> To: Routing Over Low power and Lossy networks <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Roll] IOTdir Review of draft-ietf-roll-dao-projection-19
> 
> 
> Toerless Eckert <[e-mail]> wrote:
>     > If there is any technological gap, then it is me hoping that this
>     > could be a solution for the RFC8994 A.9.4 problem, but alas this
> 
> I also thought it could help.

It will be out decision to add that to the draft or not. It's feasible.
That will be in my answer to Toerless. Sadly it takes time.

> 
>     > solution does not support establishment of additional routes for
>     > storage mode DODAGs. Too bad. Especially because its not quite clear
>     > to me why that would not be possible to easily do as well. But
>     > in understand how that RPL profile may not have been of any interest
>     > for this work.
> 
> I think that the text may be the problem.
> Last I checked, the intention is to support both adding non-storing routes
> to storing mode, and storing routes to non-storing mode.
> My view was that we were finally unifying the two modes into a kind of
> hybrid.

We still are but for now the draft does not play in a storing mode DODAG because it is lacking the DODAG topology.
Which can be alleviated by calling parents siblings and sending non-storing DAOs to the root even in storing mode for both siblings and parents.
We are already doing that mix for external routes...
Please keep that point alive.


> 
>     > The mayor issue in the text is that it front-loads a lot of details
>     > that are then hard to understand and open questions are only answered
>     > much later. For example, packet encoding is put first in the
> document,
>     > as opposed to (as i have observed it in more RFCs) at the end. Then
>     > the text follows with processing description, and only finally with
>     > what i consider to be a complete description of how the pieces
>     > interact through examples. As mentioned in the details, i think the
> order should
>     > be as much as possible top-down, starting with sufficienly complex
>     > examples that introduce the technology to the extend that the
>     > main concepts are used in the example. E.g.: sequential or complex
> track,
>     > sements, destinations, targets.
> 
> I agree.
> I also suspect that we need more implementator feedback.
>  


Same here this is a great review and it entails a significant update work. I'm on it but cannot spend all the time I'd wish.

Keep safe;

Pascal