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

["Eric Vyncke (evyncke)" <[e-mail]>]

Kent,

This document was discussed during the Feb 29th IESG telechat and the conclusion is that if the document is updated by adding text about “there are other TCP proxy techniques that are not part of this document, but could be added by augmenting the YANG module”, then I am clearing my current DISCUSS.

Regards

-éric

PS: beware of the cut-off date for I-D submission (next Monday)

From: Kent Watsen <[e-mail]>
Date: Wednesday, 21 February 2024 at 23:27
To: Eric Vyncke <[e-mail]>
Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "Per Andersson (perander)" <[e-mail]>, Mahesh Jethanandani <[e-mail]>, "Scharf, Michael" <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-netconf-tcp-client-server-21: (with DISCUSS and COMMENT)

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