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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 20 Oct 2021 23:43:19 -0700

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:
https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl-control/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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").

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Oct 2021 13:39:09 +0200

Hi Ben,

thank you for these detailed and thoughtful comments!

All the resulting changes below are now in
https://github.com/cbor-wg/cddl-control/pull/13

Yes, that is the intention.

> the case-sensitive extensions defined in [RFC7405]".

Interesting!  I live in a world that has pretty much completed the transition, and so I thought just always referencing 5234 and 7405 together would be sufficient indication.

I put into terminology:

   The term ABNF in this specification stands for the combination of
   [RFC5234] and [RFC7405], i.e., the ABNF control operators defined by
   this document allow use of the case-sensitive extensions defined in
   [RFC7405].

> is useful.  It feels a bit contrived as an example.

Oh.  The BASE is just the encoding base, i.e., if base is 400, the three numbers used as labels here are 400, 401, 402 — no interaction with the semantics of an interval.

Now:

   The example in Figure 1 contains the generic definition of a CDDL
   group "interval" that gives a lower and an upper bound and optionally
   a tolerance.  The parameter BASE allows the non-conflicting use of
   multiple of these interval groups in one map, by assigning different
   labels to the entries of the interval. "rect" combines two of these
   interval groups into a map, one group for the X dimension (using 0,
   1, and 2 as labels) and one for Y dimension (using 3, 4, and 5 as
   labels).

> main goal being to get the 8428 reference in.)

Nice!  I put that in.

> publication as an RFC, so this comment itself is somewhat pointless].

That is actually the implementation mentioned as

   An early implementation of the control operator .feature has been
   available in the CDDL tool described in Appendix F of [RFC8610] since
   version 0.8.11.  […]

> interpretation of the string").

Yep, I was about to write “The security considerations of … apply”, and then read those...

I have now added:

   While both [RFC5234] and [RFC7405] state that security is truly
   believed to be irrelevant to the respective document, the use of
   formal description techniques cannot only simplify, but sometimes
   also complicate a specification.  This can lead to security problems
   in implementations and in the specification itself.  As with CDDL
   itself, ABNF should be judiciously applied, and overly complex (or
   "cute") constructions should be avoided.

I think that should really be a standard disclaimer on all FDT techniques.
(I haven’t added “If the FDT specification does not make boring reading, you are holding it wrong.”)

> invariably surprises some people (i.e., it is not "round to zero").

I’d rather avoid that surprise be being more explicit:

 target; converting from a floating point number to an integer selects
 its floor (the largest integer less than or equal to the floating
-point number).
+point number, i.e., rounding down).

Grüße, Carsten

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 21 Oct 2021 18:52:43 -0700

Hi Carsten,

> Interesting!  I live in a world that has pretty much completed the transition, and so I thought just always referencing 5234 and 7405 together would be sufficient indication.

That is reassuring to hear; it's possible that I should re-calibrate myself
(since I mostly only encounter ABNF while doing IESG reviews).

>    this document allow use of the case-sensitive extensions defined in

Thanks; that is well said.

> Oh.  The BASE is just the encoding base, i.e., if base is 400, the three numbers used as labels here are 400, 401, 402 — no interaction with the semantics of an interval.

Oh!  I guess I should have brushed up on my CDDL more before reviewing, at
least when it's after 2200h local time.

>    1, and 2 as labels) and one for Y dimension (using 3, 4, and 5 as

Thanks!

>    available in the CDDL tool described in Appendix F of [RFC8610] since

Ah.  I guess I was assuming that "early" and "complete" were incompatible,
which is not guaranteed to be a valid assumption.

> (I haven’t added “If the FDT specification does not make boring reading, you are holding it wrong.”)

:)

> +point number, i.e., rounding down).

I left a suggestion on the PR.

Thanks for this -- it, and the PR, look good.

-Ben

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 22 Oct 2021 08:55:34 +0200

Hi Ben,

thank you for the confirmation, and the further improvement.

> On 22. Oct 2021, at 03:52, Benjamin Kaduk <[email-masked]> wrote:
> 

Committed, merged, and -07 (with input from Lars, Roman, Rob, and you) submitted.

Grüße, Carsten