Re: [Cbor] 🔔 WGLC with request for reviews on cbor-cddl-control-03

Carsten Bormann <cabo@tzi.org> Tue, 01 June 2021 19:06 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 8771D3A23D3; Tue, 1 Jun 2021 12:06:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_FAIL=0.001, SPF_HELO_NONE=0.001] autolearn=no 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 H96UCRqs4Gk8; Tue, 1 Jun 2021 12:06:09 -0700 (PDT)
Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA6253A23D2; Tue, 1 Jun 2021 12:06:08 -0700 (PDT)
Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FvhT66zxRz315t; Tue, 1 Jun 2021 21:06:02 +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: <YLZ9s74sRa+ivAEe@hephaistos.amsuess.com>
Date: Tue, 1 Jun 2021 21:06:02 +0200
Cc: cbor@ietf.org, draft-ietf-cbor-cddl-control@ietf.org
X-Mao-Original-Outgoing-Id: 644267162.5170259-f221f45305ba190eadf0b01fd07b235a
Content-Transfer-Encoding: quoted-printable
Message-Id: <670FD4AE-B34D-4910-A5A3-CDDE29C493FE@tzi.org>
References: <162257177227.3108.15057636687346300680@ietfa.amsl.com> <YLZ9s74sRa+ivAEe@hephaistos.amsuess.com>
To: =?utf-8?Q?Christian_Ams=C3=BCss?= <christian@amsuess.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/_HXwYbEI4z-BXuW2PcCCESgSstM>
Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_with_request_for_reviews_on_c?= =?utf-8?q?bor-cddl-control-03?=
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: Tue, 01 Jun 2021 19:06:12 -0000

> As this document has seen no recent review activity, I urge all
> prospective users to read the current version and provide reviews.

Well, I’m not a “prospective user” (more like an actual one), but I have been using various parts of this document over the past year as the implementations became available.  

Here are two observations that maybe could benefit from some additional discussion.


.feature has been around for a year, and it really turned out to be a brilliantly simple solution for a complex need (compare “if-feature” in YANG…).
One nit that is sometimes a bit hard to manage is the consistent use of feature names (maybe this is a tool issue, or something that a usage convention could help with).
The biggest confusion was created in one case where part of the spec said

	.feature “1.1”

while another said

	.feature 1.1

(yes, the floating point number.)
The cddl tool treats these as different features (which they obviously are), but generates exactly the same output for these.
This led to a little goose hunt…
Limiting the controller side to text strings doesn’t quite feel right either, as there may be good use for a structured feature name.
So my provisional thinking is that this should be handled by better tool support and maybe adding a little warning text in the draft.


.abnf needed .det, that was a surprise to me when implementing this.
(The other surprises were how mind-bogglingly easy the implementation was after all, and how useful the .abnf control operator is in an IETF world where much is already available in ABNF — so much better than regexps...)

As specified now, .det dedents just the rhs, and explains

   If left-hand-side (target) dedenting is needed as well, this can be
   achieved with the slightly longer construct "("" .det lhs) .det rhs”.

Well, after some use it turns out that it is much more likely that one needs both sides dedented, so maybe we switch to this and change the note to:

   If dedenting is needed only on one of the sides, this can be
   achieved with slightly longer constructs such as »lhs .cat ("" .det rhs)« 
   or »(lhs .det “”) .cat rhs«.


Apart from these somewhat advanced notes, I’m still rather happy with the draft both from a user (model author) side and from an implementer side.


Now keep the reviews flowing, please…


Grüße, Carsten

(Please excuse the random smartquotes.)