Ballot for draft-kucherawy-rfc8478bis
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
Please review and respond to Daniel Migault SECDIR review.
Thank you for the work put into this document. And, I like the fact that the authors put in evidence in the abstract that it is NOT a standard document from the IETF. Albeit I wonder why this document is not requested to be pubslished as a standard. Due to too many documents for this telechat (and one week of vacations to be honest...), I am balloting "No objection" trusting the ballots of my IESG colleagues/friends. I only quickly browsed the document with my internet area glasses. Nevertheless, please find below some non-blocking COMMENTs and NITS. I hope that this helps to improve the document, Regards, -éric == DISCUSS == == COMMENTS == -- Section 3.1.1 -- May I suggest to use the wording "0 or 4 bytes" rather than "0-4 bytes" for the Content_Checksum? The former hints to have a variable length between 0 and 4 bytes long. -- Section 3.1.1.1. -- To be honest (possibly because of my quick browse), I fail to understand why the frame header has a minimum size of 2 bytes while all fields are optional except for the 1-byte Frame_Header_Descriptor ? == NITS == A couple of nits, like in section 3.1.1.3.1.1. where the values 00, 10, ... should be identified as binary values.
Please respond to the secdir review. The guidance in Section 3.1.1.2.3 (of RFC 8478; now Section 3.1.1.2.4 of the -03) to send a Raw Block if compression would result in exceeding the maximum size seems like it might be worth retaining. [I did a fairly thorough review of what became RFC 8478, so here I mostly just look at the diff.] Section 1 This document describes the Zstandard format. Also, to enable the transport of a data object compressed with Zstandard, this document registers a media type that can be used to identify such content when it is used in a payload encoded using Multipurpose Internet Mail Extensions (MIME). It also registers a media-type structured syntax suffix. Section 6 It's a little weird to have a "Section 6 -- Use of Dictionaries" and a "Section 7.4 --Dictionaries" that have fairly related content. Provisioning for use of dictionaries with zstd is planned for future work. To ensure compatibility with the future specification of use Is this planned to involve widely-distributed and well-known dictionaries, or a more localized provisioning process (or both)? It might be worth clarifying. Section 7 I'd consider "has updated the reference field for two previously existing registrations and made one new registration". Section 9 Are there additional implementations that are worth mentioning now that almost a couple years have passed? Acknowledgments It may be worth retaining the acknowledgments from RFC 8478 with a note of their provenance, given how little has changed since then.
I only had time to quickly review the diff which seems fine...