Subject: Re: repeating records

From: [email-masked]
Date: Wed, 11 Dec 2002 08:54:44 +1100

> Okay. Andrews has specifically endorsed the three statements
> 
>    * ``DNS servers SHOULD NOT use LDAP'' and

	I didn't say that.  And it cannot be paraphrased as that.

>    * ``DNS servers SHOULD NOT use EDNS0'' and

	I didn't say that.  And it cannot be paraphrased as that.

>    * ``DNS servers SHOULD NOT use BIND 8's AXFR glue strategy''

	Yes. That is what ixfr-clarify says.

> because he claims that every DNS server implementor must understand and
> carefully weigh the implications (specifically, some minor efficiency
> issues) before doing any of these things.
> 
> Is this the same Andrews who has been telling everybody to use EDNS0?
> ``SHOULD NOT use EDNS0,'' but please use it anyway? Does he understand
> how stupid he's making himself sound here?

	Go read what I said again.
 
> Andrews tries to defend his silly AXFR position by saying that ``zones
> are getting MUCH bigger'' and by pointing to DNSSEC. But bigger zones
> and DNSSEC make BIND 8's AXFR glue strategy even _less_ of an issue! The
> djbdns/BIND 9 strategy saves space _for repeated delegations_, not for
> miscellaneous records.
> 
> In short, Andrews is making the ludicrous demand that every implementor
> worry about the .com zone. This is a transparent attempt to hold back
> progress in DNS server software.

	Do you realise how stupid you sound with these ridiculous
	assertions.   Implementors should always be looking at the
	their clients needs.  If you don't want to serve big zones
	then don't deal with their needs.

	Nothing in axfr-clarify stops you sending a record multiple
	times.  No one is forcing you to only send one record.  The
	only constraint is that the SOA record is sent exactly
	twice.  Once as the first record.  Once as the last record.

	Mark

> ---D. J. Bernstein, Associate Professor, Department of Mathematics,
> Statistics, and Computer Science, University of Illinois at Chicago
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Dec 2002 23:57:11 -0000

