jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: authenticity 
 The potential for misunderstanding here is great . If we consider authenticity to be stated as a goal , we would need more explicit about the properties that this provides . Specifically , this does not provide authenticity with respect to responses , because that is the purpose of DNSSEC . 
 Yes , that is true . Thinking about it , I think a web application developer ( one of the targets ) reading this draft might not fully understand the differences between authenticity at the HTTP layer and authenticity at the DNS layer . One of the stated features of   is authenticated channels that guarantee data integrity . If possible , I think a few more sentences elaborating on this topic would not hurt . 
 I 'm going to close this because we have no idea what kind of authentication that a user would expect , whereas we know pretty well what kind of privacy they expect . 
 I think there might be room for something different along these lines . DNS hijack from your configured DNS server is currently a major problem , and DoH does allow you to authenticate whether or not you are talking to your configured recursive ( while not saying anything about e2e ) . I 'm going to reopen to track ..
Paragraph (version A):
A client can use DNS over HTTPS as one of multiple mechanisms to
obtain DNS data.  If a client of this protocol encounters an HTTP
error after sending a DNS query, and then falls back to a different
DNS retrieval mechanism, doing so can weaken the privacy expected by
the user of the client.
Paragraph (version B):
A client can use DNS over HTTPS as one of multiple mechanisms to
obtain DNS data.  If a client of this protocol encounters an HTTP
error after sending a DNS query, and then falls back to a different
DNS retrieval mechanism, doing so can weaken the privacy and
authenticity expected by the user of the client.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: 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  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
Paragraph (version A):
A DOH API client may utilize a hierarchy of caches that include both
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.
Paragraph (version B):
A DNS API client may utilize a hierarchy of caches that include both
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.
Paragraph (version A):
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
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.
Paragraph (version B):
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
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.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: This text does not read very well in its current form . Since it is two ideas , two sentences is best .
Paragraph (version A):
The protocol must ensure interoperable media formats through a
mandatory to implement format wherein a query must be able to
contain future modifications to the DNS protocol including the
inclusion of one or more EDNS extensions (including those not yet
defined).
Paragraph (version B):
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
DNS protocol including the inclusion of one or more EDNS
extensions (including those not yet defined).
Draft: draft-ietf-doh-dns-over-https-latest

Commentary:  is a means , not an end . 
 this is a good change . I 'm good if  is good .
Paragraph (version A):
The protocol must allow implementations to use HTTP's content
negotiation mechanism.
Paragraph (version B):
The protocol must permit the addition of new formats for DNS
queries and responses.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: This text is great justification to include in a charter , but this is a protocol specification and it really does n't add much . 
 It seemed like the WG wanted the document to be shorter and more specific , so this feels good .
Paragraph (version A):
The Internet does not always provide end to end reachability for
native DNS.  On-path network devices may spoof DNS responses, block
DNS requests, or just redirect DNS queries to different DNS servers
that give less-than-honest answers.  These are also sometimes
delivered with poor performance or reduced feature sets.
Paragraph (version A):
Over time, there have been many proposals for using HTTP and HTTPS as
a substrate for DNS queries and responses.  To date, none of those
proposals have made it beyond early discussion, partially due to
disagreement about what the appropriate formatting should be and
partially because they did not follow HTTP best practices.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: 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 .
Paragraph (version A):
The Answer section of a DNS response contains one or more RRsets.
(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
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
response freshness lifetime MUST NOT be greater than that indicated
by the DNS Record with the smallest TTL in the response.
Paragraph (version B):
The Answer section of a DNS response can contain zero or more RRsets.
(RRsets are defined in RFC7719.)  According to RFC2181, each resource
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
response freshness lifetime MUST NOT be greater than that indicated
by the DNS resoruce record with the smallest TTL in the response.
Paragraph (version B):
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).
Paragraph (version A):
A DOH API client may utilize a hierarchy of caches that include both
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.
Paragraph (version B):
A DOH API client may utilize a hierarchy of caches that include both
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.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: wrt mailing list thread  and DOH andrew sullivan suggests modifying an existing paragraph in operational considerations to have one new sentence : servers may provide different results to the same query : for instance in split DNS configurations [ RFC6950 ] . It logically follows that the server which is queried can influence the end result . Therefore a client 's choice of DNS server may affect the responses it gets to its queries . In the case of DNS64 [ RFC6147 ] , the choice could affect whether IPv6 / IPv4 translation will work at all . in my opinion that 's fine . We do n't need to enumerate everything , but  was already called out as a non goal so we might as well note this implication of that . 
 PR
