Let's see below,

1-Section 2.4.5.1 states "A RPL Local Instance ID", based on section 4.1.1
trackID definition includes global as well, thus TrackID in section 2.4.5.1
should it be "A RPL Local (or Global) Instance ID ...?"

> It can be either though the expectation is to use local instances. I'm scanning through the doc to ensure its left open.

2- Section 2.4.5.3 states: "A Track that has only one path", should it be: "A
Track that has only one path from Ingress to Egress?"

> WFM

3- Section 2.4.5.8.1: The segment example, could it be formulated based on
Figure 1 or Figure 6? If so, could the figure number be added into brackets for
better understanding of the reader.

> good idea, done.

4- In Section 3.5.1.1 reads: "Packets originated by A to F ....", should it be
" Data Packets originated by A to F ...?"

Well there's no checking in the forwarding operation that it is a "Data" packet.

5- Section 3.5.2.3:
5.1: "are sent A" --> "are sent to A"

> OK

5.2: Table 16. Column P-DAO 1 to C, row Targets. It is empty, is that Ok, or
should it be "E"?

> See in section 3.5. Serial Track Signaling: "the Egress of a Non-Storing Mode P-DAO is an implicit Target that is not listed in the RPL Target Options." So there's no target signaled (no RTO) but E is implicitly a destination as shown in the RIB in table 17.

6- Section 3.6: the sentence "...and Inter-Leg Segments (aka North-South), such
as Segment 2 above which joins Leg 1 and Leg 2..."

6.1: Should it be Segment 5 instead of 2? (Segment 5 is North-South?)

> oups yes! Thanks 😊

6.2: Or it is Segment 2 and both legs 1 and 2 are joined by node "E"?

> E is the Egress (and I is the Ingress)

6.3: Segment 5 is composed only by nodes "B" and "H", right?

> right in this picture. Could be more hops.

7- Section 4.1: "as usual" --> "as specified in https://datatracker.ietf.org/doc/rfc6550/" ?

> Well that's true for all IP routing, longest match in FIB. I changed to "as normal".

8- Section 4.1.1: "...The 'P' flag is encoded in bit position 2 (to be
confirmed by IANA)..." It would be nice to point the IANA Section where it
belongs, e.g. "...The 'P' flag is encoded in bit position 2 (IANA Request
section 11.13 or Table 31)..."

> done

9- Section 4.1.2: Same as above for "1-bit flag (position to be confirmed by
IANA)", for IANA Section 11.14/Table 32

> done

10- Section 5.3:
10.1- Figure 16: "Type" --> "Option Type"

> done

10.2- In The Field descriptions, the description of the "Flags" field is
missing. It would be nice to add 1 sentence about the flags.

>  done

10.2.1- Is this flags field related to the IANA Request of Section 11.11? If
so, please add it into the description.

> done for SIO and VIO

11-Section 5.4: it reads "...An industrial Alliance that uses RPL for a
particular use / environment MAY redefine the use of this field to fit its
needs..." It would be nice to adapt it to include wider scenarios/use cases.
For e.g. "In some scenarios such as the case of an Industrial Alliances that
uses RPL for a particular use / environment MAY redefine the use of this field
to fit its needs..."

> done

12- Section 6.4.2: Figure 18, It would be nice to mark in the Figure the
Ingress and the Egress as in Figure 19.

> done

13- Section 11.11, reads "No bit is currently assigned for the PDR-ACK Flags."
--> "No bit is currently assigned for the VIO Flags." ?

> done