Re: [Roll] review of dao-projection -21

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

Hello Michael:

All good.  Please see below:

> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: mardi 23 novembre 2021 11:46
> To: Pascal Thubert (pthubert) <[e-mail]>; Routing Over Low power
> and Lossy networks <[e-mail]>
> Subject: Re: [Roll] review of dao-projection -21
> 

   > I'm not that fond of kramdown, that's an extra step for me, and I use
> it when I must.
>     > Goat seems orthogonal, I love it but lack time for fun to learn
> through the IETF procedure.
>     > Look at https://www.ietf.org/archive/id/draft-ietf-rift-rift-13.pdf;
> good yes, perfect, no. Worth the effort ?
> 
> Yes, worth the effort.
> Goat lets you write ASCII art in a slightly restricted way, and it upgrades
> it to SVG.  The reason to use kramdown here is only because it manages that
> for you.

There's still the process of uploading all the files etc. I keep that for later in the process, maybe RFC editor time.

> 
> I'm okay that the PCE/Root interface is outside RPL, and even that it's
> non-standard.   Some roots could include the PCE internally, I think.

Yes, that's function placement. We now have:

"
   With this specification, an abstract routing function called a Path
   Computation Element [PCE] (e.g., located in an central controller or
   collocated with the Root) interacts with the RPL Root to compute Peer
   to Peer (P2P) paths within a pre-existing RPL Main DODAG.
"
This seems to cover it?

> But, can we make ZZtop the theme song for this document?   :-)

I'm game
 
>     >> I suggest section 4 identify when it Updates, whether it is
> Amending,
> 
>     > Argll you're killing me :) I still do not understand what "updates"
> means and now we amend?
> 
> There is a document trying to detail this, I'm just suggesting we get ahead
> of that.

I'd rather keep that in mind and defer. When the IESG asks for it, I'll do.

> 
>     > We do not break anything in existence if that is the question.
> 
> Amends doesn't mean break... it means that there is new work.
> 
>     > Following your line of thought I should make that a different
> section,
>     > but it seems to me with this is really too picky.
> 
> if you can imagine a project manager assigning the work to two different
> people, then a new section would help. "Bob, implement 4.5.6.9. Sian,
> implement 4.5.6.8"
> 
>     > I already created many sections in the definition ad in section 3.
> This
>     > will be the draft of one sentence per section.
> 
> That's okay with me, if they need to be easily referenced.
> As, it, "Hey other implementer, you didn't do 4.5.6.7 correctly!"

That's a fine argument. I looked at the draft again ad find it hard to implement, but OK. Let's list that one as to be decided by the group during WGLC.

> 
>     >> Last paragraph of 4.1.1 is about TIO/RIO, and deserves it's own
> Amends
>     >> section.
> 
>     > I do not see why that is an amendment? The TIO/RIO discussion is
> today's RPL as is.
> 
> okay.
> 
>     >> I think that the 3-way-ness of this should be in the intro.
> 
>     > Let's take that as a potential addition to be discussed on the ML,
> too
>     > big for me to yes/no just here
> 
> okay.

Second thing to be discussed with the WGLC
 
>     >>
>     >> section 9: I don't think that the new risk for forged P-DAOs is
>     >> adequately
>     >> explained.   Can we at least authenticate P-DAO messages
>     >> because they
>     >> come from the Root? Sometimes the Root IP address is the same
>     >> as the DODAGID.
>     >> (but not always? I forget)
> 
>     > For P-DAO it is, yes. But we do not secure messages from the root.
> That
>     > would be nice. How can we do that?
> 
> I'm okay if we say that only the root (identified by IP address) can send
> them.

Good. I'm adding text for that. In particular in the security section
"
   With this specification, only the Root may generate P-DAO messages. PDR 
   messages may only be sent to the Root. This specification expects that the
   communication with the Root is authenticated but does enforce which method
   is used.
"


> 
>     >> RFC9008 probably has
>     >> provided all the primitives.  (I hope!) But, I'd like to see a state
>     >> machine of sorts that relates the P-DAO, DAO-ACK and PDR/PDR-ACK
>     >> messages.
> 
>     > Again, I'd like to see this agreed by the WG. Would that be
> normative?
> 
> Probably.

OK let's make that your WGLC comment three to be resolved by the group

> 
>     >> I fear that the SHOULD/MUSTs/new-ICMPs messages are too spread over
> the
>     >> document.
> 
>     > The previous review caused some restructuring. The more we do that
> the
>     > more we spread. What do we prefer, stricture vs. MUSt concentration?
> 
> Well, if we had the 6LR changes with state machine, then all the MUSTs
> would migrate to that section.
> 

Yes the state machine is always a debate. Some want it some not. Some want it in the main text some in appendix. 
When in main  text it becomes normative and a bad companion for BCP14, because it's like saying things twice with a risk of discord.

Let's make this your point 4 for the review.

For your other point I added a picture in the terminology, as follows:


       A ==> B ==> C -=- F ==> G ==> H     T1       I: Ingress
     /              \   /              \ /          E: Egress
   I                  O                 E -=- T2    T1, T2, T3:
     \              /   \              / \            External
       P ==> Q ==> R -=- T ==> U ==> V     T3         Targets

     I ==> A ==> B ==> C : a segment with Targets F and O

        I --> F --> E :  a leg with Targets T1, T2, T3

        I, A, B, C, F, G, H, E : a path to T1, T2, T3
                    Figure 1: A Track and its Components
Take care,

Pascal