Subject: [DNSOP] Review of draft-ietf-dnsop-respsize-07

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 27 Jun 2007 23:06:26 +0200

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-masked]
https://www1.ietf.org/mailman/listinfo/dnsop