.TEL Application
Description of TLD Policies

and

 

 

 

 

                                               

Monday, October 2, 2000



Table of Contents

 

E1. GENERAL TLD POLICIES. 3

E2. TLD String. 3

E3. Naming Conventions. 3

E3.1 DNS Delegation with regard to Naming Conventions. 4

E4. Registrars. 4

E5. Intellectual Property Provisions. 5

E6. Dispute Resolution. 6

E6.2. Supplemental dispute resolution procedures being proposed. 7

E7. Data Privacy, Escrow, and Whois. 7

E8. Billing and Collection. 8

E9. Services and Pricing. 8

E10. Other 9

E10.1 Registrar Accreditation. 9

E10.2 Registration Validation Policy for .Tel 9

E11 REGISTRATION POLICIES DURING THE START-UP PERIOD. 10

E12.  Startup Registration. 10

E16. REGISTRATION RESTRICTIONS. 11

E22  CONTEXT OF THE TLD WITHIN THE DNS. 14

Industry Background: 14

Voice over IP example: 15

Internet-Telephony directory is a requirement: 16

Voice over IP just the first step: 16

Background: 16

E27  COMPETITION  16

E28  VALUE OF PROPOSAL AS A PROOF OF CONCEPT. 18

Signature Page. 20

APPENDIX A: Registrar Accreditation Process for .Tel 21

APPENDIX B: Registrar Accreditation Agreement for .Tel 24

APPENDIX C: NetNumber Registrar License and  Agreement for .Tel 44

APPENDIX D:  Rules for Conflict Resolution Policy for .Tel 65

APPENDIX E:  Conflict Resolution Policy for .Tel 73

APPENDIX F:  Domain Naming Policy for .Tel 77

APPENDIX G: Registration Validation Policy for .Tel 79

APPENDIX H: iTAB-NetNumber Registry Zone File Access Agreement 82

 

 

 


E1. GENERAL TLD POLICIES

 

The new “.tel” gTLD utilizes and builds upon all of the existing policies in place for gTLD's today.  However, as a restricted TLD, specific modifications to existing polices have been recommended to reflect the unique operational elements of the ".tel" TLD.  In addition, three new policies are proposed:

 

Domain Naming Policy:  Definition of valid domain names in the ".tel" restricted TLD.

 

Registration Validation Policy:  Definition of the role that Accredited Registrars must play in confirming that ".tel" registrants have "day to day" control over the e164 numbers that they are registering in the ".tel" TLD.

 

Conflict Resolution Policy:  Definition of the role that Accredited Registrars and Registrants must play in working with the Registry to resolve conflicts over control of e164 numbers registered in the ".tel" TLD in a smooth and efficient fashion. 

E2. TLD String

The TLD String proposed for this new gTLD is “tel”.  This string adheres to RFC1034 and RFC1123 for the characters used in this name.

The name “tel” represents an internationally acceptable well-understood acronym identifying “telephone”.   This definition is also referenced in RFC2806 section 2.7.2 which uses the string “tel” to define the URL scheme identifying a “telephone number” by using “tel” as the URL scheme name. 

In the context of this top-level domain the string “tel” refers to “telephone number” which is used to derive a valid domain name.  “tel” represents the best possible choice given the use and meaning of the domain names to be registered in this gTLD.

E3. Naming Conventions

As a restricted top-level domain, the naming policy effectively defines the utilization of the ".tel" TLD within the Internet-Telephony industry.  The objective of ".tel" is to enable telephone number subscribers to register their numbers on the Internet via the ".tel" TLD.  As such, sub-domains of "tel" may not be arbitrarily defined; rather they are defined in accordance with the ITU E.164/I.331 [14] standard.  A valid e164 domain name under the ".tel" TLD is defined as follows:

 

-          Start with a complete telephone number:             1-212-332-1234

-          Remove all non-numeric characters:                   12123321234

-          Reverse the order of the number:                        43212332121

-          Separate by dots:                                                  4.3.2.1.2.3.3.2.1.2.1

-          Add the appropriate domain:                                 4.3.2.1.2.3.3.2.1.2.1.tel

Additional naming issues that will be considered by iTAB over the coming year include the role of ".tel" in presence management, instant messaging, and personal profile management.  Recommendations for names in delegated zones  will be suggested through standards efforts to standardize an application’s use of “.tel”.

 

The “.tel” Registry is responsible for enforcing these restrictions in the registry’s zone before accepting a registration from a Registrar.  The Registrars are also expected to adhere to this policy and should not attempt to register invalid domain names in the .tel gTLD.

 

Registrants of the “.tel” gTLD are only allowed to register domain-names that correspond to and identify valid, assigned, and in-service E.164 telephone numbers.  A registrant associated with a domain-name must have or have been delegated the “day-to-day” control of the E.164 telephone number corresponding to the domain-name being registered as defined in the Domain Naming Policy for .Tel in Appendix F.

 

For additional details regarding these naming conventions please see Appendix F.

 

E3.1 DNS Delegation with regard to Naming Conventions.

The registry uses internal DNS delegation at levels prior to the sub-domain that defines a complete E.164 number.  External delegation outside the registry may occur only after the last digit that finally defines a complete E.164 number.

                       6.4.tel  (not a valid .tel domain name)
                 7.9.8.6.4.tel  (not a valid .tel domain name)
         3.2.1.6.7.9.8.6.4.tel  (not a valid .tel domain name)
       4.3.2.1.6.7.9.8.6.4.tel  (valid .tel domain name)

 

The concept of registering a “block” of numbers (i.e. “8.6.4.tel”) that represent an entire exchange or area code of telephone numbers is not allowed within the “.tel” gTLD.  Domain names representing a single E.164 number are to remain independent thereby enabling individual subscribers to select among competing service providers for various services.   

E4. Registrars

The “.tel” policies conform to and promote an open environment encouraging a large number of  Registrars to participate in the ".tel" restricted gTLD. 

 

iTAB  proposes to utilize the existing ICANN accreditation process for “.tel” with specific modifications to the Registration Accreditation Process as required by the ".tel" TLD.  Modifications and additions to the ICANN original documents that describe the changes for “.tel” are highlighted in Registrar Accreditation Process for .Tel (Appendix A) and Registrar Accreditation Agreement for .tel (Appendix B).

 

Registrars will be required to enter into a license agreement with NetNumber.com, the Registry. The agreement defines the relationship and responsibilities between the registrar and registry including the rights to specific software enabling registrars to add, change, and delete entries in the “.tel” gTLD.  The relationship is similar to the current relationships between NSI and other accredited registrars for the NSI registry.  Details that define this for “.tel” are highlighted in the NetNumber Registrar License and Agreement for .Tel found in Appendix C. 

 

Domain-name holders will deal directly with Registrars and not with the Registry.  The ".tel" TLD places two key responsibilities on the Registrant-Registrar relationship:

 

Registration Validation:  Registrants are required to verify that they are in fact the entity that has "day to day" control over the e164 telephone numbers that they are registering in the ".tel" TLD.  Registrars are responsible for validating this information.  Specific mechanisms for validation are proposed in the Registration Validation Policy for ".TEL" found in Appendix G.

 

Conflict Resolution:  Registrants and Registrars are both required to agree to abide by the ".tel" Conflict Resolution Process which provides a mechanism for resolving conflict between two Registrants who both claim to be the entity with "day to day" control over a given e164 telephone number.   Details can be found in the Conflict Resolution Policy for .Tel found in Appendix E.

 

It is envisioned that new registrar organizations will emerge into the market that specifically deal with the “.tel” domain.   In particular NetNumber anticipates that communications service providers will incorporate the Registrar process into their existing sales and service procedures.

 

As a means of stimulating the growth of ".tel" Registrars, NetNumber has proposed modifications to existing Registry billing mechanisms and WHOIS administration procedures:

 

Registry Billing:  NetNumber will provide all baseline Registry services at no cost to all accredited Registrars during 2001.  In addition, Registrars will be billed on a monthly basis rather than on a yearly basis to more closely align Registry fees with the existing billing procedures of the global communications industry.

 

Registry WHOIS Service:  NetNumber will provide a complete WHOIS database service for use by all accredited Registrars thus eliminating the requirement for Registrars to operate their own 24 x 7 WHOIS database environments.

 

E5. Intellectual Property Provisions

E5.1. What measures will be taken to discourage registration of domain names that infringe intellectual property rights?

E.164 numbers are being viewed as Intellectual property and/or trademarks of the subscriber who maintains “day-to-day” control over the services for an E.164 number.   Registrants registering a domain name derived from an E.164 number in bad faith will be charged a fee if the automated resolution process is deliberately delayed and the registrant holding the registration is proven not to be in “day-to-day” control. 

E5.2. If you are proposing pre-screening for potentially infringing registrations, how will the pre-screening be performed?

Each registrar of “.tel” gTLD is required to support the Registration Validation Policy for .Tel which is designed to perform validation or “pre-screening” for all domain names prior to completing a valid registration.  For a description of how validation is performed please see Paragraph 4 in that policy.

 

E5.3. What registration practices will be employed to minimize abusive registrations?

There will be a contractual agreement between the registrant and the registrar requiring the registrant to declare that he/she has day-to-day control of the E.164 number.  Falsifying registration data may result in fees to be paid based on the dispute resolution process for the “.tel” gTLD.

 

E5.4. What measures do you propose to comply with applicable trademark and anti-cybersquatting legislation?

Trademark and anti-cybersquatting issues are resolved through the Registration Validation Policy for .Tel. 

 

E5.5. Are you proposing any special protections (other than during the start-up period) for famous trademarks?

Please refer to section E5.4.

E5.6. How will complete, up-to-date, reliable, and conveniently provided Whois data be maintained, updated, and accessed concerning registrations in the TLD?

The WhoIs database for .tel will be provided by the Registry as a complete service unlike the current WhoIs database of .com, .net, and .org.  Please refer to Section D15.2.8 for more detail.

 

E6. Dispute Resolution.

The foundation draft of the iTAB Conflict Resolution Policy calls for the Registry operator to support an automated process for alerting Registrars of conflicts and an automated mechanism for helping Registrars to resolve conflicts in a timely and cost effective fashion. 

NetNumber has already made a proposal to iTAB with a first draft of a web-based conflict resolution tool ("CRT") for use by all Accredited Registrars.  The CRT enables Registrars to track outstanding conflicts on-line and it enforces deadlines for the resolution of each outstanding conflict.  All CRT communication flows directly from the Registry to the appropriate Registrars at which point the Registrars are responsible for contacting Registrants directly for additional information. 

As a next step, NetNumber is developing a demo version of the CRT for review by iTAB by December 15, 2000.  For an initial draft of the Conflict Resolution Policy please see Appendix E.

E6.1 Implementing the Uniform Dispute Resolution Policy?

The ICANN Uniform Dispute Resolution Policy will only be used in extreme situations and only as a last resort.  Since it is only possible for one registrant to actually have “day-to-day” control over any one E.164 telephone number at a given time disputes should be resolved quickly.

E6.2. Supplemental dispute resolution procedures being proposed.

Dispute resolution for “.tel” is accomplished by an automated process involving a potential registrant  (complainant) that has been denied registration, the Registrar, the Registry Conflict Resolution Tool (CRT) and Conflict Resolution Center, and the current registrant (respondent).

After a denial of registration a complainant fills in a form with the Registrar and submits a complaint.  This complainant enters an agreement with the Registrar claiming to have rights to this domain name as the “day-to-day” controller of the associated E.164 telephone number.  The complainant is subject to fees after initiating this process if the claim turns out to be false. 

The Registrar will submit the complaint via the CRT and the CRT will notify the Respondent of the complaint.  The respondent will be given the option to relinquish its registration by agreeing that he/she no longer has “day-to-day” control of the E.164 number corresponding to the domain name currently registered.

In the event an error occurred such that the respondent continues to claim “day-to-day” control then the resolution process passes to the Registry’s Conflict Resolution Center (CRC).  An expert on determining “day-to-day” control will manually follow up the process and the party in error will be subject to fees as provided for by the Registration Agreement or as provided for by the agreement made when the complainant issued the complaint.

Determining who has rights for a “.tel” domain name becomes a process of determining who has “day-to-day” control over the E.164 number that was used to derive the “.tel” domain name.

Defining “day-to-day" control is described as follows:

E.164 numbers (telephone numbers) are allocated to service providers using nationally delegated organizations which follow a structure defined by the ITU (International Telecommunications Union).  A service provider assigns out telephone numbers when a subscriber requests telephone service.  As service providers assign these E.164 telephone numbers the “day-to-day” control passes from the service provider to the individual subscriber or enterprise entity that has requested service.  It is these subscribers or enterprise entities that decide what services they would like enabled for their E.164 telephone number(s).  

 

A description of the automated resolution process is described in Section E6.2.  A sample Conflict Resolution Policy for .Tel is contained in Appendix E. Appendix D

 

E7. Data Privacy, Escrow, and Whois.

Data gathered during registration by Registrars will adhere to the rules defined in Section II.F of the sample Registrar Accreditation Agreement for .Tel defined in Appendix B concerning public access to registration data. 

The key value of registering in the new .tel TLD is that the data being registered is made public to enable many types of communication with the registrant.    Registrars may enable an “Opt-Out” policy as described in Section II.F.6.f  of the sample Registrar Accreditation Agreement for .Tel. 

Certain information will be made available via public access through the use of the WhoIs database while qualified entities such as accredited registrars may be allowed bulk access of registry data providing the data is not used to provide (i)commercial advertising; (ii)unsolicited communications; (iii)sell or redistribute the data to third parties.

NetNumber, as the .tel registry, is also to follow Agreement 9 found in the sample ICANN-NetNumber Registry Agreement (Appendix F) titled Publication By NetNumber of Registry Data describing Data Privacy obligations of the .tel registry. 

For data escrow policies all .tel accredited registrars are to adhere to the terms agreed to in Section II.I of the sample Registrar Accreditation Agreement for .Tel defined in Appendix B of this document.

NetNumber, the registry, will adhere to the terms defined in Agreement 7 of the ICANN-NetNumber Registry Agreement found in Appendix F.

 

E8. Billing and Collection.

Accredited Registrars will be billed monthly on a per entry basis.

All baseline Registry services will be provided free of charge by the Registry to all Accredited Registrars during 2001.

For details see:   NetNumber Registrar License and Agreement for .Tel found in Appendix C.

E9. Services and Pricing.

What registration services do you propose to establish charges for and, for each such service, how much do you propose to charge?

 

Baseline Registry services shall be billed at a rate of $0.50/month per entry  Baseline services include the following:

 

Domain Name Resolution: 

 

Whois Service:  NetNumber will provided a common Whois database service for all ".tel" Registrars as a built-in component of the Registry service. 

 

Conflict Resolution Tool:  NetNumber will provide a shared "Conflict Resolution Tool" (CRT) for use by all ".tel" Registrars as part of the Registry service.  The CRT will provide a common mechanism for identifying and resolving registration conflicts between different Registrars.  The CRT service will be provided as part of the Registry function.

 

Update Services:  NetNumber will provide a shared Registry update system and associated "Registry Update Protocol" specification for use by all ".tel" Registrars.  Update services will be included in the Registry fee structure.

 

Additional services will be provided for a fee:

 

Conflict Resolution Center:  NetNumber will provide a staff of conflict resolution service personnel to assist Registrars in resolving conflicts that are not automatically resolved via the use of the CRT.  CRC staff services will be billed on an hourly basis to the Registrars involved in the conflict as per the ".tel" Conflict Resolution Policy.   

RUP Client License:  For Registrars that don't want to write their own client-side RUP compliant software, NetNumber will license software at a fee.  The projected pricing is a one-time fee of $5,000.

E10. Other

E10.1 Registrar Accreditation

The Registration Accreditation Agreement for .Tel proposed by iTAB follows the existing structure established between ICANN and Accredited Registrars for ".com", ".net" and ".org".  Additions to the policy address two requirements placed on Registrars of the ".tel" TLD.

(a)    Registrant Validation Requirement:  ".tel" Registrars are required to fulfill their defined operational role as presented in the ".tel" Registration Validation Policy.

(b)    Conflict Resolution Requirement:  ".tel" Registrars are required to fulfill their defined operational role as presented in the ".tel" Conflict Resolution Policy.

A complete sample of the Registrar Accreditation Agreement for .Tel marking all modifications from the original ICANN agreementcan be found in Appendix B.  

E10.2 Registration Validation Policy for .Tel

The Registration Validation policy flows directly from the ".tel" Naming policy outlined in E3 above.  The ".tel" TLD provides a mechanism for telephone number subscribers to register their phone numbers on the Internet and associate those numbers with IP-enabled communications devices and addresses.  As such, only valid telephone number subscribers or their designated agents may register numbers with the ".tel" TLD.  Valid ".tel" registrants are defined as the individuals, corporations or service providers that are current subscribers to telephone numbers. 

 

The ".tel" Registration Validation Policy defines a set of acceptable mechanisms that accredited Registrars may utilize in validating ".tel" registrations.  The objective of the policy is to minimize or eliminate inaccurate registration of telephone numbers by non-subscribers.  iTAB will work with accredited Registrars of ".tel" to advance and refine the foundation version of the Registration Validation Policy to balance two key goals: (1) Advance the registration of numbers in ".tel".  (2) Maintain the accuracy of registrations.

 

The foundation draft of the ".tel" Registration Validation Policy outlines three acceptable validation strategies that are based on the experience of the FCC in the United States in validating the selection of long distance carriers by existing telephone number subscribers.  In the long-distance example, the goal of the FCC was to validate that a current telephone number subscriber has in fact selected to switch long-distance carriers.  In the ".tel" example, the goal is to validate that a current telephone number subscriber has in fact selected to have their telephone number registered in the ".tel" TLD. 

 

Accredited Registrars are responsible for defining the specific implementation mechanisms that they will utilize to validate the identity of registrants.  The iTAB policy defines three broad categories of acceptable validation procedures that Accredited Registrars may utilize to conform to the iTAB policy:

E11 REGISTRATION POLICIES DURING THE START-UP PERIOD

E12.  Startup Registration

