Application number: 1-917-11894 for PRIMER NIVEL S.A.

PRIMER NIVEL S.A.

Global Plaza, 50th street
21st floor
PANAMA PANAMA 00000
PA

+573162928048

+5713792500

http:⁄⁄www.1ernivel.co

Mr. GERARDO ARISTIZABAL

MANAGING DIRECTOR

+573162928048

aristizabal@mi.com.co

Mr. CARLOS NEIRA

VP BUSINESS DEVELOPMENT

+573203336598

carlos@mi.com.co

SOCIEDAD ANÓNIMA

The specific law htat defines the type of entity is:
Law 32 of 1927, Panama.
A link to information that defines the entity identified is:
http:⁄⁄www.lawyers-abogados.net⁄es⁄recursos⁄Panama⁄Panama_ley-32_sociedades-anonimas.htm
Further information is available upon request.

Not Available

CARLOS NEIRA
VP BUSINESS DEVELOPMENT
GERARDO ARISTIZABAL
MANAGING DIRECTOR

CARLOS NEIRA
VP BUSINESS DEVELOPMENT
GERARDO ARISTIZABAL
MANAGING DIRECTOR

CARLOS NEIRA
VP BUSINESS DEVELOPMENT
GERARDO ARISTIZABAL
MANAGING DIRECTOR

NEWS

Not Available

This issue concerns the ongoing discussions at ICANN regadring the Universal Acceptance of All Top-Level Domains. This issue has been pertaining ICANN discussions for a while now. Since the past launches of TLDs like .info and .museum, the need has risen to demand activities with the objective of standarizing applications and developers to include all valid TLDs in the root zone.
As noted by ICANN the acceptance of all Top-Level Domains requires the cooperation of software vendors, application and website developers among others.
Ongoing efforts to achieve the acceptance are being done at two levels.
- Recommendations to application and site developers to avoid checking the validity of FQDNs (Fully Qualified Domain Names) at the application level. This is rather left unattended and to be handled at the DNS level.
- In the case that these checks are absolutely mandatory, the recommendation is to do so agains the whole list of valid TLDs available at: http:⁄⁄data.iana.org⁄TLD⁄tlds-alpha-by-domain.txt
Our approach regarding Universal Accpetance is divided in two efforts.
1) If any specific issues are noted regarding acceptance of the TLD, we will contact the software vendor, developer or related party to try to solve this situations directly. For this we will need to have an active relationship with the community. This relationship is one of the building blocks of our project.
2) We will have information publicly available at our site addressing this specific issue. We will try to make this information public and of community interest.
We hope that this approach will not only benefit us, but will also be useful for all new and existing TLDs in the process of achieving universal acceptance.

.NEWS will become the preferred domain extension for sites that publish news on geographic locations, industries, companies, or about any other subject in the Internet. .NEWS will give journalists, publishers, and anyone related to communications to establish websites under an extension that clearly indicates the intention of the site under the domain. .NEWS will allow for the creation of the best sites around the world that concern news around any activity, industry or entity. .NEWS will specifically work towards constructing an innovative Internet space were Internet users keep up to date about their related interests.

Right now according to independent studies made by the applicant more than one million domains include the word news as part of the domain. This shows that there is a huge audience that is setting up sites that may definitely find a .NEWS domain shorter, more meaningful and strongly brandable. .NEWS expects to be the choice of 75,000 news related websites after 3 years of operation.

Benefit to registrants: The .NEWS extension will allow registrants that create domains related to news to brand their web pages under an extension that clearly defines the nature of the information within the site. A lot of websites that publish news include the word news in the domain name used as address. Specifically, more than one million websites according to an independent research made by the applicant include the word news in the domain. Further more of this one million sites, more than 600,000 have the word as the last part of the domain, e.g. xxxnews.tld. This is a clear sign that there is an interesting market and a huge benefit to registrants that may be able to find a more suitable name for their websites.

Benefit to Internet users: Internet users will benefit from the extension because domains under the extension will have a clear indication of the content of the site located at a .NEWS addresses. Also, the existence of the extension will promote the creation of strong brandable sites that will increase Internet usersʹ options.

Benefit to the market as a whole: Right now, more than one half of the domain names in the world are under two extensions, both operated by the same company. The Internet as a whole needs to encourage and promote competition in a way that market rules apply to the domain extension market. The existence of .NEWS may be part of this process of enhancing competition. This in the long run benefits all the Internet consumers as products have to compete by offering better specifications and consumer services. Furthermore, the fact that the Registry is constituted by a team of people from geographically and culturally diverse backgrounds strengthens ICANN´s mission to promote a really global independent Internet.

Specialty: The extension will specialize in providing names to sites that publish news about geographic destinations, industries, entities, etc.. The extension is not intended for sites that have no relation with news publishing but will also not have issues if such situation were to arise. This will encourage specialization of sites under the extension as places full rich and informative and up to date content. 

Service Levels: Regarding service levels, this issue may be split into three sections that imply the Registry directly:

Technical service level at the Registry level regarding the avilability of DNS for the domains under the .NEWS extension: This subject will be discussed in the technical section. Basically, we have contracted with a specialized Registry services provider whose expertise and technical background guarantee the highest availability and stability of the DNS services for the domains under the .NEWS extension.

Technical service level at the Registry level regarding the availability of the registration interface to the Registrars: As with the previous question, this will be discussed in the technical section. Availability of the interface to Registrars will rely on our technical services provider.

Support service level at the Registry level to act upon support requests made by Registrars: As has been agreed with our technical services provider, support will be provided by a qualified and competent team. Support will be provided via phone and email for Registrars and will be available 24 hours a day, 7 days a week. 

Reputation: We will strive on achieving a reputation of the “up to date” space in the Internet. We will have stability and availability of our service as our pilar. Our intention is to achieve the overall recognition for sites under the extension of freshness and relevancy.

The extension will add to the current namespace an option for all the registrants that have chosen a domain in the form xxxnews.tld. Right now these sites have no natural location but are spread all over the Internet on different domain names. This gives the extension a great possibility to become the de facto choice people creating fresh informative content on industries, geographic destinations, etc. For Internet users, the extension will be a name that expresses the contents to be found in the site. The extension will allow users to know what to expect when they visit a site under the .NEWS extension, freshness and relevancy. Regarding competition, right now domains under the popular extensions have oversold. The extension will give publishers of web content the possibility to do it under a killer domain name. 

Regarding user experience, at a registrar level the .NEWS TLD will be registered using the existing distribution channels. We will have an outstanding support for our registrars and will consistently promote user adoption with Above The Line strategies. As for the Internet User experience, .NEWS will work strongly on achieving a reputation of being the home of fresh and relevant content about every subject prone to producing this type of content. 

The achievement of the goals stated above requires that we do not incorporate a complex policy framework. We need to manage policy in a way that makes user adoption easy and straightforward. The .NEWS Registry will be an open space in which one of our main goals is to facilitate as much as possible the registration of domain names. Below is a draft on the policy on domain registrations under the .NEWS extension.

Policy draft

Introduction: The policy below is an initial approach to the policies that will rule over .NEWS domain registrations. The policies include:

- Gradual Offering Plan
- Geographic String Protection (Details addressed in question 22)
- General policy considerations
- General Availability policies

Gradual Offering plan:

The Gradual Offering Plan seeks to fairly distribute domain names to registrants, protecting intellectual and industrial property, and assigning second level .NEWS domains in a fair and orderly manner. The Gradual Offering Plan ends when the 
domains are finally available for public registration.

Objectives:

There are two main objectives sought with the Gradual Offering Plan. 1) to protect trademark rights and intellectual⁄industrial property to prevent⁄avoid abuse and bad faith in domain regsitrations. 2) to allow a phase of registration where domains are not registered in a first come, first serve basis for special commercial and other interests.

Structure: The plan is divided into two phases. The Sunrise phase and the Landrush phase. Both phases will be detailed next.

Sunrise: The Sunrise phase will allow companies with Trademarks to apply for the domains at the second level that match the protected strings according to the Trademark record.

Timeframe:

The Sunrise phase will begin 90 days after the execution of the Registry Agreement with ICANN and will last for 45 days. Both opening and closing of the phase will be done at 00:00:00 UTC.

Applicable strings (Strings that may be delegated in the second level in this phase):

Only trademarks registered before the 31st of December of 2011, and in full force at the time of the request may apply for the Sunrise phase. 

- The exact equivalent of a textual trademark.
- The exact textual portion of a trademark that has textual portion and an image.

Explanatory textual terms about the trademark or the trademark registration: LLC, LTD, S.A., TM, INC, etc. may be removed from the requested domain, if and only if the text is for explanation purposes.

In the case of URLs, TLDS may be removed from the domain requested like .COM, .NET. ORG, .CO, etc. WWW may also be removed from the requested domain.

Characters like spaces and: . , ! : ? ! ” # $ % & ⁄ ( ) - _ etc. may be transcribed (f.e. & for AND or Y) removed from the requested domain.

If the trademark includes letters like “á”, “é”, “í”, “ó”, “ú”, “ü” “ñ”, these may be replaced for corresponding letters like “a”, “e”, “i”, “o”, “u”, or “n”, or the conventionally accepted characters.

No other changes may be made to the domains requested. 

Contention:

If two requests are received for the same domain, these requests will go to auction. Auctions will be conducted as detailed later. Every valid request on the Sunrise phase will be temporarily reserved by the Registry until the outcome of the registration is defined.

Special Considerations

- All Sunrise requests must be done through ICANN Accredited Registrars.
- Proxy Registrations may not be used in the Sunrise phase. Registrations may change their records to Proxy records after the extension is released to General Availability.
- Both Trademarks that are registered in the Trademark Clearinghouse, and Trademarks that are not registered in the Clearinghouse may apply for the phase.
- The Registry may reject, delete, revoke, suspend, cancel or transfer a domain according to the rules of the Registry-Registrar Agreement that will stand between the Registry and all the Accredited Registrars for any domain registration to be submitted and maintained.
- Sunrise registrations may only be done for 1 year. Subsequently after General Availability applicants may renew the domain as allowed by these policies.

Landrush: The Landrush will allow applicants with commercial or specific interest to apply for a domain name. This also includes trademark holders that for some reason may have not applied for the Sunrise phase.

Timeframe:

The Landrush phase will begin 20 days after the end of the Sunrise phase and will last for 45 days. Both opening and closing of the phase will be done at 00:00:00 UTC.

Any valid domain that has not been reserved or requested in the Sunrise phase may be requested in the Landrush phase.

Contention:

If two requests are received for the same domain, these requests will go to auction. Auctions will be conducted as detailed later. Every valid request on the Landrush phase will be temporarily reserved by the Registry until the outcome of the registration is defined.

Special Considerations

- All Landrush requests must be done through ICANN Accredited Registrars.
- Proxy Registrations may not be used in the Landrush phase. Registrations may change their records to Proxy records after the extension is released to General Availability.
- The Registry may reject, delete, revoke, suspend, cancel or transfer a domain according to the rules of the Registry-Registrar Agreement that will stand between the Registry and all the Accredited Registrars for any domain registration to be submitted and maintained.
- Landrush registrations may only be done for 1 year. Subsequently after General Availability applicants may renew the domain as allowed by these policies.

General Availability policies

General Availability will allow registrants to register a domain name on a first come first serve basis. This phase will be the regular operation of the registrations under the extension.

Timeframe:

The General Availability phase will begin 20 days after the end of the Landrush phase and will be indefinite. Opening of General Availability phase will be done at 00:00:00 UTC.

Any valid domain that has not been reserved or requested in the Sunrise, Landrush or GPP phase may be requested in General Availability.

Trademark claims service:

Registry will implement the Trademark Claims service as detailed and instructed by ICANN for the first 60 days of operation of the Registry.

Special Considerations

- All requests must be done through ICANN Accredited Registrars.
- Proxy Registrations may be used in General Availability. 
- The Registry may reject, delete, revoke, suspend, cancel or transfer a domain according to the rules of the Registry-Registrar Agreement that will stand between the Registry and all the Accredited Registrars for any domain registration to be submitted and maintained.
- General Availability registrations may only be done for up to 10 years. 
- Any domain active in the General Availability phase may be renewed so that the Registration is due for 10 years from the actual date.
- Domains may only be renewed for a period of 1 year.

IDN implementation:

Chinese IDN domain names are supported from the first day of General Availability. IDNs for other character sets as Arabic, Spanish, Russian, etc. will be implemented over time if there is a demand for such names. IDN implementation will follow all of ICANN´s guidelines.

Auction rules:

When contention occurs in any initial phase of the launch of the domains under the extension an auction will apply between qualified applicants. All the auctions will take place at the same time. The Registry has considered both the possibility of running the auctions internally or outsourcing the auction process. 

The following considerations have been initially drafted:

Timeframes:

- Auctions will be held for a period of 60 days with every auction lasting 5 days or 120 hours.
- Batching of the auctions will be done by alphabetical order.

System:

- The auctions will be conducted through an online bidding system.
- Applicants must agree to the terms and conditions of the online bidding system. If the applicant does not agree to the terms and conditions the auction will still take place and the winner of the auction will be assigned the domain name. The Registry, the auction provider if any, the registrar and any other related party will not be liable in the case an applicant fails to use the auction system.

Bidding:

- Bidding will start at 1 dollar and will have increments as implemented in the auction system.
- Proxy bidding will by allowed in the auction system.
- Extensions will also be done in case bidding is active at the final periods of the auction.

Payment:

Applicants will be required to pay within 30 days of the end of the auction. Notices of the payment will be sent every 5 days to the applicant. If payment is not received by the term provided, the domain will be reauctioned between the other applicants 45 days after the initial auction ended. This process will repeat until a successful payment is received. If only 2 applicants are participating in the auction and one defaults in payment, the domain will be awarded to the other applicant free of fees.

Allocation: 

The winner of the auction must choose an accredited registrar to register and maintain the domain name after the auction results.

General policy considerations

Technical and Syntax requirements

- Domains consist exclusively of the letters A-Z, numbers 0-9, and hyphens.
- Domains cannot begin or end with a hyphen (-)
- Domains can´t have a hyphen in the 3rd and 4th position.
- Domains can´t exceed 63 characters excluding the TLD.
- Only domains with 3 or more characters may be registered through accredited Registrars.

Reserved domain names:

- Registry will reserve all the names as instructed by ICANN in Specification 5 of the Registry agreement and any changes that may occur in the future.
- The Registry reserves the right to reserve domain names for its personal use or mere ownership at any time. The Registry will allocate or register such names as allowed by ICANN provided that Registry Operator may reserve names from registration pursuant to Section 2.6 of the Registry Agreement. The reservation of the domain names will be inline with section B of Specification 9 of the Registry Agreement.
(Note: It is important to note that part of the Registry´s marketing activities will be to develop and promote sites under the .NEWS extension. These sites will be reserved and will be used by the registry in the process of marketing the extension)
- Release of reservations: Registry will undertake discussions with ICANN and the GAC relating the release of names reserved according to Section 5, Specification 5 of the Registry Agreement.
- 1 and 2 character domains will be reserved by the Registry as allowed by ICANN policies.

Compliance:

- Registry will implement and hold related parties responsible for the implementations of policies required by ICANN, including UDRP, URS, and any other policy that were to be determined by ICANN. Please note that RRDRP does not apply in this case as the TLD is not a community based TLD.

Privacy Policy: 

A Privacy Policy will be developed regarding the access, destination and usage of all the external information at the Registry. The objective of the Privacy Policy is to allow the Registry to use the information to successfully develop the extension while maintaining companies and individuals safe from any unwanted usage of private information. 

