Hi *Jim, Charles, all, *Jim - As AD, please review the change to “blacklisting” below and let us know if you approve. This update can also be viewed in Section 1 of the diff: https://www.rfc-editor.org/authors/rfc9854-auth48diff.html.
OLD: AODV-RPL currently omits some features compared to AODV -- in particular, flagging Route Errors, "blacklisting" unidirectional links ([RFC3561]), multihoming, and handling unnumbered interfaces. NEW: AODV-RPL currently omits some features compared to AODV -- in particular, flagging route errors, blocking the use of unidirectional links [RFC3561], multihoming, and handling unnumbered interfaces. Charles - Thank you for your reply and updates. We have updated the document accordingly. A few follow-up notes: >> 15) <!-- [rfced] We note several author comments present in the XML. Please >> confirm that no updates related to these comments are outstanding. Note >> that the comments will be deleted prior to publication. --> > All the changes that we decided to make have already been made. However, I > am not at all clear on how deleting those comments would add value to the > document. Some people in the future might like to understand more about our > thought processes even if the .xml comments are not normative and do not > specify anything. Thank you for confirming that no further action is required regarding the comments in the XML. These comments will be removed from the XML as a typical part of the publication process, as defined by Section 5.6.4 of RFC 7998 <https://www.rfc-editor.org/rfc/rfc7998.html#section-5.6.4>. However, we believe the XML for the draft version of this document will remain available via Datatracker, so these comments will remain available there. Please let us know if you have additional questions or concerns. >> 16) <!-- [rfced] Terminology >> a.) We note inconsistencies in the terms below throughout the text. Should >> these be uniform? If so, please let us know which form is preferred. >> >> Next Hop >> next hop > Use next hop except when referring to the relevant information in the route > table entry. > >> source address >> Source Address >> >> destination address >> Destination Address > I think these are correct as currently used in the draft. As above, the > capitalization is used for the relevant information in the route table entry. >> >> >> lifetime >> Lifetime > Use lifetime except when referring to the relevant information in the route > table entry. Thank you for providing that additional context. We have made one update to the items above (capitalized one instance of “next hop” in Section 6.3.1 to match Section 6.4.4), but otherwise we have left these terms as is. We are not certain when these items are relevant to the route table entry, so kindly review and let us know if/where any additional updates are needed. We will await approvals from each party listed on the AUTH48 status page prior to moving forward in the publication process. The AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9854 Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. — FILES (please refresh): — The updated files have been posted here: https://www.rfc-editor.org/authors/rfc9854.txt https://www.rfc-editor.org/authors/rfc9854.pdf https://www.rfc-editor.org/authors/rfc9854.html https://www.rfc-editor.org/authors/rfc9854.xml Diff files showing changes between the last and current version: https://www.rfc-editor.org/authors/rfc9854-lastdiff.html https://www.rfc-editor.org/authors/rfc9854-lastrfcdiff.html (side by side) Diff files showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9854-auth48diff.html https://www.rfc-editor.org/authors/rfc9854-auth48rfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9854-diff.html https://www.rfc-editor.org/authors/rfc9854-rfcdiff.html (side by side) Thank you for your time, Kaelin Foody RFC Production Center > On Sep 27, 2025, at 4:48 PM, Charles Perkins <[email protected]> wrote: > > Hello folks, > > I reviewed the rest of the comments. I didn't delete any of my previous > comments. My new comments start after "End of what I was reviewed as of > 9/22/2025". > > On 9/12/2025 11:07 AM, Kaelin Foody wrote: >> -------------------------------------- >> >> Authors, >> >> While reviewing this document during AUTH48, please resolve (as necessary) >> the following questions, which are also in the XML file. >> >> >> 1) <!-- [rfced] This is a question for Charles. Would you like to like to >> retain >> the double initials (i.e., "C.E. Perkins") in the first-page header or >> update to use a single initial ("C. Perkins")? It looks like the single >> initial was used for the most recent RFCs you have authored, e.g., 9354, >> 9119, and 9034. >> >> Original: >> C.E. Perkins >> >> Perhaps: >> C. Perkins >> --> > > I prefer C.E. Perkins, because there are other persons that publish at IETF > and would possibly use C. Perkins > >> 2) <!-- [rfced] The abstract defines AODV-RPL as "Ad Hoc On-demand Distance >> Vector Routing (AODV) based RPL protocol (AODV-RPL)". May we update this >> definition as follows to avoid awkward hyphenation of "based"? Also, may >> we update the title to include this definition? >> >> Original: >> Supporting Asymmetric Links in Low Power Networks: AODV-RPL >> ... >> For that purpose, this document specifies a reactive P2P >> route discovery mechanism for both hop-by-hop routes and source >> routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL >> protocol (AODV-RPL). >> >> Perhaps: >> AODV-RPL: The Routing Protocol for Low-Power and Lossy Networks (RPL) >> Based on Ad Hoc On-Demand Distance Vector (AODV) Routing >> ... >> For that purpose, this document specifies AODV-RPL - - the Routing Protocol >> for Low-Power and Lossy Networks (RPL) based on Ad hoc On-demand Distance >> Vector (AODV) routing. AODV-RPL is a reactive P2P route discovery mechanism >> for both hop-by-hop routes and source routing. >> >> (Note that we used "- -" in the text above to avoid issues in the xml >> comment. We will delete the space when updating the document.) >> --> > > This is O.K. with me. But doesn't it make the title too long? > >> 3) <!-- [rfced] Is "otherwise" needed at the end of this sentence? >> >> Original: >> AODV-RPL >> can be operated whether or not P2P-RPL or native RPL is running >> otherwise. >> >> Perhaps: >> AODV-RPL >> can be operated whether or not P2P-RPL or native RPL is also running. >> --> > > This is fine with me. > >> 4) <!-- [rfced] Section 2: Please review the following questions regarding >> the >> terminology list in this section. >> >> a.) Note that we have updated the expansion of AODV to align with usage in >> RFC >> 3561. >> >> Original: >> >> AODV >> Ad Hoc On-demand Distance Vector Routing [RFC3561]. >> >> Current: >> >> AODV >> Ad hoc On-Demand Distance Vector [RFC3561]. > > This is O.K. with me. > >> b.) Please review the definitions for "RREQ" and "RREP". Should these be >> updated to "Route Request" and "Route Reply", respectively? Text in the >> Introduction notes: "AODV terminology has been adapted for use with AODV-RPL >> messages, namely RREQ for Route Request, and RREP for Route Reply." >> >> Original: >> RREQ >> A RREQ-DIO message. >> >> RREQ-DIO message >> A DIO message containing the RREQ option. The RPLInstanceID in >> RREQ-DIO is assigned locally by the OrigNode. The RREQ-DIO >> message has a secure variant as noted in [RFC6550]. >> ... >> RREP >> A RREP-DIO message. >> >> RREP-DIO message >> A DIO message containing the RREP option. OrigNode pairs the >> RPLInstanceID in RREP-DIO to the one in the associated RREQ-DIO >> message (i.e., the RREQ-InstanceID) as described in Section 6.3.2. >> The RREP-DIO message has a secure variant as noted in [RFC6550]. >> >> Perhaps: >> RREQ >> Route Request >> >> RREQ-DIO message >> A DIO message containing the RREQ option. The RPLInstanceID in >> RREQ-DIO is assigned locally by the OrigNode. The RREQ-DIO >> message has a secure variant as noted in [RFC6550]. >> ... >> RREP >> Route Reply >> >> RREP-DIO message >> A DIO message containing the RREP option. OrigNode pairs the >> RPLInstanceID in RREP-DIO to the one in the associated RREQ-DIO >> message (i.e., the RREQ-InstanceID) as described in Section 6.3.2. >> The RREP-DIO message has a secure variant as noted in [RFC6550]. > > This is O.K. with me, I suppose. 'Route Request' seems to be compatible with > the few places where RREQ occurs without a following '-'. Maybe the title of > section 6.4 should be 'Receiving and Forwarding RREP' -- not sure! > > >> >> >> >> c.) Some terms in the list use initial capitalization (e.g., "Asymmetric >> Route") while others capitalize just the first word (e.g., "Symmetric >> route"). Is this intentional, or are any changes are needed for consistency? >> --> > > I think capitalizing only the first word is O.K. in the example given. > >> 5) <!-- [rfced] FYI - We added the following sentence to introduce the list >> of >> terms in Section 2. >> >> Updated: >> This document also uses the following terms: >> --> >> > > Sounds good to me. > >> 6) <!-- [rfced] Should "Type and Length fields" be updated to "Option Type >> and >> Option Length fields"? Note that this text appears several times in the >> document. >> >> Original: >> Option Length >> 8-bit unsigned integer specifying the length of the option in >> octets, excluding the Type and Length fields. >> >> Perhaps: >> Option Length >> 8-bit unsigned integer specifying the length of the option in >> octets, excluding the Option Type and Option Length fields. >> --> > > I think this is a good idea. > >> 7) <!-- [rfced] We updated "this example" to "these examples" in the second >> sentence below as we believe this refers to both Figures 4 and 5. Let us >> know if this is incorrrect. >> >> Original: >> In Figure 4 and Figure 5, BR is the Border Router, O is >> the OrigNode, each R is an intermediate router, and T is the >> TargNode. In this example, the use of BR is only for illustrative >> purposes; AODV does not depend on the use of border routers for its >> operation. >> >> Updated: >> In Figures 4 and 5, BR is the Border Router, O is >> the OrigNode, each R is an intermediate router, and T is the >> TargNode. In these examples, the use of BR is only for illustrative >> purposes; AODV does not depend on the use of border routers for its >> operation. >> --> > > This is fine with me. > >> 8) <!-- [rfced] Would it be helpful to align these titles (i.e., start each >> with >> an -ing verb and use RREQ and RREP rather than expansions)? >> >> Original: >> 6.1. Route Request Generation >> 6.2. Receiving and Forwarding RREQ Messages >> 6.3. Generating Route Reply (RREP) at TargNode >> 6.4. Receiving and Forwarding Route Reply >> >> Perhaps: >> 6.1. Generating RREQ >> 6.2. Receiving and Forwarding RREQ Messages >> 6.3. Generating RREP at TargNode >> 6.4. Receiving and Forwarding RREP >> --> > > This is fine with me. > >> 9) <!-- [rfced] May we update "If so" (and "If not" in the first sentence) as >> shown below for clarity?. >> >> a) >> >> Original: >> When a router X receives a RREQ message over a link from a neighbor >> Y, X first determines whether or not the RREQ is valid. If so, X >> then determines whether or not it has sufficient resources available >> to maintain the RREQ-Instance and the value of the 'S' bit needed to >> process an eventual RREP, if the RREP were to be received. If not, >> then X MUST either free up sufficient resources (the means for this >> are beyond the scope of this document), or drop the packet and >> discontinue processing of the RREQ. >> >> Perhaps (change "If so" to "If valid" and "If not" to "If not valid"): >> When a router X receives a RREQ message over a link from a neighbor >> Y, X first determines whether or not the RREQ is valid. If valid, X >> then determines whether or not it has sufficient resources available >> to maintain the RREQ-Instance and the value of the S bit needed to >> process an eventual RREP, if the RREP were to be received. If not valid, >> then X MUST either free up sufficient resources (the means for this >> are beyond the scope of this document), or drop the packet and >> discontinue processing of the RREQ. >> >> b) >> >> Original: >> Otherwise, the router MUST determine whether the downward (i.e., >> towards the TargNode) direction of the incoming link satisfies the >> OF. If so, the S bit of the RREQ-DIO to be transmitted is set to 1. >> Otherwise the S bit of the RREQ-DIO to be transmitted is set to 0. >> >> Perhaps ("If so" to "If it does"): >> Otherwise, the router MUST determine whether the downward direction >> (i.e., towards the TargNode) of the incoming link satisfies the >> OF. If it does, the S bit of the RREQ-DIO to be transmitted is set to 1. >> Otherwise, the S bit of the RREQ-DIO to be transmitted is set to 0. >> >> c) >> >> Original: >> If the S-bit of the RREQ-Instance is set to 0, the router MUST >> determine whether the downward direction of the link (towards the >> TargNode) over which the RREP-DIO is received satisfies the Objective >> Function, and the router's Rank would not exceed the RankLimit. If >> so, the router joins the DODAG of the RREP-Instance. >> >> Perhaps: >> If the S-bit of the RREQ-Instance is set to 0, the router MUST >> determine whether the downward direction of the link (towards the >> TargNode) over which the RREP-DIO is received satisfies the Objective >> Function and whether the router's Rank would not exceed the RankLimit. If >> these are true, the router joins the DODAG of the RREP-Instance. >> >> d) >> >> Original: >> The router next >> checks if one of its addresses is included in the ART Option. If so, >> this router is the OrigNode of the route discovery. >> >> Perhaps: >> The router next >> checks if one of its addresses is included in the ART option. If >> it is included, >> this router is the OrigNode of the route discovery. >> --> > > These changes are all fine with me. > >> 10) <!-- [rfced] May we update "and H=0" as follows to improve readability of >> this sentence? >> >> Original: >> Suppose a router has joined the RREQ-Instance, and H=0, and the S-bit >> of the RREQ-Instance is set to 1. >> >> Perhaps: >> Suppose a router has joined the RREQ-Instance, the H bit is set to 0, and >> the S bit >> of the RREQ-Instance is set to 1. >> --> > > Readability is in the eyes of the beholder, but it is O.K. with me to make > this change. Some people find it easier to read things that use fewer words > as long as there's no ambiguity. > >> 11) <!-- [rfced] This sentence appears in Section 6.3. Will readers >> understand >> what "the steps below" refer to? The subsections of Section 6.3 are not >> labeled "Step 1: ..." like the subsections in Sections 6.2 and 6.4. >> >> Original: >> If the link >> to Y can be used to transmit packets to OrigNode, TargNode generates >> a RREP according to the steps below. >> >> Perhaps: >> If the link >> to Y can be used to transmit packets to OrigNode, TargNode generates >> a RREP according to Sections 6.3.1 and 6.3.2. >> --> > > This is fine with me. > >> 12) <!-- [rfced] In the IANA Considerations section, may we remove "Option" >> from >> the Meaning column in Table 1? In the "RPL Control Message Options" >> registry, most of the entries do not include "Option", and the title of >> the registry already includes "Options". If this change is made, we will >> ask IANA to update the registry accordingly prior to publication. >> >> Link to registry: >> https://www.iana.org/assignments/rpl/rpl.xhtml#control-message-options >> >> Original: >> Value Meaning >> 0x0B RREQ Option >> 0x0C RREP Option >> 0x0D ART Option >> >> Perhaps: >> Value Meaning >> 0x0B RREQ >> 0x0C RREP >> 0x0D ART >> --> > > It is O.K. with me if you think it is an improvement. Does this align with > how IANA refers to option numbering in other RFCs? > >> 13) <!-- [rfced] Would it be helpful to point to Table 3 in the first >> sentence >> below? Also, may we update "useful ETX vs RSSI table" and "ETX versus >> RSSI values" as follows? >> >> Original: >> Since the ETX value is reflective of the extent of packet drops, >> it allowed us to prepare a useful ETX vs versus RSSI table. ETX >> versus RSSI values obtained in this way may be used as explained >> below: >> >> Perhaps: >> Since the ETX value is reflective of the extent of packet drops, >> it allowed us to prepare a useful table correlating ETX and RSSI values >> (see Table 3). ETX and RSSI values obtained in this way may be used >> as explained below: >> --> > > This is fine with me. > >> 14) <!-- [rfced] In the Acknowledgements section, we added a period after >> "H.M". >> Are any further updates (e.g., surname) needed? >> >> Original: >> The authors specially thank >> Lavanya H.M for implementing AODV-RPl in Contiki and conducting >> extensive simulation studies. >> >> Current: >> The authors specially thank >> Lavanya H.M. for implementing AODV-RPl in Contiki and conducting >> extensive simulation studies. >> --> > > I don't know of any other changes to the Acknowledgements unless it is > appropriate to acknowledge the efforts of the RFC editor team. > > ---------------------------------> End of what I was reviewed as of 9/22/2025 > <------------------------------------------------ > >> 15) <!-- [rfced] We note several author comments present in the XML. Please >> confirm that no updates related to these comments are outstanding. Note >> that the comments will be deleted prior to publication. --> > All the changes that we decided to make have already been made. However, I > am not at all clear on how deleting those comments would add value to the > document. Some people in the future might like to understand more about our > thought processes even if the .xml comments are not normative and do not > specify anything. > >> >> >> 16) <!-- [rfced] Terminology >> >> a.) We note inconsistencies in the terms below throughout the text. Should >> these be uniform? If so, please let us know which form is preferred. >> >> Also, if the capitalized form of any of these is used to indicate the name of >> a field, would it be helpful to add the word field after (e.g., change >> "Address Vector" to "Address Vector field")? If so, please update the xml >> file >> or indicate which instances should be updated using OLD/NEW format. >> >> RPLInstance >> RPL Instance >> RPL instance > Use RPL Instance. >> >> >> Destination Sequence Number >> destination sequence number > Use Destination Sequence Number. >> >> >> Sequence Number >> sequence number > Use Sequence Number. >> >> >> Intermediate Router >> Intermediate router >> intermediate router > Use Intermediate Router in titles, otherwise use Intermediate router at the > beginning of sentences, and use intermediate router otherwise. >> >> >> Rank >> rank > Use Rank. > >> >> Address Vector >> address vector > Use Address Vector. >> >> >> Next Hop >> next hop > Use next hop except when referring to the relevant information in the route > table entry. > >> >> source address >> Source Address >> >> destination address >> Destination Address > I think these are correct as currently used in the draft. As above, the > capitalization is used for the relevant information in the route table entry. >> >> >> lifetime >> Lifetime > Use lifetime except when referring to the relevant information in the route > table entry. >> >> >> >> b.) We note inconsistencies in the terms listed below. We chose the latter >> form. Please let us know any objections. >> >> RREP-instance >> RREP-Instance > Use RREP-Instance >> >> >> RREQ instance >> RREQ-Instance > Use RREQ-Instance. >> >> >> trickle timer >> Trickle timer >> Note: Per usage in RFC 6206. > Use Trickle timer. >> >> >> Target Option >> Target option >> Note: Per usage in RFC 6550 and for consistency with "RREQ option" and >> "RREP option". > Use Target option. >> >> >> ART Option >> ART option >> Note: For consistency with "RREQ option" and "RREP option". > Use ART option. >> >> >> >> c.) We note that RFC 9030 stylizes "6tisch" as "6TiSCH". May we >> update the text below for consistency with RFC 9030? >> >> Original: >> >> As an example, intermediate routers can use local information (e.g., bit >> rate, bandwidth, number of cells used in 6tisch [RFC9030])... > Yes, that's fine. > >> >> >> d.) The following forms are used in the document. For consistency, we have >> expanded these upon first use and updated subsequent instances to "G-RREP" >> and >> "G-RREP-DIO". Note that we used "G-RREP-DIO" (two hyphens). Let us know any >> concerns. >> >> Gratuitous RREP >> gratuitous RREP >> G-RREP >> >> "Gratuitous" RREP-DIO >> gratuitous RREP-DIO >> G-RREP DIO > No objection. > >> >> >> e.) The following forms are used in the document for bit names. We have >> updated to use the latter form with no hyphen and no single quote (i.e, S >> bit, >> D bit, and H bit). >> >> S-bit >> 'D' bit >> H bit > > That's fine with me. > >> >> >> f.) How are "RREP" and "RREQ" pronounced? As "are-rep" and "are-req"? We ask >> for guidance in order to choose the appropriate indefinite article for these >> to follow (i.e., “a" or "an"). >> >> Examples: >> >> an RREP-DIO >> a RREP-DIO >> >> an RREQ-Instance >> a RREQ-Instance >> --> > One is easier to pronounce, the other is easier to read. Please use the > indefinite article convention that is currently in use for other RFCs. > >> >> >> 17) <!-- [rfced] Abbreviations >> >> a.) We note the full expansion of "Objective Function" is frequently used >> after its abbreviation "OF" is introduced. For consistency, may we update to >> the abbreviation after first use? > That's fine with me. > >> >> b.) FYI - We made the following updates: >> >> Expected Number of Transmissions (ETX) > Expected Transmission Count (ETX) >> Note: For consistency with RFC 6551. >> >> Received Signal Strength Indication (RSSI) > Received Signal Strength >> Indicator (RSSI) >> Note: Both forms were used in the document. > That is fine with me. > >> >> c.) We have added expansions for abbreviations upon first use per Section 3.6 >> of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document >> carefully to ensure correctness. >> >> Directed Acyclic Graph (DAG) >> Operations, Administration, and Maintenance (OAM) >> --> > > That is also fine with me. >> >> >> >> 18) <!-- [rfced] References: >> >> a.) FYI - We have removed [RFC7991] in the References section. It was only >> cited in the Change Log, which was deleted. > No problem. >> >> >> >> b.) We found the following URL for the [co-ioam] reference: >> >> https://ieeexplore.ieee.org/document/8328276 >> >> May we add this URL (and the corresponding DOI 10.1109/COMSNETS.2018.8328276) >> to this reference? >> >> Original: >> [co-ioam] Rashmi Ballamajalu, Anand, S.V.R., and Malati Hegde, "Co- >> iOAM: In-situ Telemetry Metadata Transport for Resource >> Constrained Networks within IETF Standards Framework", >> 2018 10th International Conference on Communication >> Systems & Networks (COMSNETS) pp.573-576, January 2018. >> >> Perhaps: >> [co-ioam] Ballamajalu, R., Anand, S.V.R., and M. Hegde, "Co-iOAM: >> In-situ Telemetry Metadata Transport for Resource >> Constrained Networks within IETF Standards Framework", >> 2018 10th International Conference on Communication >> Systems & Networks (COMSNETS), pp. 573-576, >> DOI 10.1109/COMSNETS.2018.8328276, January 2018, >> <https://ieeexplore.ieee.org/document/8328276>. > Thanks for finding this. > >> >> >> c.) The reference entry for the [aodv-tot] reference included a commented-out >> DOI that leads to this URL: >> >> https://ieeexplore.ieee.org/document/749281 >> >> May we add this URL and the corresponding DOI to this reference? >> >> Original: >> [aodv-tot] Perkins, C.E. and E.M. Royer, "Ad-hoc On-demand Distance >> Vector Routing", Proceedings WMCSA'99. Second IEEE >> Workshop on Mobile Computing Systems and Applications , >> February 1999. >> >> Perhaps: >> [aodv-tot] Perkins, C.E. and E.M. Royer, "Ad-hoc On-demand Distance >> Vector Routing", Proceedings WMCSA'99. Second IEEE >> Workshop on Mobile Computing Systems and Applications, pp. >> 90-100, DOI 10.1109/MCSA.1999.749281, February 1999, >> <https://ieeexplore.ieee.org/document/749281>. > Yes, that's fine. > >> >> >> d.) We found the following URL for the [empirical-study] reference: >> >> https://ieeexplore.ieee.org/document/6231290 >> >> May we add this URL (and the corresponding DOI 10.1109/MCOM.2012.6231290) to >> this reference entry? >> >> Original: >> [empirical-study] >> Prasant Misra, Nadeem Ahmed, and Sanjay Jha, "An empirical >> study of asymmetry in low-power wireless links", IEEE >> Communications Magazine (Volume: 50, Issue: 7), July 2012. >> >> Perhaps: >> [empirical-study] >> Misra, P., Ahmed, N., and S. Jha, "An empirical study of >> asymmetry in low-power wireless links", IEEE >> Communications Magazine, vol. 50, no. 7, pp. 137-146, >> DOI 10.1109/MCOM.2012.6231290, July 2012, >> <https://ieeexplore.ieee.org/document/6231290>. >> --> >> > Yes, that's fine. > >> >> 19) <!-- [rfced] Please review the "Inclusive Language" portion of the online >> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >> and let us know if any changes are needed. Updates of this nature typically >> result in more precise language, which is helpful for readers. >> >> For example, please consider whether the following can be updated in the >> instances below: >> >> a.) "native" >> >> Original: >> These P2P routes may differ from routes discoverable by native RPL. >> >> AODV-RPL can be operated whether or not P2P-RPL or native RPL is running >> otherwise. > You can use "by RPL[RFC6550]". >> >> b.) "blacklisting" >> >> Original: >> ...in particular, flagging Route Errors, "blacklisting" unidirectional links >> ([RFC3561]), multihoming, and handling unnumbered interfaces. >> --> >> > You can use "blocking the use of" (not in quotation marks). > >> >> Thank you. >> >> Kaelin Foody and Rebecca VanRheenen >> RFC Production Center > Many thanks to you. > > Regards, > Charlie P. > > ===================== end of further changes as of 9/27/2025 ================ >> >> > >> >> >>> On Sep 9, 2025, at 7:50 PM, satish anamalamudi <[email protected]> >>> wrote: >>> >>> Hello All, >>> >>> I am okay with the suggested changes. I approve this RFC for publication. I >>> thank the RFC team for their effort in publishing this draft. >>> >>> Regards, >>> Satish >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> With Regards, >>> Dr. Satish Anamalamudi, PhD., >>> >>> >>> >>> On Tue, 9 Sep 2025 at 11:04 PM, S.V.R.Anand <[email protected]> wrote: >>> Hello All, >>> >>> The suggested corrections look good for me! I thank the RFC Editor team for >>> their great work. I approve this RFC for publication. >>> >>> Regards >>> Anand >>> >>> On Mon, Sep 01, 2025 at 10:19:41PM -0700, [email protected] wrote: >>> >>>> *****IMPORTANT***** >>>> >>>> Updated 2025/09/01 >>>> >>>> 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://authors.ietf.org/rfcxml-vocabulary>. >>>> >>>> * 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 using ‘REPLY ALL’ as all >>>> the parties CCed on this message need to see your changes. The parties >>>> include: >>>> >>>> * your coauthors >>>> >>>> * [email protected] (the RPC team) >>>> >>>> * other document participants, depending on the stream (e.g., >>>> IETF Stream participants are your working group chairs, the >>>> responsible ADs, and the document shepherd). >>>> >>>> * [email protected], which is a new archival mailing list >>>> to preserve AUTH48 conversations; it is not an active discussion >>>> list: >>>> >>>> * More info: >>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>>> >>>> * The archive itself: >>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>> >>>> * Note: If only absolutely necessary, you may temporarily opt out >>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>> If needed, please add a note at the top of the message that you >>>> have dropped the address. When the discussion is concluded, >>>> [email protected] will be re-added to the CC list and >>>> its addition will be noted at the top of the message. >>>> >>>> You may submit your changes in one of two ways: >>>> >>>> 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 CCed on this message need to see your approval. >>>> >>>> >>>> Files >>>> ----- >>>> >>>> The files are available here: >>>> https://www.rfc-editor.org/authors/rfc9854.xml >>>> https://www.rfc-editor.org/authors/rfc9854.html >>>> https://www.rfc-editor.org/authors/rfc9854.pdf >>>> https://www.rfc-editor.org/authors/rfc9854.txt >>>> >>>> Diff file of the text: >>>> https://www.rfc-editor.org/authors/rfc9854-diff.html >>>> https://www.rfc-editor.org/authors/rfc9854-rfcdiff.html (side by side) >>>> >>>> Alt-diff of the text (allows you to more easily view changes >>>> where text has been deleted or moved): >>>> https://www.rfc-editor.org/authors/rfc9854-alt-diff.html >>>> >>>> Diff of the XML: >>>> https://www.rfc-editor.org/authors/rfc9854-xmldiff1.html >>>> >>>> >>>> Tracking progress >>>> ----------------- >>>> >>>> The details of the AUTH48 status of your document are here: >>>> https://www.rfc-editor.org/auth48/rfc9854 >>>> >>>> Please let us know if you have any questions. >>>> >>>> Thank you for your cooperation, >>>> >>>> RFC Editor >>>> >>>> -------------------------------------- >>>> RFC9854 (draft-ietf-roll-aodv-rpl-20) >>>> >>>> Title : Supporting Asymmetric Links in Low Power Networks: AODV-RPL >>>> Author(s) : C. Perkins, S.V.R. Anand, S. Anamalamudi, B. Liu >>>> WG Chair(s) : Ines Robles, Remous-Aris Koutsiamanis >>>> >>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde > On Sep 27, 2025, at 4:48 PM, Charles Perkins <[email protected]> wrote: > > Hello folks, > > I reviewed the rest of the comments. I didn't delete any of my previous > comments. My new comments start after "End of what I was reviewed as of > 9/22/2025". > > On 9/12/2025 11:07 AM, Kaelin Foody wrote: >> -------------------------------------- >> >> Authors, >> >> While reviewing this document during AUTH48, please resolve (as necessary) >> the following questions, which are also in the XML file. >> >> >> 1) <!-- [rfced] This is a question for Charles. Would you like to like to >> retain >> the double initials (i.e., "C.E. Perkins") in the first-page header or >> update to use a single initial ("C. Perkins")? It looks like the single >> initial was used for the most recent RFCs you have authored, e.g., 9354, >> 9119, and 9034. >> >> Original: >> C.E. Perkins >> >> Perhaps: >> C. Perkins >> --> > > I prefer C.E. Perkins, because there are other persons that publish at IETF > and would possibly use C. Perkins > >> 2) <!-- [rfced] The abstract defines AODV-RPL as "Ad Hoc On-demand Distance >> Vector Routing (AODV) based RPL protocol (AODV-RPL)". May we update this >> definition as follows to avoid awkward hyphenation of "based"? Also, may >> we update the title to include this definition? >> >> Original: >> Supporting Asymmetric Links in Low Power Networks: AODV-RPL >> ... >> For that purpose, this document specifies a reactive P2P >> route discovery mechanism for both hop-by-hop routes and source >> routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL >> protocol (AODV-RPL). >> >> Perhaps: >> AODV-RPL: The Routing Protocol for Low-Power and Lossy Networks (RPL) >> Based on Ad Hoc On-Demand Distance Vector (AODV) Routing >> ... >> For that purpose, this document specifies AODV-RPL - - the Routing Protocol >> for Low-Power and Lossy Networks (RPL) based on Ad hoc On-demand Distance >> Vector (AODV) routing. AODV-RPL is a reactive P2P route discovery mechanism >> for both hop-by-hop routes and source routing. >> >> (Note that we used "- -" in the text above to avoid issues in the xml >> comment. We will delete the space when updating the document.) >> --> > > This is O.K. with me. But doesn't it make the title too long? > >> 3) <!-- [rfced] Is "otherwise" needed at the end of this sentence? >> >> Original: >> AODV-RPL >> can be operated whether or not P2P-RPL or native RPL is running >> otherwise. >> >> Perhaps: >> AODV-RPL >> can be operated whether or not P2P-RPL or native RPL is also running. >> --> > > This is fine with me. > >> 4) <!-- [rfced] Section 2: Please review the following questions regarding >> the >> terminology list in this section. >> >> a.) Note that we have updated the expansion of AODV to align with usage in >> RFC >> 3561. >> >> Original: >> >> AODV >> Ad Hoc On-demand Distance Vector Routing [RFC3561]. >> >> Current: >> >> AODV >> Ad hoc On-Demand Distance Vector [RFC3561]. > > This is O.K. with me. > >> b.) Please review the definitions for "RREQ" and "RREP". Should these be >> updated to "Route Request" and "Route Reply", respectively? Text in the >> Introduction notes: "AODV terminology has been adapted for use with AODV-RPL >> messages, namely RREQ for Route Request, and RREP for Route Reply." >> >> Original: >> RREQ >> A RREQ-DIO message. >> >> RREQ-DIO message >> A DIO message containing the RREQ option. The RPLInstanceID in >> RREQ-DIO is assigned locally by the OrigNode. The RREQ-DIO >> message has a secure variant as noted in [RFC6550]. >> ... >> RREP >> A RREP-DIO message. >> >> RREP-DIO message >> A DIO message containing the RREP option. OrigNode pairs the >> RPLInstanceID in RREP-DIO to the one in the associated RREQ-DIO >> message (i.e., the RREQ-InstanceID) as described in Section 6.3.2. >> The RREP-DIO message has a secure variant as noted in [RFC6550]. >> >> Perhaps: >> RREQ >> Route Request >> >> RREQ-DIO message >> A DIO message containing the RREQ option. The RPLInstanceID in >> RREQ-DIO is assigned locally by the OrigNode. The RREQ-DIO >> message has a secure variant as noted in [RFC6550]. >> ... >> RREP >> Route Reply >> >> RREP-DIO message >> A DIO message containing the RREP option. OrigNode pairs the >> RPLInstanceID in RREP-DIO to the one in the associated RREQ-DIO >> message (i.e., the RREQ-InstanceID) as described in Section 6.3.2. >> The RREP-DIO message has a secure variant as noted in [RFC6550]. > > This is O.K. with me, I suppose. 'Route Request' seems to be compatible with > the few places where RREQ occurs without a following '-'. Maybe the title of > section 6.4 should be 'Receiving and Forwarding RREP' -- not sure! > > >> >> >> >> c.) Some terms in the list use initial capitalization (e.g., "Asymmetric >> Route") while others capitalize just the first word (e.g., "Symmetric >> route"). Is this intentional, or are any changes are needed for consistency? >> --> > > I think capitalizing only the first word is O.K. in the example given. > >> 5) <!-- [rfced] FYI - We added the following sentence to introduce the list >> of >> terms in Section 2. >> >> Updated: >> This document also uses the following terms: >> --> >> > > Sounds good to me. > >> 6) <!-- [rfced] Should "Type and Length fields" be updated to "Option Type >> and >> Option Length fields"? Note that this text appears several times in the >> document. >> >> Original: >> Option Length >> 8-bit unsigned integer specifying the length of the option in >> octets, excluding the Type and Length fields. >> >> Perhaps: >> Option Length >> 8-bit unsigned integer specifying the length of the option in >> octets, excluding the Option Type and Option Length fields. >> --> > > I think this is a good idea. > >> 7) <!-- [rfced] We updated "this example" to "these examples" in the second >> sentence below as we believe this refers to both Figures 4 and 5. Let us >> know if this is incorrrect. >> >> Original: >> In Figure 4 and Figure 5, BR is the Border Router, O is >> the OrigNode, each R is an intermediate router, and T is the >> TargNode. In this example, the use of BR is only for illustrative >> purposes; AODV does not depend on the use of border routers for its >> operation. >> >> Updated: >> In Figures 4 and 5, BR is the Border Router, O is >> the OrigNode, each R is an intermediate router, and T is the >> TargNode. In these examples, the use of BR is only for illustrative >> purposes; AODV does not depend on the use of border routers for its >> operation. >> --> > > This is fine with me. > >> 8) <!-- [rfced] Would it be helpful to align these titles (i.e., start each >> with >> an -ing verb and use RREQ and RREP rather than expansions)? >> >> Original: >> 6.1. Route Request Generation >> 6.2. Receiving and Forwarding RREQ Messages >> 6.3. Generating Route Reply (RREP) at TargNode >> 6.4. Receiving and Forwarding Route Reply >> >> Perhaps: >> 6.1. Generating RREQ >> 6.2. Receiving and Forwarding RREQ Messages >> 6.3. Generating RREP at TargNode >> 6.4. Receiving and Forwarding RREP >> --> > > This is fine with me. > >> 9) <!-- [rfced] May we update "If so" (and "If not" in the first sentence) as >> shown below for clarity?. >> >> a) >> >> Original: >> When a router X receives a RREQ message over a link from a neighbor >> Y, X first determines whether or not the RREQ is valid. If so, X >> then determines whether or not it has sufficient resources available >> to maintain the RREQ-Instance and the value of the 'S' bit needed to >> process an eventual RREP, if the RREP were to be received. If not, >> then X MUST either free up sufficient resources (the means for this >> are beyond the scope of this document), or drop the packet and >> discontinue processing of the RREQ. >> >> Perhaps (change "If so" to "If valid" and "If not" to "If not valid"): >> When a router X receives a RREQ message over a link from a neighbor >> Y, X first determines whether or not the RREQ is valid. If valid, X >> then determines whether or not it has sufficient resources available >> to maintain the RREQ-Instance and the value of the S bit needed to >> process an eventual RREP, if the RREP were to be received. If not valid, >> then X MUST either free up sufficient resources (the means for this >> are beyond the scope of this document), or drop the packet and >> discontinue processing of the RREQ. >> >> b) >> >> Original: >> Otherwise, the router MUST determine whether the downward (i.e., >> towards the TargNode) direction of the incoming link satisfies the >> OF. If so, the S bit of the RREQ-DIO to be transmitted is set to 1. >> Otherwise the S bit of the RREQ-DIO to be transmitted is set to 0. >> >> Perhaps ("If so" to "If it does"): >> Otherwise, the router MUST determine whether the downward direction >> (i.e., towards the TargNode) of the incoming link satisfies the >> OF. If it does, the S bit of the RREQ-DIO to be transmitted is set to 1. >> Otherwise, the S bit of the RREQ-DIO to be transmitted is set to 0. >> >> c) >> >> Original: >> If the S-bit of the RREQ-Instance is set to 0, the router MUST >> determine whether the downward direction of the link (towards the >> TargNode) over which the RREP-DIO is received satisfies the Objective >> Function, and the router's Rank would not exceed the RankLimit. If >> so, the router joins the DODAG of the RREP-Instance. >> >> Perhaps: >> If the S-bit of the RREQ-Instance is set to 0, the router MUST >> determine whether the downward direction of the link (towards the >> TargNode) over which the RREP-DIO is received satisfies the Objective >> Function and whether the router's Rank would not exceed the RankLimit. If >> these are true, the router joins the DODAG of the RREP-Instance. >> >> d) >> >> Original: >> The router next >> checks if one of its addresses is included in the ART Option. If so, >> this router is the OrigNode of the route discovery. >> >> Perhaps: >> The router next >> checks if one of its addresses is included in the ART option. If >> it is included, >> this router is the OrigNode of the route discovery. >> --> > > These changes are all fine with me. > >> 10) <!-- [rfced] May we update "and H=0" as follows to improve readability of >> this sentence? >> >> Original: >> Suppose a router has joined the RREQ-Instance, and H=0, and the S-bit >> of the RREQ-Instance is set to 1. >> >> Perhaps: >> Suppose a router has joined the RREQ-Instance, the H bit is set to 0, and >> the S bit >> of the RREQ-Instance is set to 1. >> --> > > Readability is in the eyes of the beholder, but it is O.K. with me to make > this change. Some people find it easier to read things that use fewer words > as long as there's no ambiguity. > >> 11) <!-- [rfced] This sentence appears in Section 6.3. Will readers >> understand >> what "the steps below" refer to? The subsections of Section 6.3 are not >> labeled "Step 1: ..." like the subsections in Sections 6.2 and 6.4. >> >> Original: >> If the link >> to Y can be used to transmit packets to OrigNode, TargNode generates >> a RREP according to the steps below. >> >> Perhaps: >> If the link >> to Y can be used to transmit packets to OrigNode, TargNode generates >> a RREP according to Sections 6.3.1 and 6.3.2. >> --> > > This is fine with me. > >> 12) <!-- [rfced] In the IANA Considerations section, may we remove "Option" >> from >> the Meaning column in Table 1? In the "RPL Control Message Options" >> registry, most of the entries do not include "Option", and the title of >> the registry already includes "Options". If this change is made, we will >> ask IANA to update the registry accordingly prior to publication. >> >> Link to registry: >> https://www.iana.org/assignments/rpl/rpl.xhtml#control-message-options >> >> Original: >> Value Meaning >> 0x0B RREQ Option >> 0x0C RREP Option >> 0x0D ART Option >> >> Perhaps: >> Value Meaning >> 0x0B RREQ >> 0x0C RREP >> 0x0D ART >> --> > > It is O.K. with me if you think it is an improvement. Does this align with > how IANA refers to option numbering in other RFCs? > >> 13) <!-- [rfced] Would it be helpful to point to Table 3 in the first >> sentence >> below? Also, may we update "useful ETX vs RSSI table" and "ETX versus >> RSSI values" as follows? >> >> Original: >> Since the ETX value is reflective of the extent of packet drops, >> it allowed us to prepare a useful ETX vs versus RSSI table. ETX >> versus RSSI values obtained in this way may be used as explained >> below: >> >> Perhaps: >> Since the ETX value is reflective of the extent of packet drops, >> it allowed us to prepare a useful table correlating ETX and RSSI values >> (see Table 3). ETX and RSSI values obtained in this way may be used >> as explained below: >> --> > > This is fine with me. > >> 14) <!-- [rfced] In the Acknowledgements section, we added a period after >> "H.M". >> Are any further updates (e.g., surname) needed? >> >> Original: >> The authors specially thank >> Lavanya H.M for implementing AODV-RPl in Contiki and conducting >> extensive simulation studies. >> >> Current: >> The authors specially thank >> Lavanya H.M. for implementing AODV-RPl in Contiki and conducting >> extensive simulation studies. >> --> > > I don't know of any other changes to the Acknowledgements unless it is > appropriate to acknowledge the efforts of the RFC editor team. > > ---------------------------------> End of what I was reviewed as of 9/22/2025 > <------------------------------------------------ > >> 15) <!-- [rfced] We note several author comments present in the XML. Please >> confirm that no updates related to these comments are outstanding. Note >> that the comments will be deleted prior to publication. --> > All the changes that we decided to make have already been made. However, I > am not at all clear on how deleting those comments would add value to the > document. Some people in the future might like to understand more about our > thought processes even if the .xml comments are not normative and do not > specify anything. > >> >> 16) <!-- [rfced] Terminology >> >> a.) We note inconsistencies in the terms below throughout the text. Should >> these be uniform? If so, please let us know which form is preferred. >> >> Also, if the capitalized form of any of these is used to indicate the name of >> a field, would it be helpful to add the word field after (e.g., change >> "Address Vector" to "Address Vector field")? If so, please update the xml >> file >> or indicate which instances should be updated using OLD/NEW format. >> >> RPLInstance >> RPL Instance >> RPL instance > Use RPL Instance. >> >> Destination Sequence Number >> destination sequence number > Use Destination Sequence Number. >> >> Sequence Number >> sequence number > Use Sequence Number. >> >> Intermediate Router >> Intermediate router >> intermediate router > Use Intermediate Router in titles, otherwise use Intermediate router at the > beginning of sentences, and use intermediate router otherwise. >> >> Rank >> rank > Use Rank. > >> Address Vector >> address vector > Use Address Vector. >> >> Next Hop >> next hop > Use next hop except when referring to the relevant information in the route > table entry. > >> source address >> Source Address >> >> destination address >> Destination Address > I think these are correct as currently used in the draft. As above, the > capitalization is used for the relevant information in the route table entry. >> >> lifetime >> Lifetime > Use lifetime except when referring to the relevant information in the route > table entry. >> >> >> b.) We note inconsistencies in the terms listed below. We chose the latter >> form. Please let us know any objections. >> >> RREP-instance >> RREP-Instance > Use RREP-Instance >> >> RREQ instance >> RREQ-Instance > Use RREQ-Instance. >> >> trickle timer >> Trickle timer >> Note: Per usage in RFC 6206. > Use Trickle timer. >> >> Target Option >> Target option >> Note: Per usage in RFC 6550 and for consistency with "RREQ option" and >> "RREP option". > Use Target option. >> >> ART Option >> ART option >> Note: For consistency with "RREQ option" and "RREP option". > Use ART option. >> >> >> c.) We note that RFC 9030 stylizes "6tisch" as "6TiSCH". May we >> update the text below for consistency with RFC 9030? >> >> Original: >> >> As an example, intermediate routers can use local information (e.g., bit >> rate, bandwidth, number of cells used in 6tisch [RFC9030])... > Yes, that's fine. > >> >> d.) The following forms are used in the document. For consistency, we have >> expanded these upon first use and updated subsequent instances to "G-RREP" >> and >> "G-RREP-DIO". Note that we used "G-RREP-DIO" (two hyphens). Let us know any >> concerns. >> >> Gratuitous RREP >> gratuitous RREP >> G-RREP >> >> "Gratuitous" RREP-DIO >> gratuitous RREP-DIO >> G-RREP DIO > No objection. > >> >> e.) The following forms are used in the document for bit names. We have >> updated to use the latter form with no hyphen and no single quote (i.e, S >> bit, >> D bit, and H bit). >> >> S-bit >> 'D' bit >> H bit > > That's fine with me. > >> >> f.) How are "RREP" and "RREQ" pronounced? As "are-rep" and "are-req"? We ask >> for guidance in order to choose the appropriate indefinite article for these >> to follow (i.e., “a" or "an"). >> >> Examples: >> >> an RREP-DIO >> a RREP-DIO >> >> an RREQ-Instance >> a RREQ-Instance >> --> > One is easier to pronounce, the other is easier to read. Please use the > indefinite article convention that is currently in use for other RFCs. > >> >> 17) <!-- [rfced] Abbreviations >> >> a.) We note the full expansion of "Objective Function" is frequently used >> after its abbreviation "OF" is introduced. For consistency, may we update to >> the abbreviation after first use? > That's fine with me. > >> b.) FYI - We made the following updates: >> >> Expected Number of Transmissions (ETX) > Expected Transmission Count (ETX) >> Note: For consistency with RFC 6551. >> >> Received Signal Strength Indication (RSSI) > Received Signal Strength >> Indicator (RSSI) >> Note: Both forms were used in the document. > That is fine with me. > >> c.) We have added expansions for abbreviations upon first use per Section 3.6 >> of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document >> carefully to ensure correctness. >> >> Directed Acyclic Graph (DAG) >> Operations, Administration, and Maintenance (OAM) >> --> > > That is also fine with me. >> >> >> 18) <!-- [rfced] References: >> >> a.) FYI - We have removed [RFC7991] in the References section. It was only >> cited in the Change Log, which was deleted. > No problem. >> >> >> b.) We found the following URL for the [co-ioam] reference: >> >> https://ieeexplore.ieee.org/document/8328276 >> >> May we add this URL (and the corresponding DOI 10.1109/COMSNETS.2018.8328276) >> to this reference? >> >> Original: >> [co-ioam] Rashmi Ballamajalu, Anand, S.V.R., and Malati Hegde, "Co- >> iOAM: In-situ Telemetry Metadata Transport for Resource >> Constrained Networks within IETF Standards Framework", >> 2018 10th International Conference on Communication >> Systems & Networks (COMSNETS) pp.573-576, January 2018. >> >> Perhaps: >> [co-ioam] Ballamajalu, R., Anand, S.V.R., and M. Hegde, "Co-iOAM: >> In-situ Telemetry Metadata Transport for Resource >> Constrained Networks within IETF Standards Framework", >> 2018 10th International Conference on Communication >> Systems & Networks (COMSNETS), pp. 573-576, >> DOI 10.1109/COMSNETS.2018.8328276, January 2018, >> <https://ieeexplore.ieee.org/document/8328276>. > Thanks for finding this. > >> >> c.) The reference entry for the [aodv-tot] reference included a commented-out >> DOI that leads to this URL: >> >> https://ieeexplore.ieee.org/document/749281 >> >> May we add this URL and the corresponding DOI to this reference? >> >> Original: >> [aodv-tot] Perkins, C.E. and E.M. Royer, "Ad-hoc On-demand Distance >> Vector Routing", Proceedings WMCSA'99. Second IEEE >> Workshop on Mobile Computing Systems and Applications , >> February 1999. >> >> Perhaps: >> [aodv-tot] Perkins, C.E. and E.M. Royer, "Ad-hoc On-demand Distance >> Vector Routing", Proceedings WMCSA'99. Second IEEE >> Workshop on Mobile Computing Systems and Applications, pp. >> 90-100, DOI 10.1109/MCSA.1999.749281, February 1999, >> <https://ieeexplore.ieee.org/document/749281>. > Yes, that's fine. > >> >> d.) We found the following URL for the [empirical-study] reference: >> >> https://ieeexplore.ieee.org/document/6231290 >> >> May we add this URL (and the corresponding DOI 10.1109/MCOM.2012.6231290) to >> this reference entry? >> >> Original: >> [empirical-study] >> Prasant Misra, Nadeem Ahmed, and Sanjay Jha, "An empirical >> study of asymmetry in low-power wireless links", IEEE >> Communications Magazine (Volume: 50, Issue: 7), July 2012. >> >> Perhaps: >> [empirical-study] >> Misra, P., Ahmed, N., and S. Jha, "An empirical study of >> asymmetry in low-power wireless links", IEEE >> Communications Magazine, vol. 50, no. 7, pp. 137-146, >> DOI 10.1109/MCOM.2012.6231290, July 2012, >> <https://ieeexplore.ieee.org/document/6231290>. >> --> >> > Yes, that's fine. > >> 19) <!-- [rfced] Please review the "Inclusive Language" portion of the online >> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >> and let us know if any changes are needed. Updates of this nature typically >> result in more precise language, which is helpful for readers. >> >> For example, please consider whether the following can be updated in the >> instances below: >> >> a.) "native" >> >> Original: >> These P2P routes may differ from routes discoverable by native RPL. >> >> AODV-RPL can be operated whether or not P2P-RPL or native RPL is running >> otherwise. > You can use "by RPL[RFC6550]". >> b.) "blacklisting" >> >> Original: >> ...in particular, flagging Route Errors, "blacklisting" unidirectional links >> ([RFC3561]), multihoming, and handling unnumbered interfaces. >> --> >> > You can use "blocking the use of" (not in quotation marks). > >> Thank you. >> >> Kaelin Foody and Rebecca VanRheenen >> RFC Production Center > Many thanks to you. > > Regards, > Charlie P. > > ===================== end of further changes as of 9/27/2025 ================ >> >> > >> >>> On Sep 9, 2025, at 7:50 PM, satish anamalamudi <[email protected]> >>> wrote: >>> >>> Hello All, >>> >>> I am okay with the suggested changes. I approve this RFC for publication. I >>> thank the RFC team for their effort in publishing this draft. >>> >>> Regards, >>> Satish >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> With Regards, >>> Dr. Satish Anamalamudi, PhD., >>> >>> >>> >>> On Tue, 9 Sep 2025 at 11:04 PM, S.V.R.Anand <[email protected]> wrote: >>> Hello All, >>> >>> The suggested corrections look good for me! I thank the RFC Editor team for >>> their great work. I approve this RFC for publication. >>> >>> Regards >>> Anand >>> >>> On Mon, Sep 01, 2025 at 10:19:41PM -0700, [email protected] wrote: >>> >>>> *****IMPORTANT***** >>>> >>>> Updated 2025/09/01 >>>> >>>> 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://authors.ietf.org/rfcxml-vocabulary>. >>>> >>>> * 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 using ‘REPLY ALL’ as all >>>> the parties CCed on this message need to see your changes. The parties >>>> include: >>>> >>>> * your coauthors >>>> >>>> * [email protected] (the RPC team) >>>> >>>> * other document participants, depending on the stream (e.g., >>>> IETF Stream participants are your working group chairs, the >>>> responsible ADs, and the document shepherd). >>>> >>>> * [email protected], which is a new archival mailing list >>>> to preserve AUTH48 conversations; it is not an active discussion >>>> list: >>>> >>>> * More info: >>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>>> >>>> * The archive itself: >>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>> >>>> * Note: If only absolutely necessary, you may temporarily opt out >>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>> If needed, please add a note at the top of the message that you >>>> have dropped the address. When the discussion is concluded, >>>> [email protected] will be re-added to the CC list and >>>> its addition will be noted at the top of the message. >>>> >>>> You may submit your changes in one of two ways: >>>> >>>> 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 CCed on this message need to see your approval. >>>> >>>> >>>> Files >>>> ----- >>>> >>>> The files are available here: >>>> https://www.rfc-editor.org/authors/rfc9854.xml >>>> https://www.rfc-editor.org/authors/rfc9854.html >>>> https://www.rfc-editor.org/authors/rfc9854.pdf >>>> https://www.rfc-editor.org/authors/rfc9854.txt >>>> >>>> Diff file of the text: >>>> https://www.rfc-editor.org/authors/rfc9854-diff.html >>>> https://www.rfc-editor.org/authors/rfc9854-rfcdiff.html (side by side) >>>> >>>> Alt-diff of the text (allows you to more easily view changes >>>> where text has been deleted or moved): >>>> https://www.rfc-editor.org/authors/rfc9854-alt-diff.html >>>> >>>> Diff of the XML: >>>> https://www.rfc-editor.org/authors/rfc9854-xmldiff1.html >>>> >>>> >>>> Tracking progress >>>> ----------------- >>>> >>>> The details of the AUTH48 status of your document are here: >>>> https://www.rfc-editor.org/auth48/rfc9854 >>>> >>>> Please let us know if you have any questions. >>>> >>>> Thank you for your cooperation, >>>> >>>> RFC Editor >>>> >>>> -------------------------------------- >>>> RFC9854 (draft-ietf-roll-aodv-rpl-20) >>>> >>>> Title : Supporting Asymmetric Links in Low Power Networks: AODV-RPL >>>> Author(s) : C. Perkins, S.V.R. Anand, S. Anamalamudi, B. Liu >>>> WG Chair(s) : Ines Robles, Remous-Aris Koutsiamanis >>>> >>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde >>>> >>>> >>>> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
