Subject: [manet] DLEP-11 comments

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Tue, 12 May 2015 11:00:54 +0000

Hi,

Please find below my (belated) comments on DLEP version -11 (which should apply to -12 as well)

Thanks,
Ronald

<start of comments>

(Somewhat) Major
-----------------------

* I think the document could benefit from a short applicability statement, either as a separate section or added to the Assumptions section (2). In particular, the following should/could be addressed:
- Is the modem assumed to act as a transparent layer 2 bridge for data traffic in all cases?  (The text in section 2 on the signalling in Destination Up messages of MAC addresses for delivering data traffic suggests as much, but this could be made more explicit).
- The Introduction mentions different methods of physically connecting modem devices to routers. It says, that in the case of Ethernet or serial attachment, routers are not aware of radio link related events and characteristics. It goes on to state, that this is one of the challenges that DLEP addresses. However, given the reliance of DLEP on the use of MAC addresses, I don't see how DLEP could help in the case a modem is connected to router by means of a serial link.
- Although it has been stated that DLEP is agnostic to the routing protocol being used, I wonder whether it works as well for a reactive MANET routing protocol as for a pro-active MANET routing protocol. The Abstract says, that routers need characteristics of wireless links to make better _forwarding_ decisions. Shouldn't that be, at least in the case of pro-active MANET protocols: better _routing_ decisions? After routes have been installed in the FIB, the forwarding is nothing more than a next hop lookup. Not sure how in this works for reactive MANET protocols.

* Section 7.5, Peer Update Signal
- 2nd paragraph: If modems that do not track Layer 3 addresses are to silently ignore a Peer Update signalling an address change, whereas modems that _do_ track Layer 3 addresses are to respond with a Peer Update ACK, how should the router determine whether to retransmit or not? (In other words, HOW would the router obtain the knowledge to do what the 4th paragraph of this section says it SHOULD do?) Would it not be more robust if the modem were required to always respond with a Peer Update ACK, which in the non-tracking case should contain a Status data item with an appropriate Status Code (e.g., Request Denied)? Also note the last sentence of section 7.5, which states that a Peer Update signal MUST be acknowledged by the receiver issuing a Peer Update ACK signal. This seems to contradict the "silent ignoring" above.
- Why does the address update mechanism described here (i.e., Peer Update from router to modem with address change causes Destination Update on the far end of the radiolink) apply only to simple addresses and not to IPv4 or IPv6 attached subnets?

* Section 7.7, Peer Termination Signal
- 5th/6th paragraph: Interpreting the absence of a Status data item in the Peer Termination as an implicit Status Code 'Success' does not make sense to me. I think that in a Peer Termination Signal, the Status data item should be seen more as a 'Reason' data item, reflecting _why_ the connection is being torn down. In fact, a separate data item could have been specified for this purpose. Barring that, in my view a more useful interpretation of the absence of a Status data item would be: 'Unspecified reason for termination'. Note that  at the time the peer initiating termination sends this signal, it is by no means certain that termination will indeed be graceful: What if the other side does not respond with a Peer Termination ACK signal?

