A. Low Cost Services in the Public Interest

The services below are intended to enrich the online efforts of the organizations registering .ORG domain names.

1. ORGWatch

This service, available at a nominal fee, will allow monitoring of a .ORG domain name, or a keyword and its domains associated with the keywords. Any changes to the domain name data for the linked domains will result in a notification being generated.

2. ORGLock

PIR recognizes the registrants' need to safeguard their data. The ORGLock service intends to provide registrants with the ability to prevent modifications, transfers, or deletions of domain names without explicit permission from the registrant. The service's main purposes are to prevent malicious domain hijacking and domain transfer errors. The registrant will be contacted before any changes are made to their accounts for confirmation of the requested change. The registry, or registrar, under certain special conditions to be determined at a later date, may override an ORGLock.

PIR intends to provide, in conjunction with Registrars a program that allows organizations to submit their sites to a wide variety of search engines at a nominal fee. Given the immense popularity of search engines, this product will help users Internet find organizations quickly.

4. ORGCloak

PIR contemplates providing, at a nominal fee, a service in conjunction with registrars, that allows organizations to protect portions of their WHOIS information from the general public. This will protect organizations from spamming, and can be useful to organizations that require a level of anonymity (such as free speech or human rights organizations that operate in politically unfriendly countries). The WHOIS data will remain available, under safeguarding policies and procedures, to qualified entities such as law enforcement bodies and UDRP dispute resolution service providers.

This service will not be offered until proper consultation with the Intellectual Property Community and the .ORG Advisory Council to ensure that the enforcement of intellectual property rights are not compromised.

5. ORGSure

PIR expects to provide, in conjunction with registrars, a certification service for registered noncommercial organizations, so that they can display an "official .ORG site" logo and be listed for free in an official .ORG directory.

The logo will be available to .ORG members in good standing in a variety of formats, including are black-and-white and color versions for online and offline use. The online version also has available hidden text explaining the benefits of membership.

Digital Certificate services (below) might be offered separately from ORGSure or in conjunction with ORGSure. PIR will provide systems that help register the organization's certification, net public identity, and its trust association with its registered business identity, and make them publicly available in a secure fashion.

6. Digital Certificate Services

PIR anticipates offering digital certification services in conjunction with registrars to benefit .ORG registrants. Digital certificates will be available at the 40-, 56-, and 128-bit encryption levels. Registrants will need to provide appropriate credentials to verify their organization and their right to use their .ORG domain name. Certificates give the end users of Web sites a higher level of trust, ensure their privacy, and providing a secure mechanism for any online financial transactions.

PIR expects to offer a distribution mechanism (currently, a Secure-Socket Layer (SSL) web server farm) that will hold a registrant's public certifications and public PGP keys, allowing for secure yet easy access to these crucial pieces to identity.

7. Domain Auto-Renewal

When a domain reaches its expiration date the registry will automatically renew the domain for one additional year. A registrar has the duration of the auto-renewal grace period to delete the domain and receive a refund for the automatic renewal. PIR's policy will restrict the maximum outstanding expiration period to ten years.

Back to top
 
 

These services are the "standard" set of registry services: they are the tools required to effectively manage the ORG TLD.

1. Domain Name Registrations

Domain names in the .ORG TLD may be registered through ICANN-accredited registrars that will have Registry-Registrar Agreements ("RRAs") in effect with PIR and are qualified ("Approved Registrars"), according to the following criteria:

• Each domain name must have from two to 13 nameservers, inclusive.
  
  
• At least one of each type of contact (registrant, administrative, technical, and billing)
  
  
• A minimum one-year term, maximum ten-year term, in one-year increments.
  
  
• Domain names must be of the format specified for the "Domain name character set" as specified in Appendix J.
  
  
• Domain names must meet the naming conventions for domain names specified in Appendix J.
  
  
• Domain name registrations may be renewed prior to their expiration for a period of years up to ten years (in one-year increments), provided that the expiration date of a domain-name registration can never be more than ten years in the future. A renewal that would set the expiration date further than ten years in the future will lead to the expiration date being set to ten years. Any remaining time will be forfeited.
  
  
• All domain-name registrations must be made pursuant to the requirements of the Approved Registrar's RRA with PIR. Among other things, the RRA requires that the registrar and registrant have a registration agreement.
  
  
• The Approved Registrar will collect registration information from the registrant and check to ensure the validity of the domain-name registration. The registrar must submit through the Shared Registration System complete, accurate, and valid registration data, and must update that data when changes occur.

The above criteria are intended to summarize the requirements for registration and do not supersede any other requirements in this Registry Agreement or otherwise.

During their term, domain name registrations will be maintained in the .ORG Shared Registration System. They will be reported by the .ORG WHOIS service, as described in Section V, C27. In addition, domain names with registrations including the names and IP addresses (Ipv4, as well as Ipv6, when this protocol standard has been adopted) of at least two nameservers will be delegated in the .ORG TLD zone or a sub-zone, as described in Section V, C27.

2. Renew Domain

