On Stable Storage for Items in Concise Binary Object Representation (CBOR)
draft-ietf-cbor-file-magic-12

[Ballot comment]
Hi,

Apologies for a late review, and there is just one none blocking issue that I wanted to raise:

  It is further
  suggested to avoid values that have an embedded zero byte in the four
  bytes of their binary representation (such as 0x12003456), as these
  may confuse implementations that treat the magic number as a C
  string.

I was less convinced by this statement because:
(1) It seems like C treating this as null terminated string is probably not the right thing to do, I'm not sure that we should be implicitly endorsing that.
(2) When translating values from the Content-Format registry means that this issue is presumably unavoidable.  I.e., it looks like your example in 2.2.1 violates this guidance.

Regards,
Rob

[Ballot comment]
Thanks for this document. It seems useful, and the core specification
part in Section 2 is clear and understandable.

That said, it could be even friendlier to someone approaching it as a
CBOR n00b. I don't think that's a major concern, because I can’t
imagine why someone other than a hapless IESG member would approach this
document cold, without some reasonable background in CBOR. Still, if you
want an example of what I'm talking about, the casual "so that there are
no leading zeroes" in Section 2.1, with no whys or wherefores, felt a
bit like a scavenger hunt.

I also agree with a number of Lars's comments (in particular, what's a...
disk? Some technology from the 1900s?). Also Zahed's suggestion to move
Section 3 to an appendix.

Finally, while I am quibbling about style, I thought the trips down
memory lane and visits to sites of software grievances of Christmas
Past in Sections 1 and 3 slowed down the read without adding insight.

Finally, I do have one specific comment on where the text is unclear in
Section 2.2:

  A CBOR Protocol specification may specify the use of two tags only
  for specific cases.  For instance, it might use them when storing the
  representation in a local file or for Web access, but not when using
  them in protocol messages that already provide the necessary context.

The first sentence reads like a prohibition on specification of two tags
for general cases. (I don't know what that would mean, it's just a
straightforward way to parse it. "May" combined with "only" is
the difficult bit I think.) If your meaning is what I think it is,
substituting "might" for "may" would fix it.

But in the final analysis, the fact that all I've got is quibbles is
evidence of a job well done, thank you. :-)

[Ballot comment]
There is a statement in this document in Appendix B that I cannot agree with due to a past legal dispute that involved one of the document authors which prevents me from balloting No Objection.

[Ballot comment]
There is a statement in this document in Appendix B that I cannot agree with due to a past legal dispute which prevents me from balloting No Objection.

[Ballot comment]
Thanks for working on this document. I kind of like the question/answer style of writing the document.

Some comments/questions below, and I think addressing them would help improving the document.

- Section 2.1: it say's

      This tag needs to be allocated by the author of the CBOR Protocol
 
  it was not clear to me if "this tag" is the same tag that needs IANA registration or not. It needs some clarification text on that.

- file(1) is both referred as command and program, I always thought it is a command.

- Section 3.2: I didn't get the proper motivation for this section in this document. There were no mention of other CBOR data items and certainly they become the center piece in this section. I think it would be great to add some text about the motivation.

- Speaking very frankly I feel like section 3.1 and section 3.2 are not the center part of this specification and should be moved to appendix section.

[Ballot discuss]
Section 2.1.

(a) "In both enveloping methods, CBOR Protocol designers need to obtain a CBOR tag for each kind of object that they might store on disk.  ... The IANA policy for 4-byte CBOR Tags is First Come First Served, ..."

(b) "This tag needs to be allocated by the author of the CBOR Protocol."

Both of these statements are made in this section and they appear to conflict.  (a) appears to be saying that CBOR tags will be allocated from the FCFS IANA registry to the protocol designer.  However, later in the section (b) says that the author is allocating the tags.  If the author performing the allocation/assignment, it would seem to be coming from the registry per (a).

[Ballot comment]
Thank to Chris Wood for the SECDIR review.  Please review the editorial suggestions posed there.

** Section 2.2
  This method wraps the CBOR value as tags usually do.  Applications
  that need to send the CBOR value across a constrained link may wish
  to remove the two tags if the use is implicitly understood.

Is this behavior akin to not using this enveloping method?

** Section 3.3
  If the Protocol expects to use other tags values at the top-level,
  then the use of the tag wrapped format may be easier to explain in
  the protocol description.

(As also pointed by Chris Wood in the SECDIR review) This text would benefit from refinement.  Specifically:

-- what does it mean to be “easier to explain in the protocol description”?