The .tel gTLD will not experience the “rush” phenomenon that new open generic gTLDs are suspected to experience.  Telephone number subscribers with day to day control over a telephone number have the right to register that number in the ".tel" TLD.   As a result, registrants won’t experience a sense of urgency to reserve a domain name (telephone number) before it is taken.  From the moment .tel is brought on-line every potential registrant has what could be considered a “reserved” domain name in .tel.

The flow of registrations into ".tel" will follow a well defined structure that starts with technology vendors integrating a directory service based on ".tel" into their product offerings  (IP-PBX vendors, Voicemail vendors, Softswitch providers, etc.).  NetNumber has gained direct experience with this process over the past year in working with key Internet-Telephony vendors.  (See Registry Operator Proposal for more detail).

Current expectations for first year registrations in ".tel" range from 300,000 to 600,000 based on conservative case projections of IP-Telephony market penetration.  The IP-telephony market is currently at the early stages of market adoption.  Enormous growth is projected for the industry over the next five years and the  ".tel" Registry will play an important part in the growth of this industry.  Registrations will start at an easily manageable pace and will grow as the industry matures.

E13.  Do you propose to place limits on the number of registrations per registrant? Per registrar? If so, how will these limits be implemented?

No limits are to be placed on the number of registrations allowed per registrant.  A registrant may register as many E.164 numbers that he/she maintains day-to-day control over. 

The NetNumber registry update servers are designed and provisioned to handle registration loads well above any expectations during the start-up period.  (Please see Section D15.2.10 in the Registry Operator’s Proposal for specific details.)

E14. Will pricing mechanisms be used to dampen a rush for registration at the initial opening of the TLD? If so, please describe these mechanisms in detail.

No price mechanisms will be used to dampen registration.  

E15. Will you offer any "sunrise period" in which certain potential registrants are offered the opportunity to register before registration is open to the general public? If so, to whom will this opportunity be offered (those with famous marks, registered trademarks, second-level domains in other TLDs, pre-registrations of some sort, etc.)? How will you implement this?

A “sunrise period” is not necessary for the .tel gTLD.  Since all domain names are essential predetermined due to E.164 assignments there is no need to provide pre-registration opportunities.

The value of an individual registration may be perceived to be worth more by an individual registrant depending on the services enabled by the registration.  This may cause some registrations to occur before others but no registration will limit in inhibit any one else or entity from making valid registrations.

E16. REGISTRATION RESTRICTIONS

The ".tel" gTLD has restrictions that specifically apply to a domain name string being registered and to the requirements a registrant must maintain to keep authority over a domain name.

As described in section E3 and in the sample  Domain Naming Policy for .Tel the rules specifically define valid domain names that may be registered in the ".tel" gTLD.  The rules specifically state how a. tel domain name is derived from an identified E.164 number.  

The Registration Validation Policy for .Tel describes rules that define how a registrant may become an authority over a ".tel" domain name.  This policy specifically states that an individual or entity must meet a set of registrar requirements that justifies the potential registrant as the day-to-day controller of telephony services tied to one or more identified E.164 numbers. 

To maintain authority for a .tel domain name the registrant must remain in day-to-day control of the E.164 number.  If a ".tel" registrant loses day-to-day control over telephone service for the E.164 number identified by the .tel domain name then the registrant also loses authority for the ".tel" domain name derived from this E.164 number.

E17. Describe in detail the criteria for registration in the TLD. Provide a full explanation of the reasoning behind the specific policies chosen.

The criteria for a registrant to complete the ".tel" registration process is defined in the Registration Validation Policy for .Tel located in Appendix G.

E18. Describe the application process for potential registrants in the TLD.

NetNumber's experience in the market over the last year indicate that the ".tel" registration process will not follow the model of existing gTLD's.  The current model of registrants reserving a name via a Registrar web-site does not fit the Internet-Telephony model as it is evolving today.  Rather, the current focus is on integrating a ".tel" directory service into the IP-based communications systems that will leverage automated registration services provided by a Registrar. 

For example, NetNumber has already engaged in integration work with several vendors of IP-PBX platforms that are working to integrate the NetNumber GITD into their platforms.  When a customer installs a GITD enabled communications platform, the platform itself is configured to register end-user telephone numbers and associated Internet addresses with the GITD.  NetNumber anticipates that this model of tight integration of the ".tel" TLD into Internet-Telephony infrastructure will drive the majority of registrations.

The specific registration process may vary slightly among registrars but at a minimum the following information is to be collected per registration entry.  The source of some of the information may come from the registrant, registrar, and/or the registry depending on the type of registration option the potential registrant has selected.

·         Registrants Name, address, and contact information

·         IP addresses and corresponding names of the primary and secondary DNS nameservers

·         Identity of the Registrar sponsoring the registration

·         Date of registration application

After the registrant information is retrieved the registrar will use the RUP registry software to confirm that the .tel domain name has not already been registered.  In the event a conflict is discovered the registrar is to engage the Conflict Resolution Policy for .Tel.  If no conflict exists then the domain name will be registered and registrar will receive confirmation via the RUP registry software. 

E19.
Enforcement policies to be followed during the start-up period for ensuring registrants meet the registration requirements are the same as those defined for normal .tel TLD operation. Please refer to Section E5.3 for this information.

E20..
The appeal process for denial of registration is described in two steps.  The first action to be taken when denial of registration occurs is to follow the processes defined in the Conflict Resolution Policy for .Tel.  In the rare cases this fails to resolve the conflict the complainant may appeal this process by engaging the ICANN Uniform Domain Name Dispute Resolution Policy.

E21. Describe any procedure that permits third parties to seek cancellation of a TLD registration for failure to comply with restrictions
Any individual or entity providing accurate information to a registrar and acting on behalf of the potential registrant having day-to-day control over an E.164 number may initiate the process defined by the Conflict Resolution Policy for .Tel   Depending on the options supported by the specific registrar in validating potential .tel registrants additional communication with the individual or entity requesting the conflict resolution process may not be necessary thereby enabling third parties to initiate the cancellation of an invalid TLD registration.

 


E22  CONTEXT OF THE TLD WITHIN THE DNS

 

"A Top-Level Domain For The Emerging Internet-Telephony Industry"

Industry Background:

The global communications industry is moving at remarkable speed to embrace the new world of Internet Protocol (IP) technology. Underlying economics and the growing demand for data services dictate that networks like the Internet, corporate intranets, and managed extranets will be the telecommunications networks of the future.

Standard communications devices like telephones, fax machines, and voicemail systems are quickly becoming IP-enabled devices that connect to both the existing telephone network and to data networks like the Internet.  As IP-enabled communications devices begin to proliferate around the world, a requirement has emerged to integrate the existing addressing scheme of the legacy Public Switched Telephone Network (PSTN) with the emerging addressing schemes of the Internet-Telephony industry.  In short, a requirement exists for a directory service that will translate existing legacy telephone numbers into Internet addresses

 

The underlying need for the ".tel" TLD can be summarized as follows:

Voice over IP example:

IP-enabled PBX (Private Branch Exchange) systems are telephone systems that have the ability to connect calls over both the PSTN and data networks like the public Internet.  Major suppliers of IP-PBX systems include 3Com, Cisco, Nortel, Lucent, Ericsson, etc.  One of the goals of IP-PBX systems is to provide "least cost routing" for every call placed by an end-user.  In the Internet-Telephony world, the true least cost route comes from setting up a call "end-to-end" over the public Internet.  The process starts with an end-user picking up a phone and dialing a telephone number.  The IP-PBX looks at the number and tries to make a least cost routing decision.  The least cost option is to connect the call over the Internet.  The higher-cost back up is to send the call out over the existing telephone network (PSTN).  In order to send a call out over the Internet the IP-PBX needs to check a global directory to determine if the telephone number can be translated into an Internet address for an IP-PBX or IP-phone at the distant end.

The ".tel" TLD is the top-tier of a globally distributed directory solution that enables end-users to register their phone numbers on the Internet and associate those phone numbers with any number of IP-enabled communications devices (phone, fax, e-mail, PDA, etc.)  As the top-tier of the global system, the ".tel" TLD simply provides a pointer to the appropriate location where authoritative Internet address information is stored for a given number.  For simplicity, only the top-tier of the directory is shown in this example.

 

1. End-user at Company A picks up the phone and dials a phone number.

2. IP-PBX at Company-A uses the ".tel" TLD to determine if an Internet address is

    available for the distant end.

3. IP-PBX at Company-A contacts IP-PBX at Company-B via the Internet.

