> On Oct 2, 2015, at 11:23 AM, 神明達哉 <[email protected]> wrote:
>
> 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.
Thanks, this has been updated:
@@ -380,7 +380,10 @@
<xref target="RFC1035"/>.
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
+ described by that length field, to the TCP layer at the
+ same time (e.g., in a single "write" system call) to make
+ it more likely that all the data will be transmitted in
+ a single TCP segment
(<xref target="I-D.ietf-dnsop-5966bis"/>, Section 8).
>
> - 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]'.
Fine with me and not hearing any other comments, I've removed it as you
suggested:
@@ -543,8 +545,7 @@
<t>
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 <xref target="RFC3118"/>.
+ such information may be provided at system installation.
>
> - Section 9: a minor nit: s/be//?
>
> 2. Middleboxes [RFC3234] are be present in some networks and have
Thanks!
DW
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
