> On May 11, 2017, at 7:12 AM, Sara Dickinson <[email protected]> wrote: > > >> 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.
Thanks, that helps. A few words about that near the SHOULD would be helpful. > >> >> 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”? I think that would help. > >> >> 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? That seems reasonable to me. > >> >> 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. I’m not sure that changes my comment. It still needs to be a normative reference, and I assume the RFC is still experimental? > >> >> 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? I would suggest leaving it where it is, but making a change along the following lines “A DNS server that implements DNS-over-TLS and may optionally implement DNS-over-DTLS.”, and state the normative bits elsewhere. > >> >> 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.” Looks good to me. > >> >> 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. > Okay. >> >> 11: Is "SHOULD consider implementing" different than "SHOULD implement”? > > No, I don’t think so :-) Propose it is changed to “SHOULD implement”. Looks good to me. Thanks! Ben. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
