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

[Rahul Jadhav <[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 <[e-mail]>, 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
>
> >
> > The usual 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
> >
> > Thanks again!
> >
> > RFC Editor/lb
> >
> >
> >> On Mar 30, 2021, at 6:56 AM, Pascal Thubert (pthubert) <
> [e-mail]> wrote:
> >>
> >> Hello Lynne, all
> >>
> >> Please find attached my update of Rahul’s xml in this thread.
> >> While minor, some of the changes are some fully editorial and it would
> be good that Alvrao and Rahul confirm they agree.
> >> I do not think that the changes mandate another round trip through the
> WG though.
> >>
> >> Keep safe,
> >>
> >> Pascal
> >>
> >>
> >> From: Rahul Jadhav <[e-mail]>
> >> Sent: mardi 30 mars 2021 7:52
> >> To: Pascal Thubert <[e-mail]>
> >> Cc: Lynne Bartholomew <[e-mail]>; Pascal Thubert
> (pthubert) <[e-mail]>; Alvaro Retana <[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
> >>
> >> Hi Lynne,
> >>
> >> There was one more place in the draft where 'No routing entry' was
> referred to with an incorrect document reference. Fixed it to point to the
> IANA section in the same document and PFA the updated xml.
> >> Sorry for the multiple updates.
> >>
> >> Thanks,
> >> Rahul
> >>
> >> On Tue, 30 Mar 2021 at 11:01, Pascal Thubert <[e-mail]>
> wrote:
> >> Dear all
> >>
> >> Le 30 mars 2021 à 07:25, Rahul Jadhav <[e-mail]> a écrit :
> >>
> >> 
> >> Lynne, Many thanks for the updates. Those updates look fine to me.
> Please find responses for the points below:
> >>
> >> Regards,
> >> Rahul
> >> p.s. PFA the updated XML.
> >>
> >> On Thu, 25 Mar 2021 at 02:46, 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/>.
> >>
> >> However, please note that there appear to be two additional issues
> related to IANA items:
> >>
> >> Issue 1.  Rahul's updated text in Section 4.3.4 of this document
> regarding "No routing entry" now points to companion document RFC 9010, but
> <https://www.iana.org/assignments/rpl/> shows the following:
> >>
> >> 1       No routing entry        [draft-ietf-roll-efficient-npdao-18]
> >>
> >> It appears that we should ask IANA to make the following update on <
> https://www.iana.org/assignments/rpl/>; is that correct?
> >>
> >> Currently:
> >>
> >> 1       No routing entry        [draft-ietf-roll-efficient-npdao-18]
> >>
> >> Possibly:
> >>
> >> 1       No routing entry        [RFC-ietf-roll-unaware-leaves-30]
> >>
> >> (Note that IANA will add the appropriate RFC numbers when these
> documents are published.)
> >>
> >> [RJ] I think it is better to keep this entry defined in NPDAO. I
> earlier thought that this is defined also in unaware-leaves, but it turns
> out unaware-leaves is simply pointing toward EFFICIENT-NPDAO for this. I
> have attached an updated XML. With this, we do not have to ask IANA to make
> any updates I believe.
> >>
> >> Same here, we are in sync
> >>
> >>
> >>
> >> = = = =
> >>
> >> Issue 2.  Table 5 of companion document RFC 9010 shows the following.
> It appears that "9009" should be "9010" there and that we should ask the
> authors of RFC 9010 if we can update accordingly; is that correct?
> >>
> >> 2.    | 1     | No routing entry      | RFC 9009  |
> >>
> >> [RJ] With the above change, this point will also be taken care of.
> >>
> >> As agreed above 9009 is correct.
> >>
> >> Keep safe,
> >>
> >> Pascal
> >>
> >>
> >>
> >>
> >>
> >> = = = = = = = =
> >>
> >> Regarding this item and Rahul's reply:
> >>
> >>> <!-- [rfced] Section 4.4:  Does "it" in this sentence refer to the
>
> >>> DCOSequence values (in which case it should be "those values"), or
>
> >>> something else?
>
> >>>
> >>> Original:
>
> >>> The scope of DCOSequence values is unique to the node which generates
>
> >>> it.
>
> >>>
> >>> [rahul] "it" refers to the node ... not the DCOSequence values.
>
> >>> I believe the current statement is correct.
>
> >>> -->
> >>
> >>
> >> If "it" refers to the node, then saying "unique to the node that
> generates the node" looks odd.  Please confirm that this is correct and
> will be clear to readers (in other words, does the node generate itself?).
> >>
> >> [RJ] Sorry, I was mistaken. "it" refers to the DCOSequence values here
> and not the node. The node does not generate itself.
> >>
> >>
> >> = = = = = = = =
> >>
> >> This updated sentence still does not parse.  Please clarify "are 6LRs
> en-route DCO message path that does not support".
> >>
> >>   If there are 6LRs en-route DCO message path that does
> >>   not support this document, then the route invalidation for
> >>   corresponding targets may not work or may work partially, i.e., only
> >>   part of the path supporting the DCO may be invalidated.
> >>
> >> [RJ] The point of this statement is that, .... "if there are 6LR nodes
> which do not support this document in the path of the DCO message
> transmission, then the route invalidation for the corresponding targets
> (targets which are in the DCO message) may not work or may work
> partially".
> >> = = = = = = = =
> >>
> >> 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-xmldiff1.html
> >>   https://www.rfc-editor.org/authors/rfc9009-xmldiff2.html
> >>
> >> Thanks again!
> >>
> >> RFC Editor/lb
> >>
> >>
> >>>> On Mar 23, 2021, at 10:35 AM, Pascal Thubert (pthubert) <
> [e-mail]> wrote:
> >>>
> >>> Dear RFC editor
> >>>
> >>> Please let us know when the changes proposed by Rahul are committed
> and I’ll make my full review.
> >>>
> >>> Keep safe;
> >>>
> >>> pascal
> >>>
> >>> From: Rahul Jadhav <[e-mail]>
> >>> Sent: lundi 22 mars 2021 18:24
> >>> To: Lynne Bartholomew <[e-mail]>; Pascal Thubert <
> [e-mail]>
> >>> Cc: Pascal Thubert (pthubert) <[e-mail]>;
> [e-mail]; Zhen Cao <[e-mail]>; peter van der
> Stok <[e-mail]>; dominique barthel <
> [e-mail]>; Ines Robles <[e-mail]>;
> Alvaro Retana <[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: AUTH48 [LB]: RFC 9009
> <draft-ietf-roll-efficient-npdao-18.txt> NOW AVAILABLE
> >>>
> >>> Hi All,
> >>>
> >>> Please find attached the updated XML with inline comments responses.
> The latest XML sent by @Lynne Bartholomew is used for all the updates.
> >>>
> >>> @Alvaro Retana, @Pascal Thubert, The draft is updated to remove an
> IANA section for DCO-ACK Status. The draft now references unaware-leaves
> (now defined as RFC 9010) for the definition of the DCO-ACK Status field.
> This is as per our previous discussions based on which IANA was informed
> (dated 4th Jan 2021). The RFCed had duly noted this inline and brought this
> to my attention. Many Thanks.
> >>>
> >>> Thanks,
> >>> Rahul
> >>>
> >>>
> >>>> On Mon, 22 Mar 2021 at 22:23, Lynne Bartholomew <
> [e-mail]> wrote:
> >>> Dear authors,
> >>>
> >>> We have made a few minor corrections to this document.  Please refresh
> your browser to view the latest.
> >>>
> >>>   https://www.rfc-editor.org/authors/rfc9009.txt
> >>>   https://www.rfc-editor.org/authors/rfc9009.html
> >>>   https://www.rfc-editor.org/authors/rfc9009.pdf
> >>>   https://www.rfc-editor.org/authors/rfc9009.xml
> >>>   https://www.rfc-editor.org/authors/rfc9009-diff.html
> >>>   https://www.rfc-editor.org/authors/rfc9009.original.v2v3.xml
> >>>   https://www.rfc-editor.org/authors/rfc9009.form.xml
> >>>   https://www.rfc-editor.org/authors/rfc9009-xmldiff1.html
> >>>   https://www.rfc-editor.org/authors/rfc9009-xmldiff2.html
> >>>
> >>> Thank you.
> >>>
> >>> RFC Editor/lb
> >>>
> >>>> On Mar 21, 2021, at 10:32 PM, [e-mail] wrote:
> >>>>
> >>>> Authors,
> >>>>
> >>>> While reviewing this document during AUTH48, please resolve (as
> necessary) the
> >>>> following questions, which are also in the XML file.
> >>>>
> >>>> 1) <!-- [rfced] Author lists:  Would Rahul Jadhav and Rabi Narayan
> >>>> Sahoo like their names on the first page to appear as "R. Jadhav"
> >>>> and "R. Sahoo" or "R.A. Jadhav" and "R.N. Sahoo"?  We ask because
> >>>> we do not see a precedent in published RFCs and would like to know
> >>>> how their names should appear on the first page of this RFC, as well
> >>>> as future RFCs.
> >>>>
> >>>> Listings in the XML file:
> >>>> <author fullname="Rahul Arvind Jadhav" initials="R.A." role="editor"
> surname="Jadhav">
> >>>> ...
> >>>> <author fullname="Rabi Narayan Sahoo" initials="R.N." surname="Sahoo">
> >>>>
> >>>> Original text output (xml2rfc v2):
> >>>> ROLL                                                      R. Jadhav,
> Ed.
> >>>> Internet-Draft
> Huawei
> >>>> Intended status: Standards Track                              P.
> Thubert
> >>>> Expires: October 17, 2020
> Cisco
> >>>>                                                                R.
> Sahoo
> >>>> ...
> >>>>
> >>>> Current text output (xml2rfc v3):
> >>>> Internet Engineering Task Force (IETF)                  R.A. Jadhav,
> Ed.
> >>>> Request for Comments: 9009
> Huawei
> >>>> Category: Standards Track                                     P.
> Thubert
> >>>> ISSN: 2070-1721
> Cisco
> >>>>                                                              R.N.
> Sahoo
> >>>> ... -->
> >>>>
> >>>>
> >>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear
> in the
> >>>> title) for use on https://www.rfc-editor.org/search -->
> >>>>
> >>>>
> >>>> 3) <!-- [rfced] Section 1.1:  This sentence did not parse.  We updated
> >>>> as follows.  If this is incorrect, please clarify "has target with
>
> >>>> lifetime 0 used".
> >>>>
> >>>> Original:
> >>>> No-Path DAO (NPDAO):
> >>>>   A DAO message which has target with lifetime 0 used for the
> >>>>   purpose of route invalidation.
> >>>>
> >>>> Currently:
> >>>> No-Path DAO (NPDAO):
> >>>>   A DAO message that has a target with a lifetime of 0.  Used for
> >>>>   the purpose of route invalidation. -->
> >>>>
> >>>>
> >>>> 4) <!-- [rfced] Section 1.3:  It appears that NPDAO messaging, as
> opposed
> >>>> to an NPDAO, is important.  We updated this title accordingly.
> >>>> Please let us know if this is incorrect.
> >>>>
> >>>> Original:
> >>>> 1.3.  Why Is NPDAO Important?
> >>>>
> >>>> Currently:
> >>>> 1.3.  Why Is NPDAO Messaging Important? -->
> >>>>
> >>>>
> >>>> 5) <!-- [rfced] Section 1.3: As (D), (E), and (F) appear to be
> distinct
> >>>> destinations per Figure 1, we changed "destination" to "destinations"
> in this
> >>>> sentence.  Also, please note that we added spaces between what appear
> to be
> >>>> node entries.
> >>>>
> >>>> Please let us know if anything is incorrect.  For example, were
> >>>> spaces between the node entries left out because paths, as opposed to
> >>>> separate nodes, are indicated?
> >>>>
> >>>> Original:
> >>>> In the above example, when
> >>>> Node (D) switches parent, the route updates needs to be done for the
> >>>> routing tables entries of (C),(H),(A),(G), and (B) with destination
> >>>> (D),(E) and (F).
> >>>>
> >>>> Currently:
> >>>> In the above example,
> >>>> when Node (D) switches its parent, route updates need to be done for
> >>>> the routing table entries of (C), (H), (A), (G), and (B) with
> >>>> destinations (D), (E), and (F).
> >>>>
> >>>> If paths are indicated, then possibly (per Section 1.2):
> >>>> In the above example,
> >>>> when Node (D) switches its parent, route updates need to be done for
> >>>> the routing table entries of (C)-(H)-(A)-(G) and for (B) with
> >>>> destinations (D)-(E) and (F). -->
> >>>>
> >>>>
> >>>> 6) <!-- [rfced] Section 2.2:  Does "on its behalf" mean "on its own
>
> >>>> behalf" (i.e., Node (D)) or "on behalf of the parent"?
> >>>>
> >>>> Original:
> >>>> In the example topology, when Node (D) switches its parent, Node (D)
> >>>> generates an NPDAO on its behalf. -->
> >>>>
> >>>>
> >>>> 7) <!-- [rfced] Section 4.2:  Please review the following, and let us
> >>>> know any concerns.
> >>>>
> >>>> a) This document cited an older version of
> >>>> [I-D.ietf-roll-unaware-leaves].  What used to be Figure 3
> >>>> ("RPL Status Format") is now Figure 6 in the latest version of
> >>>> [I-D.ietf-roll-unaware-leaves].  We updated this sentence
> >>>> accordingly.  Please let us know any concerns.
> >>>>
> >>>> Original:
> >>>> Value 195 represents 'E' and 'A' bit in RPL Status to be set as per
> >>>> Figure 3 of [I-D.ietf-roll-unaware-leaves] with the lower 6 bits with
> >>>> value 3 indicating 'Moved' as per Table 1 of [RFC8505].
> >>>>
> >>>> Currently:
> >>>> Value 195 represents the 'E' and 'A' bits in RPL Status, to be set as
> >>>> per Figure 6 of [RFC9010], with the lower 6 bits with value 3
> >>>> indicating 'Moved' as per Table 1 of [RFC8505].
> >>>>
> >>>> b) Because RFC 8505 was not listed in the References section, we
> >>>> added it, as it appears to be required for this document.  Please
> >>>> let us know if we should create an Informative References section for
> >>>> it, as opposed to listing it as a Normative Reference.
> >>>>
> >>>> Currently:
> >>>> [RFC8505]  Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
> >>>>           Perkins, "Registration Extensions for IPv6 over Low-Power
>
> >>>>           Wireless Personal Area Network (6LoWPAN) Neighbor
>
> >>>>           Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
> >>>>           <https://www.rfc-editor.org/info/rfc8505>. -->
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> 8) <!-- [rfced] Figures 2, 3, and 4:  The alignment of the "ruler"
> >>>> numbers in these figures is unusual, in that the numbers appear over
> >>>> the "plus" ("+") signs instead of the dashes ("-").  Please let us
> >>>> know if we should correct the alignment per more common usage in
> >>>> RFCs (e.g., RFC 6550).
> >>>>
> >>>> Original (excerpted from Figure 2) (best viewed with a fixed-point
> >>>> font such as Courier):
> >>>> 0                   1                   2                   3
> >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>> |   Type = 0x06 | Option Length |E|I|  Flags    | Path Control  |
> >>>> ...
> >>>>
> >>>> Suggested:
> >>>> 0                   1                   2                   3
> >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>> |   Type = 0x06 | Option Length |E|I|  Flags    | Path Control  |
> >>>> ... -->
> >>>>
> >>>>
> >>>> 9) <!-- [rfced] Sections 4.3.4 and 5.2:  Please let us know how the
> >>>> items related to "DCO-ACK Status" (diagram, description, and the
> >>>> table in Section 5.2) should be updated.  We received email from
> >>>> IANA, dated 4 January 2021, that says the following regarding
> >>>> the "Destination Cleanup Object Acknowledgment (DCO-ACK) Status"
> >>>> registry:
> >>>>
> >>>> "That registry was deleted on October 28th per Alvaro and Pascal
>
> >>>> [IANA #1181404]."
> >>>>
> >>>> Also, it now appears that "Unqualified acceptance", as listed here
> >>>> and in Section 5.2, is now defined by RFC 9010
> <draft-ietf-roll-unaware-leaves>
> >>>> instead of this document.  Please advise.
> >>>>
> >>>> Original:
> >>>> | RPLInstanceID |D|   Flags     |  DCOSequence  | DCO-ACK Status|
> >>>> ...
> >>>> DCO-ACK Status: Indicates the completion.  A value of 0 is defined as
> >>>> unqualified acceptance in this specification.  A value of 1 is
> >>>> defined as "No routing-entry for the Target found".  The remaining
> >>>> status values are reserved as rejection codes.
> >>>> ...
> >>>> Section 5.2 in its entirety
> >>>>
> >>>> Currently (updated the "No routing entry" information per
> >>>> <https://www.iana.org/assignments/rpl/>):
> >>>> DCO-ACK Status:  Indicates completion.  A value of 0 is defined as
> >>>>   unqualified acceptance in this specification.  A value of 1 is
> >>>>   defined as "No routing entry".  The remaining Status values are
> >>>>   reserved as rejection codes.
> >>>>
> >>>> Please review carefully, the following appears in the IANA registry.
> From the
> >>>> text, I expect both Unqualified acceptance and Unqualified rejection
> to appear
> >>>> in the same registry.
> >>>>
> >>>> RPL Non-Rejection Status registry:
> >>>> 0 Unqualified acceptance
> >>>>
> >>>> RPL Rejection Status registry:
> >>>> 0 Unqualified rejection
> >>>> 1 No routing entry
> >>>> -->
> >>>>
> >>>>
> >>>> 10) <!-- [rfced] Section 4.4:  We had trouble following this sentence.
> >>>> We updated it as follows.  Please review, and let us know if anything
> >>>> is incorrect.
> >>>>
> >>>> Original:
> >>>> 2.  The RPLInstanceID and DODAGID fields of a DCO message MUST be the
> >>>>    same value as that of the DAO message in response to which the
> >>>>    DCO is generated on the common ancestor node.
> >>>>
> >>>> Currently:
> >>>> 2.  The RPLInstanceID and DODAGID fields of a DCO message MUST have
> >>>>    the same values as those contained in the DAO message in response
> >>>>    to which the DCO is generated on the common ancestor node. -->
> >>>>
> >>>>
> >>>> 11) <!-- [rfced] Section 4.4:  Please clarify the meaning of
> >>>> "in context to".
> >>>>
> >>>> Original:
> >>>> 5.  A node receiving a unicast DCO message MUST verify the stored
> >>>>    Path Sequence in context to the given target. -->
> >>>>
> >>>>
> >>>> 12) <!-- [rfced] Section 4.4:  As it appears that "more fresh" and
> "newer"
> >>>> mean the same thing, we added "i.e.," ("that is") to this sentence.
> >>>> Please let us know if this is incorrect (i.e., does the text mean
> >>>> "is more fresh or is newer"?).
> >>>>
> >>>> Original:
> >>>> If the stored Path
> >>>> Sequence is more fresh, newer than the Path Sequence received in
> >>>> the DCO, then the DCO MUST be dropped.
> >>>>
> >>>> Currently:
> >>>> If the stored Path
> >>>> Sequence is more fresh, i.e., newer than the Path Sequence
> >>>> received in the DCO, then the DCO MUST be dropped. -->
> >>>>
> >>>>
> >>>> 13) <!-- [rfced] Section 4.4:  Does "it" in this sentence refer to the
> >>>> DCOSequence values (in which case it should be "those values"), or
> >>>> something else?
> >>>>
> >>>> Original:
> >>>> The scope of DCOSequence values is unique to the node which generates
> >>>> it. -->
> >>>>
> >>>>
> >>>> 14) <!-- [rfced] Section 4.6.1:  To what does "its" refer in this
> >>>> sentence - the nodes, in which case perhaps the text should be
> >>>> "all of their DAO messages' Transit Information options", or
> >>>> something else?
> >>>>
> >>>> Original:
> >>>> Thus for route
> >>>> invalidation the dependent nodes may choose to always set the 'I'
> >>>> flag in all its DAO message's Transit Information Option.
> >>>>
> >>>> Possibly:
> >>>> Thus, for route invalidation, the dependent nodes may choose to
> >>>> always set the 'I' flag in all of their DAO messages' Transit
> >>>> Information options. -->
> >>>>
> >>>>
> >>>> 15) <!-- [rfced] Section 4.6.2:  This sentence does not parse.  Please
> >>>> let us know how the text can be corrected.
> >>>>
> >>>> Original:
> >>>> If there are 6LRs en-route DCO message path which do
> >>>> not support this document, then the route invalidation for
> >>>> corresponding targets may not work or may work partially i.e., only
> >>>> part of the path supporting DCO may be invalidated. -->
> >>>>
> >>>>
> >>>> 16) <!-- [rfced] Section 4.6.3:  For ease of the reader, we expanded
> >>>> several abbreviations in this sentence.  Please review, and let us
> >>>> know if any of the expansions are incorrect.
> >>>>
> >>>> Original:
> >>>> For networks supporting only MP2P and P2MP
> >>>> flows, such as in AMI and telemetry applications, the 6LRs may not be
> >>>> very keen to invalidate routes, unless they are highly memory-
> >>>> constrained.
> >>>>
> >>>> Currently:
> >>>> For networks supporting only Multi-Point to
> >>>> Point (MP2P) and Point-to-Multipoint (P2MP) flows, such as in
> >>>> Advanced Metering Infrastructure (AMI) and telemetry applications,
> >>>> the 6LRs may not be very keen to invalidate routes, unless they are
> >>>> highly memory constrained. -->
> >>>>
> >>>>
> >>>> 17) <!-- [rfced] Section 4.6.4:  As it appears that RFC 6550, as
> opposed
> >>>> to the protocol, mentions the use of an NPDAO, we added the citation
> >>>> accordingly and rephrased the text.  Please review carefully, and let
> >>>> us know if anything is incorrect.
> >>>>
> >>>> Original:
> >>>> Subsequently when
> >>>> route invalidation has to be initiated, RPL mentions use of NPDAO
> >>>> which can be initiated with an updated Path Sequence to all the
> >>>> parent nodes through which the route is to be invalidated.
> >>>>
> >>>> Currently:
> >>>> Subsequently, when
> >>>> route invalidation has to be initiated, an NPDAO, which can be
> >>>> initiated with an updated Path Sequence to all the parent nodes
> >>>> through which the route is to be invalidated, can be used; see
> >>>> [RFC6550]. -->
> >>>>
> >>>>
> >>>> 18) <!-- [rfced] Section 6:  All tables except the table at the
> beginning
> >>>> of the IANA Considerations section have a title.  May we add a title
> >>>> as follows?
> >>>>
> >>>> Suggested:
> >>>> Table 1: New Codes for DCO and DCO-ACK Messages -->
> >>>>
> >>>>
> >>>> 19) <!-- [rfced] Sections 6.1, 6.2, and 6.3:  Because "IETF Review"
> >>>> is a special term defined by RFC 8126, we have cited RFC 8126 in
> >>>> these sections and added RFC 8126 to the list of Normative
> >>>> References.  Please let us know if you approve.
> >>>
> >>>
> >>>> On Mar 21, 2021, at 10:06 PM, [e-mail] wrote:
> >>>>
> >>>> *****IMPORTANT*****
> >>>>
> >>>> Updated 2021/03/21
> >>>>
> >>>> RFC Author(s):
> >>>> --------------
> >>>>
> >>>> Instructions for Completing AUTH48
> >>>>
> >>>> Your document has now entered AUTH48.  Once it has been reviewed and
> >>>> approved by you and all coauthors, it will be published as an RFC.
> >>>> If an author is no longer available, there are several remedies
> >>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> >>>>
> >>>> You and you coauthors are responsible for engaging other parties
> >>>> (e.g., Contributors or Working Group) as necessary before providing
> >>>> your approval.
> >>>>
> >>>> Planning your review
> >>>> ---------------------
> >>>>
> >>>> Please review the following aspects of your document:
> >>>>
> >>>> *  RFC Editor questions
> >>>>
> >>>> Please review and resolve any questions raised by the RFC Editor
> >>>> that have been included in the XML file as comments marked as
> >>>> follows:
> >>>>
> >>>> <!-- [rfced] ... -->
> >>>>
> >>>> These questions will also be sent in a subsequent email.
> >>>>
> >>>> *  Changes submitted by coauthors
> >>>>
> >>>> Please ensure that you review any changes submitted by your
> >>>> coauthors.  We assume that if you do not speak up that you
> >>>> agree to changes submitted by your coauthors.
> >>>>
> >>>> *  Content
> >>>>
> >>>> Please review the full content of the document, as this cannot
> >>>> change once the RFC is published. Please pay particular attention to:
> >>>> - IANA considerations updates (if applicable)
> >>>> - contact information
> >>>> - references
> >>>>
> >>>> *  Copyright notices and legends
> >>>>
> >>>> Please review the copyright notice and legends as defined in
> >>>> RFC 5378 and the Trust Legal Provisions
> >>>> (TLP – https://trustee.ietf.org/license-info/).
> >>>>
> >>>> *  Semantic markup
> >>>>
> >>>> Please review the markup in the XML file to ensure that elements of
> >>>> content are correctly tagged.  For example, ensure that <sourcecode>
> >>>> and <artwork> are set correctly.  See details at
> >>>> <https://xml2rfc.tools.ietf.org/xml2rfc-doc.html>.
> >>>>
> >>>> *  Formatted output
> >>>>
> >>>> Please review the PDF, HTML, and TXT files to ensure that the
> >>>> formatted output, as generated from the markup in the XML file, is
> >>>> reasonable.  Please note that the TXT will have formatting
> >>>> limitations compared to the PDF and HTML.
> >>>>
> >>>>
> >>>> Submitting changes
> >>>> ------------------
> >>>>
> >>>> To submit changes, please reply to this email with one of the
> following,
> >>>> using ‘REPLY ALL’ as all the parties CC’ed on this message need to
> see
> >>>> your changes:
> >>>>
> >>>> An update to the provided XML file
> >>>> — OR —
> >>>> An explicit list of changes in this format
> >>>>
> >>>> Section # (or indicate Global)
> >>>>
> >>>> OLD:
> >>>> old text
> >>>>
> >>>> NEW:
> >>>> new text
> >>>>
> >>>> You do not need to reply with both an updated XML file and an
> explicit
> >>>> list of changes, as either form is sufficient.
> >>>>
> >>>> We will ask a stream manager to review and approve any changes that
> seem
> >>>> beyond editorial in nature, e.g., addition of new text, deletion of
> text,
> >>>> and technical changes.  Information about stream managers can be
> found in
> >>>> the FAQ.  Editorial changes do not require approval from a stream
> manager.
> >>>>
> >>>>
> >>>> Approving for publication
> >>>> --------------------------
> >>>>
> >>>> To approve your RFC for publication, please reply to this email
> >>>> stating that you approve this RFC for publication.  Please use ‘REPLY
> ALL’
> >>>> as all the parties CC’ed on this message need to see your approval.
> >>>>
> >>>>
> >>>> Files
> >>>> -----
> >>>>
> >>>> The files are available here:
> >>>> https://www.rfc-editor.org/authors/rfc9009.xml
> >>>> https://www.rfc-editor.org/authors/rfc9009.html
> >>>> https://www.rfc-editor.org/authors/rfc9009.pdf
> >>>> https://www.rfc-editor.org/authors/rfc9009.txt
> >>>>
> >>>> Diff file of the text:
> >>>> https://www.rfc-editor.org/authors/rfc9009-diff.html
> >>>>
> >>>> Diff of the XML:
> >>>> https://www.rfc-editor.org/authors/rfc9009-xmldiff1.html
> >>>>
> >>>> The following files are provided to facilitate creation of your own
> >>>> diff files of the XML.
> >>>>
> >>>> Initial XMLv3 created using XMLv2 as input:
> >>>> https://www.rfc-editor.org/authors/rfc9009.original.v2v3.xml
> >>>>
> >>>> XMLv3 file that is a best effort to capture v3-related format updates
> >>>> only:
> >>>> https://www.rfc-editor.org/authors/rfc9009.form.xml
> >>>>
> >>>>
> >>>> Tracking progress
> >>>> -----------------
> >>>>
> >>>> The details of the AUTH48 status of your document are here:
> >>>> https://www.rfc-editor.org/auth48/rfc9009
> >>>>
> >>>> Please let us know if you have any questions.
> >>>>
> >>>> Thank you for your cooperation,
> >>>>
> >>>> RFC Editor
> >>>>
> >>>> --------------------------------------
> >>>> RFC9009 (draft-ietf-roll-efficient-npdao-18)
> >>>>
> >>>> Title            : Efficient Route Invalidation
> >>>> Author(s)        : R. Jadhav, Ed., P. Thubert, R. Sahoo, Z. Cao
> >>>> WG Chair(s)      : Dominique Barthel, Ines Robles
> >>>> Area Director(s) : Alvaro Retana, John Scudder, Martin Vigoureux
> >>>>
> >>>
> >>
> >> <rfc9009-rahul-updates2.xml>
> >> <rfc9009-rahul-updates3+pascal.xml>
> >
>
>