jiebi/CodeConvo huggingface dataset:
Change:
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.

Discussion:
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> <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 <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> <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
Change:
Add a reference to the IAB statement on the registration of special use names in the ARPA domain.

Discussion:
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> <ins> result of the specification in RFC8375.  This is currently the responsibility of the IAB </ins> 8.
Change:
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

Discussion:
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> <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.
Change:
The text describing the behavior of full-featured hosts specified behavior that conflicted with the behavior specified in RFC6763 not because a change was needed, but because I just misunderstood how it worked. This change updates that text to simply refer to the relevant section in RFC6763. In addition, the term "zone" was used where "domain" should have been used, and the term "DNS Update" was used to refer to something that should only ever be an SRP update, so these errors are also corrected.

Discussion:
2.1.1. Full-featured hosts are either configured manually with a <del> registration domain, or use the "dr._dns-sd._udp.<domain>" query (RFC6763) to learn the default registration domain from the network. RFC6763 says to discover the registration domain using either ".local" or a network-supplied domain name for <domain>.  Services using SRP MUST use the domain name received through the DHCPv4 Domain Name option (RFC2132), if available, or the Neighbor Discovery DNS Search List option RFC8106.  If the DNS Search List option contains more than one domain name, it MUST NOT be used.  If neither option is available, the Service Registration protocol is not available on the local network. </del> <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 discoverable on the local network using this mechanism.  Other discovery mechanisms are possible, but are out of scope for this document. </ins> Manual configuration of the registration domain can be done either by <del> querying the list of available registration zones ("r._dns-sd._udp") and allowing the user to select one from the UI, or by any other means appropriate to the particular use case being addressed.  Full- featured devices construct the names of the SRV, TXT, and PTR records describing their service(s) as subdomains of the chosen service registration domain.  For these names they then discover the zone apex of the closest enclosing DNS zone using SOA queries RFC8765. Having discovered the enclosing DNS zone, they query for the "_dnssd-srp._tcp.<zone>" SRV record to discover the server to which they should send DNS updates.  Hosts that support SRP Updates using TLS use the "_dnssd-srp-tls._tcp.<zone>" SRV record instead. </del> <ins> querying the list of available registration domains ("r._dns-sd._udp") and allowing the user to select one from the UI, or by any other means appropriate to the particular use case being addressed.  Full-featured devices construct the names of the SRV, TXT, and PTR records describing their service(s) as subdomains of the chosen service registration domain.  For these names they then discover the zone apex of the closest enclosing DNS zone using SOA queries RFC8765.  Having discovered the enclosing DNS zone, they query for the "_dnssd-srp._tcp.<zone>" SRV record to discover the server to which they should send SRP updates.  Hosts that support SRP Updates using TLS use the "_dnssd-srp-tls._tcp.<zone>" SRV record instead. </ins> 2.1.2.
Change:
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).

Discussion:
2.1.1. <del> Full-featured hosts are either configured manually with a </del> <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. <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> <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
Change:
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.

Discussion:
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> <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.
Change:
feel free to merge if my language works for you
I just now see you gave me the go ahead to merge. I'll fix the conflict and do so.

Discussion:
order using HTTP's multi-streaming functionality (RFC7540 Section 5}). <del> The Answer section of a DNS response contains one or more RRsets. </del> <ins> The Answer section of a DNS response can contain zero or more RRsets. </ins> (RRsets are defined in RFC7719.)  According to RFC2181, each resource <del> record in an RRset is supposed to have the Time To Live (TTL) freshness information.  Different RRsets in the Answer section can 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.  Specifically, the HTTP freshness lifetime SHOULD be set to expire at the same time any of the DNS Records reach a 0 TTL.  The </del> <ins> record in an RRset has Time To Live (TTL) freshness information. Different RRsets in the Answer section can have different TTLs, although 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 RRset with the smallest TTL in the Answer section of the response.  Specifically, the HTTP freshness lifetime SHOULD be set to expire at the same time any of the DNS resource records in the Answer section reach a 0 TTL.  The </ins> response freshness lifetime MUST NOT be greater than that indicated <del> by the DNS Record with the smallest TTL in the response. </del> <ins> by the DNS resoruce record with the smallest TTL in the response. If the DNS response has no records in the Answer section, and the DNS response has an SOA record in the Authority section, the response freshness lifetime MUST NOT be greater than the MINIMUM field from that SOA record.  Otherwise, the HTTP response MUST set a freshness lifetime (RFC7234 Section 4.2) of 0 by using a mechanism such as "Cache-Control: no-cache" (RFC7234 Section 5.2.1.4). </ins> A DNS API client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic

A DOH API client may utilize a hierarchy of caches that include both HTTP and DNS specific caches.  HTTP cache entries may be bypassed <del> with HTTP mechanisms such as the Cache-Control no-cache directive </del> <ins> with HTTP mechanisms such as the "Cache-Control no-cache" directive; </ins> however DNS caches do not have a similar mechanism. A DOH response that was previously stored in an HTTP cache will
Change:
Conneg is a means, not an end.
this is a good change. I'm good if paul is good.

Discussion:
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> <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
Change:
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

Discussion:
6.1. <del> A DOH API client may utilize a hierarchy of caches that include both </del> <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 <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> <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
Change:
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 .

Discussion:
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> <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.
Change:
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.

Discussion:
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> <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 <del> DNS protocol including the inclusion of one or more EDNS extensions (including those not yet defined). </del> <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 <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> <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 <del> have one or more EDNS extensions, depending on the extension definition of the extensions given in the DNS request. </del> <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
Change:
Fixes to PR
It doesn't feel to me like "beyond what is already in {{RFC1035}}" really clarifies anything, and might just cause additional confusion, as it makes me as a reader wonder, "oh well what's in 1035? Guess I have to go searching..."
If you want to put the specific limit from RFC 1035 in, that's fine.
Well no, because I don't think there should be a limit. While DNS messages implicitly have a maximum size of 64k in DNS, there's no reason dns-udpwireformat in HTTPS can't surpass that.
NAME It would be an interoperability problem if a DNS API server handed a DNS API client a message that it could not handle. It is reasonable to assume that DNS API clients expect to parse messages as if they were DNS messages.
NAME This was sloppy on my part: I meant the addition to point to RFC 6891; now changed.
Right NAME but my point is that something like multiple AXFR messages re-assembled into one unit is still a DNS message even if it exceeds 64k. From a wire-format point of view, it parses exactly the same way.
NAME Really? Ugh. Gotta love this protocol. So, you would prefer that the text says "URL this protocol allows DNS-on-the-wire format payloads of any size"?
Yes, I would. Realistically almost everything is still going to be sub-10k, but I don't see an intrinsic need to limit it, especially with https channels routinely handling far larger responses.
I think David and I are now in agreement; NAME should consider accepting.

Discussion:
The format is for DNS over UDP.  Note that this is different than the wire format used in RFC7858.  Also note that while RFC1035 says "Messages carried by UDP are restricted to 512 bytes", that was later <del> updated by RFC6891, and this protocol does not put any limit on the size of DNS on-the-wire format payloads. </del> <ins> updated by RFC6891, and this protocol allows DNS on-the-wire format payloads of any size. </ins> When using the GET method, the data payload MUST be encoded with base64url RFC4648 and then placed as a name value pair in the query

If a DNS API server responds to a DNS API client with a DNS message that has the TC (truncation) bit set in the header, that indicates that the DNS API server was not able to retrieve a full answer for <del> the query over TCP and is providing the best answer it could get. This protocol does not require that a DNS API server that cannot get an untruncated answer send back such an answer; it can instead send back an HTTP error to indicate that it cannot give a useful answer. </del> <ins> the query and is providing the best answer it could get.  This protocol does not require that a DNS API server that cannot get an 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> 10.
Change:
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"?

Discussion:
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