Re: [C310] * AD - Alvaro Retana, John Scudder, or Martin Vigoureux Re: AUTH48 [LB]: RFC 9035 <draft-ietf-roll-turnon-rfc8138-18.txt> NOW AVAILABLE

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

Hello Lynne

I checked the diffs and found that a sentence that was to be replaced is still there

´A router MUST uncompress a packet that is to be forwarded to an external target. Otherwise, the router MUST forward the packet in the form that the source used, either compressed or uncompressed.

´

That text is replaced by
´

A border router that forwards a packet to an external target MUST uncompress the packet first. In all other cases, a router MUST forward a packet in the form that the source used, either compressed or uncompressed

´

Regards,

Pascal

Le 21 avr. 2021 à 22:10, Pascal Thubert (pthubert) via c310 <[e-mail]> a écrit :

Hello Lynne


Dear Pascal and *AD (Alvaro, John, or Martin),

* Alvaro, John, or Martin, although the following update appears to be purely editorial, we must err on the side of caution and ask for your approval, because it changes "MUST ..." to "MUST NOT ..."  Please let us know if this is OK:

There are operations in the inner packet that must be done. Like increasing hop count or changing the 6LoWPAN HC if the source address is compressed based on a MAC address.
The text below meant no RFC 8138 compression on the inner packet, but was not meant to leave the inner packet untouched wrt those operations. So it's better to rephrase a bit
OLD
" A router encapsulating a packet is the originator
of the resulting packet and is responsible for compressing the outer
headers per [RFC8138], but it MUST leave the encapsulated packet as
is.
"
NEW
"
A router encapsulating a packet is the originator
of the resulting packet and is responsible for compressing the outer
headers per [RFC8138], but it MUST NOT perform the compression on
the encapsulated packet.
"

= = = = =

Pascal, thank you for your prompt replies!

We have updated this document per your notes below.

Regarding this item and your reply:

6) <!-- [rfced] Section 3 and Figure 1:  The "<- Flags ->" portion of
Figure 1 appears to encompass five bit positions (0, 1, 2, 3, and 4,
where 'T' is the third position and 'A' is the fifth) instead of four.
So, should "four bit positions" be changed to "five bit positions"?

Also, please compare with Figure 5 in RFC 9010 (which shows "4 bits"),
and let us know if any changes are needed in this document.

Original (best viewed with a fixed-point font such as Courier):
As shown in Figure 1, the Option was originally 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| | |T| |A|       ...           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     +
                                <- Flags ->

       Figure 1: DODAG Configuration Option (Partial View)
-->


RFC 9010 refers to positions that were reserved for future use in RFC
6550.
"A" is also a flag but it was defined in RFC 6550. So it is all
consistent.
But since the text in  RFC 9035 echoes that in RFC 9010, I agree it's
better to align figure 1 to the one in RFC 9010.

We simply removed the "As shown in Figure 1," phrase.  Please let us know if we misunderstood your note and further updates are needed.


This is fine with me


= = = = =

Regarding this item and your reply:

7) <!-- [rfced] This document and the IANA registry
(https://www.iana.org/assignments/rpl/rpl.xhtml#dodag-config-option-fl
ags) don't match for this description. Which one should be used?

This document:
Enable RFC8138 Compression (T)

IANA registry:
Turn on RFC8138 Compression (T)


The best is probably to align to RFC 9008 which uses "enable"


Also, may this description be rephrased to avoid using the RFC number
as an adjective?  If so, we will send a request to IANA to update the
registry accordingly.

Perhaps:
Turn on Compression per RFC 8138 (T)

Or:
Turn on 6LoRH Compression (T)
-->

I like "perhaps" better. There could be other compression, we want to be
specific to RFC 8138.

Apologies, but we are not sure how best to update this document or ask IANA to update their corresponding entry.  We see "RPI 0x23 enable" in RFC 9008.

Would the following capture your intended meaning?

In this document and on <https://www.iana.org/assignments/rpl/rpl.xhtml#dodag-config-option-flags>:
 Enable Compression per RFC 8138 (T)

Yes, perfectly!


= = = = =

Regarding this note from you in reply to our question 8) (quoting of flag names):

Interestingly we do not seem to have attributed a letter to the flag
defined by RFC 9008.
Also I noted that the text " Table 36: DODAG Configuration Option Flag to
Indicate the RPI Flag Day" in RFC 9008 is incorrect. It does *not*
indicate a "flag day" but controls the RPI option type value (of 0x63 vs.
0x23). I guess we need an erratum?

If something in RFC 9008 is incorrect and should be addressed, then yes, an erratum should be filed.

Will do; this is cosmetic so no worries

= = = = =

