Skip to main content

Extensible Provisioning Protocol (EPP) Transport over TCP
draft-hollenbeck-rfc4934bis-01

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: 'Extensible Provisioning Protocol (EPP) Transport over TCP' to Full Standard

The IESG has approved the following document:

- 'Extensible Provisioning Protocol (EPP) Transport over TCP '
   <draft-hollenbeck-rfc4934bis-01.txt> as a Full 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-hollenbeck-rfc4934bis-01.txt

Ballot Text

Technical Summary
  This set of documents advances EPP to Standard.  References
  have been updated and non-normative text updates have been made.
  Some clarifications on TLS server sertificate verification were done.

Working Group Summary
  This is the product of an individual submitter, though the working
  group mailing list of PROVREG (now closed) was used to review the
  updates to the documents.

Document Quality
  Issues raised by AD review were addressed.
  There are multiple implementations of the protocol, as described in the
implementation report.

Personnel
  Edward Lewis is the document shepherd for this series
(draft-hollenbeck-rfc493*bis) of documents.
  Alexey Melnikov is the responsible Area Director.

RFC Editor note:

In Section 9, insert a new paragraph after the paragraph starting with
"If the server identity check fails". (The new paragraph would be
3rd to the last):

During the TLS negotiation, the EPP server MUST verify that the client
certificate matches the reference identity previously negotiated out
of band, as specified in section 8. The server should match the entire
subject name or the subjectAltName as described in RFC 5280. The server
MAY enforce other restrictions on the subjectAltName, for example if it
knows that a particular client is always connecting from a particular
hostname/IP address.

RFC Editor Note