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

Commentary: said 
 One could imagine an implementation using a small buffer to read the beginning of the stream . If the whole field section happens to fit into it , so be it . A MUST would probably mean that a conforming implementation had to unread the field section . 
 We can probably just use " can " here . From an interoperability standpoint , there is no value to recommending any particular value . 
 Does SHOULD -can mean this is a design change ? 
 Yes , so if you 're advocating doing that then I 'll mark this as design . 
 The SHOULD is there to guard against memory exhaustion attacks . Streams " parking " is a QPACK design feature . The SHOULD should stay . 
 The plan is to leave the SHOULD , but add more editorial text in 2.2.1 explaining why it 's a good idea .
Paragraph (version A):
To bound the memory requirements of the decoder for blocked streams,
encoded field section data SHOULD remain in the stream's flow control
window while the stream is blocked.  A stream becomes unblocked when
the Insert Count becomes greater than or equal to the Required Insert
Count for all encoded field sections the decoder has started reading
from the stream.
Paragraph (version B):
While blocked, encoded field section data SHOULD remain in the
blocked stream's flow control window.  This data is unusable until
the stream becomes unblocked, and releasing the flow control
prematurely makes the decoder vulnerable to memory exhaustion
attacks.  A stream becomes unblocked when the Insert Count becomes
unblocked when the Insert Count becomes greater than or equal to the
Required Insert Count for all encoded field sections the decoder has
started reading from the stream.
Draft: draft-ietf-quic-qpack

Commentary: said 
 I think we can change to SHOULD NOT . I 'd rather not be so prescriptive here , since a QPACK implementation might well cut this corner and ignore flow control constraints and rely on higher levels of the stack to ensure the necessary flow control is available ? I guess I could be convinced otherwise . 
 said 
 Even though newlines are not really allowed ( unescaped ) in field values , we can add a note to this effect . 
 said 
 Yes , that 's why they 're not there . 
 Propose to close with no action then ? Or is there a way to reformat the table to include the longer names ? 
 I see a couple options in addition to " close with no change " , namely to add a note below the table that the names are abbreviated , or to write out the IANA directives in prose without a table at all . I do n't have a particular preference among those three options , though . 
 We need to come to a decision on this . Since this is from an IESG  ( and not a DISCUSS ) , the editors can IMO go ahead with their preferred resolution . 
 said 
 I agree it 's not worth mitigating technically . I question whether it 's worth documenting , personally , but it does no harm . 
 Maybe just a sentence that this mitigation has limits when traversing multiple intermediaries ? 
 That seems like it would strike a reasonable balance . 
 said 
 This table appears before the general discussion of indexing . One thought is to add something along the top of the table , like this : ? 
 Your proposal does improve the clarity of the figure , but I am hoping for more . While it is true that the dedicated sections that discuss indexing appear later in the document , the introductory text alongside the figure uses language such as " smallest absolute index " , increases the draining index " , and " with an absolute index lower than the draining index " that imply a numerical ordering and directionality of the indices . Interpreting the figure would be easier with the direction of that ordering stated explicitly , as might be done via " Newer Entries ( larger index)"/etc .. 
 We need to come to a decision on this . Since this is from an IESG  ( and not a DISCUSS ) , the editors can IMO go ahead with their preferred resolution .
Paragraph (version A):
To avoid these deadlocks, an encoder SHOULD avoid writing an
instruction unless sufficient stream and connection flow control
credit is available for the entire instruction.
Paragraph (version B):
To avoid these deadlocks, an encoder SHOULD NOT write an instruction
unless sufficient stream and connection flow control credit is
available for the entire instruction.
Paragraph (version B):
This mitigation is most effective between two endpoints.  If messages
are re-encoded by an intermediary without knowledge of which entity
constructed a given message, the intermediary could inadvertently
merge compression contexts that the original encoder had specifically
kept separate.
Paragraph (version B):
For fomatting reasons, the setting names here are abbreviated by
removing the 'SETTING_' prefix.
Draft: draft-ietf-quic-http

