jiebi/TextFlow huggingface dataset:
Original text:
of resolver (some of which are defined below), and understanding the use of the term depends on understanding the context.  A resolver that cannot perform all resolution itself.  Stub resolvers generally depend on a recursive resolver to undertake the actual resolution function.  Stub resolvers are discussed but

Reviewer comments:
…empt to define "resolve" and "resolution".
This issue concerns consistency and definition of some terms in the document. "Name server", "name server" and, perhaps, "server" seem to be used interchangeably. None of those terms have a formal definition in the document. The terms are also used in conjunction with various modifiers like "authoritative server", "DNS server", etc. While all those terms are likely pretty well-known, for the purposes of this document, un my opinion, it would be helpful to give a generic definition of "server", and how it is then combined with modifiers to form terminology for specific types of servers. Based on the definition of "server", it would be helpful to include a definition for "name server", "name server" or "DNS server" (pick one) and then use that term uniformly throughout the document.
Added a note about this in URL
Fixed in
These are common terms that are used in contexts that are not always associated with the resolver itself, so they should have stand-alone definitions.
First attempt at definition in URL

Revised text:
of resolver (some of which are defined below), and understanding the use of the term depends on understanding the context. <ins> A related term is "resolve", which is not formally defined in RFC1034 or RFC1035.  An imputed definition might be "asking a question that consists of a domain name, class, and type, and receiving some sort of answer".  Similarly, an imputed definition of "resolution" might be "the answer received from resolving". </ins> A resolver that cannot perform all resolution itself.  Stub resolvers generally depend on a recursive resolver to undertake the actual resolution function.  Stub resolvers are discussed but
Original text:
simplifications are available.  Instead of being configured with (or discovering) the service registration domain, the (proposed) special- use domain name (see RFC6761) "default.service.arpa" is used.  The <del> details of how SRP server(s) are discovered will be specific to the constrained network, and therefore we do not suggest a specific </del>  mechanism here. <del> SRP clients on constrained networks are expected to receive from the network a list of SRP servers with which to register.  It is the responsibility of a Constrained-Node Network supporting SRP to provide one or more SRP server addresses.  It is the responsibility of the SRP server supporting a Constrained-Node Network to handle the updates appropriately.  In some network environments, updates may be accepted directly into a local "default.service.arpa" zone, which has only local visibility.  In other network environments, updates for names ending in "default.service.arpa" may be rewritten internally to names with broader visibility. </del>  2.1.3.

Reviewer comments:
This is part of the previous pull request, but I missed it because it was interleaved with some unrelated changes.

Revised text:
simplifications are available.  Instead of being configured with (or discovering) the service registration domain, the (proposed) special- use domain name (see RFC6761) "default.service.arpa" is used.  The  <ins> details of how SRP registrar(s) are discovered will be specific to the constrained network, and therefore we do not suggest a specific </ins> mechanism here.  <ins> SRP requestors on constrained networks are expected to receive from the network a list of SRP registrars with which to register.  It is the responsibility of a Constrained-Node Network supporting SRP to provide one or more SRP registrar addresses.  It is the responsibility of the SRP registrar supporting a Constrained-Node Network to handle the updates appropriately.  In some network environments, updates may be accepted directly into a local "default.service.arpa" zone, which has only local visibility.  In other network environments, updates for names ending in "default.service.arpa" may be rewritten internally to names with broader visibility. </ins> 2.1.3.
Original text:
An instruction is a Host Description Instruction if, for the appropriate hostname, it contains  2.3.2. An SRP Update MUST include zero or more Service Discovery

Reviewer comments:
The set of constraints for the host description includes a constrain that A and AAAA records must be of sufficient scope. This is asking a bit much of the SRP server, which may or may not be able to make this determination. There may also be cases where an SRP registration with an address of less than global scope is useful. Consequently, this constraint is removed, and text added to talk about how servers should deal with addresses of less-than-global scope.

Revised text:
An instruction is a Host Description Instruction if, for the appropriate hostname, it contains <ins> A and/or AAAA records that are not of of sufficient scope to be validly published in a DNS zone can be ignored by the SRP server, which could result in a host description effectively containing zero reachable addresses even when it contains one or more addresses. For example, if a link-scope address or IPv4 autoconfiguration address is provided by the SRP requestor, the SRP registrar could not publish this in a DNS zone.  However, in some situations, the SRP registrar may make the records available through a mechanism such as an advertising proxy only on the specific link from which the SRP update originated; in such a situation, locally-scoped records are still valid. </ins> 2.3.2. An SRP Update MUST include zero or more Service Discovery
Original text:
Service Registration Protocol for DNS-Based Service Discovery <del> draft-ietf-dnssd-srp-13 </del>  Abstract

Reviewer comments:
Update the draft number, date, and change draft-sekar-ul to draft-ietf-dnssd-update-lease.

Revised text:
Service Registration Protocol for DNS-Based Service Discovery  <ins> draft-ietf-dnssd-srp-14 </ins> Abstract
Original text:
record MUST contain the same public key.  The update is signed using SIG(0), using the private key that corresponds to the public key in the KEY record.  The lifetimes of the records in the update is set <del> using the EDNS(0) Update Lease option I-D.sekar-dns-ul. </del>  The KEY record in Service Description updates MAY be omitted for brevity; if it is omitted, the SRP registrar MUST behave as if the

Reviewer comments:
Update the draft number, date, and change draft-sekar-ul to draft-ietf-dnssd-update-lease.

Revised text:
record MUST contain the same public key.  The update is signed using SIG(0), using the private key that corresponds to the public key in the KEY record.  The lifetimes of the records in the update is set  <ins> using the EDNS(0) Update Lease option I-D.ietf-dnssd-update-lease. </ins> The KEY record in Service Description updates MAY be omitted for brevity; if it is omitted, the SRP registrar MUST behave as if the
Original text:
Because the DNS-SD registration protocol is automatic, and not managed by humans, some additional bookkeeping is required.  When an update is constructed by the SRP requestor, it MUST include an <del> EDNS(0) Update Lease Option I-D.sekar-dns-ul.  The Update Lease Option contains two lease times: the Lease Time and the Key Lease Time. </del>  These leases are promises, similar to RFC2131, from the SRP requestor that it will send a new update for the service registration before

Reviewer comments:
Update the draft number, date, and change draft-sekar-ul to draft-ietf-dnssd-update-lease.

Revised text:
Because the DNS-SD registration protocol is automatic, and not managed by humans, some additional bookkeeping is required.  When an update is constructed by the SRP requestor, it MUST include an  <ins> EDNS(0) Update Lease Option I-D.ietf-dnssd-update-lease.  The Update Lease Option contains two lease times: the Lease Time and the Key Lease Time. </ins> These leases are promises, similar to RFC2131, from the SRP requestor that it will send a new update for the service registration before
Original text:
There are two primary use cases for this protocol. <del> The primary one is to prevent on-path network devices from </del>  interfering with native DNS operations.  This interference includes, but is not limited to, spoofing DNS responses, blocking DNS requests, and tracking.  HTTP authentication and proxy friendliness are

Reviewer comments:
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: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid 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 wouldn'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 don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.

Revised text:
There are two primary use cases for this protocol.  <ins> The primary use case is to prevent on-path network devices from </ins> interfering with native DNS operations.  This interference includes, but is not limited to, spoofing DNS responses, blocking DNS requests, and tracking.  HTTP authentication and proxy friendliness are
Original text:
A secondary use case is web applications that want to access DNS information.  Standardizing an HTTPS mechanism allows this to be done <del> in a way consistent with the cross-origin resource sharing CORS security model of the web and also integrate the caching mechanisms of DNS with those of HTTP.  These applications may be interested in </del>  using a different media type than traditional clients. <del> [ This paragraph is to be removed when this document is published as an RFC ] Note that these use cases are different than those in a </del>  similar protocol described at I-D.ietf-dnsop-dns-wireformat-http. The use case for that protocol is proxying DNS queries over HTTP instead of over DNS itself.  The use cases in this document all

Reviewer comments:
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: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid 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 wouldn'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 don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.

