On 22/05/2010, at 20:08, Robert Kisteleki wrote: > On 2010.05.21. 23:19, Geoff Huston wrote: >>>> I agree with Terry on this one. I'd personally be much happier with >>>> verified/unverified instead of valid/invalid. These terms are much >>>> closer to what we really mean. >>> >>> Ack. We will make this terminology change in the next revision of the >>> draft. >> >> I disagree with this terminology change - there are three states that are >> potential outcomes of the process, not two and the proposed terminology >> does not accommodate this. I request that no change be made in >> terminology. > > Geoff, you misunderstood. We proposed varified/unverified/unknown instead of > valid/invalid/unknown.
I also prefer valid/invalid/unknown.
I don't believe that the term "unverified" has quite the desired meaning.
"verified" is a positive assertion ("yup, all ok"), "unknown" is a null ("pass,
I have no idea"), and the third state should reflect that it is the _opposite_
of "verified" (ie, *known* to be incorrect), so "verify failed" (or "failed
verification", or simply "failed") would, I believe, be more accurate than
"unverified"...
... at which point, it seems to me that valid/invalid/unknown is less
cumbersome.
To look at it from another angle: If you wanted to order the update in order of
preference, you would have to prefer "valid" updates over "unknown", and
"unknown" over "invalid".
[ If you were to base a comparison function for sorting on this DB lookup, I
believe it would have to look like this:
valid = 1
unknown = 0
invalid = -1
]
I don't think that "unverified" quite cuts it in this context, as it is not the
negative counterpart to the positive "verified" assertion. A naive
reader/implementer might believe that "unverified" is less dubious than
"unknown", and incorrectly order the values.
Rob
--
Robert Loomans email: [email protected]
Senior Software Engineer, APNIC sip: [email protected]
http://www.apnic.net/ phone: +61 7 3858 3100
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
