Original text:
If the client encounters a mandatory parameter in an SVCB record it does not understand, it MUST NOT use that record to discover a <del> Designated Resolver.  The client can still use others records in the </del>  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 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" <del> parameter.  For example, if a DoH resolver provides provides a filtering service for one URI path, and a non-filtered service for another URI path, an attacker could select which of these services is used by modifying the "dohpath" parameter.  These attacks can be mitigated by providing separate resolver IP addresses or hostnames. </del>  While the IP address of the Unencrypted Resolver is often provisioned over insecure mechanisms, it can also be provisioned securely, such This document calls for the addition of "resolver.arpa" to the Special-Use Domain Names (SUDN) registry established by RFC6761. <del> This will allow resolvers to respond to queries directed at themselves rather than a specific domain name.  While this document uses "resolver.arpa" to return SVCB records indicating designated encrypted capability, the name is generic enough to allow future reuse for other purposes where the resolver wishes to provide information about itself to the client. The "resolver.arpa" SUDN is similar to "ipv4only.arpa" in that the querying client is not interested in an answer from the authoritative "arpa" name servers.  The intent of the SUDN is to allow clients to communicate with the Unencrypted Resolver much like "ipv4only.arpa" allows for client-to-middlebox communication.  For more context, see the rationale behind "ipv4only.arpa" in RFC8880. </del> IANA is requested to add an entry in "Transport-Independent Locally- Served DNS Zones" registry for 'resolver.arpa.' with the description

Reviewer comments:
Thanks for the painless read! Just a few trivial comments. Minor: The editorial commentary in the IANA Considerations section seems out of place -- generally IANA Considerations is, well, requests to IANA, not interesting and fun trivia about the resources being requested. But, IANA are smart enough to disregard the superflous material. Nits: , The client can still use others records in the same response s/others/other/ , provides provides s/provides//

Revised text:
If the client encounters a mandatory parameter in an SVCB record it does not understand, it MUST NOT use that record to discover a  <ins> Designated Resolver.  The client can still use other records in the </ins> 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 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"  <ins> parameter.  For example, if a DoH resolver provides a filtering service for one URI path, and a non-filtered service for another URI path, an attacker could select which of these services is used by modifying the "dohpath" parameter.  These attacks can be mitigated by providing separate resolver IP addresses or hostnames. </ins> While the IP address of the Unencrypted Resolver is often provisioned over insecure mechanisms, it can also be provisioned securely, such This document calls for the addition of "resolver.arpa" to the Special-Use Domain Names (SUDN) registry established by RFC6761.  IANA is requested to add an entry in "Transport-Independent Locally- Served DNS Zones" registry for 'resolver.arpa.' with the description