Revised text:
A secondary use case is web applications that want to access DNS information.  Standardizing an HTTPS mechanism allows this to be done  <ins> in a way consistent with the cross-origin resource sharing security model of the web CORS and also integrate the caching mechanisms of DNS with those of HTTP.  These applications may be interested in </ins> using a different media type than traditional clients.  <ins> [[ This paragraph is to be removed when this document is published as an RFC ]] Note that these use cases are different than those in a </ins> similar protocol described at I-D.ietf-dnsop-dns-wireformat-http. The use case for that protocol is proxying DNS queries over HTTP instead of over DNS itself.  The use cases in this document all
Original text:
defined. The protocol must use a secure transport that meets the <del> requirements for modern https://. </del>  4.1.

Reviewer comments:
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: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid 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 wouldn'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 don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.

Revised text:
defined. The protocol must use a secure transport that meets the  <ins> requirements for modern HTTPS. </ins> 4.1.
Original text:
5.1. The media type is "application/dns-udpwireformat".  The body is the <del> DNS on-the-wire format is defined in RFC1035.  The body MUST be encoded with base64url RFC4648.  Padding characters for base64url MUST NOT be included. </del>  DNS API clients using the DNS wire format MAY have one or more EDNS(0) extensions RFC6891 in the request.

Reviewer comments:
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: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid 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 wouldn'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 don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.

Revised text:
5.1. The media type is "application/dns-udpwireformat".  The body is the  <ins> DNS on-the-wire format is defined in RFC1035. When using the GET method, the body MUST be encoded with base64url RFC4648.  Padding characters for base64url MUST NOT be included. When using the POST method, the body is not encoded. </ins> DNS API clients using the DNS wire format MAY have one or more EDNS(0) extensions RFC6891 in the request.
Original text:
At the time this is published, the response types are works in progress.  The only known response type is "application/dns- <del> udpwireformat", but it is likely that at least one JSON-based </del>  response format will be defined in the future. The DNS response for "application/dns-udpwireformat" in dnswire MAY

Reviewer comments:
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: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid 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 wouldn'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 don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.

Revised text:
At the time this is published, the response types are works in progress.  The only known response type is "application/dns-  <ins> udpwireformat", but it is possible that at least one JSON-based </ins> response format will be defined in the future. The DNS response for "application/dns-udpwireformat" in dnswire MAY
Original text:
7. <del> In order to satisfy the security requirements of DNS over HTTPS, this protocol MUST use HTTP/2 RFC7540 or its successors.  HTTP/2 enforces a modern TLS profile necessary for achieving the security requirements of this protocol. </del> This protocol MUST be used with https scheme URI RFC7230. <del> The messages in classic UDP based DNS RFC1035 are inherently unordered and have low overhead.  A competitive HTTP transport needs to support reordering, priority, parallelism, and header compression. For this additional reason, this protocol MUST use HTTP/2 RFC7540 or its successors. </del>  8.

Reviewer comments:
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: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid 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 wouldn'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 don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.

Revised text:
7.  This protocol MUST be used with https scheme URI RFC7230.  <ins> This protocol MUST use HTTP/2 RFC7540 or its successors in order to satisfy the security requirements of DNS over HTTPS.  Further, the messages in classic UDP based DNS RFC1035 are inherently unordered and have low overhead.  A competitive HTTP transport needs to support reordering, priority, parallelism, and header compression, all of which are supported by HTTP/2 RFC7540 or its successors. </ins> 8.
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 </del>  transport. Session level encryption has well known weaknesses with respect to

Reviewer comments:
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: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid 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 wouldn'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 don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.

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 </ins> transport. Session level encryption has well known weaknesses with respect to
Original text:
1. <del> 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. 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. </del> This document defines a specific protocol for sending DNS RFC1035 queries and getting DNS responses over HTTP RFC7540 using https:// (and therefore TLS RFC5246 security for integrity and

Reviewer comments:
This text is great justification to include in a charter, but this is a protocol specification and it really doesn't add much.
It seemed like the WG wanted the document to be shorter and more specific, so this feels good.

Revised text:
1.  This document defines a specific protocol for sending DNS RFC1035 queries and getting DNS responses over HTTP RFC7540 using https:// (and therefore TLS RFC5246 security for integrity and
Original text:
3.  The protocol described here bases its design on the following protocol requirements:

Reviewer comments:
… 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 DNS64 isn'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 don't need it in the RFC as long as the one future requirement (for formats) is still there. Please see PR

Revised text:
3. <ins> [[ RFC Editor: Please remove this entire section before publication. ]] </ins> The protocol described here bases its design on the following protocol requirements: