Skip to main content

Last Call Review of draft-ietf-opsawg-sdi-02
review-ietf-opsawg-sdi-02-genart-lc-dupont-2020-02-18-00

Request Review of draft-ietf-opsawg-sdi-02
Requested revision 02 (document currently at 13)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-02-18
Requested 2020-02-04
Requested by Joe Clarke
Authors Warren "Ace" Kumari , Colin Doyle
Draft last updated 2020-02-18
Completed reviews Genart Last Call review of -02 by Francis Dupont (diff)
Opsdir Last Call review of -03 by Mehmet Ersue (diff)
Tsvart Last Call review of -08 by Mirja Kühlewind (diff)
Iotdir Telechat review of -10 by Nancy Cam-Winget (diff)
Comments
While the draft is fairly straight-forward, it would benefit from some more eyes.  In particular, any other security issues other than those called out by the authors as well as risks and implementation pitfalls operators should be aware of would be valuable.
Assignment Reviewer Francis Dupont
State Completed
Review review-ietf-opsawg-sdi-02-genart-lc-dupont-2020-02-18
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/Q6tA2tiQGSMcEtvfsL3oUjGbg9g
Reviewed revision 02 (document currently at 13)
Result Almost Ready
Completed 2020-02-18
review-ietf-opsawg-sdi-02-genart-lc-dupont-2020-02-18-00
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.