Subject: [netconf] Éric Vyncke's No Objection on draft-ietf-netconf-sztp-csr-12: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Fri, 10 Dec 2021 02:50:46 -0800

Éric Vyncke 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 for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to Mahesh Jethanandani for the shepherd's write-up even if the
section about the WG consensus does not give any information about the WG
consensus...

I hope that this helps to improve the document,

Regards,

-éric
== COMMENTS ==

-- Section 1.2 --
Just wondering why the terms of SZTP-client/server have to be defined in the
document rather than using the previously defined bootstrap server.

-- Section 1.4 --
Even if the base64 content is rather long, why not providing examples in
appendix ?

-- Section 2.1 --
I am not a YANG expert, but it seems that the lines "module: ietf-sztp-csr"
should only appear once in the tree view ?

In "generate an new asymmetric key", should it rather be a "key pair" ? Of
course, being asymmetric requires two keys so this may be implicit.

-- Section 2.2 --
As P10 is not previously defined (guessing it is PKCS#10 though), suggest
s/P10-based/PCKS#10-based/

In the example for the algorithm leaves, are the base64 values really too long
to be represented in the examples ?

== NITS ==
In section 3, "This module is defines independently" ?

---

From: Kent Watsen <[email-masked]>
Date: Mon, 13 Dec 2021 19:35:03 +0000

Hi Eric,

Thank you for your review.  Responses to your unblocking comments are below.

Kent

> On Dec 10, 2021, at 5:50 AM, Éric Vyncke via Datatracker <[email-masked]> wrote:
> 

Good catch.  The main issue is, I think, that the RFC 8572 uses the term “device”, which is very generic and sometimes maybe confusing (though RFC 8572 does a fine job always establishing context).   We could’ve used “bootstrap-server” and “bootstrap-client”, but it seemed more proper to use “SZTP”, comparable to how folks talk about “SSH client”, “TLS server”, etc. 

> Even if the base64 content is rather long, why not providing examples in

I have 10 other drafts in-progress and the general consensus of the WG is that having real base64 values offers little value while sometimes creating huge readability issues.  I have seen it once where more than a page of draft text was nothing but base64 (a chain of certs).  Much of YANG’s readability comes from matching parameters/indentation and, when huge blocks of gibberish exist, that becomes hard to do.

> should only appear once in the tree view ?

You're so modest  ;)

Actually, an update to the underlying tool I was using to generate the tree diagram had a change in behavior.   Fixed now!

> course, being asymmetric requires two keys so this may be implicit.

Common parlance?  At least, neither of my co-authors (established Sec folks) nor the Secdir had issue with it.

My guess is that the private key is generated while the public key is derived from the private key.

> s/P10-based/PCKS#10-based/

Update applied.

> to be represented in the examples ?

The algorithm-identifiers are pretty small ASN.1 objects...such that the real base64 is just a line long.   That said, I no longer use real base64 values in any of my drafts, so small or not makes no difference...

> In section 3, "This module is defines independently" ?

Good catch:  s/defines/defined/

Kent