Yuri,

Thanks for the feedback.

On 14 Aug 2012, at 09:54, Yuri Schaeffer <y...@nlnetlabs.nl> wrote:

> I reviewed the "DNSSEC Key Timing Considerations
> draft-ietf-dnsop-dnssec-key-timing-03.txt" document rather extensively
> with emphasis on verifying correctness of the rollover timelines. I
> believe these are correct.
> 
> A remark:
> 
> 4. Standby Keys, paragraph 6: "Finally, in the Double-DS method of
> rolling a KSK, it is not a standby key that is present, it is a standby
> DS record in the parent zone."
> 
> 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. However, if the WG 
feel strongly enough then I suggest that we could either remove the words "it 
is not a standby key that is present," or change the wording to say "the 
standby key is not published in the zone, rather it is the DS RR derived from 
the standby key that is published in the parent zone.".

I do not see how the wording insinuates that it is somehow worse than having a 
"Double-Signature standby key".

> 
> Another remark. I guess this is not up for debate at this point but it
> really bothers me:
> 
> 2.3: Table 1. I don't like the names at all. It is confusing and
> inconsistent. KSK Double-Signature would in my opinion be better of
> called Double-DNSKEY. ZSK Double-Signature means: "do everything at
> once" whilst KSK Double-Signature means "do it staged". Similar to make
> it make consistent I would either cal ZSK Pre-Publication Double-DNSKEY
> or KSK Double-DS Pre-Publication. Perhaps:
> 
> +------------------+------------------+-----------------------------+
> | 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?

regards
John


---
j...@sinodun.com

http://sinodun.com

Sinodun Internet Technologies Ltd.
Stables 4, Suite 11,
Howbery Park,
Wallingford,
Oxfordshire,
OX10 8BA,
U.K.

+44 (0)1491 834957

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to