Additional Control Operators for the Concise Data Definition Language (CDDL)
draft-ietf-cbor-cddl-control-07

[Ballot comment]
Hi,

Thanks for this.  I have to confess that I'm not particularly familiar with CDDL.

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?  I guess you have to add support if you want to parse CDDL text that uses the new control codes.  Would it be helpful to have any text in the introduction about conformance/implementation?  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.


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

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.

Regards,
Rob

[Ballot comment]
Does the inclusion of RFC 7405 as a normative reference imply that the
%s"" construct is part of the core grammar used by .abnf and .abnfb?
My understanding was that just saying "ABNF" did not by default include
the case-sensitivity functionality (regardless of what references are
present), and so that it might be appropriate for us to say something
like "the ABNF control operators defined by this document allow use of
the case-sensitive extensions defined in [RFC7405]".

Section 2.1

  interval = (
    BASE => int            ; lower bound
    (BASE .plus 1) => int  ; upper bound
    ? (BASE .plus 2) => int ; tolerance

I'm having a really hard time coming up for a use case where making the
tolerance depend on the base of the interval by an affine transformation
is useful.  It feels a bit contrived as an example.

Section 4

  (enable/disable).  The latter approach could for instance be used for
  a JSON/CBOR switch, as illustrated in Figure 9.

I'd suggest something like "as illustrated in Figure 9 using SenML
[RFC8428] as the example data model used with both JSON and CBOR".  (The
main goal being to get the 8428 reference in.)

Section 6

The shepherd writeup indicates that the author has a complete
implementation, so it's surprising to not see it mentioned in this
Implementation Status section [that is to be removed prior to
publication as an RFC, so this comment itself is somewhat pointless].

Section 7

