At Mon, 14 Mar 2016 16:31:47 +0000, Ted Lemon <ted.le...@nominum.com> wrote:
> > No, it does not. > > Yes, it does. You are not calling it implementation advice, but > that's what it is. A normative requirement to do a particular > optimization is nothing other than implementation advice. I guess one key point to discuss is how strongly we recommend the nxdomain-cut behavior. Specific wording matters include whether to use RFC2119 keywords seems to be minor technicality we can easily address if and once we can reach consensus on the key part. On giving an almost fresh read of draft-ietf-dnsop-nxdomain-cut-01, my impression about the key question is that the draft recommends the behavior quite strongly. While it allows some implementation to ignore the recommendation, the overall tone of the draft sounds like the recommended nxdomain-cut behavior is "the correct" one (from Section 3) and implementations should basically follow unless there's very strong reason not to do so. My interpretation on the complaint of Ted is that he considers nxdomain-cut to be a completely optional optimization but the overall wording of the draft is too strong for such purely optional recommendation. If this observation is correct, I think what we should first agree on is the real intent of the draft: A. nxdomain-cut is "the correct behavior" and implementations SHOULD generally support the behavior. Other behaviors are allowed but should be considered minor exceptions. B. nxdomain-cut is a completely optional optimization. It's totally up to an individual implementation whether to support it. If the intent is B, I tend to agree with Ted; the current draft doesn't convey that intent appropriately, so the wording should be weakened a lot more. If the intent is A, then we should first agree on whether that intent is reasonable. Right now I personally don't have a strong opinion on this one, though. p.s. in my understanding Unbound adopts hash-based data structure for cached RRsets. If it still supports nxdomain-cut as described in Section 8, an argument against the proposal by referring to that type of implementation might sound less convincing. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
