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

[Jean Mahoney <[e-mail]>]

Rahul,

Thank you for the updated address. We have added 
[e-mail] <mailto:[e-mail]> to the 
[e-mail] mailing list.

Best regards,

RFC Editor/jm


On 3/25/21 4:00 AM, Rahul Jadhav wrote:
> Hi Lynne,
>
> When I responded back to the previous mail, I had added Rabi's Gmail 
> id ([e-mail] <mailto:[e-mail]>) in 
> the CC. I should have explicitly stated this in my response but missed 
> out.
> Anyways Rabi's Gmail id has been in CC since then and is present in 
> the last email you sent. So no worries.
>
> Thanks,
> Rahul
>
> On Thu, 25 Mar 2021 at 02:48, Lynne Bartholomew <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hello again.
>
>     We received a bounce for <[e-mail]
>     <mailto:[e-mail]>>.  If you have a working email
>     address for Rabi, would you please send it along?
>
>     Thank you!
>
>     RFC Editor/lb
>
>
>     > On Mar 24, 2021, at 2:16 PM, Lynne Bartholomew
>     <[e-mail] <mailto:[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/
>     <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/
>     <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/
>     <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.)
>     >
>     > = = = =
>     >
>     > 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  |
>     >
>     > = = = = = = = =
>     >
>     > 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?).
>     >
>     > = = = = = = = =
>     >
>     > 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.
>     >
>     > = = = = = = = =
>     >
>     > The latest files are posted here:
>     >
>     > https://www.rfc-editor.org/authors/rfc9009.txt
>     <https://www.rfc-editor.org/authors/rfc9009.txt>
>     > https://www.rfc-editor.org/authors/rfc9009.pdf
>     <https://www.rfc-editor.org/authors/rfc9009.pdf>
>     > https://www.rfc-editor.org/authors/rfc9009.html
>     <https://www.rfc-editor.org/authors/rfc9009.html>
>     > https://www.rfc-editor.org/authors/rfc9009.xml
>     <https://www.rfc-editor.org/authors/rfc9009.xml>
>     > https://www.rfc-editor.org/authors/rfc9009-diff.html
>     <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-auth48diff.html>
>     >
>     > https://www.rfc-editor.org/authors/rfc9009-xmldiff1.html
>     <https://www.rfc-editor.org/authors/rfc9009-xmldiff1.html>
>     > https://www.rfc-editor.org/authors/rfc9009-xmldiff2.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] <mailto:[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]
>     <mailto:[e-mail]>>
>     >> Sent: lundi 22 mars 2021 18:24
>     >> To: Lynne Bartholomew <[e-mail]
>     <mailto:[e-mail]>>; Pascal Thubert
>     <[e-mail] <mailto:[e-mail]>>
>     >> Cc: Pascal Thubert (pthubert) <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>; Zhen Cao <[e-mail]
>     <mailto:[e-mail]>>; peter van der Stok
>     <[e-mail] <mailto:[e-mail]>>;
>     dominique barthel <[e-mail]
>     <mailto:[e-mail]>>; Ines Robles
>     <[e-mail]
>     <mailto:[e-mail]>>; Alvaro Retana
>     <[e-mail] <mailto:[e-mail]>>; John
>     Scudder <[e-mail] <mailto:[e-mail]>>;
>     [e-mail] <mailto:[e-mail]>; Vigoureux,
>     Martin (Nokia - FR/Paris-Saclay) <[e-mail]
>     <mailto:[e-mail]>>; RFC System
>     <[e-mail] <mailto:[e-mail]>>;
>     rabi narayan sahoo <[e-mail]
>     <mailto:[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] <mailto:[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.txt>
>     >> https://www.rfc-editor.org/authors/rfc9009.html
>     <https://www.rfc-editor.org/authors/rfc9009.html>
>     >> https://www.rfc-editor.org/authors/rfc9009.pdf
>     <https://www.rfc-editor.org/authors/rfc9009.pdf>
>     >> https://www.rfc-editor.org/authors/rfc9009.xml
>     <https://www.rfc-editor.org/authors/rfc9009.xml>
>     >> https://www.rfc-editor.org/authors/rfc9009-diff.html
>     <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.original.v2v3.xml>
>     >> https://www.rfc-editor.org/authors/rfc9009.form.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-xmldiff1.html>
>     >> https://www.rfc-editor.org/authors/rfc9009-xmldiff2.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]
>     <mailto:[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
>     <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
>     <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/
>     <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]
>     <mailto:[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/ <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/
>     <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
>     <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.xml>
>     >>> https://www.rfc-editor.org/authors/rfc9009.html
>     <https://www.rfc-editor.org/authors/rfc9009.html>
>     >>> https://www.rfc-editor.org/authors/rfc9009.pdf
>     <https://www.rfc-editor.org/authors/rfc9009.pdf>
>     >>> https://www.rfc-editor.org/authors/rfc9009.txt
>     <https://www.rfc-editor.org/authors/rfc9009.txt>
>     >>>
>     >>> Diff file of the text:
>     >>> https://www.rfc-editor.org/authors/rfc9009-diff.html
>     <https://www.rfc-editor.org/authors/rfc9009-diff.html>
>     >>>
>     >>> Diff of the XML:
>     >>> https://www.rfc-editor.org/authors/rfc9009-xmldiff1.html
>     <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
>     <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
>     <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
>     <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
>     >>>
>     >>
>     >
>