jiebi/TextFlow huggingface dataset:
Original text:
When using ALPN, endpoints MUST immediately close a connection (see Section 10.2 of QUIC-TRANSPORT) with a no_application_protocol TLS <del> alert (QUIC error code 0x178; see tls-errors) if an application </del>  protocol is not negotiated.  While ALPN only specifies that servers <del> use this alert, QUIC clients MUST use error 0x178 to terminate a </del>  connection when ALPN negotiation fails. An application protocol MAY restrict the QUIC versions that it can operate over.  Servers MUST select an application protocol compatible with the QUIC version that the client has selected.  The server MUST treat the inability to select a compatible application protocol as a <del> connection error of type 0x178 (no_application_protocol).  Similarly, a client MUST treat the selection of an incompatible application protocol by a server as a connection error of type 0x178. </del>  8.2.

Reviewer comments:
One possible resolution to ; all literals are zero-padded to full bytes.
IANA made the following observation while creating the H3 registries: While the IANA copy of the registry uses two digits throughout, the QUIC draft is similarly inconsistent about whether literal hex values have any leading zeros. Is it worth updating our hex literals to use full bytes (, , etc.) or synchonizing on some other format? We probably shouldn't synchronize on trimming, since IANA has already skewed the other way.
NAME did fix this or do we need to inform IANA also?
We should probably shoot IANA an e-mail to update the registries with leading zeroes where they hadn't already assumed them.
I'll let you do that. The only registries that are affected are in HTTP/3 and QPACK.
Fixed both in the registry and the documents.
Yeah, this is easy to understand. The tables must have been annoying.

Revised text:
When using ALPN, endpoints MUST immediately close a connection (see Section 10.2 of QUIC-TRANSPORT) with a no_application_protocol TLS  <ins> alert (QUIC error code 0x0178; see tls-errors) if an application </ins> protocol is not negotiated.  While ALPN only specifies that servers  <ins> use this alert, QUIC clients MUST use error 0x0178 to terminate a </ins> connection when ALPN negotiation fails. An application protocol MAY restrict the QUIC versions that it can operate over.  Servers MUST select an application protocol compatible with the QUIC version that the client has selected.  The server MUST treat the inability to select a compatible application protocol as a  <ins> connection error of type 0x0178 (no_application_protocol). Similarly, a client MUST treat the selection of an incompatible application protocol by a server as a connection error of type 0x0178. </ins> 8.2.
Original text:
MUST send the quic_transport_parameters extension; endpoints that receive ClientHello or EncryptedExtensions messages without the quic_transport_parameters extension MUST close the connection with an <del> error of type 0x16d (equivalent to a fatal TLS missing_extension </del>  alert, see tls-errors). Transport parameters become available prior to the completion of the

Reviewer comments:
One possible resolution to ; all literals are zero-padded to full bytes.
IANA made the following observation while creating the H3 registries: While the IANA copy of the registry uses two digits throughout, the QUIC draft is similarly inconsistent about whether literal hex values have any leading zeros. Is it worth updating our hex literals to use full bytes (, , etc.) or synchonizing on some other format? We probably shouldn't synchronize on trimming, since IANA has already skewed the other way.
NAME did fix this or do we need to inform IANA also?
We should probably shoot IANA an e-mail to update the registries with leading zeroes where they hadn't already assumed them.
I'll let you do that. The only registries that are affected are in HTTP/3 and QPACK.
Fixed both in the registry and the documents.
Yeah, this is easy to understand. The tables must have been annoying.

Revised text:
MUST send the quic_transport_parameters extension; endpoints that receive ClientHello or EncryptedExtensions messages without the quic_transport_parameters extension MUST close the connection with an  <ins> error of type 0x016d (equivalent to a fatal TLS missing_extension </ins> alert, see tls-errors). Transport parameters become available prior to the completion of the
Original text:
Contains additional ranges of packets that are alternately not acknowledged (Gap) and acknowledged (ACK Range); see ack-ranges. <del> The three ECN Counts; see ack-ecn-counts. </del>  19.3.1.

