Change Poll Extension for the Extensible Provisioning Protocol (EPP)
RFC 8590

Received changes through RFC Editor sync (created alias RFC 8590, changed abstract to 'This document describes an Extensible Provisioning Protocol (EPP) extension for notifying clients of operations on client-sponsored objects that were not initiated by the client through EPP.  These operations may include contractual or policy requirements including, but not limited to, regular batch processes, customer support actions, Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid Suspension (URS) actions, court-directed actions, and bulk updates based on customer requests.  Since the client is not directly involved or knowledgable of these operations, the extension is used along with an EPP object mapping to provide the resulting state of the postoperation object, and optionally a preoperation object, with the operation metadata of what, when, who, and why.', changed pages to 20, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2019-05-10, changed IESG state to RFC Published)

[Ballot comment]
Thank you for resolving my Discuss point!  Original ballot Comment section preserved below:


Thanks for the generally well-written document!

There are several places in the document where we read about a "list of [...]
values includes" that is in fact required to be one of a fixed enumerated set
of values.  In such cases I would suggest "comprises" or "is" rather than "includes",
which could be taken to indicate the possibility of additional values being defined
at a later time.  Section 2.1 has multiple instances of this, and Section 3.12. as well.

Section 2.2

Maybe state explicitly what it's inserted into, for clarity.

Section 2.3

"CSR" could expand to either "Customer Support Representative" or
"Certificate Signing Request" for some people.  I don't know if there's
better name to suggest.

Section 2.4

I don't know if it's worth saying anything that would remind recipients of
their (non-?)obligation to accept time values that correspond to leap
seconds, but IIRC we've seen cases in the past of software that chokes when
presented with leap-second timestamps.

[Ballot discuss]
This is a fairly minor point, but the text of Section 2.3 implies that there is
a distinct list of identifier types that the server MAY use (and thus that there would
be a protocol element to convey such an identifier type), but the actual schema in
Section 4.1 is clear that the  element is just a freeform token with
some modest length restrictions (i.e., no place for internal structure).  I'd like to
hear from others on the IESG whether the text about the schema used being up
to server policy is enough to make this clear, or we think there is some level of
internal inconsistency in the document to be rectified.

[Ballot comment]
Thanks for the generally well-written document!

There are several places in the document where we read about a "list of [...]
values includes" that is in fact required to be one of a fixed enumerated set
of values.  In such cases I would suggest "comprises" or "is" rather than "includes",
which could be taken to indicate the possibility of additional values being defined
at a later time.  Section 2.1 has multiple instances of this, and Section 3.12. as well.

Section 2.2

Maybe state explicitly what it's inserted into, for clarity.

Section 2.3

"CSR" could expand to either "Customer Support Representative" or
"Certificate Signing Request" for some people.  I don't know if there's
better name to suggest.

Section 2.4

I don't know if it's worth saying anything that would remind recipients of
their (non-?)obligation to accept time values that correspond to leap
seconds, but IIRC we've seen cases in the past of software that chokes when
presented with leap-second timestamps.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-regext-change-poll-10. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that upon approval of this document, there are three actions we must complete.

First, in the ns registry on the IETF XML Registry page located at

https://www.iana.org/assignments/xml-registry/

a single new registration will be made:

ID: changePoll-1.0
URI: urn:ietf:params:xml:ns:changePoll-1.0
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we have initiated the required expert review via a separate request.

Second, in the schema registry also on the IETF XML Registry page located at

https://www.iana.org/assignments/xml-registry/

a single new registration will be made:

ID: changePoll-1.0
URI: urn:ietf:params:xml:schema:changePoll-1.0
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we have initiated the required expert review via a separate request.

Third, in the Extensions for the Extensible Provisioning Protocol (EPP) registry located at:

https://www.iana.org/assignments/epp-extensions/

a single new registration will be made:

Name of Extension: Change Poll Extension for the Extensible Provisioning Protocol (EPP)
Document Status: Standards Track
Reference: [ RFC-to-be ]
Registrant: IESG
TLDs: Any
IPR Disclosure: None
Status: Active
Notes: None

As this document requests registrations in a Specification Required (see RFC 8126) registry, we have initiated the required expert review via a separate request.

The IANA Functions Operator understands that these are the only actions required upon approval of this document.

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 meant only to confirm the list of actions that will be performed.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-11-05):

From: The IESG
To: IETF-Announce
CC: " rcarney@godaddy.com" , adam@nostrum.com, regext-chairs@ietf.org, rcarney@godaddy.com, draft-ietf-regext-change-poll@ietf.org, regext@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Change Poll Extension for the Extensible Provisioning Protocol (EPP)) to Proposed Standard


The IESG has received a request from the Registration Protocols Extensions WG
(regext) to consider the following document: - 'Change Poll Extension for the
Extensible Provisioning Protocol (EPP)'
  as Proposed Standard

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 2018-11-05. 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 an Extensible Provisioning Protocol (EPP)
  extension for notifying clients of operations on client-sponsored
  objects that were not initiated by the client through EPP.  These
  operations may include contractual or policy requirements including
  but not limited to regular batch processes, customer support actions,
  Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid
  Suspension (URS) actions, court-directed actions, and bulk updates
  based on customer requests.  Since the client is not directly
  involved or knowledgable of these operations, the extension is used
  along with an EPP object mapping to provide the resulting state of
  the post-operation object, and optionally a pre-operation object,
  with the operation meta-data of what, when, who, and why.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/ballot/


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

Technical Summary

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for change poll notifications.

Working Group Summary

draft-ietf-regext-change-poll is on standards track.  This extension adds additional elements to the EPP domain name mapping defined in RFC 5731, which is an internet standard.

Document Quality

This document has been widely discussed on the mailing lists of the regext and eppext working groups.  The authors have addressed all comments and many changes have been incorporated in the document. 

Verisign and Neustar both have working implementations of this specification.


Personnel

Document shepherd is Roger Carney, rcarney@godaddy.com
Area Director is Adam Roach, adam@nostrum.com

Shepherd Comments

As document shepherd I have verified that all XML examples against the provided  schema and EPP schemas from RFC 5730 and RFC 5371. Some examples have left out part of the XML to be more concise and better show the point of the introduced changes. These examples have been verified by the document shepherd with added XML data.

The author has confirmed following BCP78 and BCP79 in the document header. No IPR disclosures have been submitted for this document.

The IANA considerations follow the defined format for the submission to the XML and EPP registries.

All normative and informative references have been verified.

After carefully reviewing the mailings lists of the regext and eppext working groups I have found no objections to this document. From IETF meetings I recall consensus that this document is ready for publication.

As document shepherd, I believe this document is ready for publication.