Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9009 <draft-ietf-roll-efficient-npdao-18.txt> NOW AVAILABLE
Rahul Jadhav <rahul.ietf@gmail.com> Wed, 31 March 2021 11:40 UTC
Return-Path: <rahul.ietf@gmail.com>
X-Original-To: c310@rfc-editor.org
Delivered-To: c310@rfc-editor.org
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id D3790F407BE; Wed, 31 Mar 2021 04:40:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
X-Spam-Flag: NO
X-Spam-Score: -95.978
X-Spam-Level:
X-Spam-Status: No, score=-95.978 tagged_above=-999 required=5 tests=[BAYES_50=1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=0.01, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.01, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=2, SPF_PASS=-0.001, SUBJECT_IN_WHITELIST=-100, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: rfcpa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqYx1d8EgzzV; Wed, 31 Mar 2021 04:40:04 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by rfc-editor.org (Postfix) with ESMTPS id 17BB5F4079D; Wed, 31 Mar 2021 04:40:03 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id r12so29580849ejr.5; Wed, 31 Mar 2021 04:40:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QDu/spBMKrNE9NOZ6XC608EjafjQ6I6ShxxLy/UQM/4=; b=gppsSDe1hgVcLW+akl05C1PYOVybHnFcsHSrhvVbdflSZumHTBcMcZPat41G0nY9xA NnSA5qaP+dzUgUt6k8ZbF96jH6ZZ4c+cdX5e2DotsJ42hJqiZWdFrC7U7TxwO37K5tcT Bn12zN2XVDCu5KZxMveeSH7wH7jZqVOS7tE4tLmIWIQFsMsgpWav+3Apx9pvI8OiNNQs q8UYDuRtjy4r/aMDmHBkvjSZiLPYgFLZBoXFGkdzyiEKSrKQ8kakdyO+WdLarWJ+f4Zd yKvoOfASTZ9j5hskL2Mn/1q5e1VdZgK6tN0TIGvc4u+px2zlz1LiZTmVy1uHYb5hVTzu uHrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QDu/spBMKrNE9NOZ6XC608EjafjQ6I6ShxxLy/UQM/4=; b=nl0xcuT3g823JiA8pcHlmuzl1oduYppceXiEflyJVdX5E9kdZ/Fe23BsN+49ICu2i6 pKE8w7SCJJUf9c4xlUMDmjYuQMI+K084c2Ag+W+Dxto7iPt2KASpDVZ+V8ZTLJE0Nlwy WbqfHSrm28pViPKyznr6b6bRR5weeCkmOadTt4CwKBQ4sZq3rpCeBtPkbeFcrkQZOYS8 njye6bs+KWNV+PlVRqWvaTz9b+2F5nu5VBzT+5cPx1phr/6qSl0tZA9YXWt7o42ZJZnr i5vtJia765yznZGGRheCIc6oKyPECd70rBOnlg3eTFvgelixeV2XTXrzxm9uiE0ljH3k 6SQg==
X-Gm-Message-State: AOAM531J7EYWoZhU8vuRLWO6sZYrjAWBK54h3mtcwwPnfN1bjyS612Fb ieSt/+84nU4iWUCjZgh/SD+iQZx9mfP8W4dsaAE=
X-Google-Smtp-Source: ABdhPJxHR0Ka1tKe8Kv7eXWM2kRMCc/O85mHXyZotlbYZYzJYY4uDI9lpn+p1Tm6IO3nrPyDKKEqFRSYLWURBsXw04I=
X-Received: by 2002:a17:906:6bd1:: with SMTP id t17mr3079319ejs.319.1617190803097; Wed, 31 Mar 2021 04:40:03 -0700 (PDT)
MIME-Version: 1.0
References: <F9E75F6D-7371-4FE5-8F73-018543158AC3@amsl.com> <7D574467-5EFB-489F-B1DB-10FCB52A862C@cisco.com>
In-Reply-To: <7D574467-5EFB-489F-B1DB-10FCB52A862C@cisco.com>
From: Rahul Jadhav <rahul.ietf@gmail.com>
Date: Wed, 31 Mar 2021 17:09:51 +0530
Message-ID: <CAO0Djp1rSds8DqE=6hTS1VZ_sy7-F89KwV=HsPziSqn5JULEKQ@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: Lynne Bartholomew <lbartholomew@amsl.com>, Alvaro Retana <aretana.ietf@gmail.com>, Pascal Thubert <pascal.thubert@gmail.com>, Zhen Cao <zhencao.ietf@gmail.com>, peter van der Stok <consultancy@vanderstok.org>, dominique barthel <dominique.barthel@orange.com>, Ines Robles <mariainesrobles@googlemail.com>, John Scudder <jgs@juniper.net>, "c310@rfc-editor.org" <c310@rfc-editor.org>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <martin.vigoureux@nokia.com>, RFC System <rfc-editor@rfc-editor.org>, rabi narayan sahoo <rabinarayans0828@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000005a4a6d05bed39394"
Subject: Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9009 <draft-ietf-roll-efficient-npdao-18.txt> NOW AVAILABLE
X-BeenThere: c310@rfc-editor.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <c310.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/c310>, <mailto:c310-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/c310/>
List-Post: <mailto:c310@rfc-editor.org>
List-Help: <mailto:c310-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/c310>, <mailto:c310-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Mar 2021 11:40:09 -0000
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) <pthubert@cisco.com> wrote: > Hello Lynne > > > Le 30 mars 2021 à 23:44, Lynne Bartholomew <lbartholomew@amsl.com> 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) < > pthubert@cisco.com> 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 <rahul.ietf@gmail.com> > >> Sent: mardi 30 mars 2021 7:52 > >> To: Pascal Thubert <pascal.thubert@gmail.com> > >> Cc: Lynne Bartholomew <lbartholomew@amsl.com>; Pascal Thubert > (pthubert) <pthubert@cisco.com>; Alvaro Retana <aretana.ietf@gmail.com>; > Zhen Cao <zhencao.ietf@gmail.com>; peter van der Stok < > consultancy@vanderstok.org>; dominique barthel < > dominique.barthel@orange.com>; Ines Robles <mariainesrobles@googlemail.com>; > John Scudder <jgs@juniper.net>; c310@rfc-editor.org; Vigoureux, Martin > (Nokia - FR/Paris-Saclay) <martin.vigoureux@nokia.com>; RFC System < > rfc-editor@rfc-editor.org>; rabi narayan sahoo <rabinarayans0828@gmail.com > > > >> 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 <pascal.thubert@gmail.com> > wrote: > >> Dear all > >> > >> Le 30 mars 2021 à 07:25, Rahul Jadhav <rahul.ietf@gmail.com> 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 <lbartholomew@amsl.com> > 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) < > pthubert@cisco.com> 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 <rahul.ietf@gmail.com> > >>> Sent: lundi 22 mars 2021 18:24 > >>> To: Lynne Bartholomew <lbartholomew@amsl.com>; Pascal Thubert < > pascal.thubert@gmail.com> > >>> Cc: Pascal Thubert (pthubert) <pthubert@cisco.com>; > rabinarayans@huawei.com; Zhen Cao <zhencao.ietf@gmail.com>; peter van der > Stok <consultancy@vanderstok.org>; dominique barthel < > dominique.barthel@orange.com>; Ines Robles <mariainesrobles@googlemail.com>; > Alvaro Retana <aretana.ietf@gmail.com>; John Scudder <jgs@juniper.net>; > c310@rfc-editor.org; Vigoureux, Martin (Nokia - FR/Paris-Saclay) < > martin.vigoureux@nokia.com>; RFC System <rfc-editor@rfc-editor.org>; rabi > narayan sahoo <rabinarayans0828@gmail.com> > >>> 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 < > lbartholomew@amsl.com> 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, rfc-editor@rfc-editor.org 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, rfc-editor@rfc-editor.org 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> > > >
- [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll-eff… rfc-editor
- Re: [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll… rfc-editor
- Re: [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll… Lynne Bartholomew
- Re: [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll… Rahul Jadhav
- [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC… Lynne Bartholomew
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Lynne Bartholomew
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Alvaro Retana
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Rahul Jadhav
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Pascal Thubert
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Jean Mahoney
- Re: [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll… Pascal Thubert (pthubert)
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Pascal Thubert (pthubert)
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Lynne Bartholomew
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Pascal Thubert
- Re: [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll… Lynne Bartholomew
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Pascal Thubert (pthubert)
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Pascal Thubert (pthubert)
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Pascal Thubert (pthubert)
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Pascal Thubert (pthubert)
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Rahul Jadhav
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Rahul Jadhav
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Pascal Thubert (pthubert)
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Lynne Bartholomew
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Lynne Bartholomew
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Alvaro Retana
- Re: [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll… Pascal Thubert (pthubert)
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Alvaro Retana
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Pascal Thubert (pthubert)
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Pascal Thubert (pthubert)
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Rahul Jadhav
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Pascal Thubert (pthubert)
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Rahul Jadhav
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Pascal Thubert (pthubert)
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Rahul Jadhav
- Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]:… Alvaro Retana
- Re: [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll… Lynne Bartholomew
- Re: [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll… rabi narayan sahoo
- Re: [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll… Pascal Thubert (pthubert)
- Re: [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll… Lynne Bartholomew
- Re: [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll… Pascal Thubert
- Re: [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll… Zhen Cao
- Re: [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll… Lynne Bartholomew
- Re: [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll… Pascal Thubert (pthubert)
- Re: [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll… Pascal Thubert
- Re: [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll… Lynne Bartholomew
- Re: [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll… Lynne Bartholomew