jiebi/TextFlow huggingface dataset:
Original text:
for encrypted DNS protocols when the name of an encrypted resolver is known.  This mechanism is designed to be limited to cases where unencrypted resolvers and their designated resolvers are operated by <del> the same entity. </del>  1.

Reviewer comments:
changed equivalence instances for designated and added the possibility of multiple entities so long as they are cooperating This is to address issue
I am not sure we need to introduce "Equivalence" nor to develop who is operating the resolvers - especially as many entities may be involved in the operation of a resolver. I am not sure we need to introduce Equivalence. If so I would propose the following text: OLD: "Equivalence" in this context means that the resolvers are operated by the same entity; for example, the resolvers are accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. NEW: "Equivalence" in this context means that Encrypted and Unencrypted resolvers are either accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. If Equivalence is not introduced - which I prefer -I would propose the following text: NEW: In this context the discovery process ensures that Encrypted and Unencrypted resolvers are either accessible on the same IP address, or there is a certificate that claims ownership over both resolvers.
I agree that we do not need to introduce "equivalence" in this document. It is a remnant of the DEER draft DDR is based on. Per WG discussion, we want to use the term "designation" to describe the relationship between the unencrypted resolver and the encrypted resolver to which the client is transferring. I'm editing accordingly. I have also added references to the possibility of multiple "entities" as that is definitely possible. (PR coming later tonight)
good.

Revised text:
for encrypted DNS protocols when the name of an encrypted resolver is known.  This mechanism is designed to be limited to cases where unencrypted resolvers and their designated resolvers are operated by  <ins> the same entity or cooperating entities. </ins> 1.
Original text:
Both of these approaches allow clients to confirm that a discovered Encrypted Resolver is designated by the originally provisioned <del> resolver.  "Equivalence" in this context means that the resolvers are operated by the same entity; for example, the resolvers are accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. </del>  1.1.

Reviewer comments:
changed equivalence instances for designated and added the possibility of multiple entities so long as they are cooperating This is to address issue
I am not sure we need to introduce "Equivalence" nor to develop who is operating the resolvers - especially as many entities may be involved in the operation of a resolver. I am not sure we need to introduce Equivalence. If so I would propose the following text: OLD: "Equivalence" in this context means that the resolvers are operated by the same entity; for example, the resolvers are accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. NEW: "Equivalence" in this context means that Encrypted and Unencrypted resolvers are either accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. If Equivalence is not introduced - which I prefer -I would propose the following text: NEW: In this context the discovery process ensures that Encrypted and Unencrypted resolvers are either accessible on the same IP address, or there is a certificate that claims ownership over both resolvers.
I agree that we do not need to introduce "equivalence" in this document. It is a remnant of the DEER draft DDR is based on. Per WG discussion, we want to use the term "designation" to describe the relationship between the unencrypted resolver and the encrypted resolver to which the client is transferring. I'm editing accordingly. I have also added references to the possibility of multiple "entities" as that is definitely possible. (PR coming later tonight)
good.

Revised text:
Both of these approaches allow clients to confirm that a discovered Encrypted Resolver is designated by the originally provisioned  <ins> resolver.  "Designated" in this context means that the resolvers are operated by the same entity or cooperating entities; for example, the resolvers are accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. </ins> 1.1.
Original text:
Resolvers.  Other protocols can also use the format defined by I- D.schwartz-svcb-dns.  However, if any protocol does not involve some form of certificate validation, new validation mechanisms will need <del> to be defined to support validating equivalence as defined in </del>  authenticated. 4.

