Change:
This covers the text from the beginning up to Section 7.2.1. These were reviewed with Pascal on March 26th. I will continue my review from Section 7.2.2 forward. More trivial editorial suggestions to follow, as well.
Many thanks for these fixs.

Discussion:
serving.  An isolated LoWPAN also contains a 6LBR in the network, which provides the prefix(es) for the isolated network." <del> Flag Day: A transition that involves having a network with different values of RPI Option Type.  Thus the network does not work correctly (Lack of interoperation). </del> <ins> Flag Day: In this document, refers to a transition that involves having a network with different values of RPI Option Type. </ins> Non-Storing Mode (Non-SM): RPL mode of operation in which the RPL- aware-nodes send information to the root about their parents.  Thus,

A RUL is a special case of external target when the target is actually a host and it is known to support a consumed Routing Header and to ignore a HbH header as prescribed by RFC8200.  The target may <del> have been learned through as a host route or may have been registered to the 6LR using RFC8505. </del> <ins> have been learned through an external routing protocol or may have been registered to the 6LR using RFC8505. </ins> In order to enable IP-in-IP all the way to a 6LN, it is beneficial that the 6LN supports decapsulating IP-in-IP, but that is not assumed

The leaves marked as RUL (G and J) are devices which do not speak RPL at all (not-RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/ <del> DAC and efficient-ND only to participate in the network RFC6775.  In </del> <ins> DAC and 6LoWPAN ND only to participate in the network RFC8505.  In </ins> the document these leaves (G and J) are also referred to as an IPv6 node.

outer IP header.  The new header is placed after this new outer IP header. <del> A corollary is that an RH3 or RPL Option can only be removed by an intermediate router if it is placed in an encapsulating IPv6 Header, which is addressed TO the intermediate router.  When it does so, the </del> <ins> A corollary is that an intermediate router can remove an RH3 or RPL Option only if it is placed in an encapsulating IPv6 Header that is addressed TO this intermediate router.  When doing the above, the </ins> whole encapsulating header must be removed.  (A replacement may be added).  This sometimes can result in outer IP headers being addressed to the next hop router using link-local address.

the RPI down to three bytes or less removes much of the pressure to optimize this any further I-D.ietf-anima-autonomic-control-plane. <del> The earlier examples are more extensive to make sure that the process is clear, while later examples are more concise. </del> <ins> Throughout the following subsections, the examples are described in more details in the first subsections, and more concisely in the later ones. </ins> <del> The uses cases are delineated based on the following requirements: </del> <ins> The uses cases are delineated based on the following IPV6 and RPL mandates: </ins> The RPI has to be in every packet that traverses the LLN.

addressed to: (1) the final destination (the RAL node that is the target (tgt)), (2) the "root", or (3) the 6LR parent of a RUL. <del> In cases where no IPv6-in-IPv6 header is needed, the column states as "No".  If the IPv6-in-IPv6 header is needed, the column shows "must". </del> <ins> In cases where no IPv6-in-IPv6 header is needed, the column states "No", and the destination is N/A (Not Applicable).  If the IPv6-in- IPv6 header is needed, the column shows "must". </ins> In all cases, the RPI is needed, since it identifies inconsistencies (loops) in the routing topology.  In general, the RH3 is not needed because it is not used in storing mode.  However, there is one scenario (from the root to the RUL in SM) where the RH3 can be used <del> to indicate the RUL (Storing-root2notrplnoIPIP). </del> <ins> to point at the RUL (Storing-root2notrplnoIPIP). </ins> The leaf can be a router 6LR or a host, both indicated as 6LN.  The root refers to the 6LBR (see fig_CommonTopology).

number of routers (6LR) that the packet goes through from the 6LBR (Node A) to the RUL (Node G). <del> The 6LBR will insert an RPI, encapsulated in a IPv6-in-IPv6 header. The IPv6-in-IPv6 header is addressed to the 6LR parent of the RUL (6LR_n).  The 6LR parent of the RUL removes the header and sends the packet to the RUL. </del> <ins> The 6LBR will encapsulate the packet in an IPv6-in-IPv6 header, and prepend an RPI.  The IPv6-in-IPv6 header is addressed to the 6LR parent of the RUL (6LR_n).  The 6LR parent of the RUL removes the header and sends the packet to the RUL. </ins> The Storing-root2notrpl summarizes what headers are needed for this use case.

routers (6LR) that the packet goes through from the RUL to the 6LBR. When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), <del> the 6LR_1 will insert an RPI, encapsulated in a IPv6-in-IPv6 header. The IPv6-in-IPv6 header is addressed to the root (Node A).  The root removes the header and processes the packet. </del> <ins> the 6LR_1 will insert encapsulate the packet in an IPv6-in-IPv6 header and prepend an RPI.  The IPv6-in-IPv6 header is addressed to the root (Node A).  The root removes the header and processes the packet. </ins> The Storing-notrpl2root shows the table that summarizes what headers are needed for this use case where the IPv6-in-IPv6 header is

in-IPv6 header to the root.  Thus, the root removes the RPI and send the packet to the Internet. <del> No IPv6-in-IPv6 header is required. </del> Note: In this use case, it is used a node as a leaf, but this use case can be also applicable to any RPL-aware-node type (e.g. 6LR)