draft-ietf-regext-tmch-func-spec-10.txt		draft-ietf-regext-tmch-func-spec-11.txt
	Internet Engineering Task Force G. Lozano		Internet Engineering Task Force G. Lozano
	Internet-Draft ICANN		Internet-Draft ICANN
	Intended status: Informational Jun 02, 2021		Intended status: Informational Jan 04, 2022
	Expires: December 4, 2021		Expires: July 8, 2022
	ICANN TMCH functional specifications		ICANN TMCH functional specifications
	draft-ietf-regext-tmch-func-spec-10		draft-ietf-regext-tmch-func-spec-11
	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 December 4, 2021.		This Internet-Draft will expire on July 8, 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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 2, line 46 ¶		skipping to change at page 2, line 46 ¶
	5.1.2. Bootstrapping for Registrars . . . . . . . . . . . . 15		5.1.2. Bootstrapping for Registrars . . . . . . . . . . . . 15
	5.1.2.1. Credentials . . . . . . . . . . . . . . . . . . . 15		5.1.2.1. Credentials . . . . . . . . . . . . . . . . . . . 15
	5.1.2.2. IP Addresses for Access Control . . . . . . . . . 15		5.1.2.2. IP Addresses for Access Control . . . . . . . . . 15
	5.1.2.3. ICANN TMCH Trust Anchor . . . . . . . . . . . . . 15		5.1.2.3. ICANN TMCH Trust Anchor . . . . . . . . . . . . . 15
	5.1.2.4. TMDB PGP Key . . . . . . . . . . . . . . . . . . 15		5.1.2.4. TMDB PGP Key . . . . . . . . . . . . . . . . . . 15
	5.2. Sunrise Period . . . . . . . . . . . . . . . . . . . . . 16		5.2. Sunrise Period . . . . . . . . . . . . . . . . . . . . . 16
	5.2.1. Domain Name registration . . . . . . . . . . . . . . 16		5.2.1. Domain Name registration . . . . . . . . . . . . . . 16
	5.2.2. Sunrise Domain Name registration by Registries . . . 17		5.2.2. Sunrise Domain Name registration by Registries . . . 17
	5.2.3. TMDB Sunrise Services for Registries . . . . . . . . 18		5.2.3. TMDB Sunrise Services for Registries . . . . . . . . 18
	5.2.3.1. SMD Revocation List . . . . . . . . . . . . . . . 18		5.2.3.1. SMD Revocation List . . . . . . . . . . . . . . . 18
	5.2.3.2. TMV Certificate Revocation List (CRL) . . . . . . 18		5.2.3.2. TMV Certificate Revocation List (CRL) . . . . . . 19
	5.2.3.3. Notice of Registered Domain Names (NORN) . . . . 19		5.2.3.3. Notice of Registered Domain Names (NORN) . . . . 19
	5.2.4. Sunrise Domain Name registration by Registrars . . . 22		5.2.4. Sunrise Domain Name registration by Registrars . . . 22
	5.2.5. TMDB Sunrise Services for Registrars . . . . . . . . 22		5.2.5. TMDB Sunrise Services for Registrars . . . . . . . . 22
	5.3. Trademark Claims Period . . . . . . . . . . . . . . . . . 23		5.3. Trademark Claims Period . . . . . . . . . . . . . . . . . 23
	5.3.1. Domain Registration . . . . . . . . . . . . . . . . . 23		5.3.1. Domain Registration . . . . . . . . . . . . . . . . . 23
	5.3.2. Trademark Claims Domain Name registration by		5.3.2. Trademark Claims Domain Name registration by
	Registries . . . . . . . . . . . . . . . . . . . . . 24		Registries . . . . . . . . . . . . . . . . . . . . . 24
	5.3.3. TMBD Trademark Claims Services for Registries . . . . 25		5.3.3. TMBD Trademark Claims Services for Registries . . . . 25
	5.3.3.1. Domain Name Label (DNL) List . . . . . . . . . . 25		5.3.3.1. Domain Name Label (DNL) List . . . . . . . . . . 25
	5.3.3.2. Notice of Registered Domain Names (NORN) . . . . 26		5.3.3.2. Notice of Registered Domain Names (NORN) . . . . 26
	5.3.4. Trademark Claims Domain Name registration by		5.3.4. Trademark Claims Domain Name registration by
	Registrars . . . . . . . . . . . . . . . . . . . . . 26		Registrars . . . . . . . . . . . . . . . . . . . . . 26
	5.3.5. TMBD Trademark Claims Services for Registrars . . . . 28		5.3.5. TMBD Trademark Claims Services for Registrars . . . . 28
	5.3.5.1. Claims Notice Information Service (CNIS) . . . . 28		5.3.5.1. Claims Notice Information Service (CNIS) . . . . 28
	5.4. Qualified Launch Program (QLP) Period . . . . . . . . . . 28		5.4. Qualified Launch Program (QLP) Period . . . . . . . . . . 28
	5.4.1. Domain Registration . . . . . . . . . . . . . . . . . 28		5.4.1. Domain Registration . . . . . . . . . . . . . . . . . 28
	5.4.2. TMBD QLP Services for Registries . . . . . . . . . . 31		5.4.2. TMBD QLP Services for Registries . . . . . . . . . . 31
	5.4.2.1. Sunrise List (SURL) . . . . . . . . . . . . . . . 31		5.4.2.1. Sunrise List (SURL) . . . . . . . . . . . . . . . 31
	6. Data Format Descriptions . . . . . . . . . . . . . . . . . . 31		6. Data Format Descriptions . . . . . . . . . . . . . . . . . . 31
	6.1. Domain Name Label (DNL) List . . . . . . . . . . . . . . 31		6.1. Domain Name Label (DNL) List . . . . . . . . . . . . . . 32
	6.2. SMD Revocation List . . . . . . . . . . . . . . . . . . . 33		6.2. SMD Revocation List . . . . . . . . . . . . . . . . . . . 33
	6.3. List of Registered Domain Names (LORDN) file . . . . . . 35		6.3. List of Registered Domain Names (LORDN) file . . . . . . 35
	6.3.1. LORDN Log file . . . . . . . . . . . . . . . . . . . 40		6.3.1. LORDN Log file . . . . . . . . . . . . . . . . . . . 39
	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 . . . . . . . . . . . . . . . 45
	6.5. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 47		6.5. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 46
	6.6. Sunrise List (SURL) . . . . . . . . . . . . . . . . . . . 54		6.6. Sunrise List (SURL) . . . . . . . . . . . . . . . . . . . 53
	7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 55		7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 54
	7.1. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 55		7.1. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 54
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 58		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57
	9. Change History . . . . . . . . . . . . . . . . . . . . . . . 58		9. Change History . . . . . . . . . . . . . . . . . . . . . . . 57
	9.1. Version 04 . . . . . . . . . . . . . . . . . . . . . . . 58		9.1. Version 04 . . . . . . . . . . . . . . . . . . . . . . . 57
	9.2. Version 05 . . . . . . . . . . . . . . . . . . . . . . . 58		9.2. Version 05 . . . . . . . . . . . . . . . . . . . . . . . 57
	9.3. Version 06 . . . . . . . . . . . . . . . . . . . . . . . 58		9.3. Version 06 . . . . . . . . . . . . . . . . . . . . . . . 57
	9.4. Version 07 . . . . . . . . . . . . . . . . . . . . . . . 58		9.4. Version 07 . . . . . . . . . . . . . . . . . . . . . . . 58
	9.5. Version 08 . . . . . . . . . . . . . . . . . . . . . . . 59		9.5. Version 08 . . . . . . . . . . . . . . . . . . . . . . . 58
	9.6. Version 09 . . . . . . . . . . . . . . . . . . . . . . . 59		9.6. Version 09 . . . . . . . . . . . . . . . . . . . . . . . 58
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59		9.7. Version 10 . . . . . . . . . . . . . . . . . . . . . . . 58
			9.8. Version 11 . . . . . . . . . . . . . . . . . . . . . . . 58
			10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 59		11. Security Considerations . . . . . . . . . . . . . . . . . . . 59
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 60		12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 59
	12.1. Normative References . . . . . . . . . . . . . . . . . . 60		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 59
	12.2. Informative References . . . . . . . . . . . . . . . . . 61		13.1. Normative References . . . . . . . . . . . . . . . . . . 59
			13.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 10, line 5 ¶		skipping to change at page 9, line 44 ¶
	: | Registry |---------->| | . | ICANN TMCH-CA |		: | Registry |---------->| | . | ICANN TMCH-CA |
	: '-----------' . '---------' . '---------------'		: '-----------' . '---------' . '---------------'
	: ^ . . | :		: ^ . . | :
	: | ''''''''''''''''''' | :		: | ''''''''''''''''''' | :
	: | cy | :		: | cy | :
	: cr '-----------------------------------------' :		: cr '-----------------------------------------' :
	:......................................................:		:......................................................:
	Figure 1		Figure 1
			Figure 1 depicts the architecture of the Sunrise Period, including
			all the actors and interfaces.
	4.2. Trademark Claims Period		4.2. Trademark Claims Period
	Architecture of the Trademark Claims Period		Architecture of the Trademark Claims Period
	.''''''''''''''.		.''''''''''''''.
	. ICANN TMCH .		. ICANN TMCH .
	................		................
	. .		. .
	.------------. . .-------. . hv .-----.		.------------. . .-------. . hv .-----.
	| Registrant | . | TMV |<----------->| TMH |		| Registrant | . | TMV |<----------->| TMH |
	skipping to change at page 10, line 33 ¶		skipping to change at page 10, line 33 ¶
	ry | . | M | .		ry | . | M | .
	v . | D | .		v . | D | .
	.----------. dy . | B | .		.----------. dy . | B | .
	| Registry |<------->| | .		| Registry |<------->| | .
	'----------' yd . '-------' .		'----------' yd . '-------' .
	. .		. .
	''''''''''''''		''''''''''''''
	Figure 2		Figure 2
			Figure 2 depicts the architecture of the Trademark Claims Period,
			including all the actors and interfaces.
	4.3. Interfaces		4.3. Interfaces
	In the sub-sections below follows a short description of each		In the sub-sections below follows a short description of each
	interface to provide an overview of the architecture. More detailed		interface to provide an overview of the architecture. More detailed
	descriptions of the relevant interfaces follow further below		descriptions of the relevant interfaces follow further below
	(Section 5).		(Section 5).
	4.3.1. hv		4.3.1. hv
	The TMH registers a mark with a TMV via the hv interface.		The TMH registers a mark with a TMV via the hv interface.
	skipping to change at page 16, line 49 ¶		skipping to change at page 16, line 49 ¶
	|<----------------|| / ABORT | no '----------------------'		|<----------------|| / ABORT | no '----------------------'
	| |'-----------' | yes		| |'-----------' | yes
	| | |		| | |
	| | DN registered |		| | DN registered |
	| DN registered |<----------------------------|		| DN registered |<----------------------------|
	|<----------------| |		|<----------------| |
	| | |		| | |
	Figure 3		Figure 3
	Note: the figure depicted above represents a synchronous DN		Figure 3 represents a synchronous DN registration workflow (usually
	registration workflow (usually called first come first served).		called first come first served).
	5.2.2. Sunrise Domain Name registration by Registries		5.2.2. Sunrise Domain Name registration by Registries
	Registries MUST perform a minimum set of checks for verifying each DN		Registries MUST perform a minimum set of checks for verifying each DN
	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.
	skipping to change at page 18, line 45 ¶		skipping to change at page 18, line 45 ¶
	'----------------' |		'----------------' |
	| |		| |
	|----------------------------------------------------->|		|----------------------------------------------------->|
	| Download the latest SMD Revocation List |		| Download the latest SMD Revocation List |
	|<-----------------------------------------------------|		|<-----------------------------------------------------|
	| |		| |
	| |		| |
	Figure 4		Figure 4
			Figure 4 depicts the process of downloading the latest SMD Revocation
			List initiated by the Registry.
	5.2.3.2. TMV Certificate Revocation List (CRL)		5.2.3.2. TMV Certificate Revocation List (CRL)
	Registries MUST refresh their local copy of the TMV CRL file at least		Registries MUST refresh their local copy of the TMV CRL file at least
	every 24 hours using the CRL distribution point specified in the TMV		every 24 hours using the CRL distribution point specified in the TMV
	certificate.		certificate.
	Operationally, the TMV CRL file and CRL distribution point is the		Operationally, the TMV CRL file and CRL distribution point is the
	same for all TMVs and (at publication of this document) located at <		same for all TMVs and (at publication of this document) located at <
	http://crl.icann.org/tmch.crl >.		http://crl.icann.org/tmch.crl >.
	skipping to change at page 19, line 35 ¶		skipping to change at page 19, line 41 ¶
	'----------------' |		'----------------' |
	| |		| |
	|-------------------------------------------->|		|-------------------------------------------->|
	| Download the latest TMV CRL file |		| Download the latest TMV CRL file |
	|<--------------------------------------------|		|<--------------------------------------------|
	| |		| |
	| |		| |
	Figure 5		Figure 5
			Figure 5 depicts the process of downloading the latest TMV CRL file
			initiated by the Registry.
	5.2.3.3. Notice of Registered Domain Names (NORN)		5.2.3.3. Notice of Registered Domain Names (NORN)
	The Registry MUST send a LORDN file containing DNs effectively		The Registry MUST send a LORDN file containing DNs effectively
	allocated to the TMDB (over the yd interface, Section 4.3.7).		allocated to the TMDB (over the yd interface, Section 4.3.7).
	The effective allocation of a DN MUST be reported by the Registry to		The effective allocation of a DN MUST be reported by the Registry to
	the TMDB within 26 hours of the effective allocation of such DN.		the TMDB within 26 hours of the effective allocation of such DN.
	The Registry MUST create and upload a LORDN file in case there are		The Registry MUST create and upload a LORDN file in case there are
	effective allocations in the SRS, that have not been successfully		effective allocations in the SRS, that have not been successfully
	skipping to change at page 21, line 50 ¶		skipping to change at page 22, line 5 ¶
	| | no v | with said TMV | |		| | no v | with said TMV | |
	| .----------------. .------. |--------------->| |		| .----------------. .------. |--------------->| |
	'-| Correct Errors | | DONE | | | |		'-| Correct Errors | | DONE | | | |
	'----------------' '------' | | Notify each |		'----------------' '------' | | Notify each |
	| | | affected TMH |		| | | affected TMH |
	| | |-------------->|		| | |-------------->|
	| | | |		| | | |
	Figure 6		Figure 6
			Figure 6 depicts the process to notify the TMH of Registered Domain
			Names.
	The format used for the LORDN is described in Section 6.3		The format used for the LORDN is described in Section 6.3
	5.2.4. Sunrise Domain Name registration by Registrars		5.2.4. Sunrise Domain Name registration by Registrars
	Registrars MAY choose to perform the checks for verifying DN		Registrars MAY choose to perform the checks for verifying DN
	registrations as performed by the Registries (see Section 5.2.2)		registrations as performed by the Registries (see Section 5.2.2)
	before sending the command to register a DN.		before sending the command to register a DN.
	5.2.5. TMDB Sunrise Services for Registrars		5.2.5. TMDB Sunrise Services for Registrars
	skipping to change at page 24, line 5 ¶		skipping to change at page 24, line 5 ¶
	| Registration | Error .----------------------. |		| Registration | Error .----------------------. |
	| error |<-------------( Validation successful? ) |		| error |<-------------( Validation successful? ) |
	|<---------------| no '----------------------' |		|<---------------| no '----------------------' |
	| | | yes |		| | | yes |
	| | DN registered | |		| | DN registered | |
	| DN registered |<---------------------------| |		| DN registered |<---------------------------| |
	|<---------------| | |		|<---------------| | |
	Figure 7		Figure 7
	Note: the figure depicted above represents a synchronous DN		Figure 7 represents a synchronous DN registration workflow (usually
	registration workflow (usually called first come first served).		called first come first served).
	5.3.2. Trademark Claims Domain Name registration by Registries		5.3.2. Trademark Claims Domain Name registration by Registries
	During the Trademark Claims Period, Registries perform two main		During the Trademark Claims Period, Registries perform two main
	functions:		functions:
	o Registries MUST provide Registrars (over the ry interface,		o Registries MUST provide Registrars (over the ry interface,
	Section 4.3.5) the Lookup Key used to retrieve the TCNs for DNs		Section 4.3.5) the Lookup Key used to retrieve the TCNs for DNs
	that match the DNL List.		that match the DNL List.
	skipping to change at page 26, line 25 ¶		skipping to change at page 26, line 25 ¶
	'----------------' |		'----------------' |
	| |		| |
	|-------------------------------->|		|-------------------------------->|
	| Download the latest DNL List |		| Download the latest DNL List |
	|<--------------------------------|		|<--------------------------------|
	| |		| |
	| |		| |
	Figure 8		Figure 8
			Figure 8 depicts the process of downloading the latest DNL list
			initiated by the Registry.
	Note: the DNL List will be the same regardless of the TLD. If a		Note: the DNL List will be the same regardless of the TLD. If a
	Backend Registry Operator manages the infrastructure of several TLDs,		Backend Registry Operator manages the infrastructure of several TLDs,
	the Backend Registry Operator could refresh the DNL List once every		the Backend Registry Operator could refresh the DNL List once every
	24 hours, the DNL List could be used for all the TLDs managed by the		24 hours, the DNL List could be used for all the TLDs managed by the
	Backend Registry Operator.		Backend Registry Operator.
	5.3.3.2. Notice of Registered Domain Names (NORN)		5.3.3.2. Notice of Registered Domain Names (NORN)
	The NORDN process during the Trademark Claims Period is almost the		The NORDN process during the Trademark Claims Period is almost the
	same as during Sunrise Period as defined in Section 5.2.3.3 with the		same as during Sunrise Period as defined in Section 5.2.3.3 with the
	skipping to change at page 31, line 36 ¶		skipping to change at page 31, line 36 ¶
	'----------------' |		'----------------' |
	| |		| |
	|------------------------------->|		|------------------------------->|
	| Download the latest SURL |		| Download the latest SURL |
	|<-------------------------------|		|<-------------------------------|
	| |		| |
	| |		| |
	Figure 9		Figure 9
			Figure 9 depicts the process of downloading the latest SURL initiated
			by the Registry.
	Note: the SURL will be the same regardless of the TLD. If a Backend		Note: the SURL will be the same regardless of the TLD. If a Backend
	Registry Operator manages the infrastructure of several TLDs, the		Registry Operator manages the infrastructure of several TLDs, the
	Backend Registry Operator could refresh the SURL once every 24 hours,		Backend Registry Operator could refresh the SURL once every 24 hours,
	the SURL could be used for all the TLDs managed by the Backend		the SURL could be used for all the TLDs managed by the Backend
	Registry Operator.		Registry Operator.
	6. Data Format Descriptions		6. Data Format Descriptions
	6.1. Domain Name Label (DNL) List		6.1. Domain Name Label (DNL) List
	This section defines the format of the list containing every Domain		This section defines the format of the list containing every Domain
	Name Label (DNL) that matches a Pre-Registered Mark (PRM). The list		Name Label (DNL) that matches a Pre-Registered Mark (PRM). The list
	is maintained by the TMDB and downloaded by Registries in regular		is maintained by the TMDB and downloaded by Registries in regular
	intervals (see Section 5.3.3.1). The Registries use the DNL List		intervals (see Section 5.3.3.1). The Registries use the DNL List
	during the Trademark Claims Period to check whether a requested DN		during the Trademark Claims Period to check whether a requested DN
	matches a DNL of a PRM.		matches a DNL of a PRM.
	The DNL List contains all the DNLs covered by a PRM present in the		The DNL List contains all the DNLs covered by a PRM present in the
	skipping to change at page 33, line 16 ¶		skipping to change at page 33, line 22 ¶
	specified in [RFC4648].		specified in [RFC4648].
	- Sequential number: zero-padded natural number in the		- Sequential number: zero-padded natural number in the
	range 0000000001 to 2147483647.		range 0000000001 to 2147483647.
	+ <DNL insertion datetime>, datetime in UTC that the DNL was		+ <DNL insertion datetime>, datetime in UTC that the DNL was
	first inserted into the DNL List. The possible two values		first inserted into the DNL List. The possible two values
	of time for inserting a DNL to the DNL List are 00:00:00 and		of time for inserting a DNL to the DNL List are 00:00:00 and
	12:00:00 UTC.		12:00:00 UTC.
	Example of a DNL List		Example of a DNL List:
	1,2012-08-16T00:00:00.0Z		1,2012-08-16T00:00:00.0Z
	DNL,lookup-key,insertion-datetime		DNL,lookup-key,insertion-datetime
	example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\		example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\
	2010-07-14T00:00:00.0Z		2010-07-14T00:00:00.0Z
	another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\		another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\
	2012-08-16T00:00:00.0Z		2012-08-16T00:00:00.0Z
	anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\		anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\
	2011-08-16T12:00:00.0Z		2011-08-16T12:00:00.0Z
	Figure 10
	To provide authentication and integrity protection, the DNL List will		To provide authentication and integrity protection, the DNL List will
	be PGP [RFC4880] signed by the TMDB (see also Section 5.1.1.4). The		be PGP [RFC4880] signed by the TMDB (see also Section 5.1.1.4). The
	PGP signature of the DNL List can be found in the similar URI but		PGP signature of the DNL List can be found in the similar URI but
	with extension .sig as shown below.		with extension .sig as shown below.
	The URL of the dy interface (Section 4.3.3) is:		The URL of the dy interface (Section 4.3.3) is:
	o < https://<tmdb-domain-name>/dnl/dnl-latest.csv >		o < https://<tmdb-domain-name>/dnl/dnl-latest.csv >
	o < https://<tmdb-domain-name>/dnl/dnl-latest.sig >		o < https://<tmdb-domain-name>/dnl/dnl-latest.sig >
	skipping to change at page 35, line 4 ¶		skipping to change at page 35, line 4 ¶
	List is provided by the TMDB with extension .csv. The PGP signature		List is provided by the TMDB with extension .csv. The PGP signature
	of the SMD Revocation List can be found in the similar URI but with		of the SMD Revocation List can be found in the similar URI but with
	extension .sig as shown below.		extension .sig as shown below.
	The URL of the sr interface (Section 4.3.12) and sy interface		The URL of the sr interface (Section 4.3.12) and sy interface
	(Section 4.3.11) is:		(Section 4.3.11) is:
	o < https://<tmdb-domain-name>/smdrl/smdrl-latest.csv >		o < https://<tmdb-domain-name>/smdrl/smdrl-latest.csv >
	o < https://<tmdb-domain-name>/smdrl/smdrl-latest.sig >		o < https://<tmdb-domain-name>/smdrl/smdrl-latest.sig >
	Example of an SMD Revocation List		Example of an SMD Revocation List:
	1,2012-08-16T00:00:00.0Z		1,2012-08-16T00:00:00.0Z
	smd-id,insertion-datetime		smd-id,insertion-datetime
	2-2,2012-08-15T00:00:00.0Z		2-2,2012-08-15T00:00:00.0Z
	3-2,2012-08-15T00:00:00.0Z		3-2,2012-08-15T00:00:00.0Z
	1-2,2012-08-15T00:00:00.0Z		1-2,2012-08-15T00:00:00.0Z
	Figure 11
	6.3. List of Registered Domain Names (LORDN) file		6.3. List of Registered Domain Names (LORDN) file
	This section defines the format of the List of Registered Domain		This section defines the format of the List of Registered Domain
	Names (LORDN), which is maintained by each Registry and uploaded at		Names (LORDN), which is maintained by each Registry and uploaded at
	least daily to the TMDB. Every time a DN matching a DNL of a PRM		least daily to the TMDB. Every time a DN matching a DNL of a PRM
	said DN is added to the LORDN along with further information related		said DN is added to the LORDN along with further information related
	to its registration.		to its registration.
	The URIs of the yd interface (Section 4.3.7) used to upload the LORDN		The URIs of the yd interface (Section 4.3.7) used to upload the LORDN
	file is:		file is:
	skipping to change at page 38, line 8 ¶		skipping to change at page 38, line 5 ¶
	- <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
	<datetime of application creation> MUST be provided in		<datetime of application creation> MUST be provided in
	case of a DN effective allocation based on an		case of a DN effective allocation based on an
	asynchronous registration (e.g., when using auctions).		asynchronous registration (e.g., when using auctions).
	Example of a Sunrise LORDN file		Example of a Sunrise LORDN file:
	1,2012-08-16T00:00:00.0Z,3		1,2012-08-16T00:00:00.0Z,3
	roid,domain-name,SMD-id,registrar-id,registration-datetime,\		roid,domain-name,SMD-id,registrar-id,registration-datetime,\
	application-datetime		application-datetime
	SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\		SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\
	2012-07-15T00:50:00.0Z		2012-07-15T00:50:00.0Z
	EK77-REP,example2.gtld,2-2,9999,2012-08-15T14:00:03.0Z		EK77-REP,example2.gtld,2-2,9999,2012-08-15T14:00:03.0Z
	HB800-REP,example3.gtld,3-2,9999,2012-08-15T15:40:00.0Z		HB800-REP,example3.gtld,3-2,9999,2012-08-15T15:40:00.0Z
	Figure 12
	o For Trademark Claims Period:		o For Trademark Claims Period:
	* first line: <version>,<LORDN creation datetime>,<Number of DN		* first line: <version>,<LORDN creation datetime>,<Number of DN
	Lines>		Lines>
	Where:		Where:
	- <version>, version of the file, this field MUST be 1.		- <version>, version of the file, this field MUST be 1.
	- <LORDN creation datetime>, date and time in UTC that the		- <LORDN creation datetime>, date and time in UTC that the
	skipping to change at page 39, line 33 ¶		skipping to change at page 39, line 27 ¶
	asynchronous registration (e.g., when using auctions).		asynchronous registration (e.g., when using auctions).
	For a DN matching a DNL of a PRM at the moment of		For a DN matching a DNL of a PRM at the moment of
	registration, created without the TCNID, expiration datetime		registration, created without the TCNID, expiration datetime
	and acceptance datetime, because DNL was inserted (or re-		and acceptance datetime, because DNL was inserted (or re-
	inserted) for the first time into DNL List less than 24		inserted) for the first time into DNL List less than 24
	hours ago, the string "recent-dnl-insertion" MAY be		hours ago, the string "recent-dnl-insertion" MAY be
	specified in <TCNID> and <datetime of acceptance of the		specified in <TCNID> and <datetime of acceptance of the
	TCN>.		TCN>.
	Example of a Trademark Claims LORDN file		Example of a Trademark Claims LORDN file:
	1,2012-08-16T00:00:00.0Z,3		1,2012-08-16T00:00:00.0Z,3
	roid,domain-name,notice-id,registrar-id,registration-datetime,\		roid,domain-name,notice-id,registrar-id,registration-datetime,\
	ack-datetime,application-datetime		ack-datetime,application-datetime
	SH8013-REP,example1.gtld,a76716ed9223352036854775808,\		SH8013-REP,example1.gtld,a76716ed9223352036854775808,\
	9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z		9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z
	EK77-REP,example2.gtld,a7b786ed9223372036856775808,\		EK77-REP,example2.gtld,a7b786ed9223372036856775808,\
	9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z		9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z
	HB800-REP,example3.gtld,recent-dnl-insertion,\		HB800-REP,example3.gtld,recent-dnl-insertion,\
	9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion		9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion
	Figure 13
	6.3.1. LORDN Log file		6.3.1. LORDN Log file
	After reception of the LORDN file, the TMDB verifies its content for		After reception of the LORDN file, the TMDB verifies its content for
	syntactical and semantical correctness. The output of the LORDN file		syntactical and semantical correctness. The output of the LORDN file
	verification is retrieved using the yd interface (Section 4.3.7).		verification is retrieved using the yd interface (Section 4.3.7).
	The URI of the yd interface (Section 4.3.7) used to retrieve the		The URI of the yd interface (Section 4.3.7) used to retrieve the
	LORDN Log file is:		LORDN Log file is:
	o Sunrise LORDN Log file:		o Sunrise LORDN Log file:
	skipping to change at page 42, line 15 ¶		skipping to change at page 42, line 5 ¶
	roid,result-code		roid,result-code
	o One or more lines with: <roid>,<result code>		o One or more lines with: <roid>,<result code>
	Where:		Where:
	+ <roid>, DN Repository Object IDentifier (DNROID) in the SRS.		+ <roid>, DN Repository Object IDentifier (DNROID) in the SRS.
	+ <result code>, result code as described in Section 6.3.1.1.		+ <result code>, result code as described in Section 6.3.1.1.
	Example of a LORDN Log file		Example of a LORDN Log file:
	1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\		1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\
	0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\		0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\
	accepted,no-warnings,1		accepted,no-warnings,1
	roid,result-code		roid,result-code
	SH8013-REP,2000		SH8013-REP,2000
	Figure 14
	6.3.1.1. LORDN Log Result Codes		6.3.1.1. LORDN Log Result Codes
	In Figure 15 the classes of result codes (rc) are listed. Those		The classes of result codes (rc) are listed below. Those classes in
	classes in square brackets are not used at this time, but may come		square brackets are not used at this time, but may come into use at
	into use at some later stage. The first two digits of a result code		some later stage. The first two digits of a result code denote the
	denote the result code class, which defines the outcome at the TMDB:		result code class, which defines the outcome at the TMDB:
	o ok: Success, DN Line accepted by the TMDB.		o ok: Success, DN Line accepted by the TMDB.
	o warn: a warning is issued, DN Line accepted by the TMDB.		o warn: a warning is issued, DN Line accepted by the TMDB.
	o err: an error is issued, LORDN file rejected by the TMDB.		o err: an error is issued, LORDN file rejected by the TMDB.
	In case that after processing a DN Line, the error result code is		In case that after processing a DN Line, the error result code is
	45xx or 46xx for that DN Line, the LORDN file MUST be rejected by the		45xx or 46xx for that DN Line, the LORDN file MUST be rejected by the
	TMDB. If the LORDN file is rejected, DN Lines that are syntactically		TMDB. If the LORDN file is rejected, DN Lines that are syntactically
	valid will be reported with a 2001 result code. A 2001 result code		valid will be reported with a 2001 result code. A 2001 result code
	means that the DN Line is syntactically valid, however the DN Line		means that the DN Line is syntactically valid, however the DN Line
	was not processed because the LORDN file was rejected. All DNs		was not processed because the LORDN file was rejected. All DNs
	reported in a rejected LORDN file MUST be reported again by the		reported in a rejected LORDN file MUST be reported again by the
	Registry because none of the DN Lines present in the LORDN file have		Registry because none of the DN Lines present in the LORDN file have
	been processed by the TMDB.		been processed by the TMDB.
	LORDN Log Result Code Classes		LORDN Log Result Code Classes:
	code Class outcome		code Class outcome
	---- ----- -------		---- ----- -------
	20xx Success ok		20xx Success ok
	35xx [ DN Line syntax warning ] warn		35xx [ DN Line syntax warning ] warn
	36xx DN Line semantic warning warn		36xx DN Line semantic warning warn
	45xx DN Line syntax error err		45xx DN Line syntax error err
	46xx DN Line semantic error err		46xx DN Line semantic error err
	Figure 15
	In the following, the LORDN Log result codes used by the TMDB are		In the following, the LORDN Log result codes used by the TMDB are
	described:		described:
	LORDN Log result Codes		LORDN Log Result Codes:
	rc Short Description		rc Short Description
	Long Description		Long Description
	---- -------------------------------------------------------------		---- -------------------------------------------------------------
	2000 OK		2000 OK
	DN Line successfully processed.		DN Line successfully processed.
	2001 OK but not processed		2001 OK but not processed
	DN Line is syntactically correct but was not processed		DN Line is syntactically correct but was not processed
	skipping to change at page 46, line 6 ¶		skipping to change at page 45, line 37 ¶
	4609 TCNID wrong syntax		4609 TCNID wrong syntax
	The syntax of the TCNID is invalid.		The syntax of the TCNID is invalid.
	4610 TCN Acceptance Date is in the future		4610 TCN Acceptance Date is in the future
	The <datetime of acceptance of the TCN> is in the future.		The <datetime of acceptance of the TCN> is in the future.
	4611 Label has never existed in the TMDB		4611 Label has never existed in the TMDB
	The label in the registered DN has never existed in the TMDB.		The label in the registered DN has never existed in the TMDB.
	Figure 16
	6.4. Signed Mark Data (SMD) File		6.4. Signed Mark Data (SMD) File
	This section defines the format of the Signed Mark Data (SMD) File.		This section defines the format of the Signed Mark Data (SMD) File.
	After a successful registration of a mark, the TMV returns an SMD		After a successful registration of a mark, the TMV returns an SMD
	File to the TMH. The SMD File can then be used for registration of		File to the TMH. The SMD File can then be used for registration of
	one or more DNs covered by the PRM during the Sunrise Period of a		one or more DNs covered by the PRM during the Sunrise Period of a
	TLD.		TLD.
	Two encapsulation boundaries are defined for delimiting the		Two encapsulation boundaries are defined for delimiting the
	encapsulated base64 encoded SMD: i.e. "-----BEGIN ENCODED SMD-----"		encapsulated base64 encoded SMD: i.e. "-----BEGIN ENCODED SMD-----"
	skipping to change at page 47, line 18 ¶		skipping to change at page 46, line 39 ¶
	U-labels: example-one, exampleone		U-labels: example-one, exampleone
	notBefore: 2011-08-16 09:00		notBefore: 2011-08-16 09:00
	notAfter: 2012-08-16 09:00		notAfter: 2012-08-16 09:00
	-----BEGIN ENCODED SMD-----		-----BEGIN ENCODED SMD-----
	PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu		PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu
	ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN		ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN
	... (base64 data elided for brevity) ...		... (base64 data elided for brevity) ...
	dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo=		dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo=
	-----END ENCODED SMD-----		-----END ENCODED SMD-----
	Figure 17
	6.5. Trademark Claims Notice (TCN)		6.5. Trademark Claims Notice (TCN)
	The TMDB MUST provide the TCN to Registrars in XML format as		The TMDB MUST provide the TCN to Registrars in XML format as
	specified below.		specified below.
	An enclosing element <tmNotice:notice> that describes the Trademark		An enclosing element <tmNotice:notice> that describes the Trademark
	Notice to a given label.		Notice to a given label.
	The child elements of the <tmNotice:notice> element include:		The child elements of the <tmNotice:notice> element include:
	skipping to change at page 55, line 5 ¶		skipping to change at page 54, line 19 ¶
	Where:		Where:
	+ <DNL>, a Domain Name Label covered by a PRM eligible for		+ <DNL>, a Domain Name Label covered by a PRM eligible for
	Sunrise.		Sunrise.
	+ <DNL insertion datetime>, datetime in UTC that the DNL was		+ <DNL insertion datetime>, datetime in UTC that the DNL was
	first inserted into the Sunrise List. The possible two		first inserted into the Sunrise List. The possible two
	values of time for inserting a DNL to the Sunrise List are		values of time for inserting a DNL to the Sunrise List are
	00:00:00 and 12:00:00 UTC.		00:00:00 and 12:00:00 UTC.
	Example of a SURL		Example of a Sunrise List:
	1,2012-08-16T00:00:00.0Z		1,2012-08-16T00:00:00.0Z
	DNL,insertion-datetime		DNL,insertion-datetime
	example,2010-07-14T00:00:00.0Z		example,2010-07-14T00:00:00.0Z
	another-example,2012-08-16T00:00:00.0Z		another-example,2012-08-16T00:00:00.0Z
	anotherexample,2011-08-16T12:00:00.0Z		anotherexample,2011-08-16T12:00:00.0Z
	Figure 18
	To provide authentication and integrity protection, the Sunrise List		To provide authentication and integrity protection, the Sunrise List
	will be PGP signed by the TMDB (see also Section 5.1.1.4). The PGP		will be PGP signed by the TMDB (see also Section 5.1.1.4). The PGP
	signature of the Sunrise List can be found in the similar URI but		signature of the Sunrise List can be found in the similar URI but
	with extension .sig as shown below.		with extension .sig as shown below.
	The URL of the dy interface (Section 4.3.3) is:		The URL of the dy interface (Section 4.3.3) is:
	o < https://<tmdb-domain-name>/dnl/surl-latest.csv >		o < https://<tmdb-domain-name>/dnl/surl-latest.csv >
	o < https://<tmdb-domain-name>/dnl/surl-latest.sig >		o < https://<tmdb-domain-name>/dnl/surl-latest.sig >
	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 CODE BEGINS and CODE ENDS tags are not part of the schema; they
	note the beginning and ending of the schema for URI registration		are used to note the beginning and ending of the schema for URI
	purposes.		registration purposes.
	<CODE BEGINS>		<CODE BEGINS>
	<?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"		xmlns="http://www.w3.org/2001/XMLSchema"
	elementFormDefault="qualified">		elementFormDefault="qualified">
	<annotation>		<annotation>
	skipping to change at page 59, line 13 ¶		skipping to change at page 58, line 26 ¶
	MdOhSomd6_djLcthfw5mxWZkbWY		MdOhSomd6_djLcthfw5mxWZkbWY
	9.5. Version 08		9.5. Version 08
	1. Fixed issues detected by idnits tool.		1. Fixed issues detected by idnits tool.
	9.6. Version 09		9.6. Version 09
	1. Ping update.		1. Ping update.
			9.7. Version 10
			1. Ping update.
			9.8. Version 11
			1. Editorial updates.
			2. Added Privacy section.
	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]. Two URI		conforming to a registry mechanism described in [RFC3688]. IANA is
	assignments have been registered by the IANA.		requested to register two URI assignments.
	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: IETF <regext@ietf.org>		Registrant Contact: IETF <regext@ietf.org>
	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:
	skipping to change at page 59, line 51 ¶		skipping to change at page 59, line 24 ¶
	are allowed to connect to the interfaces described in this document,		are allowed to connect to the interfaces described in this document,
	providing an extra security measure.		providing an extra security measure.
	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 [RFC7525] or its successors.
	12. References		12. Privacy Considerations
	12.1. Normative References		This specification defines the interfaces to support the
			[RPM-Requirements]. Legal documents govern the interactions between
			the different parties, and such legal documents must ensure that
			privacy-sensitive and/or personal data receives the required
			protection.
			13. References
			13.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", July		ICANN, "Memorandum on Implementing Matching Rules", July
	2016, <https://newgtlds.icann.org/en/about/trademark-		2016, <https://newgtlds.icann.org/en/about/trademark-
	skipping to change at page 60, line 35 ¶		skipping to change at page 60, line 20 ¶
	[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>.
			[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
			"Recommendations for Secure Use of Transport Layer
			Security (TLS) and Datagram Transport Layer Security
			(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
			2015, <https://www.rfc-editor.org/info/rfc7525>.
	[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		[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",
	skipping to change at page 61, line 16 ¶		skipping to change at page 61, line 10 ¶
	Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,		Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
	"XML Schema Part 1: Structures Second Edition REC-		"XML Schema Part 1: Structures Second Edition REC-
	xmlschema-1-20041028", October 2004,		xmlschema-1-20041028", October 2004,
	<https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/>.		<https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/>.
	[W3C.REC-xmlschema-2-20041028]		[W3C.REC-xmlschema-2-20041028]
	Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes		Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
	Second Edition REC-xmlschema-2-20041028", October 2004,		Second Edition REC-xmlschema-2-20041028", October 2004,
	<https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.		<https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.
	12.2. Informative References		13.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,
	<http://www.iso.org/iso/home/standards/country_codes.htm>.		<http://www.iso.org/iso/home/standards/country_codes.htm>.
End of changes. 46 change blocks.
	69 lines changed or deleted		97 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/