Subject: [Roll] AD Review of draft-ietf-roll-turnon-rfc8138-07

From: Alvaro Retana <[email-masked]>
Date: Wed, 1 Jul 2020 09:44:35 -0700

Dear authors:

I hope you are doing well and staying healthy!

In short, I believe that the specification in this draft is
incomplete.  Specifically:

(1) §5.2 talks about the use of a single RPL instance, where an extra OCP is
    needed.  However, that OCP is not defined/assigned anywhere.  It then
    seems to me that this scenario cannot be implemented.  Am I missing
    something?  Is the intent of this section to specify the scenario, or
    simply as an example of something that was considered but not recommended
    (in favor of §5,3)?

(2) The text talks in several places about how a "parent router must
    know...when a leaf does not support the compression defined in
    [RFC8138]."  There is no specification related to *how* the parent would
    know.  The only hint is in the Introduction: "by configuration, or
    leveraging "RPL Capabilities" [CAPABILITIES]".  Note that the rest of the
    text doesn't even mention configuration as an option.

    I know that there's some resistance to normatively depend on
    draft-ietf-roll-capabilities.  However, the specification does use
    Normative language when describing the expected action based on the
    knowledge of support (or not); for example "delivering to a leaf that is
    not known to support [RFC8138], in which cases it MUST uncompress the
    packet." (§4)   Knowing that a capability is not yet explicitly defined
    for this use, I think there are a couple of ways forward:

    (a) Define, in this document or draft-ietf-roll-capabilities, the
    capability to indicate support for rfc8138.  Make
    draft-ietf-roll-capabilities a Normative reference.

    (b) Specify that the current method to know if the leaf supports rfc8138
    is (only) configuration.  Take all references to
    draft-ietf-roll-capabilities out.

    [Personal opinion: (a) is the complete solution.]

(3) §3 says that ""T" flag is defined only for MOP value between 0 to 6".
    The current registry is not set up for this type of assignment, so it
    needs to be updated (see more specifics below).

I will wait for these points to be addressed before moving the
document forward.  I also have more comments inline below.

Thanks!!

Alvaro.

[Line numbers from idnits.]

...
11	Abstract

13	   This document updates RFC 8138 and RFC 6550 by defining a bit in the
14	   RPL configuration option to indicate whether RFC 8138 compression is
15	   used within the RPL Instance, and specify the behavior of RFC
16	   8138-capable nodes when the bit is set and reset.

[major] rfc6550 talks about the "DODAG Configuration option", and not
about a "RPL configuration option".  Please be consistent!

...
70	1.  Introduction

72	   The transition of a RPL [RFC6550] network to activate the compression
73	   defined in [RFC8138] can only be done when all routers in the network
74	   support it.  Otherwise, a non-capable node acting as a router would
75	   drop the compressed packets and black-hole its subDAG.  In a mixed
76	   case with both RFC8138-capable and non-capable nodes, the compression
77	   may be turned on only if all the non-capable nodes act as Hosts and
78	   their RPL parents handle the compression/decompression for them.

[nit] Expand/explain subDAG.

...
128	2.2.  Glossary

130	   This document often uses the following acronyms:

[nit] Some of the acronyms were already defined in the previous section.

...
147	2.3.  BCP 14

[minor] s/BCP 14/Requirements Language

...
155	3.  Updating RFC 6550

[major] I don't think that a formal Update to rfc6550 is necessary.
In general, a formal Update indicates (at least to me) that an rfc6550
implementation has to also support this specification.  IOW, all RPL
routers will have to support the new flag to be compliant with
rfc6550.  Also, rfc8138 did not formally Update rfc6550.

[minor] I think that this section could be reorganized a little: start
by telling the reader what the Configuration Option is and that it is
distributed everywhere...this should provide background to understand
the availability of the T bit in the network.

157	   This specification defines a new flag "Enable RFC8138 Compression"
158	   (T).  The "T" flag is set to turn on the use of the compression of
159	   RPL artifacts with [RFC8138] within a RPL Instance.  If a RPL
160	   Instance has multiple Roots then they must be coordinated to use the
161	   same setting.

[major] Do we need a Normative MUST in the last sentence?  What is the
effect of the roots not coordinating?

163	   RPL defines a Configuration Option that is registered to IANA in
164	   section 20.14. of [RFC6550].  The "T" flag is encoded in one of the
165	   reserved control bits in the RPL Configuration Option.  The bit
166	   position of the "T" flag is indicated in Section 6.

[minor] "RPL defines a Configuration Option that is registered to IANA
in section 20.14. of [RFC6550]."  The Configuration Option (the whole
thing) is not registered to IANA, the Flags have a registry managed by
IANA.

[minor] It would be very nice if the packet format was shown here with
the new flag.

168	   Section 6.3.1.  of [RFC6550] defines a 3-bit Mode of Operation (MOP)
169	   in the DIO Base Object.  The new "T" flag is defined only for MOP
170	   value between 0 to 6.  For a MOP value of 7 or above, the flag MAY
171	   indicate something different and MUST NOT be interpreted as "Enable
172	   RFC8138 Compression" unless the specification of the MOP indicates to
173	   do so.

[major] The last sentence is not needed: the second one already says
that the flag is only valid for 0-6.

Also, I think there's a Normative conflict with "MAY indicate
something different and MUST NOT be interpreted as...unless the
specification of the MOP indicates to do so."  Perhaps, if you really
want to keep some text, you can include something like this:

   A document defining a MOP with value 7 or above MUST specify the behavior
   of the T flag.

[major] Regardless of the text, this document is specifying a split in
the registry (at last for this flag): it applies to some MOPs, but not
all.  The registry needs to be updated in the IANA Considerations
section to show that difference.  Is this update being done somewhere
else?

I thought that draft-ietf-roll-mopex would be a good place, but the
update doesn't seem to be there.  The intent of not applying to all
the MOPs can't be finalized until the registry can reflect it.

175	4.  Updating RFC 8138

177	   A node that supports this specification MUST source packets in the
178	   compressed form using [RFC8138] if and only if the "T" flag is set.
179	   This behaviour can be overridden by the configuration of the node in
180	   order to cope with intermediate implementations of the Root that
181	   support [RFC8138] but not this specification and cannot set the "T"
182	   flag.

[nit] s/A node that supports this specification/A node

[major] "MUST...if and only if...behaviour can be overridden"   s/MUST/SHOULD

184	   The decision of using [RFC8138] is made by the originator of the
185	   packet depending on its capabilities and its knowledge of the state
186	   of the "T" flag.  A router that encapsulates a packet is the
187	   originator of the resulting packet and decides whether to compress
188	   the outer headers as indicated above.  An external target
189	   [USEofRPLinfo] is not expected to support [RFC8138].  An intermediate
190	   router MUST forward the packet in the form that the source used,
191	   either compressed or uncompressed, unless it is forwarding to an
192	   external target or delivering to a leaf that is not known to support
193	   [RFC8138], in which cases it MUST uncompress the packet.

