1.1 Term. Names may be registered for a period of no less than one (1) year and no more than ten (10) years, commencing on the date on which the Registry accepts the request for registration submitted by the accredited registrar.
1.2 Names registered in .OOO must have at least 1 character and not more than 63. All 2 character domain names are reserved in accordance with ICANN policy and the terms of its Agreement with ICANN.
1.3 Names registered in .OOO may contain the 26 letters of the Latin alphabet, "a-z", the ten digits, "0-9", a hyphen, "-", and a dot,".". The dot is used exclusively to separate labels. The hyphen may not appear at the beginning or end of a label. A label may not contain more than 63 characters and the total number of characters in a name may not exceed 255 (including a final dot that is not normally displayed as a part of the name).
1.4 Two hyphens may appear in the third and fourth positions in a label in a .OOO name only in accordance with the policies and procedures for Internationalized Domain Names (IDN) referenced below.
1.5 IDNs may be supported in .OOO TLD. IDNs are subject to specific terms and policies set forth by ICANN and/or Registry. The limitations on the length of individual labels and the total length of a name stated in Section 1.2, above, apply to the encoded form ("Punycode") of a name containing characters from the extended range, as further described in the separate IDN documentation.
1.6 For further information on the IDN tables applicable to .OOO please see https://manage.centralnic.com/support/idn_tables. The following IDNs are available under the .OOO domain:
1.6.1 Arabic
1.6.2 Chinese
1.6.3 Cyrillic
1.6.4 French
1.6.5 Greek
1.6.6 Hebrew
1.6.7 Japanese
1.6.8 Korean
1.6.9 Lao
1.6.10 Latin
1.6.11 Myanmar
1.6.12 Polish
1.6.13 Phoenician
1.6.14 Russian
1.6.15 Spanish
1.6.16 Swedish
1.6.17 Thai
1.7 Mixed scripts are not permitted.
1.8 Registry reserves the right to implement additional IDNs in .OOO.
1.9 Dotless domains are not permitted in the TLD. Dotless domain names are those that consist of a single label (e.g., http://example, or mail@example). Dotless names would require the inclusion of, for example, an A, AAAA, or MX, record in the apex of a TLD zone in the DNS (i.e., the record relates to the TLD-string itself).
AGP (AD GRACE PERIOD) LIMITS POLICY.
The Add grace period “AGP” shall be restricted for .OOO in the following manner:
a. During any given month, the oooTLD Administrator shall not offer any refund to an oooTLD- Accredited Registrar (Herein referred to as Registrar”) for any domain names deleted during the AGP that exceed (i) 10% of the Registrars net new registrations (calculated as the total number of net new adds of one year through ten year registrations) in that month, or (ii) Fifty (50) domain names, whichever is greater, unless an exemption has been granted by the oooTLD Administrator.
b. A Registrar may seek an exemption from the .oooTLD Administrator from the application of such restrictions in a specific month, upon the documented showing of extraordinary circumstances. For any Registrar requesting such an exemption, the registrar must confirm in writing to the oooTLD Administrator how, at the time the names were deleted, these extraordinary circumstances were not known, reasonably could not have been known, and were outside the Registrar's control. Acceptance of any exemption will be at the sole and reasonable discretion of the oooTLD Administrator, however “extraordinary circumstances” which reoccur regularly of the same registrar will not be deemed extraordinary.
DEFINATION & REVIEW:This document has been prepared and published to represent our policy regarding the administrative and technical management of the TLD.
We may discontinue or amend any part or the whole of this compliance statement from time to time at our absolute discretion.
ABOUT THIS DOCUMENT:
This document describes our compliance with the Add Grace Period Limits Policy and defines the process by which a Registrar may seek an exemption. And this document provide a public statement by OOO regarding our Intention to comply with the ICANN Add Grace Period Limits Policy.
WHAT IS ADD GRACE PERIOD?
The Add Grace Period is the period following the initial Registration of a domain name, and is intended to allow for the no-cost cancellation of domain name registrations resulting from errors by registrars and registrants.
Details about Infibeam Incorporation Limited Domain Name for the oooTLD can be found in the policy section of the Registry's website ______________________.
In providing an Add Grace Period, ICANN requires that both Infibeam Incorporation Limited in the management of the .OOO and registrars comply with the Add Grace period Limits Policy.
WHY THERE ARE ADD GRACE PERIOD LIMITS?
Add grace period limits were introduced to provide an upper limit on the number of refunds a Registrar can request for domain names created in error. This limit was needed to protect against potential abuse of this functionality.
Where the limit is exceeded, any additional cancellations may not be eligible for a refund.
The limit in the Add Grace Limit Policy is applied on a monthly basis.
EFFECT ON REGISTRARS
Following notice of the effective date of the policy, Registrars processing AGP deletes during the normal course of business will be subject to the policy and will not receive refunds for AGP deletes that exceed the threshold limits set by the policy, unless an exemption has been requested by the Registrar and granted by the operator, Registrar will be obligated to provide information required by the operators in order to have exemption requests considered.
EXEMPTIONS TO THE ADD GRACE PERIOD LIMITS POLICY
In the application of the Add grace period Limit policy we may grant a Registrar an increase to the threshold imposed for a particular month. An increase may be granted where a registrar has applied to us to request such, and many or may not be granted to our sole and reasonable discretion.
The requests for increase must (amongst other things) describe why the surroundings circumstances were not known, or could not have been reasonably known by the Registrar, at the time the domain names were deleted; and how these extraordinary circumstances were outside of the Registrar's control.
EXEMPTION REQUESTS
At the conclusion of any month, a registrar has until the end of the following month to supply a request for exemption. A request must include the following information:
The exemption request must also be accompanied by the relevant fee, if any. Information relating to the particular extraordinary circumstance must be described and provided with supporting documentation. We may from time to time require additional information to process a request for exemption.
RECORD KEEPING AND REPOERTING
We will maintain information regarding an exemption request for a minimum of one year, or longer where required to do so. Where requested we may provide such information to ICANN.
We will also provide in our reporting to ICANN for each registrar:
.OOO provides an abuse point of contact through an e-mail address – oooabuse@infibeam.net . This e-mail address will allow multiple staff members to monitor and address abuse reports. .OOO reserves the right, at its sole discretion and at any time and without limitation, to deny, suspend, cancel, redirect, or transfer any registration or transaction, or place any domainname(s) on registry lock, hold, or similar status as it determines necessary for any of the following reasons:
Abusive use of a domain is described as an illegal, disruptive, malicious, or fraudulent action and includes, without limitation, the following:
In addition, as per our commitment made as part of Specification 11 of our registry agreement, no registrant may use a .ooo domain in a manner that might cause confusion with the Australian Triple Zero Emergency Call Service.
Overview:
In order to meet ICANN’s requirements, the Claims Period will operate at the close of the .OOO Sunrise Period.
Throughout the time when the Claims Period operates, during the process of making an application for a domain name, the applicant will be notified (via a Claims Notice) if the applied for label is a trademark match to a trademark record in the Trademark Clearinghouse. Where that label is allocated, the trademark holder with the corresponding trademark record will be notified of such by the TMCH Sunrise and Claims Operator.
Operation:
The Claims Notice forms part of the process of submitting an application for a domain name, and the applicant for the domain name will be required to acknowledge the information contained within the Claims Notice before processing the application.
The Claims Period will be in effect at minimum during the first ninety (90) calendar days after the commencement of General Availability.
Notice and Duration:
The Registry Operator reserves the right to extend the Claims Period duration and, if appropriate, will post such notice on the Registry Operator’s website.
This Sunrise Dispute Resolution Policy (the “SDRP”) is incorporated by reference into the Registration Agreement. This SDRP is effective as of September 1, 2014. An SDRP Complaint may be filed against a domain name registered during the .OOO TLD sunrise period, until thirty (30) days after the conclusion of the Sunrise Period.
1. Purpose
Domain names in the .OOO TLD (“the TLD”) can be registered by third parties or reserved by the Registry. This SDRP describes the process and standards that will be applied to resolve challenges alleging that a domain name has been registered in violation of the Registry’s SDRP criteria. This SDRP will not be applied to Registry-reserved names in the TLD.2. Applicable Disputes
A registered domain name in the TLD will be subject to an administrative proceeding upon submission of a complaint that the Sunrise Registration was improper under one or more of the following criteria.
a. Improper Sunrise Registration-Trademarks1
A complaint under this section shall be required to show by reasonable evidence that a registered domain name in the TLD does not comply with the provisions of the Registry’s Sunrise Program. The complaint must prove one or more of the following elements:
i. at time the challenged domain name was registered, the registrant did not hold a trademark registration of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty;
ii. the domain name is not identical to the mark on which the registrant based its Sunrise registration;2 or
iii. the trademark registration on which the registrant based its Sunrise registration is not of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty.
b. SDRP Effective Dates.
1. Applicant Guidebook 4 June 2012, Module 5, Page 8, Article 6.2.4. A dispute under this section also addresses the TLD Criteria from ICANN’s Trademark Clearinghouse Rights Protection Mechanism Requirements [published 30 September 2013], Article 2.3.6 and Article 2.3.1.4. The Forum’s SDRP does not interact with (nor instruct) the Trademark Clearinghouse and is limited to adjudicating disputes over the Registry’s registration and allocation of domain names during the sunrise period.
2. For the purposes of analysis of this element, neither the gTLD itself, nor the “dot,” shall be considered.
3. Evidence and Defenses
a. Evidence
Panelists will review the Registry’s Sunrise Criteria, allocation requirements, or community-based eligibility requirements which are required to be submitted with the Complaint, as applicable, in making its decision.
b. Defenses
Harmless error. A Respondent may produce evidence to show that, although the sunrise registration was granted based on submission of the wrong documents, or documents containing an error, the true and correct evidence existed at the time the sunrise registration was applied for and, thus, the registration would have been granted.
4. Remedies
The remedies available to a complainant for a proceeding under this SDRP shall be limited to: Improper Sunrise Registration
If the Panelist finds that the domain name was improperly registered during the Sunrise period, the sole remedy for a Complaint filed under SDRP 2(a) shall be cancellation of the registration and return of the cancelled domain name to the pool of available names available for registration in the TLD. If the Complainant independently qualifies to register the domain name, either as a regular or defensive/blocking registrant, such application may be made to the Registry, or registrar, as applicable.
In the event an SDRP dispute is brought by an auction bidder for the same domain name, the auction will be suspended until the dispute is resolved.
5. Procedure
a. Dispute Resolution Provider / Selection of Procedure A Complaint under this SDRP shall be submitted to the National Arbitration Forum (“Forum”) by submitting the complaint directly to the Forum. The Forum will administer the proceeding and select a qualified and eligible Panelist (“Panelist”). The Forum has established Rules for National Arbitration Forum’s Sunrise Dispute Resolution Policy (“Rules”), setting forth a fee schedule and other technical and process requirements for handling a dispute under this SDRP. The proceedings under this SDRP will be conducted according to this SDRP and the applicable Rules of the Forum.
b. Registry’s or Registrar’s Involvement Neither the Registry nor registrar will participate in the administration or conduct of any proceeding before a Panelist. In any event, neither the Registry nor the registrar is or will be liable as a result of any decisions rendered by the Panelist. Any sunrise-registered domain names in the TLD involved in a SDRP proceeding will be locked against transfer to another domain name holder or another registrar during the course of a proceeding.1 In the case of a claim under SDRP 2(c), the Registry will prevent other parties from registering the unregistered domain name at issue until a decision is reached. The contact details of the holder of a registered domain name in the TLD, against which a complaint has been filed, will be as shown in the registrar’s publicly available Whois database record for the relevant registrant. The Registry and the applicable registrar will comply with any Panelist decision and make all appropriate changes to the status of the domain name registration(s) in their Whois databases.
c. Parties The registrant of a registered domain name in the TLD shall be promptly notified by the Forum of the commencement of a dispute under this SDRP, and may contest the allegations of the complaint or show other cause why the remedy requested in the complaint should not be granted in accordance with this SDRP. In all cases, the burden of proof shall be on the complainant, and default or other failure of the holder of the registered domain name shall not constitute an admission to any allegation of the complaint. The Forum shall promptly notify all named parties in the dispute, as well as the registrar and the Registry of any decision made by a Panelist.
d. Decisions
(i) The Panelist may state the basis on which the decision is issued in summary format and may include such commentary or guidance as the Panelist deems appropriate;
(ii) the decision shall state whether a registered domain name in the TLD is to be cancelled or the status quo maintained; and
(iii) decisions made under this SDRP will be publicly published by the Forum on its website.
e. Implementation of a Lock and the Decision If a Panelist’s decision requires a change to the status of a registered domain name, the Registry1 will wait ten (10) business days after communication of the decision before implementing that decision, unless the registrant submits to the Registry (with a copy to the Forum) during that ten (10) day period official documentation (such as a copy of a complaint, file-stamped by the clerk of the court) that the registrant has commenced a lawsuit to preserve its claimed rights in a court of competent jurisdiction over the parties and the registered domain name. If such documentation is received no further action shall be taken until the Registry
3. A Registry may, though its agreement with registrars, instead require the registrar to perform the lock and/or implementation steps.
4. A Registry may, though its agreement with registrars, instead require the registrar to perform the lock and implementation steps.
receives (i) evidence satisfactory to the Registry of an agreed resolution between the parties; (ii) evidence satisfactory to Registry that registrant’s lawsuit has been dismissed or withdrawn; or (iii) a copy of an order from such court dismissing such lawsuit or otherwise directing disposition of the registered domain name.
f. Representations and Warranties Parties to a dispute under this SDRP shall warrant that all factual allegations made in the course thereof are true and correct to the best of their knowledge, shall remain subject to all representations and warranties made in the course of registration of a disputed domain name.
6. Maintaining the Status Quo
During a proceeding under the SDRP, the registered domain name shall be locked against transfers between registrants and/or registrars and against deletion by registrants.
7. Indemnification / Hold Harmless
The parties shall hold the registrar, the Registry, the Forum, and the Panelist harmless from any claim arising from operation of the SDRP. Neither party may name the registrar, the Registry, the Forum, or the Panelist as a party or otherwise include the registrar, the Registry, the Forum, or the Panelist in any judicial proceeding relating to the dispute or the administration of the SDRP policy. The parties shall indemnify, defend and hold harmless the registrar, the Registry, the Forum, the Panelist and their respective employees, contractors, agents and service providers from any claim arising from the conduct or result of a proceeding under this SDRP. Neither the registrar, the Registry, Forum, the Panelist and their respective employees, contractors, agents and service providers shall be liable to a party for any act or omission in connection with any administrative proceeding under this SDRP or the corresponding Rules. The complainant shall be directly and solely liable to the registrant in the event the complaint is granted in circumstances where the registrant is lawfully entitled to registration and use of the registered domain name(s) in the TLD.
8. Relation To Other Dispute Resolution Policies
This SDRP is in addition to and complementary with the Uniform Domain Name Dispute Resolution Policy ("UDRP"), the Uniform Rapid Suspension System ("URS") and any charter, nexus, or eligibility dispute policies adopted by ICANN or the Registry.
9. Effect of Other Proceedings
The administrative proceeding under the SDRP shall not prevent either party from submitting a dispute concerning the registered domain name in the TLD to concurrent administrative proceedings or to a court of competent jurisdiction for independent resolution during a pending SDRP administrative proceeding or after such proceeding is concluded. Upon notice of such other proceeding, the SDRP proceeding may be terminated (in the sole discretion of the Panelist) in deference to the outcome of such other proceeding.
10. SDRP Modifications
The Registry reserves the right to modify this SDRP at any time subject to the terms of its MoU with the Forum. Such revised SDRP shall be posted on the Forum Website at least thirty (30) calendar days before it becomes effective;1 unless this SDRP has already been invoked by the submission of a complaint, in which event the version of the SDRP in effect at the time it was invoked will apply until the dispute is concluded. In the event that registrant objects to a change in this SDRP, the sole remedy is to cancel the registration, provided that registrant will not be entitled to a refund of any fees paid in connection with such registration.
Details about ICANN’s requirements for Rights Protection Mechanisms can be found on the ICANN website at http://newgtlds.icann.org/en/about/trademarkclearinghouse.
Rights Protection Mechanisms and the Trademark Clearinghouse
ICANN has established the Trademark Clearinghouse and associated processes and procedures so that the Registry Operator can comply with its obligation to implement Rights Protection Mechanisms.
ICANN has appointed providers, the TMCH Sunrise and Claims Operator(s), to operate the Trademark Clearinghouse. Registry Operator's implementation of the Service has been integrated and tested by Verisign (the Back-end Registry Operator) with the TMCH Sunrise and Claims Operator. Information about the Trademark Clearinghouse and the TMCH Sunrise and Claims Operator can be found at http://trademark-clearinghouse.com/.
Where applicable the Registry Operator's role is to compare the information provided by a Registrar to the Registry Operator, with that information that is contained in the Trademark Clearinghouse. The Registry Operator does not make any decisions about the validity or use of a mark or its inclusion in the Trademark Clearinghouse.
Sunrise Policy: 30 Day Start Date Sunrise
Scope and Timing:
Registry Operator will offer a thirty (30) day Start Date Sunrise Period, specifically in relation to Rights Protection Mechanisms. The Sunrise Period allows trademark holders the ability to secure their trademarks in the .OOO TLD prior to General Availability, when domain names may be registered by the general public. During the Sunrise Period, only SMD File holders (or their agents) are allowed to submit Sunrise Application(s). Successful Sunrise Registration(s) will be allocated to trademark holders on a first come, first served basis.
During the Sunrise, the following applies:
Available Sunrise Registration Periods:
Sunrise Period Registrations may be purchased in yearly increments of no less than one (1) year and no more than ten (10) years, commencing on the date on which the Domain Name is registered. Unless otherwise terminated, such registration will expire on the same day of the month the registration was created.
Eligible Applicants:
Each applicant must meet the qualifications specified by ICANN requirements and detailed in the TMCH
Guidelines, as they may change from time to time.
SMD File Requirements:
The Applicant must first provide information required by the TMCH to obtain the SMD File as detailed in Sections 2 and 3 of the TMCH Guidelines. The TMCH then will issue an SMD File to verified applicants.
The Sunrise Applicant must submit a valid SMD File along with its Sunrise Application. The Registry Operator will perform verification of the SMD File and confirm that the applied for Label is contained in the SMD File. Where verification of the SMD File fails or the applied for Label is not contained in the SMD File, that Application will be rejected.
Allocation:
Unless otherwise stated in this Overview, the Registry Operator, via the Registry Service Provider, will allocate a Domain Name if:
Domain Name Label Requirements:
Registry Operator, via Registry Service Provider, will not accept a Sunrise Application unless the applied for Domain Name meets the applicable requirements as defined in RFC 1035 and RFC 1123, including the following technical and syntax requirements.
The Domain Name Label must:
The Registry's Rights:
The Registry Operator shall be entitled, but not obligated, to reject a Sunrise Application or to delete, revoke, cancel, suspend or transfer a Sunrise Registration:
Access to WHOIS information is provided to assist persons in determining the contents of a domain name registration record in the TLD database. The data in this record is provided by Infibeam Incorporation Limited (Infibeam) for informational purposes only, and Infibeam does not guarantee its accuracy. This service is intended only for query-based access.
You agree that you will use this data only for lawful purposes and that, under no circumstances will you use this data to:
All rights reserved.
Infibeam reserves the right to modify these terms at any time.
By submitting a query, you agree to abide by this policy.
https://whois.icann.org/en/about-whois