CBOR Extended Diagnostic Notation (EDN)
draft-ietf-cbor-edn-literals-19

During the interim today: https://datatracker.ietf.org/doc/agenda-interim-2025-cbor-05-cbor-01/

We discussed externalizing the requirements that have been driving the discussion regarding escaping & ABNF.
I'm marking the draft revised I-D needed, with the understanding that the group will need to makes changes before running another WGLC.

Directorate reviews (and other issues) need to be addressed, as discussed in the interim today.
I'm assuming at least some text changes will be required to address all of them.

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

IANA has completed its review of draft-ietf-cbor-edn-literals-09. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are six actions which we must complete.

First, a new registry group will be created called CBOR Diagnostic Notation on the IANA Matrix located at:

https://www.iana.org/protocols

The new registry group will have a reference of [ RFC-to-be ].

Second, a new registry is to be created in the newly created CBOR Diagnostic Notation registry group (above) called the Application-Extension Identifiers registry. The registry is to be managed via Expert Review as defined in RFC8126.

There are initial registrations in the new registry as follows:

Application-extension Identifier Description Reference
--------------------------------+-----------+--------------
h Reserved RFC8949
b32 Reserved RFC8949
h32 Reserved RFC8949
b64 Reserved RFC8949
dt Date/Time [ RFC-to-be ]
ip IP Address/Prefix [ RFC-to-be ]

Third, a new registry is to be created in the newly created CBOR Diagnostic Notation registry group (above) called the Encoding Indicators registry. The registry is to be managed via Specification Required as defined in RFC8126.

There are initial registrations in the new registry as follows:

Encoding Indicator Description Reference
_ Indefinite Length Encoding (ai=31) RFC8949, [ RFC-to-be ]
_i ai=0 to ai=23 [ RFC-to-be ]
_0 ai=24 RFC8949, [ RFC-to-be ]
_1 ai=25 RFC8949, [ RFC-to-be ]
_2 ai=26 RFC8949, [ RFC-to-be ]
_3 ai=27 RFC8949, [ RFC-to-be ]

Fourth, in the application namespace of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a single new registration is to be made as follows:

Name: cbor-diagnostic
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be; Section 4.3 ]

Fifth, in the CoAP Content-Formats in the Constrained RESTful Environments (CoRE) Parameters registry group located at:

https://www.iana.org/assignments/core-parameters/

a single new registration is to be made as follows from the 256-9999 ID range:

Content Type: application/cbor-diagnostic
Content Coding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

IANA notes that the authors request an ID less than 1000.

Sixth, in the Concise Binary Object Representation (CBOR) Tags registry located at:

https://www.iana.org/assignments/cbor-tags/

two new registrations will be made as follows from the 24-32767 range:

Tag: [ TBD-at-Registration ]
Data Item: null or array
Semantics: Diagnostic Notation Ellipsis
Reference: [ RFC-to-be ]

Tag: [ TBD-at-Registration ]
Data Item: array
Semantics: Diagnostic Notation
Unresolved Application-Extension
Reference: [ RFC-to-be ]

IANA notes the guidance given in section 4.5 of the current draft regarding the Tags assigned for these registrations and the suggestions for assignments.

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated and completed the required Expert Review via a separate request.

We understand that these are the only actions 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.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-06-05):

From: The IESG
To: IETF-Announce
CC: cbor-chairs@ietf.org, cbor@ietf.org, christian@amsuess.com, draft-ietf-cbor-edn-literals@ietf.org, orie@transmute.industries
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (CBOR Extended Diagnostic Notation (EDN): Application-Oriented Literals, ABNF, and Media Type) 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: -
'CBOR Extended Diagnostic Notation (EDN): Application-Oriented
  Literals, ABNF, and Media Type'
  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 2024-06-05. 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 Binary Object Representation, CBOR (STD 94, RFC 8949),
  defines a "diagnostic notation" in order to be able to converse about
  CBOR data items without having to resort to binary data.

  This document specifies how to add application-oriented extensions to
  the diagnostic notation.  It then defines two such extensions for
  text representations of epoch-based date/times and of IP addresses
  and prefixes (RFC 9164).

  A few further additions close some gaps in usability.  To facilitate
  tool interoperation, this document specifies a formal ABNF definition
  for extended diagnostic notation (EDN) that accommodates application-
  oriented literals.




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



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

