jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-add-ddr

Commentary: DDR designations , especially for / to non - public IP addresses , will break if cached across networks . Requirements and considerations need to be to ensure correct behavior . 
 Closing with PR
A client MUST NOT use a Designated Resolver designated by one
Unencrypted Resolver in place of another Unencrypted Resolver.  As
these are known only by IP address, this means each unique IP address
used for unencrypted DNS requires its own designation discovery.
This ensures queries are being sent to a party designated by the
resolver originally being used.
Generally, clients also SHOULD NOT reuse the Designated Resolver
discovered from an Unencrypted Resolver over one network connection
in place of the same Unencrypted Resolver on another network
connection.  Instead, clients SHOULD repeat the discovery process on
the other network connection.
However, if a given Unencrypted Resolver designates a Designated
Resolver that uses a public IP address and can be verified using the
mechanism described in verified, it MAY be used on different network
connections so long as the subsequent connections over other networks
can also be successfully verified using the mechanism described in
verified.  This is a tradeoff between performance (by having no delay
in establishing an encrypted DNS connection on the new network) and
functionality (if the Unencrypted Resolver intends to designate
different Designated Resolvers based on the network from which
clients connect).
Draft: draft-ietf-add-ddr

Commentary: We only require you to check the designated resolver IP so this text is now incorrect . 
 lgtm 
 How 's this ? 
 lgtm v2
Both of these approaches allow clients to confirm that a discovered
Encrypted Resolver is designated by the originally provisioned
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.
Both of these approaches allow clients to confirm that a discovered
Encrypted Resolver is designated by the originally provisioned
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 the IP address for the
original designating resolver.
Draft: draft-ietf-add-ddr

Commentary: does this work for you ? 
 OK , so I said LGTM , but how does a server know that it is such a server ? Ca n't I just publish a random DDR record for 1.1.1.1 ? 
 As I mentioned in the session , this is partly covered in SVCB - DNS , but perhaps we need a tighter rule . I 've opened an issue to discuss it : I 'm not entirely sure which draft this kind of text ought to go in . If you think this logic applies beyond DDR ( e.g. in ADoT cases ) , then it probably should go in the SVCB - DNS draft . Otherwise , maybe DDR is the place . 
 for security considerations , I 'm OK with multiple drafts having warnings . I think this particular attack should be mentioned in DDR , since other uses of DNS SVCB could be over more trusted channels . 
 if your resolver responds to , then we expect the address of the resolver I asked to be covered in the cert . So , if I send a packet to 1.1.1.1 , 1.1.1.1 has to be covered . So , if you just provide a " random " DDR record in response to , you can only point to some resolver that has your IP address in its cert , which presumably is sufficient coordination for the resolver to " know " it has this set up . 
 Right . Good point . 
 As mentioned at the microphone , if we are to allow the query - path to be specified in the clear like this , we need to require that servers not have different responses with different query paths . 
 LGTM
DoH resolvers that allow discovery using DNS SVCB answers over
unencrypted DNS MUST NOT provide differentiated behavior based on the
HTTP path alone, since an attacker could modify the "dohpath"
parameter.
Draft: draft-ietf-add-ddr

Commentary: Addressing 
 Once it 's published , we should reference the official draft for draft - schwartz - svcb - dns
When a client discovers Designated Resolvers, it learns information
such as the supported protocols, ports, and server name to use in
certificate validation.  This information is provided in Service
Binding (SVCB) records for DNS Servers, defined by I-D.schwartz-svcb-
dns.
When a client discovers Designated Resolvers, it learns information
such as the supported protocols, ports, and server name to use in
certificate validation.  This information is provided in Service
Binding (SVCB) records for DNS Servers.  The formatting of these
records, including the DNS-unique parameters such as "dohpath", are
defined by I-D.ietf-add-svcb-dns.
This document focuses on discovering DoH and DoT Designated
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
to be defined to support validating designation as defined in
authenticated.
This document focuses on discovering DoH and DoT Designated
Resolvers.  Other protocols can also use the format defined by I-
D.ietf-add-svcb-dns.  However, if any protocol does not involve some
form of certificate validation, new validation mechanisms will need
to be defined to support validating designation as defined in
authenticated.
Draft: draft-ietf-add-ddr

Commentary: Per on - list feedback by   :
Because this query is for an SUDN, which no entity can claim
ownership over, the SVCB response MUST NOT use the "." value for the
SvcDomainName.  Instead, the domain name used for DoT or used to
construct the DoH template MUST be provided.
Because this query is for an SUDN, which no entity can claim
ownership over, the SVCB response MUST NOT use the "." value for the
TargetName.  Instead, the domain name used for DoT or used to
construct the DoH template MUST be provided.
Draft: draft-ietf-add-ddr

Commentary: I 've made a few changes to terms used to correct some accidental lies : the starting IP address could be of an Encrypted Resolver , but does not have to be , discovery by SVCB may discover one or more resolver which may or may not be the original resolver , etc .
This document defines Discovery of Designated Resolvers (DDR), a
mechanism for DNS clients to use DNS records to discover a resolver's
encrypted DNS configuration.  This mechanism can be used to move from
unencrypted DNS to encrypted DNS when only the IP address of an
encrypted resolver is known.  It can also be used to discover support
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
the same entity or cooperating entities.
This document defines Discovery of Designated Resolvers (DDR), a
mechanism for DNS clients to use DNS records to discover a resolver's
encrypted DNS configuration.  This mechanism can be used to move from
unencrypted DNS to encrypted DNS when only the IP address of a
resolver is known.  It can also be used to discover support 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
the same entity or cooperating entities.
When only an IP address of an Unencrypted Resolver is known, the
client queries a special use domain name to discover DNS SVCB
records associated with the Unencrypted Resolver (bootstrapping).
When the hostname of an encrypted DNS server is known, the client
requests details by sending a query for a DNS SVCB record.  This
can be used to discover alternate encrypted DNS protocols
supported by a known server, or to provide details if a resolver
name is provisioned by a network (encrypted).
When only an IP address of an Unencrypted Resolver is known, the
client queries a special use domain name to discover DNS SVCB
records associated with one or more Encrypted Resolvers the
Unencrypted Resolver has designated for use when support for DNS
encryption is requested (bootstrapping).
When the hostname of an Encrypted Resolver is known, the client
requests details by sending a query for a DNS SVCB record.  This
can be used to discover alternate encrypted DNS protocols
supported by a known server, or to provide details if a resolver
name is provisioned by a network (encrypted).
Draft: draft-ietf-add-ddr

Commentary: This PR addresses issues and to ensure smoother implementation and deployment ( avoid name resolution deadlock and clearly illustrate why " . " can not be used for target names when discovering Designated Resolvers using the SUDN ) . 
 The existing examples in the document all use the " . " for the SvcDomainName . Per the SVCB draft section 2.5.2 , this would mean that queries for the SUDN that contain this value ( " . " ) would mean that the DoH template should use the SUDN as the domain name . While the examples do not query the SUDN , meaning the examples themselves are not erroneous , there is no useful example of the SUDN case . We need to add some examples showing an SUDN query response that carries the DoH domain name in the SvcDomainName field instead of the " . " . 
 RFC8484 section 10 , para 3 talks about the need for servers to ensure client do not need DNS lookups to validate the server 's certificate to avoid deadlocks . DDR should reference this and reaffirm the need to have resolvers help clients avoid this deadlock . 
 Thanks ! These examples are very useful !
To avoid name lookup deadlock, Designated Resolvers SHOULD follow the
guidance in Section 10 of RFC8484 regarding the avoidance of DNS-
based references that block the completion of the TLS handshake.
Because this query is for an SUDN, which no entity can claim
ownership over, the SVCB response MUST NOT use the "." value for the
SvcDomainName.  Instead, the domain name used for DoT or used to
construct the DoH template MUST be provided.
Draft: draft-ietf-add-ddr

Commentary: Changed 2 instances of DEER to DDR 
 I was so focused on finding " equivalent " that I missed a couple deer apparently . Thank you !
A DNS client that already knows the name of an Encrypted Resolver can
use DEER to discover details about all supported encrypted DNS
protocols.  This situation can arise if a client has been configured
to use a given Encrypted Resolver, or if a network provisioning
protocol (such as DHCP or IPv6 Router Advertisements) provides a name
for an Encrypted Resolver alongside the resolver IP address.
A DNS client that already knows the name of an Encrypted Resolver can
use DDR to discover details about all supported encrypted DNS
protocols.  This situation can arise if a client has been configured
to use a given Encrypted Resolver, or if a network provisioning
protocol (such as DHCP or IPv6 Router Advertisements) provides a name
for an Encrypted Resolver alongside the resolver IP address.
Resolver deployments that support DEER are advised to consider the
following points.
Resolver deployments that support DDR are advised to consider the
following points.