jiebi/TextFlow huggingface dataset:
Original text:
name actually queried or else the last name in a CNAME chain response. <del> [[ This text is being modified in the WG and a changed definition will appear in a future draft. ]] Data from the authority section of a non-authoritative answer. RFC1035 Section 2.1 defines "authoritative" data.  However, referrals at zone cuts (defined in zones) are not authoritative. Referrals may be zone cut NS resource records and their glue records.  NS records on the parent side of a zone cut are an authoritative delegation, but are normally not treated as authoritative data.  In general, a referral is a way for a server to send an answer saying that the server does not know the answer, but knows where the query should be directed in order to get an answer.  Historically, many authoritative servers answered with a referral to the root zone when queried for a name for which they were not authoritative, but this practice has declined. </del> 5.

Reviewer comments:
In May, 2015, Tony Finch noted that the definition of "referral" in the current draft at the time was not good. He said: It would be good to review the current definition and make improvements if necessary.
Fixed with PR

Revised text:
name actually queried or else the last name in a CNAME chain response.  5.
Original text:
The reason that the TTL is the maximum time to live is that a cache operator might decide to shorten the time to live for operational purposes, such as if there is a policy to disallow TTL <del> values over a certain number.  Also, if a value is flushed from the cache when its value is still positive, the value effectively becomes zero.  Some servers are known to ignore the TTL on some RRsets (such as when the authoritative data has a very short TTL) even though this is against the advice in RFC 1035. </del>  There is also the concept of a "default TTL" for a zone, which can be a configuration parameter in the server software.  This is

Reviewer comments:
In the "TTL" section this appears: Also, if a value is flushed from the cache when its value is still positive, the value effectively becomes zero. (1) Doesn't make sense to flush a value. I think the intention was to say "if an RRSet is flushed..." (2) nitpick: "when its value is still positive" sounds like maybe it makes assumptions about the way that caches work. It sounds like the TTL is decremented and updated in the cache over time. Something like "URL the end of the TTL interval" may be better. (3) I'm not quite sure what "effectively becomes zero" means for data that has been flushed. If its flushed its gone or at least not usable again in the future.

Revised text:
The reason that the TTL is the maximum time to live is that a cache operator might decide to shorten the time to live for operational purposes, such as if there is a policy to disallow TTL  <ins> values over a certain number.  Some servers are known to ignore the TTL on some RRsets (such as when the authoritative data has a very short TTL) even though this is against the advice in RFC 1035.  An RRset can be flushed from the cache before the end of the TTL interval, at which point the value of the TTL becomes unknown because the RRset with which it was associated no longer exists. </ins> There is also the concept of a "default TTL" for a zone, which can be a configuration parameter in the server software.  This is
Original text:
Composition of names -- A name in the global DNS has one or more labels.  The length of each label is between 0 and 63 octets <del> inclusive.  In a fully-qualified domain name, the first label in </del>  the ordered list is 0 octets long; it is the only label whose length may be 0 octets, and it is called the "root" or "root label".  A domain name in the global DNS has a maximum total

Reviewer comments:
There are still inconsistencies remaining. : it can be fully qualified (in which case, it begins at the common root of the graph) : partially qualified domain names, which are names where one or more of the earliest labels in the ordered list are omitted (for example, a name of "www" derived from "URL") Suggestions: Explicitly specify ordering in "Domain name": _ → Any path of a directed acyclic graph can be represented by a domain name consisting of the labels of its nodes, ordered by decreasing distance from the root(s). A domain name whose last label identifies a root of the graph is fully qualified; other domain names whose labels form a strict prefix of a fully qualified domain name are relative to its first omitted node. Note that the generality of "domain name" requires careful language here to accommodate arbitrary edge direction (parent→child vs. child→parent) and graph topology (e.g., non-tree DAGs can have multiple roots and/or multiply-referenced nodes). Update "Fully qualified domain name" accordingly: partially qualified domain names, which are names where one or more of the last labels in the ordered list are omitted (for example, a name of "www" relative to "URL" identifies "URL")_.