Registrars use the Renew Domain command to extend the expiration year for a domain object. A registrar can only renew domains for which it is the sponsoring registrar. The Renew Domain command must be specified with a registration period, from one to ten years. PIR's policy will restrict the maximum outstanding expiration period to ten years. A domain renewal with an extension period that exceeds this limit will be rejected. Renew Domain uses the EPP Domain Mapping <renew> and the RRP RENEW command.

PIR may charge the maximum fee per year at the time of registration for each domain name registration renewal (the "Renewal Fee") in the registry TLD during the Term of the Registry Agreement as provided in Section V, C26.

The ICANN-Accredited registrar sponsoring the domain name at the time of renewal shall pay the Renewal Fee in full.

3. Transfer Domain

Registrars use the Transfer Request Domain command to change a domain's sponsoring registrar. The transfer request is issued by the gaining registrar, after which the registry will notify the current registrar of the request to transfer the domain. The current registrar may choose to accept or deny the transfer request. If the current registrar takes no action, the registry will automatically accept the transfer after a pre-determined number of days. A domain that is transferred will have its expiration date extended by at least one year. The expiration extension is a billable operation. When a domain is transferred, all Host objects for which this domain is the parent domain will also be transferred to the gaining registrar.

Transfer Domain uses the EPP Domain Mapping <transfer> transform request as well as the RRP TRANSFER command. Following are the different operations that can be performed using the transfer command: Request, Query, Cancel, Approve, Reject

• Following at the steps involved after a transfer has been requested
  
  
  1. Email correspondence regarding Transfer Requests will be sent to the losing registrar so that hey may perform one of the following actions on objects requested for Transfer: Query/Approve/Reject
  2. Automatic approval of Domains/Contacts after grace period expires and no action has been taken by the losing registrar
  3. Email correspondence regarding Transfer Approvals will be sent to the losing registrar

4. Delete Domain

Registrars use the Delete Domain command to remove a domain object from the registry. A registrar can only delete domains for which it is the sponsoring registrar. The deletion of a domain may trigger a billing operation if the deletion is performed within certain grace periods. When a domain is deleted, all Host objects for which this domain is the parent domain will also be deleted. As a result of this requirement, a domain can only be deleted if these nameservers are not associated with any domains in the registry. Delete Domain uses the EPP Domain Mapping <delete> and the RRP DEL command.

Back to top
 
 

These products are additional for-fee services.

1. Bulk WHOIS Service

Bulk WHOIS Access is a subscription-based service that will provide intellectual property owners with the ability to more effectively police their marks while reducing the load on the core WHOIS system. Customers purchasing Bulk WHOIS Access will be contractually bound to any prohibitions that ICANN places on the use of WHOIS data, such as prohibitions against the sending of unsolicited e-mails.

The service will operate by generating a file, once a week that contains the entire list of registered .ORG domain names. The file will be delimited to allow for the easy extraction and manipulation of the data contained within. A Web-based interface will be provided that will allow the subscriber to download this file.

The Web interface will be protected with HTTP over SSL (secure HTTP). Every subscriber will be given their own unique access password, in addition to a weekly generated passphrase that is emailed to them. Subscribers will only be able to access the system via a single known IP address. The Web interface will only allow access when the password, weekly passphrase, and IP address are authenticated and valid. Passwords will be changed regularly. When a party's subscription expires, access to the Web interface will not be allowed until the subscription is renewed.

2. Extensible WHOIS (xWHOIS)

PIR will use its best commercial efforts to develop and implement an Extensible whois (xWHOIS) service for .ORG. This subscription-based service is intended to provide:

• An interface to the WHOIS database that will permit interested third parties to conduct enhanced WHOIS searches using Boolean and character string technologies.
  
  
• Enhanced search functions will include the ability to identify
  
  • registered domain names that incorporate a certain character string, or
    
  • all domain names registered by a certain registrant.
    
    
• Support for a new lookup key, "list_registrars" which will generate a list of all accredited registrars pursuant to a query

For subscribers to the xWHOIS service, a Web-based user interface will be available to define the desired output fields and search criteria. A batch process generates the report and notifies the subscriber that it is available for download. xWHOIS queries will search all records from a copy of the registry database that will be updated once a day.

A. No Cost Services in the Public Interest

The services described below are intended to enrich the online efforts of the organizations registering .ORG domain names.

1. ORGRing

PIR intends to provide a program that allows related organizations to provide navigational links to each other, similar to existing Web rings.

2. DotORG Directory

A free listing service that provides summary information about all organizations that are registered in the .ORG domain. Registrants can choose to opt-in (or opt-out), during or after domain name registration.

3. RRP to EPP Proxy Service

The registry will maintain, up to 30 days after all accredited registrars have converted to EPP (See Sec III, C18), an RRP to EPP proxy, which will be fully compliant with RFC 2832. Registrars that are connecting using RRP will connect to this proxy, and the proxy will be responsible for translating requests to the then current EPP protocol, and sending this request forward into the EPP-based registry. EPP results returning from the server will be handled in the reverse manner; the command will be translated into the appropriate RRP command(s), and sent back to the registrar. As such, all database models, as described below, are based on the thick registry EPP model, with the understanding that the associated RRP commands will be handled through the RRP proxy.

Back to top
 
 

