.MOBI Appendix S

Appendix S

Appendix S

Part 1.

DotMobi Charter

This sTLD Charter (the “Charter”) identifies (a) the purposes for which the .mobi sTLD (the “sTLD”) is delegated, and (b) the community to be served by its delegation.

Subject to Registry Operator’s compliance with this Registry Operator TLD Registry Agreement, including all attachments and appendices thereto (the “Agreement”) and any Temporary Specifications or Policies or Consensus Policies as defined in the Agreement:

1. The sTLD will serve:

1. Mobile consumers, including both individual and business consumers of products, services, devises, content and other items used or accessed while connected over mobile or wireless and organizations that represent such Consumers; and

2. Providers of those products, services, content, and other items to Consumers and other Providers in connection with their use or access while connected over mobile or wireless, and organizations that represent such Providers.

2. The sTLD community consists of those Consumers, Providers, and the Representatives of such Consumers and Providers and other parties (each as further defined in Part 3 of this Appendix S) interested in participating in the creation and development of the sTLD for the purpose of delivering a consistent and therefore predictable, high quality user experience across products, services, and content made available through domain names registered within the sTLD namespace.

3. The sTLD will be managed in accordance with the provisions of the Agreement.

4. Registry Operator will manage the sTLD in accordance with the provisions of this Agreement and will, without limitation:

1. Establish policies and procedures for the sTLD;

2. Establish registration requirements for the sTLD, which may, without limitation, include obligations related to verification of registrant eligibility, willingness to adhere to style guides and other policies and procedures for the sTLD;

3. Permit Consumers, Providers, and Representative Organisations to register names within the sTLD in accordance with the sTLD policies;

4. Operate a web site located at www.dotmobi.mobi to inform prospective registrants about registration policies and procedures;

5. Post on its web site information about its activities, procedures and policies, along with meeting minutes and information about decisions taken so that interested members of the community will have an opportunity to be aware of and respond to Registry Operator's actions and understand how to participate in the sTLD;

6. Permit creation of and participation in one or more self-organising bodies intended to facilitate participation in the development of policy for the sTLD in an open and transparent manner by:

1. Providers that have voluntarily agreed to be bound by the provisions of this Charter and have committed to adhere to all sTLD policies developed and published in accordance with the Agreement; and

2. Consumers and Representative Organisations.

Appendix S

Part 2

Delegated Authority

Subject to Registry Operator’s compliance with this Registry Operator TLD Registry Agreement, including all attachments and appendices thereto (the “Agreement”) and any Temporary Specifications or Policies or Consensus Policies as defined in the Agreement, and provided the scope of the Charter is not exceeded:

Registry Operator shall have delegated authority to develop policy for the sTLD in the following areas:

Product Management

1. Establishment of domain naming conventions to be used in the Registry Operator TLD.

2. Functional and performance specifications for Registry Services, other than those specified in the Appendix 7 of the Agreement.

3. Consistent with any condition under which a Registry Service has been approved, management responsibility for all Registry Services and products, including but not limited to:

1. Variations, modifications, or extensions of Registry Services that do not represent material changes to a previously approved Registry Service.

2. Changes to policies and restrictions associated with or necessitated by approved Registry Services (e.g. changes to style guides) as outlined in Clauses 6, 7 and 8 below.

3. Pricing.

4. Promotions and promotional products, packaging or pricing.

5. Branding, naming, or other marketing activity.

6. Modification of deployment timelines, rollout plans, and implementation details for approved Registry Services.

1. Withdrawal and suspension of all but basic Registry Services (second level registrations); provided, however, that obligations with registrants existing at the time of the withdrawal or suspension are honored.

4. Reservation of names to be offered for registration other than on a first-come, first-served basis and creation of the policies and procedures under which such names may be registered.

5. Identification and reservation of names that are not available for second level registrations and as to which third level names will be offered for registration to end users.

Restrictions on Registration and Policies for Use of Domain Names

6. Reservation of names to be withheld from reservation in the sTLD (in addition to those names reserved by ICANN and set forth in a schedule by ICANN).

7. Policies regarding eligibility to register a domain name in the sTLD, which need not be uniform for all names within the sTLD.

8. Restrictions and policies on how registered names may be used, which need not be uniform for all names within the sTLD, and which may vary, for example, by type, name, or registrant category.

