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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Lynne

Oups, It was not meant to change newer to current throughout but just in one instance!
The instance was

then the 6LRMUST NOT remove its current routing state,



Regards,

Pascal

Le 1 avr. 2021 à 22:57, Lynne Bartholomew <[e-mail]> a écrit :

Hi, Pascal and Rabi.

Rabi, we have noted your approval on the AUTH48 status page:

  https://www.rfc-editor.org/auth48/rfc9009

Pascal, our apologies.  We have changed "newer" to "current" throughout.  Please review, and let us know if we were only supposed to change some of them:

  https://www.rfc-editor.org/authors/rfc9009.txt
  https://www.rfc-editor.org/authors/rfc9009.pdf
  https://www.rfc-editor.org/authors/rfc9009.html
  https://www.rfc-editor.org/authors/rfc9009.xml
  https://www.rfc-editor.org/authors/rfc9009-diff.html
  https://www.rfc-editor.org/authors/rfc9009-auth48diff.html
  https://www.rfc-editor.org/authors/rfc9009-lastdiff.html
  https://www.rfc-editor.org/authors/rfc9009-lastrfcdiff.html

  https://www.rfc-editor.org/authors/rfc9009-xmldiff1.html
  https://www.rfc-editor.org/authors/rfc9009-xmldiff2.html

Thank you.

RFC Editor/lb


On Apr 1, 2021, at 11:06 AM, Pascal Thubert (pthubert) <[e-mail]> wrote:

Hello Lynne

Please apply Alvaro’s proposal and change newer to current. It is actually more correct since the current state can be either newer or as new.

I believe that the 240 is correct and that Rahul agreed.

Rahul: we are missing the approval from the other authors. Could you please contact them?

Regards,

Pascal

Le 1 avr. 2021 à 19:32, rabi narayan sahoo <[e-mail]> a écrit :


Hi Lynne
I approve publication of this draft .
Sorry for the late reply.

Thanks
Rabi

On Thu, 1 Apr 2021, 22:53 Lynne Bartholomew, <[e-mail]> wrote:
Hi, Alvaro, Pascal, and Rahul.

Alvaro, thank you for both approvals.  Apologies for missing your 24 March approval earlier; we have copied it to the bottom of this thread for record-keeping purposes.

Rahul, thank you for the screenshot.  We updated Section 4.1 accordingly.

Pascal, we changed "with in" to "in" per your note below.

It appears that these two changes are the only changes that are needed, but please let us know if we missed anything in the latest emails (e.g., it appears that no changes are needed re. the "240" and "newer versus current" discussions).

The latest files are posted here:

  https://www.rfc-editor.org/authors/rfc9009.txt
  https://www.rfc-editor.org/authors/rfc9009.pdf
  https://www.rfc-in editor.org/authors/rfc9009.html
  https://www.rfc-editor.org/authors/rfc9009.xml
  https://www.rfc-editor.org/authors/rfc9009-diff.html
  https://www.rfc-editor.org/authors/rfc9009-auth48diff.html
  https://www.rfc-editor.org/authors/rfc9009-lastdiff.html
  https://www.rfc-editor.org/authors/rfc9009-lastrfcdiff.html

  https://www.rfc-editor.org/authors/rfc9009-xmldiff1.html
  https://www.rfc-editor.org/authors/rfc9009-xmldiff2.html

We have noted all approvals on the AUTH48 status page:

  https://www.rfc-editor.org/auth48/rfc9009


After we receive approvals from Rabi and Zhen, we can move this document forward for publication.


We have all approvals for RFCs 9008 and 9010:

  https://www.rfc-editor.org/auth48/rfc9008

  https://www.rfc-editor.org/auth48/rfc9010


Many thanks for your help with this document!

RFC Editor/lb


On Mar 31, 2021, at 12:07 PM, Alvaro Retana <[e-mail]> wrote:

Ah, yes.  Then the original text is ok with me. :-)

Thanks!

Alvaro.

On March 31, 2021 at 1:05:42 AM, Pascal Thubert (pthubert) ([e-mail]) wrote:

Hello Lynne


Le 31 mars 2021 à 00:04, Alvaro Retana <[e-mail]> a écrit :

On March 30, 2021 at 5:44:32 PM, Lynne Bartholomew wrote:

* Alvaro, please review the latest round of updates, and let us know if you
approve. These updates include some additional "RFC 2119" terminology ("MUST
NOT"s in Section 4.3.3).

Hi!

The updates in 4.3.3 are ok...except for the part that says "MUST NOT
remove its newer routing state". I know what the intent is, but the
use of "newer" here sounds confusing to me. I think that simply
saying "MUST NOT remove its (current) routing state" is clearer.
Pascal??

Hello Alvaro

´newer’ is RFC6550 terminology to indicate a result of the special lollipop comparison in section 7.2.

If it is clear that the current is newer from the previous sentence then I’m good with your proposal.

Many thanks !

Pascal

Alvaro.

From: Rahul Jadhav <[e-mail]>
Subject: Re: *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9009 <draft-ietf-roll-efficient-npdao-18.txt> NOW AVAILABLE
Date: March 31, 2021 at 6:33:41 AM PDT
To: "Pascal Thubert (pthubert)" <[e-mail]>
Cc: Lynne Bartholomew <[e-mail]>, Alvaro Retana <[e-mail]>, Pascal Thubert <[e-mail]>, Zhen Cao <[e-mail]>, peter van der Stok <[e-mail]>, dominique barthel <[e-mail]>, Ines Robles <[e-mail]>, John Scudder <[e-mail]>, "[e-mail]" <[e-mail]>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[e-mail]>, RFC System <[e-mail]>, rabi narayan sahoo <[e-mail]>

Yes, I approve the publication of the draft.

Thanks,
Rahul

On Wed, 31 Mar 2021 at 19:01, Pascal Thubert (pthubert) <[e-mail]> wrote:
You’re fully correct and that is the intent, Rahul. A new path may have formed and be in its straight part, and using 240 will not break it. If the common parent is already aware of the new path sequence, it can use it. 240 is for the blind reset situation.



Do I read that you approve the publication of the draft? You need to indicate it formally to Lynne so we unlock the 3 RFCs 😊



Pascal



From: Rahul Jadhav <[e-mail]>
Sent: mercredi 31 mars 2021 15:09
To: Pascal Thubert (pthubert) <[e-mail]>
Cc: Lynne Bartholomew <[e-mail]>; Alvaro Retana <[e-mail]>; Pascal Thubert <[e-mail]>; Zhen Cao <[e-mail]>; peter van der Stok <[e-mail]>; dominique barthel <[e-mail]>; Ines Robles <[e-mail]>; John Scudder <[e-mail]>; [e-mail]; Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[e-mail]>; RFC System <[e-mail]>; rabi narayan sahoo <[e-mail]>
Subject: Re: *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9009 <draft-ietf-roll-efficient-npdao-18.txt> NOW AVAILABLE



I think you are right that it will be able to clean up in "most cases" regardless of path sequence.

Just to clarify, the path won't be cleared even with Path Sequence = 240 if the lollipop counter has not entered into the circular region.



I am good to go with these changes.



@Lynne Bartholomew, many thanks for the editorial fixes. One small typo fix in Section 4.1. Attached is the screenshot.





Thanks,

Rahul







On Wed, 31 Mar 2021 at 17:27, Pascal Thubert (pthubert) <[e-mail]> wrote:

Hello Rahul



I believe it is a good protection to be able to say clean up regardless of path sequence. You always need a way to reset when things get out of sync; say for instance that a router is lost the comparison in the lollipop algorithm. It will not find that the current path sequence is newer. You still need to clean it up.



I’m sure new usages of the 240 value will appear.



Keep safe;



Pascal



From: Rahul Jadhav <[e-mail]>
Sent: mercredi 31 mars 2021 13:40
To: Pascal Thubert (pthubert) <[e-mail]>
Cc: Lynne Bartholomew <[e-mail]>; Alvaro Retana <[e-mail]>; Pascal Thubert <[e-mail]>; Zhen Cao <[e-mail]>; peter van der Stok <[e-mail]>; dominique barthel <[e-mail]>; Ines Robles <[e-mail]>; John Scudder <[e-mail]>; [e-mail]; Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[e-mail]>; RFC System <[e-mail]>; rabi narayan sahoo <[e-mail]>
Subject: Re: *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9009 <draft-ietf-roll-efficient-npdao-18.txt> NOW AVAILABLE



Many thanks Pascal for the updates.



Mostly I am in sync except for one change in the following para (section 4.5).



---

  A DCO that is generated asynchronously to a DAO message and is meant
  to discard all state along the path regardless of the Path Sequence
  MUST use a Path Sequence value of 240 (see Section 7.2 of [RFC6550]).
  This value allows the DCO to win against any established DAO path but
  to lose against a DAO path that is being installed.  Note that if an
  ancestor initiates a unilateral path cleanup on an established path
  using a DCO with a Path Sequence value of 240, the DCO will
  eventually reach the target node, which will thus be informed of the
  path invalidation.

---



The intention to send an async DCO was to clear out an already established path. Thus anyone who is originating an async DCO has the latest Path Sequence to use. I am not clear if we should mandate using 240 as the Path Sequence here.



Regards,

Rahul

On Wed, 31 Mar 2021 at 10:42, Pascal Thubert (pthubert) <[e-mail]> wrote:
Hello Lynne

Le 30 mars 2021 à 23:44, Lynne Bartholomew <[e-mail]> a écrit :

Hi, Pascal, Rahul, and *Alvaro.

* Alvaro, please review the latest round of updates, and let us know if you approve.  These updates include some additional "RFC 2119" terminology ("MUST NOT"s in Section 4.3.3).

Pascal and Rahul, thank you for the updated XML files.

Please note that we made some further updates to the latest copy.  Please see <https://www.rfc-editor.org/authors/rfc9009-30Mar2021-further-updates-rfcdiff.html>, and let us know any concerns.

For example:

* We implemented the third and fourth "[RJ]" updates as listed below.
* "TIO" was not used in this document previously.  We changed "TIO" to "Transit Information option".
* "node" is lowercased, except for node names, so we changed "LLN Node" to "LLN node" and "node C" to "Node C".
* We changed "next-hop" to "next hop" where used as a noun.

I’m good with this all.

Please note that I approve the publication of the draft as it now stands.



Another question for you:  Should "indicated with in the DAO" be "indicated within the DAO", "indicated in the DAO", or something else?


Either ´in’ or ´within’ works for me.


Please note that I approve the publication of the draft as it stands, the above assumed fixed.

Many thanks !

Pascal


From: Alvaro Retana <[e-mail]>
Subject: Re: *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9009 <draft-ietf-roll-efficient-npdao-18.txt> NOW AVAILABLE
Date: March 30, 2021 at 3:07:22 PM PDT
To: Rahul Jadhav <[e-mail]>, Lynne Bartholomew <[e-mail]>, "Pascal Thubert (pthubert)" <[e-mail]>
Cc: Pascal Thubert <[e-mail]>, Ines Robles <[e-mail]>, RFC System <[e-mail]>, "[e-mail]" <[e-mail]>, Zhen Cao <[e-mail]>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[e-mail]>, peter van der Stok <[e-mail]>, dominique barthel <[e-mail]>, rabi narayan sahoo <[e-mail]>, John Scudder <[e-mail]>

Lynne:

Hi!

This is approved too.


I did send a response on Mar/24…which doesn’t mean that it got to the destination. :-)
(Message-Id: <[e-mail]>)


