Re: repeating records

["D. J. Bernstein" <djb@cr.yp.to>]

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:
> Ideally, an RFC uses SHOULD when the working group feels that an
> 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.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

--
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/>