[Gen-art] Genart last call review of draft-ietf-cbor-cddl-control-05

Theresa Enghardt via Datatracker <noreply@ietf.org> Thu, 16 September 2021 18:12 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 748FF3A31E3; Thu, 16 Sep 2021 11:12:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Theresa Enghardt via Datatracker <noreply@ietf.org>
To: gen-art@ietf.org
Cc: cbor@ietf.org, draft-ietf-cbor-cddl-control.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.37.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <163181597437.23922.16020691497893082297@ietfa.amsl.com>
Reply-To: Theresa Enghardt <ietf@tenghardt.net>
Date: Thu, 16 Sep 2021 11:12:54 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/0lDYXgcc73B27czzAsq1DYUlFww>
Subject: [Gen-art] Genart last call review of draft-ietf-cbor-cddl-control-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Sep 2021 18:12:55 -0000

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?