Original text:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del>  This document defines requirements on future QUIC versions, even where normative language is not used. Indicates that x is A bits long Indicates that x can be any length from A to B; A can be omitted <del> to indicate a minimum of zero bits and B can be omitted to </del>  indicate no set upper limit; values in this format always end on a byte boundary <del> Indicates that x, with a length described by L, has a fixed value of C </del>  <del> Indicates that x is repeated zero or more times (and that each instance is length L) </del>  This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del>  Commonly used terms in the document are described below. Indicates that x is A bits long Indicates that x holds an integer value using the variable-length <del> encoding in </del>  Indicates that x can be any length from A to B; A can be omitted <del> to indicate a minimum of zero bits and B can be omitted to </del>  indicate no set upper limit; values in this format always end on a byte boundary <del> Indicates that x has a fixed value of C with the length described by L, which can use any of the three length forms above </del>  Indicates that x has a value in the range from C to D, inclusive, with the length described by L, as above <del> Indicates that x is optional (and has length of L) </del>  <del> Indicates that zero or more instances of x are present (and that each instance is length L) </del>  This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte. becoming idle.  Non-ack-eliciting packets are eventually acknowledged when the endpoint sends an ACK frame in response to other events.  In order to assist loss detection at the sender, an endpoint SHOULD generate and send an ACK frame without delay when it receives an ack- eliciting packet either: for connections made by the endpoint and for other users of the network. <del> An endpoint that is only sending ACK frames will not receive acknowledgments from its peer unless those acknowledgments are included in packets with ack-eliciting frames.  An endpoint SHOULD send an ACK frame with other frames when there are new ack-eliciting packets to acknowledge.  When only non-ack-eliciting packets need to be acknowledged, an endpoint MAY wait until an ack-eliciting packet has been received to include an ACK frame with outgoing frames. A receiver MUST NOT send an ack-eliciting frame in all packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgments. </del> 13.2.2. A receiver determines how frequently to send acknowledgments in A variable-length integer error code that indicates the reason for closing this connection.  A CONNECTION_CLOSE frame of type 0x1c uses codes from the space defined in transport-error-codes.  A <del> CONNECTION_CLOSE frame of type 0x1d uses codes from the application protocol error code space; see app-error-codes. </del>  A variable-length integer encoding the type of frame that triggered the error.  A value of 0 (equivalent to the mention of The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del>  This document uses the terminology established in QUIC-TRANSPORT. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del>  This document uses the variable-length integer encoding from QUIC- TRANSPORT. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del>  Definitions of terms that are used in this document:

Reviewer comments:
For those drafts that are in AUTH48.
This PR makes me happy.9000! Very cool!

Revised text:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and  <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> This document defines requirements on future QUIC versions, even where normative language is not used. Indicates that x is A bits long Indicates that x can be any length from A to B; A can be omitted  <ins> to indicate a minimum of zero bits, and B can be omitted to </ins> indicate no set upper limit; values in this format always end on a byte boundary  <ins> Indicates that x has a fixed value of C; the length of x is described by L, which can use any of the length forms above </ins>  <ins> Indicates that x is repeated zero or more times and that each instance has a length of L </ins> This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and  <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> Commonly used terms in the document are described below. Indicates that x is A bits long Indicates that x holds an integer value using the variable-length  <ins> encoding described in </ins> Indicates that x can be any length from A to B; A can be omitted  <ins> to indicate a minimum of zero bits, and B can be omitted to </ins> indicate no set upper limit; values in this format always end on a byte boundary  <ins> Indicates that x has a fixed value of C; the length of x is described by L, which can use any of the length forms above </ins> Indicates that x has a value in the range from C to D, inclusive, with the length described by L, as above  <ins> Indicates that x is optional and has a length of L </ins>  <ins> Indicates that x is repeated zero or more times and that each instance has a length of L </ins> This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte. becoming idle.  Non-ack-eliciting packets are eventually acknowledged when the endpoint sends an ACK frame in response to other events. <ins> An endpoint that is only sending ACK frames will not receive acknowledgments from its peer unless those acknowledgments are included in packets with ack-eliciting frames.  An endpoint SHOULD send an ACK frame with other frames when there are new ack-eliciting packets to acknowledge.  When only non-ack-eliciting packets need to be acknowledged, an endpoint MAY choose not to send an ACK frame with outgoing frames until an ack-eliciting packet has been received. An endpoint that is only sending non-ack-eliciting packets might choose to occasionally add an ack-eliciting frame to those packets to ensure that it receives an acknowledgment; see ack-tracking.  In that case, an endpoint MUST NOT send an ack-eliciting frame in all packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgments. </ins> In order to assist loss detection at the sender, an endpoint SHOULD generate and send an ACK frame without delay when it receives an ack- eliciting packet either: for connections made by the endpoint and for other users of the network.  13.2.2. A receiver determines how frequently to send acknowledgments in A variable-length integer error code that indicates the reason for closing this connection.  A CONNECTION_CLOSE frame of type 0x1c uses codes from the space defined in transport-error-codes.  A  <ins> CONNECTION_CLOSE frame of type 0x1d uses codes defined by the application protocol; see app-error-codes. </ins> A variable-length integer encoding the type of frame that triggered the error.  A value of 0 (equivalent to the mention of The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and  <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> This document uses the terminology established in QUIC-TRANSPORT. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and  <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> This document uses the variable-length integer encoding from QUIC- TRANSPORT. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and  <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> Definitions of terms that are used in this document: