draft-ietf-regext-tmch-func-spec-06.txt   draft-ietf-regext-tmch-func-spec-07.txt 
Internet Engineering Task Force G. Lozano Internet Engineering Task Force G. Lozano
Internet-Draft ICANN Internet-Draft ICANN
Intended status: Informational Nov 19, 2019 Intended status: Informational Apr 06, 2020
Expires: May 22, 2020 Expires: October 8, 2020
ICANN TMCH functional specifications ICANN TMCH functional specifications
draft-ietf-regext-tmch-func-spec-06 draft-ietf-regext-tmch-func-spec-07
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 22, 2020. This Internet-Draft will expire on October 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 32 skipping to change at page 3, line 32
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
9.3. Version 06 . . . . . . . . . . . . . . . . . . . . . . . 58 9.3. Version 06 . . . . . . . . . . . . . . . . . . . . . . . 58
9.4. Version 07 . . . . . . . . . . . . . . . . . . . . . . . 58
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
11. Security Considerations . . . . . . . . . . . . . . . . . . . 59 11. Security Considerations . . . . . . . . . . . . . . . . . . . 59
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 59
12.1. Normative References . . . . . . . . . . . . . . . . . . 60 12.1. Normative References . . . . . . . . . . . . . . . . . . 59
12.2. Informative References . . . . . . . . . . . . . . . . . 60 12.2. Informative References . . . . . . . . . . . . . . . . . 61
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
modes came into effect: modes came into effect:
skipping to change at page 17, line 18 skipping to change at page 17, line 18
registration during the Sunrise Period upon reception of a registration during the Sunrise Period upon reception of a
registration request over the ry interface (Section 4.3.5). If any registration request over the ry interface (Section 4.3.5). If any
of these checks fails the Registry MUST abort the registration. Each of these checks fails the Registry MUST abort the registration. Each
of these checks MUST be performed before the DN is effectively of these checks MUST be performed before the DN is effectively
allocated. allocated.
In case of asynchronous registrations (e.g. auctions), the minimum In case of asynchronous registrations (e.g. auctions), the minimum
set of checks MAY be performed when creating the intermediate object set of checks MAY be performed when creating the intermediate object
(e.g. a DN application) used for DN registration. If the minimum set (e.g. a DN application) used for DN registration. If the minimum set
of checks is performed when creating the intermediate object (e.g. a of checks is performed when creating the intermediate object (e.g. a
DN application) a Registry MAY effective allocate the DN without DN application) a Registry MAY effectively allocate the DN without
performing the minimum set of checks again. performing the minimum set of checks again.
Performing the minimum set of checks Registries MUST verify that: Performing the minimum set of checks Registries MUST verify that:
1. An SMD has been received from the Registrar along with the DN 1. An SMD has been received from the Registrar along with the DN
registration. registration.
2. The certificate of the TMV has been correctly signed by the ICANN 2. The certificate of the TMV has been correctly signed by the ICANN
TMCH-CA. (The certificate of the TMV is contained within the TMCH-CA. (The certificate of the TMV is contained within the
SMD.) SMD.)
skipping to change at page 24, line 32 skipping to change at page 24, line 32
Trademark Claims Period upon reception of a registration request Trademark Claims Period upon reception of a registration request
over the ry interface (Section 4.3.5). If any of these checks over the ry interface (Section 4.3.5). If any of these checks
fails the Registry MUST abort the registration. Each of these fails the Registry MUST abort the registration. Each of these
checks MUST be performed before the DN is effectively allocated. checks MUST be performed before the DN is effectively allocated.
o In case of asynchronous registrations (e.g. auctions), the minimum o In case of asynchronous registrations (e.g. auctions), the minimum
set of checks MAY be performed when creating the intermediate set of checks MAY be performed when creating the intermediate
object (e.g. a DN application) used for DN effective allocation. object (e.g. a DN application) used for DN effective allocation.
If the minimum set of checks is performed when creating the If the minimum set of checks is performed when creating the
intermediate object (e.g. a DN application) a Registry MAY intermediate object (e.g. a DN application) a Registry MAY
effective allocate the DN without performing the minimum set of effectively allocate the DN without performing the minimum set of
checks again. checks again.
o Performing the minimum set of checks Registries MUST verify that: o Performing the minimum set of checks Registries MUST verify that:
1. The TCNID (<tmNotice:id>), expiration datetime 1. The TCNID (<tmNotice:id>), expiration datetime
(<tmNotice:notAfter>) and acceptance datetime of the TCN, have (<tmNotice:notAfter>) and acceptance datetime of the TCN, have
been received from the Registrar along with the DN been received from the Registrar along with the DN
registration. registration.
If the three elements mentioned above are not provided by If the three elements mentioned above are not provided by
skipping to change at page 55, line 36 skipping to change at page 55, line 36
7. Formal Syntax 7. Formal Syntax
7.1. Trademark Claims Notice (TCN) 7.1. Trademark Claims Notice (TCN)
The schema presented here is for a Trademark Claims Notice. The schema presented here is for a Trademark Claims Notice.
The BEGIN and END tags are not part of the schema; they are used to The BEGIN and END tags are not part of the schema; they are used to
note the beginning and ending of the schema for URI registration note the beginning and ending of the schema for URI registration
purposes. purposes.
Copyright (c) 2016 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in
Section 4.c of the IETF Trust's Legal Provisions Relating to IETF
Documents (http://trustee.ietf.org/license-info).
BEGIN BEGIN
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:tmNotice-1.0" <schema targetNamespace="urn:ietf:params:xml:ns:tmNotice-1.0"
xmlns:tmNotice="urn:ietf:params:xml:ns:tmNotice-1.0" xmlns:tmNotice="urn:ietf:params:xml:ns:tmNotice-1.0"
xmlns:mark="urn:ietf:params:xml:ns:mark-1.0" xmlns:mark="urn:ietf:params:xml:ns:mark-1.0"
xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<annotation> <annotation>
<documentation> <documentation>
Schema for representing a Trademark Claim Notice. Schema for representing a Trademark Claim Notice.
skipping to change at page 59, line 5 skipping to change at page 58, line 42
9.3. Version 06 9.3. Version 06
1. Updated the terminology text to reflect the text in RFC8174. 1. Updated the terminology text to reflect the text in RFC8174.
2. Updated the reference of RFC7719 to RFC8499. 2. Updated the reference of RFC7719 to RFC8499.
3. Updated the matching rules document reference to link to the 3. Updated the matching rules document reference to link to the
latest version. latest version.
9.4. Version 07
1. Changes based on the feedback provided here:
https://mailarchive.ietf.org/arch/msg/regext/
xcZPOAajlUJzgPgZBuqlIWRcFZg/
2. Changes based on the feedback provided here:
https://mailarchive.ietf.org/arch/msg/regext/
MdOhSomd6_djLcthfw5mxWZkbWY
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]. Two URI
assignment have been registered by the IANA. assignments 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: IETF <regext@ietf.org>
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:schema:tmNotice-1.0
Registrant Contact: See the "Author's Address" section of this Registrant Contact: IETF <regext@ietf.org>
document.
XML: See Section 7.1 of this document. XML: See Section 7.1 of this document.
11. Security Considerations 11. Security Considerations
This specification uses HTTP Basic Authentication to provide a simple This specification uses HTTP Basic Authentication to provide a simple
application-layer authentication service. HTTPS is used in all application-layer authentication service. HTTPS is used in all
interfaces in order to protect against most common attacks. In interfaces in order to protect against most common attacks. In
addition, the client identifier is tied to a set of IP addresses that addition, the client identifier is tied to a set of IP addresses that
are allowed to connect to the interfaces described in this document, are allowed to connect to the interfaces described in this document,
skipping to change at page 60, line 45 skipping to change at page 60, line 44
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/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>.
[W3C.REC-xml-20081126]
Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition) REC-xml-20081126", November 2008,
<https://www.w3.org/TR/2008/REC-xml-20081126/>.
[W3C.REC-xmlschema-1-20041028]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition REC-
xmlschema-1-20041028", October 2004,
<https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/>.
[W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition REC-xmlschema-2-20041028", October 2004,
<https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.
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/
guidebook-full-04jun12-en.pdf>. guidebook-full-04jun12-en.pdf>.
[ISO3166-2] [ISO3166-2]
ISO, "International Standard for country codes and codes ISO, "International Standard for country codes and codes
for their subdivisions", 2006, for their subdivisions", 2006,
 End of changes. 15 change blocks. 
25 lines changed or deleted 42 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/