Skip to main content

Additional Control Operators for the Concise Data Definition Language (CDDL)
draft-ietf-cbor-cddl-control-07

Yes

Francesca Palombini

No Objection

Erik Kline
Murray Kucherawy
Zaheduzzaman Sarker
Éric Vyncke
(Alvaro Retana)
(Martin Vigoureux)

Note: This ballot was opened for revision 06 and is now closed.

Francesca Palombini
Yes
Erik Kline
No Objection
John Scudder
No Objection
Comment (2021-10-20 for -06) Sent
"dedcat". Heh. Thanks for the smile (and the easy-to-follow spec).
Murray Kucherawy
No Objection
Roman Danyliw
No Objection
Comment (2021-10-20 for -06) Sent
** Section 2.2.  Checking my understanding of string concatenation:

(a) “Target and controller MUST be strings”

(b) “If the target is a text string, the result of that concatenation MUST be valid UTF-8”.

There is a distinction being made between a “text string” and “byte string” per Section 3.1 of RFC8610?
Warren Kumari
No Objection
Comment (2021-10-20 for -06) Sent
Thank you Tianran for the OpsDir review, and Carsten Bormann (and others) for addressing the comments.

I see that the document had a second IETF LC with the new track, and think that the Info -> Std chance made a lot of sense.

Thanks again, W

[ Resending because the previous one got et by the mailer...]
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection
Alvaro Retana Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Benjamin Kaduk Former IESG member
No Objection
No Objection (2021-10-20 for -06) Sent
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").
Lars Eggert Former IESG member
No Objection
No Objection (2021-10-18 for -06) Sent
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 4. , paragraph 9, nit:
-    mistakes such as using the label organisation instead of organization
+    mistakes such as using the label "organisation" instead of "organization"
+                                     +            +            +            +

Section 1.1. , paragraph 2, nit:
> operators, "target" refers to the left hand side operand, and "controller" to
>                                   ^^^^^^^^^
Did you mean the adjective "left-hand"?

Section 3. , paragraph 14, nit:
> ut might contain the controller (right hand side) as a feature name, and the
>                                  ^^^^^^^^^^
Did you mean the adjective "right-hand"?

Section 3. , paragraph 14, nit:
> s a feature name, and the target (left hand side) as a feature detail. Howev
>                                   ^^^^^^^^^
Did you mean the adjective "left-hand"?

These URLs in the document can probably be converted to HTTPS:
 * http://www.iana.org/assignments/cddl
Martin Vigoureux Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (2021-10-21 for -06) Sent
Hi,

Thanks for this.  I have to confess that I'm not particularly familiar with CDDL.

It does feel that adding support for ABNF increases the size/complexity of the CDDL language a fair bit.  Is the expectation that all CDDL implementations will add support for these new control codes?  I guess you have to add support if you want to parse CDDL text that uses the new control codes.  Would it be helpful to have any text in the introduction about conformance/implementation?  Finally, would it be helpful for this document to "update" the base CDDL spec, so that readers looking for the base CDDL spec would also find this RFC, or perhaps that is achieved via the IANA registration.


One minor nit:

Regarding dedenting, I suggest changing "in all" => "present in all"

   1.  determining the smallest amount of left-most blank space (number
       of leading space characters) in all the non-blank lines, and

Just a suggestion, but it might be helpful to include a short example where some lines are not fully dedented.  I.e., so something doesn't think that each line is processed independently.

Regards,
Rob