[manet] Benjamin Kaduk's No Objection on draft-ietf-manet-dlep-multi-hop-extension-06: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 02 May 2019 01:59 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: manet@ietf.org
Delivered-To: manet@ietfa.amsl.com
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)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-manet-dlep-multi-hop-extension@ietf.org, Stan Ratliff <sratliff@idirect.net>, aretana.ietf@gmail.com, manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <155676234540.2806.2619122792728039226.idtracker@ietfa.amsl.com>
Date: Wed, 01 May 2019 18:59:05 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/S_s0i5MB1DJqL_D0ASQ80kjm24U>
Subject: [manet] Benjamin Kaduk's No Objection on draft-ietf-manet-dlep-multi-hop-extension-06: (with COMMENT)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?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:


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

   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

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

Section 5.3

I agree with Barry that some guidance to the expert is probably in