On 2012-08-30, at 13:11, Paul Hoffman <[email protected]> wrote:
> On Aug 30, 2012, at 9:45 AM, Paul Vixie <[email protected]> wrote: > >> On 2012-08-30 9:40 AM, Johan Ihrén wrote: >>> Not to question the abilities of the WG, but I still have to ask whether >>> (in your opinion) the operations community would be better off with a >>> single document that may be finished around Christmas Eve 2020 or rather >>> live with multiple docs that are published somewhat sooner than that. >> >> while i agree with these sentiments i have a broader concern. ietf's >> mantra is good engineering. if we know now that keytiming has flaws, and >> we are only considering publishing it because we know our own record >> shows that reaching consensus for keytiming-bis will take a long time, >> then it's an implicit indictment (by us) of our own record and habits. >> >> we should have a better reason for publishing two documents, like new >> ideas occurred to us after the first one was beyond reach of our pen, or >> they have different topics. > > A big +1. An operator who wants to know how to do rollovers will not know *or > care* why they followed IETF guidance that was overturned or even clarified > soon after. I suspect an increasing proportion of operators doing DNSSEC do not care how to do rollovers, in fact. They care that the software they're using to manage keys and sign things is doing the right thing. The pragmatic long-term view is, I think, that this document doesn't give advice to operators so much as advice for those implementing DNSSEC signers. I am not suggesting that operators don't care what happens under the hood, or that vendors don't care about operators. But I think the inference that this is advice to heed before you dive in and perform rollovers by hand is short-sighted. The focus ought to be advice that can be converted easily into good code. I am not a developer of DNS software, and hence don't feel well-placed to review the draft from that perspective. However, my feeling (based on words absorbed inadvertently from people who are developers) is that the document would better serve that perspective if it presented robust state machines and algorithms for arbitrary rollovers. As an operator I would very much like trustworthy tools that could take my desire (say) to roll a KSK from an N-bit alg-A key to an M-bit alg-B key and show me the timing constraints for that rollover to be completed, so I can plan the exercise, accommodate any expected delay in DS publication in parent zones, keep my relying parties informed, and hopefully have robots execute the actual zone changes for me. Working all that out by hand (and making the zone changes manually) based on the advice in dnssec-key-timing is error-prone. Joe
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
