Re: [netconf] Éric Vyncke's Discuss on draft-ietf-netconf-tcp-client-server-21: (with DISCUSS and COMMENT)

[Kent Watsen <[e-mail]>]

Hi Éric,

Thank you for your comments.
Please see below for responses.

Kent


> On Feb 20, 2024, at 7:55 AM, Éric Vyncke via Datatracker <[e-mail]> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-netconf-tcp-client-server-21: 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-tcp-client-server/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> # Éric Vyncke, INT AD, comments for draft-ietf-netconf-tcp-client-server-21
> 
> Thank you for the work put into this document.
> 
> Please find below one blocking DISCUSS points (easy to address as it is only to
> force a reply), some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education).
> 
> Special thanks to Per Andersson for the shepherd's detailed write-up including
> the WG consensus (and the discussion with TCPM) and the justification of the
> intended status.
> 
> I hope that this review helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> # DISCUSS (blocking)
> 
> As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
> DISCUSS ballot is a request to have a discussion on the following topics:
> 
> ## No MASQUE or HTTP-proxy defined ?
> 
> This is mainly to force a discussion over email. SOCKS were (and probably are
> still) a common proxy mechanism, but should SSH tunnels, MASQUE connect (and
> its old parent HTTP connect method) be part of this document?

This discuss seems to be about the "http-client-server” draft more so than the “tcp-client-server” draft.

For instance, this section[1] in the http-client-server draft defines a node called "proxy-connect” that enables the HTTP-client to be configured to connect via either an HTTP- or HTTPS- based proxy.  Though the “http-client-server" document doesn’t say it (which I just fixed), the “proxy-connect” node intends to support HTTP connect [2].

[1] https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server-17#section-2.1.2.2
[2] https://datatracker.ietf.org/doc/html/rfc9110#section-9.3.6

I never heard before about MASQUE, which I see now is defined in both RFC 9298 (Proxying UDP in HTTP) and RFC 9484 (Proxying IP in HTTP).   Those RFCs being so new, the question is if MASQUE should be 1) added to the http-client-server draft now, 2) acknowledged as not being in the http-client-server draft, or 3) say nothing about MASQUE, only stating that HTTP-connect is supported and other proxy-types can be added by future work?

PS: there is a related DISCUSS going on for the http-client-server draft, regarding its current lack of support for QUIC.  The same 1/2/3-options in the previous paragraph are in play.   I had a conversion with the NETCONF-chairs (Mahesh and Per) today and we think that a small update to the http-client-server draft might be possible to support QUIC, assuming the configuration for QUIC and DTLS are the same (i.e., TLS + UDP).   [Is there a QUIC expert in the house I can ask?]



> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> # COMMENTS (non-blocking)
> 
> ## Section 2.1
> 
> While the text about keep-alives use cases sounds correct, I wonder whether
> this text is relevant in an I-D about *data models*, i.e., why discussing the
> semantics and use cases of TCP keep-alives?

Section 2.1.5 (Guidelines for Configuring TCP Keep-Alives) was written by my co-author, Michael Sharf (CC-ed), who is also a chair of the TCPM WG.  I had assumed that it was important...

Michael, can you respond to this comment?


> Some issue with the use of normative language for the default values of TCP
> keep-alives, those values SHOULD be in NETCONF/RESTCONF protocols and not
> discussed in this data model. To be honest, I hesitated to raise a discuss
> level on this.

I’m assuming this comment regards Section 2.1.5 (Guidelines for Configuring TCP Keep-Alives).
I agree that text about motivation doesn’t need to be in a document regarding data-models...

Michael, can you respond to this comment also?



> ## Section 3.1.2.1
> 
> The reader would probably welcome an explanation of the differences between
> 'socks4' and 'socks4a', is it only to allow for a hostname ?
> 
> Should it be possible to configure multiple remote-addresses for the proxy ?

This took some effort.   

As you’ll see when I publish an update to the suite of drafts (maybe later today),
I made the following changes:

1) added three new “feature” statements:
	- socks4-supported
	- socks4a-supported
	- socks5-supported

2) greatly expanded Section 3.1.1 (Features) to describe each feature, with the 
description for the “socks4a-supported” feature including the statement:

	"The difference between Socks4 and Socks4a is that Socks4a enables
	the "remote-address" to be specified using a hostname, in addition to 
	an IP address.

3) expanded Section 3.1.2.1, under the "proxy-server” description section, to
refer to the new “feature” statements and, in particular, the aforementioned
Section 3.1.1.

I’m hoping you will be happy with this update.



> ## Section 3.3
> 
> About the tcp-client-grouping remote-address `the IP addresses are tried
> according to local preference order`, should there be a reference to RFC 6724
> (as there can be multiple source addresses) ?

I’m looking at https://datatracker.ietf.org/doc/html/rfc6724#section-6
…and feeling unsure about applicability to this section.

My hesitation regards how this same "tcp-client-grouping” specifies
the "local-address” (which I equate to “source address” as a single
value (type inet:ip-address), either specified or picked by the OS,
but it is still just one value.

Does RFC 6724 still apply?   Please advise.



> Also in tcp-client-grouping local-address, AFAIK `INADDR6_ANY
> ('0:0:0:0:0:0:0:0' a.k.a. '::')` also means supporting IPv4-mapped addresses
> per RFC 4291. SO, the text `the server can bind to any IPv4 or IPv6 addresses,
> respectively ` should be amended.

Looking at:
	https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.2
	https://datatracker.ietf.org/doc/html/rfc4291#section-2.2
	https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5

I see what you mean.  I made this change:

	OLD: any IPv4 or IPv6 addresses, respectively.
	NEW: any IPv4 or IPv6 address.



> ## Section 4.3
> 
> Also in tcp-server-grouping local-address, AFAIK `INADDR6_ANY
> ('0:0:0:0:0:0:0:0' a.k.a. '::')` also means supporting IPv4-mapped addresses
> per RFC 4291. SO, the text `the server can bind to any IPv4 or IPv6 addresses,
> respectively ` should be amended.

I made the same change as described in my previous response.


Thanks again!
Kent