> > In Section 7.1.1, can you add a sentence or reference to explain "lame > > delegation"? I recognize that this type of error results when a name > > server is designated as the authoritative server for a domain name and > > that server does not have authoritative data. > > [ AUTHORS: This was a term that was left out of the terminology draft. Do > you have any suggestions for how we can reword this to remove the need for > the term? ] "... to distinguish the respone from one where the Authoritative Nameserver is not responsible for the name, which is a common convention for the REFUSED status." > > Section 7.4 says: "Several other implementations, however, do not > > support being able to mix positive and negative answers, and thus > > interoperability is a problem." Then, the next paragraph says that > > this topic will be revisited in a future specification. Is there any > > advice that the authors can share as a step toward interoperability > > that would be useful for implementers until the future specification > > comes about? > > [ AUTHORS: Any text for here? ] The current situation is such that I think it is best just to say only something like, "It is recommended that no specific behaviour regarding negative answers be relied upon." Personally my proposal is going to be that negative answers be allowed to be scoped the same way that positive answers can be, but I don't expect it to be without some controversy and it wouldn't be right for me to insert by own bias into this document -- especially since Wilmer is one of the people who has said that he doesn't think ECS should be able to be used with negative answers.