Generic Top-Level Domain (gTLD) Registry Agreements
Proposed Unsponsored TLD Agreement: Appendix J (.name)
|
START-UP PLAN ANTICIPATED START-UP PLAN AND LAUNCH DATES
For the purpose of this document, unless otherwise specified, "days" shall mean calendar days. Where a start-date, or termination date as specified in this document falls outside a business day (excluding Saturdays, Sundays and any English public holiday), such day will be rounded to the next following business day.
SERVICE DESCRIPTIONS ICANN-Accredited Registrars that are parties to a Registry-Registrar Agreement ("Authorized Registrars") may offer Phase I Defensive Registrations and Phase II Defensive Registrations (collectively, "Defensive Registrations"), which are described in Appendices C and L. Defensive Registrations may be challenged as described in Appendix M. Authorized Registrars may submit requests for Phase I Defensive Registrations starting sixty (60) days before the Commencement-of-Service Date and ending thirty (30) days before the Commencement-of-Service Date. These registrations will be processed by Registry Operator in a single batch thirty (30) days before the Commencement-of-Service Date. Beginning six (6) months after the Commencement-of-Service Date, Authorized Registrars may submit requests for Phase II Defensive Registrations. An interface for registering Defensive Registrations will be provided to the Authorized Registrars. The fee for and term of a Defensive Registration is specified in Appendices G and L, respectively. 2. Intellectual Property NameWatch Service The Intellectual Property NameWatch Service ("NameWatch") will be sold through Authorized Registrars. The NameWatch service allows a NameWatch registrant to monitor registrations in the Registry TLD that correspond to the registered string (each a "Watched String"). The same string may be on watch for different NameWatch registrants. The NameWatch service is described in Appendix C. Before the launch of the Live SRS, Registry Operator will process all NameWatch registrations in batches. The first such batch shall be processed at least thirty (30) days prior to the Commencement-of-Service Date. The NameWatch service is open to any person or entity, subject to the payment of yearly fees as described in Appendix G. The NameWatch service will be launched sixty (60) days before the Commencement-of-Service Date. 3. Second Level Domain E-mail Forwarding Service During the Term of this Agreement, Authorized Registrars may submit requests for SLD E-mail address registrations, which will enable SLD E-mail addresses on shared second level domains. The SLD E-mail address service is described more fully in Appendix C. As described in Appendix C, when a domain name or SLD E-mail service is registered, the Corresponding Name Service (as defined in Appendix C) is reserved for 120 days. For example, the Corresponding Name Service of the domain name firstname.example.name is the SLD E-mail address firstname@example.name, and vice versa.
The Landrush process, policies and algorithms are described below, and will be identical for both queues of domain names and queues of SLD E-mail addresses. In the following, "name", and "request" will encompass both SLD E-mail and domain name registrations. The Landrush period will include three periods:
The following batch processing mechanism shall apply to all Processing Periods for domain names and SLD E-mail addresses:
5. Pseudo-Code for the Processing Done in the Processing Period Pseudo-code for the processing procedure has been outlined below to better illustrate the process. Substantially the same process will be used for both domain names and SLD E-mail addresses. In the following pseudo-code, the first section takes the queue from each Authorized Registrar and splits it into two subdivisions: the unique entries, and the entries of which there are many duplicates. For each of the duplicates, one at random is selected and moved into the unique queue, thereby giving only unique entries per Authorized Registrar. There is no advantage to be gained from adding extra entries into the supplied input file as these will be stripped out in this process. If Registrar A has chosen the same domain name as Registrar B the merge and subsequent random selection will determine who gets the domain name first. The registrar.x.unique files will be merged into the gnr.input.batch.file. The subsequent random selection from this input file will ensure that the Registry Operator has been as fair as possible. (x signifies a registrar's unique identification) for each registrar Next, all registrar.x.unique files are concatenated to create a single gnr.input.batch.file. The following pseudo-code is the one that actually performs the registrations in the database. A random registration is selected from the input file, until empty. while entries in gnr.input.batch.file Appendix J, Section 8 below describes the format of the queue-file requested from the Authorized Registrars. 6. The Primary Processing Period The Primary Processing Period will take place over a 20 day period after the queues have been received from the Registrars, beginning twenty (20) days prior to the Commencement-of-Service Date. A detailed estimate of the time allocation of the period is as follows:
7. The Secondary Processing Periods Registry Operator will have, at a minimum, two Processing Periods. The following criteria will be considered after the Primary Processing Period ends, to determine whether the Registry Operator, in its reasonable discretion, will launch additional Processing rounds.
These additional Processing Periods will continue on a regular basis, one after another, until the opening of the Live SRS. Landrush registrations will not be transferable until the launch of the Live SRS, and after that will be subject to any other restrictions on the transfer of registrations that may apply. For example, a domain name or SLD E-mail address registered one day before the launch of the Live SRS will still be subject to any time restrictions on the transfer of registrations generally. Secondary Processing periods will take place over 10 business days and will be allocated as follows:
8. Format for Landrush Submissions The format of the input files for Landrush will be space-separated with pre-determined data fields, one record per line. The file will need to be encrypted as specified in Subsection 10 before submission into the Shared Registry System. The input files will then be decrypted to produce files consisting of UTF-8 characters. Domain names and e-mail addresses will be subject to the restricted character set sections defined in Appendix C, References and Character Sets. In essence, the queue submitted by the Authorized Registrar will be split into two separate input files by Registry Operator. The first file will contain the registrant and Authorized Registrar details. These are inserted into the database to create the unique handles which will correspond to the Authorized Registrar identifier for each contact point. A list mapping the Authorized Registrar-provided identifiers to the globally unique handles used by the Registry Operator will be written out to a file. The second file will list the domains requested and will be used to assign the correct contact identifiers, created per the details in the first file, into the database. The second input file from the Authorized Registrar should reference the Authorized Registrar-assigned identifiers from the first input file. The intention of this is to minimize the risk of errors on input. Data volumes will also be reduced by the use of handles and identifiers. The first line in each file will include the Authorized Registrar authorization and identity. Each entry for a domain will be submitted as a single line. Files will be of a standard UNIX format terminated with a line feed character (ASCII character 10 decimal) with no carriage return characters (ASCII character 13 decimal). There will be only one entry per line. Each field will be enclosed in double quotes with a single space delimiting each field. Any double quotes will have to be escaped with a backslash ('\' - ASCII character 92 decimal) within the field text. Each domain name submission will be preceded with a unique reference (for the Authorized Registrar's benefit); it will be used in generating the report of successful domain names and their subsequent Registry Operator assigned handles. Each entry field has a restricted size. No file will exceed the supported maximum single file limit. Examples of the input files for Landrush are shown below. Note that they have been amended for readability such that each line that would be submitted as a distinct entry, has been split up. Not every field will be mandatory (as not every one has a facsimile number) but others pertaining to a distinct person or entity will be required, such as name. Non-mandatory fields will still require a pair of double quotes (ASCII 34 decimal) to indicate that no value is supplied. Comments have been included in the sections pertaining to examples of input files. These have been preceded with a double asterisk (**). Comments will not be permitted in the submitted file from the Authorized Registrars. There are four distinct areas for each entry, namely Client, Technical, Billing and Administration. The Domain Name field will provide the three different levels of domain names with the first portion referring to the third level domain name, the middle portion between the two full stops as the second level domain name, with the top level domain name being .name Thus a request for john.jones.name is for "john" as the third level name, and "jones" as the second level name. ** Registrar Authorization ** Structure for each contact point is identical. ** Registrar Unique Identifier "RR0001" "RR0002" "RR0003" ** First Registrant Submission ** Second Registrant Submission A temporary file is produced from this list of Authorized Registrar-assigned contact points, giving the unique identifiers assigned by Registry Operator. The layout of this file (although private and strictly for internal use by the Registry Operator) is illustrated below. ** Registrar Authorization ** Mapping file (temporary) delimited by colon (ASCII 58). "RR0001":"ACME-456" "RR0002":"ACME-457" "RR0003":"ACME-458" "C0001":"JS-1010" "C0002":"JJ-1012" The second input file, created from the original queue-file submitted by the Authorized Registrar, is illustrated below, representing information about which contacts are associated with which registrations. This file will use references to the Authorized Registrar-assigned identifiers supplied in the first input file. As each name-server entry may have up to 13 IP addresses, multiple IP addresses for a single server are to be listed in a single double quote-enclosed field after the FQDN of that name server, separated by spaces, as shown in the example below. Since each domain may further contain 13 name-servers, there may be up to thirteen such fields in each submission request line. If more than 13 IP addresses are supplied for one name-server, or more than 13 name-servers are supplied for a domain name submission, then the file is considered to be malformed and will be rejected. These IP addresses will only be stored for .name name-servers. An IP address may additionally only have one name-server associated with it as per RFC2832. This will prevent the situation whereby a single domain name may have two name servers associated with it, but the two name servers point to the same IP address. Additionally, only IPv4 addresses will be permitted during Landrush. The fully qualified domain names will be stored in one case only but may be submitted in either case by the Authorized Registrars. Once a line feed character (ASCII 10 decimal) is met, it is assumed to be the end of the submission request for that part of the transaction. ** Registrar Authorization ** The format is --> ** If it is a SLD Email Forward request only, there is no need for any name server fields, empty or otherwise. ** First Registration Submission for domain and email ** Second Registration Submission for domain only ** Third Registration Submission for email only The Authorized Registrars will be notified upon their requested transactions by an e-mail. Only the successful registrations will be returned in a similar file format as detailed above, using UTF-8 throughout, with domain names and email addresses being subject to the relevant sections in Appendix C, References and Character Sets. Malformed files will be handled according to the procedure in Appendix J, Section 4.3 above. 9. Reporting of Landrush Processing Results Copies of all files used in the Landrush, will be stored as an offsite backup until the Registry Operator is sure that the Landrush processing is complete and verified. The result of the processing for each Authorized Registrar will be communicated to them in an email with an attached ASCII file detailing which registrations were successful. This file will follow the format described below. It has been amended for readability such that each line that had been submitted as a distinct entry, has been split up, with the various handles and return codes appended to it. A single space will be used to delimit each field. Comments have been included in the sections. They are preceded with a double asterisk (**). Comments will not be in the transmitted file returned to the Authorized Registrars. Failures in registration for unique entries will be notified to the Authorized Registrar. ** Registrar Identifier ** Format of reported results to Registrars ** Registrar Specific entries "RR0002" "RR0003" ** First Registrant Unique Identifier ** First Domain and Email application by C0001 ** Second Registrant Entry Unique Identifier ** Second Domain only application by C0002 ** Third Registrant Entry Unique Identifier ** Third Email only application by C0003 The Registry Operator-assigned handles should be stored by the Authorized Registrar for use in the live Shared Registration System. 10. Security of Landrush Transactions The comma-separated files must be encrypted with PGP. Details about the encryption algorithm will be communicated to Authorized Registrars in advance. The result for each of the Authorized Registrars' requests during the Landrush will be encrypted in the same way before transmission to the Authorized Registrars. 11. OT&E for Launch of Defensive Registrations/NameWatch and Landrush Before ICANN-Accredited Registrars will be allowed to submit Defensive Registrations, NameWatch service registrations or Landrush period registrations, they must first pass Landrush Operational Test and Evaluation ("LOT&E") certification. The LOT&E process has two main objectives:
The LOT&E certification process will be available to all ICANN-Accredited Registrars starting 60 days before the Commencement-of-Services Date. All ICANN-Accredited Registrars will be required to pass certain tests in order to pass the LOT&E certification. All tests performed during LOT&E certification must be completed without errors. Registry Operator will provide the certificate results in a timely manner and provide feedback for those ICANN-Accredited Registrars that failed to successfully complete the tests. ICANN-Accredited Registrars may correct their systems and re-schedule for certification. ICANN-Accredited Registrars will not be limited in the number of attempts at LOT&E certification and will otherwise be treated equally by Registry Operator in connection with LOT&E certification. Upon successful LOT&E certification, the ICANN-Accredited Registrar becomes eligible to submit Defensive Registrations, NameWatch service registrations and Landrush period registrations. 12. Live Shared Registration System Launch and OT&E The Live SRS is defined as the operations of the Registry System after the Landrush Periods are finished. The Live SRS will be launched one hundred twenty (120) days after the Commencement-of-Service Date. Requests will then be served on a first-come, first-served basis and Authorized Registrars will connect through the interface and protocols specified in Appendix C. Before ICANN-Accredited Registrars will be allowed to join the live registration environment, they must first pass Operational Test and Evaluation ("OT&E") certification. The OT&E process has two main objectives:
The OT&E certification process will be available to all ICANN-Accredited Registrars starting 60 days before the Live SRS is launched. All ICANN-Accredited Registrars will be required to pass certain tests in order to pass OT&E certification. All tests performed during OT&E certification must be completed without errors. Registry Operator will provide the certificate results in a timely manner and provide feedback for those ICANN-Accredited Registrars that failed to successfully complete the tests. ICANN-Accredited Registrars may correct their systems and re-schedule for certification. ICANN-Accredited Registrars will not be limited in the number of attempts at OT&E certification and will otherwise be treated equally by Registry Operator in connection with OT&E certification. Upon successful OT&E certification, the ICANN-Accredited Registrar becomes eligible for operation in the live registration environment. For specific technical details see Appendix C to the Registry Agreement. 13. Cooperative Marketing Fund Generation Program Registry Operator intends to offer an open-ended fund generation program for the Cooperative Marketing Fund ("CMF"), with the goal of facilitating a rapid uptake of Registry TLD domains in all markets. All Authorized Registrars are treated equally in the generation and implementation of the CMF, and Registry Operator intends to apply the following characteristics:
The detailed CMF guidelines will be distributed to the Authorized Registrars 30 days before the Primary Processing Period. Funds for the CMF will be raised through a Co-Marketing Fund contribution schedule based on share per domain sold, with limitations as stated in Appendix G. 14. Registry Operator Liability Limitations Registry Operator will have no liability of any kind for any loss or liability resulting from the processing of registration requests prior to live SRS launch, including, without limitation, the ability or inability of a registrant to obtain a domain name or SLD E-mail address registration using these processes. Comments concerning the layout, construction and functionality of this site should be sent to webmaster@icann.org.
(c) 2001 The Internet Corporation for Assigned Names and Numbers. All rights reserved. |
