[netconf] Roman Danyliw's No Objection on draft-ietf-netconf-sztp-csr-12: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-netconf-sztp-csr-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Yaron Sheffer for the SECDIR review.

** Section 4.1.1.

For instance, an NMS controller/orchestrator
   application could periodically prompt the SZTP-client to generate a
   new private key and provide a certificate signing request (CSR) or,
   alternatively, push both the key and an identity certificate to the
   SZTP-client using

I don’t have a sense of the classes of endpoints that would rely on SZTP. 
Would it include highly constrained or battery powered devices for which this
re-keying would be too expensive?

** Editorial nits:
-- Section 2.1.  s/an new/a new/
-- Section 2.2.  Typo. s/Following are/The following are/
-- Section 4.1.1.  s/forever contain/contain/