ICANN New gTLD Application

New gTLD Application Submitted to ICANN by: The Siam Commercial Bank Public Company Limited (ʺSCBʺ)

String: scb

Originally Posted: 13 June 2012

Application ID: 1-1197-50009


Applicant Information


1. Full legal name

The Siam Commercial Bank Public Company Limited (ʺSCBʺ)

2. Address of the principal place of business

9 Rutchadapisek Rd
Jatujak
Bangkok 10900
TH

3. Phone number

+66 2 544 1111

4. Fax number

+66 2 544 1111

5. If applicable, website or URL

http:⁄⁄www.scb.co.th

Primary Contact


6(a). Name

Mr. Teeraphong Mahatham

6(b). Title

Vice President, Change Program

6(c). Address


6(d). Phone Number

+66 2 544 7290

6(e). Fax Number

+66 2 544 4948

6(f). Email Address

teeraphong.mahatham@scb.co.th

Secondary Contact


7(a). Name

Ms. Keerataporn Sripan

7(b). Title

Vice President, Strategic Planning

7(c). Address


7(d). Phone Number

+6625445126

7(e). Fax Number

+6625443908

7(f). Email Address

Keerataporn.sripan@scb.co.th

Proof of Legal Establishment


8(a). Legal form of the Applicant

Public Company Limited

8(b). State the specific national or other jursidiction that defines the type of entity identified in 8(a).

Thai

8(c). Attach evidence of the applicant's establishment.

Attachments are not displayed on this form.

9(a). If applying company is publicly traded, provide the exchange and symbol.


9(b). If the applying entity is a subsidiary, provide the parent company.


9(c). If the applying entity is a joint venture, list all joint venture partners.


Applicant Background


11(a). Name(s) and position(s) of all directors

Anand PanyarachunChairman of the Board, Independent Director and Member of the Corporate Social Responsibility Committee
Bodin AsavanichDirector, Member of the Executive Committee, Senior Executive Vice President, and Group General Counsel
Chairayu Isarangkun Na AyuthayaDirector and Chairman of the Corporate Social Responsibility Committee
Chumpol NaLamliengIndependent Director and Chairman of the Nomination, Compensation, and Corporate Governance Committee
Disnadda DiskulDirector and Member of the Corporate Social Responsibility Committee
Ekamol KiriwatIndependent Director and Member of the Audit Committee
Jada WattanasirithamIndependent Director, Memb. of the Corp. Soc. Respon. Com. and Memb. of Nomination, Compensation, and Corp Gov Committee
Kannikar ChalitapornPresident, Member of the Executive Committee, and Member of the Corporate Social Responsibility Committee
Kulpatra SirodomIndependent Director and Member of the Audit Committee
Maris SamaramIndependent Director, and Chairman of the Audit Committee
Robert Ralph ParksIndependent Director and Member of Nomination, Compensation, and Corporate Governance Committee
Sumate TanthuwanitIndependent Director and Member of the Audit Committee
Supa PiyajittiDirector and Member of the Nomination, Compensation, and Corporate Governance Committee
Thevan VichitakulDirector and Member of Nomination, Compensation, and Corporate Governance Committee
Vicharn PanichIndependent Director and Member of the Corporate Social Responsibility Committee
Vichit SuraphongchaiDirector, Chairman of the Executive Committee, and Member of the Corporate Social Responsibility Committee

11(b). Name(s) and position(s) of all officers and partners

Arthid NanthawithayaSenior Executive Vice President, Group Head, Wholesale Banking Group
Bodin AsavanichSenior Executive Vice President, Group General Counsel
Deepak SarupSenior Executive Vice President, Chief Financial Officer & Head, Finance Group and Change Program
Kannikar ChalitapornPresident
Manoon SunkunakornSenior Executive Vice President, Group Head, Human Resources Group
Sarunthorn ChutimaSenior Executive Vice President, Division Head, Special Assets Group
Sirichai SombutsiriSenior Executive Vice President, Group Head, Business Banking Group
Vichit SuraphongchaiDirector, Chairman of the Executive Committee, and Member of the Corporate Social Responsibility Committee
Yokporn TantisawetratSenior Executive Vice President, Chief Risk Officer
Yol PhokasubSenior Executive Vice President, Group Head, Retail Banking Group

11(c). Name(s) and position(s) of all shareholders holding at least 15% of shares

Bureau of the crown property and groupNot Applicable
Krung Thai Asset Management Public Company Limited via Vayupak Mutual Fund 1Not Applicable

11(d). For an applying entity that does not have directors, officers, partners, or shareholders: Name(s) and position(s) of all individuals having legal or executive responsibility


Applied-for gTLD string


13. Provide the applied-for gTLD string. If an IDN, provide the U-label.

scb

14(a). If an IDN, provide the A-label (beginning with "xn--").

N⁄A

14(b). If an IDN, provide the meaning or restatement of the string in English, that is, a description of the literal meaning of the string in the opinion of the applicant.

N⁄A

14(c). If an IDN, provide the language of the label (in English).

N⁄A

14(c). If an IDN, provide the language of the label (as referenced by ISO-639-1).

N⁄A

14(d). If an IDN, provide the script of the label (in English).

N⁄A

14(d). If an IDN, provide the script of the label (as referenced by ISO 15924).

N⁄A

14(e). If an IDN, list all code points contained in the U-label according to Unicode form.

N⁄A

15(a). If an IDN, Attach IDN Tables for the proposed registry.

Attachments are not displayed on this form.

15(b). Describe the process used for development of the IDN tables submitted, including consultations and sources used.

N⁄A

15(c). List any variant strings to the applied-for gTLD string according to the relevant IDN tables.

N⁄A

16. Describe the applicant's efforts to ensure that there are no known operational or rendering problems concerning the applied-for gTLD string. If such issues are known, describe steps that will be taken to mitigate these issues in software and other applications.

.SCB is a string composed of three ascii characters, the same as existing three characters gTLDs, which has no known operational nor rendering problems.
We have checked and found that this string combination is not a reserved word. In addition, we searched for other companies and organization which may use this string combination and there is none.