Specific information about the collection, destination and usage of private information will be publicly posted. The privacy policy will be inline with the best practices of privacy standards and ICANN recommendations about the matter.
Protection of private information from Registrants: 

- Privacy registration or Proxy registrations are allowed after the domains are available to the general public. This allowance will comply to ICANN´s resolutions about WHOIS information and any other related determination made about the privacy of registrant information.

- Our privacy policy will be clear on the possible usage, destination and collection of data from Registrants. This policy will be strictly implemented and followed as part of our commitment of maintaining a reliable trustworthy extension.

Protection of information from all other stakeholders will be done through an internal policy framework in which usage and access to information will be strictly controlled. The best practices regarding transmission and storage of information will be implemented to guarantee the security of information available to the Registry.

Outreach and communications will help achieve our projected benefits. Outreach and communications will help achieve our goals because:

- By marketing and communications we will achieve the awareness we use about the existence of the extension.
- Communications and marketing will communicate the ideas behind the extension. The place for fresh and relevant information.
- Communications will also allow us to communicate the existence of the .NEWS, and therefore will inform the general public of the availability of options that increase competition.
- Part of the communications and outreach will be the implementation of sites with specific fresh and relevant information about subjects.

For the points outlined above, our outreach and communications strategy will support and contribute to achieve our goals.

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? 

Social costs have been identified by us to be:

- Costs related to defensive registrations
- Costs related to processes of recovering a domain from an abusive registrant
- Time spent in the above processes
- Time wasted because of confusion

Costs related to defensive registrations and costs related to processes of recovering a domain from an abusive registrant: Our operating rules aimed at minimizing this social costs are:

- We will not incentivize defensive registrations.
- We will implement URS, UDRP and every other standard rights protection mechanism.
- We will use the means at our reach to promote and facilitate URS processes regarding potential infringement of trademarks.

These policies and procedures are the tools ICANN has put in place to reduce the costs when abusive registrations occur. A registry such as the one planned for .NEWS will have open registry policies and therefore is not absent to this situation. Nevertheless we will focus a lot on that our marketing strategy communicates the processes available for trademarks to react to abusive registrations.

Furhtermore, our allocation of domains will be done through an ordered plan that seeks to assign domains in a fair organized and consistent manner. The Gradual Offering Plan we have detailed in the policy section also aids in the reduction of social costs by providing an organized distribution structure. 

We will hold Sunrise, Landrush, the Geographic protection program, and will open up for General Availability at pubic and well communicated moments in time. There will be enough time between them and enough communication and outreach activities to ensure information is available to all interested parties. The Sunrise period, intended to allow IP right holders to protect themselves. The Landrush period, to allow early registration of domain names before the General Availability time after which the First Come, First Served rule will apply. And the Geographic Protection Program to give priority to governments and local authorities. This will allow us as stated before to launch the extension through a consistent and fair process.

i. How will multiple applications for a particular domain name be resolved, for example, by auction or on a first-come⁄first-serve basis?

Multiple applications for a particular domain may only happen on the Gradual Offering plan of the extension. This plan includes Sunrise, Landrush, and Geographic protection program phases. 

If two applications for the same domain were to be received the following rules apply:

- If two requests are received for the same domain under the Geographic Protection Program, the Registry will reserve that domain and at the cost of the Registry will create a landing page that redirects to sites as instructed by the contending applicants in a fair manner. Registration fees will be assumed by applicants and will be divided among the contending applicants. The Registry reserves full rights to modify the landing page and exclude the presence of any applicant´s presence if the applicant were to cease payment or any other reason as determined by the Registry. 

- If a request under the Geographic Protection Program were to match a Sunrise request, the Geographic request will prevail and the Sunrise request will not be entertained. Every valid request on the Geographic Protection Program phase will be temporarily reserved by the Registry until the outcome of the registration is defined.

- If any other two requests are made by any two applicants in the same phase (Sunrise or Landrush) the following rules also detailed in the policy section apply:

Auction rules:

When contention occurs in any initial phase of the launch of the domains under the extension an auction will apply between qualified applicants. All the auctions will take place at the same time. The Registry has considered both the possibility of running the auctions internally or outsourcing the auction process. 

The following considerations have been initially drafted:

Timeframes:

- Auctions will be held for a period of 60 days with every auction lasting 5 days or 120 hours.
- Batching of the auctions will be done by alphabetical order.

System:

- The auctions will be conducted through an online bidding system.
- Applicants must agree to the terms and conditions of the online bidding system. If the applicant does not agree to the terms and conditions the auction will still take place and the winner of the auction will be assigned the domain name. The Registry, the auction provider if any, the registrar and any other related party will not be liable in the case an applicant fails to use the auction system.

Bidding:

- Bidding will start at 1 dollar and will have increments as implemented in the auction system.
- Proxy bidding will by allowed in the auction system.
- Extensions will also be done in case bidding is active at the final periods of the auction.

Payment:

Applicants will be required to pay within 30 days of the end of the auction. Notices of the payment will be sent every 5 days to the applicant. If payment is not received by the term provided, the domain will be reauctioned between the other applicants 45 days after the initial auction ended. 

This process will repeat until a successful payment is received. If only 2 applicants are participating in the auction and one defaults in payment, the domain will be awarded to the other applicant free of fees.

Allocation: 

The winner of the auction must choose an accredited registrar to register and maintain the domain name after the auction results.

After the domain is available for public registration domains will be awarded by a first com⁄first serve basis.

ii. Explain any cost benefits for registrants you intend to implement (e.g., advantageous pricing, introductory discounts, bulk registration discounts).

We are planning the following pricing strategies along with our Marketing campaign:

1- First year registration price reduction. To incentivize registrations and reduce barriers to registrants we may have temporary campaigns where we will reduce the price for the 1st year of registration. This will allow us to structure marketing campaigns with our Registrar partners to promote the extension.

iii. Note that the Registry Agreement requires that registrars be offered the option to obtain initial domain name registrations for periods of one to ten years at the discretion of the registrar, but no greater than ten years. Additionally, the Registry Agreement requires advance written notice of price increases. Do you intend to make contractual commitments to registrants regarding the magnitude of price escalation? If so, please describe your plans.

Commitment of price escalation: We are committed to serve our registrants in the best way possible. We understand the importance of having a consistent price structure and policy. Therefore our commitment to registrants will be the following.

- For the first five years of operation of the .NEWS registry there will be no price increases. No one year term of renewal will be higher the renewal fee set for the lauch period for the first 5 years. 

- After the 5th year the highest increment in the domain registration prices will be 5% yearly, or as low as commercially practicable.

These policies will be implemented at the wholesale level. Registrars may or may not transmit this structure to their registrants.

No

Not Available

No

Geographic String protection

We will comply to the reservation as indicated Specification 5, Section 5 in the agreement but will also allow the assignment of all the Reserved domain names and other geographic strings to the authorized government or local authority under a plan called: Geographic Protection Program.

Timeframe:

The Program will run concurrent to the Sunrise phase.

Applicable strings (Strings that may be delegated in the second level through the program):

- All the reserved names as required by ICANN under the Section 5 of the Specification 5.
- Every Subdivision name listed as in the ISO 3166-2 standard for every country in the 3166-1.
- The generally known capital city of every country in the 3166-1 list. (Advice will be requested to the GAC for the appropriate list to be used)

If the strings include letters like “á”, “é”, “í”, “ó”, “ú”, “ü” “ñ”, these may be replaced for corresponding letters like “a”, “e”, “i”, “o”, “u”, or “n”, or the conventionally accepted characters.

Contention:

If two requests are received for the same domain, the Registry will reserve that domain and at the cost of the Registry will create a landing page that redirects to sites as instructed by the contending applicants in a fair manner. Registration fees will be assumed by applicants and will be divided among the contending applicants. The Registry reserves full rights to modify the landing page and exclude the presence of any applicant´s presence if the applicant were to cease payment or any other reason as determined by the Registry. 

If a request under the Geographic Protection Program were to match a Sunrise request, the Geographic request will prevail and the Sunrise request will not be entertained. Every valid request on the Geographic Protection Program phase will be temporarily reserved by the Registry until the outcome of the registration is defined.

Special Considerations

- This program will have no costs for governments. Only registration and renewal standard fees apply to registrants.
- Requests must be done directly with the Registry.
- Registrant must choose a Domain Registrar to register and maintain the domain name. Failure to renew the domain is at the absolute responsibility of the Registrant. (With the exception of contended applications)
- Proxy Registrations may not be used in the Program. Registrations may change their records to Proxy records after the extension is released to General Availability.
- Only Local Governments may apply for the program. GAC advice will be requested for the validation of the Registrant.
- The Registry may reject, delete, revoke, suspend, cancel or transfer a domain according to the rules of the Registry-Registrar Agreement that will stand between the Registry and all the Accredited Registrars for any domain registration to be submitted and maintained.
- Every domain included in the program but not requested by the candidate registrant, may be released for public registration with the exception of the domains that must be reserved according to the Registry Agreement with ICANN. 
- Registry may also register any of the names that are subject to the program to be used at Registry discretion, provided that Registry Operator may reserve names from registration pursuant to Section 2.6 of the Registry Agreement. The reservation of the domain names will be inline with section B of Specification 9 of the Registry Agreement.

Registry shall provide Registry Services as defined below: 

(i) the receipt of data from registrars concerning registrations of domain names and name servers; 
(ii) provision to registrars of status information relating to the zone servers for the TLD; 
(iii) dissemination of TLD zone files; 
(iv) operation of the Registry zone servers;
(v) dissemination of contact and other information concerning domain name server registrations in the TLD as required by the Registry Agreement;
(vi) Internationalized Domain Names (IDN);
(vii) DNS Security Extensions (DNSSEC); 
(viii) WHOIS Data Watch Service;
(ix) searchable WHOIS Service and
(x) other products or services that the Registry Operator is required to provide because of the establishment of a Consensus Policy

Registry will be engaging Qinetics Solutions Berhad of Malaysia as the back-end registry service provider for TLD operations.

Registry System

The system is based on RegistryASP SRS Application Suite that is deployed in ccTLD Registries, namely .sg (Singapore), .hk (Hong Kong, SAR), .cd (Congo, Democratic Republic) and .my (Malaysia). 

RegistryASP utilizes a ‘thick’ registry model which is EPP (Extensible Provisioning Protocol) version 1.0 compliant, where registrant data is maintained on a central registry database as a contact set.

- Stealth DNS (Zone Generation)

The resolution of domain names is a crucial function in a registry system. The DNS system supports both IPv4 and IPv6. The stealth DNS stores the generated zone file from the database, which will undergo a thorough reconciliation process before the data is reloaded into the master zone. The Stealth DNS is hidden in the internal network and is only visible to the primary DNS server. The primary DNS server is hidden as well and is responsible for the zone transfer to external secondary DNS servers. RegistryASP has achieved 100% uptime for all country codes Top Level Domains that are supported by the SRS application Suite. The DNS is in compliance to RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966.

- External DNS (Zone Resolution)

The external DNS setup consists of the secondary DNS servers dedicated to the resolution of requests for domains under the TLD. The Secondary DNS servers are provided by 2 of the main providers in the world. These providers support AnyCast DNS with more than 100 nodes all around the world. The main provider is CommunityDNS. All zone transfers will be protected using TSIG. The DNS is in compliance to RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966.

- DNSSEC

Registry shall provide DNSSEC services to registrars in compliance with RFCs 4033, 4034, 4035, 4509 and their successors, and will follow the best practices described in RFC 4641 and its successors. The DNSSEC services shall include the publishing of Delegation Signature (DS) records and signed records to the root zones of the TLD.

- WHOIS Services

Public access to the the information of domains is available through port 43. The daemon is actually deployed for the CCTLDs described above and has been tested for millions of WHOIS queries daily. Web based searchable WHOIS will be provided for subscribed users. The WHOIS services are highly scalable, capable of handling higher query loads, and comply with RFC 3912.

- Registry Web Interface

A Registry Web Interface will be available for Registrʹs operational team in the form of a Control Panel. The Control Panel is used by the Registry operational staff to administrate domain names, root name servers, registrars and other domain name data. Key features include multi-users function control, flexible product configurations, business process configurations and event-triggered alerts.

- Registrar Web Interface

A Registrar Web Interface will be available for Registrar operations in the form of a Control Panel. Registrars can perform daily operations and transaction accounting via the web Control Panel. Major functions include domain, contact, and host management, account balance and account top-up.

- EPP Services

A standard EPP server is used to provide flexibility for registrars to automate domain registration and management. The EPP server is configured with a SSL communications link that uses the EPP version 1.0, protocol compliant with RFCs 5910, 5730, 5731, 5732, 5733, 5734, 3735.

- Reporting Services

Standard reports are provided to Registry and Registrar staff to perform secondary check on transactions made, payment received, domain renewal and balance enquiries.

- Operational Testing and Evaluation (OT&E)

All newly accredited registrars shall reserve a time slot to access OT&E server and perform a technical test. This is to ensure that the registrar’s system is capable of registering and managing domain names in the production environment without problems. Once a registrar passes the OT&E Test, the registrar will receive an account to access the production system to register and manage domain names.

- Security and Monitoring

The system adheres to ISO27001 standards by Hong Kong government and is compliant with Singapore government security guidelines. User access will be controlled through 3 tiers of authentication: Registrar SSL Certificate, Registrar IP Addresses and Registrar User Name⁄Password Combination. The communication link with registrars will be SSL encrypted.

Multiple firewalls will be in place to ensure multiple levels of security together with IP filtering and Intrusion Detection with Prevention. Multiple security monitoring systems will be setup within and outside of the network of the Registry System to monitor the Registry Services. Host based intruder detection system will be in place on top of a hardware based intruder protection system. Multi Router Traffic Grapher (MRTG) will be installed to monitor traffic usage in the network and in each server of the Registry System.

- Data Escrow

The data will be deposited to an ICANN approved escrow agent based on escrow requirements to ensure business continuity and data recovery in the unlikely event of data loss.

- Call Center

System support and maintenance to guarantee maximum uptime shall be provided through Email and Phone to registrars. A 24⁄7 technical support hotline is available in multiple languages.

- Channel Management

Client Relation Management (CRM) software is in place to manage communications and contact with the registrars.

- Other Registry Services

The registry will provide IDN domain names to the end users. The IDN will be deployed according to the IDN RFCs (5890, 5891, 5892, 5893) and the languages supported will be based on registered language tables in IANA.

None of the registry services intended are unique the the .NEWS TLD.

Shared Registration System (SRS) Performance

Compliance:

Registry is in compliance to Specification 6 and Specification 10 of the Registry Agreement. Below is the Compliance table for Specification 6.

Compliance to Specification 10 is listed in the section of SLA. 

Compliance table (specification 6)

Section ⁄ RFC ⁄ Compliance

1.1 ⁄ 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, 5966 ⁄ Yes
1.2 ⁄ 5910, 5730, 5731, 5732, 5733, 5734, 3915, 3735 ⁄ Yes
1.3 ⁄ 4033, 4034, 4035, 4509, 4641 ⁄ Yes
1.4 ⁄ 5890, 5891, 5892, 5893 ⁄ Yes
1.5 ⁄ 4472, 3912 ⁄ Yes
2.1 ⁄ NA ⁄ Yes
2.2 ⁄ 1034, 4592, 1035 ⁄ Yes
3.1, 3.2, 3.3 ⁄ NA ⁄ Yes
4.1, 4.2 ⁄ NA ⁄ Yes