Reviewer comments:
changed equivalence instances for designated and added the possibility of multiple entities so long as they are cooperating This is to address issue
I am not sure we need to introduce "Equivalence" nor to develop who is operating the resolvers - especially as many entities may be involved in the operation of a resolver. I am not sure we need to introduce Equivalence. If so I would propose the following text: OLD: "Equivalence" in this context means that the resolvers are operated by the same entity; for example, the resolvers are accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. NEW: "Equivalence" in this context means that Encrypted and Unencrypted resolvers are either accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. If Equivalence is not introduced - which I prefer -I would propose the following text: NEW: In this context the discovery process ensures that Encrypted and Unencrypted resolvers are either accessible on the same IP address, or there is a certificate that claims ownership over both resolvers.
I agree that we do not need to introduce "equivalence" in this document. It is a remnant of the DEER draft DDR is based on. Per WG discussion, we want to use the term "designation" to describe the relationship between the unencrypted resolver and the encrypted resolver to which the client is transferring. I'm editing accordingly. I have also added references to the possibility of multiple "entities" as that is definitely possible. (PR coming later tonight)
good.

Revised text:
Resolvers.  Other protocols can also use the format defined by I- D.schwartz-svcb-dns.  However, if any protocol does not involve some form of certificate validation, new validation mechanisms will need  <ins> to be defined to support validating designation as defined in </ins> authenticated. 4.
Original text:
resolvers frequently support a local "hosts file" that preempts query forwarding, and most DNS forwarders and full resolvers can also serve responses from a local zone file.  Other standardized hybrid <del> resolution behaviors include Local Root RFC8806, mDNS RFC6762, and NXDOMAIN synthesis for .onion RFC7686. </del>  In many network environments, the network offers clients a DNS server (e.g.  DHCP OFFER, IPv6 Router Advertisement).  Although this server

Reviewer comments:
Includes: Text adjustments for grammar and clarity Replacing "public" resolver with "external" Changes to references and blockquotes Made diagrams narrower
NAME NAME Please review
Changes look good to me.

Revised text:
resolvers frequently support a local "hosts file" that preempts query forwarding, and most DNS forwarders and full resolvers can also serve responses from a local zone file.  Other standardized hybrid  <ins> resolution behaviors include RFC8806, RFC6762, and RFC7686. </ins> In many network environments, the network offers clients a DNS server (e.g.  DHCP OFFER, IPv6 Router Advertisement).  Although this server
Original text:
3. <del> The protocol in this document allows the domain owner to create a split-horizon DNS.  Other entities which do not own the domain are detected by the client.  Thus, DNS filtering is not enabled by this </del>  protocol. 4.

Reviewer comments:
Includes: Text adjustments for grammar and clarity Replacing "public" resolver with "external" Changes to references and blockquotes Made diagrams narrower
NAME NAME Please review
Changes look good to me.

Revised text:
3.  <ins> The protocol in this document is designed to support the ability of a domain owner to create or authorize a split-horizon view of their domain.  The protocol does not support split-horizon views created by any other entity.  Thus, DNS filtering is not enabled by this </ins> protocol. 4.
Original text:
4.1. There are several DHCP options that convey local domain hints of <del> different kinds.  The most directly relevant is "RDNSS Selection" RFC6731, which provides "a list of domains ... about which the RDNSS has special knowledge", along with a "High", "Medium", or "Low" preference for each name.  The specification notes the difficulty of relying on these hints without validation: Other local domain hints in DHCP include the "Domain Name" RFC2132, "Access Network Domain Name" RFC5986, "Client FQDN" RFC4704, and "Name Service Search" RFC2937 options.  This specification may help clients to interpret these hints.  For example, a rogue DHCP server could use the "Client FQDN" option to assign a client the name </del>  "www.example.com" in order to prevent the client from reaching the true "www.example.com".  A client could use this specification to check the network's authority over this name, and adjust its behavior

Reviewer comments:
Includes: Text adjustments for grammar and clarity Replacing "public" resolver with "external" Changes to references and blockquotes Made diagrams narrower
NAME NAME Please review
Changes look good to me.

Revised text:
4.1. There are several DHCP options that convey local domain hints of  <ins> different kinds.  The most directly relevant is RFC6731, which provides "a list of domains ... about which the RDNSS has special knowledge", along with a "High", "Medium", or "Low" preference for each name.  The specification notes the difficulty of relying on these hints without validation: Other local domain hints in DHCP include the RFC2132, RFC5986, "Client FQDN" RFC4704, and RFC2937 options.  This specification may help clients to interpret these hints.  For example, a rogue DHCP server could use the "Client FQDN" option to assign a client the name </ins> "www.example.com" in order to prevent the client from reaching the true "www.example.com".  A client could use this specification to check the network's authority over this name, and adjust its behavior
Original text:
SSID, IP subnet assigned, DNS server IP address or name, and other similar mechanisms.  For example, one existing implementation determines the host has joined an internal network because the DHCP- <del> assigned IP address belongs to the company's IP address (as assigned by the regional IP addressing authority) and the DHCP-advertised DNS IP address is one used by IT at that network.  Other mechanisms exist in other products but are not interesting to this specification; rather what is interesting is this step to determine "we have joined the internal corporate network" occurred and the DNS server is configured as authoritative for certain DNS zones (e.g., *.example.com). </del>  Because a rogue network can simulate all or most of the above <del> characteristics this specification details how to validate these </del>  claims in validating. 4.3.

Reviewer comments:
Includes: Text adjustments for grammar and clarity Replacing "public" resolver with "external" Changes to references and blockquotes Made diagrams narrower
NAME NAME Please review
Changes look good to me.

Revised text:
SSID, IP subnet assigned, DNS server IP address or name, and other similar mechanisms.  For example, one existing implementation determines the host has joined an internal network because the DHCP-  <ins> assigned IP address belongs to the company's IP range (as assigned by the regional IP addressing authority) and the DHCP-advertised DNS IP address is one used by IT at that network.  Other mechanisms exist in other products but are not interesting to this specification; rather what is interesting is this step to determine "we have joined the internal corporate network" occurred and the DNS server is configured as authoritative for certain DNS zones (e.g., ). </ins> Because a rogue network can simulate all or most of the above  <ins> characteristics, this specification details how to validate these </ins> claims in validating. 4.3.
Original text:
7. <del> Two examples are shown below.  The first example showing an company with an internal-only DNS server resolving the entire zone for that company (e.g., *.example.com) the second example resolving only a subdomain of the company's zone (e.g., *.internal.example.com). </del>  7.1.

Reviewer comments:
Includes: Text adjustments for grammar and clarity Replacing "public" resolver with "external" Changes to references and blockquotes Made diagrams narrower
NAME NAME Please review
Changes look good to me.

Revised text:
7.  <ins> Two examples are shown below.  The first example shows a company with an internal-only DNS server that claims the entire zone for that company (e.g., ).  In the second example, the internal servers resolves only a subdomain of the company's zone (e.g., ). </ins> 7.1.
Original text:
Today, on the Internet it publishes two NS records, "ns1.example.com" and "ns2.example.com". <del> The host and network first need mutual support one of the mechanisms described in learning.  Shown in fig-learn is learning using DNR and PvD. </del>  <del> Validation is then perfomed using either example-verify-public or </del>  example-verify-dnssec. 7.1.1. The figure below shows the steps performed to verify the local claims <del> of DNS authority using a public resolver. </del>  7.1.2.

Reviewer comments:
Includes: Text adjustments for grammar and clarity Replacing "public" resolver with "external" Changes to references and blockquotes Made diagrams narrower
NAME NAME Please review
Changes look good to me.

Revised text:
Today, on the Internet it publishes two NS records, "ns1.example.com" and "ns2.example.com".  <ins> First, the host and network both need to support one of the discovery mechanisms described in learning. fig-learn shows discovery using DNR and PvD. </ins>  <ins> Validation is then perfomed using either example-verify-external or </ins> example-verify-dnssec. 7.1.1. The figure below shows the steps performed to verify the local claims  <ins> of DNS authority using an external resolver. </ins> 7.1.2.
Original text:
7.2. <del> A subdomain can also be used for all internal DNS names (e.g., the zone internal.example.com exists only on the internal DNS server). For successful validation described in this document the the internal DNS server will need a certificate signed by a CA trusted by the client. </del>  <del> For such a name internal.example.com the message flow is similar to internal-only the difference is that queries for hosts not within the subdomain (www.example.com) are sent to the public resolver rather than resolver for internal.example.com. </del>  8.

