Re: [Roll] Rtgdir last call review of draft-ietf-roll-dao-projection-32

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello again Sue

This took time, I'm sorry. There as quite a lot to do for to try to address your comments rights.
I published result of the first pass:

URL:      https://www.ietf.org/archive/id/draft-ietf-roll-dao-projection-33.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/
HTML:     https://www.ietf.org/archive/id/draft-ietf-roll-dao-projection-33.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-roll-dao-projection
Diff:     https://author-tools.ietf.org/iddiff?url2=draft-ietf-roll-dao-projection-33

Note that your contribution will be acknowledged in the next push, sorry I failed to do it here.
Please see below:


> Reasons Not ready: 

> 1) Text in 
> sections 3.4 and 3.5 have logic gaps that make it difficult to 
> determine if this general discussion is being implemented in section 7 
> (using sections 4 and 6) 


> 2) This document significantly modifies a major specification (RPL) without a prototype
> implementation that interoperates with RPL basic.   One example of how this
> impacts this document is the profile section.  The profile text has 
> editorial issues that make it unclear to a reader not involved in 
> writing the text. 

> 3) Operational details on the two strict rules that 
> prevent looping are unclear in the text.  One example is the 
> “administrator defining the ordering of the RPL domain” in section 
> 3.2. The text hints at what the answer might be, but it seems there are policies.
> 
> Proposed resolution of comments:  Place this specification as 
> experimental or await an implementation.
> 

We need to open a group wide discussion on this. RPL itself shipped without experimental status and it's still there. My personal belief is we need to improve the text but could live a long time with std track. At worse will do a v2. Our experience at ROLL is that Experimental tends to do the opposite of the hoped effect and deter implementers.

In terms of impacts with RPL: The intersection is at the time of encaps and decaps to avoid loops. The rest of the time, the instances live as ships in the night to the interaction is limited.

Since we are defining underlay wormholes, all the traffic that does not match the wormhole entry criteria is not impacted.

Now, I agree that 3.4.2 was confusing and needed rework. Sorry for your pain. Let's see.

> Text in section 3.4 – Technical and/or editorial Paragraph 2 starting 
> with “A track” has a “;” that confuses the text.  It is a critical 
> part of the description of how the encapsulating Source IP address and 
> RPI instance are set. 

Suggestion:

"
   A Track typically forms an underlay to the main Instance, and is
   associated with a Local RPL Instance from which the RPLInstanceID is
   used as the TrackID.  When a packet is placed on a Track, it is
   encapsulated IP-in-IP with a RPL Option containing a RPI which
   signals the RPLInstanceID.  The encapsulating source IP address and
   RPI Instance are set to the Track Ingress IP address and local
   RPLInstanceID, respectively, more in Section 6.3.
"

> The next paragraph jumps into the Track Lane as 
> an alternative to the segment in the main DODAG. It is important to 
> know if the longest-best match is being per RPL instance or across all 
> instances to link the packet to an ingress of a Track Lane or a 
> segment.


Suggestion:

"
   A Track typically offers service protection across several lanes.  As
   a degraded form of a Track, a path made of a single lane (i.e.,
   offering no protection) can be used as an alternative to a Segment
   for forwarding along a RPL Instance.  In that case, instead of
   following native routes along the instance, the packets are
   encapsulated to signal a more specific source-routed path between the
   loose hops in the encapsulated source routing header.
"

> The last sentence in the paragraph that starts with “A track 
> lane” is very confusing.  Perhaps the text makes sense to someone 
> deeply embedded in the RPL community, but it is unclear from the 
> knowledgeable but unfamiliar reader. 


Suggestion:

"
   If the encapsulated packet follows a global instance, then the lane
   may be part that global instance as well, for instance the global
   instance of the main DODAG.  This can only be done for global
   instances because the Ingress node that encapsulates the packets over
   the lane is not the Root of the instance, so the source address of
   the encapsulated packet cannot be used to determine the Track along
   the way.
"



> Text in section 3.5 – Technical 
> and/or editorial Editorial: Please place at top of the example which 
> figure you are using. I assumed figure 6.  Please also indicate that “ 
> in a table indicates the same value. 

done


> Issue-1: Section 3.5, paragraph 
> 8, starting with “Loose sequences of hops” – technical/editorial 
> issue. I cannot find a clear logic step due to the use of commas.  The 
> problem is I need this logic to walk through the rest of the text.  
> Perhaps the authors could provide a bullet point of what they are 
> trying to say. 


Proposed rewording:

