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

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

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]<mailto:[e-mail]>> wrote:
Dear all

Le 30 mars 2021 à 07:25, Rahul Jadhav <[e-mail]<mailto:[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]<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/>.

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]<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.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]<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 -->
> >
> >
> > 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]<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/).
> >
> > 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>