17. (OPTIONAL) Provide a representation of the label according to the International Phonetic Alphabet (http://www.langsci.ucl.ac.uk/ipa/).

N⁄A

Mission/Purpose


18(a). Describe the mission/purpose of your proposed gTLD.

We, SCB, aim to use .scb TLD as a .brand TLD with multiple purposes – short term ones and long term ones.  In the short term, we will strengthen our “SCB” branding as well as solving the internet problem (such as phishing, confusion) while the long term mission is to utilize the .scb to heavily expand our market coverage and services.  
At a starting point, we will use the .scb TLD to consolidate website addresses of SCB group businesses into one TLD. This will help establish a cohesive, clear, dedicated, immediately identifiable online identity, experience and channel for SCB. The .scb TLD provides potential to enhance our internet strategy as it will bring SCB’s online presences together into one clear channel of communication and enable us to enhance our online security. The .scb TLD will clearly distinguish SCB and its products and services from its competitors. Furthermore, .scb TLD is aimed at promoting and protecting SCB’s name from other entities in cyberspace. The .scb shall provide a distinction in terms of the legitimacy of the information of SCB and its sites, making it easier for its clients to easily locate the SCB products and services they need.

Later on, once the “SCB” branding is strengthened in the internet world which may take 3-5 years, we will be utilizing our .scb to provide the sophisticated services to the millions of our current customers.

For your information, SCB is a major commercial bank in South East Asia with Total Assets of THB 1,878 billion (USD 626 billion), Net Profit of THB 36 billion (USD 1.2 billion), and Market Capitalization of THB 396 billion (USD 13.2 million) as of 31st December 2011. Further, it has 1,094 branches, 8,459 ATMs and more than 12 million customers as of 31st December 2011. As such, it has demonstrates ability to create a big impact to the internet and all the customers.

18(b). How do you expect that your proposed gTLD will benefit registrants, Internet users, and others?

There are two main beneficiaries of the .scb:

1. The organization (SCB): The .scb will allow SCB to consolidate its diverse existing online presences. It will merge more than 30 websites of the SCB Group of Companies into a unified and consistent online platform. This will assist in building SCB brand awareness, brand loyalty and trust. Since the .scb is easier to find and remember than existing SCB domain names, SCB will have increased traffic which leads to opportunity for innovative product and service improvement. On the other hand, the .scb will eliminate miss-traffic due to typosquatting and misspellings. All registrations in the .scb TLD will be made and their use controlled by SCB, thus preventing abuse and in particular offering high protection to SCB’s value trademarks and reputation. The .scb will also help SCB protect its customers against illegitimate products and services by providing a space that guarantees the legitimacy of products and information accessed through the .scb TLD. After the first period of strengthening SCB name in the internet world, we plan to provide the sophisticated services to our customers and hence these services will benefit both ourselves (SCB) and all of our customers.

2. The clients (Internet Users): The greatest benefit of the .scb TLD to both internet users seeking SCB products & services information and the existing online customers will be the increase in trust and confidence about the legitimacy of products & services and information accessed through .scb site and the security of SCB online banking service. The direct and exclusive connection between .scb and SCB company will be the foundation of this trust and confidence. Moreover, the naming convention that will be employed in the .scb TLD for example product name .scb, customer segment .scb will enable online customers to find the products, services and information they seek more quickly and reliably while reducing confusion.

The .scb TLD will be one among the first group of new gTLDs added to the root in which a company’s brand and the values of the brand will be clearly communicated by and through the .scb TLD. We anticipate that the .scb TLD will generate awareness of SCB products and services to online customers in both domestic and international markets. This will improve our customer online experience as the .scb TLD will link all SCB affiliate and product websites to a familiar unified TLD and help to promote SCB’s promise in providing total customer solutions. Moreover, the .scb TLD will prevent abuse and infringement and increase SCB brand reliability and trust and confidence in e-commerce.

Utilizing the .scb TLD will help strengthen competitive advantage especially during the upcoming full implementation of the AEC regional market. The .scb TLD will help SCB capitalize on the increasing business opportunities. It will also create a more easy and convenient customer online experience, create reliability and trust for the customers.

SCB will be the sole registrant within the .scb TLD, and as such is provided a competitive advantage in regards to existing TLDs as there will be a higher availability of domain names and the recall of the TLD will be intrinsically tied to the domain name being registered and the registrant, SCB.

Marketing and outreach activities in relation to our TLD will be conducted; these will target both at registrants and internet users. We will utilize all existing customer channels both online and offline i.e. website, social network, public relation activities, direct mail to targeted customer and media, including visibility at branches and ATM screen. Moreover, we will utilize existing internal communications channels to alert relevant staff to the existence of .scb TLD as a new online means of communicating our brand message and offering our products to customers.

To promote .scb TLD awareness among public, it will be important to conduct communication campaign as the following :

1. Informing consumers of the .scb TLD through content developed for our existing web sites.
2. Informing consumers of the .scb TLD through our existing communication material and campaigns by featuring and highlighting .scb TLD domain names in these campaigns (print, media, online, social network).
3. Informing targeted consumers and employee of the .scb TLD through our corporate events i.e. business seminars, staff orientation and etc.

The communication activities will generate awareness among internet users, targeted customers and prospective customers. The activities will make customers realize SCB’s trustworthy and technology potential to deliver service excellence as well as SCB leadership status in Thailand’s banking business.

18(c). What operating rules will you adopt to eliminate or minimize social costs?

The domain name registration under .scb TLD will be done exclusively by Siam Commercial Bank PCL for the purposes of promoting and selling its innovative technology-based financial products for SCB and its subsidiaries. In other words, Siam Commercial Bank PCL will be both the registry and the sole registrant of the .scb TLD.  The sub-domains under .scb will be either SCB’s subsidiaries’ websites or SCB’s innovative financial products.

All registrations under the .scb TLD will be made for a one-year term with annual evaluation by management whether they are suitable to be continued. The domain names under the .scb TLD will not be sold (the registration fees will not be charged). All the occurred cost is considered as an internal cost and will be covered by .scb TLD operating budget.

With the aforementioned very tight and close control of domain registration per our .brand TLD purpose, we strongly believe the impact to society and consumers will be well minimized.

Community-based Designation


19. Is the application for a community-based TLD?

No

20(a). Provide the name and full description of the community that the applicant is committing to serve.

N⁄A

20(b). Explain the applicant's relationship to the community identified in 20(a).

N⁄A

20(c). Provide a description of the community-based purpose of the applied-for gTLD.

N⁄A

20(d). Explain the relationship between the applied-for gTLD string and the community identified in 20(a).

N⁄A

20(e). Provide a description of the applicant's intended registration policies in support of the community-based purpose of the applied-for gTLD.

N⁄A

20(f). Attach any written endorsements from institutions/groups representative of the community identified in 20(a).

Attachments are not displayed on this form.

Geographic Names


21(a). Is the application for a geographic name?

No

Protection of Geographic Names


22. Describe proposed measures for protection of geographic names at the second and other levels in the applied-for gTLD.

The country names bases on  ISO 3166-1 standardised list of names plus geographic and geopolitical names which will be provided by ICANN  will be added to .SCB reserved name list and will be reserved from the availability for general registrations.  

The list shall be updated at ICANN’s direction and will be posted on the registry website.

The country names bases on ISO 3166-1 alpha-2 and alpha-3 may be released for future SCB own usage only.

Registry Services


23. Provide name and full description of all the Registry Services to be provided.

Outsourced Registry Operator will provide an essential set of servicesincluded within
service contract. These include receipt of data concerning registrations of domain
names and nameservers from registrars; provision to registrars of status information
relating to .scb; dissemination of TLD zone file; operation of the .scb zone servers; and
dissemination of contact and other information concerning domain name and name
server registrations in the TLD. These services are provided by the SRS, Whois, and
DNS subsystems.

1. Shared Registration System (SRS)
The multiple registrar system allows registrars to obtain information relating to the
status of names within the .scb TLD, to perform the registration of new domain names;
to modify, delete, or renew existing registrations; and to initiate the transfer of a
domain name from another registrar. The SRS base on Think Registry Model meaning
that the registry will keep a copy of the information concerning registrations of domain
names including name servers and contact information so in case that the sponsored
registrar no longer in the business the registration will not lost. The SRS service will
provide Extensible Provisioning Protocol (EPP) interface as well as Web interface for
registrars to be able to register names or check status of the TLD. The SRS is
described in detail in Question 24.
SCB plans to use the .scb TLD for .brand TLD
purpose, thus SCB may not use multiple registrars. However, SCB will outsource the
registry operation to, prospectively Thai Name Server Co., Ltd. for which we require
them to offer this service.

2. DNS operation – DNS nameservers
The service that provides responses to the Internet Domain Name System (DNS)
queries to Internet users. The registry operator will operate a global constellation of at
least 4 name servers to provide domain name resolution services. The zone
generation and distribution process is described in detail in Questions 34 and 35.

3. Whois Service
Whois service is a TCP transaction bases query⁄response server that provides
directory service that allows any Internet user to obtain contact and other information
concerning domain name and name server registrations within the .scb TLD. It is
available via port 43 access and via registry’s web site. The registry operator will
operate Whois server at its secondary site. The Whois service is described in detail in
Question 26.

4. Registry data escrow deposits
All gTLD registries are required to do Data Escrow deposits. Registry Data Escrow is
the process by which an Internet Registry periodically submits data deposits to a third
party called an Escrow agent. These deposits comprise the minimum data needed by
a third party to resume operations if the registry could not function and was unable or
willing to facilitate an orderly transfer of service. The goal of data escrow is higher
resiliency of registration services, for the benefit of Internet users. The beneficiaries
of a registration organization are not just those registering information there, but all
relying parties that need to identify the owners of objects. The registry operator will
operate Data escrow server at its secondary site. The Data escrow service is described
in detail in Question 38.

5. DNSSEC – DNS Security Extensions
DNSSEC service provides set of extensions to DNS which provide to DNS client origin
authentication of DNS data, authenticated denial of existence, and data integrity, but
not availability or confidentiality. DNSSEC was designed to protect Internet resolvers
(clients) from forged DNS data, such as that created by DNS cache poisoning. All
answers in DNSSEC are digitally signed. By checking the digital signature, a DNS
resolver is able to check if the information is identical (correct and complete) to the
information on the authoritative DNS server. DNSSEC does not provide confidentiality
of data; in particular, all DNSSEC responses are authenticated but not encrypted. The
registry zone file will be signed using public-key cryptography. The answer to DNS
lookup can be verified by verifying signature of the DNS resource record set using the
correct public key found in a DNSKEY record. The DNSEC service is described in detail
in Question 43.

6. IPv6
IPv6 extensions and reachability, this service provide DNS IPv6 extensions that
support IPv6 AAAA resource record registration and DNS publication. At least two of
name-servers are reachable via IPv6 data transportation. The IPv6 service is described
in detail in Question 36.

7. Internationalized Domain Name (IDN)
Internationalized Domain Name enabled Internet users to access domain names in
their own language. .scb will provide IDN in Thai language with Thai script. The IDN
service is described in detail in Question 44.

8. Bulk Whois Access
In addition to the publicly available Whois information, the .scb registry will provide
bulk access to a limited subset of this information to individuals or organizations that
agree to specific terms of use, as provided in the ICANN gTLD registry agreement.
These entities will be provided with unique username and password combinations to
authorize their access to the data. Bulk Whois data will be made available via either
FTP or HTTP. The distribution servers will be operated at the secondary site.

9. Zone File Access
In a similar manner to bulk Whois data, .scb zone data in its entirety will be made
available to those individuals or organizations that agree to specific terms of use.
Access to this zone data will also be controlled by the use of user names and
passwords. Zone file will be made available via FTP or HTTP or by other means if
requested by ICANN. The distribution servers will be operated at the secondary site.

Demonstration of Technical & Operational Capability


24. Shared Registration System (SRS) Performance

Shared registration system (SRS) performance
Shared registration system is a critical registry function for enabling multiple
registrars to register Names in the TLD. In order to meet ICANN requirement, we
will outsource registry operation to an existing registry operator with experience in
operate the TLD registry. The registry operator will provide a robust registry
operation, including the following elements.

- Data center operations
Registry operator will house all registry operations within secure data
centers with a robust physical plant.

- Database development and maintenance
A highly available database constellation with hardware at both the primary
and secondary sites will ensure the ability to continuously update
registration data. Registry operator will also develop the schema and
related database packages needed to support the registry’s operation.

- System backups
Registry operator will provide extensive backups and data escrow further
guarantee the availability of registry information.

- System Security
All registry operations will be provided with significant attention to security.

- Network Operations
Registry operator will maintain redundant connections to the Internet at its
primary site, and will make use of advanced network management
techniques throughout its infrastructure to provide high availability and
performance.

By outsourcing the operation will reduce the cost of the development and the
delay of deploying .scb TLD. The selected SRS based on Think Registry Model
meaning that the registry will keep a copy of the information concerning
registrations of domain names including name servers and contact information so
in case that the registrar fail to continue or willing to function as registrar the
registration information can be transfer to new registrar will minimum impact to
registrants. The SRS service will provide Extensible Provisioning Protocol (EPP)
interface as well as Web interface for registrars to be able to handling domains
registration and administrate the registrar.

The SRS will be multi-tier system meaning that every core system will run on
separate server to avoid single point of failure. The SRS core components
comprise of:

1) EPP server
The EPP server acts as a gateway between the internal SRS portion and the
registrars. It provides EPP interface to registrars which comply with relevant
existing RFCs and those published in the future by the Internet Engineering Task
Force (IETF) including all successor standards, modifications or additions thereto
relating to the provisioning and management of domain names using the
Extensible Provisioning Protocol (EPP) in conformance with RFCs 5910, 5730,
5731, 5732, 5733 and 5734.