Reviewer comments:
This one slipped the net.
Either way is fine by me. Just ship it already :PThanks, Martin!

Revised text:
Contains additional ranges of packets that are alternately not acknowledged (Gap) and acknowledged (ACK Range); see ack-ranges.  <ins> The three ECN counts; see ack-ecn-counts. </ins> 19.3.1.
Original text:
The ACK frame uses the least significant bit of the type value (that is, type 0x03) to indicate ECN feedback and report receipt of QUIC packets with associated ECN codepoints of ECT(0), ECT(1), or ECN-CE <del> in the packet's IP header.  ECN Counts are only present when the ACK </del>  frame type is 0x03. When present, there are three ECN counts, as shown in ecn-count- format. <del> The three ECN Counts are: </del>  A variable-length integer representing the total number of packets received with the ECT(0) codepoint in the packet number space of

Reviewer comments:
This one slipped the net.
Either way is fine by me. Just ship it already :PThanks, Martin!

Revised text:
The ACK frame uses the least significant bit of the type value (that is, type 0x03) to indicate ECN feedback and report receipt of QUIC packets with associated ECN codepoints of ECT(0), ECT(1), or ECN-CE  <ins> in the packet's IP header.  ECN counts are only present when the ACK </ins> frame type is 0x03. When present, there are three ECN counts, as shown in ecn-count- format.  <ins> The ECN count fields are: </ins> A variable-length integer representing the total number of packets received with the ECT(0) codepoint in the packet number space of
Original text:
7.2.5. The frame (type=0x05) is used to carry a promised request header <del> section from server to client on a , as in HTTP/2. </del>  The payload consists of:

Reviewer comments:
Removed one HTTP/2 reference which seems extraneous, and corrected the polarity of another. This by doing almost nothing; speak now if you think more is warranted.
RFC Editor says: But fair enough -- are we overdoing it?
Having looked at the references, they all seem reasonable with the possible exception of PUSH_PROMISE noting it behaves "as in HTTP/2." Most references to HTTP/2 occur either in the first two sections of the document or in the Appendix which specifically discusses the relationship between HTTP/2 and HTTP/3. removes that one extraneous reference. Other than than, I plan to make no further changes to address this feedback unless someone wants to provide a more concrete list of places where the comparison is unnecessary.
Marginal: Section 4.1.1 and 4.1.1.1 seems to have some egregious use of phrasing similar to "Like HTTP/2, ..." or "as in HTTP/2". You could possibly condense these to a sentence such as "Like HTTP/2, HTTP/3 has additional considerations related to use of characters in field names, the Connect header field, and pseudo-header fields". That could be inserted into to thefirst para of 4.1.1, or the second para (thus breaking the para so the next one starts with "Characters in field names").
Fixed in .

Revised text:
7.2.5. The frame (type=0x05) is used to carry a promised request header  <ins> section from server to client on a . </ins> The payload consists of:
Original text:
The QUIC transport protocol (QUIC-TRANSPORT) is designed to support HTTP semantics, and its design subsumes many of the features of <del> HTTP/2 (RFC7540).  HTTP/2 uses HPACK (RFC7541) for compression of the header and trailer sections.  If HPACK were used for HTTP/3 (HTTP3), it would induce head-of-line blocking for field sections due to built-in assumptions of a total ordering across frames on all </del>  streams. QPACK reuses core concepts from HPACK, but is redesigned to allow

Reviewer comments:
These track corrections I've asked the RFC Editor to make directly in their copy prior to publication. It appears that some http-core sections moved since the last time we did a full sweep of our references.

Revised text:
The QUIC transport protocol (QUIC-TRANSPORT) is designed to support HTTP semantics, and its design subsumes many of the features of  <ins> HTTP/2 (RFC9113).  HTTP/2 uses HPACK (RFC7541) for compression of the header and trailer sections.  If HPACK were used for HTTP/3 (RFC9114), it would induce head-of-line blocking for field sections due to built-in assumptions of a total ordering across frames on all </ins> streams. QPACK reuses core concepts from HPACK, but is redesigned to allow
Original text:
fields; this document uses "fields" for generality. A name-value pair sent as part of an HTTP field section.  See <del> Sections 6.3 and 6.5 of SEMANTICS. </del>  Data associated with a field name, composed from all field line values with that field name in that section, concatenated together