* Section 11, IANA considerations
- Repositories for Signal Types and Data Item (Types) are requested, with provisions for experimental types of both. However, I do not see similar provisions for signals and data items of Extensions. Section 3.2 claims: " The requests for IANA-controlled registries in this document contain sufficient reserved space, both in terms of DLEP signals and DLEP data items, to accommodate future extensions to the protocol and the data transferred". However, as it is now, it seems possible for IANA to allocate values for all signals and data items currently defined in the document and reserve all the remaining values for experimental signals and data items, respectively, leaving no space for Extensions. (But it may well be that I don't understand how this works!) 

Minor
-------

Section 1, Introduction:
- First paragraph, 4th sentence: "It is also quite possible that link quality and datarate varies" should be: It is also quite possible that link quality and datarate vary ...

- An example involving an 802.11g access point is given. Even though Wi-Fi is ubiquitous these days, it wouldn't hurt to add an informative reference to IEEE 802.11. Furthermore, "g" is an obsolete indication, as this amendment has been rolled into IEEE 802.11 several revisions ago. Finally, there does not seem to be anything "g"-specific about the example, as most, if not all, PHY variants feature multiple transmission rates.

Section 1.1, Protocol overview:
- ( I agree with Christopher Dearlove's comment on the "signals" terminology).

- last sentence: "The specific algorithms ..... is outside ..." should be:  The specific algorithms ..... are outside ... Likewise: "is left": are left

Section 1.2, Requirements
- An old favourite: "NOT RECOMMENDED" is missing. (See Errata to RFC 2119).

Section 2, Assumptions
- 2nd paragraph, last sentence: "it is strongly recommended that implementations ..." should be: it is strongly RECOMMENDED that implementations ...

-4th paragraph; "It is recommended that DLEP implementations utilize IPv6 link-local addresses ..." should/could be: It is RECOMMENDED  that DLEP implementations utilize IPv6 link-local addresses ..."

Section 4, Metrics
- 2nd paragraph: "As mentioned in the introduction section of this document, DLEP allows for metrics to be sent within two contexts " ; I did not see this mentioned in the Introduction - it talks about per-destination information, but does not mention "modem-wide" metrics.

- 3rd paragraph: "In order to introduce a new metric type, DLEP modem implementations MUST terminate the session with the router ... and re-establish the session" should this not be: "In order to introduce a new metric type, DLEP modem implementations MUST terminate the session with the router ... and wait for the router to re-establish the session" ?

- 5th paragraph: " however, the specific algorithms (precedence, etc.) for utilizing the dual-context metrics is out of scope ..." should be: "... are out of scope".

Section 5
- " (see Appendix A and B for flow diagrams of the discovery signal)" should be: "(see Appendix A for flow diagrams of the discovery signal ", as the flow diagrams in Appendix B do not show Peer Discovery signalling.

Sections 5.1, 5.2 and 5.3
- All mention of UDP and TCP sockets in these sections is implementational detail that is best avoided. It is conceivable that routers and /or modems implement DLEP using a mechanism different from the socket paradigm. A protocol specification should restrict itself to describing externally observable behaviour.

Section 5.4, Common Session Flow
- 4th paragraph: "In cases where metrics are provided at peer level, the receiver MUST propagate the metrics to all destinations in its information base that are accessed via the originator". Better would be: " ....to all entries  in its information base for destinations that are accessed via the originator". (Makes it more clear that this is purely a peer-internal administrative action). 

Section 6, DLEP Signal Processing
- Section could be renamed to DLEP Signal Structure and Processiing to better cover its contents.

Section 6.1, DLEP Signal Header
- Definition of Signal Type: "One of the DLEP Signal Type values defined in this document" should be: An 8-bit unsigned integer field specifying one of the DLEP Signal Type values defined in this document.
- Definition of Length field: "The length, expressed as a 16-bit unsigned integer, of all of the DLEP data items associated with this signal" should be: The length in bytes, expressed as a 16-bit unsigned integer, of all of the DLEP data items associated with this signal.

Section 6.2, DLEP Generic Data Item
- Definition of Length field: "The length, expressed as an 8-bit unsigned integer, of the value field of the data item" should be: The length in bytes, expressed as an 8-bit unsigned integer, of the value field of the data item.

Section 7.3, Peer Initialization Signal
- 4th paragraph: "timeout and retry heurestics" should be "timeout and retry heuristics"

Sections 7.3 and 7.4
- The capitalisation of NO, NOT and BOTH in these sections is a bit questionable, as these are not RFC 2119 Imperatives. I think the associated MUSTs provide sufficient emphasis.

Section 7.10, Destination Up ACK Signal
- last sentence: "retry heurestics" should be: retry  heuristics.

Section 7.12, Destination Down ACK Signal
- last sentence: "retry heurestics" should be: retry  heuristics.

Section 7.15, Link Characteristics Request Signal
- 2nd paragraph, last sentence: " Issuing a Link Characteristics Request with ONLY the MAC Address data item is a mechanism a peer MAY use to request metrics (via the Link Characteristics ACK) from its partner." The wording leaves open which sides the "peer" and "its partner" are. The remove any ambiguity, this could be rephrased as: " Issuing a Link Characteristics Request with ONLY the MAC Address data item is a mechanism a router MAY use to request metrics (via the Link Characteristics ACK) from the modem." (Supposing that's the intended meaning!)

Section 8.2, Status
- 1st paragraph, last sentence: " ... to indicate the success or failure of the previously received signal." This is not true for Status data items in Peer Termination signals. See earlier comment on section 7.7.
- Definition of Text field, 1st sentence: "describing an problem" should be: describing a problem.

Section 8.6, Heartbeat Interval
- 2nd paragraph, 2nd sentence: "implementations MAY indicates the desire ..." should be: implementations MAY indicate the desire...
- "non 0" -> non-0 ?

Section 8.12, IPv4 Attached Subnet
- First sentence: " The DLEP IPv4 Attached Subnet allows a device to declare that it has an IPv4 subnet (e.g., a stub network) attached, ..." add: or that it has become aware of an IPv4 subnet being present at a remote destination.
- 1st paragraph: Capitalised NOT is NOT :-) an RFC 2119 Imperative. Sentence could be rephrased: In case a previously declared IPv4 Attached Subnet needs to be withdrawn, the associated Destination MUST be brought down (via the Destination Down signal (Section 7.11)) and then a Destination Up signal MUST be re-issued, without the IPv4 Attached Subnet data item.
- Definition of Subnet Mask field: Technically, this is not a subnet mask, but a prefix length.

Section 8.13, IPv6 Attached Subnet
- First sentence: " The DLEP IPv6 Attached Subnet allows a device to declare that it has an IPv6 subnet (e.g., a stub network) attached, ..." add: or that it has become aware of an IPv6 subnet being present at a remote destination.
- 1st paragraph: Capitalised NOT is NOT :-) an RFC 2119 Imperative. Sentence could be rephrased: As in the case of the IPv4 attached Subnet data item above, when a previously declared IPv6 Attached Subnet needs to be withdrawn, the associated Destination MUST be brought down (via the Destination Down signal (Section 7.11)) and then a Destination Up signal MUST be re-issued, without the IPv6 Attached Subnet data item.
- Definition of Subnet Mask field: Technically, this is not a subnet mask, but a prefix length.

Section 8.19, Resources (Receive)
- RESR field: What if a received Resources (Receive) data item contains a RESR value greater than 100? Should the connection be torn down?

Section 8.20, Resources (Transmit)
 - REST field: What if a received Resources (Transmit) data item contains a REST value greater than 100? Should the connection be torn down?

Section 8.21, Relative Link Quality (Receive)
- RLQR field: What if a received Relative Link Quality (Receive) data item contains a RLQR value greater than 100? Should the connection be torn down?

Section 8.22, Relative Link Quality (Transmit)
- RLQT field: What if a received Relative Link Quality (Transmit) data item contains a RLQT value greater than 100? Should the connection be torn down?

Section 8.23, Link Characteristics ACK Timer
- 1st sentence: "The Link Characteristics ACK Timer data item MAY appear in the Link Characteristics Request signal (Section 7.15) to indicate the desired number of seconds to the sender will wait for a response to the request." should be:  The Link Characteristics ACK Timer data item MAY appear in the Link Characteristics Request signal (Section 7.15) to indicate the desired number of seconds the sender will wait for a response to the request.
- Definition of Interval field: "has been lost" should be: "lost"

Section 9, Credit-Windowing
- Last paragraph: " MUST include a Extensions Supported data item" should be: MUST include an Extensions Supported data item.

Section 9.1.3, Destination Update Signal
- If the Destination Update Signal contains both the (mandatory) Credit Window Status data item and the (optional) Credit Grant data item, does the Receive Window value in the former already reflect the increment? 

Section 9.2, Credit-Windowing Data Items
- "MUST correctly process the following data items without error": "without error" seems redundant.

Section 9.2.1, Credit Grant
- 2nd paragraph: "If the receiver of a Destination Up signal ... supports credits, the receiver  MUST either reject the use of credits for this destination ..." should this read: "... does not support credits, ...." ?
- Below format diagram: 'Reserved' field should be: Credit Increment field?
- What do credits represent? Bytes? Could not find this anywhere! 

<enf of comments>

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 12 May 2015 22:07:58 -0400

Ronald,

Thank you for the review. I have incorporated most of your recommendations,
save for two (I believe). I not my rationale inline below.

With DLEP-13, I believe the outstanding review items have been addressed.

Regards,
Stan

On Tue, May 12, 2015 at 7:00 AM, Velt, R. (Ronald) in 't <
[email-masked]> wrote:

> * I think the document could benefit from a short applicability statement,
> either as a separate section or added to the Assumptions section (2). In
> particular, the following should/could be addressed:
> - Is the modem assumed to act as a transparent layer 2 bridge for data
> traffic in all cases?  (The text in section 2 on the signalling in
> Destination Up messages of MAC addresses for delivering data traffic
> suggests as much, but this could be made more explicit).
>

I disagree. After some reflection and discussion with the other authors, we
came to the conclusion that mandating operation of a transparent bridge at
layer 2 was overly pedantic. The key text is in paragraph 4 of section 2
(Assumptions):  "DLEP assumes that the MAC address for delivering data
traffic is the MAC specified in the Destination Up signal (Section 7.9).
No manipulation or substitution is performed; the MAC address supplied in
Destination Up is used as the OSI Layer 2 Destination MAC address. DLEP
also assumes that MAC addresses MUST be unique within the context of a
router-modem session."

- The Introduction mentions different methods of physically connecting
> modem devices to routers. It says, that in the case of Ethernet or serial
> attachment, routers are not aware of radio link related events and
> characteristics. It goes on to state, that this is one of the challenges
> that DLEP addresses. However, given the reliance of DLEP on the use of MAC
> addresses, I don't see how DLEP could help in the case a modem is connected
> to router by means of a serial link.
> - Although it has been stated that DLEP is agnostic to the routing
> protocol being used, I wonder whether it works as well for a reactive MANET
> routing protocol as for a pro-active MANET routing protocol. The Abstract
> says, that routers need characteristics of wireless links to make better
> _forwarding_ decisions. Shouldn't that be, at least in the case of
> pro-active MANET protocols: better _routing_ decisions? After routes have
> been installed in the FIB, the forwarding is nothing more than a next hop
> lookup. Not sure how in this works for reactive MANET protocols.
>

I changed "forwarding" to "routing" in the abstract. As to operation with
MANET reactive protocols? To be honest, I don't know. That is (at least to
me) part of the reason why DLEP specifies the signals to traverse the
modem-router connection, but does NOT specify what is done with the
signals. As an example, I can see some avenues for experimentation with
DLEP and reactive protocols, but I don't have any idea what the results
would be.