Andrews claims that every DNS implementor _must_ understand and
carefully weigh the implications---specifically, a minor traffic
increase for some zones---before using BIND 8's AXFR glue strategy.
(``DNS servers SHOULD NOT use BIND 8's AXFR glue strategy.'')

The following analogies show how silly Andrews's argument is:

   * ``DNS servers SHOULD NOT use BIND 8's AXFR glue strategy'' because
     another strategy sometimes generates less traffic.

   * ``DNS servers SHOULD NOT use EDNS0'' because the opposite choice
     usually generates less traffic.

   * ``DNS servers SHOULD NOT use AXFR'' because rsync practically
     always generates less traffic.

   * ``DNS servers SHOULD use bzip2-compressed zone transfers instead of
     gzip-compressed zone transfers'' because bzip2 usually generates
     less traffic than gzip.

   * ``DNS servers SHOULD use gzip-compressed zone transfers instead of
     bzip2-compressed zone transfers'' because gzip usually takes less
     CPU time than bzip2.

   * ``DNS servers SHOULD NOT serve records from an LDAP database''
     because LDAP can be slow.

I could go on like this for a while. Is there anyone other than Andrews
who still doesn't understand why this is a misuse of ``SHOULD NOT''?

In a previous message, I specifically asked Andrews about some of these
examples:

   Do you also conclude that ... every DNS implementor _must_ understand
   and carefully weigh the implications before attempting to use EDNS0?
   (``DNS servers SHOULD NOT use EDNS0.'')

His answer: ``Yes. The choice involved in EDNS are important.'' That's a
clear, direct, specific endorsement of ``DNS servers SHOULD NOT use
EDNS0''---but Andrews now claims that he never said that! Flip, flop,
flip, flop.

---

From: [email-masked]
Date: Wed, 11 Dec 2002 12:24:55 +1100

> (``DNS servers SHOULD NOT use BIND 8's AXFR glue strategy.'')

	This is perfect example of why the section is there.

	There you go again, not analysing the requirements.  You are
	assuming that there is always a *minor traffic increase*.
	You as a implementor are not in a position to say if a given
	increase in traffic is minor or not as you do not have
	enough details of the conditions underwhich the transmission
	is taking place.

	Mark

---

From: Greg Hudson <[email-masked]>
Date: Wed, 11 Dec 2002 11:33:42 -0500

Ideally, an RFC uses SHOULD when the working group feels that an
analysis of a tradeoff should generally go in one direction, but that
an implementor could reasonably choose the other direction after
thinking about it carefully.

>     another strategy sometimes generates less traffic.

The tradeoff here is between code simplicity and traffic savings.
Since you believe that code simplicity is important and that the
traffic savings never reach the level of significance, you side with
simplicity.  That's fine, but if working group consensus is against
you on that point (which is not my call), then the use of SHOULD NOT
is still appropriate.

If you said that IETF RFCs tended to erroneously choose complex
algorithms over simple ones for minor benefit, I might agree.  But
instead, you've attempted a bizarre reductio ad absurdum.

>      usually generates less traffic.

The tradeoff here is between extended functionality and traffic
savings.  So it's not a very good analogy.

>      always generates less traffic.

But rsync accomplishes different goals, as you've pointed out--server
replication versus zone replication.  (If, as you assert, zone
replication is not commonly desired, then perhaps AXFR should bite the
dust, but I think the working group remains unconvinced on that
point.)  Certainly, people should generally use the software which
most closely matches their needs.

In the situation where zone replication is desired--and particularly
when software independence is required--the tradeoff here is between a
better functionality match and traffic savings.  Still not a very good
analogy.

>      bzip2-compressed zone transfers'' because gzip usually takes less

Either of these statements might be reasonable for an RFC to make--if
the working group genuinely felt one way or another about the
bandwidth vs. time tradeoff, which seems unlikely--but obviously not
both.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 15 Dec 2002 03:18:14 -0000

I've noticed that Randy Bush discarded Len Budney's note on this topic:
http://groups.google.com/groups?selm=asnul4%24640g%241%40isrv4.isc.org

Greg Hudson writes:
> analysis of a tradeoff should generally go in one direction

No. That violates RFC 2119, section 6. These decisions are _not_ up to
the working group. They are up to the implementors and, ultimately, the
users.

When speedups actually make a difference for the users, the users notice
and select implementations accordingly. When a tradeoff is good for some
users and bad for others, implementations end up offering a variety of
options, and users end up choosing options accordingly. The free market
does a good job of matching speedups to the users who benefit from them.

Telling implementors that they ``SHOULD'' choose one option---that they
must carefully consider the consequences before doing anything else---is
naive, misguided, paternalistic, anti-competitive behavior. Even if

   * you think that some users will benefit from the option; or
   * you think that some users _need_ the option; or
   * you think that _most_ users need the option; or, as an extreme,
   * you _know_ that most users need the option;

it is still wrong to discourage implementors from making choices that
are better for the _other_ users. The only legitimate reason for a
protocol specification to make a choice is to prevent actual harm, such
as an interoperability failure.

Example: You may think that there's no good reason for DNS servers to
retrieve data from LDAP databases. You may have performance statistics
showing that thousands of DNS servers can't possibly tolerate the CPU
time or network bandwidth of these LDAP lookups. It's still wrong for
you to tell implementors that they ``SHOULD NOT use LDAP''---that they
must carefully consider the consequences before using LDAP. That's not
your decision to make.

Getting back to the example that started this discussion, namely the
bandwidth consumed by BIND 8's AXFR glue repetitions: It is wrong to
demand that implementors carefully consider the consequences before
using the BIND 8 strategy. This would be true even if there were a bunch
of sites that cared about this absurdly small bandwidth issue and that
insisted on software avoiding the BIND 8 strategy. These decisions don't
belong in protocol specifications.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 15 Dec 2002 03:51:30 -0000

[email-masked] writes:
> You as a implementor are not in a position to say if a given increase
> in traffic is minor or not as you do not have enough details of the
> conditions underwhich the transmission is taking place.

Of course, Andrews thinks that he's an exception to this rule; that he
is in a position to say that BIND 8's AXFR glue repetition is a massive
waste of bandwidth; that it was irresponsible of the BIND company to
ignore this crucial issue for so many years; that all implementors must
carefully consider the consequences before repeating BIND 8's mistake.

I'm looking forward to draft-bindcompany-gzip9-00.txt, which says that
all DNS software distribution through tar.gz format SHOULD use the -9
option to gzip, and draft-bindcompany-logging-00.txt, which says that
all UNIX DNS software SHOULD support logging to files as an efficient
alternative to syslog.

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 16 Dec 2002 11:00:31 -0500

>belong in protocol specifications.
Dan,
        Can you suggest less normative verbiage than "carefully consider 
the consequences"? Carefully considering the consequences is something 
that good implementors should be doing *anyway*, for *all* aspects of 
their implementation. So, on that basis, "carefully considering the 
consequences" isn't even nudging them in a particular direction...

                                                - Kevin