4. End-users at Company-A and Company-B talk real-time over the Internet.

 

 

 

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Note:  The IETF-ENUM working group (http://www.ietf.org/html.charters/enum-charter.html) is engaged in defining an implementation standard for representing a legacy telephone number as a domain name on the Internet.  The ".tel" TLD will utilize the ENUM naming approach. 

Internet-Telephony directory is a requirement:

Early deployments of IP-communications systems avoided the address translation problem being addressed by the ".tel" TLD by limiting the scope of IP-telephony solutions to just internal corporate communications.  By limiting the scope of the solution, each IP-PBX could be programmed with up-to-date Internet address information for every end-user inside a given company.  This "closed user group" solution has been an important first step for the emerging Internet-Telephony industry but it is breaking down as users try to expand the IP-telephony model beyond a small user group. 

As a next step in the evolution of the industry, a global directory infrastructure with appropriate regulatory oversight is an absolute requirement for the Internet-Telephony industry to achieve its full potential. 

Voice over IP just the first step:

The first step in the process of bridging legacy phone numbers with the Internet is to link a legacy telephone number with an Internet address for an IP-enabled phone.  Follow-on steps will include allowing telephone number subscribers to use a telephone number as unique identifier for a complete list of IP-enabled communications devices (phone, fax, e-mail, PDA, etc.)  In this regard, the ".tel" TLD will play an important role in enhancing the utility of legacy telephone numbers for the user community.

Background: 

The ".tel" TLD application is the outgrowth of a  multi-year intellectual property, technology development and standards body effort by NetNumber.com that culminated in the commercial launch of NetNumber's "Global Internet-Telephony Directory" (GITD) service in July of this year.  The GITD is a global directory service for the Internet-Telephony industry that translates telephone numbers into any number of supported Internet addresses and other end-user profile information.  Just two months after the launch of service, the GITD has already begun to gain significant momentum with key Internet-Telephony technology vendors and service providers.  See the "Industry Contacts" section of the Registry Operators Proposal for more information regarding industry adoption of the GITD.

The top-tier of the GITD (currently deployed under "e164.com") was designed from the outset to function as a top-level domain for the Internet-Telephony industry.  If the ".tel" application is approved by ICANN, the top-tier of the GITD currently operating under the domain "e164.com" will be migrated to ".tel" with NetNumber providing the Registry function under contract from ICANN and the "Internet-Telephony Addressing Board" (iTAB™). 

 

E27  COMPETITION 

An effort is currently underway within the IAB to define a top-tier Internet-Telephony directory structure under the ".arpa" TLD that will compete with the GITD and the ".tel" TLD at the registry level.  The proposal under review by the IAB is to give control over the registration of entries under the "e164.arpa" domain to the existing regulatory bodies that control the creation of PSTN numbers around the world.  By comparison, the ".tel" TLD is built upon the vision of giving control over registration to the telephone number subscribers (individuals and corporations) who are driving the adoption of Internet-Telephony applications.

"The existence of "e164.arpa" and ".tel" as alternative approaches for solving the global Internet-Telephony addressing challenge presents an exciting opportunity to create real competition at the Registry level in this important emerging DNS application space."

 

Beyond the obvious fact that "e164.arpa" and the GITD (".tel" TLD) are working to address the same underlying technology challenge, the key difference between the two visions is both significant and meaningful to end-users of IP-enabled communications services:

 

Existing PSTN Regulatory Control vs Subscriber Control Of Registration:

 

"e164.arpa" Control Vision:  Registration of  e164 telephone numbers on the Internet should be controlled by the existing PSTN regulatory bodies that originate and distribute telephone numbers today.

 

".tel" Control Vision:  Registration of e164 telephone numbers on the Internet should be controlled by the existing telephone number subscribers (individuals and corporations) that have paid for the right to use their telephone numbers and are driving the growth of the emerging Internet-Telephony industry. 

 

The "e164.arpa" control model is a PSTN-centric model while the ".tel" model is an Internet-Telephony centric model.  From the Internet-Telephony perspective, incumbent PSTN players (regulatory bodies and service providers) may not have the appropriate incentives to encourage the growth of the emerging Internet-Telephony industry.  Allowing an environment to emerge where there is just one "official" registry for telephone numbers on the Internet that is controlled by the incumbent PSTN regulatory infrastructure may seriously undermine the growth of an important emerging Internet industry.   

 

Advocates of the "e164.arpa" PSTN-centric model support the vision that telephone numbers are "owned" by (and should be exclusively controlled by) the regulatory entities that created the numbers in the first place.  This is certainly a valid statement from the PSTN perspective. 

 

By comparison, advocates of the ".tel" Internet-Telephony centric model support that vision that telephone number "subscribers" have paid for the right to use their phone numbers and have the right to register those numbers on the Internet when it is in their best interest.  The ".tel" vision is aligned with the subscriber perspective. 

 

Both models are valid yet supporters of both models will find eloquent arguments that support the statement that theirs is the only "correct model".   Market based competition will resolve the debate in an efficient and elegant fashion.

 

"Enabling both the "e164.arpa" implementation and the proposed ".tel" TLD will allow the market to determine which model most effectively meets the needs of the Internet community."  

E28  VALUE OF PROPOSAL AS A PROOF OF CONCEPT

The ".tel" TLD will provide ICANN with multiple opportunities to evaluate expanded uses of the DNS on a global scale, while further evolving generic TLD registry services and operating procedures:

Convergence Of Legacy PSTN And Emerging Internet Addressing: The ".tel" TLD proposes to use the DNS as a mechanism to more rapidly converge the legacy addressing structure of the PSTN with the Internet-Telephony world.  If successful, this experience will provide further insight into additional uses of the DNS in migrating other legacy addressing schemes into the Internet environment.

Utilizing The DNS To Federate Distributed LDAP Directories: The NetNumber Global Internet-Telephony Directory is a widely distributed, federated directory system providing E.164 telephone number to Uniform-Resource-Identifier and user profile translation services.  NetNumber has designed and implemented the following three different technical implementations of the GITD utilizing DNS and LDAP technologies:

(a)   DNS top-tier federating distributed DNS name servers using NAPTR resource records to return Internet address information associated with an E.164 telephone number.

(b)   DNS top-tier federating distributed DNS name servers using TXT resource records to return Internet address information associated with an E.164 telephone number.

(c)   DNS top-tier federating distributed LDAP directories using a well-defined object class to return Internet address information and other user profile data associated with an E.164 telephone number.

Early market results have shown a high level of interest and support for the DNS to LDAP approach.  The combination DNS/LDAP implementation addresses a variety of requirements from the end-user community and fits nicely into the evolution and adoption of DNS and LDAP directories in the corporate environment.

-          The DNS top tier is a highly efficient mechanism for federating a widely distributed set of LDAP directory services. 

-          LDAP is a highly efficient mechanism for storing and querying a wide range of data attributes that may be difficult or impossible to store/query in a DNS resource record format.

-          LDAP is gaining momentum as the directory standard of choice for storing and sharing end-user profile information within both the corporate environment and the service provider environment.  Witness the aggressive market push behind Microsoft's Active Directory product, SUN's iPlanet directory and the Novel Directory Service (NDS).

Lowering Barriers To Entry For Registrars:   NetNumber has proposed two Registry services that are intended to lower the barrier to entry for Registrar providers under the ".tel" TLD structure:

(a) Complete WHOIS Infrastructure:  NetNumber will provide a shared global WHOIS directory service on behalf of all ".tel" Registrars.  The objective of this service is to eliminate the requirement for Registrars to operate their own 24x7 WHOIS database infrastructure thus lowering the cost of entry for Registrars and creating consistent Whois service offering. 

(b) Shared Conflict Resolution Tool and Supporting Service:  NetNumber will provide a shared registration conflict resolution service for use by all ".tel" Registrars.  Once again, the goal of the proposed service is to lower the barrier to entry for Registrars while also seeking to smooth the interaction between multiple Registrars using the ".tel" Registry. 

 

It is the hope of the NetNumber team that the implementation ideas proposed for the ".tel" TLD will contribute to advance both the utility of the DNS in general and the efficiency of operation of gTLD's at the Registry level.

 

 


Signature Page

By signing this application through its representative, the Applicant attests that the information contained in this Description of TLD Policies, and all reference supporting documents, are true and accurate to the best of Applicant's knowledge.

 

________________________________           
Signature

David P. Peek                                              
Name (please print)

President & Secretary                                 
Title

Internet-Telephony Addressing Board Association (iTAB)
Name of Applicant Entity

________________________________
Date

 


 

 


APPENDIX A: Registrar Accreditation Process for .Tel


The Process

The process of becoming an ICANN-accredited registrar for the .tel top-level domain includes several steps. The following summary of these steps is intended to guide you through this process and enable you to make informed business decisions along the way. For a short list of the documents you must submit and/or review as part of this process, please visit Documents You Must Submit or Review.

1. Apply for Registrar Accreditation. You must complete an ICANN Registrar Accreditation Application and send it to ICANN along with a non-refundable US $1,000 application fee. You must submit the Application and review the Instructions for Completing the Application and the current Registrar Accreditation Agreement for .Tel in order to apply.

The application review process usually takes between four and six weeks. Applications with very specific, thorough answers and all necessary supporting documents may be processed more quickly. The main reason for delay is typically missing supporting documents, supporting documents which require translation into English (which ICANN requests you have done before submitting your application), and incomplete or vague answers to application questions.

Questions you may have concerning your application should be addressed to accredit@icann.org or to the ICANN Registrar Application Helpline at +1-310-823-9358, extension 22, where you can leave a voice message.

2. Receive Notification That You Qualify for Registrar Accreditation. After completing its review of your application and conducting any necessary follow-up inquiries, ICANN will inform you by e-mail of its decision to accredit your business or not. ICANN will announce your accreditation, along with contact information for your company on its web site, unless you specify that you would prefer, for business reasons, to postpone the announcement of your accreditation.

3. Sign an Accreditation Agreement with ICANN. The last step in the ICANN Registrar Accreditation process is for you to execute a Registrar Accreditation Agreement for .Tel with ICANN. The current version of the agreement was approved [DATE] by the ICANN Board of Directors. This is a standard document that all registrars sign with ICANN.

ICANN will send you two copies of the Agreement. Once you have signed both and returned them to ICANN, we will have them signed on ICANN's behalf. ICANN will then notify NetNumber.com, Inc (NNI). of your accreditation so that NNI can contact you within three to five days in order for you to start signing agreements with it and get your SRS software.

4. Receive Fully Executed Agreement from ICANN and Pay Accreditation Fee. Two or three weeks after you return your signed copies of the Registrar Accreditation Agreement to ICANN, you will receive one of the originals back, fully executed, for your records. You will also receive an invoice for the annual fixed portion of the accreditation fee, which is US$5,000.

5. Sign Confidentiality Agreement with NetNumber. NetNumber requires that you sign a Confidentiality Agreement before you are given access to certain SRS software and documentation. This agreement is contained in the NetNumber Registrar License and Agreement, which NNI will send to you after it has been notified of your accreditation by ICANN (see Step 3, above).

Before you sign your confidentiality agreement, you may get a head start on designing your system by reviewing a description of the SRS system available through NNI. .

6. Obtain Assurance of Performance. The version of the NetNumber Registrar License and Agreement currently approved for use by NNI requires registrars to have in place a US $100,000 performance assurance (such as a bond or insurance). Questions about obtaining this performance assurance should be addressed to NetNumber. More information from NNI about this requirement and others is available at NetNumber Technical Requirements for Registrars.

7. Arrange to Obtain an Appropriate SSL License. Your system's communications with the SRS will employ a secure socket layer interface. This may require you to obtain a software license from a third-party vendor.

8. Prepare to Sign a Registrar License and Agreement with NNI. NNI will send you the Registrar License and Agreement referenced above in Step 5. This must be signed and returned to NNI.


9. Prepare to Pay NNI's License Fee. NNI's SRS software license fee is a US$5,000 one-time fee. You must pay the fee before you can connect with the SRS system.

10. Obtain the RUP Software and Documentation from NNI. You will receive the RUP software (including the APIs, a reference implementation for Java, and documentation) from NNI after you have (i) signed the Registrar License and Agreement with NNI; (ii) signed the Confidentiality Agreement; and (iii) paid the NNI license fee.

11. Prepare Your Systems to Interface with the Registry. The C and Java languages are supported by the APIs. In addition to the direct registration functions to be implemented through the SRS, your system must also provide Whois (or similar) service for the names you will register for customers and also must support the ICANN data escrow program. See the ICANN Registrar Accreditation Agreement for .TEL for detailed operational requirements concerning the .TEL domain name space.

12. Test Your Software. NNI has established a test platform for your use in testing your system's interoperability with the registry’s updating process. You will be given a userid and password for this system.

13. Verify Your System's Functionality. NNI will verify that your system properly interfaces to the RUP.

14. Make Arrangements with NNI for Prepayment of Registration Fees. NNI will require that before you may actually register domain names through the RUP, you must make arrangements to pay the registry fees through a letter of credit, deposit account, or other terms acceptable to NNI.

15. Complete Preparation of Your Agreement with Customers and Uniform Domain-Name Dispute Policy. The ICANN Registrar Accreditation Agreement provides some guidance on these requirements. ICANN adopted a Uniform Dispute Resolution Policy which all accredited registrars are required to follow. You may also wish to implement a Privacy Policy to comply with the requirements of your accreditation agreement.

16. Inaugurate Your Service. After the above steps have been completed, you should be in a position to begin offering services to the public.



APPENDIX B: Registrar Accreditation Agreement for .Tel


 

REGISTRAR ACCREDITATION AGREEMENT FOR .Tel

Table of Contents

 

 

 

 

 

 

I. DEFINITIONS

II. TERMS AND CONDITIONS OF AGREEMENT

A. Accreditation.
B. Registrar Use of ICANN Name.
C. General Obligations of ICANN.
D. General Obligations of Registrar.
E. Submission of SLD Holder Data to Registry.
F. Public Access to Data on SLD Registrations.
G. Retention of SLD Holder and Registration Data.
H. Rights in Data.
I. Data Escrow.
J. Business Dealings, Including with SLD Holders.
K. Domain-Name Dispute Resolution.
L. Accreditation Fees.
M. Specific Performance.
N. Termination of Agreement.
O. Term of Agreement; Renewal; Right to Substitute Updated Agreement.
P. Resolution of Disputes Under This Agreement.
Q. Limitations on Monetary Remedies for Violations of this Agreement.
R. Handling by ICANN of Registrar-Supplied Data.
S. Miscellaneous.

This REGISTRAR ACCREDITATION AGREEMENT ("Agreement") is by and between the Internet Corporation for Assigned Names and Numbers, a not-for-profit corporation, and ________________________________ ("Registrar"), a ___________________, and shall be deemed made on __________, 1999, at Los Angeles, California, USA.

I. DEFINITIONS

As used in this Agreement, the following terms shall have the following meanings:

A. "Accredit" means to identify and set minimum standards for the performance of registration functions, to recognize persons or entities meeting those standards, and to enter into an accreditation agreement that sets forth the rules and procedures applicable to the provision of registration services.

B. A "Consensus Policy" is one adopted by ICANN as follows:

1. "Consensus Policies" are those adopted based on a consensus among Internet stakeholders represented in the ICANN process, as demonstrated by (1) the adoption of the policy by the ICANN Board of Directors, (2) a recommendation that the policy should be adopted, by at least a two-thirds vote of the council of the ICANN Supporting Organization to which the matter is delegated, and (3) a written report and supporting materials (which must include all substantive submissions to the Supporting Organization relating to the proposal) that (i) documents the extent of agreement and disagreement among impacted groups, (ii) documents the outreach process used to seek to achieve adequate representation of the views of groups that are likely to be impacted, and (iii) documents the nature and intensity of reasoned support and opposition to the proposed policy.

2. In the event that Registrar disputes the presence of such a consensus, it shall seek review of that issue from an Independent Review Panel established under ICANN's bylaws. Such review must be sought within fifteen working days of publication of the Board's action adopting the policy. The decision of the panel shall be based on the report and supporting materials required by Section I.B.1 above. In the event that Registrar seeks review and the Panel sustains the Board's determination that the policy is based on a consensus among Internet stakeholders represented in the ICANN process, then Registrar must implement such policy unless it promptly seeks and obtains a stay or injunctive relief under Section II.P.

3. In the event, following a decision by the Independent Review Panel convened under Section I.B.2 above, that Registrar still disputes the presence of such a consensus, it may seek further review of that issue within fifteen working days of publication of the decision in accordance with the dispute-resolution procedures set forth in Section II.P below; provided, however, that Registrar must continue to implement the policy unless it has obtained a stay or injunctive relief under Section II.P or a final decision is rendered in accordance with the provisions of Section II.P that relieves Registrar of such obligation. The decision in any such further review shall be based on the report and supporting materials required by Section I.B.1 above.

4. A policy adopted by the ICANN Board of Directors on a temporary basis, without a prior recommendation by the council of an ICANN Supporting Organization, shall also be considered to be a Consensus Policy if adopted by the ICANN Board of Directors by a vote of at least two-thirds of its members, and if immediate temporary adoption of a policy on the subject is necessary to maintain the stability of the Internet or the operation of the domain name system, and if the proposed policy is as narrowly tailored as feasible to achieve those objectives. In adopting any policy under this provision, the ICANN Board of Directors shall state the period of time for which the policy is temporarily adopted and shall immediately refer the matter to the appropriate Supporting Organization for its evaluation and review with a detailed explanation of its reasons for adopting the temporary policy and why the Board believes the policy should receive the consensus support of Internet stakeholders. If the period of time for which the policy is adopted exceeds 45 days, the Board shall reaffirm its temporary adoption every 45 days for a total period not to exceed 180 days, in order to maintain such policy in effect until such time as it meets the standard set forth in Section I.B.1. If the standard set forth in Section I.B.1 above is not met within the temporary period set by the Board, or the council of the Supporting Organization to which it has been referred votes to reject the temporary policy, it will no longer be a "Consensus Policy."

5. For all purposes under this Agreement, the policies specifically identified by ICANN on its website (www.icann.org/general/consensus-policies.htm) at the date of this Agreement as having been adopted by the ICANN Board of Directors before the date of this Agreement shall be treated in the same manner and have the same effect as "Consensus Policies" and accordingly shall not be subject to review under Section I.B.2.

6. In the event that, at the time the ICANN Board adopts a policy under Section I.B.1 during the term of this Agreement, ICANN does not have in place an Independent Review Panel established under ICANN's bylaws, the fifteen-working-day period allowed under Section I.B.2 to seek review shall be extended until fifteen working days after ICANN does have such an Independent Review Panel in place and Registrar shall not be obligated to comply with the policy in the interim.

C. "DNS" refers to the Internet domain-name system.

D. "ICANN" refers to the Internet Corporation for Assigned Names and Numbers, a party to this Agreement.

E. An "ICANN-adopted policy" (and references to ICANN "adopt[ing]" a policy or policies) refers to a Consensus Policy adopted by ICANN (i) in conformity with applicable provisions of its articles of incorporation and bylaws and Section II.C of this Agreement and (ii) of which Registrar has been given notice and a reasonable period in which to comply.

F. "IP" means Internet Protocol.

G. "Personal Data" refers to data about any identified or identifiable natural person.

H. The word "Registrar," when appearing with an initial capital letter, refers to ________________________________, a party to this Agreement.

I. The word "registrar," when appearing without an initial capital letter, refers to a person or entity that contracts with SLD holders and a registry, collecting registration data about the SLD holders and submitting zone file information for entry in the registry database.

J. A "Registry" is the person(s) or entity(ies) then responsible, in accordance with an agreement between ICANN and that person or entity (those persons or entities) or, if that agreement is terminated or expires, in accordance with an agreement between the US Government and that person or entity (those persons or entities), for providing registry services.

K. An "SLD" is a second-level domain name of the DNS.

L. An SLD registration is "sponsored" by the registrar that placed the record associated with that registration into the registry. Sponsorship of a registration may be changed at the express direction of the SLD holder or, in the event a registrar loses accreditation, in accordance with then-current ICANN-adopted policies.

M. A "TLD" is a top-level domain of the DNS.

N. A “SDN” is sub-domain name within the .TEL domain name space of the DNS.
(example of a SDN:    5.1.3.4.2.6.3.3.0.6.1.tel)

II. TERMS AND CONDITIONS OF AGREEMENT

The parties agree as follows:

A. Accreditation. During the term of this Agreement, Registrar is hereby accredited by ICANN to act as a registrar (including to insert and renew registration of SDNs in the registry database) for the .tel TLD.

B. Registrar Use of ICANN Name. Registrar is hereby granted a non-exclusive worldwide license to state during the term of this Agreement that it is accredited by ICANN as a registrar in the .tel TLD. No other use of ICANN's name is licensed hereby. This license may not be assigned or sublicensed by Registrar.

C. General Obligations of ICANN. With respect to all matters that impact the rights, obligations, or role of Registrar, ICANN shall during the Term of this Agreement:

1. exercise its responsibilities in an open and transparent manner;

2. not unreasonably restrain competition and, to the extent feasible, promote and encourage robust competition;

3. not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and not single out Registrar for disparate treatment unless justified by substantial and reasonable cause; and

4. ensure, through its reconsideration and independent review policies, adequate appeal procedures for Registrar, to the extent it is adversely affected by ICANN standards, policies, procedures or practices.

D. General Obligations of Registrar.

1. During the Term of this Agreement:

a. Registrar agrees that it will operate as a registrar for the TLD for which it is accredited by ICANN in accordance with this Agreement;

b. Registrar shall comply, in such operations, with all ICANN-adopted Policies insofar as they:

i. relate to one or more of the following: (A) issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, technical reliability and/or stable operation of the Internet or domain-name system, (B) registrar policies reasonably necessary to implement Consensus Policies relating to the Registry, or (C) resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names), and

ii. do not unreasonably restrain competition.

2. To the extent that Consensus Policies are adopted in conformance with Section II.C of this Agreement, the measures permissible under Section II.D.1.b.i shall include, without limitation:

i. principles for allocation of SDN names (e.g., Domain Name Policy for .Tel, timely renewal, holding period after expiration);

ii. prohibitions on warehousing of or speculation in domain names by registrars;

iii. reservation of SDN names that may not be registered initially or that may not be renewed due to reasons reasonably related to (a) avoidance of confusion among or misleading of users, (b) intellectual property, or (c) the technical management of the DNS or the Internet. (e.g., "example.com" and single-letter/digit names);

iv. the allocation among continuing registrars of the SDN names sponsored in the registry by a registrar losing accreditation;

v. the transfer of registration data upon a change in registrar sponsoring the registration; and

vi. dispute resolution policies that take into account the use of a domain name. (e.g.  Conflict Resolution Policy for .Tel)

vii. registration validation policies that take into account the resulting domain names and the authority to register them. (e.g. Registration Validation Policy for .Tel)

Nothing in this Section II.D shall limit or otherwise affect Registrar's obligations as set forth elsewhere in this Agreement.

E. Submission of SDN Holder Data to Registry. During the term of this Agreement:

1. As part of its registration of SDNs in the .tel TLD, Registrar shall submit to, or shall place in the registry database operated by Registry the following data elements concerning SDN registrations that Registrar processes:

a. The name of the SDN being registered;

b. The IP addresses of the primary nameserver and secondary nameserver(s) for the SDN;

c. The corresponding names of those nameservers;

d. Unless automatically generated by the registry system, the identity of the registrar;

e. Unless automatically generated by the registry system, the expiration date of the registration; and

f. Other data required as a result of further development of the registry system by the Registry.

2. Within five (5) business days after receiving any updates from the SDN holder to the data elements listed in Sections II.E.1.b and c for any SDN registration Registrar sponsors, Registrar shall submit the updated data elements to, or shall place those elements in the registry database operated by Registry.

3. In order to allow reconstitution of the registry database in the event of an otherwise unrecoverable technical failure or a change in the designated Registry permitted by the contract Registry has with ICANN and/or the United States Department of Commerce, within ten days of any such request by ICANN Registrar shall submit an electronic database containing the data elements listed in Sections II.F.1.a through d, j for all active records in the registry sponsored by Registrar, in a format specified by ICANN, to the Registry for the appropriate TLD.

F. Public Access to Data on SDN Registrations. During the term of this Agreement:

1. The Registry shall provide an interactive web page and a port 43 Whois service providing free complete public query-based access to up-to-date (i.e. updated at least daily) data concerning all active SDN registrations sponsored by Registrars in the registry for the .tel TLD for use by the Registrars. The data accessible shall consist of elements that are designated from time to time according to an ICANN-adopted policy. Until ICANN otherwise specifies by means of an ICANN-adopted policy, this data shall consist of the following elements as contained in Registrar's database:

a. The name of the SDN being registered and the TLD for which registration is being requested;

b. The IP addresses of the primary nameserver and secondary nameserver(s) for the SDN;

c. The corresponding names of those nameservers;

