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

[Pascal Thubert <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
>> Sent: vendredi 2 avril 2021 18:37
>> To: Pascal Thubert <[e-mail]>; Zhen Cao
>> <[e-mail]>
>> Cc: Pascal Thubert (pthubert) <[e-mail]>; rabi narayan sahoo
>> <[e-mail]>; Alvaro Retana <[e-mail]>;
>> Rahul Jadhav <[e-mail]>; dominique barthel
>> <[e-mail]>; Ines Robles
>> <[e-mail]>; Vigoureux, Martin (Nokia - FR/Paris-
>> Saclay) <[e-mail]>; peter van der Stok
>> <[e-mail]>; John Scudder <[e-mail]>; c310@rfc-
>> editor.org; RFC System <[e-mail]>
>> 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 <[e-mail]> 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 <[e-mail]>
>> 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 <[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].
>>>>>>>>> com>)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 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>
>>>>>> 
>>>> 
> 
> -- 
> c310 mailing list
> [e-mail]
> https://www.rfc-editor.org/mailman/listinfo/c310