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" <[email protected]> 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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
