Re: [Roll] Review [raft-rahul-roll-mop-ext-00]

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

Thank you Georgios for the review and feedback.
Please find my responses inline.

Regards,
Rahul


   REQ2:  Optional capabilities handshake.  Capabilities are features,

          possibly optional, which could be handshaked between the nodes

          and the root within an RPL Instance.

[GP] Maybe few words (to give minimum background) earlier in the Introduction about the "capabilities handshake”? Otherwise it appears too unexpectedly.

[RJ] Yes. Should have introduced capabilities in Introduction section. Will do.



   REQ3:  Backwards compatibility.  The new options and new fields in

          the DIO message should be backward compatible i.e. if there

          are nodes which support old MOPs they could still operate in

          their own instances.



   REQ4:  Capabilities handshake could be optionally added with existing

          MOPs.  Capabilities been optional in nature could be put to

          use with existing MOPs.  Capabilities and MOP-extension is

          mutually independent i.e. a DIO can have a capabilities

          option, MOP-extension option or both in the same message.

[GP] Structurally, I would push REQ4 before REQ3. Since both REQ2 and 4 are related with Capabilities handshake.

[RJ] Or I could swap REQ3 and REQ2 which will make related requirements club together? But yes, I get the point of structuring things together and will update in next ver.



3.  Extended MOP Control Message Option

[GP] A structural comment here, I do not see a Subsection 3.2 and so on, then I do not see why there should be 3.1.

[RJ] Will structure this properly. Should add a separate ‘Extended-MOP Base Rules’ section (which will be Section 3.2).



   This document reserves existing MOP value 7 to be used as an

   extender.

[GP] To make it clear, the value 7 did not represent something till today?

   DIO messages with MOP value of 7 MUST refer to the

   Extended MOP (MOPex) option in the DIO message.  If the MOPex option

   is absent in the DIO whose MOP is 7, then the DIO message MUST be

   silently discarded.

[RJ] MOP=7 does not represent anything today. We have added IANA consideration to reserve MOP=7. This reminds me, I need to add Extended-MOP-Value and Capabilities flag registry in the IANA consideration.


[GP] with the current implementation if this value is 7, what would be the case? It will be silently discarded as well?

[RJ] Thanks for raising this. I tried to check what happens as per 6550. As per 6550 Section 6.3.1, the node can still join the network with unknown MOP as a leaf node. This might have implications and may need handling.



        0                   1                   2                   3

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |   Type = TODO |           Extended-MOP-value                  |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                       Figure 1: Extended MOP Option

[GP] Is it possible to have this Extended MOP option Figure within the actual DIO message?

[RJ] There are 7 bits in Reserved field in DIO base message. But I’m not sure if we can use those bits since otherwise there won’t be any Reserved space left for future play.





4.1.  Capability Control Message Option

[GP] Is there room both for MOPex and for Capability options? Or it will either be one or the other one?

[RJ] The draft allows either or both options. Will make this explicit in next ver.