SRS System Description 

1. System Architecture

RegistryASP SRS application is designed with multiple control interfaces to allow access by different parties via defined user roles and matrixes. All components have been designed to be deployed in a distributed environment.

〈SEE ATTACHED FILE - EXPLANATORY IMAGE 1〉

Core Component of Registry SRS

The Registry SRS is split into multiple components to improve scalability. The Core SRS Component consists of presentation layer, application security framework, application layer and database layer. It supports HTTP, HTTPS and EPP protocols. 

The application layer is used to handle the business flow, audits, messages, processes and the daily tasks in the system. It has a data logger, which stores the details of all requests and responses from the application. The database layer deals with raw data management and utilizes relational databases.

2. SRS Data Flow Diagram

The system architecture of the SRS is designed to allow the EPP, WHOIS, registry web panel and registrar web panel to share the same business logic. The processing of any request will be the same, regardless of its origin.

〈SEE ATTACHED FILE - EXPLANATORY IMAGE 2〉

3. SRS System Features

Business Process Configuration:

- Administration module to configure business rules, policies and practices;
- Utilization of extensions in EPP to store additional information, e.g. language tag etc;
- Control panels to validate pending transactions and facilitate the submission of documents;
- Control panels for black and white list coupled with a pragmatic system to restrict sensitive names;
- Policy manager panels allow registry staff to control access to products and adjust policies;
- Feature access controller panels allow registry and registrar staff to customize functionalities available at various channels; and
- User access controller panel allows registry and registrar staff to customize access level of different users.

Channel Marketing (Registrar Support):

- Web-based multi-tier administrative control panel;
- Ability to brand email templates and extensive email tracking;
- Built-in marketing features such as volume discount and period discount tools;
- EPP connection Software Development Kit (SDK) and toolkits (in Java, PERL);
- Documentation, registrar technical training and change management.

Billing and Payment:

- Reminder notification with configurable alerts, content including other parameters; and
- Billing Manager to manage offline payments, fund alert, incentive rebate calculation and online invoice.

Report Management:

- Comprehensive statistical and transaction reporting system; and real-time reports for channel management (transaction, balance, renewal, announcements etc).
- Registrars detail and summary monthly statements; and
- Transaction tracking and action audit logs

Network Diagram

The following diagram shows the network architecture and connectivity for all the components of the Registry SRS System. The Registry System infrastructure is located in 2 different data centers for redundancy and scalability purposes. The primary data center consists of the SRS, DNSSEC signing and Data Escrow. The secondary data center will be running the WHOIS services. DNS Services are fully AnyCast enabled and dispersed geographically.

The primary data center has full redundancy up to the node level. The network is separated into 2 segments. The first network segment is IP restricted area for registrars to access the SRS which is the DMZ zone. The second segment is for internal access which consist of the database. 

All servers are protected by redundant firewall. 

The Web and EPP services are load-balanced between multiple servers. This provides maximum reliability, and is highly extensible by adding more servers behind the load balancers. Each server has redundant components (Power supplies, hard disk RAID, fans, network interfaces). The presence of multiple servers, multiple facilities, and multiple network providers means that the services will be well protected against single points of failure.

All services are setup in the secondary data center for emergency recovery in case of melt down in the primary data center. The services in the secondary data center can be online within 2 hours from the activation. Each site has at least 2 different network connections to the Internet. Our data centre belongs to a tier 1 provider with has four backbones peering to other tier 1 providers.

〈SEE ATTACHED FILE - EXPLANATORY IMAGE 3〉

The OTE server connects to the test database where the data resembles the production database. The Disaster Recovery Site (Secondary data center) is designed to replicate the primary site except the OTE environment. The OTE environment is not essential during a disaster. The DR site shall only be used to temporarily take over the registry operations while the primary site is being restored.

Interconnectivity

The main components in the systems are SRS, Data Escrow, WHOIS, DNS, Reporting, Registrar Systems, Accounting System and System Monitoring. The diagram below explains the interconnectivity between these components. 

〈SEE ATTACHMENT - EXPLANATORY IMAGE 4〉

The system consists of a SRS system where the main database server resides. The interfaces in the SRS system are mainly web and EPP. The data are received from registrars through Web panel or automation from registrar system to the EPP server in real time. The central data will then be distributed to DNS, Accounting system and Data escrow agent through batch processing mode. 

A bidirectional geographical replicated secondary database cluster is configured to replicate data from the main database in the SRS system. The secondary database will provide WHOIS query and data access for reports. The replication will be done using MySQL cluster bidirectional geographical replication feature which is near real time. The monitoring system will test the services in the SRS in real time. 

Synchronization Scheme

Interconnectivity between registry system components appear in 3 synchronization schemes:

1. Replication Synchronization (Only for database)

Source (SRS) to Destination (WHOIS)

- A secondary database cluster will be installed for providing the WHOIS response. The synchronisation is done using bidirectional database replication. The data are replicated to secondary database within miliseconds.

Source (SRS) to Destination (Reporting Services)

- A secondary database cluster will be installed for providing reports. The synchronisation is done using bidirectional database replication. The data are replicated to secondary database within miliseconds.

2.Batch Processing

Source (SRS) to Destination (Stealth DNS)

- A DNS reconciliation and generation program is in place to regenerate the zones in the interval of 2 hours.

Source (Stealth DNS) to Destination (Primary DNS)

- The zone is transferred to primary DNS using notify = yes. Once records are changed in stealth DNS, the primary DNS will be notified to transfer the zone. The transfer takes less than 1 second.

Source (Primary DNS) to Destination (Secondary DNS)

- The zone is transferred to secondary using notify = yes. Once records are changed in primary DNS, the secondary DNS will be notified to transfer the zone. The transfer takes less than 1 second.
 
Source (SRS) to Destination (Data Escrow)

- A backend program will be running daily to deposit the data into Escrow agents SFTP server.

Source (SRS) to Destination (Accounting System)

- A backend program will be running daily to generate the data file in the accounting system data import format.

3. Real Time Access

Source (Registrar System) to Destination (SRS)

- All transactions will be processed in real time and response will be returned immediately after processing.

Source (System Monitoring) to Destination (SRS)

- The monitoring software will be testing the services in near real time interval (every second).



Operations plan: Registry has outourced the Registry Technical Operation to Qinetics Solutions Berhad. Qinetics has a long track record of operating Registries like .MY, .SG, .HK, .CD with excellent stability and performance. Full implementation and operational plans are provided further in the application. Furthermore, Qinetics and the applicant´s team have worked for a while on the provision of the Registry Gateway Service for .CO, MY.CO. Past operations structure of MY.CO will be implemented in the Registry to assure a flawless operation from the Registry side. Operations include Registrar Relations, ICANN Relations, policy supervision and compliance, administration, etc.

Plan of operations detail: Perform a series of activities that provide the Registry Services with specific Resources.

Activities:
- Maintain an available SRS system that allows Domain Registration Services to Registrars.
Achieved through: Technical Outsourcing with Qinetics. In depth description will be provided in later stages of the application.

- Maintain the DNS, Escrow, etc. services related to the extension in a stable and reliable manner.
Achieved through: Technical Outsourcing with Qinetics + Community DNS + NCC. In depth description will be provided in later stages of the application.

- Monitor the correct functioning of Registry Services
Achieved through: Technical Outsourcing with Qinetics. In depth description will be provided in later stages of the application.

- Perform Registry operational non technical activities:

Achieved through: Registry will have a team that will handle:

- Administrative control, billing, accounting, etc. 
- Relationship with Registrars
- Relationship with ICANN
- Relationship with providers such as Qinetics, etc.
- Policy monitoring and Management

Registry team will perform these tasks as detailed later in the application to adequately attend the operation requirements of the service. This team will be comprised of experienced people that work in the domain registration business through Central Comercializadora de Internet (ICANN Accredited Registrar). 


Resource Plan

On-hand resources: 

- Qinetics has served domain registration services for .HK, .SG, .MY, .CD, etc. with a long track record of success. Technical resources are on hand for the full implementation of the proposed Registry. 
- Registry team has run for almost 3 years Domain Registration Services that have been very successful in Colombia and in more than 10 countries around the world. Registry team will be comprised of experienced executives in the domain registration business from Central Comercializadora de Internet (ICANN Accredited Registrar). Resources are on hand for all the non technical operations of the Registry. On hand operational non technical resources include:

- Project manager
- Two support specialists 
- Technical leader

These resources are currently part of the team that runs Central Comercializadora de Internet (ICANN Accredited Registrar).

Resource activity plan:

Qinetics will deploy the Registry Service of Registry using its existing system and infrastructure. During the implementation of Registry, new server hardware will be provisioned for SRS services. 

The following human resources will be used:

- Qinetics Project Manager
- Registry Technical leader
- Datacenter Engineer
- System Administrator
- Database Administrator
- Software Developer⁄Application support
- Test Engineer

The Data Center Engineer will perform the server provisioning and installation of OS. Once the hardware is provisioned, System Administrator shall continue to install the required software and perform security configurations. On the other hand, the Database Administrator will create the required schemas. The assigned Software Developer will configure the rules and policies into the SRS system. Once done, the Test Engineer will perform rigorous testing procedures to ensure the system performs according to specifications. When the testing is completed, the SRS system shall be handed-over to System Administrator to perform deployment to production environment. Throughout the process, a Project Manager and the Registry Technical leader will be assigned to perform project management and overall control on the implementation. The Project Manager will conduct training to all the Registry users on the functionalities of the system. The SRS setup shall be completed within a month.

After deployment

The system will be in maintenance mode after the SRS is deployed. The SRS will be supported by the general helpdesk support team for enquiries. Any technical support issues related to SRS will be escalated to the Application Support Engineer for troubleshooting. System Administrator is tasked to monitor the SRS availability. Whenever there is a support ticket, Application Support Engineer and System Administrator will escalate the support request based on the severity of the situation. The emergency response team will be triggered whenever there is a catastrophic scenario at the highest severity. 

From the Registry side, Project manager, support specialists, and Technical Leader will handle issues related to administrative control, non technical relationship with Registrars, relationship with ICANN, relationship with providers such as Qinetics, Policy monitoring and Management, etc.

Bug tracking

After an issue has been attended, and once a remedy has been identified, Test Engineer will perform testing on the fixes before deployment by System Administrator. For deployment the system will enter maintenance mode. During and after maintenance, Qinetics has committed 4 resources for the 24 x 7 helpdesk, 4 data center engineers, 2 application support engineers, 1 support manager, 1 test engineer and 2 system administrators.

Ongoing upgrades and policy tracking

As part of the ongoing policy changes, a team of software developers is available for any standard upgrades to the SRS and the changes will trigger the change request procedure in accordance to CMMI standards.

Service Level Agreement (SLA)

Registry is committed to provide SLA according to the parameters below in accordance to Specification 10:

DNS

- DNS service availability: 0 min downtime = 100% availability
- DNS name server availability: ≤432 min of downtime (≈99%)
- TCP DNS resolution RTT: ≤1500 ms, for at least 95% of the queries
- UDP DNS resolution RTT: ≤500 ms, for at least 95% of the queries
- DNS update time: ≤60 min, for at least 95% of the probes

RDDS

- RDDS availability: ≤864 min of downtime (≈98%)
- RDDS query RTT: ≤2000 ms, for at least 95% of the queries
- RDDS update time: ≤60 min, for at least 95% of the probes

EPP

- EPP service availability: ≤864 min of downtime (≈98%)
- EPP session-command RTT: ≤4000 ms, for at least 90% of the commands
- EPP query-command RTT: ≤2000 ms, for at least 90% of the commands
- EPP transform-command RTT: ≤4000 ms, for at least 90% of the commands

EPP compliance description

Qinetics will deploy a real time interface between registry and registrar based on the EPP protocol. The implementation is a thick model registry where WHOIS information is stored in registry main database as contact sets. Every registration requires a set of contacts to be submitted to the registry system. The EPP commands and responses are compliant to RFC 5730 - RFC 5734. The EPP implementation supports all Login Commands (login, logout), Query Commands (check, info, poll, transfer) and Object Transform Commands (create, delete, renew, transfer, update). 

The supported commands in the system are:

Greeting, Hello, Login, Logout, Poll, Domain Check, Domain Info, Domain Create, Domain Update, Domain Delete, Domain Renew, Domain Transfer, Contact Check, Contact Info, Contact Create, Contact Update, Contact Delete, Contact Transfer, Host Check, Host Info, Host Create, Host Update, Host Delete 

The full set of commands (requests and responses) are in a 30 page document which can be furnished on demand. The system uses all EPP statuses stated in the RFC as follows: 

- clientDeleteProhibited: Requests to delete the object must be rejected. 
- serverDeleteProhibited: Requests to delete the object must be rejected. 
- clientHold: Delegation information must be withheld from publication in the objectʹs nominal zone. 
- serverHold: Delegation information must be withheld from publication in the objectʹs nominal zone. 
- clientRenewProhibited: Requests to renew the object must be rejected. 
- serverRenewProhibited: Requests to renew the object must be rejected.
- clientTransferProhibited: Requests to transfer the object must be rejected. 
- serverTransferProhibited: Requests to transfer the object must be rejected. 
- clientUpdateProhibited: Requests to update the object (other than to remove this status) must be rejected. 
- serverUpdateProhibited: Requests to update the object (other than to remove this status) must be rejected. 


Domain Statuses

- ok: This is the nominal status value for a domain object at all times, whether or not the domain has prohibition of operation statuses. 
- Expired: This is the domain status when the domain fall into auto renew grace period
- RedemptionPeriod: The domain has fall out of renewal grace period into redemption grace period
- pendingRestore: A restore request has been received for the object, and completion of the request is pending. 
- pendingDelete: A delete request has been received for the object, but the object has not yet been purged from the server database. 
- pendingTransfer: A transfer request has been received for the object, and completion of the request is pending. 

When the requested action has been completed, the pendingDelete, pendingTransfer, or pendingRestore status value are removed. All clients involved in the transaction will be notified using a service message (Poll Command) that the action has been completed and that the status of the object has changed.

Below are conditions where domain statuses cannot co exist:
- ʺokʺ status cannot be combined with any other status.
- ʺpendingDeleteʺ status is cannot be combined with either ʺclientDeleteProhibitedʺ or ʺserverDeleteProhibitedʺ status.
- ʺpendingTransferʺ status is cannot be combined with either ʺclientTransferProhibitedʺ or ʺserverTransferProhibitedʺ status.

The pendingDelete, pendingTransfer, and pendingRestore status values cannot be combined with each other.

All Client statuses can be performed by registry or registrar, all server statuses can only be performed by registry.

Domain Transfer State Statuses:
Pending - The domain transfer request is initiated
clientApproved - Domain Transfer is approved by losing registrar
clientCancelled - Gaining registrar cancel domain transfer request
clientRejected - Losing registrar rejected the domain trainsfer request
serverApproved - Domain Transfer is approved by system after transfer grace
serverCancelled - Domain transfer is cancelled by registry system


Registrar will be required to download the EPP SDK (bundled with documentation) to establish connection to EPP Server. 

Procedure of TCP connection:

a. Post SSL request
b. SSL Handshaking
c. SSL session established
d. Send Greeting command
e. Greeting acknowledgment
f. Send login information
g. Authentication process
h. TCP over SSL connection established
i. Send command for operation such as Domain check command
j. Send Poll command to keep connection alive
k. Session will be closed automatically after 20 minutes if Poll command is not issued
l. Send logout command
m. Session closed

