Unsponsored TLD Agreement: Appendix C (.pro)
C.5 Whois Service
C.10 Grace Periods
C.11 Character Sets
This section will provide an overview of the registry. Specifically it will describe the registry facilities, the SRS systems and functions, and the nameserver systems and functions. It also provides a description of registry services.
This section describes the Registry Operator's proposed TLD Registry architecture consisting of an SRS data center and multiple nameserver sites to provide a seamless, responsive, and reliable registry service to registrars and Internet users. The .pro registry consists of one SRS and multiple nameserver data center sites geographically dispersed. All of these sites are interconnected with a secure Virtual Private Network (VPN) to provide worldwide coverage and protect against natural and man-made disasters and other contingencies.
SRS Data Center and Nameserver Buildings
Each of the Registry Operator's data center facilities is located in a modern, fire-resistant building that offers inherent structural protection from such natural and man-made disasters as hurricanes, earthquakes, and civil disorder. Facilities are protected by a public fire department, and have their internal fire-detection systems connected directly to the fire department.
Data centers are protected from fire by the sprinkler systems of the buildings that house them. Furthermore, each equipment room is protected by a pre-action fire-suppression system that uses an extinguishing agent.
The environmental factors at the SRS Data Center and nameserver sites are listed in the following table.
In addition to providing physical security by protecting buildings with security guards, closed circuit TV surveillance video cameras, and intrusion detection systems, physical access to our facilities is vigilantly controlled.
The SRS data centers incorporate redundant uninterruptible power supplies; high-capacity heating, ventilation, and air conditioning; fire suppression; physical security; system security; redundant, high availability cluster technology; and redundant network and telecommunications architectures. The sites have been engineered to be resistant to natural and man-made disasters. The functional block diagram of the infrastructure components of the .pro SRS data center is depicted in Exhibit 1. This diagram is shown for illustrative purposes and is a target architecture. Details within the diagram are subject to change as the Registry Operator progresses through development and deployment.
Each SRS data center facility provides the functions listed in the system function directory table below.
One of the five initial nameserver sites is co-located at our SRS Data Center. One of the remaining nameserver sites will be located in Europe, another of the remaining nameservers will be located in Asia. The location of the fourth and fifth nameserver sites will be within the United States. Additional geographically dispersed nameserver sites will be deployed as load and geographic diversity needs dictate and will be served with dual homed Internet and VPN local access telecommunications links to provide resilience and disaster recovery. The nameserver sites are configured to be remotely managed and operated "lights out".
Domain names in the .pro TLD may be registered through ICANN-accredited registrars that have Registry-Registrar Agreements ("RRAs") in effect with the Registry Operator and are qualified (hereafter in this Part, "Approved Registrars"), according to the following criteria:
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 .pro Shared Registration System. They will be reported by the .pro Whois service, as described in Appendix O. In addition, domain names with registrations, including the names and IP addresses (IPv4) of at least two nameservers, will be delegated in the .pro TLD zone or a sub-zone, as described in Section C.4 of this Appendix C.
C2.2 Second-Level Redirect Service
Every .pro domain name must be digitally certified. The Registry Operator will establish and operate a digital Certificate Authority (CA). This CA will serve as the certificate root for all digital certificates issued in conjunction with .pro domain names.
The .pro CA will meet the following specifications:
The Registry Operator will allow commercial certificate authorities (CCAs) to issue digital certificates to Registrars under the .pro CA. These CCAs must meet CA criteria, as described in Section C.2.3 of this Appendix C and Appendix L.
Due to the significant trust conveyed by the .pro digital security services, the Registry Operator will require that CCAs comply with the following baseline certificate issuing practices. This list is not intended to be comprehensive and the Registry Operator may modify the requirements for the provision of digital certificates and other digital security services in the future according to Appendix L and upon prior notice to Authorized Registrars and to ICANN.
Although not part of the initial launch, the Registry Operator will provide a directory of digital certificates available to .pro domain holders. This directory will make use of a standard protocol, such as LDAP, to allow queries based on a domain name. The result of a successful query will be the digital certificate associated with that domain name.
All queries into the directory will be logged, and the Registry Operator may use reasonable mechanisms, such as rate-limiting and IP filtering, to prevent abuse and denial of service attacks against the system.
This service shall be provided not later than one year after the Registry Operator launches its Sunrise Period.
Additionally, the Registry Operator may consider placing digital certificate information within the DNS. Any such data placed in the .pro zone files will be made only in accordance with IETF RFCs on the standards track.
The documents linked below have been submitted to the PROVREG Working Group of the Internet Engineering Task Force (IETF) for consideration for development of an IETF standard regarding a Registry-Registrar Protocol. They describe in detail the Registrar interface to the .pro registry, and include all of the commands and capabilities that exist between registry and registrar. The specifications in these documents are subject to change by agreement of the 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.
The Registry Operator 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].
Extensible Provisioning Protocol, Scott Hollenbeck, http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-06.txt
EPP Contact Mappings, Scott Hollenbeck, http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-04.txt
EPP Domain Mappings, Scott Hollenbeck, http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-04.txt
EPP Host Mappings, Scott Hollenbeck, http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-04.txt
EPP Transport over TCP, Scott Hollenbeck, http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-04.txt
The Registry Operator will generate and propagate DNS zone file updates to the DNS server array incrementally as transactional updates initiated by the SRS resulting from new domain name registrations. Updates will be initiated from the SRS, and queued and propagated to the DNS server array in near real-time consistent with the applicable service level requirements.
At its option, the Registry Operator may generate a unified .pro zone, or may use zone cuts to generate one or more separate zones for the professions-specific second-level domains (PS-SLDs) within the .pro domain. For each zone, the Registry Operator will store only the following resource records in the zone file:
The Registry Operator will implement, on a reasonable schedule, glue-generation and pruning criteria specified by ICANN from time to time.
Zone File Access Program
The Registry Operator will provide a data mart to enable registrars to access the zone file in bulk. Our proposed query program will:
Logging and Data Back-up
All zone files and updates are generated using information from the SRS database. All updates are recorded as database transaction logs.
Zone File-Generation Architecture
Zone file information is stored in the SRS database (along with all other registry data) and replicated to the DNS subsystem within defined service levels. See Appendix D. This data is then replicated out to the nameserver clusters at each of the nameserver data centers.
All DNS services implemented will comply with the relevant IETF standards for the DNS (e.g. RFC1034, RFC1035, RFC1101, RFC2181, RFC 2182). In addition, DNS extensions (security, transactional updates, internationalization, etc.) adopted or proposed by IETF will be assessed and supported consistent with industry acceptance and prudent operational considerations as part of the release requirements definition for the initial registry release and each subsequent one.
The Registry Operator will implement all applicable recommendations and requirements contained in RFC2870 (Root Nameserver Operational Requirements), as they become practicable.
Please see Appendix O.
The registry-registrar model provides a clear, concise and efficient deliberation of customer support responsibilities. Registrars provide support to registrants and registries provide support for registrars. This allows the Registry Operator to focus its support on the highly technical and administratively complex issues that arise between the registry and registrars.
The Registry Operator will provide Authorized Registrars with the following types of technical support:
The Registry Operator will implement a secure Web-based multimedia portal to help support registrar operations. To obtain access to the Registry Operator's Web-based services, a registrar must become an Authorized Registrar, and must have implemented security features, including SSL encryption, log in with user ID and password, and digital certificates for authentication.
The home page of the web portal will include a notice to Authorized Registrars of planned outages for database maintenance or installation of software upgrades. When possible, this notification will be posted 15 days prior to the event in addition to active notification including phone calls and email. The Registry Operator will also record outage notifications in the help desk database to facilitate compliance with the service-level agreement. Finally, seven days and again two days prior to the scheduled event, the Registry Operator will use both an e-mail and a Web-based notification to remind registrars of the outage.
The general Internet community may obtain generic information from the Registry Operator's public Web site, which will describe its TLD service offerings and Authorized Registrars.
Central Help Desk
In addition to implementing the Web site, the Registry Operator will provide telephone support to Authorized Registrars through its central Help Desk. Access to the help desk telephone support is through an automatic call distributor that routes each call to the next available customer support specialist. The Registry Operator will authenticate callers by requesting a pre-established pass phrase that is different for each authorized caller, as well as other information that may serve to authenticate the call. Requests for assistance may also come to the Help Desk via email, either directly or via the secure Web site.
Average Call Back Times
When an Authorized Registrar e-mails or faxes a service request to the Customer Support Center, the Registry Operator will contact the registrar based on the initial incident priority.
Average Resolution Time
Registry Operator's goal is to provide Registrars with a rapid response
and resolution to inquiries, however the following guidelines may be
All incoming tickets will receive prioritization based on the reported problem. Registry Operator reserves the right to adjust the severity of an issue.
The Customer Support Center is committed to resolving all customer issues in a timely and efficient manner. However, in the event that Registry or a Registrar is not satisfied with the support that Registry Operator is providing, there is an escalation process that Registrar may exercise.
If Registrar has not received satisfactory service from the Customer Support Center, escalate concerns through the following resources
(The specific escalation resources are subject to change. The Registry Operator will provide Registrars notice at least 30 days prior to implementing any changes in escalation policy.)
Initially, the Registry Operator will staff its Help Desk with a complement
of customer service specialists. It will add staff as necessary to respond
to incoming requests within the service-level agreement. Customer-service
specialists will obtain assistance from the Registry Operator's technical
staff for any problems that cannot be resolved in one phone call.
The Registry Operator will establish an operational test-and-evaluation facility that will be available for registrars to test their client systems which interact with the SRS. The Registry Operator's technical-support team, which consists of functional experts in the processes and technologies for domain-name registration, will support the registrars' testing.
Once each new registrar is satisfied that its system is compatible with the registry system, it will schedule a formal acceptance test that will be monitored by the Registry Operator. After a registrar has passed the acceptance test, the Registry Operator will issue user id, passwords, and digital certificates to the registrar, and the registrar can begin operations.
Before a registrar is allowed to join the live .pro SRS, it must first pass Operational Test and Evaluation (OT&E) certification. The purpose of OT&E certification is to verify the correct operation and performance of a Registrar's client system.
Preparations for OT&E Certification
The OT&E certification process begins when a registrar becomes accredited by ICANN to register names in the .pro TLD, at which point the registrar enters the .pro registry provisioning process. The registrar fills out a registration form and a .pro welcome package is provided to the registrar. This package includes information that will assist the registrar in implementing its Extensible Provisioning Protocol (EPP) client application for SRS. This package will include the following:
The registrar is responsible for installing the SRS client application that will interface to the registry using the SRS protocol. The registrar will interface the SRS client to the back-office systems via the SRS common APIs. The .pro Registrar Tool Kit is available free of charge to any interested registrar that would like to implement registrar client applications.
The registry-registrar communication channel will be encrypted. A digital certificate signed by the Registry Operator is required to establish the encrypted channel. The username/password and subnet list provides additional security as only a valid combination of digital certificate, username/password and subnet will be allowed to access the live SRS.
During SRS client implementation, the registrar has access to the registry OT&E Testbed environment. In the OT&E Testbed, the registrar may test the operation of its software to verify the correct handling of SRS commands, their responses, and notification messages. Operations performed in the OT&E environment will not be charged and will not have any impacts on the live SRS. Registrars will continue to have access to the OT&E Testbed after certification, so that they may continue to test their back office software systems.
When a registrar has completed the testing of its SRS client and back-office systems and would like to proceed with OT&E certification, it should contact .pro Customer Care 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 the .pro OT&E Technical Support Team to initiate the certification.
The Registrar Tool Kit
The Registrar Toolkit Kit is a software development kit (SDK) that will support the development of a registrar software system for registering Internet domain names in the registry using the SRS Registry-Registrar Protocol and the SRS common APIs. The SDK will consist of software and documentation as described below.
The SDK can be used by the registrar as a basis for connecting to the .pro registry Testbed environment during OT&E, and can also be used to develop a system for interfacing with the live .pro registry once the registrar has been certified.
The software will consist of a working C++ SRS common API and a sample implementation of a client that is used to communicate between the registry and registrar. The SDK 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 SRS Registry-Registrar Protocol. The software component of the SDK will also include XML Schema definition files for all registry SRS objects and SRS Object extentions.
The documentation will also describe the SRS software package hierarchy, the object data model, and a description of the defined objects and methods (including calling parameter lists, and expected response behavior). New versions of the SDK will be made available from time to time to provide support additional features as they become available as well as other platform and language support.
OT&E Certification Test Cases
During OT&E certification, a registrar's client application will be required to demonstrate the proper execution of any of the following operations.
NOTE: The Registry Operator may, in consultation with ICANN, change the OT&E certification requirements as necessary to ensure registrar compliance with changes in the Registry-Registrar Model and Protocol. See Section C.3 of this Appendix C.
Post OT&E Certification
All tests performed during OT&E certification must be completed without errors. The Registry Operator 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 SRS. A new username/password is assigned and
the Registry Operator will configure the live system to recognize the
SSL certificate, username, password, and subnet blocks for the registrar.
The registrar may start operation when it has satisfied the financial
requirements for going live.
The Registry Operator will provide a reporting service allowing registrars to retrieve reports on their customer base. These reports will be posted to a secure site (e.g. FTP) that can be accessed by the individual registrar by entering username and passcode. The format for reports will be easily machine-readable by registrars (i.e. XML, CSV). Naming convention of reports will identify the registrar, the date the report was created and indicate subject of the report. The Registry Operator will archive copies of all reports created.
These reports are:
The Registrar Cumulative Reports include:
Custom reporting is an optional feature that would allow registrars to specify report criteria and have a report available for download upon completion.
The RRP <transfer> command will be used to initiate the transfer of objects between registrars. Registrars may initiate, cancel, approve or reject a transfer request using the <op> command attribute of the <transfer> command.
The <transfer> command can only be used to explicitly transfer domain and contact objects. Nameserver objects are implicitly transferred when a domain is transferred between registrars.
A registrar that wishes to assume sponsorship of a known domain name or contact object from another registrar will initiate the transfer. When the Registry Operator receives the transfer request, the properties of the object will be reviewed. If the object has any of the CLIENT-NO-TRANSFER, LOCK, CLIENT-LOCK, HOLD, PENDING-VERIFICATION, or DELETE-PENDING status properties associated with it, the Registry Operator will immediately respond to the registrar initiating the transfer request indicating that the transfer has failed. If none of these properties are associated with the object, the transfer must then be authorized. This authorization procedure is as follows, consistent with Appendix F, Exhibit D, Part A to this Agreement:
ICANN and the Registry Operator will coordinate with other registry operators to develop the practices and procedures necessary for implementation of an AuthInfo mechanism (a process to obtain authentication information to be stored within database objects, such information to be used to authorize registrar transfers and other appropriate modifications). As currently contemplated, the AuthInfo mechanism would proceed as follows:
Upon development of the AuthInfo mechanism, Registry Operator may implement the mechanism upon written approval by ICANN and ninety days notice to all Authorized Registrars.
Bulk transfers of domain and contact objects will also be executed, according to Appendix F, Exhibit D, Part B to this Agreement.
Add Grace Period
The Add Grace Period is a specified number of calendar days following the initial registration of a domain. The current value of the Add Grace Period for all registrars is five calendar days. If a Delete, Renew, or Transfer operation occurs within the five calendar days, the following rules apply:
Renew Grace Period
The Renew Grace Period is a specified number of calendar days following the renewal of a domain name registration period through an SRS Command Renew. The current value of the Renew Grace Period is five calendar days. If a Delete, Extend, or Transfer occurs within that five calendar days, the following rules apply:
Auto-Renew Grace Period
The Auto-Renew Grace Period is a specified number of calendar days following an auto-renewal. An auto-renewal occurs if a domain name registration is not renewed by the expiration date; in this circumstance, the registration will be automatically renewed by the system the first day after the expiration date. The current value of the Auto-Renew Grace Period is 45 calendar days. If a Delete, Renew, or Transfer occurs within the Auto-Renew Grace Period, the following rules apply:
Transfer Grace Period
The Transfer Grace Period is a specified number of calendar days following the transfer of a domain according to Part A of Exhibit D to the Registry-Registrar Agreement. The current value of the Transfer Grace Period is five calendar days. If a Delete, Extend, or Transfer occurs within that five calendar days, the following rules apply:
Bulk Transfer Grace Period
There is no grace period associated with Bulk Transfer operations according to Part B of Exhibit D to the Registry-Registrar Agreement. Upon completion of the Bulk Transfer, any associated fee is not refundable.
Overlapping Grace Periods
If an operation is performed that falls into more that one grace period, the actions appropriate for each grace period apply (with some exceptions as noted below).
Note: If several billable operations, including transfers, are performed on a domain and the domain is deleted within the grace periods of each of those operations, only those operations that were performed after the latest transfer, including the latest transfer, are credited to the current registrar.
This section defines the different character sets being used by the Registry Operator.
This character set is for use in places where arbitrary strings are to be entered. Examples of places to use this character set is names of persons, addresses, descriptive texts and communication protocols in need of transferring international content.
Also, refer to RFC 2277 (IETF Policy On Character Sets and Languages) for recommendations on when and where to implement UTF-8.
The UTF-8 character set will be interpreted according to the definition found in RFC 2279.
Domain name character set
This character set will be used in places where a domain name is to be specified. It does not govern the specification of internationalised domain names, which are not authorized by the current specification.
The rules for the format and character set of domain names are defined by the following:
Comments concerning the layout, construction and functionality of this site
should be sent to firstname.lastname@example.org.