d. The identity of Registrar (which may be provided through Registrar's website);

e. The original creation date of the registration;

f. The expiration date of the registration;

g. The name and postal address of the SDN holder;

h. The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the SDN; and

i. The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the SDN.

2. Upon receiving any updates to the data elements listed in Sections II.F.1.b through d and f through j from the SDN holder, Registrar shall promptly update its database used to provide the public access described in Section II.F.1.

3. Registrar may subcontract its obligation to provide the public access described in Section II.F.1 and the updating described in Section II.F.2, provided that Registrar shall remain fully responsible for the proper provision of the access and updating.

4. Registrar shall abide by any ICANN-adopted Policy that requires registrars to cooperatively implement a distributed capability that provides query-based Whois search functionality across all registrars. If the Whois service implemented by registrars does not in a reasonable time provide reasonably robust, reliable, and convenient access to accurate and up-to-date data, the Registrar shall abide by any ICANN-adopted Policy requiring Registrar, if reasonably determined by ICANN to be necessary (considering such possibilities as remedial action by specific registrars), to supply data from Registrar's database to facilitate the development of a centralized Whois database for the purpose of providing comprehensive Registrar Whois search capability.

5. In providing query-based public access to registration data as required by Sections II.F.1 and II.F.4, Registrar shall not impose terms and conditions on use of the data provided except as permitted by an ICANN-adopted policy. Unless and until ICANN adopts a different policy, Registrar shall permit use of data it provides in response to queries for any lawful purposes except to: (a) allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail (spam); or (b) enable high volume, automated, electronic processes that apply to Registrar (or its systems).

6. In addition, Registrar shall provide third-party bulk access to the data subject to public access under Section II.F.1 under the following terms and conditions:

a. Registrar shall make a complete electronic copy of the data available at least one time per week for download by third parties who have entered into a bulk access agreement with Registrar.

b. Registrar may charge an annual fee, not to exceed US$10,000, for such bulk access to the data.

c. Registrar's access agreement shall require the third party to agree not to use the data to allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail (spam).

d. Registrar's access agreement may require the third party to agree not to use the data to enable high-volume, automated, electronic processes that apply to Registrar (or its systems).

e. Registrar's access agreement may require the third party to agree not to sell or redistribute the data except insofar as it has been incorporated by the third party into a value-added product or service that does not permit the extraction of a substantial portion of the bulk data from the value-added product or service for use by other parties.

f. Registrar may enable SDN holders who are individuals to elect not to have Personal Data concerning their registrations available for bulk access for marketing purposes based on Registrar's "Opt-Out" policy, and if Registrar has such a policy Registrar shall require the third party to abide by the terms of that Opt-Out policy; provided, however, that Registrar may not use such data subject to opt-out for marketing purposes in its own value-added product or service.

7. Registrar's obligations under Section II.F.6 shall remain in effect until the earlier of (a) replacement of this policy with a different ICANN-adopted policy governing bulk access to the data subject to public access under Section II.F.1, or (b) demonstration, to the satisfaction of the United States Department of Commerce, that no individual or entity is able to exercise market power with respect to registrations or with respect to registration data used for development of value-added products and services by third parties.

8. To comply with applicable statutes and regulations and for other reasons, ICANN may from time to time adopt policies establishing limits on the Personal Data concerning SDN registrations that Registrar may make available to the public through a public-access service described in this Section II.F and on the manner in which Registrar may make them available. In the event ICANN adopts any such policy, Registrar shall abide by it.

G. Retention of SDN Holder and Registration Data.

1. During the term of this Agreement, Registrar shall maintain its own electronic database, as updated from time to time, containing data for each active SDN registration sponsored by it in the registry for the .tel TLD. The data for each such registration shall include the elements listed in Sections II.F.1.a through k, as well as the name and (where available) postal address, e-mail address, voice telephone number, and fax number of the billing contact.

2. During the term of this Agreement and for three years thereafter, Registrar (itself or by its agent) shall maintain the following records relating to its dealings with the Registry and SDN holders:

a. In electronic form, the submission date and time, and the content, of all registration data (including updates) submitted in electronic form to the Registry;

b. In electronic, paper, or microfilm form, all written communications constituting registration applications, confirmations, modifications, or terminations and related correspondence with actual SDN holders, including registration contracts; and

c. In electronic form, records of the accounts of all SDN holders with Registrar, including dates and amounts of all payments and refunds.

Registrar shall make these records available for inspection by ICANN upon reasonable notice. ICANN shall not disclose such records except as expressly permitted by an ICANN-adopted policy.

H. Rights in Data. Registrar disclaims all rights to exclusive ownership or use of the data elements listed in Sections II.E.1.a through c for all SDN registrations submitted by Registrar to, or sponsored by Registrar in, the registry database for the .tel TLD. Registrar does not disclaim rights in the data elements listed in Sections II.E.1.d through f and II.F.1.d through i concerning active SDN registrations sponsored by it in the registry for .tel TLD, and agrees to grant non-exclusive, irrevocable, royalty-free licenses to make use of and disclose the data elements listed in Sections II.F.1.d through i for the purpose of providing a service (such as a Whois service under Section II.F.4) providing interactive, query-based public access. Upon a change in sponsorship from Registrar of any SDN registration in the registry for the .tel TLD, Registrar acknowledges that the registrar gaining sponsorship shall have the rights of an owner to the data elements listed in Sections II.E.1.d and e and II.F.1.d through i concerning that registration, with Registrar also retaining the rights of an owner in that data. Nothing in this Section II.H prohibits Registrar from (1) restricting bulk public access to data elements in a manner consistent with any ICANN-adopted policies or (2) transferring rights it claims in data elements subject to the provisions of this Section II.H.

I. Data Escrow. During the term of this Agreement, on a schedule, under the terms, and in the format specified in the then-current ICANN-adopted policy on registrar escrow requirements, Registrar shall submit an electronic copy of the database described in Section II.G.1 to ICANN or, at Registrar's election and at its expense, to a reputable escrow agent mutually approved by Registrar and ICANN, such approval also not to be unreasonably withheld by either party. The data shall be held under an agreement among Registrar, ICANN, and the escrow agent (if any) providing that (1) the data shall be received and held in escrow, with no use other than verification that the deposited data is complete and in proper format, until released to ICANN; (2) the data shall be released from escrow upon expiration without renewal or termination of this Agreement; and (3) ICANN's rights under the escrow agreement shall be assigned with any assignment of this Agreement. The escrow shall provide that in the event the escrow is released under this Section II.I, ICANN (or its assignee) shall have a non-exclusive, irrevocable, royalty-free license to exercise (only for transitional purposes) or have exercised all rights necessary to provide registrar services.

J. Business Dealings, Including with SDN Holders.

1. In the event ICANN adopts a policy supported by a consensus of ICANN-accredited registrars establishing or approving a Code of Conduct for such registrars, Registrar shall abide by that Code.

2. Registrar shall abide by applicable laws and governmental regulations.

3. Registrar shall not represent to any actual or potential SDN holder that Registrar enjoys access to a registry for which Registrar is accredited that is superior to that of any other registrar accredited for that registry.

4. Registrar shall not activate any SDN registration unless and until it is satisfied that it has received a reasonable assurance of payment of its registration fee. For this purpose, a charge to a credit card, general commercial terms extended to creditworthy customers, or other mechanism providing a similar level of assurance of payment shall be sufficient, provided that the obligation to pay becomes final and non-revocable by the SDN holder upon activation of the registration.

5. Registrar shall register SDNs to SDN holders only for fixed periods. At the conclusion of the registration period, failure by or on behalf of the SDN holder to pay a renewal fee within the time specified in a second notice or reminder shall, in the absence of extenuating circumstances, result in cancellation of the registration. In the event that ICANN adopts a policy concerning procedures for handling expiration of registrations, Registrar shall abide by that policy.

6. Registrar shall not insert or renew any SDN name in any registry for which Registrar is accredited by ICANN in a manner contrary to an ICANN-adopted policy stating a list or specification of excluded SDN names that is in effect at the time of insertion or renewal.

7. Registrar shall require all SDN holders to enter into an electronic or paper registration agreement with Registrar including at least the following provisions:

a. The SDN holder shall provide to Registrar accurate and reliable contact details and promptly correct and update them during the term of the SDN registration, including: the full name, postal address, e-mail address, voice telephone number, and fax number if available of the SDN holder; name of authorized person for contact purposes in the case of an SDN holder that is an organization, association, or corporation; and the data elements listed in Section II.F.1.b, c, and h through i above.

An SDN holder's willful provision of inaccurate or unreliable information, its willful failure promptly to update information provided to Registrar, or its failure to respond for over fifteen calendar days to inquiries by Registrar concerning the accuracy of contact details associated with the SDN holder's registration shall constitute a material breach of the SDN holder-registrar contract and be a basis for cancellation of the SDN registration.

Any SDN holder that intends to license use of a domain name to a third party is nonetheless the SDN holder of record and is responsible for providing its own full contact information and for providing and updating accurate technical and administrative contact information adequate to facilitate timely resolution of any problems that arise in connection with the SDN. An SDN holder licensing use of an SDN according to this provision shall accept liability for harm caused by wrongful use of the SDN, unless it promptly discloses the identity of the licensee to a party providing the SDN holder reasonable evidence of actionable harm.

b. Registrar shall provide notice to each new or renewed SDN holder stating:

i. The purposes for which any Personal Data collected from the applicant are intended;

ii. The intended recipients or categories of recipients of the data (including the Registry and others who will receive the data from Registry);

iii. Which data are obligatory and which data, if any, are voluntary; and

iv. How the SDN holder or data subject can access and, if necessary, rectify the data held about them.

c. The SDN holder shall consent to the data processing referred to in Section II.J.7.b.

d. The SDN holder shall represent that notice has been provided equivalent to that described in Section II.J.7.b. above to any third-party individuals whose Personal Data are supplied to Registrar by the SDN holder, and that the SDN holder has obtained consent equivalent to that referred to in Section II.J.7.c of any such third-party individuals.

e. Registrar shall agree that it will not process the Personal Data collected from the SDN holder in a way incompatible with the purposes and other limitations about which it has provided notice to the SDN holder in accordance with Section II.J.7.b, above.

f. Registrar shall agree that it will take reasonable precautions to protect Personal Data from loss, misuse, unauthorized access or disclosure, alteration, or destruction.

g. The SDN holder shall represent that, to the best of the SDN holder's knowledge and belief, neither the registration of the SDN name nor the manner in which it is directly or indirectly used infringes the legal rights of a third party.

h. For the adjudication of disputes concerning or arising from use of the SDN name, the SDN holder shall submit, without prejudice to other potentially applicable jurisdictions, to the jurisdiction of the courts (1) of the SDN holder's domicile and (2) where Registrar is located.

i. The SDN holder shall agree that its registration of the SDN name shall be subject to suspension, cancellation, or transfer pursuant to any ICANN-adopted policy, or pursuant to any registrar or registry procedure not inconsistent with an ICANN-adopted policy, (1) to correct mistakes by Registrar or the Registry in registering the name or (2) for the resolution of disputes concerning the SDN name.

j. The SDN holder shall indemnify and hold harmless the Registry and its directors, officers, employees, and agents from and against any and all claims, damages, liabilities, costs, and expenses (including reasonable legal fees and expenses) arising out of or related to the SDN holder's domain name registration.

8. Registrar shall abide by any ICANN-adopted policies requiring reasonable and commercially practicable (a) verification, at the time of registration, of contact information associated with an SDN registration sponsored by Registrar or (b) periodic re-verification of such information. Registrar shall, upon notification by any person of an inaccuracy in the contact information associated with an SDN registration sponsored by Registrar, take reasonable steps to investigate that claimed inaccuracy. In the event Registrar learns of inaccurate contact information associated with an SDN registration it sponsors, it shall take reasonable steps to correct that inaccuracy.

9. Registrar shall abide by any ICANN-adopted policy prohibiting or restricting warehousing of or speculation in domain names by registrars.

10. Registrar shall maintain in force commercial general liability insurance with policy limits of at least US$500,000 covering liabilities arising from Registrar's registrar business during the term of this Agreement.

11. Nothing in this Agreement prescribes or limits the amount Registrar may charge SDN holders for registration of SDN names.

K. Domain-Name Dispute Resolution. During the term of this Agreement, Registrar shall have in place a policy and procedure for resolution of disputes concerning SDN names.  This policy should not conflict with the Conflict Resolution Policy for .Tel. In the event that ICANN adopts a policy or procedure for resolution of disputes concerning SDN names that by its terms applies to Registrar, Registrar shall adhere to the policy or procedure.

L. Accreditation Fees. As a condition of accreditation, Registrar shall pay accreditation fees to ICANN. These fees consist of yearly and on-going components.

1. The yearly component for the term of this Agreement shall be US $5,000. Payment of the yearly component shall be due upon execution by Registrar of this Agreement and upon each anniversary date after such execution during the term of this Agreement (other than the expiration date).

2. Registrar shall pay the on-going component of Registrar accreditation fees adopted by ICANN in accordance with the provisions of Section II.C above, provided such fees are reasonably allocated among all registrars that contract with ICANN and that any such fees must be expressly approved by registrars accounting, in aggregate, for payment of two-thirds of all registrar-level fees. Registrar shall pay such fees in a timely manner for so long as all material terms of this Agreement remain in full force and effect, and notwithstanding the pendency of any dispute between Registrar and ICANN.

3. On reasonable notice given by ICANN to Registrar, accountings submitted by Registrar shall be subject to verification by an audit of Registrar's books and records by an independent third-party that shall preserve the confidentiality of such books and records (other than its findings as to the accuracy of, and any necessary corrections to, the accountings).

M. Specific Performance. While this Agreement is in effect, either party may seek specific performance of any provision of this Agreement in the manner provided in Section II.P below, provided the party seeking such performance is not in material breach of its obligations.

N. Termination of Agreement. This Agreement may be terminated before its expiration by Registrar by giving ICANN thirty days written notice. It may be terminated before its expiration by ICANN in any of the following circumstances:

1. There was a material misrepresentation, material inaccuracy, or materially misleading statement in Registrar's application for accreditation or any material accompanying the application.

2. Registrar:

a. is convicted of a felony or other serious offense related to financial activities, or is judged by a court to have committed fraud or breach of fiduciary duty, or is the subject of a judicial determination that ICANN reasonably deems as the substantive equivalent of any of these; or

b. is disciplined by the government of its domicile for conduct involving dishonesty or misuse of funds of others.

3. Any officer or director of Registrar is convicted of a felony or of a misdemeanor related to financial activities, or is judged by a court to have committed fraud or breach of fiduciary duty, or is the subject of a judicial determination that ICANN deems as the substantive equivalent of any of these; provided, such officer or director is not removed in such circumstances.

4. Registrar fails to cure any breach of this Agreement (other than a failure to comply with a policy adopted by ICANN during the term of this Agreement as to which Registrar is seeking, or still has time to seek, review under Section I.B.2 of whether a consensus is present) within fifteen working days after ICANN gives Registrar notice of the breach.

5. Registrar fails to comply with a ruling granting specific performance under Sections II.M and II.P.

6. Registrar continues acting in a manner that ICANN has reasonably determined endangers the stability or operational integrity of the Internet after receiving three days notice of that determination.

7. Registrar becomes bankrupt or insolvent.

This Agreement may be terminated in circumstances 1 through 6 above only upon fifteen days written notice to Registrar (in the case of circumstance 4 occurring after Registrar's failure to cure), with Registrar being given an opportunity during that time to initiate arbitration under Section II.P to determine the appropriateness of termination under this Agreement. In the event Registrar initiates litigation or arbitration concerning the appropriateness of termination by ICANN, the termination shall be stayed an additional thirty days to allow Registrar to obtain a stay of termination under Section II.P below. If Registrar acts in a manner that ICANN reasonably determines endangers the stability or operational integrity of the Internet and upon notice does not immediately cure, ICANN may suspend this Agreement for five working days pending ICANN's application for more extended specific performance or injunctive relief under Section II.P. This Agreement may be terminated immediately upon notice to Registrar in circumstance 7 above.

O. Term of Agreement; Renewal; Right to Substitute Updated Agreement. This Agreement shall have an initial term until [specific date to be inserted: five years for most agreements; for agreements substituting for the prior one-year agreements the inserted date will be the existing (one year) termination date of those agreements, as required by Section III.M of those agreements], unless sooner terminated. Thereafter, if Registrar seeks to continue its accreditation, it may apply for renewed accreditation, and shall be entitled to renewal provided it meets the ICANN-adopted policy on accreditation criteria then in effect, is in compliance with its obligations under this Agreement, as amended, and agrees to be bound by the then-current Registrar accreditation agreement (which may differ from those of this Agreement) that ICANN adopts in accordance with Sections II.C and II.D (as Section II.D may have been amended by an ICANN-adopted policy). In connection with renewed accreditation, Registrar shall confirm its assent to the terms and conditions of the such then-current Registrar accreditation agreement by signing that accreditation agreement. In the event that, during the term of this Agreement, ICANN posts on its web site an updated form of registrar accreditation agreement applicable to accredited registrars in the .tel TLD, Registrar (provided it has not received (1) a notice of breach that it has not cured or (2) a notice of termination of this Agreement under Section II.N above) may elect, by giving ICANN written notice, to enter an agreement in the updated form in place of this Agreement. In the event of such election, Registrar and ICANN shall promptly sign a new accreditation agreement that contains the provisions of the updated form posted on the web site, with the length of the term of the substituted agreement as stated in the updated form posted on the web site, calculated as if it commenced on the date this Agreement was made, and this Agreement will be deemed terminated.

P. Resolution of Disputes Under this Agreement. Disputes arising under or in connection with this Agreement, including (1) disputes arising from ICANN's failure to renew Registrar's accreditation and (2) requests for specific performance, shall be resolved in a court of competent jurisdiction or, at the election of either party, by an arbitration conducted as provided in this Section II.P pursuant to the International Arbitration Rules of the American Arbitration Association ("AAA"). The arbitration shall be conducted in English and shall occur in Los Angeles County, California, USA. There shall be three arbitrators: each party shall choose one arbitrator and, if those two arbitrators do not agree on a third arbitrator, the third shall be chosen by the AAA. The parties shall bear the costs of the arbitration in equal shares, subject to the right of the arbitrators to reallocate the costs in their award as provided in the AAA rules. The parties shall bear their own attorneys' fees in connection with the arbitration, and the arbitrators may not reallocate the attorneys' fees in conjunction with their award. The arbitrators shall render their decision within ninety days of the conclusion of the arbitration hearing. In the event Registrar initiates arbitration to contest the appropriateness of termination of this Agreement by ICANN, Registar may at the same time request that the arbitration panel stay the termination until the arbitration decision is rendered, and that request shall have the effect of staying the termination until the arbitration panel has granted an ICANN request for specific performance and Registrar has failed to comply with such ruling. In the event Registrar initiates arbitration to contest an Independent Review Panel's decision under Section I.B.2 sustaining the Board's determination that a policy is supported by consensus, Registar may at the same time request that the arbitration panel stay the requirement that it comply with the policy until the arbitration decision is rendered, and that request shall have the effect of staying the requirement until the decision or until the arbitration panel has granted an ICANN request for lifting of the stay. In all litigation involving ICANN concerning this Agreement (whether in a case where arbitration has not been elected or to enforce an arbitration award), jurisdiction and exclusive venue for such litigation shall be in a court located in Los Angeles, California, USA; however, the parties shall also have the right to enforce a judgment of such a court in any court of competent jurisdiction. For the purpose of aiding the arbitration and/or preserving the rights of the parties during the pendency of an arbitration, the parties shall have the right to seek temporary or preliminary injunctive relief from the arbitration panel or in a court located in Los Angeles, California, USA, which shall not be a waiver of this arbitration agreement.

Q. Limitations on Monetary Remedies for Violations of this Agreement. ICANN's aggregate monetary liability for violations of this Agreement shall not exceed the amount of accreditation fees paid by Registrar to ICANN under Section II.L of this Agreement. Registrar's monetary liability to ICANN for violations of this Agreement shall be limited to accreditation fees owing to ICANN under this Agreement. In no event shall either party be liable for special, indirect, incidental, punitive, exemplary, or consequential damages for any violation of this Agreement.

R. Handling by ICANN of Registrar-Supplied Data. Before receiving any Personal Data from Registrar, ICANN shall specify to Registrar in writing the purposes for and conditions under which ICANN intends to use the Personal Data. ICANN may from time to time provide Registrar with a revised specification of such purposes and conditions, which specification shall become effective no fewer than thirty days after it is provided to Registrar. ICANN shall not use Personal Data provided by Registrar for a purpose or under conditions inconsistent with the specification in effect when the Personal Data were provided. ICANN shall take reasonable steps to avoid uses of the Personal Data by third parties inconsistent with the specification.

S. Miscellaneous.

1. Assignment. Either party may assign or transfer this Agreement only with the prior written consent of the other party, which shall not be unreasonably withheld, except that ICANN may, with the written approval of the United States Department of Commerce, assign this agreement by giving Registrar written notice of the assignment. In the event of assignment by ICANN, the assignee may, with the approval of the United States Department of Commerce, revise the definition of "Consensus Policy" to the extent necessary to meet the organizational circumstances of the assignee, provided the revised definition requires that Consensus Policies be based on a demonstrated consensus of Internet stakeholders.

2. No Third-Party Beneficiaries. This Agreement shall not be construed to create any obligation by either ICANN or Registrar to any non-party to this Agreement, including any SLD holder.

3. Notices, Designations, and Specifications. All notices to be given under this Agreement shall be given in writing at the address of the appropriate party as set forth below, unless that party has given a notice of change of address in writing. Any notice required by this Agreement shall be deemed to have been properly given when delivered in person, when sent by electronic facsimile, or when scheduled for delivery by internationally recognized courier service. Designations and specifications by ICANN under this Agreement shall be effective when written notice of them is deemed given to Registrar.

If to ICANN, addressed to:

Internet Corporation for Assigned Names and Numbers
Registrar Accreditation
4676 Admiralty Way, Suite 330
Marina Del Rey, California 90292
Telephone: 1/310/823-9358
Facsimile: 1/310/823-8649

If to Registrar, addressed to:

With a copy to:

4. Dates and Times. All dates and times relevant to this Agreement or its performance shall be computed based on the date and time observed in Boston, Massachusetts, USA.

5. Language. All notices, designations, and specifications made under this Agreement shall be in the English language.

6. Entire Agreement. Except for any written transition agreement that may be executed concurrently herewith by both parties, this Agreement constitutes the entire agreement of the parties hereto pertaining to the subject matter hereof and supersedes all prior agreements, understandings, negotiations and discussions, whether oral or written, of the parties.

7. Amendments and Waivers. No amendment, supplement, or modification of this Agreement or any provision hereof shall be binding unless executed in writing by both parties. No waiver of any provision of this Agreement shall be binding unless evidenced by a writing signed by the party waiving compliance with such provision. No waiver of any of the provisions of this Agreement shall be deemed or shall constitute a waiver of any other provision hereof, nor shall any such waiver constitute a continuing waiver unless otherwise expressly provided.

8. Counterparts. This Agreement may be executed in one or more counterparts, each of which shall be deemed an original, but all of which together shall constitute one and the same instrument.

IN WITNESS WHEREOF, the parties hereto have caused this Agreement to be executed in duplicate by their duly authorized representatives.

INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS

 

By:__________________________
Michael M. Roberts
President and CEO

 

[REGISTRAR]

 

By:__________________________


APPENDIX C: NetNumber Registrar License and  Agreement for .Tel


 

REGISTRAR LICENSE AND              

                                                       AGREEMENT FOR .Tel

This Registrar License and Agreement (the "Agreement") is dated as of __________, 2000 ("Effective Date") by and between NetNumber.com, Inc., a Delaware corporation, with its principal place of business located at 650 Suffolk St., Suite 307, Lowell, Massachusetts  01854 ("NNI" or the "Registry"), and _________________, a _____________________ corporation, with its principal place of business located at ___________________________________ ("Registrar"). NNI and Registrar may be referred to individually as a "Party" and collectively as the "Parties."

WHEREAS, multiple registrars will provide Internet domain name registration services within the .tel top-level domain wherein NNI operates and maintains certain TLD servers and zone files ("Registry");

WHEREAS, Registrar wishes to register sub-domain names in the multiple registrar system for the .tel TLD.

NOW, THEREFORE, for and in consideration of the mutual promises, benefits and covenants contained herein and for other good and valuable consideration, the receipt, adequacy and sufficiency of which are hereby acknowledged, NNI and Registrar, intending to be legally bound, hereby agree as follows:

1. DEFINITIONS

1.1. "DNS" refers to the Internet domain name system.

1.2. "IP" means Internet Protocol.

1.3. An "SLD" is a second-level domain of the DNS.

1.4. The "System" refers to the multiple registrar system developed by NNI for registration of sub-domain names in the .tel TLD.

1.5. A "TLD" is a top-level domain of the DNS.

1.6. The "Licensed Product" refers to the RUP, APIs, and software, collectively.

1.7. The "SDN" is sub-domain name of the DNS representing a valid domain-name within the .tel TLD.

1.8.  “iTAB” refers to the Internet-Telephony Addressing Board.

 

2. OBLIGATIONS OF THE PARTIES

2.1. System Operation and Access. Throughout the Term of this Agreement, NNI shall operate the System and provide Registrar with access to the System enabling Registrar to transmit domain name registration information for the .tel TLD to the System according to a protocol developed by NNI and to be known as the “.tel” Registrar Update Protocol ("RUP").

2.2. Distribution of RUP, APIs and Software. No later than three business days after the Effective Date of this Agreement, NNI shall provide to Registrar (i) full documentation of the RUP, (ii) "C" and "Java" application program interfaces ("APIs") to the RUP with documentation, and (iii) reference client software ("Software") that will enable Registrar to develop its system to register sub-domain names through the System for the .tel TLD. If NNI elects to modify or upgrade the APIs and/or RUP, NNI shall provide updated APIs to the RUP with documentation and updated Software to Registrar promptly as such updates become available.

2.3. New Architectural Features. NNI will use its best commercial efforts to develop and implement two additional modifications to the Licensed Product by January 15, 2000 as follows:

2.3.1. NNI will issue an upgrade to the Licensed Product that will enable a Registrar to accept initial domain name registrations or renewals of a minimum of one year in length, or in multiples of one year increments.

2.3.2. NNI will issue an upgrade to the Licensed Product that will enable registrars to accept the addition of one additional year to a registrant's "current" registration period when a registrant changes from one registrar to another.

In no event shall the total unexpired term of a registration exceed ten (10) years.

Registrars will be able to offer these new features only for new registrations or renewals occurring after the Upgrade is deployed. Both Upgrades will be introduced into the Operational Test and Evaluation environment for testing prior to deployment.

2.4. Registrar Responsibility for Customer Support. Registrar shall be responsible for providing customer service (including domain name record support), billing and technical support, and customer interface to accept customer (the "SDN holder") orders.

2.5. Data Submission Requirements. As part of its registration of all SDN registrations in the .tel TLD during the Term of this Agreement, Registrar shall submit the following data elements using the RUP concerning SDN registrations it processes:

2.5.1. The name of the SDN being registered;

2.5.2. The IP addresses of the primary nameserver and secondary nameserver(s) for the SDN;

2.5.3. The corresponding host names of those nameservers;

2.5.4. Unless automatically generated by the registry system, the identity of the registrar;

2.5.5. Unless automatically generated by the registry system, the expiration date of the registration; and

2.5.6. Other data required as a result of further development of the registry system by the Registry.

2.6. License. Registrar grants NNI as Registry a non-exclusive non-transferable limited license to the data elements consisting of the SDN name registered the IP addresses of nameservers, and the identity of the registering registrar for propagation of and the provision of authorized access to the TLD zone files.

2.7. Registrar's Registration Agreement and Domain Name Dispute Policy. Registrar shall have developed and employ in its domain name registration business an electronic or paper registration agreement, including a domain name dispute policy, a copy of which is attached to this Agreement as Exhibit A (which may be amended from time to time by Registrar, provided a copy is furnished to the Registry three (3) business days in advance of any such amendment), to be entered into by Registrar with each SDN holder as a condition of registration. Registrar shall include terms in its agreement with each SDN holder that are consistent with Registrar's duties to NNI hereunder.

2.8. Secure Connection. Registrar agrees to develop and employ in its domain name registration business all necessary technology and restrictions to ensure that its connection to the System is secure. All data exchanged between Registrar's system and the System shall be protected to avoid unintended disclosure of information. Each RUP session shall be authenticated and encrypted using two-way secure socket layer ("SSL") protocol. Registrar agrees to authenticate every RUP client connection with the System using both an X.509 server certificate issued by a commercial Certification Authority identified by the Registry and its Registrar password, which it shall disclose only to its employees with a need to know. Registrar agrees to notify Registry within four hours of learning that its Registrar password has been compromised in any way or if its server certificate has been revoked by the issuing Certification Authority or compromised in any way.

2.9. Domain Name Lookup Capability. Registrar agrees to employ in its domain name registration business NNI's Registry domain name lookup capability to determine if a requested domain name is available or currently unavailable for registration.

2.10. Transfer of Sponsorship of Registrations. Registrar agrees to implement transfers of SDN registrations from another registrar to Registrar and vice versa pursuant to the Policy on Transfer of Sponsorship of Registrations Between Registrars appended hereto as Exhibit B.

2.11. Time. Registrar agrees that in the event of any dispute concerning the time of the entry of a domain name registration into the Registry database, the time shown in the NNI Registry records shall control.

2.12. Compliance with Terms and Conditions. Registrar agrees to comply with all other reasonable terms or conditions established from time to time, to assure sound operation of the System, by NNI as Registry in a non-arbitrary manner and applicable to all registrars, including NNI, and consistent with NSI Cooperative Agreement with the United States Government or NNI's Registry Agreement with the Internet-Telephony Address Board (“iTAB”) Internet Corporation for Assigned Names and Numbers ("ICANN"), as applicable, upon NNI's notification to Registrar of the establishment of those terms and conditions.

2.13. Resolution of Technical Problems. Registrar agrees to employ necessary employees, contractors, or agents with sufficient technical training and experience to respond to and fix all technical problems concerning the use of the RUP and the APIs in conjunction with Registrar's systems. Registrar agrees that in the event of significant degradation of the System or other emergency, NetNumber, as Registry, may, in its sole discretion, temporarily suspend access to the System. Such temporary suspensions shall be applied in a nonarbitrary manner and shall apply fairly to any registrar similarly situated, including NNI.

2.14. Surety Instrument. During the Initial Term and any Renewal Terms, Registrar shall have in place a performance bond, letter of credit or equivalent instrument (the "Surety Instrument") from a surety acceptable to NNI, in the amount of $100,000 U.S. dollars. The terms of the Surety Instrument shall indemnify and hold harmless NNI and its employees, directors, officers, representatives, agents and affiliates from all costs and damages (including reasonable attorneys' fees) which it may suffer by reason of Registrar's failure to indemnify NNI as provided in Section 6.16 by making payment(s) up to the full amount of the bond within ten (10) days of NNI's having notified the surety of its claim(s) of damages, having identified the basis for any such claim. NNI shall not be entitled to payment under the Surety Instrument until such time as it has certified that it has incurred expenses for which it is entitled to reimbursement in accordance with the provisions of Section 6.16 of this Agreement.

2.15. Prohibited Domain Name Registrations. Registrar agrees to comply with the policies of NNI as Registry that will be applicable to all registrars and that will prohibit the registration of certain domain names in the .tel TLD which are not allowed to be registered by statute or regulation.

2.16. Indemnification Required of SDN Holders. Registrar shall require each SDN holder to indemnify, defend and hold harmless NNI, and its directors, officers, employees and agents from and against any and all claims, damages, liabilities, costs and expenses, including reasonable legal fees and expenses arising out of or relating to the SDN holder's domain name registration.


3. LICENSE

3.1. License Grant. Subject to the terms and conditions of this Agreement, NNI hereby grants Registrar and Registrar accepts a non-exclusive, non-transferable, worldwide limited license to use for the Term and purposes of this Agreement the RUP, APIs and Software, as well as updates and redesigns thereof, to provide domain name registration services in the .tel TLD only and for no other purpose. The RUP, APIs and Software, as well as updates and redesigns thereof, will enable Registrar to register domain names with the Registry on behalf of its SDN holders. Registrar, using the RUP, APIs and Software, as well as updates and redesigns thereof, will be able to invoke the following operations on the System: (i) check the availability of a domain name, (ii) register a domain name, (iii) re-register a domain name, (iv) cancel the registration of a domain name it has registered, (v) update the nameservers of a domain name, (vi) transfer a domain name from another registrar to itself with proper authorization, (vii) query a domain name registration record, (viii) register a nameserver, (ix) update the IP addresses of a nameserver, (x) delete a nameserver, (xi) query a nameserver, and (xii) establish and end an authenticated session. (xiii)

3.2. Limitations on Use. Notwithstanding any other provisions in this Agreement, except with the written consent of NNI, Registrar shall not: (i) sublicense the RUP, APIs or Software or otherwise permit any use of the RUP, APIs or Software by or for the benefit of any party other than Registrar, (ii) publish, distribute or permit disclosure of the RUP, APIs or Software other than to employees, contractors, and agents of Registrar for use in Registrar's domain name registration business, (iii) decompile, reverse engineer, copy or re-engineer the RUP, APIs or Software for any unauthorized purpose, or (iv) use or permit use of the RUP, APIs or Software in violation of any federal, state or local rule, regulation or law, or for any unlawful purpose.

Registrar agrees to employ the necessary measures to prevent its access to the System granted hereunder from being used for (i) the transmission of unsolicited, commercial e?mail (spam) to entities other than Registrar's customers; (ii) high volume, automated, electronic processes that apply to NNI for large numbers of domain names, except as reasonably necessary to register domain names or modify existing registrations; or (iii) high volume, automated, electronic, repetitive queries for the purpose of extracting data to be used for Registrar's purposes, except as reasonably necessary to register domain names or modify existing registrations.

3.3. Changes to Licensed Materials. NNI may from time to time make modifications to the RUP, APIs or Software licensed hereunder that will enhance functionality or otherwise improve the System. NNI will provide Registrar with at least sixty (60) days notice prior to the implementation of any material changes to the RUP, APIs or software licensed hereunder.

4. SUPPORT SERVICES

4.1. Engineering Support. NNI agrees to provide Registrar with reasonable engineering telephone support (between the hours of 9 a.m. to 5 p.m. local Boston, Massachusetts time or at such other times as may be mutually agreed upon) to address engineering issues arising in connection with Registrar's use of the System.

4.2. Customer Service Support. During the Term of this Agreement, NNI will provide reasonable telephone and e-mail customer service support to Registrar, not SDN holders or prospective customers of Registrar, for non-technical issues solely relating to the System and its operation. NNI will provide Registrar with a telephone number and e-mail address for such support during implementation of the RUP, APIs and Software. First-level telephone support will be available on a 7-day/24-hour basis and provided by a web-based customer service. NNI will provide a web-based customer service capability in the future and such web-based support will become the primary method of customer service support to Registrar at such time.

5. FEES

5.1. License Fee. As consideration for the license of the RUP, APIs and Software, Registrar agrees to pay NNI on the Effective Date a non-refundable one-time fee in the amount of $ 5,000 payable in United States dollars (the "License Fee") and payable by check to NetNumber.com, Inc., Attention: Registry Accounts Receivable, 650 Suffolk St., Suite 307, Lowell, MA 01854 or by wire transfer to (BANK), for the credit of NetNumber.com, Inc., Account #xxxxxxxxxxx, ABA #xxxxxxxxx, Swift, xxxxxxxxx. No later than three (3) business days after either the receipt (and final settlement if payment by check) of such License Fee, or the Effective Date of this Agreement, whichever is later, NNI will provide the RUP, APIs and Software to Registrar.

5.2. Registration Fees.

(a)   Registrars shall pay a fee of $0.50 per month for each entry in the Registry.

(b)   NNI reserves the right to adjust the Registration Fees prospectively upon thirty (30) days prior notice to Registrar, provided that such adjustments are consistent with NNI's Cooperative Agreement with the United States Government or its Registry Agreement with iTAB ICANN, as applicable, and are applicable to all registrars in the .tel TLD. NNI will invoice Registrar monthly in arrears for each month's Registration Fees. All Registration Fees are due immediately upon receipt of NNI's invoice pursuant to a letter of credit, deposit account, or other acceptable credit terms agreed by the Parties.

5.3. Change in Registrar Sponsoring Domain Name. Registrar may assume sponsorship of an SND holder's existing domain name registration from another registrar by following the policy set forth in Exhibit B to this Agreement. Registrar agrees to pay NNI the applicable Registration Fee as set forth above. For transfers taking place after January 15, 2000, this shall result in a corresponding extension of the existing registration, provided that in no event shall the total unexpired term of a registration exceed ten (10) years. The losing registrar's Registration Fees will not be refunded as a result of any such transfer.

5.4. Non-Payment of Registration Fees. Timely payment of Registration Fees is a material condition of performance under this Agreement. In the event that Registrar fails to pay its Registration Fees, either initial or re-registration fees, within five (5) days of the date when due, NNI may stop accepting new registrations and/or delete the domain names associated with invoices not paid in full from the Registry database and give written notice of termination of this Agreement pursuant to Section 6.1(b) below.

6. MISCELLANEOUS

6.1. Term of Agreement and Termination.

(a) Term of the Agreement. The duties and obligations of the Parties under this Agreement shall apply from the Effective Date through and including the last day of the calendar month sixty (60) months from the Effective Date (the "Initial Term"). Upon conclusion of the Initial Term, all provisions of this Agreement will automatically renew for successive five (5) year renewal periods until the Agreement has been terminated as provided herein, Registrar elects not to renew, or NNI ceases to operate as the registry for the .tel TLD. In the event that revisions to NNI's Registrar License and Agreement are approved or adopted by the Internet-Telephony Addressing Board U.S. Department of Commerce, or ICANN, as appropriate, Registrar will execute an amendment substituting the revised agreement in place of this Agreement, or Registrar may, at its option exercised within fifteen (15) days, terminate this Agreement immediately by giving written notice to NNI.

(b) Termination For Cause. In the event that either Party materially breaches any term of this Agreement including any of its representations and warranties hereunder and such breach is not substantially cured within thirty (30) calendar days after written notice thereof is given by the other Party, then the non-breaching Party may, by giving written notice thereof to the other Party, terminate this Agreement as of the date specified in such notice of termination.

(c) Termination at Option of Registrar. Registrar may terminate this Agreement at any time by giving NNI thirty (30) days notice of termination.

(d) Termination Upon Loss of Registrar's Accreditation. This Agreement shall terminate in the event Registrar's accreditation by ICANN, or its successor, is terminated or expires without renewal.

(e) Termination in the Event that Successor Registry is Named. This Agreement shall terminate in the event that the Internet-Telephony Addressing Board U.S. Department of Commerce or ICANN, as appropriate, designates another entity to serve as the registry for the .tel TLD (the "Successor Registry").

(f) Termination in the Event of Bankruptcy. Either Party may terminate this Agreement if the other Party is adjudged insolvent or bankrupt, or if proceedings are instituted by or against a Party seeking relief, reorganization or arrangement under any laws relating to insolvency, or seeking any assignment for the benefit of creditors, or seeking the appointment of a receiver, liquidator or trustee of a Party's property or assets or the liquidation, dissolution or winding up of a Party's business.

(g) Effect of Termination. Upon expiration or termination of this Agreement, NNI will complete the registration of all domain names processed by Registrar prior to the date of such expiration or termination, provided that Registrar's payments to NNI for Registration Fees are current and timely. Immediately upon any expiration or termination of this Agreement, Registrar shall (i) transfer its sponsorship of SDN name registrations to another licensed registrar(s) of the Registry, in compliance with any procedures established or approved by the the Internet-Telephony Addressing Board U.S. Department of Commerce or ICANN, as appropriate, and (ii) either return to NNI or certify to NNI the destruction of all data, software and documentation it has received under this Agreement.

(h) Survival. In the event of termination of this Agreement, the following shall survive: (i) Sections 2.6, 2.7, 6.1(g), 6.6, 6.7, 6.10, 6.12, 6.13, 6.14 and 6.16; (ii) the SDN holder's obligations to indemnify, defend, and hold harmless NNI, as stated in Section 2.16; (iii) the surety's obligations under the Surety Instrument described in Section 2.14 with respect to matters arising during the term of this Agreement; and (iv) Registrar's payment obligations as set forth in Section 5.2 with respect to initial registrations or re-registrations during the term of this Agreement. Neither Party shall be liable to the other for damages of any sort resulting solely from terminating this Agreement in accordance with its terms but each Party shall be liable for any damage arising from any breach by it of this Agreement.

6.2. No Third Party Beneficiaries; Relationship of The Parties. This Agreement does not provide and shall not be construed to provide third parties (i.e., non-parties to this Agreement), including any SDN holder, with any remedy, claim, cause of action or privilege. Nothing in this Agreement shall be construed as creating an employer-employee or agency relationship, a partnership or a joint venture between the Parties.

6.3. Force Majeure. Neither Party shall be responsible for any failure to perform any obligation or provide service hereunder because of any Act of God, strike, work stoppage, governmental acts or directives, war, riot or civil commotion, equipment or facilities shortages which are being experienced by providers of telecommunications services generally, or other similar force beyond such Party's reasonable control.

6.4. Further Assurances. Each Party hereto shall execute and/or cause to be delivered to each other Party hereto such instruments and other documents, and shall take such other actions, as such other Party may reasonably request for the purpose of carrying out or evidencing any of the transactions contemplated by this Agreement.

6.5. Amendment in Writing. Any amendment or supplement to this Agreement shall be in writing and duly executed by both Parties.

6.6. Attorneys' Fees. If any legal action or other legal proceeding (including arbitration) relating to the performance under this Agreement or the enforcement of any provision of this Agreement is brought against either Party hereto, the prevailing Party shall be entitled to recover reasonable attorneys' fees, costs and disbursements (in addition to any other relief to which the prevailing Party may be entitled).

6.7. Dispute Resolution; Choice of Law; Venue. The Parties shall attempt to resolve any disputes between them prior to resorting to litigation. This Agreement is to be construed in accordance with and governed by the internal laws of the Commonwealth of Massachusetts Virginia, United States of America without giving effect to any choice of law rule that would cause the application of the laws of any jurisdiction other than the internal laws of the Commonwealth of Massachusetts Virginia to the rights and duties of the Parties. Any legal action or other legal proceeding relating to this Agreement or the enforcement of any provision of this Agreement shall be brought or otherwise commenced in any state or federal court located in the eastern district of the Commonwealth of Massachusetts Virginia. Each Party to this Agreement expressly and irrevocably consents and submits to the jurisdiction and venue of each state and federal court located in the eastern district of the Commonwealth of Massachusetts Virginia (and each appellate court located in the Commonwealth of Massachusetts Virginia) in connection with any such legal proceeding.

6.8. Notices. Any notice or other communication required or permitted to be delivered to any Party under this Agreement shall be in writing and shall be deemed properly delivered, given and received when delivered (by hand, by registered mail, by courier or express delivery service, by e-mail or by telecopier during business hours) to the address or telecopier number set forth beneath the name of such Party below, unless party has given a notice of a change of address in writing:

if to Registrar:

__________________________________________
__________________________________________
__________________________________________
__________________________________________
__________________________________________
__________________________________________

with a copy to:

__________________________________________
__________________________________________
__________________________________________
__________________________________________
__________________________________________
__________________________________________


if to NNI:

NetNumber.com, Inc.
650 Suffolk St., Suite 307
Lowell, MA 01854
Attention: Customer Affairs
Facsimile : +1 (978) 454-5044

with a copy to:

General Counsel
650 Suffolk St., Suite 307
Lowell, MA 01854
Attention: Customer Affairs
Facsimile : +1 (978) 454-5044


6.9. Assignment/Sublicense. Except as otherwise expressly provided herein, the provisions of this Agreement shall inure to the benefit of and be binding upon, the successors and permitted assigns of the Parties hereto. Registrar shall not assign, sublicense or transfer its rights or obligations under this Agreement to any third person without the prior written consent of NNI.

6.10. Use of Confidential Information. The Parties' use and disclosure of Confidential Information disclosed hereunder are subject to the terms and conditions of the Parties' Confidentiality Agreement (Exhibit C) that will be executed contemporaneously with this Agreement. Registrar agrees that the RUP, APIs and Software are the Confidential Information of NNI.

6.11. Delays or Omissions; Waivers. No failure on the part of either Party to exercise any power, right, privilege or remedy under this Agreement, and no delay on the part of either Party in exercising any power, right, privilege or remedy under this Agreement, shall operate as a waiver of such power, right, privilege or remedy; and no single or partial exercise or waiver of any such power, right, privilege or remedy shall preclude any other or further exercise thereof or of any other power, right, privilege or remedy. No Party shall be deemed to have waived any claim arising out of this Agreement, or any power, right, privilege or remedy under this Agreement, unless the waiver of such claim, power, right, privilege or remedy is expressly set forth in a written instrument duly executed and delivered on behalf of such Party; and any such waiver shall not be applicable or have any effect except in the specific instance in which it is given.

6.12. Limitation of Liability. IN NO EVENT WILL NNI BE LIABLE TO REGISTRAR FOR ANY SPECIAL, INDIRECT, INCIDENTAL, PUNITIVE, EXEMPLARY OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES RESULTING FROM LOSS OF PROFITS, ARISING OUT OF OR IN CONNECTION WITH THIS AGREEMENT, EVEN IF NNI HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

6.13. Construction. The Parties agree that any rule of construction to the effect that ambiguities are to be resolved against the drafting Party shall not be applied in the construction or interpretation of this Agreement.

6.14. Intellectual Property. Subject to Section 2.6 above, each Party will continue to independently own its intellectual property, including all patents, trademarks, trade names, service marks, copyrights, trade secrets, proprietary processes and all other forms of intellectual property.

6.15. Representations and Warranties

(a) Registrar. Registrar represents and warrants that: (1) it is a corporation duly incorporated, validly existing and in good standing under the law of the ______________, (2) it has all requisite corporate power and authority to execute, deliver and perform its obligations under this Agreement, (3) it is, and during the Term of this Agreement will continue to be, accredited by ICANN or its successor, pursuant to an accreditation agreement dated after November 4, 1999, (4) the execution, performance and delivery of this Agreement has been duly authorized by Registrar, (5) no further approval, authorization or consent of any governmental or regulatory authority is required to be obtained or made by Registrar in order for it to enter into and perform its obligations under this Agreement, and (6) Registrar's Surety Instrument provided hereunder is a valid and enforceable obligation of the surety named on such Surety Instrument.

(b) NNI. NNI represents and warrants that: (1) it is a corporation duly incorporated, validly existing and in good standing under the laws of the State of Delaware, (2) it has all requisite corporate power and authority to execute, deliver and perform its obligations under this Agreement, (3) the execution, performance and delivery of this Agreement has been duly authorized by NNI, and (4) no further approval, authorization or consent of any governmental or regulatory authority is required to be obtained or made by NNI in order for it to enter into and perform its obligations under this Agreement.

(c) Disclaimer of Warranties. The RUP, APIs and Software are provided "as-is" and without any warranty of any kind. NNI EXPRESSLY DISCLAIMS ALL WARRANTIES AND/OR CONDITIONS, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY OR SATISFACTORY QUALITY AND FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. NNI DOES NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE RRP, APIs OR SOFTWARE WILL MEET REGISTRAR'S REQUIREMENTS, OR THAT THE OPERATION OF THE RUP, APIs OR SOFTWARE WILL BE UNINTERRUPTED OR ERROR-FREE, OR THAT DEFECTS IN THE RRP, APIs OR SOFTWARE WILL BE CORRECTED. FURTHERMORE, NNI DOES NOT WARRANT NOR MAKE ANY REPRESENTATIONS REGARDING THE USE OR THE RESULTS OF THE RUP, APIs, SOFTWARE OR RELATED DOCUMENTATION IN TERMS OF THEIR CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE. SHOULD THE RUP, APIs OR SOFTWARE PROVE DEFECTIVE, REGISTRAR ASSUMES THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION OF REGISTRAR'S OWN SYSTEMS AND SOFTWARE.

6.16. Indemnification. Registrar, at its own expense and within thirty (30) days of presentation of a demand by NNI under this paragraph, will indemnify, defend and hold harmless NNI and its employees, directors, officers, representatives, agents and affiliates, against any claim, suit, action, or other proceeding brought against NNI or any affiliate of NNI based on or arising from any claim or alleged claim (i) relating to any product or service of Registrar; (ii) relating to any agreement, including Registrar's dispute policy, with any SDN holder of Registrar; or (iii) relating to Registrar's domain name registration business, including, but not limited to, Registrar's advertising, domain name application process, systems and other processes, fees charged, billing practices and customer service; provided, however, that in any such case: (a) NNI provides Registrar with prompt notice of any such claim, and (b) upon Registrar's written request, NNI will provide to Registrar all available information and assistance reasonably necessary for Registrar to defend such claim, provided that Registrar reimburses NNI for its actual and reasonable costs. Registrar will not enter into any settlement or compromise of any such indemnifiable claim without NNI's prior written consent, which consent shall not be unreasonably withheld. Registrar will pay any and all costs, damages, and expenses, including, but not limited to, reasonable attorneys' fees and costs awarded against or otherwise incurred by NNI in connection with or arising from any such indemnifiable claim, suit, action or proceeding.

6.17. Entire Agreement; Severability. This Agreement, which includes Exhibits A, B and C, constitutes the entire agreement between the Parties concerning the subject matter hereof and supersedes any prior agreements, representations, statements, negotiations, understandings, proposals or undertakings, oral or written, with respect to the subject matter expressly set forth herein. If any provision of this Agreement shall be held to be illegal, invalid or unenforceable, each Party agrees that such provision shall be enforced to the maximum extent permissible so as to effect the intent of the Parties, and the validity, legality and enforceability of the remaining provisions of this Agreement shall not in any way be affected or impaired thereby. If necessary to effect the intent of the Parties, the Parties shall negotiate in good faith to amend this Agreement to replace the unenforceable language with enforceable language that reflects such intent as closely as possible.

IN WITNESS WHEREOF, the Parties hereto have executed this Agreement as of the date set forth in the first paragraph hereof.

 NetNumber.com, Inc.

By:________________________

Name:_____________________

Title:______________________

 [Registrar]

By:________________________

Name:_____________________

Title:______________________

 

Exhibit A

Registrar's Dispute Policy


[To be supplied from time to time by Registrar]

 

Exhibit B

Policy on Transfer of Sponsorship of Registrations Between Registrars

 

Registrar Requirements.

The registration agreement between each Registrar and its SDN holder shall include a provision explaining that an SDN holder will be prohibited from changing its Registrar during the first 60 days after initial registration of the domain name with the Registrar. Beginning on the 61st day after the initial registration with the Registrar, the procedures for change in sponsoring registrar set forth in this policy shall apply. Enforcement shall be the responsibility of the Registrar sponsoring the domain name registration.

For each instance where an SDN holder wants to change its Registrar for an existing domain name (i.e., a domain name that appears in a particular top-level domain zone file), the gaining Registrar shall:

1) Obtain express authorization from an individual who has the apparent authority to legally bind the SDN holder (as reflected in the database of the losing Registrar).

a) The form of the authorization is at the discretion of each gaining Registrar.
b) The gaining Registrar shall retain a record of reliable evidence of the authorization.

