(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
<https://mailarchive.ietf.org/arch/msg/cbor/bc8xxKE6xGzEQ8NSDT6eyB9JXx0> 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
<https://mailarchive.ietf.org/arch/msg/cbor/GfZOP6SNthNTLZlgAZbdoAhrbmU>) 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.