On Sun, Dec 29, 2019 at 05:50:57AM -0800, Mohit Sethi via Datatracker wrote: > Reviewer: Mohit Sethi > Review result: On the Right Track > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-dprive-bcp-op-07 > Reviewer: Mohit Sethi > Review Date: 2019-12-29 > IETF LC End Date: 2020-01-02 > IESG Telechat date: Not scheduled for a telechat > > Summary: > This draft discusses privacy challenges for recursive DNS resolvers. It then > describes policy and security considerations that DNS service providers can use > for enhanced user privacy. The draft is 'On the Right Track' but not yet ready. > > Major issues: > > I wonder if section 5.1.2.1/5.1.3.1 should also talk about recommending OCSP > stapling (RFC 6066)? I looked at RFC 8310 and it mentions RFC 7525. Do you want > to mention it here in section 5.1.2.1/5.1.3.1? > > In section 5.1.2.1, what is meant by 'authentication domain names'? Later, the > text says 'authentication name for the service'. I guess you are implying the > authentic domain name of the DNS resolver service that the client software > should verify through the common name (CN) in the certificate? Some more > explanation here would be beneficial. RFC 6125 has some useful terminology to talk about this sort of server-name validation; for greenfield protocols the most common identifier type to use is the DNS-ID, but the source of the name to be validated will still need to be specified. -Ben -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
