Re: [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll-efficient-npdao-18.txt> NOW AVAILABLE

[Pascal Thubert <[e-mail]>]

No worries Lynne!

On the contrary reviewing you changes forced me to give a second look at the text. I now I’m finding bugs!

Point is the DAO coming from below and the DCO coming from below may meet with the same sequence number. In that case the DAO wins. This is a case where none is newer. They are as new.

In the text here

Sequence is more fresh, i.e., more current newer than the Path Sequence received in the DCO,

We need to say ‘as new or newer’ since we are referring to the DAO state. Or we can turn the sentence and say ‘ if the DCO is not newer’ as we do elsewhere.
Similarly in
node with a current newer Path Sequence for the target.
It is better to say

node with a Path Sequence for the target that is the same or newer, in which case the DCO transmission is canceled.

Many thanks !

Pascal

> Le 1 avr. 2021 à 23:20, Lynne Bartholomew <[e-mail]> a écrit :
> 
> Hi, Pascal.  Apologies again -- we have corrected the document and reposted:
> 
>   https://www.rfc-editor.org/authors/rfc9009.txt
>   https://www.rfc-editor.org/authors/rfc9009.pdf
>   https://www.rfc-editor.org/authors/rfc9009.html
>   https://www.rfc-editor.org/authors/rfc9009.xml
>   https://www.rfc-editor.org/authors/rfc9009-diff.html
>   https://www.rfc-editor.org/authors/rfc9009-auth48diff.html
>   https://www.rfc-editor.org/authors/rfc9009-lastdiff.html
>   https://www.rfc-editor.org/authors/rfc9009-lastrfcdiff.html
> 
>   https://www.rfc-editor.org/authors/rfc9009-xmldiff1.html
>   https://www.rfc-editor.org/authors/rfc9009-xmldiff2.html
> 
> Thank you!
> 
> RFC Editor/lb
> 
>> On Apr 1, 2021, at 2:09 PM, Pascal Thubert (pthubert) <[e-mail]> wrote:
>> 
>> Hello Lynne 
>> 
>> Oups, It was not meant to change newer to current throughout but just in one instance!
>> The instance was 
>> 
>> then the 6LRMUST NOT remove its current routing state, 
>> 
>> 
>> 
>> Regards,
>> 
>> Pascal
>> 
>>>> Le 1 avr. 2021 à 22:57, Lynne Bartholomew <[e-mail]> a écrit :
>>> 
>>> Hi, Pascal and Rabi.
>>> 
>>> Rabi, we have noted your approval on the AUTH48 status page:
>>> 
>>>  https://www.rfc-editor.org/auth48/rfc9009
>>> 
>>> Pascal, our apologies.  We have changed "newer" to "current" throughout.  Please review, and let us know if we were only supposed to change some of them:
>>> 
>>>  https://www.rfc-editor.org/authors/rfc9009.txt
>>>  https://www.rfc-editor.org/authors/rfc9009.pdf
>>>  https://www.rfc-editor.org/authors/rfc9009.html
>>>  https://www.rfc-editor.org/authors/rfc9009.xml
>>>  https://www.rfc-editor.org/authors/rfc9009-diff.html
>>>  https://www.rfc-editor.org/authors/rfc9009-auth48diff.html
>>>  https://www.rfc-editor.org/authors/rfc9009-lastdiff.html
>>>  https://www.rfc-editor.org/authors/rfc9009-lastrfcdiff.html
>>> 
>>>  https://www.rfc-editor.org/authors/rfc9009-xmldiff1.html
>>>  https://www.rfc-editor.org/authors/rfc9009-xmldiff2.html
>>> 
>>> Thank you.
>>> 
>>> RFC Editor/lb
>>> 
>>> 
>>>> On Apr 1, 2021, at 11:06 AM, Pascal Thubert (pthubert) <[e-mail]> wrote:
>>>> 
>>>> Hello Lynne
>>>> 
>>>> Please apply Alvaro’s proposal and change newer to current. It is actually more correct since the current state can be either newer or as new.
>>>> 
>>>> I believe that the 240 is correct and that Rahul agreed.
>>>> 
>>>> Rahul: we are missing the approval from the other authors. Could you please contact them?
>>>> 
>>>> Regards,
>>>> 
>>>> Pascal
>>>> 
>>>>> Le 1 avr. 2021 à 19:32, rabi narayan sahoo <[e-mail]> a écrit :
>>>>> 
>>>>> 
>>>>> Hi Lynne
>>>>> I approve publication of this draft .
>>>>> Sorry for the late reply.
>>>>> 
>>>>> Thanks
>>>>> Rabi
>>>>> 
>>>>> On Thu, 1 Apr 2021, 22:53 Lynne Bartholomew, <[e-mail]> wrote:
>>>>> Hi, Alvaro, Pascal, and Rahul.
>>>>> 
>>>>> Alvaro, thank you for both approvals.  Apologies for missing your 24 March approval earlier; we have copied it to the bottom of this thread for record-keeping purposes.
>>>>> 
>>>>> Rahul, thank you for the screenshot.  We updated Section 4.1 accordingly.
>>>>> 
>>>>> Pascal, we changed "with in" to "in" per your note below.
>>>>> 
>>>>> It appears that these two changes are the only changes that are needed, but please let us know if we missed anything in the latest emails (e.g., it appears that no changes are needed re. the "240" and "newer versus current" discussions).
>>>>> 
>>>>> The latest files are posted here:
>>>>> 
>>>>>  https://www.rfc-editor.org/authors/rfc9009.txt
>>>>>  https://www.rfc-editor.org/authors/rfc9009.pdf
>>>>>  https://www.rfc-in editor.org/authors/rfc9009.html
>>>>>  https://www.rfc-editor.org/authors/rfc9009.xml
>>>>>  https://www.rfc-editor.org/authors/rfc9009-diff.html
>>>>>  https://www.rfc-editor.org/authors/rfc9009-auth48diff.html
>>>>>  https://www.rfc-editor.org/authors/rfc9009-lastdiff.html
>>>>>  https://www.rfc-editor.org/authors/rfc9009-lastrfcdiff.html
>>>>> 
>>>>>  https://www.rfc-editor.org/authors/rfc9009-xmldiff1.html
>>>>>  https://www.rfc-editor.org/authors/rfc9009-xmldiff2.html
>>>>> 
>>>>> We have noted all approvals on the AUTH48 status page:
>>>>> 
>>>>>  https://www.rfc-editor.org/auth48/rfc9009
>>>>> 
>>>>> 
>>>>> After we receive approvals from Rabi and Zhen, we can move this document forward for publication.
>>>>> 
>>>>> 
>>>>> We have all approvals for RFCs 9008 and 9010:
>>>>> 
>>>>>  https://www.rfc-editor.org/auth48/rfc9008
>>>>> 
>>>>>  https://www.rfc-editor.org/auth48/rfc9010
>>>>> 
>>>>> 
>>>>> Many thanks for your help with this document!
>>>>> 
>>>>> RFC Editor/lb
>>>>> 
>>>>> 
>>>>>> On Mar 31, 2021, at 12:07 PM, Alvaro Retana <[e-mail]> wrote:
>>>>>> 
>>>>>> Ah, yes.  Then the original text is ok with me. :-)
>>>>>> 
>>>>>> Thanks!
>>>>>> 
>>>>>> Alvaro.
>>>>>> 
>>>>>> On March 31, 2021 at 1:05:42 AM, Pascal Thubert (pthubert) ([e-mail]) wrote:
>>>>>> 
>>>>>>> Hello Lynne  
>>>>>>> 
>>>>>>> 
>>>>>>>> Le 31 mars 2021 à 00:04, Alvaro Retana <[e-mail]> a écrit : 
>>>>>>>> 
>>>>>>>> On March 30, 2021 at 5:44:32 PM, Lynne Bartholomew wrote: 
>>>>>>>> 
>>>>>>>>> * Alvaro, please review the latest round of updates, and let us know if you 
>>>>>>>>> approve. These updates include some additional "RFC 2119" terminology ("MUST 
>>>>>>>>> NOT"s in Section 4.3.3). 
>>>>>>>> 
>>>>>>>> Hi! 
>>>>>>>> 
>>>>>>>> The updates in 4.3.3 are ok...except for the part that says "MUST NOT 
>>>>>>>> remove its newer routing state". I know what the intent is, but the 
>>>>>>>> use of "newer" here sounds confusing to me. I think that simply 
>>>>>>>> saying "MUST NOT remove its (current) routing state" is clearer. 
>>>>>>>> Pascal?? 
>>>>>>> 
>>>>>>> Hello Alvaro  
>>>>>>> 
>>>>>>> ´newer’ is RFC6550 terminology to indicate a result of the special lollipop comparison in section 7.2.  
>>>>>>> 
>>>>>>> If it is clear that the current is newer from the previous sentence then I’m good with your proposal. 
>>>>>>> 
>>>>>>> Many thanks ! 
>>>>>>> 
>>>>>>> Pascal  
>>>>>>>> 
>>>>>>>> Alvaro.
>>>>> 
>>>>>> From: Rahul Jadhav <[e-mail]>
>>>>>> Subject: Re: *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9009 <draft-ietf-roll-efficient-npdao-18.txt> NOW AVAILABLE
>>>>>> Date: March 31, 2021 at 6:33:41 AM PDT
>>>>>> To: "Pascal Thubert (pthubert)" <[e-mail]>
>>>>>> Cc: Lynne Bartholomew <[e-mail]>, Alvaro Retana <[e-mail]>, Pascal Thubert <[e-mail]>, Zhen Cao <[e-mail]>, peter van der Stok <[e-mail]>, dominique barthel <[e-mail]>, Ines Robles <[e-mail]>, John Scudder <[e-mail]>, "[e-mail]" <[e-mail]>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[e-mail]>, RFC System <[e-mail]>, rabi narayan sahoo <[e-mail]>
>>>>>> 
>>>>>> Yes, I approve the publication of the draft.
>>>>>> 
>>>>>> Thanks,
>>>>>> Rahul
>>>>>> 
>>>>>> On Wed, 31 Mar 2021 at 19:01, Pascal Thubert (pthubert) <[e-mail]> wrote:
>>>>>> You’re fully correct and that is the intent, Rahul. A new path may have formed and be in its straight part, and using 240 will not break it. If the common parent is already aware of the new path sequence, it can use it. 240 is for the blind reset situation.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Do I read that you approve the publication of the draft? You need to indicate it formally to Lynne so we unlock the 3 RFCs 😊
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Pascal
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> From: Rahul Jadhav <[e-mail]> 
>>>>>> Sent: mercredi 31 mars 2021 15:09
>>>>>> To: Pascal Thubert (pthubert) <[e-mail]>
>>>>>> Cc: Lynne Bartholomew <[e-mail]>; Alvaro Retana <[e-mail]>; Pascal Thubert <[e-mail]>; Zhen Cao <[e-mail]>; peter van der Stok <[e-mail]>; dominique barthel <[e-mail]>; Ines Robles <[e-mail]>; John Scudder <[e-mail]>; [e-mail]; Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[e-mail]>; RFC System <[e-mail]>; rabi narayan sahoo <[e-mail]>
>>>>>> Subject: Re: *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9009 <draft-ietf-roll-efficient-npdao-18.txt> NOW AVAILABLE
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> I think you are right that it will be able to clean up in "most cases" regardless of path sequence.
>>>>>> 
>>>>>> Just to clarify, the path won't be cleared even with Path Sequence = 240 if the lollipop counter has not entered into the circular region.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> I am good to go with these changes.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> @Lynne Bartholomew, many thanks for the editorial fixes. One small typo fix in Section 4.1. Attached is the screenshot.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Rahul
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Wed, 31 Mar 2021 at 17:27, Pascal Thubert (pthubert) <[e-mail]> wrote:
>>>>>> 
>>>>>> Hello Rahul
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> I believe it is a good protection to be able to say clean up regardless of path sequence. You always need a way to reset when things get out of sync; say for instance that a router is lost the comparison in the lollipop algorithm. It will not find that the current path sequence is newer. You still need to clean it up.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> I’m sure new usages of the 240 value will appear.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Keep safe;
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Pascal
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> From: Rahul Jadhav <[e-mail]> 
>>>>>> Sent: mercredi 31 mars 2021 13:40
>>>>>> To: Pascal Thubert (pthubert) <[e-mail]>
>>>>>> Cc: Lynne Bartholomew <[e-mail]>; Alvaro Retana <[e-mail]>; Pascal Thubert <[e-mail]>; Zhen Cao <[e-mail]>; peter van der Stok <[e-mail]>; dominique barthel <[e-mail]>; Ines Robles <[e-mail]>; John Scudder <[e-mail]>; [e-mail]; Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[e-mail]>; RFC System <[e-mail]>; rabi narayan sahoo <[e-mail]>
>>>>>> Subject: Re: *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9009 <draft-ietf-roll-efficient-npdao-18.txt> NOW AVAILABLE
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Many thanks Pascal for the updates.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Mostly I am in sync except for one change in the following para (section 4.5).
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ---
>>>>>> 
>>>>>>  A DCO that is generated asynchronously to a DAO message and is meant
>>>>>>  to discard all state along the path regardless of the Path Sequence
>>>>>>  MUST use a Path Sequence value of 240 (see Section 7.2 of [RFC6550]).
>>>>>>  This value allows the DCO to win against any established DAO path but
>>>>>>  to lose against a DAO path that is being installed.  Note that if an
>>>>>>  ancestor initiates a unilateral path cleanup on an established path 
>>>>>>  using a DCO with a Path Sequence value of 240, the DCO will 
>>>>>>  eventually reach the target node, which will thus be informed of the
>>>>>>  path invalidation.
>>>>>> 
>>>>>> ---
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> The intention to send an async DCO was to clear out an already established path. Thus anyone who is originating an async DCO has the latest Path Sequence to use. I am not clear if we should mandate using 240 as the Path Sequence here.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> Rahul
>>>>>> 
>>>>>> On Wed, 31 Mar 2021 at 10:42, Pascal Thubert (pthubert) <[e-mail]> wrote:
>>>>>> Hello Lynne 
>>>>>> 
>>>>>>> Le 30 mars 2021 à 23:44, Lynne Bartholomew <[e-mail]> a écrit :
>>>>>>> 
>>>>>>> Hi, Pascal, Rahul, and *Alvaro.
>>>>>>> 
>>>>>>> * Alvaro, please review the latest round of updates, and let us know if you approve.  These updates include some additional "RFC 2119" terminology ("MUST NOT"s in Section 4.3.3).
>>>>>>> 
>>>>>>> Pascal and Rahul, thank you for the updated XML files.
>>>>>>> 
>>>>>>> Please note that we made some further updates to the latest copy.  Please see <https://www.rfc-editor.org/authors/rfc9009-30Mar2021-further-updates-rfcdiff.html>, and let us know any concerns.
>>>>>>> 
>>>>>>> For example:
>>>>>>> 
>>>>>>> * We implemented the third and fourth "[RJ]" updates as listed below.
>>>>>>> * "TIO" was not used in this document previously.  We changed "TIO" to "Transit Information option".
>>>>>>> * "node" is lowercased, except for node names, so we changed "LLN Node" to "LLN node" and "node C" to "Node C".
>>>>>>> * We changed "next-hop" to "next hop" where used as a noun.
>>>>>>> 
>>>>>> I’m good with this all.
>>>>>> 
>>>>>> Please note that I approve the publication of the draft as it now stands.
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> Another question for you:  Should "indicated with in the DAO" be "indicated within the DAO", "indicated in the DAO", or something else?
>>>>>>> 
>>>>>> 
>>>>>> Either ´in’ or ´within’ works for me.
>>>>>> 
>>>>>> 
>>>>>> Please note that I approve the publication of the draft as it stands, the above assumed fixed.
>>>>>> 
>>>>>> Many thanks !
>>>>>> 
>>>>>> Pascal 
>>>>>> 
>>>>> 
>>>>>> From: Alvaro Retana <[e-mail]>
>>>>>> Subject: Re: *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9009 <draft-ietf-roll-efficient-npdao-18.txt> NOW AVAILABLE
>>>>>> Date: March 30, 2021 at 3:07:22 PM PDT
>>>>>> To: Rahul Jadhav <[e-mail]>, Lynne Bartholomew <[e-mail]>, "Pascal Thubert (pthubert)" <[e-mail]>
>>>>>> Cc: Pascal Thubert <[e-mail]>, Ines Robles <[e-mail]>, RFC System <[e-mail]>, "[e-mail]" <[e-mail]>, Zhen Cao <[e-mail]>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[e-mail]>, peter van der Stok <[e-mail]>, dominique barthel <[e-mail]>, rabi narayan sahoo <[e-mail]>, John Scudder <[e-mail]>
>>>>>> 
>>>>>> Lynne:
>>>>>> 
>>>>>> Hi!
>>>>>> 
>>>>>> This is approved too.
>>>>>> 
>>>>>> 
>>>>>> I did send a response on Mar/24…which doesn’t mean that it got to the destination. :-)
>>>>>> (Message-Id: <[e-mail]>)
>>>>>> 
>>>>>> 
>>>>>> Thanks!
>>>>>> 
>>>>>> Alvaro.
>>>>>> On March 30, 2021 at 5:57:52 PM, Lynne Bartholomew ([e-mail]) wrote:
>>>>>> 
>>>>>>> Hello again. We don't want to lose track of this earlier approval request for Alvaro (apologies if we missed an approval email; we couldn't find one): 
>>>>>>> 
>>>>>>>>> On Mar 24, 2021, at 2:16 PM, Lynne Bartholomew <[e-mail]> wrote: 
>>>>>>>>> 
>>>>>>>>> Dear Pascal, Rahul, and *AD (Alvaro), 
>>>>>>>>> 
>>>>>>>>> Pascal and Rahul, thank you for your prompt replies! Rahul, many thanks also for your work and the updated XML file. 
>>>>>>>>> 
>>>>>>>>> * Alvaro, please let us know if you approve the removal of the "New Registry for the Destination Cleanup Object Acknowledgment (DCO-ACK) Status Field" section -- apparently, the information listed there should all be found in companion document RFC 9010, as can mostly be seen on <https://www.iana.org/assignments/rpl/>. 
>>>>>>> 
>>>>>>> 
>>>>>>> Thank you! 
>>>>>>> 
>>>>>>> RFC Editor/lb 
>>>>> 
>>>>>> From: Alvaro Retana <[e-mail]>
>>>>>> Subject: Re: *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9009 <draft-ietf-roll-efficient-npdao-18.txt> NOW AVAILABLE
>>>>>> Date: March 24, 2021 at 3:01:00 PM PDT
>>>>>> To: Rahul Jadhav <[e-mail]>, Lynne Bartholomew <[e-mail]>, "Pascal Thubert (pthubert)" <[e-mail]>
>>>>>> Cc: Pascal Thubert <[e-mail]>, dominique barthel <[e-mail]>, rabi narayan sahoo <[e-mail]>, RFC System <[e-mail]>, [e-mail], Zhen Cao <[e-mail]>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[e-mail]>, Ines Robles <[e-mail]>, peter van der Stok <[e-mail]>, John Scudder <[e-mail]>, [e-mail]
>>>>>> 
>>>>>> On March 24, 2021 at 5:16:23 PM, Lynne Bartholomew wrote:
>>>>>> 
>>>>>> Hi!
>>>>>> 
>>>>>> Yes, this change is approved.
>>>>>> 
>>>>>> Thanks!
>>>>>> 
>>>>>> Alvaro.
>>>>>> 
>>>>>>> * Alvaro, please let us know if you approve the removal of the "New Registry
>>>>>>> for the Destination Cleanup Object Acknowledgment (DCO-ACK) Status Field"
>>>>>>> section -- apparently, the information listed there should all be found in
>>>>>>> companion document RFC 9010, as can mostly be seen on .
>>>>> 
>>>>> <image002.jpg>
>>> 
>