draft-ietf-regext-launchphase-00.txt   draft-ietf-regext-launchphase-01.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 27, 2016 Cloud Registry Expires: April 2, 2017 Cloud Registry
G. Brown G. Brown
CentralNic Ltd CentralNic Ltd
April 25, 2016 September 29, 2016
Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)
draft-ietf-regext-launchphase-00 draft-ietf-regext-launchphase-01
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 27, 2016. This Internet-Draft will expire on April 2, 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 3, line 14 skipping to change at page 3, line 14
6.7. gTLD Shared Registry System . . . . . . . . . . . . . . . 53 6.7. gTLD Shared Registry System . . . . . . . . . . . . . . . 53
7. Security Considerations . . . . . . . . . . . . . . . . . . . 54 7. Security Considerations . . . . . . . . . . . . . . . . . . . 54
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54
9. Normative References . . . . . . . . . . . . . . . . . . . . 54 9. Normative References . . . . . . . . . . . . . . . . . . . . 54
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 55 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 55
A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 55 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 55
A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 55 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 55
A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 56 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 56
A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 56 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 56
A.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 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.7. Change from 06 to 07 . . . . . . . . . . . . . . . . . . 57
A.8. Change from 07 to 08 . . . . . . . . . . . . . . . . . . 57 A.8. Change from 07 to 08 . . . . . . . . . . . . . . . . . . 57
A.9. Change from 08 to 09 . . . . . . . . . . . . . . . . . . 57 A.9. Change from 08 to 09 . . . . . . . . . . . . . . . . . . 57
A.10. Change from 09 to 10 . . . . . . . . . . . . . . . . . . 58 A.10. Change from 09 to 10 . . . . . . . . . . . . . . . . . . 58
A.11. Change from 10 to 11 . . . . . . . . . . . . . . . . . . 59 A.11. Change from 10 to 11 . . . . . . . . . . . . . . . . . . 59
A.12. Change from 11 to 12 . . . . . . . . . . . . . . . . . . 59 A.12. Change from 11 to 12 . . . . . . . . . . . . . . . . . . 59
A.13. Change from 12 to EPPEXT 00 . . . . . . . . . . . . . . . 59 A.13. Change from 12 to EPPEXT 00 . . . . . . . . . . . . . . . 59
A.14. Change EPPEXT 00 to EPPEXT 01 . . . . . . . . . . . . . . 59 A.14. Change EPPEXT 00 to EPPEXT 01 . . . . . . . . . . . . . . 59
A.15. Change EPPEXT 01 to EPPEXT 02 . . . . . . . . . . . . . . 59 A.15. Change EPPEXT 01 to EPPEXT 02 . . . . . . . . . . . . . . 59
A.16. Change EPPEXT 02 to EPPEXT 03 . . . . . . . . . . . . . . 60 A.16. Change EPPEXT 02 to EPPEXT 03 . . . . . . . . . . . . . . 60
A.17. Change EPPEXT 03 to EPPEXT 04 . . . . . . . . . . . . . . 60 A.17. Change EPPEXT 03 to EPPEXT 04 . . . . . . . . . . . . . . 60
A.18. Change EPPEXT 04 to EPPEXT 05 . . . . . . . . . . . . . . 60 A.18. Change EPPEXT 04 to EPPEXT 05 . . . . . . . . . . . . . . 60
A.19. Change EPPEXT 05 to EPPEXT 06 . . . . . . . . . . . . . . 60 A.19. Change EPPEXT 05 to EPPEXT 06 . . . . . . . . . . . . . . 60
A.20. Change EPPEXT 06 to EPPEXT 07 . . . . . . . . . . . . . . 60 A.20. Change EPPEXT 06 to EPPEXT 07 . . . . . . . . . . . . . . 60
A.21. Change from EPPEXT 07 to REGEXT 00 . . . . . . . . . . . 61 A.21. Change from EPPEXT 07 to REGEXT 00 . . . . . . . . . . . 61
A.22. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61
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 8 skipping to change at page 4, line 9
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 required, such as trademark information. In addition, the [RFC7848]
[I-D.ietf-eppext-tmch-smd] defines a registry interface for the defines a registry interface for the Trademark Claims or "claims"
Trademark Claims or "claims" launch phase that includes support for launch phase that includes support for presenting a Trademark Claims
presenting a Trademark Claims Notice to the Registrant. This Notice to the Registrant. This document proposes an extension to the
document proposes an extension to the domain name mapping in order to domain name mapping in order to provide a uniform interface for the
provide a uniform interface for the management of Launch Applications management of Launch Applications and Launch Registrations in launch
and Launch Registrations in launch phases. 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 4, line 39 skipping to change at page 4, line 40
white space in examples are provided only to illustrate element white space in examples are provided only to illustrate element
relationships and are not a REQUIRED feature of this protocol. relationships and are not a REQUIRED feature of this protocol.
"launch-1.0" is used as an abbreviation for "launch-1.0" is used as an abbreviation for
"urn:ietf:params:xml:ns:launch-1.0". The XML namespace prefix "urn:ietf:params:xml:ns:launch-1.0". The XML namespace prefix
"launch" is used, but implementations MUST NOT depend on it and "launch" is used, but implementations MUST NOT depend on it and
instead employ a proper namespace-aware XML parser and serializer to instead employ a proper namespace-aware XML parser and serializer to
interpret and output the XML documents. interpret and output the XML documents.
"signedMark-1.0" is used as an abbreviation for "signedMark-1.0" is used as an abbreviation for
"urn:ietf:params:xml:ns:signedMark-1.0" that is defined in "urn:ietf:params:xml:ns:signedMark-1.0" that is defined in [RFC7848].
[I-D.ietf-eppext-tmch-smd]. The XML namespace prefix "smd" is used, The XML namespace prefix "smd" is used, but implementations MUST NOT
but implementations MUST NOT depend on it and instead employ a proper depend on it and instead employ a proper namespace-aware XML parser
namespace-aware XML parser and serializer to interpret and output the and serializer to interpret and output the XML documents.
XML documents.
"mark-1.0" is used as an abbreviation for "mark-1.0" is used as an abbreviation for
"urn:ietf:params:xml:ns:mark-1.0" that is defined in "urn:ietf:params:xml:ns:mark-1.0" that is defined in [RFC7848]. The
[I-D.ietf-eppext-tmch-smd]. The XML namespace prefix "mark" is used, XML namespace prefix "mark" is used, but implementations MUST NOT
but implementations MUST NOT depend on it and instead employ a proper depend on it and instead employ a proper namespace-aware XML parser
namespace-aware XML parser and serializer to interpret and output the and serializer to interpret and output the XML documents.
XML documents.
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
skipping to change at page 5, line 43 skipping to change at page 5, line 43
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 [I-D.ietf-eppext-tmch-smd]. Both the Validator Identifier and the in [RFC7848]. Both the Validator Identifier and the Issuer
Issuer Identifier used MUST be unique. The list of validator Identifier used MUST be unique. The list of validator identifiers
identifiers and the relationship to issuer identifiers is out of and the relationship to issuer identifiers is out of scope for this
scope for this document. document.
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 14, line 10 skipping to change at page 14, line 10
<mark:mark xmlns:mark="urn:ietf:params:xml:ns:mark-1.0"> <mark:mark xmlns:mark="urn:ietf:params:xml:ns:mark-1.0">
... ...
</mark:mark> </mark:mark>
</launch:codeMark> </launch:codeMark>
2.6.2. <mark:mark> element 2.6.2. <mark:mark> element
A <mark:mark> element describes an applicant's prior right to a given A <mark:mark> element describes an applicant's prior right to a given
domain name that is used with the "mark", "mark with code", and the domain name that is used with the "mark", "mark with code", and the
"signed mark" validation models. The <mark:mark> element is defined "signed mark" validation models. The <mark:mark> element is defined
in [I-D.ietf-eppext-tmch-smd]. A new mark format can be supported by in [RFC7848]. A new mark format can be supported by creating a new
creating a new XML schema for the mark that has an element that XML schema for the mark that has an element that substitutes for the
substitutes for the <mark:abstractMark> element from <mark:abstractMark> element from [RFC7848].
[I-D.ietf-eppext-tmch-smd].
2.6.3. Digital Signature 2.6.3. Digital Signature
Digital signatures MAY be used by the server to validate either the Digital signatures MAY be used by the server to validate either the
mark information, when using the "signed mark" validation model with mark information, when using the "signed mark" validation model with
the <smd:signedMark> (Section 2.6.3.1) element or the the <smd:signedMark> (Section 2.6.3.1) element or the
<smd:encodedSignedMark> (Section 2.6.3.2) element. <smd:encodedSignedMark> (Section 2.6.3.2) element.
2.6.3.1. <smd:signedMark> element 2.6.3.1. <smd:signedMark> element
The <smd:signedMark> element contains the digitally signed mark The <smd:signedMark> element contains the digitally signed mark
information. The <smd:signedMark> element is defined in information. The <smd:signedMark> element is defined in [RFC7848].
[I-D.ietf-eppext-tmch-smd]. A new signed mark format can be A new signed mark format can be supported by creating a new XML
supported by creating a new XML schema for the signed mark that has schema for the signed mark that has an element that substitutes for
an element that substitutes for the <smd:abstractSignedMark> element the <smd:abstractSignedMark> element from [RFC7848].
from [I-D.ietf-eppext-tmch-smd].
2.6.3.2. <smd:encodedSignedMark> element 2.6.3.2. <smd:encodedSignedMark> element
The <smd:encodedSignedMark> element contains an encoded form of the The <smd:encodedSignedMark> element contains an encoded form of the
digitally signed <smd:signedMark> (Section 2.6.3.1) element. The digitally signed <smd:signedMark> (Section 2.6.3.1) element. The
<smd:encodedSignedMark> element is defined in <smd:encodedSignedMark> element is defined in [RFC7848]. A new
[I-D.ietf-eppext-tmch-smd]. A new encoded signed mark format can be encoded signed mark format can be supported by creating a new XML
supported by creating a new XML schema for the encoded signed mark schema for the encoded signed mark that has an element that
that has an element that substitutes for the <smd:encodedSignedMark> substitutes for the <smd:encodedSignedMark> element from [RFC7848].
element from [I-D.ietf-eppext-tmch-smd].
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]. The command in the EPP core protocol specification [RFC5730]. The command
mappings described here are specifically for use in the Launch Phase mappings described here are specifically for use in the Launch Phase
Extension. Extension.
This mapping is designed to be flexible, requiring only a minimum set This mapping is designed to be flexible, requiring only a minimum set
of required elements. of required elements.
skipping to change at page 20, line 13 skipping to change at page 20, line 13
domain name mapping [RFC5731]. domain name mapping [RFC5731].
3.1.3. Trademark Check Form 3.1.3. Trademark Check Form
The Trademark Check Form defines a new command called the Trademark The Trademark Check Form defines a new command called the Trademark
Check Command that is used to determine whether or not there are any Check Command that is used to determine whether or not there are any
matching trademarks for each domain name passed in the command, matching trademarks for each domain name passed in the command,
independent of the active launch phase of the server and whether the independent of the active launch phase of the server and whether the
"Claims Create Form" is required on a Domain Create Command. The "Claims Create Form" is required on a Domain Create Command. The
availability check information defined in the EPP domain name mapping 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 <launch:check> "type" form MUST be identified by setting the <launch:check> "type"
attribute to "trademark". attribute to "trademark".
Instead of returning whether the domain name is available, the Instead of returning whether the domain name is available, the
Trademark Check Command will return whether or not at least one Trademark Check Command will return whether or not at least one
matching trademark exists for the domain name. If there is at least matching trademark exists for the domain name. If there is at least
one matching trademark that exists for the domain name, a one matching trademark that exists for the domain name, a
<launch:claimKey> element is returned. The client MAY then use the <launch:claimKey> element is returned. The client MAY then use the
value of the <launch:claimKey> element to obtain Trademark Claims value of the <launch:claimKey> element to obtain Trademark Claims
Notice information from Trademark Validator based on the Validator Notice information from Trademark Validator based on the Validator
skipping to change at page 54, line 48 skipping to change at page 54, line 48
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 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] [I-D.ietf-regext-tmch-func-spec]
Lozano, G., "ICANN TMCH functional specifications", draft- 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. 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,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <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, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
skipping to change at page 55, line 37 skipping to change at page 55, line 32
[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, DOI 10.17487/RFC6982, July 2013,
<http://www.rfc-editor.org/info/rfc6982>. <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, DOI 10.17487/RFC7451,
February 2015, <http://www.rfc-editor.org/info/rfc7451>. February 2015, <http://www.rfc-editor.org/info/rfc7451>.
[RFC7848] Lozano, G., "Mark and Signed Mark Objects Mapping",
RFC 7848, DOI 10.17487/RFC7848, June 2016,
<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]".
A.2. Change from 01 to 02 A.2. Change from 01 to 02
skipping to change at page 61, line 12 skipping to change at page 61, line 12
1. Changed reference of lozano-tmch-func-spec to ietf-eppext-tmch- 1. Changed reference of lozano-tmch-func-spec to ietf-eppext-tmch-
func-spec. func-spec.
A.21. Change from EPPEXT 07 to REGEXT 00 A.21. Change from EPPEXT 07 to REGEXT 00
1. Changed to regext working group draft by changing draft-ietf- 1. Changed to regext working group draft by changing draft-ietf-
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
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 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. 18 change blocks. 
46 lines changed or deleted 48 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/