Thanks to Valery Smyslov for their secdir review.

Thanks to the author (and working group) for a specification that is easy to read.  I have a couple of comments, the last two I consider important, enough that I thought about making them discusses.  I'm sure they will be carefully considered even as no obj comments.

Section 4.1, para 1:  I would remove the parentheses from the last sentence.  It certainly is normative, and it impacts interoperability (hence the BCP 14 language). The only hesitation I have making this comment is the lead sentence which leads the reader to believe that the paragraph is only about HTTP/2 and HTTP/3.  Perhaps also consider a new topic sentence, or make the HTTP/1.1 sentence its own paragraph.

Section 6:  It is important to call out the security considerations associated with both sending TCP stream content optimistically, and the support for TLS early data.  I'm not sure if it is all covered in RFC 8470 section 6, certainly the early data portion is.

Section 6:  As RFC 9110 states in section 17.16, "everything about the topic of HTTP authentication is a security consideration", it bears repeating (or referencing) here too (especially since section 3.3.2 is all about authentication).

Thanks to the authors and the WG for their work on this document.

Please find below some comments and suggestions that I would like to offer for
your consideration. They come from someone that is not very familiar with this
area, so please correct me if I am wrong. 

The review is inline in the idnits output of v15 of this document. The end
of the review is marked by the tag <EoRv15>

208	   This protocol can be extended by defining additional relevant Capsule
209	   Types.  According to the Capsule Protocol ([CAPSULE], Section 3.2),
210	   new Capsule Types should be ignored by pre-existing proxies and
211	   intermediaries.  If a new Capsule Type cannot safely be ignored, the
212	   endpoints can confirm support using a new HTTP header field.

<minor> RFC 9297 Section 3.2 has endpoints drop unknown Capsule Types, while
intermediaries forward them unmodified. If I am correct, then perhaps:

CURRENT
   new Capsule Types should be ignored by pre-existing proxies and
   intermediaries.
SUGGEST
   new Capsule Types are silently dropped by pre-existing proxies and
   forwarded unmodified by intermediaries.


224	   *  The request SHALL include a single "Host" header field containing
225	      the origin of the proxy.

<minor> Doesn't the Host header field carries the authority (host and port) rather
than the origin, which also includes the scheme?


504	   TCP content in early data (in HTTP/2 and HTTP/3).  At the TLS layer,
505	   proxies MAY ignore, reject, or accept the early_data extension
506	   ([TLS], Section 4.2.10).  At the HTTP layer, proxies MAY process the

<nit> Early data is Section 4.3.10 in RFC 9846 (4.2.10 was its RFC 8446
number).

750	   Templated TCP proxies can make use of standard HTTP gateways and
751	   path-routing to ease implementation and allow use of shared
752	   infrastructure.  However, current gateways might need modifications
753	   to support TCP proxy services.  To be compatible, a gateway must:

<major> Sections 7.2 and 7.3 carry requirements on implementations rather than
operational advice: what a gateway "must" do. Requirements on intermediaries are 
already specified in Section 3. If these are meant to be normative, please consider 
moving the gateway list into a new subsection of Section 3 with BCP 14 key words, 
and the timeout MUST into Section 3.4, leaving deployment advice in Section 7.

787	   Endpoints MAY impose additional timeouts, especially as a defense
788	   against certain resource exhaustion attacks (Section 6.1).  However,
789	   operators should apply timeouts cautiously to minimize the impact on
790	   connections that are functioning but slow.  Any timeout imposed by
791	   the endpoint MUST be treated as an abrupt closure of the affected
792	   stream or connection (Section 3.4).

<major> The MUST on treating a timeout as an abrupt closure is a requirement
on endpoint behaviour rather than operational advice, and it would sit
naturally with the closure handling in Section 3.4. This is on the same lines
as my previous comment.

798	   IF APPROVED, IANA is requested to add the following entry to the HTTP
799	   Upgrade Token Registry:

<minor> RFC 9110 Section 16.7 asks that a registration name the expected
protocol-version tokens, and the registry has a column for them; RFC 9298
registered "connect-udp" with "None". Perhaps also use the registry's name:

CURRENT
   IF APPROVED, IANA is requested to add the following entry to the HTTP
   Upgrade Token Registry:
SUGGEST
   IF APPROVED, IANA is requested to add the following entry to the
   "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry":

   Value:  connect-tcp
   Description:  Proxying of TCP payloads
   Expected Version Tokens:  None
   Reference:  This document

831	   IF APPROVED, IANA is requested to add the following entry to the
832	   "HTTP Capsule Types" registry:

<minor> IANA has already provisionally registered 0x08 (DATA) and 0x09
(FINAL_DATA) with a reference to -12. Perhaps:

CURRENT
   IF APPROVED, IANA is requested to add the following entry to the
   "HTTP Capsule Types" registry:
SUGGEST
   IANA has provisionally registered the following entries in the "HTTP
   Capsule Types" registry.  IF APPROVED, IANA is requested to make these
   registrations permanent and to update their reference to this
   document:

<minor> Please review and fix the following related to references:
RFC 9293: should be normative? The requirements in Section 3.4 are stated in 
terms of TCP FIN, RST and the TIME-WAIT and CLOSED states.

<EoRv15>

Hi Ben, 

The changes in [1] address all the comments raised in my previous ballot [2]. 

Thank you.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-httpbis-connect-tcp-15&url2=draft-ietf-httpbis-connect-tcp-16&difftype=--html

[2] https://lists.w3.org/Archives/Public/ietf-http-wg/2026OctDec/0057.html