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/