Commentary: said 
 said 
 Honestly , this whole sentence is a bit awkward . I 'll improve that . 
 said 
 I have to say , this is a little odd . HTTP requires case insensitive comparison , but by calling it out here , the juxtaposition is weird . As we force lowercase , we could just strike : " that are compared in a case - insensitive fashion " 
 The first is a statement of fact about what SEMANTICS requires . However , I agree that we reduce confusion and lose nothing by making the statement less explicit . Interested parties can read SEMANTICS . 
 Yes , the proposed text addresses my comments . Thanks for the updates .
Paragraph (version A):
As in previous versions of HTTP, field names are strings containing a
subset of ASCII characters that are compared in a case-insensitive
fashion.  Properties of HTTP field names and values are discussed in
more detail in Section 5.1 of SEMANTICS.  As in HTTP/2, characters in
field names MUST be converted to lowercase prior to their encoding.
A request or response containing uppercase characters in field names
MUST be treated as malformed (malformed).
Paragraph (version B):
Field names are strings containing a subset of ASCII characters.
Properties of HTTP field names and values are discussed in more
detail in Section 5.1 of SEMANTICS.  As in HTTP/2, characters in
field names MUST be converted to lowercase prior to their encoding.
A request or response containing uppercase characters in field names
MUST be treated as malformed (malformed).
Paragraph (version A):
HTTP/3 uses QPACK field compression as described in QPACK, a
variation of HPACK that allows the flexibility to avoid compression-
induced head-of-line blocking.  See that document for additional
details.
Paragraph (version B):
QPACK describes a variation of HPACK that gives an encoder some
control over how much head-of-line blocking can be caused by
compression.  This allows an encoder to balance compression
efficiency with latency.  HTTP/3 uses QPACK to compress header and
trailer sections, including the pseudo-header fields present in the
header section.
Paragraph (version A):
This means that the client's first request occurs on QUIC stream 0,
with subsequent requests on stream 4, 8, and so on.  In order to
permit these streams to open, an HTTP/3 server SHOULD configure non-
zero minimum values for the number of permitted streams and the
initial stream flow control window.  So as to not unnecessarily limit
parallelism, at least 100 requests SHOULD be permitted at a time.
Paragraph (version B):
This means that the client's first request occurs on QUIC stream 0,
with subsequent requests on stream 4, 8, and so on.  In order to
permit these streams to open, an HTTP/3 server SHOULD configure non-
zero minimum values for the number of permitted streams and the
initial stream flow control window.  So as to not unnecessarily limit
parallelism, at least 100 request streams SHOULD be permitted at a
time.
Draft: draft-ietf-quic-http

Commentary: said 
 Yep , none of these are specifically locators , so URI is correct .
Paragraph (version A):
HTTP relies on the notion of an authoritative response: a response
that has been determined to be the most appropriate response for that
request given the state of the target resource at the time of
response message origination by (or at the direction of) the origin
server identified within the target URI.  Locating an authoritative
server for an HTTP URL is discussed in Section 4.3 of SEMANTICS.
Paragraph (version A):
The "https" scheme associates authority with possession of a
certificate that the client considers to be trustworthy for the host
identified by the authority component of the URL.
Paragraph (version B):
HTTP relies on the notion of an authoritative response: a response
that has been determined to be the most appropriate response for that
request given the state of the target resource at the time of
response message origination by (or at the direction of) the origin
server identified within the target URI.  Locating an authoritative
server for an HTTP URI is discussed in Section 4.3 of SEMANTICS.
Paragraph (version B):
The "https" scheme associates authority with possession of a
certificate that the client considers to be trustworthy for the host
identified by the authority component of the URI.
Paragraph (version A):
Servers MAY serve HTTP/3 on any UDP port; an alternative service
advertisement always includes an explicit port, and URLs contain
either an explicit port or a default port associated with the scheme.
Paragraph (version B):
Servers MAY serve HTTP/3 on any UDP port; an alternative service
advertisement always includes an explicit port, and URIs contain
either an explicit port or a default port associated with the scheme.
Draft: draft-ietf-quic-http

