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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Thu, 21 Oct 2021 07:19:21 -0700

Robert Wilton 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:
----------------------------------------------------------------------

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Oct 2021 17:04:11 +0200

Hi Rob,

Thank you for your review.

> ———————————————————————————————————
> […]
> will add support for these new control codes?  

No.  The extension point “control operator” was designed so that you can still meaningfully do something with the CDDL if you don’t (or only partially) implement it.

By the way, both Andrew Weiss and I were quite surprised by how easy ABNF is to implement.  (Contrast this to regexps…)

> I guess you have to add support
> if you want to parse CDDL text that uses the new control codes.  

You can parse CDDL without implementing ABNF (as .abnf uses a well-defined extension point).
You just can’t check what is said in the ABNF.

> Would it be

I’d leave that to Section 3.8 of RFC 8610 (or any update of that — see below).

> perhaps that is achieved via the IANA registration.

Control operators are a well-defined extension point, and we don’t “update” base drafts when their extension points are exercised in the prescribed manner.
I think the registry is indeed a good link to the various specifications that do (RFC 9090 and cddl-control so far, with several in the pipeline).

>       of leading space characters) in all the non-blank lines, and

Thanks!
Now in https://github.com/cbor-wg/cddl-control/pull/14

> line is processed independently.

I would expect that those that have to implement this will pick it up from the above definition.  Most users of .det will mostly use it with .abnf/.abnfb, where Bill Fenner’s bap will already have complained about unevenly indented input.
So I think we are fine even without one more example.

Grüße, Carsten