Carl S. Gutekunst <csg(_at_)habeas(_dot_)com> wrote:
The CSV-DNA Accreditation Report string defines the "recommendation"
field as:
1. 'A' for Strongly Recommended
2. 'B' for Recommended
3. 'C' for Unknown
4. 'D' for Not Recommended
5. 'E' for Strongly Not Recommended
I think we need separate responses for:
Unknown
Specified domain is unknown to the Accreditation Service.
This could be semantically the same as an NXDOMAIN response
from the DNS server, but providing a positive response from
the DNS rather than a negative response.
Neutral
Specified domain is known to the Accreditation Service but
the Service has no opinion on the domain, perhaps due to
insufficient data or inconsistent data.
I agree that "Unknown" is quite different from "Neutral"; and that
it would be unwise to interpret NXDOMAIN as exactly equal to either.
Whether it's necessary to distinguish these is less clear, but I'm
quite willing to allow for it. The exact way to code the difference
(IMHO) is an open issue.
I'd like to discuss the merits of one more:
Retracted
Specified domain is known to the Accreditation Service but
the Service now retracts all previous recommendations.
I suspect that most accreditation services wouldn't use this
(largely for fear of lawsuits). Thus, I'm hesitant to include it.
I expect most services would prefer to revert to NXDOMAIN (which leads
to NXDOMAIN not necessarily meaning "Unknown" or "Neutral".
The underlying issue is how we convey record-level negative responses
and error cases. I'm concerned about the (IMHO) laissez-faire reliance
on negative DNS responses that seems to becoming standing practice,
starting with the DNSBLs and now working its way into Domain Keys and
other places. The caching behavior of negative responses is different,
and there are still implementations in the wild that forget to timeout
negative responses (or ignore the TTL in the SOA). Fault diagnosis is
also difficult when you cannot distinguish between a legitimate "I don't
know" response and querying the wrong server. (You could argue that the
DNSBLs should have returned SERVFAIL to indicate "unlisted," rather than
an Authoritative NXDOMAIN, but the horse left that barn a long time ago.)
Hence when we're designing new records, I'd like to build in
well-defined "I don't know" and "changed my mind" responses into the
record, limiting the use of the Authoritative NXDOMAIN to really mean
"Domain Does Not Exist."
Well, of course, the actual domain queried _does_ not exist...
I'd like to interpret NXDOMAIN to mean, "There's no relationship
between this sending domain and this accreditor." I intend there to be
a closed loop where the sending domain advertises its relationship with
the accreditor and the accreditor advertises its accreditation. IMHO,
only with an established relationship can we be confident that
information about reported problems and their resolution will flow
dependably.
Thus, IMHO, in the absence of an ongoing relationship, any opinion
of the accreditor fades quickly into hearsay.
(This doesn't mean I'm opposed to defining a "changed my mind"
response -- just that I think it more confusing than useful.)
--
John Leslie <john(_at_)jlc(_dot_)net>