Mike Bishop has entered the following ballot position for draft-ietf-cose-merkle-tree-proofs-14: 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-cose-merkle-tree-proofs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 2, I don't understand the "introduces a new Section..." language. This reads as if updating an existing RFC to add new sections to it, but the links are to sections in this document. Those sections establish new registries; should this say "a new registry (see Section ...) that contains..."? The notation used in Section 4.1 ("EC2 keys (1: 2)") probably warrants a bit more explanation. By parallel with the "(TBD_1 : 1)" below, I presume that it should be read "When COSE header parameter 1 is set to the value 2..."? Section 5.2.1 appears to contain guidance to future VDS definitions, but Section 5 is intended to be a definition of one specific VDS as well as an exemplar of how to do such a definition. That guidance might be better placed elsewhere and let Section 5 focus on this specific VDS. Note also that the recommended behavior (making payloads detatched) is then carried out a few paragraphs later along with a duplicative explanation of why that needs to be done. As Ralph Merkle (inventor of the Merkle tree) is a person, "Merkle" should be capitalized throughout. ===NITS FOLLOW=== Section 1, "proves" => "proofs"? Section 4.2, "merkle tree based" => "Merkle-tree-based" Section 4.3, "this Receipts" should probably be "these Receipts" or simply "Receipts" Section 4.3, "verifiable data structure specific" => "verifiable-data-structure-specific" Section 4.3.1, "an IANA registration must be made for each individually supported algorithm" => "a separate IANA registration must be made for each supported algorithm" _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
