Hi Sara, Thanks for you replies. See below.
> On 4. Mar 2020, at 14:30, Sara Dickinson <[email protected]> wrote: > > > >> On 31 Jan 2020, at 10:45, Mirja Kühlewind via Datatracker <[email protected]> >> wrote: >> >> Mirja Kühlewind has entered the following ballot position for >> draft-ietf-dprive-bcp-op-08: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> A couple of small comments/questions: >> >> 1) RFC2119/RFC8174 disclaimer is present in section 4, however, it does seem >> to >> be the case that normative language is used. I would recommend to actually >> use >> normative language in this doc! >> > > There is one key instance of a SHOULD in section 5 which ripples through the > entire document because it covers the requirement for the various > mitigations. > > “This document does not specify policy - only best practice, however > for DNS Privacy services to be considered compliant with these best > practice guidelines they SHOULD implement (where appropriate) all:" > > It is easy to miss though…… Ah, okay! Actually maybe something that can be stated more explicitly in the intro to make sure people do miss that there are actually normative requirements. (Didn’t re-read the intro, so it might well be that it is clear already and I didn’t get it…) > >> >> 2) Can you actually provide references for the techniques listed in Table 1? > > Do you mean the Categorization/Properties or the actual techniques listed? > The latter are described in detail in Appendix B. Ah, I didn’t match that on my read. Maybe just add a reference go Appendix B then? > >> >> 3) Sec 5.1.3.1: >> “A DNS-over-TLS privacy service on both port 853 and 443. This >> practice may not be possible if e.g. the operator deploys DoH on >> the same IP address.” >> Isn’t 443 basically DoH? > > No, this means using the DNS-over-TLS protocol, just on port 443 by prior > agreement between client and server (RFC7858 describes this). No HTTPS > involved. I there is no http, I don’t think this document should recommend use fo 443. See further below. > >> Why would you deploy DoT over 853? Sorry I meant 443... >> Is that a common practice? Sorry if I miss something… > > Port 853 is the IANA assigned port for DoT. Before DoH was a thing, it was > suggested that running DoT on 443 would prevent issues where port 853 might > be blocked - several early DoT services did this. I was guessing that, but I’m not connivence we should support that in an RFC (given we have DoH on 443 now as well). Mirja > > Best regards > > Sara. > > _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
