Unsponsored TLD Agreement: Appendix C, Executive Summary (.info)

Functional Specifications

Executive Summary

This Appendix contains the functional specifications for the Afilias Registry. Guidance for the development of the functional specifications was provided by ICANN's gTLD Registry Best Practices document [GTLD].

The Afilias .info Registry will be operated as a "thick" registry. A thick registry can be defined as one in which all of the information associated with registered entities, including both technical information (information needed to produce zone files) and social information (information needed to implement operational, business or legal practices), is stored within the registry repository.

As a "thick" registry, the Afilias registry database must store objects for domain names, nameservers (hosts), contacts and registrars. Access to this Shared Registry System requires a protocol that supports operations on each of these types of objects. The NSI RRP protocol as defined in [RFC2832] is not capable of handling contact information. As a result it is not suitable as a protocol for the Afilias SRS.

In November 2000, Scott Hollenbeck of Verisign Global Registry Services published the first draft of Extensible Provisioning Protocol [EPP]. EPP is a highly flexible XML based protocol that is designed to allow multiple registrars access to a registry's SRS. The advantage of EPP over NSI RRP is that it can be used with both "thick" and "thin" registries.

At the December 2000 IETF meeting, a Birds-Of-a-Feather (BOF) was held to determine the interest level in establishing a working group that would help define an IETF standardized Registry-Registrar protocol. The BOF led to the creation of the IETF "provreg" (Provisioning Registry Protocol) working group. This working group has been chartered to develop a specification for the requirements and limitations for a protocol that enables a registrar to access multiple registries. The working group will also develop a protocol that satisfies those requirements. The EPP has been proposed as a candidate for this purpose. The working group's target is to have a draft for a standards track protocol by September 2001.

Even though the EPP is still a draft, it has a lot of potential as a general Registry-Registrar Protocol. Afilias has decided to use the EPP as the protocol for access to the Afilias SRS. Afilias expects the activities in the "provreg" working group to have significant impacts on both Registry and Registrar systems. As such, Afilias will have its key technical staff actively participate in the IETF process to help establish the standard. Afilias believes that its early adoption of the EPP protocol will allow it to provide valuable feedback to the Internet community.

Afilias will implement support for the IETF provreg working group's protocol specification no later than 135 days after it is adopted as a Proposed Standard [RFC 2026, section 4.1.1].

Section A of this Appendix contains additional information about EPP. For specific examples of the EPP commands used to manipulate registry objects, please see the EPP Domain Mapping [EPP-D], Contact Mapping [EPP-C] and Host Mapping [EPP-H] drafts.

Section B of this Appendix contains additional information about the Registry database's object stores and structure. The Transactional Services Overview section provides a summary of the commands that are available to registrars to manipulate the objects, along with references to the EPP commands that would be used for these transactions. These include:

• Create domain, nameservers or contacts.
• Get information on domains, nameservers or contacts.
• Check for the existence of domains, nameservers or contacts.
• Modify domains, nameservers or contacts.
• Delete domains, nameservers or contacts.
• Renew domains.
• Transfers domains or contacts.

The Billing Services Overview provides information on how the billing system handles the debit of a registrar's account for billable events.

Section C of this Appendix provides information on the Domain Name Services provided by Afilias. This includes the generation and distribution of zone information to geographically diverse DNS servers. Zone information will be updated at the .info TLD DNS servers every five minutes.

Section D of this Appendix refers to Appendix O, which contains information about the Whois services provided by the Registry.

Section E of this Appendix describes the OT&E certification process. After a registrar becomes accredited by ICANN to register names in the .info TLD, it will be provided with an OT&E welcome package. This package will include the following information:

• Username and password to access the Registrar only area of the Afilias web site.
• OT&E server information and username/password for two accounts to access the Afilias 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 Afilias 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.

This package will provide the Registrar with information on how to develop the client end of the SRS system so that it can interface to the Registry.

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 Registry-Registrar Protocol. 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 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 RTK will remain under development for the term of the Registry and will provide support for additional features as they become available as well as other platform and language support.

The RTK will be licensed under the GNU Lesser General Public License. See also Section 2.3 of the Registry-Registrar Agreement, Appendix F.

During OT&E certification, a Registrar's client application will be required to demonstrate the proper execution of a number of EPP commands. A list of the commands is available in Section E under the section titled OT&E Certification Test Cases.

Upon successful OT&E certification, the Registrar becomes eligible for operation in the live Shared Registry System. A new username/password is assigned and Afilias 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.

