>>>
>>> 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
> ]
This is exactly what is defined in
draft-pmohapat-sidr-origin-validation-signaling-00, though slightly different
values:
+-------+-----------------------------+
| Value | Meaning |
+-------+-----------------------------+
| 0 | Lookup result = "valid" |
| 1 | Lookup result = "not found" |
| 2 | Lookup result = "invalid" |
+-------+-----------------------------+
with:
When comparing a pair of routes for a BGP destination, the route
with the lowest "validation state" value is preferred.
- Pradosh
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
