Logo
ICANN
ICANN

Generic Top-Level Domain (gTLD) Registry Agreements

gTLD Registry Agreements establish the rights, duties, liabilities, and obligations ICANN requires of registry operators to run gTLDs.

Unsponsored TLD Agreement: Appendix C (.pro)

ICANN | Unsponsored TLD Agreement: Appendix C (.pro)
  ICANN Logo

Unsponsored TLD Agreement: Appendix C (.pro)
16 July 2009

Functional Specifications

Contents

C.1 Registry Overview

C.2 Service Descriptions

C.3 Registry-Registrar Model and Protocol

C.4 Zone File Generation, Distribution, and Publication

C.5 Whois Service

C.6 Customer Support Services and Capabilities

C.7 Operational Test and Evaluation

C.8 Registrar Reports

C.9 Transfers

C.10 Grace Periods

C.11 Character Sets

C.12 One, Two and Three Character Phased Allocation Program

C.1 Registry Overview

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.

C.1.1 Registry Facilities Site Description

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.

SRS DATA CENTER ENVIRONMENTAL FACTORS
Heating, ventilation, and air conditioning Redundant HVAC units control temperature and humidity, able to maintain the required environment under failure of any one unit.
Power supply Modular UPS with battery backup and diesel generator.

Building Security

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.

C.1.2 Shared Registration System (SRS) Data Center Functional Description

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.

Exhibit 1

Each SRS data center facility provides the functions listed in the system function directory table below.

INFRASTRUCTURE FUNCTION DIRECTORY
System Function Functional Description
Database Servers The database maintains registry data in a multi-threaded, multi-session database that is the authoritative store for all registry data. The SRS interacts with this database directory, while other services may use an intermediate database for storage of application-specific data sets.
Storage Primary and Secondary storage are accessed through fibre channel for use by the databases and select applications.
Network Attached Storage This storage is utilized by applications servers. This stores application binaries and application data, as well as zone files for the backup BIND servers.
Tape Backup System Provides backup and restore of each of the various cluster servers and database servers files and provides a shared robotic tape library facility for central backup and recovery.
Fibre Channel Switches Provide fibre channel connectivity to devices participating in the Storage Area Network.
Network Switches Provide Ethernet connectivity to devices participating in the Local Area Network.
Nameservers The nameserver handles resolution of TLD domain names to their associated nameserver names and to the IP addresses of those nameservers.
Application Servers Clusters of Application Servers provide additional services such as SRS, Whois, and Web. These servers are optimized to process extremely high transaction volumes. Requests are routed to different servers in the cluster by means of a load balancer.

C.1.3 Nameserver Sites Functional Description

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

C.2 Service Descriptions

C.2.1. Domain Name Registrations

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:

  • Domain names must be of the format for tldns (for three-level domain names) or sldns (for two-level domain names) specified for the "Domain name character set" in Section C.11 (Character Sets) of this Appendix C.
  • Domain names must meet the naming conventions for domain names specified in Appendix L.
  • Domain names in the .pro TLD are registered to certified professionals as second-level registrations, <companyname.pro>, or third level registrations, <companyname.law.pro>, where “law” is a profession- specific second-level name for providers of legal and law-related services. See Appendix L for other profession-specific second-level options.
  • In general, domain name registrations in the .pro TLD will be made on a first-come, first-served basis. (Exceptions include Defensive Registrations.)
  • Registrants must meet the Eligibility Requirements stated in Appendix L.
  • The initial registration term may be from one to ten years, in one-year increments. (Exceptions include conversions from Basic Defensive registrations within the first thirty days of the registry live period, for which the minimum initial term is four years.)
  • 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 in the future. Any remaining time will be forfeited.
  • All domain-name registrations must be made pursuant to the requirements of the Approved Registrar's RRA with the Registry Operator. Among other things, the RRA requires that the registrar and registrant have signed a registration agreement.
  • The Approved Registrar will collect registration information from the registrant and do quality checking of the data 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 Approved Registrar will also be responsible for the verification of the registrant's right to use the domain name and issue a digital certificate in conjunction with the domain name, pursuant to Registry Operator policies as described in Appendices J and L.

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

