Re: [netconf] Martin Duke's No Objection on draft-ietf-netconf-tcp-client-server-22: (with COMMENT)

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

Hi Martin, all, (+TCPM as this is mostly about TCP)

see below.

> -----Original Message-----
> From: Martin Duke via Datatracker <[e-mail]>
> Sent: Monday, February 26, 2024 9:28 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Martin Duke's No Objection on draft-ietf-netconf-tcp-client-server-22:
> (with COMMENT)
> 
> Martin Duke has entered the following ballot position for
> draft-ietf-netconf-tcp-client-server-22: No Objection
> 
> 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/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> EDIT: with another comment spurred by a different doc.
> 
> Thanks to Michael Tuexen for the TSVART review.
> 
> I support Eric's DISCUSS about support for HTTP CONNECT proxies, though I
> think
> MASQUE itself is not relevant here.
> 
> It's also important to indicate, probably in (2.1.5), that Keepalive MUST
> (SHOULD?) NOT be activated if there is application-level keepalive, as there is
> in SSH.

As far as I recall, normative guidance in this space has been discussed already several times on several WG lists, and there seems to be consensus that application-level keepalives are the better alternative.

But out of my head, I don't know any RFC that defines such a MUST (or SHOULD).

Do we have a standards track document with such a MUST (or SHOULD) that we could reference in section 2.1.5?

Section 2.1.5 is just meant as a summary of the existing standards defining the use of TCP keep-alives. It may not be the best place to introduce new normative guidance.

> Nit:
> (2.1.5) s/not universally accepted/not universally deployed? adopted?
> activated?
> 
> Accepted seems like an imprecise word here.

This sentence and in particular the word "accepted" was just copied from RFC 9293. I agree that we could change it to "deployed" or "adopted". But this would raise the question why we have used the term "accepted" in RFC 9293. (Well, I don't know...)

Michael