> - 2nd paragraph: If modems that do not track Layer 3 addresses are to
> silently ignore a Peer Update signalling an address change, whereas modems
> that _do_ track Layer 3 addresses are to respond with a Peer Update ACK,
> how should the router determine whether to retransmit or not? (In other
> words, HOW would the router obtain the knowledge to do what the 4th
> paragraph of this section says it SHOULD do?) Would it not be more robust
> if the modem were required to always respond with a Peer Update ACK, which
> in the non-tracking case should contain a Status data item with an
> appropriate Status Code (e.g., Request Denied)? Also note the last sentence
> of section 7.5, which states that a Peer Update signal MUST be acknowledged
> by the receiver issuing a Peer Update ACK signal. This seems to contradict
> the "silent ignoring" above.
> - Why does the address update mechanism described here (i.e., Peer Update
> from router to modem with address change causes Destination Update on the
> far end of the radiolink) apply only to simple addresses and not to IPv4 or
> IPv6 attached subnets?
>

The original design of DLEP was that a router, by connecting to a given
modem, would already have access to the connected subnets of the local
modem. Only subnets on the far-end need to be advertised.

> - 5th/6th paragraph: Interpreting the absence of a Status data item in the
> Peer Termination as an implicit Status Code 'Success' does not make sense
> to me. I think that in a Peer Termination Signal, the Status data item
> should be seen more as a 'Reason' data item, reflecting _why_ the
> connection is being torn down. In fact, a separate data item could have
> been specified for this purpose. Barring that, in my view a more useful
> interpretation of the absence of a Status data item would be: 'Unspecified
> reason for termination'. Note that  at the time the peer initiating
> termination sends this signal, it is by no means certain that termination
> will indeed be graceful: What if the other side does not respond with a
> Peer Termination ACK signal?
>

