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

[Rahul Arvind Jadhav <[e-mail]>]

Thanks Michael for the review and feedback.

Please find my comments inline.


1) If Capabilities and MOD-Extension are mutually independent, why is it in one document?
[RJ] I raised the possibility of keeping it in separate document in IETF 104. But no one voiced any specific reason to separate it out. Even though semantically the Capabilities and MOP-Extns are mutually independent, some of the scenarios discussions might require to discuss them together. Do you believe we should separate it out and if there is any advantage doing so?

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

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

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

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

Are they individualized, or does every node in the
   LLN have to support a capability before it can be used?
[RJ]: Nice point. I haven't thought about this in detail. In non-storing MOP, it may not be required that all the nodes support capabilities but in storing MOP, every 6LR needs to add the cap (if present) of the downstream child, thus requiring every node to support it. This definitely needs handling in the draft.
[Ref: https://github.com/roll-wg/MOPex-capabilities/issues/1]

3) I argued before against the Extended-MOP-value being added to the Base
   MOP. I prefer that the value 7 means *replace* the MOP with the MOPex.
   Yes, that results in two ways to encode MOP="3", but I think that it
   leads to far less confusing code.
[RJ]: I am ok with this approach. Will update the document.
[Ref: https://github.com/roll-wg/MOPex-capabilities/issues/2]

4) 3.2, if the MOP is not 7, and the MOPex is present, what does this mean?
   (Nothing, I think it should be ignored)
   Would we really ever assign a new the value 7?
[RJ] With point 3 accepted, this point is not relevant anymore. (?)

5) section 4.0:

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

I think that you mean, not mutually exclusive?
[RJ] I meant that caps and MOPex do not depend on each other and are mutually independent. May be I should :s/exclusive/independent/ 

4.1: >There are no capability flags defined by this document.

that makes it really hard to know how they work :-)
[RJ] Yeah, should have added an example. Will be done in the next update.
[Ref: https://github.com/roll-wg/MOPex-capabilities/issues/3]

4.2: use of "could" is very non-normative.

>   Capabilities
>   advertised by non-root nodes are strictly a subset of the
>   capabilities advertised by the root.

This should be in REQ3.
[RJ] Actually I am not sure that this will be true going forward. Why can't a intermediate 6LR add its own capability in DIO (without depending on root) for its downstream childs? If this is the case then the draft's above statement is not true. I am glad you pointed this out and wish to discuss more on this.

7.1/7.3. If you take my advance about not adding, but replacing, then this document would Update the Mode of Operation registry, and we would not need a new registry.

==== having done all of this.

How will DAO-projection signal itself?  It seems like a capability to me.
I haven't read that document in a few months.  If it uses capability, then this document that creates capabilities SHOULD probably allocate a bit in it's initial table.
[RJ] I am considering this for the example use-case of caps