XML parser will be used against request and response to ensure integrity of the data and detect corruption of data. Once data is found to be loss or corrupted, EPP command fail response will be sent to the requestor.

SSL

The EPP handshake requires exchange of certificates between the client and the server. Qinetics implementation accepts any certificates issued by authorized Certificate Authority (CA). The authorized CA list supported: Verisign, Thawte, GeoTrust, EnTrust, Comodo, GlobalTrust, DigiCert, USERTrust, CyberTrust, Microsoft

Qinetics provides a self signed certificate as optional to the registrar for better security. Registrars can file in a request through email for Qinetics generated certificate. 

Once SSL handshake is established, registrar shall send in a Login command with username and password to access the EPP services. The EPP services implements IP address check before responding to the client. 2 Tier IP check are implemented in firewall and the EPP services respectively to provide double protection.

Operation and Test Environment (OTE)
As part of the standard procedure, registrar will be given access to the OTE environment only for testing purposes. Registrar will have to download the OTE guideline and program according to the documentation.

Registrar will then send a request to start OTE test at a predefined time slot. Once the registrar pass the test, the production username and password will be sent to the registrar technical contact.


Registration Tools

- EPP 1.0 client SDK and documentation (no proxy required); and
- Tools are downloadable from registrar web interface.

EPP Extensions Schemas

The EPP shall implement extensions for DNSSEC according to RFC 5910 and IDN according to RFC 3735. The extensions are applied to the following commands only:

- Domain Info
- Domain Create
- Domain Update

Below is the XML for a few commands and responses. 

〈Also in attachemt - EPP EXAMPLES〉

Domain info

EPP 1.0 Request

〈?xml version=“1.0” encoding=“UTF-8”?〉
〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instance xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
〈command〉
〈info〉
〈domain:info xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ
 xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdʺ〉
〈domain:name hosts=ʺallʺ〉example.com〈⁄domain:name〉
〈⁄domain:info〉
〈⁄info〉
〈clTRID〉ABC-12345〈⁄clTRID〉
〈⁄command〉
〈⁄epp〉

EPP 1.0 Response

〈?xml version=“1.0” encoding=“UTF-8”?〉
〈epp xmlns=“urn:ietf:params:xml:ns:epp-1.0” xmlns:xsi=“http:⁄⁄www.w3.org⁄2001⁄XMLSchema-instance” xsi:schemaLocation=“urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
〈response〉
〈result code=ʺ1000ʺ〉
〈msg〉Command completed successfully〈⁄msg〉
〈⁄result〉
〈resData〉
〈domain:infData Xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdʺ〉
〈domain:name〉example.com〈⁄domain:name〉
〈domain:roid〉EXAMPLE1-EP〈⁄domain:roid〉
〈domain:status s=ʺokʺ⁄〉
〈domain:registrant〉jd1234〈⁄domain:registrant〉
〈domain:contact type=ʺadminʺ〉sh8013〈⁄domain:contact〉
〈domain:contact type=ʺtechʺ〉sh8013〈⁄domain:contact〉
〈domain:ns〉
〈domain:hostObj〉ns1.example.com〈⁄domain:hostObj〉
〈domain:hostObj〉ns1.example.net〈⁄domain:hostObj〉
〈⁄domain:ns〉
〈domain:host〉ns1.example.com〈⁄domain:host〉
〈domain:host〉ns2.example.com〈⁄domain:host〉
〈domain:clID〉ClientX〈⁄domain:clID〉
〈domain:crID〉ClientY〈⁄domain:crID〉
〈domain:crDate〉1999-04-03T22:00:00.0Z〈⁄domain:crDate〉
〈domain:upID〉ClientX〈⁄domain:upID〉
〈domain:upDate〉1999-12-03T09:00:00.0Z〈⁄domain:upDate〉
〈domain:exDate〉2005-04-03T22:00:00.0Z〈⁄domain:exDate〉
〈domain:trDate〉2000-04-08T09:00:00.0Z〈⁄domain:trDate〉
〈domain:authInfo〉
〈domain:pw〉2fooBAR〈⁄domain:pw〉
〈⁄domain:authInfo〉
〈⁄domain:infData〉
〈⁄resData〉
〈extension〉
〈secDNS:infData xmlns:secDNS=ʺurn:ietf:params:xml:ns:secDNS-1.1ʺ〉
〈secDNS:dsData〉
 〈secDNS:keyTag〉12345〈⁄secDNS:keyTag〉
 〈secDNS:alg〉3〈⁄secDNS:alg〉
 〈secDNS:digestType〉1〈⁄secDNS:digestType〉
 〈secDNS:digest〉49FD46E6C4B45C55D4AC〈⁄secDNS:digest〉

(Below are optional)
〈secDNS:keyData〉
〈secDNS:flags〉257〈⁄secDNS:flags〉
〈secDNS:protocol〉3〈⁄secDNS:protocol〉
〈secDNS:alg〉1〈⁄secDNS:alg〉
〈secDNS:pubKey〉AQPJ⁄⁄⁄⁄4Q==〈⁄secDNS:pubKey〉
〈⁄secDNS:keyData〉
〈⁄secDNS:dsData〉
〈⁄secDNS:infData〉
〈⁄extension〉
〈trID〉
〈clTRID〉ABC-12345〈⁄clTRID〉
〈svTRID〉54322-XYZ〈⁄svTRID〉
〈⁄trID〉
〈⁄response〉
〈⁄epp〉

Domain Create (IDN)

EPP 1.0 Request

〈?xml version=“1.0” encoding=“UTF-8”?〉
〈epp xmlns=“urn:ietf:params:xml:ns:epp-1.0” xmlns:xsi=“http:⁄⁄www.w3.org⁄2001⁄XMLSchema-instance” xsi:schemaLocation=“urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
〈command〉
〈create〉
〈domain:create xmlns:domain=“urn:ietf:params:xml:ns:domain-1.0”
xsi:schemaLocation=“urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdʺ〉
〈domain:name〉xn--asjeiu3h34jhew.com〈⁄domain:name〉
〈domain:period unit=ʺyʺ〉2〈⁄domain:period〉
〈domain:ns〉
〈domain:hostObj〉ns1.example.com〈⁄domain:hostObj〉
〈domain:hostObj〉ns1.example.net〈⁄domain:hostObj〉
〈⁄domain:ns〉
〈domain:registrant〉jd1234〈⁄domain:registrant〉
〈domain:contact type=ʺadminʺ〉sh8013〈⁄domain:contact〉
〈domain:contact type=ʺtechʺ〉sh8013〈⁄domain:contact〉
〈domain:authInfo〉
〈domain:pw〉2fooBAR〈⁄domain:pw〉
〈⁄domain:authInfo〉
〈⁄domain:create〉
〈⁄create〉
〈extension〉 
〈ext:extension xmlns:ext=ʺurn:ietf:params:xml:ns:ext-1.0ʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:ext-1.0 ext-1.0.xsdʺ〉 
〈langtag〉CHI〈⁄langtag〉 
〈⁄ext:extension〉 
〈⁄extension〉
〈clTRID〉ABC-12345〈⁄clTRID〉
〈⁄command〉
〈⁄epp〉

EPP 1.0 Response

〈?xml version=“1.0” encoding=“UTF-8”?〉
〈epp xmlns=“urn:ietf:params:xml:ns:epp-1.0” xmlns:xsi=“http:⁄⁄www.w3.org⁄2001⁄XMLSchema-instance” xsi:schemaLocation=“urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
〈response〉
〈result code=ʺ1000ʺ〉
〈msg〉Command completed successfully〈⁄msg〉
〈⁄result〉
〈resData〉
〈domain:creData
 xmlns:domain=“urn:ietf:params:xml:ns:domain-1.0” xsi:schemaLocation=“urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdʺ〉
〈domain:name〉 xn--asjeiu3h34jhew.com 〈⁄domain:name〉
〈domain:crDate〉1999-04-03T22:00:00.0Z〈⁄domain:crDate〉
〈domain:exDate〉2001-04-03T22:00:00.0Z〈⁄domain:exDate〉
〈⁄domain:creData〉
〈⁄resData〉
〈trID〉
〈clTRID〉ABC-12345〈⁄clTRID〉
〈svTRID〉54321-XYZ〈⁄svTRID〉
〈⁄trID〉
〈⁄response〉
〈⁄epp〉

Domain Create (DNSSEC)

EPP 1.0 Request

〈?xml version=“1.0” encoding=“UTF-8”?〉
〈epp xmlns=“urn:ietf:params:xml:ns:epp-1.0” xmlns:xsi=“http:⁄⁄www.w3.org⁄2001⁄XMLSchema-instance” xsi:schemaLocation=“urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
〈command〉
〈create〉
〈domain:create xmlns:domain=“urn:ietf:params:xml:ns:domain-1.0”
xsi:schemaLocation=“urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdʺ〉
〈domain:name〉example.com〈⁄domain:name〉
〈domain:period unit=ʺyʺ〉2〈⁄domain:period〉
〈domain:ns〉
〈domain:hostObj〉ns1.example.com〈⁄domain:hostObj〉
〈domain:hostObj〉ns1.example.net〈⁄domain:hostObj〉
〈⁄domain:ns〉
〈domain:registrant〉jd1234〈⁄domain:registrant〉
〈domain:contact type=ʺadminʺ〉sh8013〈⁄domain:contact〉
〈domain:contact type=ʺtechʺ〉sh8013〈⁄domain:contact〉
〈domain:authInfo〉
〈domain:pw〉2fooBAR〈⁄domain:pw〉
〈⁄domain:authInfo〉
〈⁄domain:create〉
〈⁄create〉
〈extension〉
〈secDNS:create xmlns:secDNS=ʺurn:ietf:params:xml:ns:secDNS-1.1ʺ〉
〈secDNS:maxSigLife〉604800〈⁄secDNS:maxSigLife〉
〈secDNS:dsData〉
〈secDNS:keyTag〉12345〈⁄secDNS:keyTag〉
〈secDNS:alg〉3〈⁄secDNS:alg〉
〈secDNS:digestType〉1〈⁄secDNS:digestType〉
〈secDNS:digest〉49FD46E6C4B45C55D4AC〈⁄secDNS:digest〉

(below are optional)
〈secDNS:keyData〉
〈secDNS:flags〉257〈⁄secDNS:flags〉
〈secDNS:protocol〉3〈⁄secDNS:protocol〉
〈secDNS:alg〉1〈⁄secDNS:alg〉
〈secDNS:pubKey〉AQPJ⁄⁄⁄⁄4Q==〈⁄secDNS:pubKey〉
〈⁄secDNS:keyData〉
〈⁄secDNS:dsData〉
〈⁄secDNS:create〉
〈⁄extension〉
〈clTRID〉ABC-12345〈⁄clTRID〉
〈⁄command〉
〈⁄epp〉

EPP 1.0 Response

〈?xml version=“1.0” encoding=“UTF-8”?〉
〈epp xmlns=“urn:ietf:params:xml:ns:epp-1.0” xmlns:xsi=“http:⁄⁄www.w3.org⁄2001⁄XMLSchema-instance” xsi:schemaLocation=“urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
〈response〉
〈result code=ʺ1000ʺ〉
〈msg〉Command completed successfully〈⁄msg〉
〈⁄result〉
〈resData〉
〈domain:creDat xmlns:domain=“urn:ietf:params:xml:ns:domain-1.0”
xsi:schemaLocation=“urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdʺ〉
〈domain:name〉example.com〈⁄domain:name〉
〈domain:crDate〉1999-04-03T22:00:00.0Z〈⁄domain:crDate〉
〈domain:exDate〉2001-04-03T22:00:00.0Z〈⁄domain:exDate〉
〈⁄domain:creData〉
〈⁄resData〉
〈trID〉
〈clTRID〉ABC-12345〈⁄clTRID〉
〈svTRID〉54321-XYZ〈⁄svTRID〉
〈⁄trID〉
〈⁄response〉
〈⁄epp〉

Domain Update

EPP 1.0 Request

〈?xml version=“1.0” encoding=“UTF-8”?〉
〈epp xmlns=“urn:ietf:params:xml:ns:epp-1.0” xmlns:xsi=“http:⁄⁄www.w3.org⁄2001⁄XMLSchema-instance”
 xsi:schemaLocation=“urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
〈command〉
〈update〉
〈domain:update xmlns:domain=“urn:ietf:params:xml:ns:domain-1.0”
xsi:schemaLocation=“urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdʺ〉
〈domain:name〉example.com〈⁄domain:name〉
〈domain:add〉
〈domain:ns〉
〈domain:hostObj〉ns2.example.com〈⁄domain:hostObj〉
〈⁄domain:ns〉
〈domain:contact type=ʺtechʺ〉mak21〈⁄domain:contact〉
〈domain:status s=ʺclientHoldʺ lang=ʺenʺ〉Payment overdue.〈⁄domain:status〉
〈⁄domain:add〉
〈domain:rem〉
〈domain:ns〉
〈domain:hostObj〉ns1.example.com〈⁄domain:hostObj〉
〈⁄domain:ns〉
〈domain:contact type=ʺtechʺ〉sh8013〈⁄domain:contact〉
〈domain:status s=ʺclientUpdateProhibitedʺ⁄〉
〈⁄domain:rem〉
〈domain:chg〉
〈domain:registrant〉sh8013〈⁄domain:registrant〉
〈domain:authInfo〉
〈domain:pw〉2BARfoo〈⁄domain:pw〉
〈⁄domain:authInfo〉
〈⁄domain:chg〉
〈domain:add〉
〈domain:status s=ʺclientHoldʺ⁄〉
〈⁄domain:add〉
〈⁄domain:update〉
〈⁄update〉
〈extension〉
〈secDNS:update xmlns:secDNS=ʺurn:ietf:params:xml:ns:secDNS-1.1ʺ〉
〈secDNS:rem〉
〈secDNS:dsData〉
〈secDNS:keyTag〉12345〈⁄secDNS:keyTag〉
〈secDNS:alg〉3〈⁄secDNS:alg〉
〈secDNS:digestType〉1〈⁄secDNS:digestType〉
〈secDNS:digest〉38EC35D5B3A34B33C99B〈⁄secDNS:digest〉
〈⁄secDNS:dsData〉
〈⁄secDNS:rem〉
〈secDNS:add〉
〈secDNS:dsData〉
〈secDNS:keyTag〉12346〈⁄secDNS:keyTag〉
〈secDNS:alg〉3〈⁄secDNS:alg〉
〈secDNS:digestType〉1〈⁄secDNS:digestType〉
〈secDNS:digest〉38EC35D5B3A34B44C39B〈⁄secDNS:digest〉

(below are optional)
〈secDNS:keyData〉
〈secDNS:flags〉257〈⁄secDNS:flags〉
〈secDNS:protocol〉3〈⁄secDNS:protocol〉
〈secDNS:alg〉1〈⁄secDNS:alg〉
〈secDNS:pubKey〉AQPJ⁄⁄⁄⁄4Q==〈⁄secDNS:pubKey〉
〈⁄secDNS:keyData〉
〈⁄secDNS:dsData〉
〈⁄secDNS:add〉
〈⁄secDNS:update〉
〈⁄extension〉
〈clTRID〉ABC-12345〈⁄clTRID〉
〈⁄command〉
〈⁄epp〉

EPP 1.0 Response

〈?xml version=“1.0” encoding=“UTF-8”?〉
〈epp xmlns=“urn:ietf:params:xml:ns:epp-1.0”
xmlns:xsi=“http:⁄⁄www.w3.org⁄2001⁄XMLSchema-instance”
 xsi:schemaLocation=“urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
