Change:
Modified Capabilities section.
NAME - the complete file seems to be changed! Is it because of the ^M issue? Better you can close this PR and raise another one only with the changes. Thanks
Comments for the PR.

Discussion:
Handling of Capabilities MUST be supported if the network uses MOPex [I-D.jadhav-roll-mopex]. <ins> Note that capabilities and MOPex are mutually exclusive and it is possible for an implementation to support either or both of the options. </ins> 3.1. <ins> Capabilities can be divided into two broad categories Global Capabilities: It will include the features and capability supported across an RPL instance.  These capabilities can be advertised by the Root or 6LRs of the DODAG.  If a Node in the LLN doesn't support a paticular global capability it may have to join the RPL instance as a leaf node, as indicated by that individual capability option.  Example of such capabilities are Compression Methods Supported, Support for TE paths (P-DAO). Local Capabilities: It will include the cpabilities very specific to a Node in the LLN.  Example of such capabilities are NBR Cache information, Routing Table Information. Note that some capabilities can be either global or local depending upon the context they are used ex.P-DAO 3.2. </ins> Multiple capabilities could be sent in the same message.  The length field allows the message parser to skip the capability TLV parsing. Every capability is identified by its type and it may have an optional Capability Info.  Note that a given capability may or may <del> not be diseminated with additional information depending on the 'I' flag. J = Join only as leaf if capability not understood C = Copy capability to children </del> <ins> not be diseminated with additional information depending on the scope of the capability indicated by the G bit.  The first Bit of the CAPType indicates if the capability is mandatory or optional Value of 1 indicates its a mandatory capability and 0 indicates its an optional capability G = If set indicates a Global Capability/Feature else its a local. For a capability if it's mandatory and global bit is set then node thoes either doesn't understand the capability or doesn't have this capability should not join the DODAG as LR.  All the global capablities MUST be desiminated across the network. </ins> I = Cap Info present

document.  This document provides a container format for carrying the capability and its context information. <del> 3.2. </del> <ins> 3.3. </ins> The root node could advertise the set of capabilities it supports in the DIO message.  A node could take advantage of the knowledge that

