Last Call Review of draft-ietf-dnsop-dnssec-key-timing-06
review-ietf-dnsop-dnssec-key-timing-06-secdir-lc-tsou-2014-12-18-00

Dear all,

I have reviewed this document as part of the security directorate’s ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written with the intent of improving security requirements and
considerations in IETF drafts.  Comments not addressed in last call may be
included in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

* Section 3.1:

Are all these states defined in this document. If not, please state
otherwise and provide a reference.

* Section 3.1, page 9:

> Dead        The key and is associated data are present in their
>             respective zones, but there is no longer information
>             anywhere that require their presence for use in
>             validation.  Hence they can be removed at any time.

It should say "and its associated..."

* Section 3.1, page 9:

> There is one additional state, used where [RFC5011] considerations
> are in effect (see Section 3.3.4):
>
> Revoked     The DNSKEY is published for a period with the "revoke"
>             bit set as a way of notifying validating resolvers that
>             have configured it as an [RFC5011] trust anchor that it
>             is about to be removed from the zone.

Please phrase this one without an introduction. e.g.:

Revoked     The DNSKEY is published for a period with the "revoke"
            bit set as a way of notifying validating resolvers that
            have configured it as an [RFC5011] trust anchor that it
            is about to be removed from the zone. This state is used
            where [RFC5011] considerations are in effect (see
            Section 3.3.4)

* Section 3.2.2., page 13:

> At the end of this interval, key N is said to be dead.  This occurs
> at the dead time (Tdea) so:
>
>           Tdea(N) = Tact(N+1) + Iret

Why not use this notation "Parameter(key_number)" for the figures? -- It
would make them way clearer.

* Section 3.3.5, page 23:
> In the case of an
> insecure parent, i.e. the initial creation of a new security apex, it
> is not possible to guarantee this.

Please define "security apex".

Happy holidays!

Thank you,
Tina