Reviewer comments:
Includes: Text adjustments for grammar and clarity Replacing "public" resolver with "external" Changes to references and blockquotes Made diagrams narrower
NAME NAME Please review
Changes look good to me.

Revised text:
7.2.  <ins> In many split-horizon deployments, all non-public domain names are placed in a separate child zone (e.g., ).  In this configuration, the message flow is similar to internal- only, except that queries for hosts not within the subdomain (e.g., </ins>  <ins> ) are sent to the external resolver rather than resolver for internal.example.com. As in internal-only, the internal DNS server will need a certificate signed by a CA trusted by the client. </ins> 8.
Original text:
ensure that names under the split-horizon are correctly signed or place them in an unsigned zone. <del> If an internal zone name (e.g., internal.example.com) is used with this specification and a public certificate is obtained for validation, that internal zone name will exist in Certificate Transparency logs RFC9162.  It should be noted, however, that this specification does not leak individual host names (e.g., www.internal.example.com) into the Certificate Transparancy logs or to public DNS resolvers. </del>  10.

Reviewer comments:
Includes: Text adjustments for grammar and clarity Replacing "public" resolver with "external" Changes to references and blockquotes Made diagrams narrower
NAME NAME Please review
Changes look good to me.

Revised text:
ensure that names under the split-horizon are correctly signed or place them in an unsigned zone.  <ins> If an internal zone name (e.g., ) is used with this specification and a public certificate is obtained for validation, that internal zone name will exist in Certificate Transparency logs RFC9162.  It should be noted, however, that this specification does not leak individual host names (e.g., ) into the Certificate Transparency logs or to external DNS resolvers. </ins> 10.
Original text:
3. <del> Names are formed using Port-Prefix Naming (Section 2.3 of SVCB), with a scheme of "dns".  For example, SVCB records for a DNS service identified as ""dns1.example.com"" would be located at ""_dns.dns1.example.com"". </del>  3.1.

Reviewer comments:
This should help with the case in DDR. See URL
Much better. Thanks for indulging me.

Revised text:
3.  <ins> SVCB record names (i.e.  QNAMEs) are formed using Port-Prefix Naming (Section 2.3 of SVCB), with a scheme of "dns".  For example, SVCB records for a DNS service identified as ""dns1.example.com"" would be queried at ""_dns.dns1.example.com"". In some use cases, the name used for retrieving these DNS records is different from the server identity used to authenticate the secure transport.  To distinguish them, we use the following terms: Binding authority - The service name (Section 1.4 of SVCB) and optional port number used as input to Port-Prefix Naming. Authentication name - The name used for secure transport authentication.  It must be a DNS hostname or a literal IP address.  Unless otherwise specified, it is the service name from the binding authority. </ins> 3.1.
Original text:
default of 53).  DNS URIs normally omit the authority, or specify an IP address, but a hostname and non-default port number are allowed. <del> When a non-default port number is part of a service identifier, Port- </del>  Prefix Naming places the port number in an additional a prefix on the <del> name.  For example, SVCB records for a DNS service identified as ""dns1.example.com:9953"" would be located at </del>  ""_9953._dns.dns1.example.com"".  If two DNS services operating on different port numbers provide different behaviors, this arrangement allows them to preserve the distinction when specifying alternative

Reviewer comments:
This should help with the case in DDR. See URL
Much better. Thanks for indulging me.

