jiebi/TextFlow huggingface dataset:
Original text:
Certificate Types is too strict.  Based on WG consensus, the decision was taken to change registration policy to Specification Required RFC8126 while reserving a small part of the code space for <del> experimental and private use.  Therefore, IANA [SHALL add/has added] a "Recommended" column to the registry.  X.509 and Raw Public Key are "Yes".  All others are "No".  In order to register an extension with the value "Yes", a Standards Track document RFC8126 is REQUIRED. Future Certificate Types MUST define the value of this column.  A Standards Track document RFC8126 is REQUIRED to register an entry with the value "Yes".  IESG Approval is REQUIRED for a Yes->No transition. </del>  See expert-pool for additional information about the designated expert pool.

Reviewer comments:
Looks good
I think the TLS Certificate Type section should explicitly list the values for which "specification required" applies (and for which "reserved for private use" continues to apply).

Revised text:
Certificate Types is too strict.  Based on WG consensus, the decision was taken to change registration policy to Specification Required RFC8126 while reserving a small part of the code space for  <ins> experimental and private use.  Therefore, IANA [SHALL change/has changed] the TLS Certificate Types regisry to: Change the registry policy to: Values with the first byte in the range 0-223 (decimal) are assigned via Specification Required RFC8126.  Values with the first byte 224-255 (decimal) are reserved for Private Use RFC8126. Add a "Recommended" column to the registry.  X.509 and Raw Public Key are "Yes".  All others are "No".  In order to register an extension with the value "Yes", a Standards Track document RFC8126 is REQUIRED.  Future Certificate Types MUST define the value of this column.  A Standards Track document RFC8126 is REQUIRED to register an entry with the value "Yes".  IESG Approval is REQUIRED for a Yes->No transition. </ins> See expert-pool for additional information about the designated expert pool.
Original text:
RFC5246 and TLS SignatureAlgorithm registries RFC5246: The values in this registry are only applicable to (D)TLS protocol <del> versions prior to 1.3. </del>  [SHALL update/has updated] the "Reference" field in the TLS Compression Method Identifiers, TLS HashAlgorithm and TLS

Reviewer comments:
An open issue was whether to close the HashAlgorithms and SignatureAlgorithms registries or just reserve the values and point to the new 1.3 schemes. WRT opening a closed registry, IANA told me that opening a closed registry required another RFC or if we put in the IANA considerations section IESG Approval. With that info and the fact that at least one person was like "woah wait I might need to register some algorithms for TLS1.2", I don’t really see the point in closing the registry so I propose that we leave it as is, but that we update the text as noted in the PR to explicit point to the SignatureScheme registry.
I think that reserving them is the right thing for now. TLS 1.2 and earlier will take a while to disappear, so the ability to assign more values if there is a huge surprise seems prudent.
NAME PTAL

Revised text:
RFC5246 and TLS SignatureAlgorithm registries RFC5246: The values in this registry are only applicable to (D)TLS protocol  <ins> versions prior to 1.3.  (D)TLS 1.3 and later versions' values are registered in the TLS SignatureScheme registry. </ins> [SHALL update/has updated] the "Reference" field in the TLS Compression Method Identifiers, TLS HashAlgorithm and TLS
Original text:
potential for brute-force attack.  Further, in 2017, researchers from Google and CWI Amsterdam SHA-1-Collision proved SHA-1 collision attacks were practical.  This document updates RFC5246 and RFC7525 in <del> such as way that MD5 and SHA1 MUST NOT be used for digital </del>  signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection.

Reviewer comments:
SHA-1 is spelled everywhere as "SHA-1", it's the only instance of "SHA1" change it so that it is consistent

Revised text:
potential for brute-force attack.  Further, in 2017, researchers from Google and CWI Amsterdam SHA-1-Collision proved SHA-1 collision attacks were practical.  This document updates RFC5246 and RFC7525 in  <ins> such as way that MD5 and SHA-1 MUST NOT be used for digital </ins> signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection.
Original text:
<del> Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 </del>  draft-ietf-tls-md5-sha1-deprecate-07 Abstract

