Thank you Evan and Petr fro your comments. I thought I would be able to
provide you some text this week... but I am running late. I will send you
some text next week.

I agree with your comments, and will make my best to address them. I also
came with other requirements.

Yours,
Daniel

On Fri, Apr 7, 2017 at 7:25 AM, Petr Špaček <[email protected]> wrote:

> On 31.3.2017 05:48, Evan Hunt wrote:
> > I have reviewed draft-mglt-dnsop-dnssec-validator-requirements-04.txt
> and
> > some comments on the substance of it are below. (I'll also send some
> > grammatical nitpicks via private mail.)
> >
> >> However, without valid trust anchor(s) and an acceptable value for the
> >> current time, DNSSEC validation cannot be performed.  This document
> lists
> >> the requirements to be addressed so resolvers can have DNSSEC validation
> >> can be always-on.
> >
> > This abstract, and the introduction below, both seem to suggest that the
> > intention of this draft is to list requirements for automatic
> bootstrapping
> > and recovery of DNSSEC without human intervention.  However, several of
> the
> > requirements actually included in the text describe mechanisms of human
> > intervention: for example, insertion of negative trust anchors or the
> > ability to flush the cache.
> >
> > To my mind, any need for human intervention contradicts the idea of
> DNSSEC
> > being "always-on"; humans can't react instantly.  So I suggest revising
> > the abstract and the problem statement to say that these are requirements
> > for a DNSSEC validator to be recovered when it fails, rather than for
> > it always to be on.
>
> A document listing what can possibly go wrong with DNSSEC deployment in
> real world and what "features/tools" software vendors have to provide to
> ease recovery is a good idea.
>
> Having said that, I support Evan's view that here we are not talking
> about "always-on" but more about "human intervention"/recovery. I think
> that all other Evan's comments are good ideas as well and improve the
> document.
>
> I'm looking forward to reviewing a new version of the document.
>
> --
> Petr Špaček  @  CZ.NIC
>
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
>
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to