"

   Loose sequences of hops are expressed in Non-Storing Mode; this is
   why P-DAO 3 contains a NSM-VIO.  With this specification:

   *  the DODAGID to be used by the Ingress as source address is
      signaled in the DAO base object (see Figure 8) .

   *  the via list in the VIO is encoded as an SRH-6LoRH (see
      Figure 16), and it starts with the address of the first hop node
      after the Ingress node in the loose hop sequence.

   *  the via list ends with the address of the Egress node.

   Note well:

   |  The Egress of a Non-Storing Mode P-Route is always implicitly a
   |  target; it is not listed in the RPL Target Options but still
   |  accounted for as if it was.

   Also:

   |  By design, the list of nodes in a VIO in Non-Storing Mode is
   |  exactly the list that shows in the encapsulation SRH.  So in the
   |  cases detailed below, if the Mode of the P-DAO is Non-Storing,
   |  then the VIO row can be read as indicating the SRH as well. 

"

> Issue-2.  Section 3.5.1.2 Format on inner form in Table 
> 6 in “E if (X !=A), F, or G I think you mean E if (X != A or X !=F or X != G). If so, please modify.  If not, please change text. This issue repeats.
> 

The intention is to say that the destination address can be either
 E but that happens only if X is not A, or F unconditionally, or G unconditionally.
This is because as said above, " Packets from A to E do not require an encapsulation. "

Changed to " either E if(X != A), or F, or G "

Address text above as:
"
   Packets from A to E do not require an encapsulation.  This is why in
   the tables below, E may show as IPv6 Destination Address only if the
   IPv6 Source Address X is different from A.  Conversely, the
   encapsulation is always done when the IPv6 Destination Address is F
   or G.  Other destination addresses do not match this P-Route and are  
   not subject to encapsulation.
"

> Issue-3: Section 5.1.3, Table 7 Target entry for P-DAO 2 to B Why is 
> the entry not “B,C” per your earlier text of  “P-DAO 2 signals A ==> B to B, C”

Good catch. It was commented out in the source, maybe a confusion between storing and non-storing mode.
Maybe we should always make the egress a target for simplicity?


> Issue-4: Section 3.5.1.3, table 9 - E if (X !=A), F, or G I think you 
> mean E if (X != A or X !=F or X != G). If so, please modify the 
> tabl3e.  If not, please change section. 

Changed to " either E if(X != A), or F, or G "


> Issue-5: section 3.5.2.1 
> Editorial/Technical: a) What does ND mean? B) What is it preferred 
> that A encapsulations and C decapsulates? 

A) Added 
"
   As a result the RIBs are set as follows (using ND to indicate that
   the address is discovered by IPv6 Neighbor Discovery
   [RFC4861][RFC8505] or an equivalent method:
"

B) I cannot parse the question. Do you mean: Why is it ... ?
If so, the argument is the same as in RFC 9008, the egress can remove the RPI/SRH with the encaps for delivery and the RUL gets a clean packet with no RPL artifact. Now there is a typo and that's really E doing it. If that's your point, great catch.

Updated the text to

"
   Packets originated at A to E, F and G could be generated with the RPI
   and the SRH, and no encapsulation.  Alternatively, A may generate a
   native packet to the target, and then encapsulate it with an RPI and
   an SRH indicating the source-routed path leading to E, as it would
   for a packet that it routes coming from another node.  This is
   effectively the same case as for packets generated by the root in a
   RPL network in Non-Storing mode, see section 8.1.3 of [RFC9008].  The
   latter is often is preferred since it leads to a single code path,
   and the destination when it is F or G, does no understand and process
   the RPI or the SRH.  

"

> Issue-6: section 3.5.2.2, 
> Table 13, targets, entry for P-DAO 2 Why is the entry not “C, E” since 
> your text states “P-DAO 2 signals A ==> B ==> C to C, E”? 


In this case it is effectively non-storing so the egress is an implicit target.
As said above, we might consider if it would be best to always consider the egress as a target (even in storing mode) which means more rib entries vs. a smaller message and simpler spec.


> Issue-7: 
> section 3.5.2.3, Table 16, targets, P-DAO 1 to C Why is the entry not 
> “E” since your text states “P-DAO 1 signals c == > D == > E
> -to- E”. 

Same as above; E is an implicit target since it is egress of a non-storing P-route

> Section 4.1 extending RFC 6550, paragraph 3, sentence 3 “In 
> the context of this specification, the installed route appears as a 
> more specific route to the Track targets, and the Track Ingress 
> forward packets toward the targets via the Track using the longest match as normal.” Normal for IP?
> Normal for RPL IP?

