[Cbor] Benjamin Kaduk's No Objection on draft-ietf-cbor-cddl-control-06: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 21 October 2021 06:43 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: cbor@ietf.org
Delivered-To: cbor@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8413A1009; Wed, 20 Oct 2021 23:43:19 -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-cbor-cddl-control@ietf.org, cbor-chairs@ietf.org, cbor@ietf.org, christian@amsuess.com, christian@amsuess.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <163479859923.26389.9202872336721142535@ietfa.amsl.com>
Date: Wed, 20 Oct 2021 23:43:19 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/x84QhvOc6Fpd_o4xUiNQ1to8Vdc>
Subject: [Cbor] Benjamin Kaduk's No Objection on draft-ietf-cbor-cddl-control-06: (with COMMENT)
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Oct 2021 06:43:26 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-cbor-cddl-control-06: No Objection

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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Does the inclusion of RFC 7405 as a normative reference imply that the
%s"" construct is part of the core grammar used by .abnf and .abnfb?
My understanding was that just saying "ABNF" did not by default include
the case-sensitivity functionality (regardless of what references are
present), and so that it might be appropriate for us to say something
like "the ABNF control operators defined by this document allow use of
the case-sensitive extensions defined in [RFC7405]".

Section 2.1

   interval<BASE> = (
     BASE => int             ; lower bound
     (BASE .plus 1) => int   ; upper bound
     ? (BASE .plus 2) => int ; tolerance

I'm having a really hard time coming up for a use case where making the
tolerance depend on the base of the interval by an affine transformation
is useful.  It feels a bit contrived as an example.

Section 4

   (enable/disable).  The latter approach could for instance be used for
   a JSON/CBOR switch, as illustrated in Figure 9.

I'd suggest something like "as illustrated in Figure 9 using SenML
[RFC8428] as the example data model used with both JSON and CBOR".  (The
main goal being to get the 8428 reference in.)

Section 6

The shepherd writeup indicates that the author has a complete
implementation, so it's surprising to not see it mentioned in this
Implementation Status section [that is to be removed prior to
publication as an RFC, so this comment itself is somewhat pointless].

Section 7

I would suggest that the ABNF security considerations would also imply,
except that both referenced documents disclaim any such considerations
(not even "what you actually describe may not be what you think you are
describing" or "ABNF just says whether a given string matches the
constraints of a given construction, and does not require a unique
interpretation of the string").

I might also consider mentioning that the behavior of the "floor" function
(for converting floating-point values to integers) on negative inputs
invariably surprises some people (i.e., it is not "round to zero").