ICANN Logo

Proposed Unsponsored TLD Agreement: Appendix J (.name)

(30 June 2001)


START-UP PLAN

ANTICIPATED START-UP PLAN AND LAUNCH DATES

Date

Name of Phase

C-60 days

Announcement of Schedule for Phase I Defensive Registration, NameWatch Registration and Landrush Period; First Day for Submission of Landrush Queues for Primary Processing Period

C-30 days

Processing of Phase I Defensive Registrations and NameWatch Registrations

C-21 days

Last Day for Submission of Landrush Queues for Primary Processing Period

C-20 days

Launch of the Cooperative Marketing Fund Program

C-20 days

Commencement of Primary Processing of Landrush Queues by Registry Operator; First Day for Submission of Landrush Queues for Secondary Processing Period

Commencement-of-Service (C)

Resolution into DNS and Whois of Registered Domain Names; SLD E-mail Addresses Become Operational and Are Resolved into Whois

C+19

Last Day for Submission of Landrush Queues for Secondary Processing Period

C+20 days

Secondary Processing Period(s) Begin(s)

C+120 days

Live SRS Launch

C+180 days

Collection and Processing of Phase II Defensive Registrations Begins

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

1. Defensive Registrations

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.

3.1 Notwithstanding the provisions of Appendix C, if a domain name or SLD E-mail address is registered prior to the launch of the Live SRS, the Corresponding Name Service will be reserved for 120 days, or until the launch of the Live SRS, whichever comes later.

4. Landrush

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:

1. Announcement of Landrush Period, sixty (60) days prior to the Commencement-of-Service Date.

2. Landrush Primary Processing Period, beginning twenty (20) days prior to the Commencement-of-Service Date.

3. Landrush Secondary Processing Period(s), beginning twenty (20) days after the Commencement-of-Service Date.

The following batch processing mechanism shall apply to all Processing Periods for domain names and SLD E-mail addresses:

4.1 Authorized Registrars may begin submitting their queues to the Registry Operator 21 days before commencing a Processing Period. The deadline for receipt of queues will be 24 hours before commencing the Processing Period. Receipt of the queues will be confirmed by telephone or e-mail as appropriate, if received in time.

4.2 After the deadline for the receipt of queues no late requests will be accepted for the current Processing Period.

4.3 Registry Operator will not be responsible for queues that are sent in an invalid or malformed format. Registry Operator will use reasonable efforts to notify Authorized Registrars that have submitted queues in an invalid format. Such Authorized Registrars will have until the deadline to reformat and resend their queues.

4.4 The unique entries from each Authorized Registrar's queue will be merged and put into a single pool. From each of the queue-subsets of non-unique entries, one unique entry is selected at random. This entry is then entered into the same pool.

4.5 The processing starts with a random registration in the pool.

4.6 The processing ends when all registrations have been processed.

4.7 A report is then issued to each of the Authorized Registrars with registration status of each of the requests submitted.

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
     scan input file by domain name
     take out invalid entries
     put duplicates into registrar.x.duplicate
     put unique entries into registrar.x.unique
     for ( each distinct entry in registrar.x.duplicate )
          select one random entry from distinct list (i.e.: if 10 John Smiths in duplicate list, choose one)
          move entry to registrar.x.unique
     endfor
endfor

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
     select a random entry
     process each entry
     case return code
          success : ok, delete/mark entry from batch file, break
          duplicate : log to duplicatefile, delete/mark from batch file, break
          invalid : log to baddatafile, delete/mark from batch file, break
          failure : pause processing
     endcase
endwhile

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:

Day 0-1: Confirmation of received queues from Authorized Registrars
Day 1-3: Registrar information and feedback period
Day 3-6: Processing of the queues and verification of result
Day 6-7: Processing preliminary result feedback
Day 7-14: Registrar information and feedback period
Day 14-19: Technical verification and report production
Day 20: Insertion into Whois and DNS for domain name resolution

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.

7.1 Did the registrations on the .name TLD go live in a satisfactory manner in the DNS and Whois?

7.2 Was the allocation deemed fair and equal for registrants and Authorized Registrars?

7.3 Were there significant risks of instability of the Internet during Landrush?

7.4 Is there an immediate need in the market for additional Landrush periods?

7.5 Once the evaluation is complete, if Registry Operator determines that additional Processing Periods are warranted, it will advise Authorized Registrars of the schedule for such Processing Periods.

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:

Day 0-1: Confirmation of received queues from Authorized Registrars
Day 1-2: Registrar information and feedback period
Day 2-3: Processing of the queues and verification of result
Day 2-5: Processing preliminary result feedback
Day 5-8: Registrar information and feedback period
Day 8-9: Technical verification and report production
Day 10: Insertion into Whois and DNS for domain name resolution

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
Registrar:="ACME Registrations, UK"
AuthorizationPassword:="MyCompanyKey4321"

** Structure for each contact point is identical.
** It will take this format on one line,
** each value being enclosed in double quotes (ASCII 34)
** and delimited by spaces (ASCII 32).
** Blank or empty fields should be entered as a pair of double quotes.

** Registrar Unique Identifier
** Client Name
** Client Address
** Client City
** Client State/Province
** Client Country
** Client Postcode
** Client Telephone
** Client Email
** Client Facsimile Number