I think the text pretty clearly states that you MUST respond.

> - Repositories for Signal Types and Data Item (Types) are requested, with
> provisions for experimental types of both. However, I do not see similar
> provisions for signals and data items of Extensions. Section 3.2 claims: "
> The requests for IANA-controlled registries in this document contain
> sufficient reserved space, both in terms of DLEP signals and DLEP data
> items, to accommodate future extensions to the protocol and the data
> transferred". However, as it is now, it seems possible for IANA to allocate
> values for all signals and data items currently defined in the document and
> reserve all the remaining values for experimental signals and data items,
> respectively, leaving no space for Extensions. (But it may well be that I
> don't understand how this works!)
>

I looked at this text, and don't see anything we need to change. The IANA
reservations for experimental items in both registries will only be for two
or three items, no more. The rest of the registry will be reserved.

>
> Minor
> -------
>
> Section 1, Introduction:
> - First paragraph, 4th sentence: "It is also quite possible that link
> quality and datarate varies" should be: It is also quite possible that link
> quality and datarate vary ...
>
> - An example involving an 802.11g access point is given. Even though Wi-Fi
> is ubiquitous these days, it wouldn't hurt to add an informative reference
> to IEEE 802.11. Furthermore, "g" is an obsolete indication, as this
> amendment has been rolled into IEEE 802.11 several revisions ago. Finally,
> there does not seem to be anything "g"-specific about the example, as most,
> if not all, PHY variants feature multiple transmission rates.
>

Noted. Not changed, but noted... ;-)

