Reviewer: Theresa Enghardt Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-cbor-cddl-control-05 Reviewer: Theresa Enghardt Review Date: 2021-09-16 IETF LC End Date: 2021-09-21 IESG Telechat date: Not scheduled for a telechat Summary: This document is fairly clear and concise, and basically ready for publication. I noticed a few minor issues and nits that could further enhance document clarity. Major issues: None. Minor issues: Section 1: Please consider adding a brief description of what a control operator is, how it can be used, and what its components are. .feature is described as "Detecting feature use in extension points" (introduction) VS "indicating the use of a non-basic feature in an instance" (abstract) - How can a control operator detect feature use, doesn't it merely indicate? If both of these descriptions are meant to conved the same meaning, please consider changing the "purpose" of .feature to something like "Name of a feature that is used", or, ideally, find a different word to capture what a feature is. Section 2: "CDDL as defined in [RFC8610] does not have any mechanisms to compute literals. As an 80 % solution, this specification adds three control operators" What are the missing 20%? Please consider briefly mentioning the limitations of the new operators. "Not all tools may be able to work with non-unique targets or controllers." Here, "tool" refers to "CDDL tool" as used in RFC8610, correct? If so, please consider making all references to "tool" in this document more precise. Section 2.3: Please consider adding the outcome of the .det operation in the example in Figure 3: The definition of dedenting includes "determining the smallest amount of left-most blank space (number of leading space characters) in all the non-blank lines". If I understand correctly, taking this definition literally, the operation ("oid" .det cbor-tags-oid) would result in no space being removed at all, because the string "oid" does not contain anly left-most blank spaces. But I suspect that the example is intended to show dedenting of the contents of the cbor-tags-oid variable. Perhaps I'm missing something about CDDL here that was discussed in RFC8610. Section 7 (Security considerations): Can there be any additional security concerns if CDDL specifications can contain ABNF or "arbitrary" features? While this document obviously can't go into specifics, maybe it's worth calling out that one needs to pay specific attention if these control operators are used. Nits/editorial comments: Section 2.2 "concatenating the target text string ""foo""" Is foo intended to be in two double quotes, or should there only be one pair of quotes? Section 3 "by defining a ".abnf" control operator" Should this say 'an ".abnf" control operator' instead? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
