[manet] Benjamin Kaduk's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 11 April 2019 01:00 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 EC057120125; Wed, 10 Apr 2019 18:00:58 -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-pause-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.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <155494445891.22757.7399588752085896470.idtracker@ietfa.amsl.com>
Date: Wed, 10 Apr 2019 18:00:58 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/qyfN7exMASitgI0RajBeG_moeFQ>
Subject: [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
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, 11 Apr 2019 01:00:59 -0000
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? 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. 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"? 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. 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. ---------------------------------------------------------------------- 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. 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? 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! 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.
- [manet] Benjamin Kaduk's Discuss on draft-ietf-ma… Benjamin Kaduk via Datatracker
- Re: [manet] Benjamin Kaduk's Discuss on draft-iet… Lou Berger
- Re: [manet] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [manet] Benjamin Kaduk's Discuss on draft-iet… Lou Berger
- Re: [manet] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [manet] Benjamin Kaduk's Discuss on draft-iet… Lou Berger