[minor] "as indicated above"  Where?

[major] "MUST forward...unless...MUST"  That's a strange construct
with the exception in the middle.

NEW>
   An intermediate router MUST uncompress a packet that is to be forwarded
   to an external target or delivered to a leaf that is not known to support
   [RFC8138].  Otherwise, the router MUST forward the packet in the form that
   the source used, either compressed or uncompressed.

[major] "not known"  How would the router know?  §1 mentions
capabilities as an example), but that is not part of the
specification...the MUSTs above make it so.

195	5.  Transition Scenarios
...
207	   A node that does not support [RFC8138] can interoperate with nodes
208	   that do in a network with [RFC8138] compression turned off.  If the
209	   compression is turned on, the node cannot forward compressed packets
210	   and therefore it cannot act as a router.  It may remain connected to
211	   that network as a leaf, generates uncompressed packets, and can
212	   receive packets if they are delivered by the parent router in the
213	   uncompressed form.  Unless this is known by other means, the node
214	   SHOULD join as a RUL as an indication that its parent router needs to
215	   uncompress the packets before delivering.

[nit] s/generates/generate

[minor] "this is known"  This, what?  Assuming that "this" refers to
the lack of support for rfc8138, we're then to the question of *how*
would it be known.

[major] "the node SHOULD join as a RUL"  To be clear, we're talking
about a node that doesn't support rfc8138, right?  I'm assuming that
if it doesn't support rfc8138 then it won't support this specification
either -- then we can't normatively define anything that this type of
node would do!

217	   [RFC6550] states that "Nodes other than the DODAG Root MUST NOT
218	   modify this information when propagating the DODAG Configuration
219	   option".  Therefore, even a legacy parent propagates the "T" flag as
220	   set by the Root whether it supports this specification or not.  So
221	   when the "T" flag is set, it is transparently flooded to all the
222	   nodes in the RPL Instance.

[major] s/[RFC6550] states/[RFC6550] states, when referring to the
DODAG Configuration option,

224	   Sections 8.5 and 9.2 of [RFC6550] also suggests that a RAN may only
225	   attach to a DODAG as a leaf when it does not support the Mode of
226	   Operation of a RPL Instance, the Objective Function (OF) as indicated
227	   by the Objective Code Point (OCP) or some other parameters in the
228	   configuration option.

[minor] s/also suggests that a RAN may only attach/specify that a RAN may attach

230	   This specification reiterates that a RAN that is configured to
231	   operate in a RPL Instance but does not support a value for a known
232	   parameter that is mandatory for routing, such as the OCP, MUST NOT
233	   operate as a router but MAY still join as a leaf.  Note that a legacy
234	   RAN will not recognize when a reserved field is used and will not
235	   turn to a leaf when the "T" flag is set.

[major] "This specification reiterates..."  Saying things again is not
a big deal; but normatively specifying them is.  In this case it is
not only not necessary, but also has no effect over nodes that don't
support this document...so it is not needed.

...
244	5.1.  Inconsistent State While Migrating

246	   When the "T" flag is turned on in the configuration option by the
247	   Root, the information slowly percolates through the DODAG as the DIO
248	   gets propagated.

[?] How slow?  Seconds, minutes?

250	   Some nodes will see the flag and start sourcing packets in the
251	   compressed form while other nodes in the same RPL Instance are still
252	   not aware of it.  Conversely, in non-storing mode, the Root will
253	   start using [RFC8138] with a Source Routing Header 6LoRH (SRH-6LoRH)
254	   that routes all the way to the parent router or to the leaf.

[minor] I don't understand how the second sentence reverses
("Conversely") the statement in the first sentence...or how the mode
affects the outcome of nodes (including the Root) sending compressed
packets when others may not still be aware of the flag or able to
support receiving the packets...

[minor] "[RFC8138] with a Source Routing Header 6LoRH (SRH-6LoRH)"
sounds redundant.  Also, this is the only place in the document where
the use of rfc8138 is coupled with the SRH-6LoRH.  Not wrong, just
redundant and inconsistent.  If needed, the sentence can be
restructured.

256	   To ensure that a packet is forwarded across the RPL Instance in the
257	   form in which it was generated, it is required that all the routers
258	   support [RFC8138] at the time of the switch, and that all nodes that
259	   do not support [RFC8138] only operate as leaves.

261	   Setting the "T" flag is ultimately the responsibility of the network
262	   administrator.  In a case of upgrading a network to turn the
263	   compression on, the network SHOULD be operated with the "T" flag
264	   reset until all targeted nodes are upgraded to support this
265	   specification.  Section 5.2 and Section 5.3 provide possible
266	   transition scenarios where this can be enforced.

[major] This section talks about inconsistencies, and it is "required
that all the routers support [RFC8138]", but then not setting the T
flag is only recommended.  Why/when is it ok to set the flag if it is
known that not all nodes support rfc8138?  IOW, why not use MUST?

268	5.2.  Single RPL Instance Scenario

270	   In a Single RPL Instance Scenario, nodes that support [RFC8138] are
271	   configured with a new OCP, that may use the same OF operation or a
272	   variation of it, while nodes that do not support [RFC8138] are not,
273	   but are configured to join an unknown OCP.

[major] A new OCP?  I only see 2 OCPs in the registry -- unless I'm
missing something, there's no way to configure "a new OCP, that may
use the same OF".

...
279	   The parent router - which supports [RFC8138] - compresses the packets
280	   originated from the leaf and uncompresses the packets going to the
281	   leaf.  This may be done on the fly by the parent of a non-capable
282	   RAL, or as part of the tunneling operation between the parent and the
283	   Root, if the leaf behaves as a RUL.  This is described in section 7,
284	   8, and 9 of [USEofRPLinfo].

[nit] s/This is/This operation is

286	   Note that though tunneling from the Root to the parent is the generic
287	   case for RULs, on paper it is possible for the Root to avoid it for
288	   the traffic that it originates.  The Root SHOULD always use tunneling
289	   to the parent of a RUL, even for its own packets, unless it knows
290	   that the leaf supports [RFC8138].

[nit] s/on paper/

[major] "RUL...unless it knows that the leaf supports [RFC8138]"
Isn't this a contradiction?  [BTW, §1 says that RULs implicitly don't
support rfc8138.]

[major] "unless it knows that the leaf supports [RFC8138]"  Assuming
you're not talking about a RUL, how do you know?  §1 mentions
capabilities as an example, but that is not part of the
specification...the SHOULD above makes it so.

...
294	   *  The method consumes an extra OCP.  It also forces nodes that do
295	      not support [RFC8138] to operate as RULs, unless there is a method
296	      to let the parent router know that it must uncompress the packet
297	      for this RAL.

[major] What is this "method to let the parent router know..."?

299	   *  If the RPL implementation of a node does not turn it to a leaf
300	      when the OCP is changed to an unknown one, then the node may be
301	      stalled.

[minor] Right, but then this implementation wouldn't be compliant with rfc6550.

