jiebi/TextFlow huggingface dataset:
Original text:
CertificateVerify and Finished messages. HTTP/2 restricts TLS 1.2 renegotiation (RFC9113) and prohibits TLS <del> 1.3 post-handshake authentication RFC8740.  However, they are </del>  sometimes used to implement reactive client certificate authentication in HTTP/1.1 RFC9112 where the server decides whether to request a client certificate based on the HTTP request.  HTTP

Reviewer comments:
correcting: The reference to RFC8740 is obsoleted by RFC9113 There are two separate references to RFC5246, once as "RFC5246" and once as "TLS1.2".

Revised text:
CertificateVerify and Finished messages. HTTP/2 restricts TLS 1.2 renegotiation (RFC9113) and prohibits TLS  <ins> 1.3 post-handshake authentication (RFC9113).  However, they are </ins> sometimes used to implement reactive client certificate authentication in HTTP/1.1 RFC9112 where the server decides whether to request a client certificate based on the HTTP request.  HTTP
Original text:
enabled. A TTRP negotiates the use of a mutually-authenticated TLS connection <del> with the client, such as is described in TLS or RFC5246, and validates the client certificate per its policy and trusted certificate authorities.  Each HTTP request on the underlying TLS connection are dispatched to the origin server with the following modifications: </del>  The client certificate is placed in the "Client-Cert" header field of the dispatched request, as described in header.

Reviewer comments:
correcting: The reference to RFC8740 is obsoleted by RFC9113 There are two separate references to RFC5246, once as "RFC5246" and once as "TLS1.2".

Revised text:
enabled. A TTRP negotiates the use of a mutually-authenticated TLS connection  <ins> with the client, such as is described in TLS or TLS1.2, and validates the client certificate per its policy and trusted certificate authorities.  Each HTTP request on the underlying TLS connection are dispatched to the origin server with the following modifications: </ins> The client certificate is placed in the "Client-Cert" header field of the dispatched request, as described in header.
Original text:
indicates that proxy.example.net, which used the IP address "2001:db8::1" as the next hop for this request, encountered the <del> CNAMEs "tracker.example.com." and "service1.example-cdn.com" in the </del>  DNS resolution chain.  Note that while this example includes both the "next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can be included without including "next-hop".

Reviewer comments:
The draft currently has this example: I'd suggest always omitting trailing dots since it's clear that these names will be FQDNs, i.e.:

Revised text:
indicates that proxy.example.net, which used the IP address "2001:db8::1" as the next hop for this request, encountered the  <ins> CNAMEs "tracker.example.com" and "service1.example-cdn.com" in the </ins> DNS resolution chain.  Note that while this example includes both the "next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can be included without including "next-hop".
Original text:
1. Existing RFCs define extensions to HTTP/2 HTTP2 which remain useful <del> in HTTP/3.  Section A.2.3 of HTTP3 describes the required updates for HTTP/2 frames to be used with HTTP/3. </del>  ORIGIN defines the HTTP/2 ORIGIN frame, which indicates what origins are available on a given connection.  It defines a single HTTP/2 frame type.  2. The ORIGIN HTTP/3 frame allows a server to indicate what origin(s) (RFC6454) the server would like the client to consider as members of <del> the Origin Set (Section 2.3 of ORIGIN) for the connection within which it occurs. </del>  The semantics of the frame payload are identical to those of the HTTP/2 frame defined in ORIGIN.  Where HTTP/2 reserves Stream 0 for

Reviewer comments:
NAME Adds the BCP14 boilerplate in a Notation Conventions section. As part of that, I noticed we don't reference any explanation of the frame layout language used -- it's the same used in QUIC and HTTP/3 -- so I added an RFC 9000 ref to pick that up in the same section.

Revised text:
1. Existing RFCs define extensions to HTTP/2 HTTP2 which remain useful  <ins> in HTTP/3.  HTTP3 describes the required updates for HTTP/2 frames to be used with HTTP/3. </ins> ORIGIN defines the HTTP/2 ORIGIN frame, which indicates what origins are available on a given connection.  It defines a single HTTP/2 frame type. <ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. Frame diagrams in this document use the format defined in QUIC- TRANSPORT to illustrate the order and size of fields. </ins> 2. The ORIGIN HTTP/3 frame allows a server to indicate what origin(s) (RFC6454) the server would like the client to consider as members of  <ins> the Origin Set (ORIGIN) for the connection within which it occurs. </ins> The semantics of the frame payload are identical to those of the HTTP/2 frame defined in ORIGIN.  Where HTTP/2 reserves Stream 0 for
Original text:
An Origin-Entry is a length-delimited string.  Specifically, it contains two fields: <del> An unsigned, 16-bit integer indicating the length, in octets, of the ASCII-Origin field. An OPTIONAL sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the sender asserts this connection is or could be authoritative for. </del> 3. This document introduces no new security considerations beyond those

