draft-ietf-regext-tmch-func-spec-01.txt		draft-ietf-regext-tmch-func-spec-02.txt
	Internet Engineering Task Force G. Lozano		Internet Engineering Task Force G. Lozano
	Internet-Draft ICANN		Internet-Draft ICANN
	Intended status: Standards Track June 8, 2016		Intended status: Informational October 3, 2016
	Expires: December 10, 2016		Expires: April 6, 2017
	ICANN TMCH functional specifications		ICANN TMCH functional specifications
	draft-ietf-regext-tmch-func-spec-01		draft-ietf-regext-tmch-func-spec-02
	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 December 10, 2016.		This Internet-Draft will expire on April 6, 2017.
	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 3, line 29 ¶		skipping to change at page 3, line 29 ¶
	6.3. List of Registered Domain Names (LORDN) file . . . . . . 34		6.3. List of Registered Domain Names (LORDN) file . . . . . . 34
	6.3.1. LORDN Log file . . . . . . . . . . . . . . . . . . . 39		6.3.1. LORDN Log file . . . . . . . . . . . . . . . . . . . 39
	6.3.1.1. LORDN Log Result Codes . . . . . . . . . . . . . 41		6.3.1.1. LORDN Log Result Codes . . . . . . . . . . . . . 41
	6.4. Signed Mark Data (SMD) File . . . . . . . . . . . . . . . 45		6.4. Signed Mark Data (SMD) File . . . . . . . . . . . . . . . 45
	6.5. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 46		6.5. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 46
	6.6. Sunrise List (SURL) . . . . . . . . . . . . . . . . . . . 53		6.6. Sunrise List (SURL) . . . . . . . . . . . . . . . . . . . 53
	7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 54		7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 54
	7.1. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 54		7.1. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 54
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 57		10. Security Considerations . . . . . . . . . . . . . . . . . . . 58
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 58		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 58
	11.1. Normative References . . . . . . . . . . . . . . . . . . 58		11.1. Normative References . . . . . . . . . . . . . . . . . . 58
	11.2. Informative References . . . . . . . . . . . . . . . . . 58		11.2. Informative References . . . . . . . . . . . . . . . . . 59
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 60		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 60
	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 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]. In case of IDNs, the A-label form MUST be used, i.e.		[RFC7719].
	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]. The		o DNL, Domain Name Label, the DNL is an A-label or NR-LDH label (see
	DNL is an A-label or NR-LDH.		[RFC5890]).
	o DNL List: A list of DNLs that are covered by a PRM.		o DNL List: A list of DNLs that are covered by a PRM.
	o DNS: Domain Name System, see [RFC7719].		o DNS: Domain Name System, see [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
	effective allocation. A DN object created internally by the		effective allocation. A DN object created internally by the
	Registry for subsequent delegation to another Registrant is not		Registry for subsequent delegation to another Registrant is not
	considered an effective allocation.		considered an effective allocation.
	o EPP: The Extensible Provisioning Protocol, see definition of EPP		o EPP: The Extensible Provisioning Protocol, see definition of EPP
	in [RFC7719].		in [RFC7719].
	o FQDN: Fully-Qualified Domain Name, see definition of FQDN in		o FQDN: Fully-Qualified Domain Name, see definition of FQDN in
	[RFC7719].		[RFC7719].
	o HTTP: Hypertext Transfer Protocol, see [RFC2616]		o HTTP: Hypertext Transfer Protocol, see [RFC7230] and [RFC7231].
	o HTTPS: HTTP over TLS (Transport Layer Security), [RFC2818].		o HTTPS: HTTP over TLS (Transport Layer Security), [RFC2818].
	o IDN: Internationalized Domain Name, see definition of IDN in		o IDN: Internationalized Domain Name, see definition of IDN in
	[RFC7719].		[RFC7719].
	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.
	skipping to change at page 6, line 47 ¶		skipping to change at page 6, line 44 ¶
	o Registrar, Domain Name Registrar: see definition of Registrar in		o Registrar, Domain Name Registrar: see definition of Registrar in
	[RFC7719].		[RFC7719].
	o Registry, Domain Name Registry, Registry Operator: see definition		o Registry, Domain Name Registry, Registry Operator: see definition
	of Registry in [RFC7719]. A Registry Operator is the contracting		of Registry in [RFC7719]. A Registry Operator is the contracting
	party with ICANN for the TLD.		party with ICANN for the TLD.
	o SMD, Signed Mark Data: A cryptographically signed token issued by		o SMD, Signed Mark Data: A cryptographically signed token issued by
	the TMV to the TMH to be used in the Sunrise Period to apply for a		the TMV to the TMH to be used in the Sunrise Period to apply for a
	DN that matches a DNL of a PRM; see also		DN that matches a DNL of a PRM; see also [RFC7848]. An SMD
	[I-D.ietf-eppext-tmch-smd]. An SMD generated by an ICANN-approved		generated by an ICANN-approved trademark validator (TMV) contains
	trademark validator (TMV) contains both the signed token and the		both the signed token and the TMV's PKIX certificate.
	TMV's PKIX certificate.
	o SMD File: A file containing the SMD (see above) and some human		o SMD File: A file containing the SMD (see above) and some human
	readable data. The latter is usually ignored in the processing of		readable data. The latter is usually ignored in the processing of
	the SMD File. See also Section 6.4.		the SMD File. See also Section 6.4.
	o SMD Revocation List: The SMD Revocation List is used by Registries		o SMD Revocation List: The SMD Revocation List is used by Registries
	(and optionally by Registrars) during the Sunrise Period to ensure		(and optionally by Registrars) during the Sunrise Period to ensure
	that an SMD is still valid (i.e. not revoked). The SMD Revocation		that an SMD is still valid (i.e. not revoked). The SMD Revocation
	List has a similar function as CRLs used in PKI.		List has a similar function as CRLs used in PKI.
	skipping to change at page 14, line 22 ¶		skipping to change at page 14, line 22 ¶
	o Fetch the SMD Revocation List via the sy interface		o Fetch the SMD Revocation List via the sy interface
	(Section 4.3.11).		(Section 4.3.11).
	o Fetch the DNL List from the TMDB via the dy interface		o Fetch the DNL List from the TMDB via the dy interface
	(Section 4.3.3).		(Section 4.3.3).
	o Upload the LORDN to the TMDB via the yd interface (Section 4.3.7).		o Upload the LORDN to the TMDB via the yd interface (Section 4.3.7).
	This access restriction MAY be applied by the TMDB in addition to		This access restriction MAY be applied by the TMDB in addition to
	HTTP Basic access authentication (for credentials to be used, see		HTTP Basic access authentication (see [RFC7235]). For credentials to
	Section 5.1.1.1).		be used, see Section 5.1.1.1.
	The TMDB MAY limit the number of IP addresses to be accepted per		The TMDB MAY limit the number of IP addresses to be accepted per
	Registry Operator.		Registry Operator.
	5.1.1.3. ICANN TMCH Trust Anchor		5.1.1.3. ICANN TMCH Trust Anchor
	Each Registry Operator MUST fetch the PKIX certificate ([RFC5280]) of		Each Registry Operator MUST fetch the PKIX certificate ([RFC5280]) of
	the ICANN TMCH-CA (Trust Anchor) from < https://ca.icann.org/		the ICANN TMCH-CA (Trust Anchor) from < https://ca.icann.org/
	tmch.crt > to be used:		tmch.crt > to be used:
	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 of the DN (A-label form in the case of IDNs)		8. The leftmost DNL of the DN being effectively allocated matches
	being effectively allocated matches one of the labels		one of the labels (<mark:label>) elements in the SMD. For
	(<mark:label>) elements in the SMD. For example, if the DN "xn--		example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being
	mgbachtv.xn--mgbh0fb" is being effectively allocated, the		effectively allocated, the leftmost DNL would be "xn--mgbachtv".
	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 25, line 6 ¶		skipping to change at page 25, line 6 ¶
	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.		or a different value defined by ICANN policy.
	4. Using the leftmost DNL of the DN (A-label form in the case of		4. Using the leftmost DNL of the DN being effectively allocated,
	IDNs) being effectively allocated, the expiration datetime		the expiration datetime provided by the Registrar, and the
	provided by the Registrar, and the TMDB Notice Identifier		TMDB Notice Identifier extracted from the TCNID provided by
	extracted from the TCNID provided by the Registrar compute the		the Registrar compute the TCN Checksum. Verify that the
	TCN Checksum. Verify that the computed TCN Checksum match the		computed TCN Checksum match the TCN Checksum present in the
	TCN Checksum present in the TCNID. For example, if the DN		TCNID. For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is
	"xn--mgbachtv.xn--mgbh0fb" is being effectively allocated, the		being effectively allocated, the leftmost DNL would be "xn--
	leftmost DNL would be "xn--mgbachtv".		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 48 ¶		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 of the DN (A-label form in the case of IDNs)		2. The leftmost DNL of the DN being effectively allocated
	being effectively allocated matches the label		matches the label (<tmNotice:label>) element in the TCN. For
	(<tmNotice:label>) element in the TCN. For example, if the		example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being
	DN "xn--mgbachtv.xn--mgbh0fb" is being effectively allocated,		effectively allocated, the leftmost DNL would be "xn--
	the leftmost DNL would be "xn--mgbachtv".		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.
	TCNs 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 (or a		(<tmNotice:notAfter>) of each TCN MUST be set to 48 hours (or a
	different value if defined by policy) in the future by the TMDB,		different value if defined by ICANN policy) in the future by the
	allowing the implementation of a cache by Registrars and enough time		TMDB, allowing the implementation of a cache by Registrars and enough
	for acknowledging the TCN. Registrars SHOULD implement a cache of		time for acknowledging the TCN. Registrars SHOULD implement a cache
	TCNs to minimize the number of queries sent to the TMDB. A cached		of TCNs to minimize the number of queries sent to the TMDB. A cached
	TCN MUST be removed from the cache after the expiration date of the		TCN MUST be removed from the cache after the expiration date of the
	TCN as defined by <tmNotice:notAfter>. The TMDB MAY implement rate-		TCN as defined by <tmNotice:notAfter>. The TMDB MAY implement rate-
	limiting as one of the protection mechanisms to mitigate the risk of		limiting as one of the protection mechanisms to mitigate the risk of
	performance degradation.		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
	skipping to change at page 28, line 30 ¶		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 of the DN (A-label form in the case of IDNs)		o If the leftmost DNL of the DN being effectively allocated (QLP
	being effectively allocated (QLP Name in this section) matches a		Name in this section) matches a DNL in the SURL, and an SMD is
	DNL in the SURL, and an SMD is provided, then Registries MUST		provided, then Registries MUST provide Sunrise Services (see
	provide Sunrise Services (see Section 5.2) and the DN MUST be		Section 5.2) and the DN MUST be reported in a Sunrise LORDN file
	reported in a Sunrise LORDN file during the QLP Period. For		during the QLP Period. For example, if the DN "xn--mgbachtv.xn--
	example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being effectively		mgbh0fb" is being effectively allocated, the leftmost DNL would be
	allocated, the leftmost DNL would be "xn--mgbachtv".		"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 form 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 form 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 29 ¶		skipping to change at page 45, line 29 ¶
	purposes, i.e. any data outside these boundaries as well as the		purposes, i.e. any data outside these boundaries as well as the
	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 U-label or NR-LDH labels (see
	[RFC5890]) form (i.e., U-labels or NR-LDH as the case may be)>		[RFC5890])>
	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 [RFC7848])>
	8. -----END ENCODED SMD-----		8. -----END ENCODED SMD-----
	Example of an SMD File:		Example of an SMD File:
	Marks: Example One		Marks: Example One
	smdID: 1-2		smdID: 1-2
	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-----
	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 of the DN (A-label form in		A Registry MUST use the leftmost DNL of the DN being
	the case of IDNs) being effectively allocated, the expiration		effectively allocated, the expiration datetime of the TCN
	datetime of the TCN (provided by the Registrar) and the TMDB		(provided by the Registrar) and the TMDB Notice Identifier
	Notice Identifier extracted from the TCNID (provided by the		extracted from the TCNID (provided by the Registrar) to compute
	Registrar) to compute the TCN Checksum. For example, if the DN		the TCN Checksum. For example, if the DN "xn--mgbachtv.xn--
	"xn--mgbachtv.xn--mgbh0fb" is being effectively allocated, the		mgbh0fb" is being effectively allocated, the leftmost DNL would
	leftmost DNL would be "xn--mgbachtv".		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.
	skipping to change at page 57, line 35 ¶		skipping to change at page 57, line 35 ¶
	provided by James Gould, James Mitchell and Francisco Arias. This		provided by James Gould, James Mitchell and Francisco Arias. This
	document includes feedback received from the following individuals:		document includes feedback received from the following individuals:
	Paul Hoffman.		Paul Hoffman.
	9. IANA Considerations		9. IANA Considerations
	This document uses URNs to describe XML namespaces and XML schemas		This document uses URNs to describe XML namespaces and XML schemas
	conforming to a registry mechanism described in [RFC3688]. One URI		conforming to a registry mechanism described in [RFC3688]. One URI
	assignment have been registered by the IANA.		assignment have been registered by the IANA.
	Registration request for the Trademark Claims Notice:		Registration request for the Trademark Claims Notice namespace:
	URI: urn:ietf:params:xml:ns:tmNotice-1.0		URI: urn:ietf:params:xml:ns:tmNotice-1.0
	Registrant Contact: See the "Author's Address" section of this		Registrant Contact: See the "Author's Address" section of this
	document.		document.
	XML: None. Namespace URIs do not represent an XML specification.		XML: None. Namespace URIs do not represent an XML specification.
			Registration request for the Trademark Claims Notice XML schema:
			URI: urn:ietf:params:xml:ns:tmNotice-1.0
			Registrant Contact: See the "Author's Address" section of this
			document.
			XML: See Section 7.1 of this document.
	10. Security Considerations		10. Security Considerations
	This specification uses HTTP Basic Authentication to provide a simple		This specification uses HTTP Basic Authentication to provide a simple
	application-layer authentication service. HTTPS is used in all		application-layer authentication service. HTTPS is used in all
	interfaces in order to protect against most common attacks. In		interfaces in order to protect against most common attacks. In
	addition, the client identifier is tied to a set of IP addresses that		addition, the client identifier is tied to a set of IP addresses that
	are allowed to connect to the interfaces described in this document,		are allowed to connect to the interfaces described in this document,
	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
	skipping to change at page 58, line 20 ¶		skipping to change at page 58, line 29 ¶
	The TMDB MUST require the use of strong passwords by Registries and		The TMDB MUST require the use of strong passwords by Registries and
	Registrars.		Registrars.
	The TMDB, Registries and Registrars MUST use the best practices		The TMDB, Registries and Registrars MUST use the best practices
	described in RFC 7525 or its successors.		described in RFC 7525 or its successors.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ietf-eppext-tmch-smd]		[Claims50]
	Lozano, G., "Mark and Signed Mark Objects Mapping", draft-		ICANN, "Implementation Notes: Trademark Claims Protection
	ietf-eppext-tmch-smd-06 (work in progress), March 2016.		for Previously Abused Names", July 2013,
			<https://newgtlds.icann.org/en/about/trademark-
			clearinghouse/previously-abused-16jul13-en.pdf>.
	[MatchingRules]		[MatchingRules]
	ICANN, "Memorandum on Implementing Matching Rules",		ICANN, "Memorandum on Implementing Matching Rules",
	September 2012, <https://newgtlds.icann.org/en/about/		September 2012, <https://newgtlds.icann.org/en/about/
	trademark-clearinghouse/matching-rules-24sep12-en.pdf>.		trademark-clearinghouse/matching-rules-24sep12-en.pdf>.
			[QLP-Addendum]
			ICANN, "Qualified Launch Program Addendum", April 2014,
			<https://newgtlds.icann.org/en/about/trademark-
			clearinghouse/rpm-requirements-qlp-addendum-
			10apr14-en.pdf>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<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		[RFC7848] Lozano, G., "Mark and Signed Mark Objects Mapping",
			RFC 7848, DOI 10.17487/RFC7848, June 2016,
			<http://www.rfc-editor.org/info/rfc7848>.
	[Claims50]		[RPM-Requirements]
	ICANN, "Implementation Notes: Trademark Claims Protection		ICANN, "Rights Protection Mechanism Requirements",
	for Previously Abused Names", July 2013,		September 2013, <https://newgtlds.icann.org/en/about/
	<https://newgtlds.icann.org/en/about/trademark-		trademark-clearinghouse/rpm-requirements-30sep13-en.pdf>.
	clearinghouse/previously-abused-16jul13-en.pdf>.
			11.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>.
	[QLP-Addendum]
	ICANN, "Qualified Launch Program Addendum", April 2014,
	<https://newgtlds.icann.org/en/about/trademark-
	clearinghouse/rpm-requirements-qlp-addendum-
	10apr14-en.pdf>.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616,
	DOI 10.17487/RFC2616, June 1999,
	<http://www.rfc-editor.org/info/rfc2616>.
	[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
	Leach, P., Luotonen, A., and L. Stewart, "HTTP
	Authentication: Basic and Digest Access Authentication",
	RFC 2617, DOI 10.17487/RFC2617, June 1999,
	<http://www.rfc-editor.org/info/rfc2617>.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
	DOI 10.17487/RFC2818, May 2000,		DOI 10.17487/RFC2818, May 2000,
	<http://www.rfc-editor.org/info/rfc2818>.		<http://www.rfc-editor.org/info/rfc2818>.
	[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:		[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
	Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,		Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
	<http://www.rfc-editor.org/info/rfc3339>.		<http://www.rfc-editor.org/info/rfc3339>.
	[RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma-		[RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma-
	Separated Values (CSV) Files", RFC 4180,		Separated Values (CSV) Files", RFC 4180,
	skipping to change at page 60, line 16 ¶		skipping to change at page 60, line 16 ¶
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<http://www.rfc-editor.org/info/rfc5280>.		<http://www.rfc-editor.org/info/rfc5280>.
	[RFC5890] Klensin, J., "Internationalized Domain Names for		[RFC5890] Klensin, J., "Internationalized Domain Names for
	Applications (IDNA): Definitions and Document Framework",		Applications (IDNA): Definitions and Document Framework",
	RFC 5890, DOI 10.17487/RFC5890, August 2010,		RFC 5890, DOI 10.17487/RFC5890, August 2010,
	<http://www.rfc-editor.org/info/rfc5890>.		<http://www.rfc-editor.org/info/rfc5890>.
			[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
			Protocol (HTTP/1.1): Message Syntax and Routing",
			RFC 7230, DOI 10.17487/RFC7230, June 2014,
			<http://www.rfc-editor.org/info/rfc7230>.
			[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
			Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
			DOI 10.17487/RFC7231, June 2014,
			<http://www.rfc-editor.org/info/rfc7231>.
			[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
			Protocol (HTTP/1.1): Authentication", RFC 7235,
			DOI 10.17487/RFC7235, June 2014,
			<http://www.rfc-editor.org/info/rfc7235>.
	[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS		[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Terminology", RFC 7719, DOI 10.17487/RFC7719, December		Terminology", RFC 7719, DOI 10.17487/RFC7719, December
	2015, <http://www.rfc-editor.org/info/rfc7719>.		2015, <http://www.rfc-editor.org/info/rfc7719>.
	[RPM-Requirements]
	ICANN, "Rights Protection Mechanism Requirements",
	September 2013, <https://newgtlds.icann.org/en/about/
	trademark-clearinghouse/rpm-requirements-30sep13-en.pdf>.
	[WIPO-NICE-CLASSES]		[WIPO-NICE-CLASSES]
	WIPO, "WIPO Nice Classification", 2015,		WIPO, "WIPO Nice Classification", 2015,
	<http://www.wipo.int/classifications/nice/en>.		<http://www.wipo.int/classifications/nice/en>.
	[WIPO.ST3]		[WIPO.ST3]
	WIPO, "Recommended standard on two-letter codes for the		WIPO, "Recommended standard on two-letter codes for the
	representation of states, other entities and		representation of states, other entities and
	intergovernmental organizations", March 2007,		intergovernmental organizations", March 2007,
	<http://www.iso.org/iso/home/standards/country_codes.htm>.		<http://www.iso.org/iso/home/standards/country_codes.htm>.
End of changes. 30 change blocks.
	92 lines changed or deleted		101 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/