303	   *  If the only possible parents of a node are nodes that do not
304	      support [RFC8138], then that node will loose all its parent at the
305	      time of the migration and it will be stalled until a parent is
306	      deployed with the new capability.

[minor] If the parents don't support rfc3183 then they would have
joined as leaves anyway (because of the new OCP) and wouldn't really
be available as parents, right?  What am I missing?

308	5.3.  Double RPL Instances Scenario
...
319	   Nodes that support [RFC8138] participate in both Instances but favor
320	   the new RPL Instance for the traffic that they source.  By contrast,
321	   nodes that only support the uncompressed format would either not be
322	   configured for the new RPL Instance, or would be configured to join
323	   it as leaves only.

[major] "Nodes that support [RFC8138]...favor the new RPL Instance for
the traffic that they source..."   Support for rfc8138 doesn't require
compression.  IOW, a node that supports rfc8138 can compress, but it
doesn't have to, right?  I think you need to be more specific when
talking about "favor"; does it mean that the routers SHOULD use the
new instance?

...
330	   The 2 instances MUST be operated with the same security guarantees,
331	   e.g., both "unsecured" with a lower layer security of a same
332	   strength, both "preinstalled" or both "authenticated" security mode
333	   (see section 3.2.3 of [RFC6550] for more details on those modes).
334	   The latter mode could be use to enforce the segregation of updated
335	   and non-updated nodes, by providing the keys for joining as routers
336	   to the updated nodes only.

[nit] s/could be use/could be used

[major] "The 2 instances MUST be operated with the same security
guarantees..."  Why is that a requirement?  Would something break if
it is not the case?

338	5.4.  Rolling Back

340	   After downgrading a network to turn the [RFC8138] compression off,
341	   the administrator SHOULD make sure that all nodes have converged to
342	   the "T" flag reset before allowing nodes that do not support the
343	   compression in the network (see caveats in Section 5.2).

[minor] "downgrading" sounds as if software needs to changed (at
least)...but in this case it is a configuration change.  Maybe
something like:

   When turning [RFC8138] compression off in the network...

[major] s/SHOULD make sure that all nodes have converged/SHOULD wait
until all nodes have converged

[minor] How does the administrator know when the nodes have converged?
 Given the potential problems, it sounds like a MUST may be more
appropriate...??

[minor] "see caveats in Section 5.2"  The caveats there don't seem to
apply unless the single instance scenario is specified somehow...

...
349	6.  IANA Considerations

351	   This specification updates the Registry for the "DODAG Configuration
352	   Option Flags" that was created for [RFC6550] as follows:

[major] s/This specification updates/IANA is requested to assign a new
option flag from

354	       +------------+---------------------------------+-----------+
355	       | Bit Number | Capability Description          | Reference |
356	       +============+=================================+===========+
357	       | 2          | Turn on RFC8138 Compression (T) | THIS RFC  |
358	       +------------+---------------------------------+-----------+

[major] This value (even though is free in the registry) should be
marked as a suggestion for IANA.

...
362	7.  Security Considerations

364	   First of all, it is worth noting that with [RFC6550], every node in
365	   the LLN that is RPL-aware can inject any RPL-based attack in the
366	   network.  A trust model MUST be put in place so that rogue nodes are
367	   excluded from participating to the RPL and the 6LowpAN signaling, and
368	   from the data packet exchange.  This trust model could be at a
369	   minimum based on a Layer-2 Secure joining and the Link-Layer
370	   security.  This is a generic RPL and 6LoWPAN requirement, see Req5.1
371	   in Appendix of [RFC8505].

[major] Is this paragraph talks about an "generic RPL and 6LoWPAN
requirement", then please don't use Normative language.  Also,
pointing at the appropriate RFCs and their Security Considerations is
enough.

[] As a side note, secure joining doesn't really prevent a rogue node
from being in the network.  Consider the case where the node is
subverted after joining...or simply where the administrator can set
the T flag (as below).

373	   Setting the "T" flag before some routers are upgraded may cause a
374	   loss of packets.  The new bit is protected as the rest of the
375	   configuration so this is just one of the many attacks that can happen
376	   if an attacker manages to inject a corrupted configuration.

[nit] s/before some routers/before all routers

...
392	9.  Normative References
...
414	   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
415	              Constrained-Node Networks", RFC 7228,
416	              DOI 10.17487/RFC7228, May 2014,
417	              <https://www.rfc-editor.org/info/rfc7228>.

[major] This reference should be Informative.

...
427	   [UNAWARE-LEAVES]
428	              Thubert, P. and M. Richardson, "Routing for RPL Leaves",
429	              Work in Progress, Internet-Draft, draft-ietf-roll-unaware-
430	              leaves-14, 11 April 2020, <https://tools.ietf.org/html/
431	              draft-ietf-roll-unaware-leaves-14>.

[minor] This reference can be Informative.

