draft-ietf-regext-tmch-func-spec-05.txt   draft-ietf-regext-tmch-func-spec-06.txt 
Internet Engineering Task Force G. Lozano Internet Engineering Task Force G. Lozano
Internet-Draft ICANN Internet-Draft ICANN
Intended status: Informational Oct 31, 2019 Intended status: Informational Nov 19, 2019
Expires: May 3, 2020 Expires: May 22, 2020
ICANN TMCH functional specifications ICANN TMCH functional specifications
draft-ietf-regext-tmch-func-spec-05 draft-ietf-regext-tmch-func-spec-06
Abstract Abstract
This document describes the requirements, the architecture and the This document describes the requirements, the architecture and the
interfaces between the ICANN Trademark Clearinghouse (TMCH) and interfaces between the ICANN Trademark Clearinghouse (TMCH) and
Domain Name Registries as well as between the ICANN TMCH and Domain Domain Name Registries as well as between the ICANN TMCH and Domain
Name Registrars for the provisioning and management of domain names Name Registrars for the provisioning and management of domain names
during Sunrise and Trademark Claims Periods. during Sunrise and Trademark Claims Periods.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 May 3, 2020. This Internet-Draft will expire on May 22, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 31 skipping to change at page 3, line 31
6.3.1.1. LORDN Log Result Codes . . . . . . . . . . . . . 42 6.3.1.1. LORDN Log Result Codes . . . . . . . . . . . . . 42
6.4. Signed Mark Data (SMD) File . . . . . . . . . . . . . . . 46 6.4. Signed Mark Data (SMD) File . . . . . . . . . . . . . . . 46
6.5. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 47 6.5. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 47
6.6. Sunrise List (SURL) . . . . . . . . . . . . . . . . . . . 54 6.6. Sunrise List (SURL) . . . . . . . . . . . . . . . . . . . 54
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 55 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 55
7.1. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 55 7.1. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 55
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 58 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 58
9. Change History . . . . . . . . . . . . . . . . . . . . . . . 58 9. Change History . . . . . . . . . . . . . . . . . . . . . . . 58
9.1. Version 04 . . . . . . . . . . . . . . . . . . . . . . . 58 9.1. Version 04 . . . . . . . . . . . . . . . . . . . . . . . 58
9.2. Version 05 . . . . . . . . . . . . . . . . . . . . . . . 58 9.2. Version 05 . . . . . . . . . . . . . . . . . . . . . . . 58
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 9.3. Version 06 . . . . . . . . . . . . . . . . . . . . . . . 58
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
11. Security Considerations . . . . . . . . . . . . . . . . . . . 59 11. Security Considerations . . . . . . . . . . . . . . . . . . . 59
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 59
12.1. Normative References . . . . . . . . . . . . . . . . . . 59 12.1. Normative References . . . . . . . . . . . . . . . . . . 60
12.2. Informative References . . . . . . . . . . . . . . . . . 60 12.2. Informative References . . . . . . . . . . . . . . . . . 60
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 62
1. Introduction 1. Introduction
Domain Name Registries (DNRs) may operate in special modes for Domain Name Registries (DNRs) may operate in special modes for
certain periods of time enabling trademark holders to protect their certain periods of time enabling trademark holders to protect their
rights during the introduction of a Top Level Domain (TLD). rights during the introduction of a Top Level Domain (TLD).
Along with the introduction of new generic TLDs (gTLD), two special Along with the introduction of new generic TLDs (gTLD), two special
skipping to change at page 4, line 26 skipping to change at page 4, line 26
TMCH and Domain Name Registrars (called Registrars in the rest of the TMCH and Domain Name Registrars (called Registrars in the rest of the
document) for the provisioning and management of domain names during document) for the provisioning and management of domain names during
the Sunrise and Trademark Claims Periods. the Sunrise and Trademark Claims Periods.
For any date and/or time indications, Coordinated Universal Time For any date and/or time indications, Coordinated Universal Time
(UTC) applies. (UTC) applies.
2. Terminology 2. Terminology
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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
implementation. implementation.
"tmNotice-1.0" is used as an abbreviation for "tmNotice-1.0" is used as an abbreviation for
"urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix "urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix
"tmNotice" is used, but implementations MUST NOT depend on it and "tmNotice" 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
skipping to change at page 5, line 17 skipping to change at page 5, line 20
o CRL: Certificate Revocation List, see [RFC5280]. o CRL: Certificate Revocation List, see [RFC5280].
o CSV: Comma-Separated Values, see [RFC4180] o CSV: Comma-Separated Values, see [RFC4180]
o Date and time, datetime: Date and time are specified following the o Date and time, datetime: Date and time are specified following the
standard "Date and Time on the Internet specification", see standard "Date and Time on the Internet specification", see
[RFC3339]. [RFC3339].
o DN, Domain Name, domain name: see definition of Domain name in o DN, Domain Name, domain name: see definition of Domain name in
[RFC7719]. [RFC8499].
o DNROID, DN Repository Object IDentifier: an identifier assigned by o DNROID, DN Repository Object IDentifier: an identifier assigned by
the Registry to each DN object that unequivocally identifies said the Registry to each DN object that unequivocally identifies said
DN object. For example, if a new DN object is created for a name DN object. For example, if a new DN object is created for a name
that existed in the past, the DN objects will have different that existed in the past, the DN objects will have different
DNROIDs. DNROIDs.
o DNL, Domain Name Label, the DNL is an A-label or NR-LDH label (see o DNL, Domain Name Label, the DNL is an A-label or NR-LDH label (see
[RFC5890]). [RFC5890]).
o DNL List: A list of DNLs that are covered by a PRM. o DNL List: A list of DNLs that are covered by a PRM.
o DNS: Domain Name System, see [RFC7719]. o DNS: Domain Name System, see [RFC8499].
o Effective allocation: A DN is considered effectively allocated o Effective allocation: A DN is considered effectively allocated
when the DN object for the DN has been created in the SRS of the when the DN object for the DN has been created in the SRS of the
Registry and has been assigned to the effective user. A DN object Registry and has been assigned to the effective user. A DN object
in status "pendingCreate" or any other status that precedes the in status "pendingCreate" or any other status that precedes the
first time a DN is assigned to an end-user is not considered an first time a DN is assigned to an end-user is not considered an
effective allocation. A DN object created internally by the effective allocation. A DN object created internally by the
Registry for subsequent delegation to another Registrant is not Registry for subsequent delegation to another Registrant is not
considered an effective allocation. considered an effective allocation.
o EPP: The Extensible Provisioning Protocol, see definition of EPP o EPP: The Extensible Provisioning Protocol, see definition of EPP
in [RFC7719]. in [RFC8499].
o FQDN: Fully-Qualified Domain Name, see definition of FQDN in o FQDN: Fully-Qualified Domain Name, see definition of FQDN in
[RFC7719]. [RFC8499].
o HTTP: Hypertext Transfer Protocol, see [RFC7230] and [RFC7231]. o HTTP: Hypertext Transfer Protocol, see [RFC7230] and [RFC7231].
o HTTPS: HTTP over TLS (Transport Layer Security), [RFC2818]. o HTTPS: HTTP over TLS (Transport Layer Security), [RFC2818].
o IDN: Internationalized Domain Name, see definition of IDN in o IDN: Internationalized Domain Name, see definition of IDN in
[RFC7719]. [RFC8499].
o Lookup Key: A random string of up to 51 chars from the set [a-zA- o Lookup Key: A random string of up to 51 chars from the set [a-zA-
Z0-9/] to be used as the lookup key by Registrars to obtain the Z0-9/] to be used as the lookup key by Registrars to obtain the
TCN using the CNIS. Lookup Keys are unique and are related to one TCN using the CNIS. Lookup Keys are unique and are related to one
DNL only. DNL only.
o LORDN, List of Registered Domain Names: This is the list of o LORDN, List of Registered Domain Names: This is the list of
effectively allocated DNs matching a DNL of a PRM. Registries effectively allocated DNs matching a DNL of a PRM. Registries
will upload this list to the TMDB (during the NORDN process). will upload this list to the TMDB (during the NORDN process).
skipping to change at page 6, line 36 skipping to change at page 6, line 39
o PKI: Public Key Infrastructure, see [RFC5280]. o PKI: Public Key Infrastructure, see [RFC5280].
o PRM, Pre-registered mark: Mark that has been pre-registered with o PRM, Pre-registered mark: Mark that has been pre-registered with
the ICANN TMCH. the ICANN TMCH.
o QLP Period, Qualified Launch Program Period: During this optional o QLP Period, Qualified Launch Program Period: During this optional
period, a special process applies to DNs matching the Sunrise List period, a special process applies to DNs matching the Sunrise List
(SURL) and/or the DNL List, to ensure that TMHs are informed of a (SURL) and/or the DNL List, to ensure that TMHs are informed of a
DN matching their PRM. DN matching their PRM.
o Registrant: see definition of Registrant in [RFC7719]. o Registrant: see definition of Registrant in [RFC8499].
o Registrar, Domain Name Registrar: see definition of Registrar in o Registrar, Domain Name Registrar: see definition of Registrar in
[RFC7719]. [RFC8499].
o Registry, Domain Name Registry, Registry Operator: see definition o Registry, Domain Name Registry, Registry Operator: see definition
of Registry in [RFC7719]. A Registry Operator is the contracting of Registry in [RFC8499]. A Registry Operator is the contracting
party with ICANN for the TLD. party with ICANN for the TLD.
o SMD, Signed Mark Data: A cryptographically signed token issued by o SMD, Signed Mark Data: A cryptographically signed token issued by
the TMV to the TMH to be used in the Sunrise Period to apply for a the TMV to the TMH to be used in the Sunrise Period to apply for a
DN that matches a DNL of a PRM; see also [RFC7848]. An SMD DN that matches a DNL of a PRM; see also [RFC7848]. An SMD
generated by an ICANN-approved trademark validator (TMV) contains generated by an ICANN-approved trademark validator (TMV) contains
both the signed token and the TMV's PKIX certificate. both the signed token and the TMV's PKIX certificate.
o SMD File: A file containing the SMD (see above) and some human o SMD File: A file containing the SMD (see above) and some human
readable data. The latter is usually ignored in the processing of readable data. The latter is usually ignored in the processing of
skipping to change at page 7, line 25 skipping to change at page 7, line 25
[ICANN-GTLD-AGB-20120604]. [ICANN-GTLD-AGB-20120604].
o SURL, Sunrise List: The list of DNLs that are covered by a PRM and o SURL, Sunrise List: The list of DNLs that are covered by a PRM and
eligible for Sunrise. eligible for Sunrise.
o Sunrise Period: During this period DNs matching a DNL of a PRM can o Sunrise Period: During this period DNs matching a DNL of a PRM can
be exclusively obtained by the respective TMHs. For DNs matching be exclusively obtained by the respective TMHs. For DNs matching
a PRM, a special process applies to ensure that TMHs are informed a PRM, a special process applies to ensure that TMHs are informed
on the effective allocation of a DN matching their PRM. on the effective allocation of a DN matching their PRM.
o TLD: Top-Level Domain Name, see definition of TLD in [RFC7719]. o TLD: Top-Level Domain Name, see definition of TLD in [RFC8499].
o ICANN TMCH: a central repository for information to be o ICANN TMCH: a central repository for information to be
authenticated, stored, and disseminated, pertaining to the rights authenticated, stored, and disseminated, pertaining to the rights
of TMHs. The ICANN TMCH is split into two functions TMV and TMDB of TMHs. The ICANN TMCH is split into two functions TMV and TMDB
(see below). There could be several entities performing the TMV (see below). There could be several entities performing the TMV
function, but only one entity performing the TMDB function. function, but only one entity performing the TMDB function.
o ICANN TMCH-CA: The Certificate Authority (CA) for the ICANN TMCH. o ICANN TMCH-CA: The Certificate Authority (CA) for the ICANN TMCH.
This CA is operated by ICANN. The public key for this CA is the This CA is operated by ICANN. The public key for this CA is the
trust anchor used to validate the identity of each TMV. trust anchor used to validate the identity of each TMV.
skipping to change at page 58, line 41 skipping to change at page 58, line 41
[[RFC Editor: Please remove this section.]] [[RFC Editor: Please remove this section.]]
9.1. Version 04 9.1. Version 04
1. Ping update. 1. Ping update.
9.2. Version 05 9.2. Version 05
1. Ping update. 1. Ping update.
9.3. Version 06
1. Updated the terminology text to reflect the text in RFC8174.
2. Updated the reference of RFC7719 to RFC8499.
3. Updated the matching rules document reference to link to the
latest version.
10. IANA Considerations 10. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688]. One URI conforming to a registry mechanism described in [RFC3688]. One URI
assignment have been registered by the IANA. assignment have been registered by the IANA.
Registration request for the Trademark Claims Notice namespace: Registration request for the Trademark Claims Notice namespace:
URI: urn:ietf:params:xml:ns:tmNotice-1.0 URI: urn:ietf:params:xml:ns:tmNotice-1.0
Registrant Contact: See the "Author's Address" section of this Registrant Contact: See the "Author's Address" section of this
document. document.
XML: None. Namespace URIs do not represent an XML specification. XML: None. Namespace URIs do not represent an XML specification.
Registration request for the Trademark Claims Notice XML schema: Registration request for the Trademark Claims Notice XML schema:
URI: urn:ietf:params:xml:ns:tmNotice-1.0 URI: urn:ietf:params:xml:ns:tmNotice-1.0
Registrant Contact: See the "Author's Address" section of this Registrant Contact: See the "Author's Address" section of this
skipping to change at page 59, line 37 skipping to change at page 60, line 4
The TMDB MUST provide credentials to the appropriate Registries and The TMDB MUST provide credentials to the appropriate Registries and
Registrars. Registrars.
The TMDB MUST require the use of strong passwords by Registries and The TMDB MUST require the use of strong passwords by Registries and
Registrars. Registrars.
The TMDB, Registries and Registrars MUST use the best practices The TMDB, Registries and Registrars MUST use the best practices
described in RFC 7525 or its successors. described in RFC 7525 or its successors.
12. References 12. References
12.1. Normative References 12.1. Normative References
[Claims50] [Claims50]
ICANN, "Implementation Notes: Trademark Claims Protection ICANN, "Implementation Notes: Trademark Claims Protection
for Previously Abused Names", July 2013, for Previously Abused Names", July 2013,
<https://newgtlds.icann.org/en/about/trademark- <https://newgtlds.icann.org/en/about/trademark-
clearinghouse/previously-abused-16jul13-en.pdf>. clearinghouse/previously-abused-16jul13-en.pdf>.
[MatchingRules] [MatchingRules]
ICANN, "Memorandum on Implementing Matching Rules", ICANN, "Memorandum on Implementing Matching Rules", July
September 2012, <https://newgtlds.icann.org/en/about/ 2016, <https://newgtlds.icann.org/en/about/trademark-
trademark-clearinghouse/matching-rules-24sep12-en.pdf>. clearinghouse/matching-rules-14jul16-en.pdf>.
[QLP-Addendum] [QLP-Addendum]
ICANN, "Qualified Launch Program Addendum", April 2014, ICANN, "Qualified Launch Program Addendum", April 2014,
<https://newgtlds.icann.org/en/about/trademark- <https://newgtlds.icann.org/en/about/trademark-
clearinghouse/rpm-requirements-qlp-addendum- clearinghouse/rpm-requirements-qlp-addendum-
10apr14-en.pdf>. 10apr14-en.pdf>.
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://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,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC7848] Lozano, G., "Mark and Signed Mark Objects Mapping", [RFC7848] Lozano, G., "Mark and Signed Mark Objects Mapping",
RFC 7848, DOI 10.17487/RFC7848, June 2016, RFC 7848, DOI 10.17487/RFC7848, June 2016,
<https://www.rfc-editor.org/info/rfc7848>. <https://www.rfc-editor.org/info/rfc7848>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RPM-Requirements] [RPM-Requirements]
ICANN, "Rights Protection Mechanism Requirements", ICANN, "Rights Protection Mechanism Requirements",
September 2013, <https://newgtlds.icann.org/en/about/ September 2013, <https://newgtlds.icann.org/en/about/
trademark-clearinghouse/rpm-requirements-30sep13-en.pdf>. trademark-clearinghouse/rpm-requirements-30sep13-en.pdf>.
12.2. Informative References 12.2. Informative References
[ICANN-GTLD-AGB-20120604] [ICANN-GTLD-AGB-20120604]
ICANN, "gTLD Applicant Guidebook Version 2012-06-04", June ICANN, "gTLD Applicant Guidebook Version 2012-06-04", June
2012, <http://newgtlds.icann.org/en/applicants/agb/ 2012, <http://newgtlds.icann.org/en/applicants/agb/
skipping to change at page 61, line 40 skipping to change at page 62, line 10
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235, Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014, DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>. <https://www.rfc-editor.org/info/rfc7235>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
2015, <https://www.rfc-editor.org/info/rfc7719>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[WIPO-NICE-CLASSES] [WIPO-NICE-CLASSES]
WIPO, "WIPO Nice Classification", 2015, WIPO, "WIPO Nice Classification", 2015,
<http://www.wipo.int/classifications/nice/en>. <http://www.wipo.int/classifications/nice/en>.
[WIPO.ST3] [WIPO.ST3]
WIPO, "Recommended standard on two-letter codes for the WIPO, "Recommended standard on two-letter codes for the
representation of states, other entities and representation of states, other entities and
intergovernmental organizations", March 2007, intergovernmental organizations", March 2007,
<http://www.iso.org/iso/home/standards/country_codes.htm>. <http://www.iso.org/iso/home/standards/country_codes.htm>.
 End of changes. 21 change blocks. 
24 lines changed or deleted 40 lines changed or added

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