Original text:
The Extended CONNECT protocol defined for this mechanism is "connect- ip", which is also referred to as CONNECT-IP in this document. <del> The CONNECT-IP protocol allows endpoints to set up a path for </del>  proxying IP packets using an HTTP proxy.  This can be used for various solutions that include general-purpose packet tunnelling, such as for a point-to-point or point-to-network VPN, or for limited IP packets in HTTP Datagrams (packet-handling). Any 2xx (Successful) response indicates that the proxy is willing to <del> open an IP forwarding path between it and the client.  Any response </del>  other than a successful response indicates that the tunnel has not been formed. request.  A client MUST treat a successful response containing any Content-Length or Transfer-Encoding header fields as malformed. <del> The lifetime of the forwarding path is tied to the CONNECT stream. </del>  Closing the stream (in HTTP/3 via the FIN bit on a QUIC STREAM frame, <del> or a QUIC RESET_STREAM frame) closes the associated forwarding path. </del>  Along with a successful response, the proxy can send capsules to assign addresses and routes to the client (capsules).  The client can In the other direction, when a CONNECT-IP endpoint receives an IP packet, it checks to see if the packet matches the routes mapped for <del> a CONNECT-IP forwarding path, and performs the same forwarding checks as above before transmitting the packet over HTTP Datagrams. </del>  Note that CONNECT-IP endpoints will decrement the IP Hop Count (or TTL) upon encapsulation but not decapsulation.  In other words, the server through the proxy. The following example shows an IP flow forwarding setup, where a <del> client requests to establish a forwarding path to target.example.com using ICMP (IP protocol 1), and receives a single local address and remote address it can use for transmitting packets. </del>  The following example shows a proxied UDP listen flow, where a client receives can receive UDP packets via the proxy, and can send to any

Reviewer comments:
The draft currently mentions an "IP forwarding path" (or elsewhere a "path for proxying IP packets") without defining what that term means. It's ambiguous because "path" is a . I'd propose we replace this use of the word "path" with the word "tunnel" which is .
Yes, "IP forwarding tunnel" sounds fine to me.
Yes tunnel is good. Or maybe association in the context of handling state st the proxy.

Revised text:
The Extended CONNECT protocol defined for this mechanism is "connect- ip", which is also referred to as CONNECT-IP in this document.  <ins> The CONNECT-IP protocol allows endpoints to set up a tunnel for </ins> proxying IP packets using an HTTP proxy.  This can be used for various solutions that include general-purpose packet tunnelling, such as for a point-to-point or point-to-network VPN, or for limited IP packets in HTTP Datagrams (packet-handling). Any 2xx (Successful) response indicates that the proxy is willing to  <ins> open an IP forwarding tunnel between it and the client.  Any response </ins> other than a successful response indicates that the tunnel has not been formed. request.  A client MUST treat a successful response containing any Content-Length or Transfer-Encoding header fields as malformed.  <ins> The lifetime of the forwarding tunnel is tied to the CONNECT stream. </ins> Closing the stream (in HTTP/3 via the FIN bit on a QUIC STREAM frame,  <ins> or a QUIC RESET_STREAM frame) closes the associated forwarding tunnel. </ins> Along with a successful response, the proxy can send capsules to assign addresses and routes to the client (capsules).  The client can In the other direction, when a CONNECT-IP endpoint receives an IP packet, it checks to see if the packet matches the routes mapped for  <ins> a CONNECT-IP forwarding tunnel, and performs the same forwarding checks as above before transmitting the packet over HTTP Datagrams. </ins> Note that CONNECT-IP endpoints will decrement the IP Hop Count (or TTL) upon encapsulation but not decapsulation.  In other words, the server through the proxy. The following example shows an IP flow forwarding setup, where a  <ins> client requests to establish a forwarding tunnel to target.example.com using ICMP (IP protocol 1), and receives a single local address and remote address it can use for transmitting packets. </ins> The following example shows a proxied UDP listen flow, where a client receives can receive UDP packets via the proxy, and can send to any