• Sunrise Period: The Sunrise Period allows Trademark Holders an advance opportunity to register domain names corresponding to their marks before names are generally available to the public.
• Trademark Claims Period: The Trademark Claims Period follows the Sunrise Period and runs for at least the first 90 days of an initial operating period of general registration. During the Trademark Claims Period, anyone attempting to register a domain name matching a mark that is recorded in the ICANN Trademark Clearinghouse (TMCH) will receive a notification displaying the relevant mark information.

Backend Registry Operator:

An entity that manages (a part of) the technical infrastructure for a Registry Operator. The Registry Operator may also be the Backend Registry Operator.

CA:

Certification Authority. See [RFC 5280].

CNIS:

Claims Notice Information Service. This service provides Trademark Claims Notices (TCNs) to Registrars.

CRC32:

Cyclic Redundancy Check. This algorithm is used in the ISO 3309 standard and in Section 8.1.1.6.2 of ITU-T recommendation V.42.

CRL:

Certificate Revocation List. See [RFC 5280].

CSV:

Comma-Separated Values. See [RFC 4180].

datetime:

Date and time. The date and time are specified following the standard specification "Date and Time on the Internet: Timestamps". See [RFC 3339].

DN:

Domain Name. See [RFC 8499].

DNL:

Domain Name Label. The DNL is an A-label or a Non-Reserved LDH (NR-LDH) label. See [RFC 5890].

DNL List:

A list of DNLs that are covered by a PRM.

DNROID:

DN Repository Object IDentifier. This identifier is assigned by the Registry to each DN object that unequivocally identifies said 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 DNROIDs.

DNS:

Domain Name System. See [RFC 8499].

Effective Allocation:

A DN is considered effectively allocated 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 in status "pendingCreate" or any other status that precedes the first time a DN is assigned to an end user is not considered an effective allocation. A DN object created internally by the Registry for subsequent delegation to another Registrant is not considered an effective allocation.

EPP:

Extensible Provisioning Protocol. See [RFC 8499].

FQDN:

Fully Qualified Domain Name. See [RFC 8499].

HTTP:

Hypertext Transfer Protocol. See [RFC 9110].

HTTPS:

HTTP over TLS (Transport Layer Security). See [RFC 9110].

ICANN TMCH:

A central repository for information to be authenticated, stored, and disseminated, pertaining to the rights of TMHs. The ICANN TMCH is split into two functions: TMV and TMDB (see below). There could be several entities performing the TMV function but only one entity performing the TMDB function.

ICANN TMCH-CA:

The Certification Authority (CA) for the ICANN TMCH. This CA is operated by ICANN. The public key for this CA is the trust anchor used to validate the identity of each TMV.

IDN:

Internationalized Domain Name. See [RFC 8499].

Lookup Key:

A random string of up to 51 characters from the set [a-zA-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 DNL only.

LORDN:

List of Registered Domain Names. This is the list of effectively allocated DNs matching a DNL of a PRM. Registries will upload this list to the TMDB (during the NORDN process).

Matching Rules:

Some trademarks entitled to inclusion in the TMDB include characters that are impermissible in the 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.

NORDN:

Notification of Registered Domain Names. This is the process by which Registries upload their recent LORDN to the TMDB.

PGP:

Pretty Good Privacy. See [RFC 4880].

PKI:

Public Key Infrastructure. See [RFC 5280].

PRM:

Pre-Registered Mark. A mark that has been pre-registered with the ICANN TMCH.

QLP Period:

Qualified Launch Program Period. During this optional period, a special process applies to DNs matching the Sunrise List (SURL) and/or the DNL List to ensure that TMHs are informed of a DN matching their PRM.

Registrant:

See the definition of Registrant in [RFC 8499].

Registrar:

Domain Name Registrar. See [RFC 8499].

Registry:

Domain Name Registry, Registry Operator. See [RFC 8499]. A Registry Operator is the contracting party with ICANN for the TLD.

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 DN that matches a DNL of a PRM. See [RFC 7848]. An SMD generated by an ICANN-approved Trademark Validator (TMV) contains both the signed token and the TMV's PKIX certificate.

SMD File:

A file containing the SMD (see above) and some human-readable data. The latter is usually ignored in the processing of the SMD File. See Section 6.4.

SMD Revocation List:

The SMD Revocation List is used by Registries (and optionally by Registrars) during the Sunrise Period to ensure that an SMD is still valid (i.e., not revoked). The SMD Revocation List has a similar function as CRLs used in PKI.

SRS:

Shared Registration System. See [ICANN-GTLD-AGB-20120604].

Sunrise Period:

During this period, DNs matching a DNL of a PRM can be exclusively obtained by the respective TMHs. For DNs matching a PRM, a special process applies to ensure that TMHs are informed on the effective allocation of a DN matching their PRM.

SURL:

Sunrise List. The list of DNLs that are covered by a PRM and are eligible for Sunrise.

TCN:

Trademark Claims Notice, Claims Notice, Trademark Notice. A Trademark Claims Notice consists of one or more Trademark Claims and is provided to prospective Registrants of DNs.

TCNID:

Trademark Claims Notice Identifier. An element of the Trademark Claims Notice (see above), identifying said TCN. The Trademark Claims Notice Identifier is specified in the element <tmNotice:id>.

TLD:

Top-Level Domain Name. See [RFC 8499].

TMDB:

Trademark Clearinghouse Database. This serves as a database of the ICANN TMCH to provide information to the gTLD Registries and Registrars to support Sunrise or Trademark Claims services. There is only one TMDB in the ICANN TMCH that concentrates the information about the "verified" trademark records from the TMVs.

TMH:

Trademark Holder. The person or organization owning rights on a mark.

TMV:

Trademark Validator, Trademark Validation organization. An entity authorized by ICANN to authenticate and validate registrations in the TMDB, ensuring the marks qualify as registered, are court-validated marks, or are protected by statute or treaty. This entity would also be asked to ensure that proof of use of marks is provided, which can be demonstrated by furnishing a signed declaration and one specimen of current use.

Trademark, Mark:

Marks are used to claim exclusive properties of products or services. A mark is typically a name, word, phrase, logo, symbol, design, image, or a combination of these elements. For the scope of this document, only textual marks are relevant.

Trademark Claims, Claims:

Provides information to enhance the understanding of the trademark rights being claimed by the TMH.

Trademark Claims Period:

During this period, a special process applies to DNs matching the DNL List to ensure that TMHs are informed of a DN matching their PRM. For DNs matching the DNL List, Registrars show a TCN to prospective Registrants that has to be acknowledged before effective allocation of the DN.

UTC:

Coordinated Universal Time. This is maintained by the Bureau International des Poids et Mesures (BIPM). See [RFC 3339].

• during the Sunrise Period to fetch the SMD Revocation List from the TMDB via the sy interface (Section 4.3.11),
• during the Trademark Claims Period to fetch the DNL List from the TMDB via the dy interface (Section 4.3.3), and
• during the NORDN process to notify the LORDN to the TMDB via the yd interface (Section 4.3.7).

• fetch the SMD Revocation List via the sy interface (Section 4.3.11),
• fetch the DNL List from the TMDB via the dy interface (Section 4.3.3), and
• upload the LORDN to the TMDB via the yd interface (Section 4.3.7).

• during the Sunrise Period to validate the TMV certificates and the TMV CRL.

• during the Sunrise Period to perform integrity checking of the SMD Revocation List fetched from the TMDB via the sy interface (Section 4.3.11) and
• during the Trademark Claims Period to perform integrity checking of the DNL List fetched from the TMDB via the dy interface (Section 4.3.3).

• during the Sunrise Period to (optionally) fetch the SMD Revocation List from the TMDB via the sr interface (Section 4.3.12) and
• during the Trademark Claims Period to fetch TCNs from the TMDB via the dr interface (Section 4.3.6).

• fetch the SMD Revocation List via the sr interface (Section 4.3.12) and
• fetch TCNs via the dr interface (Section 4.3.6).

• during the Sunrise Period to (optionally) validate the TMV certificates and TMV CRL.

• during the Sunrise Period to (optionally) perform integrity checking of the SMD Revocation List fetched from the TMDB via the sr interface (Section 4.3.12).

1. an SMD has been received from the Registrar, along with the DN registration,
2. the certificate of the TMV has been correctly signed by the ICANN TMCH-CA (the certificate of the TMV is contained within the SMD),
3. the datetime when the validation is done is within the validity period of the TMV certificate,
4. the certificate of the TMV is not listed in the TMV CRL file specified in the CRL distribution point of the TMV certificate,
5. the signature of the SMD (signed with the TMV certificate) is valid,
6. the datetime when the validation is done is within the validity period of the SMD based on <smd:notBefore> and <smd:notAfter> elements,
7. the SMD has not been revoked, i.e., is not contained in the SMD Revocation List, and
8. the leftmost DNL of the DN being effectively allocated matches one of the label (<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".

• Registries MUST provide Registrars (over the ry interface; see Section 4.3.5) the lookup key used to retrieve the TCNs for DNs that match the DNL List.
• Registries MUST provide the lookup key only when queried about a specific DN.

• For each DN matching a DNL of a PRM, Registries MUST perform a minimum set of checks for verifying DN registrations during the Trademark Claims Period upon reception of a registration request over the ry interface (Section 4.3.5). If any of these checks fail, the Registry MUST abort the registration. Each of these checks MUST be performed before the DN is effectively allocated.
• In case of asynchronous registrations (e.g., auctions), the minimum set of checks MAY be performed when creating the intermediate object (e.g., a DN application) used for DN effective allocation. If the minimum set of checks is performed when creating the intermediate object (e.g., a DN application), a Registry MAY effectively allocate the DN without performing the minimum set of checks again.
• Performing the minimum set of checks, Registries MUST verify that:
  1. The TCNID (<tmNotice:id>), expiration datetime (<tmNotice:notAfter>), and acceptance datetime of the TCN have been received from the Registrar, along with the DN registration. If the three elements mentioned above are not provided by the Registrar for a DN matching a DNL of a PRM, but the DNL was inserted (or reinserted) for the first time into the DNL List less than 24 hours ago, the registration MAY continue without this data, and the tests listed below are not required to be performed.
  2. The TCN has not expired (according to the expiration datetime sent by the Registrar).
  3. The acceptance datetime is within the window of time defined by ICANN policy. In the gTLD round of 2012, Registrars verified that the acceptance datetime was less than or equal to 48 hours in the past, as there were no defined ICANN policies at that time. Implementers should be aware that ICANN policy may define this value in the future.
  4. The TCN Checksum is computed using the leftmost DNL of the DN being effectively allocated, the expiration datetime provided by the Registrar, and the TMDB Notice Identifier extracted from the TCNID provided by the Registrar. Verify that the computed TCN Checksum matches the 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".

1. Use the lookup key received from the Registry to obtain the TCN from the TMDB using the dr interface (Section 4.3.6). Registrars MUST only query for the lookup key of a DN that is available for registration.
2. Present the TCN to the Registrant, as described in Exhibit A of [RPM-Requirements].
3. Ask the Registrant for acknowledgement, i.e., the Registrant MUST consent with the TCN, before any further processing. (The transmission of a TCNID to the Registry over the ry interface (Section 4.3.5) implies that the Registrant has expressed their consent with the TCN.)
4. Perform the minimum set of checks for verifying DN registrations. If any of these checks fail, the Registrar MUST abort the DN registration. Each of these checks MUST be performed before the registration is sent to the Registry. Performing the minimum set of checks, Registrars MUST verify the following:
   1. The datetime when the validation is done is within the TCN validity based on the <tmNotice:notBefore> and <tmNotice:notAfter> elements.
   2. The leftmost DNL of the DN being effectively allocated matches the label (<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 their consent with) the TCN.
5. Record the date and time when the registrant acknowledged the TCN.
6. Send the registration to the Registry (via the ry interface; see Section 4.3.5) and include the following information:
   • TCNID (<tmNotice:id>)
   • Expiration date of the TCN (<tmNotice:notAfter>)
   • Acceptance datetime of the TCN

• If the leftmost DNL of the DN being effectively allocated (QLP Name in this section) matches a DNL in the SURL and an SMD is provided, then Registries MUST provide Sunrise Services (see Section 5.2), and the DN MUST be 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".
• 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 [QLP-Addendum]), then the DN MUST be reported in a Sunrise LORDN file using the special SMD-id "99999-99999" during the QLP Period.
• 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 [QLP-Addendum]), then Registries MUST provide Trademark Claims services (see Section 5.3), and the DN MUST be reported in a Trademark Claims LORDN file during the QLP Period.
• If the QLP Name matches a DNL in the DNL List but does not match a DNL in the SURL, then Registries MUST provide Trademark Claims services (see Section 5.3), and the DN MUST be reported in a Trademark Claims LORDN file during the QLP Period.

• SMD Revocation List (see Section 5.2.3.1)
• NORDN (see Section 5.2.3.3)
• DNL List (see Section 5.3.3.1)
• Sunrise List (SURL) (see Section 5.4.2.1)

• SMD Revocation List (see Section 5.2.3.1)
• CNIS (see Section 5.3.5.1)

• first line: <version>,<DNL List creation datetime>
  • Where:
    • <version>: version of the file. This field MUST be 1.
    • <DNL List creation datetime>: date and time in UTC that the DNL List was created.
• second line: a header line, as specified in [RFC 4180]
  • With the header names as follows:
  • DNL,lookup-key,insertion-datetime
• One or more lines with: <DNL>,<lookup key>,<DNL insertion datetime>
  • Where:
    • <DNL>: a Domain Name Label covered by a PRM.
    • <lookup key>: lookup key that the Registry MUST provide to the Registrar. The lookup key has the following format: <YYYY><MM><DD><vv>/<X>/<X>/<X>/<Random bits><Sequential number>, where:
      • YYYY: year that the TCN was generated.
      • MM: zero-padded month that the TCN was generated.
      • DD: zero-padded day that the TCN was generated.
      • vv: version of the TCN; possible values are 00 and 01.
      • X: one hex character. This is the first, second, and third hex character of encoding the <Random bits> in base16, as specified in [RFC 4648].
      • Random bits: 144 random bits encoded in base64url, as specified in [RFC 4648].
      • Sequential number: zero-padded natural number in the range 0000000001 to 2147483647.
    • <DNL insertion datetime>: datetime in UTC that the DNL was 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 12:00:00 UTC.

1,2012-08-16T00:00:00.0Z
DNL,lookup-key,insertion-datetime
example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\
   2010-07-14T00:00:00.0Z
another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\
   2012-08-16T00:00:00.0Z
anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\
   2011-08-16T12:00:00.0Z

• https://<tmdb-domain-name>/dnl/dnl-latest.csv
• https://<tmdb-domain-name>/dnl/dnl-latest.sig

• first line: <version>,<SMD Revocation List creation datetime>
  • Where:
    • <version>: version of the file. This field MUST be 1.
    • <SMD Revocation List creation datetime>: datetime in UTC that the SMD Revocation List was created.
• second line: a header line, as specified in [RFC 4180]
  • With the header names as follows:
  • smd-id,insertion-datetime
• One or more lines with: <smd-id>,<revoked SMD datetime>
  • Where:
    • <smd-id>: identifier of the SMD that was revoked.
    • <revoked SMD datetime>: revocation datetime in UTC of the SMD. The possible two values of time for inserting an SMD to the SMD Revocation List are 00:00:00 and 12:00:00 UTC.

• https://<tmdb-domain-name>/smdrl/smdrl-latest.csv
• https://<tmdb-domain-name>/smdrl/smdrl-latest.sig

1,2012-08-16T00:00:00.0Z
smd-id,insertion-datetime
2-2,2012-08-15T00:00:00.0Z
3-2,2012-08-15T00:00:00.0Z
1-2,2012-08-15T00:00:00.0Z

• Sunrise LORDN file: https://<tmdb-domain-name>/LORDN/<TLD>/sunrise
• Trademark Claims LORDN file: https://<tmdb-domain-name>/LORDN/<TLD>/claims

• Sunrise LORDN file (during QLP Period): https://<tmdb-domain-name>/LORDN/<TLD>/sunrise/qlp
• Trademark Claims LORDN file (during a QLP Period): https://<tmdb-domain-name>/LORDN/<TLD>/claims/qlp

• The interface provides an HTTP/202 status code if the interface was able to receive the LORDN file and the syntax of the LORDN file is correct. The interface provides the LORDN Transaction Identifier in the HTTP Entity-body that would be used by the Registry to download the LORDN Log file. The LORDN Transaction Identifier is a zero-padded natural number in the range 0000000000000000001 to 9223372036854775807. The TMDB uses the <LORDN creation datetime> element of the LORDN file as a unique client-side identifier. If a LORDN file with the same <LORDN creation datetime> of a previously sent LORDN file is received by the TMDB, the LORDN Transaction Identifier of the previously sent LORDN file MUST be provided to the Registry. The TMDB MUST ignore the DN Lines present in the LORDN file if a LORDN file with the same <LORDN creation datetime> was previously sent. The HTTP Location header field contains the URI where the LORDN Log file could be retrieved later, for example:
  • 202 Accepted Location: https://<tmdb-domain-name>/LORDN/example/sunrise/0000000000000000001/result

• The interface provides an HTTP/400 if the request is incorrect or the syntax of the LORDN file is incorrect. The TMDB MUST return a human-readable message in the HTTP Entity-body regarding the incorrect syntax of the LORDN file.
• The interface provides an HTTP/401 status code if the credentials provided do not authorize the Registry Operator to upload a LORDN file.
• The TMDB MUST return an HTTP/404 status code when trying to upload a LORDN file using the https://<tmdb-domain-name>/LORDN/<TLD>/sunrise/qlp or https://<tmdb-domain-name>/LORDN/<TLD>/claims/qlp interface outside of a QLP Period plus 26 hours.
• The interface provides an HTTP/500 status code if the system is experiencing a general failure.

• For Sunrise Period:
  • first line: <version>,<LORDN creation datetime>,<Number of DN Lines>
    • Where:
      • <version>: version of the file. This field MUST be 1.
      • <LORDN creation datetime>: date and time in UTC that the LORDN was created.
      • <Number of DN Lines>: number of DN Lines present in the LORDN file.
  • second line: a header line, as specified in [RFC 4180]
    • With the header names as follows:
    • roid,domain-name,SMD-id,registrar-id,registration-datetime,application-datetime
  • One or more lines with: <roid>,<DN registered>,<SMD-id>,<IANA Registrar id>,<datetime of registration>,<datetime of application creation>
    • Where:
      • <roid>: DN Repository Object IDentifier (DNROID) in the SRS.
      • <DN registered>: DN that was effectively allocated. For IDNs, the A-label form is used.
      • <SMD-id>: SMD ID used for registration.
      • <IANA Registrar ID>: IANA Registrar ID.
      • <datetime of registration>: date and time in UTC that the domain was effectively allocated.
      • OPTIONAL <datetime of application creation>: date and time in UTC that the application was created. The <datetime of application creation> MUST be provided in case of a DN effective allocation based on an asynchronous registration (e.g., when using auctions).
  Example of a Sunrise LORDN file:

  1,2012-08-16T00:00:00.0Z,3
  roid,domain-name,SMD-id,registrar-id,registration-datetime,\
     application-datetime
  SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\
     2012-07-15T00:50:00.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
  

  Figure 12: Example Sunrise LORDN File
• For the Trademark Claims Period:
  • first line: <version>,<LORDN creation datetime>,<Number of DN Lines>
    • Where:
      • <version>: version of the file. This field MUST be 1.
      • <LORDN creation datetime>: date and time in UTC that the LORDN was created.
      • <Number of DN Lines>: number of DN Lines present in the LORDN file.
  • second line: a header line, as specified in [RFC 4180]
    • With the header names as follows:
    • roid,domain-name,notice-id,registrar-id,registration-datetime,ack-datetime,application-datetime
  • One or more lines with: <roid>,<DN registered>,<TCNID>,<IANA Registrar id>,<datetime of registration>,<datetime of acceptance of the TCN>,<datetime of application creation>
    • Where:
      • <roid>: DNROID in the SRS.
      • <DN registered>: DN that was effectively allocated. For IDNs, the A-label form is used.
      • <TCNID>: Trademark Claims Notice Identifier, as specified in <tmNotice:id>.
      • <IANA Registrar ID>: IANA Registrar ID.
      • <datetime of registration>: date and time in UTC that the domain was effectively allocated.
      • <datetime of acceptance of the TCN>: date and time in UTC that the TCN was acknowledged.
      • OPTIONAL <datetime of application creation>: date and time in UTC that the application was created. The <datetime of application creation> MUST be provided in case of a DN effective allocation based on an asynchronous registration (e.g., when using auctions).
    • For a DN matching a DNL of a PRM at the moment of registration, created without the TCNID, expiration datetime, and acceptance datetime because DNL was inserted (or reinserted) for the first time into a DNL List less than 24 hours ago, the string "recent-dnl-insertion" MAY be specified in <TCNID> and <datetime of acceptance of the TCN>.
  Example of a Trademark Claims LORDN file:

               
  1,2012-08-16T00:00:00.0Z,3
  roid,domain-name,notice-id,registrar-id,registration-datetime,\
      ack-datetime,application-datetime
  SH8013-REP,example1.gtld,a76716ed9223352036854775808,\
      9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z
  EK77-REP,example2.gtld,a7b786ed9223372036856775808,\
      9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z
  HB800-REP,example3.gtld,recent-dnl-insertion,\ 
      9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion
  

  Figure 13: Example Trademark Claims LORDN File

