[C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-30.txt> NOW AVAILABLE

[Lynne Bartholomew <[e-mail]>]

Dear Michael, Pascal, and *AD (Alvaro),

* Alvaro, please review the update to Section 6 (removed sentence per Pascal's reply to our question 8) below), and let us know if you approve.

Thank you for the emails.

A few follow-up items:

Pascal, our current text in Sections 12.5 and 12.6 does not match what you list here as "OLD" (i.e., there is no "and the 'E' flag set to 0").  Please advise.

> We had a comment on the ROLL ML that makes sense. The comment is this:
> "
> Section 12.5 and Section 12.6 of the document specifies the RPL Status values. I believe section 12.5 is applicable only when the 'E' bit of the status is set to 0 and Section 12.6 is applicable only when the 'E' bit is set to 1. I came across this while reviewing it in context to NPDAO compatibility.
> "
> Suggestion:
> 
> In section 12.5
> OLD
> " 
>   IANA has created a new subregistry for the RPL Non-Rejection Status
>   values for use in the RPL DAO-ACK, DCO, and DCO-ACK messages with the
>   'A' flag set to 0 and the 'E' flag set to 0, under the "Routing Protocol for Low Power and
>   Lossy Networks (RPL)" registry.
> "
> NEW
> "
>   IANA has created a new subregistry for the RPL Non-Rejection Status
>   values for use in the RPL DAO-ACK, DCO, and DCO-ACK messages with the
>   A flag set to 0 and the E flag set to 1, under the "Routing Protocol for Low Power and
>   Lossy Networks (RPL)" registry.
> "
> 
> In section 12.6
> OLD
> "   IANA has created a new subregistry for the RPL Rejection Status
>   values for use in the RPL DAO-ACK and DCO messages with the 'A' flag
>   set to 0 and the 'E' flag set to 0, under the "Routing Protocol for Low Power and Lossy
>   Networks (RPL)" registry.
> "
> NEW
> "   IANA has created a new subregistry for the RPL Rejection Status
>   values for use in the RPL DAO-ACK and DCO messages with the A flag
>   set to 0 and the E flag set to 1, under the "Routing Protocol for Low Power and Lossy
>   Networks (RPL)" registry.
> "


= = = = = 

Apologies, but we are not sure how to proceed as relates to flag names.  For example:

This note from Pascal, and Michael's reply:

>> We could rename the E flag that we create here to some letter that does
>> not show in the spec, e.g.,  G.
> 
> Is the suggestion that we rename to "G", and take the impact on RFC9009?
> Maybe we can just prefix:
> 
>  "EARO-E flag"

Pascal's reply to our question about flag-naming conventions:

>>> 19) <!-- [rfced] We see unquoted, single-quoted, and double-quoted flag
>> names
>>> in this document.  We also see both "flag" and "Flag" for flag names.  We
>>> recommend using single quotes and lowercasing "flag" for consistency with
>>> draft-ietf-roll-useofrplinfo and draft-ietf-roll-efficient-npdao.  Please let us
>>> know if this is acceptable.
>>> 
>>> For example:
>>>  R flag
>>>  R Flag
>>>  "R" and "T" flags
>>>  T Flag
>>>  L, P and E flags
>>>  'E' flag
>>>  'P' flag
>>>  'P' Flag -->
>> 
>> Let us can align to RFC 8505 with no quote and lower case flag as in < R flag >.

A note regarding the idea of the G flag:  We see the following in RFC 8505; would another G flag in this document be confusing?

   This specification defines five new capability bits for use in the
   6CIO as defined by [RFC7400] ("6LoWPAN-GHC: Generic Header
   Compression for IPv6 over Low-Power Wireless Personal Area Networks
   (6LoWPANs)"), for use in IPv6 ND messages.  (The G flag is defined in
   Section 3.3 of [RFC7400].)

We don't know which flags are GHC flags and which are EARO flags.  For example, which category of flag is "External ('E') flag in the 
Transit Information Option (TIO)"?

One option would be to double-quote the EARO flags and add some introductory text re. same (something like "Please note that, to avoid possible confusion, EARO flags are double-quoted and GHC flags are unquoted in this document.")

We have left the quoting or unquoting of flag names for later and will wait for your guidance.  Another option is that, if it turns out that the three written styles of flag names indicate three categories of flags (i.e., EARO, GHC, and something else), perhaps we should leave all quoting as is and provide explanatory text (in the first paragraph of Section 3, or earlier).

= = = = =

Pascal, regarding this question and your reply:

>>> 4) <!-- [rfced] The text refers to the "ND status codes".  Is it
>>> correct that this refers to the "Address Registration Option Status Values"
>> registry?
>>> Perhaps "ND status codes" should be "Address Registration Options" or
>>> "ARO/EARO Status values"?
>> 
>> Yes, let's go for "ARO/EARO Status values" in both cases below:

Should the two instances of "ND status code" (Sections 6.3 and 9.1) be left as is?

= = = = =

In Section 10, "it is the RPL model that the" reads a bit oddly.  Apologies for not asking our original question more clearly.  Does the current "Note that it is the RPL model that the multicast packet is copied" mean "Note that per the RPL model the multicast packet is copied", "Note that it is in the RPL model that the multicast packet is copied", or something else?

= = = = =

The latest files are posted here:

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

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

Thanks again!

RFC Editor/lb


> On Mar 23, 2021, at 1:07 PM, Michael Richardson <[e-mail]> wrote:
> 
> 
> Pascal Thubert (pthubert) <[e-mail]> wrote:
>> There are different flags named E in this spec and this may create a
>> confusion. There's already one in the EARO, and one in the GHC.
> 
>> We could rename the one we introduce here but that will impact both
>> this and RFC 9009.
> 
>> We could rename the E flag that we create here to some letter that does
>> not show in the spec, e.g.,  G.
> 
> Is the suggestion that we rename to "G", and take the impact on RFC9009?
> Maybe we can just prefix:
> 
>  "EARO-E flag"
> 
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 

> From: "Pascal Thubert (pthubert)" <[e-mail]>
> Subject: RE: AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-30.txt> NOW AVAILABLE
> Date: March 23, 2021 at 9:27:06 AM PDT
> To: "Pascal Thubert (pthubert)" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> 
> Dear RFC Editor
> 
> We had a comment on the ROLL ML that makes sense. The comment is this:
> "
> Section 12.5 and Section 12.6 of the document specifies the RPL Status values. I believe section 12.5 is applicable only when the 'E' bit of the status is set to 0 and Section 12.6 is applicable only when the 'E' bit is set to 1. I came across this while reviewing it in context to NPDAO compatibility.
> "
> Suggestion:
> 
> In section 12.5
> OLD
> " 
>   IANA has created a new subregistry for the RPL Non-Rejection Status
>   values for use in the RPL DAO-ACK, DCO, and DCO-ACK messages with the
>   'A' flag set to 0 and the 'E' flag set to 0, under the "Routing Protocol for Low Power and
>   Lossy Networks (RPL)" registry.
> "
> NEW
> "
>   IANA has created a new subregistry for the RPL Non-Rejection Status
>   values for use in the RPL DAO-ACK, DCO, and DCO-ACK messages with the
>   A flag set to 0 and the E flag set to 1, under the "Routing Protocol for Low Power and
>   Lossy Networks (RPL)" registry.
> "
> 
> In section 12.6
> OLD
> "   IANA has created a new subregistry for the RPL Rejection Status
>   values for use in the RPL DAO-ACK and DCO messages with the 'A' flag
>   set to 0 and the 'E' flag set to 0, under the "Routing Protocol for Low Power and Lossy
>   Networks (RPL)" registry.
> "
> NEW
> "   IANA has created a new subregistry for the RPL Rejection Status
>   values for use in the RPL DAO-ACK and DCO messages with the A flag
>   set to 0 and the E flag set to 1, under the "Routing Protocol for Low Power and Lossy
>   Networks (RPL)" registry.
> "
> 
> Also:
> 
> There are different flags named E in this spec and this may create a confusion. There's already one in the EARO, and one in the GHC.
> We could rename the one we introduce here but that will impact both this and RFC 9009. 
> We could rename the E flag that we create here to some letter that does not show in the spec, e.g.,  G.
> 
> What do you think?
> 
> Pascal
> 
>> -----Original Message-----
>> From: c310 <[e-mail]> On Behalf Of Pascal Thubert
>> (pthubert) via c310
>> Sent: mardi 23 mars 2021 10:24
>> To: [e-mail]; [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail]
>> Subject: Re: [C310] AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-
>> 30.txt> NOW AVAILABLE
>> 
>> Dear RFC editor
>> 
>> Please find inline some answers:
>> 
>>> 1) <!-- [rfced] As "https://" now appears to work in Michael
>>> Richardson's URL, we changed "http://" to "https://".  Please let us know any
>> objections.
>>> 
>>> Original:
>>> URI:   http://www.sandelman.ca/
>>> 
>>> Currently:
>>> URI:   https://www.sandelman.ca/ -->
>>> 
>> 
>> Much better
>> 
>>> 
>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear
>>> in the
>>> title) for use on https://www.rfc-editor.org/search -->
>> 
>> IPv6 ND Redistribution
>> 
>> 
>>> 
>>> 
>>> 3) <!-- [rfced] We suggest moving the first sentence to appear last.
>>> That way, the first sentence provides more insight regarding the
>>> content of the document.
>>> 
>>> Original:
>>>   This specification updates RFC6550, RFC6775, and RFC8505.  It
>>>   provides a mechanism for a host that implements a routing-agnostic
>>>   interface based on 6LoWPAN Neighbor Discovery to obtain reachability
>>>   services across a network that leverages RFC6550 for its routing
>>>   operations.
>>> 
>>> Suggested:
>>>   This specification provides a
>>>   mechanism for a host that implements a routing-agnostic interface
>>>   based on IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
>>>   Neighbor Discovery to obtain reachability services across a network
>>>   that leverages RFC 6550 for its routing operations.  It updates RFCs
>>>   6550, 6775, and 8505.
>>> -->
>>> 
>> 
>> Great!
>> 
>>> 
>>> 4) <!-- [rfced] The text refers to the "ND status codes".  Is it
>>> correct that this refers to the "Address Registration Option Status Values"
>> registry?
>>> Perhaps "ND status codes" should be "Address Registration Options" or
>>> "ARO/EARO Status values"?
>> 
>> Yes, let's go for "ARO/EARO Status values" in both cases below:
>> 
>>> 
>>> Original (Section 1):
>>>   *  Section 8 presents the changes made to [RFC6775] and [RFC8505];
>>>      The range of the ND status codes is reduced down to 64 values, and
>>>      the remaining bits in the original status field are now reserved.
>>> 
>>> Original (Section 8):
>>>   This document updates [RFC6775] and [RFC8505] to reduce the range of
>>>   the ND status codes down to 64 values.
>>> -->
>>> 
>>> 
>>> 5) <!-- [rfced] Glossary:  Please note that (1) we listed the terms in
>>> alphanumeric order and (2) we added several terms for ease of the reader.
>>> Please review, and let us know any objections. -->
>>> 
>>> 
>> 
>> All good
>> 
>>> 6) <!-- [rfced] Figure 2:  We updated the Registration Ownership
>>> Verifier
>>> (ROVR) field to match what is shown in Figure 1 in RFC 8505.
>>> Please let us know any objections.
>>> 
>>> Original:
>>> ...             Registration Ownership Verifier                 ...
>>> 
>>> Currently:
>>> ...          Registration Ownership Verifier (ROVR)             ... -->
>>> 
>>> 
>> 
>> Sure, thanks
>> 
>>> 7) <!-- [rfced] Section 5.2:  Because [USEofRPLinfo] does not have a
>>> Section 2.1 and Section 4.1 of [USEofRPLinfo] appears to be applicable
>>> (per text in Section
>>> 3 and later in this section), we updated this citation accordingly.
>>> Please let us know if a different section should be cited here.
>>> 
>>> Original:
>>> Section 2.1 of [USEofRPLinfo] defines the rules for tunneling either
>>> to the final destination (e.g., a RUL) or to its attachment router  (designated
>> as 6LR).
>>> 
>>> Currently:
>>> Section 4.1 of [RFC9008] defines the rules for tunneling to either
>>> the final destination (e.g., a RUL) or its attachment router
>>> (designated as a 6LR). -->
>>> 
>> 
>> Great catch. Must be a typo, that section was never 2.1! Now; that's really
>> 4.1.1. So I'd like to change to:
>> 
>> "  Section 4.1.1 of [RFC9008] defines the rules for signaling an external
>>  destination (e.g., a RUL), and tunneling to its attachment router
>>  (designated as 6LR) ."
>> 
>> 
>>> 
>>> 8) <!-- [rfced] Section 6:  We received the following email from Pascal
>> Thubert,
>>> dated 5 January 2021.  Please review, and let us know if the sentence in
>>> question should be removed.
>>> 
>>> Hello Lynne
>>> 
>>> Please see https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/
>>> in the same cluster.
>>> 
>>> It says
>>> "The RPL Status defined in section 6.5.1 of [RFC6550] for use in the
>>> DAO-ACK message is extended to be placed in DCO messages [EFFICIENT-
>>> NPDAO]
>>> as well."
>>> 
>>> Ideally we would retrofit that modification in the NPDAO draft and remove it
>>> from the RUL draft? -->
>> 
>> Maybe we can just remove that sentence.
>> I reviewed https://www.rfc-editor.org/authors/rfc9009.html#name-
>> destination-cleanup-object- and it looks good as is.
>> 
>> 
>> 
>>> 9) <!-- [rfced] Section 6.2:  We found this citation confusing, as the
>>> title of Section 4.3 of [USEofRPLinfo] is "Updates to RFC8138:
>>> Indicating the way to decompress with the new RPI Option Type", and we
>> could
>>> not find any mention of "MOP" in its text.  Please confirm that this citation is
>>> correct and will be clear to readers.
>>> 
>>> Original:
>>> Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that the
>>> definition of the Flags applies to Mode of Operation (MOP) values  from zero
>>> (0) to six (6) only.
>> 
>> -->
>> 
>> 
>> It is really section 4.1.3. :
>> 
>> "  Section 4.1.3 of [USEofRPLinfo] updates [RFC6550] to indicate that the
>> definition of the Flags applies to Mode of Operation (MOP) values  from zero
>> (0) to six (6) only.
>> 
>> "
>> 
>>> 10) <!-- [rfced] The "RPL Non-Rejection Status" registry includes the following
>>> for value 0:
>>> 
>>>   0 Unqualified acceptance [RFC6550][RFC-ietf-roll-unaware-leaves-30]
>>> 
>>> Should the description be "Success / Unqualified acceptance"?
>> 
>> Yes
>> 
>> 
>>> 
>>> Section 6.3:
>>>              | 0       | Success / Unqualified acceptance |
>>> 
>>> 
>>>   E:  1-bit flag.  Set to 1 to indicate a rejection.  When set to 0, a
>>>       Status value of 0 indicates Success / Unqualified acceptance and
>>>       other values indicate "Not an outright rejection" as per
>>>       RFC 6550.
>>> -->
>> 
>> Yes, please also update table 4 in section 12.5 to say " Success / Unqualified
>> acceptance"
>> 
>>> 
>>> 11) <!-- [rfced] Section 9.1:  We are revisiting this question (asked during the
>>> EDIT state):
>>> 
>>> We updated the sentence in question per your feedback, but please
>>> note that we used "no longer" (as in "was reachable before; isn't
>>> reachable now") as opposed to "no more" (which looks to us like a
>>> comparison, i.e., "this one is no more reachable than this other
>>> one").  Please let us know if "no longer" is incorrect (i.e., a comparison is
>>> intended).
>>> 
>>> Our original question:
>>> Section 9.1:  We had trouble following this sentence.
>>> We updated it as follows.  If this is incorrect, to what do the two instances of
>>> "it" refer?
>>> 
>>> Author replies:
>>> Oups, no. "ignore" was meant to say "not be aware" that it is no more
>>> reachable What about:
>>> "
>>> Note that a legacy RAN that receives a Non-Storing  DCO that it does not
>>> support will ignore it silently, as specified in  section 6 of [RFC6550].
>>> The result is that it will remain unaware that it is no more reachable
>>> till its next RPL exchange happens.
>>> "
>>> 
>>> Original (the previous sentence is included for context):
>>> Note that a legacy RAN that receives a Non-Storing  DCO that it does not
>>> support will ignore it silently, as specified in  section 6 of [RFC6550].  The
>> result
>>> is that it may ignore for a while  that it is no more reachable.
>>> 
>>> Currently:
>>> The result is that it will
>>> remain unaware that it is no longer reachable until its next RPL  exchange
>>> happens. -->
>>> 
>> 
>> 
>> Perfect!!! This was my French. "Plus" can mean both "more" and "longer". We
>> understand from context which is which.
>> 
>> 
>>> 
>>> 12) <!-- [rfced] Figure 10:  Would you like to close up the vertical line under
>>> "Root" in the "Proof-of-ownership" line?
>>> 
>>> Original (best viewed with a fixed-point font such as Courier;
>>>  dashed lines are broken so that xml2rfc doesn't treat them as
>>>  comments):
>>> |- - - NS EARO and Proof-of-ownership   ->|                       |
>>> 
>>> Possibly:
>>> |- -  NS(EARO) and proof of ownership - ->|           |           |
>>> -->
>> 
>> Please do
>> 
>> 
>> 
>>> 13) <!-- [rfced] Section 10:  This sentence does not parse.  Please clarify "the
>>> RPL model that the multicast packet is passed".
>>> 
>>> Also, is the use of unicast a feature that is new to this document?
>>> We see this in RFC 6550:
>>> "The
>>>  main difference is that the multicast traffic going down is copied to
>>>  all the children that have registered with the multicast group,
>>>  whereas unicast traffic is passed to one child only."
>>> 
>>> Original:
>>> Note that it is the RPL model that the multicast packet is passed as  a Layer-2
>>> unicast to each of the interested children. -->
>> 
>> "Passed" was intended to mean "copied + transmitted. This is the French for
>> handed over. Again, sorry for the native language leaking through.
>> 
>> What about:
>> 
>> "
>> Note that it is the RPL model that the multicast packet is copied and
>> transmitted as  a Layer-2
>> unicast to each of the interested children.
>> 
>> "
>> 
>> 
>>> 
>>> 14) <!-- [rfced] Section 10:  Please confirm that Section 5.1 of [RFC3810] is the
>>> correct section to cite here.  We ask because the only mention
>>> of "report" that we see in Section 5.1 of [RFC3810] is "a responding
>>> Report", and we don't see any mention of "unsolicited" in that section.  If the
>>> citation is correct, would it help the reader if this sentence were somehow
>>> reworded?
>>> 
>>> Original:
>>> Upon a DAO with a Target option for a multicast address, the RPL Root
>> checks
>>> if it is already registered as a listener for that address,  and if not, it performs
>>> its own unsolicited Report for the multicast  address as described in section
>> 5.1
>>> of [RFC3810]. -->
>>> 
>> 
>> 
>> Section 5.1 describes the message and secrtion 6 describes the operation.
>> Maybe clearer to indicate section 6.
>> Not that unsolicited is not a protocol term, just aims at indicating that it is not a
>> consequence of a query but an async indication from the listener.
>> 
>> Upon a DAO with a Target option for a multicast address, the RPL Root  checks
>> if it is already registered as a listener for that address,  and if not, it performs
>> its own unsolicited Report for the multicast  address as described in section 6.1
>> of [RFC3810].
>> 
>>> 
>>> 15) <!-- [rfced] Section 10:  We had trouble following this sentence.
>>> How is one Report mapped to a DAO one by one?  Are the contents/entries of
>>> the Report mapped to a DAO one by one?
>>> 
>>> Original:
>>> Upon the timing out of the Query
>>> Interval, the 6LR sends a Multicast Address Specific Query to each of  its
>>> listeners, for each Multicast Address, and gets a Report back  that is mapped
>>> into a DAO one by one. -->
>>> 
>> 
>> "
>> Upon the timing out of the Query Interval, the 6LR sends a Multicast Address
>> Specific Query to each of  its listeners, for each Multicast Address.
>> The listeners respond with a Report.
>> Based on the Reports, the 6LR maintains the aggregated list
>> of all the Multicast Addresses for which there is a listener, and
>> advertises them using DAO messages as specified in section 12 of [RFC6550].
>> "
>> 
>> 
>> 
>>> 
>>> 16) <!-- [rfced] Please confirm that this document be listed as a Reference for
>>> the registry, in addition to RFC 6775.  If confirmed, we will ask IANA to update
>>> https://www.iana.org/assignments/icmpv6-parameters/.
>>> 
>>> Original:
>>>   IANA is requested to modify the Address Registration Option Status
>>>   values Registry so that the upper bound of the unassigned values is
>>>   63.  This document should be added as a reference.  The registration
>>>   procedure does not change.
>>> 
>>> https://www.iana.org/assignments/icmpv6-parameters/:
>>> Address Registration Option Status Values
>>> 
>>> Registration Procedure(s)
>>>    Standards Action
>>> 
>>> Reference
>>>    [RFC6775]
>>> -->
>> 
>> Yes, see section 12.2; we change the format of the values, and IANA is already
>> aware (my understanding).
>> Also a typo in 12.2, I guess we want "changed".
>> "
>> The registration procedure has not change.
>> "
>> 
>>> 
>>> 
>>> 17) <!-- [rfced] The following appeared inconsistently in this document.  We
>>> have used the form on the right for consistency with RFC 6550.  Please let us
>>> know if any changes are needed.
>>> 
>>> Target Option / Target option
>>> target address / Target address
>>> Root node / root node
>> 
>> Thanks for this
>> 
>>> 
>>> We are revisiting this question (asked during the EDIT
>>> state):
>>> 
>>> The following terms appear to be used inconsistently in this document.
>> Please
>>> let us know which form is preferred.
>>> 
>>> advertised Prefix / advertised prefix
>>> 
>>> Flags / flags (used generally, e.g., "the flags", "the Flags")
>>> 
>>> Lifetime of zero / Lifetime of 0
>>> 
>>> Multicast Address / multicast address (where used generally,
>>>   e.g., "the Multicast Address as", "the multicast address as")
>>> 
>>> Prefix route / prefix route (appears to be used generally)
>>> 
>>> Status / status (used generally, e.g., "the non-zero status in the
>>>   DCO supersedes a positive Status")
>>> 
>>> the Lifetime / the lifetime (used more generally, e.g.,
>>>   "the Lifetime of", "the lifetime indicated in")
>>> 
>>> Updated / updated
>>>   (in text, e.g., "Updated RPL Target option", "updated RPL Target
>>>   Option")
>>> 
>>> the Size of the ROVR / the size of the ROVR -->
>> 
>> Using the right version for all is OK with me.
>> 
>>> 
>>> 
>>> 18) <!-- [rfced] This document consistently uses "collocated", while
>>> draft-ietf-roll-useofrplinfo-44 and much of C310 use "co-locate".  May we
>>> update the text to use "co-locate" for consistency with other C310
>> documents?
>>> 
>>> Originals:
>>>   ... (typically collocated with the 6LBR) ...
>>> 
>>>   [RFC8929] expects that the 6LBR is collocated with the RPL Root, ...
>>> 
>>>   Figure 9 illustrates this in the case where the 6LBR and the Root are
>>>   not collocated, and the Root proxies the EDAR/EDAC flow.
>>> -->
>> 
>> Please do
>> 
>>> 
>>> 
>>> 19) <!-- [rfced] We see unquoted, single-quoted, and double-quoted flag
>> names
>>> in this document.  We also see both "flag" and "Flag" for flag names.  We
>>> recommend using single quotes and lowercasing "flag" for consistency with
>>> draft-ietf-roll-useofrplinfo and draft-ietf-roll-efficient-npdao.  Please let us
>>> know if this is acceptable.
>>> 
>>> For example:
>>>  R flag
>>>  R Flag
>>>  "R" and "T" flags
>>>  T Flag
>>>  L, P and E flags
>>>  'E' flag
>>>  'P' flag
>>>  'P' Flag -->
>> 
>> Let us can align to RFC 8505 with no quote and lower case flag as in < R flag >.
>> 
>> Please let me know when the RFC is updated and I'll make the complete review
>> 😊
>> 
>> Pascal
>> 
>> 
>>> 
>>> Thank you.
>>> 
>>> RFC Editor
>>> 
>>> 
>>> 
>>> 
>>> On Mar 21, 2021, at 10:13 PM, [e-mail] wrote:
>>> 
>>> *****IMPORTANT*****
>>> 
>>> Updated 2021/03/21
>>> 
>>> RFC Author(s):
>>> --------------
>>> 
>>> Instructions for Completing AUTH48
>>> 
>>> Your document has now entered AUTH48.  Once it has been reviewed and
>>> approved by you and all coauthors, it will be published as an RFC.
>>> If an author is no longer available, there are several remedies available as
>>> listed in the FAQ (https://www.rfc-editor.org/faq/).
>>> 
>>> You and you coauthors are responsible for engaging other parties (e.g.,
>>> Contributors or Working Group) as necessary before providing your approval.
>>> 
>>> Planning your review
>>> ---------------------
>>> 
>>> Please review the following aspects of your document:
>>> 
>>> *  RFC Editor questions
>>> 
>>>  Please review and resolve any questions raised by the RFC Editor
>>>  that have been included in the XML file as comments marked as
>>>  follows:
>>> 
>>>  <!-- [rfced] ... -->
>>> 
>>>  These questions will also be sent in a subsequent email.
>>> 
>>> *  Changes submitted by coauthors
>>> 
>>>  Please ensure that you review any changes submitted by your
>>>  coauthors.  We assume that if you do not speak up that you
>>>  agree to changes submitted by your coauthors.
>>> 
>>> *  Content
>>> 
>>>  Please review the full content of the document, as this cannot
>>>  change once the RFC is published. Please pay particular attention to:
>>>  - IANA considerations updates (if applicable)
>>>  - contact information
>>>  - references
>>> 
>>> *  Copyright notices and legends
>>> 
>>>  Please review the copyright notice and legends as defined in
>>>  RFC 5378 and the Trust Legal Provisions
>>>  (TLP – https://trustee.ietf.org/license-info/).
>>> 
>>> *  Semantic markup
>>> 
>>>  Please review the markup in the XML file to ensure that elements of
>>>  content are correctly tagged.  For example, ensure that <sourcecode>
>>>  and <artwork> are set correctly.  See details at
>>>  <https://xml2rfc.tools.ietf.org/xml2rfc-doc.html>.
>>> 
>>> *  Formatted output
>>> 
>>>  Please review the PDF, HTML, and TXT files to ensure that the
>>>  formatted output, as generated from the markup in the XML file, is
>>>  reasonable.  Please note that the TXT will have formatting
>>>  limitations compared to the PDF and HTML.
>>> 
>>> 
>>> Submitting changes
>>> ------------------
>>> 
>>> To submit changes, please reply to this email with one of the following, using
>>> ‘REPLY ALL’ as all the parties CC’ed on this message need to see your changes:
>>> 
>>> An update to the provided XML file
>>> — OR —
>>> An explicit list of changes in this format
>>> 
>>> Section # (or indicate Global)
>>> 
>>> OLD:
>>> old text
>>> 
>>> NEW:
>>> new text
>>> 
>>> You do not need to reply with both an updated XML file and an explicit list of
>>> changes, as either form is sufficient.
>>> 
>>> We will ask a stream manager to review and approve any changes that seem
>>> beyond editorial in nature, e.g., addition of new text, deletion of text, and
>>> technical changes.  Information about stream managers can be found in the
>>> FAQ.  Editorial changes do not require approval from a stream manager.
>>> 
>>> 
>>> Approving for publication
>>> --------------------------
>>> 
>>> To approve your RFC for publication, please reply to this email s tating that
>> you
>>> approve this RFC for publication.  Please use ‘REPLY ALL’
>>> as all the parties CC’ed on this message need to see your approval.
>>> 
>>> 
>>> Files
>>> -----
>>> 
>>> The files are available here:
>>>  https://www.rfc-editor.org/authors/rfc9010.xml
>>>  https://www.rfc-editor.org/authors/rfc9010.html
>>>  https://www.rfc-editor.org/authors/rfc9010.pdf
>>>  https://www.rfc-editor.org/authors/rfc9010.txt
>>> 
>>> Diff file of the text:
>>>  https://www.rfc-editor.org/authors/rfc9010-diff.html
>>> 
>>> Diff of the XML:
>>>  https://www.rfc-editor.org/authors/rfc9010-xmldiff1.html
>>> 
>>> The following files are provided to facilitate creation of your own diff files of
>>> the XML.
>>> 
>>> XMLv3 file that is a best effort to capture v3-related format updates
>>> only:
>>>  https://www.rfc-editor.org/authors/rfc9010.form.xml
>>> 
>>> 
>>> Tracking progress
>>> -----------------
>>> 
>>> The details of the AUTH48 status of your document are here:
>>>  https://www.rfc-editor.org/auth48/rfc9010
>>> 
>>> Please let us know if you have any questions.
>>> 
>>> Thank you for your cooperation,
>>> 
>>> RFC Editor
>>> 
>>> --------------------------------------
>>> RFC9010 (draft-ietf-roll-unaware-leaves-30)
>>> 
>>> Title            : Routing for RPL Leaves
>>> Author(s)        : P. Thubert, Ed., M. Richardson
>>> WG Chair(s)      : Dominique Barthel, Ines Robles
>>> Area Director(s) : Alvaro Retana, John Scudder, Martin Vigoureux
>>> 
>>> 
>> 
>> --
>> c310 mailing list
>> [e-mail]
>> https://www.rfc-editor.org/mailman/listinfo/c310