〈response〉
〈result code=ʺ1000ʺ〉
〈msg〉Command completed successfully〈⁄msg〉
〈⁄result〉
〈trID〉
〈clTRID〉ABC-12345〈⁄clTRID〉
〈svTRID〉54321-XYZ〈⁄svTRID〉
〈⁄trID〉
〈⁄response〉
〈⁄epp〉


EPP Server Capacity Plan

System performance depends on the application server capability and the processes required for completing a transaction. As the transaction load increases, the system performance can be increased by tuning the application server, upgrading the hardware of the server, or increasing the number of servers behind load balancers. A test has been carried out using the below hardware for capacity planning:

Application Server:

- 1 x Dual Core CPU 1.6GHz
- 2G RAM

The test results recorded with a database of 180,000 names and 100 concurrent EPP connections with 1500 concurrent commands in our test environment are as follows:

EPP Queries
- Average 1.5 seconds response time for query transactions
- Average 4 seconds response time after 90% line

EPP transactions
- Average 1.5 seconds response time for transactional commands
- Average 5 seconds response time after 90% line

The results are shown in the screenshot below. According to the result, more than 90% of the online transactions take less than 2 seconds. The remaining 10% (more time-consuming) are completed in 5 seconds as per expectation.

〈SEE ATTACHED FILE - EXPLANATORY IMAGE 5〉

Based on the proposed setup, 2 EPP servers with hardware 4 times more powerful than the test server, the system can handle up to 500 concurrent connections without degrading response times. The number of servers will be increased based on the number of allowed connections per registrar, and the number of registrars accredited for the extension. Shall the number of registrars increase, new servers will be provisioned to handle transactions. Each registrar will have equal access to the shared pool of connections (Registrar connection will be limited equally for any connected entity). The shared pool will serve registrars on First Come First Serve basis for the general registration availability phases.

Resource Plan

On-hand resources: 

- Qinetics has served domain registration services for .HK, .SG, .MY, .CD, etc. with a long track record of success. Technical resources are on hand for the full implementation of the proposed Registry. 
- Registry team has run for almost 3 years Domain Registration Services that have been very successful in Colombia and in more than 10 countries around the world. Registry team will be comprised of experienced executives in the domain registration business from Central Comercializadora de Internet (ICANN Accredited Registrar). Resources are on hand for all the non technical operations of the Registry. On hand operational non technical resources include:

- Project manager
- Two support specialists 
- Technical leader

These resources are currently part of the team that runs Central Comercializadora de Internet (ICANN Accredited Registrar).

Resource activity plan:

Qinetics will deploy the Registry Service of Registry using its existing system and infrastructure. During the implementation of Registry, new server hardware will be provisioned for EPP services. 

The following human resources will be used:

- Project Manager
- Datacenter Engineer
- System Administrator
- Database Administrator
- Software Developer⁄Application support
- Test Engineer

The Data Center Engineer will perform the server provisioning and installation of OS. Once the hardware is provisioned, System Administrator shall continue to install the required software and perform security configurations. The assigned Software Developer will configure the rules and policies into the EPP system. Once done, the Test Engineer will perform rigorous testing procedures to ensure the system performs according to specifications. When testing is completed, the EPP system shall be hand-over to System Administrator to perform deployment to production environment. Throughout the process, a Project Manager is assigned to perform project management and overall control on the implementation. The Project Manager will conduct training to the registry users on the functionalities of the system. The EPP setup shall be completed within a month.

After deployment

The system will be in maintenance mode after the System is deployed. The EPP will be supported by general helpdesk support for enquiries. Any support issue related to EPP will be escalated to the Application Support Engineer for troubleshooting. System Administrator is tasked to monitor the EPP availability. Whenever there is a support ticket, Application Support Engineer and System Administrator will further escalate the support request base on severity. The emergency response team will be triggered whenever there is a catastrophic scenario at the highest severity. 

From the Registry side, Project manager, support specialists, and Technical Leader will handle issues related to administrative control, non technical relationship with Registrars, relationship with ICANN, relationship with providers such as Qinetics, Policy monitoring and Management, etc.


Bug tracking

After an issue has been identified, and once a remedy is available, the Test Engineer will perform testing on the fixes before deployment by System Administrator. During maintenance, Qintetics will commit 4 resources for the 24 x 7 helpdesk, 4 data center engineers, 2 application support engineers, 1 support manager, 1 test engineer and 2 system administrators. 

Continuous management

As part of ongoing policy changes, a team of software developers is available for any standards upgrades to the EPP. The changes will trigger the change request procedure in accordance to CMMI standards.

WHOIS System Architecture 

Compliance Table (Specification 4)

Section ⁄ RFC ⁄ Compliance
1 ⁄ 3912 ⁄ Yes
1.1, 1.2, 1.3, 1.4, 1.5, 1.6 ⁄ NA ⁄ Yes
1.7 ⁄ 5730, 5731, 5732, 5733, 5734 ⁄ Yes
1.8 ⁄ NA ⁄ Yes


The WHOIS service contains data submitted by registrars during the domain name registration process. Any changes made to the data will be reflected in real-time, thus providing all interested parties with up-to-date information.

The WHOIS services to be provisioned include:

a. Port 43 command prompt WHOIS;
b. Searchable Port 80 web based WHOIS;
c. Configurable Port 43 rate limiter to prevent excessive request from the same IP;
d. Penalty for violation of query limit (e.g. barring access for the next 24 hours);
e. Ability to exclude certain IPs from normal rate limiting facilities;
f. Support multilingual WHOIS display; 
g. Easy, scalable and reliable WHOIS service;
h. Ensure accuracy in the display of WHOIS data; and
i. Conforms to RFC 3912.

WHOIS Access Method

WHOIS service shall be accessed via:

Command line (port 43)

The command line WHOIS allow queries by domain name in compliance to RFC 3912. The information will be displayed in a standard format. The WHOIS client makes a text request to the WHOIS server, then the WHOIS server replies with text content. All requests are terminated with ASCII CR and then ASCII LF. The response might contain more than one line of text, so the presence of ASCII CR or ASCII LF characters does not indicate the end of the response. The WHOIS server closes its connection as soon as the output is finished. The closed TCP connection is the indication to the client that the response has been received.

Registry Public Web Site (port 80)

The web based WHOIS is a searchable WHOIS by domain name. The corresponding information will be displayed if a match is found.
 
Both web and command prompt WHOIS will be accessing a standard database connection pool before connecting to the database. The secondary database is configured to replicate the data from production database in real time. A interconnectivity diagram between the SRS and WHOIS service is attached.

DB Connection Thread Controller

The WHOIS system will connect directly to replicate secondary database using a connection pool which will limit the number of maximum connections that can be connected to the database at any given time. Once the maximum is reached, the remaining requests are queued until the current connections are released. If the connection(s) could not be released on time (until database timeout hits), the system will throw an error out stating that the system is currently busy. 

Searchable WHOIS Service

The registry will offer searchable web-based WHOIS service on a subscription basis and reserves the rights to impose a fee. The searchable WHOIS will have partial match capabilities on the following fields: 

- domain name
- registrant name
- registrant postal address
- all the sub-fields described in EPP (e.g., street, city, state or province, etc.).

The WHOIS will offer exact-match capabilities on the following fields: 

- registrar id
- name server name
- name servers IP address (only applies to glue records).

The searchable WHOIS will allow Boolean search capabilities supporting logical operators to join a set of search criteria: AND, OR, NOT. The search results will include domain names matching the search criteria.

A potential form of abuse for this feature is data-mining, which is already commonly seen in the domain name industry with many domain name registries implementing reviewing their public WHOIS display policies to mitigate the problem. For example, SGNIC (.SG Registry) has recently revamped their WHOIS display to remove the mailing address of the registrant and administrative contact, the mailing address and telephone number of the technical contact and all of the information of the billing contact. The formal announcement from SGNIC can be found at http:⁄⁄sgnic.sg⁄news⁄sgnic-sg-whois-changes-2-may-2012.

The subscribers can access the searchable WHOIS feature from The registry website. To access this feature, the subscriber would have to apply for access to the feature and sign an agreement with The registry. The registry reserves the right not to approve the application. Upon approval, the subscriber would be given an unique login to ensure non-abusive use of this feature. The search is also protected by Image Verification Check (IVC). The access to this service will be monitored by The registry. Any abuse detected by The registry will be severely dealt with and the access of the offending subscriber will be revoked immediately.

All subscribers will agree to abide by all applicable privacy laws and policies as stated in the Searchable WHOIS Subscription Agreement.

WHOIS Data Watch Service

The registry will provide a service for alerts on WHOIS information change. Any changes on the WHOIS data will be alerted to the previous and the new email address of the registrant contact. The registry shall provide the services for free but reserves the right to impose a fee on the service. This feature provides extra security to ensure accuracy of the WHOIS information. 

WHOIS Query Control

The WHOIS service has the capability to perform query limit to avoid bulk access. The registry has the flexibility to amend the rate limit any time. To avoid further access to the registrant information, the search do not allow query on the registrant name. The search will return exact match results to avoid harvesting of related matching records. 

WHOIS and Privacy

The registry shall provide access to registrant information to the extent compatible with applicable privacy laws and policies. The registry shall not use the WHOIS data to send any unsolicited email to registrants, to solicit registrants by telephone or to otherwise engage in unauthorized uses of their data. The registry shall not sell any WHOIS data to third party under any circumstances. 

Registrars will agree to abide by all applicable privacy laws and policies as stated in the Registry Registrar Agreement. Registrars shall require customers to enter into an agreement prohibiting the customer from using the WHOIS database to send email, contact by phone or use it for other commercial purposes. 

Registrars are required to post privacy policies that provide clear and complete notice to registrants of the type of data that will be collected, the use of such data in operating the registry service and correct data maintained by The registry. Such data are required for submission of domain registration.

System Network and Hardware:

For optimum effect of WHOIS server, minimum 2 WHOIS servers will be provisioned. 2 database servers are provisioned as replicated secondary database cluster from the production site. A backup WHOIS server is setup for disaster recovery purposes in the primary data center. The network diagram is attached.

Interconnectivity and Synchronization

A replicated secondary database cluster is configured to replicate data from the main database in the SRS system. The secondary database will provide WHOIS query and data access for reports. The replication will be done using MySQL bidirectional geographical replication feature which is near real time and providing active-active hot site. The monitoring system will probe the services in the SRS in real time. 

Source (SRS) to Destination (WHOIS)
- A secondary database cluster will be installed for providing the WHOIS response. The synchronisation is done using bidirectional database replication. The data are replicated to secondary database within mili seconds.

WHOIS Output
The WHOIS server is based on a template system for both web interface and command line based WHOIS. The templates can be configured and changed in real time. The standard WHOIS output format is as below:

Sample WHOIS Output (Search By Domain):
Domain Name:EXAMPLE〈New gTLD String〉
Created On:18-Feb-1996 05:00:00 UTC
Last Updated On:26-Mar-2010 16:53:27 UTC
Expiration Date:19-Feb-2015 05:00:00 UTC
Sponsoring Registrar:Registrar, Inc. (R91-TLD)
Status:DELETE PROHIBITED
Status:TRANSFER PROHIBITED
Status:UPDATE PROHIBITED
Registrant ID:TLD-0000012
Registrant Name:Registration Department
Registrant Organization:Domain Company.
Registrant Street1: 1511 Hayden Rd.
Registrant Street2:Ste 160, PMB 353
Registrant Street3:
Registrant City:Scottsdale
Registrant State⁄Province:Arizona
Registrant Postal Code:85260
Registrant Country:US
Registrant Phone:+1.4806242599
Registrant Phone Ext.:
Registrant FAX:+1.4806242598
Registrant FAX Ext.:
Registrant Email:admin@example.com
Admin ID:TLD-22131674
Admin Name:Registration Department
Admin Organization:Domain Company.
Admin Street1:1511 Hayden Rd.
Admin Street2:Ste 160, PMB 353
Admin Street3:
Admin City:Scottsdale
Admin State⁄Province:Arizona
Admin Postal Code:85260
Admin Country:US
Admin Phone:+1.4806242599
Admin Phone Ext.:
Admin FAX:+1.4806242598
Admin FAX Ext.:
Admin Email:admin@example.com
Tech ID:TLD-12131674
Tech Name:Registration Department
Tech Organization:Domain Company
Tech Street1:1511 Hayden Rd.
Tech Street2:Ste 160, PMB 353
Tech Street3:
Tech City:Scottsdale
Tech State⁄Province:Arizona
Tech Postal Code:85260
Tech Country:US
Tech Phone:+1.4806242599
Tech Phone Ext.:
Tech FAX:+1.4806242598
Tech FAX Ext.:
Tech Email:admin@example.com
Name Server:NS1.EXAMPLE〈New gTLD String〉
Name Server:NS2.EXAMPLE〈New gTLD String〉
DNSSEC:Signed
DS Created 1:26-Mar-2010 16:52:50 UTC
DS Maximum Signature Life 1:3456000 seconds
DS Key Tag 1:54135
Algorithm 1:5
Digest Type 1:1
Digest 1:225F055ACB65C8B60AD18B3640062E8C23A5FD89
DS Created 2:26-Mar-2010 16:53:27 UTC
DS Maximum Signature Life 2:3456000 seconds
DS Key Tag 2:54135
Algorithm 2:5
Digest Type 2:2
Digest 2:6CDE2DE97F1D07B23134440F19682E7519ADDAE180E20B1B1EC52E7F58B2831D

If the information does not exist, WHOIS will display a message e.g. “No Record Found”.
Sample WHOIS Output (Search By Host or Host IP: For Searchable WHOIS Subscribers Only):

Hostname: ns1.fivio.tld
Created On:18-Feb-1996 05:00:00 UTC
Last Updated On:26-Mar-2010 16:53:27 UTC
Expiration Date:19-Feb-2015 05:00:00 UTC
Sponsoring Registrar:GoDaddy.com, Inc. (R91-TLD)
IP address: 202.11.11.90
IP address: 202.11.11.91

Sample WHOIS Output (Search By Registrar Name, Address, Phone etc: For Searchable WHOIS Subscribers Only):
Registrar Name: Example Registrar, Inc.
Street: 1234 Admiralty Way
City: Marina del Rey
State⁄Province: CA
Postal Code: 90292
Country: US
Phone Number: +1.3105551212
Fax Number: +1.3105551213
NEW GTLD AGREEMENT SPECIFICATIONS
Email: registrar@example.tld
WHOIS Server: whois.example-registrar.tld
Referral URL: http:⁄⁄www. example-registrar.tld
Admin Contact: Joe Registrar
Phone Number: +1.3105551213
Fax Number: +1.3105551213
Email: joeregistrar@example-registrar.tld
Admin Contact: Jane Registrar
Phone Number: +1.3105551214
Fax Number: +1.3105551213
Email: janeregistrar@example-registrar.tld
Technical Contact: John Geek
Phone Number: +1.3105551215
Fax Number: +1.3105551216
Email: johngeek@example-registrar.tld

