Change:
independent i.e. a DIO can have a capabilities option, MOP- extension option or both in the same message. <del> 3. This document reserves existing MOP value 7 to be used as an extender.  DIO messages with MOP value of 7 may refer to the Extended MOP (MOPex) option in the DIO message. </del> <ins> Capabilities could be explicitly queried. </ins> <del> 3.1. An implementation supporting this document MUST calculate the final MOP value as the sum of base MOP (as supported in Section 6.3.1. of RFC6550) plus the MOPex value.  Thus if the MOPex value is 0, it means the final MOP is 7 since the base MOP in this case will be set to 7. </del> <ins> 2.1. </ins> <del> 3.2. </del> <ins> The Mode of Operation (MOP) field in RPL mandates the operational requirement for the nodes joining as routers.  MOP and DIO Configuration Option is strictly controlled by the Root node in RPL. Intermediate 6LRs could not modify the values.  Also, the MOP never changes for the lifetime of the RPL Instance.  Changes in DIO Configuration Option are possible but are very rare.  Capabilities, on the other hand, might change more dynamically. </ins> <del> If the MOPex option is absent in the DIO whose MOP is 7, then the MOPex value can be assumed to be zero (thus the final MOP in this case will be 7).  The MOPex value should be referred only if the base MOP value is 7 and if the MOPex option is present.  In case the base MOP is 7 and if the MOPex option is present, then the implementation MUST calculate the final MOP after considering the value in MOPex. </del> <ins> RPL DIO message also carries routing metrics and constraints as specified in RFC6551.  Metrics and constraints are used as part of objective function which aids in node's rank calculation.  A router may use capabilities carried in DIO message as additional metrics/ constraints.  However, capabilities have a larger scope and may be carried in other messages other than DIO and can flow in both the directions (upstream and downstream). </ins> <del> Note that RFC6550 allows the node who does not support the received MOP to still join the network as a leaf node.  This semantic continues to be true even in case of MOPex. </del> <ins> 3. </ins> <del> 4. </del> <ins> Handling of Capabilities MUST be supported if the network uses MOPex [I-D.jadhav-roll-mopex]. </ins> <del> Currently RPL specification does not have a mechanism whereby a node can signal the set of features that are available on its end.  Such a mechanism could help the root to advertise its capabilities and in response also determine some advanced information about the capabilities of the joining nodes.  The Mode of Operation field in RPL mandates the operational requirement and does not allow loose coupling of additional capabilities.  This document defines Capabilities as additional features which could be supported by the nodes and handshaked as part of RPL signaling.  Capabilities are embedded as RPL control message option as defined Section 6.7 of RFC6550 in the base messages of DIO, DAO and DAO-ACK signaling. Note that capabilities and MOPex are mutually exclusive and it is possible for an implementation to support either or both of the options. 4.1. </del> <ins> 3.1. </ins> Multiple capabilities could be sent in the same message.  The length field allows the message parser to skip the capability TLV parsing.

Discussion:
splitup with mopex differencess with DIO config option, MOP and routing metrics/constraints (fixes for ) sections reliagnment refs updated
The draft should clarify the differences and clearly state when to use when citing examples.
handled in Section 2.1