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.Dupont@fdupont.fr

PS: I removed spelling errors which were fixed in version 03.