Commentary: Specifically those defined in RFC 7540 . 
 says : The table of defined HTTP/3 settings is in The diverges a little bit from everything that is stated in RFC 7540 . is stated as reserved in IANA but no mention of it in RFC 7540 . Therefore it is ambiguous if an HTTP/3 implementation should reject this Type value . The range is reserved for HTTP/2 experimental use . Its not clear if I should reject those too . IANA also includes some extension settings : ( RFC 8441 ) , 0x10 ( MS - HTTP2E ) . I might expect to be reused by some extension that defines  over H3 . seems like something that is not reusable ? And finally , we have Extensible Priorities that defines SETTINGSDEPRECATEHTTP2_PRIORITIES and wants to claim . I do n't expect any need to also define that in HTTP/3 settings , unless the purpose is to prohibit it . In summary , I do n't think there is a huge problem . Maybe we can editorialize our way out of the ambiguity . However , I 'd really like to avoid H/3 connections instantly failing due to implementations disagreeing about this rejection requirement . 
 I overlooked that already made the point about in . 
 The intent is to reserve things that are defined in 7540 ; things reserved by other extensions might later be defined for HTTP/3 , so there should n't be any assumptions . Let 's make that requirement crisper to apply specifically to those values explicitly reserved . 
 WfM 
 I wonder if we should ask IANA if they can tell how it came to be that 0x0 was marked as reserved with 7540 as the reference even though we are failing to see what part of 7540 should be effectuating that .
Paragraph (version A):
Setting identifiers which were used in HTTP/2 where there is no
corresponding HTTP/3 setting have also been reserved (iana-settings).
These settings MUST NOT be sent, and their receipt MUST be treated as
a connection error of type H3_SETTINGS_ERROR.
Paragraph (version B):
Setting identifiers which were defined in HTTP2 where there is no
corresponding HTTP/3 setting have also been reserved (iana-settings).
These reserved settings MUST NOT be sent, and their receipt MUST be
treated as a connection error of type H3_SETTINGS_ERROR.
Draft: draft-ietf-quic-recovery

Commentary: From the transport draft 's connection migration section . 
 Section 9.4 in Transport ( ) does a nice job of explaining the RTT and congestion control implications of migration , but given one might reasonably expect some or all of that text to exist in recovery , I think it makes sense to reference it more . In particular , " Packets sent on the old path MUST NOT contribute to congestion control or RTT estimation for the new path . " is a useful sentence .
Paragraph (version A):
RTT samples for the network path are recorded in latest_rtt; see
latest-rtt.  On the first RTT sample after initialization, the
estimator is reset using that sample.  This ensures that the
estimator retains no history of past samples.
Paragraph (version B):
RTT samples for the network path are recorded in latest_rtt; see
latest-rtt.  On the first RTT sample after initialization, the
estimator is reset using that sample.  This ensures that the
estimator retains no history of past samples.  Packets sent on other
paths do not contribute RTT samples to the current path, as described
in Section 9.4 of QUIC-TRANSPORT.
Paragraph (version B):
The congestion controller is per path, so packets sent on other paths
do not alter the current path's congestion controller, as described
in Section 9.4 of QUIC-TRANSPORT.
Draft: draft-ietf-quic-http

Commentary: Address multiple editorial comments . 
 said 
 said 
 The text currently says : Transport makes the following addition , in : That might be worth reiterating in HTTP/3 . 
 said 
 Two separate questions . I 'm fine generalizing it to HTTP/1.x . The link between the first two sentences is the fact that HTTP/1.x uses human - readable whitespace - delimited fields , but those attributes make parsing inconsistent ; subsequent versions of HTTP/2 went a different direction . If you 're talking about the second and third , that could easily be a paragraph split ; it 's a change of idea under the umbrella of major changes of direction from H1 to H2 + .