2) In those instances when the Registrar of record is being changed simultaneously with a transfer of a domain name from one party to another, the gaining Registrar shall also obtain appropriate authorization for the transfer. Such authorization shall include, but not be limited to, one of the following:

a) A bilateral agreement between the parties.
b) The final determination of a binding dispute resolution body.
c) A court order.

3) Request, by the transmission of a "transfer" command as specified in the Registry Registrar Protocol, that the Registry database be changed to reflect the new Registrar.

a) Transmission of a "transfer" command constitutes a representation on the part of the gaining Registrar that:

(1) the requisite authorization has been obtained from the SDN holder listed in the database of the losing Registrar, and
(2) the losing Registrar will be provided with a copy of the authorization if and when requested.

In those instances when the Registrar of record denies the requested change of Registrar, the Registrar of record shall notify the prospective gaining Registrar that the request was denied and the reason for the denial.

Instances when the requested change of sponsoring Registrar may be denied include, but are not limited to:

1) Situations described in the Domain Name Dispute Resolution Policy
2) A pending bankruptcy of the SDN Holder
3) Dispute over the identity of the SDN Holder
4) Request to transfer sponsorship occurs within the first 60 days after the initial registration with the Registrar

In all cases, the losing Registrar shall respond to the e-mail notice regarding the "transfer" request within five (5) days. Failure to respond will result in a default "approval" of the "transfer."

