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

[Michael Richardson <[e-mail]>]

Pascal Thubert (pthubert) <[e-mail]> wrote:
    >> > 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.

yes, that's why kramdown is so nice that way, as it arranges all of that for you.

    >> 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?

Yes.

    >> 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.

okay.
I have been advised that integers are plentiful and mostly free.

    >> 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.
    > "

So I was trying to say that they should be accepted from the root only, and
that we do this by IP address.   We are going to get some Sec-Review push
back here, so let's get ahead of it.
I know that we have effectively, no BCP38 filtering within the DODAG, so any
node can impersonate the root, but at least we make it a bit harder, remove
attacks from outside the LLN, and we guard against some minor bits of
misconfiguration.

I think that all nodes know this because DODAGID, but I was always a bit
fuzzy whether that value was arbitrary or not.

    >> 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.

I wouldn't be able to code this without documenting a state machine.
I will then wind up asking questions from the state machine after the
document is published.

    > 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,

I have to put that onto paper and then re-read things.
Unfortunately, I won't get to implement before WGLC.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-