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]