Registry Requirements.

Upon receipt of the "transfer" command from the gaining Registrar, the Registry will transmit an e-mail notification to both Registrars.

The Registry shall complete the "transfer" if either:

1) the losing Registrar expressly "approves" the request, or
2) the Registry does not receive a response from the losing Registrar within five (5) days.

When the Registry's database has been updated to reflect the change to the gaining Registrar, the Registry will transmit an email notification to both Registrars.

Records of Registration.

Each SDN holder shall maintain its own records appropriate to document and prove the initial domain name registration date, regardless of the number of Registrars with which the SDN holder enters into a contract for registration services.

 



Exhibit C

CONFIDENTIALITY AGREEMENT

THIS CONFIDENTIALITY AGREEMENT is entered into by and between NetNumber.com, Inc. ("NNI"), a Delaware corporation having its principal place of business in Lowell, MA, and ________________________, a _________ corporation having its principal place of business in __________________ ("Registrar"), through their authorized representatives, and takes effect on the date executed by the final party (the "Effective Date").

Under this Confidentiality Agreement ("Confidentiality Agreement"), the Parties intend to disclose to one another information which they consider to be valuable, proprietary, and confidential.

NOW, THEREFORE, the parties agree as follows:

1. Confidential Information

1.1. "Confidential Information", as used in this Confidentiality Agreement, shall mean all information and materials including, without limitation, computer software, data, information, databases, protocols, reference implementation and documentation, and functional and interface specifications, provided by the disclosing party to the receiving party under this Confidentiality Agreement and marked or otherwise identified as Confidential, provided that if a communication is oral, the disclosing party will notify the receiving party in writing within 15 days of the disclosure.

2. Confidentiality Obligations

2.1. In consideration of the disclosure of Confidential Information, the Parties agree that:

(a) The receiving party shall treat as strictly confidential, and use all reasonable efforts to preserve the secrecy and confidentiality of, all Confidential Information received from the disclosing party, including implementing reasonable physical security measures and operating procedures.

(b) The receiving party shall make no disclosures whatsoever of any Confidential Information to others, provided however, that if the receiving party is a corporation, partnership, or similar entity, disclosure is permitted to the receiving party's officers, employees, contractors and agents who have a demonstrable need to know such Confidential Information, provided the receiving party shall advise such personnel of the confidential nature of the Confidential Information and of the procedures required to maintain the confidentiality thereof, and shall require them to acknowledge in writing that they have read, understand, and agree to be individually bound by the terms of this Confidentiality Agreement.

(c) The receiving party shall not modify or remove any Confidential legends and/or copyright notices appearing on any Confidential Information.

2.2. The receiving party's duties under this section (2) shall expire five (5) years after the information is received or earlier, upon written agreement of the Parties.

3. Restrictions On Use

3.1. The receiving party agrees that it will use any Confidential Information received under this Confidentiality Agreement solely for the purpose of providing domain name registration services as a registrar and for no other purposes whatsoever.

3.2. No commercial use rights or any licenses under any patent, patent application, copyright, trademark, know-how, trade secret, or any other NNI proprietary rights are granted by the disclosing party to the receiving party by this Confidentiality Agreement, or by any disclosure of any Confidential Information to the receiving party under this Confidentiality Agreement.

3.3. The receiving party agrees not to prepare any derivative works based on the Confidential Information.

3.4. The receiving party agrees that any Confidential Information which is in the form of computer software, data and/or databases shall be used on a computer system(s) that is owned or controlled by the receiving party.

4. Miscellaneous

