Re: [netconf] Éric Vyncke's No Objection on draft-ietf-netconf-tls-client-server-39: (with COMMENT)

[Kent Watsen <[e-mail]>]

Hi Éric,

Thank you for your valuable comments.
Please find responses below.

Kent // author



> On Feb 29, 2024, at 5:04 AM, Éric Vyncke via Datatracker <[e-mail]> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-netconf-tls-client-server-39: 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/about/groups/iesg/statements/handling-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-tls-client-server/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> # Éric Vyncke, INT AD, comments for draft-ietf-netconf-tls-client-server-39
> 
> Thank you for the work put into this document, with its companion I-Ds, this
> represents a huge work.

You bet it does!  Almost seven years in the making…


> 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 Jeff Hartley  for the shepherd's write-up including the WG
> consensus and the (light) justification of the intended status.
> 
> I hope that this review helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> # COMMENTS (non-blocking)
> 
> ## Warning about Yangcatalog.org
> 
> The Python code in the annex generates several errors when the RFC is validated
> by yangcatalog.org. While expected, it would be nice to have some text about
> this issue in the shepherd write-up.

This is a known issue.  Russ Housely suggested a fix which I applied for my next upload.  The trick is the make DataTracker not think that the Python code's YANG is a real YANG module - grrr


> ## Section 1
> 
> Suggestion: be consistent with the use of double-quotes
> 
> s/This document only defines that the IANA module exists/This document
> *assumes* that the IANA module exists/ ?

Fixed, per suggestion.

Fixed in the ssh-client-server draft also.


> ## Section 2
> 
> `Note that TLS1.2 only uses TLS Cipher Suites` seems to contradict the previous
> sentence "should". Rewording would make this paragraph easier to read.

Removed offending sentence.


> ## Section 2.2
> 
> To be honest, I was about to ballot DISCUSS on this point, but I have already
> balloted too many discuss point on this nice set of I-Ds.
> 
> The example has `tls11`, which is no more a version defined in this document.

“tls11" has now been removed, per other IESG review comments.


> ## Section 2.3
> 
> I see three authors for the YANG module but only one of them is the I-D author.
> Any reason why ?

The author discrepancy is because they stepped in to update a YANG module, but didn’t submit any document-body level text.  I think that it is fair.


> ## Section 3.1.1
> 
> A short description of the 7 features would help the reader even if their names
> are somehow self-descriptive. In my own case, it took me 3 minutes to
> understand the use of server-auth-x509-cert by reading the actual YANG module
> description of the features.

I added the sentence:

	"Please refer to the YANG module for a description of each feature."

	…to all three modules, in both the ssh-client-server and the tls-client-server drafts.

This should help future readers to jump faster.


> ## Section A.1
> 
> I wonder why the module contains algorithms that were deprecated together with
> TLS 1.1

The Python code in Appendix A works off the underlying IANA registry.

There is a column called “Recommended” and, if set to ’N’, then the Python code sets “status deprecated;”  Any interpretation past that is outside the scope of the current Python script. 

I understand that you want more algorithms to be deprecated, but shouldn’t that happen in the underlying IANA registry first, and then the Python script can read it out?

What did you have in mind?



> # NITS (non-blocking / cosmetic)
> 
> ## Abstract
> 
> Please be consistent with the use of double quotes around IETF & IANA.

Removed double quotes around both IETF & IANA.

Same update applied to the ssh-client-server draft.


> Also, unsure whether stating the module names in the abstract is more useful or
> cumbersome ;-)

se-lä-vē  ;)


Thanks again!
Kent