> On 10 May 2017, at 22:48, Ben Campbell <[email protected]> wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm balloting "yes", but I do have some comments: > > Substantive: > > 5: "Clients using Opportunistic Privacy SHOULD try for the best > case..." > When might it be reasonable _not_ to try for the best case? (That is, why > not MUST)?
If latency is a greater concern than privacy. For example if a client has 5 Privacy servers configured a MUST would require it to attempt to obtain an authenticated, encrypted connection to all 5 before falling back to using an unauthenticated, encrypted connection to the first one. There is some text on this in Appendix A. > > 5.1: What's a reasonable granularity for the profile selection? The text > suggests that decision is on a per-query basis; is that the intent? I > assume you don't expect a user to make a decision for each query. No, it is expected that the client sets the desired Profile and uses it for all queries until that setting is changed. The intent of this text was to clarify that the granularity should not be less than query level. Maybe it would help to add some text “It is anticipated that clients will use a particular Usage Profile for all queries until an operational issue or policy update dictates a change in the profile used”? > > 6.5: The statement that a client using OP "MAY" try to authenticate seems > inconsistent with the "SHOULD try for the best case" statement in S5. > (But seem my comment above about that.) You’re right it does seem inconsistent. It seems better to switch the MAY here to SHOULD? > > 13.2: [I-D.ietf-dprive-dnsodtls] is referenced using 2119 keywords, so it > should be a normative reference. (Note that this would be a downref.) It was caught in another review that this document is now an RFC. > > Editorial: > > 2: "MUST implement DNS-over-TLS [RFC7858] and MAY implement DNS- > over-DTLS [I-D.ietf-dprive-dnsodtls]." > Unless these are new-to-this-draft requirements, please use descriptive > (non-2119) language. (Especially in a definition). The definition of a Privacy-enabling DNS Server is new to this draft which is why it seemed correct to use those terms. Do you think it would be better to move that description/definition to the introduction? > > 5: "Strict Privacy provides the strongest privacy guarantees and > therefore SHOULD always be implemented in DNS clients along with > Opportunistic Privacy." > > Does that mean "SHOULD implement both strict and opportunistic privacy" > or "If you implement opportunistic you SHOULD also implement strict?” Good question. The second one. Replace with: “ Strict Privacy provides the strongest privacy guarantees and therefore SHOULD always be implemented in DNS clients that implement Opportunistic Privacy." > > 6.2: Should list item "2" be "ADN+IP", like in the table? The 'Short name’ in used in the listing, the one given in the last column of the table. > > 11: Is "SHOULD consider implementing" different than "SHOULD implement”? No, I don’t think so :-) Propose it is changed to “SHOULD implement”. Regards Sara. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
