Dear colleagues, I read draft-ietf-dnsop-respsize-15. I have a few comments. These are primarily editorial or even nits. By and large, I think this draft is fine and ready to go and we should Just Publish It. We're supposed to be an operations WG, and I don't think every bit of advice needs to be absolutely perfect before we send it, so long as we are sure we are offering good advice. Note that I have _not_ checked the arithmetic in the document. I did once before some time ago, and it was right then.
I think the expansion for DO is "DNSSEC OK" and the reference likely should be RFC 3225. RRset (or RRSet) should refer to 2181. 1035 actually didn't define this. There is a definition of RRSet in 2181 and RRset in 2136, but I guess 2181 is preferable since it was an explicit clarification of DNS protocols. The EDNS protocol extension starting with version 0 permits larger responses by mutual agreement of the initiator and responder (see Section 4.3 and Section 6.2 of [RFC6891]), and it is recommended to support EDNS. I read that as having an antecedent for "it" of "the EDNS protocol extension", which is clearly not what is meant. Perhaps The EDNS protocol extension starting with version 0 permits larger responses by mutual agreement of the initiator and responder (see Section 4.3 and Section 6.2 of [RFC6891]). For practical reasons, DNS servers and resolvers are recommended to support EDNS. The most recent measurements in the document are from 2012. Is there anything more recent? Does it matter? Even in scenarios where EDNS support in initiators and responders can be assumed, e.g. in the case of messages exchanged using DNSSEC, or at some future time where EDNS deployment can be considered ubiquitous, there will still be cases when MTU limitations or IP fragmentation/reassembly problems in firewalls and other middleboxes will cause EDNS failures which lead to non-extended DNS retries. That sentence is kind of hard to follow. Perhaps Even in scenarios where EDNS support in initiators and responders can be assumed (e.g. in the case of messages exchanged using DNSSEC, or at some future time where EDNS deployment can be considered ubiquitous), there will still be cases when MTU limitations or IP fragmentation/reassembly problems in firewalls and other middleboxes will cause EDNS failures; such cases will lead to non-extended DNS retries. I don't understand this sentence: Anycast [RFC3258] [RFC4786] is a useful technique for improving performance and below the zone cut being described by a delegation is responses. The paragraph We assume a medium query name size of 64 since that is the typical size seen in trace data at the time of this writing. If Internationalized Domain Name (IDN) or any other technology that results in larger query names be deployed significantly in advance of EDNS, then new measurements and new estimates will have to be made. suggests that re-measurement is necessary in the face of IDNA. Does this mean it's time to do that measurement, since in fact we have a number of IDNA TLDs now? Best regards, A -- Andrew Sullivan [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