These services can be considered the "standard" set of registry services: they are the tools required to effectively manage the .ORG TLD.

1. Querying functions

The following query types will be available to registrars so they can examine information within the registry.

a. Check Domain

Registrars use the Check Domain command to find out if a domain exists as a valid object in the registry. The registry will return a result of "known" or "unknown" to the Check Domain request. The checking of a domain is a non-billable operation. Check Domain uses the EPP Domain Mapping <check> command.

b. Query Domain

Registrars use the Query Domain command to retrieve the domain information of a domain object in the registry. Only the sponsoring registrar of a domain can retrieve its domain information. The query for domain information is a non-billable operation. Query Domain uses the EPP Domain Mapping <info> command.

c. Query Domain Transfer Status

Registrars use the Query Domain Transfer Status command to find out the status of a domain transfer. The query for domain transfer status information is a non-billable operation. Query Domain Transfer Status uses the EPP Domain Mapping <transfer> query command (while actually initiating a transfer is billable). Please note that this is different from the EPP <transfer> transform command.

d. Check Nameserver

Registrars use the Check Nameserver command to check to see if a nameserver object exists in the registry. The registry will return a result of "known" or "unknown" for the nameserver requested. Check Nameserver uses the EPP Host Mapping <check> command.

e. Query Nameserver

Registrars use the Query Nameserver command to retrieve the host object's information for a nameserver. Only the sponsoring registrar of the nameserver can query for a nameserver's information. Query Nameserver uses the EPP Host Mapping <info> command.

f. Check Contact

Registrars use the Check Contact command to check to see if a contact object exists in the registry. The registry will return a result of "known" or "unknown" for the contact requested. Checking contact existence is a non-billable operation. Check Contact uses the EPP Contact Mapping <check> command.

g. Query Contact

Registrars use the Query Contact command to retrieve the contact object's information for a contact. Query Contact uses the EPP Contact Mapping <info> command.

h. Query Contact Transfer Status

Registrars use the Query Contact Transfer Status command to find out the status of a contact transfer. The query for contact transfer status information is a non-billable operation (while actually initiating a transfer is billable). Query Contact Transfer Status uses the EPP Contact Mapping <transfer> query command.

Back to top
 
 

The following features allow data within the registry to be manipulated by registrars.

a. Update Domain

A registrar uses the Update Domain command to change attributes of a domain for which it is the sponsoring registrar. Attributes that can be changed include: contact information, nameservers and domain status. The EPP specification permits from zero to 13 nameservers, however PIR's policy will only permit domains with two or more nameservers to be resolvable. The EPP specification permits from zero to four contact handles, however PIR's policy will require all four contact handles. Modification of domain attributes is a non-billable operation. Update Domain uses the EPP Domain Mapping <update> command.

b. Add Nameserver

Registrars use the Add Nameserver command to create a new host object in the registry. The creation of a new nameserver is a non-billable operation. Nameservers can only be created by the sponsoring registrar of the parent domain object. A nameserver can be created with up to 13 IP addresses. Add Nameserver uses the EPP Host Mapping <create> command.

c. Modify Nameserver

Registrars use the Modify Nameserver command to change the IP addresses associated with a nameserver or change the name. The modification of a nameserver is a non-billable operation and can only be performed by the sponsoring registrar of the nameserver. Modify Nameserver uses the EPP Host Mapping <update> command.

d. Delete Nameserver

Registrars use the Delete Nameserver command to remove a host object from the registry. A registrar can only delete a nameserver for which it is the sponsoring registrar. The deletion of a nameserver is a non-billable operation. A nameserver can only be deleted if is not associated with any domains in the registry. Delete Nameserver uses the EPP Host Mapping <delete> command.

e. Add Contact

Registrars use the Add Contact command to create a new contact object in the registry. The creation of a new contact is a non-billable operation. Add Contact uses the EPP Contact Mapping <create> command.

f. Modify Contact

Registrars use the Modify Contact command to change the attributes of a contact object. The modification of a contact is a non-billable operation and can only be performed by the sponsoring registrar of the contact. Modify Contact uses the EPP Contact Mapping <update> command.

g. Delete Contact

Registrars use the Delete Contact command to remove a contact object from the registry. A registrar can only delete a contact for which it is the sponsoring registrar. The deletion of a contact is a non-billable operation. A contact can only be deleted if is not associated with any domains in the registry. Delete Contact uses the EPP Contact Mapping <delete> command.

h. Transfer Contact

Registrars use the Transfer Contact command to change a domain's sponsoring registrar. Transfer Contact uses the EPP Contact Mapping <transfer> transform command. The different operations that can be performed using the transfer command are: Request, Query, Cancel, Approve, Reject.

Back to top
 
 

In addition to the services mentioned above, the registry will support the Domain Name Service and WHOIS Internet Protocols with the following services:

1. Domain Name Service (DNS)

The DNS services provided by the Public Interest Registry are:

• Zone generation
  
  
• Zone publication
  
  
• Zone distribution
  
  
• Zone File Access

a. Zone Generation

Zone generation involves the creation of DNS zone information using the registry database as the authoritative source of domain names and their associated hosts (nameservers). Updates of the .ORG TLD DNS servers will be performed in near
real-time.