2) Database servers
The Database servers comprises of fail-over redundant database in Mysql
database. The Database servers synchronize its data through VPN tunnel
encryption.

3) Web Application server – Registrar panel
Registrar Panel provides web-based management tools capable of handling
registrar administrator and domain registration.
The EPP server compliant with ICANN’s Registry Performance requirement
documented in specification 10, Registry Performance Specifications.

Picture 24-1 Shared Registration System Overview
(File named Q24-Picture24-1-SRS-v2.jpg)

Registry facilities and locations
Thai Name Server’s SRS system will be located in two different geographic
locations data centers for redundancy. The primary location is at CAT datacenter
(CAT Telecom Bangkok Tower). The secondary location is at INET datacenter Thai
summit tower Bangkok, Thailand. Both locations have fully redundant internet
connection, highly efficient power backup system, physical security management,
as well as fire protection system. The primary data center will be the location
where production SRS activities are being conducted daily. The primary site will
hosts an EPP, SRS Web interface, DNS and primary Database servers. The second
location will be used to host DNS, WHOIS, Zone file access⁄Data escrow deposit,
and backup database servers. All servers are connected to a local datacenter
database server via local gigabit Ethernet on unrouteable private network. The
database will be replicated from the primary site with Mysql Semisynchronous
replication in near-real time. The secondary site will act as the backup SRS
operation in case of non-availability at the primary site. All backup are warm
standby servers, ready to load, configure and operate within an hour. The primary
servers in virtual machines will be cloned to the backup site on monthly basis or
after an upgrade or change in software configuration. The primary and backup
datacenter are interconnected via redundant Virtual Private Network (VPN) links.
The servers state synchronization between primary and backup servers are
asynchronous, cold standby, state are synchronized using databases.


