Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-12.txt

[Viktor Dukhovni <[e-mail]>]

> On Oct 3, 2019, at 7:11 AM, Tony Finch <[e-mail]> wrote:
> 
>>> [ I'm still not convinced "indeterminate" is a coherent validation state... ]
>> 
>> It happens when glue NS records are available, but DS RRsets are not.
> 
> That is "insecure".

No, by "available" I meant lookup succeeded (returning valid records,
NODATA or NXDOMAIN, with DoE as appropriate).  By "unavailable", I
meant a timeout, ServFail, bogus reply, ...

> I think the definitions of the terms in RFC 4033 are a lot more clear than
> RFC 4035. By the 4033 definitions the distinction between insecure and
> indeterminate is whether you have a covering trust anchor or not, so
> nothing is indeterminate any more for normal validator configurations.

A clear but vacuous/redundant definition is not useful.  In RFC7672 I
chose the 4035 variant, because it is actually useful:

   https://tools.ietf.org/html/rfc7672#section-2.1.1

The RFC4033 definition of "indeterminate" is not usefully different
from "insecure", and as you note, with the root signed, is mostly no
longer applicable.

This state is different from "bogus", "insecure" or "secure". The
resolver has an answer whose security status is unknown (indeterminate),
because the records needed to determine that status could not be
obtained (which is different from "missing").

-- 
	Viktor.