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

Commentary: These look good to me .
Paragraph (version A):
In order to maximize HTTP cache friendliness, DoH clients using media
formats that include DNS ID, such as application/dns-message, SHOULD
use a DNS ID of 0 in every DNS request.  HTTP correlates the request
and response, thus eliminating the need for the ID in a media type
such as application/dns-message.  The use of a varying DNS ID can
cause semantically equivalent DNS queries to be cached separately.
Paragraph (version B):
In order to maximize HTTP cache friendliness, DoH clients using media
formats that include the ID field from the DNS message header, such
as application/dns-message, SHOULD use a DNS ID of 0 in every DNS
request.  HTTP correlates the request and response, thus eliminating
the need for the ID in a media type such as application/dns-message.
The use of a varying DNS ID can cause semantically equivalent DNS
queries to be cached separately.
Paragraph (version A):
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 DoH server connection
procedure and the check itself requires DNS resolution to connect to
the third party a deadlock can occur.  The use of OCSP RFC6960
servers or AIA for CRL fetching (RFC5280 Section 4.2.2.1) are
examples of how this deadlock can happen.  To mitigate the
possibility of deadlock, DoH servers SHOULD NOT rely on DNS-based
references to external resources in the TLS handshake.  For OCSP, the
server can bundle the certificate status as part of the handshake
using a mechanism appropriate to the version of TLS, such as using
RFC8446 Section 4.4.2.1 for TLS version 1.3.  AIA deadlocks can be
avoided by providing intermediate certificates that might otherwise
be obtained through additional requests.  Note that these deadlocks
also need to be considered for servers that a DoH server might
redirect to.
Paragraph (version B):
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 DoH server connection
procedure and the check itself requires DNS resolution to connect to
the third party a deadlock can occur.  The use of OCSP RFC6960
servers or AIA for CRL fetching (RFC5280 Section 4.2.2.1) are
examples of how this deadlock can happen.  To mitigate the
possibility of deadlock, the authentication given DoH servers SHOULD
NOT rely on DNS-based references to external resources in the TLS
handshake.  For OCSP, the server can bundle the certificate status as
part of the handshake using a mechanism appropriate to the version of
TLS, such as using RFC8446 Section 4.4.2.1 for TLS version 1.3.  AIA
deadlocks can be avoided by providing intermediate certificates that
might otherwise be obtained through additional requests.  Note that
these deadlocks also need to be considered for servers that a DoH
server might redirect to.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: … 3849
Paragraph (version A):
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
record with an address of 192.0.2.1 and a TTL of 128 seconds.
Paragraph (version B):
This is an example response for a query for the IN AAAA records for
"www.example.com" with recursion turned on.  The response bears one
answer record with an address of 2001:db8:abcd:12:1:2:3:4 and a TTL
of 3709 seconds.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: on padding length which was absent from RFC 7830 .
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.  HTTP/2 provides further advice about the use of
compression (RFC7540 Section 10.6) and padding (RFC7540 Section 10.7
).  DoH Servers can also add DNS padding RFC7830 if the DoH client
requests it in the DNS query.
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 (RFC7540 Section 10.6) and padding (RFC7540 Section 10.7
).  DoH Servers can also add DNS padding RFC7830 if the DoH client
requests it in the DNS query.  Initial attempts to offer guidance on
choosing the padding length can be found in draft-ietf-dprive-
padding-policy.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: this is a PR against these are pretty straight forward
Paragraph (version A):
DoH encrypts DNS traffic and requires authentication of the server.
This mitigates both passive surveillance RFC7258 and active attacks
attempting to divert DNS traffic to rogue servers (RFC7626
Section 2.5.1).  DNS over TLS RFC7858 provides similar protections,
while direct UDP and TCP based transports are vulnerable to this
class of information leak.
Paragraph (version A):
Additionally, the use of the HTTPS default port 443 and the ability
to mix DoH traffic with other HTTPS traffic on the same connection
can deter on-path devices from interfering with DNS operations and
make DNS traffic analysis more difficult.
Paragraph (version A):
A DoH implementation is built on IP, TCP, TLS, and HTTP.  Each layer
contains one or more common features that can be used to correlate
different queries to the same identity.  DNS transports will
generally carry the same privacy properties of the layers used to
implement them.  For example, the properties of IP, TCP, and TLS
apply to DNS over TLS implementations.
Paragraph (version B):
DoH encrypts DNS traffic and requires authentication of the server.
This mitigates both passive surveillance RFC7258 and active attacks
that attempt to divert DNS traffic to rogue servers (RFC7626
Section 2.5.1).  DNS over TLS RFC7858 provides similar protections,
while direct UDP and TCP based transports are vulnerable to this
class of attack.
Paragraph (version B):
Additionally, the use of the HTTPS default port 443 and the ability
to mix DoH traffic with other HTTPS traffic on the same connection
can deter unprivileged on-path devices from interfering with DNS
operations and make DNS traffic analysis more difficult.
Paragraph (version B):
A DoH implementation is built on IP, TCP, TLS, and HTTP.  Each layer
contains one or more common features that can be used to correlate
queries to the same identity.  DNS transports will generally carry
the same privacy properties of the layers used to implement them.
For example, the properties of IP, TCP, and TLS apply to DNS over TLS
implementations.
Paragraph (version A):
TCP-based solutions may seek performance through the use of TCP Fast
Open RFC7413.  The cookies used in TCP Fast Open allow servers to
correlate different TCP sessions together.
Paragraph (version A):
TLS based implementations often achieve better handshake performance
through the use of some form of session resumption mechanism such as
session tickets RFC5077.  Session resumption creates trivial
mechanisms for a server to correlate different TLS connections
together.
Paragraph (version B):
TCP-based solutions may seek performance through the use of TCP Fast
Open RFC7413.  The cookies used in TCP Fast Open allow servers to
correlate TCP sessions together.
Paragraph (version B):
TLS based implementations often achieve better handshake performance
through the use of some form of session resumption mechanism such as
session tickets RFC5077.  Session resumption creates trivial
mechanisms for a server to correlate TLS connections together.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: this pr is against pr
Paragraph (version A):
A DoH application is built on IP, TCP, TLS, and HTTP.  Each layer
contains one or more common features that can be used to correlate
different queries to the same identity.  DNS transports will
generally carry the same privacy properties of the layers used to
implement them.  For example, the properties of IP, TCP, and TLS
apply to DNS over TLS implementations.
Paragraph (version B):
A DoH implementation is built on IP, TCP, TLS, and HTTP.  Each layer
contains one or more common features that can be used to correlate
different queries to the same identity.  DNS transports will
generally carry the same privacy properties of the layers used to
implement them.  For example, the properties of IP, TCP, and TLS
apply to DNS over TLS implementations.
Paragraph (version B):
Determining whether or not a DoH implementation requires HTTP cookie
RFC6265 support is particularly important because HTTP cookies are
the primary state tracking mechanism in HTTP.  HTTP Cookies SHOULD
NOT be accepted by DOH clients unless they are explicitly required by
a use case.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: This PR is against the privacy considerations branch ( pr )
Paragraph (version A):
A DoH application is built on IP, TCP, TLS, and HTTP.  Each layer
contains one or more common features that can be used to correlate
different queries to the same identity.  DoH inherits the privacy
properties of the HTTPS stack and is not known to introduce new
concerns beyond that of HTTPS.
Paragraph (version B):
A DoH application is built on IP, TCP, TLS, and HTTP.  Each layer
contains one or more common features that can be used to correlate
different queries to the same identity.  DNS transports will
generally carry the same privacy properties of the layers used to
implement them.  For example, the properties of IP, TCP, and TLS
apply to DNS over TLS implementations.
Paragraph (version B):
The privacy considerations of using the HTTPS layer in DoH are
incremental to those of DNS over TLS.  DoH is not known to introduce
new concerns beyond those associated with HTTPS.
Paragraph (version A):
Implementations of DoH clients and servers need to consider the
benefit and privacy impact of all these features, and their
deployment context, when deciding whether or not to enable them.
Paragraph (version B):
The DoH protocol design allows applications to fully leverage all the
features of the HTTP ecosystem, including features not enumerated
here.  Implementations of DoH clients and servers need to consider
the benefit and privacy impact of these features, and their
deployment context, when deciding whether or not to enable them.
Implementations should expose the minimal set of data needed to
achieve the desired feature set.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary:  has given this thumbs up out of band 
 This issue is here just so we do n't lose it ; the discussion is happening on the mailing list under the subject line that contains " special meta QTYPEs " 
 This issue is here just so we do n't lose it ; the discussion is happening on the mailing list under the subject line that contains " EDNS UDP Payload size cache issue " 
 This issue is here just so we do n't lose it ; the discussion is happening on the mailing list under the subject line that contains " TC and message size " .
