Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timing-03.txt until 2012-09-14

[Andrew Sullivan <[e-mail]>]

Dear colleagues,

On Thu, Aug 23, 2012 at 11:49:24PM +0200, Peter Koch wrote:
> Dear DNSOP WG,
> 
> this is to initiate a working group last call (WGLC) for
> 
>         "DNSSEC Key Timing Considerations"
>         draft-ietf-dnsop-dnssec-key-timing-03.txt
>         <http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/>
> 

I have read draft-ietf-dnsop-dnssec-key-timing-03. I have some
comments. I'll send additional comments containing nits to the draft
editors.

On the whole, I think the draft is a little complicated for operators
to follow easily.  I nevertheless think we should publish it: we offer
today _no_ guidance to operators on these matters, and people I work
with, at least, want such guidance.  I know there's another draft
floating about, but if we take as long to reach agreement on that
draft as we took to review this one, we'll never publish anything.

In section 1.2, it would be helpful to observe that, as a matter of
deployment, the KSK might also be the ZSK.  I'm aware that the
document is assuming a sharp distinction, but by noting they could be
the same key and leaving the working out of the implications for the
reader, the document will be made more useful.

Section 1.4 includes the RFC 2119 language, but in some places I
notice "must" (in lower case) used. I find this a little hard to work
with, and I know that at least one AD is quite exercised about this
issue, so I think someone needs to go through the document and restate
such uses. I also find it mystifying why some but not all of the
definitions are moved to an appendix, although I don't really care
about this.

Section 3.1 has this definition:

   Published   The DNSKEY record - or information associated with it -
               is published in the zone, but predecessors of the key (or
               associated information) may be held in caches.

I think this isn't quite right, because the predecessors of the key
(i.e. other keys) might also be Published, no? It's predecessors of
the relevant RRsets that might still be in caches, I think, no?

In section 3.2.2, the text, "The successor is key is now active and
the current key is said to be retired," is a little strange (it's odd
that the "current key" is the retired one and the "successor key" is
active). I understand the text given the context, but I wonder whether
this would be better phrased in terms of Key N and Key N+1.

It took me a minute to understand Section 3.2.3, Event 4.  Perhaps it
could be clarified this way:

   There is now a delay while RRSIGs that were only generated using
   Key N expire from caches.  This interval is given by the expression:

             Dprp + TTLsig

    After that interval, all caches that have any RRSIG will have the
    RRSIGs generated by both Key N and Key N-1.

Or something like that?

Best regards,

Andrew

-- 
Andrew Sullivan
[e-mail]