Skip to main content

TMCH functional specifications
draft-lozano-tmch-func-spec-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Gustavo Lozano Ibarra , Bernie Hoeneisen
Last updated 2013-03-12
Replaced by draft-ietf-eppext-tmch-func-spec, draft-ietf-eppext-tmch-func-spec
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-lozano-tmch-func-spec-00
Internet Engineering Task Force                           G. Lozano, Ed.
Internet-Draft                                                     ICANN
Intended status: Standards Track                            B. Hoeneisen
Expires: September 13, 2013                                      Ucom.ch
                                                          March 12, 2013

                     TMCH functional specifications
                     draft-lozano-tmch-func-spec-00

Abstract

   This document describes the requirements, the architecture and the
   interfaces between the Trademark Clearing House (TMCH) and Domain
   Name Registries as well as between TMCH and Domain Name Registrars
   for the provisioning and management of domain names during Sunrise
   and Trademark Claims Period of a domain name Registry.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 13, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as

Lozano & Hoeneisen     Expires September 13, 2013               [Page 1]
Internet-Draft       TMCH functional specifications           March 2013

   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Discussion . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Sunrise Period . . . . . . . . . . . . . . . . . . . . . .  9
     5.2.  Trademark Claims Period  . . . . . . . . . . . . . . . . . 10
     5.3.  Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 10
       5.3.1.  hv . . . . . . . . . . . . . . . . . . . . . . . . . . 10
       5.3.2.  vd . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       5.3.3.  dy . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       5.3.4.  tr . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       5.3.5.  ry . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       5.3.6.  dr . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       5.3.7.  yd . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       5.3.8.  dv . . . . . . . . . . . . . . . . . . . . . . . . . . 12
       5.3.9.  vh . . . . . . . . . . . . . . . . . . . . . . . . . . 12
       5.3.10. vs . . . . . . . . . . . . . . . . . . . . . . . . . . 12
       5.3.11. sy . . . . . . . . . . . . . . . . . . . . . . . . . . 12
       5.3.12. sr . . . . . . . . . . . . . . . . . . . . . . . . . . 12
       5.3.13. vc . . . . . . . . . . . . . . . . . . . . . . . . . . 13
       5.3.14. cy . . . . . . . . . . . . . . . . . . . . . . . . . . 13
       5.3.15. cr . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  Process Decriptions  . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  Bootstrap  . . . . . . . . . . . . . . . . . . . . . . . . 13
       6.1.1.  Registries . . . . . . . . . . . . . . . . . . . . . . 13
         6.1.1.1.  Credentials  . . . . . . . . . . . . . . . . . . . 13
         6.1.1.2.  TMCH Trust Anchor  . . . . . . . . . . . . . . . . 14
         6.1.1.3.  TMDB/SMDM PGP Key  . . . . . . . . . . . . . . . . 14
       6.1.2.  Registrars . . . . . . . . . . . . . . . . . . . . . . 14
         6.1.2.1.  Credentials  . . . . . . . . . . . . . . . . . . . 14
         6.1.2.2.  TMCH Trust Anchor  . . . . . . . . . . . . . . . . 14
         6.1.2.3.  TMDB PGP Key . . . . . . . . . . . . . . . . . . . 14
         6.1.2.4.  IP Addresses for Access Control  . . . . . . . . . 15
     6.2.  Sunrise Period . . . . . . . . . . . . . . . . . . . . . . 16
       6.2.1.  Domain Registration  . . . . . . . . . . . . . . . . . 16
       6.2.2.  DN Registration by Registries  . . . . . . . . . . . . 17
       6.2.3.  TMCH Sunrise Services for Registries . . . . . . . . . 18
         6.2.3.1.  SMD Revocation List  . . . . . . . . . . . . . . . 18
         6.2.3.2.  Certificate Revocation List  . . . . . . . . . . . 18
         6.2.3.3.  Notice of Registered Domain Names  . . . . . . . . 19
       6.2.4.  DN registration by Registrars  . . . . . . . . . . . . 21

Lozano & Hoeneisen     Expires September 13, 2013               [Page 2]
Internet-Draft       TMCH functional specifications           March 2013

       6.2.5.  TMCH Sunrise Services for Registrars . . . . . . . . . 21
     6.3.  Trademark Claims Period  . . . . . . . . . . . . . . . . . 21
       6.3.1.  Domain Registration  . . . . . . . . . . . . . . . . . 21
       6.3.2.  DN registration by Registries  . . . . . . . . . . . . 23
       6.3.3.  Trademark Claims Services for Registries . . . . . . . 24
         6.3.3.1.  Domain Name Label (DNL) List . . . . . . . . . . . 24
         6.3.3.2.  Notice of Registered Domain Names  . . . . . . . . 24
       6.3.4.  DN Registration by Registrars  . . . . . . . . . . . . 24
       6.3.5.  Tradermark Claims Services for Registrars  . . . . . . 26
         6.3.5.1.  Claims Notice Information Service  . . . . . . . . 26
   7.  Data Format Descriptions . . . . . . . . . . . . . . . . . . . 26
     7.1.  DNL List file  . . . . . . . . . . . . . . . . . . . . . . 26
     7.2.  LORDN File . . . . . . . . . . . . . . . . . . . . . . . . 27
       7.2.1.  LORDN Log File . . . . . . . . . . . . . . . . . . . . 28
       7.2.2.  LORDN Error Codes  . . . . . . . . . . . . . . . . . . 29
     7.3.  SMD File . . . . . . . . . . . . . . . . . . . . . . . . . 29
     7.4.  SMD revocation list  . . . . . . . . . . . . . . . . . . . 30
     7.5.  Trademark Claims Notice  . . . . . . . . . . . . . . . . . 31
   8.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 32
     8.1.  Trademark Claims Notice  . . . . . . . . . . . . . . . . . 33
   9.  Status of this Draft . . . . . . . . . . . . . . . . . . . . . 36
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 36
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 36
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 36
     13.2. Informative References . . . . . . . . . . . . . . . . . . 36
   Appendix A.  Document Changelog  . . . . . . . . . . . . . . . . . 37
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38

Lozano & Hoeneisen     Expires September 13, 2013               [Page 3]
Internet-Draft       TMCH functional specifications           March 2013

1.  Introduction

   Domain Name Registries may operate in special modes within certain
   periods of time to facilitate allocation of domain names.

   Along with the upcoming introduction of new global Top Level Domains
   (gTLD), two special modes will come into effect:

   o  Sunrise Period

   o  Trademark Claims Period

   The Sunrise and Trademark Claims Periods are defined in the gTLD
   Applicant Guidebook [ICANN-GTLD-AGB-20120604].

   This document describes the requirements, the architecture and the
   interfaces between the Trademark Clearing House (TMCH) and Domain
   Name Registries as well as between TMCH and Domain Name Registrars
   for the provisioning and management of domain names during the
   Sunrise and Trademark Claims Periods.

   After the Terminology (Section 2) and Glossary (Section 3) the
   Requirements (Section 4) are listed, followed by the architecture
   (Section 5) and the different process descriptions (Section 6).
   Afterwards, in Section 7, the necessary Data Formats are defined,
   followed by their formal syntax (Section 8).

