Automating DNSSEC Delegation Trust Maintenance
RFC 7344
Yes
No Objection
Note: This ballot was opened for revision 13 and is now closed.
(Joel Jaeggli; former steering group member) Yes
(Richard Barnes; former steering group member) Yes
I actually sort of agree with Pete that this would be better as PS. But I don't care enough to block the document.
(Adrian Farrel; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
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?
(Barry Leiba; former steering group member) (was Discuss) No Objection
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.
(Brian Haberman; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) (was Discuss) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
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?
(Ted Lemon; former steering group member) No Objection
I support Pete's DISCUSS.