Section F of this Appendix explains the customer support Afilias will provide for its Registrars. There are three types of customer support.

1. Front line customer support
2. Administrative/billing/financial support
3. Technical support

The front line support is the first point of contact for Afilias Registrars. This 24/7 operation will be able to answer general registrar questions. When the answer is not available or the registrar is not satisfied with the answer, a service support case is opened and a support ticket is issued. These support tickets are escalated to either the technical support team or the administrative/financial/billing support team depending on the nature of the problem.

The administrative/financial/billing support team will deal with Registrars' business, financial, billing and account management issues. Example support cases include: Registrar account balance inquiries, registrar cash deposits and request to change account balance, legal issues related to the registry-registrar agreement.

Afilias technical support will be available 24/7, with required members of the department on call. Escalation procedures shall be in place to sure that Registrars and Afilias management is notified of service outages in a timely manner.

The technical support group will also be responsible for notifying Registrars of upcoming maintenance and outages with strict requirements regarding advance notice. At a minimum, planned outages and maintenance shall be announced at least 7 days prior to the scheduled date. Further, Afilias technical support shall be required to provide immediate notice of unplanned or unscheduled outages and maintenance.

Section G of this Appendix provides information on Registry Operations.

The Registry consists of two geographically separate physical facilities - the primary and the standby (secondary). In the event that the primary facility fails, the systems will switchover to use the standby facility. All locations are telco-grade, high security buildings. Security guards are on duty 24/7, and enforce a sign-in process where anyone entering the facility must be on the approved list. Visitors must show legal photo ID to be granted access to each facility.

Once inside the facility, visitors must use a card key and palm scanner to gain access to the data center. The Registry systems are locked within cages in the data center, and must be unlocked by security. The entire facility is monitored by video surveillance. Multiple air conditioning units are configured in a fully redundant array. Multiple UPS power units with battery backup provide clean and reliable electrical power. Multiple diesel generators, also in a redundant array, are available for extended power outages.

The Registry system uses a distributed architecture that achieves the goals of scalability, reliability, and extensibility. The systems can continue to function even if an entire server were to suffer catastrophic failure. The registry will use load balancers to assist in scalability as well as to prevent service outages. Due to the nature of load balancing, in many cases it will be possible to also perform upgrades on servers without the customer being impacted.

Connectivity between the Internet and the Primary and Secondary Registry is via multiple redundant connections. In addition, connections between servers on the internal Registry Network are via redundant multi-homed 100 Mbps Ethernet. Connectivity between the primary and secondary registry facility (for replication) is via redundant connections within the network.

The Internet services of the registry includes multiple DNS servers, mail servers, EPP gateways, Whois servers, Report servers, OT&E servers, Web servers for Registrar and Registry Administrative interfaces, and Registry Operations servers. All gateways and servers are hosted in a UNIX environment on multi-processor servers. All servers are protected behind firewall systems.

The Registry will conduct routine backup procedures. This will be performed in such a way as not to adversely impact scheduled operations.

Normal backups will allow retention of:

• Up to 7 versions of database backup (flat file).
• Up to 3 versions of non-database changed files.
• Weekly full on-line backups of database files and provide off-site storage of one weekly full database backup per month.
• Archival of database transaction logs once per day.

Afilias 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 Administration Interface secure web site. This site requires the Registrar to provide its username and password for authorization.

The daily registrar reports will include:

• Daily Transaction Report
• Gaining Transfer Report
• Losing Transfer Report

The weekly registrar reports will include:

• Weekly Domain Report
• Weekly Nameserver Report
• Domains Hosted by Nameserver Weekly Report

Afilias will also provide various informational reports regarding the registry. These are explained in more detail in Appendix T.

Section H of this Appendix explains the details related to the transfer of objects between Registrars in the Registry.

A Registrar who wishes to assume sponsorship of a known object from another client uses the EPP <transfer> command with the value of the "op" attribute set to "request". Once a transfer request has been received by the Registry, the Registry will notify the current sponsoring Registrar of the requested transfer. This notification will be done using an out-of-band communication method, specifically, via e-mail. The current sponsoring Registrar may explicitly approve or reject the transfer request. The Registrar may approve the request using a <transfer> command with the value of the "op" attribute set to "approve". The Registrar may reject the request using a <transfer> command with the value of the "op" attribute set to "reject".

Section I of this Appendix explains the grace periods supported by Afilias.

The References and Attachments sections at the end of this Appendix contain additional information that are useful in the understanding of this document.