i've been a bit anxious about ted's use of the word "normative", so i
looked it up:
adjective
1. of or relating to a norm, especially an assumed norm regarded as
the standard of correctness in behavior, speech, writing, etc.
2. tending or attempting to establish such a norm, especially by the
prescription of rules: normative grammar.
3. reflecting the assumption of such a norm or favoring its
> establishment: a normative attitude.
as this document is a clarification, it would be strange to have it
place new constraints on implementations. but it's the word
"prescriptive" that makes me want to run screaming down the hall to get
away from the MUST vs. SHOULD discussion.
let the authors describe, please, what they can see, and then let the
readers interpret and implement. thus the text below, which is factual,
and no more.
Paul Vixie wrote:
"As implied by STD 13 and as made explicit herein, an authoritative
response of code 3 (NXDOMAIN) asserts the nonexistence of both its QNAME
and all possible subdomains. DNS coherence can be systemically improved
if, after receiving such a response and before receiving some new
response indicating the existence of some RRset at or below that QNAME,
a recursive server answers with code 3 (NXDOMAIN) for all questions
which are equal to or subdomains of that QNAME, even if the recursive
server has unexpired RRsets stored at subdomains of that QNAME. As to
whether the resources held by such cached RRsets are reclaimed, or
whether they are allowed to expire naturally, this specification makes
no recommendation."
no SHOULD, no MUST. just, what we see. there are a million or more
better ways to say it than what i wrote above, so let's say it better,
but let's not say SHOULD or MUST. let's honour mike padlipsky on the
matter, say that this document clarifies rather than specifies, and
speak descriptively, not prescriptively.
it would be misleading to omit the description of positive coherence,
but wrongheaded to make our observations into a burden on the
implementer merely because this implication was not universally clear at
first, and not explicit until now.
(so, ted, we appear to agree after all.)
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
