On 22/05/2010, at 10:30 PM, Robert Loomans wrote:
>
> 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.
Or if my followup explanation is still unclear, then "What Rob said here" is
what I was intending to convey
Geoff
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
