Re: [manet] Benjamin Kaduk's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS and COMMENT)

Lou Berger <lberger@labn.net> Mon, 06 May 2019 01:22 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 716FE12008C for <manet@ietfa.amsl.com>; Sun, 5 May 2019 18:22:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.099
X-Spam-Level: ***
X-Spam-Status: No, score=3.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 m7CnkinxVXH4 for <manet@ietfa.amsl.com>; Sun, 5 May 2019 18:22:19 -0700 (PDT)
Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 9A999120048 for <manet@ietf.org>; Sun, 5 May 2019 18:22:19 -0700 (PDT)
Received: from CMGW (unknown [10.9.0.13]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id 272C3400A7 for <manet@ietf.org>; Sun, 5 May 2019 19:22:18 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id NSKghKQ7peyBxNSKghjxF2; Sun, 05 May 2019 19:22: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=P41/6n5+IUQUNAhyju3R/a0g1OhEg/m8RGWfDH0FnaE=; b=2KMTTqi6LBmgtv2jV2gc7TLkgW zHhvyyL7jEUDu7gJoKTKZLimec6zs5d2UldNWVbXiZ3gRJQ6GOKQgGyj5li3rM2VvufmNOmMNjN4S SkRJBuBEsoAfJNUMxV1mupbaQ;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:54954 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 1hNSKf-0028FW-TR; Sun, 05 May 2019 19:22:17 -0600
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
Cc: draft-ietf-manet-dlep-pause-extension@ietf.org, manet@ietf.org, manet-chairs@ietf.org
References: <155494445891.22757.7399588752085896470.idtracker@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: <e20c4e6d-b36f-690c-2049-4bc81f5cd37a@labn.net>
Date: Sun, 5 May 2019 21:22: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: <155494445891.22757.7399588752085896470.idtracker@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: 1hNSKf-0028FW-TR
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]:54954
X-Source-Auth: lberger@labn.net
X-Email-Count: 8
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Org: HG=bhcustomer;ORG=bluehost;
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/X8Kph5MC4cA78gEwrA1t0XsCZ8A>
Subject: Re: [manet] Benjamin Kaduk's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS and COMMENT)
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: Mon, 06 May 2019 01:22:21 -0000

Hi,
	My apologies, I thought I responded to this, but can't seem to find the
response (hopefully my responses are consistent if I did!).

On 4/10/19 9:00 PM, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-manet-dlep-pause-extension-06: Discuss
> 
> 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-pause-extension/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Section 3.1 defines 'Scale' as a four-bit unsigned integer field but only the
> values 0-3 are assigned, leaving 4-16k usable.  How will future values be
> assigned?
> 

A future revision or update of this document.  We discussed a IANA
registry, but thought it overkill as future additions seem quite unlikely.

> In Section 3.1.1:
> 
>    DS Field Qn:
> 
>       The data item contains a sequence of 8 bit DS Fields.  The number
>       of DS Fields present MUST equal the sum of all Num DSCPs field
>       values.
> 
> Perhaps I'm misreading, but I thought the Num DSCPs Qn field was global
> for this queue index, so there would just be one of them and no need to
> take a sum.

It's just saying that more than one DSCP can match to a single queue
index value.


> 
> In Section 3.3:
> 
>    A router which receives the Restart Data Item SHOULD resume
>    transmission of the identified traffic to the modem.
> 
> Why is this only a "SHOULD"?

to cover the case where the router is choosing not to send data, e.g.,
due to lack of available data or other policy such as traffic rate shaping.

> 
> Section 4
> 
>                                  The extension does not inherently
>    introduce any additional vulnerabilities above those documented in
>    [RFC8175].  [...]
> 
> As noted by others, this sentence is just not true.
> I will not duplicate the suggestions for additional considerations that
> need to be documented.  

Please see comments / discussion elsewhere on this.

> In particular, I agree with Roman that the use
> of TLS needs to be mandatory, especially since this protocol is
> nominally only defined for use with radio links.


As covered elsewhere, in particular this is really a comment on base
DLEP and I think this extension should be consistent with that document.
(Consider an example from when 8175 was issued, consider the case where
the modem and router use MACsec, 802.1X and 802.1 AE, why is TLS needed
as well.)

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 3.1
> 
>                                 Any errors or inconsistencies
>    encountered in parsing Sub Data Items are handled in the same fashion
>    as any other Data Item parsing error encountered in DLEP.
> 
> I had a hard time finding the indicated behavior in RFC 8175 -- "error"
> does not appear at all (and "erroneous" only twice, for IP address
> processing, v4 and v6); "parse" only appears once (in the Session
> Initialization State); "inconsistent" apprears several times but I did
> not see one that seemed to be a generic catch-all case.  It's probably
> worth putting in a section reference or changing the text to use
> keywords that are searchable in RFC 8175.
> 
I've added the typical text from 8175to remove any ambiguity:

      In particular, the receiving implementation MUST issue a
      Session Termination Message containing a Status Data Item with
      status code set to 130 'Invalid Data' and transition to the
      Session Termination state.

> Section 3.1.1
> 
>    Queue Size Qn:
> 
>       A 24-bit unsigned integer representing the size, in the octet
>       scale indicated by the Scale field, of the queue supporting
>       traffic with the DSCPs associated with the queue index.
> 
> Is there any value in including a specific sentinel value that indicates
> that the modem cannot or does not wish to state the size of the
> corresponding queue?

As here is no requirement for the modem to set this, I'm not sure if
there would be any value in such.

> 
> Section 3.2
> 
>    A router which receives the Pause Data Item MUST cease sending the
>    identified traffic to the modem.  This may of course translate into
>    the router's queues exceeding their own thresholds.  If a received
>    Pause Data Item contains a Queue Index value other than 255, or a
>    queue index established by a Session Initialization or Session Update
>    Message, the router MUST terminate the session with a Status Data
>    Item indicating Invalid Data.
> 
> This would be a nit, but actually has serious functional consequences:
> remove the comma after "255".  The current text says that if the router
> receives a queue index established by a Session Initialization message,
> the router MUST terminate the session, which does not seem to be the
> intent!

done.

> 
> Section 3.3
> 
>    The Restart Data Item is used by a modem to indicate to its peer that
>    transmission of previously suppressed traffic may be resumed.  An
>    example of when a modem might send this data item is when an internal
>    queue length drops below a particular threshold.
> 
> This seems like a fine place to suggest the application of hysteresis
> (i.e., that the "particular threshold" here might be lower than the one
> indicated in Section 3.2).
> 
> Section 5.x
> 
> It's not clear to me what value there is in repeating the registration
> policy of the registries from which codepoints are being allocated.
> IANA will apply the correct policy, and the reader of this document
> doesn't need to care what policy was applied.

This section will get revised as part of final processing so defer to
both IANA and the RFC editor on this.

Thanks!
Lou
> 
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>