I would suggest that the ABNF security considerations would also imply,
except that both referenced documents disclaim any such considerations
(not even "what you actually describe may not be what you think you are
describing" or "ABNF just says whether a given string matches the
constraints of a given construction, and does not require a unique
interpretation of the string").

I might also consider mentioning that the behavior of the "floor" function
(for converting floating-point values to integers) on negative inputs
invariably surprises some people (i.e., it is not "round to zero").

[Ballot comment]
Thank you Tianran for the OpsDir review, and Carsten Bormann (and others) for addressing the comments.

I see that the document had a second IETF LC with the new track, and think that the Info -> Std chance made a lot of sense.

Thanks again, W

[ Resending because the previous one got et by the mailer...]

[Ballot comment]
Thank you Tianran for the OpsDir review, and Carsten Bormann (and others) for addressing the comments.

I see that the document had a second IETF LC with the new track, and think that the Info -> Std chance made a lot of sense.

Thanks again, W

[Ballot comment]
** Section 2.2.  Checking my understanding of string concatenation:

(a) “Target and controller MUST be strings”

(b) “If the target is a text string, the result of that concatenation MUST be valid UTF-8”.

There is a distinction being made between a “text string” and “byte string” per Section 3.1 of RFC8610?

[Ballot comment]
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 4. , paragraph 9, nit:
-    mistakes such as using the label organisation instead of organization
+    mistakes such as using the label "organisation" instead of "organization"
+                                    +            +            +            +

Section 1.1. , paragraph 2, nit:
> operators, "target" refers to the left hand side operand, and "controller" to
>                                  ^^^^^^^^^
Did you mean the adjective "left-hand"?

Section 3. , paragraph 14, nit:
> ut might contain the controller (right hand side) as a feature name, and the
>                                  ^^^^^^^^^^
Did you mean the adjective "right-hand"?

Section 3. , paragraph 14, nit:
> s a feature name, and the target (left hand side) as a feature detail. Howev
>                                  ^^^^^^^^^
Did you mean the adjective "left-hand"?

These URLs in the document can probably be converted to HTTPS:
* http://www.iana.org/assignments/cddl

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cbor-cddl-control-06. If any part of this review is inaccurate, please let us know.

In the CDDL Control Operators registry on the Concise Data Definition Language (CDDL) registry page located at:

https://www.iana.org/assignments/cddl/

six new registrations are to be made as follows:

Name: .plus
Reference: [ RFC-to-be ]

Name: .cat
Reference: [ RFC-to-be ]

Name: .det
Reference: [ RFC-to-be ]

Name: .abnf
Reference: [ RFC-to-be ]

Name: .abnfb
Reference: [ RFC-to-be ]

Name: .feature
Reference: [ RFC-to-be ]

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

(1) What type of RFC is being requested? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The intended  status is Proposed Standard, as a result of the first Last Call feedback and subsequent discussion in the working group. It thus complements (through existing extension points that do not necessitate an update) the original CDDL specification (RFC 8610), which is also Standards Track.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. [...]

Technical Summary:

The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. The present document defines a number of control operators that did not make it into RFC 8610: .plus, .cat and .det for the construction of constants, .abnf/.abnfb for including ABNF (RFC 5234/RFC 7405) in CDDL specifications, and .feature for indicating the use of a non-basic feature in an instance.

Working Group Summary:

The process through the WG was a bit quiet but uncontroversial. Discussion happened more during interims than on list; an outstanding point was on whether the document needs to go to such lengths (dedenting) to accommodate ABNF oddities -- this was found to be the most practical way.

Document Quality:

A complete implementation exists, provided by the author; a second exists but is incomplete. No vendors that use this are currently known, but it is being used inside IETF by ASDF. Henk Birkholz's comprehensive review  well sums up the status, with some enhancements processed into -04.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Christian Amsüss is Document Shepherd, Francesca Palombini is the Responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A review (archived at ) found the document practically ready, with just minor editorial issues that were incorporated into -05. Other than that, it does raise questions on further exotic uses, which serve more to reaffirm understanding than to indicate necessary changes to the document.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

A broader reviewing process would have been desirable, but given the size of the working group, the interim / list discussions, Henk's review and the shepherd review should do.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No relevant concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There have been no disclosures about this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Support for the document has been soft but consistently present. The WG as a whole has sees its usefulness. If the low volume of the overll discussion is to be attributed to anything other than the WG's small size, it's likely due to the document doing "boring" ground work.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No actual nits found.

(tools identifies some, but they are all false positives in some form, be it because the expiry date is not recognized, a legitimate Umlaut is complained about, or RFCthis is not assigned before RFC edltor is done).

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal reviews are required.

(13) Have all references within this document been identified as either normative or informative?

Yes.

Note: As this builds solely on CDDL (which is applicable to CBOR and JSON), it seems reasonable that CBOR is not a normative reference; it is referenced informatively as used in examples.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Normative references are in order; one is to an IANA registry but that is not uncommon.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? [...]

No; it merely uses defined extension points.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries [...]

The IANA considertions are simple, consistent and correct.

(18) List any new IANA registries that require Expert Review for future allocations. [...]

No registries are established.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

None automated checks exist. The blocks containing standalone examples were manually checked against the full implementation which processes them as expected.

(20) If the document contains a YANG module, [...]

No YANG around.

The following Last Call announcement was sent out (ends 2021-10-12):

From: The IESG
To: IETF-Announce
CC: cbor-chairs@ietf.org, cbor@ietf.org, christian@amsuess.com, draft-ietf-cbor-cddl-control@ietf.org, francesca.palombini@ericsson.com
Reply-To: last-call@ietf.org
Sender:
Subject: Second Last Call:  (Additional Control Operators for CDDL) to Proposed Standard


The IESG has received a request from the Concise Binary Object Representation
Maintenance and Extensions WG (cbor) to consider the following document: -
'Additional Control Operators for CDDL'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-10-12. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Concise Data Definition Language (CDDL), standardized in RFC
  8610, provides "control operators" as its main language extension
  point.

  The present document defines a number of control operators that were
  not yet ready at the time RFC 8610 was completed: .plus, .cat and
  .det for the construction of constants, .abnf/.abnfb for including
  ABNF (RFC 5234/RFC 7405) in CDDL specifications, and .feature for
  indicating the use of a non-basic feature in an instance.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl-control/



No IPR declarations have been submitted directly on this I-D.

As a result of the first Last Call feedback, and subsequent discussion in the working group, the Intended RFC status should be Proposed Standard. Note that the CDDL main spec (RFC 8610) is also Standards Track.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cbor-cddl-control-05. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the CDDL Control Operators registry on the Concise Data Definition Language (CDDL) registry page located at:

https://www.iana.org/assignments/cddl/

six new registrations are to be made as follows:

Name: .plus
Reference: [ RFC-to-be ]

Name: .cat
Reference: [ RFC-to-be ]

Name: .det
Reference: [ RFC-to-be ]

Name: .abnf
Reference: [ RFC-to-be ]

Name: .abnfb
Reference: [ RFC-to-be ]

Name: .feature
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-09-21):

