--- 1/draft-ietf-regext-launchphase-00.txt 2016-09-29 08:15:57.803024118 -0700 +++ 2/draft-ietf-regext-launchphase-01.txt 2016-09-29 08:15:57.907026743 -0700 @@ -1,21 +1,21 @@ Internet Engineering Task Force J. Gould Internet-Draft VeriSign, Inc. Intended status: Standards Track W. Tan -Expires: October 27, 2016 Cloud Registry +Expires: April 2, 2017 Cloud Registry G. Brown CentralNic Ltd - April 25, 2016 + September 29, 2016 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) - draft-ietf-regext-launchphase-00 + draft-ietf-regext-launchphase-01 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 27, 2016. + This Internet-Draft will expire on April 2, 2017. Copyright Notice Copyright (c) 2016 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 @@ -97,36 +97,37 @@ 6.7. gTLD Shared Registry System . . . . . . . . . . . . . . . 53 7. Security Considerations . . . . . . . . . . . . . . . . . . . 54 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 9. Normative References . . . . . . . . . . . . . . . . . . . . 54 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 55 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 55 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 55 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 56 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 56 A.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 56 - A.6. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 57 + A.6. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 56 A.7. Change from 06 to 07 . . . . . . . . . . . . . . . . . . 57 A.8. Change from 07 to 08 . . . . . . . . . . . . . . . . . . 57 A.9. Change from 08 to 09 . . . . . . . . . . . . . . . . . . 57 A.10. Change from 09 to 10 . . . . . . . . . . . . . . . . . . 58 A.11. Change from 10 to 11 . . . . . . . . . . . . . . . . . . 59 A.12. Change from 11 to 12 . . . . . . . . . . . . . . . . . . 59 A.13. Change from 12 to EPPEXT 00 . . . . . . . . . . . . . . . 59 A.14. Change EPPEXT 00 to EPPEXT 01 . . . . . . . . . . . . . . 59 A.15. Change EPPEXT 01 to EPPEXT 02 . . . . . . . . . . . . . . 59 A.16. Change EPPEXT 02 to EPPEXT 03 . . . . . . . . . . . . . . 60 A.17. Change EPPEXT 03 to EPPEXT 04 . . . . . . . . . . . . . . 60 A.18. Change EPPEXT 04 to EPPEXT 05 . . . . . . . . . . . . . . 60 A.19. Change EPPEXT 05 to EPPEXT 06 . . . . . . . . . . . . . . 60 A.20. Change EPPEXT 06 to EPPEXT 07 . . . . . . . . . . . . . . 60 A.21. Change from EPPEXT 07 to REGEXT 00 . . . . . . . . . . . 61 + A.22. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 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. @@ -139,27 +140,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 - [I-D.ietf-eppext-tmch-smd] 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, 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. 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 @@ -170,32 +171,30 @@ white space in examples are provided only to illustrate element relationships and are not a REQUIRED feature of this protocol. "launch-1.0" is used as an abbreviation for "urn:ietf:params:xml:ns:launch-1.0". The XML namespace prefix "launch" is used, but implementations MUST NOT depend on it and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents. "signedMark-1.0" is used as an abbreviation for - "urn:ietf:params:xml:ns:signedMark-1.0" that is defined in - [I-D.ietf-eppext-tmch-smd]. The XML namespace prefix "smd" is used, - but implementations MUST NOT depend on it and instead employ a proper - namespace-aware XML parser and serializer to interpret and output the - XML documents. + "urn:ietf:params:xml:ns:signedMark-1.0" that is defined in [RFC7848]. + The XML namespace prefix "smd" is used, but implementations MUST NOT + depend on it and instead employ a proper namespace-aware XML parser + and serializer to interpret and output the XML documents. "mark-1.0" is used as an abbreviation for - "urn:ietf:params:xml:ns:mark-1.0" that is defined in - [I-D.ietf-eppext-tmch-smd]. The XML namespace prefix "mark" is used, - but implementations MUST NOT depend on it and instead employ a proper - namespace-aware XML parser and serializer to interpret and output the - XML documents. + "urn:ietf:params:xml:ns:mark-1.0" that is defined in [RFC7848]. The + XML namespace prefix "mark" is used, but implementations MUST NOT + depend on it and instead employ a proper namespace-aware XML parser + and serializer to interpret and output the XML documents. 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 @@ -221,24 +220,24 @@ 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 [I-D.ietf-eppext-tmch-smd]. 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. + 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. 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 @@ -556,50 +555,47 @@ ... 2.6.2. element A element describes an applicant's prior right to a given domain name that is used with the "mark", "mark with code", and the "signed mark" validation models. The element is defined - in [I-D.ietf-eppext-tmch-smd]. A new mark format can be supported by - creating a new XML schema for the mark that has an element that - substitutes for the element from - [I-D.ietf-eppext-tmch-smd]. + in [RFC7848]. A new mark format can be supported by creating a new + XML schema for the mark that has an element that substitutes for the + element from [RFC7848]. 2.6.3. Digital Signature Digital signatures MAY be used by the server to validate either the mark information, when using the "signed mark" validation model with the (Section 2.6.3.1) element or the (Section 2.6.3.2) element. 2.6.3.1. element The element contains the digitally signed mark - information. The element is defined in - [I-D.ietf-eppext-tmch-smd]. A new signed mark format can be - supported by creating a new XML schema for the signed mark that has - an element that substitutes for the element - from [I-D.ietf-eppext-tmch-smd]. + information. The element is defined in [RFC7848]. + A new signed mark format can be supported by creating a new XML + schema for the signed mark that has an element that substitutes for + the element from [RFC7848]. 2.6.3.2. element The element contains an encoded form of the digitally signed (Section 2.6.3.1) element. The - element is defined in - [I-D.ietf-eppext-tmch-smd]. A new encoded signed mark format can be - supported by creating a new XML schema for the encoded signed mark - that has an element that substitutes for the - element from [I-D.ietf-eppext-tmch-smd]. + element is defined in [RFC7848]. A new + encoded signed mark format can be supported by creating a new XML + schema for the encoded signed mark that has an element that + substitutes for the element from [RFC7848]. 3. EPP Command Mapping A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [RFC5730]. The command mappings described here are specifically for use in the Launch Phase Extension. This mapping is designed to be flexible, requiring only a minimum set of required elements. @@ -816,21 +812,21 @@ domain name mapping [RFC5731]. 3.1.3. Trademark Check Form The Trademark Check Form defines a new command called the Trademark Check Command that is used to determine whether or not there are any matching trademarks for each domain name passed in the command, independent of the active launch phase of the server and whether the "Claims Create Form" is required on a Domain Create Command. The availability check information defined in the EPP domain name mapping - [RFC5731] MUST NOT be returned for the Claims Check Command. This + [RFC5731] MUST NOT be returned for the Trademark Check Command. This form MUST be identified by setting the "type" attribute to "trademark". Instead of returning whether the domain name is available, the Trademark Check Command will return whether or not at least one matching trademark exists for the domain name. If there is at least one matching trademark that exists for the domain name, a element is returned. The client MAY then use the value of the element to obtain Trademark Claims Notice information from Trademark Validator based on the Validator @@ -2247,27 +2243,23 @@ 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. 9. Normative References - [I-D.ietf-eppext-tmch-smd] - Lozano, G., "Mark and Signed Mark Objects Mapping", draft- - ietf-eppext-tmch-smd-06 (work in progress), March 2016. - [I-D.ietf-regext-tmch-func-spec] Lozano, G., "ICANN TMCH functional specifications", draft- - ietf-regext-tmch-func-spec-00 (work in progress), April + ietf-regext-tmch-func-spec-01 (work in progress), June 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . @@ -2283,20 +2275,24 @@ [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, DOI 10.17487/RFC6982, July 2013, . [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, February 2015, . + [RFC7848] Lozano, G., "Mark and Signed Mark Objects Mapping", + RFC 7848, DOI 10.17487/RFC7848, June 2016, + . + Appendix A. Change History A.1. Change from 00 to 01 1. Changed to use camel case for the XML elements. 2. Replaced "cancelled" status to "rejected" status. 3. Added the child elements of the element. 4. Removed the XML schema and replaced with "[TBD]". A.2. Change from 01 to 02 @@ -2543,20 +2540,26 @@ 1. Changed reference of lozano-tmch-func-spec to ietf-eppext-tmch- func-spec. A.21. Change from EPPEXT 07 to REGEXT 00 1. Changed to regext working group draft by changing draft-ietf- eppext-launchphase to draft-ietf-regext-launchphase and by changing references of draft-ietf-eppext-tmch-func-spec to draft- ietf-regext-tmch-func-spec. +A.22. Change from REGEXT 00 to REGEXT 01 + + 1. Fixed reference of Claims Check Command to Trademark Check + Command in the Trademark Check Form section. + 2. Replaced reference of draft-ietf-eppext-tmch-smd to RFC 7848. + Authors' Addresses James Gould VeriSign, Inc. 12061 Bluemont Way Reston, VA 20190 US Email: jgould@verisign.com URI: http://www.verisigninc.com