[C310] [IANA] Re: Re: AUTH48 [LB]: RFC 9035 <draft-ietf-roll-turnon-rfc8138-18.txt> NOW AVAILABLE

[Lynne Bartholomew <[e-mail]>]

Dear IANA,

We are preparing this document for publication.

Please make the following updates on <https://www.iana.org/assignments/rpl/>:

"Mode of Operation" registry:
OLD:  
7 Reserved [RFC9008][RFC9010]  
 
NEW:  
7 Reserved [RFC9008][RFC9010][RFC-ietf-roll-turnon-rfc8138-18]

= = = = =

"DODAG Configuration Option Flags for MOP 0..6" registry:
OLD:
Turn on RFC8138 Compression (T)  
 
NEW *:  
Enable Compression per RFC 8138 (T)

* Please use this wording instead of the wording that appears in author feedback below; this "NEW" text is what matches the document (https://www.rfc-editor.org/authors/rfc9035.txt)


Thank you!

RFC Editor/lb


> On Apr 22, 2021, at 1:24 PM, Lynne Bartholomew <[e-mail]> wrote:
> 
> Hi, Pascal and Li.  Pascal, thank you for the quick clarifications!
> 
> Li, per the first of your two emails dated today, we have noted your approval on the AUTH48 status page:
> 
>   https://www.rfc-editor.org/auth48/rfc9035
> 
> As we now have approvals from both of you, we will prepare this document for publication shortly.
> 
> Thanks again for your help and patience!
> 
> RFC Editor/lb
> 
> 
>> On Apr 22, 2021, at 1:08 PM, Pascal Thubert (pthubert) <[e-mail]> wrote:
>> 
>> Hello Lynne 
>> 
>> 
>> 
>>> Le 22 avr. 2021 à 21:50, Lynne Bartholomew <[e-mail]> a écrit :
>>> 
>>> Hi, Pascal and Li.
>>> 
>>> We made a couple updates in Section 3 per your notes below.  Please clarify the following items:
>>> 
>>> 1.  "to form and then maintains" does not parse.  Does this mean "to form its structure and then maintain it" or something else?
>>> 
>> 
>> I think the idea was “to form and then to maintain”. I believe the text is good as is. Your proposal works too, whichever sounds better to your hear is good for us. Please remember that we are non native speakers and certainly we trust you to know better.
>> 
>> 
>>> 2.  "Align figure 1 to the one in RFC 9010.:" and "For the bits,  it’s fine if we remove the reference.":  Apologies, but we do not know what these mean.  Please provide specific "OLD" and "NEW" text.
>>> 
>> 
>> Again I believe that we’re good as is now. Li meant that the changes you already made clear that issue.
>> 
>>> The latest files are posted here:
>>> 
>> 
>> We’re ok to publish as is. 
>> 
>> Take care,
>> 
>> Pascal 
>> 
>> 
>>> 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-lastdiff.html
>>> https://www.rfc-editor.org/authors/rfc9035-lastrfcdiff.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
>>> 
>>> Thank you!
>>> 
>>> RFC Editor/lb
>>> 
>>> 
>>>> On Apr 22, 2021, at 4:26 AM, Pascal Thubert (pthubert) <[e-mail]> wrote:
>>>> 
>>>> Nice! We are in sync then.
>>>> 
>>>> Take care,
>>>> 
>>>> Pascal
>>>> 
>>>> From: Li Zhao (liz3) <[e-mail]> 
>>>> Sent: jeudi 22 avril 2021 12:13
>>>> To: Pascal Thubert (pthubert) <[e-mail]>; Lynne Bartholomew <[e-mail]>
>>>> Cc: [e-mail]; RFC System <[e-mail]>; [e-mail]; [e-mail]
>>>> Subject: Re: [C310] Re: AUTH48 [LB]: RFC 9035 <draft-ietf-roll-turnon-rfc8138-18.txt> NOW AVAILABLE
>>>> 
>>>> Hello Pascal,
>>>> 
>>>> My first proposal is changing Flags to flags in section 3 in order to align with 9010.
>>>> 
>>>> The DODAG Configuration option was originally designed with four bit positions reserved for future use as Flags.
>>>> -> The DODAG Configuration option was originally designed with four bit positions reserved for future use as flags.
>>>> 
>>>> The 'T' flag is encoded in position 2 of the reserved Flags
>>>> -> The 'T' flag is encoded in position 2 of the reserved flags
>>>> 
>>>> Section 4.1.2 of [RFC9008] updates [RFC6550] to indicate that the definition of the Flags
>>>> -> Section 4.1.2 of [RFC9008] updates [RFC6550] to indicate that the definition of the flags
>>>> 
>>>> This specification defines a new flag, "Enable RFC8138 Compression" (T).
>>>> -> This specification defines a new flag, "Enable RFC8138 Compression (T)”.
>>>> 
>>>> For the bits,  it’s fine if we remove the reference.
>>>> 
>>>> 
>>>> Best regards,
>>>> Li
>>>> 
>>>> From: Pascal Thubert (pthubert) <[e-mail]>
>>>> Date: Thursday, April 22, 2021 at 17:34
>>>> To: Li Zhao (liz3) <[e-mail]>, Lynne Bartholomew <[e-mail]>
>>>> Cc: [e-mail] <[e-mail]>, RFC System <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
>>>> Subject: RE: [C310] Re: AUTH48 [LB]: RFC 9035 <draft-ietf-roll-turnon-rfc8138-18.txt> NOW AVAILABLE
>>>> 
>>>> Hello Li
>>>> 
>>>> Sorry I cannot see what your first proposed change is?
>>>> For the bits, we decided that A is a bit, so we left the picture as is and just removed the reference in the text that says that the 4 bits are shown in the figure.
>>>> 
>>>> Many thanks!
>>>> 
>>>> Pascal
>>>> 
>>>> From: Li Zhao (liz3) <[e-mail]> 
>>>> Sent: jeudi 22 avril 2021 10:19
>>>> To: Pascal Thubert (pthubert) <[e-mail]>; Lynne Bartholomew <[e-mail]>
>>>> Cc: [e-mail]; RFC System <[e-mail]>; [e-mail]; [e-mail]
>>>> Subject: Re: [C310] Re: AUTH48 [LB]: RFC 9035 <draft-ietf-roll-turnon-rfc8138-18.txt> NOW AVAILABLE
>>>> 
>>>> Hello Lynne,
>>>> 
>>>> Pleas find my additional editorial changes; I approve the publication of RFC 9035 once they are applied.
>>>> 
>>>> Section 3
>>>> Flags -> flags (3 places); "Enable RFC8138 Compression" (T) ->  "Enable RFC8138 Compression (T)”  to make it consistent with RFC9010.
>>>> 
>>>> Align figure 1 to the one in RFC 9010.:
>>>> 
>>>>    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|       ...           |
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     +
>>>>                                   |4 bits |
>>>> 
>>>> 
>>>> The DIO message propagates down the DODAG to form and then maintain its structure.                  
>>>> to
>>>> The DIO message propagates down the DODAG to form and then maintains its structure.
>>>> 
>>>> 
>>>> Best regards,
>>>> Li
>>>> 
>>>> 
>>>> From: Pascal Thubert (pthubert) <[e-mail]>
>>>> Date: Thursday, April 22, 2021 at 14:37
>>>> To: Lynne Bartholomew <[e-mail]>, Li Zhao (liz3) <[e-mail]>
>>>> Cc: [e-mail] <[e-mail]>, RFC System <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
>>>> Subject: RE: [C310] Re: AUTH48 [LB]: RFC 9035 <draft-ietf-roll-turnon-rfc8138-18.txt> NOW AVAILABLE
>>>> 
>>>> Dear Lynne:
>>>> 
>>>> I checked https://www.rfc-editor.org/authors/rfc9035-auth48diff.html and I'm all good now.
>>>> 
>>>> Keep safe;
>>>> 
>>>> Pascal
>>>>> -----Original Message-----
>>>>> From: Lynne Bartholomew <[e-mail]>
>>>>> Sent: jeudi 22 avril 2021 2:40
>>>>> To: Pascal Thubert (pthubert) <[e-mail]>; [e-mail]
>>>>> Cc: [e-mail]; RFC System <[e-mail]>;
>>>>> [e-mail]
>>>>> Subject: Re: [C310] Re: AUTH48 [LB]: RFC 9035 <draft-ietf-roll-turnon-
>>>>> rfc8138-18.txt> NOW AVAILABLE
>>>>> 
>>>>> Hi, Pascal, Alvaro, and John.
>>>>> 
>>>>> Alvaro and John, thank you for your quick replies!  We have noted your
>>>>> approvals:
>>>>> 
>>>>> https://www.rfc-editor.org/auth48/rfc9035
>>>>> 
>>>>> Pascal, apologies for the oversight, and thanks for spotting it!  We
>>>>> removed the old sentence.  We also updated Table 1 per your note below and
>>>>> will ask IANA to make this additional update shortly before publication.
>>>>> 
>>>>> Please refresh your browser to view the latest:
>>>>> 
>>>>> 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-lastdiff.html
>>>>> https://www.rfc-editor.org/authors/rfc9035-lastrfcdiff.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
>>>>> 
>>>>> Thanks again!
>>>>> 
>>>>> RFC Editor/lb
>>>>> 
>>>>> 
>>>>>> On Apr 21, 2021, at 1:17 PM, Pascal Thubert (pthubert)
>>>>> <[e-mail]> wrote:
>>>>>> 
>>>>>> 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
>>>>> 
>>>>>> From: Alvaro Retana <[e-mail]>
>>>>>> Subject: Re: * AD - Alvaro Retana, John Scudder, or Martin Vigoureux
>>>>>> Re: AUTH48 [LB]: RFC 9035 <draft-ietf-roll-turnon-rfc8138-18.txt> NOW
>>>>>> AVAILABLE
>>>>>> Date: April 21, 2021 at 1:08:35 PM PDT
>>>>>> To: "[e-mail]" <[e-mail]>, Lynne Bartholomew
>>>>>> <[e-mail]>, "Pascal Thubert (pthubert)"
>>>>>> <[e-mail]>
>>>>>> Cc: RFC System <[e-mail]>, "Li Zhao (liz3)"
>>>>>> <[e-mail]>, "[e-mail]" <[e-mail]>,
>>>>>> "[e-mail]" <[e-mail]>,
>>>>>> "[e-mail]" <[e-mail]>
>>>>>> 
>>>>>> Lynn:
>>>>>> 
>>>>>> Hi!
>>>>>> 
>>>>>> This change is ok.
>>>>>> 
>>>>>> Thanks!
>>>>>> 
>>>>>> Alvaro.
>>>>> 
>>>>>> From: John Scudder <[e-mail]>
>>>>>> Subject: Re: * AD - Alvaro Retana, John Scudder, or Martin Vigoureux
>>>>>> Re: AUTH48 [LB]: RFC 9035 <draft-ietf-roll-turnon-rfc8138-18.txt> NOW
>>>>>> AVAILABLE
>>>>>> Date: April 21, 2021 at 1:05:07 PM PDT
>>>>>> To: Lynne Bartholomew <[e-mail]>
>>>>>> Cc: "Pascal Thubert (pthubert)" <[e-mail]>,
>>>>>> "[e-mail]" <[e-mail]>, RFC System
>>>>>> <[e-mail]>, "Li Zhao (liz3)" <[e-mail]>,
>>>>>> "[e-mail]" <[e-mail]>,
>>>>>> "[e-mail]" <[e-mail]>,
>>>>>> "[e-mail]" <[e-mail]>
>>>>>> 
>>>>>> The proposed change looks fine to me.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> —John
>>>>> 
>>>>>> 
>>>>>>> Le 21 avr. 2021 à 22:10, Pascal Thubert (pthubert) via c310 <c310@rfc-
>>>>> editor.org> 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-opti
>>>>>>>>>>> on-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-opti
>>>>>>>>>>> on-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
>>>> 
>>> 
> 
> 
> 
>