Re: repeating records

[Greg Hudson <ghudson@MIT.EDU>]

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.

Dan Bernstein wrote:
>   * ``DNS servers SHOULD NOT use BIND 8's AXFR glue strategy'' because
>     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.

Dan Bernstein wrote:
>    * ``DNS servers SHOULD NOT use EDNS0'' because the opposite choice
>      usually generates less traffic.

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

>    * ``DNS servers SHOULD NOT use AXFR'' because rsync practically
>      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.

>    * ``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.

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.

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