Updates to the zone information will be generated automatically every 15 minutes. These updates will reflect any modifications, additions to, or deletions from the registry that have been made by the registrars during that time period. Only changes that have been committed to the database will be reflected in the zone information update. Incomplete units of work will be ignored.

The master zone file will include the following resource records:

• A single SOA record.
  
  
• A number of NS and A records, up to a maximum of 13 of each, for the TLD DNS servers for .ORG.
  
  
• One NS record for each unique domain/nameserver combination. Only domain objects with status values of ACTIVE, LOCK, CLIENT-LOCK and PENDING-TRANSFER will be included in the zone file, although this list may be modified if any additional status should be qualified at a later date for inclusion into the zone file.
  
  
• One A record for each required glue record. (PIR will implement, on a reasonable schedule, glue-generation and pruning criteria specified by ICANN from time to time.)

b. Zone Publication

The publication of zone information involves the installation of zone information updates in the master nameserver. Zone publication occurs immediately following zone generation.

c. Zone Distribution

The distribution of zone information involves the installation of zone updates on the DNS nameservers around the world. Zone distribution occurs immediately following zone publication. Zone information updates will be distributed to DNS nameservers using industry-accepted methods, and will be done in a secure manner, using data encryption and secure channels.

d. TLD Zone File Access

PIR will provide bulk access to the TLD zone file to qualified third parties. The service will operate by generating a file, once a day, which contains the entire list of registered domain names. The file will be delimited to allow for easy extraction and manipulation of the data contained within. Subscribers will be able to download this file via an HTTP interface. The registry may, as industry practices improve, provide additional protocols for the method of distribution. In the event a protocol is deprecated, the registry will post the event onto its website no later than 45 days before the protocol will no longer be provided for the purposes of this transfer.

Every subscriber will be given its own unique access account and password. Subscribers will only be able to access the system from a single known IP address. Access to the TLD zone file will only be granted if the account name, password and IP address are authenticated and valid. Subscribers will be urged to maintain the confidentiality of their passwords. When a party's subscription expires, access to zone file will not be allowed until the subscription is renewed.
For more details please refer to Section III, C17.4 (Zone File generation) and C17.5 (Zone file distribution and publication)

2. WHOIS services

PIR will maintain a registry-level centralized WHOIS database that will contain information for every registered .ORG domain. The WHOIS service will be available on the common WHOIS port (Port 43) and through the registry's public website. The WHOIS service will contain data submitted by registrars during the registration process. Once a registrar has been converted to the EPP protocol, any changes made to the data by a registrant will be submitted to the registry by the registrar and will be reflected in the WHOIS, thus providing all interested parties with up-to-date information for every .ORG domain. This WHOIS maintained by PIR will be authoritative, consistent and accurate, as people do not have to query different registrars for WHOIS information, as there is only one central WHOIS system. The data will automatically be migrated from the thin to thick registry model as transforms on the data occur (See Section IV, C22).
WHOIS will be used to look up records in the registry database. Information about domain, host, contact and registrar objects can be searched using this WHOIS service.

For more information please refer to Section III, C17.8. ("Publicly Accessible Lookup/WHOIS Service").

Back to top
 
 

These systems are designed to help the registrar effectively manage their domain names and accounts with the registry.

1. Billing Services

The billing subsystem handles all billing events from the registry that are created as part of normal registry operations. This mechanism also handles requests from the Web based Administration Interface. The billing mechanism interfaces with the PIR financial system by way of a database interface.

Examples for billing events handled by the server are:

• Create domain
  
  
• Transfer domain
  
  
• Renew domain
  
  
• Auto-renew domain
  
  
• Delete domain within create grace period
  
  
• Delete domain within transfer grace period
  
  
• Delete domain within renew grace period
  
  
• Delete domain within auto-renew grace period
  
  
• Transfer domain within auto-renew grace period
  
  
• Deposit

The billing events require an immediate response enabling the registration process to take place. The billing implementation reflects a pre-paid billing model where a balance is debited for each bill event presented.

A negative response is returned by the billing subsystem if there are not sufficient funds available to complete the requested event. An EPP operation that receives a negative response from the billing subsystem will return an "operation failed" response to the registrar that initiated the operation.

Each Billing system event has a dependency on the registry having done the following:

• Ensured that the registrar is valid within the described registrars
  
  
• Ensured that the billing event is fully described with sufficient price information.
  
  
• Ensured that there is a balance for any registrars who require processing for billable events.

The Billing Events must contain the "Transaction ID" as outlined in the EPP specification. This enables registry events to be traced in terms of their billing consequences.

PIR will implement an automatic Threshold Notification process for the registrars to inform them about their low account balance. As soon as the registrars balance falls below a pre determined threshold an out-of-band communication (e-mail) would be sent to the registrars informing them. The registrars are thus always aware of their low account balance and can make arrangements to transfer additional funds. This prevents the registrars from losing business due to lack of funds.

2. Web-based Administration Interface

Each registrar will be provided with a username/password to access a secured web site where it can perform certain functions.

• Query Registrar Account - View your current registrar account information
  
  
• Update Registrar Account - Update your own registrar account information
  
  
• Query Registrar Contact Information - View a list of your registrar contacts
  
  
• Update Registrar Contact Information - Change information for an existing registrar contact;
  
  
• Add Registrar Contact Information - Create a new registrar contact
  
  
• Delete Registrar Contact Information - Delete an existing registrar contact
  
  
• Query Registrar Account Balance - Check the available balance in your registrar account.

In addition, there are some registry-only functions designed for an administrator of the registry. These include:

• Add Registrar Account - Creates a new registrar account
  
  
• Delete Registrar Account - Removes a registrar account
  
  
• Update Registrar Account - Allows the modification of fields that are read-only for registrars
  
  
• Update Registrar Account Status - Change the operational status of a registrar account
  
  
• Update Registrar Account Balance - Credit or debit the current balance for a particular registrar. This function is typically used when a registrar submits payment to the registry.

PIR's management will also be able to use this interface to manage accounts for administration staff and define roles to restrict the functionality available to a particular staff.

3. OT&E Certification Services

Before a registrar is allowed to join the live Shared Registry System it must first pass Operational Test and Evaluation (OT&E) certification. The purpose of OT&E certification is to verify the correct operation of a registrar's client system. Below are overviews of the OT&E phases; please see Appendix L for a detailed description of the OT&E tests themselves.

The OT&E certification process begins when a registrar becomes accredited by ICANN to register names in the .ORG TLD, at which point an OT&E welcome package will be provided to the registrar. This package will include information that will assist the registrar in developing its client application for the Shared Registry System. This package will include the following:

• Username and password to access the registrar only area of the registry web site.
  
  
• OT&E server information and username/password for two accounts to access OT&E environment for registrar client testing.
  
  
• Instructions on where to download the Registrar Tool Kit.
  
  
• Instructions on where to download the documentation for the Registrar Tool Kit.
  
  
• Instructions on where to download the EPP specifications.
  
  
• Instructions on how to proceed with the OT&E certification process.
  
  
• Instructions on how to obtain an SSL certificate from an approved Certificate Authority.
  
  
• Instructions on how to provide registry with the list of subnets that will be used to access the live Shared Registry System.
  
  
• Documentation that will explain the tests to be performed during OT&E verification.

The registrar is responsible for developing the client application that will interface to the registry using the EPP protocol, however PIR will be able, for a fee, to provide client development assistance (See Section V, C25). PIR's Registrar Tool Kit will be available to any interested party that would like to develop registrar client applications. A registrar may opt to develop its application to conform to the EPP specification without the use of the Registrar Tool Kit. This is acceptable as long as the client is able to pass the OT&E certification process.

The registry-registrar communication channel will be encrypted. A SSL certificate from an approved Certificate Authority is required to establish this encrypted channel. The username/password and subnet list provides additional security as only a valid combination of SSL certificate; username/password and subnet will be allowed to access the live Shared Registry System.

During client development, the registrar has access to The Public Interest Registry' OT&E environment. In the OT&E environment, the registrar may test the operation of its software to verify the correct handling of EPP commands and their responses. Operations performed in the OT&E environment will not be charged and will not have any impacts on the live Shared Registry System. Registrars will continue to have access to the OT&E environment after certification, so that they may continue to test their software systems.

When a registrar has completed the testing of its client systems and would like to proceed with OT&E certification, it will contact PIR technical support to schedule a time slot. Time slots will be scheduled on a first-come-first-serve basis. At the scheduled time, the registrar should contact PIR's OT&E Team to initiate the certification.

b. Post OT&E Certification

All tests performed during OT&E certification must be completed without errors. PIR will provide the certification results in a timely manner and provide feedback for those registrars that failed to successfully complete the tests. Registrars may correct their systems and re-schedule for certification. Registrars will not be limited in the number of attempts at OT&E certification.

Upon successful OT&E certification, the registrar becomes eligible for operation in the live Shared Registry System. A new username/password is assigned and PIR will configure the live system to recognize the SSL certificate, username and subnet blocks for the registrar. The registrar may start operation when it has satisfied the financial requirements for going live.

4. The Registrar Tool Kit

The Registrar Tool Kit (RTK) is a software development kit that will support the development of a registrar software system for registering Internet domain names in the registry using the EPP Protocol. The RTK will consist of software and documentation as described below.

The RTK can be used by the registrar as a basis for connecting to the Test bed environment during OT&E, and can also be used to develop a system for interfacing with the live registry once the registrar has been certified.

The software will consist of a working Java API and samples and C samples that can be used to implement the EPP protocol that is used to communicate between the registry and registrar. The samples will illustrate how XML requests (Registration Events) can be assembled and forwarded to the registry for processing. The software will provide the registrar with the basis for a reference implementation that conforms to the Registry-Registrar Protocol. The software component of the RTK will be based on static XML requests.

The documentation will explain to the registrar the details of the protocol specification. It will describe the commands that need to be sent to the registry in order to support domain registration events, as well as the possible responses that may be returned by the registry. The precise nature of the sequencing of commands, as well as the payload that must be assembled and transmitted to the registry, will be defined for each possible registration event.

