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

[Matthijs Mekking <[e-mail]>]

Hi Andrew,

On 09/07/2012 09:32 PM, Andrew Sullivan wrote:
> 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.

I agree the document can be complicated for operators, but the document
targets developers in the first place. But I must admit, also for
developers, it can be quite a challenge to fully grasp all the timings
and its explanations on the first read.

> 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.

If we would add such a notion, I would also add that this document does
not cover time lines for rollovers where the key has both roles.

> 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
>