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

[Zhen Cao <[e-mail]>]

Hi Lynne and all,

Thank you so much for the hard work.  I approve the publication of this
document.

Best regards,
Zhen

On Fri, Apr 2, 2021 at 1:23 AM 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-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 .
>
>
>