Regarding this note from you in reply to our question 11):

I guess this is the same exactly as RFC 9010 which was added. The reason
is that we mandate an operation in MOP 7.
That is the agreement with the A-Ds. And yes the sentence is accurate. So
all is good and IANA needs to add the reference to RFC 9035 in
https://www.iana.org/assignments/rpl/rpl.xhtml#mop

Thank you for the explanation.  We have flagged this and will ask IANA to make this update shortly before publication.


Cool

= = = = =

The updated files are posted here.  Please review carefully, and let us know if we missed anything.

 https://www.rfc-editor.org/authors/rfc9035.txt
 https://www.rfc-editor.org/authors/rfc9035.pdf
 https://www.rfc-editor.org/authors/rfc9035.html
 https://www.rfc-editor.org/authors/rfc9035.xml
 https://www.rfc-editor.org/authors/rfc9035-diff.html
 https://www.rfc-editor.org/authors/rfc9035-auth48diff.html

 https://www.rfc-editor.org/authors/rfc9035-alt-diff.html
 https://www.rfc-editor.org/authors/rfc9035-xmldiff1.html
 https://www.rfc-editor.org/authors/rfc9035-xmldiff2.html
 https://www.rfc-editor.org/authors/rfc9035-alt-diff.html

Although several items (above) are pending, we have noted your approval on the AUTH48 status page:

 https://www.rfc-editor.org/auth48/rfc9035

Thanks again!

RFC Editor/lb


All good, Lynne, many many thanks !

Keep safe ;

Pascal


On Apr 20, 2021, at 8:59 AM, Pascal Thubert (pthubert) <[e-mail]> wrote:

Dear RFC editor

Pleas find my additional editorial changes; I approve the publication of RFC 9035 once they are applied.


There are operations in the inner packet that must be done. Like increasing hop count or changing the 6LoWPAN HC if the source address is compressed based on a MAC address.
The text below meant no RFC 8138 compression on the inner packet, but was not meant to leave the inner packet untouched wrt those operations. So it's better to rephrase a bit
OLD
" A router encapsulating a packet is the originator
of the resulting packet and is responsible for compressing the outer
headers per [RFC8138], but it MUST leave the encapsulated packet as
is.
"
NEW
"
A router encapsulating a packet is the originator
of the resulting packet and is responsible for compressing the outer
headers per [RFC8138], but it MUST NOT perform the compression on
the encapsulated packet.
"



It is not clear below if forwarding is to a next hop or hops away.
Let us clarify that the border router is the one that uncompresses:
OLD
"
A router MUST uncompress a packet that is to be forwarded to an
external target.  Otherwise, the router MUST forward the packet in
the form that the source used, either compressed or uncompressed.
"

NEW
"
A border router that forwards a packet to an external target MUST
uncompress the packet first. In all other cases, a router MUST
forward a packet in the form that the source used, either compressed
or uncompressed.
"


Keep safe;

Pascal



From: "Pascal Thubert (pthubert)" <[e-mail]>
Subject: RE: AUTH48 [LB]: RFC 9035 <draft-ietf-roll-turnon-rfc8138-18.txt> NOW AVAILABLE
Date: April 20, 2021 at 8:38:01 AM PDT
To: "[e-mail]" <[e-mail]>, "Li Zhao (liz3)" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>

Hello again:

A side note that RFC 6550 uses the term " sub-DODAG ". I think we should stick to it, that is change subdag to sub-DODAG throughout.

Keep safe;

Pascal



-----Original Message-----
From: Pascal Thubert (pthubert)
Sent: mardi 20 avril 2021 14:50
To: [e-mail]; Li Zhao (liz3) <[e-mail]>
Cc: [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: RE: AUTH48 [LB]: RFC 9035 <draft-ietf-roll-turnon-rfc8138-18.txt>
NOW AVAILABLE

Dear RFC Editor

Many thanks for your hard work on this draft!
Li and I exchanged; please find an aggregate of our comments

Let's see below


1) <!-- [rfced] Document title: Should the abbreviated title (which
appears in the PDF in the running header) be updated as follows to
more closely match what's discussed in the text?

Original:
Turn On 6LoRH

Perhaps:
Turn On 6LoRH Compression

Good



Also, we expanded the abbreviations in the full document title.
Please let us know if you prefer the "Perhaps" option below, or
otherwise.

Original:
A RPL DODAG Configuration Option for the 6LoWPAN Routing Header

Currently (full title):
    A Routing Protocol for Low-Power and Lossy Networks (RPL)
Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option
for the IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
                          Routing Header

Perhaps (if "6LoWPAN" is not expanded):
    A Routing Protocol for Low-Power and Lossy Networks (RPL)
Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option
                for the 6LoWPAN Routing Header