Revised text:
Composition of names -- A name in the global DNS has one or more labels.  The length of each label is between 0 and 63 octets  <ins> inclusive.  In a fully-qualified domain name, the last label in </ins> the ordered list is 0 octets long; it is the only label whose length may be 0 octets, and it is called the "root" or "root label".  A domain name in the global DNS has a maximum total
Original text:
the definition here also applies to systems other than the DNS. RFC1034 defines the "domain name space" using mathematical trees and their nodes in graph theory, and this definition has the same <del> practical result as the definition here.  Using graph theory, a domain name is a list of labels identifying a portion along one edge of a directed acyclic graph.  A domain name can be relative to parts of the tree, or it can be fully qualified (in which case, it begins at the common root of the graph). </del>  Also note that different IETF and non-IETF documents have used the term "domain name" in many different ways.  It is common for The need for the term "fully qualified domain name" comes from the existence of partially qualified domain names, which are names <del> where one or more of the earliest labels in the ordered list are omitted (for example, a name of "www" derived from "www.example.net").  Such relative names are understood only by context. </del>  This term and its equivalent, "hostname", have been widely used but are not defined in RFC1034, RFC1035, RFC1123, or RFC2181.  The

Reviewer comments:
cc NAME NAME Ref 92efaf05a13690953c3123bef664fcd96d2b07c7 Ref URL :
This is an improvement over the existing text and is formally more correct, I think. That means, however, that it is technically a substantive change. I think it is not a substantive change that would make any difference to any DNSOP participant so I think this is ok without going back to the WG.

Revised text:
the definition here also applies to systems other than the DNS. RFC1034 defines the "domain name space" using mathematical trees and their nodes in graph theory, and this definition has the same  <ins> practical result as the definition here.  Any path of a directed acyclic graph can be represented by a domain name consisting of the labels of its nodes, ordered by decreasing distance from the root(s) (which is the normal convention within the DNS, including this document).  A domain name whose last label identifies a root of the graph is fully qualified; other domain names whose labels form a strict prefix of a fully qualified domain name are relative to its first omitted node. </ins> Also note that different IETF and non-IETF documents have used the term "domain name" in many different ways.  It is common for The need for the term "fully qualified domain name" comes from the existence of partially qualified domain names, which are names  <ins> where one or more of the last labels in the ordered list are omitted (for example, a domain name of "www" relative to "example.net" identifies "www.example.net").  Such relative names are understood only by context. </ins> This term and its equivalent, "hostname", have been widely used but are not defined in RFC1034, RFC1035, RFC1123, or RFC2181.  The
Original text:
In order to be fully functional, the owner of the 'arpa.' zone must add a delegation of 'service.arpa.' in the '.arpa.' zone RFC3172. This delegation should be set up as was done for 'home.arpa', as a <del> result of the specification in RFC8375. </del>  8.

Reviewer comments:
Add a reference to the IAB statement on the registration of special use names in the ARPA domain.

Revised text:
In order to be fully functional, the owner of the 'arpa.' zone must add a delegation of 'service.arpa.' in the '.arpa.' zone RFC3172. This delegation should be set up as was done for 'home.arpa', as a  <ins> result of the specification in RFC8375.  This is currently the responsibility of the IAB </ins> 8.
Original text:
This document only makes use of the 'default.service.arpa' subdomain of 'service.arpa.'  Other subdomains are reserved for future use by DNS-SD or related work.  The IANA is requested to create a registry, <del> the "service.arpa Subdomain Registry".  This registry shall begin as the following table: </del>  9.3.

Reviewer comments:
David Schinazi pointed out: This PR implements David's suggestion.
I noticed this during my shepherd review. Section creates a new registry but is lacking sufficient information for IANA to create the registry. In particular, the registration procedure is missing. Please refer to RFC 8126 for guidance.
Fixed by

Revised text:
This document only makes use of the 'default.service.arpa' subdomain of 'service.arpa.'  Other subdomains are reserved for future use by DNS-SD or related work.  The IANA is requested to create a registry,  <ins> the "service.arpa Subdomain Registry".  The IETF shall have change control for this registry.  New entries may be added either as a result of Standards Action RFC8126 or with IESG approval RFC 8126, provided that a specification exists RFC8126. The IANA shall group the "service.arpa Subdomain Registry" with the "Locally-Served DNS Zones" registry.  The registry shall be a table with three columns: the subdomain name (expressed as a fully- qualified domain name), a brief description of how it is used, and a reference to the document that describes its use in detail. This registry shall begin as the following table: </ins> 9.3.
Original text:
2.1.1. <del> Full-featured hosts are either configured manually with a </del>  registration domain, or discover the default registration domain as described in RFC6763.  If this process does not produce a default registration zone, the Service Registration protocol is not 2.2.1. <del> We refer to the DNS Update message sent by servers using SRP as an SRP Update.  Three types of updates appear in an SRP update: Service Discovery records, Service Description records, and Host Description records. </del>  RFC6763 describes the details of what each of these types of updates contains, with the exception of the KEY RR, which is defined in

Reviewer comments:
I had a brief chat with Qiaoyu and the change here is the result of that discussion, including a minor editorial fix that makes a compound sentence a little more comprehensible (I hope).

