I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments.
For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-opsawg-sdi-02.txt Reviewer: Francis Dupont Review Date: 20200212 IETF LC End Date: 20200218 IESG Telechat date: unknown Summary: Almost Ready Major issues: None Minor issues: crypto use details are missing. IMHO it is a problem of presentation, I propose: - make only requirements in the first/normative part - put all details in the appendix/demo part Nits/editorial comments: - ToC page 2 and 8 page 11: Acknowledgements -> Acknowledgments - 2 page 4: there are two kinds of certificates so I suggest at the first occurrence to put "public key certificate". - 2 page 5, 2.2 page 5, 4.2 page 6, 5.3 page 10, 7 page 11: e.g -> e.g., - 3.1 page 5: as an example of something which could be specified but IMHO should not be: the certificate has (extended) key usages and other policy parameters. - 4.2 page 6: in "The operator will then encrypt the initial configuration to the key in the certifcate" * the "to" seems a bit strange to me (I expected "with" but I am not a native English speaker) * public key crypto does not provide a way to directly encrypt a large amount of data. IMHO it is not a real problem: just require the key is used to protect the initial configuration * it will be fine to have a bit more than confidentiality, for instance to protect integrity or at least the data length. Last both points are handled by SMIME so again it is only a presentation problem. - 4.3 page 7: Add that DHCP option 66 is TFTP server name and option 150 is TFTP server address. - 5.1 page 10: I've checked (googled it) the TPM abbrev and it seems the common usage in the context is the expected one (BTW it is not in the RFC editor abbrev table). - B.1.1 page 13: IMHO it is a good diea to give the OpenSSL command line (OpenSSL man pages are more than cryptic :-). - B.2.2 page 14: I support the choice of S/MIME: it does the job (including length check) and it is commonly available. Of course there should be better ways but it is clearly far better than a home made solution. BTW as it is encoded ASN.1 it is trivial to recognize (i.e., no ambiguity with ASCII text). - B.3 page 15: then then -> then Regards francis.dup...@fdupont.fr PS: I removed spelling errors which were fixed in version 03. _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
