Approval announcement
Draft of message to be sent after approval:
Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.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
Ballot Text
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.