Sample WHOIS Output (Search By Registrant ID: For Searchable WHOIS Subscribers Only):
Registrant ID:TLD-0000012
Created On:18-Feb-1996 05:00:00 UTC
Last Updated On:26-Mar-2010 16:53:27 UTC
Expiration Date:19-Feb-2015 05:00:00 UTC
Sponsoring Registrar:GoDaddy.com, Inc. (R91-TLD)
Registrant Name:Registration Department
Registrant Organization:Domain Company.
Registrant Street1: 1511 Hayden Rd.
Registrant Street2:Ste 160, PMB 353
Registrant Street3:
Registrant City:Scottsdale
Registrant State⁄Province:Arizona
Registrant Postal Code:85260
Registrant Country:US
Registrant Phone:+1.4806242599
Registrant Phone Ext.:
Registrant FAX:+1.4806242598
Registrant FAX Ext.:
Registrant Email:admin@example.com

Internationalized Domain Name (IDN)

The same templates that are used for the English version will be used for IDN display. Users will have to convert the domain name to puny code before executing the query. 

IPv6 Address
Any hostname submitted with IPv6 AAAA record will be displayed.

Resource Plan

On-hand resources: 

- Qinetics has served domain registration services for .HK, .SG, .MY, .CD, etc. with a long track record of success. Technical resources are on hand for the full implementation of the proposed Registry. 
- Registry team has run for almost 3 years Domain Registration Services that have been very successful in Colombia and in more than 10 countries around the world. Registry team will be comprised of experienced executives in the domain registration business from Central Comercializadora de Internet (ICANN Accredited Registrar). Resources are on hand for all the non technical operations of the Registry. On hand operational non technical resources include:

- Project manager
- Two support specialists 
- Technical leader

These resources are currently part of the team that runs Central Comercializadora de Internet (ICANN Accredited Registrar).

Resource activity plan:


Qinetics will deploy the Registry Service of Registry using its existing system and infrastructure. During the implementation of Registry, new server hardware will be provisioned for WHOIS services. 

The following human resources will be used:

- Project Manager
- Datacenter Engineer
- System Administrator
- Database Administrator
- Software Developer⁄Application support
- Test Engineer

The Data Center Engineer will perform the server provisioning and installation of OS. Once the hardware is provisioned, System Administrator shall continue to install the required software and perform security configurations. The assigned Software Developer will configure the rules that apply for the WHOIS service. Once done, the Test Engineer will perform rigorous testing procedures to ensure the system performs according to specifications. When testing is completed, the WHOIS system shall be hand-over to System Administrator to perform deployment to production environment. Throughout the process, a Project Manager is assigned to perform project management and overall control on the implementation. The Project Manager will conduct training to the registry users on the functionalities of the system. The WHOIS setup shall be completed along with the completion of the SRS deployment within a month.

After deployment

The system will be in maintenance mode after the System is deployed. The WHOIS will be supported by general helpdesk support for enquiries. Any support issue related to WHOIS service will be escalated to the Application Support Engineer for troubleshooting. System Administrator is tasked to monitor the WHOIS service availability. Whenever there is a support ticket, Application Support Engineer and System Administrator will further escalate the support request base on severity. The emergency response team will be triggered whenever there is a catastrophic scenario at the highest severity. 

From the Registry side, Project manager, support specialists, and Technical Leader will handle issues related to administrative control, non technical relationship with Registrars, relationship with ICANN, relationship with providers such as Qinetics, Policy monitoring and Management, etc.

Bug tracking

After an issue has been identified, and once a remedy is available, the Test Engineer will perform testing on the fixes before deployment by System Administrator. During maintenance, Qintetics will commit 4 resources for the 24 x 7 helpdesk, 4 data center engineers, 2 application support engineers, 1 support manager, 1 test engineer and 2 system administrators. 

Continuous management

As part of ongoing policy changes, a team of software developers is available for any standards upgrades to the WHOIS. The changes will trigger the change request procedure in accordance to CMMI standards.

Registration Lifecycle

Next we will detail the registration lifecycle for domains under .NEWS. The proposed lifecycle is similar to the one already present in gTLDs like .COM.

Lifespan of domains under the extension: Registration (1 to 10 years). A domain name can be registered for a span of 1 to 10 years.

Periods of a domain name

1. Active Period: A domain name becomes ACTIVE immediately upon being registered, meaning that it is no longer available for registration, and the information is published to the production database. The WHOIS record of the newly registered domain is created upon registration. A domain name can be active for 1-10 years depending on the duration of the registration term selected by the registrant. 

2. Restore Period: After a domain is deleted, (except for a deletion in an Add Grace Period as detailed further) the domain will enter a Redemption or Restore period. During this period the domain may be restored. The effect of this process is the restoration of the domain to the zone file, and the renewal of the domain for 1 year.

3. PendingDelete Period: After a domain has finished the restore period, the domain enters the Pending Delete Period. During this Period the domain may not be modified by any reason. The domain will be purged from the system once the Pending Delete phase finalizes.


Diagram of the Domain Name Life Cycle

〈SEE ATTACHEMENT - EXPLANATORY IMAGE 8〉

Grace Periods

Grace periods are available for billable EPP commands to account for errors and support the auto-renewal model. The applicable grace period information is returned in the domain info EPP XML response. The Grace Period is a specified number of calendar days following the a transaction on a domain. The proposed Grace Period is 5 calendar days, except for the Auto-Renew Grace Period that is proposed to be 45. Within 5 days the behavior of the domain will be ruled by the following policies.

Add Grace Period 

- Delete. If a domain name is deleted within the Add Grace Period, the sponsoring registrar will be refunded the amount of the registration fee. The domain name is immediately deleted from the registry database and available for registration by any registrar. If a domain name is deleted after the 5 calendar day grace period expires, it will be placed in the Redemption Period Status for 30 calendar days and then deleted via the system after going through a 5 calendar day Pending Delete Period. 
- Renew. If a domain name is renewed within the Add Grace Period, and deleted afterwards, the grace period will loose effect. There will be no grace period credit for the registration or the renewal. The sponsoring registrar will be charged for the number of years the domain name is renewed up to a maximum resulting registration period of not more than 10 years. 
- Transfer. A domain name may not be transferred within the Add Grace Period. Registrants are prohibited from changing registrars within the first 60 days of the initial registration of the domain name.

Add Grace Period Consensus Policy - Domain tasting

If a domain is deleted within the Add Grace Period, the sponsoring registrar is credited for the amount of the registration fee. However, the Add Grace Period Consensus Policy limits the number of deletes within the grace period that are allowed per registrar. It is the intention of this Policy is to limit the behavior known as “domain tasting” through modifications to the Add Grace Period (AGP) process. The Add Grace Period Consensus Policy can be found on the ICANN website at http:⁄⁄www.icann.org⁄en⁄tlds⁄agp-policy-17dec08-en.htm

Registry will not offer any refund to an ICANN accredited registrar for any domain names deleted during the AGP that exceed (i) 10% of that registrarʹs net new registrations (calculated as the total number of domain name registrations of one-year through ten-year registrations) in that month, or (ii) fifty (50) domain names, whichever is greater, unless an exemption has been granted by the registry. A registrar may seek an exemption from the registry from the application of such restrictions in a specific month under special circumstances. A report would have to be presented to the registry by the registrar requesting for the exemption stating the circumstances and that the registrar was unable to prevent the deletions from taking place. The acceptance of any exemption will be at the sole and reasonable discretion of the registry, however special circumstances which reoccur regularly for the same registrar will not be deemed acceptable and will be rejected as a reason. 

Example:

If a registrar has 1,000 net new registrations, had its account with the registry auto-debited for US$5,000 (based on a price of US$5 per domain name registration), and had 250 AGP deletes, the Registrar would be entitled to a refund of US$500 for 100 AGP deletes (10% of 1,000 net new registrations at US$5 per domain name registration). The registrar would not be eligible for a refund of US$750 for the additional 150 deletes made.

Renew Grace Period 

If a Delete, Renew, or Transfer occurs within 5 calendar days of a renewal, the following rules apply:

- Delete: If a domain name is deleted within the Renew Grace Period, the sponsoring registrar will be refunded the renewal fee, only if the renewal was not made within another Grace Period. The domain then enters the Redemption Grace Period unless the deletion occurs during the 5 day Add Grace Period. 
- Renew: A domain name can be renewed up to a total of 10 years. If a domain name is renewed within the Renew Grace Period there will be no grace period. The sponsoring registrar will be charged for each of the years of the subsequent renewal.
- Transfer: If a domain name is transferred within the Renew Grace Period, the number of years that was renewed for the domain name will still be valid. There will be no Grace Period of the transfer is made within the Renewal Grace Period. Still, a transfer will include a renewal and may not be possible if the transfer+renewal were to extend the domainʹs expiration date to a date further to 10 years in the future.

Transfer Grace Period 

If a Delete, Renew, or Transfer operation occurs within 5 calendar days of a transfer process, the following rules apply: 

- Delete. If a domain is deleted within the Transfer Grace Period, the sponsoring registrar will be refunded the transfer (renewal) fee. 
- Renew. If a domain is renewed within the Transfer Grace Period, and then deleted, there will be no grace period. The registrar will be charged for the number of years of the renewal.
- Transfer. A domain can´t be transferred to another registrar within the Transfer Grace Period. Domains may not be transferred to another registrar within 60 days of the last transfer.

Auto-renew Grace Period 

If the sponsoring registrar does not renew the domain name prior to its expiration date, the registry automatically renews the domain for 1 year. The renewal of the domain name is executed by the registry system the day prior to the expiration date via a batch process. The sponsoring registrar has 45 calendar days to delete the domain and receive a refund for the domain name renewal fee. This way it is similar to a Renewal Grace Period but for 45 days.

If a Delete, Renew, or Transfer operation occurs within the 45 calendar days, the following rules apply:

- Delete. If a domain name is deleted within the Auto-Renew Grace Period, the sponsoring registrar will be refunded the renewal fees. The domain will enter redemption status for 30 days, and then will enter pendingDelete status for 5 days.
- Renew. A domain name can be renewed up to a total of 10 years. If a domain name is renewed within the Auto-Renew Grace Period, there will be no grace period. 
- Transfer. If a domain name transfer is approved or auto-approved within the Auto-renewal Grace Period, there will be no refunds for the loosing registrar. The winning registrar may opt for the Transfer Grace Period.
 
Notes: 

For any of the above grace periods, if a domain name is deleted and then restored then the domain name is no longer considered to be in any grace period.


Explanation of the Redemption Period: The proposed Redemption Period is 30 calendar days. When a domain name is deleted outside of the Add Grace period, it is placed on redemptionPeriod status for 30 days. The Redemption Period status does NOT apply to domain names deleted within the 5 day Add Grace Period. If a domain name is deleted within the 5 day Add Grace Period, it is immediately purged from the registry, and immediately made available for registration. The Redemption Period is designed to help registrars defend against inadvertent deletions. By placing the domain name on Redemption Period status for 30 days, the registrar has a sufficient time to realise the deletion and restore it, and not worry about the domain name being purged from the registry. During the Redemption period the domains will be removed from the zone and will not resolve. No modifications or tranasactions on a domain may be executed while it is in Redemption period. The only process that may be executed is the Restoration process detailed next.

Restore process: A domain stays in the redemptionPeriod status for 30 days OR until a successful RESTORE command attempts to restore the domain name to an active status. When a RESTORE command is executed on a domai name, RESTORE report is expected within 7 days. If a RESTORE report is not received the domain will enter a 30 day Redemption period again. If a RESTORE command and a RESTORE report are executed within the appropriate timing the domain will be reinstated to the zone file and renewed for 1 year. Registrar must pay for the cost of the RESTORE and the RENEW of the domain. 

Explanation fo the Pending Delete Period: After the Redemption period is over, the domain enters the Pending Delete Period for 5 calendar days. During this period no modification is possible to the domain. After 5 days the domain will be purged and made available for registration again.


Pending Periods

Pending Periods are defined as a specified number of calendar days following a specific operation during which certain operations are prohibited. There are four Pending Periods - Redemption Period, Pending Restore, Pending Delete and pending Transfer. The following subsections define the length of each pending period and the operations that are allowed within each pending period.

Redemption Period - redemptionPeriod: When a delete domain request is successful, the domain is placed on redemptionPeriod status for 30 days (Unless the delete was executed during an Add Grace Period). During this 30-day Redemption Period, the domain can be restored if the registrar submits a successful Restore request and Restore Report. (as explained earlier)

Pending Restore - pendingRestore: A successful RESTORE command on a domain chages its status to pendingRestore. This status matches the 7 day period in which a RESTORE report may be submitted for the definite reinstatement of the domain. The pendingRestore period will last for 7 days or until a RESTORE report is submitted. When the RESTORE report is received the status of the domain changes to active or OK.

Pending Delete Period - pendingDelete - The proposed Pending Delete Period is 5 calendar days. A domain name that is deleted outside of the Add Grace Period, and does not have a RESTORE command issued during the 30 day Redemption Period is placed into the Pending Delete Period. As explained before, once the domain enters the pendingDelete status, no modification can be made on the domain (no EPP operations can be performed on domains with the pendingDelete status). The domain stays in pendingDelete status for 5 days and then it is purged from the system at the end of the 5 days. 

Pending Transfer Period: The proposed Pending Transfer Period is 5 calendar days. A successful TRANSFER REQUEST command will place the domain on pendingTransfer status for 5 days or until the transfer is explicitly approved, rejected, cancelled, or auto-approved. The sponsoring registrar (also referred to as the losing registrar) has 5 calendar days to approve or reject the request. If the potential winning registrar receives an approve response, then the domain is automatically transferred. If the potential gaining registrar receives a reject response, then the pendingTransfer status is removed. If the potential gaining registrar does not receive any response by the end of 5 calendar days, then the request is automatically approved. Domains in pendingTransfer period may not be deleted, renewed or requested again for transfer. A rejection is necessary before any of this actions may apply again.

Special notes:

About domains with status Registry-Lock: This status can only be set by the registry. A domain name with this status cannot be transferred, modified or deleted by its registrar. The domain can however be renewed. The domain will resolve as it is included in the registry zone files if the domain has been delegated to at least one name server.

About domains with status Registry Hold: This status can only be set by the registry. A domain with this status cannot be transferred, modified or deleted by its registrar. The domain can however be renewed. The domain will not resolve as it is not included in the registry zone files.

Resource and Operation Plan

On-hand resources: 

- Qinetics has served domain registration services for .HK, .SG, .MY, .CD, etc. with a long track record of success. Technical resources are on hand for the full implementation of the proposed Registry. 
- Registry team has run for almost 3 years Domain Registration Services that have been very successful in Colombia and in more than 10 countries around the world. Registry team will be comprised of experienced executives in the domain registration business from Central Comercializadora de Internet (ICANN Accredited Registrar). Resources are on hand for all the non technical operations of the Registry. On hand operational non technical resources include:

- Project manager
- Two support specialists 
- Technical leader

These resources are currently part of the team that runs Central Comercializadora de Internet (ICANN Accredited Registrar).

Resource activity plan:


Qinetics will deploy the Registry Service of Registry using its existing system and infrastructure. During the implementation of Registry, new server hardware will be provisioned for the Registry service that will alow for the configuration of the domain life cycle. 

The following human resources will be used:

- Project Manager
- Datacenter Engineer
- System Administrator
- Database Administrator
- Software Developer⁄Application support
- Test Engineer

The Data Center Engineer will perform the server provisioning and installation of OS. Once the hardware is provisioned, System Administrator shall continue to install the required software and perform security configurations. The assigned Software Developer will configure the rules that apply for the specific lifecycle of the domains. Once done, the Test Engineer will perform rigorous testing procedures to ensure the system performs according to specifications. When testing is completed, the registration system shall be hand-over to System Administrator to perform deployment to production environment. Throughout the process, a Project Manager is assigned to perform project management and overall control on the implementation. The Project Manager will conduct training to the registry users on the specific behavior of domains under the registry. 

