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

[Lynne Bartholomew <[e-mail]>]

Dear IANA,

We are preparing this document for publication.

Please make the following update to the "Address Registration Option Status Values" registry on <https://www.iana.org/assignments/icmpv6-parameters/>:  
 
OLD:  
Reference  
[RFC6775]  
 
NEW:  
Reference  
[RFC6775][RFC-ietf-roll-unaware-leaves-30]

Please make the following update on <https://www.iana.org/assignments/rpl/>:  
 
OLD:  
0 Unqualified acceptance [RFC6550][RFC-ietf-roll-unaware-leaves-30]  
 
NEW:  
0 Success / Unqualified acceptance [RFC6550][RFC-ietf-roll-unaware-leaves-30]

Thank you.

RFC Editor/lb

> On Mar 29, 2021, at 5:08 PM, Michael Richardson <[e-mail]> wrote:
> 
> Lynne Bartholomew <[e-mail]> wrote:
>> https://www.rfc-editor.org/auth48/rfc9010
> 
>> Michael, it's not clear whether you approve terminology updates only or
>> the document's readiness for approval; please let us know.
> 
> Yes. All.
> 

> On Mar 29, 2021, at 1:46 PM, Lynne Bartholomew <[e-mail]> wrote:
> 
> Hi, Pascal and Michael.
> 
> Pascal, we have updated the AUTH48 status page and noted your confirmed approval for publication:
> 
>   https://www.rfc-editor.org/auth48/rfc9010
> 
> Michael, it's not clear whether you approve terminology updates only or the document's readiness for approval; please let us know.
> 
> Thank you!
> 
> RFC Editor/lb
> 
> 
>> On Mar 29, 2021, at 12:21 PM, Pascal Thubert (pthubert) <[e-mail]> wrote:
>> 
>> Dear all 
>> 
>> Same here ; I approve the draft publication.
>> 
>> Keep safe,
>> 
>> Pascal
>> 
>>> Le 29 mars 2021 à 20:48, Michael Richardson <[e-mail]> a écrit :
>>> 
>>> 
>>> I have reviewed the DODAG root changes, and I approve.
>>> 
>>> 
>>> --
>>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>>>         Sandelman Software Works Inc, Ottawa and Worldwide
>>> 
>>> 
>>> 
>>> 
> 
> -- 
> c310 mailing list
> [e-mail]
> https://www.rfc-editor.org/mailman/listinfo/c310