Reviewer comments:
These track corrections I've asked the RFC Editor to make directly in their copy prior to publication. It appears that some http-core sections moved since the last time we did a full sweep of our references.

Revised text:
fields; this document uses "fields" for generality. A name-value pair sent as part of an HTTP field section.  See  <ins> Sections 6.3 and 6.5 of RFC9110. </ins> Data associated with a field name, composed from all field line values with that field name in that section, concatenated together
Original text:
8. This document makes multiple registrations in the registries defined <del> by HTTP3.  The allocations created by this document are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). </del>  8.1. This document specifies two settings.  The entries in the following table are registered in the "HTTP/3 Settings" registry established in <del> HTTP3. </del>  For formatting reasons, the setting names here are abbreviated by removing the 'SETTINGS_' prefix.

Reviewer comments:
These track corrections I've asked the RFC Editor to make directly in their copy prior to publication. It appears that some http-core sections moved since the last time we did a full sweep of our references.

Revised text:
8. This document makes multiple registrations in the registries defined  <ins> by RFC9114.  The allocations created by this document are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). </ins> 8.1. This document specifies two settings.  The entries in the following table are registered in the "HTTP/3 Settings" registry established in  <ins> RFC9114. </ins> For formatting reasons, the setting names here are abbreviated by removing the 'SETTINGS_' prefix.
Original text:
This document specifies two stream types.  The entries in the following table are registered in the "HTTP/3 Stream Types" registry <del> established in HTTP3. </del>  8.3. This document specifies three error codes.  The entries in the following table are registered in the "HTTP/3 Error Codes" registry <del> established in HTTP3. </del> 

Reviewer comments:
These track corrections I've asked the RFC Editor to make directly in their copy prior to publication. It appears that some http-core sections moved since the last time we did a full sweep of our references.

Revised text:
This document specifies two stream types.  The entries in the following table are registered in the "HTTP/3 Stream Types" registry  <ins> established in RFC9114. </ins> 8.3. This document specifies three error codes.  The entries in the following table are registered in the "HTTP/3 Error Codes" registry  <ins> established in RFC9114. </ins>
Original text:
This document defines two new DATAGRAM QUIC frame types, which carry application data without requiring retransmissions.  Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org [3] or on the GitHub repository which contains the draft: https://github.com/quicwg/datagram [4].

Reviewer comments:
Some applications might want to send messages, and not care about the order of delivery, but still get reliability. QUIC streams give them reliability, but within a stream it enforces order of delivery. This datagram proposal gives unordered delivery of messages, but without reliability. Why not provide datagrams with optional (opt-in) reliability? It shouldn't be a lot of extra work for QUIC implementors to provide reliable datagrams as well as unreliable, given that retransmission is already there for QUIC streams. (I guess an application could create a separate QUIC stream for each unordered reliable message. That might work, but seems ugly and may have some overhead.)
What you describe can already be accomplished using streams: each “reliable datagram” is its own stream. That provides reliable delivery without ordering between independent datagrams. I don’t think we need to add optional reliability to the datagram spec.
Streams are very lightweight, and well suited to this task. Beware applying intuition from TCP too heavily.
So, here's a suggestion then: since I'm sure I'm not the only person who is going to think of this, maybe add some verbiage to the spec explaining why supporting reliable datagrams is unnecessary?
Sounds good. We can keep this issue open as requesting an editorial change.