>
> - last sentence: "The specific algorithms ..... is outside ..." should
> be:  The specific algorithms ..... are outside ... Likewise: "is left": are
> left
>
> - 2nd paragraph, last sentence: "it is strongly recommended that
> implementations ..." should be: it is strongly RECOMMENDED that
> implementations ...
>
> -4th paragraph; "It is recommended that DLEP implementations utilize IPv6
> link-local addresses ..." should/could be: It is RECOMMENDED  that DLEP
> implementations utilize IPv6 link-local addresses ..."
>
> Section 4, Metrics
> - 2nd paragraph: "As mentioned in the introduction section of this
> document, DLEP allows for metrics to be sent within two contexts " ; I did
> not see this mentioned in the Introduction - it talks about per-destination
> information, but does not mention "modem-wide" metrics.
>
> - 3rd paragraph: "In order to introduce a new metric type, DLEP modem
> implementations MUST terminate the session with the router ... and
> re-establish the session" should this not be: "In order to introduce a new
> metric type, DLEP modem implementations MUST terminate the session with the
> router ... and wait for the router to re-establish the session" ?
>
> - 5th paragraph: " however, the specific algorithms (precedence, etc.) for
> utilizing the dual-context metrics is out of scope ..." should be: "... are
> out of scope".
>
> Section 5
> - " (see Appendix A and B for flow diagrams of the discovery signal)"
> should be: "(see Appendix A for flow diagrams of the discovery signal ", as
> the flow diagrams in Appendix B do not show Peer Discovery signalling.
>
> - All mention of UDP and TCP sockets in these sections is implementational
> detail that is best avoided. It is conceivable that routers and /or modems
> implement DLEP using a mechanism different from the socket paradigm. A
> protocol specification should restrict itself to describing externally
> observable behaviour.
>
> - 4th paragraph: "In cases where metrics are provided at peer level, the
> receiver MUST propagate the metrics to all destinations in its information
> base that are accessed via the originator". Better would be: " ....to all
> entries  in its information base for destinations that are accessed via the
> originator". (Makes it more clear that this is purely a peer-internal
> administrative action).
>
> - Definition of Signal Type: "One of the DLEP Signal Type values defined
> in this document" should be: An 8-bit unsigned integer field specifying one
> of the DLEP Signal Type values defined in this document.
> - Definition of Length field: "The length, expressed as a 16-bit unsigned
> integer, of all of the DLEP data items associated with this signal" should
> be: The length in bytes, expressed as a 16-bit unsigned integer, of all of
> the DLEP data items associated with this signal.
>
> - Definition of Length field: "The length, expressed as an 8-bit unsigned
> integer, of the value field of the data item" should be: The length in
> bytes, expressed as an 8-bit unsigned integer, of the value field of the
> data item.
>
> - The capitalisation of NO, NOT and BOTH in these sections is a bit
> questionable, as these are not RFC 2119 Imperatives. I think the associated
> MUSTs provide sufficient emphasis.
>
> - 2nd paragraph, last sentence: " Issuing a Link Characteristics Request
> with ONLY the MAC Address data item is a mechanism a peer MAY use to
> request metrics (via the Link Characteristics ACK) from its partner." The
> wording leaves open which sides the "peer" and "its partner" are. The
> remove any ambiguity, this could be rephrased as: " Issuing a Link
> Characteristics Request with ONLY the MAC Address data item is a mechanism
> a router MAY use to request metrics (via the Link Characteristics ACK) from
> the modem." (Supposing that's the intended meaning!)
>