Reviewer comments:
Addresses , , and .
Replace Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 with Deprecating MD5 and SHA-1 signature hashes in (D)TLS 1.2
Add the following to the WANG reference: URL Replace: URL with URL and URL with URL
replace Dell with CIS/Center for Internet Security (CIS)

Revised text:
 <ins> Deprecating MD5 and SHA-1 signature hashes in (D)TLS 1.2 </ins> draft-ietf-tls-md5-sha1-deprecate-07 Abstract
Original text:
attacks were practical.  This document updates RFC5246 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. <del> Note that the CABF has also deprecated use of SHA-1 CABF. </del>  1.1.

Reviewer comments:
 We might say that the CABF action was deprecation for use in certificate signatures (not that CABF is likely to be concerned about other uses of SHA1, of course). I don't see much harm in adding "illegal_parameter" to the list of allowed alerts here, as Hubert proposed.  It's otherwise the natural thing to do if an algorithm is received in CertificateVerify that was not advertised in the signature algorithms extension. Sean's proposal at https://mailarchive.ietf.org/arch/msg/tls/rSbXvNPhmr27z0HOBzwv6x0j1mI/ (which makes "illegal_parameter" the only alert) seems like it ought to work.

Revised text:
attacks were practical.  This document updates RFC5246 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection.  <ins> Note that the CABF has also deprecated use of SHA-1 for use in certificate signatures CABF. </ins> 1.1.
Original text:
Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange message. If client does receive a MD5 or SHA-1 signature in the <del> ServerKeyExchange message it MUST abort the connection with handshake_failure or insufficient_security alert. </del>  5.

Reviewer comments:
replying with handshakefailure when server breaks protocol invariants isn't a good idea, make the behaviour conditional on values in signaturealgorithms (since this is the normal behaviour a client should exhibit when a signature algorithm is disabled, this does not actually increase complexity of the implementation)

Revised text:
Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange message. If client does receive a MD5 or SHA-1 signature in the  <ins> ServerKeyExchange message and it sent one in signature_algorithms extensions it MUST abort the connection with handshake_failure or insufficient_security alert.  If client did not send MD5 nor SHA-1 hash algorithm in signature_algorithms extension and it receives a MD5 or SHA-1 signature in the ServerKeyExchange it MUST abort the connection with the illegal_parameter alert. </ins> 5.
Original text:
on the underlying hash constructions Transcript-Collision.  Further, in 2017, researchers from Google and CWI Amsterdam SHA-1-Collision proved SHA-1 collision attacks were practical.  This document updates <del> RFC5246 and RFC7525 in such as way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. </del>  1.1. 2. <del> Clients SHOULD NOT include MD5 and SHA-1 in the signature_algorithms </del>  extension.  If a client does not send a signature_algorithms extension, then the server MUST abort the handshake and send a handshake_failure alert, except when digital signatures are not used 3. Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest <del> message. </del>  4. <del> Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange message. If client does receive a MD5 or SHA-1 signature in the ServerKeyExchange message and it sent one in signature_algorithms extensions it MUST abort the connection with handshake_failure or insufficient_security alert.  If client did not send MD5 nor SHA-1 hash algorithm in signature_algorithms extension and it receives a MD5 or SHA-1 signature in the ServerKeyExchange it MUST abort the connection with the illegal_parameter alert. </del>  5. <del> Clients MUST NOT include MD5 and SHA-1 in CertificateVerify message. If the server receives a CertificateVerify message with MD5 or SHA-1 it MUST abort the connection with handshake_failure or </del>  insufficient_security alert. 6.

Reviewer comments:
As per discussion on mailing list.
NAME can you please float this change on the mailing list?