Paragraph (version A):
HTTP semantics (SEMANTICS) are used for a broad range of services on
the Internet.  These semantics have most commonly been used with
HTTP/1.1, over a variety of transport and session layers, and with
HTTP/2 over TLS.  HTTP/3 supports the same semantics over a new
transport protocol, QUIC.
Paragraph (version B):
HTTP semantics (SEMANTICS) are used for a broad range of services on
the Internet.  These semantics have most commonly been used with
HTTP/1.1 and HTTP/2.  HTTP/1.1 has been used over a variety of
transport and session layers, while HTTP/2 has been used primarily
with TLS over TCP.  HTTP/3 supports the same semantics over a new
transport protocol, QUIC.
Paragraph (version A):
HTTP/1.1 (HTTP11) uses whitespace-delimited text fields to convey
HTTP messages.  While these exchanges are human-readable, using
whitespace for message formatting leads to parsing complexity and
excessive tolerance of variant behavior.  Because HTTP/1.x does not
include a multiplexing layer, multiple TCP connections are often used
to service requests in parallel.  However, that has a negative impact
on congestion control and network efficiency, since TCP does not
share congestion control across multiple connections.
Paragraph (version B):
HTTP/1.1 (HTTP11) uses whitespace-delimited text fields to convey
HTTP messages.  While these exchanges are human-readable, using
whitespace for message formatting leads to parsing complexity and
excessive tolerance of variant behavior.
Paragraph (version B):
Because HTTP/1.1 does not include a multiplexing layer, multiple TCP
connections are often used to service requests in parallel.  However,
that has a negative impact on congestion control and network
efficiency, since TCP does not share congestion control across
multiple connections.
Paragraph (version B):
If there are open streams that have not been explicitly closed, they
are implicitly closed when the connection is closed; see Section 10.2
of QUIC-TRANSPORT.
Draft: draft-ietf-quic-qpack

Commentary: I opted to reframe the language from HTTP/3 endpoint to decoder , since encoder and decoder instances are what this spec primarily talks about . We already say that HTTP/3 endpoints contain both an encoder and a decoder . I also a comment that encoders track the contents of the table at the decoder . I specifically did not say that they keep a full copy of the table , however ; they might not . 
 said : 
 said :
Paragraph (version A):
The dynamic table consists of a list of field lines maintained in
first-in, first-out order.  Each HTTP/3 endpoint holds a dynamic
table that is initially empty.  Entries are added by encoder
instructions received on the encoder stream; see encoder-
instructions.
Paragraph (version B):
The dynamic table consists of a list of field lines maintained in
first-in, first-out order.  A QPACK encoder and decoder share a
dynamic table that is initially empty.  The encoder adds entries to
the dynamic table and sends them to the decoder via instructions on
the encoder stream; see encoder-instructions.
Paragraph (version A):
The size of an entry is the sum of its name's length in bytes, its
value's length in bytes, and 32.  The size of an entry is calculated
using the length of its name and value without Huffman encoding
applied.
Paragraph (version B):
The size of an entry is the sum of its name's length in bytes, its
value's length in bytes, and 32 additional bytes.  The size of an
entry is calculated using the length of its name and value without
Huffman encoding applied.
Draft: draft-ietf-quic-http

Commentary: this fixes two section references ( terminology was already aligned in )
Paragraph (version A):
If an implementation wishes to advise its peer of this limit, it can
be conveyed as a number of bytes in the
SETTINGS_MAX_FIELD_SECTION_SIZE parameter.  An implementation that
has received this parameter SHOULD NOT send an HTTP message header
that exceeds the indicated size, as the peer will likely refuse to
process it.  However, an HTTP message can traverse one or more
intermediaries before reaching the origin server; see Section 3.6 of
SEMANTICS.  Because this limit is applied separately by each
implementation which processes the message, messages below this limit
are not guaranteed to be accepted.
Paragraph (version B):
If an implementation wishes to advise its peer of this limit, it can
be conveyed as a number of bytes in the
SETTINGS_MAX_FIELD_SECTION_SIZE parameter.  An implementation that
has received this parameter SHOULD NOT send an HTTP message header
that exceeds the indicated size, as the peer will likely refuse to
process it.  However, an HTTP message can traverse one or more
intermediaries before reaching the origin server; see Section 3.7 of
SEMANTICS.  Because this limit is applied separately by each
implementation which processes the message, messages below this limit
are not guaranteed to be accepted.
Paragraph (version A):
Compression can allow an attacker to recover secret data when it is
compressed in the same context as data under attacker control.
HTTP/3 enables compression of fields (header-formatting); the
following concerns also apply to the use of HTTP compressed content-
codings; see Section 8.5.1 of SEMANTICS.
Paragraph (version B):
Compression can allow an attacker to recover secret data when it is
compressed in the same context as data under attacker control.
HTTP/3 enables compression of fields (header-formatting); the
following concerns also apply to the use of HTTP compressed content-
codings; see Section 8.4.1 of SEMANTICS.
Draft: draft-ietf-quic-recovery