Well for both. The FIB takes the longest match in the RIBs.


> Section 4.1.4 – How are loops prevented in the multicast DAO?  This is 
> not really clear her or in section 3. 

The origin of the mcast DAO provides the list of all its neighbors so it can serve as a relay between neighbors that are too far apart from one another. You'll find that concept already in MANET with NHDP, RFC 6130.

So there's no routing involved, and as long as the sender of the mcast DAO has the destination as neighbor as advertised, there can be no loop. Keep in mind that direct neighbor has precedence over indirect, which has precedence over routing.

Now if the sender loses the destination as neighbor; loops may occur. If we want to handle that case we could do a number of things, e.g: poison back to the previous hop using the RPI as we do in RPL, decrement the TTL to 2 when sending to an indirect neighbor, keep a state about the neighbor gone and drop packets till more mcast DAOs have cleaned the situation up. What do you think? 

Finally: for  completeness I reread the text on loop avoidance in 6.6.2. and reworded to clarify as follows:
"
   It is known that a packet is forwarded along a Track by the source
   address and the RPI in the encapsulation.  The Track ID is used to
   identify the RIB entries associated to that Track, which, in
   intermediate nodes, correspond to the P-routes for the segments of
   the Track that the forwarding router is aware of.  The packet
   processing uses a precedence that favors self delivery or routing
   header handling when one is present, then delivery to direct
   neighbors, then to indirect neighbors, then routing along a segment
   along the Track, and finally as a last resort injecting the packet in
   another Track.

   To achieve this, the packet handling logic MUST happen in the
   following order:




Thubert, et al.           Expires 15 March 2024                [Page 66]


Internet-Draft               DAO Projection               September 2023


   *  If the destination of the packet is self:

      1.  if the header chain contains a RPL Source Route Header that is
          not fully consumed, then the packet is forwarded along the
          Track as prescribed by [RFC6554], meaning that the next entry
          in the routing header becomes the destination;

      2.  otherwise: if the packet was encapsulated, then the packet is
          decapsulated and the forwarding process recurses; else the
          packet is delivered to the stack.

   *  Otherwise, the packet is forwarded as follows:

      1.  If the destination of the packet is a direct neighbor, e.g.,
          installed by IPv6 Neighbor Discovery, then the packet the
          packet MUST be forwarded to that neighbor;

      2.  Else If the destination of the packet is an indirect neighbor,
          e.g., installed by a multicast DAO message from a common
          neighbor, see Section 4.1.4, then the packet MUST be forwarded
          to the common neighbor;

      3.  Else, if there is a RIB entry for the same Track (e.g.,
          installed by an SM-VIO in a DAO message with the destination
          as target), and the next hop in the RIB entry is a direct
          neighbor, then the packet is passed to that neighbor;

      4.  Else, if there is a RIB entry for the different Track (e.g.,
          installed by an NSM-VIO in a DAO message with the destination
          as target), then the packet is encapsulated to be forwarded
          along that Track and the forwarding process recurses;
          otherwise the packet is dropped.

      5.  To avoid loops, and as opposed to packets that were not
          encapsulated, a packet that was decapsulated from a Track MUST
          NOT be routed along the default route of the main DODAG; this
          would mean that the end-to-end path is uncontrolled.  The node
          that discovers the fault MUST discard the packet.

   The node that drops a packet for either of the reasons above MUST
   send an ICMPv6 Error message [RFC4443] to the Root, with a new Code
   "Error in P-Route" (See Section 11.15).  The Root can then repair by
   updating the broken Segment and/or Tracks, and in the case of a
   broken Segment, remove the leftover sections of the Segment using SM-
   VIOs with a lifetime of 0 indicating the section to one or more nodes
   being removed (See Section 6.6).

"

Note that there can still be a loop of Tracks, but then that's a bug in the controller.
We could have ordered the tracks to avoid that, but that would be added complexity.

> Sections 4-7 have error 
> handling, but I am concerned since I am not an expert in RPL error 
> handling.  I strongly suggest an independent person RPL experience 
> review this text. I am concerned about what happens when messages drop 
> in the midst of a switch from one Track lane to an other or from one 
> segment to another. 

I'll trust my co authors on that. They are some of the most knowledgeable RPL people, bot with implementation experience. Maybe we can also ask Dominique (co-chair) who also has that experience.

