On Fri, Mar 11, 2016 at 04:26:19AM +0000, Ted Lemon <ted.le...@nominum.com> wrote a message of 13 lines which said:
> 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. It is certainly not the goal. Can you tell exactly where it is assumed? Section 2 is supposed to be implementation-neutral. Section 5 discusses implementations but does not assume or recommend a specific one. Section 1 uses the word "tree" but to describe the abstract data structure (you will certainly agree that domain names are a tree...) not the actual implementation. > If the cache is a hash, the requirement at the beginning of section > two is actually expensive to implement, This is exactly what section 5 says (last paragraph). > 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. I disagree here. This is (if approved) a normative document. It does place "new" requirments. (I write "new" between quotes because resolvers with NXDOMAIN cut behavior are, IMHO, legal even today, the original RFCs are not perfectly clear.) > 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. It is a change in the behaviour of the majority of resolvers, but not a change in the protocol. So, yes, it is "to address operational issues with the DNS protocols by extending or performing protocol maintenance on them" _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
