At Wed, 23 Sep 2015 10:32:05 -0400, Warren Kumari <[email protected]> wrote:
> Please review our documents: > https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls/ I've reviewed the 00 version of draft-ietf-dprive-dns-over-tls. I didn't see any substantial issues, so it seems to me almost ready to ship. (But I don't think I can claim to be a TCP or TLS or security expert, so my review is more or less superficial anyway). For the record I agreed with what Stephane Bortzmeyer complained about in his review. I have a couple of more minor comments and one editorial nit: - Section 3.3 For reasons of efficiency, DNS clients and servers SHOULD transmit the two-octet length field, and the message described by that length field, in a single TCP segment ([I-D.ietf-dnsop-5966bis], Section 8). I pointed out that 'in a single TCP segment' is not realistic for my review on 5966bis, and in my understanding this sentence has been revised. This draft will also have to make corresponding updates. - Section 4.2 Methods for pre-deployment of the designated DNS provider are outside the scope of this document. In corporate settings, such information may be provided at system installation, for instance within the authenticated DHCP exchange [RFC3118]. In my understanding no one ever seriously used RFC3118 (or RFC3315)-style DHCP authentication. In fact, the dhc wg is now even going to deprecate the original RFC3315-based authentication in a bis document. So, even with 'for instance', referring to this particular authentication mechanism seems to be too unrealistic. If there's a better and more practical example (which I don't know), I suggest replacing the example with that one; otherwise, I'd rather suggest removing the "for instance...[RFC3118]'. - Section 9: a minor nit: s/be//? 2. Middleboxes [RFC3234] are be present in some networks and have -- JINMEI, Tatuya _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
