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

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
> 