draft-ietf-regext-tmch-func-spec-00.txt | draft-ietf-regext-tmch-func-spec-01.txt | |||
---|---|---|---|---|
Internet Engineering Task Force G. Lozano | Internet Engineering Task Force G. Lozano | |||
Internet-Draft ICANN | Internet-Draft ICANN | |||
Intended status: Standards Track April 22, 2016 | Intended status: Standards Track June 8, 2016 | |||
Expires: October 24, 2016 | Expires: December 10, 2016 | |||
ICANN TMCH functional specifications | ICANN TMCH functional specifications | |||
draft-ietf-regext-tmch-func-spec-00 | draft-ietf-regext-tmch-func-spec-01 | |||
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 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 24, 2016. | This Internet-Draft will expire on December 10, 2016. | |||
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 5, line 14 ¶ | skipping to change at page 5, line 14 ¶ | |||
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]. | [RFC7719]. In case of IDNs, the A-label form MUST be used, i.e. | |||
each of the DNLs are an A-label or NR-LDH (see [RFC5890]). | ||||
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, see definition of Label in [RFC7719]. | o DNL, Domain Name Label, see definition of Label in [RFC7719]. The | |||
DNL is an A-label or NR-LDH. | ||||
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 [RFC7719]. | |||
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 | |||
skipping to change at page 6, line 11 ¶ | skipping to change at page 6, line 14 ¶ | |||
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). | |||
o Matching Rules: Some trademarks entitled to inclusion in the TMDB | ||||
include characters that are impermissible in the domain name | ||||
system (DNS) as a DNL. The TMV changes ( using the ICANN TMCH | ||||
Matching Rules [MatchingRules]) certain DNS-impermissible | ||||
characters in a trademark into DNS-permissible equivalent | ||||
characters | ||||
o NORDN, Notification of Registered Domain Names: The process by | o NORDN, Notification of Registered Domain Names: The process by | |||
which Registries upload their recent LORDN to the TMDB. | which Registries upload their recent LORDN to the TMDB. | |||
o PGP: Pretty Good Privacy, see [RFC4880] | o PGP: Pretty Good Privacy, see [RFC4880] | |||
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. | |||
skipping to change at page 17, line 46 ¶ | skipping to change at page 17, line 46 ¶ | |||
5. The signature of the SMD (signed with the TMV certificate) is | 5. The signature of the SMD (signed with the TMV certificate) is | |||
valid. | valid. | |||
6. The datetime when the validation is done is within the validity | 6. The datetime when the validation is done is within the validity | |||
period of the SMD based on <smd:notBefore> and <smd:notAfter> | period of the SMD based on <smd:notBefore> and <smd:notAfter> | |||
elements. | elements. | |||
7. The SMD has not been revoked, i.e., is not contained in the SMD | 7. The SMD has not been revoked, i.e., is not contained in the SMD | |||
Revocation List. | Revocation List. | |||
8. The leftmost DNL (A-label in case of IDNs) of the DN being | 8. The leftmost DNL of the DN (A-label form in the case of IDNs) | |||
effectively allocated matches one of the labels (<mark:label>) | being effectively allocated matches one of the labels | |||
elements in the SMD. | (<mark:label>) elements in the SMD. For example, if the DN "xn-- | |||
mgbachtv.xn--mgbh0fb" is being effectively allocated, the | ||||
leftmost DNL would be "xn--mgbachtv". | ||||
These procedure apply to all DN effective allocations at the second | These procedure apply to all DN effective allocations at the second | |||
level as well as to all other levels subordinate to the TLD that the | level as well as to all other levels subordinate to the TLD that the | |||
Registry accepts registrations for. | Registry accepts registrations for. | |||
5.2.3. TMDB Sunrise Services for Registries | 5.2.3. TMDB Sunrise Services for Registries | |||
5.2.3.1. SMD Revocation List | 5.2.3.1. SMD Revocation List | |||
A new SMD Revocation List MUST be published by the TMDB twice a day, | A new SMD Revocation List MUST be published by the TMDB twice a day, | |||
skipping to change at page 24, line 52 ¶ | skipping to change at page 25, line 5 ¶ | |||
If the three elements mentioned above are not provided by | If the three elements mentioned above are not provided by | |||
the Registrar for a DN matching a DNL of a PRM, but the DNL | the Registrar for a DN matching a DNL of a PRM, but the DNL | |||
was inserted (or re-inserted) for the first time into DNL | was inserted (or re-inserted) for the first time into DNL | |||
List less than 24 hours ago, the registration MAY continue | List less than 24 hours ago, the registration MAY continue | |||
without this data and the tests listed below are not | without this data and the tests listed below are not | |||
required to be performed. | required to be performed. | |||
2. The TCN has not expired (according to the expiration datetime | 2. The TCN has not expired (according to the expiration datetime | |||
sent by the Registrar). | sent by the Registrar). | |||
3. The acceptance datetime is no more than 48 hours in the past. | 3. The acceptance datetime is no more than 48 hours in the past, | |||
or a different value defined by policy. | ||||
4. Using the leftmost DNL (A-label in the case of IDNs) of the DN | 4. Using the leftmost DNL of the DN (A-label form in the case of | |||
being registered, the expiration datetime provided by the | IDNs) being effectively allocated, the expiration datetime | |||
Registrar, and the TMDB Notice Identifier extracted from the | provided by the Registrar, and the TMDB Notice Identifier | |||
TCNID provided by the Registrar compute the TCN Checksum. | extracted from the TCNID provided by the Registrar compute the | |||
Verify that the computed TCN Checksum match the TCN Checksum | TCN Checksum. Verify that the computed TCN Checksum match the | |||
present in the TCNID. | TCN Checksum present in the TCNID. For example, if the DN | |||
"xn--mgbachtv.xn--mgbh0fb" is being effectively allocated, the | ||||
leftmost DNL would be "xn--mgbachtv". | ||||
These procedures apply to all DN registrations at the second level as | These procedures apply to all DN registrations at the second level as | |||
well as to all other levels subordinate to the TLD that the Registry | well as to all other levels subordinate to the TLD that the Registry | |||
accepts registrations for. | accepts registrations for. | |||
5.3.3. TMBD Trademark Claims Services for Registries | 5.3.3. TMBD Trademark Claims Services for Registries | |||
5.3.3.1. Domain Name Label (DNL) List | 5.3.3.1. Domain Name Label (DNL) List | |||
A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 | A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 | |||
skipping to change at page 26, line 42 ¶ | skipping to change at page 26, line 48 ¶ | |||
4. Perform the minimum set of checks for verifying DN registrations. | 4. Perform the minimum set of checks for verifying DN registrations. | |||
If any of these checks fails the Registrar MUST abort the DN | If any of these checks fails the Registrar MUST abort the DN | |||
registration. Each of these checks MUST be performed before the | registration. Each of these checks MUST be performed before the | |||
registration is sent to the Registry. Performing the minimum set | registration is sent to the Registry. Performing the minimum set | |||
of checks Registrars MUST verify that: | of checks Registrars MUST verify that: | |||
1. The datetime when the validation is done is within the TCN | 1. The datetime when the validation is done is within the TCN | |||
validity based on the <tmNotice:notBefore> and | validity based on the <tmNotice:notBefore> and | |||
<tmNotice:notAfter> elements. | <tmNotice:notAfter> elements. | |||
2. The leftmost DNL (A-label in case of IDNs) of the DN being | 2. The leftmost DNL of the DN (A-label form in the case of IDNs) | |||
effectively allocated matches the label (<tmNotice:label>) | being effectively allocated matches the label | |||
element in the TCN. | (<tmNotice:label>) element in the TCN. For example, if the | |||
DN "xn--mgbachtv.xn--mgbh0fb" is being effectively allocated, | ||||
the leftmost DNL would be "xn--mgbachtv". | ||||
3. The Registrant has acknowledged (expressed his/her consent | 3. The Registrant has acknowledged (expressed his/her consent | |||
with) the TCN. | with) the TCN. | |||
5. Record the date and time when the registrant acknowledged the | 5. Record the date and time when the registrant acknowledged the | |||
TCN. | TCN. | |||
6. Send the registration to the Registry (ry interface, | 6. Send the registration to the Registry (ry interface, | |||
Section 4.3.5) and include the following information: | Section 4.3.5) and include the following information: | |||
* TCNID (<tmNotice:id>) | * TCNID (<tmNotice:id>) | |||
* Expiration date of the TCN (<tmNotice:notAfter>) | * Expiration date of the TCN (<tmNotice:notAfter>) | |||
* Acceptance datetime of the TCN. | * Acceptance datetime of the TCN. | |||
TCN are generated twice a day. The expiration date | TCNs are generated twice a day. The expiration date | |||
(<tmNotice:notAfter>) of each TCN MUST be set to 48 hours in the | (<tmNotice:notAfter>) of each TCN MUST be set to 48 hours (or a | |||
future by the TMDB, allowing the implementation of a cache by | different value if defined by policy) in the future by the TMDB, | |||
Registrars and enough time for acknowledging the TCN. Registrars | allowing the implementation of a cache by Registrars and enough time | |||
SHOULD implement a cache of TCNs to minimize the number of queries | for acknowledging the TCN. Registrars SHOULD implement a cache of | |||
sent to the TMDB. A cached TCN MUST be removed from the cache after | TCNs to minimize the number of queries sent to the TMDB. A cached | |||
the expiration date of the TCN as defined by <tmNotice:notAfter>. | TCN MUST be removed from the cache after the expiration date of the | |||
The TMDB MAY implement rate-limiting as one of the protection | TCN as defined by <tmNotice:notAfter>. The TMDB MAY implement rate- | |||
mechanisms to mitigate the risk of performance degradation. | limiting as one of the protection mechanisms to mitigate the risk of | |||
performance degradation. | ||||
5.3.5. TMBD Trademark Claims Services for Registrars | 5.3.5. TMBD Trademark Claims Services for Registrars | |||
5.3.5.1. Claims Notice Information Service (CNIS) | 5.3.5.1. Claims Notice Information Service (CNIS) | |||
The TCNs are provided by the TMDB online and are fetched by the | The TCNs are provided by the TMDB online and are fetched by the | |||
Registrar via the dr interface (Section 4.3.6). | Registrar via the dr interface (Section 4.3.6). | |||
To get access to the TCNs, the Registrar needs the credentials | To get access to the TCNs, the Registrar needs the credentials | |||
provided by the TMDB (Section 5.1.2.1) and the Lookup Key received | provided by the TMDB (Section 5.1.2.1) and the Lookup Key received | |||
skipping to change at page 28, line 20 ¶ | skipping to change at page 28, line 30 ¶ | |||
During the OPTIONAL (see [QLP-Addendum]) Qualified Launch Program | During the OPTIONAL (see [QLP-Addendum]) Qualified Launch Program | |||
(QLP) Period effective allocations of DNs to third parties could | (QLP) Period effective allocations of DNs to third parties could | |||
require that Registries and Registrars provide Sunrise and/or | require that Registries and Registrars provide Sunrise and/or | |||
Trademark Claims services. If required, Registries and Registrars | Trademark Claims services. If required, Registries and Registrars | |||
MUST provide Sunrise and/or Trademark Claims services as described in | MUST provide Sunrise and/or Trademark Claims services as described in | |||
Section 5.2 and Section 5.3. | Section 5.2 and Section 5.3. | |||
The effective allocation scenarios are: | The effective allocation scenarios are: | |||
o If the leftmost DNL (A-label in case of IDNs) of the DN being | o If the leftmost DNL of the DN (A-label form in the case of IDNs) | |||
effectively allocated (QLP Name in this section) matches a DNL in | being effectively allocated (QLP Name in this section) matches a | |||
the SURL, and an SMD is provided, then Registries MUST provide | DNL in the SURL, and an SMD is provided, then Registries MUST | |||
Sunrise Services (see Section 5.2) and the DN MUST be reported in | provide Sunrise Services (see Section 5.2) and the DN MUST be | |||
a Sunrise LORDN file during the QLP Period. | reported in a Sunrise LORDN file during the QLP Period. For | |||
example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being effectively | ||||
allocated, the leftmost DNL would be "xn--mgbachtv". | ||||
o If the QLP Name matches a DNL in the SURL but does not match a DNL | o If the QLP Name matches a DNL in the SURL but does not match a DNL | |||
in the DNL List, and an SMD is NOT provided (see section 2.2 of | in the DNL List, and an SMD is NOT provided (see section 2.2 of | |||
[QLP-Addendum]), then the DN MUST be reported in a Sunrise LORDN | [QLP-Addendum]), then the DN MUST be reported in a Sunrise LORDN | |||
file using the special SMD-id "99999-99999" during the QLP Period. | file using the special SMD-id "99999-99999" during the QLP Period. | |||
o If the QLP Name matches a DNL in the SURL and also matches a DNL | o If the QLP Name matches a DNL in the SURL and also matches a DNL | |||
in the DNL List, and an SMD is NOT provided (see section 2.2 of | in the DNL List, and an SMD is NOT provided (see section 2.2 of | |||
[QLP-Addendum]), then Registries MUST provide Trademark Claims | [QLP-Addendum]), then Registries MUST provide Trademark Claims | |||
services (see Section 5.3) and the DN MUST be reported in a | services (see Section 5.3) and the DN MUST be reported in a | |||
skipping to change at page 36, line 42 ¶ | skipping to change at page 36, line 42 ¶ | |||
* One or more lines with: <roid>,<DN registered>,<SMD-id>,<IANA | * One or more lines with: <roid>,<DN registered>,<SMD-id>,<IANA | |||
Registrar id>,<datetime of registration>,<datetime of | Registrar id>,<datetime of registration>,<datetime of | |||
application creation> | application creation> | |||
Where: | Where: | |||
- <roid>, DN Repository Object IDentifier (DNROID) in the | - <roid>, DN Repository Object IDentifier (DNROID) in the | |||
SRS. | SRS. | |||
- <DN registered>, DN that was effectively allocated. For | - <DN registered>, DN that was effectively allocated. For | |||
IDNs the A-Label (see [RFC5890]) is used. | IDNs, the A-Label form is used. | |||
- <SMD-id>, SMD ID used for registration. | - <SMD-id>, SMD ID used for registration. | |||
- <IANA Registrar ID>, IANA Registrar ID. | - <IANA Registrar ID>, IANA Registrar ID. | |||
- <datetime of registration>, date and time in UTC that the | - <datetime of registration>, date and time in UTC that the | |||
domain was effectively allocated. | domain was effectively allocated. | |||
- OPTIONAL <datetime of application creation>, date and | - OPTIONAL <datetime of application creation>, date and | |||
time in UTC that the application was created. The | time in UTC that the application was created. The | |||
skipping to change at page 38, line 6 ¶ | skipping to change at page 38, line 6 ¶ | |||
* One or more lines with: <roid>,<DN registered>,<TCNID>,<IANA | * One or more lines with: <roid>,<DN registered>,<TCNID>,<IANA | |||
Registrar id>,<datetime of registration>,<datetime of | Registrar id>,<datetime of registration>,<datetime of | |||
acceptance of the TCN>,<datetime of application creation> | acceptance of the TCN>,<datetime of application creation> | |||
Where: | Where: | |||
- <roid>, DN Repository Object IDentifier (DNROID) in the | - <roid>, DN Repository Object IDentifier (DNROID) in the | |||
SRS. | SRS. | |||
- <DN registered>, DN that was effectively allocated. For | - <DN registered>, DN that was effectively allocated. For | |||
IDNs the A-Label is used. | IDNs, the A-Label form is used. | |||
- <TCNID>, Trademark Claims Notice Identifier as specified | - <TCNID>, Trademark Claims Notice Identifier as specified | |||
in <tmNotice:id>. | in <tmNotice:id>. | |||
- <IANA Registrar ID>, IANA Registrar ID. | - <IANA Registrar ID>, IANA Registrar ID. | |||
- <datetime of registration>, date and time in UTC that the | - <datetime of registration>, date and time in UTC that the | |||
domain was effectively allocated. | domain was effectively allocated. | |||
- <datetime of acceptance of the TCN>, date and time in UTC | - <datetime of acceptance of the TCN>, date and time in UTC | |||
skipping to change at page 45, line 30 ¶ | skipping to change at page 45, line 30 ¶ | |||
boundaries themselves MUST be ignored for validation purposes. | boundaries themselves MUST be ignored for validation purposes. | |||
The structure of the SMD File is as follows, all the elements are | The structure of the SMD File is as follows, all the elements are | |||
REQUIRED, and MUST appear in the specified order. | REQUIRED, and MUST appear in the specified order. | |||
1. Marks: <marks> | 1. Marks: <marks> | |||
2. smdID: <SMD-ID> | 2. smdID: <SMD-ID> | |||
3. U-labels: <comma separated list of labels in U-label (see | 3. U-labels: <comma separated list of labels in U-label (see | |||
[RFC5890]) form (i.e., U-labels or LDH as the case may be)> | [RFC5890]) form (i.e., U-labels or NR-LDH as the case may be)> | |||
4. notBefore: <begin validity> | 4. notBefore: <begin validity> | |||
5. notAfter: <end validity> | 5. notAfter: <end validity> | |||
6. -----BEGIN ENCODED SMD----- | 6. -----BEGIN ENCODED SMD----- | |||
7. <encoded SMD (see [I-D.ietf-eppext-tmch-smd])> | 7. <encoded SMD (see [I-D.ietf-eppext-tmch-smd])> | |||
8. -----END ENCODED SMD----- | 8. -----END ENCODED SMD----- | |||
skipping to change at page 47, line 21 ¶ | skipping to change at page 47, line 21 ¶ | |||
since 1970-01-01T00:00:00Z not counting leap seconds. For | since 1970-01-01T00:00:00Z not counting leap seconds. For | |||
example, the conversion to Unix time of 2010-08-16T09:00:00.0Z | example, the conversion to Unix time of 2010-08-16T09:00:00.0Z | |||
is shown: | is shown: | |||
unix_time(2010-08-16T09:00:00.0Z)=1281949200 | unix_time(2010-08-16T09:00:00.0Z)=1281949200 | |||
The TMDB uses the <tmNotice:label> and <tmNotice:notAfter> | The TMDB uses the <tmNotice:label> and <tmNotice:notAfter> | |||
elements from the TCN along with the TMDB Notice Identifier to | elements from the TCN along with the TMDB Notice Identifier to | |||
compute the TCN Checksum. | compute the TCN Checksum. | |||
A Registry MUST use the leftmost DNL (A-label in case of IDNs) | A Registry MUST use the leftmost DNL of the DN (A-label form in | |||
of the DN being registered, the expiration datetime of the TCN | the case of IDNs) being effectively allocated, the expiration | |||
(provided by the Registrar) and the TMDB Notice Identifier | datetime of the TCN (provided by the Registrar) and the TMDB | |||
extracted from the TCNID (provided by the Registrar) to compute | Notice Identifier extracted from the TCNID (provided by the | |||
the TCN Checksum. For example the DN "foo.bar.example" being | Registrar) to compute the TCN Checksum. For example, if the DN | |||
effectively allocated, the left most label would be "foo". | "xn--mgbachtv.xn--mgbh0fb" is being effectively allocated, the | |||
leftmost DNL would be "xn--mgbachtv". | ||||
Example of computation of the TCN Checksum: | Example of computation of the TCN Checksum: | |||
CRC32(example-one12819492009223372036854775807)=370d0b7c | CRC32(example-one12819492009223372036854775807)=370d0b7c | |||
o A <tmNotice:notBefore> element that contains the start of the | o A <tmNotice:notBefore> element that contains the start of the | |||
validity date and time of the TCN. | validity date and time of the TCN. | |||
o A <tmNotice:notAfter> element that contains the expiration date | o A <tmNotice:notAfter> element that contains the expiration date | |||
and time of the TCN. | and time of the TCN. | |||
o A <tmNotice:label> elements that contain the DNL (A-label in case | o A <tmNotice:label> element that contains the DNL covered by a PRM. | |||
of IDNs) form of the label that correspond to the DN covered by a | ||||
PRM. | ||||
o One or more <tmNotice:claim> elements that contain the Trademark | o One or more <tmNotice:claim> elements that contain the Trademark | |||
Claim. The <tmNotice:claim> element contains the following child | Claim. The <tmNotice:claim> element contains the following child | |||
elements: | elements: | |||
* A <tmNotice:markName> element that contains the mark text | * A <tmNotice:markName> element that contains the mark text | |||
string. | string. | |||
* One or more <tmNotice:holder> elements that contains the | * One or more <tmNotice:holder> elements that contains the | |||
information of the holder of the mark. An "entitlement" | information of the holder of the mark. An "entitlement" | |||
skipping to change at page 58, line 24 ¶ | skipping to change at page 58, line 24 ¶ | |||
described in RFC 7525 or its successors. | described in RFC 7525 or its successors. | |||
11. References | 11. References | |||
11.1. Normative References | 11.1. Normative References | |||
[I-D.ietf-eppext-tmch-smd] | [I-D.ietf-eppext-tmch-smd] | |||
Lozano, G., "Mark and Signed Mark Objects Mapping", draft- | Lozano, G., "Mark and Signed Mark Objects Mapping", draft- | |||
ietf-eppext-tmch-smd-06 (work in progress), March 2016. | ietf-eppext-tmch-smd-06 (work in progress), March 2016. | |||
[MatchingRules] | ||||
ICANN, "Memorandum on Implementing Matching Rules", | ||||
September 2012, <https://newgtlds.icann.org/en/about/ | ||||
trademark-clearinghouse/matching-rules-24sep12-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, | |||
<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>. | |||
11.2. Informative References | 11.2. Informative References | |||
skipping to change at page 59, line 5 ¶ | skipping to change at page 59, line 10 ¶ | |||
[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, | |||
<http://www.iso.org/iso/home/standards/country_codes.htm>. | <http://www.iso.org/iso/home/standards/country_codes.htm>. | |||
[MatchingRules] | ||||
ICANN, "Memorandum on Implementing Matching Rules", | ||||
September 2012, <https://newgtlds.icann.org/en/about/ | ||||
trademark-clearinghouse/matching-rules-24sep12-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>. | |||
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | |||
Transfer Protocol -- HTTP/1.1", RFC 2616, | Transfer Protocol -- HTTP/1.1", RFC 2616, | |||
DOI 10.17487/RFC2616, June 1999, | DOI 10.17487/RFC2616, June 1999, | |||
End of changes. 19 change blocks. | ||||
50 lines changed or deleted | 68 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/ |