9. Establishment of policies applicable to registrants and/or registrars related to mobile content, formatting, services, end-user addressing, operations, eligibility verification, and registration procedures within the domain, consistent with industry and technology standards and practices.

Operational Policy and Performance Management

10. Except as specifically set forth in the Agreement, matters related to operation of the registry and the sTLD, including, without limitation:

1. Performance of eligibility and name-selection services (ENS), either directly by the Registry Operator or by one or more organizations or individuals to which it delegates the responsibility for performing such services;

2. Operational capability decisions, including location, staffing, organisation structure, capital expenditure, suppliers and, consistent with ICANN approved policies related to selection and management of ICANN-Accredited Registrars, distribution and promotional channels;

3. Other operations-related processes and procedures, including but not be limited to:

1. Internal operations of the Registry Operator;

2. Registry/Registrar relations and channel management, including the terms and conditions contained in the registry/registrar agreement;

3. Terms and conditions required to be included in the end-user registration agreement;

4. Management, support, and interactions with the Membership Advisory Group (MAG) and Policy Advisory Board (PAB);

5. Mechanisms for resolution of disputes between owners of rights in names (such as trademarks) and registrants;

6. Mechanisms for enforcement of registration restrictions and policies; and

7. Provisions for publication of registry and registrar data.

Other

11. Any other policies or practices not inconsistent with the Agreement, ICANN Temporary Specifications and Policies, or Consensus Policy.

Appendix S

Part 3

Description of the sTLD Community

Subject to Registry Operator’s compliance with this Registry Operator TLD Registry Agreement, including all attachments and appendices thereto (the “Agreement”) and any Temporary Specifications or Policies or Consensus Policies as defined in the Agreement, and provided the scope of the Charter is not exceeded:

The Registry Operator TLD community will be defined as all self-identified participants that have a stake in the Charter of the sTLD as described in Part 1 of this Appendix S.

1. We anticipate the following to be the major beneficiaries and stakeholders in the community:

1. Mobile consumers, including both individual and business consumers of products, devises, and Internet based services, content and other items used or accessed while connected over mobile or wireless (“Consumers”) and organizations that represent such Consumers; and

2. Business and other providers (“Providers”) of those products, services, content, applications, and other items to Consumers and other Providers in connection with their use or access while connected over mobile or wireless, and organizations that represent such Providers. Providers include, without limitation:

1. Providers of content, services, devices, features, and applications for mobile consumption;

2. Developers and distributors of mobile content, applications and other services that are designated to be usable while mobile;

3. Mobile operators providing wireless two-way connectivity to Consumers on the move;

4. Mobile equipment and device manufacturers, vendors, and/or distributors, including, without limitation, handset, networks, software and services vendors; and

5. Vendors of IT based technologies, hardware, clients, and servers dedicated to serving the mobility community by delivering products or services for Consumers or other Providers.

3. Representatives of Consumers and Providers and other interested parties (“Representatives”), including, without limitation:

1. Consumer advocacy organizations;

2. Mobile technology, mobile media, mobile services and mobile entertainment stakeholder consortia;

3. Standards and other technical bodies;

4. Trade and other not-for-profit associations; and

5. Entrepreneurs, academia, university consortia, researchers, private sector non-governmental organizations.

2. Registry Operator may modify and/or expand the description of the sTLD Community, consistent with the Agreement, to reflect evolution of the mobile industry and its consumers.

Appendix S

Part 4

Start-up Plan

Subject to Registry Operator’s compliance with this Registry Operator TLD Registry Agreement, including all attachments and appendices thereto (the “Agreement”) and any Temporary Specifications or Policies or Consensus Policies as defined in the Agreement, and provided the scope of the Charter is not exceeded:

Registry Operator will implement the following start-up plan:

BACKGROUND

The start-up plan provides for the introduction of the sTLD in an orderly, transparent, and logical way, for the purpose of ensuring competition, fairness and reliability for ICANN-Accredited Registrars, registrants, and the sTLD Community (as defined in Part 3 of this Appendix S). It is intended to create a stable and effective registration process for the benefit of the Internet community in general, and effected stakeholders in particular.

The plan consists of a multiphase process that will be executed by the Registry Operator.

TIMELINE