-->

"Perhaps" feels a lot better!


2) <!-- [rfced] Please insert any keywords (beyond those that appear
in the
title) for use on https://www.rfc-editor.org/search -->

IoT, Header Compression, Source Routing Header, Hop-by-Hop Header, RPL
artifacts


3) <!-- [rfced] FYI, instances of "[RFC8138] compression"
have been rephrased as "compression per [RFC8138]" or "6LoRH
compression [RFC8138]" for the sake of clarity.
Please let us know if you prefer otherwise.
-->

I'm good with the change


4) <!-- [rfced] Section 2.1:  Because "References" is generally used
to indicate Normative and Informative References sections in RFCs, we
changed this title to "Related Documents" per RFC 8505 and as was done
in RFC 9010.  Please let us know any objections.

Original:
2.1.  References

Currently:
2.1.  Related Documents -->


Cool


5) <!-- [rfced] Section 2.2:  We had trouble following the use of
"which"
in this definition.  We updated as noted below.  If this is incorrect,
please clarify the text.

Original:
SubDAG:  A DODAG rooted at a node which is a child of that node and a
 subset of a larger DAG

Currently:
SubDAG:  A DODAG rooted at a node, which is a child of that node and
 a subset of a larger DAG -->

RFC 6550 says:
“The sub-DODAG of a node is the set of other nodes whose paths to the
DODAG root pass through that node.  Nodes in the sub-DODAG of a node have
a greater Rank than that node.”

Merging this, I'd rather we use:
"
The sub-DAG of a node is a DODAG rooted at that node that is a subset of a
main DODAG the node belongs to. It is formed by the other nodes in the
main DODAG whose paths to the main DODAG root pass through that node.

"


6) <!-- [rfced] Section 3 and Figure 1:  The "<- Flags ->" portion of
Figure 1 appears to encompass five bit positions (0, 1, 2, 3, and 4,
where 'T' is the third position and 'A' is the fifth) instead of four.
So, should "four bit positions" be changed to "five bit positions"?

Also, please compare with Figure 5 in RFC 9010 (which shows "4 bits"),
and let us know if any changes are needed in this document.

Original (best viewed with a fixed-point font such as Courier):
As shown in Figure 1, the Option was originally 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| | |T| |A|       ...           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     +
                                <- Flags ->

       Figure 1: DODAG Configuration Option (Partial View)
-->


RFC 9010 refers to positions that were reserved for future use in RFC
6550.
"A" is also a flag but it was defined in RFC 6550. So it is all
consistent.
But since the text in  RFC 9035 echoes that in RFC 9010, I agree it's
better to align figure 1 to the one in RFC 9010.




7) <!-- [rfced] This document and the IANA registry
(https://www.iana.org/assignments/rpl/rpl.xhtml#dodag-config-option-fl
ags) don't match for this description. Which one should be used?

This document:
Enable RFC8138 Compression (T)

IANA registry:
Turn on RFC8138 Compression (T)


The best is probably to align to RFC 9008 which uses "enable"


Also, may this description be rephrased to avoid using the RFC number
as an adjective?  If so, we will send a request to IANA to update the
registry accordingly.

Perhaps:
Turn on Compression per RFC 8138 (T)

Or:
Turn on 6LoRH Compression (T)
-->

I like "perhaps" better. There could be other compression, we want to be
specific to RFC 8138.



8) <!-- [rfced] FYI, we have changed from "T" flag (double quotes) to
'T'
flag (single quotes) in keeping with usage in Section 6.2 of RFC 9010.
Please let us know if you prefer otherwise.
-->

You did good. I gave a look at 9008 and 9010 to compare how we did things
there.

Interestingly we do not seem to have attributed a letter to the flag
defined by RFC 9008.
Also I noted that the text " Table 36: DODAG Configuration Option Flag to
Indicate the RPI Flag Day" in RFC 9008 is incorrect. It does *not*
indicate a "flag day" but controls the RPI option type value (of 0x63 vs.
0x23). I guess we need an erratum?


9) <!-- [rfced] Section 3:  Because Section 4.3 of RFC 9008 is
"Updates to RFC 8138: Indicating the Way to Decompress with the New
RPI Option Type", whereas Section 4.1 of is "Updates to RFC 6550", we
changed "4.3" to "4.1" accordingly.  Please let us know if this is not
accurate.

Original:
Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that the
definition of the Flags applies to Mode of Operation (MOP) values
zero
(0) to six (6) only.

Currently:
Section 4.1 of [RFC9008] updates [RFC6550] to indicate that the
definition of the Flags applies to Mode of Operation (MOP) values
zero
(0) to six (6) only. -->