433	10.  Informative References
...
441	   [RFC8138]  Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
442	              "IPv6 over Low-Power Wireless Personal Area Network
443	              (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
444	              April 2017, <https://www.rfc-editor.org/info/rfc8138>.

[major] This reference must be Normative.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 3 Jul 2020 13:16:31 +0000

Hello Alvaro

Many thanks for your review!

Indeed we have this problem with the capabilities draft. On the one hand, the missing flag blocks the use of RFC 8138 in brown field networks and 3rd party standards that would build on RPL, so we want turnon, like yesterday. Note that those are RPLv1.

OTOH, the complete scenario would be with the capabilities, but then the capabilities draft is not stable, so it would push the feature to an undefined future (till RPLv2 in fact). Existing RPLv1 networks will never benefit from the capability draft, you'll need a flag day to make them RPLv2.

So we went for the unpleasant (b) which means that for now we live without the capability and it takes an external management system to know if all nodes are ready; in the future the capability draft will improve the game as a second step for RPLv2 networks. 

Now this is in the open for the group to reconsider; I still stand for (b) though you're completely right that a piece is missing.

Also, I'd like to have a round of Q/A with you before I propose text, so make sure we agree on the direction, if that's OK?

Please see below:

> In short, I believe that the specification in this draft is incomplete.  Specifically:
> 

Both, actually. A deployment is free to use its own OCPs with its own OFs, the whole game being to allow new environments (metrics and logic) that the IETF could not predict. I did not expect OF0 to be generally used, all the contrary I just wanted to provide a strawman on how to specify an OF in another std body; it is very possible for the upgraded node to be configured with OCP =5 with the meaning that it is the same as OCP=4, or a smallish variation of it that favors parents that expose the DODAG that has the new flag set. Now, this is a bit scary and weird, and as you point out, not favored.

Is it enough to indicate the latter (not recommended) or should I also indicate how that's possible with the explanation above?

>     text doesn't even mention configuration as an option.

Maybe we should stick to network management / configuration for this draft? Note that when the parent does not know, it decompresses, so the text should probably say that if the parent knows for sure that the leaf supports the compression then it can leave the packet compressed, else it MUST uncompress. Will that be better

>     [Personal opinion: (a) is the complete solution.]

I placed the discussion at the top of the mail because it is core. I believe we need to support the RPLv1 brown field and that RPL v2 will come with this and other capabilities, later. 

>     needs to be updated (see more specifics below).

Yes there is something there. One thing is that MOP value between 0 to 6 designate RPLv1. 
https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-40#section-4.3 has similar language and the same concern. 

A proposal would be for now to rename the registry to indicate MOP values 0..1 and the specs of RPL v2 will have to create another registry per MOP.

An alternate is a new column and we tried that with RFC 8025 https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml#_6lowpan-parameters-1 . But that has become a nightmare to manage for IANA and now we are talking about splitting.

What's you inclination? Which draft should resquest it?

> 
> I will wait for these points to be addressed before moving the document
> forward.  I also have more comments inline below.
> 
> 
> Thanks!!
> 
> Alvaro.
> 
> 
> [major] rfc6550 talks about the "DODAG Configuration option", and not about
> a "RPL configuration option".  Please be consistent!

Will do

> [nit] Expand/explain subDAG.

Will do

> [nit] Some of the acronyms were already defined in the previous section.
 
Will do

> [minor] s/BCP 14/Requirements Language
 
Will do
 
> implementation has to also support this specification.  IOW, all RPL routers will
> have to support the new flag to be compliant with rfc6550.  Also, rfc8138 did
> not formally Update rfc6550.
> 
> [minor] I think that this section could be reorganized a little: start by telling the
> reader what the Configuration Option is and that it is distributed
> everywhere...this should provide background to understand the availability of
> the T bit in the network.
> 

Will do

> effect of the roots not coordinating?

There are possible side effects like a node that is a router in a "T" off dodag would become a leaf as it jumps to the "T" on, leaving its children potentially orphan. Also trouble if using projected routes that traverse DODAGs. So it seemed simpler to request a coordinated setting in the RPL domain than to go through those cases.

I do not see things that we could not address with enough effort but this "must" is a way to keep things simple. Happy to make it a MUST. Note that this is also a problem to be handled for any configuration item. All the DODAGs must have the same configuration else roaming becomes complex with a situation that depends on the configuration item.

Now you make me wonder what we can really do with the capabilities in the case of multiple roots. Each can only learn the capabilities within its own DODAG. Like I said the capabilities work is not complete.

> [minor] "RPL defines a Configuration Option that is registered to IANA in
> section 20.14. of [RFC6550]."  The Configuration Option (the whole
> thing) is not registered to IANA, the Flags have a registry managed by IANA.

True, will correct that 

> 
> [minor] It would be very nice if the packet format was shown here with the
> new flag.

Yes, I thought of doing that but it is in flux with other drafts also setting bits. A lot easier not to do it but if you insist...

> [major] The last sentence is not needed: the second one already says that the
> flag is only valid for 0-6. 
> 
> Also, I think there's a Normative conflict with "MAY indicate something
> different and MUST NOT be interpreted as...unless the specification of the
> MOP indicates to do so."  Perhaps, if you really want to keep some text, you
> can include something like this:
> 

It may also not use it at all : ) what about 
A document defining a MOP with value 7 or above MUST specify the behavior
of the T flag or keep it reserved

> 
> [major] Regardless of the text, this document is specifying a split in the registry
> (at last for this flag): it applies to some MOPs, but not all.  The registry needs to
> be updated in the IANA Considerations section to show that difference.  Is this
> update being done somewhere else?

We can do it here; useofrplinfo is shipping earlier and has the same concern.

> 
> I thought that draft-ietf-roll-mopex would be a good place, but the update
> doesn't seem to be there.  The intent of not applying to all the MOPs can't be
> finalized until the registry can reflect it.

Happy to indicate in MOPex that the MOPs over 7 create the new IANA registries.
Since the MOPs above 7 do not exist at this time, there does not seem to be a consequence in delaying the IANA update.

> overridden"   s/MUST/SHOULD

Will do both

> [major] "MUST forward...unless...MUST"  That's a strange construct with the
> exception in the middle.
> 
> NEW>

Great!

> [major] "not known"  How would the router know?  §1 mentions capabilities as
> an example), but that is not part of the specification...the MUSTs above make
> it so.
> 

Will add that this is the config / management information as discusses at the beginning of this mail

> [nit] s/generates/generate

Will do

> 
> [minor] "this is known"  This, what?  Assuming that "this" refers to the lack of
> support for rfc8138, we're then to the question of *how* would it be known.
> 

Maybe we can have a small section on that, and refer to it in the few places where the knowledge is useful?

> [major] "the node SHOULD join as a RUL"  To be clear, we're talking about a
> node that doesn't support rfc8138, right?  I'm assuming that if it doesn't
> support rfc8138 then it won't support this specification either -- then we can't
> normatively define anything that this type of node would do!

The RUL draft https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/ is independent of this and if RFC 8138. The RUL operation is arch minimal vs. RPL support. 
It creates the default assumption of no support for RFC 8138 and provides RPL routing with less hassle. If the node cannot do RUL then it should not attempt to join.
Suggestion is to add a reference to remind what the RUL operation i.

> [major] s/[RFC6550] states/[RFC6550] states, when referring to the DODAG
> Configuration option,

Will do

> [minor] s/also suggests that a RAN may only attach/specify that a RAN may

Will do

> [major] "This specification reiterates..."  Saying things again is not a big deal;
> but normatively specifying them is.  In this case it is not only not necessary, but
> also has no effect over nodes that don't support this document...so it is not
> needed.
> 

Ack, will remove

> [?] How slow?  Seconds, minutes?

Depends in the Trickle settings, could be second to days. I can remind that in this text.

> ("Conversely") the statement in the first sentence...or how the mode affects
> the outcome of nodes (including the Root) sending compressed packets when
> others may not still be aware of the flag or able to support receiving the
> packets...

Wrong term, sorry. I guess we can just remove that word? I cannot find the term that would say "the related thing in the opposite situation"

> sounds redundant.  Also, this is the only place in the document where the use
> of rfc8138 is coupled with the SRH-6LoRH.  Not wrong, just redundant and
> inconsistent.  If needed, the sentence can be restructured.

RFC 8138 defines the 6LoRH. The SRH-6LoRH is one of the possible 6LoRH. It is used to transport a source routing header. This happens only in non-storing mode. In general the text talks about any and all 6LoRH. This sentence is the place where we talk about the specific case when one of the 6LoRH added to the frame is an SRH. It probably looks redundant but actually the wording was intended. Should I change since it creates confusion? Suggestion?

> [major] This section talks about inconsistencies, and it is "required that all the
> routers support [RFC8138]", but then not setting the T flag is only
> recommended.  Why/when is it ok to set the flag if it is known that not all
> nodes support rfc8138?  IOW, why not use MUST?

Yes, MUST it must be.

> [major] A new OCP?  I only see 2 OCPs in the registry -- unless I'm missing
> something, there's no way to configure "a new OCP, that may use the same
> OF".
> 