Revised text:
on the underlying hash constructions Transcript-Collision.  Further, in 2017, researchers from Google and CWI Amsterdam SHA-1-Collision proved SHA-1 collision attacks were practical.  This document updates  <ins> RFC5246 and RFC7525 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. </ins> 1.1. 2.  <ins> Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms </ins> extension.  If a client does not send a signature_algorithms extension, then the server MUST abort the handshake and send a handshake_failure alert, except when digital signatures are not used 3. Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest  <ins> messages. </ins> 4.  <ins> Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages. If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange message it MUST abort the connection with the illegal_parameter alert. </ins> 5.  <ins> Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages. If a server receives a CertificateVerify message with MD5 or SHA-1 it MUST abort the connection with handshake_failure or </ins> insufficient_security alert. 6.
Original text:
discard any additional tickets.  Servers SHOULD additionally place a limit on the number of tickets they are willing to send, to save resources.  Therefore, the number of NewSessionTicket messages sent <del> will be the minimum of the server's self-imposed limit and </del>  TicketRequestContents.count. Servers that support ticket requests MUST NOT echo "ticket_request"

Reviewer comments:
I don't think any of this paragraph should have 2119 language in it. But, even overlooking that minor disagreement, it's important to avoid unintentional requirements. I think my edit guides well-meaning implementors, while making no guarantees.
This editorial change is fine by me.

Revised text:
discard any additional tickets.  Servers SHOULD additionally place a limit on the number of tickets they are willing to send, to save resources.  Therefore, the number of NewSessionTicket messages sent  <ins> will typically be the minimum of the server's self-imposed limit and </ins> TicketRequestContents.count. Servers that support ticket requests MUST NOT echo "ticket_request"
Original text:
dispose of pooled tickets after some reasonable amount of time that mimics the ticket rotation period.  Servers that do not enforce a limit on the number of NewSessionTicket messages sent in response to a "ticket_request" extension could leave themselves open to DoS attacks, especially if ticket creation is

Reviewer comments:
Adding the text proposed in the email
Unless I am missing something, I believe that checking the IP address may be useful to filter packets that are outside the key exchange, but I do not see this as a counter measure to the amplification attack. With a single round trip, unless i am missing something, I do not see how the server can verify the Client's IP address. It receives the ClientHello responds with the ServerHello..Finished,NewSessionTickets. In other cases, the server received from the given IP address the ClientHello and the client Finished which I think proves that IP receives the the ServerHello and responds to it. Yours, Daniel
TLS has a cookie extension for this purpose, for example.
Thanks, looks good to me. Yours, Daniel
I agree with the change below and updated the text. OLD: Server should limit the number of NewSessionTicket messages sent in response to a "ticket_request" should be based on the applicability and the amplification factor of such attack. NEW Servers SHOULD limit the number of NewSessionTicket messages they send until they have verified the client's ownership of its IP address.
Great! We're just waiting on NAME
Approved pending Chris' last suggestion

Revised text:
dispose of pooled tickets after some reasonable amount of time that mimics the ticket rotation period. <ins> In some cases, a server may send NewSessionTicket messages immediately upon sending the server Finished message rather than waiting for the client Finished.  If the server has not verified the client's ownership of its IP address, e.g., with the TLS Cookie extension (see RFC8446; Section 4.2.2), an attacker may take advantage of this behavior to create an amplification attack proportional to the count value toward a target by performing a key exchange over UDP with spoofed packets.  Servers SHOULD limit the number of NewSessionTicket messages they send until they have verified the client's ownership of its IP address. </ins> Servers that do not enforce a limit on the number of NewSessionTicket messages sent in response to a "ticket_request" extension could leave themselves open to DoS attacks, especially if ticket creation is
Original text:
Examples of TLS 1.3 handshakes are shown.  Private keys and inputs are provided so that these handshakes might be reproduced. <del> Intermediate values, including secrets, traffic keys and ivs are </del>  shown so that implementations might be checked incrementally against these values. 1. <del> TLS 1.3 TLS13 defines a new key schedule and a number new </del>  cryptographic operations.  This document includes sample handshakes that show all intermediate values.  This allows an implementation to be verified incrementally, examining inputs and outputs of each In this example, the simplest possible handshake is completed.  The server is authenticated, but the client remains anonymous.  After connecting, a few application data octets are exchanged.  The server <del> sends a session ticket that permits the use of 0-RTT in any resumed session. </del> 

