All, This document has been making the rounds for some 2.5 years now, initally as a personal submission by the authors, and later on as a WG document. The reason that it has taken so long is a combination of
* the subject matter being quite complicated and several re-starts trying to find the best approach for description * the need to track an evolving subject matter, interact with other documents like 4641-bis, etc * the usual sundry time constraint issues for authors, editors and reviewers The present state is that we have a document that's fairly "stable", has been reviewed several times with nits fixed in between. So it is almost ready to go, isn't it? Well, not necessarily... One of the problems with delays is that over time you gain a clearer understanding of what was once new. Another is that when that perfect 20/20 hindsight appears you realise that if you were to start over you would do it in a different way. And this is perhaps where we are now. There are significant changes that are being discussed, including: * a section on rollovers of the so-called CSK (Combined Signing Key) in addition to the treatment of KSK and ZSK rollovers. * there is a lack of clarity in the current definition of key states that would benefit from further work. For instance, current logic assumes that a transition from one active key to the next is immediate, while for large zones it is becoming clear that signing with the new key may be a gradual phase-in that will take some time until all signatures are replaced. See the recent email from Matthijs Mekking. * alternatively, a more fundamental change would be to completely change the terminology by switching away from a state description that is "key centric" (i.e. keys have states and the rollover progresses as a function of the keys changing states) to instead be "rollover centric" (i.e. the rollover has states, and keys change behaviour and tasks as a function of of the rollover changing states). However, it would allow for a consistent terminology across all types of rollovers. * manage the complexity and problems finding reviewers by splitting the material into two documents, the first laying down terminology and defining states and transitions, the second having all the math, equations, and complete treatment of all consequences of all choices of rollover mechanisms. The first document would be of more general interest and the latter clearly more of relevance to implementers. However, doing major surgery like this at this time would clearly delay publication significantly and we are therefore at a point in time where we have to ask the WG for guidance on how to best proceed. We see the following three paths forward: A. "Improvements should always be incorporated, even in the light of further delays". This is also known as the "This Time For Sure"-alternative. B. "Better to publish what we have and initiate work on a -bis document immediately. Also known as the "Perfect is the Enemy of Timely"-alternative. C. Drop it. If it isn't sufficiently cooked after getting on for three years, then perhaps it s/after three years/after getting on for three years/ is either a case of bad ingredients, or incompetent chefs. Also known as the "This Parrot Is Dead"-alternative. We are willing to proceed in either of these directions, and we do have opinions on what to do with this. But, as this email is the "problem statement", this is not the place to express them. So there it is. Please speak up on where we ought to go with this. A, B or C (or some other alternative not listed above). Regards, John, Stephen and Johan _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
