John, all, On Mon, Aug 20, 2012 at 12:50:55PM +0100, John Dickinson wrote:
> > Saying this does not count as a 'standby key' is confusing in the > > light that the term key is used rather loosely. Also this text > > insinuates that it is somehow worse than having a "Double-Signature > > standby key" but fails to mention why. > > I am reluctant to make changes to the wording at this stage. with co-chair and shepherd hat on I must say there is no 'stage' of the document that would discourage or prevent clarifications if members of the WG feel the need. Personally (i.e., no hats) I must say I am not sure I understand what message this paragraph is trying to convey: if it is that the key cannot be used right away because it needs to become active first, then maybe that could or should be made more explicit. > > +------------------+------------------+-----------------------------+ > > | ZSK Method | KSK Method | Description | > > +------------------+------------------+-----------------------------+ > > | Double-DNSKEY | - | Publish the DNSKEY before | > > | | | the RRSIGs. | > > | Double-RRSIG | - | Publish RRSIGs before the | > > | | | DNSKEY. | > > | Double-ZSK | - | Publish the DNSKEY and | > > | | | RRSIGs at same time. | > > | - | Double-DNSKEY | Publish the DNSKEY before | > > | | | The DS. | > > | - | Double-DS | Publish DS before the | > > | | | DNSKEY. | > > | - | Double-KSK | Publish DNSKEY and DS in | > > | | | parallel. | > > +------------------+------------------+-----------------------------+ > > Yes, I guess this table could be clarified, but again I am reluctant to make > changes to the naming at this stage, especially as this would require > changing the names throughout the document. We could rearrange the table to > tidy up the description of the Double-Signature method but keep the existing > names. Would that help? And again (hat++), the stage is not a reason to refuse change, especially given that this has not been discussed before as far as I remember. However, this is a WG document and apart from editorial changes and obvious errors, (significant) changes do need WG consensus - and i have seen no support so far. What we need to keep in mind here, though, is internal document consistency as well as consistency with other WG documents, nost notably RFC 4641 and 4641bis as well as established operational convention (as opposed to, just for completeness sake, sloppy language or marketing blurb). -Peter _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
