Re: [netconf] Paul Wouters' Discuss on draft-ietf-netconf-tls-client-server-39: (with DISCUSS)

[Kent Watsen <[e-mail]>]

Hi Paul,

Thank you for your comments.
Please find responses below.

Kent // author



> On Feb 28, 2024, at 3:46 PM, Paul Wouters via Datatracker <[e-mail]> wrote:
> 
> Paul Wouters has entered the following ballot position for
> draft-ietf-netconf-tls-client-server-39: Discuss
> 
> 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/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Two minor DISCUSS points that are likely easy to resolve.
> 
> 1) 2.2 examples
> 
> This example uses tls11 and tls12. It would be better to use tls12 and tls13
> as examples as tls11 is on its way to being deprecated. also "identity tls11"
> is not defined in the document but they are for 1.2 and 1.3.

Example updated.


> It claims in "identity tls12" that it's status is "deprecated"
> 
> I don't see that (yet) in https://datatracker.ietf.org/doc/bcp195/
> or at https://datatracker.ietf.org/wg/tls/documents/
> 
> 1.2 is obsoleted by 1.3, but is not yet deprecated. I'm also not sure
> why the "status" field needs to be there at all? What is the purpose of
> this field? I read the description and it related to MUST NOT actions, but
> I'm unsure what the difference is between not having the the entry (eg the
> entire "identity tls12") or having the entry with the included "status"
> field ? (again, sorry I am not a Yang Doctor)

My misunderstanding.  I have removed the two “status deprecated” statements.

FWIW, the semantics for the “deprecated” statement is that the configuration is allowed, but the validator should throw a warning.



> 2) !-- USE ONLY ONE AT A TIME
> 
> I am confused about this directive. Is it to the RFC Editor for generating
> the yang? For the implementer to only allow one? For the user to only define
> one?

My bad - that was cruft from my testing harness.  In order to avoid confusion, I have removed all of the commented-out configuration.


> What it you want to migrate from one method to another in a cloud of machines,
> and you cannot update them all at once? Wouldn't having more than one give
> you a proper migration path?

I don’t understand this comment.  
Can you give an example?


Thanks again!
Kent