jiebi/TextFlow huggingface dataset:
Original text:
Responses may be returned in a different temporal order than requests were made using the protocols native multi-streaming functionality. <del> In the HTTP responses, the HTTP cache headers SHOULD be set to expire at the same time as the shortest DNS TTL in the response.  Because DNS provides only caching but not revalidation semantics, DNS over HTTP responses should not carry revalidation response headers (such as Last-Modified: or Etag:) or return 304 responses. </del>  A DNS API Server MUST be able to process application/dns- udpwireformat request messages.

Reviewer comments:
closes issue
NAME thanks.
The draft says "the HTTP cache headers SHOULD be set to expire at the same time as the shortest DNS TTL in the response", which might not be strong enough. A SHOULD might be OK for shorter, but allowing the value to increase might be unwise, depending on the caching model.
agree
Seems like it should be MUST:
some typos, also, I can't seem to parse 1 of the sentence.

Revised text:
Responses may be returned in a different temporal order than requests were made using the protocols native multi-streaming functionality.  <ins> A DNS response may contain a set of DNS Resource Records each with its own Time To Live (TTL) freshness information.  The freshness lifetime (RFC7234 Section 4.2) of the HTTP response should be coordinated with the Resource Record bearing the smallest TTL in the response.  The freshness lifetime SHOULD be set to expire at the same time any of the DNS Records reach a 0 TTL.  The response freshness lifetime MUST NOT be greater than that indicated by the DNS Record with the smallest TTL in the response. A DNS API Client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic freshness (RFC7234 Section 4.2.2.) greater than that indicated by the DNS Record with the smallest TTL in the response. Because DNS provides only caching but not revalidation semantics, DNS over HTTP responses should not carry revalidation response headers (such as Last-Modified: or Etag:) or return 304 responses. </ins> A DNS API Server MUST be able to process application/dns- udpwireformat request messages.
Original text:
9. <del> Running DNS over HTTPS relies on the security of the underlying HTTP connection.  By requiring at least RFC7540 levels of support for TLS, this protocol expects to use current best practices for secure transport. </del>  Session level encryption has well known weaknesses with respect to traffic analysis which might be particularly acute when dealing with RFC7540 provide some further advice on mitigations within an HTTP/2 context.  [[ From the WG charter: The working group will analyze the security and privacy issues that

Reviewer comments:
Separate out confidentiality and authentication - -01 said "Running DNS over HTTPS relies on the security of the underlying HTTP connection." This PR clarifies that the HTTPS connection can only provide confidentiality and authentication of the DNS API server. Clients wanting authentic DNS answers need to perform DNSSEC validation or explicitly trust the DNS API server.
I reverted this because my comment above was not satisfied before merge.
pr did some of this but was backed out. see that diff and discussion
I agree with the notion of separating transport security from e2e validation.. but I think the changes overshoot a touch. I would leave the first paragraph alone - https provides more than confidentiality and I don't think the text suggests anything other than doh relies on https. I like your second paragraph - though if we leave the first one in tact you probably want to remove the "also authenticates" part.. it can be recast as transport security between api server and client vs e2e validation

Revised text:
9.  <ins> DNS over HTTPS relies on the underlying HTTPS connection to provide confidentiality.  By requiring at least RFC7540 levels of support for TLS, this protocol expects to use current best practices for confidential transport. </ins> Session level encryption has well known weaknesses with respect to traffic analysis which might be particularly acute when dealing with RFC7540 provide some further advice on mitigations within an HTTP/2 context. <ins> The HTTPS connection also authenticates the DNS API server but does not inherently assure of authenticity of DNS data.  A DNS API client may choose to trust answers from a particular DNS API server, much as a DNS client might choose to trust answers from its recurvise DNS resolver.  A DNS API client may also perform full DNSSEC validation of answers received from a DNS API server. </ins> [[ From the WG charter: The working group will analyze the security and privacy issues that
Original text:
10. <del> Joe Hildebrand contributed lots of material for a different iteration of this document.  Helpful early comments were given by Ben Schwartz and Mark Nottingham. </del>  11.  References

Reviewer comments:
recently I've left the ack section mostly untouched until the final (or near final) edit. Easier to deal with it once. However I think its good idea to have leave the PR open and amend it as useful
OK, having a "living" PR seems OK.

Revised text:
10.  <ins> This work required a high level of cooperation between experts in different technologies.  Thank you Ray Bellis, Stephane Bortzmeyer, Manu Bretelle, Tony Finch, Daniel Kahn Gilmor, Olafur Guomundsson, Wes Hardaker, Rory Hewitt, Joe Hildebrand, David Lawrence, Eliot Lear, John Mattson, Alex Mayrhofer, Mark Nottingham, Jim Reid, Adam Roach, Ben Schwartz, Davey Song, Daniel Stenberg, Andrew Sullivan, Martin Thomson, and Sam Weiler. </ins> 11.  References
Original text:
9. <del> DNS over HTTPS relies on the underlying HTTPS connection to provide confidentiality.  By requiring at least RFC7540 levels of support for TLS, this protocol expects to use current best practices for confidential transport. </del>  Session level encryption has well known weaknesses with respect to traffic analysis which might be particularly acute when dealing with RFC7540 provide some further advice on mitigations within an HTTP/2 context. <del> The HTTPS connection also authenticates the DNS API server but does not inherently assure of authenticity of DNS data.  A DNS API client may choose to trust answers from a particular DNS API server, much as a DNS client might choose to trust answers from its recurvise DNS resolver.  A DNS API client may also perform full DNSSEC validation of answers received from a DNS API server. </del> [[ From the WG charter: The working group will analyze the security and privacy issues that

Reviewer comments:
Reverts dohwg/draft-ietf-doh-dns-over-https

Revised text:
9.  <ins> Running DNS over HTTPS relies on the security of the underlying HTTP connection.  By requiring at least RFC7540 levels of support for TLS, this protocol expects to use current best practices for secure transport. </ins> Session level encryption has well known weaknesses with respect to traffic analysis which might be particularly acute when dealing with RFC7540 provide some further advice on mitigations within an HTTP/2 context.  [[ From the WG charter: The working group will analyze the security and privacy issues that
Original text:
(RRsets are defined in RFC7719.)  According to RFC2181, each resource record in an RRset is supposed to have the Time To Live (TTL) freshness information.  Different RRsets in the Answer section can <del> have different TTLs.  The HTTP response freshness lifetime (RFC7234 Section 4.2) should be coordinated with the Resource Record bearing the smallest TTL in the Answer section of the response.  The HTTP freshness lifetime SHOULD be set to expire at the same time any of the DNS Records reach a 0 TTL.  The response freshness lifetime MUST NOT be greater than that indicated by the DNS Record with the smallest TTL in the response. </del>  A DNS API Client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic

Reviewer comments:
…
during the singapore meeting tale noted that the http caching model, where 1 lifetime is assigned to the rrset is not necessarily the way a dns cache would handle things.. each rr can have its own ttl (though one dns implementation does it this way). perhaps worth some explanatory text when talking about rrset granularity and http caches.

Revised text:
(RRsets are defined in RFC7719.)  According to RFC2181, each resource record in an RRset is supposed to have the Time To Live (TTL) freshness information.  Different RRsets in the Answer section can  <ins> have different TTLs, though it is only possible for the HTTP response to have a single freshness lifetime.  The HTTP response freshness lifetime (RFC7234 Section 4.2) should be coordinated with the Resource Record bearing the smallest TTL in the Answer section of the response.  The HTTP freshness lifetime SHOULD be set to expire at the same time any of the DNS Records reach a 0 TTL.  The response freshness lifetime MUST NOT be greater than that indicated by the DNS Record with the smallest TTL in the response. </ins> A DNS API Client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic
Original text:
Server.  Filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment.  11. Joe Hildebrand contributed lots of material for a different iteration

Reviewer comments:
In order to prevent a dependency on traditional DNS or a DNS query for CRL/OCSP certificate validation check, OCSP stapling should be used for the HTTPS web server.
we're probably better off describing the potential deadlock in revocation and mentioning stapling as a best practice.. but in general I think we want to stay away from specifying a whole lot of how-to-profile-https details as these things do differ between clients and we tend to accept all of the variants as "https".. for e.g.

Revised text:
Server.  Filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment. <ins> 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. </ins> 11. Joe Hildebrand contributed lots of material for a different iteration
Original text:
This is an example response for a query for the IN A records for "www.example.com" with recursion turned on.  The response bears one <del> record with an address of 93.184.216.34 and a TTL of 128 seconds. </del>  7.

Reviewer comments:
Unfortunately, we shouldn't use the existing real-world URL address and should be using example ip space instead.
unfortunately you included the PR changes in this PR too.. let's see if the merge process can sort that out :)
ok! thanks.

Revised text:
This is an example response for a query for the IN A records for "www.example.com" with recursion turned on.  The response bears one  <ins> record with an address of 192.0.2.1 and a TTL of 128 seconds. </ins> 7.
Original text:
The protocol must ensure interoperable media formats through a mandatory to implement format wherein a query must be able to <del> contain one or more EDNS extensions, including those not yet defined. </del>  The protocol must use a secure transport that meets the requirements for HTTPS.

Reviewer comments:
Right now the text only defines that future edns options must be supported, but (IMHO) we should support all future versions of changes to the DNS in general, not just future EDNS extensions. So I proposed text that rewords a bit to state this and uses EDNS as an example.
Good call. There might be other on-the-wire extension mechanisms in the future.

Revised text:
The protocol must ensure interoperable media formats through a mandatory to implement format wherein a query must be able to  <ins> contain future modifications to the DNS protocol including the inclusion of one or more EDNS extensions (including those not yet defined). </ins> The protocol must use a secure transport that meets the requirements for HTTPS.
Original text:
5.  The URI scheme MUST be https. <del> The path SHOULD be "/.well-known/dns-query" but a different path can be used if the DNS API Client has prior knowledge about a DNS API service on a different path at the origin being used.  (See iana for the registration of this in the well-known URI registry.)  Using the well-known path allows automated discovery of a DNS API Service, and also helps contextualize DNS Query requests pushed over an active HTTP/2 connection. </del>  A DNS API Client encodes the DNS query into the HTTP request using either the HTTP GET or POST methods.

Reviewer comments:
Firstly, mention that the URI can be anything. Then explain why the well-known exists. The well-known URI exists for two reasons: to aid in discovery, for cases where the discovery process produces only a domain name (or domain name and port) to contextualize server pushes The first doesn't need a SHOULD.
The draft gets stuck into describing pieces of the URL, but neglects to point out some obvious things, like what the URL is for. It could probably use some more clarity about the configuration and discovery point as well.

Revised text:
5. <ins> To make a DNS API query, a DNS API client sends an HTTP request to the URI of the DNS API. </ins> The URI scheme MUST be https.  <ins> A client can be configured with a DNS API URI, or it can discover the URI.  This document defines a well-known URI path of "/.well-known/ dns-query" so that a discovery process that produces a domain name or domain name and port can be used to construct the DNS API URI.  (See iana for the registration of this in the well-known URI registry.) DNS API servers SHOULD use this well-known path to help contextualize DNS Query requests that use server push RFC7540. </ins> A DNS API Client encodes the DNS query into the HTTP request using either the HTTP GET or POST methods.
Original text:
These examples use HTTP/2 style formatting from RFC7540. These examples use a DNS API service located at <del> https://dnsserver.example.net/dns-query.  The requests are represented as application/dns-udpwirefomat typed bodies, but the client indicates it can parse responses in either that format or as a hypothetical JSON-based content type.  The application/simpledns+json type used by this example is currently fictitious. </del>  <del> The same DNS query, using the POST method would be: </del>  6.

Reviewer comments:
I've seen an implementation report that confused base64 and base64url; they noted that the examples didn't include one where the distinction was important
NAME yes, there is also the bit about not having the sign paddings that caught me at first. During the DOH proxy implementation, I missed the padding part. I have it implemented in URL and I think it is correct :) Would an example implementation in a language be worth adding to the examples? It may be more straightforward to read than examples. URL documentation says: This may be worth highlighting as what base64url is too.
This is complicated by the fact that some people want the encoding of responses to GET to be media-type-specific.
I think you mean GET request body parameters (not responses - which are always in bodies and not encoded)
Yes, I meant body parameters.
Please stop calling the parameter . It's really confusing. (I just read this and thought to myself "GET doesn't have a body").
note that the current encoded url in the github copy is wrong as it wasn't updated when the dns id changed to 0. I'll fix that as part of making a base 64 example.

Revised text:
These examples use HTTP/2 style formatting from RFC7540. These examples use a DNS API service located at  <ins> https://dnsserver.example.net/dns-query to resolve the IN A records. </ins>  <ins> The requests are represented as application/dns-udpwirefomat typed bodies, but the client indicates it can parse responses in either that format or as a hypothetical JSON-based content type.  The application/simpledns+json type used by this example is currently fictitious. The first example request uses GET to request www.example.com The same DNS query for www.example.com, using the POST method would be: Finally, a GET based query for a.62characterlabel-makes-base64url- distinct-from-standard-base64.example.com is shown as an example to emphasize that the encoding alphabet of base64url is different than regular base64 and that padding is omitted. The DNS query is 94 bytes represented by the following hex encoding </ins> 6.
Original text:
https://dnsserver.example.net/dns-query to resolve the IN A records. The requests are represented as application/dns-udpwirefomat typed <del> bodies, but the client indicates it can parse responses in either that format or as a hypothetical JSON-based content type.  The application/simpledns+json type used by this example is currently fictitious. </del>  The first example request uses GET to request www.example.com At the time this is published, the response types are works in progress.  The only response type defined in this document is <del> "application/dns-udpwireformat", but it is possible that at least one JSON-based response format will be defined in the future. </del>  The DNS response for "application/dns-udpwireformat" in dnswire MAY have one or more EDNS extensions, depending on the extension

Reviewer comments:
The discussion of Accept: header tries too hard to suggest that there will be future formats. We don't actually know that, and the examples in the current draft have confused some developers. See PR URL
Yep, easier to narrow this down than address the implied questions.

Revised text:
https://dnsserver.example.net/dns-query to resolve the IN A records. The requests are represented as application/dns-udpwirefomat typed  <ins> bodies. </ins> The first example request uses GET to request www.example.com At the time this is published, the response types are works in progress.  The only response type defined in this document is  <ins> "application/dns-udpwireformat", but it is possible that other response formats will be defined in the future. </ins> The DNS response for "application/dns-udpwireformat" in dnswire MAY have one or more EDNS extensions, depending on the extension
Original text:
smaller than their GET equivalents. When using the GET method the URI path MUST contain a query parameter <del> with the name of "ct" and a value indicating the media-format used for the dns parameter.  The value may either be an explicit media type (e.g. ct=application/dns-udpwireformat&dns=...) or it may be empty.  An empty value indicates the default application/dns- udpwireformat type (e.g. ct&dns=...). </del>  When using the GET method the URI path MUST contain a query parameter with the name of "dns".  The value of the parameter is the content of

Reviewer comments:
…ry parameter
The spec refers to "query parameters", but does not specify their syntax. The most current reference for its definition is: URL
If you take , then you conveniently avoid having to normatively reference that specification :)

Revised text:
smaller than their GET equivalents. When using the GET method the URI path MUST contain a query parameter  <ins> name-value pair QUERYPARAMETER with the name of "ct" and a value indicating the media-format used for the dns parameter.  The value may either be an explicit media type (e.g. ct=application/dns- udpwireformat&dns=...) or it may be empty.  An empty value indicates the default application/dns-udpwireformat type (e.g. ct&dns=...). </ins> When using the GET method the URI path MUST contain a query parameter with the name of "dns".  The value of the parameter is the content of
Original text:
Abstract <del> DNS queries sometimes experience problems with end to end connectivity at times and places where HTTPS flows freely. HTTPS provides the most practical mechanism for reliable end to end communication.  Its use of TLS provides integrity and confidentiality guarantees and its use of HTTP allows it to interoperate with proxies, firewalls, and authentication systems where required for transit. </del> This document describes how to run DNS service over HTTP using https:// URIs.

Reviewer comments:
... says: """ DNS queries sometimes experience problems with end to end connectivity at times and places where HTTPS flows freely. HTTPS provides the most practical mechanism for reliable end to end communication. Its use of TLS provides integrity and confidentiality guarantees and its use of HTTP allows it to interoperate with proxies, firewalls, and authentication systems where required for transit. """ Do we need to be talking about the motivation here? The way it's written sounds like it's using HTTP for tunnelling, which is something we wanted to avoid (especially if future efforts take away the message that HTTPS is the best tunnel).
I think the introduction does a decent job of dealing with the "not just a tunnel" question.. and therefore these motivators can live there and we can have a very simple 1 line abstract. (cutting non normative text is in vogue).. so I'll put up a PR that reflects that.

Revised text:
Abstract  This document describes how to run DNS service over HTTP using https:// URIs.
Original text:
API Server's hostname via traditional DNS or another DOH server while still authenticating the resulting connection via HTTPS.  10. Joe Hildebrand contributed lots of material for a different iteration

Reviewer comments:
we can provide a reminder that http is stateless and therefore reordering happens so don't use doh for a session protocol.

Revised text:
API Server's hostname via traditional DNS or another DOH 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 between different requests.  DOH cannot be used as a transport for other protocols that require strict ordering. </ins> 10. Joe Hildebrand contributed lots of material for a different iteration