Revised text:
This document defines two new DATAGRAM QUIC frame types, which carry application data without requiring retransmissions. <ins> Note that DATAGRAM frames are only meant for unreliable transmissions.  Reliable transmission is already supported by QUIC via STREAM frames. </ins> Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org [3] or on the GitHub repository which contains the draft: https://github.com/quicwg/datagram [4].
Original text:
7.  This document registers a new value in the QUIC Transport Parameter <del> Registry: </del>  <del> 0x0020 (if this document is approved) </del>  max_datagram_frame_size <del> A non-zero value indicates that the endpoint supports receiving unreliable DATAGRAM frames.  An endpoint that advertises this transport parameter can receive DATAGRAM frames from the other endpoint, up to and including the length in bytes provided in the transport parameter.  The default value is 0. </del>  <del> This document also registers a new value in the QUIC Frame Type registry: </del>  0x30 and 0x31 (if this document is approved) DATAGRAM <del> Unreliable application data </del>  8.

Reviewer comments:
The IANA section was added before the QUIC registries had a notion of permanent vs provisional, and we then forgot to update it. This PR fixes that oversight.
Latest change looks good to me
Noticed during Shepherd review. All of the core types registered in RFC 9000 simply link to the relevant document (RFC 9000) and section in the document where the protocol element is defined. In contrast, in datagram's IANA considerations section, the transport parameter and frame type registrations include the required field with some text that is already included in the document. This will manifest as a weird juxtaposition in the IANA table. I suggest you simply reference the section 3 and section 4 respectively. If you really want some prose (I don't recommend that) then it can be added as a note to the table.
I noticed that when writing and I agree, we should just list "This specification" in there as most RFCs do.
Noticed during the shepherd writeup of IANA considerations: The document is attempting to register: maxdatagramframe_size Transport Parameter with value 0x0020 DATAGRAM frame type with values 0x30 and 0x31 According to IANA (URL) registrations can be of different types. Here the requested values are in the bracket. So I suggest that the document state clearly that this is a request for permanent registration of these types.
Agreed. Wrote up to fix this.
LGTM, thanks!

Revised text:
7. <ins> 7.1. </ins> This document registers a new value in the QUIC Transport Parameter  <ins> Registry maintained at <https://www.iana.org/assignments/quic/ quic.xhtml#quic-transport>. </ins>  <ins> 0x20 (if this document is approved) </ins> max_datagram_frame_size  <ins> permanent This document </ins>  <ins> 7.2. This document registers two new values in the QUIC Frame Type registry maintained at <https://www.iana.org/assignments/quic/ quic.xhtml#quic-frame-types>. </ins> 0x30 and 0x31 (if this document is approved) DATAGRAM  <ins> permanent This document </ins> 8.
Original text:
extension parameters: To avoid clashes, implementers SHOULD prefix unregistered parameters <del> with an "x-<vendor>" identifier, e.g. "x-acme-policy", "x-acme- burst".  While it is useful to define a clear syntax and semantics even for custom parameters, it is important to note that user agents are not required to process quota policy information. </del>  2.2.

Reviewer comments:
See .
iirc there was a discussion on stuff. In general I'm ok with just NAME do you see any issue with that?
No issue, I was aware of the BCP and I think this case fits the first provision for segregating the name spaces in the Appendix B, so any one of the proposed solutions there, including yours, is fine with me.

Revised text:
extension parameters: To avoid clashes, implementers SHOULD prefix unregistered parameters  <ins> with a vendor identifier, e.g. "acme-policy", "acme-burst".  While it is useful to define a clear syntax and semantics even for custom parameters, it is important to note that user agents are not required to process quota policy information. </ins> 2.2.
Original text:
references) and are matched against a resolved link target.  Queries for endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in URI form otherwise; the RD SHOULD recognize <del> either. </del>  Endpoints that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource

Reviewer comments:
Closes: URL
In the lookup filtering description, we talk about how href can be queried for (that it only applies in the URI form), but say nothing about anchor (to which the same applies in principle, with slightly different statements about application to the endpoints). Thanks Christer for pointing that out. As RFC6690 contains a lookup example for ?anchor=, we may want to add one here as well.