• Sunrise LORDN Log file: https://<tmdb-domain-name>/LORDN/<TLD>/sunrise/<lordn-transaction-identifier>/result
• Trademark Claims LORDN Log file: https://<tmdb-domain-name>/LORDN/<TLD>/claims/<lordn-transaction-identifier>/result

• The interface provides an HTTP/200 status code if the interface was able to provide the LORDN Log file. The LORDN Log file is contained in the HTTP Entity-body.
• The interface provides an HTTP/204 status code if the LORDN Transaction Identifier is correct but the server has not finalized processing the LORDN file.
• The interface provides an HTTP/400 status code if the request is incorrect.
• The interface provides an HTTP/401 status code if the credentials provided do not authorize the Registry Operator to download the LORDN Log file.
• The interface provides an HTTP/404 status code if the LORDN Transaction Identifier is incorrect.
• The interface provides an HTTP/500 status code if the system is experiencing a general failure.

• first line: <version>,<LORDN Log creation datetime>,<LORDN file creation datetime>,<LORDN Log Identifier>,<Status flag>,<Warning flag>,<Number of DN Lines>
  • Where:
    • <version>: version of the file. This field MUST be 1.
    • <LORDN Log creation datetime>: date and time in UTC that the LORDN Log was created.
    • <LORDN file creation datetime>: date and time in UTC of creation for the LORDN file that this log file is referring to.
    • <LORDN Log Identifier>: unique identifier of the LORDN Log provided by the TMDB. This identifier could be used by the Registry Operator to unequivocally identify the LORDN Log. The identified will be a string of a maximum length of 60 characters from the base64 alphabet.
    • <Status flag>: whether the LORDN file has been accepted for processing by the TMDB. Possible values are "accepted" or "rejected".
    • <Warning flag>: whether the LORDN Log has any warning result codes. Possible values are "no-warnings" or "warnings-present".
    • <Number of DN Lines>: number of DN effective allocations processed in the LORDN file.
  • A Registry Operator is not required to process a LORDN Log with <Status flag>="accepted" and <Warning flag>="no-warnings".
• second line: a header line, as specified in [RFC 4180]
  • With the header names as follows:
  • roid,result-code
• One or more lines with: <roid>,<result code>
  • Where:
    • <roid>: DNROID in the SRS.
    • <result code>: result code, as described in Section 6.3.1.1.

1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\
   0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\
   accepted,no-warnings,1
roid,result-code
SH8013-REP,2000

• ok: Success. The DN Line is accepted by the TMDB.
• warn: A warning is issued. The DN Line is accepted by the TMDB.
• err: An error is issued. The LORDN file is rejected by the TMDB.

1. Marks: <marks>
2. smdID: <SMD-ID>
3. U-labels: <comma separated list of U-label or NR-LDH labels (see [RFC 5890])>
4. notBefore: <begin validity>
5. notAfter: <end validity>
6. -----BEGIN ENCODED SMD-----
7. <encoded SMD (see [RFC 7848])>
8. -----END ENCODED SMD-----

Marks: Example One
smdID: 1-2
U-labels: example-one, exampleone
notBefore: 2011-08-16 09:00
notAfter: 2012-08-16 09:00
-----BEGIN ENCODED SMD-----
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu
ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN
... (base64 data elided for brevity) ...
dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo=
-----END ENCODED SMD-----

• A <tmNotice:id> element that contains the unique identifier of the Trademark Notice. This element contains the TCNID.
  • The TCNID is a string concatenation of a TCN Checksum and the TMDB Notice Identifier. The first 8 characters of the TCNID is a TCN Checksum. The rest is the TMDB Notice Identifier, which is a zero-padded natural number in the range of 0000000000000000001 to 9223372036854775807.
  • Example of a TCNID:
    • 370d0b7c9223372036854775807.
  • Where:
    • TCN Checksum=370d0b7c
    • TMDB Notice Identifier=9223372036854775807
  • The TCN Checksum is an 8-character-long base16-encoded output of computing the CRC32 of the string concatenation of: label + unix_timestamp(<tmNotice:notAfter>) + TMDB Notice Identifier.
  • The TMDB MUST use the Unix time conversion of the <tmNotice:notAfter> in UTC to calculate the TCN Checksum. Unix time is defined as the number of seconds that have elapsed since 1970-01-01T00:00:00Z, not counting leap seconds. For example, the conversion of 2010-08-16T09:00:00.0Z to Unix time is:
    • unix_time(2010-08-16T09:00:00.0Z)=1281949200
  • The TMDB uses the <tmNotice:label> and <tmNotice:notAfter> elements from the TCN along with the TMDB Notice Identifier to compute the TCN Checksum.
  • A Registry MUST use the leftmost DNL of the DN being effectively allocated, the expiration datetime of the TCN (provided by the Registrar), and the TMDB Notice Identifier extracted from the TCNID (provided by the Registrar) to compute the TCN Checksum. For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being effectively allocated, the leftmost DNL would be "xn--mgbachtv".
  • An example computation of the TCN Checksum is:
    • CRC32(example-one12819492009223372036854775807)=370d0b7c