> Section 5 – the concept of lifetime being 
> “infinity” for 0xFF needs a clear description.  I believe you set to a 
> value (even 0xFF) and then count down.  If 0xFF is a special value, 
> then it needs to be specified. 

Added " (never time out)"

> Section 6 – Configured values should be 
> carefully specified rather than stated “A reasonable time” see section 6.6.1 in paragraph 3.

That was always problematic with RPL, which deals with a large variety of environments, some with high latency. As the text says, that's what the particular network needs to drain its queues. 


> =============
> Strictly Editorial issues:
> #1 Section 2.3 – missing at least PSE and ARQ.  Please do a search to 
> make sure you have all the abbreviations.  I ran out of time to do that search.


done

>  Was there a reason you did not provide the original place these terms 
> were defined?  Are you assuming that section 1 allows you to skip this step?

Most terms are very familiar in the RPL and radio spaces. I do not even have a clue who defined ARQ or where. For things less common to RPL people like Point of Local Repair (PSE was renamed at RAW) there's text in the first use that provides a reference.


> #2 Section 2.3.5.5:
> This section contains a single run-on sentence with unclear language.   If
> you
> mean that all Serial tracks are created from segments, you could 
> include this in your definition in 2.4.5.3.  If not, please modify 
> both to indicate what you mean. New:/Refers to a Segment or a lane 
> that is installed with a single P-DAO and fully defines a serial Track 
> installed from single Storing Mode Via Information option (SM-VIO). / 

We're talking about section 3.4.5.5. The answer is the "if not". A serial track could also be a lane expressed as a strict source routed path, in which case there's no segment. Following RAW, we are removing that "serial track", just using "path". Proposed slight rewording:
"
    Refers to a Segment or a Lane that is installed with a single P-DAO that
    fully defines the path, e.g., a stand-alone segment is installed
    with a single Storing Mode Via Information option (SM-VIO) all the way
    between Ingress and Egress.
"



> #3: Section 3.2, paragraph 8 The two strict ordering rules would 
> benefit from a numerical list in the order.  Here are possible text 
> changes for this paragraph: New-1/ The possible forwarding methods are 
> the following: 1)  to a direct next hop,  2) to an indirect neighbor 
> via a common neighbor, 3) along a segment, and 4) along a track./ 

Done. Also indicated a reference to section 6.7.  Encapsulating and Forwarding Along a Track



> New-2/ A RPL Instance may leverage another instance if and if only if 
> that other Instance is higher in the order defined by the operator.  
> Higher instances [should/must?] be defined as higher if they are 
> farther away from the main instance. / The text is unclear how the 
> operator will know what the ordering should be. 


Makes sense. I also split the 7th paragraph for more clarity.

"
Routing in a multi-topology domain may cause loops unless strict
   rules are applied.  This specification defines two strict orders to
   ensure loop avoidance when projected routes are used in a RPL domain,
   one between forwarding methods and one between RPL Instances, seen as
   routing topologies.

   The first and strict order relates to the forwarding method and the
   more specifically the origin of the information used in the next-hop
   computation.  The possible forwarding methods are: 1) to a direct
   next hop, 2) to an indirect neighbor via a common neighbor, 3) along
   a Segment, and 4) along a nested Track.  The methods are strictly
   ordered as listed above, more in Section 6.7.  A forwarding method
   may leverage any of the lower order ones, but never one with a higher
   order; for instance, when forwarding a packet along a Segment, the
   router may use direct or indirect neighbors but cannot use a Track.
   The lower order methods have a strict precedence, so the router will
   always prefer a direct neighbor over an indirect one, or a Segment
   within the current RPL Instance vs. another Track.

   The second strict and partial order is between RPL Instances.  It
   allows the RPL node to detect an error in the state installed by the
   PCE, e.g., after a desynchronization.  That order must be defined by
   the administrator for his RPL domain and defines a DODAG of underlays
   with the main Instance as Root.  The relation of RPL instances may be
   represented as a DODAG of instances where the main instance is Root.
   The rule is that a RPL Instance may leverage another RPL instance as
   underlay if and only if that other Instance is one of its descendants
   in the graph.  Supporting this method is OPTIONAL for nested Tracks
   and REQUIRED between a Track instance and the main instance.  It may
   be done using network management, or future extensions to this
   specifications.  When it is not communicated, then the RPL nodes
   consider by default that all Track instances are children of the main
   instance, and do not attempt to validate the order for nested Tracks,
   trusting the PCE implicitly.  As a result, a packet that is being
   forwarded along the main Instance may be encapsulated in any Track,
   but a packet that was forwarded along a Track MUST NOT be forwarded
   along the default route of main Instance. "


