draft-ietf-regext-launchphase-01.txt   draft-ietf-regext-launchphase-02.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: April 2, 2017 Cloud Registry Expires: April 30, 2017 Cloud Registry
G. Brown G. Brown
CentralNic Ltd CentralNic Ltd
September 29, 2016 October 27, 2016
Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)
draft-ietf-regext-launchphase-01 draft-ietf-regext-launchphase-02
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 April 2, 2017. This Internet-Draft will expire on April 30, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 2, line 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . 4 1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 5 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Application Identifier . . . . . . . . . . . . . . . . . 5 2.1. Application Identifier . . . . . . . . . . . . . . . . . 5
2.2. Validator Identifier . . . . . . . . . . . . . . . . . . 5 2.2. Validator Identifier . . . . . . . . . . . . . . . . . . 5
2.3. Launch Phases . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Launch Phases . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Status Values . . . . . . . . . . . . . . . . . . . . . . 6 2.3.1. Trademark Claims Phase . . . . . . . . . . . . . . . 6
2.4.1. State Transition . . . . . . . . . . . . . . . . . . 8 2.4. Status Values . . . . . . . . . . . . . . . . . . . . . . 9
2.5. Poll Messaging . . . . . . . . . . . . . . . . . . . . . 9 2.4.1. State Transition . . . . . . . . . . . . . . . . . . 10
2.6. Mark Validation Models . . . . . . . . . . . . . . . . . 12 2.5. Poll Messaging . . . . . . . . . . . . . . . . . . . . . 11
2.6.1. <launch:codeMark> element . . . . . . . . . . . . . . 13 2.6. Mark Validation Models . . . . . . . . . . . . . . . . . 14
2.6.2. <mark:mark> element . . . . . . . . . . . . . . . . . 14 2.6.1. <launch:codeMark> element . . . . . . . . . . . . . . 15
2.6.3. Digital Signature . . . . . . . . . . . . . . . . . . 14 2.6.2. <mark:mark> element . . . . . . . . . . . . . . . . . 16
2.6.3.1. <smd:signedMark> element . . . . . . . . . . . . 14 2.6.3. Digital Signature . . . . . . . . . . . . . . . . . . 16
2.6.3.2. <smd:encodedSignedMark> element . . . . . . . . . 14 2.6.3.1. <smd:signedMark> element . . . . . . . . . . . . 16
3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 14 2.6.3.2. <smd:encodedSignedMark> element . . . . . . . . . 16
3.1. EPP <check> Command . . . . . . . . . . . . . . . . . . . 15 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 16
3.1.1. Claims Check Form . . . . . . . . . . . . . . . . . . 15 3.1. EPP <check> Command . . . . . . . . . . . . . . . . . . . 17
3.1.2. Availability Check Form . . . . . . . . . . . . . . . 18 3.1.1. Claims Check Form . . . . . . . . . . . . . . . . . . 17
3.1.3. Trademark Check Form . . . . . . . . . . . . . . . . 20 3.1.2. Availability Check Form . . . . . . . . . . . . . . . 20
3.2. EPP <info> Command . . . . . . . . . . . . . . . . . . . 23 3.1.3. Trademark Check Form . . . . . . . . . . . . . . . . 22
3.3. EPP <create> Command . . . . . . . . . . . . . . . . . . 26 3.2. EPP <info> Command . . . . . . . . . . . . . . . . . . . 25
3.3.1. Sunrise Create Form . . . . . . . . . . . . . . . . . 26 3.3. EPP <create> Command . . . . . . . . . . . . . . . . . . 28
3.3.2. Claims Create Form . . . . . . . . . . . . . . . . . 32 3.3.1. Sunrise Create Form . . . . . . . . . . . . . . . . . 28
3.3.3. General Create Form . . . . . . . . . . . . . . . . . 35 3.3.2. Claims Create Form . . . . . . . . . . . . . . . . . 34
3.3.4. Mixed Create Form . . . . . . . . . . . . . . . . . . 36 3.3.3. General Create Form . . . . . . . . . . . . . . . . . 37
3.3.5. Create Response . . . . . . . . . . . . . . . . . . . 38 3.3.4. Mixed Create Form . . . . . . . . . . . . . . . . . . 38
3.4. EPP <update> Command . . . . . . . . . . . . . . . . . . 39 3.3.5. Create Response . . . . . . . . . . . . . . . . . . . 40
3.5. EPP <delete> Command . . . . . . . . . . . . . . . . . . 40 3.4. EPP <update> Command . . . . . . . . . . . . . . . . . . 41
3.6. EPP <renew> Command . . . . . . . . . . . . . . . . . . . 41 3.5. EPP <delete> Command . . . . . . . . . . . . . . . . . . 42
3.7. EPP <transfer> Command . . . . . . . . . . . . . . . . . 42 3.6. EPP <renew> Command . . . . . . . . . . . . . . . . . . . 43
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 42 3.7. EPP <transfer> Command . . . . . . . . . . . . . . . . . 44
4.1. Launch Schema . . . . . . . . . . . . . . . . . . . . . . 42 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 44
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 4.1. Launch Schema . . . . . . . . . . . . . . . . . . . . . . 44
5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 49 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 50 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 51
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 50 5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 52
6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 51 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 52
6.2. Verisign Consolidated Top Level Domain (CTLD) SRS . . . . 51 6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 53
6.3. Verisign .COM / .NET SRS . . . . . . . . . . . . . . . . 52 6.2. Verisign Consolidated Top Level Domain (CTLD) SRS . . . . 53
6.4. REngin v3.7 . . . . . . . . . . . . . . . . . . . . . . . 52 6.3. Verisign .COM / .NET SRS . . . . . . . . . . . . . . . . 54
6.5. RegistryEngine EPP Service . . . . . . . . . . . . . . . 52 6.4. REngin v3.7 . . . . . . . . . . . . . . . . . . . . . . . 54
6.6. Neustar EPP SDK . . . . . . . . . . . . . . . . . . . . . 53 6.5. RegistryEngine EPP Service . . . . . . . . . . . . . . . 54
6.7. gTLD Shared Registry System . . . . . . . . . . . . . . . 53 6.6. Neustar EPP SDK . . . . . . . . . . . . . . . . . . . . . 55
7. Security Considerations . . . . . . . . . . . . . . . . . . . 54 6.7. gTLD Shared Registry System . . . . . . . . . . . . . . . 55
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 7. Security Considerations . . . . . . . . . . . . . . . . . . . 56
9. Normative References . . . . . . . . . . . . . . . . . . . . 54 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 55 9. Normative References . . . . . . . . . . . . . . . . . . . . 57
A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 55 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 57
A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 55 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 57
A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 56 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 57
A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 56 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 58
A.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 56 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 58
A.6. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 56 A.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 58
A.7. Change from 06 to 07 . . . . . . . . . . . . . . . . . . 57 A.6. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 58
A.8. Change from 07 to 08 . . . . . . . . . . . . . . . . . . 57 A.7. Change from 06 to 07 . . . . . . . . . . . . . . . . . . 59
A.9. Change from 08 to 09 . . . . . . . . . . . . . . . . . . 57 A.8. Change from 07 to 08 . . . . . . . . . . . . . . . . . . 59
A.10. Change from 09 to 10 . . . . . . . . . . . . . . . . . . 58 A.9. Change from 08 to 09 . . . . . . . . . . . . . . . . . . 59
A.11. Change from 10 to 11 . . . . . . . . . . . . . . . . . . 59 A.10. Change from 09 to 10 . . . . . . . . . . . . . . . . . . 60
A.12. Change from 11 to 12 . . . . . . . . . . . . . . . . . . 59 A.11. Change from 10 to 11 . . . . . . . . . . . . . . . . . . 61
A.13. Change from 12 to EPPEXT 00 . . . . . . . . . . . . . . . 59 A.12. Change from 11 to 12 . . . . . . . . . . . . . . . . . . 61
A.14. Change EPPEXT 00 to EPPEXT 01 . . . . . . . . . . . . . . 59 A.13. Change from 12 to EPPEXT 00 . . . . . . . . . . . . . . . 61
A.15. Change EPPEXT 01 to EPPEXT 02 . . . . . . . . . . . . . . 59 A.14. Change EPPEXT 00 to EPPEXT 01 . . . . . . . . . . . . . . 61
A.16. Change EPPEXT 02 to EPPEXT 03 . . . . . . . . . . . . . . 60 A.15. Change EPPEXT 01 to EPPEXT 02 . . . . . . . . . . . . . . 61
A.17. Change EPPEXT 03 to EPPEXT 04 . . . . . . . . . . . . . . 60 A.16. Change EPPEXT 02 to EPPEXT 03 . . . . . . . . . . . . . . 61
A.18. Change EPPEXT 04 to EPPEXT 05 . . . . . . . . . . . . . . 60 A.17. Change EPPEXT 03 to EPPEXT 04 . . . . . . . . . . . . . . 62
A.19. Change EPPEXT 05 to EPPEXT 06 . . . . . . . . . . . . . . 60 A.18. Change EPPEXT 04 to EPPEXT 05 . . . . . . . . . . . . . . 62
A.20. Change EPPEXT 06 to EPPEXT 07 . . . . . . . . . . . . . . 60 A.19. Change EPPEXT 05 to EPPEXT 06 . . . . . . . . . . . . . . 62
A.21. Change from EPPEXT 07 to REGEXT 00 . . . . . . . . . . . 61 A.20. Change EPPEXT 06 to EPPEXT 07 . . . . . . . . . . . . . . 62
A.22. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 61 A.21. Change from EPPEXT 07 to REGEXT 00 . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 A.22. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 63
A.23. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 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 6, line 23 skipping to change at page 6, line 23
result code of 2306 if there is a mismatch. result code of 2306 if there is a mismatch.
The following launch phase values are defined: The following launch phase values are defined:
sunrise The phase during which trademark holders can submit sunrise The phase during which trademark holders can submit
registrations or applications with trademark information that can registrations or applications with trademark information that can
be validated by the server. be validated by the server.
landrush A post-Sunrise phase when non-trademark holders are allowed landrush A post-Sunrise phase when non-trademark holders are allowed
to register domain names with steps taken to address a large to register domain names with steps taken to address a large
volume of initial registrations. volume of initial registrations.
claims The Trademark Claims phase, as defined in the TMCH Functional claims The phase, as defined in the Section 2.3.1, in which a Claims
Specification [I-D.ietf-regext-tmch-func-spec], in which a Claims Notice MUST be displayed to a prospective registrant of a domain
Notice must be displayed to a prospective registrant of a domain
name that matches trademarks. name that matches trademarks.
open A post-launch phase that is also referred to as "steady state". open A post-launch phase that is also referred to as "steady state".
Servers MAY require additional trademark protection during this Servers MAY require additional trademark protection during this
phase. phase.
custom A custom server launch phase that is defined using the "name" custom A custom server launch phase that is defined using the "name"
attribute. attribute.
For extensibility, the <launch:phase> element includes an OPTIONAL For extensibility, the <launch:phase> element includes an OPTIONAL
"name" attribute that can define a sub-phase, or the full name of the "name" attribute that can define a sub-phase, or the full name of the
phase when the <launch:phase> element has the "custom" value. For phase when the <launch:phase> element has the "custom" value. For
example, the "claims" launch phase could have two sub-phases that example, the "claims" launch phase could have two sub-phases that
include "landrush" and "open". include "landrush" and "open".
Launch phases MAY overlap to support the "claims" launch phase, Launch phases MAY overlap to support the "claims" launch phase,
defined in the TMCH Functional Specification defined in the Section 2.3.1, and to support a traditional "landrush"
[I-D.ietf-regext-tmch-func-spec], and to support a traditional launch phase. The overlap of the "claims" and "landrush" launch
"landrush" launch phase. The overlap of the "claims" and "landrush" phases SHOULD be handled by setting "claims" as the <launch:phase>
launch phases SHOULD be handled by setting "claims" as the value and setting "landrush" as the sub-phase with the "name"
<launch:phase> value and setting "landrush" as the sub-phase with the attribute. For example, the <launch:phase> element SHOULD be
"name" attribute. For example, the <launch:phase> element SHOULD be
<launch:phase name="landrush">claims</launch:phase>. <launch:phase name="landrush">claims</launch:phase>.
2.3.1. Trademark Claims Phase
The Trademark Claims Phase is when a Claims Notice MUST be displayed
to a prospective registrant of a domain name that matches trademarks.
The source of the trademarks is a Trademark Validator and the source
of the Claims Notice information is a Claim Notice Information
Service (CNIS), which MAY be directly linked to a Trademark
Validator. The client interfaces with the server to determine if a
trademark exists for a domain name, interfaces with a CNIS to get the
Claims Notice information, and interfaces with the server to pass the
Claims Notice acceptance information in a create command. This
document supports the Trademark Claims Phase in two ways including:
Claims Check Form Claims Check Form (Section 3.1.1) is used to
determine whether or not there are any matching trademarks for a
domain name. If there is at least one matching trademark that
exists for the domain name, a claims key is returned. The mapping
of domain names and the claims keys is based on an out-of-band
interface between the server and the Trademark Validator. The
CNIS associated with the claims key Validator Identifier
(Section 2.2) MUST accept the claims key as the basis for
retrieving the claims information.
Claims Create Form Claims Create Form (Section 3.3.2) is used to
pass the Claims Notice acceptance information in a create command.
The notice identifier (<launch:noticeID>) format, validation
rules, and server processing is up to the interface between the
server and the Trademark Validator. The CNIS associated with the
Validator Identifier (Section 2.2) MUST generate a notice
identifier compliant with the <launch:noticeID> element.
The following shows the Trademark Claims Phase registration flow:
.------------. .--------. .--------. .------.
| Registrant | | Client | | Server | | CNIS |
'------------' '--------' '--------' '------'
| Request Domain | | |
| Registration | | |
|--------------->| Domain Check | |
| |--------------------------->| |
| Domain | Domain Unavailable .------------. |
| Unavailable |<---------------------( Available? ) |
|<---------------| No '------------' |
| | Domain Available | Yes |
| |<---------------------------| |
| | Domain Claims Check | |
| |--------------------------->| |
| | .---------. |
| | / Does \ |
| |<--------------------( Domain have ) |
| | No \ Claims? / |
| | '---------' |
| | Domain Create | | Yes |
| |--------------------------->| | |
| Domain | Domain Registered | | |
| Registered |<---------------------------| | |
|<---------------| | |
| | |
| | Claims Key | |
| |<------------------------------' |
| | |
.-----. | | Request Claims Info with Claims Key |
|Abort| | Display |-------------------------------------->|
'-----' | Claims | Return Claims Info |
^ | Notice |<--------------------------------------|
| No |<---------------| |
| .------. Yes | |
'-( Ack? )----------->| Domain Claims Create Form | |
'------' |--------------------------->| |
| Registration | Error .----------------------. |
| Error |<-----------( Validation Successful? ) |
|<---------------| No '----------------------' |
| | | Yes |
| Domain | Domain Registered | |
| Registered |<---------------------------| |
|<---------------| | |
Figure 1
2.4. Status Values 2.4. Status Values
A Launch Application or Launch Registration object MAY have a launch A Launch Application or Launch Registration object MAY have a launch
status value. The <launch:status> element is used to convey the status value. The <launch:status> element is used to convey the
launch status pertaining to the object, beyond what is specified in launch status pertaining to the object, beyond what is specified in
the object mapping. A Launch Application or Launch Registration MUST the object mapping. A Launch Application or Launch Registration MUST
set the [RFC5731] "pendingCreate" status if a launch status is set the [RFC5731] "pendingCreate" status if a launch status is
supported and the launch status is not one of the final statuses, supported and the launch status is not one of the final statuses,
including the "allocated" and "rejected" statuses. including the "allocated" and "rejected" statuses.
skipping to change at page 8, line 45 skipping to change at page 10, line 49
| | | | | |
| | | | | |
| | | | | |
v v v v v v
+---------+ +--------+ +---------+ +--------+
/ \ / \ / \ / \
| allocated | | rejected | | allocated | | rejected |
\ / \ / \ / \ /
+---------+ +--------+ +---------+ +--------+
Figure 1 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 a domain name of [RFC5731] in "pendingCreate" status, with the launch
status values defined in Section 2.4. As a Launch Application or status values defined in Section 2.4. As a Launch Application or
Launch Registration transitions between the status values defined in Launch Registration transitions between the status values defined in
Section 2.4, the server SHOULD insert poll messages, per [RFC5730], Section 2.4, the server SHOULD insert poll messages, per [RFC5730],
for the applicable intermediate statuses, including the for the applicable intermediate statuses, including the
"pendingValidation", "validated", "pendingAllocation, and "invalid" "pendingValidation", "validated", "pendingAllocation, and "invalid"
skipping to change at page 17, line 10 skipping to change at page 19, line 10
domain name. This element MUST contain an "exists" attribute domain name. This element MUST contain an "exists" attribute
whose value indicates if a matching trademark exists for the whose value indicates if a matching trademark exists for the
domain name that requires the use of the "Claims Create Form" domain name that requires the use of the "Claims Create Form"
on a Domain Create Command. A value of "1" (or "true") means on a Domain Create Command. A value of "1" (or "true") means
that a matching trademark does exist and that the "Claims that a matching trademark does exist and that the "Claims
Create Form" is required on a Domain Create Command. A value Create Form" is required on a Domain Create Command. A value
of "0" (or "false") means that a matching trademark does not of "0" (or "false") means that a matching trademark does not
exist or that the "Claims Create Form" is NOT required on a exist or that the "Claims Create Form" is NOT required on a
Domain Create Command. Domain Create Command.
<launch:claimKey> Zero or more OPTIONAL claim keys that MAY be <launch:claimKey> Zero or more OPTIONAL claim keys that MAY be
passed to a third-party trademark validator such as the passed to a third-party Trademark Validator such as the ICANN
Trademark Clearinghouse (TMCH) for querying the information Trademark Clearinghouse (TMCH) for querying the information
needed to generate a Trademark Claims Notice. The needed to generate a Trademark Claims Notice. The
<launch:claimKey> is used as the key for the query in place <launch:claimKey> is used as the key for the query in place
of the domain name to securely query the service without of the domain name to securely query the service without
using a well-known value like a domain name. The OPTIONAL using a well-known value like a domain name. The OPTIONAL
"validatorID" attribute is the Validator Identifier "validatorID" attribute is the Validator Identifier
(Section 2.2) whose value indicates which Trademark Validator (Section 2.2) whose value indicates which Trademark Validator
to query for the Claims Notice information, with the default to query for the Claims Notice information, with the default
being the ICANN TMCH. The "validatorID" attribute MAY being the ICANN TMCH. The "validatorID" attribute MAY
reference a non-trademark claims clearinghouse identifer to reference a non-trademark claims clearinghouse identifer to
skipping to change at page 21, line 45 skipping to change at page 23, line 45
<launch:cd> One or more <launch:cd> elements that contain the <launch:cd> One or more <launch:cd> elements that contain the
following child elements: following child elements:
<launch:name> Contains the fully qualified name of the queried <launch:name> Contains the fully qualified name of the queried
domain name. This element MUST contain an "exists" attribute domain name. This element MUST contain an "exists" attribute
whose value indicates if a matching trademark exists for the whose value indicates if a matching trademark exists for the
domain name. A value of "1" (or "true") means that a domain name. A value of "1" (or "true") means that a
matching trademark does exist. A value of "0" (or "false") matching trademark does exist. A value of "0" (or "false")
means that a matching trademark does not exist. means that a matching trademark does not exist.
<launch:claimKey> Zero or more OPTIONAL claim keys that MAY be <launch:claimKey> Zero or more OPTIONAL claim keys that MAY be
passed to a third-party trademark validator such as the passed to a third-party Trademark Validator such as the ICANN
Trademark Clearinghouse (TMCH) for querying the information Trademark Clearinghouse (TMCH) for querying the information
needed to generate a Trademark Claims Notice. The needed to generate a Trademark Claims Notice. The
<launch:claimKey> is used as the key for the query in place <launch:claimKey> is used as the key for the query in place
of the domain name to securely query the service without of the domain name to securely query the service without
using a well-known value like a domain name. The OPTIONAL using a well-known value like a domain name. The OPTIONAL
"validatorID" attribute is the Validator Identifier "validatorID" attribute is the Validator Identifier
(Section 2.2) whose value indicates which Trademark Validator (Section 2.2) whose value indicates which Trademark Validator
to query for the Claims Notice information, with the default to query for the Claims Notice information, with the default
being the ICANN TMCH. The "validatorID" attribute MAY being the ICANN TMCH. The "validatorID" attribute MAY
reference a non-trademark claims clearinghouse identifer to reference a non-trademark claims clearinghouse identifer to
skipping to change at page 54, line 46 skipping to change at page 56, line 46
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, Michael
Holloway, Jan Jansen, Rubens Kuhl, Ben Levac, Gustavo Lozano, Klaus Holloway, Jan Jansen, Rubens Kuhl, Ben Levac, Gustavo Lozano, Klaus
Malorny, Alexander Mayrhofer, Patrick Mevzek, James Mitchell, Malorny, Alexander Mayrhofer, Patrick Mevzek, James Mitchell,
Francisco Obispo, Mike O'Connell, Bernhard Reutner-Fischer, Trung Francisco Obispo, Mike O'Connell, Bernhard Reutner-Fischer, Trung
Tran, Ulrich Wisser and Sharon Wodjenski. Tran, Ulrich Wisser and Sharon Wodjenski.
9. Normative References Some of the description of the Trademark Claims Phase was based on
the work done by Gustavo Lozano in the ICANN TMCH functional
specifications.
[I-D.ietf-regext-tmch-func-spec] 9. Normative References
Lozano, G., "ICANN TMCH functional specifications", draft-
ietf-regext-tmch-func-spec-01 (work in progress), June
2016.
[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, March 1997.
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-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, January 2004.
<http://www.rfc-editor.org/info/rfc3688>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, STD 69, RFC 5730, August 2009.
<http://www.rfc-editor.org/info/rfc5730>.
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Domain Name Mapping", STD 69, RFC 5731, Domain Name Mapping", STD 69, RFC 5731, August 2009.
DOI 10.17487/RFC5731, August 2009,
<http://www.rfc-editor.org/info/rfc5731>.
[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, July
DOI 10.17487/RFC6982, July 2013, 2013.
<http://www.rfc-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, February 2015.
February 2015, <http://www.rfc-editor.org/info/rfc7451>.
[RFC7848] Lozano, G., "Mark and Signed Mark Objects Mapping", [RFC7848] Lozano, G., "Mark and Signed Mark Objects Mapping", RFC
RFC 7848, DOI 10.17487/RFC7848, June 2016, 7848, DOI 10.17487/RFC7848, June 2016,
<http://www.rfc-editor.org/info/rfc7848>. <http://www.rfc-editor.org/info/rfc7848>.
Appendix A. Change History Appendix A. Change History
A.1. Change from 00 to 01 A.1. Change from 00 to 01
1. Changed to use camel case for the XML elements. 1. Changed to use camel case for the XML elements.
2. Replaced "cancelled" status to "rejected" status. 2. Replaced "cancelled" status to "rejected" status.
3. Added the child elements of the <claim> element. 3. Added the child elements of the <claim> element.
4. Removed the XML schema and replaced with "[TBD]". 4. Removed the XML schema and replaced with "[TBD]".
skipping to change at page 61, line 18 skipping to change at page 63, line 11
eppext-launchphase to draft-ietf-regext-launchphase and by eppext-launchphase to draft-ietf-regext-launchphase and by
changing references of draft-ietf-eppext-tmch-func-spec to draft- changing references of draft-ietf-eppext-tmch-func-spec to draft-
ietf-regext-tmch-func-spec. ietf-regext-tmch-func-spec.
A.22. Change from REGEXT 00 to REGEXT 01 A.22. Change from REGEXT 00 to REGEXT 01
1. Fixed reference of Claims Check Command to Trademark Check 1. Fixed reference of Claims Check Command to Trademark Check
Command in the Trademark Check Form section. Command in the Trademark Check Form section.
2. Replaced reference of draft-ietf-eppext-tmch-smd to RFC 7848. 2. Replaced reference of draft-ietf-eppext-tmch-smd to RFC 7848.
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.
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. 21 change blocks. 
103 lines changed or deleted 178 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/