--- 1/draft-ietf-regext-launchphase-03.txt 2017-04-27 11:13:16.919745673 -0700 +++ 2/draft-ietf-regext-launchphase-04.txt 2017-04-27 11:13:17.023747959 -0700 @@ -1,21 +1,21 @@ Internet Engineering Task Force J. Gould Internet-Draft VeriSign, Inc. Intended status: Standards Track W. Tan -Expires: October 26, 2017 Cloud Registry +Expires: October 29, 2017 Cloud Registry G. Brown CentralNic Ltd - April 24, 2017 + April 27, 2017 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) - draft-ietf-regext-launchphase-03 + draft-ietf-regext-launchphase-04 Abstract This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of domain name registrations and applications during the launch of a domain name registry. Status of This Memo @@ -25,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -117,20 +117,21 @@ A.15. Change EPPEXT 01 to EPPEXT 02 . . . . . . . . . . . . . . 61 A.16. Change EPPEXT 02 to EPPEXT 03 . . . . . . . . . . . . . . 62 A.17. Change EPPEXT 03 to EPPEXT 04 . . . . . . . . . . . . . . 62 A.18. Change EPPEXT 04 to EPPEXT 05 . . . . . . . . . . . . . . 62 A.19. Change EPPEXT 05 to EPPEXT 06 . . . . . . . . . . . . . . 62 A.20. Change EPPEXT 06 to EPPEXT 07 . . . . . . . . . . . . . . 62 A.21. Change from EPPEXT 07 to REGEXT 00 . . . . . . . . . . . 63 A.22. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 63 A.23. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 63 A.24. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 63 + A.25. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 1. Introduction This document describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping specifies a flexible schema that can be used to implement several common use cases related to the provisioning and management of domain name registrations and applications during the launch of a domain name registry. @@ -143,27 +144,27 @@ The EPP domain name mapping [RFC5731] is designed for the steady- 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 mapping [RFC5731]. For example, registries often accept multiple applications for the same domain name during the "Sunrise" launch phase, referred to as a Launch Application. A Launch Registration refers to a registration made during a launch phase when the server uses a "first-come, first-served" model. Even in a "first-come, first-served" model, additional steps and information might be - required, such as trademark information. In addition, the [RFC7848] - defines a registry interface for the Trademark Claims or "claims" - launch phase that includes support for presenting a Trademark Claims - Notice to the Registrant. This document proposes an extension to the - domain name mapping in order to provide a uniform interface for the - management of Launch Applications and Launch Registrations in launch - phases. + required, such as trademark information. In addition, RFC 7848 + [RFC7848] defines a registry interface for the Trademark Claims or + "claims" launch phase that includes support for presenting a + Trademark Claims Notice to the Registrant. This document proposes an + extension to the domain name mapping in order to provide a uniform + interface for the management of Launch Applications and Launch + Registrations in launch phases. 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming @@ -194,53 +195,51 @@ 2. Object Attributes This extension adds additional elements to the EPP domain name mapping [RFC5731]. Only those new elements are described here. 2.1. Application Identifier Servers MAY allow multiple applications, referred to as a Launch Application, of the same domain name during its launch phase - operations. Upon receiving a valid request to create a Launch - Application, the server MUST create an application object + operations. Upon receiving a valid command to create + a Launch Application, the server MUST create an application object corresponding to the request, assign an application identifier for the Launch Application, set the [RFC5731] pendingCreate status, and return the application identifier to the client with the element. In order to facilitate correlation, all subsequent launch operations on the Launch Application MUST be qualified by the previously assigned application identifier using the element. - If the 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 The Validator Identifier is the unique identifier for a Trademark Validator that validates marks and has a repository of validated marks. The OPTIONAL "validatorID" attribute is used to define the Validator Identifier of the Trademark Validator. Registries MAY support more than one Third Party Trademark Validator. The Internet Corporation for Assigned Names and Numbers (ICANN) Trademark Clearinghouse (TMCH) is the default Trademark Validator and is reserved the Validator Identifier of "tmch". If the ICANN TMCH is not used or multiple Trademark Validators are used, the Validator Identifier MUST be defined using the "validatorID" attribute. The Validator Identifier MAY be related to one or more issuer identifiers of the element and the element defined in [RFC7848]. Both the Validator Identifier and the Issuer - Identifier used MUST be unique. The list of validator identifiers - and the relationship to issuer identifiers is out of scope for this - document. + Identifier used MUST be unique. If the ICANN TMCH is not used or + multiple Trademark Validators are used, the server MUST define the + 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 supports a form of claims. 2.3. Launch Phases The server MAY support multiple launch phases sequentially or simultaneously. The element MUST be included by the client to define the target launch phase of the command. The server SHOULD validate the phase and MAY validate the sub-phase of the @@ -448,34 +447,35 @@ / \ / \ | allocated | | rejected | \ / \ / +---------+ +--------+ Figure 2 2.5. Poll Messaging A Launch Application MUST and a Launch Registration MAY be handled as - a domain name of [RFC5731] in "pendingCreate" status, with the launch - status values defined in Section 2.4. As a Launch Application or - Launch Registration transitions between the status values defined in - Section 2.4, the server SHOULD insert poll messages, per [RFC5730], - for the applicable intermediate statuses, including the - "pendingValidation", "validated", "pendingAllocation, and "invalid" - statuses, using the element with the - extension. The element MAY contain - non-mandatory information, like contact and name server information. - Also, further extensions that would normally be included in the - response of a command, per [RFC5731], MAY be included. - For the final statuses, including the "allocated" and "rejected" - statuses, the server MUST insert a poll message, per - [RFC5731], with the extension. + an EPP domain name object as specified in RFC 5731 [RFC5731] in + "pendingCreate" status, with the launch status values defined in + Section 2.4. As a Launch Application or Launch Registration + transitions between the status values defined in Section 2.4, the + server SHOULD insert poll messages, per [RFC5730], for the applicable + intermediate statuses, including the "pendingValidation", + "validated", "pendingAllocation, and "invalid" statuses, using the + element with the extension. The + element MAY contain non-mandatory information, like + contact and name server information. Also, further extensions that + would normally be included in the response of a + command, per [RFC5731], MAY be included. For the final statuses, + including the "allocated" and "rejected" statuses, the server MUST + insert a poll message, per [RFC5731], with the + extension. The following is an example poll message for a Launch Application that has transitioned to the "pendingAllocation" state. S: S: S: S: S: Command completed successfully; ack to dequeue S: @@ -1727,21 +1727,21 @@ schema. The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML 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 registration purposes. 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. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. o Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in @@ -2315,25 +2315,25 @@ fields that are publicly accessible. 8. Acknowledgements The authors wish to acknowledge the efforts of the leading participants of the Community TMCH Model that led to many of the changes to this document, which include Chris Wright, Jeff Neuman, Jeff Eckhaus, and Will Shorter. Special suggestions that have been incorporated into this document - were provided by Jothan Frakes, Keith Gaughan, Seth Goldman, Michael - Holloway, Jan Jansen, Rubens Kuhl, Ben Levac, Gustavo Lozano, Klaus - Malorny, Alexander Mayrhofer, Patrick Mevzek, James Mitchell, - Francisco Obispo, Mike O'Connell, Bernhard Reutner-Fischer, Trung - Tran, Ulrich Wisser and Sharon Wodjenski. + were provided by Jothan Frakes, Keith Gaughan, Seth Goldman, Scott + Hollenbeck, Michael Holloway, Jan Jansen, Rubens Kuhl, Ben Levac, + Gustavo Lozano, Klaus Malorny, Alexander Mayrhofer, Patrick Mevzek, + James Mitchell, Francisco Obispo, Mike O'Connell, Bernhard Reutner- + Fischer, Trung Tran, Ulrich Wisser and Sharon Wodjenski. Some of the description of the Trademark Claims Phase was based on the work done by Gustavo Lozano in the ICANN TMCH functional specifications. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, @@ -2634,22 +2634,38 @@ A.23. Change from REGEXT 01 to REGEXT 02 1. Removed the reference to ietf-regext-tmch-func-spec and briefly described the trademark claims phase that is relavent to draft- ietf-regext-launchphase. A.24. Change from REGEXT 02 to REGEXT 03 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 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 VeriSign, Inc. 12061 Bluemont Way Reston, VA 20190 US Email: jgould@verisign.com URI: http://www.verisigninc.com Wil Tan