EPP LaunchPhase Extension: draft requirements and scope

Requirements
--------------------


In Scope
----------

Module 5 of ICANN's gTLD Applicant Guidebook states:

"The registry operator must implement, at a minimum, either a Sunrise 
period or a Trademark Claims service during the start-up phases for 
registration in the TLD. These mechanisms will be supported by the 
established Trademark Clearinghouse as indicated by ICANN."

This extension is designed to meet the requirements of registry 
operators and registrars participating in the Sunrise period of a new 
gTLD during the start-up phase of the gTLD registry, and during the 
additional "Landrush" period which has frequently followed the Sunrise 
period during previous registry launches. During Sunrise and Landrush 
periods, the registry operates under a different model to the standard 
"first-come, first-served", "steady state" or "General Availability" 
model. Specifically:

  * domain names are *not* registered on a "first-come, first-served" 
    basis

      Multiple applications for the same domain name may be received. 
      After an application is received, a <check> for the associated 
      domain name will still return an available result, as other 
      registrars may still submit application requests. The domain name 
      is only provisioned at the end of the specific phase of the 
      launch.

  * All applications made during the Sunrise period must meet minimum 
    Sunrise Eligibility Requirements (SERs), which are validated by the 
    Trademark Clearinghouse

      During the Sunrise period, all applications submitted to the 
      registry must include proof of eligibility. This may include 
      details of an associated trademark, or a token from the Trademark 
      Clearinghouse indicating that the applicant's eligibility has 
      already been validated.

  * Contentious applications for the same domain name are resolved via 
    an out-of-band process

      At the end of the Sunrise and/or Landrush period, all applications 
      are processed by the registry operator. Where there is only a 
      single application for a given domain name, then this domain name 
      is immediately provisioned and associated with the applicant, and 
      the applicant's registrar. Where there are multiple applications 
      for the same domain name, an out-of-band process such as a 
      mediation or auction process is used to determine the final 
      registrant of the domain.


Out of scope
--------------------

This extension does not attempt to solve any other use cases. In 
particular, it is not meant for "steady-state" operations, so any use 
case that may require an extension beyond a phase with a defined window 
of time will not be addressed. For example, if a registry is to be run 
with ongoing eligibility (or "nexus") requirements, then a separate 
extension should be used for these requirements.

1. This extension does not specify any mechanism for performing 
   validation of submitted data. It is assumed to be out of band.

2. Management of the application object on the server side (updating
   status, cancelling an application) [see notes]


Requirements for Registrars
---------------------------

* the extension should not change the semantics of existing commands, 
  objects or object elements, or define new object types

* the extension should allow for applications to be submitted, queried
  (both during and after the launch phase) and cancelled

Requirements for Registries
---------------------------

* the extension should not change the semantics of existing commands, 
  objects or object elements, or define new object types

* The data elements for Sunrise Eligibility Requirements must allow for 
  all possible data required by the Trademark Clearinghouse

* the extension should allow for multiple clearinghouses, and provide a
  way for registrars to indicate which clearinghouse has been used to
  validate an application

* the extension should provide a means to communicate the final outcome 
  of an application after the completion of the Sunrise/Landrush period

Requirements for Trademark Clearinghouses
-----------------------------------------

* Any data passed to the registry by the registrar as part of Sunrise 
  Eligibility Requirements should be complete

NOTES
* the above requirements are a first pass and we are very keen on
  getting feedback from all three stakeholder groups
* this extension will be agnostic on contact (doesn't matter if registry
  is thin/thick) and host mappings (doesn't matter which style is used:
  hostObj / hostAttr)
* can work with instant validation => in which case, registry may
  choose to reject requests that fail online validation, or place object
  into "validated" status immediately if it passes online validation.
* no extension on poll messages - or is that the best way to communicate
  results of end-of-phase processing?
* semantics of <check>
* should we allow updating of lp data e.g. trademark_name?
* [question in the draft] should we allow multiple status values? For
  example, it may make sense to have both the "validated" and
  "allocated" status values.
* proposal: adding a ID "type" field
* do we need to specify management of the object on the backend, i.e.
  updating status, deleting an application, etc.?