Thank you for your review, Francis. This was helpful. I think it will add additional clarity.
Joe > On Feb 18, 2020, at 10:02, Francis Dupont <francis.dup...@fdupont.fr> wrote: > > 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
