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

[Lynne Bartholomew <[e-mail]>]

Great!  Thank you, Amanda!

RFC Editor/lb

> On Apr 6, 2021, at 5:17 PM, Amanda Baber via RT <[e-mail]> wrote:
> 
> Hi Lynne, all,
> 
> These updates are complete:
> 
> On Mon Apr 05 23:03:28 2021, [e-mail] wrote:
>> 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]
> 
> Done:
> 
> https://www.iana.org/assignments/icmpv6-parameters
> 
>> 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]
> 
> Done:
> 
> https://www.iana.org/assignments/rpl
> 
> Best regards,
> 
> Amanda Baber
> Lead IANA Services Specialist
> 
>> Thank you.
>> 
>> RFC Editor/lb

>>> From: Lynne Bartholomew <[e-mail]>
>>> Subject: [IANA] Re: AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-30.txt> NOW AVAILABLE
>>> Date: April 5, 2021 at 4:03:10 PM PDT
>>> To: Amanda Baber via RT <[e-mail]>
>>> Cc: "Pascal Thubert \(pthubert\)" <[e-mail]>, 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]>
>>> 
>>> 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]" <c310@rfc-
>>> editor.org>
>>> 
>>> 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]" <c310@rfc-
>>> editor.org>
>>> 
>>> 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" <c310@rfc-
>>> editor.org>
>>> 
>>> 
>>> 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" <c310@rfc-
>>> editor.org>
>>> 
>>> 
>>> 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 <rfc-editor@rfc-
>>> editor.org>, "[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]>, "rfc-
>>>>>> [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]; c310@rfc-
>>>>>>> editor.org
>>>>>>> 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
>>> 
>