-- how does a top-level tag that isn’t one of the two approaches posed here work with the rest of the behavior in this document?

** Section 4.  Consider adding the following generic text on relying on “magic values”:

End-point assessment technologies should not solely rely on the meta data approaches described in this document to decide whether to inspect a given file.

Depending on operating systems configurations and related properties of the execution environment, use of these meta data approaches could influence the default application used to process a file, regardless of whether this file in fact contains CBOR.

[Ballot comment]
"Abstract", paragraph 1, comment:
>    This document defines an on-disk format for CBOR data items that is
>    friendly to common on-disk recognition systems such as the Unix
>    file(1) command.

I suggest to not talk about disks or stable storage in this abstract or the
document body. What's actually being defined here is a file layout, and files
can be stored on a variety of media. (And "file" isn't an "on-disk recognition
system" either, it's a heuristic file type classifier.)

Section 2.1, paragraph 1, comment:
>    The IANA policy for 4-byte CBOR Tags is First Come First Served, so
>    all that is required is an email to IANA, having filled in the small
>    template provided in Section 9.2 of [STD94].

FCFS codepoints may be requested in different ways in the future (e.g., web
forms) in addition to email. The document need not go into details on how FCFS
requests are made.

Section 2.1, paragraph 0, comment:
>    In order to be in the four-byte range, and so that there are no
>    leading zeros, the value needs to be in the range 0x01000000 (decimal
>    16777216) to 0xFFFFFFFF (decimal 4294967295).

Including or excluding those two boundary values?

Section 2.1, paragraph -1, comment:
>    The use of a sequence of four US-ASCII codes which are mnemonic to
>    the protocol is encouraged, but not required.

If it's encouraged, why not require it, so that software can actually depend on
it rather than needing to test for it? (Ditto for the suggestion to avoid
zeroes.)

Thanks to Pete Resnick for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/UX8_f-rnj6FGgrSKRd-WCB8SuYg).

-------------------------------------------------------------------------------

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.

Paragraph 7768, nit:
>  shutting the daemon down. During testing it is sometimes the case that upgr
>                                  ^^^^^^^
A comma is probably missing here.

Paragraph 7824, nit:
> ot normally loaded in the daemon. Instead the IPC that is normally sent acro
>                                  ^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Instead".

[Ballot comment]
Thank you for the work put into this document. This document describes a nice addition to CBOR.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Christian Amsüss for the shepherd's write-up even if the justification for the intended status is somehow weak (but at least present).

I hope that this helps to improve the document,

Regards,

-éric

## General comment

I was about to ballot a DISCUSS due to the absence of BCP14 and any normative language in a standard track document. Explanations from the authors/WG/AD will be more than welcome as I am not convinced by the shepherd's explanation ("let's avoid down ref in the future").

## Abstract

Just wondering whether the "on-disk" actually reflects the use of the Unix `file` command as this command also works on many other file systems / storage.

The abstract seems to indicate that there is ONE format while the rest of the document is about THREE formats. Suggest to update the abstract to reflect the choice among 3 formats.

## Section 1

Unsure whether the comparison of Unix file with TCP/IP stream brings any value.

Should there be a reference for "MIME type" ?

Should there be a reference for "media type registration template" ?

BTW, this section reads like a nice set of anecdotes, which is easy to read, but a more logical flow would be a plus for the reader.

A reference to CBOR RFC 8742 is probably required.

"magic number" should perhaps be introduced before citing it ?

Unsure whether the paragraph "A major inspiration ..." brings any value to the text.

## Section 1.2

Is the 'magic number' unique per CBOR protocol or just for any CBOR protocol? (i.e., this definition seems really restricted to CBOR and not to `file`) Should it also be distinct from other 'magic numbers' in /etc/magic ?

## Section 2

I am confused, and probably misread the document, but earlier I had the impression that THREE methods will be specified in this document and this section defines only TWO.

## Section 2.1

Should the 4-byte magic number be different than the existing 'magic numbers' supported by `file` ?

## Section 2.2.1

I must be really confused (and sorry about that) but the example contains a 0x00 which contradicts the above "avoid values that have an embedded zero byte" (from section 2.1).

## Section 3

I really love the "COVID vaccination certificate that needs to be displayed in QR code form" example (just use "COVID-19" perhaps) but should a reference be added ?

The considerations for the protocol designers do not really fit my ideas about a standard track document but rather of a BCP.

# NITS 

## Section 1

In "two possible methods of enveloping data are presented: a CBOR Protocol designer will specify one", should the ":" rather be a ";" ? Anyway, the RFC editor will review it ;-)