> #3 section 3.3, 
> paragraph 3. Old: /Limiting the packet size is directly beneficial to 
> the energy budget, but mostly, it reduces the changes of frame loss 
> and packet fragmentation, which are high detrimental to the LLN 
> operational.] The sentences should be rewritten as two sentences.  I 
> believe you are saying: 1) reduces packet size cuts transmission time 
> + reduces frame loss + packet fragmentation. You are indicating that 
> reasons #2 and #3 are more important than #1.  Please just state that. 

Proposed:

"
   Limiting the packet size is beneficial to the energy
   budget, directly for the current transmission, but also indirectly
   since it reduces the chances of frame loss and energy spent in
   retries, e.g., by ARQ over one hop at Layer-2, or end-to-end at upper
   layers.  Using smaller packets also reduces the chances of packet
   fragmentation, which is highly detrimental to the LLN operation, in
   particular when fragments are forwarded but not recovered, see
   [RFC8930] vs. [RFC8931] for more.
"

> Note – after section 4, my editorial review was brief so I may have 
> missed some of the sentence which use the “;” in an improper way. 




#4 
> section 4.1.1, paragraph 3 starting “This document Amends” Unless it is clearly specified in standards, then “AMENDS” or whatever is used. #5  section 4.1.4 to end RAN is an abbreviation that is widely used.  I suggest you pick another abbreviation:
> RPLAN

RAN is a RPL term defined in rfc9008 ; I added that reference in the Terminology section.


I used 2 commits to get through this pass:
- https://github.com/roll-wg/dao-projection/commit/e1e583e25f4d400653e92d41b4961f3cd428f08c
- https://github.com/roll-wg/dao-projection/commit/b4a5ad8237fb21642147e933ac766344329259a4 for the largest 
 


 Pascal
