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