capabilities advertised by the root. In storing MOP, the DAO message from the 6LR could contain multiple <del> target options.  The targets of the capabilities option are indicated by one or more Target options that precede the Capabilties Option. This handling is similar to the Transit Information Option as supported in Section 6.7.8. of RFC6550. </del> <ins> target options beacuse of the DAO-Aggregation.  The targets of the capabilities option are indicated by one or more Target options that precede the Capabilties Option.  This handling is similar to the Transit Information Option as supported in Section 6.7.8. of RFC6550. 3.4. 3.4.1. I-D.ietf-roll-dao-projection proposes mechanisms to compute and install traffic engineered paths in the RPL network.  It enables an RPL Root to install and maintain Projected Routes based on requested path metric, within its DODAG, along with a selected set of nodes that may or may not include self, for a chosen duration.  Projected Route Capability will be used to enable this TE path calculation. PRC will be an optional global capability.  Any node that does not understand or support the projected route functions can still act as an LR. The DODAG root will use projected routes capability to advertise the support of projected routes with the possible mode of operations and set of path metrics it can use to calculate a projected route.  DODAG root will add the PRC to DIO message so that it can disseminate the information in entire DODAG.  Router nodes in the LLN receiving DIOs with PRC MUST forward the same into their sub-DODAG without any change even though they don't understand or support the projected route feature.LR will use the path metric information advertised by the DODAG root to learn these metrics from the network and neighbors. The same information they will use to advertise in the sibling information option.  LR will also use these path metrics information to request traffic-engineered routes optimizing a or set of specific network metric(s). LRs in the network will use this capability to inform the PCE if they can be part of a storing or non-storing or both mode of projected routes.  Here the PRC will be part of the DAO message. The capability will convey the below information.  The PRC MUST have either of the information or both depending upon the node type.If originator is BR, then both the information MUST be there. Supports projected route for both storing and non-storing mode. List of supported path metrics that supported that can be used to compute projected routes [To Decide] Can we add the PCE address information to this? 3.4.1.1. Type: 0x01. Flags: DODAG root MUST set G bit to 1 plus LRs MUST set it to 0.  I bit will always be set to 1. CAPLen: 8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Length fields. MOP: 3-bit field indicating the mode of operation of projected route capability. Resvd: 5-bit unused fields.They MUST be initialized to zero by the sender and MUST be ignored by the receiver. Routing Merric: 16 bit unsigned integer represetning the the routing metric to be used for TE path calculation.  There can be n number of such routing metric fields.  These fileds are alowed with the PRC sent by the DODAG ROOT.  LRs MUST not send routing metric information with PRC. 3.4.2. RFC8138 introduces a new 6LoWPAN Routing Header (6LoRH) to carry IPv6 routing information.  The 6LoRH may contain source routing information such as a compressed form of SRH, and other sorts of routing information such as the RPI and IP-in-IP encapsulation The transition to RFC8138 in a network can only be done when all nodes support the specification.  In a mixed case with both RFC8138-capable and non-capable nodes it would not be posssible to take advantage of 6LoRH.I-D.thubert-roll-turnon-rfc8138 defines a mechanism to control the use of 6LoRH in a DODAG by using "T" flag bit in RPL configuration option.  To assist DODAG root to decide if it has to set "T" flag bit in RPL Configuration Option to enable 6LoRH within its DODAG, all LRs in DODAG MUST inform their support of RFC 8138 by adding 6LoRH capability TLV to their advertised capability control message option. DODAG root MUST use 6LoRH capability TLV to inform all the nodes in the DODAG, that DODAG is RFC8138 compliance. 6LoRH is an optional local capability. Any LR joining the DODAG MUST add 6LoRH capability TLV to the capability control message option in its DAO message to inform BR that it supports RFC8138.If received DAO message doesn't have 6LoRH capability TLV, DODAG Root MUST conclude the target node doesn't support RFC 8138.So if DODAG is still not using 6LoRH, it MUST refrain from using the compression and if it is already using it, it MUST deny the LR from joining the DODAG with proper error code. [TODO- Need to add new Error code]. 6LoRH capability is an optional capability any node that doesn't understand or support the 6LoRH can join the DODAG if the "T" flag in the RPL Configuration option is not set otherwise it MUST join the network as a leaf node. 3.4.2.1. Type: 0x02. Flags: LRs MUST set it to 0.  I bit will always be set to 0. Reserved: 16-bit unsigned integer, they MUST be initialized to zero by the sender and MUST be ignored by the receiver.. 3.4.3. Storing mode of operation requires each intermediate router in the LLN to maintain routing states' information in the routing table. LLN routers typically operate with constraints on processing power, memory, and energy (battery power).  Memory limits the number of routing states an LR and BR can maintain.  When the routing table of an LR or BR is full, it will either reject the new DAO messages received or will use some replacement policy to remove a routing entry and add the new one.  Rejection of DAO messages will lead to an increase in DAO message transmission that impacts the energy and network convergence time.  Routing state replacement leads to downward path downtime. One possible way to solve problems due to routing table size constraint is to use this information to add neighbors to the DAO parent set.Routing resource capability can be used by LR and BR to advertise their current routing table usage details in the network. LR or LNs in LLN can use this information in the selection of the DAO parent set.  PCE can use this information to select intermediate routers for the projected routes.  Routing Resource is an optional local capability. Routing reource capability TLV can occur multiple times in the capability control message option to advertise below possible routing table information. Master Routing Table Storing Storing mode P-DAO Table Non-Storing mode P-DAO Routing resource capabablity sent in DIO message has link local scope and it MUST not be forwarded. 3.4.3.1. Type: 0x03. Flags: G bit MUST be set to 0.  I bit will always be set to 1. CAPLen: 8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Length fields. RT: 3-bit field indicating the routing resource type.  This document defines 3 routing resource type. Master Routing Table Storing(RT = 1) Storing mode P-DAO Table(RT = 2) Non-Storing mode P-DAO(RT = 3) Resvd: 5-bit unused fields.They MUST be initialized to zero by the sender and MUST be ignored by the receiver. Total Capacity: 16 bit unsigned integer represetning the the routing table size. Percentage used: 8 bit unsigned integer represetning the the percentage of routing table space currently in use. Threshold: 8 bit unsigned integer represetning the maximum routing table space that can be used.  If the routing resource type is RT1 and used Percentage is greater than or equal to a threshold, its siblings MUST stop using it as the preferred parent or remove it from the parent list.  If the routing resource type is RT2 or RT3 and used Percentage is greater than or equal to a threshold, PCE MUST recompute some projected routes by excluding this node. 3.4.4. A neighbor cache maintains neighboring one-hop connected nodes information such as MAC address, link-local IP address and other reachability state information needed for layer two communication.Node density has direct implications on the neighbor cache.  In the constrained network scenario the size of the neighbor cache will be limited.  Thus there are chances that a node may not be able to store all the neighboring nodes in its cache and use replacement algorithms to evict some of the entries to accommodate the new one.  If the replaced neighbor has installed a DAO route on it then it can lead to packet loss or additional address resolution message exchange.  To avoid unnecessary replacement of neighbor cache entries neighbor cache management policy I-D.ietf-lwig-nbr-mgmt- policy proposes a solution that will put a restriction on the connectivity to immediate neighbor depending upon the type of neighbor.  But this won't solve the problem unless until the availability of neighbor cache is not taken into consideration while selecting the DAO parent set. Neighbor Cache capability can be used by LR and BR to advertise their neighbor cache size information.  This capablity information has only link scope and should not be advertised in the entire network. [TODO-- As neighbor cache entries category is not yet standardized i think we can't use it in capability.  With categories format of the TLV is going to chnage.] 3.4.4.1. </ins> 4.