jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-quic-bit-grease

Commentary: This one says something like what  said , with the caveat that the whole thing about per - connection ID is specific to spin bits , so I dropped that . 
 LGTM
The second-to-most significant bit of the first byte in every QUIC
packet is defined as having a fixed value in QUIC version 1 QUIC.
The purpose of having a fixed value is to allow QUIC to be
efficiently distinguished from other protocols; see DEMUX for a
description of a system that might use this property.  As this bit
can identify a packet as QUIC, it is sometimes referred to as the
"QUIC Bit".
The second-to-most significant bit of the first byte in every QUIC
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
description of a system that might use this property.  As this bit
can identify a packet as QUIC, it is sometimes referred to as the
"QUIC Bit".
This document introduces no new security considerations for endpoints
or entities that can rely on endpoint cooperation.  However, this
change makes the task of identifying QUIC more difficult without
cooperation of endpoints.  This sometimes works counter to the
security goals of network operators who rely on network
classification to identify threats.
This document introduces no new security considerations for endpoints
or entities that can rely on endpoint cooperation.  However, this
change makes the task of identifying QUIC more difficult without
cooperation of endpoints.  This sometimes works counter to the
security goals of network operators who rely on network
classification to identify threats; see Section 3.1 of MANAGEABILITY
for a more comprehensive treatment of this topic.
Draft: draft-ietf-quic-bit-grease

Commentary: LGTM . 
 Actually , looking at a bit closer , perhaps consider : " ... endpoint and cooperating intermediaries to efficiently ... " and perhaps make the Manageability reference explicitly to section 3.1 that covers identifying QUIC traffic . 
 Note that this is the second paragraph of the document . I 'd prefer not to pile too many unrelated concepts in at this point . I think that it is OK to consider " cooperating intermediaries " to be implicit when we say " endpoint " when operating at this level of abstraction . Toward the end , where manageability is cited , is a better place for that sort of detail . I narrowed the citation to point to Section 3.1 as you suggested . 
 I think this update addresses 's point in the telechat review .
The second-to-most significant bit of the first byte in every QUIC
packet is defined as having a fixed value in QUIC version 1 QUIC.
The purpose of having a fixed value is to allow QUIC to be
efficiently distinguished from other protocols; see DEMUX for a
description of a system that might use this property.  As this bit
can identify a packet as QUIC, it is sometimes referred to as the
"QUIC Bit".
The second-to-most significant bit of the first byte in every QUIC
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
description of a system that might use this property.  As this bit
can identify a packet as QUIC, it is sometimes referred to as the
"QUIC Bit".
This document introduces no new security considerations for endpoints
or entities that can rely on endpoint cooperation.  However, this
change makes the task of identifying QUIC more difficult without
cooperation of endpoints.  This sometimes works counter to the
security goals of network operators who rely on network
classification to identify threats.
This document introduces no new security considerations for endpoints
or entities that can rely on endpoint cooperation.  However, this
change makes the task of identifying QUIC more difficult without
cooperation of endpoints.  This sometimes works counter to the
security goals of network operators who rely on network
classification to identify threats; see Section 3.1 of MANAGEABILITY
for a more comprehensive treatment of this topic.
Draft: draft-ietf-quic-bit-grease

Commentary: Broken into separate changes ; see the commentary on each . This wo n't rebase nicely with , but I can manage that later .
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 as a connection error of type
TRANSPORT_PARAMETER_ERROR.
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.
Draft: draft-ietf-quic-bit-grease

Commentary: Inappropriate use of MAY , lack of MUST [ NOT ] . Thanks to   for schooling me on the correct usage .
Advertising the grease_quic_bit transport parameter indicates that
packets sent to this endpoint MAY set a value of 0 for the QUIC Bit.
The QUIC Bit is defined as the second-to-most significant bit of the
first byte of QUIC packets (that is, the value 0x40).
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
Bit is defined as the second-to-most significant bit of the first
byte of QUIC packets (that is, the value 0x40).
A server MUST clear the QUIC bit only after processing transport
parameters from a client.  A server cannot remember that a client
negotiated the extension in a previous connection and clear the QUIC
Bit based on that information.
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.
A server MUST clear the QUIC bit only after processing transport
parameters from a client.  A server MUST NOT remember that a client
negotiated the extension in a previous connection and clear the QUIC
Bit based on that information.
An endpoint MUST NOT 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.
Draft: draft-ietf-quic-bit-grease

Commentary: 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 do n'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 ca n'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 do n'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 ca n't be processed " do you mean at server ? can we write this down ? 
 The text already says why : 
 now that we have explicitly 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
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.
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.
Draft: draft-ietf-quic-bit-grease

