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
On Aug 15, 2019, at 12:24 PM, Henderson, Karl
wrote:
>
> To be clear, ADoT is not a new standard. This is simply DNS over TLS as
> specified in RFC7858,
RFC 7858 makes it clear that it is for stub-to-recursive. That is called out in
the Abstract and the Introduction.
> further defined as
To be clear, ADoT is not a new standard. This is simply DNS over TLS as
specified in RFC7858, further defined as ADoT in
https://tools.ietf.org/html/draft-hoffman-dns-terminology-ter-02, and again in
this draft in the introduction “…this document's scope is the
recursive-to-authoritative
Hi DPRIVE,
+1 on not adopting deployment guidelines for standards which dont exist.
So, this gives us an "order of approval". Indeed, it may mean that the AHoT op
doc is never an RFC. Whatever.
(and here I continue to wholly agreeing with you, but waffle on because I think
this is
Hi Stephen,
The intent is to be both descriptive (outlining the problem space and things
that need to be considered for robust deployment) and prescriptive in areas we
feel are necessary (i.e. TLS 1.3 SHOULD be preferred over TLS 1.2...). This is
in line with the other RFCs noted earlier
Hi Karl,
On 15/08/2019 14:07, Henderson, Karl wrote:
> Stephen,
>
> Thanks for your thorough and thoughtful review.
>
> To answer question #0, we are aiming for RFC with Informational
> category. This is in line with other operational considerations such
> as RFC2541->RFC6781 and RFC4472.
Ok,
Stephen,
Thanks for your thorough and thoughtful review.
To answer question #0, we are aiming for RFC with Informational category. This
is in line with other operational considerations such as RFC2541->RFC6781 and
RFC4472.
I will discuss your other questions and suggestion for a non-operator
Hi DPRIVE,
Firstly, I concur with Stephen Farrell's comments.
I support the document and further work on it. My comments are:
1.1.1
spelling: proection -> protection
"Initial deployments of ADoT may offer an immediate expansion of the
attack surface (additional port, transport
> -Original Message-
> From: dns-privacy On Behalf Of Brian
> Haberman
> Sent: Wednesday, August 14, 2019 4:40 PM
> To: dns-privacy@ietf.org
> Subject: [EXTERNAL] [dns-privacy] Call for Adoption: draft-hal-adot-
> operational-considerations
>
> This starts a Call for Adoption for
>