Reviewer comments:
NAME Adds the BCP14 boilerplate in a Notation Conventions section. As part of that, I noticed we don't reference any explanation of the frame layout language used -- it's the same used in QUIC and HTTP/3 -- so I added an RFC 9000 ref to pick that up in the same section.

Revised text:
An Origin-Entry is a length-delimited string.  Specifically, it contains two fields:  3. This document introduces no new security considerations beyond those
Original text:
Abstract This document defines an HTTP Proxy-Status Parameter that contains a <del> list of aliases received over DNS when establishing a connection to the next hop. </del>  1.

Reviewer comments:
This draft (-00) is using the term "alias" in a slightly different way than used in DNS: A CNAME record has two names, the owner name on the left-hand side or "alias", and the target name on the right-hand side or "canonical name". RFC 8499 (DNS Terminology): In other words, to use the example in the draft: Which might correspond to a DNS response that looked something like: and are DNS aliases (because there are CNAME records with those owner names) whereas is a DNS "canonical name" without an alias. But is included in the example in this draft. This might be confusing for the DNS name at the end of the CNAME chain (which is not an alias from a DNS perspective), so I might suggest changing: to something like:

Revised text:
Abstract This document defines an HTTP Proxy-Status Parameter that contains a  <ins> list of aliases and canonical names received over DNS when establishing a connection to the next hop. </ins> 1.
Original text:
chain of aliases encountered during DNS resolution when connecting to the next hop. <del> Knowing the full chain of aliases that were used during DNS resolution is particularly useful for clients of forward proxies, in which the client is requesting to connect to a specific target hostname using the CONNECT method HTTP or UDP proxying CONNECT-UDP. DNS aliases can be used to "cloak" hosts that perform tracking or malicious activity behind more innocuous hostnames, and clients such as web browsers use the chain of DNS aliases to influence behavior like cookie usage policies COOKIES or blocking of malicious hosts. This document allows clients to receive the chain of DNS aliases for the next hop by including the list of names in a new "next-hop- </del>  aliases" Proxy-Status parameter. 1.1.

Reviewer comments:
This draft (-00) is using the term "alias" in a slightly different way than used in DNS: A CNAME record has two names, the owner name on the left-hand side or "alias", and the target name on the right-hand side or "canonical name". RFC 8499 (DNS Terminology): In other words, to use the example in the draft: Which might correspond to a DNS response that looked something like: and are DNS aliases (because there are CNAME records with those owner names) whereas is a DNS "canonical name" without an alias. But is included in the example in this draft. This might be confusing for the DNS name at the end of the CNAME chain (which is not an alias from a DNS perspective), so I might suggest changing: to something like:

Revised text:
chain of aliases encountered during DNS resolution when connecting to the next hop.  <ins> Knowing the full chain of names that were used during DNS resolution via CNAME records DNS is particularly useful for clients of forward proxies, in which the client is requesting to connect to a specific target hostname using the CONNECT method HTTP or UDP proxying CONNECT-UDP.  CNAME records can be used to "cloak" hosts that perform tracking or malicious activity behind more innocuous hostnames, and clients such as web browsers use the chain of DNS names to influence behavior like cookie usage policies COOKIES or blocking of malicious hosts. This document allows clients to receive the CNAME chain of DNS names for the next hop by including the list of names in a new "next-hop- </ins> aliases" Proxy-Status parameter. 1.1.
Original text:
The "next-hop-aliases" parameter's value is a String that contains one or more DNS names in a comma-separated list.  The items in the <del> list include all names received in CNAME records DNS during the course of resolving the next hop's hostname using DNS.  Since DNS names can include comma (",") characters in them, any commas that appear in a DNS names MUST be represented using a percent-encoded "%2C" value instead.  The aliases SHOULD appear in the order in which they were received in DNS; that is, if a name has a CNAME record with a first alias, which has a CNAME record for a second alias, the aliases should appear in that order. For example: indicates that proxy.example.net, which used the IP address "2001:db8::1" as the next hop for this request, encountered the CNAMEs "tracker.example.com" and "service1.example-cdn.com" in the DNS resolution chain.  Note that while this example includes both the </del>  "next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can be included without including "next-hop".