4.1. This Confidentiality Agreement shall be governed by and construed in accordance with the laws of the Commonwealth of Massachusetts Virginia and all applicable federal laws. The Parties agree that, if a suit to enforce this Confidentiality Agreement is brought in the U.S. Federal District Court for the Eastern District of Massachusetts Virginia, they will be bound by any decision of the Court.

4.2. The obligations set forth in this Confidentiality Agreement shall be continuing, provided, however, that this Confidentiality Agreement imposes no obligation upon the Parties with respect to information that (a) is disclosed with the disclosing party's prior written approval; or (b) is or has entered the public domain through no fault of the receiving party; or (c) is known by the receiving party prior to the time of disclosure; or (d) is independently developed by the receiving party without use of the Confidential Information; or (e) is made generally available by the disclosing party without restriction on disclosure.

4.3. This Confidentiality Agreement may be terminated by either party upon breach by the other party of any its obligations hereunder and such breach is not cured within three (3) calendar days after the allegedly breaching party is notified by the disclosing party of the breach. In the event of any such termination for breach, all Confidential Information in the possession of the Parties shall be immediately returned to the disclosing party; the receiving party shall provide full voluntary disclosure to the disclosing party of any and all unauthorized disclosures and/or unauthorized uses of any Confidential Information; and the obligations of Sections 2 and 3 hereof shall survive such termination and remain in full force and effect. In the event that the Registrar License and Agreement between the Parties is terminated, the Parties shall immediately return all Confidential Information to the disclosing party and the receiving party shall remain subject to the obligations of Sections 2 and 3.

4.4. The terms and conditions of this Confidentiality Agreement shall inure to the benefit of the Parties and their successors and assigns. The Parties' obligations under this Confidentiality Agreement may not be assigned or delegated.

4.5. The Parties agree that they shall be entitled to seek all available legal and equitable remedies for the breach of this Confidentiality Agreement.

4.6. The terms and conditions of this Confidentiality Agreement may be modified only in a writing signed by NNI and Registrar.

4.7. EXCEPT AS MAY OTHERWISE BE SET FORTH IN A SIGNED, WRITTEN AGREEMENT BETWEEN THE PARTIES, THE PARTIES MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESSED OR IMPLIED, AS TO THE ACCURACY, COMPLETENESS, CONDITION, SUITABILITY, PERFORMANCE, FITNESS FOR A PARTICULAR PURPOSE, OR MERCHANTABILITY OF ANY CONFIDENTIAL INFORMATION, AND THE PARTIES SHALL HAVE NO LIABILITY WHATSOEVER TO ONE ANOTHER RESULTING FROM RECEIPT OR USE OF THE CONFIDENTIAL INFORMATION.

4.8. If any part of this Confidentiality Agreement is found invalid or unenforceable, such part shall be deemed stricken herefrom and the Parties agree: (a) to negotiate in good faith to amend this Confidentiality Agreement to achieve as nearly as legally possible the purpose or effect as the stricken part, and (b) that the remainder of this Confidentiality Agreement shall at all times remain in full force and effect.

4.9. This Confidentiality Agreement contains the entire understanding and agreement of the Parties relating to the subject matter hereof.

4.10. Any obligation imposed by this Confidentiality Agreement may be waived in writing by the disclosing party. Any such waiver shall have a one-time effect and shall not apply to any subsequent situation regardless of its similarity.

4.11. Neither Party has an obligation under this Confidentiality Agreement to purchase, sell, or license any service or item from the other Party.

4.12. The Parties do not intend that any agency or partnership relationship be created between them by this Confidentiality Agreement.

IN WITNESS WHEREOF, and intending to be legally bound, duly authorized representatives of NNI and Registrar have executed this Confidentiality Agreement in Virginia on the dates indicated below.

("Registrar") NetNumber.com, Inc. ("NNI")

By: ____________________________ By: __________________________
Title: ___________________________ Title:_________________________
Date:___________________________ Date:_________________________


 

APPENDIX D:  Rules for Conflict Resolution Policy for .Tel


   Rules for
Conflict Resolution Policy for .Tel

               (the "Rules")

Administrative proceedings for the resolution of conflict under the Conflict Resolution Policy for .Tel adopted by Internet-Telephony Addressing Board (“iTAB”) shall be governed by these Rules and also the Supplemental Rules of the Registry administering the proceedings, as posted on its web site.

1. Definitions

In these Rules:

Complainant means the party initiating a complaint concerning a domain-name registration.

iTAB refers to the Internet-Telephony Addressing Board.

NNI refers to NetNumber.com, Inc; the Registry.

Party means a Complainant or a Respondent.

Policy means the Conflict Resolution Policy for .Tel that is incorporated by reference and made a part of the Registration Agreement for .Tel.

Registrar means the entity with which the Respondent has registered a domain name that is the subject of a complaint.

Registration Agreement means the agreement between a Registrar and a “.tel” domain-name holder.

Respondent means the holder of a “.tel” domain-name registration against which a complaint is initiated.

Reverse Domain Name Hijacking means using the Policy in bad faith to attempt to deprive a registered domain-name holder of a domain name.

Supplemental Rules means the rules adopted by the Registry administering a proceeding to supplement these Rules. Supplemental Rules shall not be inconsistent with the Policy or these Rules and shall cover such topics as fees, word and page limits and guidelines, and the means for communicating with the Registry.

2. Communications

(a) When forwarding a complaint of conflict to the Respondent, it shall be the Registry’s responsibility to employ reasonably available means calculated to achieve actual notice to Respondent. Achieving actual notice, or employing the following measures to do so, shall discharge this responsibility:

(i) sending the complaint in electronic form by e-mail to:

(A) the e-mail addresses for those technical, administrative, and billing contacts;

(ii) sending the complaint to any address the Respondent has notified the Registrar it prefers and, to the extent practicable, to all other addresses provided to the Registrar by Complainant under Paragraph 3(b)(iv).

(b) Except as provided in Paragraph 2(a), any written communication to Complainant or Respondent provided for under these Rules shall be made by the preferred means stated by the Complainant or Respondent, respectively (see Paragraphs 3(b)(iii) and 5(b)(iii)), or in the absence of such specification

 (i) Electronically via the Internet, a record of successful transmission is preferred if available.

(iI) by telecopy or facsimile transmission, with a confirmation of transmission; is required if electronic messaging fails.

(c) Communications shall be made in the language prescribed in Paragraph 6. E-mail communications should, if practicable, be sent in plaintext.

(d) Either Party may update its contact details by notifying the Registry if automated services for doing so are available.

(e) Except as otherwise provided in these Rules, all communications provided for under these Rules shall be deemed to have been made:

(i) if via the Internet, on the date that the communication was transmitted, provided that the date of transmission is verifiable;

(ii) if delivered by telecopy or facsimile transmission, on the date shown on the confirmation of transmission.

(f) Except as otherwise provided in these Rules, all time periods calculated under these Rules to begin when a communication is made shall begin to run on the earliest date that the communication is deemed to have been made in accordance with Paragraph 2(e).

(g) It shall be the responsibility of the sender to retain records of the fact and circumstances of sending, which shall be available for inspection by affected parties and for reporting purposes.

(h) In the event a Party sending a communication receives notification of non-delivery of the communication, the Party shall promptly notify other parties of the circumstances of the notification. Further proceedings concerning the communication and any response shall be as directed by the Registry.

3. The Complaint

