[manet] Tsvart last call review of draft-ietf-manet-dlep-multi-hop-extension-06

Bob Briscoe via Datatracker <noreply@ietf.org> Tue, 09 April 2019 11:22 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 7E26C12078A; Tue, 9 Apr 2019 04:22:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Bob Briscoe via Datatracker <noreply@ietf.org>
To: <tsv-art@ietf.org>
Cc: draft-ietf-manet-dlep-multi-hop-extension.all@ietf.org, manet@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <155480892243.14232.8537433440288444332@ietfa.amsl.com>
Date: Tue, 09 Apr 2019 04:22:02 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/hArsxJACZLctU9IBUG-Odfk4qms>
Subject: [manet] Tsvart last call review of draft-ietf-manet-dlep-multi-hop-extension-06
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: Tue, 09 Apr 2019 11:22:04 -0000

Reviewer: Bob Briscoe
Review result: Ready with Issues

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

AFAICT, there's nothing technically wrong, but I believe the authors use of
normative text does not convey the meaning they intended, in nearly every case.
 It will be seen below that there seems to be a general misunderstanding of the
use of, 'SHOULD do X' when there will never be a case when X should not be
done. 'SHOULD' and 'MAY' need to be used judiciously, because they make
interoperability harder.

==Inappropriate Normative Text==

S.2.
"The use of the Multi-Hop Forwarding Extension SHOULD be configurable. "
{I think you mean it SHOULD be possible to enable/disable the extension? On a
modem. a router or both? In what circumstances would it not be configurable (if
none, then MUST would be appropriate)? What happens if one device uses the
extension and another doesn't? This last question also applies for incremental
deployment.}

S.3.1.
"The Hop Count Data Item SHOULD be carried in the Destination Up, Destination
Update, Destination Announce Response, and Link Characteristics Response
messages." {I don't think the use of "SHOULD" here achieves what you intend. I
think you're trying to say that this data item can only be carried in these 4
messages. But what you've said is that all these messages SHOULD contain a Hop
Count data item. If any normative text is needed here, I think it would say
this data item MUST NOT be carried in messages other than these 4. But maybe
just substitute 'SHOULD' with 'can'?}

S.3.2.
The Hop Control Data Item MAY be carried in a Session Update Message sent by a
router when the control applies to the whole device, or a Link Characteristics
Request Message when the control applies to a particular destination. {Again, I
think you're trying to say, "If used, the Hop Control Data Item MUST only be
carried in" ...one of these two message types.}

"A modem that receives the Hop Control Data Item in a [XXX] Message SHOULD take
whatever actions are needed to make the change indicated by the data item for
[YYY]." (two occurrences) {Inappropriate use of SHOULD: a) Surely a modem MUST
"take whatever actions are needed." Why would it not? b) Anyway, it's
meaningless to normatively require a vaguely defined action}

S.3.2.3 Direction Connection

"It indicates that the modem SHOULD attempt to establish a direct connection
with the destination identified in the message." {I think you mean 'MUST'. Why
would it not even attempt to?}

"This action SHOULD only be sent for destinations for which the Hop Count is
greater than 1 and has the P-Bit set in the previously received Hop Count Data
Item." {I think you mean MUST. Why would it be sent otherwise?}

S.3.2.4. Suppress Forwarding
I suggest that you don't gratuitously switch from 'MUST' to 'SHALL' just for
this section? Many implementers search the text for 'MUST'.

==Authentication==

S.4.
RFC8175 says
   'For all "networked deployments" ..., the implementation and use of TLS are
   STRONGLY RECOMMENDED.'

I believe it would be worth identifying which extensions would be unsafe if TLS
were not used. Certainly all the Multi-Hop Extensions would be unsafe if not
authenticated.

==General Nits==
Inappropriate and/or inconsistent capitalization of certain phrases, like 'Data
Item' or 'Action' or 'Message'.

==Specific Nits==
I've provided suggested corrections in the following xml files:
http://bobbriscoe.net/tmp/draft-ietf-manet-dlep-multi-hop-extension-06_BB.xml
http://bobbriscoe.net/tmp/draft-ietf-manet-dlep-multi-hop-extension-06_BB.txt
http://bobbriscoe.net/tmp/draft-ietf-manet-dlep-multi-hop-extension-06_BB-DIFF-06.html