Registry Operator plans to introduce and begin to support products and services on the following approximate and estimated timeline. All referenced dates are based on the Effective Date of the Registry Agreement.

Date	Event
In-Process	Registry Operator formation and staffing Agreement and Policy development
Contract Date (“CD”)	ICANN contract execution Registry Operator start-up period begins Third-party party registry services provider contract awarded
CD + 90 Days	Registry Operator publishes revised operations timeline Registry Operator publishes Registrar agreements
CD + 180 Days	Registry Operator publishes initial registrant agreements with applicable policy (styleguides) All Registrar agreements complete OT&E testing begins
CD + 210 days	Registrant agreements finalized Premium Names auction process published
CD + 240 days	OT&E testing ends Premium Names auction schedule published
CD + 270 days	Sunrise period registration begins (90 day window) Premium Names first auction conducted
CD + 360 days	SLD name sales begin through ICANN Accredited Registrars Full operations begin Establish timeline for other products and services

AGREEMENT AND POLICY DEVELOPMENT

Registry Operator has commenced development of the various agreements and policies needed in connection with the operation of the sTLD and will continue during the start-up period with publication and execution as outlined in the Timeline section. The development of any policy will include a review and update process with Registry Operator’s Policy Advisory Board (“PAB”) and Membership Advisory Group (“MAG).

The goal of the agreement and policy development period will be to establish a structure that best serves the sTLD Community.

THIRD PARTY REGISTRY SERVICES PROVIDER

Registry Operator will conclude contract negotiations with its third party provider of outsourced registry operations for the registry. Outsourced registry operations (“ORO”) will include, but are not limited to, interfaces for registrars, WHOIS-database, 24x7 customer service and technical support.

Contracting with the ORO provider is designed to enable a quick start-up of sTLD operations with an ICANN knowledgeable registry back-end service provider that has a track record of proven reliability and stability.

OT&E TESTING

Registry Operator and ORO provider will conduct comprehensive testing of the registry system and registration procedures (including the interfaces with Registrars and the ENS Services provider(s)). This testing will occur in cooperation with a select group of ICANN accredited registrars (the “Testbed Registrars”) with in put from sTLD Community members as appropriate.

The goal of OT&E testing is the confirmation that all entities involved in the registration process are prepared for the commencement of full operations and that escalation, support and reporting processes are in place and ready.

SUNRISE PERIOD

The Sunrise Period will allow intellectual property owners to register trademarks to which they have title as domain names in the sTLD prior to opening registrations through ICANN Accredited Registrars. Registrants must validate their ownership interests in requested domains through a trademark validation process to avoid abusive or ineligible registrations. The Sunrise Period is currently scheduled for a period of 90 days.

During the Sunrise period, Registry Operator will closely monitor the day-to-day operation of the registry and the ORO provider and adjust policies and processes as necessary to ensure stable registry operation and prepare for commencement of full operations.

The goal of the Sunrise period is to ensure, prior to full operations, that only trademark owners can register their trademark as a domain name in the STLD and to resolve disputes among individuals and entities claiming inconsistent or overlapping rights in sTLD names.

FULL OPERATIONS

Full operations will commence with the acceptance of domain name registration requests from all eligible registrants through ICANN Accredited Registrars who have executed a contact with Registry Operator (“Participating Registrars”).

Registrations will generally be accepted on a first-come, first served basis. The UDRP will be used to resolve trademark or name resolution disputes.

Registry Operator may from time to time update registration operations and procedures and include new products and services consistent with the Registry Agreement.

The goal of the full operations period is provide continuous and stable registry operation to the Internet Community.

PRODUCTS AND SERVICES

Registry Operator intends to make the products and services described in Attachment 1 hereto available to registrants.

In accordance with the Agreement, Registry Operator may offer additional or modified Registry Services (as defined in the Agreement).

Registry Operator reserves the right to introduce mini start-up plans for new products and services similar to the above-described initial Start-up Plan. These plans will include appropriate testing periods and service validation for the interface with Registrars and registration process.

REGISTRY RESERVED NAMES

Registry Operator intends to reserve certain names, to be permanently reserved or allocated on an other than first-come, first-served basis.

Appendix S

Part 4

Start-up Plan

Attachment 1:

DotMobi Product List

