Re: repeating records

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

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  your subscription address is
  54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if you
  wish to regularly post from an address that is not subscribed to this
  mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to
  have the alternate address added to the list of addresses from which
  submissions are automatically accepted. ]

BIND company employee Andreas Gustafsson writes:
> D. J. Bernstein writes:
> > Yes or no: Are you claiming that every DNS implementor, before choosing
> > to use (for example) BIND 8's strategy of sending glue whenever it's
> > referenced, _must_ understand and carefully weigh the implications?
> Yes.

Let me get this straight. Because the BIND 4/8 strategy (for the sake of
server simplicity) generates slightly more traffic (for some zones), you
conclude that every DNS implementor _must_ understand and carefully
weigh the implications before choosing that strategy?

After many years of BIND 4/8 working just fine without anybody worrying
about this, why did this suddenly become an issue? Maybe the .com
administrators care, but how does that justify demanding that _every_
implementor worry about this? Are you sure that you aren't wildly
exaggerating the importance of an absurdly small issue?

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

If the last two answers are no: What, precisely, is the relevant
difference between these situations and the repeated-glue situation?
Don't you agree that these things generate more traffic? A moment ago
you said how important it was for all implementors to pay attention to
efficiency issues; are you retreating from that principle?

How would you like it if other people tried to force you to imitate
their implementation decisions by declaring that implementations SHOULD
make those decisions---never mind actual costs and benefits?

> > If people really are misusing ``SHOULD'' for minor efficiency issues
> > (misinterpreting ``harm'' in section 6 of RFC 2119), we're going to need
> > a new word to point out real dangers such as over-eager retransmission.
> We already have one.  It's called MUST.

I'm cc'ing this to Bradner. RFC 2119 is obviously meant to stop people
from pretending that every implementation decision is a protocol issue;
it is not succeeding at this goal.

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