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