[manet] Benjamin Kaduk's No Objection on draft-ietf-manet-dlep-multi-hop-extension-06: (with COMMENT)
Benjamin Kaduk via Datatracker <firstname.lastname@example.org> Thu, 02 May 2019 01:59 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 649CF1202A7; Wed, 1 May 2019 18:59:05 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Benjamin Kaduk via Datatracker <email@example.com>
To: "The IESG" <firstname.lastname@example.org>
Cc: email@example.com, Stan Ratliff <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Reply-To: Benjamin Kaduk <email@example.com>
Date: Wed, 01 May 2019 18:59:05 -0700
Subject: [manet] Benjamin Kaduk's No Objection on draft-ietf-manet-dlep-multi-hop-extension-06: (with COMMENT)
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Thu, 02 May 2019 01:59:06 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-manet-dlep-multi-hop-extension-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-multi-hop-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Roman's Discuss. I think that there's room in the document to add some of the clarifications made in response to the TSV-art review, especially regarding the "exception cases" responsible for SHOULD-level requirements as opposed to MUST-level requirements. Section 1 forwarding in intermediate modems. This document refers to forwarding by intermediate modems as 'multi-hop forwarding'. example using . DLEP Destination messages can be used to report such nit: there seems to be some formatting issue or extraneous pasted text here. It is important to note that the use of the hop control mechanism defined in this can result in connectivity changes and even loss of the ability to reach one or more destinations. The defined mechanism nit: missing word ("this document", perhaps?) will report such connectivity changes, but the details of what a router does or how it reacts to such are out scope of this document. nit: maybe s/to such/to such reports/? Section 2 The use of the Multi-Hop Forwarding Extension SHOULD be configurable. To indicate that the extension is to be used, an implementation MUST include the Multi-Hop Forwarding Extension Type Value in the Extensions Supported Data Item. [...] Is the configurability for exposing that the feature is available (in the Extensions Supported data item)? (Independently of that answer?) I don't think the second MUST is appropriate, as it is just duplicating a requirement from RFC 8175. Section 3.1 The Hop Count Data Item is used by a modem to indicate the number of modem that transmits/sends data to reach a particular destination, nit: "modems" plural and "transmit/send" to match. The Hop Count Data Item SHOULD be carried in the Destination Up, Destination Update, Destination Announce Response, and Link Characteristics Response Messages when the Hop Count to a destination is greater than one (1). I'm not sure that the response to the tsv-art review addressed the key question, namely: should this data item be carried in messages other than the four listed here? The current text makes no statement either way, but the reviewer seemed to think that the intent was to suggest that it did not make sense to carry the Hop Count Data Item in messages not listed here. Is that incorrect? A router receiving a Hop Count Data Item can use this information in its forwarding and routing decisions, and specific use is out of scope of this document. The absence of the Hop Count Data Item MUST be interpreted by the router as a Hop Count value of one (1). This "MUST" may not be forward-looking, in the case where some future extension supersedes this one and so a message lacks a Hop Count Data Item but has some other indicator of a greater-than-one hop count. To phrase it differently, in some sense this text is attempting to place a constraint on implementations that do not implement this specification. Perhaps the declarative "is interpreted" is less problematic. Section 3.2 The modem MUST also notify the router of each destination that is not identified in the Link Characteristics Response Message and has a changed Hop Count impacted via a Destination Update Message. nit: "changed" and "impacted" seem redundant. For both the Session Update and Link Characteristic Request cases, we only talk about Destination Down and Destination Update messages. Is there any case where we might need to send a Destination Up message in response to the changes effected by a Hop Control Data Item (or is that requirement already imposed by RFC 8175 in a part that I didn't read)? Section 3.2.4 A modem which receives the Suppress Forwarding Data Item in a Session Update Message MUST suppress multi-hop forwarding on a device wide basis. This means that data traffic originating from the modem's peer router SHALL only be sent by the modem to destinations that are one modem hop away, and that any data traffic received by the modem from another modem that is not destined to the peer router SHALL be dropped. [...] nit(?): I'm not sure I understand the meaning of "destined to the peer router", here. It feels more natural if I instead say "destined to itself", but perhaps this is because I am using "peer" to refer to modem-level peering and this is instead intended to reflect a relationship between the modem and router components of a single DLEP entity. Section 4 I don't think that "The extension does not inherently introduce any additional threats above those documented in [RFC8175]." is really correct -- as Roman notes, we are setting up control messages to change the configuration of the radio hardware in ways not envisioned by RFC 8175 (i.e., "re-aiming the antenna"), as well as the explicit software "suppress" controls. With the Link Characteristics Request Message, this risk is implicit. With the Hop Control mechanism defined in this document it is more likely. From a nit: I don't think "implicit" conveys quite the intended meaning; perhaps "implicit and small" is better. security perspective, implementations should be aware of this increased risk and may choose to implement additional configuration control mechanisms to ensure that the Hop Control mechanism is only used under conditions intended by the network operator. (It seems like in practice this will mean the TLS requirement Roman mentions, for almost all environments, though perhaps I am missing some details.) Section 5.3 I agree with Barry that some guidance to the expert is probably in order.
- [manet] Benjamin Kaduk's No Objection on draft-ie… Benjamin Kaduk via Datatracker