Actually the intent is to use an unregistered OCP. The registry is intended for well-known OCPs but is not seen as limitative. 
We probably should define a range for private / experimental OCPs to avoid this situation?

> [nit] s/This is/This operation is

OK

> 290	   that the leaf supports [RFC8138].

Ack

> Isn't this a contradiction?  [BTW, §1 says that RULs implicitly don't support
> rfc8138.]

Yes, the RUL is not expected to understand RFC 8138, but on paper it could, there is no law that says it must not. 
It would just be VERY surprising to support RPL compression but not RPL. I need to revisit both places.
For the text above, maybe I should remove the "unless it knows that the leaf supports [RFC8138]" because it creates more questions than it actually helps.

> 
> [major] "unless it knows that the leaf supports [RFC8138]"  Assuming you're
> not talking about a RUL, how do you know?  §1 mentions capabilities as an
> example, but that is not part of the specification...the SHOULD above makes it
> so.
> 

Same as several times above, I suggest we do (b) and document knowledge through management.

> [major] What is this "method to let the parent router know..."?

Can add "e.g., through management". The goal of this weird wording is to leave the road open for capabilities when they come. Your suggestions very welcome!

> [minor] Right, but then this implementation wouldn't be compliant with

Correct. Can I remove that sentence?

> [minor] If the parents don't support rfc3183 then they would have joined as
> leaves anyway (because of the new OCP) and wouldn't really be available as
> parents, right?  What am I missing?

Say T is off and those guys are parents. Then we set T on. As you point out they become leaves so they are no more available as parents. This node becomes an orphan though it was not before as a consequence of turning the flag. In the 2 instances method, this node remains attached to the old DODAG and the root can see that it Is not visible on the new instance, so it can figure there's something to do like upgrade or deploy more.

> [major] "Nodes that support [RFC8138]...favor the new RPL Instance for the
> traffic that they source..."   Support for rfc8138 doesn't require
> compression.  IOW, a node that supports rfc8138 can compress, but it doesn't
> have to, right?  I think you need to be more specific when talking about
> "favor"; does it mean that the routers SHOULD use the new instance?

Yes, will reword like that. It MUST join the new instance and SHOULD use it for its traffic to benefit from the compression. It is a SHOULD because the RANK in that more limited DODAG may be bad in which case it is unusable. I can add words that say that too.

> [nit] s/could be use/could be used

Ack

> guarantees..."  Why is that a requirement?  Would something break if it is not
> the case?
> 

Hmu, the new instance should have at least the same guarantees, otherwise we are trading compression gains with security, hard to do.

> [minor] "downgrading" sounds as if software needs to changed (at least)...but
> in this case it is a configuration change.  Maybe something like:
> 

OK, no problem, will change

> 
> [major] s/SHOULD make sure that all nodes have converged/SHOULD wait until
> all nodes have converged
> 

OK

>  Given the potential problems, it sounds like a MUST may be more

Yes, will MUST

> 
> [minor] "see caveats in Section 5.2"  The caveats there don't seem to apply
> unless the single instance scenario is specified somehow...
> 

I can remove the "see caveats". The bottom line is that the legacy nodes will not like a compressed packet so we need to ensure the T off is generalized first.

> [major] s/This specification updates/IANA is requested to assign a new option
> flag from

OK

> 356
> 	       +============+=================================+========
> ===+
> [major] This value (even though is free in the registry) should be marked as a
> suggestion for IANA.

OK will do

> requirement", then please don't use Normative language.  Also, pointing at the
> appropriate RFCs and their Security Considerations is enough.

OK

> 
> [] As a side note, secure joining doesn't really prevent a rogue node from being
> in the network.  Consider the case where the node is subverted after
> joining...or simply where the administrator can set the T flag (as below).
> 

Very true; we are starting zero trust work in IOT, like https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/ and ROV is RPL by transporting the ROVR in DaDAO messages see https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/ . Maybe
 
"so that rogue nodes are excluded from participating to the RPL"
->
"in an effort to exclude rogue nodes from participating to the RPL"

> are
> 367	   excluded from participating to the RPL
> 

Ack, will change

> [major] This reference should be Informative.

I'm getting that recommendation in both ways but OK, will do.

> [minor] This reference can be Informative.
OK

> [major] This reference must be Normative.

OK also : )

So many thanks Alvaro, this was really deep and constructive. Please let me know when the proposals are in the right direction and when not. Based on that I'll publish a revision to track the proposed changes and present it to you.

Take care,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 9 Jul 2020 14:37:56 +0000

Dear Alvaro

This is the second response for the same questions. Considering the depth I had to take it to the WG and thankfully there were quick answers and efficient discussions. 

We decided to stick he *normal* scenario is migrate slowly the nodes with the bit off and when all are migrated turn the bit on. The complex case is that of "forgotten nodes", e.g., nodes for which there was never a new code for this draft and for the compression, to try to serve them still. We decided no to handle that case. They will have to be decommissioned or maintained in a legacy network.

Bottom line is that the simplification removes the text to turn "forgotten nodes" into leaves and any special knowledge of the leave support in this specification. Which removes a number of the pain points that you raised.

I published https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-08 so you can visualize where that takes us and we can move forward based on that.

> I hope you are doing well and staying healthy!
Same on your side 😊

>     simply as an example of something that was considered but not

This was removed with the simplification

>     text doesn't even mention configuration as an option.

This was removed with the simplification

>     [Personal opinion: (a) is the complete solution.]

I removed the discussion on the capabilities work from version 08 of the draft. Capabilities are a RPLv2 feature (MOP>=7) whereas the turnon flag is only defined for RPLv1 (MOP<7). The capability can help to decide when to turn on, and that is earlier in the flow. The draft covers what happens when the decision is made. 

When the capabilities infrastructure is available, if we decide to have a capability for RFC 8138, we could allow a non-capable RAN when the compression is on if we accept to decompress / recompress between routers. This would be a new design for RPLv2. 

But it might also be that we simply MUST the support of RFC 8138 with RPLv2, in which can we will not even need a capability. That’s a decision for the future, we do not need it now. IMHO new RPLv2 code would be better invested doing the compression than the capability exchange to explain that it is not supported.

>     needs to be updated (see more specifics below).

Basically added text in IANA section to make all flags " defined only for MOP value between 0 to 6"

"

6.  IANA Considerations

   IANA is requested to assign a new option flag from the Registry for
   the "DODAG Configuration Option Flags" that was created for [RFC6550]
   as follows:

      +---------------+---------------------------------+-----------+
      | Bit Number    | Capability Description          | Reference |
      +---------------+---------------------------------+-----------+
      | 2 (suggested) | Turn on RFC8138 Compression (T) | THIS RFC  |
      +---------------+---------------------------------+-----------+

                Table 1: New DODAG Configuration Option Flag

   The DODAG Configuration Option Flags defined so far will be obsolete
   for RPL Mode of Operation (MOP) above and including 7.

   IANA is requested to update the name of the Registry from "DODAG
   Configuration Option Flags" to "DODAG Configuration Option Flags for
   RPL MOP 0..6".

   When MOP values of 7 and more are defined, a new registry will be
   needed.