The documentation will also describe the software (mentioned above) that implements the EPP Registry-Registrar protocol. This will consist of a description of the software package hierarchy, and an explanation of the defined objects and methods (including calling parameter lists, and expected response behavior).
The RTK will remain under development for the term of the Registry Agreement and will provide support for additional features as they become available as well as other platform and language support.

5. Customer and Technical Support Services

PIR shall provide a complete package of support services through the Technical Support Group ("TSG"). These services will be dedicated primarily to operational registrars, although inquiries from potential registrars, or those in evaluation stages shall be supported by a sub-group of the TSG. Overall, the TSG shall attempt to provide round the clock, real time professional support ranging from basic inquiries to high level operations critical technical support. Registrars shall receive equal levels of support regardless of their location of operations. The Public Interest Registry will provide Customer service for general inquiries and billing related issues as well. There will be a sufficient conduit for support escalation to a higher level of billing system administration and/or to operations support. Please refer to Section III, C17.11 for more information.

a. Regularly Scheduled Reports

PIR will generate reports for each registrar on a daily and weekly basis. These reports will contain domains, nameservers and contacts for which the registrar is the sponsoring registrar. The reports are available for download from the registrar web administration Interface secure web site. This site requires the registrar to provide its username and password for authorization.

i. Report Types

Two types of reports will be created for each registrar: Daily Reports and Weekly Reports. These are described below.

• Daily Transaction Report: This reports includes Addition, Modification, and Delete and domain Transfer activity by the registrar. Domain operations produce one row for each associated nameserver. Nameserver operations produce one row for each associated IP address. A transaction ID is included in column 1 to allow unique identification of transactions. Column 2 contains the transaction operation. The content of column 3 and 4 is dependent on the operation according to the following table.
  
  

  Figure 53 Daily Transaction Report Data Based on Operation

  Operation	Column 3	Column 4
  ADD_DOMAIN	Domain Name	Server Name
  MOD_DOMAIN	Domain Name	Server Name
  DEL_DOMAIN	Domain Name	Server Name
  ADD_NAMESERVER	IP Address	Server Name
  MOD_NAMESERVER	IP Address	Server Name
  DEL_NAMESERVER	IP Address	Server Name
  TRANSFER_DOMAIN	Domain Name	Null

  
  Column 5 contains the transaction date (as illustrated in the example below).

  For example,
  1234567:ADD-DOMAIN:EXAMPLE1.ORG:NS1.EXAMPLE1.ORG:2001.07.01.11.12.54
  1234568:ADD-DOMAIN:EXAMPLE1.ORG:NS2.EXAMPLE1.ORG:2001.07.01.11.12.54
  1235789:ADD-DOMAIN:EXAMPLE2.ORG:NS1.EXAMPLE1.ORG:2001.07.01.11.13.30
  1235790:ADD-DOMAIN:EXAMPLE2.ORG:NS2.EXAMPLE1.ORG:2001.07.01.11.13.30
  1245734:ADD-NAMESERVER:111.222.123.211:NS1.EXAMPLE1.ORG:2001.07.01.11.13.50
  1245735:ADD-NAMESERVER:111.222.123.212:NS1.EXAMPLE1.ORG:2001.07.01.11.13.50
  2341413:TRANSFER_DOMAIN:TEST.ORG::2001.07.01.11.14.31
  

• Daily Transfer Reports: This report includes gaining and losing transfer activity. There are two separate reports for transfers:
  • Gaining Transfer Report: indicates domains transferred to the registrar ("gaining registrar").
    
  • Losing Transfer Report: indicates domains transferred away from the registrar ("losing registrar").
    
    

  The Transfer reports will have the following fields: Gaining registrar name, Domain name, Losing registrar name, Date/time of transfer request, Status (one of ACK, NACK or PENDING), Date/time of ACK/NACK. The value of Date/time of ACK/NACK will be NULL if the status is PENDING. For example:

  Registrar A, Inc.:EXAMPLE1.ORG:Registrar B Inc.:2001.07.01.15.13.41:PENDING:
  Registrar A, Inc.:TEST.ORG:Registrar B Inc.:2001.07.01.15.14.00:ACK:2001.07.03.04.23.12
  Registrar A, Inc.:TEST2.ORG:Registrar B Inc.:2001.07.01.15.25.00:NACK:2001.07.03.05.50.39
  

• Weekly Domain Report: Lists all domain names currently sponsored by the registrar. The domain is listed once with each current status and associated name server. For example:

  EXAMPLE1.ORG:ACTIVE:NS1.EXAMPLE1.ORG
  EXAMPLE1.ORG:ACTIVE:NS2.EXAMPLE1.ORG
  EXAMPLE2.ORG:ACTIVE:NS1.EXAMPLE1.ORG
  EXAMPLE2.ORG:ACTIVE:NS2.EXAMPLE1.ORG
  TEST.ORG:HOLD:NS1.TEST.ORG
  TEST.ORG:HOLD:NS2.TEST.ORG
  HAPPY.ORG:ACTIVE:

