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.
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
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.
||Call Back Time
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:
||Average Resolution Time
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:
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
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.)
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
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:
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.
- 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.
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:
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
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 firstname.lastname@example.org.
Page Updated 05-Oct-2004
©2002 The Internet Corporation for Assigned Names and Numbers. All rights reserved.