From: The IESG
To: IETF-Announce
CC: cbor-chairs@ietf.org, cbor@ietf.org, christian@amsuess.com, draft-ietf-cbor-cddl-control@ietf.org, francesca.palombini@ericsson.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Additional Control Operators for CDDL) to Informational RFC


The IESG has received a request from the Concise Binary Object Representation
Maintenance and Extensions WG (cbor) to consider the following document: -
'Additional Control Operators for CDDL'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-09-21. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Concise Data Definition Language (CDDL), standardized in RFC
  8610, provides "control operators" as its main language extension
  point.

  The present document defines a number of control operators that did
  not make it into RFC 8610: ".plus", ".cat" and ".det" for the
  construction of constants, ".abnf"/".abnfb" for including ABNF (RFC
  5234/RFC 7405) in CDDL specifications, and ".feature" for indicating
  the use of a non-basic feature in an instance.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl-control/



No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

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.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. [...]

Technical Summary:

The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. The present document defines a number of control operators that did not make it into RFC 8610: .plus, .cat and .det for the construction of constants, .abnf/.abnfb for including ABNF (RFC 5234/RFC 7405) in CDDL specifications, and .feature for indicating the use of a non-basic feature in an instance.

Working Group Summary:

The process through the WG was a bit quiet but uncontroversial. Discussion happened more during interims than on list; an outstanding point was on whether the document needs to go to such lengths (dedenting) to accommodate ABNF oddities -- this was found to be the most practical way.

Document Quality:

A complete implementation exists, provided by the author; a second exists but is incomplete. No vendors that use this are currently known, but it is being used inside IETF by ASDF. Henk Birkholz's comprehensive review  well sums up the status, with some enhancements processed into -04.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Christian Amsüss is Document Shepherd, Francesca Palombini is the Responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A review (archived at ) found the document practically ready, with just minor editorial issues that were incorporated into -05. Other than that, it does raise questions on further exotic uses, which serve more to reaffirm understanding than to indicate necessary changes to the document.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

A broader reviewing process would have been desirable, but given the size of the working group, the interim / list discussions, Henk's review and the shepherd review should do.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No relevant concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There have been no disclosures about this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Support for the document has been soft but consistently present. The WG as a whole has sees its usefulness. If the low volume of the overll discussion is to be attributed to anything other than the WG's small size, it's likely due to the document doing "boring" ground work.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No actual nits found.

(tools identifies some, but they are all false positives in some form, be it because the expiry date is not recognized, a legitimate Umlaut is complained about, or RFCthis is not assigned before RFC edltor is done).

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal reviews are required.

(13) Have all references within this document been identified as either normative or informative?

Yes.

Note: As this builds solely on CDDL (which is applicable to CBOR and JSON), it seems reasonable that CBOR is not a normative reference; it is referenced informatively as used in examples.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Normative references are in order; one is to an IANA registry but that is not uncommon.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? [...]

No; it merely uses defined extension points.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries [...]

The IANA considertions are simple, consistent and correct.

(18) List any new IANA registries that require Expert Review for future allocations. [...]

No registries are established.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

None automated checks exist. The blocks containing standalone examples were manually checked against the full implementation which processes them as expected.

(20) If the document contains a YANG module, [...]

No YANG around.

(1) What type of RFC is being requested? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

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.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. [...]

Technical Summary:

The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. The present document defines a number of control operators that did not make it into RFC 8610: .plus, .cat and .det for the construction of constants, .abnf/.abnfb for including ABNF (RFC 5234/RFC 7405) in CDDL specifications, and .feature for indicating the use of a non-basic feature in an instance.

Working Group Summary:

The process through the WG was a bit quiet but uncontroversial. Discussion happened more during interims than on list; an outstanding point was on whether the document needs to go to such lengths (dedenting) to accommodate ABNF oddities -- this was found to be the most practical way.

Document Quality:

