Application Downloaded On: 27 Mar 2015
String: smart
Application ID: 1-2139-55785
1. Full legal name
Smart Communications, Inc. (SMART)
2. Address of the principal place of business
Smart Tower, 6799 Ayala Avenue Makati City, Metro Manila - 1226 PH
3. Phone number
+6325113101
4. Fax number
+6325113100
5. If applicable, website or URL
http://www.smart.com.ph
6(a). Name
Vida Fe Sioson
6(b). Title
Supervisor, Partner Management, Innovations and Product Development Group
6(c). Address
6(d). Phone Number
+6325112870
6(e). Fax Number
+6325113100
6(f). Email Address
vlsioson@smart.com.ph
7(a). Name
Victor Reyes
7(b). Title
Manager, Planning and Architecture - Infra, Technical Services Division
7(c). Address
7(d). Phone Number
+6325114280
7(e). Fax Number
+6325113100
7(f). Email Address
vgreyes@smart.com.ph
8(a). Legal form of the Applicant
Corporation
8(b). State the specific national or other jurisdiction that defines the type of entity identified in 8(a).
Philippine Laws
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.
11(a). Name(s) and position(s) of all directors
|
| Anabelle L. Chua | Chief Financial Officer |
| George Lim | Director |
| Imelda A. Manguiat | Director |
| Lorenzo V. Tan | Director |
| Manuel V. Pangilinan | Chairman |
| Napoleon L. Nazareno | President and CEO |
| Orlando B. Vea | Chief Wireless Advisor |
| Oscar Reyes | Directro |
| Ramoncito Fernandez | Director |
| Rolando G. Pena | Head, Customer Assurance |
11(b). Name(s) and position(s) of all officers and partners
|
| Anabelle L. Chua | Chief Financial Officer |
| Charles A. Lim | Advisor |
| Emmanuel Ramon C. Lorenzana | Head, Wireless Consumer |
| Jovan S. Barac | Advisor |
| Lawrence Goh | Chief Information Officer |
| Manuel V. Pangilinan | Chairman |
| Mario G. Tamayo | Head, Technical Services |
| Napoleon L. Nazareno | President and CEO |
| Orlando B. Vea | Chief Wireless Advisor |
| Rene G. Banez | Head, Administration and Materials Management |
| Rolando G. Pena | Head, Customer Assurance |
| Setsuya Kimura | Advisor |
11(c). Name(s) and position(s) of all shareholders holding at least 15% of shares
|
| Philippine Long Distance Telephone Company | Not 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
13. Provide the applied-for gTLD string. If an IDN, provide the U-label.
smart
14A. If applying for an IDN, provide the A-label (beginning with "xn--").
14B. 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.
14C1. If an IDN, provide the language of the label (in English).
14C2. If an IDN, provide the language of the label (as referenced by ISO-639-1).
14D1. If an IDN, provide the script of the label (in English).
14D2. If an IDN, provide the script of the label (as referenced by ISO 15924).
14E. If an IDN, list all code points contained in the U-label according to Unicode form.
15A. If an IDN, upload IDN tables for the proposed registry. An IDN table must include:
- the applied-for gTLD string relevant to the tables,
- the script or language designator (as defined in BCP 47),
- table version number,
- effective date (DD Month YYYY), and
- contact name, email address, and phone number.
Submission of IDN tables in a standards-based format is encouraged.
15B. Describe the process used for development of the IDN tables submitted, including consultations and sources used.
15C. List any variants to the applied-for gTLD string according to the relevant IDN tables.
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.
The applied-for gTLD string is not an IDN and shall not have any known operational or rendering problems.
17. OPTIONAL.
Provide a representation of the label according to the International Phonetic Alphabet (http://www.langsci.ucl.ac.uk/ipa/).
18A. Describe the mission/purpose of your proposed gTLD.
Smart Communications, Inc. (SMART) is the Philippinesʹ leading wireless services provider with 49.0 million subscribers on its GSM network as of end-December 2011.
SMART has built an international reputation for innovation, having introduced world-first wireless data services, such as Smart Money (the world’s first electronic wallet linked to a mobile phone), Smart Load (electronic prepaid top-ups in sachet denominations), Smart Padala (mobile-based remittance service) and the Netphone (Android-based operator feature phone). SMART also offers 3G and HSPA+ services, and the country’s first and only LTE network. Its Smart Link service provides communications to the global maritime industry.
Smart Broadband, Inc., a wholly-owned subsidiary, offers a wireless broadband service, Smart BRO, with over 1.6 million subscribers as of end-December 2011.
SMART is a wholly-owned subsidiary of the Philippinesʹ leading telecommunications carrier, the Philippine Long Distance Telephone Company which is listed at the New York Stock Exchange.
SMART has nationwide coverage in the Philippines and has worldwide partnerships.
In the Philippines, SMART has an extensive network of over 1.4 million load retailers and dealers selling prepaid top-ups.
Launched in Hong Kong in August 2004, 1528 SMART is a prepaid GSM mobile phone service offering in Hong Kong designed and packaged to cater to the Filipino community. It is the product of the partnership of Hong Kong CSL Ltd. and PLDT (HK) Ltd.⁄ PLDT Global, in close collaboration with Smart.
Through strategic partnerships with The Western Union Company® (NYSE:WU) and MoneyGram International (NYSE: MGI) in November 2010, Filipinos all over the world can now send cash directly to the Smart mobile phones of their loved ones in the Philippines through any of over 95,000 international money transfer locations, including the United States and Hong Kong.
In June 2010, MasterCard Worldwide and Smart subsidiary, Smart Hub, Inc., announced a joint venture to accelerate the delivery of mobile payment solutions that will enable financial institutions and cellular phone networks around the world to deliver end-to-end mobile payment services through the MasterCard Worldwide Network. This service, which made its debut in Brazil, will be brought to major markets in Eurasia, Europe, Africa, and Middle East.
In the Philippines, the SMART brand is one of the most recognized trademarks in the country, with wide-recall among the population.
In the telecommunications industry worldwide, the SMART brand is automatically associated with the company, having won numerous international awards and acknowledged as a leader in the global associations of mobile operators.
As part of its thrust to introduce innovative services for its subscribers and as a strategy for growth in its global partnerships, SMART is planning to provide the .SMART gTLD as integral in increasing the value of its service delivery in its efforts to further expand and consolidate its leadership role in the mobile and Internet field.
The .SMART gTLD will serve the needs of the SMART including the provisioning of its cellular, wireless broadband, financial, technology solutions, mobile virtual networks and satellite services for the use of its authorized mobile and Internet subscribers.
The .SMART gTLD is for the exclusive use of the company and its subsidiaries, its authorized partners, and its subscribers. Registration in .SMART is not open to the general public.
SMART is investing PhP22.3-M for capital expenditures and an average of PhP15-M for operations yearly. Based on current utilization of its DNS infrastructure, SMART foresees two million authoritative queries per day in the first year alone. This does not account for future service offerings that the company will be introducing under the .SMART gTLD.
The .SMART gTLD will be integral to the company’s delivery of services for its subsidiaries, affiliates, partners and subscribers not only in the Philippines but worldwide. SMART will be using the .gTLD as part of its strategy to constantly be competitive in the industry. It will promote competitiveness, consumer trust and brand choice.
18B. How do you expect that your proposed gTLD will benefit registrants, Internet users, and others?
The .SMART gTLD will serve the needs of SMART including the provisioning of its cellular, wireless broadband, financial, technology solutions, mobile virtual networks and satellite services for the use of its authorized mobile and Internet subscribers.
The .SMART gTLD is for the exclusive use of the company and its subsidiaries, its authorized partners, and its subscribers, hence it will be a closed-registry model. It is not for the use of the general public.
Applications for registrations will be reviewed by the company’s .SMART Policy Board to protect the interests of its subscribers, partners, affiliates and equity.
The .SMART gTLD will follow SMART’s privacy policies for its services. Please refer to answers to Sections 26 and 30 for the details.
SMART will use the .SMART gTLD to operate its businesses. The registry will not be a direct business of the company but is seen as a support infrastructure for the company’s businesses. Hence, the stability of the registry is dependent on the stability of the company. Funding for the registry will come from the company’s network, IT and marketing budgets. SMART is one of the highest earning companies in the Philippines and high growth is still foreseen especially for its broadband Internet business.
SMART has a strong and robust technical infrastructure and capabilities and because the company will be directly controlling the .SMART gTLD, capacity and operations can be planned.
Completely and solely operated by the company, the registryʹs reputation will be tied with that of the company. This will assure the companyʹs partners and subscribers that every domain in the registry is vetted by the company in the same manner that it vets its service and products.
In its delivery, the .SMART gTLD will help mitigate security risks for its services and operations, ensuring consumer confidence.
The .SMART gTLD will also be a conduit for new and innovative products from SMART as it further expands its businesses not only for subscribers in the Philippines but also to subscribers and partners worldwide.
To achieve these projected benefits, SMART will conduct a multimedia campaign strategy and program that will communicate the establishment of the .SMART gTLD as well as its applications for various business streams. The campaign will ride on and will be integrated in SMART’s heavy marketing and communications investments.
18C. What operating rules will you adopt to eliminate or minimize social costs (e.g., time or financial resource costs, as well as various types of consumer vulnerabilities)? What other steps will you take to minimize negative consequences/costs imposed upon consumers?
Since this will be a closed .gTLD system, SMART will reserve the right to decide on multiple domain name applications through its .SMART Policy Board.
Because SMART will be operating the registry for its businesses, it will be an integral add-on benefit for its partners, affiliates and subscribers, a value-for-money proposition on top of the services they are paying for.
SMART will control the period for domain allocations at no greater than ten years at a time.
19. Is the application for a community-based TLD?
No
20A. Provide the name and full description of the community that the applicant is committing to serve. In the event that this application is included in a community priority evaluation, it will be scored based on the community identified in response to this question. The name of the community does not have to be formally adopted for the application to be designated as community-based.
20B. Explain the applicant’s relationship to the community identified in 20(a).
20C. Provide a description of the community-based purpose of the applied-for gTLD.
20D. Explain the relationship between the applied- for gTLD string and the community identified in 20(a).
20E. Provide a complete description of the applicant’s intended registration policies in support of the community-based purpose of the applied-for gTLD. Policies and enforcement mechanisms are expected to constitute a coherent set.
20F. Attach any written endorsements for the application from established institutions representative of the community identified in 20(a). An applicant may submit written endorsements by multiple institutions, if relevant to the community.
21A. Is the application for a geographic name?
No
22. Describe proposed measures for protection of geographic names at the second and other levels in the applied-for gTLD. This should include any applicable rules and procedures for reservation and/or release of such names.
Every domain name that will be registered in the TLD is fully controlled by SMART Communications, Inc. and will go through a rigorous vetting process by the Internet Committee.The Internet Committee will be composed of Network Services, Information Technology, Legal, Marketing, and Public Affairs. As a policy, the committee will disallow geographic names at the second and other levels in the applied-for gTLD. The Internet Committee will be consulting ISO 3166-1 standard and the ISO 3166-2 standard as part of the vetting process.
23. Provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns.
The following registry services are customary services offered by a registry operator:
- Receipt of data from registrars concerning registration of domain names and name servers.
- Dissemination of TLD zone files.
- Dissemination of contact or other information concerning domain name registrations (e.g., port-43 WHOIS, Web- based Whois, RESTful Whois service).
- Internationalized Domain Names, where offered.
- DNS Security Extensions (DNSSEC). The applicant must describe whether any of
these registry services are intended to be offered in a manner unique to the TLD.
Additional proposed registry services that are unique to the registry must also be described.
The .SMART TLD will be operated by SMART as the Registry Operator. The TLD is for the exclusive use of the company, its authorized affiliates, partners, and subscribers. The company will use .SMART to communicate with its affiliates, partners, and subscribers and to deliver official corporate information to the general public.
The registration of a second-level domain in the registry is to be restricted to the company and would be based on on the company’s operational needs. Registration to .SMART is not to be open to any registrant outside of the above restricted population.
CUSTOMARY REGISTRY SERVICES
The following is a list of the ICANN-defined customary registry services. Explanations are given if .SMART will not offer or will offer them in a manner unique to the TLD.
(A) Receipt of data from registrars concerning registration of domain names and name servers.
Not offered. Reason: The registry will be restricted for the exclusive use of the company and is not open to the general public. There will be no external registrars because there will be no non-company affiliated registrants.
(B) Dissemination of TLD zone files.
Offered. The registry will use BIND 9.9 for its DNS and will comply with all the relevant RFCs.
(C) Dissemination of contact or other information concerning domain name registrations (e.g., port-43 WHOIS, Web- based Whois, RESTful Whois service).
Offered. With Modification For all the SLDs, the registrant contact information will all be the same as that of the TLD and will refer to the company’s official contact person(s). Registration in the TLD will be subject to the company’s internal procedures and may not be done without the approval of the Head of the Business Unit. Hence the Head of the Business Unit will be able to answer all questions regarding any SLD.
(D) Dissemination of TLD zone files.
Offered. The registry will use BIND 9.9 for its DNS and will comply with all the relevant RFCs.
(E) Internationalized Domain Names, where offered.
Not offered. Reason: The company uses English and Filipino as its official business languages and both are accommodated by ASCII.
(F) DNS Security Extensions (DNSSEC).
Offered. The registry will use BIND 9.9 for its DNS servers and will comply with all the relevant RFCs. The registry will offer only the above customary services with the stated modifications. Because all of the above services are standards-compliant, the Registry Operator foresees no harmful effect on the stability or security of the DNS.
24. Shared Registration System (SRS) Performance:
describe
- the plan for operation of a robust and reliable SRS. SRS is a critical registry function for enabling multiple registrars to provide domain name registration services in the TLD. SRS must include
the EPP interface to the registry, as well as any other interfaces intended to be provided, if they are critical to the functioning of the registry. Please refer to
the requirements in Specification 6 (section 1.2) and Specification 10 (SLA Matrix) attached to the Registry Agreement; and
• resourcing plans for the initial implementation of, and ongoing maintenance for, this aspect of the criteria (number and description of personnel
roles allocated to this area).
A complete answer should include, but is not limited to: - A high-level SRS system description;
- Representative network diagram(s);
- Number of servers;
- Description of interconnectivity with other registry systems;
- Frequency of synchronization between servers; and
- Synchronization scheme (e.g., hot standby, cold standby).
Smart’s SRS system will be composed of 4 physical SRS servers running under a highly available load balancer pair distributed across our two data centers. Having been approved for the Specification 13 exemption which categorizes the *.SMART registry as a .Brand TLD, the SRS systems will only be accessible to its designated ICANN-accredited registrars.
The SRS server hardware specifications are as follows:
Hostname: SRS1
Hardware Specification : HP ProLiant DL380 Gen8
Processor: 2 x Intel 6-Core E5-2640 Processor (2.50GHz)
Memory 2 x 8GB 2Rx4 PC3L-10600R-9 Kit
Network Controller: 1 x HP Ethernet 1Gb 4-port 331T Adapter +
1 x HP Ethernet 1GbE 4P 331FLR FIO Adapter
Storage Controller: 1 x HP Smart Array P420/1GB FBWC Controller
Internal Storage: 6 x HP 300GB 6G SAS 10K 2.5in SC ENT HDD
FC Controller: 2 x HP 82Q 8Gb Dual Port PCI-e FC HBA
Optical: 1 x HP 12.7mm SATA DVD RW Jb Kit
Power Supply: 2 x HP 750W CS Gold Ht Plg Pwr Supply Kit
Management: HP Integrated Lights Out (iLO) – Advanced
Form Factor: 2U Rack Model
Support 3Y 24 x 7 6H CTR Hardware Support
Additional Peripherals: 10Gb Network - HP NC552SFP 10GbE 2p Server
Adapter
Red Hat Certified
Hardware https://access.redhat.com/ecosystem/hardware/951243
IPv4 Private IP address: 10.111.89.12/26
IPv6 IP address: 2407:9800:0:B::2/96
Location: IDC Pasig
Hostname: SRS2
Hardware Specification : HP ProLiant DL380 Gen8
Processor: 2 x Intel 6-Core E5-2640 Processor (2.50GHz)
Memory 2 x 8GB 2Rx4 PC3L-10600R-9 Kit
Network Controller: 1 x HP Ethernet 1Gb 4-port 331T Adapter +
1 x HP Ethernet 1GbE 4P 331FLR FIO Adapter
Storage Controller: 1 x HP Smart Array P420/1GB FBWC Controller
Internal Storage: 6 x HP 300GB 6G SAS 10K 2.5in SC ENT HDD
FC Controller: 2 x HP 82Q 8Gb Dual Port PCI-e FC HBA
Optical: 1 x HP 12.7mm SATA DVD RW Jb Kit
Power Supply: 2 x HP 750W CS Gold Ht Plg Pwr Supply Kit
Management: HP Integrated Lights Out (iLO) – Advanced
Form Factor: 2U Rack Model
Support 3Y 24 x 7 6H CTR Hardware Support
Additional Peripherals: 10Gb Network - HP NC552SFP 10GbE 2p Server
Adapter
Red Hat Certified
Hardware https://access.redhat.com/ecosystem/hardware/951243
IPv4 Private IP address: 10.111.89.13/26
IPv6 IP address: 2407:9800:0:B::3/96
Location: IDC Pasig
Hostname: SRS3
Hardware Specification : HP ProLiant DL380 Gen8
Processor: 2 x Intel 6-Core E5-2640 Processor (2.50GHz)
Memory 2 x 8GB 2Rx4 PC3L-10600R-9 Kit
Network Controller: 1 x HP Ethernet 1Gb 4-port 331T Adapter +
1 x HP Ethernet 1GbE 4P 331FLR FIO Adapter
Storage Controller: 1 x HP Smart Array P420/1GB FBWC Controller
Internal Storage: 6 x HP 300GB 6G SAS 10K 2.5in SC ENT HDD
FC Controller: 2 x HP 82Q 8Gb Dual Port PCI-e FC HBA
Optical: 1 x HP 12.7mm SATA DVD RW Jb Kit
Power Supply: 2 x HP 750W CS Gold Ht Plg Pwr Supply Kit
Management: HP Integrated Lights Out (iLO) – Advanced
Form Factor: 2U Rack Model
Support 3Y 24 x 7 6H CTR Hardware Support
Additional Peripherals: 10Gb Network - HP NC552SFP 10GbE 2p Server
Adapter
Red Hat Certified
Hardware https://access.redhat.com/ecosystem/hardware/951243
IPv4 Private IP address: 10.101.202.12/26
IPv6 IP address: 2407:9800:0:B:0:1::2/96
Location: Cebu
Hostname: SRS4
Hardware Specification : HP ProLiant DL380 Gen8
Processor: 2 x Intel 6-Core E5-2640 Processor (2.50GHz)
Memory 2 x 8GB 2Rx4 PC3L-10600R-9 Kit
Network Controller: 1 x HP Ethernet 1Gb 4-port 331T Adapter +
1 x HP Ethernet 1GbE 4P 331FLR FIO Adapter
Storage Controller: 1 x HP Smart Array P420/1GB FBWC Controller
Internal Storage: 6 x HP 300GB 6G SAS 10K 2.5in SC ENT HDD
FC Controller: 2 x HP 82Q 8Gb Dual Port PCI-e FC HBA
Optical: 1 x HP 12.7mm SATA DVD RW Jb Kit
Power Supply: 2 x HP 750W CS Gold Ht Plg Pwr Supply Kit
Management: HP Integrated Lights Out (iLO) – Advanced
Form Factor: 2U Rack Model
Support 3Y 24 x 7 6H CTR Hardware Support
Additional Peripherals: 10Gb Network - HP NC552SFP 10GbE 2p Server
Adapter
Red Hat Certified
Hardware https://access.redhat.com/ecosystem/hardware/951243
IPv4 Private IP address: 10.101.202.13/26
IPv6 IP address: 2407:9800:0:B:0:1::3/96
Location: Cebu
The SRS servers will have the following applications installed:
MariaDB client
Gnu Privacy Guard (GnuPG)
OpenSSL V0.9.8x from http://openssl.org
rsync included with the Redhat installation
xinetd included with the Redhat installation
Apache HTTPD V2.0.64 from a mirror site listed in http://www.apache.org
mod perl from http://perl.apache.org
Perl from www.perl.org
Spread server from http://www.spread.org
fping from http://fping.org
PARI/GP from ftp://pari.math.u-bordeaux.fr/pub/pari/unix/OLD
PHP included with the Redhat installation
mod_whoisng from https://gitlab.centralnic.com/centralnic/mod_whoisng
mod_epp from http://sourceforge.net/projects/aepps
The RegistryEngine base libraries provided by CentralNic
EPP, whois, and Registrar Console modules provided by CentralNic
Bind stealth DNS
Backend billing and administration modules provided by CentralNic
The servers’ operating system is Redhat 6.6 and all are routable from the load balancers. They will be installed implementing Smart IAPA’s (Information Asset Protection Assurance) minimum baseline standards (MBS) tailored after CIS RHEL 6 benchmark (Refer to Q24 Annex A for CIS Background).
All servers have redundant power supplies and redundant network interface cards.
These load balancers, in high availability pairs, will be deployed in the two data centers: the active HA pair in IDC Pasig, and the standby pair in Cebu City. All appliances have redundant power supplies sourced to different power distribution units (PDU’s). This set-up assures 99.999% service availability for registrars and WHOIS transactions. The load balancer virtual IP addresses routable from the internet via IPv4 and IPv6
The hardware specifications are as follows:
F5 Viprion 2400 Chassis/Viprion Blade 2150 Load balancer
HTTP Throughput : 5M Requests per sec
VPN throughput (SSL) : SSL at 2k Keys – 100,000 tps / SSL concurrent session 2.5M / Concurrent SSL VPN – 50K
SSL offloading : 5 Gbps
HTTP scan : 9 Gbps
Compression : 10 Gbps
SSL Throughput: 9 GBPs
CPU: 1 Intel Quad Core Xeon processor
Ports: 8 x 1/10 Gbps Interface
Memory: 32 GB
Power: Dual; 1200W, 100-240VAc, 47-63 Hz
Active pair virtual IP addresses:
HTTP, HTTPS (VIP)
IPv6 IP address: 2407:9800:0:F:0:0::2/96
Public IP address: 203.87.175.162/30
WHOIS (VIP)
IPv6 IP address: 2407:9800:0:F:0:0::3/96
Public IP address: 203.87.175.166/30
Location: IDC Pasig
Standby site pair virtual IP addresses:
HTTP, HTTPS (VIP)
IPv6 IP address: 2407:9800:0:F:0:1:0::2/96
Public IP address: 121.54.22.162/30
WHOIS (VIP)
IPv6 IP address: 2407:9800:0:F:0:1::3/96
Public IP address 121.54.22.166/30
Location: Cebu City
The SRS System
Smart’s Domain Name Registry System (DNRS) is based on CentralNic’s proprietary RegistryEngine software.
The RegistryEngine software uses the “LAMP” (Linux, Apache, MySQL/MariaDB, PHP) platform and has been tested and deployed on Red Hat Enterprise Linux 6x (and derivative operating systems). The Apache web server and PHP stack are installed on servers from the vendor’s package repository.
Transaction Flow
Below is the detailed transaction flow, in reference with the Diagram 1 (24 SRS attachment-1.PNG):
Registrars will connect to Smart’s registry through the SRS, which has 2 sets virtual public IP addresses: 2 IPv4 IP addresses and 2 IPv6 IP addresses.
These requests are received by the load balancer virtual IP’s open for HTTP (port 80), HTTPS (port 443) & EPP (port 700) connection. The load balancer forwards the requests to the active server. At any given time, there is only one active server for registrar requests. All the other servers are in “Maintenance” mode.
The registrars and the registry communicate with each other by using XML-format messages over a TLS-encrypted TCP session. The registrars send system requests to the registry as XML requests. The registry responds with an XML-format message.
The active server receives the registrar request (domain name creation, renewal, release, update, etc) and sends the request to the Back End. These validate the request and issue the necessary SQL commands to their respective MariaDB databases. Each DB sends its response to the active server. The server sends the response to the registrar.
The Back End systems in the DNRS synchronize their databases with each other.
The zone files are built by the servers as a scheduled job. The DNRS uses genzone process (included in the DNRS) to allow the registry to initiate the creation of DNS zone configuration files for all registered domains that have been set to delegate. The DNRS generates a run-log entry for this request recording the final status.
These updates will be transferred to the two stealth DNS servers, SRS-SDNS1 and SDNS2 using a shell script which will run every hour as a scheduled job. It is appended in the BIND configuration using dynamic DNS (DDNS).
Domain and zone updates in SNDS1 will be replicated to the two Authoritative/Publishing DNSes (APDNS1, APDNS2 and APDNS3) through incremental zone transfer (IXFR) via their public IP addresses.
Testing Procedures
The DNRS uses software provided by CentralNic. The software used is the same software deployed on CentralNic’s own registry system. It is also deployed on several other gTLD and ccTLD registry systems.
As a result, the software used for .SMART will be subject to extensive testing both prior to release (in QA, staging, and OT&E) and in production environments.
Disaster Recovery Scenarios
Scenario 1. One or more active server fails
There are 4 (four) SRS servers: SRS1 AND SRS2 in the active site, IDC; and SRS3 AND SRS4 in Cebu.
The DNRS servers are configured to have only 1 active server at any given time, hence, the load balancer is set-up to forward production traffic only to SRS1 initially.
The load balancers monitor the health of SRS servers through heartbeating and application-specific requests (i.e., https and whois protocols). It validates the resulting responses to determine if the server is able to process the traffic it will forward.
In the event that SRS1 fails due to hardware error (and similar events), the load balancer will automatically forward traffic to the second SRS server in IDC, SRS2. SRS2 will now be the sole active server and it will update the servers and SDNSes. Likewise, if the same happens for SRS2, the next available SRS server, SRS3 will assume its role as the active SRS and so on.
Hardware Upgrade
Smart’s Capacity Assessment Planning allows us to view the daily and monthly utilization of each server. When necessary, a machine hardware upgrade would suffice before horizontal expansion (i.e., addition of new load balancer pair, FE or backend servers).
Q24 Annex A. CIS
Excerpts from the CIS website, https://www.cisecurity.org:
“The Center for Internet Security (CIS) is a nonprofit organization focused on enhancing the cyber security readiness and response of public and private sector entities, with a commitment to excellence through collaboration. Through its four divisions--Security Benchmarks, Multi-State ISAC, Trusted Purchasing Alliance, and the Integrated Intelligence Center--CIS serves as a central resource in the development and delivery of high-quality, timely products and services to assist our partners in government, academia, the private sector and the general public in improving their cyber security posture.
The CIS Security Benchmarks division provides well-defined, unbiased and consensus-based industry best practices to help organizations assess and improve their security. Resources include secure configuration benchmarks, automated configuration assessment tools and content, security metrics and security software product certifications.
The Security Benchmarks division is recognized as a trusted, independent authority that facilitates the collaboration of public and private industry experts to achieve consensus on practical and actionable solutions. Because of this reputation, our resources are recommended as industry-accepted system hardening standards and are used by organizations in meeting compliance requirements for FISMA, PCI, HIPAA and other security requirements.”
Smart’s IAPA’s (Information Asset Protection Assurance) Department recommends all servers in production to implement a minimum baseline security standard (MBS) based on CIS’ Red Hat Enterprise Linux 6 Benchmark for x86 and x64 platforms.
25. Extensible Provisioning Protocol (EPP): provide a detailed description of the interface with registrars, including how the applicant will comply with EPP in RFCs 3735 (if applicable), and 5730-5734.
If intending to provide proprietary EPP extensions, provide documentation consistent with RFC 3735, including the EPP templates and schemas that will be used.
Describe resourcing plans (number and description of personnel roles allocated to this area).
A complete answer is expected to be no more than 5 pages. If there are proprietary EPP extensions, a complete answer is also expected to be no more than 5 pages per EPP extension.
The Extensible Provisioning Protocol (EPP) 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 domains, nameservers and contact details held by domain registries. It is widely deployed in the gTLD and ccTLD registry space.
CentralNic’s implementation of EPP has been developed and operated since 2005, and can support significant load in terms of registrars, sessions and transaction volumes. CentralNic's EPP implementation is fully compliant with the following RFC specifications:
5730 - Base Protocol
5731 - Domain Names
5732 - Host Objects
5733 - Contact Objects
5734 - TCP Transport
3735 - Extension Guidelines
3915 - RGP Extension
5910 - DNSSEC Extension
Description of Interface
EPP is a stateful XML protocol layered over TCP (see RFC 5734). Protected using lower-layer security protocols, clients exchange identification, authentication, and option information, and 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).
EPP provides four basic service elements: service discovery, commands, responses, and an extension framework that supports definition of managed objects and the relationship of protocol requests and responses to those objects.
EPP servers respond 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, queries, and transform commands. Session management commands are used to establish and end persistent sessions with an EPP server. Query commands perform read-only object information retrieval operations. Transform commands perform read-write object management operations.
Commands are processed by a server in the order they are received from a client. The protocol includes features that allow for offline review of transform commands before the requested action is completed. In such situations, the response clearly notes that the command has been received but that the requested action is pending. 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.
EPP uses XML namespaces to provide an extensible object management framework and to identify schemas required for XML instance parsing and validation. These namespaces and schema definitions are used to identify both the base protocol schema and the schemas for managed objects.
Objects Supported
Registrars may create and manage the following object types in the RegistryEngine EPP system:
domains (RFC 5731)
host objects (RFC 5732)
contact objects (RFC 5733)
Commands Supported
The CentralNic RegistryEngine EPP system supports the following EPP commands:
<hello> - retrieve the <greeting> from the server
<login> and <logout> - session management
<poll> - message queue management
<check> - availability check
<info> - object information
<create> - create object
<update> - update object
<renew> - renew object
<delete> - delete object
<transfer> - manage object transfer
EPP State Diagram
Figure 25.1 describes the state machine for the EPP system. 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.
EPP Object Policies
The following policies apply to objects provisioned via the EPP system:
Domains
Domains must comply with the syntax described in RFC 1035 §2.3.1. Additionally, the first label of the name must be between 1 and 63 characters in length.
Domains must have a registrant attribute which is associated with a contact object in the database.
Domains must have an administrative contact attribute which is associated with a contact object in the database.
Domains must have a technical contact which attribute is associated with a contact object in the database.
Domains may have an billing contact attribute which is associated with a contact object in the database.
Domains may have between 0 (zero) and 13 DNS servers. A domain with no name servers will not resolve and no records will be published in the DNS
The host object model for domains is used rather than the host attribute model.
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.
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.
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.
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. Domain names may not be renewed more than ten years into the future.
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.
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.
Only the sponsoring registrar of the domain may submit <update>, <renew> or <delete> commands for the domain.
Host Objects
Host names must comply with RFC 1035. The maximum length of the host name may not exceed 255 characters.
In-bailiwick hosts must have at least one IPv4 or IPv6 address. They may have additional IP addresses of either type.
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.
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.
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.
A host cannot be deleted if one or more domains are delegated to it (the registry deletes hosts to remove orphan glue, see §28).
Inter-registrar transfers are not permitted.
Only the sponsoring registrar of the host may submit <update> or <delete> commands for the object.
Contact Objects
Contact IDs may only contain characters from the set [A-Z, 0-9, . (period), - (hyphen) and - (underscore)] and are case-insensitive.
Phone numbers and email addresses must be valid as described in RFC 5733 §2.5 and §2.6.
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".
The <contact:org>, <contact:sp>, <contact:pc>, <contact:phone> and <contact:fax> elements are optional.
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.
A contact cannot be deleted if one or more domains are associated with it.
Only the sponsoring registrar of the contact may submit <update> or <delete> commands for the object.
EPP Extensions
The CentralNic RegistryEngine EPP system supports the following EPP extensions. The implementations fully comply with the required specifications.
Registry Grace Period Mapping
Various grace periods and hold periods are supported by the Registry Grace Period mapping, as defined in RFC 3915. This is described further in §27.
DNSSEC Security Extensions Mapping
Registrars may submit Delegation Signer (DS) record information for domains under their sponsorship. This permits the establishment of a secure chain-of-trust for DNSSEC validation.
The CentralNic RegistryEngine supports the specification defined in RFC 5910. This supports two interfaces: the DS Data Interface and Key Data Interface. The RegistryEngine supports the former interface (DS Data), where registrars submit the keytag, algorithm, digest type and digest for DS records as XML elements, rather than as key data. Key data is stored if provided as a child element of the <secDNS:dsData> element. The maxSigLife element is optional in the specification and is not currently supported.
Launch Phase Extension
CentralNic has assisted development of a standard EPP extension for 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 domains with claimed rights such as a registered trademark. The extension is currently described in the Internet-Draft draft-ietf-eppext-launchphase-02. It is intended that this draft will eventually be published as an RFC.
The RegistryEngine system implements this extension and will support the most recent version of the draft during the initial launch of .SMART. Once .SMART enters General Availability, this extension will no longer be available for use by registrars.
Fee Extension
The Fee extension provides a means for registrars to query the fees applicable to billable transactions such as domain name registration, renewal, and transfer. The specification for this extension was developed by Gavin Brown, CentralNic's CTO, and is in widespread use among other gTLD registries. The extension is specified in an Internet-Draft at http://tools.ietf.org/html/draft-brown-epp-fees-02.
Registrar Credentials and Access Control
Registrars are issued with a username (their registrar ID) and a password. 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.
RFC 5730 requires "mutual, strong client-server authentication". SMART requires that all registrars connect using an SSL certificate. This certificate may be obtained from a recognised certificate authority, or it may be a self-signed certificate registered with SMART via the Registrar Console. Registrar officers with the "Management" access level can upload SSL certificates for their account.
Session Limits and Transaction Volumes
During normal operations, there are no 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, during initial launch periods when there is an increased demand from registrars, the number of concurrent connections per registrar will be restricted and a "speed limit" imposed on each connection, to ensure equal access to all registrars.
Transaction Logging and Reporting
All "transform" commands are logged. Transform commands are: <create>, <renew>, <update>, <delete> and <transfer>. The system logs the time and date when the command was received, the registrar that submitted it, the request and response frames, the result code and message. All commands, whether successful or not, are logged.
The transaction log is stored in the primary registry database. Registrars have access to the log for their account via the Registrar Console. The log viewer permits filtering by command, object type, object ID (domain, 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.
EPP Message Queue
The EPP protocol provides a message queue to provide registrars with notifications for out-of-band events. CentralNic currently supports the following EPP message notifications:
approved inbound transfer
rejected inbound transfer
new outbound transfer
cancelled outbound transfer
approved or rejected domain registration request (where TLD policy requires out-of-band approval of <domain:create> requests, such as during Sunrise)
Registrar Support, Software Toolkit
CentralNic has supported EPP for many years. CentralNic has released a number of open source client libraries for several popular programming languages. These are used by registrars and registries around the world. CentralNic maintains the following open source EPP libraries:
Net::EPP, a general purpose EPP library for Perl.
Preppi, a graphical EPP client written in Perl.
Pepper, a command line EPP client written in Perl.
Net_EPP, a PHP client class for EPP.
Simpleepp, a Python client class for EPP.
tx-epp-proxy, a EPP reverse proxy for shared-nothing client architectures written in Python.
These libraries are available for anyone to use, at no cost. CentralNic develops these libraries, and accepts submissions and bug reports from users around the world.
CentralNic's open source software is published at https://gitlab.centralnic.com/.
Quality Assurance, RFC Compliance
To ensure that its EPP system fully complies with the relevant specifications documents, CentralNic has implemented the following QA systems:
Schema Validation
The EPP system automatically validates all response frames against the XSD schema definitions provided in the RFCs. Should a non-validating response be sent to a registrar, an alert is raised with the NOC to be investigated and corrected.
Multi-stage Deployment and Testing
EPP system code is developed, tested and deployed in a multi-stage environment:
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.
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).
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.
Registrar Feedback
Registrars are provided with an easy way to report issues with the EPP system, and many perform schema validation 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.
Resourcing
Smart has two headquarters dedicated for TSD (Technical Services Division) operations – IDC Pasig and Cebu. Smart L1 Operations is operating on a 24 x 7 mode in both sites. There are 4 Smart TSD (Technology Services Division) personnel per shift manning the operations requirements of the company and one shift supervisor.
Smart SRS system will be included in their day to day responsibility – including the monitoring, escalation, backup of the system. Each site has an operations manager responsible for the day to day operations. The operations managers reports to one department head. The main site is IDC Pasig that servers as the primary site. The site in Cebu serves as the DR site.
Below are the manpower provided for monitoring of the SRS/WHOIS system:
Operations Head: 1 Department Head
Level 1 Operations Manager: 2 Operations Manager
Level 1 Operations Shifting Personnel: 12 Staff
Level 2 Operations Manager: 1 Systems Administration Manager
Level 2 Operations: 2 Systems Administrators
26. Whois: describe
- how the applicant will comply with Whois specifications for data objects, bulk access, and lookups as defined in Specifications 4 and 10 to the Registry Agreement;
- how the Applicant's Whois service will comply with RFC 3912; and
- resourcing plans for the initial implementation of, and ongoing maintenance for, this aspect of the criteria (number and description of personnel roles allocated to this area).
A complete answer should include, but is not limited to:
- A high-level Whois system description;
- Relevant network diagram(s);
- IT and infrastructure resources (e.g., servers, switches, routers and other components);
- Description of interconnectivity with other registry systems; and
Frequency of synchronization between servers.
To be eligible for a score of 2, answers must also include:
- Provision for Searchable Whois capabilities; and
- A description of potential forms of abuse of this feature, how these risks will be mitigated, and the basis for these descriptions
A complete answer is expected to be no more than 5 pages.
Smart’s publicly accessible Whois service provides a reliable, stable, standards-compliant platform for supporting the .SMART registry.
The .SMART Whois supports a thick registry model which contains the technical and social contact information associated with the registrant.
WHOIS Infrastructure
(Refer to 26 Whois attachment-1.jpg)
The WHOIS functions of Smart’s gTLD reside on the SRS systems. Network diagram is attached.
There are 4 physical WHOIS servers running under a highly available load balancer pair, and 3 physical Backend servers, distributed across two data centers.
The hardware specifications of the servers are as follows:
Hostname: SRS1
Hardware Specification : HP ProLiant DL380 Gen8
Processor: 2 x Intel 6-Core E5-2640 Processor (2.50GHz)
Memory 2 x 8GB 2Rx4 PC3L-10600R-9 Kit
Network Controller: 1 x HP Ethernet 1Gb 4-port 331T Adapter +
1 x HP Ethernet 1GbE 4P 331FLR FIO Adapter
Storage Controller: 1 x HP Smart Array P420/1GB FBWC Controller
Internal Storage: 6 x HP 300GB 6G SAS 10K 2.5in SC ENT HDD
FC Controller: 2 x HP 82Q 8Gb Dual Port PCI-e FC HBA
Optical: 1 x HP 12.7mm SATA DVD RW Jb Kit
Power Supply: 2 x HP 750W CS Gold Ht Plg Pwr Supply Kit
Management: HP Integrated Lights Out (iLO) – Advanced
Form Factor: 2U Rack Model
Support 3Y 24 x 7 6H CTR Hardware Support
Additional Peripherals: 10Gb Network - HP NC552SFP 10GbE 2p Server
Adapter
Red Hat Certified
Hardware https://access.redhat.com/ecosystem/hardware/951243
IPv4 Private IP address: 10.111.89.12/26
IPv6 IP address: 2407:9800:0:B::2/96
Location: IDC Pasig
Hostname: SRS2
Hardware Specification : HP ProLiant DL380 Gen8
Processor: 2 x Intel 6-Core E5-2640 Processor (2.50GHz)
Memory 2 x 8GB 2Rx4 PC3L-10600R-9 Kit
Network Controller: 1 x HP Ethernet 1Gb 4-port 331T Adapter +
1 x HP Ethernet 1GbE 4P 331FLR FIO Adapter
Storage Controller: 1 x HP Smart Array P420/1GB FBWC Controller
Internal Storage: 6 x HP 300GB 6G SAS 10K 2.5in SC ENT HDD
FC Controller: 2 x HP 82Q 8Gb Dual Port PCI-e FC HBA
Optical: 1 x HP 12.7mm SATA DVD RW Jb Kit
Power Supply: 2 x HP 750W CS Gold Ht Plg Pwr Supply Kit
Management: HP Integrated Lights Out (iLO) – Advanced
Form Factor: 2U Rack Model
Support 3Y 24 x 7 6H CTR Hardware Support
Additional Peripherals: 10Gb Network - HP NC552SFP 10GbE 2p Server
Adapter
Red Hat Certified
Hardware https://access.redhat.com/ecosystem/hardware/951243
IPv4 Private IP address: 10.111.89.13/26
IPv6 IP address: 2407:9800:0:B::3/96
Location: IDC Pasig
Hostname: SRS3
Hardware Specification : HP ProLiant DL380 Gen8
Processor: 2 x Intel 6-Core E5-2640 Processor (2.50GHz)
Memory 2 x 8GB 2Rx4 PC3L-10600R-9 Kit
Network Controller: 1 x HP Ethernet 1Gb 4-port 331T Adapter +
1 x HP Ethernet 1GbE 4P 331FLR FIO Adapter
Storage Controller: 1 x HP Smart Array P420/1GB FBWC Controller
Internal Storage: 6 x HP 300GB 6G SAS 10K 2.5in SC ENT HDD
FC Controller: 2 x HP 82Q 8Gb Dual Port PCI-e FC HBA
Optical: 1 x HP 12.7mm SATA DVD RW Jb Kit
Power Supply: 2 x HP 750W CS Gold Ht Plg Pwr Supply Kit
Management: HP Integrated Lights Out (iLO) – Advanced
Form Factor: 2U Rack Model
Support 3Y 24 x 7 6H CTR Hardware Support
Additional Peripherals: 10Gb Network - HP NC552SFP 10GbE 2p Server
Adapter
Red Hat Certified
Hardware https://access.redhat.com/ecosystem/hardware/951243
IPv4 Private IP address: 10.101.202.12/26
IPv6 IP address: 2407:9800:0:B:0:1::2/96
Location: Cebu
Hostname: SRS4
Hardware Specification : HP ProLiant DL380 Gen8
Processor: 2 x Intel 6-Core E5-2640 Processor (2.50GHz)
Memory 2 x 8GB 2Rx4 PC3L-10600R-9 Kit
Network Controller: 1 x HP Ethernet 1Gb 4-port 331T Adapter +
1 x HP Ethernet 1GbE 4P 331FLR FIO Adapter
Storage Controller: 1 x HP Smart Array P420/1GB FBWC Controller
Internal Storage: 6 x HP 300GB 6G SAS 10K 2.5in SC ENT HDD
FC Controller: 2 x HP 82Q 8Gb Dual Port PCI-e FC HBA
Optical: 1 x HP 12.7mm SATA DVD RW Jb Kit
Power Supply: 2 x HP 750W CS Gold Ht Plg Pwr Supply Kit
Management: HP Integrated Lights Out (iLO) – Advanced
Form Factor: 2U Rack Model
Support 3Y 24 x 7 6H CTR Hardware Support
Additional Peripherals: 10Gb Network - HP NC552SFP 10GbE 2p Server
Adapter
Red Hat Certified
Hardware https://access.redhat.com/ecosystem/hardware/951243
IPv4 Private IP address: 10.101.202.13/26
IPv6 IP address: 2407:9800:0:B:0:1::3/96
Location: Cebu
The servers will have the following applications installed:
MariaDB client
Gnu Privacy Guard (GnuPG)
OpenSSL V0.9.8x from http://openssl.org
rsync included with the Redhat installation
xinetd included with the Redhat installation
Apache HTTPD V2.0.64 from a mirror site listed in http://www.apache.org
mod perl from http://perl.apache.org
Perl from www.perl.org
Spread server from http://www.spread.org
fping from http://fping.org
PARI/GP from ftp://pari.math.u-bordeaux.fr/pub/pari/unix/OLD
PHP included with the Redhat installation
mod_whoisng from https://gitlab.centralnic.com/centralnic/mod_whoisng
mod_epp from http://sourceforge.net/projects/aepps
The RegistryEngine base libraries provided by CentralNic
EPP, whois, and Registrar Console modules provided by CentralNic
Backend billing and administration modules provided by CentralNic
The servers’ operating system is Red Hat 6.6 and all are routable from the load balancers. They will be installed implementing Smart IAPA’s (Information Asset Protection Assurance) minimum baseline standards (MBS) tailored after CIS RHEL 6 benchmark (Refer to Q26 Annex A for CIS Background).
The WHOIS servers will serve as the back-end of the load balancers. These load balancers will be deployed in the two data centers: the active HA pair in IDC Pasig, and the standby load balancer in Cebu City.
All servers have redundant power supplies and redundant network interface cards.
The WHOIS server application uses software provided by CentralNic. The software used is the same software deployed on CentralNic’s own WHOIS system. It is also deployed on several other gTLD and ccTLD registry systems.
All appliances have redundant power supplies sourced to different power distribution units (PDU’s). This set-up assures 99.999% service availability for registrars and WHOIS transactions. The load balancer virtual IP addresses are routable from the internet via IPv4 and IPv6.
The hardware specifications are as follows:
F5 Viprion 2400 Chassis/Viprion Blade 2150 Load balancer
HTTP Throughput : 5M Requests per sec
VPN throughput (SSL) : SSL at 2k Keys – 100,000 tps / SSL concurrent session 2.5M / Concurrent SSL VPN – 50K
SSL offloading : 5 Gbps
HTTP scan : 9 Gbps
Compression : 10 Gbps
SSL Throughput: 9 GBPs
CPU: 1 Intel Quad Core Xeon processor
Ports: 8 x 1/10 Gbps Interface
Memory: 32 GB
Power: Dual; 1200W, 100-240VAc, 47-63 Hz
Active pair virtual IP addresses:
HTTP, HTTPS (VIP)
IPv6 IP address: 2407:9800:0:B:0:0::2/96
Public IP address: 203.87.175.162/30
WHOIS (VIP)
IPv6 IP address: 2407:9800:0:B:0:1::2/96
Public IP address: 203.87.175.166/30
Location: IDC Pasig
Standby site virtual IP addresses:
HTTP, HTTPS (VIP)
IPv6 IP address: 2407:9800:0:B:1:0::2/96
Public IP address: 121.54.22.162/30
WHOIS (VIP)
IPv6 IP address: 2407:9800:0:B:1:1::2/96
Public IP address: 121.54.22.166/30
Location: Cebu City
WHOIS Transaction Flow
WHOIS queries for *.smart gTLD will be forwarded to an internet routable hostname. This hostname has 2 sets virtual public IP addresses: 2 IPv4 IP addresses and 2 IPv6 IP addresses.
A server can only be in one of the following modes: (1) registrar – active for registrar transactions and on standby for WHOIS or (2) whois – active for WHOIS and on standby for registrar transactions.
At any given time, only one of the four servers is in “registrar” mode. This receives EPP traffic from the registrars. All four (4) available servers are on “WHOIS” mode, ready to receive WHOIS transactions but on standby for registrar traffic.
The requests from WHOIS clients are received by the load balancer virtual IP’s open for WHOIS connection (port 43). The load balancer forwards the WHOIS requests to any of the three active WHOIS servers.
Smart will be remain as the centralized WHOIS database even if *.smart gTLD will be offered to different registars.
Testing Procedure
The WHOIS functionality for Smart gTLD was installed in virtual environment in the SDC cloud, with the SRS test bed.
Command line WHOIS queries were sent to the WHOIS virtual server from the two test registrar servers. Likewise, web based WHOIS queries were also tested from the same registrar test beds.
Minimum WHOIS Reply
Smart supports thick WHOIS registry, hence, WHOIS queries for second level domains for *.smart will generate the following reply:
Domain Name: EXAMPLE.TLD
Domain ID: D1234567-TLD
WHOIS Server: whois.smart
Referral URL: http://www.example.tld
Updated Date: 2009-05-29T20:13:00Z
Creation Date: 2000-10-08T00:45:00Z
Registry Expiry Date: 2010-10-08T00:44:59Z
Sponsoring Registrar: EXAMPLE REGISTRAR LLC
Sponsoring Registrar IANA ID: 5555555
Domain Status: clientDeleteProhibited
Domain Status: clientRenewProhibited
Domain Status: clientTransferProhibited
Domain Status: serverUpdateProhibited
Registrant ID: 5372808-ERL
Registrant Name: SMART REGISTRANT
Registrant Organization: Smart Communications, Inc.
Registrant Street: Smart Tower 6799 Ayala Ave.
Registrant City: Makati City
Registrant State/Province: Metro Manila
Registrant Postal Code: 1226
Registrant Country: PH
Registrant Phone: +632 811 0211
Registrant Phone Ext: 1234
Registrant Fax: +632 811 0211
Registrant Fax Ext: 4321
Registrant Email: DomainRegistrar@smart
Admin ID: 5372809-SMR
Admin Name: SMART REGISTRANT
Admin Organization: Smart Communications, Inc.
Admin Street: Smart Tower 6799 Ayala Ave.
Admin City: Makati City
Admin State/Province: Metro Manila
Admin Postal Code: 1226
Admin Country: PH
Admin Phone: +632 811 0211
Admin Phone Ext: 1234
Admin Fax: +632 811 0211
Admin Fax Ext:
Admin Email: DomainRegistrar@smart
Tech ID: 5372811-SMR
Tech Name: SMART REGISTRANT
Tech Organization: Smart Communications, Inc.
Tech Street: Smart Tower 6799 Ayala Ave.
Tech City: Makati City
Tech State/Province: Metro Manila
Tech Postal Code: 1226
Tech Country: PH
Tech Phone: +632 811 0211
Tech Phone Ext: 1234
Tech Fax: +632 811 0211
Tech Fax Ext: 93
Tech Email: DomainRegistrar@smart
Name Server: ns1.smart
Name Server: v
DNSSEC: signedDelegation
DNSSEC: unsigned
>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<
Disaster Recovery Scenarios
The WHOIS service of Smart gTLD resides in a highly available infrastructure set-up. The SRS also resides in the same infrastructure; hence they share the same disaster recovery fallback procedures:
Scenario 1. One or more of the WHOIS servers fails
There are 4 (four) WHOIS servers, two (2) in the active site, WHOIS1 and WHOS2 in IDC; and two (2) in the HA site, WHOIS3 and WHOIS4 in Cebu.
The F5 load balancers distribute WHOIS queries among these four (4) WHOIS servers taking into account server load and bandwidth availability.
The load balancers monitor the health of the WHOIS servers through heartbeating and application-specific requests (i.e., whois protocols). It validates the resulting responses to determine if the server is able to process the traffic it will forward. If one of these four (4) fails, the load balancer will not forward traffic to the node that is offline.
Hardware Upgrade
Smart’s Capacity Assessment Planning allows us to view the daily and monthly utilization of each server. When necessary, a machine hardware upgrade would suffice before horizontal expansion (i.e., addition of new load balancer pair, or WHOIS servers).
Resourcing Plans
Smart has two headquarters dedicated for TSD (Technical Services Division) operations – IDC Pasig and Cebu. Smart L1 Operations is operating on a 24 x 7 mode in both sites. There are 4 Smart TSD (Technology Services Division) personnel per shift manning the operations requirements of the company and one shift supervisor.
Smart SRS system will be included in their day to day responsibility – including the monitoring, escalation, backup of the system. Each site has an operations manager responsible for the day to day operations. The operations managers reports to one department head. The main site is IDC Pasig that servers as the primary site. The site in Cebu serves as the DR site.
Below are the manpower provided for monitoring of the SRS/WHOIS system:
Operations Head: 1 Department Head
Level 1 Operations Manager: 2 Operations Manager
Level 1 Operations Shifting Personnel: 12 Staff
Level 2 Operations Manager: 1 Systems Administration Manager
Level 2 Operations: 2 Systems Administrators
Q26 Annex A. CIS
Excerpts from the CIS website, https://www.cisecurity.org:
“The Center for Internet Security (CIS) is a nonprofit organization focused on enhancing the cyber security readiness and response of public and private sector entities, with a commitment to excellence through collaboration. Through its four divisions--Security Benchmarks, Multi-State ISAC, Trusted Purchasing Alliance, and the Integrated Intelligence Center--CIS serves as a central resource in the development and delivery of high-quality, timely products and services to assist our partners in government, academia, the private sector and the general public in improving their cyber security posture.
The CIS Security Benchmarks division provides well-defined, unbiased and consensus-based industry best practices to help organizations assess and improve their security. Resources include secure configuration benchmarks, automated configuration assessment tools and content, security metrics and security software product certifications.
The Security Benchmarks division is recognized as a trusted, independent authority that facilitates the collaboration of public and private industry experts to achieve consensus on practical and actionable solutions. Because of this reputation, our resources are recommended as industry-accepted system hardening standards and are used by organizations in meeting compliance requirements for FISMA, PCI, HIPAA and other security requirements.”
Smart’s IAPA’s (Information Asset Protection Assurance) Department recommends all servers in production to implement a minimum baseline security standard (MBS) based on CIS’ Red Hat Enterprise Linux 6 Benchmark for x86 and x64 platforms.
27. Registration Life Cycle: provide a detailed description of the proposed registration lifecycle for domain names in the proposed gTLD. The description must:
- explain the various registration states as well as the criteria and procedures that are used to change state;
- describe the typical registration lifecycle of create/update/delete and all intervening steps such as pending, locked, expired, and transferred that may apply;
- clearly explain any time elements that are involved - for instance details of add-grace or redemption grace periods, or notice periods for renewals or transfers; and
- describe resourcing plans for this aspect of the criteria (number and description of personnel roles allocated to this area).
The description of the registration lifecycle should be supplemented by the inclusion of a state diagram, which captures definitions, explanations of trigger points, and transitions from state to state.
If applicable, provide definitions for aspects of the registration lifecycle that are not covered by standard EPP RFCs.
A complete answer is expected to be no more than 5 pages.
The life-cycle of a typical .SMART domain name will be as follows.
1. Internal registrant goes through the Internal Registrar’s website to apply for a domain name. The registrant fills up the application form in the website with the necessary information, including the following:
a. the SLD to be registered
b. the authoritative DNS servers for the SLD
c. the department⁄unit requesting for the SLD
No registry staff is involved in this step.
2. The Internal Registrar queries the SMART Registry to determine whether the requested SLD is available. If available, the application is marked as “PENDING.” If not available, the application is rejected.
No registry staff is involved in this step.
3. The “PENDING” application is kept until all the necessary requirements are fulfilled. The registrant has seven days to fulfill all the necessary requirements. After seven days, all “PENDING” applications are removed from the system.
No registry staff is involved in this step.
4. The details about the “PENDING” application are e-mailed to the head of the department⁄unit for confirmation.
No registry staff is involved in this step.
5. When confirmation is received from the Department⁄Unit head, the application is approved and marked as “ACTIVE.” It is registered for a period of one (1) year.
There will be at least one registry staff member, designated as the “Approver”, who manually checks the confirmation e-mail from the Department⁄Unit Head. The Approver manually sets the “PENDING” domain name to “ACTIVE.”
6. Two months before the expiration date, an e-mail is sent to the registrant reminding the registrant of the date of expiration. The registration is marked as “EXPIRING.”
No registry staff is involved in this step.
7. One month before the expiration date, an e-mail is sent to the registrant reminding the registrant of the date of expiration. No registry staff is involved in this step.
8. “EXPIRING” domains may be renewed at any time by the registrant by replying to any of the two reminder e-mails. No registry staff is involved in this step.
9. “EXPIRING” domains are automatically deleted from the Registry upon the date of expiration. No registry staff is involved in this step.
28. Abuse Prevention and Mitigation: Applicants should describe the proposed policies and procedures to minimize abusive registrations and other activities that have a negative impact on Internet users. A complete answer should include, but is not limited to:
- An implementation plan to establish and publish on its website a single abuse point of contact responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning all names registered in the TLD through all registrars of record, including those involving a reseller;
- Policies for handling complaints regarding abuse;
- Proposed measures for removal of orphan glue records for names removed from the zone when provided with evidence in written form that the glue is present in connection with malicious conduct (see Specification 6); and
- Resourcing plans for the initial implementation of, and ongoing maintenance for, this aspect of the criteria (number and description of personnel roles allocated to this area).
To be eligible for a score of 2, answers must include measures to promote Whois accuracy as well as measures from one other area as described below.
- Measures to promote Whois accuracy (can be undertaken by the registry directly or by registrars via requirements in the Registry-Registrar Agreement (RRA)) may include, but are not limited to:
- Authentication of registrant information as complete and accurate at time of registration. Measures to accomplish this could include performing background checks, verifying all contact information of principals mentioned in registration data, reviewing proof of establishment documentation, and other means
- Regular monitoring of registration data for accuracy and completeness, employing authentication methods, and establishing policies and procedures to address domain names with inaccurate or incomplete Whois data; and
- If relying on registrars to enforce measures, establishing policies and procedures to ensure compliance, which may include audits, financial incentives, penalties, or other means. Note that the requirements of the RAA will continue to apply to all ICANN-accredited registrars.
- A description of policies and procedures that define malicious or abusive behavior, capture metrics, and establish Service Level Requirements for resolution, including service levels for responding to law enforcement requests. This may include rapid takedown or suspension systems and sharing information regarding malicious or abusive behavior with industry partners;
- Adequate controls to ensure proper access to domain functions (can be undertaken by the registry directly or by registrars via requirements in the Registry-Registrar Agreement (RRA)) may include, but are not limited to:
- Requiring multi-factor authentication (i.e., strong passwords, tokens, one-time passwords) from registrants to process update, transfers, and deletion requests;
- Requiring multiple, unique points of contact to request and/or approve update, transfer, and deletion requests; and
- Requiring the notification of multiple, unique points of contact when a domain has been updated, transferred, or deleted.
A complete answer is expected to be no more than 20 pages.
The .SMART gTLD is for the exclusive use of the company and its subsidiaries, its authorized partners, and its subscribers. Registration in .SMART is not open to the general public. By controlling every registration in the .SMART gTLD, the company will totally eliminate abusive registrations and other activities that affect the legal rights of others.
A domain name in the .SMART gTLD is considered to be a valid domain name if it meets at least one of the following characteristics:
1) it corresponds to a bona fide offering of goods or services
2) it is not intended to mislead or divert consumers away or tarnish the trademark or service mark of any mark-holders
3) it corresponds to the name that the company’s subsidiary, authorized partner, or product is commonly known
4) it is a generic or a descriptive name which the company has fair use of
Only valid domain names may be registered in the .SMART gTLD.
An Abusive Registration is one which is not a valid domain name and which
1) was registered to take an unfair advantage of or to the detriment of a Complainantʹs Rights or
2) has been used in a manner which has taken unfair advantage of or has been unfairly detrimental to the Complainantʹs Rights
Despite the policy of registering only valid domain names, it is possible for the company or its employees to commit mistakes. These unwitting mistakes will be flagged when a complainant notifies the company of its specific concerns and details the specific conduct the complainant believes as an abusive registration. The company will publish in its website a single abuse point of contact responsible for addressing complaints of abusive registrations. At any given time, at least one staff member of the SMART operations staff is tasked with the responsibility of ensuring that the
The following details the .SMART policy and procedures for handling complaints of abusive registrations:
COMMUNICATION
1) All complaints must be in English or Filipino and must be in written form.
2) Complaints must be submitted by fax, e-mail, or registered mail. In the .SMART website, the registry will publish an e-mail address, fax number(s), and postal address to receive complaints of abuse.
3) E-mailed complaints must be sent as plain text and attachments must be in PDF.
4) All complaints are deemed to have been received on:
i. if sent by fax , on the date transmitted; or
ii. if sent by registered mail, on the day of delivery; or
iii. if sent via the Internet, on the date that the e-mail was received by .SMART’s mail server(s);
iv. and, unless otherwise provided in this procedure, the time periods provided for under the Policy and this Procedure shall be calculated accordingly.
COMPLAINTS
1) Any person or organization may submit a complaint of Abusive Registration following the procedures in this document.
2) The complaint shall:
a) not exceed 5000 words
b) specify the complete name and address (postal and e-mail) of the complainant
c) specify the domain name which the complainant alleges to be an Abusive Registration
and
i) if alleging violation of complainant’s rights,
I. the rights the complainant claims in the name or mark
II. the name or mark the complainant claims it has rights to
III. documentary evidence to prove such rights over the name or mark
ii) if not alleging violation of complainant’s rights, describe the grounds on which the complaint is made and why the domain name should be considered to be an Abusive Registration in the hands of the Respondent
REGISTRY’S ACTION
.SMART will check that the complaint complies with the form prescribed in this document. If non-compliant, .SMART will immediately inform the complainant of the deficiencies in the filed complaint and allow the complainant to file a modified complaint to remedy the deficiencies. If the complaint is valid in form and substance, the registry will forward the complaint to the registrant of the domain, together with an explanatory covering letter. The registry will handle all complaints within three (3) working days.
REGISTRANT’S RESPONSE
Within five (5) working days after receipt of the complaint, the respondent registrant must submit its reply to the complaint. The reply shall:
a) not exceed 5000 words
b) specify the grounds of the registrant to rebut the complaint of an Abusive Registration:
i) if violation of complainant’s rights is alleged,
I. the rights the registrant claims in the name or mark
II. the name or mark the registrant claims it has rights to
III. documentary evidence to prove such rights over the name or mark
ii) if violation of complainant’s rights is not alleged, describe the grounds on why the domain name should not be considered to be an Abusive Registration
The Registry will forward the response to the complainant within three (3) working days after receipt of the same.
Should the registrant fail to respond to the complaint, the complaint is deemed to be submitted for resolution.
COMPLAINANT’S REPLY
Within five (5) days of receiving the respondent’s response, the complainant must submit a reply to the response. The reply shall:
a) not exceed 2000 words and be solely restricted to the issues raised by the respondent and not repeat the issues raised in the initial complaint.
or
b) indicate that the complainant has no further reply to the response of the respondent
REGISTRY’S DECISION
Within three (3) working days of receiving the complainant’s reply or the failure of the registrant to reply, the Registry will issue its decision. Should the Registry find that the assailed domain name does not meet any one of the following criteria:
• it corresponds to a bona fide offering of goods or services
• it is not intended to mislead or divert consumers away or tarnish the trademark or service mark of the complainant
• it corresponds to the name that the company’s subsidiary, authorized partner, or product is commonly known
• it is a generic or a descriptive name which the company has fair use of
then the Registry will issue an adverse ruling against the respondent registrant.
Should the assailed domain meet one of the above criteria, the complaint will be dismissed. The parties to the complaint will be informed of the decision within one (1) working day after the decision is made.
Should the assailed registration be found to be an Abusive Registration, it will be removed from the .SMART registry within two (2) working days.
Should the complaint be dismissed by the Registry, the Complainant may opt to avail of the different ICANN-mandated Rights Protection Mechanism (RPM) to which .SMART adheres.
THE TICKET TRACKING SYSTEM
At any given time, the Registry will have a person assigned to handle all complaints of abusive registrations. Upon receiving a complaint, the person logs the complaint to SMART’s abuse desk facility by filling in details of the complaint which includes the complainant’s e-mail address, the domain being assailed as an abusive registration, the date of complaint, among other details. Once the complaint is logged, the system automatically generates a ticket number and a password for the complainant and the complaint is tagged as “UNDER EVALUATION.” The complainant, using the ticket number and the password, may track the progress of the complaint through the system by logging in to the system’s web-based interface.
When a complaint is logged into the system, it it automatically assigned to a member of the Registry’s operations staff for handling. The staff member checks whether the complaint is valid in form and substance. If so, the handler forwards the complaint to the registrant of the assailed domain. The registrant is given a password to the system to allow it to follow the progress of the complaint through the system by logging in to the system’s web-based interface.
The status of the complaint is changed to “FORWARDED.”
If the complaint is not valid in form and substance, the handler will note all the deficiencies in the complaint and change its status to “COMPLAINT DEFICIENT.” The complainant may then correct all the deficiencies in the complaint and re-submit the complaint under the same ticket number.
When a resubmitted complaint is received, the status is changed to “COMPLAINT EVALUATION.” After seven (7) working days of not being corrected by the complainant, a “COMPLAINT DEFICIENT” complaint is automatically “CLOSED.”
When a registry receives an answer from the registrant, the status of the complaint is changed from “FORWARDED” to “RESPONSE EVALUATION.” The handler evaluates whether the response is valid in form and substance. If so, the response is forwarded to the complainant and the complaint is tagged as “REGISTRANT ANSWERED.” If the response is not valid in form and substance, the deficiencies are logged and the respondent is notified of the deficiencies.
“FORWARDED” complaints are automatically changed to “FOR RESOLUTION” after five (5) days. This occurs when the respondent does not submit an answer to the complaint.
When the complainant’s reply to the registrant’s answer is received, the status of the complaint is changed from “REGISTRANT ANSWERED” to “COMPLAINANT REPLY EVALUATION.” The handler checks that the reply is valid in form and substance. If so, the status is changed from “COMPLAINANT REPLY EVALUATION” to “FOR RESOLUTION.”
After five (5) days, a “REGISTRANT ANSWERED” complaint is changed to “FOR RESOLUTION.” This occurs when no complainant reply which is valid in form and substance is received.
When a complaint’s status changes to “FOR RESOLUTION”, and the complaint is sent to the DotSMART Policy Board for resolution.
RESOURCING PLANS
There will be at least three persons assigned to man the abuse desk ticketing system.
ORPHAN GLUE RECORDS
The registry does not allow orphan glue records.
WHOIS ACCURACY
The accuracy of WHOIS data is guaranteed because the .SMART gTLD is for the exclusive use of the company and its subsidiaries, its authorized partners, and its subscribers. This means that all the registrants are all known to the company. Authentication of the identity of each and every registrant is assured because of each registrant’s relationship with the company.
29. Rights Protection Mechanisms: Applicants must describe how their registry will comply with policies and practices that minimize abusive registrations and other activities that affect the legal rights of others, such as the Uniform Domain Name Dispute Resolution Policy (UDRP), Uniform Rapid Suspension (URS) system, and Trademark Claims and Sunrise services at startup.
A complete answer should include:
- A description of how the registry operator will implement safeguards against allowing unqualified registrations (e.g., registrations made in violation of the registry’s eligibility restrictions or policies), and reduce opportunities for behaviors such as phishing or pharming. At a minimum, the registry operator must offer a Sunrise period and a Trademark Claims service during the required time periods, and implement decisions rendered under the URS on an ongoing basis; and
- A description of resourcing plans for the initial implementation of, and ongoing maintenance for, this aspect of the criteria (number and description of personnel roles allocated to this area).
>To be eligible for a score of 2, answers must also include additional measures specific to rights protection, such as abusive use policies, takedown procedures, registrant pre-verification, or authentication procedures, or other covenants.
A complete answer is expected to be no more than 10 pages.
As stated in the Registry’s Mission and Purpose, the .SMART gTLD will serve the needs of SMART including the provisioning of its cellular, wireless broadband, financial, technology solutions, mobile virtual networks and satellite services for the use of its authorized mobile and Internet subscribers.
The .SMART gTLD is for the exclusive use of the company and its subsidiaries, its authorized partners, and its subscribers. Registration in .SMART is not open to the general public. By controlling every registration in the .SMART gTLD, the company will totally eliminate abusive registrations and other activities that affect the legal rights of others. Through its Policy Board, the company will ensure that each domain name registered in the .SMART has at least one of the following characteristics:
• it corresponds to a bona fide offering of goods or services
• it is not intended to mislead or divert consumers away or tarnish the trademark or service mark of any mark-holders
• it corresponds to the name that the company’s subsidiary, authorized partner, or product is commonly known
• it is a generic or a descriptive name which the company has fair use of
Furthermore, the company will comply with the Rights Protection Mechanisms (RPMs) that have been established by ICANN to protect trademark holders from abusive registrations. Each mechanism is listed below:
1. Trademark Clearinghouse
2. Uniform Rapid Suspension (URS)
3. Post Delegation Dispute Resolution Procedure (PDDRP)
4. Uniform Domain Name Dispute Resolution Policy (UDRP)
This document describes how the .SMART Registry will comply with policies and practices that minimize abusive registrations and other activities that affect the legal rights of others.
1. Trademark Clearinghouse
As a centralized repository of verified data on registered, court-validated word marks or word marks that are protected by statute or treaty, the Clearinghouse is to be used for the Trademark Claims service and the Sunrise Process.
1.1 Trademark Claims service
As a registry for the exclusive use of the company, the registry will not be open to the general public. Only company-related registrants (as defined in the Mission⁄Objective part of the Application) may register domain names in the registry. The Trademark Clearinghouse would be used by the company to be informed of any Trademark claims on prospective domain names as this would impact how the domain names could be used by the company. Should the company decide to continue the registration of a domain name contained in the Clearinghouse Database, company would promptly notify the mark holder(s) of the registration.
1.2. Sunrise service
The objective of the Sunrise service is to allow mark-holders the opportunity to register domain names for their marks ahead of non-mark-holders. However, the purpose of .SMART is to the deliver the company’s goods and services including the provisioning of its cellular, wireless broadband, financial, technology solutions, mobile virtual networks and satellite services for the use of its authorized mobile and Internet subscribers. The registry will not be open to the general public. It doesn’t make sense for the company to allow non-company related entities to register domains in the registry, even if these entities are mark-holders, because that would violate the purpose of the .SMART Registry.
In fact, allowing these mark-holders to register their marks in the .SMART Registry would create the wrong impression that these mark-holders are part of the company, or have a business relationship with the company, or are vetted by the company.
Worse would be to allow a competitor company, COMPETITOR, the mark-holder of the same company name, to register the domain COMPETITOR.SMART as part of the Sunrise service. This would imply to the general public that the company vets for the service of the competitor
company, COMPETITOR.
.SMART is seeking exemption from ICANN from providing this Sunrise service. The company submits that the rights of the mark-holders are amply protected by the Trademark Claims Service.
2. Uniform Rapid Suspension (URS)
Designed as a lighter and quicker relief for trademark holders than the existing UDRP, the remedy that a panel may grant to a complainant is the suspension of a domain name. Within twenty-four (24) hours of receipt of a Notice of Complaint from a URS Provider, the company shall restrict all changes to the registration data. The company shall notify the URS Provider immediately upon locking the domain with a “Notice of Lock.” When a URS panel finds a clear-cut case of trademark abuse in a registered domain name, the Registry will comply with a suspension order immediately upon receipt of the Determination. The nameservers for the domain shall be redirected to the informational web page provided by URS Provider.
3. Post Delegation Dispute Resolution Procedure (PDDRP)
The PDDRP is an administrative option for trademark holders to file an objection against a registry whose affirmative conduct in its operation or use of its gTLD is alleged to cause or materially contribute to the infringement of its trademark and thereby harm the trademark holder.
The Registry understands that because it operates a closed company-only registry, the registration of second-level domains may only be done under the control of the company. Thus it has a great responsibility to ensure that the rights of trademark holders are protected. We believe that by ensuring that the company only registers domain names which meet the characteristics itemized in the Introduction, trademark will never be infringed and the respective trademark holders will never be harmed.
Nevertheless, it is possible for the company or its employees to commit mistakes. These unwitting mistakes will be flagged when a complainant notifies the company of its specific concerns and details the specific conduct the complainant believes infringes on the complainant’s trademarks. The company will attempt to resolve these issues by meeting the conferring with the complainant.
4. Uniform Domain Name Dispute ResolutionPolicy (UDRP)
The UDRP is an administrative remedy for for rights-holding complainant to resolve cases of bad-faith, abusive registration of domain names. Should a UDRP panel favor a complainant, the UDRP panel may order the transfer or the cancellation of a domain name. The registrar is obliged to implement this decision.
As a closed registry, only company-affiliated registrants are allowed to register .SMART domain names and only the company-affiliated registrar may register in their behalf. Should a UDRP decision to cancel or transfer a domain name be received, the company registrar must comply with the order except when restrained by a competent court.
We believe that by ensuring that the company only registers domain names which meet the characteristics itemized in the Introduction, rights will never be infringed and the respective trademark holders will never be harmed.
5. Additional Protection Mechanism
The company is committed to protecting the rights of trademark holders in the .SMART gTLD. This is ensured by following the guideline that a domain name may be registered only if it meets at least one of the following criteria:
• it corresponds to a bona fide offering of goods or services
• it is not intended to mislead or divert consumers away or tarnish the trademark or service mark of any mark-holders
• it corresponds to the name that the company’s susbidiary, authorized
partner, or product is commonly known
• it is a generic or a descriptive name which the company has fair use of
These, in addition to the use of the Trademark Clearing House will ensure that the rights of trademark-holders are amply protected pro-actively. In addition to the above RPMs, the company will make available a specific e-mail address, trademarks@smart, to which rights-holder complaints may be addressed. This will be routed to the members of the .SMART Policy Board. The Legal Staff of the Board is specifically tasked to investigate and answer complaints coursed through the e-mail address. This will ensure that mistakes by the Registry are promptly corrected, even without going through the ICANN-mandated RPMs.
30A. Security Policy: provide a summary of the security policy for the proposed registry, including but not limited to:
- indication of any independent assessment reports demonstrating security capabilities, and provisions for periodic independent assessment reports to test security capabilities;
- description of any augmented security levels or capabilities commensurate with the nature of the applied for gTLD string, including the identification of any existing international or industry relevant security standards the applicant commits to following (reference site must be provided);
- list of commitments made to registrants concerning security levels.
To be eligible for a score of 2, answers must also include:
- Evidence of an independent assessment report demonstrating effective security controls (e.g., ISO 27001).
A summary of the above should be no more than 20 pages. Note that the complete security policy for the registry is required to be submitted in accordance with 30(b).
SMART has a dedicated Information Asset Protection and Assurance (IAPA) Department that identifies and minimizes risks in order to maximize the success of the company by ensuring confidentiality, integrity and availability of information assets within the company, which will include the operations of .SMART registry.
INDEPENDENT ASSESSMENT BY AN EXTERNAL PARTY
SMART, as a wholly owned mobile phone and Internet service subsidiary of the Philippine Long Distance Telephone Company (PLDT) is required to comply with Sarbanes-Oxley Act. Annual assessment is being conducted by an external party, Ernst & Young (E&Y), to accredit SMART as compliant to the said U.S. Federal Law.
As part of Sarbanes-Oxley Act, the assessment by the external party is to ensure User Access Management (UAM) is strictly followed by the company. UAM in SMART is being reviewed based on the following:
· Type of access (i.e. physical and logical access)
· Type of account (e.g. administrator, regular user, system account)
· Access privilege to ensure practice of least privilege and segregation of duties
· Frequency of review (e.g. monthly, quarterly)
· Employee movement (e.g. transfer, resignation)
Also, SMART Money service of SMART is a Payment Card Industry Data Security Standard (PCI-DSS) compliant service being accredited by PCI Council, one of which is MasterCard. In order to be compliant, a PCI Council-accredited Qualified Security Assessor (QSA) is needed to annually assess all involved processes and systems of the said service.
CORPORATE INFORMATION SECURITY POLICY
The Corporate Information Security Policy of SMART is annually reviewed, updated as necessary, and approved by the top level management before being cascaded to different groups or departments. Current security policy is based on the eleven (11) domains and controls of the ISO 27001:
· Security Policy -- the creation, suitability, adequacy and effectiveness of the information security policy shall be ensured by reviewing the policy at planned intervals or after changes which affect the organization’s security requirements are approved and implemented.
· Organization of information security Policy – this policy pertains to the establishment of applicable processes and controls for both internal and external parties of SMART’s.
· Internal – includes the management commitment to Information Security, establishment of Information Security Steering Committee (ISSC) responsible for developing the management for framework for information security, accountability.
· External – addressing security when outsourcing or dealing with clients or contractors.
· Asset Management Policy – this includes the responsibility for assets and classification of assets
· Human Resource Policy – the policy addresses the security concerning employment lifecycle from prior to employment, during employment, termination or change of employment of an employee, contractor, or third party. The security being addressed includes employee terms and conditions, non-disclosure agreement (NDA), declaration of compliance, inclusion of security responsibilities in the performance evaluation, security awareness and training.
· Physical and Environmental Security Policy – this policy addresses security that includes establishment of physical security perimeter, segregation of areas, access restriction and access authorization requirements, logging of physical entry access, monitoring and audit of the logs, establishment of controls against external and environmental threats, protection of equipment.
· Communications and Operations Management Policy – this policy includes the need for documentation of operation procedures, change management, segregation of duties, separation of facilities (i.e. development, testing, operational), third party service delivery management, system planning and acceptance, protection against malicious and mobile code, back-up, different media handling, exchange of information.
· Access Control Policy – this policy includes the need for endorsement and approval of access request, legal contract or agreement by an authorized SMART office with contractor, business partners, or third party. It also requires following user access management, which refers to user registration, privilege management, password management, and review of user access rights. The policy also includes the need for applicable controls on network, server, application, mobile computing and teleworking.
· Information Systems Acquisition, Development and Maintenance Policy – this policy includes the need for security requirements specifications on all business requirements for new or existing information systems, control of internal processing, data validation, use of cryptographic controls, key management, access control to program source code, security in development and support processes, technical vulnerability management.
· Incident Management Policy – this policy includes reporting information security events and weaknesses, management of information security incidents and improvements that refers to development of Security Response Team, collection and handling of evidence.
· Business Continuity Management Policy – this policy includes the need to adopt a program for developing, testing, maintaining, and update as necessary of business continuity plan throughout SMART in case of a disaster.
· Compliance Policy – this policy includes the need for compliance with legal requirements which refers to identification of applicable legislation, intellectual property rights (IPR), regulation of cryptographic controls, data protection and privacy of personal information. It also includes compliance with SMART’s security policies and standards, and audit considerations.
Complementing the 11 policies are sub-policies that touch on detailed security controls covering the following areas:
· Password and Login Control – covers the security of login and passwords that include, but are not limited to, password complexity, password length, password expiration and account locking.
· Network Security – covers network controls that include, but are not limited to, securing internal networks, externally-access networks or DMZs, implementation of firewalls, other network protection systems (i.e. intrusion detection, web filtering, SPAM control, etc.) and network management. It also covers security of Internet access provided to employees that include, but are not limited to, acceptable use, web filtering, provision of access and compliance with Intellectual Property Rights.
· Information Processing Facilities – covers security for Company facilities used to process Company information that include, but are not limited to, facility classification & corresponding security controls, physical access controls, security of physical equipment and environmental security
· Information Asset Classification – covers security of Company information which includes, but not limited to, classification of information, handling of information based on classification, classification labeling, information ownership and roles & responsibilities.
· Security Monitoring & Incident Management – covers monitoring for security events and managing security incidents that include, but are not limited to, management of system logs (i.e. collection, review, protection, etc.), incident reporting, investigation, response & handling and disciplinary process. This also includes the security of email, desktop, and application systems.
· User Access Management – covers security implemented on all systems that manage all levels of accesses (both from users and from systems) to ensure that systems are accessed only by authorized users or systems at any point in time.
· Outsourcing and Third Party – covers security for working Third Party entities for various engagements and for Outsourcing engagements that include, but are not limited to, service level agreements (SLAs), maintenance services, escalation, contract management, acceptance and data confidentiality.
IAPA RESPONSIBILITIES
Technical Standards – IAPA has a list of different technical standards internally available to SMART technical teams to ensure that systems being deployed follow an internationally-accepted settings or configurations. These technical standards are derived from the documents publicly available on:
· Center for Internet Security or CIS (http:⁄⁄www.cisecurity.org)
· National Institute of Standards and Technology or NIST (http:⁄⁄www.nist.gov⁄index.html)
· Other sites that provide security best practices, such as (but not limited to):
· SANS Institute (http:⁄⁄www.sans.org⁄security-resources)
· Information Systems Audit and Control Association or ISACA (http:⁄⁄www.isaca.org)
Enrollment to Control Compliance Tool – this is an activity to ensure that systems are checked as compliant with the existing technical standards. This activity is done before deployment of systems to production, and regularly observed while the systems are in production.
Vulnerability Management – an activity ensuring a regular vulnerability assessment of systems are performed before and after being deployed. As publicly known, it is a cyclical practice of identifying, classifying, remediating, and mitigating vulnerabilities. IAPA has a commercially-developed tool to conduct the scan in order to identify the vulnerabilities present on a system. After this, a report will be generated and IAPA will classify or assess what vulnerabilities need to be remediated based on the severity. The assessment will then be forwarded to the custodian of the systems for remediation and mitigation. If all vulnerabilities subject for remediation have been addressed, another round of vulnerability scanning will be conducted for validation.
Installation of Intrusion Detection System (IDS) – an activity currently performed on perimeter of SMART’s network. IAPA is using an open-source IDS tool to detect anomaly-based intrusion and then logged to the centralized log tool in real time. Incident management process follows if intrusion is detected.
Incident Management - handled by the Computer Security Incident Response Team (CSIRT) in IAPA with the following roles and responsibilities:
· Available 24⁄7 to respond to alerts corresponding to intrusion detection, intrusion prevention, and file integrity monitoring systems
· Performs initial investigation of the cause of problems encountered
· Ensure immediate system availability
· Tests the incident management plan (annually) in coordination with the other teams
· Performs Security Monitoring activities scanning our environment for vulnerabilities, threats, and abnormal activities from our systems
· Monitors for the presence of rogue wireless access devices
Sample of Incident Management:
· Operating System Event – Switch user to root
· Any attempts seen will notify CSIRT via e-mail.
· CSIRT will file immediately an incident ticket and directly assign it to the respective custodians of the system involved
· Custodians will then investigate why the users switch user to root
· Comment in the incident ticket coming from the user who triggered the event will be required, explaining the event.
· Assessment, including mitigation and sanctions, will be provided as applicable
(2) Security capabilities are consistent with the overall business approach and planned size of the registry.
IAPA has sufficient manpower and funding to ensure security of gTLD systems and processes.
(3) A technical plan adequately resourced in the planned costs detailed in the financial section.
IAPA has the process, technical plan, and roadmap to implement processes and solutions across Smart Communications. IAPA has also ongoing discussions and implementations of security solutions with vendors including, but not limited to:
· IBM
· HP
· ArcSight
· Tripwire
· Cyber-Ark
IAPA has an annual CAPEX budget to cover new technology tools that would increase the protection of information and USD1.0M for OPEX to continue operations of existing tools and implement Service-type (e.g. Consultations, Outsourced services, etc) security controls.
(4) Security measures are consistent with any commitments made to registrants regarding security levels. Registrant information is protected in that .SMART does not rent, sell, or share personal information about the registrant with other people or non-affiliated companies except to provide products or services that the registrant has requested and has given permission (to be shared).
(5) Security measures are appropriate for the applied for gTLD string (For example, applications for strings with unique trust implications, such as financial services-oriented strings, would be expected to provide a commensurate level of security).
Please refer to section 30(a)(2) above.
© Internet Corporation For Assigned Names and Numbers.