Thanks!

Alvaro.
On March 30, 2021 at 5:57:52 PM, Lynne Bartholomew ([e-mail]) wrote:

Hello again. We don't want to lose track of this earlier approval request for Alvaro (apologies if we missed an approval email; we couldn't find one):

On Mar 24, 2021, at 2:16 PM, Lynne Bartholomew <[e-mail]> wrote:

Dear Pascal, Rahul, and *AD (Alvaro),

Pascal and Rahul, thank you for your prompt replies! Rahul, many thanks also for your work and the updated XML file.

* Alvaro, please let us know if you approve the removal of the "New Registry for the Destination Cleanup Object Acknowledgment (DCO-ACK) Status Field" section -- apparently, the information listed there should all be found in companion document RFC 9010, as can mostly be seen on <https://www.iana.org/assignments/rpl/>.


Thank you!

RFC Editor/lb

From: Alvaro Retana <[e-mail]>
Subject: Re: *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9009 <draft-ietf-roll-efficient-npdao-18.txt> NOW AVAILABLE
Date: March 24, 2021 at 3:01:00 PM PDT
To: Rahul Jadhav <[e-mail]>, Lynne Bartholomew <[e-mail]>, "Pascal Thubert (pthubert)" <[e-mail]>
Cc: Pascal Thubert <[e-mail]>, dominique barthel <[e-mail]>, rabi narayan sahoo <[e-mail]>, RFC System <[e-mail]>, [e-mail], Zhen Cao <[e-mail]>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[e-mail]>, Ines Robles <[e-mail]>, peter van der Stok <[e-mail]>, John Scudder <[e-mail]>, [e-mail]

On March 24, 2021 at 5:16:23 PM, Lynne Bartholomew wrote:

Hi!

Yes, this change is approved.

Thanks!

Alvaro.

* Alvaro, please let us know if you approve the removal of the "New Registry
for the Destination Cleanup Object Acknowledgment (DCO-ACK) Status Field"
section -- apparently, the information listed there should all be found in
companion document RFC 9010, as can mostly be seen on .

<image002.jpg>