You are correct. That's really " Section 4.1.2 of [RFC9008] updates..."


10) <!-- [rfced] Section 5.3:  We had trouble following the first
sentence in this paragraph, and the second sentence does not parse.
If the suggested text is not correct, please clarify "converged to the
'T' flag unset" and "SHOULD be exposed the node's management
interface".

Original:
When turning [RFC8138] compression off in the network, the Network
Administrator MUST wait until all nodes have converged to the "T"
flag unset before allowing nodes that do not support the compression
in the network.  To that effect, whether the compression is active in
a node SHOULD be exposed the node's management interface.

Perhaps:
When turning 6LoRH compression [RFC8138] off in the network, the
network administrator MUST wait until all nodes have converged to the
point  where their 'T' flags are unset before allowing nodes that do
not  support compression in the network.  Information regarding
whether  compression is active in a node SHOULD be visible to the node's
management interface.

Or:
When turning 6LoRH compression [RFC8138] off in the network, the
network administrator MUST wait until each node has its 'T' flag unset
before allowing nodes that do not support compression in the network.
Information regarding whether compression is active in a node SHOULD
be exposed in the node's management interface.
-->

Please use "Or" that does the trick nicely



11) <!-- [rfced] This sentence appears in the original:
IANA is requested to add [this document] as a reference for MOP 7 in
the RPL Mode of Operation registry.

However, the IANA registry
(https://www.iana.org/assignments/rpl/rpl.xhtml#mop)
doesn't include this document as a reference for value 7:

7   Reserved   [RFC9008][RFC9010]

So, should the sentence be removed, or should the registry be updated?
(See also Section 11.3 of RFC 9008, and Section 12.3 of RFC 9010.)

Also, please review whether this sentence in Section 3 is accurate.
"For a MOP value of 7, [RFC8138] MUST be
used on links where 6LoWPAN Header Compression [RFC6282] applies and
MUST NOT be used otherwise."
-->

I guess this is the same exactly as RFC 9010 which was added. The reason
is that we mandate an operation in MOP 7.
That is the agreement with the A-Ds. And yes the sentence is accurate. So
all is good and IANA needs to add the reference to RFC 9035 in
https://www.iana.org/assignments/rpl/rpl.xhtml#mop


12) <!-- [rfced] Section 7:  We had trouble following this sentence;
are some words missing?  Please clarify "is protected as the rest of
the configuration".

Original (the previous sentence is included for context):
Setting the 'T' flag before all routers are upgraded may cause a loss
of packets.  The new bit is protected as the rest of the
configuration so this is just one of the many attacks that can happen
if an attacker manages to inject a corrupted configuration. -->

OLD
The new bit is protected as the rest of the  configuration so this is just
one of the many attacks that can happen  if an attacker manages to inject
a corrupted configuration

NEW
The new bit benefits from the same protection as the rest of the
information in the DODAG Configuration Option that transports it. Touching
the new bit is just one of the many attacks that can happen  if an
attacker manages to inject a corrupted configuration option in the
network.





13) <!-- [rfced] Section 7:  We had trouble following this paragraph.
If the suggested text is not correct, please clarify "would compress
when that it is not desired" and "both settings, which could raise
attention".

Original:
An attacker may unset the 'T' flag to force additional energy
consumption of child or descendant nodes in its subDAG.  Conversely
it may set the 'T' flag, so that nodes located downstream would
compress when that it is not desired, potentially resulting in the
loss of packets.  In a tree structure, the attacker would be in
position to drop the packets from and to the attacked nodes.  So the
attacks above would be more complex and more visible than simply
dropping selected packets.
The downstream node may have other  parents and see both settings,
which could raise attention.

Suggested:
An attacker may unset the 'T' flag to force additional energy
consumption of child or descendant nodes in its subDAG.  Conversely,
it may set the 'T' flag so that nodes located downstream would
compress packets even when compression is not desired, potentially
causing packet loss.  In a tree structure, the attacker would be in  a
position to drop the packets from and to the attacked nodes.  So,  the
attacks mentioned above would be more complex and more visible  than
simply dropping selected packets.  The downstream node may have  other
parents and see both settings; such a scenario could raise  concerns.
-->


I'm good with "suggested". For the last sentence OLD "
The downstream node may have  other parents and see both settings; such a
scenario could raise  concerns "
I'd rather have
NEW
"
The downstream node may have  other parents and see the bit with both
settings; such an situation may be detected and an alert may be triggered
"

Please let us know when the document is updated and I'll perform a full
review.

Take care,

Pascal

--
c310 mailing list
[e-mail]
https://www.rfc-editor.org/mailman/listinfo/c310