Hi Charlie, Anand, and Satish,
Thank you for your approvals; we have marked them on the AUTH48 status page for
this document here: https://www.rfc-editor.org/auth48/rfc9854.
We will assume your approval stands even if your coauthors submit further
changes unless we hear objections at that time.
Please note that we are unable to move this document forward in the publication
process until all document-specific questions are resolved and we have received
approval from the final author. We have included these questions at the end of
this email for your convenience.
Thank you!
Kaelin Foody
RFC Production Center
--------------------------------------
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
-->
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.)
-->
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.
-->
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].
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].
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?
-->
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:
-->
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.
-->
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.
-->
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
-->
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.
-->
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.
-->
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.
-->
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
-->
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:
-->
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.
-->
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. -->
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
Destination Sequence Number
destination sequence number
Sequence Number
sequence number
Intermediate Router
Intermediate router
intermediate router
Rank
rank
Address Vector
address vector
Next Hop
next hop
source address
Source Address
destination address
Destination Address
lifetime
Lifetime
b.) We note inconsistencies in the terms listed below. We chose the latter
form. Please let us know any objections.
RREP-instance
RREP-Instance
RREQ instance
RREQ-Instance
trickle timer
Trickle timer
Note: Per usage in RFC 6206.
Target Option
Target option
Note: Per usage in RFC 6550 and for consistency with "RREQ option" and
"RREP option".
ART Option
ART option
Note: For consistency with "RREQ option" and "RREP 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])...
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
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
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
-->
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?
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.
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)
-->
18) <!-- [rfced] References:
a.) FYI - We have removed [RFC7991] in the References section. It was only
cited in the Change Log, which was deleted.
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>.
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>.
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>.
-->
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.
b.) "blacklisting"
Original:
...in particular, flagging Route Errors, "blacklisting" unidirectional links
([RFC3561]), multihoming, and handling unnumbered interfaces.
-->
Thank you.
Kaelin Foody and Rebecca VanRheenen
RFC Production Center
> 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]