After deployment

The system will be in maintenance mode after the System is deployed. Any issues regarding the lifecycle of the domain will be supported by general helpdesk support for enquiries. Any support issue related to the lifecycle of domains will be escalated to the Application Support Engineer for troubleshooting. Whenever there is a support ticket, Application Support Engineer and System Administrator will further escalate the support request base on severity. The emergency response team will be triggered whenever there is a catastrophic scenario at the highest severity. 

From the Registry side, Project manager, support specialists, and Technical Leader will handle issues related to administrative control, non technical relationship with Registrars, relationship with ICANN, relationship with providers such as Qinetics, Policy monitoring and Management, etc.

Bug tracking

After an issue has been identified, and once a remedy is available, the Test Engineer will perform testing on the fixes before deployment by System Administrator. During maintenance, Qintetics will commit 4 resources for the 24 x 7 helpdesk, 4 data center engineers, 2 application support engineers, 1 support manager, 1 test engineer and 2 system administrators. 

Continuous management

As part of ongoing policy changes, a team of software developers is available for any standards upgrades and necessary changes to the lifecycle. Changes will trigger the change request procedure in accordance to CMMI standards.

Abuse prevention

Next we will detail how we will promote proper conduct under the registry and try to avoid abusive behavior and unacceptable registrant behaviour. We will address the topics:

- Mechanisms
- Resources
- Policy
- Promotion of WHOIS accuracy
- Special REBATE WHOIS accuracy promotion

Mechanisms

The following mechanisms will be implemented to avoid abusive registrations and unacceptable registrant behavior. 

1) Launch phases (Gradual Offering Plan): As stated before the registry will implement a Gradual offering plan that seeks to fairly assign domains to their rightful owers.

- Sunrise: As mentioned ealier a Sunrise phase will be implemented to grant privileged accesss to Registrants representing valid Trademarks as per the Sunrise policies implemented.
- Landrush: For Trademarks that do not qualify for the sunrise phase and for individuals with interests in strings that are not protected by Trademarks the Landrush phase will allow a period for the assignment of domains not in a first come - first served basis.

2) Resolution policies adopted: Registry will adopt Resolution policies as per ICANN indications

- URS: The Uniform Rapid Suspension process will be implemented by the Registry to allow for rapid takedown of abusive regsitrations.
- UDRP: The UDRP will be adopted and Registrars will be required to comply to any and every determination made by the administrative entity handling any UDRP process.

Alternative use of Rapid Takedown Dispute Resolution Policies: In the absence of URS, the Registry may provide a Rapid Takedown process through engagement with a dispute resolution provider that consists of a response team of qualified expert (qualified UDRP panelist). The Registry agrees that majority of cases that go through the Uniform Dispute Resolution Process (UDRP) are mainly obvious variant of well-known marks. As such, it would be a waste of time or resources for the most obvious cases of infringement to go through the UDRP filings. Registry may provide a rapid takedown process where a response team of qualified experts (qualified UDRP panellists) will be involved to determine within 48 hours of receipt of a short and simple claim of involving a well-known mark or otherwise inherently distinctive mark and a domain name where no conceivable good faith basis exists. The results may result in an immediate termination of the domain name, but will not prejudice either party’s election to pursue other dispute mechanisms.

3) Abuse point of contact: Registry will prominently publish abuse contact information on its website; The abuse contact will prominently displayed on its webpage, and a uniform naming convention will be utilized to facilitate discovery of the website; The abuse contact information shall consist of telephone and email address. The email address may be an alias, not a specific person’s name, to manage operational efficiency; Request submitted by verified law enforcement agencies to this contact will receive an acknowledgement of receipt from the registry within 24 hours; and
The contact at the registry will be empowered to act in response to a well-founded report of illegal, criminal or malicious activity involving any domain name registration.

4) Other mechanisms: As required be ICANN Registry will comply to the Trademark Notice Notification service. This service will be implemented for the first 60 days after general availability is open. The service will be fully provided by the Registry and the Registrars need not to worry about the implementation of the notices. In addition to this, we will implement a special mechanism to encourage accurate WHOIS data. The mechanism will be explained further in this answer.


Resources:

The following resources will be employed by the Registry to avoid abusive registrations and unacceptable registrant behavior. 

- Compliance executive: The project manager of the extension will assume the roles of an executive Compliance officer. This role will be in charge of:

a) Receiving any abuse complaint on domains under the extension.
b) Serve as the point of contact for any issues regarding processes like URS and UDRP. The Compliance officer will also execute decisions regarding the policies.
c) Engage with outside providers for the internal monitoring of sites and monitoring of phishing or pharming activities.
d) Track and monitor the takedown of abusive registrations and sites involved in illegal activity such as phishing of pharming.
e) Participate and engage with ICANN regarding all compliance requests and policies to be implemented.
*Compliance officer will be in charge of setting up a single point of contact with information at the Registry website.
*Compliance officer will be bound to a SLA as described later

Registrar policy: Registry will also demand that an abuse point of contact be present at all accredited registrars and serve for:

a) Receiving any abuse complaint on domains under the extension.
b) Serve as the point of contact for any issues regarding processes like URS and UDRP. The Compliance officer will also execute decisions regarding the policlies.

- Other resources that may be needed by the Registry to implement the proposed mechanisms will be assigned from the actual operations team as per pragmatic requirements. At least one operations executive will be in charge of supervising the correct applications of the mechanisms and engaging with the Compliance officer to solve any issues.


Policy:

Pursuant to the RRA, the Registry reserves the right to deny, cancel, or transfer any registration or transaction, or place any domain name(s) on registry lock or hold, in its discretion, with the aim to:
- Protect the security and stability of the DNS;
- Comply with any applicable court order, laws, government rules and requests of law enforcement;
- Comply with any dispute resolution process;
- Comply with the terms of Registration Agreement;
- Avoid any liability, civil or criminal, on the part of the registry, as well as its affiliates, subsidiaries, officers, directors and employees;
- Correct mistakes of the registry or any registrars with regards to domain registration.

The Registry reserves the right to place upon registry lock, hold or similar status a domain name during resolution of a dispute.


Registrar policy: Registrar will be required to have terms and agreements with every registrant that strictly state what constitutes abusive behaviour, restricts the same, and clearly states remedies available as mitigation to such behavior.

- The Registry intends to incorporate Anti Abuse Use Policy into the Registry Registrar Agreement (RRA). Registrars should not tolerate abusive use related to domain names for which they act as sponsoring registrars. 
- Under the provision of the Registry Registrar Agreement, Registrar shall promptly investigate complaints alleging any such abusive practices, and shall take all appropriate actions based upon such investigations. Registrar shall use commercially reasonable effort to resolve the complaints, as request or recommended by the registry or any legal authority. 
- Registrar’s failure to comply with the policy shall constitute a material breach of the RRA, and shall give rise to the rights and remedies available to the registry under the RRA. 

Reseller policy: Registrar will be required and bound by the Registrar agreement to represent any Reseller as if the actions of the Reseller were made by the Registrar itself. Registrar will also be required to have terms and agreements with every reseller that strictly control and instruct policies in the case of abusive registrations.

Joining Working Groups: To keep up with knowledge in dealing with anti-abuse issues and mitigation practises, The Registry intends to participate in Anti-Phishing Working Group (APWG). The APWG is the global pan-industrial and law enforcement association focused on eliminating fraud and identity theft that result from phishing, pharming, and email spoofing of all types. The APWG also focuses on policy-related issues associated with the DNS to examine abuses of the DNS that may require remediation. The Registry may also tap into the forum of Registry Internet Safety Group (RISG). The purpose of RiSG is to facilitate dialogue, affect change, and promulgate best practices to combat domain name abuse, Internet identity theft in all its forms and malware distribution. The member registry operators are examining anti-abuse best practices and use cases for registries, and opportunities for data sharing. 

All other policies as instructed by ICANN and as found relevant to reduce abusive behaviour and Registrations.


Promotion of WHOIS accuracy: 

Several elements will be put in place for the promotion of WHOIS accuracy under the extension. Next we will name and describe each of the elements.

Policy elements:

1) Registry-Registrar Agreement: The Registry-Registrar Agreement will have in place clauses that require that Registrants deliver and maintain up to date information about the WHOIS information for domain names. These clauses must be present in the Registrar agreement, in any Registrant agreement and in any Reseller agreement.
1b) Regular Monitoring of Registration Data for Accuracy and Completeness : Registrars will be required to email with a reminder of registrant´s obligation to keep WHOIS data accurate as per WDRP. The Registry will rely on the WHOIS Data Reminder Policy (WDRP) set down by ICANN for the accredited registrars to ensure the WHOIS data of all domain names are at least reviewed once a year for accuracy. The email will include the actual WHOIS data and instructions to update the information. 

2) Thick Registry: The implementation of the Registry will be a thick Registry and therefore the Registry will have information on the Registrants as provided by the Registrar. (Except of registrations with proxy data)
3) Registrars will be required by the registry to undertake reasonable steps whenever there is a report of inaccurate information in WHOIS.

Special REBATE WHOIS accuracy promotion mechanism:

The Registry will promote whois accuracy by a proprietary mechanism described next:

- A random selection of registrants not using PROXY services will be emailed with a request to verify email and phones provided.
- For the verification, a link in the initial email will be sent to the email provided as the regsitrant email. The link in the email must be clicked to verify the accuracy of the email delivered. This click will take the registrant to the Registry controlled validation site.
- For the verification of the phone number a text message, or an automatic call will be sent to the registrant phone number once the link in the first email has been clicked. The text message will include a PIN number that must be entered in the registry controlled site.

This data will allow us to know the estimate the accuracy of the WHOIS database and will allow us to actively participate in ICANN´s debate arount the enforcement of WHOIS infomation.

Specific topics on abuse prevention and mitigation

Management of orphan glue records: The Registry does not allow orphan glue records. Glue records are removed when (or required to be removed before) the delegation point NS record is removed. Other domain names that need the glue record for correct DNS operation may become unreachable or less reachable depending on their settings of DNS service.


What constitutes abusive behaviour: The Registry does not tolerate the abusive use of its domain name, which causes security and stability issues for the registry, registrars and the general Internet community. The Registry defines abusive use as the wrong use of power, position or ability. Abusive behavior will be any act done by any registrant that were to violate the rights of any other person or legal entity, in any jurisdiction, whether it were by the sole act of a registration of a domain or by the usage given to the same for the publishing of content or its use for communicative purposes. Abusive behavior includes but is not limited to the following:

- Illegal or fraudulent actions;
- Any form of spam i.e. email spam, messaging spam etc;
- Phishing which involves the use of bogus websites to obtain personal information;
- Pharming which involves redirecting unknowing users to fraudulent websites to obtain personal information;
- Willful dissemination of malware;
- Fast-flux hosting which involves the use of DNS to frequently change the location of a website to hide its location or host illegal activities; and
- Botnet command and control.


SLA for resolution of abuse complains: Registry will comply to timing as indicated in Dispute Resolution policies adopted by ICANN. 

1. Participating in Uniform Rapid Suspension (URS)

The Registry will cooperate with ICANN for the implementation of URS, shall the policies and procedures are finalized. The involvement of the registry for the scope of URS shall include the following:

- Upon completion of the Administrative Review, the URS Provider will immediately notify the registry (via email) (“Notice of Compliant”) after the Compliant has deemed compliant with the filing requirements. Within 24 hours of receipt of the Notice of Complaint from the URS Provider, the registry shall “lock” the domain name, meaning the registry shall restrict all changes to the registration data, including transfer and deletion of the domain names, but the name will continue to resolve. The registry will notify the URS provider immediately upon locking the domain name (“Notice of Lock”).
- If after the Examination in Default case, the Examiner rules in favor of the Registrant, the URS provider shall notify the registry. Upon receiving the official notice from the URS provider, the registry will unblock the name and return full control of the domain name registration to the Registrant.
- If the Determination is in favor of the Complainant, upon receiving the official decision from the URS provider, the registry will suspend the domain name, which shall remain suspended for the balance of the registration period and would not resolve to the original web site. The nameservers shall be re-directed to an informational web page provided by the USR Provider. 

2. Service Level for responding to law enforcement requests

In responding to law enforcement requests, the Registry will use the provision within the Anti-Abuse Domain Use policy to act quickly to take down sites that are harboring malware, launching phishing attacks, or otherwise being used to launch attacks across the Internet. 

3. The following internal SLAs will also be enforced:

- Reply to an abuse claim: 12 hours
- Communication to all related parties of any abuse complain: 12 hours
- Compliance to any instructions given by Administrators panellists of other authorized personnel: 36 hours


Resource and Operation Plan

As this issue is heavily related to policy, resources constitute only means of executing the proposed mechanisms. For the implementation the following resources will be available:

- Compliance officer
- Operational executive (support)

These two persons will manage implement and track the execution of the proposed Abuse Mitigation measures.

On-hand resources: 

- Registry team has run for almost 3 years Domain Registration Services that have been very successful in Colombia and in more than 10 countries around the world. Registry team will be comprised of experienced executives in the domain registration business from Central Comercializadora de Internet (ICANN Accredited Registrar). Resources are on hand for all the non technical operations of the Registry. On hand operational non technical resources for this task include:

- Project manager (Compliance officer)
- Operational executive (One of the two support specialists)
These resources are currently part of the team that runs Central Comercializadora de Internet (ICANN Accredited Registrar).

Resource activity plan:

As this task is strictly related with policy it will be the Registry team that will be in charge of this aspect. 

From the Registry side, Project manager, support specialists, and Technical Leader will handle issues related to administrative control, non technical relationship with Registrars, relationship with ICANN, relationship with providers such as Qinetics, Policy monitoring and Management, etc. Registry team will fulfill all of the tasks and activities detailed above.

Rights Protection Mechanism

Registry commits to implement rights protection mechanisms sufficient to comply with at least minimum requirements in specification 7 of the Registry Agreement. The Registry shall implement and adhere to any Rights Protection Mechanisms (RPMs) that may be mandated by ICANN from time to time. Additional RPMs as further described below may also be developed and implemented by the Registry to discourage and prevent abusive domain name registrations. All RPMs mandated by ICANN and independently developed by the Registry will be included in the Registry registry-registrar agreement.

〈Many of the answers to the following questions may overlap answers to issues related with Abuse prevention. This situation arises because mechanisms implemented may serve both causes: Abuse prevention and Rights Protection〉

In this question we will address the mechanisms and resources we will use to protect rights of potential and actual registrants of domains under the extension.

- Mechanisms
- Resources
- Policy

Mechanisms

Mechanisms implemented for Rights protection can be divided in two sections:

- Mechanisms that grant priority to interested parties with rights over a domain
- Mehanisms that relieve situations in which a registration was made violating someone else´s rights

We will next list the mechanisms proposed under both sections and explain the detail for each one.

Priority mechanisms

1) Launch phases (Gradual Offering Plan): As stated before the registry will implement a Gradual offering plan that seeks to fairly assign domains to their rightful owners.

- Sunrise: As mentioned ealier a Sunrise phase will be implemented to grant privileged accesss to Registrants representing valid Trademarks as per the Sunrise policies implemented.
- Landrush: For Trademarks that do not qualify for the sunrise phase and for individuals with interests in strings that are not protected by Trademarks the Landrush phase will allow a period for the assignment of domains not in a first come - first served basis.

