.XXX Agreement Appendix S

Part 1. DotXXX Charter

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

Subject to Registry Operator's compliance with the Registry Agreement to which this Appendix S is attached, including all attachments and additional appendices thereto (the "Agreement") and any Temporary Specifications or Policies or Consensus Policy as defined in the Agreement:

1. The sTLD will serve individuals, business, entities, and organizations (the "Sponsored Community") that: (i) have voluntarily determined that a system of self-identification would be beneficial, (ii) have voluntarily agreed to comply with all International Foundation for Online Responsibility ("IFFOR") Policies and Best Practices Guidelines, as published from time to time on the IFFOR web site; and (iii) either:

1. Provide online, sexually-oriented Adult Entertainment ("Online Adult Entertainment") intended for consenting adults ("Providers");

2. Represent Providers ("Representatives"); or

3. Provide products or services to Providers and Representatives ("Service Providers").

The term "Adult-Entertainment" is intended to be understood broadly for a global medium, to include those websites that provide Online Adult Entertainment (as defined above), operated by webmasters who have voluntarily determined that a system of self-identification would be beneficial.

2. The sTLD will (i) foster communication between the Sponsored Community and other Internet stakeholders, (ii) protect free expression rights as defined in the United Nations Declaration of Human Rights, and (iii) promote the development and adoption of responsible business practices designed to combat child pornography, facilitate user choice and parental control regarding access to Online Adult Entertainment, and protect the privacy, security, and consumer rights of consenting adult consumers of Online Adult Entertainment goods and services (the "Policy Goals").

3. The sTLD will be managed in accordance with the provisions of the Agreement, including, without limitation, the provisions of Part 8 of this Appendix S.

4. In the event Registry Operator proposes to modify the Charter, Registry Operator shall bear the burden of demonstrating that such modification is consistent with the application for the sTLD submitted by ICM Registry in March 2004, as amended, and any such modification shall be subject to approval by ICANN.

Part 2. Delegated Authority

Subject to Registry Operator's compliance with the Agreement and any Temporary Specifications or Policies or Consensus Policy 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, consistent with its obligations to delegate certain policy development authority to IFFOR as set forth in the Sponsoring Organization Agreement between IFFOR and ICM, and consistent with the provisions of Part 7 of this Appendix S in the following areas:

Product Management

1. Establishment of domain naming conventions to be used in the sTLD.

2. Functional and performance specifications for Registry Services, other than those specified in 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 previously approved Registry Services.

2. Changes to policies and restrictions associated with or necessitated by approved Registry Services 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.

7. 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, as well as developing the terms and conditions under which such registrations shall be offered.

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 information, products, 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, organization 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. Articulation and management of the relationship between Registry Operator and IFFOR, and establishing the terms and conditions under which they interact;

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.

Part 3. Description of the sTLD Community

Subject to Registry Operator's compliance with the Agreement and any Temporary Specifications or Policies or Consensus Policy as defined in the Agreement, and provided the scope of the Charter is not exceeded:

The Sponsored Community will consist of individuals, business, entities, and organizations that: (i) have voluntarily determined that a system of self-identification would be beneficial, (ii) have voluntarily agreed to comply with all IFFOR Policies and Best Practices Guidelines, as published from time to time on the IFFOR web site; and (iii) either:

1. Provide Online Adult Entertainment intended for consenting adults ("Providers");

2. Represent Providers ("Representatives"); or

3. Provide products or services to Providers and Representatives ("Service Providers").

The term "Adult-Entertainment" is intended to be understood broadly for a global medium, to include those websites that convey Online Adult Entertainment, operated by webmasters who have voluntarily determined that a system of self-identification would be beneficial.

Interested stakeholders, including individuals and entities concerned about child safety, free expression, and data privacy ("Other Stakeholders") are not part of the sponsored community, but will play an important, formal role in the IFFOR policy development process.

In the event Registry Operator proposes to modify the definition of the Sponsored Community, Registry Operator shall bear the burden of demonstrating that such modification is consistent with the application for the sTLD submitted by ICM Registry in March 2004, and any such modification shall be subject to approval by ICANN.

Part 4. Start-up Plan

Subject to Registry Operator's compliance with the Agreement and any Temporary Specifications or Policies or Consensus Policy as defined in the Agreement, and provided the scope of the Charter is not exceeded:

Registry Operator will implement the start-up plan shown in 4.1 below. In doing so, Registry Operator will provide for the introduction of the sTLD in an orderly, transparent and logical way, ensuring competition, fairness and reliability for ICANN Accredited Registrars, registrants, the Community and Other Stakeholders.

4.1 Start-up Plan

Products and services

Registry Operator intends to make the products and Registry 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).

Subject to the provisions of the Agreement (including, Section 3.1(d)(iv) of the Agreement), Registry Operator reserves the right to introduce mini start-up plans for new products and Registry 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.

Part 5. Selection of Registrars

Subject to Registry Operator's compliance with the Agreement and any Temporary Specifications or Policies or Consensus Policy as defined in the Agreement, and provided the scope of the Charter is not exceeded:

Registry Operator will select ICANN-accredited registrar(s) that wish to enter into an agreement to register .xxx domain names (the "Registry-Registrar Agreement"). As part of the selection process, Registry Operator will evaluate each registrar on a case-by-case basis, weighing the following characteristics:

Selection of Registrars

1. Understanding of the Community to be supported by the sTLD;

2. Thorough understanding of the principles and intentions underlying the .xxx registration policies;

3. Geographic and language diversity reflecting the diversity of the Community in its region;

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. Demonstrated willingness and ability to publicize and market the sTLD, and to use sTLD marketing materials as appropriate;

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

7. Demonstration that sufficient staff resources are available and ability to interface with automated and manual elements of the sTLD registry process;

8. Demonstrated systems designed to avoid submission of clearly inappropriate applicants that will over-tax the sTLD authentication system; and

9. Demonstrated systems designed to avoid any disputes regarding transfers among registrars.

Registry Operator will select all ICANN-accredited registrars that wish to enter into a Registry-Registrar Agreement that meet the foregoing criteria and, in collaboration with the sTLD Community, will review and revise its selection of registrars and registrar criteria from time to time as appropriate.

Part 6. Public Whois Specification

Subject to Registry Operator's compliance with the Agreement and any Temporary Specifications or Policies or Consensus Policy 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 Create 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 RFC3912-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].

RFC3912-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 .XXX TLD data. The registry provides a front-end web interface to allow convenient user access to the WHOIS service.

The RFC3912-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 RFC3912-conformant WHOIS service will conform to the requirements of Appendix 5.

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

• Standard protocol accessible over port 43 on "whois.nic.xxx".

• Batch-style or near real time updates.

• Additional fields capability.

• WHOIS Service Data Elements

• The format of responses shall follow a semi-free text format outline below, optionally followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.

• Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as a delimiters, followed by the value.

• For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.

• The format of the following data fields: domain status, individual and organizational names, street, city, state/province, postal code, country, telephone and fax numbers, email addresses, date and times should conform to the mappings specified in EPP RFCs 5730-5734 so that the display of this information (or values return in WHOIS responses) can be uniformly processed and understood.

WHOIS Service Data Elements

The RFC3912-conformant service will include the following data fields:

• The name of the domain name registered;

• The IP addresses of the primary nameserver and secondary nameserver(s) of the name registered, if applicable, and the corresponding names of those nameservers;

• The identity of the Sponsoring 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

The display order of the fields in the various Whois objects will be changed at the discretion of the Registry Operator.

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 some additional fields to the list of WHOIS fields. Those fields will be preceded and identified by appropriate tags.

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 legal or regulatory obligations.

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 and the IP address field.

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

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
Sponsoring Registrar (IANA-assigned identifier) and name of Registrar
Registrant, Administrative, Technical Contact Information including:

Contact ID
Contact Name
Contact Organization
Contact Address, City, State/Province, Country
Contact Postal Code
Contact Phone, Fax, E-mail

Names of Nameservers associated with this domain
Additional fields (Registry Operator specified, will be defined later, if required)
Create Date
Domain Expiration Date
Domain Last Updated Date
DNSSEC status of delegation (signedDelegation, unsigned)

Nameserver Record:

Nameserver ID
Nameserver name
Currently Associated (true/false)
Nameserver status
IP address (if applicable)
Sponsoring Registrar (IANA-assigned identifier)
Create Date
Last Updated 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 (if available), E-mail
Create Date
Contact Last Updated Date
Currently Associated
Contact Status
Additional fields (Registry Operator specified)
Sponsoring Registrar (IANA-assigned identifier)

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.xxx"