Resourcing plan
Resourcing plan is based on the size of 1,000 or less domain names under .SCB
within the first three years of the delegation and is calculated from the cost
offered by the prospected registry operator, Thai Name Server Company. During
the initial implementation phase, four system engineers of ThailNameServer will
responsible for registry system setup, customization and implementation for .scb.
The system engineers will take care of
- Registry system setup
- SRS setup and customization
- EPP implementation and integration
- Database and WHOIS setup
- DNS Service setup
- DNSSEC setup and implementation for .scb

Two system administrators and three technicians will responsible for the on-going
operation and maintenance of the registry system.Roles of the system
administrators are SRS, EPP, Whois, Database, DNSSEC and DNS Service system
operation and maintenance.

Roles of the technicians are
- 24x7 system and database monitoring; and
- 24x7 technical support point of contact for registrars, outsourced DNS
service provider, SCB and ICANN

25. Extensible Provisioning Protocol (EPP)

Extensible Provisioning Protocol (EPP)
The .SCB registry implementation will feature a “thick” model as typified by the
rich object store managed by the centralized registry. EPP is the Extensible
Provisioning Protocol. EPP is an application layer client-server protocol for
provisioning and management of objects stored in a shared registration system.
Specified in XML, the protocol 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, name-servers and contact details held by domain
registries. It is widely deployed in the gTLD and ccTLD registry space. The EPP
server will be developed by outsourced registry operator with experience in
development and operation of Registry and Registrar operation. The EPP service is
based on the Apache EPP server. It complies with version 1.0 of the EPP
specification, as defined in RFCs 5730, 5731, 5732, 5733, 5734 and 5910. Registry
Operator will provide and update the relevant documentation of all the EPP
Objects and Extensions supported to ICANN prior to deployment. The EPP objects
that will be used for the registry are domains, contacts and hosts. The registry will
provide object query and object transform command sets to support the Registry
Service.

Object Query Commands
EPP provides three commands to retrieve object information: 〈info〉 to retrieve
detailed information associated with a known object, 〈check〉 to determine if an
object is known to the server, and 〈transfer〉 to retrieve known object transfer
status information.

These are described below.

Info
The EPP 〈info〉 command is used to retrieve information associated with a known
object. The elements needed to identify an object and the type of information
associated with an object are both object-specific, so the child elements of the
〈info〉 command are specified using the EPP extension framework.

Check
The EPP 〈check〉 command is used to determine if an object is known to the
server. The elements needed to identify an object are object-specific, so the child
elements of the 〈check〉 command are specified using the EPP extension
framework.

Transfer (Query)
The EPP 〈transfer〉 command provides a query operation that allows a client to
determine real-time status of pending and completed transfer requests. The
elements needed to identify an object that is the subject of a transfer request are
object-specific, so the child elements of the 〈transfer〉 query command are
specified using the EPP extension framework.

Object Transform Commands
EPP provides five commands to transform objects: 〈create〉 to create an instance
of an object with a server, 〈delete〉 to remove an instance of an object from a
server, 〈renew〉 to extend the validity period of an object, 〈update〉 to change
information associated with an object, and 〈transfer〉 to manage changes in
client sponsorship of a known object.

These are described below.

Create
The EPP 〈create〉 command is used to create an instance of an object. An object
may be created for an indefinite period of time, or an object may be created for a
specific validity period. The EPP mapping for an object MUST describe the status of
an object with respect to time, to include expected client and server behavior if a
validity period is used.

Delete
The EPP 〈delete〉 command is used to remove an instance of a known object. The
elements needed to identify an object are object-specific, so the child elements of
the 〈delete〉 command are specified using the EPP extension framework.

Renew
The EPP 〈renew〉 command is used to extend the validity period of an object. The
elements needed to identify and extend the validity period of an object are object specific,
so the child elements of the 〈renew〉 command are specified using the
EPP extension framework.

Transfer
The EPP 〈transfer〉 command is used to manage changes in client sponsorship of
a known object. Clients may initiate a transfer request, cancel a transfer request,
approve a transfer request, and reject a transfer request.

Update
The EPP 〈update〉 command is used to change information associated with a
known object. The elements needed to identify and modify an object are object specific,
so the child elements of the 〈update〉 command are specified using the
EPP extension framework.


The registry will provide the following commands for each object.

- Contact Object:
Contact Check, Contact Create, Contact Info, Contact Update, Contact
Transfer and Contact Delete