Revised text:
2.1.1.  <ins> Full-featured hosts either are configured manually with a </ins> registration domain, or discover the default registration domain as described in RFC6763.  If this process does not produce a default registration zone, the Service Registration protocol is not 2.2.1.  <ins> We refer to a DNS Update message that is constructed so as to conform to the constraints described in server_behavior as an SRP update. SRP Updates are sent by SRP requestors to SRP registrars.  Three types of updates appear in an SRP update: Service Discovery records, Service Description records, and Host Description records. </ins> RFC6763 describes the details of what each of these types of updates contains, with the exception of the KEY RR, which is defined in
Original text:
In order to maximize cache friendliness, DNS API clients using media formats that include DNS ID, such as application/dns-udpwireformat, <del> should use a DNS ID of 0 in every DNS request.  HTTP semantics correlate the request and response, thus eliminating the need for the ID in a media type such as application/dns-udpwireformat. </del>  DNS API clients can use HTTP/2 padding and compression in the same way that other HTTP/2 clients use (or don't use) them.

Reviewer comments:
And explain why more clearly.
this is editorial - should me merged imo NAME
I fully disagree that making something a RFC 2119 requirement is "editorial". In this case, it could have surprising effects on the DNS server side of a DOH server. It's worth discussing, but not just sweeping it in with "editorial".
when I wrote that text I meant it to be SHOULD - its a typo; that's why its editorial :) If its not normative then it really has no meaning in that paragraph.

Revised text:
In order to maximize cache friendliness, DNS API clients using media formats that include DNS ID, such as application/dns-udpwireformat,  <ins> SHOULD use a DNS ID of 0 in every DNS request.  HTTP correlates request and response, thus eliminating the need for the ID in a media type such as application/dns-udpwireformat and the use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. </ins> DNS API clients can use HTTP/2 padding and compression in the same way that other HTTP/2 clients use (or don't use) them.
Original text:
The queries and responses must be able to be flexible enough to express every normal DNS query. <del> The protocol must allow implementations to use HTTP's content negotiation mechanism. </del>  The protocol must ensure interoperable media formats through a mandatory to implement format wherein a query must be able to

Reviewer comments:
Conneg is a means, not an end.
this is a good change. I'm good if paul is good.

Revised text:
The queries and responses must be able to be flexible enough to express every normal DNS query.  <ins> The protocol must permit the addition of new formats for DNS queries and responses. </ins> The protocol must ensure interoperable media formats through a mandatory to implement format wherein a query must be able to
Original text:
6.1. <del> A DOH API client may utilize a hierarchy of caches that include both </del>  HTTP and DNS specific caches.  HTTP cache entries may be bypassed with HTTP mechanisms such as the "Cache-Control no-cache" directive; however DNS caches do not have a similar mechanism. A DNS API client may face a similar bootstrapping problem when the HTTP request needs to resolve the hostname portion of the DNS URI. Just as the address of a traditional DNS nameserver cannot be <del> originally determined from that same server, a DOH client cannot use its DOH server to initially resolve the server's host name into an address.  Alternative strategies a client might employ include making the initial resolution part of the configuration, IP based URIs and corresponding IP based certificates for HTTPS, or resolving the DNS API server's hostname via traditional DNS or another DOH server while still authenticating the resulting connection via HTTPS. </del>  HTTP RFC7230 is a stateless application level protocol and therefore DOH implementations do not provide stateful ordering guarantees

Reviewer comments:
Yipes, I thought I had found these in the last round. Thanks!
Even though the Terminology section contains "DNS API client" and "DNS API server" respectively, the -04 version of the draft still contains a few instances of "DOH client" and "DOH server". Not sure that's intended.
As well as one instance of "DOH API client" in Section 6.1

Revised text:
6.1.  <ins> A DNS API client may utilize a hierarchy of caches that include both </ins> HTTP and DNS specific caches.  HTTP cache entries may be bypassed with HTTP mechanisms such as the "Cache-Control no-cache" directive; however DNS caches do not have a similar mechanism. A DNS API client may face a similar bootstrapping problem when the HTTP request needs to resolve the hostname portion of the DNS URI. Just as the address of a traditional DNS nameserver cannot be  <ins> originally determined from that same server, a DNS API client cannot use its DNS API server to initially resolve the server's host name into an address.  Alternative strategies a client might employ include making the initial resolution part of the configuration, IP based URIs and corresponding IP based certificates for HTTPS, or resolving the DNS API server's hostname via traditional DNS or another DNS API server while still authenticating the resulting connection via HTTPS. </ins> HTTP RFC7230 is a stateless application level protocol and therefore DOH implementations do not provide stateful ordering guarantees
Original text:
server.  Filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment. <del> Many HTTPS implementations perform real time third party checks of the revocation status of the certificates being used by TLS.  If this check is done as part of the DNS API server connection procedure and the check itself requires DNS resolution to connect to the third party a deadlock can occur.  The use of an OCSP RFC6960 server is one example of how this can happen.  DNS API servers SHOULD utilize OCSP Stapling RFC6961 to provide the client with certificate revocation information that does not require contacting a third party. </del>  A DNS API client may face a similar bootstrapping problem when the HTTP request needs to resolve the hostname portion of the DNS URI.

Reviewer comments:
hmm. we do need to fix this - but the proposed fix removes a normative should and introduces tls 1.3 which creates a publishing dependency. The dep is rather minor, but the benefit to DoH even more minor. let me see if I can come up with a fix that is just a SHOULD inline/staple
We cannot say SHOULD use 6961 because that is not allowed in TLS 1.3. I purposely didn't make a publishing dependency to TLS 1.3 by naming it but not giving a link; every reader of this document will know what we are talking about.
I understand the problem. We can probably say something like SHOULD generically staple or inline (such as 6961 where it applies). tls 1.3 does do stapling, it just doesn't do it via 6961.
wdyt of that NAME ?
Reworded again, and back to you NAME
"DNS API servers SHOULD utilize OCSP Stapling [RFC6961] to provide the client with certificate revocation information that does not require contacting a third party." TLS 1.3 will probably be published before DOH and TLS 1.3 deprecates/obsoletes RFC 6961. TLS 1.3 uses only RFC 6066. Maybe you should refer to both RFC 6066 and RFC 6961.
Good catch! Open as PR .

Revised text:
server.  Filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment.  <ins> Some HTTPS client implementations perform real time third party checks of the revocation status of the certificates being used by TLS.  If this check is done as part of the DNS API server connection procedure and the check itself requires DNS resolution to connect to the third party a deadlock can occur.  The use of an OCSP RFC6960 server is one example of how this deadlock can happen.  To avoid the possibility of deadlock, DNS API servers SHOULD bundle the certificate status as part of the handshake using a mechanism appropriate to the version of TLS, such as using RFC6961 for TLS version 1.2. </ins> A DNS API client may face a similar bootstrapping problem when the HTTP request needs to resolve the hostname portion of the DNS URI.
Original text:
The protocol must use normal HTTP semantics. The queries and responses must be able to be flexible enough to <del> express every normal DNS query. </del>  The protocol must permit the addition of new formats for DNS queries and responses. The protocol must ensure interoperability by specifying a single format for requests and responses that is mandatory to implement. That format must be able to support future modifications to the <del> DNS protocol including the inclusion of one or more EDNS extensions (including those not yet defined). </del>  The protocol must use a secure transport that meets the requirements for HTTPS. Supporting insecure HTTP <del> Supporting legacy HTTP versions </del> 4. To make a DNS API query a DNS API client encodes a single DNS query is used directly as the HTTP message body. DNS API clients using the DNS wire format MAY have one or more EDNS <del> extensions RFC6891 in the request. </del>  The media type is "application/dns-udpwireformat". response formats will be defined in the future. The DNS response for "application/dns-udpwireformat" in dnswire MAY <del> have one or more EDNS extensions, depending on the extension definition of the extensions given in the DNS request. </del>  Each DNS request-response pair is matched to one HTTP request- response pair.  The responses may be processed and transported in any

Reviewer comments:
NAME my previous (deleted now) comment was in error in case you get a copy of that in email. sorry - git skillz failure on my part.

Revised text:
The protocol must use normal HTTP semantics. The queries and responses must be able to be flexible enough to  <ins> express every DNS query that would normally be sent in DNS over UDP (including queries and responses that use DNS extensions, but not those that require multiple responses). </ins> The protocol must permit the addition of new formats for DNS queries and responses. The protocol must ensure interoperability by specifying a single format for requests and responses that is mandatory to implement. That format must be able to support future modifications to the  <ins> DNS protocol including the inclusion of one or more EDNS options (including those not yet defined). </ins> The protocol must use a secure transport that meets the requirements for HTTPS. Supporting insecure HTTP  4. To make a DNS API query a DNS API client encodes a single DNS query is used directly as the HTTP message body. DNS API clients using the DNS wire format MAY have one or more EDNS  <ins> options RFC6891 in the request. </ins> The media type is "application/dns-udpwireformat". response formats will be defined in the future. The DNS response for "application/dns-udpwireformat" in dnswire MAY  <ins> have one or more EDNS options, depending on the extension definition of the extensions given in the DNS request. </ins> Each DNS request-response pair is matched to one HTTP request- response pair.  The responses may be processed and transported in any
Original text:
untruncated answer send back such an answer; it can instead send back an HTTP error to indicate that it cannot give a useful answer.  10. Joe Hildebrand contributed lots of material for a different iteration

Reviewer comments:
This is to address the issue of draft-ietf-dnsop-dns-wireformat-http needing to say what the original transport was. Covered on the mailing list March 25 and March 30.
What's the benefit of "original_" over just plain "transport"?

Revised text:
untruncated answer send back such an answer; it can instead send back an HTTP error to indicate that it cannot give a useful answer. <ins> This protocol does not define any use for the "original_transport" optional parameter of the application/dns-udpwireformat media type. </ins> 10. Joe Hildebrand contributed lots of material for a different iteration