Subject: [DNSOP] draft-ietf-dnsop-respsize-15

From: Andrew Sullivan <[email-masked]>
Date: Mon, 21 Apr 2014 13:59:47 -0400

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-masked]