Output:

Domain ID: AAA-0001
Domain Name: BILLING.XXX
Sponsoring Registrar: XYZ Registrar, Inc.
Sponsoring Registrar IANA ID: 1234
Domain Status: ok
Creation Date: 2002-01-02T14:09:12Z
Updated Date: 2002-03-02T10:18:23Z
Expirartion Date: 2004-01-02T23:59:59Z
Registrant ID: PER-00001
Registrant Name: JOHN DOE
Registrant Organization: BILLING, LTD
Registrant Street: 100 elm street
Registrant Street: Suite 400
Registrant City: ANYTOWN
Registrant State/Province: ANYSTATE
Registrant Postal Code: GU1
Registrant Country: UK
Registrant Phone: +44.201234567
Registrant Phone Ext: 1234
Registrant Fax: +44.201234568
Registrant Fax Ext: 4321
Registrant Email: JDOE@BILLING.XXX
Admin ID: PER-00002
Admin Name: JOHN DOE
Admin Organization: BILLING, LTD
Admin Street: 100 elm street
Admin City: ANYTOWN
Admin State/Province: ANYSTATE
Admin Postal Code: GU1
Admin Country: UK
Admin Phone: +44.201234567
Admin Fax: +44.201234568
Admin Email: JDOE@BILLING.XXX
Tech ID: PER-00002
Tech Name: JOHN DOE
Tech Organization: BILLING, LTD
Tech Street: 100 elm street
Tech City: ANYTOWN
Tech State/Province: ANYSTATE
Tech Postal Code: GU1
Tech Country: UK
Tech Phone: +44.201234567
Tech Fax: +44.201234568
Tech Email: JDOE@BILLING.XXX
NameServer: NIC.XXX.ORG
Name Server: WWW.ICOM.ORG
DNSSEC: signedDelegation
DNSSEC: unsigned
Last update of WHOIS database: 2010-07-29T20:15:00Z

Nameserver Record:

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

Output:

Nameserver ID: HST-1
Nameserver name: NIC.BILLING.XXX
Nameserver status: linked
IP address: 130.242.28.6
Sponsoring Registrar: XYZ Registrar, Inc.
Sponsoring Registrar IANA ID: 1234
Created On: 2002-01-02T09:18:34Z
Updated On: 2002-03-02T19:35:08Z
Last update of WHOIS database: 2010-07-29T20:15:00Z

Additional fields (Registry Operator specified, will be defined later, if required)

Contact Record:

Input: WHOIS "contact PER-00002"

Output:

Contact ID: PER-00002
Name: John Doe
Organization: Registrant, Inc.
Street: 100 ELM STREET
City: ANYTOWN
State: ANYSTATE
Postal Code: GU1
Country: UK
Phone: +44.123456789
Fax: +44.987654321
E-mail: JDOE@BILLING.XXX
Status: linked
Sponsoring Registrar: XYZ Registrar, Inc.
Sponsoring Registrar IANA ID: 1234
Created On: 2006-01-01T22:00:09Z
Updated On: 2006-01-02T15:24:59Z
Last update of WHOIS database: 2010-07-29T20:15:00Z

Registrar Record:

Input : WHOIS "registrar SAMPLE"

Output:

Registrar Name: XYZ Registrar, Inc.
Registrar IANA ID: 1234
Registrar Status: operational
Registrar Street: 123 Some Street
Registrar City: Acity
Registrar State/Province: RE
Registrar Postal Code: 12345
Registrar Country: CC
Registrar Phone: +1.11111111111
Registrar Fax: +22.2222222222
Registrar E-mail: jdoe@sample.tld
Admin Contact ID: PER-00003
Tech Contact ID: PER-00004
Billing Contact ID: PER-00005
Last update of WHOIS database: 2010-07-29T20:15:00Z

Part 7. Additional Provisions

IFFOR Policies

