Re: [Cbor] [Last-Call] Opsdir last call review of draft-ietf-cbor-cddl-control-05

Tianran Zhou <> Tue, 21 September 2021 23:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E6233A0FBF; Tue, 21 Sep 2021 16:54:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0YwqLFIx5WG4; Tue, 21 Sep 2021 16:54:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 320D73A0FBD; Tue, 21 Sep 2021 16:54:49 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4HDdWh1K0Vz67PWm; Wed, 22 Sep 2021 07:52:16 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Wed, 22 Sep 2021 01:54:45 +0200
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Wed, 22 Sep 2021 07:54:43 +0800
Received: from ([]) by ([]) with mapi id 15.01.2308.008; Wed, 22 Sep 2021 07:54:43 +0800
From: Tianran Zhou <>
To: Carsten Bormann <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: [Last-Call] Opsdir last call review of draft-ietf-cbor-cddl-control-05
Thread-Index: AQHXqwpK+PqhuAFYt0WJwJVC6p4eJauvMX1w
Date: Tue, 21 Sep 2021 23:54:43 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Cbor] [Last-Call] Opsdir last call review of draft-ietf-cbor-cddl-control-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Sep 2021 23:54:55 -0000

Hi Carsten,

Thanks for your clarification.
I am good with the modification.
It would be good if the working group can discuss and agree with the document type.


-----Original Message-----
From: Carsten Bormann [] 
Sent: Thursday, September 16, 2021 10:50 PM
To: Tianran Zhou <>
Subject: Re: [Last-Call] Opsdir last call review of draft-ietf-cbor-cddl-control-05

Hi Tianran,

thank you for this thoughtful review.

> 1. " The present document defines a number of control operators that 
> did not make it into RFC 8610:" This confused me why it was not included into RFC 8610.
> Is there any WG decision to make this draft seperate from RFC8610?

At the time RFC 8610 went into its finishing phase, we identified a number of features where waiting for their completion would unduly hold up the completion of the RFC.
A document was created (“the freezer”) to capture those features:
The WG did have several discussions about this, including a survey Francesca (WG chair at the time) made that helped clarify our priorities.

The cddl-control draft essential is an extraction from the freezer, with some further development of course (otherwise we could have put in the features into RFC 8610).  This particular extraction focuses on features that can be attached to existing extension points of RFC 8610, with leaving a “CDDL 2.0” or some such to the next step after that.

“were not ready at the time RFC 8610 was completed” maybe is a bit more explicit.


> 2. Why this document is informational while RFC8610 is standard?
> This somewhat related to the first question.
> I looked into the shepherd comments, but the reason is still not clear to me.
> "This is Informational. It provides extensions to CDDL through an 
> extension registry that's only "specification required". It is being 
> done through the IETF process (and working group) because much of it 
> was already planned to be shipped as "included batteries" with 
> original CDDL, because there expertise on ABNF (which it is linking 
> into CDDL) is in here, and because the proposed additions are expected 
> to be used as important tools future CDDL-based specifications."
> I do not think "an extension registry that's only "specification required""
> should be the reason for informaitonal.

Actually, I agree with your view here.

This is really an instance of a larger question that we have had repeatedly:  What is the intended status of documents that “just” exercise extension points of a base standard, which could as well have been exercised by a "specification required” registration?

I believe the fact that a “specification required” registration would have sufficed (and the base document is not “updated”) is not sufficient to make the decision.  Instead, we should have focused on the question what the normative intent is.  We do expect CDDL users to be able to use these features (and we have two known public implementations), so the intent is for this specification to stand on the same level as the base document itself.

I have stronger opinions about this than a couple of months ago because we just went through very much the same kind of discussion again with draft-ietf-core-senml-data-ct, where we did reach the conclusion that “standards track” was the right answer.


I did not make a change to the document itself now because I think we need to await the result of this discussion.

> 3. A nit in section 2:
> "As an 80 % solution" is not easy to understand what this mean to the 
> later words.

   CDDL as defined in [RFC8610] does not have any mechanisms to compute
   literals.  As an 80 % solution, this specification adds three control
   operators: [details]

So what was meant here is that the need for computing the value of literals may be wider, but 80 % (proverbial, not actually measured) of the use cases should be addressed with these three control operators.

So, again, let’s make this more explicit:

-literals.  As an 80 % solution, this specification adds 
+literals.  To cover a large part of the use cases, this specification 


The changes are assembled in

Thanks again for helping us to weed out unneeded jargon!

Grüße, Carsten