Source: http://tierra-aoi.net/37.html
Timestamp: 2019-04-22 08:17:01+00:00

Document:
The string ʺKFHʺ consists of three ASCII characters, each one of which currently occurs as part of existing and operational TLD strings. We are not aware of any possible rendering problems concerning the string ʺKFHʺ.
We are aware of the issue of universal acceptability and accept that some incorrectly configured third-party software may consider ʺKFHʺ to be an invalid string, in the same way that other TLDs such as ʺ.INFOʺ and “.MUSEUMʺ are also at times considered ʺinvalid.ʺ Applicant will work to raise awareness of the issue of universal acceptance of KFH and other new gTLDs. CentralNic has previously contributed to these efforts, such as by publication of TLD Verification code for the PHP programming language.
We are aware that a significant fraction of queries sent to the DNS root servers are for invalid TLDs such as ʺ.LOCALʺ or ʺ.LANʺ, and that the delegation of these TLDs could cause previously undiscovered configuration errors to result in operational problems for other operators. We have reviewed the research in this area, including the SAC 045 report from ICANNʹs Security and Stability Advisory Committee, data from the Day In The Life of the Internet project, and other sources, and are not aware of any significant volume of invalid root server queries related to KFH. Therefore we feel confident that the delegation of this string will not result in any operation problems for Internet users.
Kuwait Finance House (“KFH” or “Applicant”) has chosen to apply for the TLD to promote awareness of KFH’s services and products and facilitate the digital growth and physical expansion of KFH. The TLD will control and protect KFH and its Trademarks by providing an official digital hub for consumers worldwide as well as fostering consumer trust by creating a secure and technically stable zone. KFH is confident that the TLD will allow the company not only to achieve its own goals of expansion, risk reduction, improved performance and efficiency, and technological development, but also contribute to ICANNʹs commitment to innovation, consumer protection, security, and stability across new markets.
Headquartered in Kuwait City, Kuwait, KFH provides Islamic Finance or Shari’a compliant services covering banking, real estate, trade finance, investment portfolios, and corporate, commercial, and retail financial markets. KFH was the first Islamic bank established in the State of Kuwait and is today one of the foremost Islamic financial institutions in the world. From its inception in 1977, KFH has grown into a robust banking and financial institution that is a market leader not only in the Islamic banking industry but also in the banking sector as a whole (both in terms of profitability and total assets). KFH has strong affiliations with leading international institutions and in the past has successfully launched a number of products in alliance with other major global banks such as Citi, Deutsche Bank, JP Morgan, Chase, BNP Paribas, ABN Amro, and HSBC.
Although KFH’s core market remains Kuwait (where it holds a 30% retail market share and the largest customer and retail base of any bank in Kuwait), the bank also cultivates a strong and growing international presence. KFH has established fully owned, independently functioning banks in Turkey (1989), Bahrain (2002), and Malaysia (2005, extended into Australia in 2008) while establishing significant stakes in other Islamic banks regionally and worldwide. As at December 2011, KFH also held subsidiaries in the Cayman Islands, the UAE, and Saudi Arabia. KFH actively seeks to expand its customer base both in Kuwait and internationally, quantitatively and qualitatively, by increasing the number of branches, developing communications channels with customers, developing innovative new products to meet evolving requirements, and continuously improving customer service to achieve the highest standards of quality and efficiency (as benchmarked against international standards). In its constant pursuit of excellence and bringing quality, secure banking products to new markets, KFH’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.
KFH is a multi-award winning organization, and it has received recognition and accolades from industry organizations and counterparts in every field – from Banking to Real Estate and Technology. In 2010, KFH won Global Finance’s award for Best Islamic Finance Bank in the GCC and was selected among the same organization’s Safest Banks in the Middle East. It is rated A+ by Fitch and Capital Intelligence, Aa3 by Moody’s, and A- by Standard and Poor’s. Its excellent ratings reflect the bank’s high degree of flexibility and resistance to market shocks. But perhaps the best gauge of the bank’s success and reliability is the trust consumers have placed in it: KFH ranks first in the banking deposit segment in Kuwait.
KFH was rated Best Consumer Internet Bank in Kuwait by Global Finance in 2010. The bank has an active internet presence, with the most-followed Twitter account (@KFHGroup) of any bank in the region (allowing for real-time customer feedback and service) as well as a Facebook page (www.facebook.com⁄KuwaitFinanceHouse). Most significantly, however, KFH’s website allows for the execution of 140 different banking services; KFH Online was the top rated application among customer testimonies. Throughout the past few years, KFH has targeted the best solutions and banking applications, matching the best international practices and standards in order to upgrade business efficiency and achieve the highest standards of quality. The establishment of quality control measures and increasing the capacity of equipment, systems, and network throughout KFH’s digital infrastructure further ensure KFH has the resources necessary to match the service requirements of the future. The decision to launch the TLD thus falls squarely within KFH’s digital strategy by providing access to unprecedented levels of technical security and innovation.
In addition to its commitment to stability, security, and its consumers, KFH takes its mission of corporate social responsibility very seriously. The bank supports various initiatives in the fields of education, healthcare, youth empowerment and development, special needs assistance, and caring for needy families. In 2011, KFH donated significant funds toward the elimination of famine and the provision of drought relief in the Horn of Africa as well as contributed to local efforts to combat diabetes.
The TLD will provide a digital home for information about all the previously-mentioned services as well as facilitate the future expansion of KFH’s web and market presence while simultaneously contributing to the bank’s technical improvement and innovation. As KFH actively expands into new markets and service categories, the TLD will serve as a platform for innovation as well as technical security and stability. It will provide a digital hub for all entities and subsidiaries within the KFH aegis and will provide a badge of authenticity, stability, and security designed specifically to protect KFH’s customers and infrastructure.
The term “KFH” is associated with a vast array of products and services related to Kuwait Finance House. As a result, millions of internet users and consumers associate the term “KFH” with Kuwait Finance House, and this number is only projected to increase with the forecast expansion of KFH. KFH holds Trademarks for the brand, ensuring not only the protection of the brand but also its public recognition. KFH will retain domains for internal use, educating consumers about KFH’s diverse service offerings as the bank expands internationally and within Kuwait. The expansion of KFH itself will simultaneously extend the outreach of the TLD – ensuring not only the promotion of KFH but also the effective organization of its domain name structure and the technical security and stability of its internet presence. The TLD will allow KFH to continue innovating and bringing new products to an emerging consumer base without compromise – thereby exceeding customer expectations and reaching new horizons.
i. The TLD has been specifically designed to meet KFH’s requirements and facilitate its corporate mission. Mirroring ICANNʹs own goals of promoting consumer protection, security, stability, innovation, and rights protection, KFH’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 KFH to register the shortest, most intuitive, and most descriptive domain names possible. Consumers will be aware that corporate communications and websites are authorized by KFH - promoting their confidence in the brands and their protection from potentially harmful third parties (particularly important for financial institutions).
iii. The TLD will allow web users to easily identify the KFH brand worldwide – unimpeded by artificial boundaries (such as generic or ccTLD endings) and secure in the knowledge that the communications and information uncompromisingly originate directly from KFH. The TLD will assist with the dissemination of information about KFH product offerings, allowing internet users to become more familiar with the services offered and the various business units within the KFH aegis. It will be a trusted zone functioning at the highest standards of technical and operational utility and security and serve as a platform for KFH’s already significant online banking operation.
iv. The TLD is open to registrations by authorized parties and business units within KFH for assigning domains related to KFH and its subsidiaries and affiliates. Although individual business units within KFH 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 KFH sites and services under an uncompromised, secure, stable, and innovative digital hub. The marketing and branding activities undertaken by KFH internationally will reinforce this goal.
As further detailed in the responses to questions 28 and 29, KFH 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 complete copy of the intended registration policy is found in Question 29.
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 KFH are described in detail in the answer to question 30 ʺSecurity Policyʺ.
vi. KFH will incorporate the use of the TLD in its existing marketing campaigns and materials in order to encourage user understanding, protection, and uptake. These communications and outreach efforts will ensure internet users, KFH customers, and the wider public are aware that the information disseminated on the TLD will provide content directly originating from KFH.
i. KFH 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.
Depending on various factors including the up-take and usage of new TLDs, KFH 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.
ii. KFH will not implement any promotions or registrant discounts.
At this time KFH 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.
Since the optimistic projection for the number of domains registered in the TLD after three years is fewer than 1,000 domains, the TLD will therefore require less than 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.
mod_epp is an Apache server module which adds support for the EPP transport protocol to Apache. This permits implementation of an EPP server using the various features of Apache, including CGI scripts and other dynamic request handlers, reverse proxies, and even static files. mod_epp was originally developed by Nic.at, the Austrian ccTLD registry. Since its release, a large number of ccTLD and other registries have deployed it and continue to support its development and maintenance. Further information can be found athttp:⁄⁄sourceforge.net⁄projects⁄aepps. CentralNic uses mod_epp to manage EPP sessions with registrar clients, and to convert EPP commands into HTTP requests which can then be handled by backend application servers.
* 1st Level: initial support level responsible for basic customer issues. The first job of 1st Level personnel is to gather the customer’s information and to determine the customer’s issue by analyzing the symptoms and figuring out the underlying problem.
* 2nd Level: more in-depth technical support level than 1st Level support containing experienced and more knowledgeable personnel on a particular product or service. Technicians at this level are responsible for assisting 1st Level personnel solve basic technical problems and for investigating elevated issues by confirming the validity of the problem and seeking for known solutions related to these more complex issues.
* 3rd Level: the highest level of support in a three-tiered technical support model responsible for handling the most difficult or advanced problems. Level 3 personnel are experts in their fields and are responsible for not only assisting both 1st and 2nd level personnel, but with the research and development of solutions to new or unknown issues.
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 fewer than 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 less than 0.1% of the total resources available for this area of the registry system.
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.
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.
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.
* 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.
* OK - present if none of the above apply.
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.
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.TLD does not exist, then NS0.EXAMPLE.TLD 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.
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 .موزايك 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.
.موزايك 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.
CentralNic, Applicant’s registry services provider, has maintained a similar dispute resolution policy with WIPO which is available athttp:⁄⁄www.wipo.int⁄amc⁄en⁄domains⁄gtld⁄cnic⁄index.html. CentralNic has dedicated personnel trained to address these types of complaints and to communicate with WIPO and other relevant stakeholders.
Applicant also reaffirms its commitment to maintain .موزايك 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 fewer than 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.01% of the total resources available for this area of the registry system.
Registry TLD: KFH Top Level Domain.
Registry: Kuwait Finance House 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.

References: §33
 §34
 §2
 §27
 §28
 §2
 §2