"RR0001"
"ACME Registrations, UK"
"P.O. Box 1"
"CityY"
"Kent"
"UK"
"PP2 1PP"
"+44.321321321"
"tech@acmereg.co.uk"
"+44.321001001"

"RR0002"
"ACME Registrations, UK"
"P.O. Box 1"
"CityY"
"Kent"
"UK"
"PP2 1PP"
"+44.321321321"
"billing@acmereg.co.uk"
"+44.321001001"

"RR0003"
"ACME Registrations, UK"
"P.O. Box 1"
"CityY"
"Kent"
"UK"
"PP2 1PP"
"+44.321321321"
"admin@acmereg.co.uk"
"+44.321001001"

** First Registrant Submission
"C0001"
"John Smith"
"1, Old Street"
"CityY"
"Kent"
"UK"
"PP1 2PP"
"+44.123123123"
"john@workemail.co.uk"
""

** Second Registrant Submission
"C0002"
"jayne.jones.name"
"Jayne M. Jones"
"12, Down Ave"
"TownZ"
"Kent"
"UK"
"PP1 2PP"
"+44.125125125"
"jayne@workemail.co.uk"
""

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
Registrar:="ACME Registrations, UK" AuthorizationPassword:="MyCompanyKey4321"

** Mapping file (temporary) delimited by colon (ASCII 58).
** Each entry is terminated by a LF (ASCII 10) character.
** The format is :
** Registrar Unique Identifier : Registry Operator allocated handle

"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
Registrar:="ACME Registrations, UK" AuthorizationPassword:="MyCompanyKey4321"
LandrushType:="Domain"

** The format is -->
** Domain Id
** SLD Email Forward Address
** Registrant Unique Identifier
** Technical Unique Identifier
** Billing Unique Identifier
** Administration Unique Identifier
** Email Forward To
** Name Server 1, Name Server IP address 1, Name Server IP Address 2
** Name Server 2, Name Server IP address 2

** 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
"john.smith.name"
"john@smith.name"
"C0001"
"RR0001"
"RR0002"
"C0001"
"john@workemail.co.uk"
"ns1.acme.reg.name 192.168.1.106 10.10.12.1"
"ns2.acme.reg.name 192.168.2.101"

** Second Registration Submission for domain only
"jayne.jones.name"
""
"C0002"
"RR0001"
"RR0002"
"RR0003"
""
"ns1.acemreg.co.uk"
"ns2.acmereg.co.uk"

** Third Registration Submission for email only
""
"steve@smith.name"
"C0003"
"RR0001"
"RR0002"
"RR0003"
"stevesm9Z@llyyll.net"

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
Registrar:="ACME Registrations, UK"

** Format of reported results to Registrars
** Registrar Unique Identifier
** Registry Operator unique Identifier to contact point
** Domain Name requested
** Email Forwarding Service requested
** Return Code

** Registrar Specific entries
"RR0001"
"ACME456"
""
""
"OK"

"RR0002"
"ACME457"
""
""
"OK"

"RR0003"
"ACME458"
""
""
"OK"

** First Registrant Unique Identifier
"C0001"
"JS-1010"
""
""
"OK"

** First Domain and Email application by C0001
"C0001"
""
"john.smith.name"
"john@smith.name"
"OK"

** Second Registrant Entry Unique Identifier
"C0002"
"JJ-1012"
""
""
"OK"

** Second Domain only application by C0002
"C0002"
""
"jayne.jones.name"
""
"OK"

** Third Registrant Entry Unique Identifier
"C0003"
"SS-1011"
""
""
"OK"

** Third Email only application by C0003
"C0003"
""
""
"steve@smith.name"
"OK"

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:

1. Verifying the correct operation of an ICANN-Accredited Registrar's client system, and the ICANN-Accredited Registrar's capability to operate the interface with the Registry; and

2. Establishing the contractual and business relationship between the ICANN-Accredited Registrar and the Registry, in accordance with the Registry-Registrar Agreement.

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:

1. Verifying the correct operation of an ICANN-Accredited Registrar's client system, and the ICANN-Accredited Registrar's capability to operate the interface with the Registry; and

2. Establishing the contractual and business relationship between the ICANN-Accredited Registrar and the Registry, in accordance with the Registry-Registrar Agreement.

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:

13.1 All Authorized Registrar-operated campaigns are subject to approval by Registry Operator according to the CMF guidelines. The CMF guidelines will include, without limitation, descriptions of proper formatting, placement and channels for advertising. Authorized Registrar campaigns which are not in line with the CMF guidelines will not be eligible for funds from the CMF. The CMF guidelines will specify that to qualify, promotions will have to conform to specified criteria including the size and look of the Registry TLD logo, use of slogans, prominence of the Registry TLD in the total promotion, and use of media. The CMF guidelines will be made available to all Authorized Registrars.

13.2 50% of pre-approved Authorized Registrar promotional Registry TLD spending will be refunded by the CMF.

13.3 Every Authorized Registrar is eligible for funds from the CMF up to the amount that the same Authorized Registrar has contributed to the CMF.

13.4 Any unused funds will go into a Marketing Development Fund, and will be spent on other initiatives for building usage and awareness of .name TLD.

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.

Page Updated 30-Jun-2001
(c) 2001  The Internet Corporation for Assigned Names and Numbers. All rights reserved.