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

[Kent Watsen <[e-mail]>]

Hi Roman,

Thank you for your review!   Below are responses to your comments.

Diffs: https://github.com/netconf-wg/sztp-csr/commit/f31f47932f60b88a746b8ec7a26a6f00986355e9 <https://github.com/netconf-wg/sztp-csr/commit/f31f47932f60b88a746b8ec7a26a6f00986355e9>

Kent (and Sean and Russ)


> On Dec 15, 2021, at 7:05 PM, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> 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, e.g., a PKCS #12 [RFC7292].
> 
> 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?

Possibly.  For the most part, IoT deployments seem to be going to BRSKI route (though that isn’t any more efficient in this regrade).  All of the SZTP deployments I’m aware of are easily able to generate fresh keying material.  But note that, if extreme cases, the material could be pushed to the device via a p12, which obviates concern, no?

[No update to the draft has been made to reflect this comment yet.]


> 
> ** Editorial nits:
> -- Section 2.1.  s/an new/a new/

Fixed!  (Change made by an earlier review)


> -- Section 2.2.  Typo. s/Following are/The following are/

Instead used s/Following are/Below are/  - otherwise okay to let copy editor handle?


> -- Section 4.1.1.  s/Forever contain/contain/

Fixed!