> so whenever i hear words like "that'll be slow for flat-hash dns caches" > it reminds me of the joke that begins "doctor, it hurts when i do $this" > and ends with "well, then don't do $this".
This sounds like a really good rejoinder until you realize that we are talking about an optimization that is likely to produce very little actual benefit in practice other than in the presence of certain kinds of PRSD attacks. So the current draft makes an algorithm which apparently works well for several implementations work less well in order to get a benefit the magnitude of which is unclear, but likely small. As a matter of principle, of course, what you are saying is true. However, remember that what we are debating here is not whether to clarify the rules for handling NXDOMAINs, but rather whether to add normative language strongly urging implementations to do this optimization. We all, I think, agree that the clarification is good. By your argument, we should not add the normative language--we should just clarify the spec, and then see what happens. If we see widespread implementation of this optimization, then we can conclude that it was worth doing. If nobody implements it, or only tree-structured caches implement it, then we can conclude that whatever benefit may have come from doing the optimization wasn't sufficient to justify widespread implementation. More likely, though, what we will see if we make this clarification without adding normative language, is that implementors make intelligent use of the optimization, as Wouter suggests, based on what will work most efficiently with their implementation. So once again I urge the working group to make this a clarification and not a normative requirement, so that smart implementors can do what makes the most sense in the context of their implementations. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
