jiebi/CodeConvo huggingface dataset:
Code change:
Small tweak to text to make clearer that validation RRsets can be in any order.

Related discussion:
text: unsigned CNAME records that may have been synthesized in the response from a DNS resolver. <del> The subsequent RRsets MUST contain the full sequence of DNS records needed to authenticate the TLSA record set from the server's trust anchor.  Typically this means a sequence of DNSKEY and DS RRsets that cover all zones from the target zone containing the TLSA record set to the trust anchor zone. </del> <ins> The subsequent RRsets MUST contain the full set of DNS records needed to authenticate the TLSA record set from the server's trust anchor. Typically this means a set of DNSKEY and DS RRsets that cover all zones from the target zone containing the TLSA record set to the trust anchor zone.  The TLS client should be prepared to receive this set of RRsets in any order. </ins> Names that are aliased via CNAME and/or DNAME records may involve multiple branches of the DNS tree.  In this case, the authentication
Code change:
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.

Related discussion:
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> <ins> the same entity or cooperating entities. </ins> 1.
Code change:
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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <ins> to be defined to support validating designation as defined in </ins> authenticated. 4.
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
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> <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 <del> characteristics this specification details how to validate these </del> <ins> characteristics, this specification details how to validate these </ins> claims in validating. 4.3.
Code change:
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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <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> <del> Validation is then perfomed using either example-verify-public or </del> <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 <del> of DNS authority using a public resolver. </del> <ins> of DNS authority using an external resolver. </ins> 7.1.2.
Code change:
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.

Related discussion:
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> <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> <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> <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.
Code change:
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.

Related discussion:
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> <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.
Code change:
This should help with the case in DDR. See URL
Much better. Thanks for indulging me.

Related discussion:
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> <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.
Code change:
This should help with the case in DDR. See URL
Much better. Thanks for indulging me.

Related discussion:
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> <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 <del> name.  For example, SVCB records for a DNS service identified as ""dns1.example.com:9953"" would be located at </del> <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
Code change:
This should help with the case in DDR. See URL
Much better. Thanks for indulging me.

Related discussion:
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> <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
Code change:
This should help with the case in DDR. See URL
Much better. Thanks for indulging me.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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
Code change:
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.

Related discussion:
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
Code change:
This text does not read very well in its current form. Since it is two ideas, two sentences is best.

Related discussion:
text: The protocol must permit the addition of new formats for DNS queries and responses. <del> 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). </del> <ins> 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). </ins> The protocol must use a secure transport that meets the requirements for HTTPS.