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

[Lynne Bartholomew <[e-mail]>]

Hi, Pascal and Michael.

Pascal, we have made additional updates to this document per your notes below.

As relates to this note from you --

> Root -> root or "DODAG root" as you feel best. Please do not change the P flag definition that would impact IANA.

-- please review our updates carefully (we went with "root"), and let us know if anything is incorrect.

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-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

Pascal, we have noted your approval on the AUTH48 status page:

  https://www.rfc-editor.org/auth48/rfc9010

Thank you!

RFC Editor/lb


> On Mar 26, 2021, at 10:28 AM, Pascal Thubert (pthubert) <[e-mail]> wrote:
> 
> 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


> 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

> 
>> -----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
>>> 
>>> 
>>> 
>>> 
>