Original text:
Connection to be congestion controlled or not.  Note that if a Connection is not congestion controlled, an application using such a Connection SHOULD itself perform congestion control in accordance <del> with RFC2914, RFC2119.  Also note that reliability is usually combined with congestion control in protocol implementations, </del>  rendering "reliable but not congestion controlled" a request that is <del> unlikely to succeed. </del>  5.2.10. reused, e.g., to create another Listener. Listening continues until the global context shuts down, or until the <del> Stop action is performed on the Listener object: After calling Stop(), the Listener object can be disposed of. </del>  The ConnectionReceived Event occurs when a Remote Endpoint has established a transport-layer connection to this Listener (for 7.1.8. <del> maxSendRate / maxRecvRate </del>  Numeric (with special value "Unlimited") / Numeric (with special <del> value "Unlimited") </del>  <del> Unlimited / Unlimited </del>  This property specifies an upper-bound rate that a transfer is not expected to exceed (even if flow control and congestion control allow higher rates), and/or a lower-bound rate below which the application <del> does not deem a will be useful.  These are specified in bits per </del>  second.  The special value "Unlimited" indicates that no bound is specified. All of the below properties are optional (e.g., it is possible to specify "User Timeout Enabled" as true, but not specify an Advertised User Timeout value; in this case, the TCP default will be used).  7.2.1.

Reviewer comments:
, . Partially addresses .
sec 7.2 perhaps I'm not thinking of this correctly, but should there be a way to query the peer-offered user timeout?
This looks protocol-specific (it's not a generic transport function). QUIC could let you query it in a protocol-specific property. Proposing moving to the QUIC mapping doc.
I agree with addressing this in the QUIC mapping doc, but for clarification: this is protocol-specific already (it's about a protocol-specific TCP property), and I added a clarification that the API calls reflect the API specified in Section 3 of RFC 5482 (which doesn't include this functionality). => I agree that allowing to query the peer's UTO might be useful, but it's probably not worth adding more text for this, as I also suspect that nobody will implement this for TCP anyway (even the underlying logic from RFC 5482 isn't widely available either AFAIK). If someone does, they are still free to allow querying whatever they like ... but IMO, we shouldn't make this document longer with more protocol-specific elements than we absolutely need to include.
Can we close the Peer user timeout with no-action?
I temporarily gave this a "discuss" label to see if it provokes people to have a 1-minute chat about closing this. This didn't happen, so now I just closed it.
sec 7.1.8 This section is missing a reference to minSendRate and minRecvRate
sec 6.2 "After Stop() is called, the Listener can be disposed of." I don't understand the difference between calling URL() and simply disposing of the object. Does this imply that there is a URL() that allows a configured listener to resume?
We should just not talk about "disposing" here. Just remove the sentence.
Object disposal implies a language with synchronous destruction, something we can't assume. For something garbage collected, you'd need an explicit close method because you don't know when the object will be destroyed.
sec 5.2.9 It would be helpful to say "Applications that neither prohibit nor require congestion should query the result and disable their own congestion control if present in the transport"
Interesting, but we need to be careful in what we say. It seems safe, but not performant to do CC at multiple layers, and if it's done at a lower layer performance might be improved by not replicating the function at a higher layer...
Link to UDP guidelines document. Just mention that there are performance implications of multiple CC loops; don't just say "disable CC".

Revised text:
Connection to be congestion controlled or not.  Note that if a Connection is not congestion controlled, an application using such a Connection SHOULD itself perform congestion control in accordance  <ins> with RFC8085, RFC2914, RFC2119.  Also note that reliability is usually combined with congestion control in protocol implementations, </ins> rendering "reliable but not congestion controlled" a request that is  <ins> unlikely to succeed.  If the Connection is congestion controlled, performing additional congestion control in the application can have negative performance implications. </ins> 5.2.10. reused, e.g., to create another Listener. Listening continues until the global context shuts down, or until the  <ins> Stop action is performed on the Listener object. </ins> The ConnectionReceived Event occurs when a Remote Endpoint has established a transport-layer connection to this Listener (for 7.1.8.  <ins> minSendRate / minRecvRate / maxSendRate / maxRecvRate </ins> Numeric (with special value "Unlimited") / Numeric (with special  <ins> value "Unlimited") / Numeric (with special value "Unlimited") / Numeric (with special value "Unlimited") </ins>  <ins> Unlimited / Unlimited / Unlimited / Unlimited </ins> This property specifies an upper-bound rate that a transfer is not expected to exceed (even if flow control and congestion control allow higher rates), and/or a lower-bound rate below which the application  <ins> does not deem it will be useful.  These are specified in bits per </ins> second.  The special value "Unlimited" indicates that no bound is specified. All of the below properties are optional (e.g., it is possible to specify "User Timeout Enabled" as true, but not specify an Advertised User Timeout value; in this case, the TCP default will be used). <ins> These properties reflect the API extension specified in Section 3 of RFC5482. </ins> 7.2.1.