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

[Kent Watsen <[e-mail]>]

Hi Rob,

Thank you for your review!
I just replied to Med’s review too…


> On Aug 9, 2024, at 11:01 AM, Rob Wilton (rwilton) <rwilton=[e-mail]> wrote:
> 
> Hi Kent,
>  
> Just commenting on the http-client-server draft (--21), I think that these changes make sense (based on the discussion that we had with Mark & Lars in Brisbane at IETF 119).

Yes, it seems to be in pretty good shape now, especially with your’s and Med’s reviews!


> A few comments for you to consider
>  
> 1)
> In Section 2.2, you use an example which includes tls-client-parameters and server-authentication.  I think that it might also be helpful to also include the trivial example of just using a URI, since that may well be the most common use case?

I added a simple example w/o TLS.


> 2)
> Section 2.3:
>  
>      feature tls-supported {
>        description
>          "Indicates that the server supports configuring
>           HTTP client certificates.";
>        reference
>          "RFC 9110: HTTP Semantics";
>      }
>  
> Is “tls-supported” the right name for this feature?  Will clients that support HTTPS (and hence TLS) always be expected to support these additional parameters?  Please consider whether tweaking the grouping name would make sense.

I think the name is good, but only in the soon-to-be-posted -22, where a new “http-3-supported” feature depends on the “tls-supported” feature.


> 3) Section 2.3:
>        leaf uri {
>          nacm:default-deny-all;
>          type inet:uri;
>          mandatory true;
>  
> I was surprised by the default-deny-all on the URI, since I don’t generally think of these as being particularly security sensitive beyond any other configuration.  Was this intentional? 

Yes, but I’m willing to be convinced otherwise.  My reasoning is because the URI may encode a cleartext password (basic or digest auth)... 


> And if this does remain, then you may need to update the security considerations in section 4.1 which talks about other nodes, but not this one. 

Security Considerations section updated!


> In fact, looking at the security considerations text, perhaps you wanted the nacm:default-deny-all to be on the proxy-uri instead?

It should be on both nodes, as seen in -22


> Regards,
> Rob

Thanks!
Kent