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

[Carsten Bormann <[e-mail]>]

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

> ----------------------------------------------------------------------
> 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?

Yes, that is the intention.

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

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

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

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

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

Nice!  I put that 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].

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

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

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

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

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