Draft: draft-ietf-add-ddr

Commentary: changed equivalence instances for designated and 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 references to the possibility of multiple " entities " as that is definitely possible . ( PR coming later tonight ) 
 good .
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.
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.
Both of these approaches allow clients to confirm that a discovered
Encrypted Resolver is designated by the originally provisioned
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.
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.
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 equivalence 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.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.