## Section 2.3

Please be consistent with the use of lower case or upper case for hexadecimal numbers, e.g., 0x42_4f_52

[Ballot discuss]
Thank you for the work put into this document. This document describes a nice addition to CBOR.

Please find below one blocking DISCUSS points (mainly to generate discussion -- I will clear my DISCUSS most probably after discussion), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Christian Amsüss for the shepherd's write-up even if the justification for the intended status is somehow weak (but at least present).

I hope that this helps to improve the document,

Regards,

-éric

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

Just a normal DISCUSS based on the absence of BCP14 and any normative language in a standard track document. Explanations from the authors/WG/AD will be more than welcome as I am not convinced by the shepherd's explanation (basically "let's avoid down ref").

[Ballot comment]
# COMMENTS

## Abstract

Just wondering whether the "on-disk" actually reflects the use of the Unix `file` command as this command also works on many other file systems / storage.

The abstract seems to indicate that there is ONE format while the rest of the document is about THREE formats. Suggest to update the abstract to reflect the choice among 3 formats.

## Section 1

Unsure whether the comparison of Unix file with TCP/IP stream brings any value.

Should there be a reference for "MIME type" ?

Should there be a reference for "media type registration template" ?

BTW, this section reads like a nice set of anecdotes, which is easy to read, but a more logical flow would be a plus for the reader.

A reference to CBOR RFC 8742 is probably required.

"magic number" should perhaps be introduced before citing it ?

Unsure whether the paragraph "A major inspiration ..." brings any value to the text.

## Section 1.2

Is the 'magic number' unique per CBOR protocol ? (i.e., this definition seems really restricted to CBOR and not to `file`) Should it also be distinct from other 'magic numbers' in /etc/magic ?

## Section 2

I am confused, and probably misread the document, but earlier I had the impression that THREE methods will be specified in this document and this section defines only TWO.

## Section 2.1

Should the 4-byte magic number be different than the existing 'magic numbers' supported by `file` ?

## Section 2.2.1

I must be really confused (and sorry about that) but the example contains a 0x00 which contradicts the above "avoid values that have an embedded zero byte" (from section 2.1).

## Section 3

I really love the "COVID vaccination certificate that needs to be displayed in QR code form" example (just use "COVID-19" perhaps) but should a reference be added ?

The considerations for the protocol designers do not really fit my ideas about a standard track document but rather of a BCP.

# NITS 

## Section 1

In "two possible methods of enveloping data are presented: a CBOR Protocol designer will specify one", should the ":" rather be a ";" ? Anyway, the RFC editor will review it ;-)

## Section 2.3

Please be consistent with the use of lower case or upper case for hexadecimal numbers, e.g., 0x42_4f_52

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

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

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the CBOR Tags registry on the Concise Binary Object Representation (CBOR) Tags registry page located at:

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

the early registration for:

Tag: 55800
Data Item: byte-string
Semantics: indicates that the file contains one or more CBOR Sequences

will have its reference changed to [ RFC-to-be ].

Second, also in the CBOR Tags registry on the Concise Binary Object Representation (CBOR) Tags registry page located at:

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

a new registration will be made as follows:

Tag: 55801
Data Item: tagged byte string
Semantics: indicates that the file starts with a CBOR-Labeled Non-CBOR Data label
Reference: [ RFC-to-be ]

Third, also in the CBOR Tags registry on the Concise Binary Object Representation (CBOR) Tags registry page located at:

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

the following tags will be registered as follows:

Tags: 1668546560-1668612095
Data Item: byte string
Semantics: the representation of content-format 1668546560-1668612095
Reference: [ RFC-to-be ]

The IANA Functions Operator understands 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.

Please note that specific values cannot be reserved. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-04-15):

From: The IESG
To: IETF-Announce
CC: cbor-chairs@ietf.org, cbor@ietf.org, christian@amsuess.com, draft-ietf-cbor-file-magic@ietf.org, francesca.palombini@ericsson.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (On storing CBOR encoded items on stable storage) 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: -
'On storing CBOR encoded items on stable storage'
  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 2022-04-15. 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


  This document defines an on-disk format for CBOR objects that is
  friendly to common on-disk recognition systems such as the Unix
  file(1) command.




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



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

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document aims to become a Proposed Standard. It does have characteristics that would also indicate Informational (it is registering code points in FCFS regions of IANA registries), but we anticipate that this mechanism will be used and referenced in future normative documents, thus going for PS.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document defines an on-disk format for CBOR data items that is friendly to common on-disk recognition systems such as the Unix file(1) command. It describes methods for the different cases of tagging CBOR objects, CBOR streams and for data transported in CoAP messages.

