[Roll] do capabilities need to understood, can they be added?

[Michael Richardson <[e-mail]>]

I asked:

    mcr> Are they individualized, or does every node in the LLN have to support
    mcr> a capability before it can be used?

Rahul Arvind Jadhav <[e-mail]> wrote:
    rj> Nice point. I haven't thought about this in detail. In non-storing
    rj> MOP, it may not be required that all the nodes support capabilities
    rj> but in storing MOP, every 6LR needs to add the cap (if present) of
    rj> the downstream child, thus requiring every node to support it. This
    rj> definitely needs handling in the draft.  [Ref:
    rj> https://github.com/roll-wg/MOPex-capabilities/issues/1

I see:

1) the root announces a capability.  6LRs that understand it may use the
   new capability unilaterally if they understand it, and see a need for it.
   Nodes that do not understand the new capability are not affected.
   This could be a control plane thing, or a data plane thing.

2) the root announces support for capability that it wishes to enable, in
   order for it be used, every node must support it.  If every DAO from
   every node supports the capability, then the root announces that it
   is turned on.
   This in effect is a two-pass system, requiring either two capability
   bits.
   It might be that it is better to encode these two bits are three
   values (plus 00-not supported).

3) any 6LR may announce a capability to it's children that it received from
   it's parent, if it understands that capability.  If it does not, then
   it MUST clear the capability.

   This can be a unilateral capability (like 1), or one that has to be
   confirmed (like 2).  So this is really 3A and 3B.

4) any 6LR may announce a capability to it's children, even if it did not
   receive it from a parent.  The capability is not to be repeated by
   the children (regardless of whether they understand it), unless they also
   wish to enable it.

I therefore see several issues to resolve.
For capabilities that a node understands, it can know which type of
capability it is.  For a capability that is unknown, if the behaviour
is other than "set to zero", then we need to tell the node what kind of
capability it is, and how it is encoded.

Counting above, I see (1)-available, (2)-query, (2)-enable, (3)-available,
(3)-query, (3)-enable, (4)-available.  Conveniently, 7 things, plus all
zeros.  We could encode capabilities in three bits, so the behaviour would
be part of the encoded.

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