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

["Scharf, Michael" <[e-mail]>]

Hi Eric,

 

for a subset of the normative language in Section 2.1.5, the normative language and the exact value of parameters directly follow from RFC 9293. If the references to RFC 9293 are not enough to make this clear, we could add an explicit sentence. If section 2.1.5 just copies a sentence from RFC 9293, I fail to see why we should remove the normative language mandated by RFC 9293. Of course, we could paraphrase all requirements copied from RFC 9293 to avoid normative language, but why can we not just state what RFC 9293 asks for?

 

Now, the challenge is that RFC 9293 does not exactly specify how to configure TCP keep-alives, but the data model in this I-D includes three parameters that need to be picked very carefully. So, the document needs to talk about the exact parameters in the data model. What we could do is to remove the normative language for those statements that are not copied directly from RFC 9293; the 15 seconds would be one such example. This mostly affects some SHOULD and MAY, i.e., implementers can deviate from these statements anyway. I don’t think that these SHOULD and MAY are problematic, but I won’t strongly push back against rewording this to non-normative language if others believe that SHOULD/MAY doesn’t make sense here.

 

There is one normative MUST statement (“the time interval between probes MUST NOT be smaller than one second”) that is tricky, though. This one second value is backed by various RFCs dealing with congestion control (e.g., RFC 8961). I *do* believe that the specification of this data model needs to explain that IETF standards mandate this lower bound. Of course, we could paraphrase also this explanation without a MUST NOT, but isn’t this exactly the purpose of normative language?

 

BTW, one of the challenges with TCP keep-alives is that it is an optional, non-trivial TCP feature that is not even available on all TCP stacks. In an ideal world, we would have an RFC that exactly defines how to configure TCP keep-alives independently of a YANG data model and an actual TCP implementation. Then section 2.1.5 would maybe not be needed at all. But we don’t have such an RFC and probably won’t have it in the foreseeable future. So section 2.1.5 is a compromise between meeting the requirements of the NETCONF WG and reflecting the concerns in TCPM.

 

Anyway, for this discussion it could help a lot if others (most notably in TCPM) could speak up whether normative language should be used in section 2.1.5, or not.

 

Michael

 

 

 

 

 

From: Eric Vyncke (evyncke) <[e-mail]> 
Sent: Wednesday, February 28, 2024 11:02 AM
To: Scharf, Michael <[e-mail]>; Kent Watsen <[e-mail]>
Cc: The IESG <[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)

 

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] <mailto:[e-mail]> >
Date: Monday, 26 February 2024 at 14:23
To: Kent Watsen <[e-mail] <mailto:[e-mail]> >, Eric Vyncke <[e-mail] <mailto:[e-mail]> >
Cc: The IESG <[e-mail] <mailto:[e-mail]> >, "[e-mail] <mailto:[e-mail]> " <[e-mail] <mailto:[e-mail]> >, "[e-mail] <mailto:[e-mail]> " <[e-mail] <mailto:[e-mail]> >, "[e-mail] <mailto:[e-mail]> " <[e-mail] <mailto:[e-mail]> >, "Per Andersson (perander)" <[e-mail] <mailto:[e-mail]> >, Mahesh Jethanandani <[e-mail] <mailto:[e-mail]> >, "[e-mail] Extensions <mailto:[e-mail]%20Extensions> " <[e-mail] <mailto:[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] <mailto:[e-mail]> > 
Sent: Wednesday, February 21, 2024 11:27 PM
To: Éric Vyncke <[e-mail] <mailto:[e-mail]> >
Cc: The IESG <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; Per Andersson (perander) <[e-mail] <mailto:[e-mail]> >; Mahesh Jethanandani <[e-mail] <mailto:[e-mail]> >; Scharf, Michael <[e-mail] <mailto:[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