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

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

Michael

Thanks for your detailed response on one of my ballot COMMENT (i.e., not blocking).

I appreciate the complexity of TCP ‘internals’ and I am even sympathetic to the configuration of those internals via YANG (perhaps not in a Netconf wg document tough but this is the broad IETF family of WGs anyway). But, what I do not understand is why a *data model* uses normative language (including values such as 15 seconds) for a *transport protocol* configuration. The section 2.1.5 is even labelled as “guidelines”, i.e., not normative. Removing the normative language (uppercase SHOULD / MAY / ...) would be better IMHO.

Again, this is a non-blocking suggestion (and I have hesitated a lot whether to DISCUSS this point).

Regards

-éric

From: "Scharf, Michael" <[e-mail]>
Date: Monday, 26 February 2024 at 14:23
To: Kent Watsen <[e-mail]>, 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]>, "[e-mail] Extensions" <[e-mail]>
Subject: RE: Éric Vyncke's Discuss on draft-ietf-netconf-tcp-client-server-21: (with DISCUSS and COMMENT)

Hi all (+TCPM),

Regarding the comments below related to Section 2.1.5:

1/ Regarding “why discussing the semantics and use cases of TCP keep-alives”:

The TCPM working group has reviewed this document and there was quite some controversial discussion in TCPM regarding configuration of “TCP keep-alives”, since it is a non-trivial mechanism. Not everybody may understand how to use it properly. If TCP keep-alives are used by an application, it is important to pick the parameters appropriately. The TCP standards include corresponding normative guidance on how to select the parameters, but it is not clear if a reader of draft-ietf-netconf-tcp-client-server would indeed be familiar with these TCP details and the tradeoffs. So, the TCPM consensus was to summarize the normative guidance from RFC 9293 in draft-ietf-netconf-tcp-client-server and to add corresponding references to RFC 9293. This is also meant as a warning sign, in order to ensure that whoever configures that YANG data model really understands the implications.

2/ Regarding “those values SHOULD be in NETCONF/RESTCONF protocols”:

TCP keep-alives are an optional, generic TCP mechanism that can theoretically be used by any application protocol. The core TCP standard in RFC 9293 applies to NETCONF, RESTCONF, and any other Internet application protocol that wants to use TCP keep-alives. It probably doesn’t make sense to discuss in all standards for IETF application protocols how to properly use TCP… At least, that approach would not scale well ;-) So, the NETCONF/RESTCONF standards may not be a good place.

What is special in draft-ietf-netconf-tcp-client-server is that the YANG data model offers access to parameters that are implemented inside the TCP stack. The YANG data model for TCP keep-alives could therefore also be used for other TCP-based application protocols; NETCONF/RESTCONF are just the – apparently – most relevant use case that needs a YANG data model for this. So, it seems to make more sense to have an explanation on how to properly configure the TCP parameters inside the YANG data model that exposes those parameters to a user or administrator.


Removing Section 2.1.5 would IMHO require a new discussion inside TCPM on how to deal with TCP keep-alive configuration.

I hope that this helps

Michael


From: Kent Watsen <[e-mail]>
Sent: Wednesday, February 21, 2024 11:27 PM
To: Éric Vyncke <[e-mail]>
Cc: The IESG <[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]<mailto:[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