[netconf] Roman Danyliw's Discuss on draft-ietf-netconf-http-client-server-17: (with DISCUSS and COMMENT)

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

Roman Danyliw has entered the following ballot position for
draft-ietf-netconf-http-client-server-17: 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-http-client-server/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(Let me know if I am misunderstanding how this YANG module would be deployed. 
I was envisioning this being a stand-alone configuration.)

Constraining credential use:
** Section 2.3.  Per “grouping http-client-identity-grouping” how does one
constrain the use of the username/password to a particular webserver?

** Section 2.3.  Per “tls-client-parameters” and support for a client
certificate.

-- Editorial.  I was expected statement in the text to explain to me that this
is a client certificate for mutually authenticated TLS (mTLS) -- If a client
certificate is configured, does that imply the implementation will always use
this certificate if mTLS is requested by the server?  How does one constrain
the places/servers a certificate would be used?

-- If configured with multiple client certificates, how does which is the
appropriate certificate to use?


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

** Section 3.3.  Is it possible to configure a
client-auth-supported/basic-auth-support without tls-supported?  If so, can
there be caution added about such arrangements

** Section 4.1 and 4.2.  Certain nodes are called out a vulnerable with
write-access.  Can the rationale and impact of misuse please be explained.

** Section 4.1 and 4.2 use a very concerning editorial construct that could be
easily misinterpreted.  Paragraph one reads “Please be aware that this YANG
module uses groupings from other YANG modules that define nodes that may be
considered sensitive or vulnerable in network environments.  Please review the
Security Considerations for dependent YANG modules for information as to which
nodes may be considered sensitive or vulnerable in network environments.”  This
text followed by another paragraph which then says “None of the readable data
nodes defined in this YANG module are considered sensitive or vulnerable in
network environments.”

The first paragraph is unambiguous (i.e., check the references and their
Security Considerations apply).  The second paragraph’s accuracy depends on an
interpretation that “defined in this YANG module” excludes imported modules.  I
believe that clearer language is needed here.