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

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