Original text:
6.  An WebTransport session over HTTP/2 is terminated when either endpoint closes the stream associated with the CONNECT request that initiated the session.  Upon learning about the session being terminated, the endpoint MUST stop sending new datagrams and reset all of the streams associated with the session. <del> 7. </del>  The WebTransport framework OVERVIEW defines a set of optional transport properties that clients can use to determine the presence TLS.  Without such support, Http2Transport connections cannot survive network transitions. <del> 8. </del>  WebTransport over HTTP/2 satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams. <del> 9. </del>  <del> 9.1. </del>  The following entry is added to the "HTTP/2 Settings" registry established by RFC7540: This document <del> 9.2. An example of negotiating a WebTransport Stream on an HTTP/2 connection follows.  This example is intended to closely follow the example in Section 5.1 of RFC8441 to help illustrate the differences defined in this document. An example of the server initiating a WebTransport Stream follows. The only difference here is the endpoint that sends the first WT_STREAM frame. 10.  References </del>  <del> 10.1.  URIs </del>  [1] mailto:webtransport@ietf.org

Reviewer comments:
There is not "right" place to put these, but as they are fairly large (and not that useful, frankly), I am going to suggest that they go after the frame definitions.
Yeah, these used to describe how you'd handle a bunch of new concepts, this is now pretty basic and not particularly enlightening. Mayyyybe useful for the establishment, if you've never seen Extended CONNECT, but... yeah. Seems good to move around now and we can cut it later if we don't end up adding anything useful to them. (I also updated with the section reference change from the other PRs to fix up conflicts, since this moved one of those)
I think these have evolved through various versions of the drafts. When the original draft was presented, things like a "CONNECT stream" and how other streams relate to it were not common knowledge, so the examples were maybe more useful. If everyone has got the idea, we can drop it.

Revised text:
6. <ins> An example of negotiating a WebTransport Stream on an HTTP/2 connection follows.  This example is intended to closely follow the example in Section 5.1 of RFC8441 to help illustrate the differences defined in this document. An example of the server initiating a WebTransport Stream follows. The only difference here is the endpoint that sends the first WT_STREAM frame. 7. </ins> An WebTransport session over HTTP/2 is terminated when either endpoint closes the stream associated with the CONNECT request that initiated the session.  Upon learning about the session being terminated, the endpoint MUST stop sending new datagrams and reset all of the streams associated with the session.  <ins> 8. </ins> The WebTransport framework OVERVIEW defines a set of optional transport properties that clients can use to determine the presence TLS.  Without such support, Http2Transport connections cannot survive network transitions.  <ins> 9. </ins> WebTransport over HTTP/2 satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams.  <ins> 10. </ins>  <ins> 10.1. </ins> The following entry is added to the "HTTP/2 Settings" registry established by RFC7540: This document  <ins> 11.  References </ins>  <ins> 11.1.  URIs </ins> [1] mailto:webtransport@ietf.org