Reviewer comments:
"IV" is usually capitalized, and a couple of grammar nits. I couldn't figure out what "PRK" meant in the (generated) output; should that be expanded?
I think Sean had tried to clue me in a while ago, but I only just now realized, that it would be nice if this one could be in the same cluster as the core spec, but doing that (basically) requires going through IETF LC/etc. while the test vectors are still for a draft version. So I'd like to kick things off soon and we can see how long it takes. Please do drop a new rev, though; no need to have genart pester us again.

Revised text:
Examples of TLS 1.3 handshakes are shown.  Private keys and inputs are provided so that these handshakes might be reproduced.  <ins> Intermediate values, including secrets, traffic keys and IVs are </ins> shown so that implementations might be checked incrementally against these values. 1.  <ins> TLS 1.3 TLS13 defines a new key schedule and a number of new </ins> cryptographic operations.  This document includes sample handshakes that show all intermediate values.  This allows an implementation to be verified incrementally, examining inputs and outputs of each In this example, the simplest possible handshake is completed.  The server is authenticated, but the client remains anonymous.  After connecting, a few application data octets are exchanged.  The server  <ins> sends a session ticket that permits the use of 0-RTT data in any resumed session. </ins>
Original text:
multiplex HTTP requests over a QUIC connection.  This document defines a mechanism for multiplexing non-HTTP data with HTTP/3 in a manner that conforms with the WebTransport protocol requirements and <del> semantics OVERVIEW.  Using the mechanism described here, multiple </del>  WebTransport instances can be multiplexed simultaneously with regular HTTP traffic on the same HTTP/3 connection.

Reviewer comments:
Noticed we had a few oddly long lines, so I hit the rewrap button.
This was Sublime, but many others will attempt to do the same :)
What tool do you use that has a rewrap button?

Revised text:
multiplex HTTP requests over a QUIC connection.  This document defines a mechanism for multiplexing non-HTTP data with HTTP/3 in a manner that conforms with the WebTransport protocol requirements and  <ins> semanticsOVERVIEW.  Using the mechanism described here, multiple </ins> WebTransport instances can be multiplexed simultaneously with regular HTTP traffic on the same HTTP/3 connection.
Original text:
from the one used by the server. In addition to the setting above, the server MUST send a <del> SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter indicating the maximum </del>  number of concurrent sessions it is willing to receive.  The default <del> value for the SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter is "0", </del>  meaning that the server is not willing to receive any WebTransport sessions. 3.4. <del> This document defines a SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter </del>  that allows the server to limit the maximum number of concurrent WebTransport sessions on a single HTTP/3 connection.  The client MUST NOT open more sessions than indicated in the server SETTINGS

Reviewer comments:
Fix up references to setting names
The draft uses both but I presume they refer to the same thing, so lets pick one.
Ah, left over from a previous change, I believe. is the correct form, can update to match.
Yep sgtm

Revised text:
from the one used by the server. In addition to the setting above, the server MUST send a  <ins> SETTINGS_WEBTRANSPORT_MAX_SESSIONS parameter indicating the maximum </ins> number of concurrent sessions it is willing to receive.  The default  <ins> value for the SETTINGS_WEBTRANSPORT_MAX_SESSIONS parameter is "0", </ins> meaning that the server is not willing to receive any WebTransport sessions. 3.4.  <ins> This document defines a SETTINGS_WEBTRANSPORT_MAX_SESSIONS parameter </ins> that allows the server to limit the maximum number of concurrent WebTransport sessions on a single HTTP/3 connection.  The client MUST NOT open more sessions than indicated in the server SETTINGS
Original text:
WebTransport server associated with the specified ":authority" and ":path" values.  If it does not, it SHOULD reply with status code 404 (Section 6.5.4, RFC7231).  If it does, it MAY accept the session by <del> replying with status code 200.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. </del>  From the client's perspective, a WebTransport session is established <del> when the client receives a 200 response.  From the server's perspective, a session is established once it sends a 200 response. </del>  WebTransport over HTTP/3 does not support 0-RTT. 3.4.

