Re: [Roll] comments on mopex-cap-00

[Michael Richardson <[e-mail]>]

Rahul Arvind Jadhav <[e-mail]> wrote:
    RJ> I raised the possibility of keeping it in separate document in IETF
    RJ> 104. But no one voiced any specific reason to separate it out. Even
    RJ> though semantically the Capabilities and MOP-Extns are mutually
    RJ> independent, some of the scenarios discussions might require to
    RJ> discuss them together. Do you believe we should separate it out and
    RJ> if there is any advantage doing so?

I think that it will be easier for reviewers if the two parts are clearly
separated.  On the other hand, both parts deal with how to do extensions to
the RPL control plane, and there is a non-trivial fixed cost to processing an
RFC.

    mcr> 2) MOP clearly applies to the entire DODAG.  I don't know if
    mcr> Capabilities do from the description:

    doc>    REQ3: Optional capabilities handshake.  Capabilities are features,
    doc> possibly optional, which could be handshaked between the nodes and the
    doc> root within an RPL Instance.

    mcr>    Are they things that the root tells nodes, or things that the node
    mcr> tells the root?

    RJ> MOP is indicated by the root and the whole network has to follow
    RJ> it. The capabilities on the other hand are node specific. For e.g.,
    RJ> the end node can indicate that it supports a primitive via cap flag
    RJ> and this info could be used by the root and vice-versa.  The answer
    RJ> to your questions above is, "Both".

okay, so probably need to have two requirements, and we need to clearly
delineate the two behaviours.

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

    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'll start a new thread.

    > 5) section 4.0:

    doc> Note that capabilities and MOPex are mutually exclusive and it is
    doc> possible for an implementation to support either or both of the
    doc> options.

    mcr> I think that you mean, not mutually exclusive?

    rj> I meant that caps and MOPex do not depend on each other and are
    rj> mutually independent. May be I should :s/exclusive/independent/

yes.

    mcr> How will DAO-projection signal itself?  It seems like a capability to
    mcr> me.  I haven't read that document in a few months.  If it uses
    mcr> capability, then this document that creates capabilities SHOULD
    mcr> probably allocate a bit in it's initial table.

    RJ> I am considering this for the example use-case of caps

If DAO-projection references this document, then they will likely become a
set when published, and we coud probably get them reviewed together.


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