> 
> > -----Original Message-----
> > From: Susan Hares via Datatracker <[e-mail]>
> > Sent: Wednesday, August 23, 2023 11:56 PM
> > To: [e-mail]
> > Cc: [e-mail]; [e-mail];
> > [e-mail]
> > Subject: Rtgdir last call review of draft-ietf-roll-dao-projection-32
> >
> > Reviewer: Susan Hares
> > Review result: Has Issues
> >
> > Status: Has Issues
> > Summary:
> > This specification demonstrates an amazing amount of work.  I commend
> > the authors for their creativity and their diligence in forging
> > forward on new concepts in routing. Reasons Not ready: 1) Text in
> > sections 3.4 and 3.5 have logic gaps that make it difficult to
> > determine if this general discussion is being implemented in section 7
> > (using sections 4 and 6) 2) This document significantly modifies a major
> specification (RPL) without a prototype
> > implementation that interoperates with RPL basic.   One example of how
> this
> > impacts this document is the profile section.  The profile text has
> > editorial issues that make it unclear to a reader not involved in
> > writing the text. 3) Operational details on the two strict rules that
> > prevent looping are unclear in the text.  One example is the
> > “administrator defining the ordering of the RPL domain” in section
> > 3.2. The text hints at what the answer might be, but it seems there are
> policies.
> >
> > Proposed resolution of comments:  Place this specification as
> > experimental or await an implementation.
> >
> > Text in section 3.4 – Technical and/or editorial Paragraph 2 starting
> > with “A track” has a “;” that confuses the text.  It is a critical
> > part of the description of how the encapsulating Source IP address and
> > RPI instance are set.  The next paragraph jumps into the Track Lane as
> > an alternative to the segment in the main DODAG. It is important to
> > know if the longest-best match is being per RPL instance or across all
> > instances to link the packet to an ingress of a Track Lane or a
> > segment. The last sentence in the paragraph that starts with “A track
> > lane” is very confusing.  Perhaps the text makes sense to someone
> > deeply embedded in the RPL community, but it is unclear from the
> > knowledgeable but unfamiliar reader. Text in section 3.5 – Technical
> > and/or editorial Editorial: Please place at top of the example which
> > figure you are using. I assumed figure 6.  Please also indicate that “
> > in a table indicates the same value. Issue-1: Section 3.5, paragraph
> > 8, starting with “Loose sequences of hops” – technical/editorial
> > issue. I cannot find a clear logic step due to the use of commas.  The
> > problem is I need this logic to walk through the rest of the text.
> > Perhaps the authors could provide a bullet point of what they are
> > trying to say. Issue-2.  Section 3.5.1.2 Format on inner form in Table
> > 6 in “E if (X !=A), F, or G I think you mean E if (X != A or X !=F or X
> != G). If so, please modify.  If not, please change text. This issue
> repeats.
> >
> > Issue-3: Section 5.1.3, Table 7 Target entry for P-DAO 2 to B Why is
> > the entry not “B,C” per your earlier text of  “P-DAO 2 signals A ==> B
> to B, C”
> > Issue-4: Section 3.5.1.3, table 9 - E if (X !=A), F, or G I think you
> > mean E if (X != A or X !=F or X != G). If so, please modify the
> > tabl3e.  If not, please change section. Issue-5: section 3.5.2.1
> > Editorial/Technical: a) What does ND mean? B) What is it preferred
> > that A encapsulations and C decapsulates? Issue-6: section 3.5.2.2,
> > Table 13, targets, entry for P-DAO 2 Why is the entry not “C, E” since
> > your text states “P-DAO 2 signals A ==> B ==> C to C, E”? Issue-7:
> > section 3.5.2.3, Table 16, targets, P-DAO 1 to C Why is the entry not
> > “E” since your text states “P-DAO 1 signals c == > D == > E
> > -to- E”. Section 4.1 extending RFC 6550, paragraph 3, sentence 3 “In
> > the context of this specification, the installed route appears as a
> > more specific route to the Track targets, and the Track Ingress
> > forward packets toward the targets via the Track using the longest match
> as normal.” Normal for IP?
> > Normal for RPL IP?
> > Section 4.1.4 – How are loops prevented in the multicast DAO?  This is
> > not really clear her or in section 3. Sections 4-7 have error
> > handling, but I am concerned since I am not an expert in RPL error
> > handling.  I strongly suggest an independent person RPL experience
> > review this text. I am concerned about what happens when messages drop
> > in the midst of a switch from one Track lane to an other or from one
> > segment to another. Section 5 – the concept of lifetime being
> > “infinity” for 0xFF needs a clear description.  I believe you set to a
> > value (even 0xFF) and then count down.  If 0xFF is a special value,
> > then it needs to be specified. Section 6 – Configured values should be
> > carefully specified rather than stated “A reasonable time” see section
> 6.6.1 in paragraph 3.
> > =============
> > Strictly Editorial issues:
> > #1 Section 2.3 – missing at least PSE and ARQ.  Please do a search to
> > make sure you have all the abbreviations.  I ran out of time to do that
> search.
> >  Was there a reason you did not provide the original place these terms
> > were defined?  Are you assuming that section 1 allows you to skip this
> step?
> > #2 Section 2.3.5.5:
> > This section contains a single run-on sentence with unclear language.
> If
> > you
> > mean that all Serial tracks are created from segments, you could
> > include this in your definition in 2.4.5.3.  If not, please modify
> > both to indicate what you mean. New:/Refers to a Segment or a lane
> > that is installed with a single P-DAO and fully defines a serial Track
> > installed from single Storing Mode Via Information option (SM-VIO). /
> > #3: Section 3.2, paragraph 8 The two strict ordering rules would
> > benefit from a numerical list in the order.  Here are possible text
> > changes for this paragraph: New-1/ The possible forwarding methods are
> > the following: 1)  to a direct next hop,  2) to an indirect neighbor
> > via a common neighbor, 3) along a segment, and 4) along a track./
> > New-2/ A RPL Instance may leverage another instance if and if only if
> > that other Instance is higher in the order defined by the operator.
> > Higher instances [should/must?] be defined as higher if they are
> > farther away from the main instance. / The text is unclear how the
> > operator will know what the ordering should be. #3 section 3.3,
> > paragraph 3. Old: /Limiting the packet size is directly beneficial to
> > the energy budget, but mostly, it reduces the changes of frame loss
> > and packet fragmentation, which are high detrimental to the LLN
> > operational.] The sentences should be rewritten as two sentences.  I
> > believe you are saying: 1) reduces packet size cuts transmission time
> > + reduces frame loss + packet fragmentation. You are indicating that
> > reasons #2 and #3 are more important than #1.  Please just state that.
> > Note – after section 4, my editorial review was brief so I may have
> > missed some of the sentence which use the “;” in an improper way. #4
> > section 4.1.1, paragraph 3 starting “This document Amends” Unless it is
> clearly specified in standards, then “AMENDS” or whatever is used. #5
> section 4.1.4 to end RAN is an abbreviation that is widely used.  I
> suggest you pick another abbreviation:
> > RPLAN
> >
> >