• A <tmNotice:notBefore> element that contains the start of the valid date and time of the TCN.
• A <tmNotice:notAfter> element that contains the expiration date and time of the TCN.
• A <tmNotice:label> element that contains the DNL covered by a PRM.
• One or more <tmNotice:claim> elements that contain the Trademark Claims. The <tmNotice:claim> element contains the following child elements:
  • A <tmNotice:markName> element that contains the mark text string.
  • One or more <tmNotice:holder> elements that contain the information of the holder of the mark. An "entitlement" attribute is used to identify the entitlement of the holder; possible values are: owner, assignee, or licensee. The child elements of <tmNotice:holder> include:
    • An OPTIONAL <tmNotice:name> element that contains the name of the holder. <tmNotice:name> MUST be specified if <tmNotice:org> is not specified.
    • An OPTIONAL <tmNotice:org> element that contains the name of the organization holder of the mark. <tmNotice:org> MUST be specified if <tmNotice:name> is not specified.
    • A <tmNotice:addr> element that contains the address information of the holder of a mark. <tmNotice:addr> contains the following child elements:
      • One, two, or three OPTIONAL <tmNotice:street> elements that contain the organization's street address.
      • A <tmNotice:city> element that contains the organization's city.
      • An OPTIONAL <tmNotice:sp> element that contains the organization's state or province.
      • An OPTIONAL <tmNotice:pc> element that contains the organization's postal code.
      • A <tmNotice:cc> element that contains the organization's country code. This a two-character code from [ISO3166-2].
    • An OPTIONAL <tmNotice:voice> element that contains the organization's voice telephone number.
    • An OPTIONAL <tmNotice:fax> element that contains the organization's facsimile telephone number.
    • An OPTIONAL <tmNotice:email> element that contains the email address of the holder.
  • Zero or more OPTIONAL <tmNotice:contact> elements that contain the information of the representative of the mark registration. A "type" attribute is used to identify the type of contact; possible values are: owner, agent, or third party. The child elements of <tmNotice:contact> include:
    • A <tmNotice:name> element that contains the name of the responsible person.
    • An OPTIONAL <tmNotice:org> element that contains the name of the organization of the contact.
    • A <tmNotice:addr> element that contains the address information of the contact. <tmNotice:addr> contains the following child elements:
      • One, two, or three OPTIONAL <tmNotice:street> elements that contain the contact's street address.
      • A <tmNotice:city> element that contains the contact's city.
      • An OPTIONAL <tmNotice:sp> element that contains the contact's state or province.
      • An OPTIONAL <tmNotice:pc> element that contains the contact's postal code.
      • A <tmNotice:cc> element that contains the contact's country code. This a two-character code from [ISO3166-2].
    • A <tmNotice:voice> element that contains the contact's voice telephone number.
    • An OPTIONAL <tmNotice:fax> element that contains the contact's facsimile telephone number.
    • A <tmNotice:email> element that contains the contact's email address.
  • A <tmNotice:jurDesc> element that contains the name (in English) of the jurisdiction where the mark is protected. A jurCC attribute contains the two-character code of the jurisdiction where the mark was registered. This is a two-character code from [WIPO.ST3].
  • Zero or more OPTIONAL <tmNotice:classDesc> elements that contain the description (in English) of the Nice Classification, as defined in [WIPO-NICE-CLASSES]. A classNum attribute contains the class number.
  • A <tmNotice:goodsAndServices> element that contains the full description of the goods and services mentioned in the mark registration document.
  • An OPTIONAL <tmNotice:notExactMatch> element signals that the claim notice was added to the TCN based on rules (e.g., [Claims50]) other than exact match (defined in [MatchingRules]). <tmNotice:notExactMatch> contains one or more of the following:
    • An OPTIONAL <tmNotice:udrp> element that signals that the claim notice was added because of a previously abused name included in a Uniform Domain-Name Dispute-Resolution Policy (UDRP) case. <tmNotice:udrp> contains:
      • A <tmNotice:caseNo> element that contains the UDRP case number used to validate the previously abused name.
      • A <tmNotice:udrpProvider> element that contains the name of the UDRP provider.
    • An OPTIONAL <tmNotice:court> element that signals that the claim notice was added because of a previously abused name included in a court's resolution. <tmNotice:court> contains:
      • A <tmNotice:refNum> element that contains the reference number of the court's resolution used to validate the previously abused name.
      • A <tmNotice:cc> element that contains the two-character code from [ISO3166-2] of the jurisdiction of the court.
      • A <tmNotice:courtName> element that contains the name of the court.

<?xml version="1.0" encoding="UTF-8"?>
<tmNotice:notice
 xmlns:tmNotice="urn:ietf:params:xml:ns:tmNotice-1.0">
 <tmNotice:id>370d0b7c9223372036854775807</tmNotice:id>
 <tmNotice:notBefore>2010-08-14T09:00:00.0Z</tmNotice:notBefore>
 <tmNotice:notAfter>2010-08-16T09:00:00.0Z</tmNotice:notAfter>
 <tmNotice:label>example-one</tmNotice:label>
 <tmNotice:claim>
  <tmNotice:markName>Example One</tmNotice:markName>
  <tmNotice:holder entitlement="owner">
   <tmNotice:org>Example Inc.</tmNotice:org>
   <tmNotice:addr>
    <tmNotice:street>123 Example Dr.</tmNotice:street>
    <tmNotice:street>Suite 100</tmNotice:street>
    <tmNotice:city>Reston</tmNotice:city>
    <tmNotice:sp>VA</tmNotice:sp>
    <tmNotice:pc>20190</tmNotice:pc>
    <tmNotice:cc>US</tmNotice:cc>
   </tmNotice:addr>
  </tmNotice:holder>
  <tmNotice:contact type="owner">
   <tmNotice:name>Joe Doe</tmNotice:name>
   <tmNotice:org>Example Inc.</tmNotice:org>
   <tmNotice:addr>
    <tmNotice:street>123 Example Dr.</tmNotice:street>
    <tmNotice:street>Suite 100</tmNotice:street>
    <tmNotice:city>Reston</tmNotice:city>
    <tmNotice:sp>VA</tmNotice:sp>
    <tmNotice:pc>20190</tmNotice:pc>
    <tmNotice:cc>US</tmNotice:cc>
   </tmNotice:addr>
   <tmNotice:voice x="4321">+1.7035555555</tmNotice:voice>
   <tmNotice:email>jdoe@example.com</tmNotice:email>
  </tmNotice:contact>
  <tmNotice:jurDesc jurCC="US">USA</tmNotice:jurDesc>
  <tmNotice:classDesc classNum="35">
  Advertising; business management; business administration.
 </tmNotice:classDesc>
  <tmNotice:classDesc classNum="36">
  Insurance; financial affairs; monetary affairs; real estate.
 </tmNotice:classDesc>
  <tmNotice:goodsAndServices>
  Bardus populorum circumdabit se cum captiosus populum.
  Smert populorum circumdabit se cum captiosus populum.
 </tmNotice:goodsAndServices>
 </tmNotice:claim>
 <tmNotice:claim>
  <tmNotice:markName>Example-One</tmNotice:markName>
  <tmNotice:holder entitlement="owner">
   <tmNotice:org>Example S.A. de C.V.</tmNotice:org>
   <tmNotice:addr>
    <tmNotice:street>Calle conocida #343</tmNotice:street>
    <tmNotice:city>Conocida</tmNotice:city>
    <tmNotice:sp>SP</tmNotice:sp>
    <tmNotice:pc>82140</tmNotice:pc>
    <tmNotice:cc>BR</tmNotice:cc>
   </tmNotice:addr>
  </tmNotice:holder>
  <tmNotice:jurDesc jurCC="BR">BRAZIL</tmNotice:jurDesc>
  <tmNotice:goodsAndServices>
  Bardus populorum circumdabit se cum captiosus populum.
  Smert populorum circumdabit se cum captiosus populum.
 </tmNotice:goodsAndServices>
 </tmNotice:claim>
 <tmNotice:claim>
  <tmNotice:markName>One</tmNotice:markName>
  <tmNotice:holder entitlement="owner">
   <tmNotice:org>One Corporation</tmNotice:org>
   <tmNotice:addr>
    <tmNotice:street>Otra calle</tmNotice:street>
    <tmNotice:city>Otra ciudad</tmNotice:city>
    <tmNotice:sp>OT</tmNotice:sp>
    <tmNotice:pc>383742</tmNotice:pc>
    <tmNotice:cc>CR</tmNotice:cc>
   </tmNotice:addr>
  </tmNotice:holder>
  <tmNotice:jurDesc jurCC="CR">COSTA RICA</tmNotice:jurDesc>
  <tmNotice:goodsAndServices>
  Bardus populorum circumdabit se cum captiosus populum.
  Smert populorum circumdabit se cum captiosus populum.
 </tmNotice:goodsAndServices>
  <tmNotice:notExactMatch>
   <tmNotice:court>
    <tmNotice:refNum>234235</tmNotice:refNum>
    <tmNotice:cc>CR</tmNotice:cc>
    <tmNotice:courtName>Supreme Court of Spain</tmNotice:courtName>
   </tmNotice:court>
  </tmNotice:notExactMatch>
 </tmNotice:claim>
 <tmNotice:claim>
  <tmNotice:markName>One Inc</tmNotice:markName>
  <tmNotice:holder entitlement="owner">
   <tmNotice:org>One SA de CV</tmNotice:org>
   <tmNotice:addr>
    <tmNotice:street>La calle</tmNotice:street>
    <tmNotice:city>La ciudad</tmNotice:city>
    <tmNotice:sp>CD</tmNotice:sp>
    <tmNotice:pc>34323</tmNotice:pc>
    <tmNotice:cc>AR</tmNotice:cc>
   </tmNotice:addr>
  </tmNotice:holder>
  <tmNotice:jurDesc jurCC="AR">ARGENTINA</tmNotice:jurDesc>
  <tmNotice:goodsAndServices>
  Bardus populorum circumdabit se cum captiosus populum.
  Smert populorum circumdabit se cum captiosus populum.
 </tmNotice:goodsAndServices>
  <tmNotice:notExactMatch>
   <tmNotice:udrp>
    <tmNotice:caseNo>D2003-0499</tmNotice:caseNo>
    <tmNotice:udrpProvider>WIPO</tmNotice:udrpProvider>
   </tmNotice:udrp>
  </tmNotice:notExactMatch>
 </tmNotice:claim>
