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

Lou Berger <lberger@labn.net> Thu, 25 April 2019 16:13 UTC

Return-Path: <lberger@labn.net>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EBC12006F for <manet@ietfa.amsl.com>; Thu, 25 Apr 2019 09:13:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JjBEISbOE1m for <manet@ietfa.amsl.com>; Thu, 25 Apr 2019 09:13:27 -0700 (PDT)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1694120048 for <manet@ietf.org>; Thu, 25 Apr 2019 09:13:27 -0700 (PDT)
Received: from cmgw15.unifiedlayer.com (unknown [10.9.0.15]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 33173140D6A for <manet@ietf.org>; Thu, 25 Apr 2019 09:45:18 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id JgYohEn2UszDUJgYohOtdc; Thu, 25 Apr 2019 09:45:18 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=W8NP2q7utFe7mDuRGMcwjb5rwE5eEfKn8AXAeL4qMk0=; b=yiiUsLKofbYakOwajzFolzTLch Re3YgkYgzULaQHh+79qAP11W7pGKk0kwXvnVqA0gBb04F1qn/i4UsvqHmqbImVqf+DeT9jaZqAMSc 6PpplMFCgWaQL9PLYB+mDdRqD;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:52238 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <lberger@labn.net>) id 1hJgYn-002hh8-Se; Thu, 25 Apr 2019 09:45:17 -0600
To: Bob Briscoe <ietf@bobbriscoe.net>, tsv-art@ietf.org
Cc: draft-ietf-manet-dlep-multi-hop-extension.all@ietf.org, manet@ietf.org, ietf@ietf.org
References: <155480892243.14232.8537433440288444332@ietfa.amsl.com>
From: Lou Berger <lberger@labn.net>
Openpgp: preference=signencrypt
Autocrypt: addr=lberger@labn.net; prefer-encrypt=mutual; keydata= mQENBERW5dYBCAC1Bjgr/mVovBhi1rbqkowJShVtvLitNEGOTd6RtmwO7FPebg61J9+kRFTz 1wt869yiAjtQO1EtQs26QFTH5ZDZJU/LDAOzxTi12mpBic+AWI8W0yrB1C+KOZ0gw2p7Vnfj EKc3ohwkCICHTnZ3blO8Mslb4qHGxDm7Uy3luRjvH1ZDifuZvfFHcHVw2dJyGwLg2MhXCqpo OyUqFN0tlGqz1TOCAy3/IMG6OdNK27DGF5+vJyIqek/2xkIVDOLgzVCek3dARLqPP37W1Lx2 uXJUsgcJ7t7om5AEV2LTFrafvAvJbKLT9RZ0fgF4LXeRTIVlFXKkvYJFgygW+r4JCTvHABEB AAG0HUxvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+iQGHBBABAgBxBQJEVuXyMBSAAAAA ACAAB3ByZWZlcnJlZC1lbWFpbC1lbmNvZGluZ0BwZ3AuY29tcGdwbWltZQcLCQgHAwIKAhkB GRhsZGFwOi8va2V5c2VydmVyLnBncC5jb20FGwMAAAADFgIBBR4BAAAABBUICQoACgkQgbLN W8HBX9eB9QgAl8/lFnNh43at51P//sRX8cDg33C/biok8st8Fff0Y/6p+6HkYKQcxiuZuOLr HHtBFxTdMGfFrlJIFob/N6m92CwVwoTRZu8QIe68DLewd+72PIEzvlSy/iTq3e91XqfGWCE7 oqw7H/weJJlB7yzPWXra/BwgPD+WkTxUiKeG2F2HzBTQfBQ6VpHiMqW6AL0jcCh/Drya93ZA aAdWfW2ywVPqIKETZIk04SBsZCw9WESB2If/NqeZu/DNwBg4FsXCrfp3WfMSTkYmfT3zcU11 MpKcv20YUpG8Jf9lyMY1DgMHHdpUHdjo/fuLz4aVSQvt8EygRSzCxGWOWb89bUosAbkBDQRE VuXXAQgApBEy7m0+xMm4SEcQtFi/UQQqjVOllc2227M1ypbcEMRa46Tq6p0P5QBM9C9pxjAl tyI2m3hzvBxBJNnjknXTp875DGyj/yDwj9VeA18Tj9q6PRsJIxAnGKBgWO0yGdZLpsp0AN5n kMamxdVFGYojzUiwkPBayST6sEUp33o4xHsx99TA2bFxZRj6k0igWgdrPVq4qeEgD1l7Cl3f pj96owzm+7wecswAts2b545gfR4/V/Vx3VUebETR/LwMDecXokP5fiDAIRHhEUi/+FXcwg6w 6jtPilFcJ64HJP6P81OUdfeMDUxvSmbeRqXaZrbRN+hF6XfWODTKepsqPaX8TQARAQABiQEi BBgBAgAMBQJEVuXXBRsMAAAAAAoJEIGyzVvBwV/XUcMH/2eB6dvsP52su9KgaDHqsgPbxF21 AQL9oDCheN+AJKD3Eouj/d/MbQdsp/M/pjgTAqB3G4/rtoyJw+BDjnvZwdUe4HQ656IPZOub e10sOgq1taJQZtQIl+mWKURMGlIihScYeuGfi/1RzMqXeCcFW63n5POVG55FzU8B7DBwQ2oJ Zy7NL0YVbT0ROXGson6WHLhzGnVP8CjHq5TN5co/FH/2BntaQIdSaOmTqN+vy38KkRsYa3cx k9eTbP99ypebZclmw6kxlOZGl9DBp4qNkTn/7LgQ7iZNVyESs9rSE7hQXnmfM+C+TCpeZo62 8AwC5SYEqa5YlkpgsP0NIEMAIoU=
Message-ID: <8b06996c-a16f-cf33-2c78-8a4733522ac6@labn.net>
Date: Thu, 25 Apr 2019 11:45:16 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <155480892243.14232.8537433440288444332@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 72.66.11.201
X-Source-L: No
X-Exim-ID: 1hJgYn-002hh8-Se
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net (fs2.dc.labn.net) [72.66.11.201]:52238
X-Source-Auth: lberger@labn.net
X-Email-Count: 5
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/S2AGfKjpsO_v9kXPfr9SP3WQdg8>
Subject: Re: [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
Precedence: list
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, 25 Apr 2019 16:13:30 -0000

Hi Bob,
	Sorry for the late reply. See below for specific responses.

On 4/9/19 7:22 AM, Bob Briscoe via Datatracker wrote:
> 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?

To me that's what this says.

> On a
> modem. a router or both? 
yes, by any node that supports the extension.

> In what circumstances would it not be configurable (if
> none, then MUST would be appropriate)?
We generally don't stop people from building products that meet their
specific market requirements as long as there's no interop issue, hence
the SHOULD vs MUST.> What happens if one device uses the
> extension and another doesn't? This last question also applies for incremental
> deployment.}
This is covered in the base DLEP RFC.

> 
> 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'?}
> 

I'd be fine with MAY as this is more aligned with RFC8175 statement of
what DIs to carry in a message.  This siad, I believe the feeling was
that MAY was too weak for an extension-specific DI.  Unless there is
strong objection with this, I'm inclined to leave it with how the WG
approved it.

> 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

this should be Direct 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?}
> 

local policy, or that it know that a connection is no longer possible.

> "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?}

A must would translate to a dlep error on the receiving side, which
would translate to a session reset, which is really disruptive.

> 
> 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.

umm, I think all of DLEP would be unsafe without TLS, or some other
equivalent, e.g., macsec.

> 
> ==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

Thanks!
I've pushed changes to https://github.com/louberger/dlep-extensions and
will coordinate an update with the AD.
Lou
> 
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>