C1 Registry Overview
C2 Registry Services Locations
C3 Service Descriptions
C4 Registry-Registrar Model and Protocol
C5 Zone File Generation, Distribution, and Publication
C6 Whois Service
C7 Customer Support Services and Capabilities
C8 Operational Test and Evaluation
C9 Registrar Reports
C11 Grace Periods
C12 Character Sets
C13 Additional Services
C1. Registry Overview
The .org registry consists of a shared registration system, a Whois system, a name services system, and a number of ancillary and supporting subsystems which allow Internet users to register domain names, perform queries against the registry database, and otherwise perform operations relevant to the use of the .org top-level domain name space. There are also additional services provided for registrars to manage the business they conduct with the registry. Details of the various subsystems are found in the sections that follow.
Registry Facilities site descriptions
All registry systems are located within secure data centers, which conform to these minimum security standards:
- 24/7 on-site security personnel and security monitoring
- Surveillance cameras
- Controlled access to the data center
- Use of identification systems
The registry operator currently locates data centers in St. Louis, MO, USA and Secaucus, NJ, USA. Data centers may be moved to other, equivalent-class centers around the world. The registry operator may also acquire additional equivalent-class data center space in other locations as the need arises.
C2. Registry Services Locations
The .org registry consists of multiple, geographically dispersed sites. The SRS and Whois systems share facilities; the DNS systems are located in separate facilities (see Section C4 for details). Primary and secondary facilities, and the administrative center, are connected to one another using a secure virtual private network (VPN); connections to the DNS systems use the public Internet, but rely on a secure connection.
Primary center: fully-managed facility, St. Louis, MO, USA
Primary facilities are fully hosted solutions in V3 telco-grade, high security buildings. Only center staff has access to the physical environment, servers, network devices, and so on. Multiple air conditioning units are configured in a fully redundant array. Multiple UPS power units with battery backup provide clean and reliable electrical power. Multiple diesel generators, also in a fully redundant array, are available during extended power outages. Server racks, cases, network cables and components are systematically labeled with color coded identifiers; minimizing the possibility of any human error during plant service work, and accelerating trouble-shooting capabilities in the event of equipment failure. Security guards are on duty 24/7, and enforce a sign-in process where center staff entering the facility must be on the approved list and be accompanied by a minimum of one other staff member. The entire facility is monitored by video surveillance.
Secondary ("fail-over") center: managed and self-managed facility, Secaucus, NJ, USA
All fail-over facilities are co-located in telco-grade, high-security buildings. Security guards are on duty 24 hours a day, 7 days a week, and enforce a sign-in process where anyone entering the facility must be on the approved list. Visitors must show legal photo ID to be granted access to each facility. Once inside the facility, visitors must use a card key and palm scanner to gain access to the data center. The registry systems are locked within cages in the data center and must be unlocked by security personnel. The entire facility is monitored by video surveillance. Multiple air conditioning units are configured in a fully redundant array. Multiple uninterruptible power supplies provide clean and reliable electrical power. Multiple diesel generators, also in a fully redundant array, are available for extended power outages.
C2.1. SRS Data Center Functional Description
The SRS data centers house the SRS servers, the Whois servers, and the databases to support these services. All services at the primary data center are provisioned in a redundant manner, so that the failure of a single component does not disable completely the data center. Services are additionally replicated in the secondary data center, so that the complete failure of the primary data center will not entail a failure of the registry. A target architecture diagram is provided in Figure 1. The diagram is for illustrative purposes, and the design is subject to change as the registry operator continues development of its SRS. No changes in the design will compromise the aforementioned redundancy and/or failover characteristics of the registry.
Figure 1: Target architecture of .org registry
The table below summarizes some of the key components of the registry; many of these components are illustrated in Figure 1.
| Infrastructure directory
|Primary database (master)
||The database provides read-write data storage for the SRS. It is the authoritative repository of names in the .org database, and provides the data to slave databases
| Secondary databases (slave)
||During normal operations, these databases provide read-only data storage to various services, including the Whois servers. In failover mode, any of these systems may get promoted to become the primary database.
| EPP server
||The server which provisions registry objects. It uses the extensible provisioning protocol as its native protocol. It performs all database operations by connecting to the primary database.
| RRP proxy
||A compatibility layer which permits users of the legacy .org protocol, RRP, to perform object queries and transformations in the new .org registry. The capabilities of the proxy are limited to the capabilities of RRP.
| Whois server
||A server which responds to Whois queries according to the protocol defined in RFC 954. It may perform database read operations against the master or slave databases.
| Web admin server
||A web-based interface to the EPP server. It provides additional, administrative functions via EPP which are available only through the admin interface (e.g. accessing reports).
| Load balancer
||Access to the application-layer services in the primary data center is balanced across multiple instances of the same services, in order to ensure balanced use of resources.
| Rate limiter
||Concurrent and near-concurrent access to the application-layer services in the data centers is limited, in order to guard against denial-of-service attacks.
| Enhanced services
||Enhanced services such as ORGWatch, when available, will be deployed in the same redundant fashion as other production services.
| Support services
||Support services (such as reports) will be located on servers at the secondary site.
| OTE servers
||Operational Testing and Evaluation servers will be offered on servers at the secondary site. These servers will provide copies of the production software, so that registrars who are experiencing technical difficulties or testing new client software may experiment without affecting the real .org registry. One OT&E server will function as a "sandbox", to allow registrars to perform such tests as they desire at will. Another server will be reserved for testing registrars for compliance with policies, and with the protocols used by the registry.
| Data mart
||Some data will be moved from the "live" database servers to a secondary database, in order to avoid affecting SRS or Whois services. This data will be subject to the same controls as the primary and secondary databases.
C2.2. Nameserver site functional description.
The registry operator shall provide domain name services via multiple meshes of core servers located around the world, in accordance with the provisions of Appendices D and E. Some of the domain name server sites are listed below, and illustrated in Figure 2. Additional sites may be added as the need arises.
- Palo Alto, CA, USA
- Vienna, VA, USA
- San Jose, CA, USA
- Ashburn, VA, USA
- Chicago, IL, USA
- London, UK
- Tokyo, JP
- Marina del Rey, CA, USA
Figure 2 :Illustrative DNS server locations
C3. Service Descriptions
Domain name registrations
The .org registry has two modes of operation: "thick" and "thin" modes. The native mode of registration in the SRS requires the use of EPP to register domain names; in this mode, the registry will operate as a "thick" registry, and therefore will require full contact data for each registered domain name. In order to facilitate the transition to the thick registry, however, the registry will initially operate a traditional "thin" registry in accordance with the schedule in Appendix J.
A. Thick mode
Domain names in the .ORG TLD may be registered through ICANN-accredited registrars that will have Registry-Registrar Agreements ("RRAs") in effect with PIR and are qualified ("Approved Registrars"), according to the following criteria:
Each domain name which is to be entered in the DNS zone file must have from two to 13 nameservers, inclusive.
At least one of each type of contact (registrant, administrative, technical, and billing) must be assigned to each domain name. The same contact may be used for the different contact types, as well as across multiple domains.
A minimum one-year term, maximum ten-year term, in one-year increments.
Domain names must be of the format specified for the "Domain name character set" as specified.
Domain names must meet the naming conventions for domain names specified.
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 be rejected by the system. Should a registrant require a transfer or renewal past the 10-year term (for instance, as required by a court order), Registry Operator may undertake a different, potentially non-automated process to ensure compliance.
All domain-name registrations must be made pursuant to the requirements of the Approved Registrar's RRA with PIR.
The Approved Registrar will collect registration information from the registrant and check to ensure the validity of the domain-name registration. The registrar must submit through the Shared Registration System complete, accurate, and valid registration data, and must update that data when changes occur.
The above criteria are intended to summarize the requirements for registration and do not supersede any other requirements in this Registry Agreement or otherwise.
During their term, domain name registrations will be maintained in the .ORG Shared Registration System. They will be reported by the .ORG Whois service, as described in Appendix O. In addition, domain names with registrations that include at least two name servers will be included in the .ORG TLD zone. (Domain names found in the zone at the time of Cutover with only a single nameserver will be continued, but this condition must be corrected after a migration period to be agreed by PIR and ICANN.) All name servers located within the .ORG TLD are required to be registered with an IP address, and will be published to the .ORG TLD zone with an associated glue resource record. Other additional information will be required for Ipv6. This is further described in Section C5, Zone File Generation, Distribution and Publication.
B. Thin mode
In the thin mode, the registry will not require registrars to provide contacts for each domain name registered (because RRP does not have a facility for manipulating registry contact objects). The thick registry-required contact data, however, will nevertheless be present. Special reserved contact information will be used in order that the registry is always technically compliant with the thick registry model; but this contact information will be marked in such a way as to label the contact information as non-authoritative. Registrars shall be required to provide appropriate and accurate contact data to the registry upon conversion to the thick registry mode, in accordance with the schedule in Appendix J.
Because of the requirement to support RRP, the thin mode registry will also not comply with all of the EPP requirements during the period of thin-mode registration.
C4. Registry-Registrar Model and Protocol
Initially, approved registrars will connect to the registry using the registry-registrar protocol, as outlined in RFC2832 (http://ietf.org/rfc/rfc2832.txt?number=2832). The RRP interface will be a proxy for EPP commands, so that the fundamental application need not change when registrars are prepared to adopt the newer EPP protocol. Each RRP key-value pair will be translated to EPP XML. The proxy will add additional, required fields to the XML, where necessary, to generate valid EPP commands. Additional out-of-band services may be provided to help facilitate current RRP functionality.
The registry will maintain some information about each domain, in order to indicate whether the domain was last manipulated through RRP; this will allow the SRS to indicate whether it has authoritative contact data for the domain.
The SRS native protocol is EPP, the product of the work of the IETF provreg working group (<http://www.ietf.org/html.charters/provreg-charter.html>). The registry will initially use the protocol as outlined in <http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-07.txt> and its associated documents; these are attached as Exhibits A, B, C, and D.
In order to accommodate the lack of contact-manipulation commands in RRP, the registry will be seeded with contacts to be associated with domains manipulated via RRP.
EPP requires the use of an <authInfo> element, in order to authenticate the requester of certain transform operations on a domain name. RRP does not enforce such a restriction, and therefore the <authInfo> element will not provide the authentication mechanism it is designed to provide until a given registrar has converted to EPP.
C5. Zone File Generation, Distribution, and Publication
Zone file generation involves the creation of DNS zone information using the registry database as the authoritative source of domain names and their associated hosts (name servers). Updates to the zone information will be generated automatically at least every fifteen minutes and published to the name servers. These updates will reflect any DNS-related modifications, additions or deletions to the registry, that have been made by the registrars during that time period. Only changes that have been committed to the database will be reflected in the zone information update. Incomplete units of work will be ignored.
The master zone file will include the following resource records:
- A single SOA record.
- A number of NS and A records, up to a maximum of 13 of each, for the TLD DNS servers for .ORG.
- One NS record, up to a maximum of 13, for each unique domain/nameserver combination. Domain objects with status values of clientHold, serverHold, or inactive will not be included in the zone file.
The ORGLock service, when available, will have an effective EPP value of the union of<serverDeleteProhibited>,<serverTransferProhibited>, and <serverUpdateProhibited>, and so will not affect the DNS status of a domain.
In the case of Ipv4, one A record for each required glue record, up to a maximum of 13 per domain name. The registry will implement, on a rational schedule, glue generation and pruning criteria as specified by ICANN from time to time.
In the case of Ipv6, one A6 record for each required glue record, up to a maximum of 13 per domain name. Additional glue records may also be published, if symbolic domain name servers included as part of a domain name’s A6 record are also subordinate to the .ORG TLD.
The .ORG registry will provide bulk access to the TLD zone file for qualified third parties. The service will operate according to the prevailing policies of ICANN and PIR.
The DNS services comply fully with the following RFCs: 1034, 1035, 1101, 2181, and 2182, as well as (to the extent applicable) 1771, 1812, 2080, 2236, 2328, 2373, 2453, 2460, 2463, and 2464.
C6. Whois Service
Please see Appendix O for details of the Whois service.
C7. Customer Support Services and Capabilities
In order to provide registrars and registrants with the support they need, the registry operator will offer customer service. Because of changes in the marketplace, the emergence of new technologies and the decline of old ones, and other factors beyond the registry operator's control, the facilities and arrangements for customer service may change from time to time. Each change in policy will be preceded by adequate notice, according to the degree of change anticipated. (For instance, the presence of additional technical support personnel would require no notice, but the addition of a new set of registrar documents would require advance notice.) What follows is a sample description for illustrative purposes only: while the overall level of support will be similar to that outlined here, details are subject to change. The overall responsiveness of customer support will conform to the outline below, according to best current industry practices.
The registry's customer service will be organized into the following departments:
- Front-line customer support
- Administrative/ billing/ financial support
- Technical support
- Front-line Customer Support
C7.1 Front-line Customer Support
The front-line support is the first point of contact for .ORG registrars. This 24/7/365 operation will be able to answer general registrar questions. Upon receiving any query from a registrar, a service support case is opened and a support ticket is issued. If the query is out of the bounds of customer support, these support tickets are escalated to either the technical support team or the administrative/financial/billing support team depending on the nature of the problem.
Methods of contact that will be supported by customer support will include telephone, fax, postal mail, e-mail, and other methods announced from time to time by the registry operator according to market conditions.
Web-based self-help shall be made available to the registrars that will include at least the following:
- Registry policies
- Frequently asked questions
- Knowledge bases
- Downloads of registry client software
- Administrative/Financial/Billing Support
C7.2 Administrative/Financial/Billing Support
The administrative/financial/billing support team will deal with registrars' business, account management, financial and billing issues. Examples that fall into these categories include the following:
- Registrar account balance inquiries
- Registrar low-balance warning notifications
- Crediting a registrar's account after payment
- Legal issues related to the registry-registrar agreement
- Administrative issues for the acceptance of new registrars
C7.3 Technical Support
The technical support team is responsible for dealing with registrars' technical issues. Technical support will be provided through our help desk. The Technical Support Specialist will authenticate the caller by using a pre-established security pass phrase. Request for assistance may also come to the technical support team via e-mail, fax or Front-line Customer Support, or other means as announced from time to time by the registry operator, in view of market conditions.
The registry shall provide a complete package of support services through the Technical Support Group (TSG). These services shall be dedicated primarily to authorized registrars, although inquiries from potential registrars or those in evaluation stages shall also be supported. Overall, the TSG will provide around the clock, real time professional support ranging from basic inquiries to high-level operations critical technical support.
The registry's operation staff shall be available 24/7/365, with required members of the department on call. Escalation procedures shall be in place ensuring that management is notified of service outages in a timely manner.
C7.4 Ticketing System and Call Statistics
The registry's help desk shall collect call statistics and record service requests and trouble tickets in a help desk database. The help desk database documents the status of requests and tickets, and notifies the help desk when an SLA threshold is close to being breached. Each customer and technical support specialist uses our problem management process to respond to trouble tickets with a troubleshooting, diagnosis, and resolution procedure as well as root cause-analysis.
C7.5 Access to Registry Data
The TSG shall have access to registry data sufficient to support authorized registrars. To the extent that current operating status can be determined, response to specific registrar queries about registrar specific data or specific transactions can be provided. PIR employees shall be required to properly identify the authorized registrar before providing any registrar critical data, and shall be prohibited from providing information about operations of other authorized registrars.
The registry's TSG shall be responsible for notifying Authorized registrars of upcoming maintenance and outages with strict requirements regarding advance notice. At a minimum, all planned C1 service outages and maintenance shall be announced at least 7 days prior to the scheduled date; all planned C2 service outages and maintenance shall be announced at least 7 days prior to the scheduled date; all planned C3 service outages and maintenance shall be announced at least 1 day prior to the scheduled date . Further, the TSG shall provide immediate notice of unplanned or unscheduled outages and maintenance.
C7.7 Customer Escalation Process
The TSG will operate with an escalation policy. Normally, support calls or other forms of communication will start with the lowest level of support, and be escalated should the first level of support be insufficient. In cases where higher levels of support are immediately apparent (all levels of support staff will be trained in identifying these) the escalation chain may be jumped. Also, should the time limit expire with no notice, the support level may be escalated. The following outline is a target, included for illustrative purposes, and is subject to change according to best current industry practices. The escalation levels and response requirements are as follows:
Technical question, usually unique to the registrar that may require support from a registry systems operator or engineer. Initial responses to requests for information or technical support shall be provided within one hour unless is it deemed to be a Level 2 incident.
Systems outage involving non-critical operations to the registry affecting one or more registrars only, but not the entire system. Response reports shall be provided regularly, but no less often than every 6 hours, by no less than a qualified registry systems engineer.
Catastrophic outage, or disaster recovery involving critical operations to the registry overall. Response reports shall be provided at least every 90 minutes, by no less than a senior registry systems engineer.
C8. Operational Test and Evaluation
Kinds of OT&E tests
Before a registrar is allowed to join the live Shared Registry System it must first pass Operational Test and Evaluation (OT&E) certification. The purpose of OT&E certification is to verify the correct operation of a registrar's client system.
In addition, a special OT&E test will be performed by any registrar with pre-existing, RRP-generated data in the registry. This test is in addition to the standard initial OT&E test.
C8.1 Initial OT&E (Phase 1 of OT&E)
The OT&E certification process begins when a registrar becomes accredited by ICANN to register names in the .ORG TLD, at which point an OT&E welcome package will be provided to the registrar. This package will include information that will assist the registrar in developing its client application for the Shared Registry System. This package will include the following:
- Username and password to access the registrar only area of the registry web site.
- OT&E server information and username/password for two accounts to access OT&E environment for registrar client testing.
- Instructions on where to download the Registrar Tool Kit.
- Instructions on where to download the documentation for the Registrar Tool Kit.
- Instructions on where to download the EPP specifications.
- Instructions on how to proceed with the OT&E certification process.
- Instructions on how to obtain an SSL certificate from an approved Certificate Authority.
- Instructions on how to provide the registry with the list of subnets that will be used to access the live Shared Registry System.
- Documentation that will explain the tests to be performed during OT&E verification.
The registrar is responsible for developing the client application that will interface to the registry using the EPP protocol. For a fee, PIR may be able to provide client development assistance. PIR's Registrar Tool Kit will be available to any interested party that would like to develop registrar client applications. A registrar may opt to develop its application to conform to the EPP specification without the use of the Registrar Tool Kit. This is acceptable as long as the client is able to pass the OT&E certification process.
During client development, the registrar has access to The Public Interest Registry' OT&E environment. In the OT&E environment, the registrar may test the operation of its software to verify the correct handling of EPP commands and their responses. There will be no charges associated with operations performed in the OT&E environment and will not have any impacts on the live Shared Registry System. Registrars will continue to have access to the OT&E environment after certification, so that they may continue to test their software systems.
When a registrar has completed the testing of its client systems and would like to proceed with OT&E certification, it will contact PIR technical support to schedule a time slot. Time slots will be scheduled on a first-come-first-serve basis. At the scheduled time, the registrar should contact PIR's OT&E Team to initiate the certification.
C8.2 RRP-to-EPP OT&E (Phase 2 of OT&E)
In order to ensure the stability of the functioning registry, and to ensure a smooth migration for registrars, each registrar that sponsors RRP-manipulated names in the database will need to pass an additional test. This second test evaluates the ability of the registrar to successfully use EPP, and to alter RRP-created data using EPP, so that the data conforms fully to the thick registry model.
As with the initial OT&E process, a registrar will have open access to the registry operator's OT&E environment, in order to test client code and procedures. When the registrar believes it has completed development, it will contact the registry operator, and schedule a test. Test spaces will be filled according to demand, in the order requests are made.
C9. Registrar Reports
PIR will generate reports for each registrar on a daily and weekly basis. These reports will contain domains, nameservers and contacts for which the registrar is the sponsoring registrar. The reports are available for download from the registrar web administration interface secure web site. This site requires the registrar to provide its username and password for authorization.
C9.1 Report Types
Two types of reports will be created for each registrar: Daily Reports and Weekly Reports. These are described below.
C9.1.1 Daily Reports
Daily Transaction Report: This reports includes Addition, Modification, Delete and domain Transfer activity by the registrar. Domain operations produce one row for each associated nameserver. Nameserver operations produce one row for each associated IP address. A transaction ID is included in column 1 to allow unique identification of transactions. Column 2 contains the transaction operation. The content of column 3 and 4 is dependent on the operation according to Table 1.
| Add domain
| Mod domain
| Del domain
| Add nameserver
| Mod nameserver
| Del nameserver
| Transfer domain
Column 5 contains the transaction date (as illustrated in the example below).
Daily Transfer Reports: This report includes gaining and losing transfer activity. There are two separate reports for transfers:
Gaining Transfer Report: indicates domains transferred to the registrar ("gaining registrar").
Losing Transfer Report: indicates domains transferred away from the registrar ("losing registrar").
The Transfer reports will have the following fields: Gaining registrar name, Domain name, Losing registrar name, Date/time of transfer request, Status (one of ACK, NACK or PENDING), Date/time of ACK/NACK. The value of Date/time of ACK/NACK will be NULL if the status is PENDING. For example:
Registrar A, Inc.:EXAMPLE1.ORG:Registrar B Inc.:2001.07.01.15.13.41:PENDING:
Registrar A, Inc.:TEST.ORG:Registrar B Inc.:2001.07.01.15.14.00:ACK:2001.07.03.04.23.12
Registrar A, Inc.:TEST2.ORG:Registrar B Inc.:2001.07.01.15.25.00:NACK:2001.07.03.05.50.39
C9.1.2 Weekly Reports
Weekly Domain Report: Lists all domain names currently sponsored by the registrar. The domain is listed once with each current status and associated name server. For example:
Weekly Nameserver Report: Lists all nameservers currently sponsored by the registrar. The nameserver is listed once with each associated IP address. For example:
Domains Hosted by Nameserver Weekly Report: Lists all domains hosted on nameservers currently sponsored by the registrar. The nameserver is listed once with each associated domain name.
C9.2 Report Frequency
Daily reports will be generated daily every four hours. Previous reports for that day shall be overwritten each time a new daily report is generated.
Weekly reports will be generated on Sunday at 00:00 UTC and shall contain activity for the previous week.
Daily registrar reports are maintained for each registrar for seven days. Daily reports older than seven days will be archived for a period of 30 days, after which they will be removed.
Weekly registrar reports are maintained for each registrar for four weeks. Weekly reports older than four weeks will be archived for a period of 6 months, after which they will be removed.
Registrar reports shall be available for download via a Reports section in the registrar web administrative interface. Each registrar will have secure, password-protected access to the registrar administrative interface. A given registrar will only have access to its own reports. The registry operator reserves the right to change the distribution method as new protocols are adopted.
Registrars use the Transfer Request Domain command to change a domain's sponsoring registrar. The transfer request is issued by the gaining registrar, after which the registry will notify the current registrar of the request to transfer the domain. The current registrar may choose to accept or deny the transfer request. If the current registrar takes no action, the registry will automatically accept the transfer after a pre-determined number of days. A domain that is transferred will have its expiration date extended by at least one year. The expiration extension is a billable operation. When a domain is transferred, all Host objects for which this domain is the parent domain will also be transferred to the gaining registrar.
Transfer Domain uses the EPP Domain Mapping <transfer> transform request as well as the RRP TRANSFER command, depending on whether the registrar has begun to use EPP. Different procedures will be followed during the period before all registrars have completed the transition to EPP, When all registrars have begun to use EPP, the following is the procedure to transfer a domain:
A requesting registrar requests the transfer, providing the <authInfo> data as required by EPP.
The domain is put into PendingTransfer status.
The losing registrar uses the EPP <poll> command to discover pending events, and finds the pending transfer.
The losing registrar either approves or rejects the request, or does nothing. If the losing registrar does nothing, the transfer will proceed after the period determined by ICANN's prevailing policy has expired.
Following are the different operations that can be performed using the transfer command: Request, Query, Cancel, Approve, Reject
During the period where RRP is still a valid protocol for the registry, the <authInfo> element will not always be available, either because the protocol does not support it (in case a gaining registrar is using RRP) or because the <authInfo> is unknown (in case a gaining registrar is using EPP, but the domain was last manipulated with RRP). As a result, an additional protocol will be used in that period, to reduce the risk of unauthorized transfers. After a transfer is requested, email correspondence regarding Transfer Requests will be sent to the losing registrar so that he may perform one of the following actions on objects requested for Transfer: Query/Approve/Reject. Additionally, in case of automatic approval of Domains/Contacts after grace period expires and no action has been taken by the losing registrar, email correspondence regarding Transfer Approvals will be sent to the losing registrar.
Registrars shall not provide identical Registrar-generated <authinfo> codes for domain names registered by different registrants with the same Registrar. The Registry Operator in its sole discretion may choose to modify <authinfo> codes for a given domain and shall notify the sponsoring registrar of such modifications via EPP compliant mechanisms (i.e. EPP<poll> or EPP<domain:Info>). Documentation of these mechanisms shall be included in the Registrar toolkit provided by the Registry Operator. The purpose of this is to reduce the potential for unauthorized transfers due to duplication of <authInfo> data.
C11. Grace Periods
A Grace Period refers to a specified number of calendar days following a Registry operation in which the domain may be deleted and a credit may be issued to a registrar. Relevant registry operations in this context are:
- Registration of a new domain
- Extension of an existing domain
- Auto-Renew of an existing domain Transfer of an existing domain
- Deletion of an existing domain
- Restore of a domain name
Extension of a registration period is accomplished using the EPP Renew command or by auto-renewal; registration is accomplished using the EPP Create command; deletion is accomplished using the EPP Delete command; restore is accomplished by the procedure described in detail in Part C13, Appendix C, and transfer is accomplished using the EPP Transfer command or where ICANN approves a bulk transfer.
There are five grace periods in the PIR Shared Registration System:
1. Add Grace Period
2. Renew/Extend Grace Period
3. Auto-Renew Grace Period
4. Transfer Grace Period
5. Redemption Grace Period
A Pending Period refers to a specified number of calendar days following a Registry operation in which final Registry action is deferred before the operation may be completed. Relevant Registry operations in this context are:
- Transfer of an existing domain
- Deletion of an existing domain
C11.1 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, Extend (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 Overlapping Grace Periods for a description of overlapping grace period exceptions. If a domain name is deleted after the five calendar day grace period expires, it will be placed on HOLD for five calendar days and then deleted through the system.
Extend (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 Extend operation.
Transfer (other than ICANN-approved bulk transfer): Transfers under Part A of Exhibit D 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 will be 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.
C11.2. Renew/Extend Grace Period
The Renew/Extend Grace Period is a specified number of calendar days following the renewal/extension of a domain name registration period. The current value of the Renew/Extend 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/Extend Grace Period, the sponsoring registrar at the time of the deletion receives a credit of the renew/extend fee. The deleted domain is moved to the Redemption Grace Period (that is to the status: Pending Delete – Restorable) as described in Part C13, Appendix C. See Overlapping Grace Periods for a description of overlapping grace period exceptions.
Extend (Renew): A domain can be extended within the Renew/Extend Grace Period for up to a total of ten years. The registrar's available credit will be charged for each of the additional number of years the registration is extended.
Transfer (other than ICANN-approved bulk transfer): If a domain is transferred within the Renew/Extend Grace Period, there is no credit. The expiration date of the domain is extended by one year and the years added as a result of the Extend remain on the domain name up to a total of 10 years.
Bulk Transfer (with ICANN approval): Bulk transfers with ICANN approval may be made during the Renew/Extend 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/Extend operation.
C11.3 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, Extend, 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 deleted domain is moved to the Redemption Grace Period (that is to the status: Pending Delete – Restorable) as described in Part C13, Appendix C. See Overlapping Grace Periods for a description of overlapping grace period exceptions.
Extend (Renew): A domain can be extended 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 of 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 ten 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.
C11.4. 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 B 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 deleted domain is moved to the Redemption Grace Period (that is to the status: Pending Delete – Restorable) as described in Part C13, Appendix C. See Overlapping Grace Period for a description of overlapping grace period exceptions.
Extend (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 B 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.
C11.5 Bulk Transfer Grace Period
There is no grace period associated with Bulk Transfer operations. Upon completion of the Bulk Transfer, any associated fee is not refundable.
C11.6. Overlapping Grace Periods
If an operation is performed that falls into more than one grace period, the actions appropriate for each grace period apply except as follows:
If a domain is deleted within the Add Grace Period and the Extend Grace Period, then the registrar is credited the registration and extend amounts, taking into account the number of years for which the registration and extend were done.
The domain is deleted from the Registry database and is immediately available for registration by any Registrar.
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. The years that were added to the domain’s expiration as a result of the auto-renewal and extension are removed. The deleted domain is moved to the Redemption Grace Period (that is, to the status: Pending Delete - Restorable) as described in Part C13, Appendix C.
C11.7. 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/renewed 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.
C11.8. Transfer Pending Period
The Transfer Pending Period is a specified number of calendar days following a request from a registrar (registrar A) to transfer a domain in which the current registrar of the domain (registrar B) may explicitly approve or reject the transfer request. The current value of the Transfer Pending Period is five calendar days for all registrars. The transfer will be finalized upon receipt of explicit approval or rejection from the current registrar (registrar B). If the current registrar (registrar B) does not explicitly approve or reject the request initiated by registrar A, the registry will approve the request automatically after the end of the Transfer Pending Period. During the Transfer Pending Period:
- RRP TRANSFER request or RRP RENEW request is denied.
- AUTO-RENEW is allowed.
- RRP DELETE request is denied.
- Bulk Transfer operations are allowed.
C11.9. Delete Pending Period
The Delete Pending Period is a specified number of calendar days following a request to delete a domain in which the domain is placed in HOLD status without removing the domain from the Registry database. The current value of the Delete Pending Period for all registrars is five calendar days.
Registrars may request retraction of a delete request by calling PIR Customer Service staff within the Delete Pending Period. The Registrar will need to provide the security phrase to the PIR staff member prior to the staff member performing this retraction. This operation cannot be performed by the Registrar. Retraction requests processed during the delete pending period are currently at no cost to the registrar. If, by the end of the Delete Pending Period, no action is taken the domain will be deleted from the Registry database and returned to the pool of domain names available for registration by any registrar.
- EPP Renew or Auto-Renew requests are ignored.
- EPP Transfer request is denied.
- Bulk Transfer operations are allowed.
C11.10 Redemption Grace Period
PIR will implement a Redemption Grace Period (including related revisions to this item C11) as specified by ICANN within 135 days after its implementation by VeriSign Global Registry Services in the .com and .net top-level domains.
C11.11 Handling of released names
If it is technically and commercially feasible, PIR will undertake to devise a "Waiting List service", whereby names which are scheduled for release can be held for those on a waiting list.
C12 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 include 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.
This character set will mostly be used for logfile contents, error messages, and console text.
The interpretation of the ISO 8859-1 is per the ISO documentation for the ISO 8859 character set standard.
Reduced Character Set
This is a character set mostly for use in places where control characters are undesirable.
The reduced character set will be interpreted as a subset of the standard specification of the 7-bit US-ASCII character set found in the following document: 7-bit American Standard Code for Information Interchange (ASCII)," ANSI X3.4-1986.
The reduced character set consists of the following characters, specified in the Backus-Naur Form (BNF) meta-language.
References made to decimal character values are taken to mean corresponding US-ASCII values:
Reduced charset definition:
text = 1*CHAR ; max length depends on context
CHAR = (Decimal 32.-126.)
Password Character Set
This character set defines the characters available for specifying passwords.
The password character set will be interpreted as a subset of the standard specification of the 7-bit US-ASCII character set found in the following document: "7-bit American Standard Code for Information Interchange (ASCII),"ANSI X3.4-1986.
The password character set consists of the following characters, specified in the Backus-Naur Form (BNF) meta-language.
References made to decimal character values are taken to mean corresponding US-ASCII values:
Password charset definition:
password = 1*CHAR ; max length depends on context
CHAR = (Decimal 33.-126.)
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 internationalized 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
hostname = 1*(label dot) sldn; not to exceed 254 characters
E-mail Address Character Set
This character set is for use in places where an e-mail address is to be specified.
The rules for the format and character set of e-mail addresses are defined by RFC 2822. Except where otherwise specified, or where restricted by other standards, the registry operator's system will allow any address that is a legal e-mail address per the definitions given in RFC 2822 where an -mail address is to be used. An SLD E-mail address registered under the SLD E-mail service must, however, comply with the format rules for a third-level domain name, except that the first "." is replaced with a "@".
C.13 Additional Services
Redemption Grace Period Service
The Redemption Grace Period Service allows registrars to restore Registered Names that were unintentionally deleted and are still within a thirty-day Redemption Grace Period (RGP). The RGP Service covers all names deleted by registrars, with the exception of those names deleted in the Add Grace Period.
The RGP Service may be implemented in two stages. Stage 1 is as described in the following. In the future, ICANN and Registry Operator will discuss implementation of Stage 2, with the goal, if feasible, of allowing registrants to choose which registrar will restore their deleted name(s).
Stage 1 of the .org Registry RGP Service is implemented in two steps. The first step is an implementation of manual procedures. The second step is contemplated a fully automated and EPP-compliant implementation. The second step will be undertaken according to specifications agreed upon by ICANN and the Registry Operator.
Only statuses defined in the current EPP specifications will be used. As such all domains slated for deletion will remain in PendingDelete status for 35 days or until they are restored. The first 30 days the domain will be in the RGP and for the remaining 5 days, domain names that have not been requested for restore will be placed in a Redemption Hold Period.
Redemption Grace Period
All domains deleted outside the Add Grace Period will be placed in the RGP for a total of 30 days.
The only action allowed by the registrar in the RGP is the restoration of the domain name. Domain names in RGP cannot be otherwise modified.
Note: BULK TRANSFER operations are allowed within the 30-day RGP provided that such transfer is in accordance with Exhibit D to Appendix F. The gaining registrar in any ICANN-approved bulk transfer assumes the role of the deleting registrar with regards to any name in the PendingDelete status sponsored by the losing registrar at the time of transfer.
Note: TRANSFER or modification requests shall not be allowed during the RGP.
Upon being placed in RGP, domain names will be immediately removed from the DNS, but will remain in the Whois with a notation about their availability of being restored. The status of the domain names in RGP is: PendingDelete – Restorable.
Redemption Hold Period
At the conclusion of the 30-day RGP, domains not requested for restore, are placed in the Redemption Hold Period for the following five days.
In this period no changes can be made to the domain name (including restore) and the status of the domain will be shown as: PendingDelete – Scheduled for Release.
At the conclusion of this period, the domain will be purged from the Registry database and hence available for re-registration.
Manual Restore Process
The implementation of the RGP Service involves one command.
RESTORE Command: Registrars may restore names by contacting the registry operator by e-mail or fax using a specified Restore Request Form to request that the name be restored. The registrars must follow the specific process specification for the restore process as specified by Registry Operator's additional service description made available to all registrars.
A successful restore request will terminate the PendingDelete-Restorable status, and place the restored domain in a Redemption Lock Period as described below.
Restore Lock Period
After the name has been restored, it will be placed into a Restore Lock Period (RLP) for a period up to seven calendar days. In this time period the registrar must submit a Registrar Restore Report to the Registry Operator ( including the requirements set forth below).
If the registrar fails to submit a complete Registrar Restore Report within the RLP, the Registry Operator will, following an attempt to notify the registrar by both telephone and email automatically undo the Restore (with no refund to the registrar) and return the name to deleted status, subject to a new RGP.
If the registrar submits a successful Registrar Restore Report within the RLP the Registry Operator will remove the deleted status attribute from the registration and return the registered name to the same state it was in immediately prior to the delete request.
If the registered name is past its expiration date at the time it is restored, then, following the restore, its registration term will be extended by the minimum term of years necessary to bring it current. The registrar will first be debited for the restoration and following for the renewal term.
There is no Restore Grace Period.
Appropriate Use of the Restore Capability
Registrars may only Restore Registered Names in order to correct unintentional deletions caused by registrant, registrar, or registry mistake (or as required by operation of the UDRP or other applicable dispute resolution policy in order to implement a court, arbitral tribunal or Administrative Panel decision). Restoring Registered Names in order to assume the rights to use or sell them will be considered an abuse of the system and will give Registry Operator the ability to delete those impacted domain names or terminate the Registry-Registrar Agreement.
Registrar Reporting Requirement
In order to facilitate verification of registrar compliance with the intended purpose of the RGP Service, Registrars are required to submit a "Registrar Restore Report" to the Registry Operator.
The Registrar Restore Reports will be transmitted electronically according to a specified format and shall include the following content:
- WHOIS data for deleted name, as it existed prior to deletion.
- WHOIS data for deleted name, as it existed at the time of report submission.
- Exact date and time of deletion.
- Exact date and time of restore.
- Written explanation and corresponding reason code as to why registered name was restored (e.g., registrant mistake, registrar mistake, registry mistake, dispute resolution, etc.).
- Written statement affirming that Registrar has not restored the .ORG domain name in question in order to assume the rights to use or sell the name for itself or for any third party (unless the name was restored as required to give effect to an order or decision from a court, arbitral tribunal or Administrative Panel – in such cases a copy of the order should be provided separately to the Registry Operator by no later than five (5) business days following the restore).
- Written statement affirming that information in report is factually accurate to the best of the Registrar's knowledge, and that the registrar acknowledges that intentionally supplying false information in the Restore Report shall constitute an incurable material breach of the Registry-Registrar Agreement and may result in the deletion of the impacted domain name(s).
The registry will maintain (for two years) copies of all Restore commands, as well as provide ICANN with copies of such reports. Further, the registry will include in its monthly report to ICANN the number of Restore Reports received (see Appendix T).
Registry Transparency Requirement – Registry Reports
The Registry will provide comprehensive, regularly updated lists of names in Redemption Hold Period (PendingDelete-Scheduled for release) to all Registrars via an FTP or SCP mechanism; these lists will include corresponding dates of deletion. These reports will only include names in the last five days of the PendingDelete status.
The Registry will provide daily lists of names in RGP (Pending Delete – Restorable) to each Registrar via an FTP or SCP mechanism. These lists will only contain those names for which the Registrar is the Registrar of Record and will include corresponding status, date of deletion into RGP, scheduled date of deletion from system and date restored (if applicable).
Registry Transparency – Public Whois
See Appendix O.
Registry Fees for Restoring Deleted Names
The maximum registry fee for restoring a deleted name is set forth in Appendix G to the Registry Agreement. The RGP Service fee is separate from, and in addition to, the ordinary charges for registration term extensions.
24 October 2002
19 August 2003
Comments concerning the layout, construction and functionality of this site
should be sent to firstname.lastname@example.org.
Page Updated 27-Aug-2004
© 2004 The Internet Corporation for Assigned Names and Numbers. All rights reserved.