draft-ietf-regext-launchphase-03.txt   draft-ietf-regext-launchphase-04.txt 
Internet Engineering Task Force J. Gould Internet Engineering Task Force J. Gould
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Intended status: Standards Track W. Tan Intended status: Standards Track W. Tan
Expires: October 26, 2017 Cloud Registry Expires: October 29, 2017 Cloud Registry
G. Brown G. Brown
CentralNic Ltd CentralNic Ltd
April 24, 2017 April 27, 2017
Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)
draft-ietf-regext-launchphase-03 draft-ietf-regext-launchphase-04
Abstract Abstract
This document describes an Extensible Provisioning Protocol (EPP) This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for the provisioning and management of domain name extension mapping for the provisioning and management of domain name
registrations and applications during the launch of a domain name registrations and applications during the launch of a domain name
registry. registry.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 October 26, 2017. This Internet-Draft will expire on October 29, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 3, line 34 skipping to change at page 3, line 34
A.15. Change EPPEXT 01 to EPPEXT 02 . . . . . . . . . . . . . . 61 A.15. Change EPPEXT 01 to EPPEXT 02 . . . . . . . . . . . . . . 61
A.16. Change EPPEXT 02 to EPPEXT 03 . . . . . . . . . . . . . . 62 A.16. Change EPPEXT 02 to EPPEXT 03 . . . . . . . . . . . . . . 62
A.17. Change EPPEXT 03 to EPPEXT 04 . . . . . . . . . . . . . . 62 A.17. Change EPPEXT 03 to EPPEXT 04 . . . . . . . . . . . . . . 62
A.18. Change EPPEXT 04 to EPPEXT 05 . . . . . . . . . . . . . . 62 A.18. Change EPPEXT 04 to EPPEXT 05 . . . . . . . . . . . . . . 62
A.19. Change EPPEXT 05 to EPPEXT 06 . . . . . . . . . . . . . . 62 A.19. Change EPPEXT 05 to EPPEXT 06 . . . . . . . . . . . . . . 62
A.20. Change EPPEXT 06 to EPPEXT 07 . . . . . . . . . . . . . . 62 A.20. Change EPPEXT 06 to EPPEXT 07 . . . . . . . . . . . . . . 62
A.21. Change from EPPEXT 07 to REGEXT 00 . . . . . . . . . . . 63 A.21. Change from EPPEXT 07 to REGEXT 00 . . . . . . . . . . . 63
A.22. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 63 A.22. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 63
A.23. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 63 A.23. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 63
A.24. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 63 A.24. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 63
A.25. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
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 EPP mapping Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping
specifies a flexible schema that can be used to implement several specifies a flexible schema that can be used to implement several
common use cases related to the provisioning and management of domain common use cases related to the provisioning and management of domain
name registrations and applications during the launch of a domain name registrations and applications during the launch of a domain
name registry. name registry.
skipping to change at page 4, line 14 skipping to change at page 4, line 14
The EPP domain name mapping [RFC5731] is designed for the steady- The EPP domain name mapping [RFC5731] is designed for the steady-
state operation of a registry. During a launch period, the model in state operation of a registry. During a launch period, the model in
place may be different from what is defined in the EPP domain name place may be different from what is defined in the EPP domain name
mapping [RFC5731]. For example, registries often accept multiple mapping [RFC5731]. For example, registries often accept multiple
applications for the same domain name during the "Sunrise" launch applications for the same domain name during the "Sunrise" launch
phase, referred to as a Launch Application. A Launch Registration phase, referred to as a Launch Application. A Launch Registration
refers to a registration made during a launch phase when the server refers to a registration made during a launch phase when the server
uses a "first-come, first-served" model. Even in a "first-come, uses a "first-come, first-served" model. Even in a "first-come,
first-served" model, additional steps and information might be first-served" model, additional steps and information might be
required, such as trademark information. In addition, the [RFC7848] required, such as trademark information. In addition, RFC 7848
defines a registry interface for the Trademark Claims or "claims" [RFC7848] defines a registry interface for the Trademark Claims or
launch phase that includes support for presenting a Trademark Claims "claims" launch phase that includes support for presenting a
Notice to the Registrant. This document proposes an extension to the Trademark Claims Notice to the Registrant. This document proposes an
domain name mapping in order to provide a uniform interface for the extension to the domain name mapping in order to provide a uniform
management of Launch Applications and Launch Registrations in launch interface for the management of Launch Applications and Launch
phases. Registrations in launch phases.
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
XML is case sensitive. Unless stated otherwise, XML specifications XML is case sensitive. Unless stated otherwise, XML specifications
and examples provided in this document MUST be interpreted in the and examples provided in this document MUST be interpreted in the
character case presented in order to develop a conforming character case presented in order to develop a conforming
skipping to change at page 5, line 16 skipping to change at page 5, line 16
2. Object Attributes 2. Object Attributes
This extension adds additional elements to the EPP domain name This extension adds additional elements to the EPP domain name
mapping [RFC5731]. Only those new elements are described here. mapping [RFC5731]. Only those new elements are described here.
2.1. Application Identifier 2.1. Application Identifier
Servers MAY allow multiple applications, referred to as a Launch Servers MAY allow multiple applications, referred to as a Launch
Application, of the same domain name during its launch phase Application, of the same domain name during its launch phase
operations. Upon receiving a valid request to create a Launch operations. Upon receiving a valid <domain:create> command to create
Application, the server MUST create an application object a Launch Application, the server MUST create an application object
corresponding to the request, assign an application identifier for corresponding to the request, assign an application identifier for
the Launch Application, set the [RFC5731] pendingCreate status, and the Launch Application, set the [RFC5731] pendingCreate status, and
return the application identifier to the client with the return the application identifier to the client with the
<launch:applicationID> element. In order to facilitate correlation, <launch:applicationID> element. In order to facilitate correlation,
all subsequent launch operations on the Launch Application MUST be all subsequent launch operations on the Launch Application MUST be
qualified by the previously assigned application identifier using the qualified by the previously assigned application identifier using the
<launch:applicationID> element. <launch:applicationID> element.
If the <domain:create> command processes a request synchronously
without the use of an intermediate Launch Application, then an
application identifier MAY not be needed.
2.2. Validator Identifier 2.2. Validator Identifier
The Validator Identifier is the unique identifier for a Trademark The Validator Identifier is the unique identifier for a Trademark
Validator that validates marks and has a repository of validated Validator that validates marks and has a repository of validated
marks. The OPTIONAL "validatorID" attribute is used to define the marks. The OPTIONAL "validatorID" attribute is used to define the
Validator Identifier of the Trademark Validator. Registries MAY Validator Identifier of the Trademark Validator. Registries MAY
support more than one Third Party Trademark Validator. The Internet support more than one Third Party Trademark Validator. The Internet
Corporation for Assigned Names and Numbers (ICANN) Trademark Corporation for Assigned Names and Numbers (ICANN) Trademark
Clearinghouse (TMCH) is the default Trademark Validator and is Clearinghouse (TMCH) is the default Trademark Validator and is
reserved the Validator Identifier of "tmch". If the ICANN TMCH is reserved the Validator Identifier of "tmch". If the ICANN TMCH is
not used or multiple Trademark Validators are used, the Validator not used or multiple Trademark Validators are used, the Validator
Identifier MUST be defined using the "validatorID" attribute. Identifier MUST be defined using the "validatorID" attribute.
The Validator Identifier MAY be related to one or more issuer The Validator Identifier MAY be related to one or more issuer
identifiers of the <mark:id> element and the <smd:id> element defined identifiers of the <mark:id> element and the <smd:id> element defined
in [RFC7848]. Both the Validator Identifier and the Issuer in [RFC7848]. Both the Validator Identifier and the Issuer
Identifier used MUST be unique. The list of validator identifiers Identifier used MUST be unique. If the ICANN TMCH is not used or
and the relationship to issuer identifiers is out of scope for this multiple Trademark Validators are used, the server MUST define the
document. list of supported validator identifiers and MUST make this
information available to clients using a mutually acceptable, out-of-
band mechanism.
The Validator Identifier MAY define a non-Trademark Validator that The Validator Identifier MAY define a non-Trademark Validator that
supports a form of claims. supports a form of claims.
2.3. Launch Phases 2.3. Launch Phases
The server MAY support multiple launch phases sequentially or The server MAY support multiple launch phases sequentially or
simultaneously. The <launch:phase> element MUST be included by the simultaneously. The <launch:phase> element MUST be included by the
client to define the target launch phase of the command. The server client to define the target launch phase of the command. The server
SHOULD validate the phase and MAY validate the sub-phase of the SHOULD validate the phase and MAY validate the sub-phase of the
skipping to change at page 11, line 8 skipping to change at page 11, line 8
/ \ / \ / \ / \
| allocated | | rejected | | allocated | | rejected |
\ / \ / \ / \ /
+---------+ +--------+ +---------+ +--------+
Figure 2 Figure 2
2.5. Poll Messaging 2.5. Poll Messaging
A Launch Application MUST and a Launch Registration MAY be handled as A Launch Application MUST and a Launch Registration MAY be handled as
a domain name of [RFC5731] in "pendingCreate" status, with the launch an EPP domain name object as specified in RFC 5731 [RFC5731] in
status values defined in Section 2.4. As a Launch Application or "pendingCreate" status, with the launch status values defined in
Launch Registration transitions between the status values defined in Section 2.4. As a Launch Application or Launch Registration
Section 2.4, the server SHOULD insert poll messages, per [RFC5730], transitions between the status values defined in Section 2.4, the
for the applicable intermediate statuses, including the server SHOULD insert poll messages, per [RFC5730], for the applicable
"pendingValidation", "validated", "pendingAllocation, and "invalid" intermediate statuses, including the "pendingValidation",
statuses, using the <domain:infData> element with the "validated", "pendingAllocation, and "invalid" statuses, using the
<launch:infData> extension. The <domain:infData> element MAY contain <domain:infData> element with the <launch:infData> extension. The
non-mandatory information, like contact and name server information. <domain:infData> element MAY contain non-mandatory information, like
Also, further extensions that would normally be included in the contact and name server information. Also, further extensions that
response of a <domain:info> command, per [RFC5731], MAY be included. would normally be included in the response of a <domain:info>
For the final statuses, including the "allocated" and "rejected" command, per [RFC5731], MAY be included. For the final statuses,
statuses, the server MUST insert a <domain:panData> poll message, per including the "allocated" and "rejected" statuses, the server MUST
[RFC5731], with the <launch:infData> extension. insert a <domain:panData> poll message, per [RFC5731], with the
<launch:infData> extension.
The following is an example poll message for a Launch Application The following is an example poll message for a Launch Application
that has transitioned to the "pendingAllocation" state. that has transitioned to the "pendingAllocation" state.
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response> S: <response>
S: <result code="1301"> S: <result code="1301">
S: <msg>Command completed successfully; ack to dequeue</msg> S: <msg>Command completed successfully; ack to dequeue</msg>
S: </result> S: </result>
skipping to change at page 44, line 24 skipping to change at page 44, line 24
schema. schema.
The formal syntax presented here is a complete schema representation The formal syntax presented here is a complete schema representation
of the object mapping suitable for automated validation of EPP XML of the object mapping suitable for automated validation of EPP XML
instances. The BEGIN and END tags are not part of the schema; they instances. The BEGIN and END tags are not part of the schema; they
are used to note the beginning and ending of the schema for URI are used to note the beginning and ending of the schema for URI
registration purposes. registration purposes.
4.1. Launch Schema 4.1. Launch Schema
Copyright (c) 2012 IETF Trust and the persons identified as authors Copyright (c) 2017 IETF Trust and the persons identified as authors
of the code. All rights reserved. of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions modification, are permitted provided that the following conditions
are met: are met:
o Redistributions of source code must retain the above copyright o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer. notice, this list of conditions and the following disclaimer.
o Redistributions in binary form must reproduce the above copyright o Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in notice, this list of conditions and the following disclaimer in
skipping to change at page 56, line 40 skipping to change at page 56, line 40
fields that are publicly accessible. fields that are publicly accessible.
8. Acknowledgements 8. Acknowledgements
The authors wish to acknowledge the efforts of the leading The authors wish to acknowledge the efforts of the leading
participants of the Community TMCH Model that led to many of the participants of the Community TMCH Model that led to many of the
changes to this document, which include Chris Wright, Jeff Neuman, changes to this document, which include Chris Wright, Jeff Neuman,
Jeff Eckhaus, and Will Shorter. Jeff Eckhaus, and Will Shorter.
Special suggestions that have been incorporated into this document Special suggestions that have been incorporated into this document
were provided by Jothan Frakes, Keith Gaughan, Seth Goldman, Michael were provided by Jothan Frakes, Keith Gaughan, Seth Goldman, Scott
Holloway, Jan Jansen, Rubens Kuhl, Ben Levac, Gustavo Lozano, Klaus Hollenbeck, Michael Holloway, Jan Jansen, Rubens Kuhl, Ben Levac,
Malorny, Alexander Mayrhofer, Patrick Mevzek, James Mitchell, Gustavo Lozano, Klaus Malorny, Alexander Mayrhofer, Patrick Mevzek,
Francisco Obispo, Mike O'Connell, Bernhard Reutner-Fischer, Trung James Mitchell, Francisco Obispo, Mike O'Connell, Bernhard Reutner-
Tran, Ulrich Wisser and Sharon Wodjenski. Fischer, Trung Tran, Ulrich Wisser and Sharon Wodjenski.
Some of the description of the Trademark Claims Phase was based on Some of the description of the Trademark Claims Phase was based on
the work done by Gustavo Lozano in the ICANN TMCH functional the work done by Gustavo Lozano in the ICANN TMCH functional
specifications. specifications.
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, DOI 10.17487/RFC2119, March 1997,
skipping to change at page 63, line 28 skipping to change at page 63, line 28
A.23. Change from REGEXT 01 to REGEXT 02 A.23. Change from REGEXT 01 to REGEXT 02
1. Removed the reference to ietf-regext-tmch-func-spec and briefly 1. Removed the reference to ietf-regext-tmch-func-spec and briefly
described the trademark claims phase that is relavent to draft- described the trademark claims phase that is relavent to draft-
ietf-regext-launchphase. ietf-regext-launchphase.
A.24. Change from REGEXT 02 to REGEXT 03 A.24. Change from REGEXT 02 to REGEXT 03
1. Ping update. 1. Ping update.
Authors' Addresses A.25. Change from REGEXT 03 to REGEXT 04
1. Updates based on feedback from Scott Hollenbeck that include:
1. Nit on reference to RFC 7848 in section 1.
2. Added reference to <domain:create> for the request to create
a Launch Application in section 2.1.
3. Removed the second paragraph of section 2.1 describing the
option of creating an application identifier for a Launch
Registration.
4. Provided clarification in section 2.2 on the responsibility
of the server to ensure that the supported validator
identifiers are unique.
5. Updated the text in section 2.5 referencing the domain name
object in RFC 5731.
6. Updated the copyright to 2017 in section 4.1.
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
Wil Tan Wil Tan
 End of changes. 14 change blocks. 
41 lines changed or deleted 57 lines changed or added

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