[Cbor] Lars Eggert's No Objection on draft-ietf-cbor-file-magic-11: (with COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

Lars Eggert has entered the following ballot position for
draft-ietf-cbor-file-magic-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cbor-file-magic/



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