Paragraph (version A):
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.  Also note that while RFC1035 says
"Messages carried by UDP are restricted to 512 bytes", that was later
updated by RFC6891.  This protocol allows DNS on-the-wire format
payloads of any size.
Paragraph (version A):
When using the GET method, the data payload MUST be encoded with
base64url RFC4648 and then provided as a variable named "dns" to the
URI Template expansion.  Padding characters for base64url MUST NOT be
included.
Paragraph (version A):
When using the POST method, the data payload MUST NOT be encoded and
is used directly as the HTTP message body.
Paragraph (version A):
DNS API clients using the DNS wire format MAY have one or more EDNS
options RFC6891 in the request.
Paragraph (version A):
The media type is "application/dns-message".
Paragraph (version B):
The data payload for the application/dns-message media type is a
single message of the DNS on-the-wire format defined in section 4.2.1
of RFC1035.  The format was originally for DNS over UDP.  Although
RFC1035 says "Messages carried by UDP are restricted to 512 bytes",
that was later updated by RFC6891.  This media type restricts the
maximum size of the DNS message to 65535 bytes.  Note that the wire
format used in this media type is different than the wire format used
in RFC7858 (which uses the format defined in section 4.2.2 of
RFC1035).
Paragraph (version B):
DNS API clients using this media type MAY have one or more EDNS
options RFC6891 in the request.  DNS API servers using this media
type MUST ignore the value given for the EDNS UDP payload size in DNS
requests.
Paragraph (version B):
When using the GET method, the data payload for this media type MUST
be encoded with base64url RFC4648 and then provided as a variable
named "dns" to the URI Template expansion.  Padding characters for
base64url MUST NOT be included.
Paragraph (version B):
When using the POST method, the data payload for this media type MUST
NOT be encoded and is used directly as the HTTP message body.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: this paragraph is true .. but its a tad confusing and I do n't think really describes anything germane to doh . 
 WFM to just remove this text
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 and
authenticity expected by the user of the client.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: clarify that server identity authentication is part of  . 
 Thanks - this addresses my request .
Paragraph (version A):
A DNS API client uses configuration to select the URI, and thus the
DNS API server, used for resolution.  A client MUST NOT use a DNS API
server simply because it was discovered, or because the client was
told to use the DNS API server by an untrusted party.
Paragraph (version B):
A DNS API client uses configuration to select the URI, and thus the
DNS API server, used for resolution.  A client MUST NOT use a DNS API
server simply because it was discovered, or because the client was
told to use the DNS API server by an untrusted party.  RFC2818
defines how HTTPS verifies the server's identity.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: Remove double use of " responses " . 
 ok by me . assigning to
Paragraph (version A):
In the absence of DNSSEC information about the authenticity of
responses a DNS API server can give a client invalid data in
responses.  A client MUST NOT use arbitrary DNS API servers.
Instead, a client MUST only use DNS API servers specified using
mechanisms such as explicit configuration.  This does not guarantee
protection against invalid data but reduces the risk.
Paragraph (version B):
In the absence of DNSSEC information, a DNS API server can give a
client invalid data in response to a DNS query.  A client MUST NOT
use arbitrary DNS API servers.  Instead, a client MUST only use DNS
API servers specified using mechanisms such as explicit
configuration.  This does not guarantee protection against invalid
data but reduces the risk.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: … raft - ietf - doh - dns - over - https / commit/#commitcomment- and that this wording is much clearer . 
 Sara , making this pr was on my todo list - thanks for the time saver .  sent me an IM about it , so I 'll ga and merge .
Paragraph (version A):
The HTTPS connection provides transport security for the interaction
between the DNS API server and client, but does not provide the
response integrity of DNS data provided by DNSSEC.  DNSSEC and DOH
are independent and fully compatible protocols, each solving
different problems.  The use of one does not diminish the need nor
the usefulness of the other.  It is the choice of a client to either
perform full DNSSEC validation of answers or to treat answers from a
DNS API server as DNSSEC-authenticated, and this choice may be
affected by the response media type.
Paragraph (version B):
The HTTPS connection provides transport security for the interaction
between the DNS API server and client, but does not provide the
response integrity of DNS data provided by DNSSEC.  DNSSEC and DOH
are independent and fully compatible protocols, each solving
different problems.  The use of one does not diminish the need nor
the usefulness of the other.  It is the choice of a client to either
perform full DNSSEC validation of answers or to trust the DNS API
server to do DNSSEC validation and inspect the AD (Authentic Data)
bit in the returned message to determine whether an answer was
authentic or not.  As noted in http-response, different response
media types will provide more or less information from a DNS response
so this choice may be affected by the response media type.
Paragraph (version A):
In the absence of information about the authenticity of responses,
such as DNSSEC, a DNS API server can give a client invalid data in
responses.  A client MUST NOT use arbitrary DNS API servers.
Instead, a client MUST only use DNS API servers specified using
mechanisms such as explicit configuration.  This does not guarantee
protection against invalid data but reduces the risk.
Paragraph (version B):
In the absence of DNSSEC information about the authenticity of
responses a DNS API server can give a client invalid data in
responses.  A client MUST NOT use arbitrary DNS API servers.
Instead, a client MUST only use DNS API servers specified using
mechanisms such as explicit configuration.  This does not guarantee
protection against invalid data but reduces the risk.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: merge this if you 're ok with the change
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.  HTTP/2 provides further advice about the use of
compression (Section 10.6 of RFC7540) and padding (Section 10.7 of
RFC7540).
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).  DNS API Servers can also add DNS padding RFC7830 if the
DNS API requests it in the DNS query.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: This is the only place where a client cache is mentioned , and stub resolvers normally do n't have caches . ( Some browsers have caches for the stub resolvers , but this is rare and not well known outside a small group of people . ) This change replaces that one instance with wording that still explains the main problem .
Paragraph (version A):
In the absence of information about the authenticity of responses,
such as DNSSEC, a DNS API server can poison a client's cache.  A
client MUST NOT authorize arbitrary DNS API servers.  Instead, a
client MUST specifically authorize DNS API servers using mechanisms
such as explicit configuration.
Paragraph (version B):
In the absence of information about the authenticity of responses,
such as DNSSEC, a DNS API server can give a client invalid data in
responses.  A client MUST NOT authorize arbitrary DNS API servers.
Instead, a client MUST specifically authorize DNS API servers using
mechanisms such as explicit configuration.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: Attempt to deal with . I 'm not convinced that this is much better than the current text , but it might help others . 
 I think that we should specify behaviour for truncated responses with the TC bit more clearly . Right now the text is a little vague . There seem to be three options : the generation of an HTTP error the forwarding of the truncated response allow either the use of truncated responses and recommend fallback to TCP if the DNS API server is just making DNS requests to another server I think that the draft current vacilates in the direction of 3 , but I tend to like 1 or 4 . Choosing 4 would n't be consistent with the dnsop DNS - over - HTTP draft using DOH though . 
 is the right answer , so the text should just be stronger about it . If DOH requires or , that means that the DNS server code will need to be heavily reworked to capture these from going out , which seems pointless . DOH clients can act like normal stubs : either they do or do n't know about truncation and  . 
 I agree - I do n't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error . can you do a pr to clarify ? 
 Will do .
Paragraph (version A):
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
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.
Paragraph (version B):
A DNS API server is allowed to answer queries with any valid DNS
response.  For example, a valid DNS response might have the TC
(truncation) bit set in the DNS header to indicate that the server
was not able to retrieve a full answer for the query but is providing
the best answer it could get.  A DNS API server can reply to queries
with an HTTP error for queries that it cannot fulfill.  In this same
example, a DNS API server could use an HTTP error instead of a non-
error response that has the TC bit set.
Draft: draft-ietf-doh-dns-over-https-latest

Commentary: … but keep the requirement for future formats . 
 Attempts to 
 As input to the process , this was extremely valuable , but now that this is in WGLC , we 're done with it . Does the audience of the ultimate RFC need this information ? The only thing that I can see that is worth salvaging is a statement to the effect that  is n't explicitly supported . 
 Yes , we still need it . We have not gone to IETF Last Call and , despite what some people think , the IETF gets to change a protocol significantly during IETF Last Call . But even after that , once it is an RFC , others will want to update the RFC . It is important to keep the requirements for them as well . 
 Actually , we probably do n't need it in the RFC as long as the one future requirement ( for formats ) is still there . Please see PR
Paragraph (version A):
In order to maximize interoperability, DNS API clients and DNS API
servers MUST support the "application/dns-message" media type.  Other
media types MAY be used as defined by HTTP Content Negotiation
(RFC7231 Section 3.4).
Paragraph (version B):
In order to maximize interoperability, DNS API clients and DNS API
servers MUST support the "application/dns-message" media type.  Other
media types MAY be used as defined by HTTP Content Negotiation
(RFC7231 Section 3.4).  Those media types MUST be flexible enough to
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).