Source: https://gtldresult.icann.org/applicationstatus/applicationchangehistory:downloadtodocument/4434?t:ac=187
Timestamp: 2017-10-23 06:16:54
Document Index: 94199430

Matched Legal Cases: ['§33', '§34', '§2', '§27', '§28', '§2', '§2', '§2', '§3', '§43']

New gTLD Application Submitted to ICANN by: Ooredoo
Application Downloaded On: 16 Jan 2015
String: كيوتل
Ooredoo Tower, 100 West Bay PO Box 217 Doha - NA QA
+974 4440 0400
+974 4447 6231
+44 7540 723 115
tas-qtel-idn-primary@centralnic.com
Senior Director, Technology Services
+974 4440 0776
+974 4483 0407
tas-qtel-idn-secondary@centralnic.com
Ooredoo was established by Law 21 of 1998 and Articles of Association (see attached)
Doha Securities Market / ORDS Qatar Exchange / ORDS
H.E. Mohammed Bin Isa Al Mouhanadi Director
H.E. Sheikh Abdullah Bin Monammed Bin Saud Al Thani Chairman of the Board
Mr. Ali Sharif Al Emadi Director
Mr. Aziz Ahmad Al-Othman Director
Mr. Hamad Abdullah Al Shamsi Director
Mr. Hamad Saeed Al Badi Director
Mr. Hareb Masoud Al Darmaki Director
Mr. Nasser Rashid Al Humaidi Director
Mr. Tami Hajar Al Benali Director
Mr. Turki Bin Mohammed Al Khater Director
Abdullatif Hamad Dafallah Chief Financial Officer
Bjorn Johan Lundstrom Chief Technology Officer
Izzeldin Hamed Mohamed Salih Hussein Chief Legal and Regulatory Officer
Saoud Nasser F.N. Al Thani Chief Executive Officer
Waleed Mohammed Al Sayed Chief Operating Officer
xn--pgb3ceoj
كيوتل is the brand name of Applicant, the primary telecommunications provider in Qatar. The designation is used throughout the country in relation to the services of the Applicant.
U+0643 U+064A U+0648 U+062A U+0644
The proposed IDN character table for the Arabic language was compiled based on the recommendations given in RFC 5564 ʺLinguistic Guidelines for the Use of the Arabic Language in Internet Domainsʺ. Besides, applicant examined the IDN character tables adopted by the local IDN ccTLD registries (UAE, Qatar). The character repertoire provided in the proposed character table agrees with all the three sources above. Applicant also consulted with Dr. Sarmad Hussain who is one of the leading specialists in Arabic script IDNs and incorporated his input into the proposed character table.
No variant labels are declared for the TLD.
The string ʺ.كيوتلʺ is an Internationalized Domain Name (IDN) label that according to the IDNA standards has two forms. The A-label form ʺ.xn--pgb3ceojʺ consists exclusively of ASCII characters and does not appear to present any rendering problems whatsoever.
The U-label form ʺ.كيوتلʺ consists of Arabic language characters and is supposed to be primarily used in Arabic language environment. According to the applicable standards this string is classified as having a right-to-left (RTL) display order.
As demonstrated below, the Applicant has made a comprehensive review of sources of information regarding rendering issues, and is taking the steps outlined below to mitigate those issues.
16.1. Mixed context rendering
While use of the string in a fully RTL context does not pose any rendering problems, certain complexities may arise when the string is rendered in a mixed environment that uses both RTL and LTR display order.
To address these complexities Applicant will adhere to the recommendations given in RFC 5893. In particular, application of the Bidi rule (para. 2 of RFC 5893) results in the following additional constraints that the Registry will enforce for second level domain registrations:
1.Labels must start with an Arabic letter.
2.If Arabic numbers are present in the label, no European numbers may be present, and vice versa.
Bidi rule guarantees that different strings will not be rendered in the same way regardless of the display order of the characters that constitute the string and the display order of the context in which the string appears.
Applicant will limit the registrations in the TLD exclusively to IDNs with RTL display order. Therefore, at least with regards to second-level domain names under the TLD no mixed context rendering issues will occur.
16.2. TLD string rendering by the browsers
Different browser engines use different approaches to decide whether the domain name part of an IDN-based URL should be rendered in its U-label form or in its A-label form.
Some browsers, such as Mozilla, maintain a white list of IDN-enabled TLDs, giving certain level of control over the rendering mechanism to the Registry Operator. Including a TLD as a entry in the white list triggers rendering the domain name in the address bar in its U-label form rather then in the A-label form. Applicant will work with Mozilla to ensure the TLD is white-listed for Mozilla browsers.
Besides, we will address the browser-related rendering issues in several other ways.
Where browsers are found to incorrectly render Arabic language TLDs we will report this to the browser manufacturers and ask them to update the view for IDNs
We will provide a list of “preferred browsers” on our website for the viewers for consistent viewing.
We will support initiatives of ICANN and other industry bodies to address the issue of Universal Acceptance of IDN TLDs and contribute where possible.
Ooredoo has chosen to apply for the TLD to promote awareness of its services and products and facilitate the digital growth and physical expansion of the Ooredoo brand. The TLD will control and protect the Ooredoo brand by providing an official digital hub for consumers in the Arabic language as well as foster consumer trust by creating a secure and technically stable zone that is easily understandable and navigable for Arabic language internet users. Ooredoo’s goal is to be among the top 20 telecommunications companies in the world by 2020, and it actively pursues a program of expansion and consolidation to bring improved service and choice to customers across the Middle East, North Africa, the Indian subcontinent, and South East Asia. The deployment of the TLD across this region as the Ooredoo brand expands will therefore contribute to ICANNʹs commitment to innovation, consumer protection, security, and stability across new markets while simultaneously contribute to ICANN’s goal of increased use of IDNs at the Top and Second Level.
Headquartered in Doha, Qatar, Ooredoo currently has a presence in 17 countries (Qatar, the United Arab Emirates, Saudi Arabia, Jordan, Palestine, Iraq, Oman, Algeria, Tunisia, Kuwait, Pakistan, the Maldives, Cambodia, Laos, Singapore, the Philippines, and Indonesia) and has a customer base in excess of 83 million. Ooredoo has a strong vision and strategy to offer consumer mobile, broadband, and corporate managed services to customers across its coverage area. The company actively seeks entry in developing or emerging markets, bringing a level of service and previously unknown product offerings to consumers. In this regard, Ooredoo’s expansion program directly mirrors ICANN’s commitment to the extension of choice and the promotion of secure and stable technology across new and emerging markets.
Ooredoo was incorporated in 1987 and listed on the Qatar Exchange in 1998. The Qatari government provides direct and indirect strategic backing, fuelling the growth and expansion of the company. Within Qatar, Ooredoo is a full service telecommunications provider offering a suite of mobile, fixed line, broadband, and digital entertainment (television) services. The Qatar operation has 2,000 employees and is one of the largest publicly traded companies in the country, with listings in several other international exchanges (including the London Stock Exchange or LSE).
Ooredoo is a multi-award winning organization, and it has received recognition and accolades from industry organizations and counterparts in every field – from the business as a whole (Best Telecom Deal, Best Company for Investor Relations in Qatar, Telecommunications Company of the Year) to innovation in products and services (Best Brand award for the Nojoom Loyalty Program). Ooredoo has won the Gulf Excellence Award (2005) and the GCC Economic Award (2006) among others.
Ooredoo shares ICANNʹs commitment to consumer empowerment, innovation, and competition. One noted example is the company’s significant investment in next generation digital media and entertainment services and best in value-added telecommunications services which are at the forefront of developing Qatar’s knowledge-based economy. Ooredoo has additionally introduced next generation services such as LTE, WiMAX, and fibre optic (high speed internet) connections across Qatar and in various emerging markets. It also launched many innovative services designed to improve customer experience, including “Backstage” (a music download service for mobile phones and PCs that gives music fans unlimited access to their favourite music in Qatar and other markets across the Ooredoo Group), Instant Top-Up, Skype, and Twitter Mobile across the MENA region.
In addition to its commitment to technology and its consumers, Ooredoo takes its mission of corporate social responsibility very seriously. Ooredoo’s “Triple P” approach – whereby People and the Planet are as highly valued as Profit – ensures that the company provides material and social support for community groups and charities as well as promotes environmental causes. Ooredoo actively engages in projects promoting education, healthcare, the environment, social welfare, and sport within Qatar and across the company’s markets in an ongoing mission to help enhance all aspects of society. Innovative initiatives such as the e-Waste Recycling Program and charity auctions of “easy-to-remember” mobile numbers visibly demonstrate Ooredoo’s commitment to people and the planet. Ooredoo was presented with the Corporate Social Responsibility Award at the CEO Middle East Awards (2009 and 2011) in recognition of its efforts toward continued support of CSR activity in Qatar and the extension of CSR strategy into international markets.
The TLD will provide a digital home for information about all the previously-mentioned services in the Arabic language as well as facilitate the future expansion of Ooredoo’s web and market presence. The Ooredoo Group strategy focuses on customer experience, broadband, and new growth opportunities, and its corporate mission requires it to actively expand, bringing unprecedented service levels and innovation to new consumers. The launch of the TLD falls squarely within this mission and will allow Ooredoo to achieve its goals of innovation, outreach, growth, and learning while reinforcing its credibility and reputation for technical stability, security, and excellence. Additionally, the deployment of the Arabic language TLD will not only empower Arabic-speaking internet users but also contribute to ICANNʹs goals of increasing usage and utility of IDN TLDs.
Ooredoo will retain domains for internal use, educating consumers about the Ooredoo brand as it expands globally. As new companies across Ooredoo’s target region join the Ooredoo Group, their digital presence and internet addresses will be absorbed into the TLD – ensuring not only the promotion of the Ooredoo brand in the Arabic language but also the effective organization of the Group’s domain name structure and the technical security and stability of its internet presence. The TLD will allow Ooredoo to continue innovating and bringing new products to an emerging consumer base without compromise and achieve its corporate goals of increasing productivity, standing out from the competition, growing B2B and IT services, and exploring new opportunities such as TV, finance, and health. Additionally, the deployment of the Arabic language TLD will not only empower Arabic-speaking internet users but also contribute to ICANNʹs goals of increasing usage and utility of IDN TLDs.
i. The TLD has been specifically designed to meet Ooredoo’s requirements and facilitate its corporate mission. Mirroring ICANNʹs own goals of promoting consumer protection, security, stability, innovation, and rights protection, Ooredoo’s application for and desire to operate the TLD affirms its commitment to these areas and will ensure their execution. The domain will allow authorized parties within Ooredoo to register the shortest, most intuitive, and most descriptive domain names possible in the Arabic language without having to change scripts and keyboards. Various business units under the Ooredoo corporate aegis will have access to the most efficient web and email addresses and be united under the Ooredoo brand umbrella. Consumers will be aware that corporate communications and websites are authorized by Ooredoo - promoting their confidence in the brand and their protection from potentially harmful third parties.
ii. The TLD will be the first Arabic language TLD specifically designed to serve the needs of Ooredoo’s Arabic-language brand and business consumers - allowing all to grow and prosper unhindered in the digital landscape without compromising on language. It will provide ICANN-mandated levels of technical service and serve as a platform for the expansion of Ooredoo’s services and product offerings as previously described.
Additionally, the TLD will promote ICANN’s goals of promoting competition, consumer trust, consumer choice, security, and rights protection by:
diversifying the ownership and control of gTLD registries
introducing a gTLD registry owned and operated in the Middle East (an unprecedented evolution)
introducing a gTLD registry with operations in a number of territories where the domain industry is heretofore undeveloped
providing a zone where the significant number of brand users and affiliates can receive accurate information about Ooredoo and its product offerings and services
operating at the levels of technical security and stability required by ICANNʹs new gTLD program
protecting Ooredoo as a rights holder, creating a dedicated zone wherein complete brand protection and control is guaranteed
introducing more Arabic language into the Domain Name System both at the top and second levels
iii. The TLD will allow web users to easily identify the Ooredoo brand in the Arabic language – unimpeded by artificial boundaries (such as generic or ccTLD endings) and linguistic compromise and secure in the knowledge that the communications and information uncompromisingly originate directly from Ooredoo. The TLD will assist with the dissemination of information about Ooredoo product offerings, allowing internet users to become more familiar with the services offered and the various business units within the Ooredoo brand universe in the Arabic language. It will be a trusted zone functioning at the highest standards of technical and operational utility and security and will assist in the promotion and adoption of IDN TLDs worldwide (a key goal of ICANN’s new gTLD program), providing the next billion users web access entirely in their native language.
iv. The TLD is open to Arabic-language registrations by authorized parties and business units within the Ooredoo Group. Although individual business units within the Ooredoo Group may wish to adopt their own strategies corresponding specifically with their unique requirements or market preferences, the common denominator will be employing the TLD to unite Ooredoo Group sites and services under an uncompromised, secure, stable, and innovative digital hub. The marketing and branding activities undertaken by Ooredoo Group internationally will reinforce this goal. As further detailed in the responses to questions 28 and 29, Ooredoo will implement all rights protection mechanisms required by ICANN (including but not limited to the URS and the UDRP) and will additionally operate a Sunrise period for Trademark holders prior to General Availability (again, in accordance with all ICANN rules).
A copy of the intended registration policy can be found in response to question 29.
v. Ooredoo in its capacity as a TLD registry operator will not be providing any special services for protecting the privacy or confidential information of registrants or end-users apart from those required by applicable laws, policies, agreements or technical standards. Some registry services intrinsically support the protection of usersʹ confidential information. Examples of such services are:
SRS (protecting confidentiality of the EPP transfer authorisation codes)
Dissemination of TLD zone files (protecting confidentiality of zone file FTP accounts credentials)
All registry services, including those described above, will be provided in accordance with the ICANN requirements and specifications to the Registry Agreement. The data security measures adopted by Ooredoo are described in detail in the answer to question 30 ʺSecurity Policyʺ.
vi. Ooredoo will incorporate the use of the TLD in its existing Arabic-language marketing campaigns and materials in order to encourage user understanding, protection, and uptake. These communications and outreach efforts will ensure Arabic-language internet users, Ooredoo customers, and the wider public are aware that the information disseminated on the TLD will provide content directly originating from Ooredoo.
The TLD has been designed to provide a trusted zone free from security breaches and technical problems. The extensive security measures embedded into the heart of the zone ensure the minimization of social costs and negative consumer consequences.
i. Ooredoo has taken great care to develop the most fair registration policy possible. It will offer a phased launch consistent with ICANN requirements to ensure the protection of Trademark holders and the satisfaction of potential registrants. Phase 1 will be the ICANN-mandated Sunrise period open to TM holders eligible for registering domains in the TLD. The Sunrise rules and regulations are described in full in section 29.
The Sunrise phase will be followed by General Availability, during which time domain names will be become available for eligible entities on a first-come, first-served basis (the limited initial pool of authorized registrants negates the possibility of any registration collisions). All domain name registrations in the TLD will be registered to and maintained by the Registry Operator for its own and its affiliates’ exclusive use within the first three years of delegation.
Depending on various factors including the up-take and usage of new TLDs, Ooredoo may extend the client base in the future, though in not less than three years from delegation. The initially proposed Eligibility Policy provides for such expansion, and amendments to the Eligibility Policy to make it less restrictive are also feasible.
Any significant expansion of the potential registrant base will be prepended by an intermediate Sunrise period to allow new entrants to register their trademarks as domains under the TLD. Standard first-come, first-served policy will take over thereafter. The Applicant firmly believes this tiered policy will satisfy all potential registrants both now and in the future.
ii. Ooredoo will not implement any promotions or registrant discounts.
iii. Domain names will be available for registration on a one-year to ten-year basis in compliance with ICANN requirements. Interim takedowns of non-compliant domains are possible to protect the integrity of the zone.
At this time Ooredoo does not foresee a need to increase the registry fees, but the registry will certainly give ample notice of any change in fees as required by the Registry Agreement and ICANN regulations.
-the short form (in English) of all country and territory names contained on the ISO 3166-1 list;
-the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names;
1.Registry Grace Period Mapping - compliant with RFC 3915
2.DNSSEC Security Extensions - compliant with RFC 5910
3.Launch Phase Extension - will be only active during the Sunrise phase, before the SRS opens for the general public. The extension is compliant with the current Internet Draft https:⁄⁄github.com⁄wil⁄EPP-Launch-Phase-Extension-Specification⁄blob⁄master⁄draft-tan-epp-launchphase.txt
1.Planned and unplanned maintenance;
2.Denial-of-service attacks;
3.unplanned network outages;
4.delays in publication of DNS zone updates;
5.security incidents such as attempted or successful breaches of access controls;
6.significant changes in DNS server behaviour or features;
7.DNSSEC key rollovers.
Senior Operations Engineer(s)
Operations Engineer(s)
Senior Technical Developer x 2
Technical Developer x 3
Support Agent(s)
Since the optimistic projection for the number of domains registered in the TLD after three years is 1,000, the TLD will therefore require 0.1% of CentralNicʹs total available HR resources in order operate fully and correctly. In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of the TLD are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of the TLD for at least the first 18 months of operation.
The load balancers pass sessions to the EPP protocol servers. Load is distributed using a weighted-least-connections algorithm. The protocol servers run the Apache web server with the mod_epp and mod_proxy_balancer modules. These servers process session commands (ʺhelloʺ, “login” and “logout”) and function as reverse proxies for query and transform commands, converting them into plain HTTP requests which are then distributed to the application servers. EPP commands are distributed using a weighted-least-connections algorithm.
1.24x7x365 monitoring provides reports of incidents to NOC
2.Quarterly review of capacity, performance and reliability
3.Monthly reviews of uptime, latency and bandwidth consumption
4.Hardware depreciation schedules
5.Unit testing framework
6.Frequent reviews by QA working group
7.Schema validation and similar technologies to monitor compliance on a real-time, ongoing basis
8.Revision control software with online annotation and change logs
9.Bug Tracking system to which all employees have access
10.Code Review Policy in place to enforce peer review of all changes to core code prior to deployment
11.Software incorporates built-in error reporting mechanisms to detect flaws and report to Operations team
12.Four stage deployment strategy: development environment, staging for internal testing, OT&E deployment for registrar testing, then finally production deployment
13.Evidence-based project scheduling
14.Specification development and revision
15.Weekly milestones for developers
16.Gantt charts and critical path analysis for project planning
1.Normal: general enquiry, usage question, or feature enhancement request. Handled by 1st level support.
2.Elevated: issue with a non-critical feature for which a work-around may or may not exist. Handled by 1st level support.
3.Severe: serious issue with a primary feature necessary for daily operations for which no work-around has been discovered and which completely prevents the feature from being used. Handled by 2nd level support.
4.￼Critical: ￼A major production system is down or severely impacted. These issues are catastrophic outages that affect the overall Registry System operations. Handled by 3rd level support.
1.replication of data between active and standby servers (see §33). CentralNic implements redundancy in its database system by means of an active⁄standby database cluster. The database system used by CentralNic supports native real-time replication of data allowing operation of a reliable hot standby server. Automated heartbeat monitoring and failover is implemented to ensure continued access to the database following a failure of the primary database system.
2.replication is used to synchronise the primary operations centre with the Disaster Recovery site hosted in the Isle of Man (see §34). Database updates are replicated to the DR site in real-time via a secured VPN, providing a ʺhotʺ backup site which can be used to provide registry services in the event of a failure at the primary site.
CentralNicʹs resourcing model assumes that the ʺdedicatedʺ resourcing required for the TLD (ie, that required to deal with issues related specifically to the TLD and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that the TLD will use. After three years of operation, the optimistic projection for the TLD states that there will be 1,000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names. Therefore the TLD will require 0.1% of the total resources available for this area of the registry system.
“hello” - retrieve the “greeting” from the server
“login” and “logout” - session management
“poll” - message queue management
“check” - availability check
“info” - object information
“create” - create object
“update” - update object
“renew” - renew object
“delete” - delete object
“transfer” - manage object transfer
1.domains must comply with the syntax described in RFC 1035 §2.3.1. Additionally, the first label of the name must be between 3 and 63 characters in length.
2.domains must have a registrant attribute which is associated with a contact object in the database.
3.domains must have an administrative contact attribute which is associated with a contact object in the database.
4.domains must have a technical contact which attribute is associated with a contact object in the database.
5.domains may have an billing contact attribute which is associated with a contact object in the database.
6.domains may have between 0 (zero) and 13 DNS servers. A domain with no name servers will not resolve and no records will be published in the DNS
7.the host object model for domains is used rather than the host attribute model.
8.domains may have a number of status codes. The presence of certain status codes indicates the domainʹs position in the lifecycle, described further in §27.
9.where policy requires, the server may respond to a “domain:create” command with an ʺObject Pendingʺ (1001) response. When this occurs, the domain is placed onto the pendingCreate status while an out-of-band validation process takes place.
10.when registered, the expiry date of a domain may be set up to ten years from the initial date of registration. Registrars can specify registration periods in one-year increments from one to ten.
11.when renewed, the expiry date of a domain may be set up to ten years from the current expiry date. Registrars can specify renewal periods in one-year increments from one to ten. domains which auto-renew are renewed for one year at a time.
12.domains must have an authInfo code which is used to authenticate inter-registrar transfer requests. This authInfo code may contain up to 48 bytes of UTF-8 character data.
13.domains may have one or more DS records associated with them. DS records are managed via the secDNS EPP extension, as specified in RFC 5910.
14.only the sponsoring registrar of the domain may submit “update”, “renew” or “delete” commands for the domain.
1.host names must comply with RFC 1035. The maximum length of the host name may not exceed 255 characters.
2.in-bailiwick hosts must have an IPv4 address. They may optionally have an IPv6 address.
3.multiple IP addresses are not currently permitted.
4.sponsorship of hosts is determined as follows: if an object is in-bailwick (ie child of a domain in the database, and therefore also child to a TLD in the system), then the sponsor is the sponsor of the parent domain. If the object is out-of-bailiwick, the sponsor is the registrar which created the contact.
5.if a registrar submits a change to the name of a host object, if the new host name is subordinate to an in-bailiwick domain, then that registrar must be the sponsor of the new parent domain.
6.registrars are not permitted to create hosts that are subordinate to a non-existent in-bailiwick domain, or to change the name of a host object so that it us subordinate to a non-existent in-bailiwick domain.
7.a host cannot be deleted if one or more domains are delegated to it (the registry deletes hosts to remove orphan glue, see §28).
8.inter-registrar transfers are not permitted.
9.only the sponsoring registrar of the host may submit “update” or “delete” commands for the object.
1.contact IDs may only contain characters from the set [A-Z, 0-9, . (period), - (hyphen) and - (underscore)] and are case-insensitive.
2.phone numbers and email addresses must be valid as described in RFC 5733 §2.5 and §2.6.
3.contact information is accepted and stored in ʺinternationalizedʺ format only: that is, contact objects only have a single “contact:postalInfo” element and the type attribute is always ʺintʺ.
4.the “contact:org”, “contact:sp”, “contact:pc”, “contact:phone” and “contact:fax” elements are optional.
5.contacts must have an authInfo code which is used in inter-registrar transfers. This code may contain up to 48 bytes of UTF-8 character data.
6.a contact cannot be deleted if one or more domains are associated with it.
7.only the sponsoring registrar of the contact may submit “update” or “delete” commands for the object.
CentralNic supports the specification defined in RFC 5910. This supports two interfaces: the DS Data Interface and Key Data Interface. CentralNic supports the former interface (DS Data), where registrars submit the keytag, algorithm, digest type and digest for DS records as XML elements, rather than as key data. Key data is stored if provided as a child element of the “secDNS:dsData” element. The maxSigLife element is optional in the specification and is not currently supported.
All ʺtransformʺ commands are logged. Transform commands are: “create”, “renew”, “update”, “delete” and “transfer”. The system logs the time and date when the command was received, the registrar which submitted it, the request and response frames, the result code and message. All commands, whether successful or not, are logged.
Query commands (“check”, “info”, “poll op=ʺreqʺ“) and session commands (“login”, “logout” and “hello”) are not logged due to the large volume of such queries (particularly “check” queries). The EPP system uses counters for these commands to facilitate generation of monthly reports.
approved or rejected domain registration request (where TLD policy requires out-of-band approval of “domain:create” requests)
1.Developers maintain their own development environment in which new code is written and changes are prepared. Development environments are configured with the highest level of debugging and strictness to provide early detection of faults.
2.All changes to the EPP system are subjected to peer review: other developers in the team must review, test and sign off the changes before being committed (or, if developed on a branch, being merged into the stable branch).
3.Changes to EPP system code are then deployed in the OT&E environment. Registrars continually test this system as part of their own QA processes, and this additional phase provides an additional level of quality assurance.
The Whois service will additionally comply with all requisite data protection laws (with regards to the collection and retention of personal data), including all relevant European Union privacy directives.
An example of a domain whois response is included in Appendix 26.1. The Domain ROID is the Repository Object Identifier as described in RFC 5730, §2.8. The ROID field corresponds to the “domain:roid” element of EPP “info” responses.
PENDING CREATE - a “domain:create” command has been received through the SRS, but the registration has not yet been finalised as an out-of-band review process has not yet been completed.
Users can query for information about a contact by submitting a query of the form ʺcontact [ID]ʺ, where ʺ[ID]ʺ is the contact ID equivalent to the “contact:id” element in EPP “info” responses. This is also the ID used when referring to contacts in domain responses.
The domain is not registered. No delegation (or any other records) exist in the DNS, and the whois system will return a ʺNOT FOUNDʺ response to queries. An EPP “check” command will return an ʺavailʺ status of 1.
A registar submits an EPP “create” command or registers the domain name via the Registrar Console. The registration fee is deducted from the registrarʹs balance. The initial registration period may be any whole number of years between one (1) and ten (10).
While the domain is registered, it is delegated to the specified name servers and will resolve normally. During this time, the registrar may update the domain nameʹs DNS settings, lock statuses and contact associations, and may extend the registration period (subject to a maximum of ten (10) years) by submitting a “renew” EPP command or using the Registrar Console.
The Renew Grace Period is the five (5) calendar days following the renewal of the domain via an EPP “renew” command, or via the Registrar Console.
This status may be set by registrars using an EPP “update” command, or via the Registrar Console. Domains with this status are removed from the DNS and will not resolve.
This status may be set by registrars using an EPP “update” command, or via the Registrar Console. When set, all attempts by the registrar to delete the domain using an EPP “delete” command will be refused with EPP response code 2304 (Status Prohibits Operation). Registrars must remove the code using an EPP “update” command before they can delete the domain.
This status may be set by registrars using an EPP “update” command, or via the Registrar Console. When set, all attempts by the registrar to renew the domain using an EPP “renew” command will be refused with EPP response code 2304 (Status Prohibits Operation). Registrars must remove the code using an EPP “update” command before they can renew the domain.
This status may be set by registrars using an EPP “update” command, or via the Registrar Console. When set, all attempts by the registrar to update the domain using an EPP “update” command will be refused with EPP response code 2304 (Status Prohibits Operation), unless the “update” request frame includes a “rem” element to remove this status. Once the status has been removed, subsequent “update” commands will succeed.
This status may be set by registrars using an EPP “update” command, or via the Registrar Console. When set, all attempts by other registrars to submit a transfer request for the the domain using an EPP “transfer” command, or via the Registrar Console, will be refused with EPP response code 2304 (Status Prohibits Operation). The sponsoring registrar must remove this status before any other registrar can submit a transfer request.
This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to delete the domain using an EPP “delete” command will be refused with EPP response code 2304 (Status Prohibits Operation).
This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to update the domain using an EPP “update” command will be refused with EPP response code 2304 (Status Prohibits Operation).
This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to renew the domain using an EPP “renew” command will be refused with EPP response code 2304 (Status Prohibits Operation).
This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to transfer the domain using an EPP “transfer” command will be refused with EPP response code 2304 (Status Prohibits Operation).
The Registry system supports the ʺpendingCreateʺ status for domain names, as described in RFC 5731, §3.3. Domains in this state are fully registered in the database (subsequent “create” commands would fail with an Object Exists error) but are not present in the DNS.
-The e-mail account is continuously monitored and all communication securely stored
-The telephone number is either answered by a live person or diverted to a monitored voicemail account.
-Abuse contact information will be kept current and will be updated should it ever change in a timely manner
-Distribution of illegal content
-Botnetting
-Unauthorized access to information systems
-Threats to the security and⁄or stability of the TLD
The .كيوتل Acceptable Use Policy will be incorporated into the Registry-Registrar agreements and Registrars will be required to pass through the requirements to comply with the policy to the registrants.
CentralNic has significant experience in the domain registry business, and is an industry leader with respect to its anti-abuse policies. CentralNic has a dedicated Dispute Resolution Policy in place with WIPO, found at WIPO’s website: http:⁄⁄www.wipo.int⁄amc⁄en⁄domains⁄gtld⁄cnic⁄index.html. This policy mirrors the UDRP policy for new gTLDs and, as a result, CentralNic already has real-time experience working with WIPO to implement and execute a similar policy. CentralNic has trained personnel who handle interaction with WIPO, to ensure that panelists’ decisions are carried out expeditiously as required by the DRP.
Firstly, the Shared Registry System will reject any request to create host object that is the child of a non-existent domain name. That is, if EXAMPLE.كيوتل does not exist, then NS0.EXAMPLE.كيوتل cannot be created. If the parent domain name does exist, then only the sponsoring registrar of that domain is permitted to create child host objects.
In addition to the standard measures described above, the .كيوتل WHOIS system will feature extra levels of reliability with regards to Whois information.
Verify syntactic correctness of email addresses and phone numbers by validating them against the corresponding standards
Verify that the domain holder receives email at the addresses listed in WHOIS as registrant’s email address and administrative contact email address, by requiring them to click a unique web link that is sent to those addresses.
Applicant will periodically (at least once every 12 months) perform a random check of WHOIS records in the TLD for prima facie evidence of fraudulent or inaccurate WHOIS information. For those suspicious records that may be found, Applicant will further require registrars to conduct a reasonable investigation and to respond with one of the three possible actions:
confirm that the information provided in WHOIS is accurate, or
correct the WHOIS information, or
delete the domain name(s).
28.7. Extra provisions for validation-based TLDs
As mentioned above, registrations in the TLD will not be in real time. The registration process will involve manual verification of the identity of the applicant, correctness of its contact information and its compliance with the Eligibility restrictions.
The manual verification process will ensure that only legitimate and reputable businesses will be able to register domain names in the TLD. Manual verification of contact information will further ensure unprecedented accuracy of WHOIS data.
Applicant expects that this additional manual screening process, added on to the standard anti-abuse measures, will discourage abusive registrations and make any malicious activity extremely unlikely to occur in the TLD.
Applicant will support Trademark Clearinghouse (TCH) once it is implemented by ICANN. Owners of trademarks pre-validated by the Clearinghouse (those who are also eligible to hold domain registrations in the TLD according to the eligibility criteria) will be able to secure their domain registrations during the Sunrise period without further verification of their intellectual property rights.
Full details of the Sunrise registration process will be finalized after the Trademark Clearinghouse service is implemented and full documentation, policies, terms and conditions are made available. For guidance, data items that will need to be provided by the qualifying applicant to apply for a Sunrise registration are listed below:
TLD will comply with the Uniform Domain Name Dispute Resolution Policy or with any successor thereof. The UDRP will be incorporated by reference into Registry-Registrar Agreements. Similarly, Registrars will be required to incorporate it into their Domain Registration agreements with the Registrants.
Applicant also reaffirms its commitment to maintain the TLD free of violations of third party trademark rights through second level domain registration and use. Applicant has all the required resources, policies and procedures in place to address any situations of abuse without the need to invoke the PDDRP procedure.
CentralNicʹs resourcing model assumes that the ʺdedicatedʺ resourcing required for the TLD (ie, that required to deal with issues related specifically to the TLD and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that the TLD will use. After three years of operation, the optimistic projection for the TLD states that there will be 1,000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names. Therefore the TLD will require 0.02% of the total resources available for this area of the registry system.
29.9 Extra provisions for validation-based TLDs
As mentioned above, registrations in the TLD will not be in real time. The registration process will involve an additional step of manual verification of the identity of the applicant, correctness of its contact information and its compliance with the Eligibility restrictions.
Applicant expects that this additional manual screening process, added on to the standard anti-abuse measures, will discourage abusive registrations and make any abusive or malicious activity extremely unlikely to occur in the TLD.
29.10. Initial Eligibility and Acceptable Use Policy
This policy is subject to all ICANN requirements for new gTLDs, including the URS and UDRP, and will be made compliant with any future ICANN requirements as and when necessary
29.10.1. Definitions
Registry TLD: .كيوتل Top Level Domain.
Registry: Ooredoo which is responsible, in accordance with the Registry Agreement, for operating the Registry TLD. Where applicable, the term “Registry” also includes the Registry’s service providers, agents and subcontractors.
Domain Name Holder: an entity that holds the second level domain name registration under a Registry TLD and is entitled to use it.
TLD Policies: this Eligibility and Acceptable Use Policy, ICANN consensus policies and such other policies as may be adopted by the Registry or ICANN for application to the Registry TLD.
29.10.2. Introduction.
This Policy establishes the operational principles of the Registry TLD and sets forth, among other items, the restrictions on who can register domain names under the Registry TLD and which second level labels can be registered under this TLD. It also describes the situations in which the Registry can intervene into functioning of a domain name and the procedures associated with such intervention.
29.10.3. Parties subject to this policy
29.10.4. Purpose of the Registry TLD
The Registry TLD is intended to serve the Registry and its affiliates, distributors, retailers and consumers worldwide.
29.10.5. Eligibility restrictions
The following entities are eligible to register domain names under the Registry TLD:
2. Registry affiliates worldwide;
3. Any other parties explicitly authorized by the Registry.
An eligible entity can apply to register domain names under the Registry TLD via an Accredited Registrar pursuant to terms and conditions of that registrar.
The Registry, or its appointed agent, verifies applicant’s compliance with the eligibility requirements and accuracy of the contact information provided by the applicant. The decision of the Registry with regards to applicant’s eligibility or non-eligibility is final.
A Domain Name Holder must maintain its eligibility throughout the entire life of the domain. Should at any time a Domain Name Holder become incompliant with any of the eligibility requirements above, such holder must stop using the Domain Name immediately and arrange deletion of the domain name from the Registry as soon as practicable.
The registry reserves the right to re-verify the Domain Name Holder compliance with this Policy and may at any time request current documentary evidence of the Domain Name Holder’s eligibility. Domain Name Holder will promptly provide such documentary evidence.
29.10.6. Acceptable use policy
Prospective registrants are required to seek explicit approval from the Registry prior to applying to register a domain name under the Registry TLD and it remains at the ultimate discretion of the Registry to approve or deny registration and⁄or renewal of any domain name under the Registry TLD.
Domain Names under the Registry TLD can only be used for lawful purposes, i. e. in the manner that is not prohibited by the laws applicable in the jurisdiction where Registry is domiciled. The Registry is committed to maintaining the environment free from online crime, malicious or illegal activities. The Registry will investigate all reports of illegal activity and will cooperate with the competent governmental agencies in such investigations.
29.10.7. Enforcement
29.10.7.1 Notice of Violation and Opportunity to Correct
In case the Registry encounters or is informed of any alleged violation of the TLD Policies, by the Registrar or the Domain Name Holder, it will investigate the alleged violation. If the Registry, in its sole discretion, concludes that the Domain Name Holder has indeed violated a TLD Policy, it will normally request the Domain Name Holder to comply with this Policy within thirty (30) days’ notice.
The Registry may use any notification methods, but as a minimum it will send an email to the email address of the Administrative contact that is on record with the Registry. Such e-mail notification should be deemed sufficient notice.
29.10.7.2 Revocation
In case an inadequate response or no response has been received within the notice period given to the Domain Name Holder, the Registry may revoke the domain name registration without any further notice, and without the Domain Name Holder, nor any third party, being entitled to any damages resulting from such actions.
29.10.7.3 Interim Measures
In extreme situations where there is evidence that a Domain Name under a Registry TLD is being used in connection with illegal or malicious activity including, but not limited to phishing, pharming, distribution of illegal content, distribution of malware, fast flux hosting, botnets, unauthorized access to information systems, or the domain name is used in a way that threatens security and stability of a Registry TLD, the Registry reserves the right, in its sole discretion, to apply these interim measures as soon as practically possible, and prior to any notice to the Domain Name Holder.
In addition, the Registry reserves the right to apply these interim measures in its discretion; (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of the Registry as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement or (5) to correct mistakes made by the Registry or any Registrar in connection with a domain name registration.
29.10.7.4 Registrar Assistance
-The SRS will be operated in a secure manner. Controls will be in place to prevent unauthorised access and modification of registry data.
-The Whois service will prevent unauthorised bulk access to domain name registration data, and provide tools to protect personal information.
-The DNS system will be designed to provide effective defence against DDoS attacks. The registry will proactively monitor the DNS system to provide early warning against threats to the stability of the TLD.
-The DNSSEC system will be operated in accordance with best practices and recommendations as described in the relevant RFC documents (described in §43).
-Security incidents reported by registrars, registrants and other stakeholders will be acted upon in accordance with the Security Incident Response Policy (see below).
-Security vulnerabilities reported to the registry will be acknowledged and remediated as quickly as possible.
-Registrars will be promptly notified of all incidents that affect the security and stability of the registry system and their customers, and will be kept informed as incidents develop.
-Review and monitor information security threats and incidents.
-Approve initiatives and methodologies to enhance information security.
-Agree and review the security policy, objectives and responsibilities.
-Review client requirements concerning information security.
-Promote the visibility of business support for information security company-wide.
-Manage changes to 3rd party services that may impact on Information Security
-Perform internal audits with the assistance of Blackmores.
Certified Security standards:
ISO 9001:2008, ISO 27001: 2005
Digital data is safe guarded by DLP while non-digital data is kept in restricted access, locked cabinets or rooms.
We are currently deploying an enterprise-wide privileged password management solution.
It will be stored encrypted on the relevant equipment.
Access logs to data and credentials:
All systems added to the corporate SIEM are access logged and audited.
Office networks, email and document storage.
Digital data is safe guarded by DLP while non-digital data are kept in restricted access, locked cabinets or rooms.
Building & Offices: 2 levels of buildings security, one for the entire compound and then for particular building. Also CCTV cameras are installed in the restricted and public areas.
Are enabled, but can be disabled using DLP.
Physical Documents: Kept in locked cabinets or rooms
Access to core network: Firewalls, NAC. Without proper authentication user will be quarantined.
VPN: SSL VPN is under implementation. user will only be able to Access the network based on his user profil in SSL VPN, also user session can be monitored.
Wireless: user authentication is required to Access Wireless network.
Macfee suite is installed on all the system and managed by ePO server for latest patches. Also AV is in place at the SMTP level as well as at the Gateways.
Controls in place to mitigate the risk from unpatched vulnerabilities in software:
All the patches are downloaded and pushed to system by Windows serves automatically.
Domain password policy requires all users to form a strong password, which must be changed periodically.
Ooredoo shall nominate a point-of-contact, who shall be responsible for overseeing all matters related to the TLDs including liaison and coordination with relevant authorities.