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

Bob Briscoe <> Fri, 17 May 2019 20:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1D90120046; Fri, 17 May 2019 13:39:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zEXiUWfJeUF6; Fri, 17 May 2019 13:39:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E238120158; Fri, 17 May 2019 13:39:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding: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=m0SxyHEVP7wpRI1W3Osrvmsn1xbMAzaX9eFQOh3SqgE=; b=4gtSe/ZHHzAGRVndV75b0oWPj MApVmSNvHPgrh+eHKN/eXh0Jvkh5Rcbo1Lsxkymui/9oDLEkqwgBr5lTtu3JK+wnHu1/BGsqjmN+I ktJWnzZF3ThUEzby9Sogb9Ug6sW+doNwB7NXwqMS2q1TROtN24gmszvB+t1j4l7X9PbejPI+MZIJ3 YfJkfSC9psTHIL3rZR1zTscDvn8H69n0aXfDFkN0nDe2LV8plcEYnUa/KYniziT7NegyOLbhYe8Nu rR5RX9iJZvQc+lVkKDNjqcCSAgs9mlKh9EexiLzN6JtsDz89pIxswEbd9WgwzlikGWX0Q9rXcm1De +qQIcK0aQ==;
Received: from [] (port=60290 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <>) id 1hRjdp-0001B9-VO; Fri, 17 May 2019 21:39:46 +0100
To: Lou Berger <>,
References: <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Fri, 17 May 2019 21:39:44 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------29CF8890E9EEAF14027AC68A"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [manet] Tsvart last call review of draft-ietf-manet-dlep-multi-hop-extension-06
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mobile Ad-hoc Networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 May 2019 20:39:54 -0000


On 25/04/2019 16:45, Lou Berger wrote:
> Hi Bob,
> 	Sorry for the late reply. See below for specific responses.
And sry for my longer delay replying...

> 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
>> 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.
[BB] It's just ambiguous. "Configurable" usually means "capable of 
having its settings configured". Yes, "the use of" makes it more likely 
that you mean "the ability to use", but it's just not clearly written.
>> 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.
[BB] I think you've missed my point, which is about ambiguous meaning of 
sentences, not a technical question.

But before we get to that, there was a prerequisite question about this 
sentence in my editorial nits file. The full sentence said:

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

My nit question about this sentence was:
"{Does this 'when >1' clause apply to all 4 messages, or just Link 
Characteristic Response messages?}"

You've just ignored this and left the sentence as it was. Did you not 
understand my question? if so, you could have asked.

The grammar of the sentence reads as "The Hop Count Data Item SHOULD be 
carried in the first three message types (whatever the hop count), and 
in the fourth message type (when the hop count is >1). I doubt you meant 
that. If not, the sentence ought to be disambiguated as follows:

    When the Hop Count to a destination is greater than one (1), the Hop
    Count Data Item SHOULD be carried in the Destination Up, Destination
    Update, Destination Announce Response, and Link Characteristics Response

Next, let's return to the SHOULD. This means that, even when count > 1, 
it doesn't have to be included in these messages. The next para says:

    The absence of the Hop Count Data Item MUST be interpreted by the
    router as a Hop Count value of one (1).

So, when count > 1, you say it doesn't have to be carried in these 
messages,... so the router will assume it is 1, even tho it isn't. Is 
that what you intended to say? If so, surely you need to say under what 
circumstances a hop count >1 would not be carried in these messages.

It all seems very vague to me.

>> 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" of these two message types.}
[BB] Actually, perhaps you didn't mean to use normative text at all. 
Perhaps you just meant

    The Hop Control Data Item would be carried in...

>> "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}
[BB] You didn't respond to this point.
>> 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.
[BB] I meant "This action MUST only be sent for destinations for which 
... count >1 & P set ...". I don't think that would cause errors, would it?

Again, my point is about use of English, not technical. I'm picking up 
every case where you say "SHOULD" and working out what exceptions your 
English allows. By using "SHOULD only be sent" rather than "MUST only be 
sent", it allows exceptions to 'only' not to 'sent'. So it means 
"although this action will normally solely be sent for destinations with 
count>1 & P set, it could be sent for other destinations..." which, as 
you say yourself, would cause errors.

I don't think you actually need normative text here anyway. I think you 
used 'SHOULD' because you were trying to say something like: "the action 
can only be sent for destinations with count > 1 & P set (but for those 
destinations the action doesn't have to be sent)."

Or perhaps you really do need normative text here for interop in order 
to avoid dlep errors, and you meant to say: "The action MUST NOT be sent 
for destinations that do not have count>1 & P set ..."

This is all becoming rather painful, 'cos you don't seem to be getting 
that I'm just trying to improve the highly ambiguous English around the 
normative text. However, it's hard 'cos I'm not sure what you were 
trying to mean in the first place.

>> 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
>> 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.
[BB] Again, you're not grocking that I am questioning the use of 
RECOMMENDED, which is equivalent to SHOULD, and therefore weaker than 
MUST, even with STRONGLY added. (BTW, STRONGLY isn't a normative word 
defined in RFC2119).

If you are only saying STRONGLY RECOMMENDED, you are still saying 
implementers don't have to use TLS. If you really don't want to require 
them to, then it is always best to explain why you are not saying MUST 
(e.g. perhaps to allow for deployments in trusted environments).

>> ==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:
On a quick look, I found a couple of nits still:

3.2.4. Suppress Forwarding
s/Impact to destination hop counts are provided to the router by the 
modem as described above./
  /The impact on destination hop counts is provided to the router by the 
modem as described above./
If you didn't mean that, you can't leave the sentence like it is.

Security Considerations:
s/Similar attacks are generally possible base DLEP,/
  /Similar attacks are generally possible in base DLEP,/

> Thanks!
> I've pushed changes to and
> will coordinate an update with the AD.
> Lou

>> _______________________________________________
>> manet mailing list

Bob Briscoe