jiebi/CodeConvo huggingface dataset:
Change:
I committed the change.
WHERE: All Candidates Discarded WHAT: Remove/rewrite the following: "(e.g., a candidate that contains a FQDN that fails to resolve)." WHY: It is unclear whether how/if FQDNs can be used in candidates. I think the text saying that the candidate cannot be used for some other reason is enough.
Implemented in One issue, though: The text says: "One consequence of this behavior is that in cases where ICE should fail, e.g., where both sides provide candidates with unsupported address families ICE will no longer fail immediately, and only fail when the aforementioned timer expires." ('unsupported address families' used to be 'unresolvable FQDNs', but the issue is the same) Q: If both endpoints provide candidates that can't be used, how is the timer going to help? No endpoint will send any connectivity checks, so there will be no peer-reflexive candidates.
LG with one minor text change

Discussion:
the peer agent if it does not know what to do with them.  For example, candidates may use an address family that the peer agent does not support, (e.g., a host candidate with an IPv6 address in a <del> NAT64 scenario), or may not be usable for some other reason (e.g., a candidate that contains a FQDN that fails to resolve). </del> <ins> NAT64 scenario), or may not be usable for some other reason. </ins> In these scenarios, when the candidates are discarded, the checklist at the peer agent will once again be empty, leading to immediate ICE

there are no such checklists, no action is necessary. One consequence of this behavior is that in cases where ICE should <del> fail, e.g., where both sides provide candidates with unresolvable FQDNs ICE will no longer fail immediately, and only fail when the aforementioned timer expires.  However, because most ICE scenarios require an extended period of time to determine failure, the fact that some specific scenarios no longer fail fast should have minimal application impact, if any. </del> <ins> fail, e.g., where both sides provide candidates with unsupported address families, ICE will no longer fail immediately, and only fail when the aforementioned timer expires.  However, because most ICE scenarios require an extended period of time to determine failure, the fact that some specific scenarios no longer fail fast should have minimal application impact, if any. </ins> Note also that the timer is potentially relevant to the ICE nomination procedure described in RFC8445, Section 8.1.1.  That
Change:
It's a lot of words, makes the sentence harder to read, and given that this is introductory text, doesn't really clarify the document. I also think we'd have to similarly rewrite several other paragraphs in the intro if we did this, so I'm not in favor of adding the suggested text.
Perhaps, there are a few places that talks about "all pairs", without clarifying that it is for a checklist. So, at the moment, one could read the Introduction saying that ICE failure is typically declared once all pairs associated with the whole session have failed, which is not true. I assume you agree with that? As you have indicated yourself, ICE failure can be declared when all pairs associated with ONE checklist have failed, even if there are other checklists in the Completed state. Anyway, I think my issue is clarified in the "Update to RFC8445" section, so in order to move the draft forward, I am willing to accept ( ) and then leave the Introduction text as it is. I guess one has to assume that the reader of the draft knows ICE well enough to understand when ICE failure etc takes place.
Right, this is non-normative text, so I think we can keep it simple here and be specific (as we already have done) in the 8445 update section.

Discussion:
form a list of candidate pairs, and then test each candidate pair to see if connectivity can be established.  If the test for a given pair fails, it is marked accordingly, and if all pairs have failed, the <del> overall ICE process is considered to have failed. </del> <ins> overall ICE process typically is considered to have failed. </ins> During the process of connectivity checks, additional candidates may be created as a result of successful inbound checks from the remote
Change:
See URL for details.
Looks good. It's probably good to also add a note, asking the RFC Editor to replace XXX with the Trickle RFC number, once published. Something like: [RFC EDITOR NOTE: Please replace RFC XXXX with the RFC number of once it has been published.]

Discussion:
5. <ins> [RFC EDITOR NOTE: Please replace RFC XXXX with the RFC number of draft-ietf-ice-trickle once it has been published.] Trickle ICE I-D.ietf-ice-trickle considers a similar problem, namely whether an ICE agent should allow a checklist to enter the Failed state if more candidates might still be provided by the remote peer. The solution, specified in I-D.ietf-ice-trickle, Section 8, is to wait until an end-of-candidates indication has been received before determining ICE failure. However, for the same reasons described above, the ICE agent may discover peer-reflexive candidates after it has received the end-of- candidates indication, and so the solution proposed by this document MUST still be used even when the ICE agent is using Trickle ICE. Note also that sending an end-of-candidates indication is only a SHOULD-strength requirement, which means that ICE agents will need to implement an backup mechanism to decide when all candidates have been received, typically a timer.  Accordingly, ICE agents MAY use the PAC timer to also serve as an end-of-candidates fallback. 6. </ins> The security considerations for ICE are defined in RFC8445.  This specification only recommends that ICE agents wait for a certain time of period before they declare ICE failure, and does not introduce new security considerations. <del> 6. </del> <ins> 7. </ins> This specification makes no requests to IANA.
Change:
…tion
Section 4.2, verified, calls out the entire cert check for validation, but section 4.3, opportunistic, only talks about skipping the IP validation. It has gone without saying that these are equivalent because the IP is the only thing about the cert being validated, but for implementors, does this mean they can skip the entire cert validation process (meaning the connection will be used even if other errors occur, such as the cert being expired)? I assume yes (no cert checking of any kind), but we should be specific.
I think it's up to implementations. If I look at the opportunistic profile in RFC 7858, it say: I think we should point to that and explain that it's open to the client to determine how opportunistic it wants to be
LGTM

Discussion:
RFC4291, whose identity cannot be safely confirmed using TLS certificates under most conditions. <del> Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as a mode in which clients do not validate the name of the resolver presented in the certificate.  Opportunistic Privacy similarly applies to DoQ RFC9250.  A client MAY use information from the SVCB record for "resolver.arpa" with this "opportunistic" approach (not validating the names presented in the SubjectAlternativeName field of the certificate) as long as the IP address of the Encrypted DNS Resolver does not differ from the IP address of the Unencrypted DNS Resolver.  Clients SHOULD use this mode only for resolvers using private or local IP addresses, since resolvers that use other addresses are able to provision TLS certificates for their addresses. </del> <ins> An Opportunistic Privacy Profile is defined for DoT in Section 4.1 of RFC7858 as a mode in which clients do not validate the name of the resolver presented in the certificate.  This Opportunistic Privacy Profile similarly applies to DoQ RFC9250.  For this profile, Section 4.1 of RFC7858 explains that clients might or might not validate the resolver; however, even if clients choose to perform some certificate validation checks, they will not be able to validate the names presented in the SubjectAlternativeName field of the certificate for private and local IP addresses. A client MAY use information from the SVCB record for "resolver.arpa" with this Opportunistic Privacy Profile as long as the IP address of the Encrypted DNS Resolver does not differ from the IP address of the Unencrypted DNS Resolver.  Clients SHOULD use this mode only for resolvers using private or local IP addresses, since resolvers that use other addresses are able to provision TLS certificates for their addresses. </ins> 5.
Change:
In 6.3 we say: "When performing discovery using resolver IP addresses, clients MUST use the IP address as the URI host for DoH requests." There are multiple IP addresses that may be in-play here. We should clarify which is "the IP address" in the case where the Designated Resolver and the Unencrypted Resolver do NOT share an IP. (I take it that this is the IP of the Unencrypted Resolver ?)
Good point!
LGTM

Discussion:
connections, or in the URI host for DoH requests. When performing discovery using resolver IP addresses, clients MUST <del> use the IP address as the URI host for DoH requests. </del> <ins> use the original IP address of the Unencrypted DNS Resolver as the URI host for DoH requests. </ins> Note that since IP addresses are not supported by default in the TLS SNI, resolvers that support discovery using IP addresses will need to
Change:
From Section 1 Introduction, it is not obvious if the two mechanisms mentioned in the section are alternative or complementary, and how they relate to the DoT, DoQ and DoH requirements introduced in the same section. Section 4 gets into details about DoT and DoQ using IP addresses - it would be good to explain a little more about it in the Intro section. In Section 5, the requirements seem to overlap with draft-ietf-add-svcb-dns. It would be good to further clarify the relationship between the two specifications. Finally, since multiple solutions are presented, some recommendations about when, how and why one mechanism should be used vs the other would be useful to the reader.
LGTM

Discussion:
(RA) options RFC8106, as well as manual configuration. This document defines two mechanisms for clients to discover <del> designated resolvers using DNS server Service Binding (SVCB, I- D.ietf-dnsop-svcb-https) records: </del> <ins> designated resolvers that support these encrypted protocols using DNS server Service Binding (SVCB, I-D.ietf-dnsop-svcb-https) records: </ins> When only an IP address of an Unencrypted DNS Resolver is known, the client queries a special use domain name (SUDN) RFC6761 to
Change:
The document was inconsistent, with the authenticated section saying same IP addresses MAY use opportunistic, but the opportunistic section saying the same IP address exception was for private IP addresses only.
Forgot to mention this is to address issue
From Eliot Lear: Can you explain the following statement? and that IP address is a private address (such as those defined in [RFC1918] I ask because it appears that you are using private addresses as some sort of security property. I recommend against that, not least of which is that end systems that are likely to deploy this stuff will have a wide ranging mishmosh of addressing plans, and of course, private network addresses don’t really have any positive security properties to speak of. The only aspect I can see is that one really has to be quite careful of including private network addresses in certificates. Of course, public trust anchors won’t allow it, but even private ones will have some difficulty. Your average bank might have multiple overlapping zones of trust - it’s a pretty hairy scene.
The intent of that section is to say that "if you were going to send this local IP address unencrypted traffic anyway, using encryption to that same IP address is a net improvement to the threat model." It certainly was not meant to imply that private addresses could be verified via the TLS cert SAN mechanism used for public addresses. I can try to rephrase this section to be more accurate. Please comment again if I missed the point.
In reviewing the opportunistic section, I see what you mean Eliot. The need to use "private IP" as a feature is not necessary since same-IP opportunistic discovery is permitted whether the address is private or not. However, the draft conflicted on that point. I have a PR to remove the local IP address as a decision branch and make the draft consistent.
With the PR merged, I am closing this issue.

Discussion:
There are situations where authenticated discovery of encrypted DNS configuration over unencrypted DNS is not possible.  This includes <del> Unencrypted Resolvers on non-public IP addresses whose identity cannot be confirmed using TLS certificates. </del> <ins> Unencrypted Resolvers on non-public IP addresses such as those defined in RFC1918 whose identity cannot be confirmed using TLS certificates. </ins> Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as a mode in which clients do not validate the name of the resolver

approach (not validating the names presented in the SubjectAlternativeName field of the certificate) as long as the IP address of the Encrypted Resolver does not differ from the IP address <del> of the Unencrypted Resolver, and that IP address is a private address (such as those defined in RFC1918).  This approach can be used for DoT or DoH. If the IP addresses of the Encrypted and Unencrypted Resolvers are not the same, or the shared IP address is not a private IP address, the client MUST NOT use the Encrypted Resolver opportunistically. </del> <ins> of the Unencrypted Resolver.  This approach can be used for any encrypted DNS protocol that uses TLS. </ins> 5.
Change:
This PR addresses issues and to ensure smoother implementation and deployment (avoid name resolution deadlock and clearly illustrate why "." cannot be used for target names when discovering Designated Resolvers using the URL 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!

Discussion:
Binding (SVCB) records for DNS Servers, defined by I-D.schwartz-svcb- dns. <del> The following is an example of an SVCB record describing a DoH server: </del> <ins> The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.example.net": </ins> <del> The following is an example of an SVCB record describing a DoT server: </del> <ins> The following is an example of an SVCB record describing a DoT server discovered by querying for "_dns.example.net": </ins> If multiple Designated Resolvers are available, using one or more encrypted DNS protocols, the resolver deployment can indicate a preference using the priority fields in each SVCB record I-D.ietf- dnsop-svcb-https. <ins> 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. </ins> 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

client issues a query for "_dns.resolver.arpa" with the SVCB resource record type (64) I-D.ietf-dnsop-svcb-https. <ins> 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. The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.resolver.arpa": The following is an example of an SVCB record describing a DoT server discovered by querying for "_dns.resolver.arpa": </ins> If the recursive resolver that receives this query has one or more Designated Resolvers, it will return the corresponding SVCB records. When responding to these special queries for "dns://resolver.arpa",
Change:
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.

Discussion:
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 <del> 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 </del> <ins> 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 </ins> 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 <del> records associated with the Unencrypted Resolver (bootstrapping). </del> <ins> records associated with one or more Encrypted Resolvers the Unencrypted Resolver has designated for use when support for DNS encryption is requested (bootstrapping). </ins> <del> When the hostname of an encrypted DNS server is known, the client </del> <ins> When the hostname of an Encrypted Resolver is known, the client </ins> 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
Change:
Addressing
Once it's published, we should reference the official draft for draft-schwartz-svcb-dns

Discussion:
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 <del> Binding (SVCB) records for DNS Servers, defined by I-D.schwartz-svcb- dns. </del> <ins> 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. </ins> The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.example.net":

This document focuses on discovering DoH and DoT Designated Resolvers.  Other protocols can also use the format defined by I- <del> D.schwartz-svcb-dns.  However, if any protocol does not involve some </del> <ins> D.ietf-add-svcb-dns.  However, if any protocol does not involve some </ins> form of certificate validation, new validation mechanisms will need to be defined to support validating designation as defined in authenticated.
Change:
We only require you to check the designated resolver IP so this text is now incorrect.
lgtm
How's this?
lgtm v2

Discussion:
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 <del> certificate that claims ownership over both resolvers. </del> <ins> certificate that claims ownership over the IP address for the original designating resolver. </ins> 1.1.
Change:
DDR designations, especially for/to non-public IP addresses, will break if cached across networks. Requirements and considerations need to be added to ensure correct behavior.
Closing with PR

Discussion:
Resolver without some sort of validation, such as the two methods defined in this document or a future mechanism. <ins> 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). </ins> 4.2. Verified Discovery is a mechanism that allows automatic use of a
Change:
To address
We should clarify that if a client doesn’t understand a mandatory parameter in an SVCB record, it MUST NOT use it as normal DoT/DoH, since it could be misinterpreting the meaning.
Concrete example might be with: "mandatory=foo,dohpath foo=[...] alpn=h2 dohpath=[...]" Where clients which don't know how to handle "foo" must ignore that RR in the RRset, which might also contain other SVCB RRs for just DoH.

Discussion:
preference using the priority fields in each SVCB record I-D.ietf- dnsop-svcb-https. <ins> If the client encounters a mandatory parameter in an SVCB record it does not understand, it MUST NOT use that record to discover a Designated Resolver.  The client can still use others records in the same response if the client can understand all of their mandatory parameters.  This allows future encrypted deployments to simultaneously support protocols even if a given client is not aware of all those protocols.  For example, if the Unencrypted Resolver returns three SVCB records, one for DoH, one for DoT, and one for a yet-to-exist protocol, a client which only supports DoH and DoT should be able to use those records while safely ignoring the third record. </ins> 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.