- Domain Object:
Domain Check, Domain Create, Domain Info, Domain Update, Domain
Renew, Domain Transfer and Domain Delete

- Host Object:
Host Check, Host Create, Host Info, Host Update and Host Delete

EPP interface also defines the following requests: login, logout, hello and poll. They
allow EPP client to establish a connection to EPP server. The poll action is the
mechanism by which a registrar can retrieve notifications from the registry, such
as object transfer-away notifications. The only EPP extension that is intended to be
implemented is DNSSEC extension defined in RFC 5910.

Resourcing plan
Resourcing plan is based on the size of 1,000 or less domain names under .SCB
within the first three years of the delegation. Refer to resourcing plan described in
the response to Question 24, during the initial implementation phase, four system
engineers of ThailNameServer will responsible for registry system setup,
customization and implementation for .scb, including the EPP implementation and
integration. Two system administrators and three technicians will responsible for
the on-going operation and maintenance of the registry system. Roles of the
system administrators include EPP operational and maintenance and roles of the
technicians include
- 24x7 system and database monitoring; and
- 24x7 technical support point of contact

26. Whois

Whois
WHOIS is a TCP-based transaction-oriented query⁄response protocol as defined in
RFC 3912. A WHOIS server listens on TCP port 43 for requests from WHOIS clients.
The WHOIS client makes a text request to the WHOIS server, then the WHOIS server
replies with text content. The Registry Operator will operate a WHOIS service
available via port 43 in accordance with RFC 3912 and a web-based Directory Service
at 〈whois.nic.TLD〉 providing free public query-based access to at least the
elements in the format defined in Specification 4 of the ICANN’s Registry Agreement.
ICANN reserves the right to specify alternative formats and protocols, and upon such
specification, the Registry Operator will implement such alternative specification as
soon as reasonably practicable.

WHOIS Server
WHOIS server will be placed on different location from the EPP server and
Primary Database server for redundancy. This site will be used to host WHOIS
server and Bulk WHOIS server. The server compliant with ICANN’s Registry
Performance requirement documented in specification 10, Registry
Performance Specifications, i.e. downtime ≤ 864 min⁄month with Round-Trip
Time or RTT ≤ 2000ms and update time ≤ 60 min.

The Whois server is connected to a local datacenter database server via local
gigabit Ethernet on unrouteable private network. The database will be
replicated from the primary site with Mysql Semisynchronous replication in
near-real time. The primary site will act as the backup Whois operation in
case of non-availability at the secondary site. All backup are warm standby
servers, ready to load, configure and operate within an hour. The Whois
server in a virtual machine will be cloned to the backup site on monthly basis
or after an upgrade or change in software configuration. The Whois and
backup datacenter are interconnected via redundant Virtual Private Network
(VPN) links. The servers state synchronization between primary and backup
servers are asynchronous, cold standby, state are synchronized using
databases.


Picture 26-1 WHOIS and Bulk WHOIS access server interconnectivity (file name
Q26-Picture26-1-Whois-v2.jpg)


Bulk Registration Data Access to ICANN
Registry operator will provide ICANN on a weekly basis (the day to be
designated by ICANN) with up-to-date Registration Data as specified below.
Data will include data committed as of 00:00:00 UTC on the day previous to
the one designated for retrieval by ICANN. Registry Operator will provide, at
least, the following data for all registered domain names: domain name,
domain name repository object id (roid), registrar id (IANA ID), statuses, last
updated date, creation date, expiration date, and name server names. For
sponsoring registrars, at least, it will provide: registrar name, registrar
repository object id (roid), hostname of registrar Whois server, and URL of
registrar. The data will be provided in the format specified in Specification 2
for Data Escrow (including encryption, signing, etc.) but including only the
fields mentioned in the previous section, i.e., the file will only contain Domain
and Registrar objects with the fields mentioned above. Registry Operator will
have the file(s) ready for download as of 00:00:00 UTC on the day designated
for retrieval by ICANN. The file(s) will be made available for download by
SFTP, though ICANN may request other means in the future. Exceptional
Access to Thick Registration Data, In case of a registrar failure,
deaccreditation, court order, etc. that prompts the temporary or definitive
transfer of its domain names to another registrar, at the request of ICANN,
Registry Operator will provide ICANN with up-to-date data for the domain
names of the losing registrar. The data will be provided in the format
specified in Specification 2 for Data Escrow. The file will only contain data
related to the domain names of the losing registrar. Registry Operator will
provide the data within 2 business days. Unless otherwise agreed by Registry
Operator and ICANN, the file will be made available for download by ICANN in
the same manner as the data specified in Section 3.1 of Specification 4 for
Registration Data Publication Services.


Resourcing plan
Resourcing plan is based on the size of 1,000 or less domain names under .SCB
within the first three years of the delegation and is calculated from the cost offered
by the prospected registry operator, Thai Name Server Company.

Refer to resourcing plan described in the response to Question 24, during the initial
implementation phase, four system engineers of ThailNameServer will responsible
for registry system setup, customization and implementation for .scb, including the
WHOIS implement. Two system administrators and three technicians will responsible
for the on-going operation and maintenance of the registry system. Roles of the
system administrators include WHOIS operational & maintenance and roles of the
technicians include
- 24x7 system and database monitoring; and
- 24x7 technical support point of contact for registrars, outsourced DNS service provider, SCB and ICANN.

27. Registration Life Cycle

Registration life cycle


Picture 27-1 Registration life cycle (file name Q27-Picture27-1-
RegistrationLiftCycle.jpg)

The Registration will be done solely by our Company via API or Web Interface to a
selected ICANN accredited REGISTRAR. The Registration will not be charged. The
Registry not intended to implement Registry Grace Period or RGP in the EPP
Server. Registration is accomplished using the EPP domain Create command,
deletion is accomplished using the EPP domain Delete command, transfer is
accomplished using the EPP domain Transfer command, update is accomplished
using the EPP domain Update command and extension of a registration period is
accomplished using the EPP domain Renew command. The extension of a
registration period for expired domain is done automatically by the server with the
extension period of 1 year.


Picture 27-2 Registration life cycle state diagram (file name Q27-Picture27-2-
RegistrationLifeCycleStateDiagram.jpg)


Registration life cycle state of domain names, upon the completion of the EPP
domain Create command Domain Object is created with either “ok” status (no
other status values) or “inactive” status (Delegation information has not been
associated with host object). The Status of Domain object can be set only by client
that sponsors a domain object and by the server on which the object resides. A
client can change the status of a domain object using the EPP using EPP Update
command. A client cannot alter status values set by the server. A server may
alter or override status values set by a client, subject to local server policies. The
status of an object may change as a result of either a client-initiated transform
command or an action performed by a server operator. Status values that can be
added or removed by a client are prefixed with “client”. Status values that can be
added or removed by a server are prefixed with “server”. Status values that do
not begin with either “client” or “server” are server-managed. The “ok” status
must not be combined with any other status. The following status
clientDeleteProhibited, clientRenewProhibited, clientTransferProhibited,
clientUpdateProhibited are used to lock an object from corresponding command.

The Transfer Pending Period is a specified number of calendar days following a
request from a registrar (registrar A) to transfer a domain in which the current
registrar of the domain (registrar B) may explicitly approve or reject the transfer
request. The current value of the Transfer Pending Period is five calendar days for
all registrars. The transfer will be finalized upon receipt of explicit approval or
rejection from the current registrar (registrar B). If the current registrar (registrar
B) does not explicitly approve or reject the request initiated by registrar A, the
registry will approve the request automatically after the end of the Transfer
Pending Period. When the requested transfer has been completed, the
pendingTransfer status value must be removed. All clients involved in the
transaction must be notified using a service message that the action has been
completed and that the status of the object has changed.

Resourcing plan
.scb does not intend to implement Registry Grace Period. The personnel resources
needed for these criteria are the person who responsible for EPP implementation
and operational.:

Refer to resourcing plan described in the response to Question 24 and 25, during
the initial implementation phase, four system engineers of ThailNameServer will
responsible for registry system setup, customization and implementation for .scb,
including the EPP implementation and integration. Two system administrators and
three technicians will responsible for the on-going operation and maintenance of
the registry system. Roles of the system administrators include EPP operational
and maintenance and roles of the technicians include
- 24x7 system and database monitoring; and
- 24x7 technical support point of contact for registrars, outsourced DNS
service provider, SCB and ICANN.

28. Abuse Prevention and Mitigation

Domain names under .scb will be registered through SCB’s technical staff under SCB ownership. SCB
will be the registrant and all contacts of the domain names and will take full controls of the domain
names under .scb TLD. During the registration process, technical staff will check and verify that all
information and contacts are completed and accurate. Therefore, the Whois will be 100% accurate.

Resourcing Plan :
There will be two IT staff handling the registration front-end to check & verify all registration information
and being the abuse contact point to execute all duties as stated in the following Anti-abuse Policy.

Anti-abuse Policy Declaration :
Since .scb will be use internally, SCB will be the only registrant of all registered domain names, some
concerning topics regarding anti-abuse has been covered or doesn’t have any possibility to be occurred
including “Innocent Registrant Protection”.

Anti-abuse Policy :
To prevent and⁄or mitigate the effect of abuse, .scb prepared the “.scb Domain Name Anti-abuse Policy”
as the following : (This draft policy is subject to change and the effective date below will be updated
with the actual effective date)

.scb Domain Name Anti-abuse Policy
The following policy [.scb Domain Anti-abuse Policy] is announced in effect between .scb, Siam
Commercial Bank PCL. [SCB] and the Registry Operator, Thai Name Server Co., Ltd.
[ThaiNameServer], and the Registrar, DotArai Co., Ltd. [DotArai], and .scb Registrant.

Abusive use(s) of .scb domain names should not be tolerated. The nature of such abuses creates
security and stability issues for the registry, registrar and registrants, as well as for users of the Internet
in general. SCB defines abusive use of a domain as the wrong or excessive use of power, position or
ability, and includes, without limitation, the following:

Illegal or fraudulent actions;

Spam: The use of electronic messaging systems to send unsolicited bulk messages. The term
applies to e-mail spam and similar abuses such as instant messaging spam, mobile
messaging spam, and the spamming of Web sites and Internet forums. An example, for
purposes of illustration, would be the use of email in denial-of-service attacks;

Phishing: The use of counterfeit Web pages that are designed to trick recipients into divulging
sensitive data such as usernames, passwords, or financial data;

Pharming: The redirecting of unknowing users to fraudulent sites or services, typically through
DNS hijacking or poisoning;

Willful distribution of malware: The dissemination of software designed to infiltrate or
damage a computer system without the owner’s informed consent. Examples include, without
limitation, computer viruses, worms, keyloggers, and trojan horses.

Fast flux hosting: Use of fast-flux techniques to disguise the location of Web sites or other
Internet services, or to avoid detection and mitigation efforts, or to host illegal activities. Fastflux
techniques use DNS to frequently change the location on the Internet to which the domain
name of an Internet host or name server resolves. Fast flux hosting may be used only with
prior permission of SCB;

Botnet command and control: Services run on a domain name that are used to control a
collection of compromised computers or “zombies,” or to direct denial-of-service attacks
(DDoS attacks);

Distribution of child pornography; and

Illegal Access to Other Computers or Networks: Illegally accessing computers, accounts,
or networks belonging to another party, or attempting to penetrate security measures of
another individual’s system (often known as “hacking”). Also, any activity that might be used as
a precursor to an attempted system penetration (e.g., port scan, stealth scan, or other
information gathering activity).


SCB reserves the right to deny, cancel or transfer any registration or transaction, or place any domain
name(s) on registry lock, hold or similar status, that it deems necessary, 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 SCB, 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 SCB or
any Registrar in connection with a domain name registration. SCB also reserves the right to place upon
registry lock, hold or similar status a domain name during resolution of a dispute.

Abusive uses, as defined above, undertaken with respect to .scb domain names shall give rise to the
right of SCB to take such actions under the RRA in its sole discretion.


Why did SCB issue this policy?
This policy is addressing a significant potential harm to Internet users. Abuses that may be prevented
include identity theft, harm to children, and an erosion of trust in the Internet by users. SCB is enforcing
its terms of service to registrar to prevent abuse across the .scb domain for the benefit of all users.


What authority does SCB have to enforce the abuse policy?
The Domain Name Anti-abuse Policy is enacted under the clear, long standing, contractual authority of
SCB.


How will this policy affect registrants?
It is the goal of SCB that only those who abuse the domain system and engage in illegal or fraudulent
activity will be affected by this policy. Ordinarily, there should be no change in your relationship with
your registrar or the operation of your .scb domain.


What if SCB makes a mistake and suspends an innocent domain?
While SCB is taking steps to ensure a mistake does not occur, we recognize that the rare false-positive
may happen. SCB will place domains suspected of abuse on hold and not immediately delete them.
This should ensure that in the extremely rare case that an innocent domain is suspended, that it can
quickly be corrected.