• Weekly Nameserver Report: Lists all nameservers currently sponsored by the registrar. The nameserver is listed once with each associated IP address. For example:

  NS1.EXAMPLE1.ORG:111.222.123.211
  NS1.EXAMPLE1.ORG:111.222.123.212
  NS1.TEST.ORG:123.14.2.4

• Domains Hosted by Nameserver Weekly Report: Lists all domains hosted on nameservers currently sponsored by the registrar. The nameserver is listed once with each associated domain name.

  NS1.EXAMPLE1.ORG:EXAMPLE1.ORG
  NS1.EXAMPLE1.ORG:EXAMPLE2.ORG
  NS2.EXAMPLE1.ORG:EXAMPLE1.ORG
  NS2.EXAMPLE1.ORG:EXAMPLE2.ORG
  NS1.TEST.ORG:TEST.ORG
  NS2.TEST.ORG:TEST.ORG
  

Daily reports will be generated daily every four hours. Previous reports for that day shall be overwritten each time a new daily report is generated.

Weekly reports will be generated on Sunday at 00:00 UTC and shall contain activity for the previous week.

c. Storage

Daily registrar reports are maintained for each registrar for seven days. Daily reports older than seven days will be removed.

Weekly registrar reports are maintained for each registrar for four weeks. Weekly reports older than four weeks will be removed.

d. Distribution

Registrar reports shall be available for download via a Reports section in the registrar web administrative interface. Each registrar will have secure, password-protected access, to the registrar administrative interface. A given registrar will only have access to its own reports.

7. Registrar-Registry Synchronization

There are two methods available for the registrar to synchronize data with the authoritative-source registry.

a. Bulk Synchronization

A registrar will contact registry support and request a data file containing all domains registered by that registrar, within a certain time interval. The data file will be generated by registry support and made available for download using a secure web server. The data file will be a comma delimited file that contains all domains the registrar has registered in the time period requested - including all associated host (nameserver) and contact information.

b. Single object synchronization via EPP

The registrar can, at any time, use the EPP <info> command to obtain definitive data from the registry, for a known object: including domains, hosts (nameservers) and contacts. There is no need to contact registry support for this synchronization method.

8. Bulk Transfers

ICANN may request PIR to perform a bulk transfer of all registered objects from one registrar to another registrar. The bulk transfer will not be performed with the use of EPP commands. Instead it will be performed as a bulk database operation of the necessary fields for all objects currently sponsored by the losing registrar. A complete log will be kept of this transaction for auditing purposes.

Back to top
 
 

These systems are designed to help the registrant effectively manage their domain names with both their registrar and the registry.

1. AuthInfo Code Support

a. Inter-domain Name Uniqueness

The registry, if commercially feasible, will verify that a duplicate AuthInfo code is not used within the domains of each registrar. This will ensure that each domain name has a unique AuthInfo code, which may curtail possible domain theft by attempted use of a duplicate code.

b. Registrant AuthInfo Code Assistance

If, for any reason, a registrant has difficulty obtaining the AuthInfo code for their domain, PIR will provide a mechanism for them to get their code. This facility will give the sponsoring registrar an additional access method for the AuthInfo code, and provide the registrant with the ability to easily obtain it from the registrar.

1. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF RFC 2119.

Capitalized terms used herein and not otherwise defined shall have the meaning ascribed to them in the Registry Agreement.

2.1 "Core Internet Service Failure" refers to an extraordinary and identifiable event beyond the control of Public Interest Registry affecting the Internet services to be measured pursuant to Section 2 of Nameserver Availability and Performance Measurements in Appendix N. Such events include but are not limited to congestion collapse, partitioning, power grid failures, and routing failures.

2.2 "Current Pricing Level" refers to prices charged for Registry Services as provided in Section V, C26

2.3 "C1" means Category 1, a mission critical service.

2.4 "C2" means Category 2, a mission important service.

2.5 "C3" means Category 3, a mission beneficial service.

2.6 "Degraded Performance" means a service not meeting the performance requirement set forth in this document. Round-trip time is calculated from within the server complex. This is used as the basis of this metric for all services except nameservice; for nameservice packet loss and Round-trip time are used as metrics.

2.7 "Monthly Timeframe" shall mean each single calendar month beginning and ending at Universal Time Convention (UTC).

2.8 "Monthly Unplanned Outage Time" shall be the sum of minutes of all Unplanned Outage Time during the Monthly Timeframe.

2.9 "Not Responding" - A service will be deemed as "Not Responding" in the event that the Registry Component Ping (rcPing), as described in Appendix N attached hereto, responds with a negative or degraded service response.

2.10 "Planned Outage" means the periodic pre-announced occurrences when the System will be taken out of service for maintenance or care. Planned Outages will be scheduled during a routine pre-determined time frame (the "Planned Outage Period"). This Planned Outage Period may be changed from time to time by PIR, in its sole discretion, upon prior notice to each registrar. Planned Outages will not exceed four (4) hours/per calendar week beginning at 0000 UTC Monday nor total more than eight (8) hours/per calendar month. Notwithstanding the foregoing, in each calendar year PIR may incur one (1) additional Planned Outage of up to eight (8) hrs in duration during the Planned Outage Period for major systems or software upgrades ("Extended Planned Outages"). This Extended Planned Outage represents the total allowed Planned Outages for the month.

