On Feb 28, 2013, at 19:43, Tony Finch wrote: > > The update logic ought to be idempotent, i.e. the instructions from the > child should be of the form "make it look like this" not "perform this > action". Then the parent needs no state other than the CDS RRset and the > DS RRset.
I'd considered that. My experience is that this goal is admirable but can cause a request to become large in size and hard to understand. I'm hoping to avoid yet another too-large RRset that could cause problems in abuse situations. And we do have an interested party here, the client, that should have already automated the KSK change event. > It might be desirable to be able to say "like this before such-and-such a > time, and like that afterwards". So maybe CDS RRs need inception and > expiry dates? Oh, great scott no! Sigh, sorry. I spent many years (in the 90's) playing with the semantics of having RRSIGs for a set with varying spans of validity. It's a waste! Note - my assumption is that I'll layer over the CDS a tool that will manage the key roll and that tool will be managed by some sort of calendar. Part of this maps to what I've seen in an open source DNS product that will allow users to schedule key changes now. (Poorly worded way of saying - given how I've seen changes happen in operator settings, I think embedding times and trying to be idempotent detract from the experience. Again, this is opinion, not based on factual logic.) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