I didn't change anything here, either. Don't think the restriction is a
requirement, though I do not have a use case yet for modems asking about
metrics from a router, although it could...

Regards,
Stan

>
> Section 8.2, Status
> - 1st paragraph, last sentence: " ... to indicate the success or failure
> of the previously received signal." This is not true for Status data items
> in Peer Termination signals. See earlier comment on section 7.7.
> - 2nd paragraph, 2nd sentence: "implementations MAY indicates the desire
> ..." should be: implementations MAY indicate the desire...
> - "non 0" -> non-0 ?
>
> - First sentence: " The DLEP IPv4 Attached Subnet allows a device to
> declare that it has an IPv4 subnet (e.g., a stub network) attached, ..."
> add: or that it has become aware of an IPv4 subnet being present at a
> remote destination.
> - 1st paragraph: Capitalised NOT is NOT :-) an RFC 2119 Imperative.
> Sentence could be rephrased: In case a previously declared IPv4 Attached
> Subnet needs to be withdrawn, the associated Destination MUST be brought
> down (via the Destination Down signal (Section 7.11)) and then a
> Destination Up signal MUST be re-issued, without the IPv4 Attached Subnet
> data item.
> - First sentence: " The DLEP IPv6 Attached Subnet allows a device to
> declare that it has an IPv6 subnet (e.g., a stub network) attached, ..."
> add: or that it has become aware of an IPv6 subnet being present at a
> remote destination.
> - 1st paragraph: Capitalised NOT is NOT :-) an RFC 2119 Imperative.
> Sentence could be rephrased: As in the case of the IPv4 attached Subnet
> data item above, when a previously declared IPv6 Attached Subnet needs to
> be withdrawn, the associated Destination MUST be brought down (via the
> Destination Down signal (Section 7.11)) and then a Destination Up signal
> MUST be re-issued, without the IPv6 Attached Subnet data item.
> - RESR field: What if a received Resources (Receive) data item contains a
> RESR value greater than 100? Should the connection be torn down?
>
>  - REST field: What if a received Resources (Transmit) data item contains
> a REST value greater than 100? Should the connection be torn down?
>
> - RLQR field: What if a received Relative Link Quality (Receive) data item
> contains a RLQR value greater than 100? Should the connection be torn down?
>
> - RLQT field: What if a received Relative Link Quality (Transmit) data
> item contains a RLQT value greater than 100? Should the connection be torn
> down?
>
> - 1st sentence: "The Link Characteristics ACK Timer data item MAY appear
> in the Link Characteristics Request signal (Section 7.15) to indicate the
> desired number of seconds to the sender will wait for a response to the
> request." should be:  The Link Characteristics ACK Timer data item MAY
> appear in the Link Characteristics Request signal (Section 7.15) to
> indicate the desired number of seconds the sender will wait for a response
> to the request.
> - Last paragraph: " MUST include a Extensions Supported data item" should
> be: MUST include an Extensions Supported data item.
>
> - If the Destination Update Signal contains both the (mandatory) Credit
> Window Status data item and the (optional) Credit Grant data item, does the
> Receive Window value in the former already reflect the increment?
>
> - 2nd paragraph: "If the receiver of a Destination Up signal ... supports
> credits, the receiver  MUST either reject the use of credits for this
> destination ..." should this read: "... does not support credits, ...." ?
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>