T = Timeline. Launch, 1st year, 2^nd year, 3^rd year, etc.

F/S = Domain Feature or Domain Service. Feature means optional new function for existing product with no price change at registry level, Service is an add-on to Domain that that includes additional fee.

DR = Domain Requirements. Service implementation requirements (style guides) for services implemented

RGP = Redemption Grace Period. Service to delay availability of a domain for re-assignment after its expiry

Appendix S

Part 5

Selection of Registrars

Subject to Registry Operator’s compliance with this Registry Operator TLD Registry Agreement, including all attachments and appendices thereto (the “Agreement”) and any Temporary Specifications or Policies or Consensus Policies as defined in the Agreement, and provided the scope of the Charter is not exceeded:

Registry Operator will select registrars from among ICANN-Accredited Registrars in a manner that promotes the following characteristics in the group of authorized ICANN-Accredited Registrars:

1. Recognition of the specific aspects of the mobile services community to be supported by the sTLD and a willingness to participate in that spirit;

2. Thorough understanding of the principles and goals underlying sTLD policies, including without limitation the domain name management policy;

3. Demonstrated ability to provide Eligibility and Name-Selection Services (ENS Services) and demonstrated familiarity with the needs of the sTLD Community in the language and region(s) served by the registrar, and established modes for reflecting these needs in the ENS Services processes;

4. Dedicated willingness and ability to propagate and enforce sTLD policies in an observant and diligent manner and in accordance with policies and procedures prescribed by Registry Operator;

5. Broad geographic distribution and language diversity of registrars;

6. Established collaborative contact with one or several associations representing Providers and Representatives (as defined in Part 3 above) in the language and geographical region or sector served by the registrar;

7. Dedicated willingness and ability to act together with the mobile communications community in the processing of registration requests.

8. Established business relationships with substantial numbers (proportionate to the size of the registrar) of Providers and Representatives in the region(s) served by the registrar;

9. Demonstrated willingness and ability to publicize and market the sTLD, to follow all sTLD marketing guidelines, and to develop and use sTLD marketing materials as appropriate, as reflected by a minimum committed marketing budget of an amount proportionate to the size of the registrar;

10. Demonstration that sufficient staff resources are available and able to interface with automated and manual elements of the sTLD registry process and a willingness to implement modifications and revisions reasonably deemed by the Registry Operator to be required based on the characteristics and functions of the sTLD;

11. The existence of proven systems designed to avoid submission of unqualified or incomplete applications that will burden the ENS system or make it impossible for Registry Operator to fulfill its commitments to ICANN;

12. The existence of proven systems to avoid transfer disputes among registrars;

13. Demonstrated willingness to share relevant marketing information with the Registry Operator, including, consistent with applicable law, information about current registrants with whom the registrar has relationships who are eligible for registration.

14. Willingness to provide reduced fee or free services to Providers and Representatives from developing countries who meet minimum criteria reasonably established by Registry Operator for special assistance; and

15. Willingness and ability to post and refresh a minimum deposit against which fees will be drawn.

This Part 5 of this Appendix S specifies the criteria for Registry Operator’s selection of ICANN Accredited Registrars wishing to enter into a Registry-Registrar Agreement to register domain names in the sTLD. Registry Operator will determine the initial number of ICANN-Accredited Registrars to be selected and, in collaboration wit the sTLD Community, will review and revise its selection of registrars and registrar criteria from time to time as appropriate.

Appendix S

Part 6

Public Whois Specification

Subject to Registry Operator’s compliance with this Registry Operator TLD Registry Agreement, including all attachments and appendices thereto (the “Agreement”) and any Temporary Specifications or Policies or Consensus Policies as defined in the Agreement, and provided the scope of the Charter is not exceeded:

Registry Operator will implement the following public WHOIS specification:

PURPOSE

Provision of a WHOIS database for the sTLD will assist registrants and appointed contact persons for associated registrations to protect their rights to use the registered domain names.

SPECIFICATION

Subject to any future policy regarding WHOIS data adopted by ICANN, domain name registrants will be required to provide correct contact information and, as permitted by applicable law, consent to selected information being made public for legitimate purposes.

A participating registrar, at the registrar’s expense, will be required to provide those wishing to query the WHOIS database (other than for marketing purposes or other purposes contrary to sTLD policy) with access to complete and up-to-date data for each registered domain name record (subject to applicable privacy policies) including, but not limited to the following:

• Domain name and the TLD in which the domain name is registered;

• Status of the domain name, e.g., "on hold" or "pending delete";

• Registrant's name and postal address;

• Administrative/technical contacts' name, postal address, e-mail address, telephone number and (if any) facsimile number;

• Original registration date, expiration date and date on which the database was last updated;

• Internet Protocol addresses and corresponding names of primary and secondary

• Name servers for the domain name; and

• Registrar's identification information.

In order to assist complainants under the UDRP to determine whether a pattern of "bad faith" has been demonstrated by a particular registrant, the information set forth above will be available on a publicly accessible database, subject to applicable privacy policies, which will be searchable by domain name, registrant's name, registrant's postal address, contacts' names, Registrars Contact IDs and Internet Protocol address without arbitrary limit. In order to provide an effective WHOIS database, Boolean search capabilities may be offered.

Registrars will be required to participate in the operation of a cross-registry WHOIS database, which will provide searching capabilities and access to all information concerning domain name registrations regardless of which TLD the domain name is registered in or which registrar processed the domain name application.

Registry Operator will require the registrars to adhere to a compliance review policy. As part of that policy, each registrar will be required to designate a contact point to which evidence of false or fraudulent contact data may be reported. Registrars will institute procedures for investigating claims that registrations may contain false information, and for registrations found to contain false information, requiring their speedy and efficient correction, or otherwise cancellation. Interested third parties may invoke these procedures.

Registry Operator will provide RFC954-conformant WHOIS service. This Appendix is subject to change by agreement of Registry Operator and ICANN during the design process as well as during the IETF standards process. However, the following provides the target architecture and initial functionality. In addition, Registry Operator agrees to implement changes to this Appendix specified by ICANN to conform to IETF provreg working group's protocol specification no later than 135 days after the IETF specification is adopted as a Proposed Standard [RFC 2026, section 4.1.1].

RFC954-Conformant WHOIS

The standard WHOIS service is intended as a lookup service for registries, registrars, registrants, as well as for other individuals and businesses that wish to query details of domain names or nameservers stored in the registry. The standard WHOIS service will provide a central location for all authoritative .mobi TLD data. The registry provides a front-end web interface to allow convenient user access to the WHOIS service.

The RFC954-conformant WHOIS service will be engineered to handle moderate transaction load and be integral to the standard suite of Registry Services. The WHOIS service will return a single response per domain name or nameserver query. The RFC954-conformant WHOIS service will conform to the requirements of Appendix 6 and 7.

The RFC954-conformant service provided by the registry will have the following features:

• Standard protocol accessible over port 43.

• Batch-style or near real time updates.

• Additional fields capability.

• WHOIS Service Data Elements

WHOIS Service Data Elements

The RFC954-conformant service will include the following data elements:

• The name of the domain name registered;

• The IP addresses of the primary nameserver and secondary nameserver(s) of the name registered, if applicable, i.e. nameserver has a .mobi name;

• The corresponding names of those nameservers;

• The identity of the Registry Operator registrar;

• The original creation date and term of the registration;

• The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the domain name registrant;

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

• The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the name registered; and

• The Maintainer URL (email or website). The maintainer is a person that has been designated by the Registrar for the registration of the domain (for example a reseller, could also depend on the registrant).

Minimum Data Update Frequency

Registry Operator shall make reasonable efforts to update the data continuously as requests are processed, in a matter of seconds or minutes. The typical update cycle will be 30 seconds but may be different depending on performance considerations. Registry Operator shall ensure that records in the WHOIS server are updated no later than 24 hours after the completion of the registration or modification transaction with the registrar.

Additional Fields Capability

If necessary, Registry Operator may introduce after a 6 to 12 month period of operational stability some additional fields to the list of WHOIS fields. Those fields will be preceded and identified by appropriate tags. Additional fields will not contain any information that could be used to facilitate ENUM applications.

Privacy Capability

Registry Operator may introduce the optional ability to associate privacy labels to a record in the Registry Database. These fields would appear in an "additional information" section of the WHOIS data. The maximum number of custom fields allowed per record is yet to be determined. The privacy label capability allows certain data to be associated with an indication of any special disclosure or handling restrictions. This characteristic may be used e.g. to comply with potential regulatory or other telecom subscription related requirements, which mobile operators need to implement in their services.

