Automating DNSSEC Delegation Trust Maintenance
draft-ietf-dnsop-delegation-trust-maintainance-14

[Ballot comment]

You don't say (or I missed it while reading in a hurry;-) if
a child can have the new key be the same as the old key.
What happens if a child does that?

[Ballot discuss]
[Note to Stephen and probably Richard: Please avert your eyes. Reading this DISCUSS may damage your senses.]

Why in heavens name is this document not being put forward for Proposed Standard? There is no explanation at all in the shepherd writeup (no dessert for the shepherd tonight), and the ballot writeup only says that there may be more than one way to do this, which doesn't preclude this being a Proposed Standard. This document defines a new RRType and defines how it gets used. That sounds like protocol to me. What gives?

[Ballot comment]
Thanks for a very well written document, and for a good separation of normative and informative references.

Version -14 addresses my minor comments and clarifies the IANA considerations -- thanks.

[Ballot comment]
Section 1:
'This document is a compilation of two earlier drafts: draft-barwood-
  dnsop-ds-publish[I-D.ds-publish] and draft-wkumari-dnsop-ezkeyroll.'

Does draft-wkumari-dnsop-ezkeyroll exist or was that supposed to be a reference to draft-kumari-ogud-dnsop-cds? Either way, a citation is needed.

Section 2.2:
'After a Child DNS Operator first signs the zone, there is a need to
  interact with the Parent, for example via a delegation account
  interface, to "upload / paste-in the zone's DS information".'

What is being quoted here?

[Ballot discuss]
-- Section 7 --
This is a DISCUSS for the clarification of the registration of the CDNSKEY RR Type, as the authors promised to IANA.  No actual discussion with me is needed; I'll clear when the authors decide on the registration text and post it.

[Ballot comment]
Thanks for a very well written document, and for a good separation of normative and informative references.

-- Section 1 --

  This document is a compilation of two earlier drafts: draft-barwood-
  dnsop-ds-publish[I-D.ds-publish] and draft-wkumari-dnsop-ezkeyroll.

That should come out...

-- Section 2.1 --
It might make more sense to put some of this into a "road not taken" appendix, to make it clearer what's being proposed, and what's in other proposals, and not in this one.

-- Section 6.2 --

  However the
  precise out-of-band measures that a parent zone SHOULD take are
  outside the scope of this document.

I'm not sure what this "SHOULD" is really trying to say, and how it interacts with the "MAY" earlier in the paragraph.  Can you explain?  Perhaps some rewording of this paragraph would help.

-- Section 6.2.1 --

  In the case where the parent fetches the CDNSKEY RRset and calculates
  the DS it MAY be the case that the DS published in the parent zone is
  not identical with the data in the CDS resource record made available
  by the child.

This seems a wrong use of "MAY": it describes a situation that may happen, not a protocol option that MAY be taken.  A correct use of "MAY" here would say something about how the parent MAY accept a CDS even if it isn't identical with the DS, or some such.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dnsop-delegation-trust-maintainance-13.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

NOTE: the IANA Considerations section did not include an entry for the "Meaning" field for the CDNSKEY registration. Please verify that what we filled in is correct.

IANA understands that, upon approval of this document there are two IANA actions which must be completed.

First, in the Resource Record (RR) TYPEs registry in the Domain Name System (DNS) Parameters registry located at:

http://www.iana.org/assignments/dns-parameters/

the temporary assignment for 59 (CDS) is to be made permanent and the reference changed to [ RFC-to-be ].

Second, also in the Resource Record (RR) TYPEs registry in the Domain Name System (DNS) Parameters registry at

http://www.iana.org/assignments/dns-parameters/

a new resource record type is to be registered as follows:

Type: CDNSKEY
Value: [ TBD-at-registration ]
Meaning: Child DS Key
Template:
Reference: [ RFC-to-be ]

IANA notes the request in the IANA Considerations section that the value 60 be used for CDNSKEY.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Automating DNSSEC Delegation Trust Maintenance) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'Automating DNSSEC Delegation Trust Maintenance'
  as
Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-05-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes a method to allow DNS operators to more
  easily update DNSSEC Key Signing Keys using the DNS as communication
  channel.  The technique described is aimed at delegations in which it
  is currently hard to move information from the child to parent.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/ballot/


No IPR declarations have been submitted directly on this I-D.

1) This document is being requests as Informational and is so noted.


2)

Technical Summary

This document describes a method to allow DNS operators to more
  easily update DNSSEC Key Signing Keys using the DNS as communication
  channel.  The technique described is aimed at delegations in which it
  is currently hard to move information from the child to parent.


Working Group Summary

During the cycle of this document, there was much discussion on this method not being the only method to update this information. There was debate that the WG should wait to see what the Registrars will do in communicating with gTLDs.  There was rough consensus within the group, but also from the chairs, that each method can be described and documented in a RFC, if we felt the method would be deployed.

There were many iterations during WGLC, but mostly surrounding the wording, An additional Appendix section was added.

Tim Wicinski is the Document Shepherd and Joel Jaeggli is the Responsible Area Director.

The Document Shepherd did a thorough editorial and technical review of the document, and resolved any issues brought up during WGLC

The Document Shepherd does not have any concerns about the depth or breath of the reviews.  They were detailed and far ranging.

6) The Shepherd has no concerns for this document.

7)  All Authors have not problems conforming with BCP 78.

8) No IPR disclosure has been filed.

9) The Working Group consensus is very solid, and seemed to get stronger as the document went through the editorial cycle.

10) N/A

11) The document references the document draft-ietf-dnsop-dnssec-key-timing, which had been approved for publication but never followed through on, and is shown to be expired.

Additionally, the document references RFC2119 key word "NOT RECOMMENDED" without referencing it.

(12) N/A

13) yes.


(14)  N/A

(15) N/A

(16)  N/A


(17)  N/A

(18)

(19)