# Orie Steele, ART AD, comments for draft-ietf-cbor-edn-literals-08
CC @OR13

Thanks to Carsten and the CBOR working group for this document.

This review is in the ["IETF Comments" Markdown format][ICMF].
You can use the [`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues, or using this [online validator](https://mnot.github.io/ietf-comments/).

Line numbers are generated with this:
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-cbor-edn-literals-08.txt&submitcheck=True

## Comments

### Is ABNF Definition for Extended Diagnostic Notation normative?

```
853 A.1.  Overall ABNF Definition for Extended Diagnostic Notation

855   This appendix provides an overall ABNF definition for the syntax of
856   CBOR extended diagnostic notation.
```

Note that https://datatracker.ietf.org/doc/html/rfc8610#appendix-B

Starts with:

"This appendix is normative.".


### Encoding indicators

I found Table 2 a bit confusing, `ai=31` is never introduced until the appendix:

```
1014       -  an underscore _ on its own stands for indefinite length
1015         encoding (ai=31, only available behind the opening brace/
1016         bracket for map and array: strings have a special syntax
1017         streamstring for indefinite length encoding except for the
1018         special cases ''_ and ""_), and

1020       -  _0 to _3 stand for ai=24 to ai=27, respectively.

1022       Surprisingly, Section 8.1 of RFC 8949 [STD94] does not address
1023       ai=0 to ai=23 — the assumption seems to be that preferred
1024       serialization (Section 4.1 of RFC 8949 [STD94]) will be used when
1025       converting CBOR diagnostic notation to an encoded CBOR data item,
1026       so leaving out the encoding indicator for a data item with a
1027       preferred serialization will implicitly use ai=0 to ai=23 if that
1028       is possible.  The present specification allows to make this
1029       explicit:

1031       -  _i ("immediate") stands for encoding with ai=0 to ai=23.
```

I recommend adding a sentence or 2 introducing what "ai=" means, where it comes from, and why its sufficient or recommended as a description.

I would expect a brief sentence in a description field, not an equation :)


### Reference to Section G.4 of RFC 8949

```
1051       -  A simple sequence of string chunks is simply joined together.
1052         In both cases of joining strings, the rules of Section G.4 of
1053         RFC 8949 [STD94] need to be followed; in particular, if a text
1054         string results from the joining operation, that result needs to
1055         be valid UTF-8.
```

There does not appear to be a section G.4, perhaps G.3 is the correct reference?

```
1057       -  Some of the strings may be app-strings.  If the type of the
1058         app-string is an actual string, joining of chunked strings
1059         occurs as with directly notated strings; otherwise the
1060         occurrence of more than one app-string or an app-string
1061         together with a directly notated string cannot be processed.
```

This kind of guidance, and the preceding section seem to be doing a lot of nearly normative specification in the appendix.

Ideally, implementers can produce conformant representations without reading the appendix.

### CPA terms and line breaks

I found the note to the RFC Editor a bit confusing:

```
405   // RFC-Editor: This document uses the CPA (code point allocation)
406   // convention described in [I-D.bormann-cbor-draft-numbers].  For
407   // each usage of the term "CPA", please remove the prefix "CPA" from
408   // the indicated value and replace the residue with the value
409   // assigned by IANA; perform an analogous substitution for all other
410   // occurrences of the prefix "CPA" in the document.  Finally, please
411   // remove this note.
```

In some cases I see `/CPA/999` in other places I see `CPA999`.

Ideally there is a single string which can be found and replaced, that is not broken by line wraps, as occurs in Section 3.1


### Examples with ellipses inside comments

```
1234       EDN:  98(['', {}, /rest elided here: …/])

1236       CDDL:  COSE_Sign_Tagged = #6.98(COSE_Sign)
```

`/rest elided here: …/` is a comment containing an ellipses... but where there is not elision?

Perhaps an example that looked something like this would be better:

```
98([h'' / empty encoded protected header /, {} / empty unprotected header /, ... / payload and signature elided /])
```

(also note the h'' change here.)

Same comment with:

```
1251       EDN:  98([/h'a10126'/ << {/alg/ 1: -7 /ECDSA 256/ } >>, /…/])
1252       CDDL:  serialized_map = bytes .cbor header_map
```

I would suggest changing this to:

```
98([ / h'a10126' is the encoded protected header /  << {/alg/ 1: -7 /ECDSA 256/ } >> / decoded protected header /, ... / payload and signature elided /])
```

I also think some new lines and strategic spacing would make these examples more readable.


### Comments inside of byte strings represented in hex

```
1075   The syntax of the content of byte strings represented in hex, such as
1076   h'', h'0815', or h'/head/ 63 /contents/ 66 6f 6f' (another
1077   representation of << "foo" >>), is described by the ABNF in Figure 2.
1078   This syntax accommodates both lower case and upper case hex digits,
1079   as well as blank space (including comments) around each hex digit.
```

This layer of detail seems to belong outside of an appendix.
This example would be better if it matched the example on line 1251, that starts with `EDN:  98([/h'a10126'/`, perhaps explaining the encoded protected header using the comment syntax.


### Consider distinguishing EDN from CDDL earlier

This section in the appendix:

```
1190   EDN was designed as a language to provide a human-readable
1191   representation of an instance, i.e., a single CBOR data item or CBOR
1192   sequence.  CDDL was designed as a language to describe an (often
1193   large) set of such instances (which itself constitutes a language),
1194   in the form of a _data definition_ or _grammar_ (or sometimes called
1195   _schema_).

1197   The two languages share some similarities, not the least because they
1198   have mutually inspired each other.  But they have very different
1199   roots:

1201   *  EDN syntax is an extension to JSON syntax [STD90].  (Any
1202       (interoperable) JSON text is also valid EDN.)

1204   *  CDDL syntax is inspired by ABNF's syntax [STD68].
```

Is helpful, especially if readers could have this in mind when encountering the first instances of CDDL in this document, for example:

```
233   comparing test data.  Information obtained from a CDDL model can help
234   in choosing application-oriented literals or specific string
235   representations such as embedded CBOR or b64'' in the appropriate
236   places.
```

and later:

```

450   A single ellipsis (or key/value pair of ellipses) can imply eliding
451   multiple elements in an array (members in a map); if more detailed
452   control is required, a data definition language such as CDDL can be
453   employed.  (Note that the stand-in form defined here does not allow
454   multiple key/value pairs with an ellipsis as a key: the CBOR data
455   item would not be valid.)
```

These comments regarding CDDL would make more sense if the reader was already aware of the general differences between EDN and CDDL.

## Nits

### expand on first use CDDL

```
169   values.  The term "CDDL" refers to the data definition language
170   defined in [RFC8610] and its registered extensions (such as those in
171   [RFC9165]), as well as [I-D.ietf-cbor-update-8610-grammar].
```

The title of RFC8610 is Concise Data Definition Language (CDDL).

### expand on first use PEG

```
850   intended to be useful in a PEG parser interpretation (see Appendix A
851   of [RFC8610] for an introduction into PEG).
```

The title of the referenced section is Parsing Expression Grammars (PEGs).

### registration procedure clarity

```
692   TBD1 is to be assigned from the space 256..999.
```

I would be clearer to say "TBD1 is to be assigned from the space 256-9999, according to the procedure "IETF Review or IESG Approval".

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has received constructive input from several working group regulars.
Thus, the state is probably best described as a practicing consensus, with few active voices on the list (as is often the case in this WG).

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There war some disagreement about whether the format should be used as an interchange format, but that is more a disagreement on the "how it is used" side and not on the "what we specify" side. (Thread for reference at )

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is one widely used implementation maintained by the author at .
Other implementation have not yet taken this up, but there have been requests to update them.
Note that as this is not an interchange format, there is no immediate need for a large number of implementations,
as the conversion between EDN and CBOR can happen at the end user's device, whereas most devices only process the transmitted CBOR.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

All interactions are through CBOR, which itself does not change as a result of this document.

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

No formal review has been requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

There is no YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The ABNF in the appendices has been checked against the tool at .
It warns of the dependency on RFC7405, which this document duly references.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is ready.

(For context, a shepherd review of the first WGLC'd version is documented at ; reading -08 again produced no further comments).

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

This falls into the ART area's expertise.
No review from that team has been requested, given that both the author and previous reviewers are well familiar with the ART topics.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The intended status is Informational, as reflected in the document and the data tracker.
This is suitable because it does not aim for the interoperability level of a proposed standard (it is not an interchange format).

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The author has been reminded to file any IPR disclosure; none have been filed or are expected to be filed.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No I-D nits were found when comparing the document to the guidelines.

The nits reported by the tools are false positives or otherwise not actionable:
* Non-ASCII characters are acceptable nowadays.
* What appears to be code is structured language that has the right metadata.
* I-D.bormann-cbor-draft-numbers is a reference only inside a comment to the RFC editor.
* This document and I-D.ietf-cbor-update-8610-grammar-03 are expected to be published together.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The normativity status looks good as a whole.
The normativity of the IEEE754, C an Cplusplus references could be altered if one of them were deemed *the* normative reference for the `basenumber` format, but as the explanation treats them as equivalent, they all must be normative.

There are normative references to IANA registries.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The IEEE754, C and Cplusplus references are not freely available.
For the latter two, pointers to equivalent text are provided.
As these three are part of an equivalent set, this is sufficient.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

There are no downrefs.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

There are no unpublished documents in the normative references.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document does not change existing RFCs.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Instructions are clear and consistent.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The new registries of Expert Review and above have clear guidance.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has received constructive input from several working group regulars.
Thus, the state is probably best described as a practicing consensus, with few active voices on the list (as is often the case in this WG).

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There war some disagreement about whether the format should be used as an interchange format, but that is more a disagreement on the "how it is used" side and not on the "what we specify" side. (Thread for reference at )

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is one widely used implementation maintained by the author at .
Other implementation have not yet taken this up, but there have been requests to update them.
Note that as this is not an interchange format, there is no immediate need for a large number of implementations,
as the conversion between EDN and CBOR can happen at the end user's device, whereas most devices only process the transmitted CBOR.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

All interactions are through CBOR, which itself does not change as a result of this document.

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

No formal review has been requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

There is no YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The ABNF in the appendices has been checked against the tool at .
It warns of the dependency on RFC7405, which this document duly references.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is ready.

(For context, a shepherd review of the first WGLC'd version is documented at ; reading -08 again produced no further comments).

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

This falls into the ART area's expertise.
No review from that team has been requested, given that both the author and previous reviewers are well familiar with the ART topics.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The intended status is Informational, as reflected in the document and the data tracker.
This is suitable because it does not aim for the interoperability level of a proposed standard (it is not an interchange format).

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The author has been reminded to file any IPR disclosure; none have been filed or are expected to be filed.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No I-D nits were found when comparing the document to the guidelines.

The nits reported by the tools are false positives or otherwise not actionable:
* Non-ASCII characters are acceptable nowadays.
* What appears to be code is structured language that has the right metadata.
* I-D.bormann-cbor-draft-numbers is a reference only inside a comment to the RFC editor.
* This document and I-D.ietf-cbor-update-8610-grammar-03 are expected to be published together.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The normativity status looks good as a whole.
The normativity of the IEEE754, C an Cplusplus references could be altered if one of them were deemed *the* normative reference for the `basenumber` format, but as the explanation treats them as equivalent, they all must be normative.

There are normative references to IANA registries.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The IEEE754, C and Cplusplus references are not freely available.
For the latter two, pointers to equivalent text are provided.
As these three are part of an equivalent set, this is sufficient.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

There are no downrefs.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

There are no unpublished documents in the normative references.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document does not change existing RFCs.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Instructions are clear and consistent.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The new registries of Expert Review and above have clear guidance.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

@@@

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There war some disagreement about whether the format should be used as an interchange format, but that is more a disagreement on the "how it is used" side and not on the "what we specify" side. (Thread for reference at )

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is one widely used implementation maintained by the author at .
Other implementation have not yet taken this up, but there have been requests to update them.
Note that as this is not an interchange format, there is no immediate need for a large number of implementations,
as the conversion between EDN and CBOR can happen at the end user's device, whereas most devices only process the transmitted CBOR.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

All interactions are through CBOR, which itself does not change as a result of this document.

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

No formal review has been requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

There is no YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The ABNF in the appendices has been checked against the tool at .
It warns of the dependency on RFC7405, which this document duly references.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

@@@ Shepherd review pending.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

This is going into a joint WGLC of  draft-ietf-cbor-edn-literals and draft-ietf-cbor-update-8610-grammar; both will end on Monday November 6th (the Monday of IETF118).

Please read the document, and let us know what you think of it; remember that short reviews of "It'd be useful to me" without any details are also very helpful at this stage.