"

> a "RPL configuration option".  Please be consistent!

Fixed

> [nit] Expand/explain subDAG.

Changed to

"
1.  Introduction

   The packet compression technique defined in [RFC8138] can only be
   activated in a RPL [RFC6550] network when all the nodes support it.
   Otherwise, a non-capable node acting as leaf-only would fail to
   communicate, and acting as a router it would drop the compressed
   packets and black-hole a portion of the network.

"

> [nit] Some of the acronyms were already defined in the previous section.

I'd like to keep it this way. The reader will have a single place to look for all acronyms, useful with a paper copy.

.
> [minor] s/BCP 14/Requirements Language

Done

> not formally Update rfc6550.

Removed the formal Update to rfc6550

> the T bit in the network.

Done
"

3.  The RPL DODAG Configuration Option

   The DODAG Configuration Option is defined in Section 6.7.6 of
   [RFC6550].

   The RPL DODAG Configuration Option is typically placed in a DODAG
   Information Object (DIO) message.  The DIO message propagates down
   the DODAG to form and then maintain its structure.  The DODAG
   Configuration Option is copied unmodified from parents to children.

   As shown in Figure 1, the DODAG Configuration Option was designed
   with 4 bit positions reserved for future use as Flags.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Type = 0x04 |Opt Length = 14| Flags |A|       ...           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     +
     |                               ...                             |

            Figure 1: DODAG Configuration Option (Partial View)

"

> effect of the roots not coordinating?

I removed the requirement that the whole instance is updated. The bit applies to the DODAG. Which implicitly means that a node may have to change its habits when jumping to a new DODAG.

> thing) is not registered to IANA, the Flags have a registry managed by IANA.

Changed the reference, see above

> [minor] It would be very nice if the packet format was shown here with the

I added a picture with the location of the flags. The final position can now easily be shown once IANA allocates the bit.

> flag is only valid for 0-6.

Removed

> can include something like this:

I do not really want 😊

>    A document defining a MOP with value 7 or above MUST specify the behavior

This would raise more questions. 
 
> update being done somewhere else?

This or useofrplinfo (this being easier at this stage) should enforce that the bits are not defined beyond 7.

> finalized until the registry can reflect it.

And yes, the MOP draft should reset all the bits to reserved - including the A bit, if we deprecate that mechanism that was never used for all I know. 

I'll take to the list separately.

> [nit] s/A node that supports this specification/A node

Done

> overridden"   s/MUST/SHOULD

Done

"
   A node SHOULD source packets in the compressed form using [RFC8138]
   if and only if the "T" flag is set.  This behaviour can be overridden
   by e.g., configuration or network management.  Overriding may be
   needed e.g., to cope with a legacy implementations of the Root that
   supports [RFC8138] but not this specification and cannot set the "T"
   flag.

"

> [minor] "as indicated above"  Where?

Removed; now we have:
"

  A router that encapsulates a packet is the
   originator of the resulting packet and is responsible to compress the
   outer headers with [RFC8138], but it MUST leave the encapsulated
   packet as is.
"

>    the source used, either compressed or uncompressed.

Used as is, many thanks.

> an example), but that is not part of the specification...the MUSTs above make

All the need to know is gone since we do not address the case of "forgotten nodes"

> [nit] s/generates/generate

That discussion relates also to "forgotten nodes" So it was removed

> support for rfc8138, we're then to the question of *how* would it be known.

That discussion relates also to "forgotten nodes" So it was removed

> normatively define anything that this type of node would do!

I agree that the argument that a RUL supporting the RPL compression looks like an oxymoron.
I changed the text so a RUL is expected to not support the compression and that's it.

"

   An external target [USEofRPLinfo] is not expected to support
   [RFC8138].  In most cases, packets from/to an external target are
   tunneled back and forth between the RPL border router and the Root
   regardless of the MOP used in the RPL DODAG.  The inner packet is
   typically not compressed with [RFC8138] so the 6LR just needs to
   decapsulate the (compressed) outer header and forward the
   (uncompressed) inner packet towards the external target.

...

   A RUL [UNAWARE-LEAVES] is both a leaf and an external target . A RUL
   does not participate in RPL and depends on the parent router to
   obtain connectivity.  In the case of a RUL, forwarding towards an
   external target actually means delivering the packet.

"

> [major] s/[RFC6550] states/[RFC6550] states, when referring to the DODAG

Done, with a taïpo that I'll remove next

> [minor] s/also suggests that a RAN may only attach/specify that a RAN may

All gone

> also has no effect over nodes that don't support this document...so it is not

All gone As well

> [?] How slow?  Seconds, minutes?

That's really the admin setting of DIOs and trickle. Could be hours. What's important is that there will be coexistence and we need to address it.

> others may not still be aware of the flag or able to support receiving the

I forgot to re-fix that one after the major change. The conversely was opposing storing vs. non storing. Any suggestion?

> inconsistent.  If needed, the sentence can be restructured.

Well, that's probably our only discrepancy. The SRH66LoRH (compressed IPv6 RH type 3, really) is specific to the Root and to non-storing. It shows packets could fly with the compression as soon as the root knows the bit is set and way before the nodes are aware of it. The next sentence is 
"
   To ensure that a packet is forwarded across the RPL DODAG in the form
   in which it was generated, it is required that all the RPL nodes
   support [RFC8138] at the time of the switch.

"

 I can reword if that leaves confusion and would appreciate suggestions.

> nodes support rfc8138?  IOW, why not use MUST?

Made it a MUST

> something, there's no way to configure "a new OCP, that may use the same

All gone

> [nit] s/This is/This operation is

All gone

> 290	   that the leaf supports [RFC8138].

No more

> Isn't this a contradiction?  [BTW, §1 says that RULs implicitly don't support

Agreed

> example, but that is not part of the specification...the SHOULD above makes it

All gone

> [major] What is this "method to let the parent router know..."?

All gone

> [minor] Right, but then this implementation wouldn't be compliant with

All gone

> parents, right?  What am I missing?

Right, the point is that at that point the child may become an orphan. But all this is gone now.

> "favor"; does it mean that the routers SHOULD use the new instance?
 
Gone
 
> [nit] s/could be use/could be used

Gone

> guarantees..."  Why is that a requirement?  Would something break if it is not

Also gone

>    When turning [RFC8138] compression off in the network...

OK: This becomes 

"
5.3.  Rolling Back

   When turning [RFC8138] compression off in the network, the Network
   Administrator MUST wait until all nodes have converged to the "T"
   flag reset before allowing nodes that do not support the compression
   in the network. 

"
> [major] s/SHOULD make sure that all nodes have converged/SHOULD wait until

In the above

>  Given the potential problems, it sounds like a MUST may be more

Made a MUST in the above; as for the latter we have:g
"
The idea is to use the flag to maintain the compression inactive
   during the migration phase.  When the migration is complete (e.g., as
   known by network management and/or inventory), the flag is set and
   the compression is globally activated in the whole DODAG.
