Francis, thanks for your review. Warren, thanks for addressing Francis’ comments. I entered a No Objection ballot.
Alissa > On Mar 6, 2020, at 12:13 PM, Warren Kumari <war...@kumari.net> wrote: > > Whoops, apologies, I just realized that I forgot to mention that I've > posted a new version (-05) addressing these / hit send too soon. > > Thank you again, Francis. > W > > > On Fri, Mar 6, 2020 at 12:09 PM Warren Kumari <war...@kumari.net > <mailto:war...@kumari.net>> wrote: >> >> Wow, apologies, I had completely missed this email -- I have a complex >> set of filtering rules to allow me to focus on drafts on the upcoming >> telechats, and this fell into the cracks. >> >> On Tue, Feb 18, 2020 at 10:57 AM 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 >> >> Thank you. >> >> I have attempted to do this - where I have crypto discussion I am >> clarifying that this is just illustrative, and that the vendor should >> figure out what is best for their environment. I also suggest vendors >> may want to consider draft-gutmann-scep. >> >>> >>> Nits/editorial comments: >>> - ToC page 2 and 8 page 11: Acknowledgements -> Acknowledgments >> >> Thank you, done. >> >>> >>> - 2 page 4: there are two kinds of certificates so I suggest at the >>> first occurrence to put "public key certificate". >> >> Done. Thank you. >> >>> >>> - 2 page 5, 2.2 page 5, 4.2 page 6, 5.3 page 10, 7 page 11: e.g -> e.g., >> >> Done (x8!) >> Thank you. >> >> >>> >>> - 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. >> >> I added: :The vendor's Certificate Publication >> Server should only accept certificates from the manufacturing facility, >> and which match vendor defined policies (for example, extended key usage, >> extensions, etc.)" >> >> Does this address your concern? I suspect that this section (and >> others :-)) will get a fair but of discussion / feedback during IETF >> LC, and SecDir / IESG review :-) >> >>> >>> - 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. >> >> Thank you -- the example uses SMIME specifically for this reason. I >> was trying to word it in a way that was neither too prescriptive, nor >> too convoluted. How is: >> "The operator will then encrypt the initial >> configuration (for example, using SMIME) using the key in the certificate, >> and place it on their TFTP server. " >> >>> >>> - 4.3 page 7: Add that DHCP option 66 is TFTP server name and >>> option 150 is TFTP server address. >> >> Oooh, thank you. Done. >> >>> >>> - 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). >> >> Thank you - I expanded it. >> >>> >>> - B.1.1 page 13: IMHO it is a good diea to give the OpenSSL command >>> line (OpenSSL man pages are more than cryptic :-). >> >> Thank you - OpenSSL CLI processing is indeed, um, cryptic. I somewhat >> think that this is by design - if someone accidentally publishes their >> key, it doesn't actually matter, because no-one will figure out how to >> invoke OpenSSL to *do* anything with it :-P >> >>> >>> - 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). >> >> Thank you! >> >>> >>> - B.3 page 15: then then -> then >> >> Oooh, good catch, fixed, thank you. >> W >> >> >>> Regards >>> >>> francis.dup...@fdupont.fr >>> >>> PS: I removed spelling errors which were fixed in version 03. >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org <mailto:Gen-art@ietf.org> > https://www.ietf.org/mailman/listinfo/gen-art > <https://www.ietf.org/mailman/listinfo/gen-art>
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
