Change:
The ops drafts often reference the core drafts by section number; make sure these section number references are correct for the WGLC drafts.
Correcting overcorrections regarding capitalization, but this seems benign.

Discussion:
Multiple QUIC packets may be coalesced into a UDP datagram, with a datagram carrying one or more long header packets followed by zero or one short header packets.  When packets are coalesced, the Length <del> fields in the long headers are used to separate QUIC packets.  The length header field is variable length and its position in the header is also variable depending on the length of the source and destination connection ID.  See Section 4.6 of QUIC-TRANSPORT. </del> <ins> fields in the long headers are used to separate QUIC packets; see Section 12.2 of QUIC-TRANSPORT.  The length header field is variable length, and its position in the header is also variable depending on the length of the source and destination connection ID; see Section 17.2 of QUIC-TRANSPORT. </ins> 2.3.

secrecy (PFS). Data in the first flight sent by the client in a connection <del> established with 0-RTT MUST be idempotent (as specified in section 2.1 in QUIC-TLS).  Applications MUST be designed, and their data MUST be framed, such that multiple reception of idempotent data is recognized as such by the receiver.  Applications that cannot treat data that may appear in a 0-RTT connection establishment as </del> <ins> established with 0-RTT MUST be idempotent (as specified in Section 5.6 in QUIC-TLS).  Applications MUST be designed, and their data MUST be framed, such that multiple reception of idempotent data is recognized as such by the receiver.  Applications that cannot treat data that may appear in a 0-RTT connection establishment as </ins> idempotent MUST NOT use 0-RTT establishment.  For these reason the QUIC transport SHOULD provide some or all of the following interfaces to applications:

While a QUIC implementation must necessarily provide a way for an application to send data on separate streams, it does not necessarily <del> expose stream identifiers to the application (see e.g.  QUIC-HTTP section 6) either at the sender or receiver end, so applications should not assume access to these identifiers. </del> <ins> expose stream identifiers to the application (see, for example, QUIC- HTTP, Section 6) either at the sender or receiver end, so applications should not assume access to these identifiers. </ins> 4.1.

has two sets of types: one for QUIC internal problems that might lead to connection closure, and one for closures initiated by the application.  An application using QUIC can define application- <del> specific error codes, e.g. see QUIC-HTTP section 8.1.  In the case of a grateful shut-down initiated by the application after application layer negotiation, a NO_ERROR code is expected.  Further, the CONNECTION_CLOSE frame provides an optional reason field, that can be used to append human-readable information to an error code.  Note that QUIC RESET_STREAM and STOP_SENDING frames provide similar </del> <ins> specific error codes (see, for example, QUIC-HTTP, Section 8.1).  In the case of a grateful shut-down initiated by the application after application layer negotiation, a NO_ERROR code is expected.  Further, the CONNECTION_CLOSE frame provides an optional reason field, that can be used to append human-readable information to an error code. Note that QUIC RESET_STREAM and STOP_SENDING frames provide similar </ins> capablities.  Usually application error codes are defined to be applicabile to all three frames.

adjust the maximum idle timeout based on the number of open or expected connections as shorter timeout values may free-up memory more quickly.  If an application desires to keep the connection open <del> for longer than the announced timeout, it can send keep-alives </del> <ins> for longer than the announced timeout, it can send keep-alive </ins> messages, or a QUIC implementation may provide an option to defer the <del> time-out to avoid unnecessary load, as specified in Section 10.2.2 of </del> <ins> time-out to avoid unnecessary load, as specified in Section 10.1.2 of </ins> QUIC.  See resumption-v-keepalive for further guidance on keep- alives.

9.1. QUIC supports a server-generated Connection ID, transmitted to the <del> client during connection establishment (see Section 6.1 of QUIC). </del> <ins> client during connection establishment (see Section 7.2 of QUIC). </ins> Servers behind load balancers may need to change the Connection ID during the handshake, encoding the identity of the server or information about its load balancing pool, in order to support