-----Original Message----- From: Roman Danyliw via Datatracker <[email protected]> Sent: Tuesday, June 9, 2020 10:27 AM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; Matthew Miller <[email protected]>; [email protected] Subject: Roman Danyliw's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-cose-rfc8152bis-algs-09: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the easy to read diff on a bis document, and for addressing the SecDir feedback. ** Section 8. Per “For an algorithm, the first element should always be a key type value, but the items that are specific to a key should not be included in the algorithm capabilities” and later “For a key, the first element should also be a key type value” is there a reason for not making these “should” into normative MUSTs? [JLS] Yes, consider what the capabilities would be for a hash algorithm, it has no key so that would make the first one not a MUST. This is advisory, after it is set then it is going to be known and not changed. This means that all one needs to know in the end is what the sequence is. ** Section 8. I would have benefited from more text to understand how to parse a capabilities field. IMO, it would have been helpful to say that the first element of the array maps to the Value column of the COSE Key Type registry. The new Capabilities column of that corresponding entry describes the semantics of the second array element. [JLS] Given the above do you still feel this way? ** Editorial Nits: -- The text in the header notes this document is standards track. However, the datatracker and shepherd write-up note that it is informational. I suspect it should be fixed in this document to be informational. [JLS] The document is wrong and fixed. -- Abstract. Please remove the explicit references from abstract (as they are not permitted to be there) [JLS] As I have noted elsewhere, for drafts I prefer this to make sure that it is seen by the RFC Editor and corrected. -- Abstraction. Editorial. The sentence “In this specification the conventions …” is incomplete. [JLS] Changed to "This specification defines the conventions for the use of a number of cryptographic algorithms with COSE." -- Section 1. Editorial. “Additional algorithms beyond what are in this document are defined elsewhere”. IMO, this sentence doesn’t appear to add anything. Recommend removal. [JLS] Done - I guess the word 'initial' makes the point that other can be defined. -- Section 8. Per ”There is a presumption in the way that this is laid out is that the algorithm identifier itself is not needed to be a part of this as it is specified in a different location”, I had trouble following this sentence from the previous one – what is the double reference to “this” here? [JLS] How about "The algorithm identifier is not included in the capabilities data as it should be encoded elsewhere in the message." -- Section 8.3. Typo. s/it is encodes/, they encode/ [JLS] Already rewritten -- Section 10.2. Typo. s/rquested/requested/ [JLS] Fixed. _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