(a) Any person or entity may initiate an conflict proceeding, after receiving a denial of registration, by submitting a complaint in accordance with the Policy and these Rules to any “.tel” accredited Registrar. (Due to capacity constraints or for other reasons, a Registrar's ability to accept complaints may be suspended at times. In that event, the Registrar shall refuse the submission. The person or entity may submit the complaint to another Registrar following a subsequent denial of registration from that Registrar.)

(b) The complaint shall be submitted in electronic form and shall:

(i) Request that the complaint be submitted for decision in accordance with the Policy and these Rules;

(ii) Provide the name, postal and e-mail addresses, and the telephone and telefax numbers of the Complainant and of any representative authorized to act for the Complainant in the administrative proceeding;

(iii) Specify a preferred method for communications directed to the Complainant in the administrative proceeding (including person to be contacted, medium, and email address information) for each of (A) electronic-only material and (B) material including hard copy;

(iv) Provide the name of the Respondent (domain-name holder) and any e-mail addresses and telephone and telefax numbers known to Complainant regarding how to contact Respondent;

(v) Specify the domain name(s) that is/are the subject of the complaint;

(vi) Identify the Registrar(s) with whom the domain name(s) is/are registered at the time the complaint is filed known to the Complainant;

(vii) Conclude with the following statement followed by the signature of the Complainant or its authorized representative:

"Complainant agrees that its claims and remedies concerning the registration of the domain name, the conflict, or the conflict's resolution shall be solely against the domain-name holder and waives all such claims and remedies against (a) the registry, except in the case of deliberate wrongdoing, (b) the registrar, (c) the Internet-Telephony Addressing Board, as well as their directors, officers, employees, and agents."

"Complainant certifies that the information contained in this Complaint is to the best of Complainant's knowledge complete and accurate, that this Complaint is not being presented for any improper purpose, such as to harass, and that the assertions in this Complaint are warranted under these Rules and under applicable law, as it now exists or as it may be extended by a good-faith and reasonable argument."

“Complainant agrees to fees defined by the Supplemental Rules of the Registry in the case of deliberate false claims or  inaccurate claims”;
and

 (c) The complaint may relate to more than one domain name, provided that the domain names are registered by the same domain-name holder.

(d) The Registrar, upon accepting a complete complaint, electronically submits the complaint to the Respondent via the Registry’s Registry Conflict Resolution Tool (CRT).

4. Notification of Complaint

(a) The Registry upon accepting the complaint and if found in compliance with the Policy and these Rules shall follow the Policy in regards to verifying and validating the complaint.

(b) If the Registrar finds the complaint to be administratively deficient or finds the complaint to fail validation, it shall promptly notify the Complainant of the nature of the deficiencies identified. The Complainant shall have five (5) calendar days within which to correct any such deficiencies, after which the automated proceeding will be deemed withdrawn without prejudice to submission of a different complaint by Complainant.

(c) The date of commencement of the automated proceeding shall be the date on which the Registrar completes its responsibilities under Paragraph 2(a) in connection with forwarding the Complaint to the Respondent and requesting Respondent action.

 

5. The Response

(a) Within ten (10) days of the date of commencement of the automated proceeding the Respondent shall submit a response to the Registry.

(b) The response shall be submitted in electronic form by the Respondent or any representative authorized to act for the Respondent and shall:

(i) Respond in full compliance with specific directions defined in the complaint message.  Reference numbers may be required to fill in at a web site or URLs may be used to direct the Respondent further.

(ii) If the Respondent intents to relinquish control of the domain-name in response to the complaint then the Respondent shall comply with the requirements to do so.   The Respondent will only complete its   obligations when the Respondent receives notification from the Registry through the CRT that is has accepted and completed the conflict resolution process.

(ii) If Respondent claims the complaint is false or inaccurate then the Respondent is to comply with the Registry’s requirements defined in the message or in links provided in the message, to notify the Registry  specifically to the statements and allegations contained in the complaint and include any and all bases for the Respondent (domain-name holder) to retain registration and use of the domain name in conflict. (This portion of the response shall comply with word or page limit set forth in the Registry’s Supplemental Rules (if any));

(iii) Conclude with the following statement followed by an electronic method that the Respondent has accepted this statement:

"Respondent certifies that the information contained in this Response is to the best of Respondent's knowledge complete and accurate, that this Response is not being presented for any improper purpose, such as to harass, and that the assertions in this Response are warranted under these Rules and under applicable law, as it now exists or as it may be extended by a good-faith and reasonable argument."

“Respondent understands false claims to domain names are subject to fees according to the Registration Agreement and to the Supplemental Rules of the Registry’s CRC”;

(c) At the request of the Respondent, the Registry may, in exceptional cases, extend the period of time for the filing of the response. The period may also be extended by written stipulation between the Parties.

 (d) If a Respondent does not submit a response, in the absence of exceptional circumstances, the Registry shall decide the dispute based upon the complaint.

6. Language of Proceedings

(a) Unless otherwise agreed by the Parties, or specified otherwise in the Registration Agreement, the language of the administrative proceeding shall be the language of the Registration Agreement, subject to the authority of the Registry to determine otherwise, having regard to the circumstances of the automated proceeding.

7. Default

(a) In the event that a Party, in the absence of exceptional circumstances, does not comply with any of the time periods established by these Rules, the Registry shall proceed to a decision on the complaint.

(b) If a Party, in the absence of exceptional circumstances, does not comply with any provision of, or requirement under, these Rules, the Registry shall draw such inferences therefrom as it considers appropriate.

8. Registry Decisions

(a) The Registry shall decide a complaint on the basis of the statements and documents submitted and in accordance with the Policy, these Rules and any rules and principles of law that it deems applicable.

(b) In the unlikely event there is insufficient information for the Registry to decide a complaint automatically by use of the Registry Conflict Resolution Center (CRC) and both the Complainant and Respondent continue to claim authority for the domain-name the ICANN UDRP Policy will be engaged.

9. Communication of Decision to Parties

(a) Within three (3) calendar days after receiving the response from the Respondent, the Registry shall communicate the full text of the decision to each Party.

(b) The Registry may opt to publish the full decision and the date of its automated implementation on a publicly accessible web site. In any event, the portion of any decision determining a complaint to have been brought in bad faith shall be published.

10. Settlement or Other Grounds for Termination

(a) If, before the automated process is complete, it becomes unnecessary or impossible to continue the administrative proceeding for any reason, the Registry shall terminate the automated proceeding, unless a Party raises justifiable grounds for objection within ten (10) days.

11. Fees

(a) In exceptional circumstances, the complainant or respondent may be required to pay a fee to the Registry, in accordance with the Registry's Supplemental Rules for the CRC and as part of the Registration Agreements for .Tel, within the time and in the amount required if the complaint was unjustified or deemed to be in bad faith.  Typically there will be no fee for the automated conflict resolution process.

(b) In the event the conflict can not be resolved through the automated conflict resolution process and the Registry’s CRC then  the ICANN UDRP process is engage the respondent and complainant will be subject to fees imposed by that Policy and its rules.

12. Exclusion of Liability

Except in the case of deliberate wrongdoing, neither the Registry nor a CRC Expert shall be liable to a Party for any act or omission in connection with any administrative or automated proceeding under these Rules.

21. Amendments

The version of these Rules in effect at the time of the submission of the complaint to the Registrar shall apply to the automated proceeding commenced thereby. These Rules may not be amended without the express written approval of  iTAB.


APPENDIX E:  Conflict Resolution Policy for .Tel


 
Conflict Resolution Policy for .Tel  (sample)

 

 

1. Purpose. This Conflict Resolution Policy for .Tel (the "Policy") has been adopted by the Internet-Telephony Addressing Board (“iTAB”), is incorporated by reference into your Registration Agreement for .Tel, and sets forth the terms and conditions in connection with a conflict between you and another potential registrant (other than us, the registrar) over the registration and use of an Internet domain name registered by you. Proceedings under Paragraph 4 of this Policy will be conducted according to the Rules for Conflict Resolution for .Tel (the "Rules of Procedure"), and any of the Registry’s CRC supplemental rules.

2. Your Representations. By applying to register a domain name, or by asking us to maintain or renew a domain name registration, you hereby represent and warrant to us that (a) the statements that you made in your Registration Agreement are complete and accurate; (b) to your knowledge, the registration of the domain name will not infringe upon or otherwise violate the rights of any third party; (c) you are not registering the domain name for an unlawful purpose; and (d) you will not knowingly use the domain name in violation of any applicable laws or regulations. It is your responsibility to determine whether your domain name registration infringes or violates someone else's rights.

3. Cancellations, Transfers, and Changes. We will cancel, transfer or otherwise make changes to domain name registrations under the following circumstances:

a. subject to the provisions of Paragraph 8, our receipt of written or appropriate electronic instructions from you or your authorized agent to take such action;

b. our receipt of an order from a court or arbitral tribunal, in each case of competent jurisdiction, requiring such action; and/or

c. our receipt of a decision of the Registry’s CRC requiring such action in any administrative proceeding to which you were a party and which was conducted under this Policy or a later version of this Policy adopted by iTAB. (See Paragraph 4(i) and (k) below.)

We may also cancel, transfer or otherwise make changes to a domain name registration in accordance with the terms of your Registration Agreement or other legal requirements.

4. Mandatory Administrative Proceeding.

This paragraph sets forth the type of conflict for which you are required to submit to a mandatory administrative proceeding. These proceedings will be administered and tracked by the Registry’s automated CRT service.

a. Domain Name Conflicts. You are required to submit to a mandatory administrative proceeding in the event that a third party (a "complainant") asserts to the Registry, in compliance with the Rules of Procedure, that

(i) your domain name is identical to an E.164 number  in which the complainant has rights; and

(ii) you have no rights in respect of the domain name; or

(iii) your domain name has been registered and is being used in bad faith.

During administrative proceeding, the complainant must prove that (i) and (ii) elements are present or that element (iii) is present.

b. How to disagree with the complaint . When you receive a complaint, you will have the option to dispute the complaint if you believe and can demonstrate that you have rights to the E.164 number corresponding to the domain name in conflict.

c. Remedies. The remedies available to a complainant prior to engaging the Registry’s Conflict Resolution Center or the ICANN UDRP Policy shall be limited to requiring the cancellation of your domain name or the transfer of your domain name registration to the complainant.

d. Notification and Publication. The Registry shall notify us (the Registrar) of any decision made with respect to a domain name you have registered with us. All decisions under this Policy will be published in full over the Internet, except when the Registry CRC determines in an exceptional case to redact portions of its decision.

 

5. All Other Disputes and Litigation. All other disputes between you and any party other than us regarding your domain name registration that are not brought pursuant to the mandatory administrative proceeding provisions of Paragraph 4 shall be resolved between you and such other party through any court, arbitration or other proceeding that may be available.

6. Registrar Obligations

a. Validation of complaint: The Registrar receiving the complaint is to seek proof that this new potential registrant has day-to-day control over the E.164 number by using processes defined in the Registration Validation Policy found in Appendix G.2.

If the complaint is verified the process continues otherwise the complainant is notified that the complaint is being held until proper verification can be obtained. 

b. Additional Procedures and Policies:  In addition to this policy, the Registrar receiving the compliant must adhere to any supplemental rules defined by the Registry for use of the Registry’s Conflict Resolution Tool and/or the Registry’s Conflict Resolution Center.

 

6. Registry Obligations

a. Sending Notification to Respondant: After the complaint has passed validation the current registrant of the domain-name (the respondent) is notified of the complaint by the Registry’s CRT service.   The respondent is given the option to relinquish control of the domain-name through simple and secure methods.  Typically complaints will end at this stage, as the respondent may recognize his/her failure to comply with the policies of a valid domain name registration.   The respondent at this point should voluntarily cancel the registration thereby allowing the complainant to complete proper registration. 

 

c. if Registry’s CRT Automated Resolution fails: In some circumstances it is conceivable that both the complainant and the respondent might continue to declare “day-to-day” control over the same E.164 telephone number thereby claiming to be the valid authority of the associated domain-name within “.tel”.  If the automated process for resolution conflict is insufficient and/or fails to resolve the conflict then the Registry’s Conflict Resolution Center is engaged. 

d. If Registry’s CRC Resolution fails: In very rare cases if the respondent and complainant continue the dispute and insufficient evidence of “day-to-day” control is retrieved by the CRC then the complainant has the final option to engage the standard ICANN Uniform Dispute Resolution Policy.  Each party must meet the new requirements and responsibilities imposed by that Policy.

 

6. Our Involvement in Disputes. We will not participate in any way in any dispute between you and any party other than us regarding the registration and use of your domain name. You shall not name us as a party or otherwise include us in any such proceeding. In the event that we are named as a party in any such proceeding, we reserve the right to raise any and all defenses deemed appropriate, and to take any other action necessary to defend ourselves.

7. Maintaining the Status Quo. We will not cancel, transfer, activate, deactivate, or otherwise change the status of any domain name registration under this Policy except as provided in Paragraph 3 above.

8. Transfers During a Dispute.

a. Transfers of a Domain Name to a New Holder. You may not transfer your domain name registration to another holder (i) during a pending administrative proceeding brought pursuant to Paragraph 4 or for a period of fifteen (15) business days (as observed in the location of our principal place of business) after such proceeding is concluded; or (ii) during a pending court proceeding or arbitration commenced regarding your domain name unless the party to whom the domain name registration is being transferred agrees, in writing, to be bound by the decision of the court or arbitrator. We reserve the right to cancel any transfer of a domain name registration to another holder that is made in violation of this subparagraph.

b. Changing Registrars. You may not transfer your domain name registration to another registrar during a pending administrative proceeding brought pursuant to Paragraph 4 or for a period of fifteen (15) business days (as observed in the location of our principal place of business) after such proceeding is concluded. You may transfer administration of your domain name registration to another registrar during a pending court action or arbitration, provided that the domain name you have registered with us shall continue to be subject to the proceedings commenced against you in accordance with the terms of this Policy. In the event that you transfer a domain name registration to us during the pendency of a court action or arbitration, such dispute shall remain subject to the domain name dispute policy of the registrar from which the domain name registration was transferred.

9. Policy Modifications. We reserve the right to modify this Policy at any time with the permission of iTAB. We will post our revised Policy at <URL> at least thirty (30) calendar days before it becomes effective. Unless this Policy has already been invoked by the submission of a complaint to a Provider, in which event the version of the Policy in effect at the time it was invoked will apply to you until the dispute is over, all such changes will be binding upon you with respect to any domain name registration dispute, whether the dispute arose before, on or after the effective date of our change. In the event that you object to a change in this Policy, your sole remedy is to cancel your domain name registration with us, provided that you will not be entitled to a refund of any fees you paid to us. The revised Policy will apply to you until you cancel your domain name registration.



APPENDIX F:  Domain Naming Policy for .Tel


 

   Domain Naming Policy for .Tel (Sample)

 

 

1. Purpose. This Domain Naming Policy for .Tel (the "Policy") has been adopted by the Internet-Telephony Addressing Board (“iTAB”) and is incorporated by reference into your Registration Agreement for .Tel, and sets forth the terms and conditions under which a domain name is determined to be “valid” for registration in the “.tel” gTLD.

2. Definitions

2.1.    "DNS" refers to the Internet domain name system.

2.2.     A "TLD" is a top-level domain of the DNS

2.3.           “E.164 number” is the international format of an individual telephone number.

2.4.           “Day-to-Day control” refers to having the authority of adding, changing, or deleting services applied to a specific E.164 number.   An end-user or subscriber who has been assigned a telephone number with telephone service has day-to-day control over the E.164 number.

3. E.164 Numbers and Domain-Names. A domain name that becomes part of the “.tel” domain name space is derived directly from an E.164 number.  A registrant of “.tel” defines an E.164 number that results in a specific domain name rather than the enabling the registrant to define an arbitrary domain name.  The registrant has no control over the actual domain name that is ultimately registered in “.tel” although the final domain name may be derived by following a set of rules defined in Paragraph 4 of this policy.  
  

4. E.164 Number to Domain Name Rules. The following rules define how a domain name is derived from an E.164 number during the registration process.

   1.  See that the E.164 number is written in its full form, including

       the country code ID. Example: +46-8-9761234 
 
   2.  Remove all non-digit characters with the exception of the
       leading '+'. Example: +4689761234 
 
   3.  Remove all characters with the exception of the digits. Example:
       4689761234 
 
   4.  Put dots (".") between each digit. Example: 4.6.8.9.7.6.1.2.3.4 
 
   5.  Reverse the order of the digits. Example: 4.3.2.1.6.7.9.8.6.4 
 
   6.  Append the TLD string ".tel" to the end. Example:
       4.3.2.1.6.7.9.8.6.4.tel 


The string resulting from these rules define the domain name to be registered in the “.tel” TLD. 


5. Sub-Domain Delegation.  There are no DNS delegations of any sub-domains outside the registry prior to a sub-domain that defines a complete E.164 number.  Delegation to proprietary and custom sub zones occur only after the complete E.164 number has been defined within the Registry’s zone.  Further delegation to proprietary and custom sub-domains and the definition of sub-domain names that extend the “.tel” domain name space may occur at this point.

               MySubDomain.Mysub.4.3.2.1.6.7.9.8.6.4.tel

            |_____Private zone_____||______ Registry zone _____|

 

6. Recommended Use of Sub-Domain Names  The use of specific sub-domain names outside the registry are under complete control of the operator of the delegated zone.  In order to provide interoperability for specific applications and uses of “.tel” sub-domain names within the “.tel” domain name space will be recommended and produce on an IETF standards track to promote efficient use of the “.tel” TLD.

 


APPENDIX G: Registration Validation Policy for .Tel


 

 Registration Validation Policy for .Tel (Sample)

 

1. Purpose. This Registration Validation Policy for .Tel (the "Policy") has been adopted by the Internet Telephony Addressing Board (iTAB), is incorporated by reference into your Registration Agreement for .Tel, and sets forth the terms and conditions in connection with you, as a registrant, being validated as the authorized registrant for the domain-name you are requesting registration or are currently holding within .tel gTLD.  Proceedings under Paragraph 5 and procedures under Paragraph 4 will be conducted according to this Policy and the selected Registrar's supplemental rules.

2. Your Representations. By applying to register a .tel domain name, or by asking us to maintain or renew a .tel domain name registration, or at anytime this Policy is initiated as a result of domain name conflict resolution procedures, you hereby represent and warrant to us that (a) the statements that you made in your Registration Agreement are complete and accurate; (b) to your knowledge, the registration of the domain name will not infringe upon or otherwise violate the rights of any third party; (c) you are not registering the domain name for an unlawful purpose; and (d) you will not knowingly use the domain name in violation of any applicable laws or regulations. It is your responsibility to assure that the E.164 telephone number used to derive your domain name registration is under your day-to-day control and not under someone else’s control or authority.

3. Registration Cancellations, Transfers, and Changes. We will cancel, transfer or otherwise make changes to domain name registrations under the following circumstances:

a. our receipt of a decision from the Registry CRC after administrative proceedings conducted under the Conflict Resolution Policy for .Tel or a later version of this Policy adopted by iTAB.

b. if validation procedures defined in Paragraph 4 fail the registration request will not be completed and the potential registrant will be notified.

We may also cancel, transfer or otherwise make changes to a domain name registration in accordance with the terms of your Registration Agreement or other legal requirements.

 

 

4. Minimum Validation Procedures.

 

Electronic Validation: 

 

Accredited Registrars may utilize the functionality of the Public Switched Telephone Network to validate control of a telephone number by a registrant. 

 

ITAB anticipates that Registrars will utilize electronic validation as a primary mechanism for validation of consumer based registrations.  For example, electronic validation could be achieved through one of two mechanisms:

 

(a)   Receiving a call from a registrant placed from the telephone number being registered.  Validation is achieved by verifying the number through caller ID information carried by the PSTN.

 

(b)   Placing a call to a registrant at the telephone number being registered.  Validation is achieved by recording a confirmation from a registrant through a call made to the telephone number being validated. 

 

Research Validation:

 

Accredited Registrars may define a validation process that confirms a registrant's identity through acceptable public sources of information.  ITAB anticipates that this approach will be used extensively to validate the identity of business entities registering blocks of numbers. 

 

For example:  

 

(a)   Registrars may validate the existence of a business entity through a public source of information (Phone book, Dun & Bradstreet, etc.) and then further validate control over the numbers being registered as follows:

 

                                             I.      Validate that the individual registering numbers on behalf of a business entity in fact works for the business entity.  (Phone call to main number located via public source)

 

                                           II.      Random calling of at least three numbers from each block of registered numbers to confirm the numbers are assigned to the registering business entity.

 

(b) Registrars may validate the control of a block of numbers by a business entity by requesting a copy of a telephone bill that confirms control of the registered numbers by the registrant.

 

Pre-Approved Validation:

 

Accredited Registrars may work with existing communications service providers to pre-approve blocks of numbers that the service provider will register on behalf of end-user subscribers. 

 

5. Mandatory Administrative Proceeding.

This Paragraph sets forth the type of validation proceedings for which you are required to submit to a mandatory administrative proceeding.  All proceedings for this Policy will be handled electronically between you, the Registrant and us, the Registrar. 

a. No Evidence. In cases of new registrations you are required to submit to a mandatory administrative proceeding in the event that we, through Paragraph 4 procedures, find no evidence that finds you as being in day-to-day control for the E.164 number used to derive the domain-name registration.   In this case and depending on our Supplemental Rules for Registration Validation you may be requested to:

(i) respond with sufficient proof that you are in day-to-day control of the E.164 number associated with the domain-name registration.

b. Evidence of Invalid Registration.  In cases where an existing registration is being re-validated and found to be invalid you will be required to comply with administrative proceedings defined by the Conflict Resolution Policy of .Tel and its Rules.

 

 

 

 


APPENDIX H: iTAB-NetNumber Registry Zone File Access Agreement


 

AGREEMENT


1. PARTIES

The User named in this Agreement hereby contracts with NetNumber.com, Inc. ("NetNumber") for a non-exclusive, non-transferable, limited right to access an Internet host server or servers designated by NetNumber from time to time, and to transfer a copy of the described Data to the User's Internet host machine specified below, under the terms of this Agreement. Upon execution of this Agreement by NetNumber, NetNumber will return a copy of this Agreement to you for your records with your UserID and Password entered in the spaces set forth below.

2. USER INFORMATION

(a) User: _______________________________________________________

(b) Contact Person: _______________________________________________________

(c) Street Address: _______________________________________________________

(d) City, State or Province: _______________________________________________________

(e) Country and Postal Code: _______________________________________________________

(f) Telephone Number: _______________________________________________________
(including area/country code)

(g) Fax Number: _______________________________________________________
(including area/country code)

(h) E-Mail Address: _______________________________________________________

(i) Specific Internet host machine which will be used to access NetNumber’s server to transfer copies of the Data:

Name: ______________________________________________________

IP Address: ______________________________________________________

(j) Purpose(s) for which the Data will be used: During the term of this Agreement, you may use the data for any legal purpose, not prohibited under Section 4 below. You may incorporate some or all of the Data in your own products or services, and distribute those products or services for a purpose not prohibited under Section 4 below.

3. TERM

This Agreement is effective for a period of three (3) months from the date of execution by NetNumber (the "Initial Term"). Upon conclusion of the Initial Term this Agreement will automatically renew for successive three month renewal terms (each a "Renewal Term") until terminated by either party as set forth in Section 12 of this Agreement or one party provides the other party with a written notice of termination at least seven (7) days prior to the end of the Initial Term or the then current Renewal Term.

NOTICE TO USER: CAREFULLY READ THE FOLLOWING TERMS AND CONDITIONS. YOU MAY USE THE USER ID AND ASSOCIATED PASSWORD PROVIDED IN CONJUNCTION WITH THIS AGREEMENT ONLY TO OBTAIN A COPY OF NETNUMBER’S AGGREGATED .TEL TOP LEVEL DOMAIN ("TLD") ZONE FILES, AND ANY ASSOCIATED ENCRYPTED CHECKSUM FILES (COLLECTIVELY THE "DATA"), VIA THE FILE TRANSFER PROTOCOL ("FTP") PURSUANT TO THESE TERMS.

4. GRANT OF ACCESS

NetNumber grants to you a non-exclusive, non-transferable, limited right to access an Internet host server or servers designated by NetNumber from time to time, and to transfer a copy of the Data to the Internet host machine identified in Section 2 of this Agreement no more than once per 24 hour period using FTP for the purposes described in the next following sentence. You agree that you will use this Data only for lawful purposes but that, under no circumstances will you use this Data to: (1) allow, enable, or otherwise support the transmission of unsolicited, commercial e-mail (spam) to entities other than your own existing customers; or (2) enable high volume, automated, electronic processes that apply to any .tel registrar (or their systems) for large numbers of domain names, except as reasonably necessary to register domain names or modify existing registrations. NetNumber reserves the right, with the approval of the U.S. Department of Commerce iTAB, which shall not unreasonably be withheld, to specify additional specific categories of prohibited uses by giving you reasonable written notice at any time and upon receiving such notice you shall not make such prohibited use of the Data you obtain under this Agreement. You agree that you will only copy the Data you obtain under this Agreement into a machine-readable or printed form as necessary to use it in accordance with this Agreement in support of your use of the Data. You agree that you will comply with all applicable laws and regulations governing the use of the Data. You agree to take all reasonable steps to protect against unauthorized access to, use and disclosure of the Data you obtain under this Agreement. Except as provided in Section 2(j) above, you agree not to distribute the Data you obtained under this Agreement or any copy thereof to any other party without the express prior written consent of NetNumber.

5. FEE

You agree to remit in advance to NetNumber a quarterly fee of $0 (USD) for the right to access the files during either the Initial Term or Renewal Term of this Agreement. NetNumber reserves the right to adjust this fee on thirty days' prior notice to reflect a change in the cost of providing access to the files.

6. PROPRIETARY RIGHTS

You agree that no ownership rights in the Data are transferred to you under this Agreement. You agree that any copies of the Data that you make will contain the same notice that appears on and in the Data obtained under this Agreement.

7. METHOD OF ACCESS

NetNumber reserves the right, with the approval of the U.S. Department of Commerce iTAB, which shall not unreasonably be withheld, to change the method of access to the Data at any time. You also agree that, in the event of significant degradation of system processing or other emergency, NetNumber may, in its sole discretion, temporarily suspend access under this Agreement in order to minimize threats to the operational stability and security of the Internet and the NNI system.

8. NO WARRANTIES

The Data is being provided "as-is." NetNumber disclaims all warranties with respect to the Data, either expressed or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose and non-infringement of third party rights. Some jurisdictions do no allow the exclusion of implied warranties or the exclusion or limitation of incidental or consequential damages, so the above limitations or exclusions may not apply to you.

9. SEVERABILITY

In the event of invalidity of any provision of this Agreement, the parties agree that such invalidity shall not affect the validity of the remaining provisions of this Agreement.

10. NO CONSEQUENTIAL DAMAGES

In no event shall NetNumber be liable to you for any consequential, special, incidental or indirect damages of any kind arising out of the use of the Data or the termination of this Agreement, even if NetNumber has been advised of the possibility of such damages.

11. GOVERNING LAW

This Agreement shall be governed and construed in accordance with the laws of the Commonwealth of Massachusetts. You agree that any legal action or other legal proceeding relating to this Agreement or the enforcement of any provision of this Agreement shall be brought or otherwise commenced in the state or federal courts located in the eastern district of the Commonwealth of Massachusetts. You expressly and irrevocably agree and consent to the personal jurisdiction and venue of the federal and states courts located in the eastern district of the Commonwealth of Virginia (and each appellate court located therein). The United Nations Convention on Contracts for the International Sale of Goods is specifically disclaimed.

12. TERMINATION

You may terminate this Agreement at any time by erasing the Data you obtained under this Agreement from your Internet host machine together with all copies of the Data and providing written notice of your termination to NetNumber, Attention: Registry, Customer Affairs, 650 Suffolk St, Suite 307, Lowell, MA 01854. NetNumber has the right to terminate this Agreement immediately if you fail to comply with any term or condition of this Agreement. You agree upon receiving notice of such termination of this Agreement by NetNumber or expiration of this Agreement to erase the Data you obtained under this Agreement together with all copies of the Data.

13. ENTIRE AGREEMENT

This is the entire agreement between you and NetNumber concerning access and use of the Data, and it supersedes any prior agreements or understandings, whether written or oral, relating to access and use of the Data.

NetNumber.com, Inc.
 
By: _________________________________
(sign)
Name: _______________________________
(print)
Title: _______________________________
 
Date: ________________________________
User: ________________________
By: ___________________________________
(sign)
Name: ________________________________
(print)
Title: _________________________________
Date: __________________________________

ASSIGNED USERID AND PASSWORD

(To be assigned by NetNumber upon execution of this Agreement):

 

USERID: ______________________________ PASSWORD: __________________________________