Working Group Summary:

The process through the WG was unremarkable, with small controversies at bikeshedding level sorted out during interims.

Document Quality:

Based on this document, OpenSWAN has allocated CBOR tags and is using them; updates to the file magic database are being prepared.
The document was authored and reviewed by the designated experts for CBOR tag allocations.

Personnel:

Christian Amsüss is Document Shepherd, Francesca Palombini is Responsible Area Director.

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

The review found some inconsistencies or vagueness in areas that were edited relatively recently; the concerns were addresse swiftly, and the shepherd has no further comments on -10. Three single-word changes are still outstanding, but minor enough that they are not expected to impact the IESG review.

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

No. There have been few on-list reviews, but much collaboration inside the WG during interim meetings as documented in their minutes.

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

File formats and file type recognition falls into the broad ART area expertise; review has been solicited, provided by Bernard Aboba (see ), and addressed in the later versions of the document (eg. the switch to Proposed Standard).

(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?

No 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?

The authors are not personally aware of any patent claims that would read on this specification.

(8) Has an IPR disclosure been filed that references this document?

No IPR has been disclosed to date.

(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?

It's a small working group, but the document is supported and understood by a large portion. (Looking at the list interactions and interim minutes, most of that is visible from adoption time; in later stages discussions were mostly about details more relevant on a quality-of-document level than on a consensus-on-what-we-do level and thus involved fewer vocal people).

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

The tools complain about non-ASCII characters and reference mismatches (on RFC8949 / STD94); both appear to be in order in the produced documents.

(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 review criteria apply.

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

Yes; in particular, none of the informative references are required to understand when implementing this document.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?

No.

(15) Are there downward normative references (see RFC 3967)?

No.

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

No.

(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 include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations describe one tag that has been allocated already from a draft; that description does not match verbatim any more (the registry can be updated at release time).
Allocations are consistent with the relevant sections of the text.
The registry is not identified by its full name, the authors will refine it together with any updates resulting from IESG review.

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

All allocations happen in FCFS areas.

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

The CDDL snippets in the code validated on https://cddl.anweiss.tech/

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

No YANG modules are present.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document aims to become a Proposed Standard. It does have characteristics that would also indicate Informational (it is registering code points in FCFS regions of IANA registries), but we anticipate that this mechanism will be used and referenced in future normative documents, thus going for PS.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document defines an on-disk format for CBOR data items that is friendly to common on-disk recognition systems such as the Unix file(1) command. It describes methods for the different cases of tagging CBOR objects, CBOR streams and for data transported in CoAP messages.

Working Group Summary:

The process through the WG was unremarkable, with small controversies at bikeshedding level sorted out during interims.

Document Quality:

Based on this document, OpenSWAN has allocated CBOR tags and is using them; updates to the file magic database are being prepared.
The document was authored and reviewed by the designated experts for CBOR tag allocations.

Personnel:

Christian Amsüss is Document Shepherd, Francesca Palombini is Responsible Area Director.

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

The review found some inconsistencies or vagueness in areas that were edited relatively recently; the concerns were addresse swiftly, and the shepherd has no further comments on -10. Three single-word changes are still outstanding, but minor enough that they are not expected to impact the IESG review.

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

No. There have been few on-list reviews, but much collaboration inside the WG during interim meetings as documented in their minutes.

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

File formats and file type recognition falls into the broad ART area expertise; review has been solicited, provided by Bernard Aboba (see ), and addressed in the later versions of the document (eg. the switch to Proposed Standard).

(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?

No 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?

The authors are not personally aware of any patent claims that would read on this specification.

(8) Has an IPR disclosure been filed that references this document?

No IPR has been disclosed to date.

(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?

It's a small working group, but the document is supported and understood by a large portion. (Looking at the list interactions and interim minutes, most of that is visible from adoption time; in later stages discussions were mostly about details more relevant on a quality-of-document level than on a consensus-on-what-we-do level and thus involved fewer vocal people).

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

The tools complain about non-ASCII characters and reference mismatches (on RFC8949 / STD94); both appear to be in order in the produced documents.

(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 review criteria apply.

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

Yes; in particular, none of the informative references are required to understand when implementing this document.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?

No.

(15) Are there downward normative references (see RFC 3967)?

No.

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

No.

(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 include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations describe one tag that has been allocated already from a draft; that description does not match verbatim any more (the registry can be updated at release time).
Allocations are consistent with the relevant sections of the text.
The registry is not identified by its full name, the authors will refine it together with any updates resulting from IESG review.

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

All allocations happen in FCFS areas.

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

The CDDL snippets in the code validated on https://cddl.anweiss.tech/

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

No YANG modules are present.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document aims to become a Proposed Standard. It does have characteristics that would also indicate Informational (it is registering code points in FCFS regions of IANA registries), but we anticipate that this mechanism will be used and referenced in future normative documents, thus going for PS.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document defines an on-disk format for CBOR objects that is friendly to common on-disk recognition systems such as the Unix file(1) command. It describes methods for the different cases of tagging CBOR objects, CBOR streams and for data transported in CoAP messages.

Working Group Summary:

The process through the WG was unremarkable, with small controversies at bikeshedding level sorted out during interims.

Document Quality:

Based on this document, OpenSWAN has allocated CBOR tags and is using them; updates to the file magic database are being prepared.
The document was authored and reviewed by the designated experts for CBOR tag allocations.

Personnel:

Christian Amsüss is Document Shepherd, Francesca Palombini is Responsible Area Director.

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

The review found some inconsistencies or vagueness in areas that were edited relatively recently; the concerns were addresse swiftly, and the shepherd has no further comments on -10.

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

No. There have been few on-list reviews, but much collaboration inside the WG during interim meetings as documented in their minutes.

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

File formats and file type recognition falls into the broad ART area expertise; review has been solicited, provided by Bernard Aboba (see ), and addressed in the later versions of the document (eg. the switch to Proposed Standard).

(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 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?

The authors are not personally aware of any patent claims that would read on this specification.

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

No IPR has been disclosed to date.

(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?

It's a small working group, but it is supported and understood by a large portion. (Looking at the list interactions and interim minutes, most of that is visible from adoption time; in later stages discussions were mostly about details more relevant on a quality-of-document level than on a consensus-on-what-we-do level and thus involved fewer vocal people).

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

The tools complain about non-ASCII characters and reference mismatches (on RFC8949 / STD94); both appear to be in order in the produced documents.

(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 review criteria apply.

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

Yes; in particular, none of the informative references are required to understand when implementing this document.

(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?

No.

(15) Are there downward normative 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? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(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 include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations describe one tag that has been allocated already from a draft; that description does not match verbatim any more (the registry can be updated at release time).
Allocations are consistent with the relevant sections of the text.
The registry is not identified by its full name, the authors will refine it together with any updates resulting from IESG review.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

All allocations happen in FCFS areas.

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

The CDDL snippets in the code validated on https://cddl.anweiss.tech/

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

No YANG modules are present.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document aims to become a Proposed Standard. It does have characteristics that would also indicate Informational (it is registering code points in FCFS regions of IANA registries), but we anticipate that this mechanism will be used and referenced in future normative documents, thus going for PS.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document defines an on-disk format for CBOR objects that is friendly to common on-disk recognition systems such as the Unix file(1) command. It describes methods for the different cases of tagging CBOR objects, CBOR streams and for data transported in CoAP messages.

Working Group Summary:

TBD (Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?)

Document Quality:

TBD (Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?)

Personnel:

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

Christian Amsüss is Document Shepherd, Francesca Palombini is Responsible Area Director.

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

TBD

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

No. There have been few on-list reviews, but much collaboration inside the WG during interim meetings as documented in their minutes.

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

File formats and file type recognition falls into the broad ART area expertise; review has been solicited, provided by Bernard Aboba (see ), and addressed in the later versions of the document (eg. the switch to Proposed Standard).

(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 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?

TBD

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

No IPR has been disclosed to date. (TBD check before submit).

(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?

It's a small working group, but it is supported and understood by a large portion. (Looking at the list interactions and interim minutes, most of that is visible from adoption time; in later stages discussions were mostly about details more relevant on a quality-of-document level than on a consensus-on-what-we-do level and thus involved fewer vocal people).

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

The tools complain about non-ASCII characters and reference mismatches (on RFC8949 / STD94); both appear to be in order in the produced documents.

(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 review criteria apply.

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

Yes; in particular, none of the informative references are required to understand when implementing this document.

(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?

No.

(15) Are there downward normative 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? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(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 include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

TBD

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

All allocations happen in FCFS areas.

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

The CDDL snippets in the code validated on https://cddl.anweiss.tech/

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

No YANG modules are present.

Going through a second WGLC as there has been substantial change since the -02 that was reviewed; it is relatively brief as there has been good WG interaction about the aspects that were altered.