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

[Tianran Zhou <[e-mail]>]

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:[e-mail]] 
Sent: Thursday, September 16, 2021 10:50 PM
To: Tianran Zhou <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
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:
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

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

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.

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