Reviewer comments:
This makes our behavior consistent with the regular CONNECT method.
The spec currently explicitly requires . suggests that any 2xx code should work. Should we change the text accordingly?
I'd suggest server MUST send 200 and client MUST accept any 2XX. That way future extensions can apply meaning to other 2XX codes.
What would happen if we require client to reject 2xx other than 200?

Revised text:
WebTransport server associated with the specified ":authority" and ":path" values.  If it does not, it SHOULD reply with status code 404 (Section 6.5.4, RFC7231).  If it does, it MAY accept the session by  <ins> replying with a 2xx series status code, as defined in Section 15.3 of SEMANTICS.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. </ins> From the client's perspective, a WebTransport session is established  <ins> when the client receives a 2xx response.  From the server's perspective, a session is established once it sends a 2xx response. </ins> WebTransport over HTTP/3 does not support 0-RTT. 3.4.
Original text:
Both client and server can create a unidirectional stream using a special stream type. <del> A datagram can be sent using a QUIC DATAGRAM frame QUIC-DATAGRAM. </del>  An WebTransport session is terminated when the CONNECT stream that created it is closed. may be using a version of WebTransport extension that is different from the one used by the server. <del> If SETTINGS_ENABLE_WEBTRANSPORT is negotiated, support for the QUIC DATAGRAMs within HTTP/3 MUST be negotiated as described in HTTP3-DATAGRAM; negotiating WebTransport support without negotiating HTTP/3 DATAGRAM support SHALL result in a H3_SETTINGS_ERROR error. </del> 3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by perspective, a session is established once it sends a 2xx response. WebTransport over HTTP/3 does not support 0-RTT.  3.4. From the flow control perspective, WebTransport sessions count 4.4. <del> Datagrams can be sent using the DATAGRAM frame as defined in QUIC- DATAGRAM and HTTP3-DATAGRAM.  For all HTTP/3 connections in which the SETTINGS_ENABLE_WEBTRANSPORT option is negotiated, the Flow Identifier is set to the session ID.  In other words, the format of datagrams SHALL be the session ID, followed by the user-specified payload (fig-datagram). </del>  In QUIC, a datagram frame can span at most one packet.  Because of that, the applications have to know the maximum size of the datagram WebTransport application error codes. This document. 

Reviewer comments:
This PR keeps WebTransport in sync with the latest changes in draft-ietf-masque-h3-datagram.

Revised text:
Both client and server can create a unidirectional stream using a special stream type.  <ins> A datagram can be sent using HTTP Datagrams HTTP-DATAGRAM. </ins> An WebTransport session is terminated when the CONNECT stream that created it is closed. may be using a version of WebTransport extension that is different from the one used by the server.  3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by perspective, a session is established once it sends a 2xx response. WebTransport over HTTP/3 does not support 0-RTT. <ins> The "webtransport" HTTP Upgrade Token uses the Capsule Protocol as defined in HTTP-DATAGRAM. </ins> 3.4. From the flow control perspective, WebTransport sessions count 4.4.  <ins> Datagrams can be sent using HTTP Datagrams, using the WEB_TRANSPORT HTTP Datagram Format Type (see value in iana-format-type).  When using the WEB_TRANSPORT HTTP Datagram Format Type, the WebTransport datagram payload is sent unmodified in the "HTTP Datagram Payload" field of an HTTP Datagram.  When sending a registration capsule using the "Datagram Format Type" set to WEB_TRANSPORT, the "Datagram Format Additional Data" field SHALL be empty. </ins> In QUIC, a datagram frame can span at most one packet.  Because of that, the applications have to know the maximum size of the datagram WebTransport application error codes. This document. <ins> 7.6. This document will request IANA to register WEB_TRANSPORT in the "HTTP Datagram Format Types" registry established by HTTP-DATAGRAM. </ins>