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

From: Tianran Zhou via Datatracker <[email-masked]>
Date: Thu, 16 Sep 2021 00:40:50 -0700

Reviewer: Tianran Zhou
Review result: Ready

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

In general, this document is clear to me. I did not see any special operational
or network management related issue.

There are several clearification questions and nits as follows:

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?

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.

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

Cheers,
Tianran

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 16 Sep 2021 16:50:27 +0200

Hi Tianran,

thank you for this thoughtful review.

> 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:
https://datatracker.ietf.org/doc/draft-bormann-cbor-cddl-freezer/
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.

Now https://github.com/cbor-wg/cddl-control/commit/91c7c39

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

Now
https://github.com/cbor-wg/cddl-control/issues/10

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

> "As an 80 % solution" is not easy to understand what this mean to the later

   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 adds 

Now https://github.com/cbor-wg/cddl-control/commit/87ad909

The changes are assembled in
https://github.com/cbor-wg/cddl-control/pull/9

Thanks again for helping us to weed out unneeded jargon!

Grüße, Carsten

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 21 Sep 2021 23:54:43 +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.

Best,
Tianran

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

Hi Tianran,

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

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

Now

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

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

Grüße, Carsten

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 22 Sep 2021 20:28:25 +0200

Hello Tianran, hello Carsten,

thank you for your input on this document.

> should be the reason for informaitonal.

this point was discussed in today's CBOR interim meeting, and
considering this thread, input from the interim including from Francesca
as responsible AD, we chairs agree that this can be moved to standards
track without the need for further discussion.

Carsten, please switch the document over to standards track with your
next upload (and poke me if I don't update my shepherd review to reflect
the changed situation right after that).

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom