Source: http://tierra-aoi.net/413.html
Timestamp: 2019-04-22 08:14:25+00:00

Document:
The word ʺاتصالات.ʺ   is Applicant’s registered trademark used in 18 countries across Asia, the Middle East and Africa. ʺاتصالات.ʺ is also a word in Arabic language that means ʺcommunicationsʺ.
7. U+062A ARABIC LETTER TEH Arabic language is written right-to-left, so code point no. 1 in the list above corresponds to the rightmost character of the string and code point no. 7 - to the leftmost character.
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.
There are no variants to the applied-for string.
ʺ.xn--mgbaakc7dvfʺ 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.
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.
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.
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.
-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.
The broad phonetic transcription of the TLD string is ⁄etisa:la:t⁄.
Etisalat (Emirates Telecommunications Corporation) has chosen to apply for the TLD to promote awareness of its services and products and facilitate the digital growth and expansion of the اتصالات brand (which is “Etisalat” in Arabic script) The TLD will be a tool to control and protect the brand and its Trademarks by providing an official digital hub for consumers worldwide as well as foster consumer trust by creating a secure and technically stable zone. Etisalatʹs mission is to extend peopleʹs reach by promoting its core consumer-centric values of reliability, openness, enabling, simplicity, caring, energy and optimism. Etisalat believes not only that the deployment of the TLD will facilitate this mission, but also that it will contribute to ICANNʹs commitment to innovation, consumer protection, security, and stability.
Headquartered in Abu Dhabi, United Arab Emirates (UAE), Etisalat has presence in Middle East, Asia and Africa and is the largest telecommunications operator in the Middle East and Africa. With a market value in excess of AED 80 billion (US$21 billion) and annual revenues of approximately AED 32 billion (US$9 billion), Etisalat is a successful and respected corporation both in the MENA region and worldwide. It has won dozens of awards, including being named ʺbest overall operatorʺ in the Middle East 10 times since 2006, and in 2012, receiving prestigious GSMA awards for Best Mobile Health Innovation, and Mobile Product for Women in Emerging Markets for Mobile Baby initiative and also named Best Mobile Money Innovation.
Etisalat has served the telecommunications need of individuals and businesses in the UAE and Gulf Region since 1976. Since then, it has built a modern telecom infrastructure, established itself as a technology leader, and continued to expand its reach not only through innovative services for its UAE customer base but through its ever growing international markets. Etisalat is a blue chip multinational organization that operates in 17 countries across Asia, the Middle East and Africa – a coverage area with a population of over two billion people. The group’s global subscriber base exceeds over 165 million subscribers through mobile, fixed line voice and data services, broadband and cable TV. Its satellite network provides services over two thirds of the planetʹs surface. Etisalat is one of the worldʹs fastest growing operators, and it has helped the UAE sustain its position as the regionʹs technological hub while simultaneously pioneering environmentally friendly information and communications systems.
Etisalat is not only in the  telecommunications business ; the corporation offers a variety of  hi-tech complimentary services to the telecommunications industry including managerial and  technical training, SIM card manufacturing, payment solutions, clearing house services,  peering, voice and data transit, and submarine and land cable services. The decision to apply for the TLD is part and parcel of its commitment to state-of-the-art technology throughout the company infrastructure and product offering, which has seen Etisalat pioneer next-generation networks for fixed lines and wireless and deploy enough fibre optic cable in the UAE to stretch to the moon and back two and a half times. Not only will this infrastructure meet the highest international standards, but it is expected to reduce carbon emissions by 80% and energy consumption by 70%. This focus on technological innovation and environmental responsibility has helped Etisalat capture significant market share as the company expands.
Etisalat shares ICANNʹs commitment to consumer empowerment, innovation, and competition. One noted example is the introduction of mobile broadband services (including video call and mobile TV) to Egypt and Saudi Arabia, which has changed market dynamics and provided affordable internet access to millions of consumers. Etisalat was named ʺmost innovative companyʺ at the 2011 International Business Awards and has recently launched 4G mobile to the UAE while offering the Middle Eastʹs fastest fixed line broadband service.
In addition to its commitment to technology and its consumers, Etisalat takes its mission of corporate social responsibility very seriously, and it actively engages in projects promoting health care for women in sub-Saharan Africa, providing access to clean water in Egypt, and famine and malnourishment relief in Africa, among others. Etisalat supported, and contributed to multiple initiatives in 2011, through sponsorships and donations for sports, educational, health, community and charitable events - in an ongoing mission to help enhance all aspects of society.
Etisalat’s award-winning Mobile Baby initiative delivers affordable healthcare for all powered by mobile connectivity with significant results: Mobile Baby programme is a complete suite of services that enables birth attendants and midwives to ensure safer pregnancies and deliveries by enabling them to identify, communicate, and act on obstetric emergencies quickly and accurately.In Tanzania where Etisalat first launched the service, there has been a substantial drop in baseline maternal mortality rates and a 30 percent increase in the in-medical facility delivery rate.  During 2012 the Etisalat Mobile Baby service will be rolled out across its operations in Africa and Asia.
The TLD will provide a digital home for information about all the previously-mentioned services in the Arabic language as well as facilitate the potential future expansion of Etisalat’s internet presence. Etisalat’s corporate mission requires it to actively extend people’s reach – meaning that it consistently develops active networks that enable people to develop, learn, and achieve their aspirations in life. The deployment of this 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. The launch of the TLD falls squarely within Etisalatʹs and ICANNʹs missions and will allow Etisalat to achieve its goals of innovation, outreach, growth, and learning while reinforcing its credibility and reputation for technical stability, security, and excellence.
The Etisalat brand has been recognized in the Brand Finance Global 500 list as ranking number 363 among the world’s leading brands with brand value up to US$ 3.12 billion, and the second most valuable brand in the Middle East. Etisalat has almost 1,000 Trademarks filed. The word ʺاتصالات.ʺ   is a brand name that is widely recognized and has been used since the company’s founding in 1976 throughout Etisalatʹs coverage area of 2 billion inhabitants and elsewhere as synonymous with the aforementioned service offerings. It is Etisalatʹs intention for the deployment of the TLD to mirror Etisalat’s growth as a brand and as a company, and also for the TLD to become part of Etisalatʹs Intellectual Property portfolio (thereby protecting the brand and the legion of consumers who currently recognize the brand and the many more who will do so as the company expands its reach).
Although the initial number of domains is expected to be small, depending on the evolution of the new TLD program and uses of new TLDs, Etisalat domains may be made available for registration by higher numbers of affiliates of Etisalat. The proposed Initial Eligibility and Acceptable Use Policy is located in response to question 29.10.
i. The TLD has been specifically designed to meet Etisalat’s requirements and facilitate its corporate mission. Mirroring ICANNʹs own goals of promoting consumer protection, security, stability, innovation, and rights protection, Etisalatʹ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 to register the shortest, most intuitive, and most descriptive domain names possible while ensuring that the content on the screen matches the input language for the domain (negating the requirement to switch between various keyboards). Various business units under the Etisalat corporate aegis will have access to the most efficient web addresses and be united under the اتصالات brand umbrella. Consumers will be aware that corporate communications and websites are authorized by Etisalat - 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 Etisalatʹs Arabic-language brand and business consumers, allowing both to grow and prosper unhindered in the digital landscape. It will provide unprecedented levels of technical service and serve as a platform for the expansion of Etisalat’s services and product offerings as well as boosting utility for Arabic-speaking internet users.
- protecting Etisalat 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  Its use may include but is not limited to websites, emails, online applications, online  transactions, social media, directories and any new usages of domain names.
iii. The TLD will allow web users to easily identify the Etisalat brand in the Arabic language – unimpeded by artificial boundaries (such as generic or ccTLD endings) and linguistic compromise. The TLD will assist with the dissemination of information about Etisalat product offerings in the Arabic language, allowing internet users to become more familiar with the services offered and the various business units within the Etisalat brand universe. 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 millions of consumers web access entirely in their native language.
To this end, Etisalat has made provisions for marketing the TLD extensively by incorporating the use of the new TLD in its marketing materials, so as to promote potential user uptake and understanding.
iv. The TLD is open to registrations by authorized parties within the Arabic-speaking Etisalat universe. A global, top-down outreach initiative will ensure that authorized registrants and internet users alike are aware of the TLD. Although individual business units within the Etisalat organization may wish to adopt their own informative strategies corresponding specifically with their unique team or market preferences, the common denominator will remain uniting the Etisalat universe under one TLD.
v. Applicant in its capacity of a TLD registry operator will not be providing any special services for protecting privacy or confidential information of registrants or end-users apart from those required by applicable laws, policies, agreements or technical standards. Some registry services include as their integral part, protection of usersʹ confidential information.
- 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 the Applicant are described in detail in the answer to question 30 “Security Policyʺ.
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. Etisalat 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, Etisalat 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. Etisalat will not implement any promotions or registrant discounts within the first three years from delegation.
iii. Domain names under the TLD 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 Etisalat 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.
Technical Support support refers to 1st, 2nd and 3rd line support for registrars and end-users. Areas covered include technical support for systems and services, billing and account management. Support personnel also deal with compliance and legal issues such as UDRP and URS proceedings, abuse reports and enquiries from law enforcement.
Since the optimistic projection for the number of domains registered in the TLD after three years is 1000, 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.
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 1000 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.
The Extensible Provisioning Protocol (EPP, defined in RFC 5730 and others) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. EPP defines generic object management operations and an extensible framework that maps protocol operations to objects. EPP has become established as the common protocol by which domain registrars can manage domain names, nameservers and contact details held by domain registries. It is widely deployed in the gTLD and ccTLD registry space.
EPP is a stateful XML protocol that can be layered over multiple transport protocols, the most popular implementation being that described in RFC 3734. Protected using lower-layer security protocols, clients exchange identification, authentication, and option information, and then engage in a series of client-initiated command-response exchanges. All EPP commands are atomic (there is no partial success or partial failure) and designed so that they can be made idempotent (executing a command more than once has the same net effect on system state as successfully executing the command once).
An EPP server responds to client-initiated communication (which can be either a lower-layer connection request or an EPP service discovery message) by returning a greeting to a client. The server then responds to each EPP command with a coordinated response that describes the results of processing the command.
EPP commands fall into three categories: session management commands, query commands, and object transform commands. Session management commands are used to establish and end persistent sessions with an EPP server. Query commands are used to perform read-only object information retrieval operations. Transform commands are used to perform read-write object management operations.
Commands are processed by a server in the order they are received from a client. Though an immediate response confirming receipt and processing of the command is produced by the server, the protocol includes features that allow for offline review of transform commands before the requested action is actually completed. In such situations, the response from the server will clearly note that the command has been received and processed but that the requested action is pending. The state of the corresponding object then reflects processing of the pending action. The server will also notify the client when offline processing of the action has been completed. Object mappings describe standard formats for notices that describe completion of offline processing.
Figure 25.1 describes the state machine for the EPP system. This derived from RFC 5730. Clients establish a connection with the server, which sends a greeting. Clients then authenticate, and once a login session is established, submits commands and receive responses until the server closes the connection, the client sends a logout command, or a timeout is reached.
1.domain names must comply with the Preferred name 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.domain names must have a registrant attribute which is associated with a contact object in the registry database.
3.domain names must have an administrative contact attribute which is associated with a contact object in the registry database.
4.domain names must have a technical contact which attribute is associated with a contact object in the registry database.
5.domain names may have an billing contact attribute which is associated with a contact object in the registry database.
6.domain names may have between 0 (zero) and thirteen (13) DNS servers. A domain with no name servers will not resolve and no records will be published in the DNS. CentralNicʹs EPP system uses the host object model for domain names, rather than the host attribute model (see RFC 5731, §1.1).
7.domain names may have a number of status codes. These codes are described in RFC 5731, § 2.3. The presence of certain status codes indicates the domain nameʹs position in the lifecycle, which is described further in §27.
8.where TLD policy requires, the server will response 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.
9.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.
10.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. Domain names which auto-renew are renewed for one year at a time.
11.domain names 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.
12.domain names may have one or more DS records associated with them. DS records are managed via the secDNS EPP extension, as specified in RFC 5910.
13.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 host objects is determined as follows: if an object is in-bailwick (ie subordinate to a domain in the registry database, and therefore also subordinate to a TLD in the system), then the sponsor is the sponsor of the superordinate domain name. 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 host objects 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 object cannot be deleted if one or more domain names are delegated to it (the registry may delete host objects to remove orphan glue, see §28).
8.inter-registrar transfers of hosts 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.contact objects 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.
6.a contact object cannot be deleted if one or more domain names are associated with it.
7.only the sponsoring registrar of the domain may submit “update” or “delete” commands for the object.
8.the “contact:disclose” element may be used to cause a contact object to be opted-out of display in the Whois (see §26 and the discussion of the Contact Type extension below. Note that this feature is redundant and will be disabled for TLDs which forbid registration by natural persons).
CentralNic has implemented the following EPP extensions. Rather than include detailed descriptions of these extensions, references to external specifications are included instead. CentralNicʹs implementations fully comply with the required specifications.
CentralNic supports the most recent specification of the secDNS extension, defined in RFC 5910. This specification supports two interfaces: the DS Data Interface and Key Data Interface (see RFC 5910, §4). CentralNic supports the former interface (DS Data), whereby registrars submit the keytag, algorithm, digest type and digest for DS records as XML elements, rather than as opaque (to EPP) DNSKEY data. DNSKEY data is accepted and stored where it is provided as a child element of the “secDNS:dsData” element.
The maxSigLife element is optional in the specification and is not currently supported.
CentralNic has contributed to a project to develop a standardised EPP extension for domain registry ʺlaunch phasesʺ (ie Sunrise and Landrush periods), during which the steady-state mode of ʺfirst-come, first-servedʺ operation does not apply. This extension permits registrars to submit requests for domain names with support for claimed rights such as a registered trademark. The extension is currently described in an Internet-Draft (see http:⁄⁄tools.ietf.org⁄html⁄draft-tan-epp-launchphase-00). It is hoped that this draft will eventually be published as an RFC which can be implemented by other registries and registrars.
CentralNicʹs system implements this extension and will support the most recent version of the draft during the initial launch of the TLD. Once the TLD enters the General Availability phase, this extension will no longer be available for use by registrars. Example command and response frames describing the use of this extension are included in Appendix 25.2. As of writing, the current Internet Draft does not include a full schema definition, but a schema from a previous version has been included in Appendix 25.3. When the Draft is updated to include a schema, it will be based on this version.
Registrars are issued with a username (their registrar ID) and a password which is used to access the EPP system. This password cannot be used to access any other service and only this password can be used to access the EPP system. Registrar officers with the ʺManagementʺ access level can change their EPP password via the Registrar Console. Password changes take effect immediately, but do not affect any existing login sessions.
RFC 5730 requires that EPP clients and servers implement ʺmutual, strong client-server authenticationʺ. To that effect, CentralNic requires that all registrars connect to the EPP system using a client SSL certificate. This certificate may be obtained from a recognised certificate authority, or it may be a self-signed certificate registered with CentralNic via the Registrar Console. Registrar officers with the ʺManagementʺ access level can upload SSL certificates for their account.
CentralNic does not impose limits on the number of active sessions a registrar can maintain with the server. Similarly, there are no limits on the volume of transactions a registrar may send. However the system is fully capable of imposing connection limits and this measure may be used in future to ensure equal access amongst registrars.
All ʺtransformʺ EPP 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 frame, the response frame, the result code and message, and the time taken by the system to generate the response. All commands, whether successful or not, are logged.
The EPP transaction log is stored in the primary registry database. Registrars have access to the full log for their account via the Registrar Console. The log viewer permits filtering by command, object type, object ID (domain name, host name, contact ID), result code and timestamp.
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.
Being open source, these libraries are available for anyone to use, at no cost. CentralNic continues to develop and update these libraries, and accepts submissions and bug reports from users around the world.
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.
CentralNic registrars are provided with an easy way to report issues with the EPP system, and many perform schema validation and other tests on the responses they receive. When issues are detected by registrars, they are encouraged to submit bug reports so that developers can rectify the issues.
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.
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.
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).
The telephone number is either answered by a live person or diverted to a monitored voicemail account.
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 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 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.
The 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 be1000 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.
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.
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 abusive or malicious activity extremely unlikely to occur in the TLD.
Registry TLD: اتصالات. Top Level Domain.
Registry: Emirates Telecommunications Corporation 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.
Accredited Registrar: an entity that (i) has entered into a Registrar Accreditation Agreement with ICANN (ii) is authorised to provide domain name registration services for the Registry TLD, (iii) contracts with Domain Name Holders, and (iv) submits Domain Name Holders’ registration data into the Registry database.
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.
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.
The Registry TLD is intended to serve the Registry and its affiliates, distributors, retailers and consumers 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.
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.
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.
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.
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.
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.
Perform internal audits with the assistance of Blackmores.
ISMS ISO 27001 Certified scopes: 1. Emirates data clearing house (EDCH). 2. Etisalat Managed Solution services MSS (Expected May 2012).  3. Etisalat Data centers (Expected March 2013). PCI certificate for the scope of Etisalat Internet Payment Gateway.
User accounts will be created for business owners & will be strictly managed by Group IT team as per the existing security policies.
The records will be stored in the existing SAN storage system & access will be granted only through application. These applications are accessed through a two factor authentication mechanism.
Access to registry services and other third party systems will be controlled through a two factor authentication system.
The credentials are installed in the two factor authentication servers & on the password database servers.
All access to data & credentials is logged & monitored by the event management system (tool). Auditing is enabled by the application & OS which is monitored by the administration on an adhoc & regular basis.
Email, Websites, FTP service, Document storage and collaboration tools.
The access will be granted based on a ʺNeed to Knowʺ basis and will be based on managed approval. An Identity Management System is already deployed & granting access will be provisioned⁄logged⁄monitored⁄revoked as per the status of the employee in the organization.
Building: Etisalat buildings are equipped with a physical access control system and access is granted to authorized staff based on the nature of duties on their ID cards.
Offices: Each floor is controlled by gate access and only authorized staff will have access to the respective floor during the office hours. Beyond office hours, a special access request must be initiated with proper justification & authorized by the administration department.
Computer Equipment: All business endpoint clients have controlled domain access, restricted by two factor authentication. Non-business endpoints are allowed internet ʺguestʺ access only.
Network Equipment: All network equipment is secured physically & by secured password authentication. Access to this equipment is restricted to authorized network & IT team.
Network Infrastructure: The network infrastructure components are properly installed through network containment setup. The backhaul setup is physically secured with access to authorized staff.
Portable Media: The portable media ports are controlled & access is restricted to standard encrypted USB devices.
Physical Documents: As part of Etisalat policies, all physical documents are stored in locked cabinets, with a key kept with the respective owner. All staff are requested to destroy unwanted documents as per the clear desktop & clear screen policy.
Access to all network media is restricted to authorized staff by credentials which have a recycle policy.
All communications to the outside network are controlled by content filtering against any malware & other threats.
A patch management solution is implemented at the server & endpoint level.
As per existing password policy, users are advised to use complex passwords (containing combinations of capital letters, small letters, numbers and special characters), a minimum of 12 characters in length. Users are advised to change their passwords on a regular basis.
Etisalat is always in touch with the law enforcement organizations through respective departments in Etisalat, and they conduct frequent meetings. Etisalat attend ICANN meetings to be updated on the best practices of internet management & the latest laws⁄regulations.

References: v. 
 §33
 §34
 §2
 §1
 § 2
 §27
 §28
 §2
 §2
 §26
 §4
 §43