On Saturday, March 12, 2016 01:58, Paul Vixie wrote: > Ted, I think you're reading it wrong. The implementation doesn't matter > at all. As Co-Chair Woolf kindly and classily 2x4'd me last year, an RFC > should be of the form "if you want to do X, here's a way to do it > interoperably."
With all due respect, Paul, it is you who are reading it wrong, because the spec doesn't do what you say Supreme Co-Chair Woolf said, to wit: > This specification should express the basic idea that after an NXDOMAIN > has been received from an authority server for name X, then the receiver > of that NXDOMAIN is allowed to (note: "allowed to"; this is optional, > and is just an optimization) treat it as also applying to any name that > is in-bailiwick for X. (Sometimes that will be expressed as "at or below > X" or "a subdomain of X".) This is what the specification _should_ say, not what it _does_ say. > Like all other forms of negative caching, this is just a speedup, and if > a cache is implemented in a way that makes "is there a negative cache > element for whose owner name this qname is in-bailiwick?" too expensive, > then that negative caching implementation will probably not perform this > optimization. If it's a speed hack, there shouldn't be any normative language associated with implementing it. I'm objecting to the normative language, not the clarification that allows the speed hack. I agree with the clarification. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