Commentary:   said : 
 I think the ambiguity is whether the " limited to " is saying : the maximum datagram size is no more than twice the maximum datagram size ( which is nonsensical ) the initial congestion window is min(10\maxdatagramsize ,  ( bytes , 2\maxdatagramsize ) ) Given that one of the possible interpretations is logically inconsistent , the other one must be correct . I 'm not sure how to make this sentence clearer except through pseudo - code . Looking at the pseudo - code , there is n't any -- kInitialWindow is declared to be a constant , value defined by this text , but the definition of this constant is given in terms of a variable ( maxdatagramsize ) . Maybe kInitialWindow should become a variable itself , and then have pseudo - code with the  / min relationship to B.3 ? 
 This is clearer ; thanks .
Paragraph (version A):
QUIC begins every connection in slow start with the congestion window
set to an initial value.  Endpoints SHOULD use an initial congestion
window of 10 times the maximum datagram size (max_datagram_size),
limited to the larger of 14720 bytes or twice the maximum datagram
size.  This follows the analysis and recommendations in RFC6928,
increasing the byte limit to account for the smaller 8-byte overhead
of UDP compared to the 20-byte overhead for TCP.
Paragraph (version B):
QUIC begins every connection in slow start with the congestion window
set to an initial value.  Endpoints SHOULD use an initial congestion
window of 10 times the maximum datagram size (max_datagram_size),
while limiting the window to the larger of 14720 bytes or twice the
maximum datagram size.  This follows the analysis and recommendations
in RFC6928, increasing the byte limit to account for the smaller
8-byte overhead of UDP compared to the 20-byte overhead for TCP.
Draft: draft-ietf-quic-transport

Commentary: This seems to have caused problems , so address it . 
 This text in seems to cause confusion for implementors : since it leaves it unclear what the Initial packet can be coalesced with to pad it . Specifically , some implementations use zeros or other ( random ) data , which seems to surprise some implementors . ( , which is referred to , also does n't seem to clarify this . ) 
 My understanding is that transport draft does not say anything about padding outside QUIC packet . Because a receiver is required to ignore invalid long packets , zero padding outside QUIC packet just works . So this is " OK because it is not explicitly disallowed " category . 
 I agree , but it has tripped up implementers ( again ) . I wonder if a wording can be found that does n't do that . 
 I 'd be happy to see a bit more explicit text to clarify this , since as you said , it 's come up a few times as non - obvious . 
 Maybe something like : " An Initial that is padded by coalescing could be coalesced with valid or even invalid QUIC packets ; the latter MUST be ignored as described in Section XYZ . "
Paragraph (version A):
A client MUST expand the payload of all UDP datagrams carrying
Initial packets to at least the smallest allowed maximum datagram
size of 1200 bytes by adding PADDING frames to the Initial packet or
by coalescing the Initial packet; see packet-coalesce.  Similarly, a
server MUST expand the payload of all UDP datagrams carrying ack-
eliciting Initial packets to at least the smallest allowed maximum
datagram size of 1200 bytes.  Sending UDP datagrams of this size
ensures that the network path supports a reasonable Path Maximum
Transmission Unit (PMTU), in both directions.  Additionally, a client
that expands Initial packets helps reduce the amplitude of
amplification attacks caused by server responses toward an unverified
client address; see address-validation.
Paragraph (version B):
A client MUST expand the payload of all UDP datagrams carrying
Initial packets to at least the smallest allowed maximum datagram
size of 1200 bytes by adding PADDING frames to the Initial packet or
by coalescing the Initial packet; see packet-coalesce.  Initial
packets can even be coalesced with invalid packets, which a receiver
will discard.  Similarly, a server MUST expand the payload of all UDP
datagrams carrying ack-eliciting Initial packets to at least the
smallest allowed maximum datagram size of 1200 bytes.
Paragraph (version B):
Sending UDP datagrams of this size ensures that the network path
supports a reasonable Path Maximum Transmission Unit (PMTU), in both
directions.  Additionally, a client that expands Initial packets
helps reduce the amplitude of amplification attacks caused by server
responses toward an unverified client address; see address-
validation.