</tmNotice:notice>

• first line: <version>,<Sunrise List creation datetime>
  • Where:
    • <version>: version of the file. This field MUST be 1.
    • <Sunrise List creation datetime>: date and time in UTC that the Sunrise List was created.
• second line: a header line, as specified in [RFC 4180]
  • With the header names as follows:
  • DNL,insertion-datetime
• One or more lines with: <DNL>,<DNL insertion datetime>
  • Where:
    • <DNL>: a Domain Name Label covered by a PRM eligible for Sunrise.
    • <DNL insertion datetime>: datetime in UTC that the DNL was first inserted into the Sunrise List. The possible two values of time for inserting a DNL to the Sunrise List are 00:00:00 and 12:00:00 UTC.

1,2012-08-16T00:00:00.0Z
DNL,insertion-datetime
example,2010-07-14T00:00:00.0Z
another-example,2012-08-16T00:00:00.0Z
anotherexample,2011-08-16T12:00:00.0Z

• https://<tmdb-domain-name>/dnl/surl-latest.csv
• https://<tmdb-domain-name>/dnl/surl-latest.sig

URI:

urn:ietf:params:xml:ns:tmNotice-1.0

Registrant Contact:

IETF <iesg@ietf.org> and ICANN <globalsupport@icann.org>

XML:

None. Namespace URIs do not represent an XML specification.

Note:

Note that this assignment is made from the wrong point in the tree in order to be consistent with deployed implementations.

URI:

urn:ietf:params:xml:schema:tmNotice-1.0

Registrant Contact:

IETF <iesg@ietf.org> and ICANN <globalsupport@icann.org>

XML:

See Section 7.1 of RFC 9361.

Note:

Note that this assignment is made from the wrong point in the tree in order to be consistent with deployed implementations.

[Claims50]

ICANN, "Implementation Notes: Trademark Claims Protection for Previously Abused Names", July 2013,
<https://newgtlds.icann.org/en/about/trademark-clearinghouse/previously-abused-16jul13-en.pdf>.

[MatchingRules]

ICANN, "Explanatory Memorandum: Implementing the Matching Rules", July 2016,
<https://newgtlds.icann.org/en/about/trademark-clearinghouse/matching-rules-14jul16-en.pdf>.

[QLP-Addendum]

ICANN, "Trademark Clearinghouse Rights Protection Mechanism Requirements: Qualified Launch Program Addendum", April 2014,
<https://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirements-qlp-addendum-10apr14-en.pdf>.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC3688]

M. Mealling, "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.

[RFC7848]

G. Lozano, "Mark and Signed Mark Objects Mapping", RFC 7848, DOI 10.17487/RFC7848, June 2016,
<https://www.rfc-editor.org/info/rfc7848>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC9325]

Y. Sheffer, P. Saint-Andre, and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022,
<https://www.rfc-editor.org/info/rfc9325>.

[RPM-Requirements]

ICANN, "Trademark Clearinghouse Rights Protection Mechanism Requirements", September 2013,
<https://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirements-30sep13-en.pdf>.

[W3C.REC-xml-20081126]

T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, and F. Yergeau, "Trademark Clearinghouse Rights Protection Mechanism Requirements", November 2008,
<https://www.w3.org/TR/2008/REC-xml-20081126/>.

[W3C.REC-xmlschema-1-20041028]

H. Thompson, D. Beech, M. Maloney, and N. Mendelsohn, "Trademark Clearinghouse Rights Protection Mechanism Requirements", October 2004,
<https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/>.

[W3C.REC-xmlschema-2-20041028]

P. Biron, and A. Malhotra, "Trademark Clearinghouse Rights Protection Mechanism Requirements", October 2004,
<https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.

[ICANN-GTLD-AGB-20120604]

ICANN, "gTLD Applicant Guidebook Version 2012-06-04", June 2012,
<http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf>.

[ISO3166-2]

ISO, "gTLD Applicant Guidebook Version 2012-06-04",
<http://www.iso.org/iso/home/standards/country_codes.htm>.

[RFC3339]

G. Klyne, and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.

[RFC4180]

Y. Shafranovich, "Common Format and MIME Type for Comma-Separated Values (CSV) Files", RFC 4180, DOI 10.17487/RFC4180, October 2005,
<https://www.rfc-editor.org/info/rfc4180>.

[RFC4648]

S. Josefsson, "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.

[RFC4880]

J. Callas, L. Donnerhacke, H. Finney, D. Shaw, and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007,
<https://www.rfc-editor.org/info/rfc4880>.

[RFC5280]

D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.

[RFC5890]

J. Klensin, "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.

[RFC7617]

J. Reschke, "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015,
<https://www.rfc-editor.org/info/rfc7617>.

[RFC8499]

P. Hoffman, A. Sullivan, and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019,
<https://www.rfc-editor.org/info/rfc8499>.

[RFC9110]

R. Fielding, M. Nottingham, and J. Reschke, "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.

[WIPO-NICE-CLASSES]

WIPO, "HTTP Semantics",
<http://www.wipo.int/classifications/nice/en>.

[WIPO.ST3]

WIPO, "HTTP Semantics", November 2022,
<https://www.wipo.int/export/sites/www/standards/en/pdf/03-03-01.pdf>.

Gustavo Lozano