Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org> Subject: Protocol Action: 'Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)' to Proposed Standard The IESG has approved the following document: - 'Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) ' <draft-gould-rfc4310bis-07.txt> as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Alexey Melnikov. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gould-rfc4310bis-07.txt
Technical Summary This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security extensions (DNSSEC) for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. This document incorporates feedback from implementers and users. This document obsoletes RFC 4310. Working Group Summary This document is not a product of a working group, the people that have participated in the discussions on the document seem to have come to an agreement that this is a good specification. As this was not a product of a working group some people that actually work in this area did not know the discussion of updating RFC4310 was taking place. These same people once they joined the discussion made significant contributions. Document Quality There are existing implementations of RFC 4310. This document is based on feedback from such implementors. Personnel Olafur Gudmundsson is the Document Shepherd for this document. Alexey Melnikov is the responsible AD. RFC Editor Note In Section 4.1, 1st paragraph, last sentence: The key data SHOULD have the Secure Entry Point (SEP) bit set as described in RFC 3757 [RFC3757]. Please add a second reference to RFC 4034 at the end.