draft-ietf-regext-change-poll-04.txt   draft-ietf-regext-change-poll-05.txt 
Network Working Group J. Gould Network Working Group J. Gould
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Intended status: Standards Track K. Feher Intended status: Standards Track K. Feher
Expires: April 21, 2018 Neustar Expires: July 6, 2018 Neustar
October 18, 2017 January 2, 2018
Change Poll Extension for the Extensible Provisioning Protocol (EPP) Change Poll Extension for the Extensible Provisioning Protocol (EPP)
draft-ietf-regext-change-poll-04 draft-ietf-regext-change-poll-05
Abstract Abstract
This document describes an Extensible Provisioning Protocol (EPP) This document describes an Extensible Provisioning Protocol (EPP)
extension for notifying clients of operations on client sponsored extension for notifying clients of operations on client sponsored
objects that were not initiated by the client through EPP. These objects that were not initiated by the client through EPP. These
operations MAY include contractual or policy requirements including operations MAY include contractual or policy requirements including
but not limited to regular batch processes, customer support actions, but not limited to regular batch processes, customer support actions,
Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid
Suspension (URS) actions, court directed actions, and bulk updates Suspension (URS) actions, court directed actions, and bulk updates
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2018. This Internet-Draft will expire on July 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Operation . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Operation . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Who . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Who . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Dates and Times . . . . . . . . . . . . . . . . . . . . . 5
3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 5 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 5
3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 5 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 5
3.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 5 3.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 5
3.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 5 3.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 5
3.1.3. EPP <transfer> Command . . . . . . . . . . . . . . . 15 3.1.3. EPP <transfer> Command . . . . . . . . . . . . . . . 15
3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 15 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 15
3.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 15 3.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 15
3.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 15 3.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 15
3.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 15 3.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 15
3.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 15 3.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 15
skipping to change at page 2, line 48 skipping to change at page 2, line 49
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 19
6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 20 6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 20
6.2. Verisign Consolidated Top Level Domain (CTLD) SRS . . . . 20 6.2. Verisign Consolidated Top Level Domain (CTLD) SRS . . . . 20
6.3. Verisign .COM / .NET SRS . . . . . . . . . . . . . . . . 20 6.3. Verisign .COM / .NET SRS . . . . . . . . . . . . . . . . 20
6.4. Neustar EPP SDK . . . . . . . . . . . . . . . . . . . . . 21 6.4. Neustar EPP SDK . . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
9. Normative References . . . . . . . . . . . . . . . . . . . . 22 9. Normative References . . . . . . . . . . . . . . . . . . . . 22
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 22 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 22
A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 22 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 22
A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 22 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 23
A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 23 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 23
A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 23 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 23
A.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 23 A.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 23
A.6. Change from 05 to REGEXT 00 . . . . . . . . . . . . . . . 23 A.6. Change from 05 to REGEXT 00 . . . . . . . . . . . . . . . 23
A.7. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 23 A.7. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 23
A.8. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 23 A.8. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 23
A.9. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 23 A.9. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 23
A.10. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 23 A.10. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 A.11. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
This document describes an extension mapping for version 1.0 of the This document describes an extension mapping for version 1.0 of the
Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an
extension to EPP object mappings like the EPP domain name mapping extension to EPP object mappings like the EPP domain name mapping
[RFC5731], is used to notify clients of operations they are not [RFC5731], is used to notify clients of operations they are not
directly involved in, on objects that the client sponsors. It is up directly involved in, on objects that the client sponsors. It is up
to server policy to determine what transform operations and clients to server policy to determine what transform operations and clients
to notify. Using this extension clients can more easily keep their to notify. Using this extension, clients can more easily keep their
systems in-sync with the objects stored in the server. When a change systems in-sync with the objects stored in the server. When a change
occurs that a client needs to be notified of, a poll message can be occurs that a client needs to be notified of, a poll message can be
inserted by the server for consumption by the client using the EPP inserted by the server for consumption by the client using the EPP
<poll> command and response defined in [RFC5730]. The extension <poll> command and response defined in [RFC5730]. The extension
supports including a "before" operation poll message and an "after" supports including a "before" operation poll message and an "after"
operation poll message. operation poll message.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 4, line 25 skipping to change at page 4, line 25
<changePoll:operation> element defines the operation. The OPTIONAL <changePoll:operation> element defines the operation. The OPTIONAL
"op" attribute is used to define a sub-operation or the name of a "op" attribute is used to define a sub-operation or the name of a
"custom" operation. The enumerated list of <changePoll:operation> "custom" operation. The enumerated list of <changePoll:operation>
values include: values include:
"create" Create operation as defined in [RFC5730]. "create" Create operation as defined in [RFC5730].
"delete" Delete operation as defined in [RFC5730]. If the delete "delete" Delete operation as defined in [RFC5730]. If the delete
operation results in an immediate purge of the object, then the operation results in an immediate purge of the object, then the
"op" attribute MUST be set to "purge". "op" attribute MUST be set to "purge".
"renew" Renew operation as defined in [RFC5730]. "renew" Renew operation as defined in [RFC5730].
"transfer" Transfer operation as defined in [RFC5730] with the "transfer" Transfer operation as defined in [RFC5730] that MUST set
OPTIONAL "op" attribute defining the transfer type with the the "op" attribute with one of the possible transfer type values
possible values of "request", "approve", "cancel", and "reject". that include "request", "approve", "cancel", or "reject".
"update" Update operation as defined in [RFC5730]. "update" Update operation as defined in [RFC5730].
"restore" Restore operation as defined in [RFC3915] with the "restore" Restore operation as defined in [RFC3915] that MUST set
OPTIONAL "op" attribute defining the restore type with the the "op" attribute with one of the possible restore type values
possible values of "request" and "report". that include "request" or "report".
"autoRenew" Auto renew operation executed by the server. "autoRenew" Auto renew operation executed by the server.
"autoDelete" Auto delete operation executed by the server. If the "autoDelete" Auto delete operation executed by the server. If the
"autoDelete" operation results in an immediate purge of the "autoDelete" operation results in an immediate purge of the
object, then the "op" attribute MUST be set to "purge". object, then the "op" attribute MUST be set to "purge".
"autoPurge" Auto purge operation executed by the server when "autoPurge" Auto purge operation executed by the server when
removing the object after it had the "pendingDelete" status. removing the object after it had the "pendingDelete" status.
"custom" Custom operation that uses the "op" attribute to define the "custom" Custom operation that MUST set the "op" attribute with the
custom operation name. custom operation name.
2.2. Who 2.2. Who
Who defines who executed the operation for audit purposes, and is The <changePoll:who> element defines who executed the operation for
represented using the <changePoll:who> element. The scheme used for audit purposes. The scheme used for the possible set of
the possible set of Who values is up to server policy. The server <changePoll:who> element values is up to server policy. The server
MAY identify Who based on: MAY identify the <changePoll:who> element value based on:
"Identifier" Unique user identifier of the user that executed the "Identifier" Unique user identifier of the user that executed the
operation. An example is "ClientX". operation. An example is "ClientX".
"Name" Name of the user that executed the operation. An example is "Name" Name of the user that executed the operation. An example is
"John Doe". "John Doe".
"Role" Role of the user that executed operation. An example is "Role" Role of the user that executed operation. An example is
"CSR" for a Customer Support Representative or "Batch" for a "CSR" for a Customer Support Representative or "Batch" for a
server batch. server batch.
2.3. Dates and Times
Date and time attribute values MUST be represented in Universal
Coordinated Time (UTC) using the Gregorian calendar. The extended
date-time form using upper case "T" and "Z" characters defined in
[W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time
values, as XML Schema does not support truncated date-time forms or
lower case "T" and "Z" characters.
3. EPP Command Mapping 3. EPP Command Mapping
A detailed description of the EPP syntax and semantics can be found A detailed description of the EPP syntax and semantics can be found
in the EPP core protocol specification [RFC5730]. in the EPP core protocol specification [RFC5730].
3.1. EPP Query Commands 3.1. EPP Query Commands
EPP provides three commands to retrieve object information: <check> EPP provides three commands to retrieve object information: <check>
to determine if an object is known to the server, <info> to retrieve to determine if an object is known to the server, <info> to retrieve
detailed information associated with an object, and <transfer> to detailed information associated with an object, and <transfer> to
skipping to change at page 5, line 31 skipping to change at page 5, line 40
3.1.1. EPP <check> Command 3.1.1. EPP <check> Command
This extension does not add any elements to the EPP <check> command This extension does not add any elements to the EPP <check> command
or <check> response described in the [RFC5730]. or <check> response described in the [RFC5730].
3.1.2. EPP <info> Command 3.1.2. EPP <info> Command
This extension does not add any elements to the EPP <info> command This extension does not add any elements to the EPP <info> command
described in the [RFC5730]. described in the [RFC5730].
This extension adds transaction detail of the operations to the EPP This extension adds operation detail of EPP object mapping operations
<info> poll response, as described in [RFC5730], of an EPP Object Section 2.1 to an EPP poll response, as described in [RFC5730], that
Mapping like [RFC5731]. Any transform operation to an object defined is an extension of the EPP object mapping info response. Any
in an EPP Object Mapping, by a client other than the sponsoring transform operation to an object defined in an EPP object mapping, by
client, MAY result in extending the <info> response of the object for a client other than the sponsoring client, MAY result in extending
inserting an EPP poll message with the operation detail. The the <info> response of the object for inserting an EPP poll message
sponsoring client will then receive the state of the object with with the operation detail. The sponsoring client will then receive
operation detail like what, who, when, and why the object was the state of the object with operation detail like what, who, when,
changed. The <changePoll:changeData> element contains the operation and why the object was changed. The <changePoll:changeData> element
detail along with an indication of whether the object reflects the contains the operation detail along with an indication of whether the
state before or after the operation, using the OPTIONAL "state" object reflects the state before or after the operation, using the
attribute, with the possible values of "before" or "after", and with OPTIONAL "state" attribute, with the possible values of "before" or
a default value of "after". The "state" attribute describes the "after", and with a default value of "after". The "state" attribute
state of the response data or <resData> block returned in the poll describes the state of the response data or <resData> block returned
response. The server MAY support providing the "before" state and in the poll response. The server MAY support providing the "before"
"after" state to the operation, by using one poll message for the state and "after" state to the operation, by using one poll message
"before" state and one poll message for the "after" state. When for the "before" state and one poll message for the "after" state.
using the "before" state poll message, it MUST be inserted prior to When using the "before" state poll message, it MUST be inserted prior
the "after" state poll message. The <changePoll:changeData> element to the "after" state poll message. The <changePoll:changeData>
includes the operation detail with the following child elements: element includes the operation detail with the following child
elements:
<changePoll:operation> Transform operation executed on the object as <changePoll:operation> Transform operation executed on the object as
defined in Section 2.1. defined in Section 2.1.
<changePoll:date> Date and time when the operation was executed. <changePoll:date> Date and time when the operation was executed.
<changePoll:svTRID> Server transaction identifier of the operation. <changePoll:svTRID> Server transaction identifier of the operation.
<changePoll:who> Who executed the operation as defined in <changePoll:who> Who executed the operation as defined in
Section 2.2. Section 2.2.
<changePoll:caseId> OPTIONAL case identifer associated with the <changePoll:caseId> OPTIONAL case identifer associated with the
operation. The required "type" attribute defines the type of operation. The required "type" attribute defines the type of
case with an enumerated list of case types including: case with an enumerated list of case types including:
skipping to change at page 21, line 47 skipping to change at page 21, line 47
protocol layers used by EPP. The security considerations described protocol layers used by EPP. The security considerations described
in these other specifications apply to this specification as well. in these other specifications apply to this specification as well.
8. Acknowledgements 8. Acknowledgements
The authors wish to acknowledge the original concept for this draft The authors wish to acknowledge the original concept for this draft
and the efforts in the initial versions of this draft by Trung Tran and the efforts in the initial versions of this draft by Trung Tran
and Sharon Wodjenski. and Sharon Wodjenski.
Special suggestions that have been incorporated into this document Special suggestions that have been incorporated into this document
were provided by Michael Holloway. were provided by Michael Holloway and Patrick Mevzek.
9. Normative References 9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, <https://www.rfc- DOI 10.17487/RFC3688, January 2004, <https://www.rfc-
skipping to change at page 22, line 39 skipping to change at page 22, line 39
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, Code: The Implementation Status Section", RFC 6982,
DOI 10.17487/RFC6982, July 2013, <https://www.rfc- DOI 10.17487/RFC6982, July 2013, <https://www.rfc-
editor.org/info/rfc6982>. editor.org/info/rfc6982>.
[RFC7451] Hollenbeck, S., "Extension Registry for the Extensible [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible
Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
February 2015, <https://www.rfc-editor.org/info/rfc7451>. February 2015, <https://www.rfc-editor.org/info/rfc7451>.
[W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Recommendation
REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
Appendix A. Change History Appendix A. Change History
A.1. Change from 00 to 01 A.1. Change from 00 to 01
1. Added an optional caseId element that defines the case identifier 1. Added an optional caseId element that defines the case identifier
from UDRP, URS, or custom case, based on feedback from Michael from UDRP, URS, or custom case, based on feedback from Michael
Holloway. Holloway.
A.2. Change from 01 to 02 A.2. Change from 01 to 02
skipping to change at page 23, line 40 skipping to change at page 23, line 46
A.9. Change from REGEXT 02 to REGEXT 03 A.9. Change from REGEXT 02 to REGEXT 03
1. Changed Neustar author to Kal Feher. 1. Changed Neustar author to Kal Feher.
A.10. Change from REGEXT 03 to REGEXT 04 A.10. Change from REGEXT 03 to REGEXT 04
1. Added Neustar implementation to the Implementation Status 1. Added Neustar implementation to the Implementation Status
section. section.
A.11. Change from REGEXT 04 to REGEXT 05
1. Updates based on feedback from Patrick Mevzek, that include:
1. Added a missing comma to "Using this extension, clients" in
the Introduction section.
2. Modified the description of the "transfer", "restore", and
"custom" operations to include "MUST set the "op" attribute"
language.
3. Rephrased the first sentence of the Who section.
4. Added references to the <changePoll:who> element in the Who
section.
5. Revise the sentence that describes how the extension extends
the info response in the EPP <info> Command section.
6. Refer to EPP Object Mapping as EPP object mapping throughout
the document.
7. Add a Dates and Times section to the Object Attributes
section.
Authors' Addresses Authors' Addresses
James Gould James Gould
VeriSign, Inc. VeriSign, Inc.
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
US US
Email: jgould@verisign.com Email: jgould@verisign.com
URI: http://www.verisigninc.com URI: http://www.verisigninc.com
 End of changes. 17 change blocks. 
40 lines changed or deleted 78 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/