Registration of second-level domain names under the .pro TLD are available in two different forms described as follows. Regardless of which option the registrant is choosing the requirements stated above in C2.1 must be followed.

If the registrant provides multiple professional services and hence meets two or more of the eligibility requirements as stated in Appendix L, then registration can be performed directly under .pro, in the form <companyname.pro>.

If the registrant provides professional service under one of the profession- specific second-level options (see Appendix L for requirements) registration can also be performed on the second-level. In this case the registration will require a redirect to the third-level professional designator that corresponds to the registrant’s professional area.

As an example, a law firm could register <companyname.pro> in addition to <companyname.law.pro>. For both URL and email services, a redirect would be provided and required so that <companyname.pro> would be redirected to <companyname.law.pro>.









C.2.3 Defensive Registrations

  • Defensive Registrations must be of the format for tldns (for three-level domain names) or sldns (for two-level domain names, to the extent permitted) specified for the "Domain name character set" in Section C.11 (Character Sets) of this Appendix C.
  • Defensive Registrations must meet the naming conventions specified in Appendix L.
  • In general, Defensive Registrations in the .pro TLD will be made on a first-come, first-served basis.
  • Registrants must meet the Eligibility Requirements stated in Appendix L.
  • The initial registration term of Defensive Registrations is four years. They may be renewed in four year terms, provided that the expiration date of a Defensive 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 in the future. Any remaining time will be forfeited.
  • All Defensive Registrations must be made pursuant to the requirements of the Approved Registrar's RRA with the Registry Operator. Among other things, the RRA requires that the registrar and registrant have signed a registration agreement.
  • The Approved Registrar will collect registration information from the registrant and do quality checking of the data to ensure the validity of the Defensive Registration. The registrar must submit through the Shared Registration System complete, accurate, and valid registration data, and must update that data when changes occur.
  • Please refer to Appendices G, L and M for more information related to Defensive Registrations.

  • The above criteria in Section 2.1 and 2.2 are intended to summarize the requirements for registration and do not supersede any other requirements in this Registry Agreement. During their term, domain name and Defensive 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. A Defensive Registration will not resolve in the DNS. Domain names that would match a Defensive Registration may be registered following the judgement of dispute resolution proceedings, if the Defensive Registration has expired or if a Defensive Registrant provides consent. After such point, the domain name would resolve in the DNS.

    C.2.4 Digital Certificate Authority

    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:

    • A clearly defined Certificate Practice Statement (CPS) will govern the CA's operations and policies. This document will be made publicly available.
    • The CA root key, and all operations relating to certificate signing, will be protected by an extensive system of physical, logical and procedural safeguards.
    • The CA root key will be generated on hardware that is at least FIPS 140-1 level 2 compliant.
    • The CA root key will be at least 1024 bits in length.
    • A list of revoked certificates will be maintained and made available to the public.

    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.

    C.2.5 Digital Certificate Protocol

    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.

    2.5.1. CCAs must verify the identity of the individual or organization requesting the certificate. Certain trusted third parties may perform this function, provided that all parties comply with the verification guidelines issued by the Registry Operator and certify the same to the Registry Operator.

    2.5.2. For organizations, CCAs must verify that the request for the certificate is appropriately authorized. Certain trusted third parties may perform this function, provided that all parties comply with the verification guidelines by the Registry Operator and certify the same to the Registry Operator.

    2.5.3. CCAs will verify that the individual or organization requesting the certificate meets the registration requirements defined in Appendix L. Certain trusted third parties may perform this function, provided that all parties comply with the verification guidelines issued by the Registry Operator and certify the same to the Registry Operator.

    2.5.4. CCA initial key size will be at least 1024 bits.

    2.5.5. A trusted hardware device (FIPS 140-1 Level 3 certifiable) must be used to create, protect, and destroy the CCAs' private keys.

    2.5.6. CCAs must have a clear "certificate policy", as defined by X.509 Amendment 1 to ISO/IEC 9594-8:1995.

    2.5.7. CCAs must issue certificates complying with the X.509 standard.

    2.5.8. CCAs must be capable of issuing both X.509 v1 and X.509 v3 type certificates.

    2.5.9 CCAs must provide appropriate warranties and indemnities in respect of certificate issuing/verification and confirming credentials.

    2.5.10. Upon notification from (a) the Registry Operator that the .pro domain name associated with a certificate is subject to a transfer request or has been transferred to another registrant or deleted, or (b) the Registry Operator or a trusted third party used to validate some of the requirements for certificate issuance that those requirements are no longer met, the CCA must revoke the certificate. The CCA must maintain a publicly available revocation list, and must transmit its revocation list to the Registry Operator at least daily, or such CCA may operate a real-time server that maintains a continuously updated list of revoked certificates.

    C.2.6 Digital Certificate Directory

    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.

    C.3 Registry-Registrar Model and Protocol

    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

    C.4 Zone File Generation, Distribution, and Publication

    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:

    • A single SOA record
    • A number of NS and A records, up to a maximum of 13 of each, for the DNS servers for .pro TLD or for the PS-SLD, as the case may be
    • Domain name and delegated nameservers (NS Records)
    • Nameserver host names and their associated IP addresses (A Records)

    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:

    • Reduce the load placed on the nameservers by data mining programs. (For example, some ISPs use data mining to accelerate domain name availability checking.)
    • Bind subscribers to limiting conditions as to how they can use the data, according to the terms set forth in Appendix N.
    • Provide the entire database in a BIND format that will facilitate such services as suggesting alternate names, accelerating DNS queries, and compiling industry statistics.

    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.

    Standards Compliance

    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.

    C.5 Whois Service

    Please see Appendix O.

    C.6 Customer Support Services and Capabilities

    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.

    C.6.1 Technical Help Systems

    The Registry Operator will provide Authorized Registrars with the following types of technical support:

    • Web-based self-help services, including:
      • Knowledge bases
      • Frequently asked questions
      • White papers
      • Downloads of SRS client software
      • Support for email messaging
    • Telephone support from our central Help Desk
    • Fee-based consulting services

    Web Portal

    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.

    Priority Call Back Time
    1 20 minutes
    2 1-business hour
    3 1-business day
    4 2-business days

    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 useful:

    Priority Average Resolution Time
    1 2-business hours
    2 1-business day
    3 3-business days
    4 5-business days

    Ticket Prioritization

    All incoming tickets will receive prioritization based on the reported problem. Registry Operator reserves the right to adjust the severity of an issue.

    Priority 1 A priority 1 ticket is the highest priority within the Support Center system. The Center will make every reasonable effort to ensure that the customer is operational as soon as possible. Registry Operator will be in continuous contact with the customer until the problem is resolved. Typical Priority 1 issues include:

    • System inoperative

    Priority 2 Typically a Priority 2 ticket is for a problem that prevents the Registrar from completing non-registration business but does not cause Registrar's use of the registry to become completely inoperable. Registry Operator will make every reasonable effort to resolve the reported problem as soon as possible. Typical Priority 2 issues include:

    • Domain-name resolution impacted
    • Registration activities impaired, but not rendered inoperable
    • Registrar access to registry services is limited, but not made unavailable
    • Serious installation or upgrade issues (installation and upgrade issues may be considered Priority 1 issues if they seriously impact progress towards completion and/or production dates)

    Priority 3 A Priority 3 ticket is for a problem that causes a feature or system failure that can be avoided by the customer applying alternative methods. Typical Priority 3 issues include the following:

    • Reports will not run
    • Performance problems
    • Functionality issues
    • Receiving error messages in the reports
    • Receiving console error messages
    • Exporting/importing data files failing
    • Upgrade or installation planning

    Priority 4 A Priority 4 ticket is for a minor problem having only a minimal impact on the customer's business. Typical Priority 4 issues include:

    • General product questions
    • Product shipment questions

    Escalation

    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

    1. Account Manager
    2. Customer Support Center Director
    3. Chief Operating Officer

    (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.)

    Staffing

    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.

    C.6.2 Test and Evaluation Facility

    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.

    C.7 Operational Test and Evaluation

    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:

    1. Username and password to access the Registrar Channel Partner only area of the .pro web site.

    2. The OT&E Testbed server information and username/password for two accounts to access the .pro OT&E Testbed for registrar client testing.

    3. Instructions on where to download the SRS Registrar Tool Kit.

    4. Instructions on where to download the documentation for the SRS Registrar Tool Kit.

    5. Instructions on where to download the SRS specifications and SRS Common Application Programmer Interfaces (APIs).

    6. Instructions on how to proceed with the OT&E certification process.

    7. Instructions on how to obtain an SSL certificate verified by the Registry Operator.

    8. Instructions on how to provide .pro with the list of subnets that will be used to access the SRS.

    9. Test Plans and Procedures that will explain the test cases, test metrics, data collection, test data analysis, and reporting to be performed during OT&E verification.

    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.

    1. Connection establishment

    2. SRS <login> command

    3. Change of <login> password

    4. SRS <logout> command

    5. Domain Name Operations

    a. Create domain with contacts and nameservers
    b. Create domain with contacts, but no nameservers
    c. Create domain with maximum registration period
    d. Create domain with maximum number of nameservers
    e. Create domain with maximum number of contacts
    f. Create domain with maximum length domain name (63 characters + . + valid second-level domain name + .pro)
    g. Create domain with invalid name
    h. Check domain (SRS Query <check>) - domain not available
    i. Check domain (SRS Query <check>) - domain available
    j. Check domain - maximum length domain name (63 characters + . + valid second-level domain name + .pro) not available
    k. Query domain (SRS Query <INFO>)
    l. Query domain transfer status (SRS Query <transfer>)
    m. Delete domain (SRS Transform <delete>)
    n. Renew domain (SRS Transform <renew>)
    o. Transfer domain (SRS Transform <transfer>)
    p. Change domain (SRS Transform <update>) - nameservers
    q. Change domain (SRS Transform <update>) - contact
    r. Change domain (SRS Transform <update>) - status
















    6. Nameserver Operations

    a. Create nameserver (SRS Transform <create>)
    b. Create nameserver with 80-character host name
    c. Check nameserver (SRS Query <check>) - nameserver known
    d. Check nameserver (SRS Query <check>) - nameserver unknown
    e. Query nameserver (SRS Query <INFO>)
    f. Delete nameserver (SRS Transform <delete>)
    g. Change nameserver (SRS Transform <update>) - add IP address
    h. Change nameserver (SRS Transform <update>) - remove IP address






    7. Contact Operations

    a. Create contact (SRS Transform <create>)
    b. Check contact (SRS Query <check>) - contact known
    c. Check contact (SRS Query <check>) - contact unknown
    d. Query contact (SRS Query <INFO>)
    e. Query contact transfer status (SRS Query <transfer>)
    f. Delete contact (SRS Transform <delete>)
    g. Transfer contact (SRS Transform <transfer>)
    h. Change contact (SRS Transform <update>) - change element
    i. Change contact (SRS Transform <update>) - remove element







    8. Effectiveness and utility of client session management and information exchange.

    9. Performance of client session management and information exchange throughput.

    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.

    C.8 Registrar Reports

    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:

    1. Daily Reconciliation Reports created from credit/debit and debit account transaction logs
    2. Daily and Monthly Registrar Cumulative Report for domain-names registrations
    3. Transaction logs
    4. Complete database export file of all data entities they own
    5. Objects transferred to other registrars
    6. Objects deleted from system
    7. Domains renewed automatically
    8. Daily Report of domains pending verification prior






    The Registrar Cumulative Reports include:

    • Total .pro domain-names "registered"
    • Total debit account debits and amount
    • Total wire transfers and amount

    Custom reporting is an optional feature that would allow registrars to specify report criteria and have a report available for download upon completion.

    • Numbers and names of domain-names registered within any period
    • Domain names transferred to/away from registrar within a specified period
    • Change of ownership activity, time/date request were processed
    • Re-delegation activity

    C.9 Transfers

    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.

    Procedure

    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:

    At the time the gaining registrar requests the transfer, a notification message will be sent to the losing registrar indicating that a transfer of the object has been requested, and the gaining registrar will receive a response indicating that the transfer is pending the authorization of the request by the losing registrar. The losing registrar will then have up to five days to respond. In the event the losing registrar does not respond, the transfer will be processed as if it had been approved. If the losing registrar responds with a message denying the request to transfer, the Registry Operator will generate a notification message to both the registrar initiating the transfer and the losing registrar indicating that the transfer will not be completed, and the transfer process will terminate. If the losing registrar responds with a message approving the transfer, or if the five day window ends without a response, both the registrar initiating the request and the losing registrar will be notified that the transfer has been authorized, and the object will be immediately transferred to the registrar that initiated the transfer.

    Once authorization of the object has been completed, the object will be transferred from the losing registrar to the gaining registrar. This transfer is affected by modifying the "Registrar" field associated with the object. For domain objects, at the time of the transfer, the registration period is extended by a year, and the gaining registrar's account is charged for a registration. All nameserver objects within a domain are implicitly transferred between registrars at the time that the domain is transferred; name servers associated with a domain are not transferred unless they are within the domain.

    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:

    The Registry Operator would allow authentication information to be stored by registrars within database objects. Initial authentication information would be generated at the time that object registration occurs, and could be modified or queried through the RRP by the object's sponsoring registrar.

    At the time a transfer were initiated, the registrar initiating the transfer could collect the authentication information from the Registered Name Holder and submit this information through the EPP as part of the <transfer> command. If the authentication information matched that stored in the registry's database, both the registrar initiating the transfer and the losing registrar would be sent a message confirming that the transfer would take place, and the object would be immediately transferred to the registrar initiating the transfer. If the authentication information did not match that stored in the registry's database, the registrar initiating the transfer would receive an error response and the transfer would not occur. Simultaneously, a message would be transmitted to the losing registrar indicating that a transfer of the object had been requested, but that the authentication information was invalid.

    The mechanism would also include operational practices and commitments of the Registry Operator and registrars for the handling of the authorization information that reasonably assures that transfers can occur if, and only if, they are authorized by the Registered Name Holder.

    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.

    C.10 Grace Periods

    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:

    Delete. If a domain is deleted within the Add Grace Period, the sponsoring Registrar at the time of the deletion is credited for the amount of the registration. The domain is deleted from the Registry database and is immediately available for registration by any Registrar. See below for a description of overlapping grace period exceptions.

    Renew. If a domain is extended within the Add Grace Period, there is no credit for the add. The account of the sponsoring Registrar at the time of the extension will be charged for the initial add plus the number of years the registration is extended. The expiration date of the domain is extended by the number of years, up to a total of ten years, as specified by the registrar's requested Renew operation.

    Transfer (other than ICANN-approved bulk transfer). Transfers under Part A of Exhibit B to the Registry-Registrar Agreement may not occur during the Add Grace Period or at any other time within the first 60 days after the initial registration. Enforcement is the responsibility of the Registrar sponsoring the domain name registration and is currently enforced by the SRS.

    Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be made during the Add Grace Period according to the procedures in Part B of Exhibit D to the Registry-Registrar Agreement. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the initial add.

    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:

    Delete. If a domain is deleted within the Renew Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the renew fee. The domain is deleted from the Registry database and is immediately available for registration by any Registrar. See below for a description of overlapping grace period exceptions.

    Renew. A domain can be extended within the Renew Grace Period for up to a total of ten years. The account of the sponsoring Registrar at the time of the additional extension will be charged for the additional number of years the registration is extended.

    Transfer (other than ICANN-approved bulk transfer). If a domain is transferred within the Renew Grace Period, there is no credit. The expiration date of the domain is extended by one year. In the event that the extension would result in an expiration date for the domain that is more than ten years from the date of the transfer, the expiration date will be set to ten years from the date of the transfer.

    Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be made during the Renew Grace Period according to the procedures in Part B of Exhibit D to the Registry-Registrar Agreement. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the Renew operation.

    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:

    Delete. If a domain is deleted within the Auto-Renew Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the Auto-Renew fee. The domain is deleted from the Registry database and is immediately available for registration by any Registrar. See below for a description of overlapping grace period exceptions.

    Renew. A domain can be Renewed within the Auto-Renew Grace Period for up to a total of ten years. The account of the sponsoring Registrar at the time of the additional extension will be charged for the additional number of years the registration is extended.

    Transfer (other than ICANN-approved bulk transfer). If a domain is transferred under Part A of Exhibit D to the Registry-Registrar Agreement within the Auto-Renew Grace Period, the losing Registrar is credited with the Auto-Renew charge and the year added by the Auto-Renew operation is cancelled. The expiration date of the domain is extended by one year up to a total maximum of ten by virtue of the transfer and the gaining Registrar is charged for that additional year, even in cases where a full year is not added because of the 10-year maximum limitation.

    Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be made during the Auto-Renew Grace Period according to the procedures in Part B of Exhibit D to the Registry-Registrar Agreement. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the Auto-Renew.

    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:

    Delete. If a domain is deleted within the Transfer Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the transfer fee. The domain is deleted from the Registry database and is immediately available for registration by any Registrar. See below for a description of overlapping grace period exceptions.

    Renew. If a domain is extended within the Transfer Grace Period, there is no credit for the transfer. The Registrar's account will be charged for the number of years the registration is extended. The expiration date of the domain is extended by the number of years, up to a maximum of ten years, as specified by the registrar's requested Extend operation.

    Transfer (other than ICANN-approved bulk transfer). If a domain is transferred within the Transfer Grace Period, there is no credit. The expiration date of the domain is extended by one year up to a maximum term of ten years.

    Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be made during the Transfer Grace Period according to the procedures in Part B of Exhibit D to the Registry-Registrar Agreement. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the Transfer operation that occurred prior to the Bulk Transfer.

    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).

    • If a domain is deleted within the Add Grace Period and the Renew Grace Period, then the Registrar is credited the registration and renew amounts, taking into account the number of years for which the registration and renew were done.
    • If a domain is auto-renewed, then extended, and then deleted within the Extend Grace Period, the registrar will be credited for the Auto-Renew and the number of years for the extension.

    Overlap Exception

    • If a domain is deleted within one or several Transfer Grace Periods, then only the current sponsoring Registrar is credited for the transfer amount. For example if a domain is transferred from Registrar A to Registrar B and then to Registrar C and finally deleted by Registrar C within the Transfer Grace Period of the first, second and third transfers, then only the last transfer is credited to Registrar C.
    • If a domain is extended (through the SRS command "Renew") within the Transfer Grace Period, then the current Registrar's account is charged for the number of years the registration is extended.

    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.

    C.11 Character Sets

    This section defines the different character sets being used by the Registry Operator.

    UTF-8

    Usage

    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.

    Definition

    The UTF-8 character set will be interpreted according to the definition found in RFC 2279.

    Domain name character set

    Usage

    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.

    Definition

    The rules for the format and character set of domain names are defined by the following:

    dot = %x2E ; "."
    alpha = %x41-5A | %x61-7A ; A-Z | a-z
    digit = %x30-39 ; 0-9
    dash = %x2D ; "-"
    dns-char = alpha | digit | dash
    id-prefix = alpha | digit
    label = id-prefix [*61dns-char id-prefix]
    sldn = label dot label; not to exceed 254 characters
    tldn = label dot label dot label; not to exceed 254 characters
    hostname = 1*(label dot) sldn; not to exceed 254 characters or such shorter limit that ICANN establishes in consultation with Registry Operator








    C.12 One, Two and Three Character Phased Allocation Program

    .PRO One, Two, and Three Character Phased Allocation Program ("Phased Allocation Program"). The domain names included within the scope of the Phased Allocation Program shall be limited to one, two, and three character .PRO domain names. RegistryPro reserves the right to not allocate all one, two and three character .PRO domain names.

    Pursuant to the Phased Allocation Program, RegistryPro may elect to allocate the domain names via the following processes: 1) request for proposals based on evaluation criteria, 2) auction, or 3) first come, first served registration.

    The domain names allocated via the Phased Allocation Program are an exception to the Maximum Service Fee described in Appendix G of the .PRO Registry Agreement.

    Earlier draft:

    30 Sept 2004
    21 May 2004
    26 August 2003
    27 April 2002

    3 March 2002


    Comments concerning the layout, construction and functionality of this site
    should be sent to webmaster@icann.org.

    Page Updated 30-Jul-2009

    ©2002  The Internet Corporation for Assigned Names and Numbers. All rights reserved.