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

Hi, Pascal.  Great!  Wishing you a good weekend, too, and thank you again!

RFC Editor/lb

> On Apr 2, 2021, at 12:55 PM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> 
> I’m all good now, Lynne.
> 
> Looking forward to seeing the RFCs show up!
> 
> Tons of thanks, enjoy the weekend 😊
> 
> Pascal
> 
>> Le 2 avr. 2021 à 21:45, Lynne Bartholomew <lbartholomew@amsl.com> a écrit :
>> 
>> Hi, Pascal.
>> 
>> Apologies.  The latest files are posted here; please let me know if anything is still incorrect:
>> 
>>  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 for your patience!
>> 
>> RFC Editor/lb
>> 
>> 
>>> On Apr 2, 2021, at 10:52 AM, Pascal Thubert <pascal.thubert@gmail.com> wrote:
>>> 
>>> Hello Lynne
>>> 
>>> I refreshed and still see
>>> 
>>> 
>>> DAO from another child node with a newer Path Sequence for the target that is the same or newer, in which case the DCO transmission is canceled.
>>> 
>>> The first instance of newer above was to go away
>>> 
>>> A bientôt;
>>> 
>>> Pascal
>>> 
>>>>> Le 2 avr. 2021 à 18:48, Pascal Thubert (pthubert) via c310 <c310@rfc-editor.org> a écrit :
>>>> 
>>>> Almost, Lynne!
>>>> 
>>>> One sentence turned vinegar:
>>>> 
>>>> OLD
>>>> for instance, as a delayed response to receiving a regular DAO from another child node with a newer Path Sequence for the target that is the same or newer
>>>> 
>>>> should be
>>>> NEW
>>>> for instance, as a delayed response to receiving a regular DAO from another child node with a Path Sequence for the target that is the same or newer
>>>> 
>>>> 
>>>> and that one can be simplified
>>>> 
>>>> OLD
>>>> If the stored Path Sequence is more fresh, i.e., as new as or newer than the Path Sequence received in the DCO, then the DCO MUST be dropped.
>>>> 
>>>> 
>>>> should be
>>>> NEW
>>>> If the stored Path Sequence is as new as or newer than the Path Sequence received in the DCO, then the DCO MUST be dropped.
>>>> 
>>>> Other than that I'm all good!
>>>> 
>>>> Keep safe;
>>>> 
>>>> Pascal
>>>> 
>>>>> -----Original Message-----
>>>>> From: Lynne Bartholomew <lbartholomew@amsl.com>
>>>>> Sent: vendredi 2 avril 2021 18:37
>>>>> To: Pascal Thubert <pascal.thubert@gmail.com>; Zhen Cao
>>>>> <zhencao.ietf@gmail.com>
>>>>> Cc: Pascal Thubert (pthubert) <pthubert@cisco.com>; rabi narayan sahoo
>>>>> <rabinarayans0828@gmail.com>; Alvaro Retana <aretana.ietf@gmail.com>;
>>>>> Rahul Jadhav <rahul.ietf@gmail.com>; dominique barthel
>>>>> <dominique.barthel@orange.com>; Ines Robles
>>>>> <mariainesrobles@googlemail.com>; Vigoureux, Martin (Nokia - FR/Paris-
>>>>> Saclay) <martin.vigoureux@nokia.com>; peter van der Stok
>>>>> <consultancy@vanderstok.org>; John Scudder <jgs@juniper.net>; c310@rfc-
>>>>> editor.org; RFC System <rfc-editor@rfc-editor.org>
>>>>> Subject: Re: AUTH48 [LB]: RFC 9009 <draft-ietf-roll-efficient-npdao-
>>>>> 18.txt> NOW AVAILABLE
>>>>> 
>>>>> Hi, Pascal and Zhen.
>>>>> 
>>>>> Pascal, we have updated Sections 4.1 and 4.4 per your notes below.  Please
>>>>> refresh your browser to view the latest, and please confirm that
>>>>> everything is now OK.  After we get your OK, we can prepare this document
>>>>> and RFC 9010 for publication, as we now have all approvals for both
>>>>> documents:
>>>>> 
>>>>> 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
>>>>> 
>>>>> Zhen, we have noted your approval on the AUTH48 status page:
>>>>> 
>>>>> https://www.rfc-editor.org/auth48/rfc9009
>>>>> 
>>>>> Thank you!
>>>>> 
>>>>> RFC Editor/lb
>>>>> 
>>>>>> On Apr 1, 2021, at 10:01 PM, Zhen Cao <zhencao.ietf@gmail.com> wrote:
>>>>>> 
>>>>>> Hi Lynne and all,
>>>>>> 
>>>>>> Thank you so much for the hard work.  I approve the publication of this
>>>>> document.
>>>>>> 
>>>>>> Best regards,
>>>>>> Zhen
>>>>> 
>>>>> 
>>>>>> On Apr 1, 2021, at 9:05 PM, Pascal Thubert <pascal.thubert@gmail.com>
>>>>> wrote:
>>>>>> 
>>>>>> 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 <lbartholomew@amsl.com> 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)
>>>>> <pthubert@cisco.com> 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 <lbartholomew@amsl.com> 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)
>>>>> <pthubert@cisco.com> 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
>>>>> <rabinarayans0828@gmail.com> 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,
>>>>> <lbartholomew@amsl.com> 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
>>>>> <aretana.ietf@gmail.com> 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)
>>>>> (pthubert@cisco.com) wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Hello Lynne
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Le 31 mars 2021 à 00:04, Alvaro Retana <aretana.ietf@gmail.com>
>>>>> 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 <rahul.ietf@gmail.com>
>>>>>>>>>>>> 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)" <pthubert@cisco.com>
>>>>>>>>>>>> Cc: Lynne Bartholomew <lbartholomew@amsl.com>, Alvaro Retana
>>>>>>>>>>>> <aretana.ietf@gmail.com>, Pascal Thubert
>>>>>>>>>>>> <pascal.thubert@gmail.com>, Zhen Cao <zhencao.ietf@gmail.com>,
>>>>>>>>>>>> peter van der Stok <consultancy@vanderstok.org>, dominique
>>>>>>>>>>>> barthel <dominique.barthel@orange.com>, Ines Robles
>>>>>>>>>>>> <mariainesrobles@googlemail.com>, John Scudder
>>>>>>>>>>>> <jgs@juniper.net>, "c310@rfc-editor.org" <c310@rfc-editor.org>,
>>>>>>>>>>>> "Vigoureux, Martin (Nokia - FR/Paris-Saclay)"
>>>>>>>>>>>> <martin.vigoureux@nokia.com>, RFC System
>>>>>>>>>>>> <rfc-editor@rfc-editor.org>, rabi narayan sahoo
>>>>>>>>>>>> <rabinarayans0828@gmail.com>
>>>>>>>>>>>> 
>>>>>>>>>>>> Yes, I approve the publication of the draft.
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Rahul
>>>>>>>>>>>> 
>>>>>>>>>>>> On Wed, 31 Mar 2021 at 19:01, Pascal Thubert (pthubert)
>>>>> <pthubert@cisco.com> 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 <rahul.ietf@gmail.com>
>>>>>>>>>>>> Sent: mercredi 31 mars 2021 15:09
>>>>>>>>>>>> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
>>>>>>>>>>>> Cc: Lynne Bartholomew <lbartholomew@amsl.com>; Alvaro Retana
>>>>>>>>>>>> <aretana.ietf@gmail.com>; Pascal Thubert
>>>>>>>>>>>> <pascal.thubert@gmail.com>; Zhen Cao <zhencao.ietf@gmail.com>;
>>>>>>>>>>>> peter van der Stok <consultancy@vanderstok.org>; dominique
>>>>>>>>>>>> barthel <dominique.barthel@orange.com>; Ines Robles
>>>>>>>>>>>> <mariainesrobles@googlemail.com>; John Scudder
>>>>>>>>>>>> <jgs@juniper.net>; c310@rfc-editor.org; Vigoureux, Martin (Nokia
>>>>>>>>>>>> - FR/Paris-Saclay) <martin.vigoureux@nokia.com>; RFC System
>>>>>>>>>>>> <rfc-editor@rfc-editor.org>; rabi narayan sahoo
>>>>>>>>>>>> <rabinarayans0828@gmail.com>
>>>>>>>>>>>> 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)
>>>>> <pthubert@cisco.com> 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 <rahul.ietf@gmail.com>
>>>>>>>>>>>> Sent: mercredi 31 mars 2021 13:40
>>>>>>>>>>>> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
>>>>>>>>>>>> Cc: Lynne Bartholomew <lbartholomew@amsl.com>; Alvaro Retana
>>>>>>>>>>>> <aretana.ietf@gmail.com>; Pascal Thubert
>>>>>>>>>>>> <pascal.thubert@gmail.com>; Zhen Cao <zhencao.ietf@gmail.com>;
>>>>>>>>>>>> peter van der Stok <consultancy@vanderstok.org>; dominique
>>>>>>>>>>>> barthel <dominique.barthel@orange.com>; Ines Robles
>>>>>>>>>>>> <mariainesrobles@googlemail.com>; John Scudder
>>>>>>>>>>>> <jgs@juniper.net>; c310@rfc-editor.org; Vigoureux, Martin (Nokia
>>>>>>>>>>>> - FR/Paris-Saclay) <martin.vigoureux@nokia.com>; RFC System
>>>>>>>>>>>> <rfc-editor@rfc-editor.org>; rabi narayan sahoo
>>>>>>>>>>>> <rabinarayans0828@gmail.com>
>>>>>>>>>>>> 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)
>>>>> <pthubert@cisco.com> wrote:
>>>>>>>>>>>> Hello Lynne
>>>>>>>>>>>> 
>>>>>>>>>>>>> Le 30 mars 2021 à 23:44, Lynne Bartholomew
>>>>> <lbartholomew@amsl.com> 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 <aretana.ietf@gmail.com>
>>>>>>>>>>>> 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 <rahul.ietf@gmail.com>, Lynne Bartholomew
>>>>>>>>>>>> <lbartholomew@amsl.com>, "Pascal Thubert (pthubert)"
>>>>>>>>>>>> <pthubert@cisco.com>
>>>>>>>>>>>> Cc: Pascal Thubert <pascal.thubert@gmail.com>, Ines Robles
>>>>>>>>>>>> <mariainesrobles@googlemail.com>, RFC System
>>>>>>>>>>>> <rfc-editor@rfc-editor.org>, "c310@rfc-editor.org"
>>>>>>>>>>>> <c310@rfc-editor.org>, Zhen Cao <zhencao.ietf@gmail.com>,
>>>>>>>>>>>> "Vigoureux, Martin (Nokia - FR/Paris-Saclay)"
>>>>>>>>>>>> <martin.vigoureux@nokia.com>, peter van der Stok
>>>>>>>>>>>> <consultancy@vanderstok.org>, dominique barthel
>>>>>>>>>>>> <dominique.barthel@orange.com>, rabi narayan sahoo
>>>>>>>>>>>> <rabinarayans0828@gmail.com>, John Scudder <jgs@juniper.net>
>>>>>>>>>>>> 
>>>>>>>>>>>> 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:
>>>>>>>>>>>> <CAMMESsw+GjG9Um0H_xoebza9t8gsX7yxv9AJWwGCAJ361PWCeQ@mail.gmail.
>>>>>>>>>>>> com>)
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>> 
>>>>>>>>>>>> Alvaro.
>>>>>>>>>>>> On March 30, 2021 at 5:57:52 PM, Lynne Bartholomew
>>>>> (lbartholomew@amsl.com) 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
>>>>> <lbartholomew@amsl.com> 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 <aretana.ietf@gmail.com>
>>>>>>>>>>>> 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 <rahul.ietf@gmail.com>, Lynne Bartholomew
>>>>>>>>>>>> <lbartholomew@amsl.com>, "Pascal Thubert (pthubert)"
>>>>>>>>>>>> <pthubert@cisco.com>
>>>>>>>>>>>> Cc: Pascal Thubert <pascal.thubert@gmail.com>, dominique barthel
>>>>>>>>>>>> <dominique.barthel@orange.com>, rabi narayan sahoo
>>>>>>>>>>>> <rabinarayans0828@gmail.com>, RFC System
>>>>>>>>>>>> <rfc-editor@rfc-editor.org>, c310@rfc-editor.org, Zhen Cao
>>>>>>>>>>>> <zhencao.ietf@gmail.com>, "Vigoureux, Martin (Nokia -
>>>>>>>>>>>> FR/Paris-Saclay)" <martin.vigoureux@nokia.com>, Ines Robles
>>>>>>>>>>>> <mariainesrobles@googlemail.com>, peter van der Stok
>>>>>>>>>>>> <consultancy@vanderstok.org>, John Scudder <jgs@juniper.net>,
>>>>>>>>>>>> rabinarayans@huawei.com
>>>>>>>>>>>> 
>>>>>>>>>>>> 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>
>>>>>>>>> 
>>>>>>> 
>>>> 
>>>> -- 
>>>> c310 mailing list
>>>> c310@rfc-editor.org
>>>> https://www.rfc-editor.org/mailman/listinfo/c310
>> 