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

Carsten Bormann <cabo@tzi.org> Thu, 21 October 2021 15:04 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F7E3A177F; Thu, 21 Oct 2021 08:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5XQz6kMj2Ei; Thu, 21 Oct 2021 08:04:15 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B177F3A177B; Thu, 21 Oct 2021 08:04:14 -0700 (PDT)
Received: from [192.168.217.118] (p5089a10c.dip0.t-ipconnect.de [80.137.161.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HZrNW2W46z30L8; Thu, 21 Oct 2021 17:04:11 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <163482596094.17691.12740221348124236410@ietfa.amsl.com>
Date: Thu, 21 Oct 2021 17:04:11 +0200
Cc: The IESG <iesg@ietf.org>, =?utf-8?Q?Christian_Ams=C3=BCss?= <christian@amsuess.com>, cbor@ietf.org, draft-ietf-cbor-cddl-control@ietf.org, cbor-chairs@ietf.org
X-Mao-Original-Outgoing-Id: 656521450.607217-a5e9aea910d54871ac0e8266df952210
Content-Transfer-Encoding: quoted-printable
Message-Id: <33B27933-BC05-4A25-8694-B072B1C616EA@tzi.org>
References: <163482596094.17691.12740221348124236410@ietfa.amsl.com>
To: Robert Wilton <rwilton@cisco.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/qb0Ie3OpiOIGvjagrYYCgY_LLIQ>
Subject: Re: [Cbor] Robert Wilton's No Objection on draft-ietf-cbor-cddl-control-06: (with COMMENT)
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Oct 2021 15:04:19 -0000

Hi Rob,

Thank you for your review.

> ----------------------------------------------------------------------
> COMMENT:
> ———————————————————————————————————
> […]
> 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?  

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
> helpful to have any text in the introduction about conformance/implementation? 

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

> 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.

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).

> 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

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

> 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.

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