Trademark Clearinghouse: The Registry will use Trademark Clearinghouse to support its pre-launch or initial launch period rights protection mechanism (RPMs). These RPMs, at minimum, will consist of a Trademark Claim service (explained later) and a Sunrise process. 
- The Registry agrees to adhere to the Clause 6 ‘Mandatory Rights Protection Mechanisms’ and Clause 7 ‘Protection for Marks in Clearinghouse’ of the Trademark Clearinghouse attachment to the AGB. 
- The Registry shall also take reference to the Trademark Notice as attached in the same document. 
- The Registry has allocated budget as cost of sales to pay Trademark Clearinghouse for the Trademark Claims and Sunrise service.

By the use of these phases we grant priority access to domain registrations to companies and individuals with rights over specific domains. If a party holds rights over a certain string, they may register the corresponding domain in the Sunrise phase before anyone else. On the other hand, for special circumstances rightful owners may request a domain in the Landrush phase without being subject to the First Come First Serve basis. This opportunity gives rights to rightful owners to participate for the registration without priority, but whithout the hassle of timeframes.


Relief mechanisms

1) Resolution policies adopted: Registry will adopt Resolution policies as per ICANN indications

- URS: The Uniform Rapid Suspension process will be implemented by the Registry to allow for rapid takedown of abusive regsitrations. The Registry will cooperate with ICANN for the implementation of URS, shall the policies and procedures are finalized. The involvement of the registry for the scope of URS shall include the following:
- Upon completion of the Administrative Review, the URS Provider will immediately notify the registry (via email) (“Notice of Compliant”) after the Compliant has deemed compliant with the filing requirements. Within 24 hours of receipt of the Notice of Complaint from the URS Provider, the registry shall “lock” the domain name, meaning the registry shall restrict all changes to the registration data, including transfer and deletion of the domain names, but the name will continue to resolve. The registry will notify the URS provider immediately upon locking the domain name (“Notice of Lock”).
- If after the Examination in Default case, the Examiner rules in favor of the Registrant, the URS provider shall notify the registry. Upon receiving the official notice from the URS provider, the registry will unblock the name and return full control of the domain name registration to the Registrant.
If the Determination is in favor of the Complainant, upon receiving the official decision from the URS provider, the registry will suspend the domain name, which shall remain suspended for the balance of the registration period and would not resolve to the original web site. The nameservers shall be re-directed to an informational web page provided by the USR Provider. 
- The Registry will incorporate URS into the Registration policies, as a takedown measures and procedures to minimize abusive registration. 

Alternative use of Rapid Takedown Dispute Resolution Policies: In the absence of URS, the Registry may provide a Rapid Takedown process through engagement with a dispute resolution provider that consists of a response team of qualified expert (qualified UDRP panelist). The Registry agrees that majority of cases that go through the Uniform Dispute Resolution Process (UDRP) are mainly obvious variant of well-known marks. As such, it would be a waste of time or resources for the most obvious cases of infringement to go through the UDRP filings. Registry may provide a rapid takedown process where a response team of qualified experts (qualified UDRP panellists) will be involved to determine within 48 hours of receipt of a short and simple claim of involving a well-known mark or otherwise inherently distinctive mark and a domain name where no conceivable good faith basis exists. The results may result in an immediate termination of the domain name, but will not prejudice either party’s election to pursue other dispute mechanisms.


- UDRP: The UDRP will be adopted and Registrars will be required to comply to any and every determination made by the administrative entity handling any UDRP process. The Registry will adopt UDRP within the Registration Agreement and also be adopted by the registrars. Essentially, the UDRP is a policy between a registrar and its customer and is included in registration agreements for all ICANN-accredited registrars. 


The policies mentioned above are relief measures that may be adopted by any person or company if rights have been violated through a domain registration. We will attend and implement the mentioned procedures in a strict manner.


Other mechanisms: As required be ICANN Registry will comply to the Trademark Notice Notification service. This service will be implemented for the first 60 days after general availability is open. The service will be fully provided by the Registry and the Registrars need not to worry about the implementation of the notices. 


Resources:

The following resources will be employed by the Registry to promote the rightful behavior of registrants of domain names under the extension. 

- Compliance executive: The compliance executive will serve as a leader of the implementation of rightful policies and mechanisms for domains under the extension.

Tasks of the Compliance executive related to rigths protection include:

a) Serving as the point of contact for any issues regarding processes like URS and UDRP. The Compliance officer will also execute decisions regarding the policies.
b) Promote the comunication of rights protection mechanisms among registrants and the general audience.
c) Participate and engage with ICANN regarding all compliance requests and policies to be implemented.
*Compliance officer will be in charge of setting up a single point of contact with information at the Registry website for rights protection issues.
*Compliance officer will be bound to a SLA as described later


Policy:

Registrar policy: Registry will also demand that a rights protection point of contact (may be the same abuse point of contact) be present at all accredited registrars and serve for:

a) Receiving any rights complaints about registrations.
b) Serving as the point of contact for any issues regarding processes like URS and UDRP. 

Registrar policy: Registrar will be required to have terms and agreements with every registrant that strictly state what constitutes rights violations, restricts the same, and clearly states remedies available as mitigation to such behavior.

Reseller policy: Registrar will be required and bound by the Registrar agreement to represent any Reseller as if the actions of the Reseller were made by the Registrar itself. Registrar will also be required to have terms and agreements with every reseller that strictly control and instruct policies in the case of rights violations.

All other policies as instructed by ICANN and as found relevant to reduce unrightful domain Registrations.


Specific topics on rights protection 

It is not the responsibility of the Registry to determine if a domain registration is rightful or not. For this purpose, Administrative entities and establishemnts have been set. The Registry will conform to policies and procedures but must not intevene in legal determinations whatsoever.

SLA for resolution of rights violation determinations: Registry will comply to timing as indicated in Dispute Resolution policies adopted by ICANN. The following SLAs will also be enforced:

- Reply to any rights violation claim: 12 hours
- Communication to all related parties of rights violation claim: 12 hours
- Compliance to any instructions given by Administrators panelists of other authorized personnel: 36 hours


Resource and Operation Plan

As this issue is heavily related to policy, resources constitute only means of executing the proposed mechanisms. For the implementation the following resources will be available:

- Compliance officer
- Operational executive (support)

These two persons will manage implement and track the execution of the proposed Abuse Mitigation measures.

On-hand resources: 

- Registry team has run for almost 3 years Domain Registration Services that have been very successful in Colombia and in more than 10 countries around the world. Registry team will be comprised of experienced executives in the domain registration business from Central Comercializadora de Internet (ICANN Accredited Registrar). Resources are on hand for all the non technical operations of the Registry. On hand operational non technical resources for this task include:

- Project manager (Compliance officer)
- Operational executive (One of the two support specialists)
These resources are currently part of the team that runs Central Comercializadora de Internet (ICANN Accredited Registrar).

Resource activity plan:

As this task is strictly related with policy it will be the Registry team that will be in charge of this aspect. 

From the Registry side, Project manager, support specialists, and Technical Leader will handle issues related to administrative control, non technical relationship with Registrars, relationship with ICANN, relationship with providers such as Qinetics, Policy monitoring and Management, etc. Registry team will fulfill all of the tasks and activities detailed above.

Summary of Security Policies

.NEWS Registry will outsource the technical backend registry service to Qinetics. Registry will deploy Security Policy and Security Measures as adopted by Qinetics. The policies established provide a comprehensive approach as highlighted below, to identify and prevent unauthorized access, intrusion, loss of information and software error. Qinetics has wide experience on security implementation with successful implementation of ISO27001 in .HK registry system. The procedures, policies, and infrastructure deployed for the ISO27001 certification will be deployed for the extension.

In the following summary we will address shortly the following security elements:

1. Phsical Security
2. Network Security
3. Server Level Security
4. Application Level Security

Furthermore a General Policy Framework will be outlined and the result of an independent product assesment will be referenced.

1. Physical Security

Application and infrastructure security are based on a set of layers. The initial layer is the Physical Security Layer. Physical security is provided by the data centers that will be used to deploy the registry solution. Only authorized personnel are allowed to enter the premises of the data center. The data center has several policies in place regarding physical security including but not limited to: Data Center Access Policy, Equipment Policy, Site Visits Policy and Network Security. This layer protects all equipment in the network from hacker or malicious attack at a physical level. 

2. Network Security

On top of the Physical layer, a Network Security Layer will provide monitoring and reaction policies to mitigate any attack based on the network infrastructure. For this, a set of sniffers will be in place to screen all the traffic of the registration system. Packetes and traffic will be monitored continuously to avoid DDOS attacks or other malicious attemtps to affect the system by degrading the network performance. Security alarm will be triggered if there are abnormal activities in the network. Policies related to Network Security have been put in place and include, among others: Firewall Policy, Denial of Services Policy and mitigation plans, System Monitoring Policy, Network Hosts Security.

3. Server Level Security

The Server Level Security policy layer enforces the policies and procedures in place that mitigate any issues related with security at the server level. This includes management and attention to security issues relating Operating System and Server extensions and access policies. These two sets of policies are in place to mitigate any issues that may be compromise security at the Server and Usage level of the registry services deployed. A governance policy will be developed and strictly enforced to establish control over access and movement of servers. 

4. Application Level Security

Security is built within the applications running on the servers. The applications are built using the well known OWASP security policy. This way the application is built maintained and managed taking into account: 1) Organizational Management towards security threat mitigation, 2) A written policy properly communicated aross the organization for all related parties and derived from strict standards, 3) A development and maintenance methodology with thorough checkpoints and monitoring, and 3) A clear devised process for the secure release and configuration of products, changes and procedures. 

General Policy Framework

Furthermore, a strict set of policies have been structured at the General Level to guarantee consistent methods of access, usage and transmission of information within and outside the organization. These policies include:

- A Systemwide Password Policy that mandates on general parameters of use and maintenance of Passwords.
- A Data Integrity Policy to enforce integrity of information and infrastructure at the General Level of the Registry.
- A System audit Policy to perform independent assesment of the Security, policies, procedures and implementations in place.
- A Security Patch Policy built in to structure upgrades and keep systems up to date. 
- A Security Response Policy that guides every step that should be taken into account as a reaction to any materialized threat.
- An Acceptable Use Policy to determine any and every user´s acceptable behavior related to the Registry system.

Registrar Security: A Registrar Agreement will be in place with the corresponding measures of the Policy Framework that are related to Registrars.


Product Assessment

Qinetics has engaged independent 3rd party auditor to perform product assessment on 28th Dec 2011 till 29th Dec 2011. The Malaysia MSC Product Assessment & Rating Standard was developed by TUV Rheinland Malaysia Sdn. Bhd., in collaboration with Macrofirm Technology Sdn. Bhd., under the commissioning of the Multimedia Development Corporation (MDeC). TUV Rheinland Malaysia is a member of TÜV Rheinland Group, a global leader in independent testing and assessment services. The TÜV Rheinland Group was established in 1872, and has offices located in over 490 locations in 61 countries on all five continents. 

Existing software quality evaluation standards were used as the basis for the development and endorsement of the software quality criteria and sub-criteria to be assessed in MSC Malaysia Software Product Assessment and Rating Standard. This is also referred to as the “As-is Situation”. The standards used as the basis for development of this assessment standard are as follows:

- CMMI (Capability Maturity Model Integration) Ver. 1.3 Dev 
- ISO⁄IEC 9126 (Software Engineering – Product Quality) 
- ISO⁄IEC 14598 (Information technology - Software product evaluation) 
- Common Criteria (CC)

In the product assessment, a total of 13 main requirements or criteria, divided into 6 process-related criteria (criteria in which the process of development of the software product is assessed) and 7 product-related criteria (criteria in which the developer’s methods to manage and ensure the actual performance of their software product is assessed), were identified for inclusion in the Standard. These criteria in turn were divided into a further 44 process-related sub-criteria and 32 product-related sub-criteria to make a total of 76 sub-criteria.


Evaluation Report

This evaluation report is based on the findings of the MSC Malaysia Product Assessment & Rating on-site product evaluation. As a supplement to the awarded rating, this report provides recommendations to improve the company’s methods of ensuring product quality.

The MSC Malaysia Product Assessment & Rating rates the product on 13 main criteria which are divided into:

1) Six (6) Process-related criteria, ie. criteria in which the process of development of the software product is assessed.
2) Seven (7) Product-related criteria, ie. criteria in which the developer’s methods to manage and ensure the actual performance of their software product itself is assessed.

Results of the evaluation are as below:

Overall % Compliance 97 %

Process-Related Requirements:

- Requirements Management 95 %
- Technical Solution 100 %
- Product Integration 100 %
- Validation 98 %
- Verification 100 %
- Support 100 %

Product-Related Requirements:

- Functionality 100 %
- Reliability 100 %
- Security 91 %
- Usability 92 %
- Maintainability 100 %
- Portability 96 %
- Architectural Principles 97 %

The assesment states the proper implementation of Qinetics of Security policies and procedures. The Registry an Qinetics will constantly work together to further strengthen and improve policies and procedures regarding Security.


Resource and Operation Plan

On-hand resources: 

- Qinetics has served domain registration services for .HK, .SG, .MY, .CD, etc. with a long track record of success. Technical resources are on hand for the full implementation of the proposed Registry. 
- Registry team has run for almost 3 years Domain Registration Services that have been very successful in Colombia and in more than 10 countries around the world. Registry team will be comprised of experienced executives in the domain registration business from Central Comercializadora de Internet (ICANN Accredited Registrar). Resources are on hand for all the non technical operations of the Registry. On hand operational non technical resources include:

- Project manager
- Two support specialists 
- Technical leader

These resources are currently part of the team that runs Central Comercializadora de Internet (ICANN Accredited Registrar).

Resource activity plan:


Qinetics will deploy the Registry Service of Registry using its existing system and infrastructure. During the implementation of Registry, new server hardware will be provisioned for the Registry service that will alow for the configuration all the Security Mechanisms. 

The following human resources will be used:

- Project Manager
- Datacenter Engineer
- System Administrator
- Database Administrator
- Software Developer⁄Application support
- Test Engineer

The Data Center Engineer will perform the server provisioning and installation of OS. Once the hardware is provisioned, System Administrator shall continue to install the required software and perform security configurations. The assigned Software Developer will configure the rules that apply for the Security requisites of the system. Once done, the Test Engineer will perform rigorous testing procedures to ensure the system performs according to specifications. When testing is completed, the registration system shall be hand-over to System Administrator to perform deployment to production environment. Throughout the process, a Project Manager is assigned to perform project management and overall control on the implementation. The Project Manager will conduct training to the registry users on the specific behavior of domains under the registry. 

After deployment

The system will be in maintenance mode after the System is deployed. Any issues regarding security of the system will be immediately attended. Whenever there is a support ticket related to security, Application Support Engineer and System Administrator will further escalate the support request. The emergency response team will be triggered whenever there is a catastrophic scenario at the highest severity. 

From the Registry side, Project manager, support specialists, and Technical Leader will handle issues related to administrative control, non technical relationship with Registrars, relationship with ICANN, relationship with providers such as Qinetics, Policy monitoring and Management, etc.

Bug tracking

After an issue has been identified, and once a remedy is available, the Test Engineer will perform testing on the fixes before deployment by System Administrator. During maintenance, Qintetics will commit 4 resources for the 24 x 7 helpdesk, 4 data center engineers, 2 application support engineers, 1 support manager, 1 test engineer and 2 system administrators. 

Continuous management

As part of ongoing policy changes, a team of software developers is available for any standards upgrades and necessary changes to system setup. Changes will trigger the change request procedure in accordance to CMMI standards.