Revised text:
default of 53).  DNS URIs normally omit the authority, or specify an IP address, but a hostname and non-default port number are allowed.  <ins> When the binding authority specifies a non-default port number, Port- </ins> Prefix Naming places the port number in an additional a prefix on the  <ins> name.  For example, if the binding authority is ""dns1.example.com:9953"", the client would query for SVCB records at </ins> ""_9953._dns.dns1.example.com"".  If two DNS services operating on different port numbers provide different behaviors, this arrangement allows them to preserve the distinction when specifying alternative
Original text:
presentation and wire format) is a relative URI Template RFC6570, normally starting with "/".  If the "alpn" SvcParamKey indicates support for HTTP, clients MAY construct a DNS over HTTPS URI Template <del> by combining the prefix "https://", the service name, the port from the "port" key if present, and the "dohpath" value.  (The DNS service's original port number MUST NOT be used.) </del>  Clients SHOULD NOT query for any "HTTPS" RRs when using the constructed URI Template.  Instead, the SvcParams and address records

Reviewer comments:
This should help with the case in DDR. See URL
Much better. Thanks for indulging me.

Revised text:
presentation and wire format) is a relative URI Template RFC6570, normally starting with "/".  If the "alpn" SvcParamKey indicates support for HTTP, clients MAY construct a DNS over HTTPS URI Template  <ins> by combining the prefix "https://", the authentication name, the port from the "port" key if present, and the "dohpath" value.  (The binding authority's port number MUST NOT be used.) </ins> Clients SHOULD NOT query for any "HTTPS" RRs when using the constructed URI Template.  Instead, the SvcParams and address records
Original text:
This section considers an adversary who can add or remove responses to the SVCB query. <del> Clients MUST authenticate the server to its name during secure transport establishment.  This name is the hostname used to construct the original SVCB query, and cannot be influenced by the SVCB record contents.  Accordingly, this draft does not mandate the use of DNSSEC.  This draft also does not specify how clients authenticate the name (e.g. selection of roots of trust), which might vary according to the context. </del>  Although this adversary cannot alter the authentication name of the service, it does have control of the port number and "dohpath" value.

Reviewer comments:
This should help with the case in DDR. See URL
Much better. Thanks for indulging me.

Revised text:
This section considers an adversary who can add or remove responses to the SVCB query.  <ins> During secure transport establishment, clients MUST authenticate the server to its authentication name, which is not influenced by the SVCB record contents.  Accordingly, this draft does not mandate the use of DNSSEC.  This draft also does not specify how clients authenticate the name (e.g. selection of roots of trust), which might vary according to the context. </ins> Although this adversary cannot alter the authentication name of the service, it does have control of the port number and "dohpath" value.
Original text:
the delegation, even though they are not themselves authoritative data.  "[Resource records] which are not part of the authoritative data [of the zone], and are address resource records for the [name servers in subzones].  These RRs are only necessary if the name

Reviewer comments:
We don't seem to have defined "lame delegation", which is a term that is used all the time. It's in RFC 1912. Should we add it?
Yes.

Revised text:
the delegation, even though they are not themselves authoritative data. <ins> "A lame delegations exists when a nameserver is delegated responsibility for providing nameservice for a zone (via NS records) but is not performing nameservice for that zone (usually because it is not set up as a primary or secondary for the zone)." (Definition from RFC1912, Section 2.8) </ins> "[Resource records] which are not part of the authoritative data [of the zone], and are address resource records for the [name servers in subzones].  These RRs are only necessary if the name
Original text:
An instruction is a Service Discovery Instruction if it contains  2.3.1.2. An instruction is a Service Description Instruction if, for the

Reviewer comments:
Update Service Discovery Instruction text to address Esko Dijk's last call comments. This fixes a bogus reference, removes a confusing double negative, and splits the text hierarchically in a way that hopefully makes more sense.

Revised text:
An instruction is a Service Discovery Instruction if it contains <ins> Note that there can be more than one Service Discovery Instruction for the same name if the SRP requestor is advertising more than one service of the same type, or is changing the target of a PTR RR.  For each such PTR RR add or remove, the above constraints must be met. </ins> 2.3.1.2. An instruction is a Service Description Instruction if, for the