Reviewer comments:
This draft (-00) is using the term "alias" in a slightly different way than used in DNS: A CNAME record has two names, the owner name on the left-hand side or "alias", and the target name on the right-hand side or "canonical name". RFC 8499 (DNS Terminology): In other words, to use the example in the draft: Which might correspond to a DNS response that looked something like: and are DNS aliases (because there are CNAME records with those owner names) whereas is a DNS "canonical name" without an alias. But is included in the example in this draft. This might be confusing for the DNS name at the end of the CNAME chain (which is not an alias from a DNS perspective), so I might suggest changing: to something like:

Revised text:
The "next-hop-aliases" parameter's value is a String that contains one or more DNS names in a comma-separated list.  The items in the  <ins> list include all alias names and canonical names received in CNAME records DNS during the course of resolving the next hop's hostname using DNS, not including the original requested hostname itself.  The names SHOULD appear in the order in which they were received in DNS. If there are multiple CNAME records in the chain, the first name in the "next-hop-aliases" list would be the value in the CNAME record for the original hostname, and the final name in the "next-hop- aliases" list would be the name that ultimately resolved to one or more addresses. For example, consider a proxy "proxy.example.net" that receives the following records when performing DNS resolution for the next hop "host.example.com": The proxy could include the following proxy status in its response: This indicates that proxy.example.net, which used the IP address "2001:db8::1" as the next hop for this request, encountered the names "tracker.example.com" and "service1.example-cdn.com" in the DNS resolution chain.  Note that while this example includes both the </ins> "next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can be included without including "next-hop".
Original text:
next-hop-aliases <del> A string containing one or more DNS alises used to establish a proxied connection to the next hop. </del>  This document

Reviewer comments:
This draft (-00) is using the term "alias" in a slightly different way than used in DNS: A CNAME record has two names, the owner name on the left-hand side or "alias", and the target name on the right-hand side or "canonical name". RFC 8499 (DNS Terminology): In other words, to use the example in the draft: Which might correspond to a DNS response that looked something like: and are DNS aliases (because there are CNAME records with those owner names) whereas is a DNS "canonical name" without an alias. But is included in the example in this draft. This might be confusing for the DNS name at the end of the CNAME chain (which is not an alias from a DNS perspective), so I might suggest changing: to something like:

Revised text:
next-hop-aliases  <ins> A string containing one or more DNS aliases or canonical names used to establish a proxied connection to the next hop. </ins> This document
Original text:
aliases" list would be the name that ultimately resolved to one or more addresses.  For example, consider a proxy "proxy.example.net" that receives the following records when performing DNS resolution for the next hop "host.example.com":

Reviewer comments:
Agreed, but I don't see a way around having a "." be allowed there. If a system wants to further escape dots within labels if they know about them, that's OK...
The current text says names MUST be represented using a percent-encoded value instead. However, domain names can also contain and , so I think the escaping rule has to be a bit more generic than just escaping commas, as indicated in the current text.
Wire format DNS names can contain arbitrary octets. I'd suggest allowing characters in the set and %-encoding any other character. This is similar to the filtering that the glibc stub resolver performs on CNAME alias chains.
Reference RFC 1035 section 3.1 for the fact that these can be arbitrary Percent encode everything that it not alphanumeric or dash Mention in the security considerations that if you don't do this, you could inject newlines, etc.
Actually, sf-string already prohibits things like newlines:
The unreserved characters are: is a valid interior label character in a wire-format DNS name, which seems like it would allow spoofing a label boundary. Not sure how much of a problem this is.

Revised text:
aliases" list would be the name that ultimately resolved to one or more addresses. <ins> The list of DNS names in "next-hop-aliases" use a comma (",") as a separator between names.  DNS names normally just contain alphanumeric characters and hyphens ("-"), although they are allowed to contain any character RFC1035, Section 3.1, including a comma.  To prevent commas or other special characters in names leading to incorrect parsing, any characters that appear in names in this list that do not belong to the set of URI Unreserved Characters RFC3986, Section 2.3 MUST be percent-encoded as defined in RFC3986, Section 2.1. </ins> For example, consider a proxy "proxy.example.net" that receives the following records when performing DNS resolution for the next hop "host.example.com":
Original text:
the signature parameters structure.  Initial values for this registry are given in iana-param-contents.  Future assignments and modifications to existing assignments are to be made through the <del> Expert Review registration policy RFC8126 and shall follow the template presented in iana-param-template. </del>  6.3.1.

Reviewer comments:
Comment by NAME I would suggest being explicit about the meaning of "active" and especially "deprecated": these are terms everywhere in RFCs (I am aware), but sometimes they are open for interpretation, and we keep discussing their meaning. It would be good to avoid that situation from this doc.
Comment by NAME The new registries do not have any guidance for the designated experts as to what registrations should be accepted or denied (conformance with template, point squatting, availability of reference specification, etc). See of RFC8126: The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry. It is particularly important to lay out what should be considered when performing an evaluation and reasons for rejecting a request.

Revised text:
the signature parameters structure.  Initial values for this registry are given in iana-param-contents.  Future assignments and modifications to existing assignments are to be made through the  <ins> Expert Review registration policy RFC8126. The DE is expected to ensure that the name follows the template presented in iana-param-template, including that the length of the name is not excessive while still being unique and recognizable for its defined function.  The DE is expected to ensure that the defined functionality is clear and does not conflict with other registered parameters.  The DE is expected to ensure that the definition of the metadata parameter includes its behavior when used as part of the normal signature process as well as when used in an Accept-Signature field. </ins> 6.3.1.
Original text:
values.  Initial values for this registry are given in iana-content- contents.  Future assignments and modifications to existing assignments are to be made through the Expert Review registration <del> policy RFC8126 and shall follow the template presented in iana- content-template. </del>  6.4.1.

Reviewer comments:
Comment by NAME I would suggest being explicit about the meaning of "active" and especially "deprecated": these are terms everywhere in RFCs (I am aware), but sometimes they are open for interpretation, and we keep discussing their meaning. It would be good to avoid that situation from this doc.
Comment by NAME The new registries do not have any guidance for the designated experts as to what registrations should be accepted or denied (conformance with template, point squatting, availability of reference specification, etc). See of RFC8126: The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry. It is particularly important to lay out what should be considered when performing an evaluation and reasons for rejecting a request.

Revised text:
values.  Initial values for this registry are given in iana-content- contents.  Future assignments and modifications to existing assignments are to be made through the Expert Review registration  <ins> policy RFC8126. The DE is expected to ensure that the name follows the template presented in iana-content-template, including that the length of the name is not excessive while still being unique and recognizable for its defined function.  The DE is expected to ensure that the component value represented by the registration request can be deterministically derived from the target HTTP message.  The DE is expected to ensure that any parameters defined for the registration request are clearly documented, along with their effects on the component value.  The DE should also ensure that the registration request is not sufficiently distinct from existing derived component definitions to warrant its registration.  When setting a registered item's status to "Deprecated", the DE should ensure that a reason for the deprecation is documented, along with instructions for moving away from the deprecated functionality. </ins> 6.4.1.
Original text:
are associated with, and the modifications these parameters make to the component value.  Definitions of parameters MUST define the targets to which they apply (such as specific field types, derived <del> components, or contexts) and any incompatibilities with other parameters known at the time of definition.  Initial values for this registry are given in iana-component-param-contents.  Future assignments and modifications to existing assignments are to be made through the Expert Review registration policy RFC8126 and shall follow the template presented in iana-component-param-template. </del>  6.5.1.

Reviewer comments:
Comment by NAME I would suggest being explicit about the meaning of "active" and especially "deprecated": these are terms everywhere in RFCs (I am aware), but sometimes they are open for interpretation, and we keep discussing their meaning. It would be good to avoid that situation from this doc.
Comment by NAME The new registries do not have any guidance for the designated experts as to what registrations should be accepted or denied (conformance with template, point squatting, availability of reference specification, etc). See of RFC8126: The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry. It is particularly important to lay out what should be considered when performing an evaluation and reasons for rejecting a request.

Revised text:
are associated with, and the modifications these parameters make to the component value.  Definitions of parameters MUST define the targets to which they apply (such as specific field types, derived  <ins> components, or contexts).  Initial values for this registry are given in iana-component-param-contents.  Future assignments and modifications to existing assignments are to be made through the Expert Review registration policy RFC8126. The DE is expected to ensure that the name follows the template presented in iana-component-param-template, including that the length of the name is not excessive while still being unique and recognizable for its defined function.  The DE is expected to ensure that the definition of the field sufficiently defines any interactions incompatibilities with other existing parameters known at the time of the registration request.  If the parameter changes the component value, the DE is expected to ensure that the component value defined by the component identifier with the parameter applied can be deterministically derived from the target HTTP message. </ins> 6.5.1.