"
> [major] s/This specification updates/IANA is requested to assign a new option

All done:

"
  IANA is requested to assign a new option flag from the Registry for
   the "DODAG Configuration Option Flags" that was created for [RFC6550]
   as follows:

      +---------------+---------------------------------+-----------+
      | Bit Number    | Capability Description          | Reference |
      +---------------+---------------------------------+-----------+
      | 2 (suggested) | Turn on RFC8138 Compression (T) | THIS RFC  |
      +---------------+---------------------------------+-----------+

"
> appropriate RFCs and their Security Considerations is enough.

Made it:
"

   First of all, it is worth noting that with [RFC6550], every node in
   the LLN that is RPL-aware can inject any RPL-based attack in the
   network.  A trust model has to be put in place in an effort to
   exclude rogue nodes from participating to the RPL and the 6LoWPAN
   signaling, as well as from the data packet exchange.  This trust
   model could be at a minimum based on a Layer-2 Secure joining and the
   Link-Layer security.  This is a generic RPL and 6LoWPAN requirement,
   see Req5.1 in Appendix of [RFC8505].
"

> joining...or simply where the administrator can set the T flag (as below).

Yes, see that reworded in te snippet above

> [nit] s/before some routers/before all routers

Done

> [major] This reference should be Informative.
Done

> [minor] This reference can be Informative.

This and useofrplinfo then?
Done.

> [major] This reference must be Normative.

Done.

This was quite major, Alvaro, a great many thanks for it all.

Though most of the text that is there was already there, there's a reorg that had to take place with the removal of the support of "forgotten nodes". The result is certainly easier to digest.

Please let us know if we missed something?

Take care,

Pascal

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 20 Jul 2020 15:10:19 -0400

On July 9, 2020 at 10:38:29 AM, Pascal Thubert wrote:

Pascal:

Hi!

...
> We decided to stick he *normal* scenario is migrate slowly the nodes with
> the bit off and when all are migrated turn the bit on. The complex case is
> that of "forgotten nodes", e.g., nodes for which there was never a new code
> for this draft and for the compression, to try to serve them still. We
> decided no to handle that case. They will have to be decommissioned or
> maintained in a legacy network.
>
> Bottom line is that the simplification removes the text to turn "forgotten
> nodes" into leaves and any special knowledge of the leave support in this
> specification. Which removes a number of the pain points that you raised.

I think that the simplification is a good thing! :-)

...
> MOP value between 0 to 6"

I've been thinking about this some more, and I think we're getting
into putting-the-cart-before-the-horse [1] territory.

[1] https://en.wikipedia.org/wiki/Cart_before_the_horse

There's no special meaning assigned to MOP = 7, yet.  This document
talks about it because you (the WG, etc.) already know about the
future intent.  But that has not been specified anywhere, and there
are no other specifics about that change here...nor should there be.

IOW, I'm thinking that instead of changing the registry in this
document, we should leave it as is and make no statement as to which
MOPs the new flag applies to.  That explanation will come later when
the RPLv2 work is done -- we can go into the details at that time.

This should simplify more.  Thoughts?

...
...

The Abstract still says that the document Updates rfc6550:

Suggestion>
   This document updates RFC 8138 by defining a bit in the RPL DODAG
   Configuration Option to indicate whether compression is used within the
   RPL Instance, and specify the behavior of when the bit is set and reset.

...
...

The text in this section says that "The new "T" flag is encoded in one
of the reserved bits in the RPL DODAG Configuration Option."

[] s/"T" flag is encoded in one of the reserved bits/"T" flag is
encoded in the Flags field

...
...
> > packets when others may not still be aware of the flag or able to support
> > receiving the packets...
>
> I forgot to re-fix that one after the major change. The conversely was
> opposing storing vs. non storing. Any suggestion?

Just start with "In storing mode...", and take "conversely" out. ;-)

> > sounds redundant. Also, this is the only place in the document where the
> > use of rfc8138 is coupled with the SRH-6LoRH. Not wrong, just redundant and
> Well, that's probably our only discrepancy. The SRH66LoRH (compressed IPv6
> RH type 3, really) is specific to the Root and to non-storing. It shows
> packets could fly with the compression as soon as the root knows the bit is
> set and way before the nodes are aware of it. The next sentence is
> "

Let's leave is at is.

...
> 5.3. Rolling Back

[major] The last sentence in the last paragraph changed from "used as
a leaf" to "used as a RUL"...the "MUST" makes the reference for RUL
Normative.  If you don't want UNAWARE-LEAVES to be Normative, then
change it back.

I'll wait for one more update before starting the IETF Last Call.

Thanks!

Alvaro.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 20 Jul 2020 21:30:59 +0000

Hello Alvaro 

I’ll respond at length tomorrow.
Still I wanted to start on one item tonight.
I agree about the wheels and cart thing. We do not want that and thought we avoided it.

We do not know what mop>7 will be. We do not say that this flag will not be valid. We say that we do not know if it is valid either. So what we want is an implementation of today should process the bit only if the mop is less than 7.  We want code now to protect the future so the flag can reused.

As it goes that implementation will not know the mop either so it can only be a leaf. So a legacy node will only just itself if is misbehaves. 

What would help is if we specify that all mop>7 support the compression. But that was not really agreed so far though it’s in the air...

Take care,
Pascal

> Le 20 juil. 2020 à 21:10, Alvaro Retana <[email-masked]> a écrit :
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Jul 2020 19:58:58 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > We do not know what mop>7 will be. We do not say that this flag will
    > not be valid. We say that we do not know if it is valid either. So what
    > we want is an implementation of today should process the bit only if
    > the mop is less than 7.  We want code now to protect the future so the
    > flag can reused.

What Pascal said.
We talked about this in both Montreal and Singapore, I think.
(I think that the WG would otherwise be very hesistant to let these flags go)

At the same time, while I think that we are rapidly approaching the need for
an "RPLv2", I think we need a fair bit more energy to get it done.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 21 Jul 2020 09:53:40 +0000

Hello Alvaro

Many thanks (again) for your review!

> > Bottom line is that the simplification removes the text to turn
> > "forgotten nodes" into leaves and any special knowledge of the leave
> > support in this specification. Which removes a number of the pain points that
> you raised.
> 

Adopted then

> > > The current registry is not set up for this type of assignment, so
> > > it needs to be updated (see more specifics below).
> >
> I've been thinking about this some more, and I think we're getting into putting-
> the-cart-before-the-horse [1] territory.
> 
> There's no special meaning assigned to MOP = 7, yet.  This document talks
> about it because you (the WG, etc.) already know about the future intent.  But
> that has not been specified anywhere, and there are no other specifics about
> that change here...nor should there be.
> 
> IOW, I'm thinking that instead of changing the registry in this document, we
> should leave it as is and make no statement as to which MOPs the new flag
> applies to.  That explanation will come later when the RPLv2 work is done -- we
> can go into the details at that time.

