This is going to be a very useful document, two high-level points: On Tue, May 19, 2009 at 01:03:09PM +0100, stephen.mor...@nominet.org.uk wrote: > Wes Hardaker <wjh...@hardakers.net> wrote on 07/05/2009 22:04:11: > > > I think it could be best handled by simply including a section near > > the top that defines one term that is included in all the needed > > equations below. That term would be 0 if you weren't doing RFC5011 > > processing or would be something like 30days + fudge, for example, > > if you were. That wouldn't require making the text below more > > complicated but would still show the important points in the process > > where longer wait times are necessary. > > > > I think this is critical and must be included. IMHO, of course. > > But I'll do my best to adapt everyone else's HO as well. > > As Johan said at the WG meeting, the draft only deals with state > transitions, not distributing trust anchors. However, you make a powerful > argument: what do other people think? Is there a need for detailed timing > considerations of RFC 5011 processing?
I understand the distinction you're making so maybe another document should be written around 5011, but getting the bits out there would be good and this is also not a bad place to do it. (Does adding Wes' additional term open too many other cans of worms, or no?) > This raises a question that we have discussed amongst ourselves, namely > the terminology "KSK" and "ZSK". Conceptually it is simple, in that a ZSK > signs the records in the zone, and a KSK signs the DNSKEY RRset and is > pointed to by a DS/configured as a trust anchor. But as you say, ZSKs can > be pointed to by a DS and used as trust anchors. And theoretically you > could have multiple ZSKs, each of which signs just some of the records in > the zone (a partial-zone signing key?). Please don't change this. Making finer distinctions in one document, clearly defined, is one thing. But please don't try to change terminology we're finally starting to get people to use; it's been (and continues to be) hard enough to get them to stop talking about one key and the singular act of signing. thanks, Suzanne _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