What procedures will SCB be using to identify abuse?
SCB has established a variety of methods for tracking domain abuse and for verifying that those
domains which are identified are in fact being used in an abusive manner. These methods may include
coordination with law enforcement, reports from security vendors, and internal investigation. In case
abuse is reported, SCB team gathers required information from audit logs and investigates the case. If
the team confirms the abuse case, then SCB informs the related government agencies, such as
ICANN, Thai Ministry of Information and Communication Technology (MICT), Thai National Electronics
and Computer Technology (NECTEC), Thai CERT, US CERT and FBI. Also, SCB coordinate with police
to arrest the attackers. Once abuse is identified, SCB may notify and assist the registrar in resolving
the abusive activity. This policy is designed to assist the registrar by providing them with important
information for the betterment of the Internet as a whole.


How will SCB manage and remove orphan glue records from the zone when evidence in written
form that the glue is present in connection with malicious conduct is provided?
To prevent the malicious orphan glue records, SCB do not allow any orphan glue record in the system.
All the orphan records will be automatically remove by the detection script.


Will this policy deal with alleged violations of trademark or other intellectual property rights?
This policy is not a replacement for the UDRP. This policy is aimed at illegal and abusive use of domain
names and is not a substitute for current remedies to resolve intellectual property disputes involving
domain names and websites.


Abuse contact :
Any abuse report would be performed through a single security contact which is abuse(at)scb.

* The registrant is a .scb domain name holder. The registrant information and all contact information
will be verified and completed in registration process. To verified contact information, SCB will ask for
establishment documentation or identification card. In addition, the regular information update request
will be sent to registrants email annually. All contact information will be placed in the WHOIS** system.

** WHOIS is an Internet service that allows anyone to obtain registration and contact information about
domain name registrants. Although there are certain limitations on SCB’s commercial use of the
information, there are no effective means for protection of personal privacy. SCB holds this information
for .scb as other registries hold it for other generic TLDs. And like all generic TLDs, SCB currently is
required to make this information available through the WHOIS service in accordance with its
agreement with ICANN.


What procedures will SCB take to use the revised .scb Domain Name Anti-abuse Policy ?
In case of a new policy arose to reflect certain current circumstances and technologies, SCB will
announce them publicly on our registry website as well as on the registrar website one month prior the
effective date.

Authorization :
SCB would declare the right to perform any action stated in this policy and would be fully controlled by
the registry to access all domain functions in case of the abuse prevention or mitigation.

29. Rights Protection Mechanisms

Domain names under .scb will be registered through SCB’s technical staff under SCB ownership. SCB will be the registrant and all contacts of the domain names and will take full controls of the domain names under .scb TLD. During the registration process, technical staff will check and verify that registrant and other contacts are SCB. Only those two assigned and authorized IT staff can process the domain name registration through a secured channel provided by the contracted registrar. 

Each domain name and website of each domain name will be under a supervision of the IT Team. The team will routinely check the usage of each domain name and make sure that there is no phishing or pharming nor abused activities under the registered domain name. Management team will evaluate the usage of each domain name (website) from time to time, at least once a year, to decide whether the website and domain name will be continued. If any evidences of abusive occurs, the IT team can suspend the website or domain name usage immediately.

The following rights protection mechanisms (RPMs) will be implemented to minimize abusive registrations and other activities that affect the legal rights of others.

Resourcing Plan:
To implement RPMs, SCB will designate the existing two key staffs to handle administration and verification processes as well as all sorts of complaints. In addition, SCB also provides lawyers, who are experienced in many areas of the Intellectual Property laws, to take appropriate actions as responses to complaints, as well as to ensure that the registrations of domains under .scb correspond to the UDRP specification.


Rights Protection Mechanisms (RPMs)


UDRP compliance :
SCB agreed to allied with the ICANN existing Uniform Domain Name Dispute Resolution Policy (UDRP) to maintain the Rights Protection under .scb.

UDRP Attorney:
In case of any dispute occurred, complainer must use the ICANN designated agency of the UDRP to execute the UDRP procedures.

Safe-guard:
- Authorization
The objective of .scb is to be used only for internal organizations. Domains under .scb will be used for the SCB’s reputations activities. Any domain name that needed to be registered under .scb will be approved by .scb TLD Project Manager, who has a well-understanding of the registration process as well as the UDRP conditions. This can initially guarantee that domains under .scb will not be used for the bad faith of any other identities or will not be using for other business trademarks that may cause confusions.

- Trademark Claim
In addition to the authorization requirements that domains under .scb need to align, SCB also has the right protection mechanisms for any trademarks during the sunrise period. These mechanisms will be explained in more details later in this document.

- Geographic Name
To ensure that country names will not be used under .scb, the SCB registration system maintains a reserve list of all country names. When a registration is applied, the system will check the nominated domain name against this country name list. Only domain names with non-country names can pass this validation process. All the country names will be put into the permanent reserve list. This is to ensure that non of any country name will be used under .scb.

Channel of Complaint :
SCB provides a Dispute Resolution contact point, dispute@scb, to receive complaints from any complainer(s). When a complaint is received, SCB staffs will take care of it by following the procedures specified in the UDRP.

Sunrise Period:
To enhance effectiveness of Right Protection Mechanisms (RPMs), , SCB planned to have a sunrise period of approximately 2 months before the opening of .scb. During the sunrise period, the country name reserved list mechanism mentioned earlier will be developed, as well as the “Trademark Name Protection” mechanisms (described below) will be executed.

Trademark Name Protection:
To protect trademarks from being violated by .scb, SCB will announce publicly to trademark owners to register their trademarks to SCB. An online name submission system will be provided for trademark owners to register their names. SCB requires trademark owners to submit all relevant evidences to prove their rights within the sunrise period. All those names that pass this verification process will be added to the trademark reserve list. Again, when a registration is requested, SCB system will check the requested name against this trademark reserve list to avoid trademark violations.

Right protection through the Registry Operator and the Registrar:
Although the Registry Operator and the Registrar must agree to register any .scb names by the order of SCB, they also need to accept the requirements under the Registry Operator Agreement ⁄ Registrar Agreement to comply with this RPMs to ensure the protection will be highly performed.

30(a). Security Policy: Summary of the security policy for the proposed registry

.SCB TLD will be used solely by Siam Commercial Bank PCL the first commercial bank in Thailand established since 1904. The TLD will be used primarily for offering financial services. The Registry operator commits to develop processes and deploy the security management across infrastructure and systems to comply with an international standard ISO⁄IEC 27001:2005 (Please see the “Enterprise Information Security Policy” submitted as a separate document for the complete registry operator’s security policy, file name “Q30(b)-Exhibit30_DotSCB_REGISTRY_Information_Security_Policy.pdf”).

