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