Paragraph (version A):
Local policy considerations and similar factors mean different DNS
servers may provide different results to the same query: for instance
in split DNS configurations RFC6950.  It logically follows that the
server which is queried can influence the end result.  Therefore a
client's choice of DNS server may affect the responses it gets to its
queries.
Paragraph (version B):
Local policy considerations and similar factors mean different DNS
servers may provide different results to the same query: for instance
in split DNS configurations RFC6950.  It logically follows that the
server which is queried can influence the end result.  Therefore a
client's choice of DNS server may affect the responses it gets to its
queries.  For example, in the case of DNS64 RFC6147, the choice could
affect whether IPv6/IPv4 translation will work at all.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: Make clear here that it does n't intrinsically come with a content - length limit , despite traditional DNS message length limits ? 
 I merged this in a race condition with 's comments . I support that change , but its a little different than the bug that drove this . can you just make the change directly and minimally in this same text ? 
 it could use a preview to help the reader orient herself 
 See
Paragraph (version A):
The data payload is the DNS on-the-wire format defined in RFC1035.
Paragraph (version B):
The data payload is the DNS on-the-wire format defined in RFC1035.
The format is for DNS over UDP.  (Note that this is different than
the wire format used in RFC7858.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: … dnssec 
 on list   writes : Section 6 of -03 says this : Different response media types will provide more or less information from a DNS response . For example , one response type might include the information from the DNS header bytes while another might omit it . But section 9 says A DNS API client may also perform full DNSSEC validation of answers received from a DNS API server or it may choose to trust answers from a particular DNS API server , much as a DNS client might choose to trust answers from its recursive DNS resolver . It seems to me that these are in tension with one another , because the AD and CD bits are in the header that the response type is permitted to throw away . Maybe it could be resolved thus : NEW A DNS API client may also perform full DNSSEC validation of answers received from a DNS API server or it may choose to trust answers from a particular DNS API server , much as a DNS client might choose to trust answers from its recursive DNS resolver . This capability might be affected by the response media type a DNS API server supports .
Paragraph (version A):
The HTTPS connection provides transport security for the interaction
between the DNS API server and client, but does not inherently ensure
the authenticity of DNS data.  A DNS API client may also perform full
DNSSEC validation of answers received from a DNS API server or it may
choose to trust answers from a particular DNS API server, much as a
DNS client might choose to trust answers from its recursive DNS
resolver.
Paragraph (version B):
The HTTPS connection provides transport security for the interaction
between the DNS API server and client, but does not inherently ensure
the authenticity of DNS data.  A DNS API client may also perform full
DNSSEC validation of answers received from a DNS API server or it may
choose to trust answers from a particular DNS API server, much as a
DNS client might choose to trust answers from its recursive DNS
resolver.  This capability might be affected by the response media
type.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: intended 
 largely a restating of mailing list thread : A question on the mix of DNS and HTTP semantics 
 keep pr but reopen the issue to add a little more text 
 PRs during meetings iz hArd
Paragraph (version A):
An HTTP response with a 2xx status code (RFC7231 Section 6.3)
indicates a valid DNS response to the query made in the HTTP request.
A valid DNS response includes both success and failure responses.
Paragraph (version B):
An HTTP response with a 2xx status code (RFC7231 Section 6.3)
indicates a valid DNS response to the query made in the HTTP request.
A valid DNS response includes both success and failure responses.
For example, a DNS failure response such as SERVFAIL or NXDOMAIN will
contain a successful HTTP 2xx status code even though there was a
failure at the DNS layer.  Responses with non-successful HTTP status
codes do not contain DNS answers to the question in the corresponding
request.  Some of these non-successful HTTPS responses (such as
redirects or authentication failures) could allow clients to make new
requests to satisfy the original question.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: In section 9 of DOH , it makes the following references : This is n't one of the formats that the tools process will convert into deep links . Instead , the " 10.6 " becomes a link to section 10.6 of DOH ( which does n't exist ) , while 10.7 does n't become a link at all . 
 thanks . ugh . 
 HTTP/2 provides further advice about the use of compression ( see Section 10.6 of [ RFC7540 ] ) and padding ( Section 10.7 of [ RFC7540 ] ) . That removes the " mitigations " word . 
 Fixed in PR