Registry operation will also be charged with following the Financial Services gTLD Control Requirements (http:⁄⁄www.icann.org⁄en⁄correspondence⁄aba-bits-to-beckstrom-crocker-20dec11-en.pdf) to provide reasonable assurance that the security, availability, and confidentiality of systems and information assets. In particular, the registry operator will ensure that critical registry operations (i.e., registration services, registry databases, zone administration, and provision of domain name resolution services) and business
operations are maintained according to the following:
- defining and communicating performance objectives, policies, and standards for system and information asset security, availability, confidentiality, and privacy
- utilizing procedures, people, software, data, and infrastructure to achieve defined objectives in accordance with established policies and standards
- monitoring the system and information assets and taking action to achieve compliance with defined objectives, policies, and standards

Below, the security policies of the registry operator as well as the control required over registrars are described.

1. Registry Operator’s Security Policy
+Domain Name Registration⁄Maintenance
-DNSSEC must be used for all DNS transactions
+ Encryptions
- All traffic among registry operators, registrars and registrants shall be encrypted
- All domains shall utilize HTTPS when the activity includes the display or entry of non-public personal information, the display of financial records, or the transacting of financial activities
- All data related to authentication credentials associated with the interaction of registry operators, registrars and registrants shall be encrypted in the storage
+ Defined Naming Conventions
- Registry operator shall define and implement name allocation policy including a process to resolve a conflict between identical or confusingly similar names
+ Authentications
- Registry operator requires that Registrars accessing Registry services must use strong, dual factor authentication to ensure only authorized access
- Registry Operator shall provide non-discriminatory access for all approved registrars
+ Maintenance and Accuracy of Whois data
- The registry shall perform verification quarterly with ICANN about the accuracy of Whois data
- Proxy registrations are prohibited within the registry
+ Resolution Services
- DNS lookup services shall be available at all times with rapid response to all queries
- Registry operator must offer Thick Whois
+ Server Configuration⁄Maintenance Standards
- Server configuration and maintenance shall be consistent with NIST Special Publication SP-800-123, “Guide to General Server Security”
+ Business Continuity Requirements⁄Backup And Disaster Recovery Capabilities
- Registry operations will be located in a geography with minimal exposure to natural disasters
- Registry operations shall provide sufficient physical redundancy to assure continuous operations of the domain in the event of a natural or man-made physical disaster
- Registry operators shall plan for ability to withstand and quickly recover from a cyber-attack including ability to recover from known attack scenarios including distributed
denials of service and penetration attacks (i.e., those which take advantage of unfixed vulnerabilities)
+ Registry operator shall test its physical recovery capabilities at least annually
- Registry operator shall test its cyber-attack recovery capabilities at least semi-annually
- Registry operator is willing to participate in at least one major industry-level physical disaster simulation and one major industry-level cyber-attack simulation annually
+ Auditing of Backup and Disaster Recovery Capabilities
- Registry operator shall make its backup and recovery plans and test results available for third party verification by an industry-approved review service independent of the
registry operator
+ Ongoing Monitoring
- Registry operator shall be able to detect variations from expected “normal” state of IT operations
- Registry operator shall be able to detect actual and potential cyber attacks
- Registry operator shall have and monitor a reliable source to gather physical and cyber threat intelligence
+ Incident Management Process Requirements
- Registry operator shall ensure that the mitigation of threats, be they physical, cyber or operational, will not degrade the ongoing operation and legitimate domain traffic
- Registry operator shall inform registrars and registrants of threat intelligence it identifies as a result of its own monitoring and must have capability to issue immediate alerts
upon identification of critical or high-risk incidents
+ Change Management Process Requirements
- Registry operator shall implement procedures related to environmental changes in hardware, software or operations that incorporate adequate pre-implementation planning and notification to parties potentially affected, adequate pre-implementation testing, post-implementation testing and adequate back-out contingencies
+ Security
- Registry operator shall comply with industry standards and best practices for DNS signing
- Registry operator requires DNSSEC for all domain names and sub-domains whose purposes involve accessing to private information, financial information or the execution of financial transactions
- DNSSEC shall employ NextSecure⁄NSEC (and preferably with NSEC3)
+ Encryptions
- Registry operator requires all traffic utilize a minimum of 128-bit encryption
+ Key Management Controls for Signing Keys
- Registry operator will have adequate procedures to control the upgrade, replacement, retirement of encryption keys for both the TLD keys and domain name zones
+ Other Security Requirements
- Registry operator shall utilize commercially reasonable defense in depth protections including network and personal firewall protections, intrusion prevention and filtering to block malicious traffic
- Registry operators shall monitor their environment for security breaches or potential indicators of security issues utilizing commercially reasonable monitoring tools including IDS monitoring, etc.
- Registry operator shall perform at least annual network penetration testing
- Registry operator will ensure that its Internal Registry Systems shall be protected using PKI certificates for authentication and encryption of sensitive data
- Registry operation shall have written policies and procedures for key generation and storage, and aging and renewal of certificates (including alerting to certificate recipients of upcoming expirations)

2. Registrar Control
+ The registry operator will limit the number of registrars to the fewest possible to effectively serve any financial services gTLD. And all registrars must meet all the following criteria:
+ Registrars must provide the following evidences to the registry operator:
+ Financial Background (preferably at least 10 years back)
+ Criminal Background (preferably at least 10 years back)
+ Registrars must be revalidated based on the above criteria at least quarterly. If the Registrant fails any of these checks during any post-initial acceptance revalidation, the Registry operator should suspend the Registrar.
+ Registry operator will monitor registrar fraud activity looking for patterns indicative of inappropriate registrar controls
+ Registry operator will provide written policies and procedures for registering, suspending and terminating registrars
+ In any cases, the registry operator requires that registrar registration procedures implement policy and procedures aligned to the requirements specified in the Financial Services gTLD Control Requirements (http:⁄⁄www.icann.org⁄en⁄correspondence⁄aba-bits-to-beckstrom-crocker-20dec11-en.pdf)
+ Registry operator also requires that registrants shall behave and follow the requirements specified in the Financial Services gTLD Control Requirements (http:⁄⁄www.icann.org⁄en⁄correspondence⁄aba-bits-to-beckstrom-crocker-20dec11-en.pdf)



© Internet Corporation For Assigned Names and Numbers.