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

[Lynne Bartholomew <[e-mail]>]

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?

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.

The latest files are posted here:

   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
>