As promised in Prague, here is a (late) review of draft-ietf-dnsop-respsize-07.
First, I would like to say that I believe it is important to have a stable and reviewed document about this response size issue since it is one we'll typically have to deal with in the future (IPv6, DNSsec, IDN, etc). This is specially important since worries about response sizes have already been used to back political decisions. So, I believe that such a document should be published and I would really like to see the document going forward. However, I have some reservations about the current version. *************************** The biggest concerns I have: 2.3.1: "In case of multi-homed name servers, it is advantageous to include an address record from each of several name servers before including several address records for any one name server." This one really puzzles me. It seems to recommend to add only one address record from a RRset (since the machine is multi-homed, it has several addresses and so several A or AAAA records), which would be useless (it would force truncation), and, I believe, contradicts 2.1.3, 2.3.5 and 4.4. 2.3.4: I'm concerned that it seems to redefine "truncation" in a way which is apparently incompatible with RFC 1035 and 2181 by introducing "explicit truncation" and "silent truncation". Truncation is only when the TC bit is set. "silent truncation" is not truncation at all, it is selection of RRsets (RFC 2181, 9). ********************************* Some less (IMHO) important issues: Abstract: "zones wishing to expose a moderate or high number of authority servers (NS RRs)". But the issue is independant of the type and concerns about response sizes were mentioned for protocols using TXT records like RFC 4408 or 4871. 4: the entire section 4 seems out of place since 2.2 already lists the advices to zone owners (which is what 4 is about). I suggest to merge 4 into 2.2 and to put a simple conclusion just reminding the importance of the issue and that the zone owners and server implementors should care about the problem. 4.6: "glue records for them should be considered "less optional"" while 2.3.3 call them "necessary content", not "less optional". ***************** Editorial issues: 2.1.5 "incompressable" should be "incompressible" 2.1.6. "In this worst case scenario, the question section will be 259 octets in size, which would leave only 240 octets for the authority and additional sections" I believe the answer section should be mentioned as well. 2.2.1 "but that it is reasonable to expect truncation and TCP retry in that case.". Shouldn't it be "but it is reasonable ..."? (And, BTW, I am not sure it is reasonable.) 3.1 "512 octet" should have a 's' 3.2 "occurances" should be "occurrences" References: I do not know if there is an explicit IETF policy about it but I believe that, when you have Perl code in a RFC, a reference to Perl must be provided. Not everyone speaks Perl (or Java or Haskell or Lua). When ABNF is used, you reference RFC 4234. When Perl is used (I know it has no written spec so it is more complicated than C or Scheme), we should have something like: [PERL] "The Perl programming language", http://www.perl.org/. or may be: [PERL] Larry Wall, Tom Christiansen, Jon Orwant, "Programming Perl", O'Reilly, ISBN 0-596-00027-8, July 2000. _______________________________________________ DNSOP mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dnsop