Registry Operator shall comply with and implement all policy proposals of IFFOR, unless Registry Operator demonstrates to ICANN's reasonable satisfaction that such policy proposal: (i) exceeds the scope of IFFOR's authority; (ii) violates the sponsorship agreement between ICM and IFFOR; (iii) would, if implemented, require ICM to violate the Agreement; (iv) creates a threat to the stability or security of the DNS; or (v) cannot be implemented in a commercially reasonable manner because such policy proposal requires material modification of the systems, practices, and procedures used by Registry Operator and/or its registrars in connection with registration of names in the sTLD.

TLD Differentiation

ICANN and Registry Operator acknowledge that one of the criteria included in the application process in which the sTLD was selected, and in the previous TLD application expansion round, was that a new TLD be "clearly differentiated from existing TLDs." 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.

Change in Control Transactions

ICANN shall have the right to review in advance any proposed transaction or series of transactions that will or would be expected to result in a change in Control of Registry Operator (a "Change in Control Transaction"). Registry Operator shall provide notice to ICANN of any Change in Control Transaction no less than thirty (30) calendar days in advance of such Change in Control Transaction. ICANN shall have twenty-five (25) calendar days to review such Change in Control Transaction, during which period Registry Operator shall provide additional data or information reasonably requested by ICANN. At any time within such twenty-five (25) day period, ICANN may notify Registry Operator that it is concerned that the proposed Change in Control Transaction may materially undermine (i) Registry Operator's compliance with its obligations under the Registry Agreement, as amended from time to time, including, without limitation, the Charter and other appendices thereto; or (ii) ICANN's ability to enforce such obligations, or otherwise fulfill its technical oversight and coordination obligations and responsibilities, in which case Registry Operator shall not effect the Change in Control Transaction until such concerns have been resolved. Disputes regarding the reasonableness of ICANN's disapproval shall be resolved in accordance with Article V of the Agreement.

"Control" in this clause shall mean in respect of any person or entity, (a) direct or indirect control of at least fifty percent (50%) of the voting rights eligible in the election of directors, or (b) the power directly or indirectly (i) to elect a majority of its directors or (ii) to cause the direction of its management, whether through share ownership, contract or otherwise, or (c) the direct or indirect ownership or control of all or substantially all of its assets reasonably required for the performance of the Agreement.

Part 8

Registry Operator will:

1. Serve the Sponsored Community by:

1. Entering into the contract between Registry Operator and IFFOR attached hereto as the Sponsoring Organization Agreement, under which (i) IFFOR will develop policy within the Scope of Delegated Authority, as defined therein, in furtherance of the Policy Goals as defined therein, and operate the Grants Program as defined therein, and (ii) Registry Operator will fulfill its funding and other commitments, as specified therein.

2. Publishing, implementing and enforcing the policies attached hereto as ICM Registry Policy: Preventing Abusive Registration. Such policies may be modified by ICM Registry as required to comply with changes in law applicable to the Registry Operator or provisions of the Agreement, including, without limitation, any ICANN Consensus Policy, and/or any ICANN Temporary Specification or Policy. Such policies may be modified by ICM Registry to address new and emerging forms of abusive registration and/or to reflect changing verification and authentication technology following a thirty (30) day public comment period.

3. Consistent with its obligations under the Registry Agreement, publishing, implementing, and enforcing IFFOR Policies developed in accordance with and defined in the Sponsoring Organization Agreement and the IFFOR Bylaws; provided, however, that Registry Operator may not implement changes in the IFFOR Baseline Policies (as defined in the Sponsoring Organization Agreement) that are inconsistent with the Policy Goals (as defined in the Sponsoring Organization Agreement).

4. Publishing, implementing, and enforcing additional Registry policies consistent with this Registry Agreement and ICM's obligations under the Sponsoring Organization Agreement (collectively, with the existing Registry policies, the "sTLD Policies").

5. Permitting members of the Sponsored Community to register names within the sTLD in accordance with the sTLD Policies.

6. Operating a web site located at www.about.xxx to inform prospective registrants about registration policies and procedures.

7. Posting on www.about.xxx or www.iffor.org or www.icmregistry.com relevant information about its activities, procedures and policies, along with meeting minutes and information about decisions taken by IFFOR or ICM so that interested members of the Sponsored Community, registrars and others will have an opportunity to be aware of and respond to Registry Operator's actions and understand how to participate in the sTLD.

Attachment 1

.xxx Product List

T = Timeline. Launch, 1^st 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 includes additional fee.

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