2.11 "Round-trip" means the amount of measured time that it takes for a reference query to make a complete trip from the sampling agent, to the system or process being tested and back again. This is usually measured in milliseconds.

2.12 "Service Availability" means when the System is operational and predictably responding in a commercially reasonable manner. By definition, this does not include Planned Outages or Extended Planned Outages.

2.13 "Service Unavailability" means when, as a result of a failure of systems within PIR's control.

2.13.1 With respect to services other than WHOIS Service and nameservice, Registrar is unable to establish a session with the System gateway which shall be defined as:

2.13.1.1 successfully complete a TCP session start,

2.13.1.2 successfully complete the SSL authentication handshake, and

2.13.1.3 successfully complete the Extensible Provisioning Protocol ("EPP") or (RRP) <login> command.

2.13.2 With respect to all services, system monitoring tools register three (3) consecutive monitoring failures on any of the components listed in Section V, C25 and C27.

2.14 "SLA" means the service level agreement between PIR and registrar attached as Appendix M.

2.15 "SLA Credit" means those credits available to the registrar pursuant to the SLA and who have successfully completed the procedure defined in Section 2.5 of Appendix M.

2.16 "System" shall mean the list of components listed in Section III, System Services.

2.17 "Transaction" shall mean chargeable Registry Services, which includes initial and renewal registrations.

2.18 "Unplanned Outage Time" shall mean all of the following:

2.18.1 With respect to services other than WHOIS Service and nameserver resolution, the amount of time recorded between a trouble ticket first being opened by PIR in response to a registrar's claim of Service Unavailability for that registrar through the time when the registrar and PIR agree the Service Unavailability has been resolved with a final fix or a temporary work around, and the trouble ticket has been closed. This will be considered Service Unavailability only for those individual registrars impacted by the outage;

2.18.2 With respect to services other than WHOIS Service and nameserver resolution, the amount of time recorded between a trouble ticket first being opened by the registry in the event of Service Unavailability that affects all registrars through the time when the registry resolves the problem with a final fix or a temporary work around, and the trouble ticket has been closed;

2.18.3 With respect to all services, the amount of time that Planned Outage time exceeds the limits established in Section 2.10 above; or

2.18.4 With respect to all services, the amount of time that Planned Outage time occurs outside the window of time established in Section 2.10 above.

2.19 "WHOIS Service" means PIR's WHOIS Services described in Section III, C17.8.

The following table lists, by category (C1, C2, or C3), the Registry System services for which availability and performance requirements are established. Services shall meet availability requirements according to their category, as listed in the "Cat." column below. In addition, various services must meet the performance requirements listed in the "Perf." column below. These availability and performance requirements are the subject of the Service Level Agreement (SLA) between PIR and registrars (SLA) or the requirements of the Registry Agreement between PIR and ICANN, as noted by the × marks below.

Except for nameserver performance measurements (P4), PIR will monitor the System in accordance with the following principles.

a. System/Component Monitoring

The services defined in this Appendix will be sampled and tested as to availability pursuant to the schedule attached hereto as Appendix N.

b. Performance Monitoring

The services defined in this Appendix will be sampled and tested as to their performance pursuant to the schedule attached hereto as Appendix N. Services Not Responding within the Round-trip response times listed in Section IV, Service Levels will be deemed suffering from Degraded Performance for the purposes of this Appendix.

Nameserver performance measurements will be conducted by ICANN according to Appendix N.

6. Responsibilities of the Parties

6.1 Except in the case of nameserver performance measurements, PIR will perform monitoring from internally located systems as a means to verify that the availability and performance measurements of this document are being met.

6.2 PIR will update the WHOIS Service on a near real-time basis. During normal operation, all registration and information updates sent from a registrar to the registry are stored in the primary database (database A). The information in database A is replicated to a backup database (database B) at regular intervals, normally within five (5) minutes. The WHOIS Service uses database B as its source of information. The time lag in the WHOIS information update is determined by the database replication interval. PIR will notify registrars in advance when changes to the WHOIS Service update schedule occur.

6.3 PIR will initiate the addition, deletion or other modification of DNS zone information to the master DNS server within 15 minutes of a Transaction upon implementation of its own TLD name servers. PIR will notify registrar in advance when changes to the schedule occur. PIR will notify registrars regarding any scheduled maintenance and unavailability of the TLD root-servers.

6.4 PIR will use commercially reasonable efforts to restore the critical systems of the System within 24 hours in the event of a force majeure and restore full system functionality within 48 hours. Outages due to a force majeure will not be considered Service Unavailability.

6.5 Beginning no later than 120 days post Commencement-of-Service Date, PIR will publish preliminary weekly system performance and availability reports. PIR will use best efforts to finalize these reports no later than 30 days after the preliminary reports are provided.

6.6 PIR will provide Service Availability percentages during each Monthly Timeframe as listed in Section IV, Service Levels.

7. Miscellaneous

7.1 This section is not intended to replace any term or condition in the Registry Agreement.

7.2 Dispute Resolution will be handled pursuant to the terms of Subsection 5.9 of the Registry Agreement.