Original text:
negotiated the extension in a previous connection and clear the QUIC Bit based on that information.  3.2. The purpose of this extension is to allow for the use of the QUIC Bit

Reviewer comments:
It seems like the answer to was already in the draft. It just wasn't precise enough to be useful. I also found the wording of the next section awkward, so I'm bundling my changes.
The editorial improvements seem good but I still don't see an answer about the question of stateless reset. For instance, you mention NEW_TOKEN but not .
Oh, I misread. Good thing I didn't mark this as closing . I'll add that.
Would it be correct to say that packets will never be affected by this extension?
Good question. An Initial with a token from (NEW_TOKEN from) a previous connection can clear the bit if the server originally included the transport parameter. If the server puts this information in the token, processes that token, and decides to send a Retry anyway, it might know that the client previously supported the extension. The question is whether we want to allow that. Allowing that means that the client is now constrained (as the server is) to not offer a token if it changes its attitude toward the extension in the interim. Disallowing it means that Retry doesn't get the benefit of greasing. The other way this might happen is if the Retry is sent after processing the contents of the Initial packet. That's much less likely given the way Retry works, but it is at least theoretically possible. I'm leaning toward forbidding the server from exercising the extension unless it reads the client's opinion from the message it receives. We don't add a bunch of constraints on how clients offer tokens or tickets elsewhere in the stack and it would be bad form to start.
Gah, I misread that as Retry. I keep doing that. As for stateless reset, it seems unlikely that a server would be able to generate a truly stateless reset with the QUIC Bit cleared. Except... A server could condition its use of the QUIC Bit extension on support from the client. That is, it only declares support for the extension if the client does the same. In that case, packets it receives with the QUIC Bit cleared would indicate that the client also supports the extension. In that case, the server would be able to clear the QUIC Bit on its own stateless reset packets. Aside from that, it seems like it would be hard to be confident that the cleared bit would be acceptable to a client.
Right, we might expect that a QUIC server that has a good relationship with e.g. a Load Balancer might be able to share some information about itself and behaviours. But that sounds too hard for the minimal gain it would provide here, so I'm pessimistic anyone would bother just for QUIC bit grease. The new text cuts a good balance on speaking to the consideration and allow people to do what they like.
LGTM thanks

Revised text:
negotiated the extension in a previous connection and clear the QUIC Bit based on that information. <ins> An endpoint cannot clear the QUIC Bit without knowing whether the peer supports the extension.  As stateless reset packets (Section 10.3 of QUIC) are only used after a loss of connection state, endpoints are unlikely to be able to clear the QUIC Bit on stateless reset packets. </ins> 3.2. The purpose of this extension is to allow for the use of the QUIC Bit