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 (RFC2541 and RFC4472).
We will include research/analysis results and steps as they become available.
Thanks,
Karl
On 8/15/19, 9:24 AM, "Stephen Farrell" <stephen.farr...@cs.tcd.ie> wrote:
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, so the eventual aim is to document the results
of the analysis as those affect how one might deploy
ADOT sensibly? (But not to document all the steps
in the analysis that lead to those results?)
If so, that could make sense yes. Might be early
to start though and the current text doesn't really
do that, but is (I think) for now more describing
the analyses you think need doing.
Is that about right?
And to be clear: I think ending up with such a
document is a fine plan if it also provides
guidance on how to achieve the aimed-for privacy
benefits. My concern is more that it may be hard
(and ultimately unnecessary) to try get WG consensus
on text that describes the work to be done (which'll
likely include experiments for which in the end
there's no need to report) rather than the results
after the work is done.
Cheers,
S.
>
> I will discuss your other questions and suggestion for a non-operator
> author with my co-authors.
>
> Regards, Karl
>
>
> _______________________________________________ dns-privacy mailing
> list dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