1.1.  Discussion

   Any interested parties are invited to contribute to the discussion of
   this draft and provide feedback.  The discussion currently takes
   place on the tmch-tech discussion list <tmch-tech@icann.org>.
   Interested parties can subscribe to this mailing list via
   < https://mm.icann.org/mailman/listinfo/tmch-tech >.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   XML is case sensitive.  Unless stated otherwise, XML specifications
   and examples provided in this document MUST be interpreted in the
   character case presented in order to develop a conforming
   implementation.

   "tmNotice-1.0" is used as an abbreviation for

Lozano & Hoeneisen     Expires September 13, 2013               [Page 4]
Internet-Draft       TMCH functional specifications           March 2013

   "urn:ietf:params:xml:ns:tm-notice-1.0".  The XML namespace prefix
   "tmNotice" is used, but implementations MUST NOT depend on it and
   instead employ a proper namespace-aware XML parser and serializer to
   interpret and output the XML documents.

3.  Glossary

   In the following the most common terms are briefly Explained:

   o  Allocated DN: A DN is considered Allocated when the DN object for
      the DN has been created in the SRS of the Registry.  A DN object
      in status "pendingCreate" or any other status that precedes the
      first time a DN is in "ok" status is not considered Allocated.
      Also a DN object created internally by the Registry for subsequent
      delegation to another Registrant is not considered Allocated; see
      also [ICANN-GTLD-AGB-20120604].

   o  CA: Certificate Authority, see [RFC5280] and [RFC6818]

   o  CSV: Comma-Separated Values, see [RFC4180]

   o  CNIS, Claims Notice Information Service: This service provides
      trademark claims notices to Registrars.

   o  CRL: Certificate Revocation List, see [RFC5280] and [RFC6818].

   o  DN: Domain Name, see [RFC1034]

   o  DNS: Domain Name System, see [RFC1034]

   o  DNL, Domain Name Label: An ASCII string used in the DNS (an FQDN
      is composed by such labels separated by dots) as defined in
      [RFC1034].  For IDNs the A-Label is used [RFC5891].

   o  EPP: Extensible Provisioning Protocol, see [RFC5730].

   o  FQDN: Fully Qualified Domain Name (e.g. myname.example.com)

   o  HTTP: Hypertext Transfer Protocol, see [RFC2616]

   o  HTTPS: HTTP over TLS (Transport Layer Security), [RFC2818]

   o  ICANN-CA: ICANN's Certificate Authority (CA); Trust Anchor for the
      SMD PKI model.

   o  IDN: Internationalized Domain Names, see [RFC5891]

Lozano & Hoeneisen     Expires September 13, 2013               [Page 5]
Internet-Draft       TMCH functional specifications           March 2013

   o  LORDN, List of Registered Domain Names: This is the list of
      registered domain names matching a DNL of a PRM that Registries
      daily upload to the TMDB (during the NORDN process).

   o  Lookup Key: A random string of 32 chars from the set [a-zA-Z0-9/]
      to be used as the lookup Key by Registrars to obtain the claims
      notice using the CNIS.  Lookup Keys are unique and are related to
      one DNL only.

   o  NORDN, Notification of Registered Domain Names: The process where
      Registries daily upload the recent LORDN to the TMCH.

   o  PGP: Pretty Good Privacy, see [RFC4880]

   o  PKI: Public Key Infrastructure, see [RFC5280] and [RFC6818]

   o  PRM, Pre-registered mark: Mark that has been pre-registered with
      the TMCH.

   o  Registrant: Person or Organization registering a Domain Name via a
      Registrar.

   o  Registrar, Domain Name Registrar: Registers Domain Names with the
      Registry on behalf of the Registrant.

   o  Registry, Domain Name Registry: Entity that accepts Domain Name
      registrations from Registrars, maintains the central Database of
      Registered Domains.

   o  SFTP: Secure File Transfer Protocol

   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
      Domain Name that matches a DNL of a PRM; see also
      [I-D.lozano-tmch-smd]

   o  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 also Section 7.3.

   o  SMDM, SMD Manager: A entity managing the SMDs, mainly maintaining
      lists of revoked SMDs; see also [I-D.lozano-tmch-smd]

   o  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.

Lozano & Hoeneisen     Expires September 13, 2013               [Page 6]
Internet-Draft       TMCH functional specifications           March 2013

   o  SRS: Shared Registration System, see also
      [ICANN-GTLD-AGB-20120604].

   o  Sunrise Period: During this period Domain Names matching a DNL of
      a PRM can be exclusively obtained by the respective mark holders.
      For domain names matching PRM, a special process applies to ensure
      a TMH gets informed on the registration of a domain name matching
      his PRM.  Every launch of a new gTLD Registry starts with a
      Sunrise Period, followed by a Trademark Claims Period (see below).

   o  TLD: Top Level Domain Name, see [RFC1591]

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

   o  Trademark Claims, Claims: Trademark Claims should enhance
      understanding of the Trademark rights being claimed by the
      Trademark Holder.

   o  Trademark Claims Notice, Claims Notice: A Trademark Claims Notice
      consist of Trademark Claims (see above) provided in real time to
      prospective Registrants of Domain Names.

   o  Trademark Claims Notice Identifier, Claims Notice Identifier,
      Claims Notice ID: Part of the Trademark Claims Notice (see above),
      identifying said Claims Notice.  During Trademark Claims period it
      is used to confirm to the Registry that the Claims Notice has been
      fetched from the TMCH and the Registrant has agreed to the Claims
      Notice.

   o  Trademark Claims Period: During this period, a special process
      applies to DNs matching DNL of a PRM, to ensure a TMH gets
      informed on the registration of a domain name matching his PRM.
      For DNs matching DNL of a PRM, Registrars show a Trademark Claims
      Notice to prospective Registrants to be acknowledged.

   o  TMCH, Trademark Clearing House: The Trademark Clearinghouse is an
      ICANN central repository for information to be authenticated,
      stored, and disseminated, pertaining to the rights of trademark
      holders.  The Clearinghouse is split into two functions TMV and
      TMDB (see below).  There are several entities carrying out the TMV
      function, but only one single entity performing the TMDB function.

   o  TMDB, Trademark Clearinghouse Database: Serves as a database of
      the TMCH to provide information to the new gTLD Registries and

Lozano & Hoeneisen     Expires September 13, 2013               [Page 7]
Internet-Draft       TMCH functional specifications           March 2013

      Registrars to support Sunrise or Trademark Claims Services.  There
      is only one TMDB in the TMCH Global System that concentrates the
      information about the "verified" Trademark records from the
      different TMVs.

   o  TMH, Trademark Holder: The person or organization owning rights on
      a Trademark.

   o  TMV, Trademark Validator, Trademark validation organization: An
      entity authorized by ICANN to authenticate and validate
      registrations ensuring the marks qualify as registered or are
      court-validated marks or marks that 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.

   o  UTC: Coordinated Universal Time, as maintained by the Bureau
      International des Poids et Mesures (BIPM); see also [RFC3339].

4.  Requirements

   TBD

Lozano & Hoeneisen     Expires September 13, 2013               [Page 8]
Internet-Draft       TMCH functional specifications           March 2013

5.  Architecture

5.1.  Sunrise Period

   Architecture Sunrise Period

                       SMD hand over (out of band;
                       trivial if Registrant == TMH)
              ...........................................
              :                                         :
              :           .'''''''''''''''''''.         :
              :           .       TMCH        .         :
              :           .....................         :
              v           .                   .         :
       .------------.     .  .-------------.  . hv   .-----.
       | Registrant |     .  |     TMV     |<------->| TMH |
       '------------'     .  '-------------'  .  vh  '-----'
             |            .     |       ^   \ .
             |            .     |       |    \.
          tr |            .  vs |       |     \
             |            .     |       | dv  .\
             v            .     v       |     . \
       .-----------.  sr  .   .---.     |     .  \
    .->| Registrar |<.........| S |  vd |     .   \
    :  '-----------'      .   | M |     |     .    \
    :        |        sy  .   | D |     v     .     \
    :     ry |    .-----------| M |   .---.   .   vc \
    :        |    |       .   '---'   | T |   .       \
    :        v    v       .           | M |   .        v
    :  .-----------.      .           | D |   .   .----------.
    :  | Registry  |----------------->| B |   .   | ICANN-CA |
    :  '-----------'      .       yd  '---'   .   '----------'
    :        ^            .                   .      |    :
    :        |             '''''''''''''''''''       |    :
    :        | cy                                    |    :
    : cr     '---------------------------------------'    :
    :.....................................................:

                                 Figure 1

Lozano & Hoeneisen     Expires September 13, 2013               [Page 9]
Internet-Draft       TMCH functional specifications           March 2013

5.2.  Trademark Claims Period

   Architecture Trademark Claims Period

                       .'''''''''''''.
                       .    TMCH     .
                       ...............
                       .             .
    .------------.     .  .-------.  . hv   .-----.
    | Registrant |     .  |  TMV  |<------->| TMH |
    '------------'     .  '-------'  .  vh  '-----'
           |           .      ^      .
        tr |           .      | dv   .
           |           .   vd |      .
           v           .      v      .
    .-----------.  dr  .  .-------.  .
    | Registrar |<--------|   T   |  .
    '-----------'      .  |       |  .
           |           .  |   M   |  .
        ry |           .  |       |  .
           v           .  |   D   |  .
     .----------.  dy  .  |       |  .
     | Registry |<------->|   B   |  .
     '----------'   yd .  '-------'  .
                       .             .
                        '''''''''''''

                                 Figure 2

5.3.  Interfaces

   In the following sub-sections a short description of each interface
   to provide an overview of the architecture.  More detailed
   descriptions of the relevant interfaces follow further below
   (Section 6).

5.3.1.  hv

   Via the hv interface the TMH registers a mark with a TMV.

   After the successful registration of the mark, the TMV makes
   available a SMD (Signed Mark Data) file (see also Section 7.3) to the
   TMH to be used during Sunrise Period.

   The specifics of the hv interface are beyond the scope of this
   document.

Lozano & Hoeneisen     Expires September 13, 2013              [Page 10]
Internet-Draft       TMCH functional specifications           March 2013

5.3.2.  vd

   After successful mark registration, the TMV ensures the TMDB inserts
   the corresponding DNLs and mark information into the database via the
   vd interface.

   The specifics of the vd interface are beyond the scope of this
   document.

5.3.3.  dy

   Not used during the Sunrise Period.

   During the Trademark Claims Period the Registry fetches the latest
   DNL list from the TMDB via the dy interface in regular intervals.
   The protocol used on the dy interface is SFTP.

5.3.4.  tr

   Via the tr interface the Registrant communicates with the Registrar.
   Every Registrar is free to use its own protocol.

   The specifics of the tr interface are beyond the scope of this
   document.

5.3.5.  ry

   Via the ry interface the Registrar communicate with the Registry.
   The ry interfaces is typically implemented in EPP [RFC5730].  TMCH
   specific EPP extensions are to be developed by the community, mainly
   by Registries and Registrars.

5.3.6.  dr

   Not used during the Sunrise Period.

   During the Trademark Claims Period the Registrar fetches the
   Trademark Claims Notice from the TMDB (to be displayed to the
   Registrant via the tr interface) via the dr interface.  The protocol
   used for fetching the Trademark Claims Notice is HTTPS [RFC2818].

5.3.7.  yd

   During the Sunrise period the Registry notifies the TMDB daily via
   the yd interface of all domain names registered.  (Note: Only domain
   names matching a DNL of a PRM can be registered during the Sunrise
   Period.)

Lozano & Hoeneisen     Expires September 13, 2013              [Page 11]
Internet-Draft       TMCH functional specifications           March 2013

   During the Trademark Claims period, the Registry notifies daily the
   TMDB via the yd interface of all domains registered that included a
   Claims Notice Identifier during the creation of the domain name.

   The protocol used on the yd interface is SFTP.

5.3.8.  dv

   Via the dv interface the TMDB notifies the TMV of all domains
   registered as informed by Registries.

   The specifics of the dv interface are beyond the scope of this
   document.

5.3.9.  vh

   Via the vh interface the TMV notifies the TMH after a domains has
   been registered that matches a PRM of this TMH.

   The specifics of the vh interface are beyond the scope of this
   document.

5.3.10.  vs

   Via the vs interface the TMV requests to add a revoked SMD to the
   list of revoked SMDs at the SMDM.

   The specifics of the vs interface are beyond the scope of this
   document.

   Not relevant during the Trademark Claims Period.

5.3.11.  sy

   During the Sunrise Period the Registry fetches the most recent list
   of revoked SMDs from the SMDM via the sy interface in regular
   intervals.  The protocol used on the sy interface is SFTP.

   Not relevant during the Trademark Claims Period.

5.3.12.  sr

   During the Sunrise Period the Registrar may fetch the most recent
   list of revoked SMDs from the SMDM via the sr interface.  The
   protocol used on the sr interface is the same as on the sy interface
   (s. above), i.e.  SFTP.

   Not relevant during the Trademark Claims Period.

Lozano & Hoeneisen     Expires September 13, 2013              [Page 12]
Internet-Draft       TMCH functional specifications           March 2013

5.3.13.  vc

   Via the vc interface the TMV requests to add a revoked TMV
   certificate to the CRL at the ICANN-CA.

   The specifics of the vc interface are beyond the scope of this
   document.

   Not relevant during the Trademark Claims Period.

5.3.14.  cy

   During the Sunrise Period the Registry fetches the most recent CRL
   from the ICANN-CA via the cy interface in regular intervals.  The CRL
   is mainly used for validation of TMV certificates.  The protocol used
   on the cy interface is HTTPS [RFC2818].

   Not relevant during the Trademark Claims Period.

5.3.15.  cr

   During the Sunrise Period the Registrar may fetch the most recent CRL
   from the ICANN-CA via the cr interface.  The protocol used on the cr
   interface is the same as on the cy interface (s. above).

   Not relevant during the Trademark Claims Period.

6.  Process Decriptions

6.1.  Bootstrap

6.1.1.  Registries

6.1.1.1.  Credentials

   All Registries receive credentials to be used:

   o  during the Sunrise Period to fetch the lists of revoked SMDs from
      the SMDM via the sy interface (Section 5.3.11).

   o  during Trademark Claims Period to fetch the lists of DNL from the
      TMDB via the dy interface (Section 5.3.3).

   o  during the NORDN process to notify the LORDN to the TMDB via the
      yd interface (Section 5.3.7).

Lozano & Hoeneisen     Expires September 13, 2013              [Page 13]
Internet-Draft       TMCH functional specifications           March 2013

6.1.1.2.  TMCH Trust Anchor

   All Registries fetch the X.509 certificate ([RFC5280] / [RFC6818]) of
   the ICANN-CA (Trust Anchor) from < https://ca.icann.org/tmch.crt > to
   be used:

   o  during the Sunrise Period to validate the TMV's certificates and
      the CRL of TMV certificates.

6.1.1.3.  TMDB/SMDM PGP Key

   All Registries receive the public portion of the PGP Key used by TMDB
   and SMDM, from the TMDB administrator to be used:

   o  during the Sunrise Period to perform integrity checking of the
      list of revoked SMDs fetched from the SMDM via the sy interface
      (Section 5.3.11).

   o  during Trademark Claims Period to perform integrity checking of
      the list of DNL fetched from the TMDB via the dy interface
      (Section 5.3.3).

6.1.2.  Registrars

6.1.2.1.  Credentials

   All Registrars receive credentials to be used:

   o  during the Sunrise Period to (optionally) fetch the lists of
      revoked SMDs from the SMDM via the sr interface (Section 5.3.12).

   o  during Trademark Claims Period to fetch Claims Notices from the
      TMDB via the dr interface (Section 5.3.6).

6.1.2.2.  TMCH Trust Anchor

   Registrars may fetch the X.509 certificate ([RFC5280] / [RFC6818]) of
   the ICANN-CA (Trust Anchor) from < https://ca.icann.org/tmch.crt > to
   be used:

   o  during the Sunrise Period to (optionally) validate the TMV's
      certificates and the CRL of TMV certificates.

6.1.2.3.  TMDB PGP Key

   Registrars receive the public portion of the PGP Key used by TMDB and
   SMDM from the TMDB administrator to be used:

Lozano & Hoeneisen     Expires September 13, 2013              [Page 14]
Internet-Draft       TMCH functional specifications           March 2013

   o  during the Sunrise Period to (optionally) perform integrity
      checking of the list of revoked SMDs fetched from the SMDM via the
      sr interface (Section 5.3.12).

6.1.2.4.  IP Addresses for Access Control

   The Registrars need to provide to the TMDB administrator all IP
   addresses, which are used by their hosts to fetch Trademark Claims
   Notices via the dr interface (Section 5.3.6).  The TMDB restricts
   access to known IP Addresses only.  This access restriction is
   applied in addition to HTTP Basic access authentication (for
   credentials to be used, see Section 6.1.2.1).

Lozano & Hoeneisen     Expires September 13, 2013              [Page 15]
Internet-Draft       TMCH functional specifications           March 2013

6.2.  Sunrise Period

6.2.1.  Domain Registration

   Registration during Sunrise Period

   .------------.  .-----------.                 .----------.
   | Registrant |  | Registrar |                 | Registry |
   '------------'  '-----------'                 '----------'
          |              |                             |
          |  Request DN  |                             |
          | Registration |                             |
          |  (with SMD)  |                             |
          |------------->|    Check DN availability    |
          |              |---------------------------->|
          |              |                             |
          |              |.-------. DN unavail. .-------------.
          |              || ABORT |<-----------( DN available? )
          |              |'-------'          no '-------------'
          |              |                             | yes
          |              |                             |
          |              |             .-------------------------------.
          |              |             |       Validate SMD and        |
          |              |             | corresponding TMV certificate |
          |              |             '-------------------------------'
          |              |                             |
          |              |                             |
          |              |.-------. Error  .----------------------.
          |              ||  TRY  |<------( Validation successful? )
          |              || AGAIN |     no '----------------------'
          |              ||  OR   |                    | yes
          |              || ABORT |                    |
          |              |'-------'           .-----------------.
          |              |                    | Add DN to LORDN |
          |              |                    '-----------------'
          |              |                             |
          |              |   DN registered             |
          |  DN regist.  |<----------------------------|
          |<-------------|                             |
          |              |                             |
          |              |                             |

                                 Figure 3

Lozano & Hoeneisen     Expires September 13, 2013              [Page 16]
Internet-Draft       TMCH functional specifications           March 2013

6.2.2.  DN Registration by Registries

   Registries MUST perform a minimum set of checks for verifying DN
   registrations during Sunrise Period upon reception of a registration
   request over the ry interface (Section 5.3.5).  If any of these
   checks fails the Registry MUST abort the DN registration.  Each of
   these checks MUST be performed before the DN is Allocated (see
   Section 3).

   Performing the minimum set of checks Registries MUST verify that:

   1.   The IP address of the Registrant has been received from the
        Registrar along with the DN registration.

   2.   The IP address used by the Registrant is a global unicast IP
        address, in particular it is not a private IP address as defined
        in [RFC1918].  This check is only required, if the IP address of
        the Registrant has been provided by the Registrar.

   3.   An SMD has been received from the Registrar along with the DN
        registration.

   4.   The certificate of the TMV has been correctly signed by the
        ICANN-CA.  (The certificate of the TMV is contained within the
        SMD.)

   5.   The validity period of the TMV certificate is within the allowed
        range.

   6.   The Key Usage extension in the TMV certificate is marked as
        "critical" [RFC5280]

   7.   Only the "digitalSignature" bit (Key Usage) is set and no
        Extended Key Usage is set in the TMV certificate [RFC5280].

   8.   The certificate of the TMV is not be listed in the CRL file
        specified in the CRL distribution point of the TMV certificate.

   9.   The signature of the SMD (signed with the TMV certificate) is
        valid.

   10.  The validity period of the SMD is within the allowed range
        (<smd:notBefore> and <smd:notAfter> elements).

   11.  The SMD has not been revoked, i.e. is not contained in the SMD
        revocation list.

Lozano & Hoeneisen     Expires September 13, 2013              [Page 17]
Internet-Draft       TMCH functional specifications           March 2013

   12.  The DN being registered matches at least one of the labels
        (<mark:label>) elements in the SMD.

   For any date or time indications, Coordinated Universal Time (UTC)
   applies.

   Note: 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 accepts registrations for.

6.2.3.  TMCH Sunrise Services for Registries

6.2.3.1.  SMD Revocation List

   A new SMD revocation list is published by the SMDM twice a day,
   namely at 00:00 and 12:00 UTC.

   Registries MUST download the latest version of the SMD revocation
   list at least once in 24 hours.

   Update SMD revocation list

       .----------.                                             .------.
       | Registry |                                             | SMDM |
       '----------'                                             '------'
             |                                                      |
    .----------------.                                              |
    |  Periodically, |                                              |
    |    at least    |                                              |
    | every 24 hours |                                              |
    '----------------'                                              |
             |                                                      |
             |----------------------------------------------------->|
             | Download latest revocation list for SMD certificates |
             |<-----------------------------------------------------|
             |                                                      |
             |                                                      |

                                 Figure 4

6.2.3.2.  Certificate Revocation List

   Registries MUST update their local copy of the CRL at least every 4
   hours using the CRL distribution point specified in the TMV
   certificate.

Lozano & Hoeneisen     Expires September 13, 2013              [Page 18]
Internet-Draft       TMCH functional specifications           March 2013

   Operationally, the CRL file and CRL distribution point is the same
   for all TMVs and (at publication of this document) located at
   < https://crl.icann.org/tmch.crl >.

   Update SMD revocation list

      .----------.                                 .----------.
      | Registry |                                 | ICANN-CA |
      '----------'                                 '----------'
            |                                            |
    .---------------.                                    |
    | Periodically, |                                    |
    |   at least    |                                    |
    | every 4 hours |                                    |
    '---------------'                                    |
            |                                            |
            |------------------------------------------->|
            |  Download latest CRL for TMV certificates  |
            |<-------------------------------------------|
            |                                            |
            |                                            |

                                 Figure 5