Query Control - Object Type Control

The following keywords restrict a search to specific object type:

• Domain: Search only by domain objects. The input string is searched in the Name field.

• Contact: Search only contact objects. The input string is searched in the ID field.

• Nameserver: Search only by nameserver objects. The input string is searched in the nameserver field or the IP address field.

• Registrar: Search only registrar objects. The input string is searched in the Name field.

By default, if no object type control is specified, then the Name field of the Domain object is searched.

WHOIS Output Fields

Domain Record:

A WHOIS query that results in domain information will return the following fields from the Domain object and the associated data from host and contact objects. This set of data is also referred to as the Domain Record.

Domain ID
Domain Name
Domain Status
Registry Operating Registrar (IANA-assigned identifier)
Registrant, Administrative, Technical and Billing Contact Information including:

Contact ID
   Contact Name
    Contact Organization
    Contact Address, City, State/Province, Country
Contact Postal Code
    Contact Phone, Fax, E-mail
Maintainer URL
Names of Nameservers associated with this domain
Created by Registrar (IANA-assigned identifier)
Last Updated by Registrar (IANA-assigned identifier)
Last Transferred Date
Additional fields (Registry Operator specified, will be defined later, if required)
Domain Registration Date
Domain Expiration Date
Domain Last Updated Date

Nameserver Record:

Nameserver ID
Nameserver name
Currently Associated (true/false)
Nameserver status
IP addresses associated (if applicable)
Created by Registrar (IANA-assigned identifier)
Registry Operator Registrar (IANA-assigned identifier)
Last Updated by Registrar (IANA-assigned identifier)
Created Date
Last Updated Date
Last Transferred Date
Additional fields

Note: Any additional fields will be Registry Operator specified, to be defined later if required.

Contact Record:

A WHOIS query that results in contact information will return the following. This set of information is referred to as the Contact Record.

Contact ID
Contact Name
Contact Organization
Contact Address, City, State/Province, Country + 3 street fields
Contact Postal Code
Contact Phone, Fax, E-mail
Contact Registration Date
Contact Last Updated Date
Currently Associated
Contact Status
Additional fields (Registry Operator specified)
Registry Operator Registrar (IANA-assigned identifier)
Created by Registrar (IANA-assigned identifier)
Last Transferred Date

Registrar Record:

A WHOIS query that results in registrar information will return the following. This set of information is referred to as the Registrar Record.

Registrar ID (conforming to the IANA registrar-ids registry)
Registrar Name
Registrar Status
Registrar Address, City, State/Province, Country
Registrar Postal Code
Registrar Phone, Fax, E-mail
Registrar Administrative Contacts
Registrar Technical Contacts
Registrar Billing Contacts

Sample WHOIS Output

This section provides sample output from the WHOIS server for each type of Registry Object: Domain, Contact, Nameserver, and Registrar. The output is structured as key/value pairs, which simplifies machine-readability. In the Input section, the quoted string represents the string actually passed to the server in the request packet.

Domain Record:

Input: WHOIS "domain = billing.mobi"
Output: Domain ID: AAA-0001
Domain Name: BILLING.MOBI
Registry Operator Registrar: REG-01
Domain Status: ACTIVE
Registrant ID: PER-00001
Registrant Name: FRED SMITH
Registrant Organization: BILLING, LTD
Registrant Address: 1 HIGH STREET
Registrant City: GUILDFORD
Registrant State/Province: SURREY
Registrant Country: UK
Registrant Postal Code: GU1
Registrant Phone Number: +44-20-123-4567
Registrant Facsimile Number: +44-20-123-4568
Registrant Email: FSMITH@BILLING.MOBI
Admin ID: PER-00002
Admin Name: FRED SMITH
Admin Organization: BILLING, LTD
Admin Address: 1 HIGH STREET
Admin City: GUILDFORD
Admin State/Province: SURREY
Admin Country: UK
Admin Postal Code: GU1
Admin Phone Number: +44-20-123-4567
Admin Facsimile Number: +44-20-123-4568
Admin Email: FSMITH@BILLING.MOBI
Tech ID: PER-00002
Tech Name: FRED SMITH
Tech Organization: BILLING, LTD
Tech Address: 1 HIGH STREET
Tech City: GUILDFORD
Tech State/Province: SURREY
Tech Country: UK
Tech Postal Code: GU1
Tech Phone Number: +44-20-123-4567
Tech Facsimile Number: +44-20-123-4568
Tech Email: FSMITH@BILLING.MOBI
Billing ID: PER-00002
Billing Name: FRED SMITH
Billing Organization: BILLING, LTD
Billing Address: 1 HIGH STREET
Billing City: GUILDFORD
Billing State/Province: SURREY
Billing Country: UK
Billing Postal Code: GU1
Billing Phone Number: +44-20-123-4567
Billing Facsimile Number: +44-20-123-4568
Billing Email: FSMITH@BILLING.MOBI
Name Server: NIC.MOBI.ORG
Name Server: WWW.ICOM.ORG
Maintainer: SPECIALCARE@RESELLER.COM
Created By: REG-02
Updated By: REG-01
Created On: 2002-01-02
Expires On: 2004-01-02
Updated On: 2002-03-02
Transferred On: 2002-03-02