Commentary: a reference for NEW_TOKEN is needed here .
A client MAY also clear the QUIC Bit in Initial packets that are sent
prior to receiving transport parameters from the server.  A client
can only clear the QUIC Bit if such packets include a token provided
by the server in a NEW_TOKEN frame on a connection where the server
also included the grease_quic_bit transport parameter.  To allow for
changes in server configuration, clients SHOULD set the QUIC Bit if
the token was provided more than 7 days prior.
A client MAY also clear the QUIC Bit in Initial packets that are sent
prior to receiving transport parameters from the server.  A client
can only clear the QUIC Bit if such packets include a token provided
by the server in a NEW_TOKEN frame (Section 19.7 of QUIC) on a
connection where the server also included the grease_quic_bit
transport parameter.  To allow for changes in server configuration,
clients SHOULD set the QUIC Bit if the token was provided more than 7
days prior.
Draft: draft-ietf-quic-bit-grease

Commentary: This is also fewer words :) 
 there is no definition of what an intermediary stands for here to understand the statement . I think rather defining the " intermediary " we can rephrase to inform the original intention of the fixed bit in QUIC packet i.e. coexistence with protocols in  . The statement here also gives an impression that any node in the network should be able to efficiently distinguish QUIC packets where in our OPS draft we are saying this is not reliable with a notion of " do n't use it " . so rephrasing should also help from this point of view . I would propose something like this - The purpose of having a fixed value is to allow coexistance with other protocols in ] . As this bit can be used to identify a packet as QUIC , it is sometimes referred to as the " QUIC Bit " .
The second-to-most significant bit of the first byte in every QUIC
packet is defined as having a fixed value in QUIC version 1 QUIC.
The purpose of having a fixed value is to allow intermediaries and
endpoints to efficiently distinguish between QUIC and other
protocols; see DEMUX for a description of a scheme that QUIC can
integrate with as a result.  As this bit effectively identifies a
packet as QUIC, it is sometimes referred to as the "QUIC Bit".
The second-to-most significant bit of the first byte in every QUIC
packet is defined as having a fixed value in QUIC version 1 QUIC.
The purpose of having a fixed value is to allow QUIC to be
efficiently distinguished from other protocols; see DEMUX for a
description of a system that might use this property.  As this bit
can identify a packet as QUIC, it is sometimes referred to as the
"QUIC Bit".
Draft: draft-ietf-quic-bit-grease

Commentary: It seems like the answer to was already in the draft . It just was n'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 do n't see an answer about the question of stateless reset . For instance , you mention NEW_TOKEN but not . 
 Oh , I misread . Good thing I did n'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 does n'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 do n'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
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.
Draft: draft-ietf-quic-bit-grease

Commentary: At the moment , the paragraph says " Initial packets that are sent to establish a new connection . " That is unclear . It is possible to interpret this text as " all Initial packets that the client sends , " because all the Initial packets are used to establish a new connection . As the paragraph right above discusses what endpoints should do once they receive transport parameters , we can be clear that this paragraph discusses what should be done until then . 
 Thanks  , this is definitely clearer .  of the tweak ?
A client MAY also clear the QUIC Bit in Initial packets that are sent
to establish a new connection.  A client can only clear the QUIC Bit
if the packet includes a token provided by the server in a NEW_TOKEN
frame on a connection where the server also included the
grease_quic_bit transport parameter.  To allow for changes in server
configuration, clients SHOULD set the QUIC Bit if the token was
provided more than 7 days prior.
A client MAY also clear the QUIC Bit in Initial packets that are sent
prior to receiving transport parameters from the server.  A client
can only clear the QUIC Bit if such packets include a token provided
by the server in a NEW_TOKEN frame on a connection where the server
also included the grease_quic_bit transport parameter.  To allow for
changes in server configuration, clients SHOULD set the QUIC Bit if
the token was provided more than 7 days prior.
Draft: draft-ietf-quic-bit-grease

Commentary: This was unclear as it was n't clear which extension was operative in the sentence . 
 changes lgtm
For example, an extension might define a transport parameter that is
sent in addition to the grease_quic_bit transport parameter.  Though
the value of the QUIC Bit in packets received by a peer might be set
according to rules defined by the extension, they might also be
randomized according to the definition of the grease_quic_bit
extension.  Receiving the transport parameter for the extension could
be used to confirm that a peer supports the semantic defined in the
extension.  To avoid acting on a randomized signal, the extension can
require that endpoints set the QUIC Bit according to the rules of the
extension, but defer acting on the information conveyed until the
transport parameter for the extension is received.
For example, an extension might define a transport parameter that is
sent in addition to the grease_quic_bit transport parameter.  Though
the value of the QUIC Bit in packets received by a peer might be set
according to rules defined by the extension, they might also be
randomized as specified in this document.  Receiving the transport
parameter for the extension could be used to confirm that a peer
supports the semantic defined in the extension.  To avoid acting on a
randomized signal, the extension can require that endpoints set the
QUIC Bit according to the rules of the extension, but defer acting on
the information conveyed until the transport parameter for the
extension is received.