Theresa, thank you for your review. I have entered a No Objection ballot for this document. Lars > On 2021-9-16, at 21:12, Theresa Enghardt via Datatracker <noreply@xxxxxxxx> wrote: > > 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? > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