Nameserver Record:

Input: WHOIS "nameserver nic.billing.mobi" or WHOIS "nameserver 130.242.24.6"

Output:

Nameserver ID: HST-1
Nameserver name: NIC.BILLING.MOBI
Currently Associated (true/false):T
Nameserver status: ACTIVE
IP addresses associated: 130.242.28.6
Registry Operator Registrar: REG-01
Created By: REG-02
Updated By: REG-01
Created On: 2002-01-02
Updated On: 2002-03-02
Transferred On: 2002-03-02
Additional fields (Registry Operator specified, will be defined later, if required)

Contact Record:

Input: WHOIS "contact = PER-00002"
Output: Contact ID: PER-00002
Name: FRED SMITH
Organization: BILLING, LTD
Address: 1 HIGH STREET
City: GUILDFORD
State: SURREY
Country: UK
Postal Code: GU1
Phone Number: +44-20-123-4567
Facsimile Number +44-20-123-4568
E-mail: FSMITH@BILLING.MOBI
Status: Active
Registry Operator Registrar: REG-01
Created By: REG-01
Created On: 2002-01-02
Updated On: 2002-01-02
Transferred On: 0000-00-00

Registrar Record:

Input:

WHOIS "registrar SAMPLE"

Output:

Registrar ID: REG-01
Registrar Name: SAMPLE
Registrar Status: ACTIVE
Registrar Address 1: 123 Some Street
Registrar Address 2:
Registrar City: Acity
Registrar State/Province: RE
Registrar Country: CC
Registrar Postal Code: 12345
Registrar Phone: +11-11-1111-1111
Registrar Fax: +22-22-2222-2222
Registrar E-mail: jdoe@sample.tld
Admin Contact ID: PER-00003
Tech Contact ID: PER-00004
Billing Contact Name: PER-00005

Appendix S

Part 7

Additional Provisions

Interpretation

For purposes of this Agreement, and for the avoidance of doubt, Registry Operator and ICANN agree that a material failure by ICANN to comply with the provisions of Section 3.1(d) in accordance with its specific terms shall entitle Registry Operator to pursue all remedies under the Agreement otherwise available to it.

TLD Differentiation

ICANN and Registry Operator acknowledge that a criterion included in the application process in which the .mobi TLD was selected, and in the previous TLD application expansion round, was that a new TLD be “clearly differentiated from existing TLD’s.” ICANN, when undertaking to effect the delegation of new TLDs, shall take into consideration Internet community input received, including any objections interested third parties may have under policy considerations or applicable law or otherwise, regarding the creation of new TLD strings.

Appendix S

Part 8

Changes

In accordance with Section 2.1(b) of the Agreement, the following reflects material changes from statements contained in Registry Operator’s application for the TLD, or made by Registry Operator in negotiating this Agreement:

The following members of the sponsored community are investors in the DotMobi joint venture:

Handset/ Mobile Infrastructure Manufacturers

Nokia

Ericsson

Samsung

Mobile Communications Operators

Vodafone

T-Mobile

Telefonica

TIM

Hutchison

GSM

IT/ Internet Content and Service Providers

Microsoft

Sun Microsystems

Syniverse Technologies