> Begin forwarded message:
> 
> From: "Pascal Thubert (pthubert)" <[e-mail]>
> Subject: RE: AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-30.txt> NOW AVAILABLE
> Date: March 26, 2021 at 10:28:18 AM PDT
> To: Lynne Bartholomew <[e-mail]>, Michael Richardson <[e-mail]>
> Cc: Alvaro Retana <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, RFC System <[e-mail]>, "[e-mail]" <[e-mail]>
> 
> Hello Lynne
> 
> Dear RFC editor. I made a full pass on the draft, rechecked after this republication. Happy that you used U for the flag now.
> 
> Nits:
> 
> RFC 8200 is about IPv6 not routing services so:
> "to provide IPv6 routing services [RFC8200]" -> "to provide routing services for IPv6 [RFC8200]"
> 
> "The unicast packet-forwarding operation by the 6LR serving a RUL is described in Section 4.1 of [RFC9008]."
> That's really section 4.1.1
> 
> RPL root -> RPL DODAG root.
> Root -> root or "DODAG root" as you feel best. Please do not change the P flag definition that would impact IANA.
> 
> Please record my approval for publication.
> 
> Keep safe,
> 
> Pascal
> 
>> -----Original Message-----
>> From: Lynne Bartholomew <[e-mail]>
>> Sent: vendredi 26 mars 2021 18:16
>> To: Michael Richardson <[e-mail]>
>> Cc: Pascal Thubert (pthubert) <[e-mail]>; Alvaro Retana
>> <[e-mail]>; [e-mail]; [e-mail];
>> [e-mail]; RFC System <[e-mail]>;
>> [e-mail]
>> Subject: Re: AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-30.txt>
>> NOW AVAILABLE
>> 
>> Hi, Michael.
>> 
>> Thank you for spotting those items!  I made further updates and reposted the
>> files (no new iteration).
>> 
>> Please note that in addition to reverting the change in Section 9.2.2 per your
>> note, I also reverted to "the External ('E') flag in the Transit Information Option
>> (TIO)" in Section 3.  Please let me know if this is incorrect.
>> 
>> Please review, and let me know if I missed anything or if anything else is
>> incorrect.  (You'll need to refresh your browser.)
>> 
>>   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-lastdiff.html
>>   https://www.rfc-editor.org/authors/rfc9010-lastrfcdiff.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 26, 2021, at 9:33 AM, Michael Richardson <[e-mail]>
>> wrote:
>>> 
>>> 
>>> Lynne Bartholomew <[e-mail]> wrote:
>>>> 1. changed what I *believe* to be the "E" flags in question to "U"
>>> 
>>>> 2. gone ahead and updated Sections 12.5 and 12.6 per your note
>>>> further below (but using "U" instead of "E")
>>> 
>>> I might be suffering from the confusion that we are trying to reduce!
>>> But, I think that we need to change the name of the flag in figure 6
>>> and the description too, right?
>>> 
>>>                           0 1 2 3 4 5 6 7
>>>                             +-+-+-+-+-+-+-+-+
>>>                             |E|A|StatusValue|
>>>                             +-+-+-+-+-+-+-+-+
>>> 
>>>                       Figure 6: RPL Status Format
>>> 
>>>  This specification updates the RPL Status with the following
>>>  subfields:
>>> 
>>>  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.
>>> 
>>> section 9.2.2:
>>> 
>>>  3.  The 6LR sets the External ('E')-> ('U') flag in the TIO to indicate that
>>>      it is redistributing an external target into the RPL network.
>>> 
>>> I don't think that this replacement is correct.
>>> 
>>> I think that the rest of the updates are correct.
>>> 
>>> 
>>> --
>>> 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 26, 2021 at 10:28:18 AM PDT
> To: Lynne Bartholomew <[e-mail]>, Michael Richardson <[e-mail]>
> Cc: Alvaro Retana <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, RFC System <[e-mail]>, "[e-mail]" <[e-mail]>
> 
> Hello Lynne
> 
> Dear RFC editor. I made a full pass on the draft, rechecked after this republication. Happy that you used U for the flag now.
> 
> Nits:
> 
> RFC 8200 is about IPv6 not routing services so:
> "to provide IPv6 routing services [RFC8200]" -> "to provide routing services for IPv6 [RFC8200]"
> 
> "The unicast packet-forwarding operation by the 6LR serving a RUL is described in Section 4.1 of [RFC9008]."
> That's really section 4.1.1
> 
> RPL root -> RPL DODAG root.
> Root -> root or "DODAG root" as you feel best. Please do not change the P flag definition that would impact IANA.
> 
> Please record my approval for publication.
> 
> Keep safe,
> 
> Pascal
> 
>> -----Original Message-----
>> From: Lynne Bartholomew <[e-mail]>
>> Sent: vendredi 26 mars 2021 18:16
>> To: Michael Richardson <[e-mail]>
>> Cc: Pascal Thubert (pthubert) <[e-mail]>; Alvaro Retana
>> <[e-mail]>; [e-mail]; [e-mail];
>> [e-mail]; RFC System <[e-mail]>;
>> [e-mail]
>> Subject: Re: AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-30.txt>
>> NOW AVAILABLE
>> 
>> Hi, Michael.
>> 
>> Thank you for spotting those items!  I made further updates and reposted the
>> files (no new iteration).
>> 
>> Please note that in addition to reverting the change in Section 9.2.2 per your
>> note, I also reverted to "the External ('E') flag in the Transit Information Option
>> (TIO)" in Section 3.  Please let me know if this is incorrect.
>> 
>> Please review, and let me know if I missed anything or if anything else is
>> incorrect.  (You'll need to refresh your browser.)
>> 
>>   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-lastdiff.html
>>   https://www.rfc-editor.org/authors/rfc9010-lastrfcdiff.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 26, 2021, at 9:33 AM, Michael Richardson <[e-mail]>
>> wrote:
>>> 
>>> 
>>> Lynne Bartholomew <[e-mail]> wrote:
>>>> 1. changed what I *believe* to be the "E" flags in question to "U"
>>> 
>>>> 2. gone ahead and updated Sections 12.5 and 12.6 per your note
>>>> further below (but using "U" instead of "E")
>>> 
>>> I might be suffering from the confusion that we are trying to reduce!
>>> But, I think that we need to change the name of the flag in figure 6
>>> and the description too, right?
>>> 
>>>                           0 1 2 3 4 5 6 7
>>>                             +-+-+-+-+-+-+-+-+
>>>                             |E|A|StatusValue|
>>>                             +-+-+-+-+-+-+-+-+
>>> 
>>>                       Figure 6: RPL Status Format
>>> 
>>>  This specification updates the RPL Status with the following
>>>  subfields:
>>> 
>>>  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.
>>> 
>>> section 9.2.2:
>>> 
>>>  3.  The 6LR sets the External ('E')-> ('U') flag in the TIO to indicate that
>>>      it is redistributing an external target into the RPL network.
>>> 
>>> I don't think that this replacement is correct.
>>> 
>>> I think that the rest of the updates are correct.
>>> 
>>> 
>>> --
>>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>>>          Sandelman Software Works Inc, Ottawa and Worldwide
>>> 
>>> 
>>> 
>>> 
> 

> From: Michael Richardson <[e-mail]>
> Subject: Re: AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-30.txt> NOW AVAILABLE
> Date: March 26, 2021 at 10:25:17 AM PDT
> To: Lynne Bartholomew <[e-mail]>
> Cc: "Pascal Thubert \(pthubert\)" <[e-mail]>, Alvaro Retana <[e-mail]>, "jgs\@juniper.net" <[e-mail]>, "rahul.ietf\@gmail.com" <[e-mail]>, "martin.vigoureux\@nokia.com" <[e-mail]>, RFC System <[e-mail]>, "c310\@rfc-editor.org" <[e-mail]>
> 
> 
> I have looked over the latest patch to the U-flag, and it all looks correct
> to me.
> 
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 

> From: Lynne Bartholomew <[e-mail]>
> Subject: Re: AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-30.txt> NOW AVAILABLE
> Date: March 26, 2021 at 10:15:33 AM PDT
> To: Michael Richardson <[e-mail]>
> Cc: "Pascal Thubert \(pthubert\)" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Alvaro Retana <[e-mail]>, "[e-mail]" <[e-mail]>, RFC System <[e-mail]>
> 
> Hi, Michael.
> 
> Thank you for spotting those items!  I made further updates and reposted the files (no new iteration).
> 
> Please note that in addition to reverting the change in Section 9.2.2 per your note, I also reverted to "the External ('E') flag in the Transit Information Option (TIO)" in Section 3.  Please let me know if this is incorrect.
> 
> Please review, and let me know if I missed anything or if anything else is incorrect.  (You'll need to refresh your browser.)
> 
>   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-lastdiff.html
>   https://www.rfc-editor.org/authors/rfc9010-lastrfcdiff.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 26, 2021, at 9:33 AM, Michael Richardson <[e-mail]> wrote:
>> 
>> 
>> Lynne Bartholomew <[e-mail]> wrote:
>>> 1. changed what I *believe* to be the "E" flags in question to "U"
>> 
>>> 2. gone ahead and updated Sections 12.5 and 12.6 per your note further
>>> below (but using "U" instead of "E")
>> 
>> I might be suffering from the confusion that we are trying to reduce!
>> But, I think that we need to change the name of the flag in figure 6 and the
>> description too, right?
>> 
>>                           0 1 2 3 4 5 6 7
>>                             +-+-+-+-+-+-+-+-+
>>                             |E|A|StatusValue|
>>                             +-+-+-+-+-+-+-+-+
>> 
>>                       Figure 6: RPL Status Format
>> 
>>  This specification updates the RPL Status with the following
>>  subfields:
>> 
>>  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.
>> 
>> section 9.2.2:
>> 
>>  3.  The 6LR sets the External ('E')-> ('U') flag in the TIO to indicate that
>>      it is redistributing an external target into the RPL network.
>> 
>> I don't think that this replacement is correct.
>> 
>> I think that the rest of the updates are correct.
>> 
>> 
>> --
>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>>          Sandelman Software Works Inc, Ottawa and Worldwide
>> 
>> 

> From: Michael Richardson <[e-mail]>
> Subject: Re: *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-30.txt> NOW AVAILABLE
> Date: March 26, 2021 at 9:33:14 AM PDT
> To: Lynne Bartholomew <[e-mail]>
> Cc: "Pascal Thubert \(pthubert\)" <[e-mail]>, Alvaro Retana <[e-mail]>, "jgs\@juniper.net" <[e-mail]>, "rahul.ietf\@gmail.com" <[e-mail]>, "martin.vigoureux\@nokia.com" <[e-mail]>, RFC System <[e-mail]>, "c310\@rfc-editor.org" <[e-mail]>
> 
> 
> Lynne Bartholomew <[e-mail]> wrote:
>> 1. changed what I *believe* to be the "E" flags in question to "U"
> 
>> 2. gone ahead and updated Sections 12.5 and 12.6 per your note further
>> below (but using "U" instead of "E")
> 
> I might be suffering from the confusion that we are trying to reduce!
> But, I think that we need to change the name of the flag in figure 6 and the
> description too, right?
> 
>                            0 1 2 3 4 5 6 7
>                              +-+-+-+-+-+-+-+-+
>                              |E|A|StatusValue|
>                              +-+-+-+-+-+-+-+-+
> 
>                        Figure 6: RPL Status Format
> 
>   This specification updates the RPL Status with the following
>   subfields:
> 
>   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.
> 
> section 9.2.2:
> 
>   3.  The 6LR sets the External ('E')-> ('U') flag in the TIO to indicate that
>       it is redistributing an external target into the RPL network.
> 
> I don't think that this replacement is correct.
> 
> I think that the rest of the updates are correct.
> 
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 

> From: Lynne Bartholomew <[e-mail]>
> Subject: Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-30.txt> NOW AVAILABLE
> Date: March 26, 2021 at 8:57:49 AM PDT
> To: Alvaro Retana <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, RFC System <[e-mail]>, "[e-mail]" <[e-mail]>, [e-mail]
> 
> Hi, Alvaro.
> 
> We have noted your approval on the AUTH48 status page:
> 
>   https://www.rfc-editor.org/auth48/rfc9010
> 
> Thank you!
> 
> RFC Editor/lb
> 
>> On Mar 25, 2021, at 2:56 PM, Alvaro Retana <[e-mail]> wrote:
>> 
>> On March 25, 2021 at 4:52:21 PM, Lynne Bartholomew wrote:
>> 
>>> * 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.
>> 
>> 
>> Hi Lynn!
>> 
>> I looked at the exchange, and the diffs, and this change is fine with me.
>> 
>> Thanks!
>> 
>> Alvaro.
>> 
> 
> -- 
> c310 mailing list
> [e-mail]
> https://www.rfc-editor.org/mailman/listinfo/c310

> From: Lynne Bartholomew <[e-mail]>
> Subject: Re: *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-30.txt> NOW AVAILABLE
> Date: March 26, 2021 at 8:52:39 AM PDT
> To: "Pascal Thubert (pthubert)" <[e-mail]>
> Cc: Michael Richardson <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Alvaro Retana <[e-mail]>, "[e-mail]" <[e-mail]>, RFC System <[e-mail]>
> 
> Hi, Pascal.
> 
> Apologies for my confusion.
> 
> For now, I have 
> 
> 1. changed what I *believe* to be the "E" flags in question to "U"
> 
> 2. gone ahead and updated Sections 12.5 and 12.6 per your note further below (but using "U" instead of "E")
> 
> 3. Left all quoting as is
> 
> Please review my updates carefully (for example, is "External ('U') flag" correct?), and let me know any issues.  If my updates are completely wrong, I can easily revert to the previous iteration and start over in this regard.
> 
> The latest files are posted here (you might need to refresh your browser):
> 
>   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-lastdiff.html
>   https://www.rfc-editor.org/authors/rfc9010-lastrfcdiff.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
> 
> Thank you very much for your patience.
> 
> Lynne
> 
> 
>> On Mar 25, 2021, at 11:20 PM, Pascal Thubert (pthubert) <[e-mail]> wrote:
>> 
>> Hello Lynne 
>> 
>> In fact I tried to use the quotes in the way the original draft that defines the flag uses them. I thought that was better that way. Since you commented I was ok to change but I like it better if we conserve the form of the origin draft.
>> 
>> This quote game helps discriminate the flags called E but that’s imperfect. I do not think we should go farther on that path. I believe that the text should remove all ambiguity regardless of quotes.
>> 
>> Sorry for G I proposal didn’t look that deep. I’m primarily concerned with the consistency within this document; so the fact that it exists I. A reference hurts less; anyway any letter would do and I’d happy with another one, say U or V.
>> 
>> If E remains we have to review all cases to ensure there’s never an ambiguity. I believe we are OK with the preexisting E flags from other RFCs, but not necessarily with the EARO. In case of slightest uncertainty,  instead of saying ‘the E flag’ we must say ‘the E flag in the EARO’. I found several cases of that.
>> 
>> My preference is to change the letter.
>> 
>> Keep safe!
>> 
>> Pascal 
>> 
>>> Le 25 mars 2021 à 21:52, Lynne Bartholomew <[e-mail]> a écrit :
>>> 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
>