This document seems ready for WG Last Call. The comments I have hear can
be dealt with before or during WG Last Call.
--Paul Hoffman
=====
The following text from section 4.2 still seems wrong:
Since Strict Privacy provides the strongest privacy guarantees it is
preferable to Opportunistic Privacy.
Strict Privacy is only preferable to users who would rather have an
unusable Internet connection: an Internet connection where every DNS
lookup in every application fails. Currently, that size of that set of
users is incredibly small, although it might grow over time. The
sentence above could lead developers to implement Strict Privacy without
also implementing Opportunistic Privacy to the detriment of the vast
majority of current Internet users.
Proposed replacement:
Strict Privacy provides the strongest privacy guarantees and
therefore should always be implemented along with Opportunistic Privacy.
The negative implications of the two types of privacy are so radically
different (a possibly-unusable Internet service for Strict Privacy;
complete control of DNS responses for Opportunistic Privacy) that
neither option can be considered a good default for all users.
=====
I have a significant concern about the discussion of
draft-ietf-dprive-dnsodtls, which is listed as an informational
reference. That document seems to be stalled again, which is
unfortunate. If, during IETF review, someone insists that the DTLS
document is in fact a normative reference (which would make sense if
that document were finished), draft-ietf-dprive-dtls-and-tls-profiles
will be blocked from publication.
Proposal: remove any mention of draft-ietf-dprive-dnsodtls from
draft-ietf-dprive-dtls-and-tls-profiles. When (if?)
draft-ietf-dprive-dnsodtls goes through WG Last Call, it can have a
paragraph that says that the RFC that
draft-ietf-dprive-dtls-and-tls-profiles has become applies to it.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
