Re: [Roll] Martin Duke's Discuss on draft-ietf-roll-turnon-rfc8138-12: (with DISCUSS and COMMENT)

[Michael Richardson <[e-mail]>]

Martin Duke <[e-mail]> wrote:
    > I find this all very odd, which maybe is a sign we should simply DISCUSS in
    > the telechat. As far as I can understand:
    > - codepoints 5, 6,  and 7 are currently unassigned, though
    > draft-ietf-roll-mopex-01 (still in the WG) allocates 7 as a field extender
    > (though this is not listed as a dependency)

Right, we aren't sure what will be codepoints 5 and 6, but we suspect that we
might need them before we have an RPLv2.  Maybe.

    > - The intent of this document is to define a compression behavior of MOP 7
    > independently of the eventual outcome of roll-mopex, or indeed what the
    > extended MOP codepoints might want to do

No, that's not the goal.
The intent of this document is to define a compression behaviour for MOP 0..6 only.
We are signaling that before looking at the T flag, you need to know the MOP number.

    > - MOP 7 might indicate there is no T flag, although the current draft says
    > there would be and quick scan of draft-ietf-roll-mopex-01 doesn't reveal
    > why that might be true..

Because mopex doesn't define RPLv2.
mopex gives us enough more bits in order that we can eventually define
things.  Nodes that do not not understand the MOP value join a leaves rather
than routers (and we have several documents that clarify this behaviour).

So, the MOP value is the highest order determination of behaviour.

    > It is entirely possible I missed something critical, but as described this
    > seems unsatisfactory to me.

I think that the first step is to make get you to understand our goals,
and then you can tell us where our text led you astray.

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