On Tue, Aug 20, 2019 at 9:39 AM Henderson, Karl <[email protected]> wrote:
> Hi Ben and Hugo, > > > > I wanted to follow up and see if my response to Paul satisfies your > concerns regarding ADoT being a new unspecified protocol? > > > > 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. > > > > Regards, > > Karl > > > > >Hi Paul, > > > > > >To further clarify, we are not suggesting a change to the DoT protocol > and are making liberal use of the final sentence in the Abstract of RFC7858 > and echoed in the Introduction of RFC8310: "It does not prevent future > applications of the protocol to recursive-to-authoritative traffic." > I interpret that sentence differently. I read that sentence to refer to "future applications" of the [RFC 7858] protocol in the context of a future standard, yet to be defined. In the absence of such a standard today, there is no defined way for a recursive server to speak DNS over TLS to an authoritative server. In your draft, I would characterize sections 3.1, 3.2, 3.3, 3.4, 3.7, 3.8, and 4.2 (a majority of the substantive text) as input to the standards development process for an ADoT standard, which is indeed part of this working group's charter. I think that this input is valuable, and will help us develop a more useful, complete standard for ADoT. However, I don't think drafts whose main purpose is to provide input to the standards process are generally appropriate for working group adoption. I fully expect that this working group will define a standards-track proposal for ADoT, with recommendations that cover the questions you've raised in those sections. I think readers might well be confused if both that standard and this draft were to be published with RFC numbers. > > > > >Regards, > > >Karl > > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