A complete implementation exists, provided by the author; a second exists but is incomplete. No vendors that use this are currently known, but it is being used inside IETF by ASDF. Henk Birkholz's comprehensive review  well sums up the status, with some enhancements processed into -04.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Christian Amsüss is Document Shepherd, Francesca Palombini is the Responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A review (archived at ) found the document practically ready, with just minor editorial issues that were incorporated into -05. Other than that, it does raise questions on further exotic uses, which serve more to reaffirm understanding than to indicate necessary changes to the document.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

A broader reviewing process would have been desirable, but given the size of the working group, the interim / list discussions, Henk's review and the shepherd review should do.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No relevant concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There have been no disclosures about this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Support for the document has been soft but consistently present. The WG as a whole has sees its usefulness. If the low volume of the overll discussion is to be attributed to anything other than the WG's small size, it's likely due to the document doing "boring" ground work.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No actual nits found.

(tools identifies some, but they are all false positives in some form, be it because the expiry date is not recognized, a legitimate Umlaut is complained about, or RFCthis is not assigned before RFC edltor is done).

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal reviews are required.

(13) Have all references within this document been identified as either normative or informative?

Yes.

Note: As this builds solely on CDDL (which is applicable to CBOR and JSON), it seems reasonable that CBOR is not a normative reference; it is referenced informatively as used in examples.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Normative references are in order; one is to an IANA registry but that is not uncommon.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? [...]

No; it merely uses defined extension points.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries [...]

The IANA considertions are simple, consistent and correct.

(18) List any new IANA registries that require Expert Review for future allocations. [...]

No registries are established.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

None automated checks exist. The blocks containing standalone examples were manually checked against the full implementation which processes them as expected.

(20) If the document contains a YANG module, [...]

No YANG around.

(1) What type of RFC is being requested? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

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.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. [...]

Technical Summary:

The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. The present document defines a number of control operators that did not make it into RFC 8610: .plus, .cat and .det for the construction of constants, .abnf/.abnfb for including ABNF (RFC 5234/RFC 7405) in CDDL specifications, and .feature for indicating the use of a non-basic feature in an instance.

Working Group Summary:

The process through the WG was a bit quiet but uncontroversial. Discussion happened more during interims than on list; an outstanding point was on whether the document needs to go to such lengths (dedenting) to accommodate ABNF oddities -- this was found to be the most practical way.

Document Quality:

A complete implementation exists, provided by the author; a second exists but is incomplete. No vendors that use this are currently known, but it is being used inside IETF by ASDF. Henk Birkholz's comprehensive review  well sums up the status, with only a few nit-level comments that are being processed into the document.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Christian Amsüss is Document Shepherd, Francesca Palombini is the Responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A review (archived at ) found just minor editorial issues. Other than that, it does raise questions on further exotic uses, which serve more to reaffirm understanding than to indicate necessary changes to the document.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

A broader reviewing process would have been desirable, but given the size of the working group, the interim / list discussions, Henk's review and the shepherd review should do.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No relevant concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Not yet (TBD).

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There have been no disclosures about this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Support for the document has been soft but consistently present. The WG as a whole has sees its usefulness. If the low volume of the overll discussion is to be attributed to anything other than the WG's small size, it's likely due to the document doing "boring" ground work.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

TBD.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal reviews are required.

(13) Have all references within this document been identified as either normative or informative?

Yes.

Note: As this builds solely on CDDL (which is applicable to CBOR and JSON), it seems reasonable that CBOR is not even an informative reference.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

TBD (checking on normative referencability of an IANA registry itself).

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? [...]

No; it merely uses defined extension points.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries [...]

The IANA considertions are simple, consistent and correct.

(18) List any new IANA registries that require Expert Review for future allocations. [...]

No registries are established.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

None automated checks exist. The blocks containing standalone examples were manually checked against the full implementation which processes them as expected.

(20) If the document contains a YANG module, [...]

No YANG around.

Criteria set out at WGLC are completed, WG consensus is achieved. Shepherd review and addressing of latest comment will happen intertwined over the next two weeks.

This document is lacking recent reviews -- no voices against it, but lack of non-authors who take some time with the document.

Unlike other WGLCs, for this to be successful we *will* need reviews of this document.