Original text:
All packets sent after receiving and processing transport parameters might be affected, including Initial, Handshake, and Retry packets. <del> A client MAY also clear the QUIC Bit in packets that are sent prior to receiving transport parameters from the server.  However, a client MUST NOT clear the QUIC Bit unless the Initial packets it sends include a token provided by the server in a NEW_TOKEN frame (Section 19.7 of QUIC) received less 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 server configuration changes and a client does not set the QUIC

Reviewer comments:
URL Has there been any analysis done for the 7 day rule? or is this just an agreed value. It would be nice to provide some reasoning behind the 7 day rule.
This matches the recommendations in TLS for session tickets, which prohibit the use of tickets after 7 days. But I don't think we should hide from the fact that this is completely and unapologetically arbitrary. Arbitrary is OK; justification only papers over that.
If this is completely arbitrary then we should not need to recommend this, this is not an experimental specification. In that case it makes sense to even drop it. But I see this is not really that much arbitrary, and reflects the practice for TLS session token. I think we can just say that. in this case we can go from SHOULD to MAY, making it optional. by the way I also think, the security consideration falls short on this topic. If we are recommending something then we it is better to say what happens when it is not followed.
It is arbitrary, but it does need a specified maximum. What happens when it is not followed is that packets can't be processed.
yes, if we say something then it will be best to specify a maximum. so the question now from my side is - do we need a strong recommendation (SHOULD) or can we make is optional (MAY)? if we don't have enough experience of actual deployment of it them perhaps it is best that we make it optional. But I am interested to hear why this should be a "SHOULD". when you say "packets can't be processed" do you mean at server? can we write this down?
The text already says why:
now that we have explicitly added handshake and 0-RTT packet in this clause, the to me call for a attention from the WG to review. Otherwise looks good to me. Latest text LGTMThanks for addressing my nits

Revised text:
All packets sent after receiving and processing transport parameters might be affected, including Initial, Handshake, and Retry packets.  <ins> A client MAY also clear the QUIC Bit in Initial, Handshake, or 0-RTT packets that are sent prior to receiving transport parameters from the server.  However, a client MUST NOT clear the QUIC Bit unless the Initial packets it sends include a token provided by the server in a NEW_TOKEN frame (Section 19.7 of QUIC), received less 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 server configuration changes and a client does not set the QUIC