Revised text:
references) and are matched against a resolved link target.  Queries for endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in URI form otherwise; the RD SHOULD recognize  <ins> either.  The "anchor" attribute is usable for resource lookups, and, if queried, MUST be for in URI form as well. </ins> Endpoints that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource
Original text:
registration if it were not to be used in lookup or attributes, but would make a bad parameter for lookup, because a resource lookup with an "if" query parameter could ambiguously filter by the registered <del> endpoint property or the RFC6690 target attribute).  It is expected that the registry will receive between 5 and 50 registrations in total over the next years. </del>  9.3.1.

Reviewer comments:
Something around "whether many registrations are expected over time" is supposed to be said according to BCP26, but it seems this belongs in the shepherd write-up, where it is now being added. To be merged right away.

Revised text:
registration if it were not to be used in lookup or attributes, but would make a bad parameter for lookup, because a resource lookup with an "if" query parameter could ambiguously filter by the registered  <ins> endpoint property or the RFC6690 target attribute). </ins> 9.3.1.
Original text:
Changed the lookup interface to accept endpoint and Domain as query string parameters to control the scope of a lookup. 

Reviewer comments:
... as promised for yesterday (oops)
ad "what is sub": it's DNS-SD's syntax for subtypes (RFC6763 Section 7.1). Might also be URL ("Subtype strings are not required to begin with an underscore, though they often do").
Looks good to me.
There are several ways specified for finding a host serving an RD: static (unicast or anycast, addresses or DNS? could contain full RD path (as in LWM2M)?) various neighbor discovery derived RDAO the border router (ABRO) "other ND options that happen to point to servers (such as RDNSS)" might-be-defined DHCPv6 options multicast (all-coap-nodes + .well-known/core; serves the path by design) There is an open issue to describe how this can be used with DNS-SD (), and it came up 2017-04-07 that discovery via mDNS by those mechanisms might be possible but is not advisable. Can we give a set of discovery options that should be supported by all general-purpose clients and servers to avoid fragmentation where one vendor's clients expect an RDAO while the other vendor's server relies on clients doing a multicast? Can we say anything about which options are recommended to use, and which are rather to be viewed as shortcuts in extremely constrained cases? Using RDNSS would be a candidate for such a statement. Maybe those cases are better described as "explicitly configured to use whichever RDNSS is announced", so this is something that's better than static configuration but still not to be expected from a generic client.
The new section 4 introduced in URL takes care of this.

Revised text:
Changed the lookup interface to accept endpoint and Domain as query string parameters to control the scope of a lookup. <ins> Editorial Comments [_1] cabo: What is _sub here? </ins>
Original text:
Internet Backbone: If a censor controls the gateways into a region, they can filter undesirable traffic that is traveling into and out of the region by sniffing and mirroring at the relevant <del> exchange points.  Censorship at this point-of-control is most </del>  effective at controlling the flow of information between a region and the rest of the Internet, but is ineffective at identifying content traveling between the users within a region. Internet Service Providers: Internet Service Providers are perhaps <del> the most natural point-of-control.  They have a benefit of being </del>  easily enumerable by a censor paired with the ability to identify the regional and international traffic of all their users.  The censor's filtration mechanisms can be placed on an ISP via

Reviewer comments:
From Stephane:
Shouldn't the CA / cert hierarchy be a point of control? For example, KZ is requiring users to install their CA, to allow them to MITM all traffic: URL Another example of CA abuse is ROA whacking, RPKI manipulation, etc.: URL
Also got this feedback from Will Scott:

Revised text:
Internet Backbone: If a censor controls the gateways into a region, they can filter undesirable traffic that is traveling into and out of the region by sniffing and mirroring at the relevant  <ins> exchange points.  Censorship at this point of control is most </ins> effective at controlling the flow of information between a region and the rest of the Internet, but is ineffective at identifying content traveling between the users within a region. Internet Service Providers: Internet Service Providers are perhaps  <ins> the most natural point of control.  They have a benefit of being </ins> easily enumerable by a censor paired with the ability to identify the regional and international traffic of all their users.  The censor's filtration mechanisms can be placed on an ISP via