Hi Stephen, I agree we need a service discovery mechanism as specified in the considerations document. However, isn't this the same problem that both stub-to-resolver DoT and stub-to-resolver DoH face? If so, why do we accept these as protocols without this mechanism specified but we don't for ADoT?
Regards, Karl On 8/20/19, 9:46 AM, "Stephen Farrell" <[email protected]> wrote: Hiya, I'm not who you asked but... On 20/08/2019 14:38, Henderson, Karl wrote: > To be clear, we argue that ADoT is NOT a new protocol. ADoT is simply > DoT with a prepended A to disambiguate the path taken. Doesn't the need to figure out if an authoritative server does/doesn't do DoT before sending a query require something new that isn't in DoT and that must be part of ADoT? If so, ISTM that there is a new protocol spec of some sort needed even if 90% of the meat of that is the reference to DoT. (I guess maybe if the answer for discovery was "does it listen on 853" you could argue that's not new but I didn't think the WG had figured that out yet.) Cheers, S. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