6.2.3.3.  Notice of Registered Domain Names

   The Registry MUST send the LORDN file containing all DNs registered
   on the previous calendar day (UTC), to the TMDB (over the yd
   interface, Section 5.3.7) between midnight and 3 a.m.  UTC.

   If a new LORDN file (containing the registered DNs for the same date)
   is uploaded before 3 a.m.  UTC, the previous LORDN file is discarded
   and the new LORDN file is processed instead.  At 3 a.m.  UTC, the
   last uploaded LORDN file is considered final, given no ERRORs (i.e.
   only OKs and warnings) occur during the processing of the file at the
   TMDB.  If a LORDN file is considered final, it is stored in the TMDB,
   and information is sent to the TMVs for informing the TMHs.  Any
   LORDN file (for the same date) that is uploaded later than 3 a.m.
   will be ignored.

   For any date or time indications, Coordinated Universal Time (UTC)
   applies.

Lozano & Hoeneisen     Expires September 13, 2013              [Page 19]
Internet-Draft       TMCH functional specifications           March 2013

   NORDN

        .----------.            .------.          .-----.        .-----.
        | Registry |            | TMDB |          | TMV |        | TMH |
        '----------'            '------'          '-----'        '-----'
              |                     |                |              |
    .------------------.      .-----------.          |              |
    | Periodically,    |      | Wait for  |<-------. |              |
    | every 24 hours   |      | LORDN     |        | |              |
    | (between 0 and 3 |      '-----------'        | |              |
    | o'clock UTC)     |            |              | |              |
    '------------------'            |              | |              |
              |                     |              | |              |
   .--------->|     Upload LORDN    |              | |              |
   |          |-------------------->|              | |              |
   |          |                     |              | |              |
   |          |        .-------------------------. | |              |
   |          |        | Verify each domain name | | |              |
   |          |        |   in the uploaded file  | | |              |
   |          |        |  and write results to a | | |              |
   |          |        |  .err-file (within 30') | | |              |
   |          |        '-------------------------' | |              |
   |          |                     |              | |              |
   |          |  Download .err file |              | |              |
   |          |<--------------------|              | |              |
   |          |                     |              | |              |
   | .-----------------.    .---------------.      | |              |
   | |  Check whether  |   / everything fine \ no  | |              |
   | |    .err-file    |  (  (i.e. no errors  )----' |              |
   | | contains errors |   \ in .err-file)?  /       |              |
   | '-----------------'    '---------------'        |              |
   |          |                     | yes            |              |
   |  .---------------.             |                |              |
   | / everything fine \ yes        |                |              |
   |(  (i.e. no errors  )-----.     |  Notify TMVs   |              |
   | \ in .err-file)?  /      |     |  on the LORDN  |              |
   |  '---------------'       |     | pre-registered |              |
   |          | no            v     |  with said TMV |              |
   | .----------------.   .------.  |--------------->|              |
   '-| Correct Errors |   | DONE |  |                |              |
     '----------------'   '------'  |                | Notify each  |
              |                     |                | affected TMH |
              |                     |                |------------->|
              |                     |                |              |
              |                     |                |              |

                                 Figure 6

Lozano & Hoeneisen     Expires September 13, 2013              [Page 20]
Internet-Draft       TMCH functional specifications           March 2013

   The format used for the LORDN is described in Section 7.2

6.2.4.  DN registration by Registrars

   Registrars MAY choose to perform the checks for verifying DN
   registrations as performed by the Registries (see Section 6.2.2)
   before sending the application to register a DN.

   Registrars MUST forward the SMD received from the Registrant along
   with the IP address seen on tr interface (Section 5.3.4); i.e. the IP
   address used by the customer who submitted the application for
   registration of the DN.

6.2.5.  TMCH Sunrise Services for Registrars

   The processes described in Section 6.2.3.1 and Section 6.2.3.2 are
   also available for Registrars to optionally validate the SMDs
   received.

6.3.  Trademark Claims Period

6.3.1.  Domain Registration

Lozano & Hoeneisen     Expires September 13, 2013              [Page 21]
Internet-Draft       TMCH functional specifications           March 2013

   Registration during Trademark Claims Period

   .------------.  .-----------.                 .----------.   .------.
   | Registrant |  | Registrar |                 | Registry |   | TMCH |
   '------------'  '-----------'                 '----------'   '------'
          |              |                             |            |
          |  Request DN  |                             |            |
          | Registration |    Check DN availability    |            |
          |------------->|---------------------------->|            |
          |              |                             |            |
          |              |.-------. DN unavail. .-------------.     |
          |              || ABORT |<-----------( DN available? )    |
          |              |'-------'          no '-------------'     |
          |              |                             | yes        |
          |              |       DN available &   .---------.       |
          |              |.----------. no claim  /  Does DN  \      |
          |              || CONTINUE |<---------(  match DNL  )     |
          |              || NORMALLY |        no \  of PRM?  /      |
          |              |'----------'            '---------'       |
          |              |                             | yes        |
          |              |    DN avail./claims exists  |            |
          |              |     (Lookup Key included)   |            |
          |              |<----------------------------|            |
          |              |                             |            |
          |              |    Request Claims Notice                 |
          |   Display    |----------------------------------------->|
          |   Claims     |                                          |
          |   Notice     |               Return Claims Notice       |
          |<-------------|<-----------------------------------------|
          |              |                                          |
          |              |         Register DN                      |
      .------.  yes      | (Claims Notice ID included) |            |
     ( Agree? )--------->|---------------------------->|            |
      '------'           |                             |            |
          ||no           |.-------. Error .----------------------.  |
          ||  .-------.  ||  TRY  |<-----( Validation successful? ) |
          |'->| ABORT |  || AGAIN |    no '----------------------'  |
          |   '-------'  ||  OR   |                    | yes        |
          |              || ABORT |           .-----------------.   |
          |              |'-------'           | Add DN to LORDN |   |
          |              |                    '-----------------'   |
          |  DN regist.  |   DN registered             |            |
          |<-------------|<----------------------------|            |
          |              |                             |            |
          |              |                             |            |

                                 Figure 7

Lozano & Hoeneisen     Expires September 13, 2013              [Page 22]
Internet-Draft       TMCH functional specifications           March 2013

6.3.2.  DN registration by Registries

   During Trademark Claim Periods, Registries perform two main
   functions:

   o  Whenever a Registrar queries the domain availability that matches
      a DNL of a PRM (over the ry interface, Section 5.3.5) for
      availability, the Registry MUST return the corresponding Lookup
      Key.

   o  For any DN matching a DNL of a PRM, Registries MUST perform a
      minimum set of checks for verifying DN registrations during
      Trademark Claims Period upon reception of a registration request
      over the ry interface (Section 5.3.5).  If any of these checks
      fails the Registry MUST abort the DN registration.  Each of these
      checks MUST be performed before the DN is Allocated (see
      Section 3).  Performing the minimum set of checks Registries MUST
      verify that:

      1.  The Claims Notice Identifier, expiration date of the Trademark
          Claim notice and the IP address of the Registrant have been
          received from the Registrar along with the DN registration.
          If the expiration date, Claims Notice Identifier and IP
          address of the Registrant is not provided during registration
          and the DNL was inserted (or re-inserted) into the list of DNL
          less than 24 hours ago, the registration MAY continue without
          this data.  (Note that such DN registrations MUST also be
          included to the LORDN.)

      2.  The claim notice has not expired (using the expiration date
          (<tmNotice:notAfter>).  This check is REQUIRED only if the
          expiration date has been provided by the Registrar.

      3.  The IP address used by the Registrant is a global unicast IP
          address, in particular it is not a private IP address as
          defined in [RFC1918].  This check is only required, if the IP
          address of the Registrant has been provided by the Registrar.

   For any date or time indications, Coordinated Universal Time (UTC)
   applies.

   Note: 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 accepts registrations for.

   Note: Even if a Claims Notice Identifier is provided for a DN not
   present in the DNL list, the Registry MUST include this DN
   registration in the LORDN file.

Lozano & Hoeneisen     Expires September 13, 2013              [Page 23]
Internet-Draft       TMCH functional specifications           March 2013

6.3.3.  Trademark Claims Services for Registries

6.3.3.1.  Domain Name Label (DNL) List

   A new DNL list is published by the TMDB twice a day, namely at 00:00
   and 12:00.

   Registries MUST download the latest version of the DNL list at least
   once in 24 hours.

   Update DNL list

       .----------.                        .------.
       | Registry |                        | TMDB |
       '----------'                        '------'
             |                                 |
    .----------------.                         |
    |  Periodically, |                         |
    |    at least    |                         |
    | every 24 hours |                         |
    '----------------'                         |
             |                                 |
             |-------------------------------->|
             |  Download latest list of DNLs   |
             |<--------------------------------|
             |                                 |
             |                                 |

                                 Figure 8

6.3.3.2.  Notice of Registered Domain Names

   The NORDN process during the Trademark Claims Period is almost the
   same as during Sunrise Period as defined in Section 6.2.3.3 with the
   only difference that just registrations subject to a Trademark Claim
   are included in the LORDN.

6.3.4.  DN Registration by Registrars

   For any DN matching a DNL of a PRM, Registrars MUST perform the
   following steps:

   1.  Use the Lookup Key received from the Registry (while verifying DN
       availability) to obtain the Claims Notice from the TMDB using the
       dr interface (Section 5.3.6)

Lozano & Hoeneisen     Expires September 13, 2013              [Page 24]
Internet-Draft       TMCH functional specifications           March 2013

   2.  Present the Claims Notice to the Registrant as described in
       [ICANN-GTLD-AGB-20120604].

   3.  Ask Registrant for confirmation, i.e. the Registrant MUST consent
       with the Claims Notice, before any further processing.  (The
       transmission of a Trademark Claims Identifier to the Registry
       (over the ry interface, Section 5.3.5) implies that the
       Registrant has expressed his consent with the Claims Notice.)

   4.  Record the IP address as seen on tr interface (Section 5.3.4,
       i.e. the IP address used by the customer who submitted the
       application for registration of the DN)

   5.  Perform the minimum set of checks for verifying DN registrations.
       If any of these checks fails 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 that:

       1.  The claim notice has not expired (using expiration date
           (<tmNotice:notAfter>).

       2.  The DN being registered matches the label (<tmNotice:label>)
           element in the Trademark Claim Notice.

       3.  The Registrant has acknowledged (expressed his consent with)
           the Claims Notice.

   6.  Send the registration to the Registry (ry interface,
       Section 5.3.5) and include the following information:

       *  recorded IP address as seen on tr interface

       *  Trademark Claims Identifier (<tmNotice:id>)

       *  Expiration date of the claims notice (<tmNotice:notAfter>)

   Note: Claims notices are generated twice a day, namely at 00:00 and
   12:00 UTC.  The expiration date of the claims notice is set to 48
   hours in the future, allowing the implementation of a cache within
   the Registrar and enough time for the registration workflow process
   to finalize.  Registrars SHOULD implement a cache of claims notices
   to minimize the number of queries sent to the TMDB.  The TMDB
   implements rate-limiting as one of the protection mechanisms to
   mitigate the risk of performance degradation.

Lozano & Hoeneisen     Expires September 13, 2013              [Page 25]
Internet-Draft       TMCH functional specifications           March 2013

6.3.5.  Tradermark Claims Services for Registrars

6.3.5.1.  Claims Notice Information Service

   The Trademark Claims Notices are provided by the TMDB online and are
   fetched by the Registrar via the dr interface (Section 5.3.6).  To
   get access to the Trademark Claims Notices, the Registrar needs the
   credentials provided by the TMDB (Section 6.1.2.1) and the Lookup Key
   received from the Registry via the ry interface (Section 5.3.5).  The
   dr interface (Section 5.3.6) uses HTTPS with Basic access
   authentication.  Furthermore the Registrar has to ensure that all IP
   addresses used by his own systems on dr interface have been informed
   to the TMDB to be entered into the list known IP Addresses
   (Section 6.1.2.4).

   The URL of the dr interface (Section 5.3.6) is:
   < https://<tmdb-domain-name>/cnis/<lookupkey>.xml.gz >

   The TLS certificate (HTTPS) used on the dr interface (Section 5.3.6)
   MUST be signed by a well know public CA.

7.  Data Format Descriptions

7.1.  DNL List file

   This section defines format of the list containing every Domain Name
   Label (DNL) that matches a Pre-Registered Mark (PRM).  The list is
   maintained by the TMDB and downloaded by Registries in regular
   intervals (see Section 6.3.3.1).  The Registries use the DNL list
   during the Trademark Claims period to check whether a requested DN
   matched a DNL of a PRM.

   The DNL list is contained in a CSV file that has the following
   structure:

   o  first line: <version>,<creation date/time>

   o  One or more lines with: <DNL>,<Lookup Key>,<unixtimestamp inserted
      to the DNL>

Lozano & Hoeneisen     Expires September 13, 2013              [Page 26]
Internet-Draft       TMCH functional specifications           March 2013

   Example for DNL list

   1.0,1362965626
   example, j8f/KR6/Dex/T4H/dac5KfM3FKhevbYEaevbYddfEr,1362955239
   another-example,lj3/l4F/dsd/33F/f434HGgsfeg44HGgsfeg42l5Ts,1362955316
   anotherexample, h7h/nm9/FEJ/NJ4/iHHtFJL8f2mkHtFL8f2mkj3d2c,1362956532

                                 Figure 9

   To provide authentication and integrity protection, the DNL list is
   PGP [RFC4880] signed by the TMDB with the private key of the TMDB
   (see also Section 6.1.1.3).  The DNL list is provided by the TMDB as
   gzip [RFC1952] compressed tarball containing two files:

   o  CSV

   o  PGP Signature

7.2.  LORDN File

   This section defines the format of the List of Registered Domain
   Names (LORDN), which is maintained by each Registry and uploaded
   daily to the TMDB.  Every time a DN matching a DNL of a PRL said DN
   is added to the LORDN along with further information related to its
   registration.

   The LORDN is contained in a CSV file that has the following
   structure:

   o  For Sunrise Period:

      *  first line: <version>,<creation-date/
         time>,<date-of-registrations>

      *  One or more lines with: <roid>,<domain-name>,<smd-id>,<IANA-
         registrar-id>,<unixtimestamp-of-registration>,<registrant-IP>

   o  For Trademark Claims Period:

      *  first line: <version>,<creation date/time>,<date of
         registrations>

      *  One or more lines with: <roid>, <domain-
         name>,<tmNoticeID>,<IANA-registrar-id>,<unixtimestamp-of-
         registration>,<registrant-IP>

Lozano & Hoeneisen     Expires September 13, 2013              [Page 27]
Internet-Draft       TMCH functional specifications           March 2013

   Example for LORDN

   1.0,1362965626,2013-02-27
   SH8013-REP,example1.gtld,j8yKR69DevT5KfM3FKhevbjqd680YEr, \
       977,1362965626,128.66.3.73
   EK77-REP,example2.gtld,l5Fdssa5G333lj324lF4Fyds2d3v3Ff, \
       6,1362965626,128.66.0.19
   HB800-REP,example3.gtld,tbk56h7hgndm96FEvJ64UNJRi66H4Ht, \
       1238,1362965626,2001:DB8::dead:c0:ffee

                                 Figure 10

7.2.1.  LORDN Log File

   After reception of the LORDN File, the TMDB verifies its content for
   syntactical and semantical correctness and writes the results of this
   check to a log file (suffix .log).  It uses return codes to indicate
   success, warning or error.

   In case there are warnings or errors, additional files are generated,
   i.e.:

   o  a file with suffix .warn contains only the warnings, if any

   o  a file with suffix .err contains only the errors, if any

   The LORDN log file is contained in a CSV file that has the following
   structure:

   o  first line: <version>,<creation-unixtimestamp>,<creation-
      unixtimestamp-of-LORDN-file>,<date-of-registrations>

   o  One or more lines with: <roid>,<error-code>

   Example for LORDN Logfile

   1.0,1362965626,1362965624,2013-02-27
   SH8013-REP,2202
   EK77-REP,1020
   HB800-REP,2032

                                 Figure 11

Lozano & Hoeneisen     Expires September 13, 2013              [Page 28]
Internet-Draft       TMCH functional specifications           March 2013

7.2.2.  LORDN Error Codes

   TBD

7.3.  SMD File

   This section defines the format of the SMD File.  After a successful
   registration of a mark, TMV returns an SMD 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.

   Two encapsulation boundaries are defined for delimiting the
   encapsulated base64 encoded SMD, i.e. "-----BEGIN ENCODED SMD-----"
   and "-----END ENCODED SMD-----".  Only data inside the encapsulation
   boundaries MUST be used by Registries (and Registrars) for validation
   purposes, i.e. any data outside these boundaries as well as the
   boundaries themselves MUST be ignored for validation purposes.

   The structure of the SMD File is as follows:

   o  Marks: <marks>

   o  smdID: <smd-ID>

   o  U-labels: <comma separated list of U-labels>

   o  notBefore: <begin validity>

   o  notAfter: <end validity>

   o  -----BEGIN ENCODED SMD-----

   o  <encoded SMD (see [I-D.lozano-tmch-smd])>

   o  -----END ENCODED SMD-----

Lozano & Hoeneisen     Expires September 13, 2013              [Page 29]
Internet-Draft       TMCH functional specifications           March 2013

   Example for SMD File (shortened at [...])

   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
   YXJrLTEuMCIgaWQ9InNpZ25lZE1hcmsiPgogIDxzbWQ6aWQ+MS0yPC9zbWQ6aWQ+
   [...]
   cnRpZmljYXRlPgo8L1g1MDlEYXRhPgogICAgPC9LZXlJbmZvPgogIDwvU2lnbmF0
   dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo=
   -----END ENCODED SMD-----

                                 Figure 12

7.4.  SMD revocation list

   This section defines format of the list of SMDs that have been
   revoked.  The list is maintained by the SMDM and downloaded by
   Registries (and optionally by Registrars) in regular intervals (see
   Section 6.2.3.1).  The SMD revocation list is used during the Sunrise
   Period to validate SMDs received.  The SMD revocation list has a
   similar function as CRLs used in PKI [RFC5280] / [RFC6818].

   The SMD revocation list is contained in a CSV file that has the
   following structure:

   o  first line: <version>,<creation-unixtimestamp>

   o  One or more lines with: <smd-id>

   Example for SMD Revocation list

   1.0,1362965626
   cdfghjtedxcvbnjrewsdsbhhjkjkllllt
   avixukrjfiknenncl2dd45ggsdt456hyt
   jwmchtgenblksalalotlajhhfddfasfee

                                 Figure 13

   To provide integrity protection, the SMD revocation list is PGP

Lozano & Hoeneisen     Expires September 13, 2013              [Page 30]
Internet-Draft       TMCH functional specifications           March 2013

   [RFC4880] signed by the TMDB with the private key of the TMDB (see
   also Section 6.1.1.3).  The SMD revocation list provided is provided
   by the TMDB as gzip [RFC1952] compressed tarball containing two
   files:

   o  CSV

   o  PGP Signature

7.5.  Trademark Claims Notice

   The TMDB provides the Trademark Claim Notice to Registrars as an XML
   file compressed using gzip.

   Example of <tmNotice:notice> object:

 <tmNotice:notice xmlns:tmNotice="urn:ietf:params:xml:ns:tm-notice-1.0">
   <tmNotice:id>AJDJEICMEOWALWJFIWJWJELEL53454345343</tmNotice:id>
   <tmNotice:notBefore>2009-08-16T09:00:00.0Z</tmNotice:notBefore>
   <tmNotice:notAfter>2010-08-16T09:00:00.0Z</tmNotice:notAfter>
   <tmNotice:label>example-one</tmNotice:label>
   <tmNotice:trademark>
     <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:jurisdiction>US</tmNotice:jurisdiction>
     <tmNotice:classDesc classNum="35">Advertising; business management;
       business administration; office functions</tmNotice:classDesc>
     <tmNotice:classDesc classNum="36">Insurance; financial affairs;
       monetary affairs; real estate affairs</tmNotice:classDesc>
     <tmNotice:goodsAndServices>Dirigendas et eiusmodi
       featuring infringo in airfare et cartam servicia.
     </tmNotice:goodsAndServices>
   </tmNotice:trademark>
   <tmNotice:treatyOrStatute>
     <tmNotice:markName>Example One</tmNotice:markName>
     <tmNotice:holder entitlement="owner">
       <tmNotice:org>Example Inc.</tmNotice:org>

Lozano & Hoeneisen     Expires September 13, 2013              [Page 31]
Internet-Draft       TMCH functional specifications           March 2013

       <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:protection ruling="US">
       <tmNotice:cc>US</tmNotice:cc>
       <tmNotice:region>Puerto Rico</tmNotice:region>
     </tmNotice:protection>
     <tmNotice:goodsAndServices>Dirigendas et eiusmodi
       featuring infringo in airfare et cartam servicia.
     </tmNotice:goodsAndServices>
   </tmNotice:treatyOrStatute>
   <tmNotice:court>
     <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:goodsAndServices>Dirigendas et eiusmodi
       featuring infringo in airfare et cartam servicia.
     </tmNotice:goodsAndServices>
     <tmNotice:cc>US</tmNotice:cc>
   </tmNotice:court>
 </tmNotice:notice>

   Note: this example generates a TRADEMARK NOTICE with three mark
   claims.

   For formal syntax of the Trademark Claims Notice please refer to
   Section 8.1.

8.  Formal Syntax

Lozano & Hoeneisen     Expires September 13, 2013              [Page 32]
Internet-Draft       TMCH functional specifications           March 2013

8.1.  Trademark Claims Notice

   The schema presented here is for the Trademark Claims Notice.

   Copyright (c) 2012 IETF Trust and the persons identified as authors
   of the code.  All rights reserved.

   Redistribution and use in source and binary forms, with or without
   modification, are permitted provided that the following conditions
   are met:

   o  Redistributions of source code must retain the above copyright
      notice, this list of conditions and the following disclaimer.

   o  Redistributions in binary form must reproduce the above copyright
      notice, this list of conditions and the following disclaimer in
      the documentation and/or other materials provided with the
      distribution.

   o  Neither the name of Internet Society, IETF or IETF Trust, nor the
      names of specific contributors, may be used to endorse or promote
      products derived from this software without specific prior written
      permission.

   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
   A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT
   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

 BEGIN
 <?xml version="1.0" encoding="UTF-8"?>
 <schema
   targetNamespace="urn:ietf:params:xml:ns:tm-notice-1.0"
   xmlns:tmNotice="urn:ietf:params:xml:ns:tm-notice-1.0"
   xmlns:mark="urn:ietf:params:xml:ns:mark-1.0"
   xmlns="http://www.w3.org/2001/XMLSchema"
   elementFormDefault="qualified">

   <annotation>
     <documentation>

Lozano & Hoeneisen     Expires September 13, 2013              [Page 33]
Internet-Draft       TMCH functional specifications           March 2013

       Schema for representing a Trademark Notice.
     </documentation>
   </annotation>

   <import namespace="urn:ietf:params:xml:ns:mark-1.0"
     schemaLocation="mark-1.0.xsd" />

   <element name="notice" type="tmNotice:noticeType"/>

   <complexType name="holderType">
     <sequence>
       <element name="org" type="token" minOccurs="0"/>
       <element name="addr" type="tmNotice:addrType"/>
     </sequence>
     <attribute name="entitlement" type="mark:entitlementType"/>
   </complexType>

   <complexType name="noticeType">
     <sequence>
       <element name="id" type="token"/>
       <element name="notBefore" type="dateTime"/>
       <element name="notAfter" type="dateTime"/>
       <element name="label" type="mark:labelType"/>
       <element name="trademark" type="tmNotice:trademarkType"
         minOccurs="0" maxOccurs="unbounded"/>
       <element name="treatyOrStatute"
         type="tmNotice:treatyOrStatuteType" minOccurs="0"
         maxOccurs="unbounded"/>
       <element name="court" type="tmNotice:courtType" minOccurs="0"
         maxOccurs="unbounded"/>
     </sequence>
   </complexType>

   <complexType name="trademarkType">
     <sequence>
       <element name="markName" type="token"/>
       <element name="holder" type="tmNotice:holderType"
         maxOccurs="unbounded" />
       <element name="jurisdiction" type="mark:ccType"/>
       <element name="classDesc" type="tmNotice:classDescType"
         minOccurs="0" maxOccurs="unbounded"/>
       <element name="goodsAndServices" type="token" />
     </sequence>
   </complexType>

   <complexType name="treatyOrStatuteType">
     <sequence>
       <element name="markName" type="token"/>

Lozano & Hoeneisen     Expires September 13, 2013              [Page 34]
Internet-Draft       TMCH functional specifications           March 2013

       <element name="holder" type="tmNotice:holderType"
         maxOccurs="unbounded" />
       <element name="protection" type="tmNotice:protectionType"
         maxOccurs="unbounded"/>
       <element name="goodsAndServices" type="token" />
     </sequence>
   </complexType>

   <complexType name="courtType">
     <sequence>
       <element name="markName" type="token"/>
       <element name="holder" type="tmNotice:holderType"
         maxOccurs="unbounded" />
       <element name="goodsAndServices" type="token" />
       <element name="cc" type="mark:ccType"/>
     </sequence>
   </complexType>

   <complexType name="classDescType">
     <simpleContent>
       <extension base="token">
         <attribute name="classNum" type="integer" use="required"/>
       </extension>
     </simpleContent>
   </complexType>

   <complexType name="addrType">
     <sequence>
       <element name="street" type="token" minOccurs="1" maxOccurs="3"/>
       <element name="city" type="token"/>
       <element name="sp" type="token" minOccurs="0"/>
       <element name="pc" type="mark:pcType" minOccurs="0"/>
       <element name="cc" type="mark:ccType"/>
     </sequence>
   </complexType>

   <complexType name="protectionType">
     <sequence>
       <element name="cc" type="mark:ccType"/>
       <element name="region" type="token" minOccurs="0"/>
     </sequence>
     <attribute name="ruling" type="mark:ccType"/>
   </complexType>
 </schema>
 END

Lozano & Hoeneisen     Expires September 13, 2013              [Page 35]
Internet-Draft       TMCH functional specifications           March 2013

9.  Status of this Draft

   This (-00) version is intended to provide a first version of the TMCH
   functional specifications.  This draft is the product of several
   discussions regarding the interaction between the TMCH and
   Registries/Registrars.  It does by no means claim to be complete and
   minor updates are likely to be added in future versions of this
   document.

10.  Acknowledgements

   TBD

11.  IANA Considerations

   TBD

12.  Security Considerations

   TBD

13.  References

13.1.  Normative References

   [I-D.lozano-tmch-smd]
              Lozano, G., "Mark and Signed Mark Objects Mapping",
              draft-lozano-tmch-smd-00 (work in progress), March 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

13.2.  Informative References

   [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>.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1591]  Postel, J., "Domain Name System Structure and Delegation",
              RFC 1591, March 1994.

Lozano & Hoeneisen     Expires September 13, 2013              [Page 36]
Internet-Draft       TMCH functional specifications           March 2013

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC1952]  Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G.
              Randers-Pehrson, "GZIP file format specification version
              4.3", RFC 1952, May 1996.

   [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, June 1999.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC3339]  Klyne, G., Ed. and C. Newman, "Date and Time on the
              Internet: Timestamps", RFC 3339, July 2002.

   [RFC4180]  Shafranovich, Y., "Common Format and MIME Type for Comma-
              Separated Values (CSV) Files", RFC 4180, October 2005.

   [RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
              Thayer, "OpenPGP Message Format", RFC 4880, November 2007.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
              STD 69, RFC 5730, August 2009.

   [RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891, August 2010.

   [RFC6818]  Yee, P., "Updates to the Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 6818, January 2013.

Appendix A.  Document Changelog

   [RFC Editor: This section is to be removed before publication]

   draft-lozano-tmch-functional-spec-00:

   o  Initial version

Lozano & Hoeneisen     Expires September 13, 2013              [Page 37]
Internet-Draft       TMCH functional specifications           March 2013

Authors' Addresses

   Gustavo Lozano (editor)
   ICANN
   12025 Waterfront Drive, Suite 300
   Los Angeles  90292
   US

   Phone: +1.3103015800
   Email: gustavo.lozano@icann.org

   Bernie Hoeneisen
   Ucom Standards Track Solutions GmbH
   CH-8000 Zuerich
   Switzerland

   Phone: +41 44 500 52 44
   Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
   URI:   http://www.ucom.ch/

Lozano & Hoeneisen     Expires September 13, 2013              [Page 38]