Agreed for the registry part. 
All we want is to say that the code should check for MOP<7 before it uses the flag.
To prepare for this the current draft onlyt changes the name of the registry as below.

"
6.  IANA Considerations

Should I remove the text after the table or is it OK?

> This should simplify more.  Thoughts?

Please keep in mind that we want the core written today to disregard the flag (I guess that means use a default that is TBD) for MOP >= 7. Said this way, we still need text, and we need to define the default. I suspect it should be "ON" but I need to check with the ML.

>    RPL Instance, and specify the behavior of when the bit is set and reset.

Did you mean
"
     This document updates RFC 8138 by defining a bit in the RPL DODAG
     Configuration Option to indicate whether compression is used within the
     RPL Instance, and specify the behavior of RFC 8138-capable nodes
     when the bit is set and reset.

"

?

> The text in this section says that "The new "T" flag is encoded in one of the
> reserved bits in the RPL DODAG Configuration Option."
> 
> [] s/"T" flag is encoded in one of the reserved bits/"T" flag is encoded in the
> Flags field
> 

Done

Done

> > > redundant and inconsistent. If needed, the sentence can be restructured.
> >
> > Well, that's probably our only discrepancy. The SRH66LoRH (compressed
> > IPv6 RH type 3, really) is specific to the Root and to non-storing. It
> > shows packets could fly with the compression as soon as the root knows
> > the bit is set and way before the nodes are aware of it. The next
> > sentence is "

Cool

> ...
> > 5.3. Rolling Back
> 
> [major] The last sentence in the last paragraph changed from "used as a leaf"
> to "used as a RUL"...the "MUST" makes the reference for RUL Normative.  If
> you don't want UNAWARE-LEAVES to be Normative, then change it back.

A leaf is not enough in storing mode, because the service 6LR cannot know if the next hop is the final destination. So TRUL it has to be. Note that in non-storing mode it would know because the RH3 is consumed.

I made the RUL draft reference normative then. They should progress together anyway.

> I'll wait for one more update before starting the IETF Last Call.

Thank YOU, Alvaro!

For the IANA section, I see that Michael also clarified why we want this code to limit the bit to lower MOPs. Please give us your thoughts.

I'll need to poll the list on the default beyond MOP 7, will do that separately to attract attention.

Take care,

Pascal

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 21 Jul 2020 11:03:39 -0400

On July 21, 2020 at 5:53:53 AM, Pascal Thubert wrote:

Pascal:

Hi!

...
> To prepare for this the current draft onlyt changes the name of the

Changing the name of the registry will result in having to Update the
other documents that have option flags because they don't include a
limitation.  It would also probably require an additional registry for
MOP >= 7...just for completeness.  By the time we're done with that
justification we're already half way to RLPv2 -- in this document!

Let's leave the registry unchanged.

> the "DODAG Configuration Option Flags" that was created for [RFC6550]

Yes, please.

> Please keep in mind that we want the core written today to disregard the
> flag (I guess that means use a default that is TBD) for MOP >= 7. Said this
> way, we still need text, and we need to define the default. I suspect it
> should be "ON" but I need to check with the ML.

This default won't be in this document, right?

...
> when the bit is set and reset.

Sure.

Thanks!

Alvaro.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 21 Jul 2020 15:24:20 +0000

Hello Alvaro

> -----Original Message-----
> Changing the name of the registry will result in having to Update the other
> documents that have option flags because they don't include a limitation.  It
> would also probably require an additional registry for MOP >= 7...just for
> completeness.  By the time we're done with that justification we're already half
> way to RLPv2 -- in this document!
> 

OK

OK

> > Please keep in mind that we want the core written today to disregard
> > the flag (I guess that means use a default that is TBD) for MOP >= 7.
> > Said this way, we still need text, and we need to define the default.
> > I suspect it should be "ON" but I need to check with the ML.
> 

It needs to be. The problem is that people will write the code now. We ask them to do

If mop < 7
   If  "T"  use compression
   Else do not use compression
Else
   Oups, what should I do here?

We need to provide them with the else specification.
I launched a thread and so far we confirmed that the code should be like:

If mop < 7
    If  "T"  use compression
    Else do not use compression
Else
    use compression

Is there an issue with this?

> > > Configuration Option to indicate whether compression is used within
> > > the RPL Instance, and specify the behavior of when the bit is set and reset.
> > >
> > >
> >
> > Did you mean
> > "
> > Configuration Option to indicate whether compression is used within
> > the RPL Instance, and specify the behavior of RFC 8138-capable nodes

Cool

Take care,

Pascal

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 21 Jul 2020 12:07:30 -0400

On July 21, 2020 at 11:24:53 AM, Pascal Thubert wrote:

...
> Is there an issue with this?

§3:

   Section 6.3.1.  of [RFC6550] defines a 3-bit Mode of Operation (MOP)
   in the DIO Base Object.  The new "T" flag is defined only for MOP
   value between 0 to 6.

The piece that is really giving me a hard time is that the "flag is
defined only for MOP...".  Given the logic above, in reality the flag
is defined for all the MOPs, they just behave differently.

Suggestion>

   Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP)
   in the DIO Base Object.  For MOP values 0 to 6, the use of compression is
   as specified in this document.  A MOP value of 7 MUST use compression by
   default and ignore the setting of the “T” flag.

??

Alvaro.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 21 Jul 2020 16:25:22 +0000

Works for me, Alvaro. 

Please note that we must do the same change in useofrplinfo for the 0x23 enable flag.
The result is visible in github at https://github.com/roll-wg/roll-turnon-rfc8138 
I cannot publish during the cutoff but I'll do it first thing next week?

Please let me know if there's anything else.

May, many thanks Alvaro!

Pascal

> From: Alvaro Retana <[email-masked]>
> Sent: mardi 21 juillet 2020 18:08
> To: Pascal Thubert (pthubert) <[email-masked]>; draft-ietf-roll-turnon-
> [email-masked]
> Cc: [email-masked]; Routing Over Low power and Lossy networks
> <[email-masked]>
> Subject: RE: AD Review of draft-ietf-roll-turnon-rfc8138-07
> 
> > > > Please keep in mind that we want the core written today to
> > > > disregard the flag (I guess that means use a default that is TBD) for MOP
> >= 7.
> The piece that is really giving me a hard time is that the "flag is defined only for
> MOP...".  Given the logic above, in reality the flag is defined for all the MOPs,
> they just behave differently.
> 
> 
> Suggestion>
>

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 21 Jul 2020 13:48:45 -0400

> Please note that we must do the same change in useofrplinfo for the 0x23

Yup.

> I cannot publish during the cutoff but I'll do it first thing next week?

ok

> Please let me know if there's anything else.

I think we're done. :-)

Thanks!!

Alvaro.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 27 Jul 2020 14:31:00 +0000

Published 😊

> Sent: mardi 21 juillet 2020 19:49
> > The result is visible in github at
> > https://github.com/roll-wg/roll-turnon-
> > rfc8138