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

Lou Berger <> Tue, 07 May 2019 14:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 579CA120043 for <>; Tue, 7 May 2019 07:42:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.1
X-Spam-Level: ***
X-Spam-Status: No, score=3.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (768-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4Xt_KobceQpP for <>; Tue, 7 May 2019 07:42:15 -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 960FB120157 for <>; Tue, 7 May 2019 07:42:12 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id C47F41ADBD5 for <>; Tue, 7 May 2019 08:34:59 -0600 (MDT)
Received: from ([]) by cmsmtp with ESMTP id O1BLhqAlmsFwgO1BLhqmQ4; Tue, 07 May 2019 08:34:59 -0600
X-Authority-Reason: nr=8
X-Authority-Analysis: v=2.3 cv=P/gUeBIu c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10:nop_charset_1 a=xqWC_Br6kY4A:10:nop_ipv6 a=E5NmQfObTbMA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=48vgC7mUAAAA:8 a=RC5-ijVT858AEFDaw74A:9 a=SCG8YGdjpUg6_aZu:21 a=GA4wWs8jr_PHhDo7:21 a=QEXdDO2ut3YA:10:nop_charset_2 a=mYAOWqAtFUkA:10:demote_hacked_domain_1 a=1dbGxDndw2gA:10:demote_hacked_domain_7 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; 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=Pr0i2UxKucL2S+Xg/GWhY1TtdkFzFEpnQ2AYdCtDkog=; b=0XTXX+pREVzawZGWVB+0mf7Vl9 8NneDP/oX9FXM63dR1vtcIFizDeXfFh3fjBdwoFDkm1dfYJxwY6ypHSSrOAJZiUnM//n8XEVRcU3/ H0+zciToYcrAwVGH1Nv/nn5ga;
Received: from ([]:46282 helo=[IPv6:::1]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <>) id 1hO1BL-003637-6U; Tue, 07 May 2019 08:34:59 -0600
To: Benjamin Kaduk <>
Cc: The IESG <>,,,
References: <> <> <>
From: Lou Berger <>
Message-ID: <>
Date: Tue, 07 May 2019 10:34:57 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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-BWhitelist: no
X-Source-L: No
X-Exim-ID: 1hO1BL-003637-6U
X-Source-Sender: ([IPv6:::1]) []:46282
X-Email-Count: 9
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <>
Subject: Re: [manet] Benjamin Kaduk's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS and COMMENT)
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: Tue, 07 May 2019 14:42:18 -0000

Please see responses below...

On 5/6/2019 6:40 PM, Benjamin Kaduk wrote:
> On Sun, May 05, 2019 at 09:22:16PM -0400, Lou Berger wrote:
>> 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
>>> for more information about IESG DISCUSS and COMMENT positions.
>>> The document, along with other ballot positions, can be found here:
>>> ----------------------------------------------------------------------
>>> ----------------------------------------------------------------------
>>> 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.
> Okay.  The Discuss was just to make sure it was considered in some fashion;
> we do have a bunch of documents that explictly note "additional values are
> to be allocated by updates to this specification" but I do not insist on
> it.
>>> 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.
> Okay, if I'm looking at the figure properly then this is just an editorial
> issue, then:
>          0                   1                   2                   3
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |  Queue Index  |             Queue Size Qn                     |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         | Num DSCPs Qn  |  DS Field Qn  |              ...              :
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         :                          ...                  |  DS Field Qn  |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> So we have the chunk of stuff for a given queue (index), and the size of
> that queue, then a separate array/length for the DS values.  The various DS
> values that can match this queue index are the contents of this array, but
> this is the only array in the sub data item describing this queue index.
> If that's correct, then isn't the description of "DS Field Qn" just "The
> sub data item contains a sequence of 8 bit DS Fields for this queue index.
> The number of DS Fields present MUST equal this value."?

Yes - I'm fine with a specific text revision if you have one.

>>> 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.
> Okay.  Frequently documents will give the reader some hint as to what the
> exceptional cases might be, but I will not insist on it here.
>>> 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.
> Sorry, most of these threads have aged out of my cache; could you give me a
> hint about whose ballot thread to look in, or a link?

Perhaps it's just best to point you at the current text and see if 
you're okay with it -- see

and let me/us know if you still have any unresolved comments.

>>> 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.)
> Perhaps.  I think it's highly dependent on whether DLEP is only conveyed
> over wired links and the physical scope of those links, though -- my
> understanding is that most of the IESG was treating this protocol as
> running over the radio link.

umm, DLEP is *NEVER* expected to run over the air.  This is covered in 
RFC8175 and is not impacted by this extension.



>>> ----------------------------------------------------------------------
>>> ----------------------------------------------------------------------
>>> 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.
> Thanks.
>>> 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.
> Sounds good!
> Thanks,
> Ben