Re: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)

["Ben Campbell" <[e-mail]>]

Thanks for the response. Discussion inline, with things that appear to 
be addressed removed.

Ben.

On 8 Jul 2016, at 16:26, Wes Hardaker wrote:

> "Ben Campbell" <[e-mail]> writes:

[...]

>
>> - 1.2, 2nd paragraph: Is "full non-support" effectively different 
>> from
>> "non-support" in this context?
>
> CHanged to "Detecting complete lack of support", which I hope works 
> for you?

It answers my question. But don't the described tests detect degrees of 
non-supportness?

>
>> Do we have reason to expect the github project to be maintained for 
>> the
>> life of the RFC?
>
> I wondered about including such a URL.  I doubt github or olafur will
> ever drop the repository, however.

I'm okay if the answer is "yes" or even "we hope so"; I just want to 
make sure people thought about it.

>
>> - 3.1.1 et. al. : Do we have reason to believe the dnssec-tools.org
>> domain will be maintained for the life of the RFC?
>
> I think for some of the tests we may be able to use the root of the 
> DNS
> instead.  However, in some cases we need specific data types.
>
> I have no intention of ever dropping the signing of dnssec-tools.org,
> and my co-workers have backup responsibility for it and the means to
> sign it should I get thrown in jail by the protocol police, eg.

(repeat previous comment)

>

[...]

>
>> -8: Seems like there could be  more to say about the potential
>> consequences about the “fail or proceed without security” 
>> decision in 6
>> and 6.1.
>
> I think the world is very much at a loss as to the best thing to do in
> that case.  And is likely very case specific.  Military installations
> tend to be a bit more strict about continuing through to a 
> unacceptable
> security certificate, eg.  I'm not sure we can enumerate every 
> context,
> but rather say each local policy will need to do what is appropriate 
> for them.
>

I think it would be useful to say _that_. (as in "here's a security 
consideration people need to, well, consider")

> -- 
> Wes Hardaker
> Parsons