[netconf] Re: http and RC client-server updates

[Kent Watsen <[e-mail]>]

Hi Med,

Thank you for your thorough review!


> On Jul 9, 2024, at 8:18 AM, [e-mail] wrote:
> 
> Hi Kent,
>  
> Please find some quick comments, fwiw. Most are very minor.
>  
> * Consistency
>  
>    This document presents ** two ** YANG 1.1 [RFC7950] modules: …
>  
> vs.
>  
> 1.1.  Relation to other RFCs
>  
>    This document presents ** one or more ** YANG modules [RFC7950]..

This comment applies to the “http-client-server” draft.

Yes, that would be better.  But it would be hard for me to fix since that text is in a file that is shared by the suite of client-server drafts.

The text isn’t wrong, and the Editor can fix...


> * Section 1.1 : now that the dependency on the udp grouping was added, I’m afraid that the dependency figure should be refreshed. Idem for Table 1.

I see what you mean, but I’m explicitly not trying to show every “import” statement.  E.g., the http-client-server also depends on tcp-client-server and the tls-client-server.   In all cases, the dependency is because of a “stack” grouping.  But these stack groupings are for minor convenience; the core of the data-model is elsewhere.   That said, I updated the text in that section to be more accurate as follows:

	OLD: The dependency relationship between the primary YANG groupings...
	NEW: Primary dependency relationships between the YANG groupings…



> * Section 2: nit
>  
> OLD:
>    Examples illustrating the module's use are provided in Examples
>    (Section 2.2). 
>  
> NEW:
>    Examples illustrating the module's use are provided in Section 2.2. 

Fixed (in two places)

 
> * Section 2.1.2.1: nits
>  
> OLD:
>    *  Unlike other "client" groupings in the suite a "client-server"
>       drafts mentioned in Section 1.1), 
>  
> NEW:
>    *  Unlike other "client" groupings in the suite a "client-server"
>       documents mentioned in Section 1.1, 

Fixed - thanks!


> * Section 2..1.2.1: Shouldn’t the client grouping include a parameter to control/explicit the http version? Also, wouldn’t be useful to define a quic-supported feature as well and the following be modified to list quic-supported feature?
>  
> CURRENT:
>        +-- tls-client-parameters {tls-supported}?
>           +---u tlsc:tls-client-grouping

Regarding param to control client-version, yes, and I recall Per making the same comment.

Regarding a quic-supported feature, I added a  “http-3-supported” feature and made it dependent on the “tls-supported” feature. 

See the -22 diff for details (will be published soon)



> * Section 2.3:
>  
> (1) remove the udp-client-server for the following list as this is imported/cited here.
>  
> CURRENT:
> 2.3.  YANG Module
>  
>    This YANG module has references to [RFC3986], [RFC6991], [RFC8341],
>    [RFC9110], [I-D.ietf-netconf-tls-client-server], and
>    [I-D.ietf-netconf-udp-client-server].

I’d already spotted this  - thanks

 
> 
> (2) DELETE as this isn’t used in the module
>  
>         The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
>         'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
>         'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
>         are to be interpreted as described in BCP 14 (RFC 2119)
>         (RFC 8174) when, and only when, they appear in all
>         capitals, as shown here.";

Does no harm either, right?    I’m too lazy to chase if any of those words appear
in my modules.  I know that sometimes they do.   Whether that makes sense is
a different question.


> (3) redundant referencing (similar other occurrences)
>  
> OLD:
>        description
>          "Indicates that the server supports configuring HTTP
>           clients to connect to a remote HTTP server via a
>           proxy, per Section 9.3.6 of RFC 9110.";
>        reference
>          "RFC 9110: HTTP Semantics";
>  
> NEW:
>        description
>          "Indicates that the server supports configuring HTTP
>           clients to connect to a remote HTTP server via a
>           proxy.";
>        reference
>          "RFC 9110: HTTP Semantics, Section 9.3.6 ";

I have always referenced sections in the “description” statement, never the “reference” statement.



> * Section 3.1.1: Update to echo all the features in the module, e.g., quic-supported is missing in the list.
>  
> CURRENT:
> 3.1.1.  Features
>  
>    The following diagram lists all the "feature" statements defined in
>    the "ietf-http-server" module:

Fixed.   Also fixed in the "ietf-http-client” section...



> * Section 3.1.2.2:  Update the structure/module to avoid versions older than TLS1.3
>  
> CURRENT:
>           +--:(quic) {quic-supported}?
>              +-- quic
>                 +-- udp-server-parameters
>                 |  +---u udps:udp-server-grouping
>                 +-- tls-server-parameters
>                 |  +---u tlss:tls-server-grouping
>                 +-- http-server-parameters
>                    +---u http-server-grouping

I don’t think a config knob is needed for this.   
A Quic server will already not use a version of TLS older than 1.3.


> * Update the following to cite quic case. Also, avoid the use of normative language (MAY)/
>  
> CURRENT:
>  
>            "Choice amongst various transports type.  TCP, with and
>             without TLS are defined here, with 'feature' statements
>             so that they may be disabled.  Other transports MAY be
>             augmented in as 'case' statements by future efforts.";

Fixed.


>  
> * The description is from the perspective of the client, while this is about the server behavior. Please update accordingly.
>  
> CURRENT:
>                      "The HTTP client will attempt to connect
>                       to the IANA-assigned well-known port for
>                       'http' (80) if no value is specified.";

Fixed.
 

> * Idem as previous comment
>  
> CURREN:
>                      "The HTTP client will attempt to connect
>                       to the IANA-assigned well-known port for
>                       'https' (443) if no value is specified.";

Also fixed.

 
> Cheers,
> Med

Thanks!
Kent



>  
> De : Kent Watsen <[e-mail] <mailto:[e-mail]>> 
> Envoyé : mardi 9 juillet 2024 03:39
> À : [e-mail] <mailto:[e-mail]>
> Objet : [netconf] http and RC client-server updates
>  
> 
> I posted updates for the following drafts:
>  
>              - http-client-server
>              - restconf-client-server
>  
> The updates are as follows:
>  
> For the http-client-server draft, the update is rather big.  After discussing with HTTP chairs and other experts, it was noted that our configuration for the HTTP-client was not expected.   What was stated was that the URI itself should be sufficient.  The update only affects the “client” groupings.  Now the client groupings have a “uri” leaf that is expected to encode transport details.
>  
> For the restconf-client-server draft, the update is only to adjust the examples to reflect the changes in the http-client-server draft.
>  
> Best,
> K
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.