> Main change: reorganisation of the text so that the normative section > 2 is written in a purely protocol-behaviour way, without any reference > to the implementation. Section 5 now discuss implementation.
This seems like the right thing to do. However, I think that this document still goes too far in terms of assuming a particular implementation, in the sense that it appears to assume that the cache is a tree. If the cache is a hash, the requirement at the beginning of section two is actually expensive to implement, depending on how thorough one wants to be, and also depending on whether we rely on DNSSEC or not. I think this document could be made a lot simpler if it simply said what it says in the abstract, without placing new requirements on DNS caches. Right now it says DNS caches SHOULD take an NXDOMAIN on a particular domain as applying to all names under it. This is certainly a valid thing to do, and I can think of ways to do it reasonably efficiently even wish a hashed cache, but reasonably is still O(number of labels) instead of O(1). If you just say what the abstract says and nothing more, that allows implementations to be "more efficient," as you suggest, without requiring implementations to be less efficient. Granted, it's a SHOULD, but I think that still goes too far. You should just say that NXDOMAIN means what you want it to mean, and leave it at that. BTW, is this even in charter for DNSOP? I suppose the theory is that it falls under item 4 in the charter, but that seems like a stretch to me. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
