Original text:
Greasing the QUIC Bit <del> draft-ietf-quic-bit-grease-latest </del> Abstract This document describes a method for negotiating the ability to send <del> an arbitrary value for the second-to-most significant bit in QUIC </del>  packets. 1. <del> QUIC QUIC intentionally describes a very narrow set of fields that are visible to entities other than endpoints.  Beyond those characteristics that are defined as invariant QUIC-INVARIANTS, very little about the "wire image" RFC8546 of QUIC is visible. </del>  <del> The second-to-most significant bit of the first byte in every QUIC </del>  packet is defined as having a fixed value in QUIC version 1 QUIC. The purpose of having a fixed value is to allow endpoints to efficiently distinguish QUIC from other protocols; see DEMUX for a Where endpoints and the intermediaries that support them do not depend on the QUIC Bit having a fixed value, sending the same value <del> in every packet is more of liability than an asset.  If systems come to depend on a fixed value, then it might become infeasible to define a version of QUIC that attributes semantics to this bit. </del>  In order to safeguard future use of this bit, this document defines a QUIC transport parameter that indicates that an endpoint is willing 3. <del> The grease_quic_bit transport parameter (0x2ab2) can be sent by both client and server.  The transport parameter is sent with an empty value; an endpoint that understands this transport parameter MUST treat receipt of a non-empty value of the transport parameter as a connection error of type TRANSPORT_PARAMETER_ERROR. </del>  An endpoint that advertises the grease_quic_bit transport parameter MUST accept packets with the QUIC Bit set to a value of 0.  The QUIC <del> Bit is defined as the second-to-most significant bit of the first byte of QUIC packets (that is, the value 0x40). </del>  3.1. than 604800 seconds (7 days) prior on a connection where the server also included the grease_quic_bit transport parameter. <del> This 7 day limit allows for changes in server configuration.  If </del>  server configuration changes and a client does not set the QUIC Bit, then it is possible that a server will drop packets, resulting in connection failures. <del> A server MUST set the QUIC bit to 0 only after processing transport </del>  parameters from a client.  A server MUST NOT remember that a client negotiated the extension in a previous connection and set the QUIC Bit to 0 based on that information. according to rules defined by the extension, they might also be randomized as specified in this document. <del> Receiving a transport parameter for an extension that uses the QUIC Bit could be used to confirm that a peer supports the semantic </del>  defined in the extension.  To avoid acting on a randomized signal, the extension can require that endpoints set the QUIC Bit according <del> to the rules of the extension, but defer acting on the information </del>  conveyed until the transport parameter for the extension is received. Extensions that define semantics for the QUIC Bit can be negotiated Permanent <del> This document. Date of registration. </del>  <del> QUIC Working Group (quic@ietf.org) </del>  IETF (iesg@ietf.org)  (none)

Reviewer comments:
These are all the changes I found from the text diff, plus some extra changes about versions.
I have reviewed the changes, and I agree that they are editorial in nature.

Revised text:
Greasing the QUIC Bit  Abstract This document describes a method for negotiating the ability to send  <ins> an arbitrary value for the second-most significant bit in QUIC </ins> packets. 1.  <ins> The version-independent definition of QUIC QUIC-INVARIANTS intentionally describes a very narrow set of fields that are visible to entities other than endpoints.  Beyond those characteristics that are invariant, very little about the "wire image" RFC8546 of QUIC is visible. </ins>  <ins> The second-most significant bit of the first byte in every QUIC </ins> packet is defined as having a fixed value in QUIC version 1 QUIC. The purpose of having a fixed value is to allow endpoints to efficiently distinguish QUIC from other protocols; see DEMUX for a Where endpoints and the intermediaries that support them do not depend on the QUIC Bit having a fixed value, sending the same value  <ins> in every packet is more of a liability than an asset.  If systems come to depend on a fixed value, then it might become infeasible to define a version of QUIC that attributes semantics to this bit. </ins> In order to safeguard future use of this bit, this document defines a QUIC transport parameter that indicates that an endpoint is willing 3.  <ins> The grease_quic_bit transport parameter (0x2ab2) is defined for QUIC version 1 QUIC.  This transport parameter can be sent by both client and server.  The transport parameter is sent with an empty value; an endpoint that understands this transport parameter MUST treat receipt of a non-empty value of the transport parameter as a connection error of type TRANSPORT_PARAMETER_ERROR. </ins> An endpoint that advertises the grease_quic_bit transport parameter MUST accept packets with the QUIC Bit set to a value of 0.  The QUIC  <ins> Bit is defined as the second-most significant bit of the first byte of QUIC packets (that is, the value 0x40). </ins> 3.1. than 604800 seconds (7 days) prior on a connection where the server also included the grease_quic_bit transport parameter.  <ins> This 7-day limit allows for changes in server configuration.  If </ins> server configuration changes and a client does not set the QUIC Bit, then it is possible that a server will drop packets, resulting in connection failures.  <ins> A server MUST set the QUIC Bit to 0 only after processing transport </ins> parameters from a client.  A server MUST NOT remember that a client negotiated the extension in a previous connection and set the QUIC Bit to 0 based on that information. according to rules defined by the extension, they might also be randomized as specified in this document.  <ins> The receipt of a transport parameter for an extension that uses the QUIC Bit could be used to confirm that a peer supports the semantic </ins> defined in the extension.  To avoid acting on a randomized signal, the extension can require that endpoints set the QUIC Bit according  <ins> to the rules of the extension but defer acting on the information </ins> conveyed until the transport parameter for the extension is received. Extensions that define semantics for the QUIC Bit can be negotiated Permanent  <ins> RFC 9287 </ins>  <ins> 2022-07-13 </ins> IETF (iesg@ietf.org) <ins> QUIC Working Group (quic@ietf.org) </ins> (none)