Paragraph (version A):
Session level encryption has well known weaknesses with respect to
traffic analysis which might be particularly acute when dealing with
DNS queries.  Sections 10.6 (Compression) and 10.7 (Padding) of
RFC7540 provide some further advice on mitigations within an HTTP/2
context.
Paragraph (version B):
Session level encryption has well known weaknesses with respect to
traffic analysis which might be particularly acute when dealing with
DNS queries.  HTTP/2 provides further advice about the use of
compression (Section 10.6 of RFC7540) and padding (Section 10.7 of
RFC7540).
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: If you 're ok with the language I think this is ready to go into the draft based on list discussion . ( this does imply to has consensus - everything needs consensus , but as a process matter we need to try and channel those discussions into text for consideration .. its open to feedback , of course ) 
 forked off from which deals with error handling , text on what happens if you choose to handle errors in a non doh fashion related to mailing list thread : A question on the mix of DNS and HTTP semantics
Paragraph (version B):
A client can use DNS over HTTPS as one of multiple mechanisms to
obtain DNS data.  If a client of this protocol encounters an HTTP
error after sending a DNS query, and then falls back to a different
DNS retrieval mechanism, doing so can weaken the privacy expected by
the user of the client.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: That s better . Thanks 
 It would be good to explicitly call out the DNS rcode SERVFAIL as a type of failure response as well , not just NXDOMAIN , as they are very different sorts of failures such that the latter can be considered , in some contexts , as not really a failure . 
 the merged patch no longer mentions specific rcodes at all .. wdyt ? 
 I personally think that as a DNS implementer that there is enough ambiguity around understanding a valid DNS response , a negative answer , and a failure response , that it should be made more painfully clear that something like all DNS servers returning message - valid SERVFAILs still warrants an HTTP 2xx . 
 Agree with . 
 will reopen the issue to add more text 
 largely a restating of mailing list thread : A question on the mix of DNS and HTTP semantics 
 keep pr but reopen the issue to add a little more text 
    rewording for the response text , but removed the security considerations until further discussion .  , please edit or pull .
Paragraph (version A):
The described approach is more than a tunnel over HTTP.  It
establishes default media formatting types for requests and responses
but uses normal HTTP content negotiation mechanisms for selecting
alternatives that endpoints may prefer in anticipation of serving new
use cases.  In addition to this media type negotiation, it aligns
itself with HTTP features such as caching, proxying, and compression.
Paragraph (version B):
The described approach is more than a tunnel over HTTP.  It
establishes default media formatting types for requests and responses
but uses normal HTTP content negotiation mechanisms for selecting
alternatives that endpoints may prefer in anticipation of serving new
use cases.  In addition to this media type negotiation, it aligns
itself with HTTP features such as caching, redirection, proxying, and
compression.
Paragraph (version B):
An HTTP response with a 2xx status code (RFC7231 Section 6.3)
indicates a valid DNS response to the query made in the HTTP request.
A valid DNS response includes both success and failure responses.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: we can provide a reminder that http is stateless and therefore reordering happens so do n't use doh for a session protocol .
Paragraph (version B):
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.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: ... 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 .
Paragraph (version A):
DNS queries sometimes experience problems with end to end
connectivity at times and places where HTTPS flows freely.
Paragraph (version A):
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.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: … ry parameter 
 The spec refers to " query parameters " , but does not specify their syntax . The most current reference for its definition is : 
 If you take , then you conveniently avoid having to normatively reference that specification :)
Paragraph (version A):
When using the GET method the URI path MUST contain a query parameter
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=...).
Paragraph (version B):
When using the GET method the URI path MUST contain a query parameter
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=...).
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: The discussion of Accept : header tries too hard to suggest that there will be future formats . We do n't actually know that , and the examples in the current draft have confused some developers . See PR 
 Yep , easier to narrow this down than address the implied questions .
Paragraph (version A):
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.
Paragraph (version B):
The requests are represented as application/dns-udpwirefomat typed
bodies.
Paragraph (version A):
At the time this is published, the response types are works in
progress.  The only response type defined in this document is
"application/dns-udpwireformat", but it is possible that at least one
JSON-based response format will be defined in the future.
Paragraph (version B):
At the time this is published, the response types are works in
progress.  The only response type defined in this document is
"application/dns-udpwireformat", but it is possible that other
response formats will be defined in the future.