Application Preview
Application number: 1-943-512 for ECOM-LAC Federaciòn de Latinoamèrica y el Caribe para Internet y el Comercio Electrònico
Generated on 11 06 2012
Applicant Information
1. Full legal name
ECOM-LAC Federaciòn de Latinoamèrica y el Caribe para Internet y el Comercio Electrònico
2. Address of the principal place of business
Rambla Repùblica de Mèxico 6125
Montevideo 11400
UY
3. Phone number
4. Fax number
5. If applicable, website or URL
Primary Contact
6(a). Name
Mr. Anthony Ronald Harris
6(b). Title
6(c). Address
6(d). Phone Number
6(e). Fax Number
6(f). Email Address
Secondary Contact
7(a). Name
Mr. Oscar Alberto Messano
7(b). Title
7(c). Address
7(d). Phone Number
7(e). Fax Number
7(f). Email Address
Proof of Legal Establishment
8(a). Legal form of the Applicant
Non-profit Non Governmental International Organization
8(b). State the specific national or other jursidiction that defines the type of entity identified in 8(a).
Decree Nº 334⁄70 of 14⁄07⁄1980, Republic of Uruguay
8(c). Attach evidence of the applicant's establishment.
9(a). If applying company is publicly traded, provide the exchange and symbol.
9(b). If the applying entity is a subsidiary, provide the parent company.
9(c). If the applying entity is a joint venture, list all joint venture partners.
Applicant Background
11(a). Name(s) and position(s) of all directors
Eduardo Parajo | Director |
Hugo Montgomery | Treasurer |
Jacobo Cohen Imach | Vice President |
Julio Cesar Vega | Director |
Osvaldo Novoa | Secretary |
Pedro Less Andrade | Vice President |
Pinkard Brand | Director |
Ricardo Presta | Vice President |
11(b). Name(s) and position(s) of all officers and partners
11(c). Name(s) and position(s) of all shareholders holding at least 15% of shares
11(d). For an applying entity that does not have directors, officers, partners, or shareholders: Name(s) and position(s) of all individuals having legal or executive responsibility
Applied-for gTLD string
13. Provide the applied-for gTLD string. If an IDN, provide the U-label.
14(a). If an IDN, provide the A-label (beginning with "xn--").
14(b). If an IDN, provide the meaning or restatement of the string
in English, that is, a description of the literal meaning of the string in the
opinion of the applicant.
14(c). If an IDN, provide the language of the label (in English).
14(c). If an IDN, provide the language of the label (as referenced by ISO-639-1).
14(d). If an IDN, provide the script of the label (in English).
14(d). If an IDN, provide the script of the label (as referenced by ISO 15924).
14(e). If an IDN, list all code points contained in the U-label according to Unicode form.
15(a). If an IDN, Attach IDN Tables for the proposed registry.
15(b). Describe the process used for development of the IDN tables submitted, including consultations and sources used.
15(c). List any variant strings to the applied-for gTLD string according to the relevant IDN tables.
16. Describe the applicant's efforts to ensure that there are no known operational or rendering problems concerning the applied-for gTLD string.
If such issues are known, describe steps that will be taken to mitigate these issues in software and other applications.
LAT is a three character string, and it is not an IDN. These two characteristics makes LAT string just the same as COM or NET, so there are no known operational or rendering problems for the gTLD string.
IDNs will be offered at the second level for spanish language. There are a number of TLDs that currently offer IDNs at the second level sucessfully without known operational or rendering problems.
17. (OPTIONAL) Provide a representation of the label according to the International Phonetic Alphabet (http://www.langsci.ucl.ac.uk/ipa/).
Mission/Purpose
18(a). Describe the mission/purpose of your proposed gTLD.
.LAT MISSION AND PURPOSE
Internet continues growing day by day, touching more and more people every day. This means that internet users need to identify and differentiate themselves, even beyond their own region, in an effort to reflect their identity in their cultural, social and business activities.
In response to this need, in recent years we have seen the advent of some new top level domains such as: ‘.biz’, ‘.info’, ‘.name’, ‘.travel’, ‘.mobi’, and notably the regional identity TLDs – ‘.eu’, and ‘.asia’ and cultural identity domains such as ‘.cat’ . These two latter domains, offer their registrants the option of registering domain names that enable them to establish a regional or cultural identity in the Internet, in comparison with, for example, a national identity obtained by registering their domain names under a country code top level domain (ccTLD).
With the purpose of responding to the need of choice, and to give latino individuals and organizations from all over the world a new choice to identify themselves with the rest of the internet, eCOM-LAC and NIC Mexico have partnered together to participate in ICANN’s New gTLDs Program and apply to obtain the delegation of a new top level domain for latinos: .LAT
.LAT is easily recognizable and has intrinsic meaning as oriented to latinos and has the potential to serve as a virtual space that brings together the diverse actors that make up the latino community.
ABOUT ECOM-LAC
eCOM-LAC is the Latin America and Caribbean Federation of Internet and Electronic Commerce. Founded in March 1999 in a meeting of stakeholders held in Rio de Janeiro, eCOM-LAC was conceived as a non-profit regional entity, which could congregate non-profit industry associations, chambers of commerce and corporations, interested in contributing to the development of the Internet and Electronic Commerce in the region. The entity registered formally in the Republic of Uruguay as an International Non-Profit Entity, and has legal and administrative offices in the LACNIC building in Montevideo.
The entity’s main activities can be summarized thus:
* Participation in ICANN since 1999, attending every ICANN meeting worldwide
* Founding member of LACNIC - 1999
* Organizer of two Regional e-Commerce Summits – Sao Paulo 2000, Buenos Aires 2001
* Participation in the World Summit of the Information Society (WSIS)-2003-2005
* Social inclusion educational project titled “Mi lugar, Atlas de la diversidad” – 2002-2004 (As member of group of NGOs in the European Commission @lis program)
* Became a member of Global Knowledge Partnership (GKP) in 2006
* Became member of GKP Board of Directors (2009), and then a Trustee of the new GKP Foundation (registered in Gijòn – Asturias, March 2011)
* Organized two “Future of the Internet” conferences – Chile and Brazil (2010)
* Organized two Latin America⁄Caribbean Public Policy Forums – Miami 2010 and 2011
A TLD FOR LATINOS
Latin or Hispanic population, latinos, refers to people who have in common or share a strong heritage of any country from Latin America, this special link is strengthened by their own cultural influence. Being that the most common languages in Latin America have the same origin, it is easy to understand why language is one of the most important cultural influences in this culture.
Notwithstanding the existing and clearly visible geographic differences in Latin America, latinos are noted for preserving a strong identity connection with people from their same origins. This linkage is reinforced by the existing similarities that are characteristic of latino countries, be it in their political histories, their social structures and their economies.
The latinos that live in a country they were not born in, tend to miss their old way of life, such as the habits and customs they performed daily. This homesickness becomes a factor that increases the latino sentiment, with this the latino population generates and develops a series of activities within their community, in order to link up and remember their past, be it through specialized commercial products, integration cultural activities, religious festivities, etc. In the United States, these activities are generating a resurgence of the latino identity, which to a degree, is caused by the increase in purchasing power of the new latino generations and the migrations of the last decades.
OBJECTIVES OF THE .LAT
The .LAT is an initiative to give latino individuals and organizations from all over the world a new choice to identify themselves with the rest of the internet, enabling them to promote their culture, interests and heritage through internet presence with latin identity.
The objectives the .LAT initiative pursues are:
* Adopt a new gTLD oriented to the latino community. This translates to the development and promotion of a new category of specialized domain names for the latino community, becoming a real alternative to the current TLDs.
* Establish a gTLD that is easily recognizable. The .LAT, due to its number of characters and intrinsic meaning, will be easy to memorize, and will represent a cultural legacy more than a geographic space.
* Facilitate regional communication between latinos. The .LAT will serve as a means of drawing close, targeted at the worldwide latino community, be they residents of their country of origin, or people who have had to migrate to another country.
* Guarantee a virtual space that brings together the diverse actors that make up the latino community. The latino diversity does not center only on country of origin, but it also includes their social environment and economic activity: companies, institutions and civil society.
* Turn the .LAT domain into a platform for the growth of the Internet, and as a tool for business in the latino market. The .LAT will be a digital component that will increasingly enable more latino companies and individuals to initiate or continue their growth and conquer new markets on a global scale. Thus, the gTLD will promote the visibility of the latino market, offering a communication channel via the Internet by leveraging the high label recognition, multiplying the efforts of companies and individuals seeking to offer services and⁄or products for the latino market through the Internet.
* Promote and develop the use of information technologies. The .LAT will contribute to the process of developing technologically based initiatives, that promote the development of the Internet, focused on the welfare of latinos and reinforcing their identity on the Internet.
* Complement the development of the latino ccTLDs, The existing links between the diverse latino ccTLDs will be reinforced and thus, between the communities that make up and use these ccTLDs, taking the integration between the users of these ccTLDs to the next level, to a global scale. This will result in an important impulse in the category of latino domain names, projecting them as an increasingly attractive market. A specialized domain will assist in the acceleration and self-evolution of the latino identity, which will complement the national identity.
In summary, the .LAT TLD is the “logical home” for latinos all over the world seeking internet presence with latin identity.
With the development of the .LAT new gTLD, eCOM-LAC will get the funds necessary to finance projects and initiatives contained in the main directives of the organization, like the development of information technologies in Latin-America , and also the promotion and support to projects and initiatives that focus on reducing the digital divide.
18(b). How proposed gTLD will benefit registrants, Internet users, and others
I. WHAT IS THE GOAL OF YOUR PROPOSED GTLD IN TERMS OF AREAS OF SPECIALTY, SERVICE LEVELS, OR REPUTATION?
The aim of .LAT, as far as specialization, reputation and levels of service, is to offer a gTLD directed specifically to the latin market, with an ongoing commitment to maintain stability of the Internet, implementing the highest levels of service to offer a service that is trustworthy and up to par with the industry. The .LAT will undertake the necessary marketing and communication efforts to ensure a high degree of identification with the latin market. With .LAT we aim to create a TLD that really knows the latin market, and which permanently is keeping abreast of the needs of this market, in order to respond appropriately with services and policies which will address these needs.
II. WHAT DO YOU ANTICIPATE YOUR PROPOSED GTLD WILL ADD TO THE CURRENT SPACE, IN TERMS OF COMPETITION, DIFFERENTIATION, OR INNOVATION?
Competition promotes innovation, since it can multiply the benefit of innovating. The .LAT will present a platform for innovation, for the offer of online services and products from and to the latin market. The .LAT itself has an important differentiation factor since it relates directly to latinos, enabling their easy identification and adoption by the consumers.
The .LAT is presented as a globally visible domain that provides a space for the spirit of integration of the latinos, that need not depend on the limitations of the existing generic TLDs. At the same time it participates in expanding the distribution of the Internet infrastructure outside of the more developed countries.
.LAT TLD will be dedicated to serve the interests of the latino market, focusing on a differentiated marketing effort which will be tailored for this market, offering services of the highest level suitable to the market and it’s special characteristics.
Knowing the market enables us to approach it, enter into alliances to ensure that the TLD penetrates the market, guaranteeing effective distribution and promotion to the market that we wish to serve. We will differentiate from the other TLDs in the service and the marketing.
III. WHAT GOALS DOES YOUR PROPOSED GTLD HAVE IN TERMS OF USER EXPERIENCE?
Latinos have in common a strong heritage, a mixture of vestiges of an ancient civilization and the language and religion brought from the old continent by the colonizers. If diverse in various aspects, latinos from different countries and origins have found the way to set common grounds to facilitate supranational cooperation mechanisms, while preserving what makes them different and unique.
Thus, Latin society shares literature, music, movies and more. The communication and entertainment industry (TV, radio, newspapers, books, films) recognizes the relevance of the Latino community and how fundamental this segment is for its business purposes. This segmentation allows them to customize products and services focusing in a single community that regardless of their nationality will always be part of the Latino community.
Since this is a TLD meant for the latinos, we seek to offer the possibility of being able to register Internet domain names that reinforce the latin identity. With the .LAT, the users of the net will find it easier to locate sites and people they are familiar with. The latinos can be present with an identity that enables them to identify with their roots, tell the world who they are and where they come from. They could expect that a website or service under a .LAT will contain elements they are familiar with, or that they will be directed in a manner that enables easy access.
As part of the marketing and brand positioning efforts, we will seek agreements with the largest possible amount of ICANN Accredited Registrars (NIC Mexico currently works directly with some of the biggest ones). At the same time we will promote the Accreditation of Registrars that are latin companies. By promoting the accreditation of increasing numbers of latin companies, we can also enhance the offer of services from the other TLDs (existing or new), thus promoting the entire category
At the same time, moved by domain name market growth among latinos, we could expect more and more companies looking into offering services over the internet within that market, promoting investment and economic growth. Nevertheless, market growth comes along with the necessity of providing increased security standards and abuse prevention practices altogether with rights protection mechanisms.
With this in mind, .LAT registry will look to engage with a latin organization that could become a regional dispute resolution provider. This will enhance the capabilities in the region to attend the problems related to trademark infringement and other domain use related abuses. In addition, it might drive experience to other TLDs in the region that do not have access to the UDRP (and URS) mechanisms and also catch the attention of other relevant actors in the latin community that could participate in such project.
IV. PROVIDE A COMPLETE DESCRIPTION OF THE APPLICANT’S INTENDED REGISTRATION POLICIES IN SUPPORT OF THE GOALS LISTED ABOVE.
.LAT REGISTRATION POLICIES
.LAT is a self-explanatory TLD, highly recognizable and primarily associated with latinos all over the world. .LAT will be a standard, general purpose TLD so there will be no registration restrictions other than the ones being imposed by ICANN in the Guidebook and the Consensus Policies.
.LAT will only accept domain names requests from ICANN Accredited Registrars. Furthermore, .LAT has a strong commitment to develop the latino domain name market and will engage with latino registrars to help them become ICANN accredited so they can participate of market development and contribute to market growth.
REGISTRATION OF DOMAIN NAMES
By receiving and accepting a domain registration request .LAT Registry recognizes the right of the Registrant to the use and enjoyment of a Domain Name during the registration period. This does not imply the transfer and⁄or granting of any ownership rights.
By registering a domain name, the registrant accepts, to the best of its knowledge, that the domain name being registered or its intended use does not infringe legal rights of third parties and further, that the domain name is not registered to be used for unlawful purposes.
The registrant accepts that by registering a domain name accepts to adhere and honor the resolutions rendered by the UDRP and URS evaluation panels as defined by ICANN. Also, the registrant accepts to adhere and honor the resolutions of the ʺRegional Anti-Abuse Centerʺ should it is created.
ALLOWED DOMAINS:
.LAT will accept domain name registration at the second level only, and the registered names must comply with ICANN policies and all applicable RFCs, like 1034, 1035, and others.
NAME RULES
* The total length of a domain name must not exceed 63 characters to the left of the .LAT label.
* Allowed characters are numbers “0” to “9”, hyphen “-“, and all letters from “a” to “z”
* Domain names must not contain only numbers and must not begin or end with hyphen, or contain two hyphen characters put together.
* Domain names included in the reserved names schedule defined by ICANN will not be registered.
REGISTRATION INFORMATION
As part of the registration process, the registrant is required to provide certain information through the Registrar and to update it promptly as soon as such information changes so that the registry records remain current, complete and accurate. The information that must be provided corresponds to:
* The name, postal address, e-mail address, and voice and fax (if available) telephone numbers of the registrant for the domain name;
* The name, postal address, e-mail address, and voice and fax (if available) telephone numbers of the administrative, billing and technical contact for the domain name;
The maximum validity period of the Domain Name registration is 10 years, according to the Registry Agreement.
IDN REGISTRATION
IDN registration will be provided in Spanish language.
* Allowed characters are numbers “0” to “9”, hyphen “-“, all letters from “a” to “z” and the following special characters from Spanish language: á, é, í, ó, ú, ü, ñ.
When registering an IDN there will be an extra availability check for an equivalent name. To construct the equivalent name first hyphens will be removed, and then all special characters will be replaced with the corresponding characters without the accent mark or in the case of “ñ” for “n”. IDN registration will not be permitted if there is an equivalent domain name in the database for a different registrant.
Any change or update to these Policies will be published with a notice of at least 15 days before going into effect.
RIGHTS PROTECTION MECHANISMS AND ABUSE PREVENTION
.LAT will implement Rights Protection Mechanisms including UDRP and URS. IP Claims service will be available for 60 days following the launch of the TLD.
A searchable whois will be provided as an extended service for clients in need of such feature like intellectual property owners and firms. This service would help them to identify and contact potential infringers.
The Sunrise period and the use of UDRP and URS, together with the IP Claims service should be sufficient to prevent any abuses in registration as all those mechanisms have been streamlined as a result of the work carried out by ICANN as part of the New gTLDs Program. In addition .LAT registry will be open to requests and suggestions from the community and will adopt any new policy on registration abuse as published by ICANN.
There will be an abuse contact who will accept reports on abuses and bad use of the domain names under the .LAT TLD.
V. WILL YOUR PROPOSED GTLD IMPOSE ANY MEASURES FOR PROTECTING THE PRIVACY OR CONFIDENTIAL INFORMATION OF REGISTRANTS OR USERS? IF SO, PLEASE DESCRIBE ANY SUCH MEASURES.
.LAT Registry will take every effort needed to balance the need for privacy with the need to provide access to records that contain information on the registrant and contacts of domain names in order to maintain security and stability of the DNS. .LAT registry will operate an accurate public WHOIS service in a way that is compatible with applicable privacy laws. .LAT will request from registrants the minimal set of information needed to perform the whois functions as required by ICANN.
.LAT registry will require registrars to post privacy policies and data practices that clearly communicate to registrants the type of data that will be collected and managed by the .LAT Registry and the use of such data to perform registry functions, specially the WHOIS service. Those policies and data practices will also include the rights of the registrants to access and correct data stored in the .LAT Registry database. The submission of a domain registration request made will imply consent from the registrar and the registrant of .LAT Registry’s data practices.
.LAT will allow registrars to offer data privacy services like proxy services, but will include the corresponding covenants for registrars to disclose information of domain name registrants upon request from authorities relevant to the .LAT Registry.
More detail will be provided in the description of registry services.
VI. DESCRIBE WHETHER AND IN WHAT WAYS OUTREACH AND COMMUNICATIONS WILL HELP TO ACHIEVE YOUR PROJECTED BENEFITS.
The availability of a TLD clearly related to latinos provides internet users all over the world a great opportunity to target a latin audience or, on the other side, gives latin companies and individuals the opportunity to get internet presence with latin identity. .LAT could be of great help to enhance any branding strategies for the latino market . The self-explanatory nature of the TLD could clearly facilitate its use over the internet among the targeted audience.
The .LAT will serve latino market interests, by providing the means to implement differentiated commercialization and marketing strategies, tailored for the latin market.
.LAT outreach and communication efforts will focus first on its own brand building and positioning in developed markets, and then .LAT will look into developing the market in less developed areas by promoting and facilitating the use of .LAT domain names to get Internet presence with latin identity.
eCOM-LAC is uniquely positioned to promote the .LAT domain. Some of its members, such as chambers of commerce, want to promote the domain to their members, since this is seen as an opportunity to offer latino entities, companies, businesses and professionals a specific highly recognizable domain, whereas when the Internet became available for public use, registration in the .COM space was almost a default option for a registrant seeking a non-territorial domain name. The partnership of two entities such as eCOM-LAC and NIC Mexico, together with the potential of the hundreds of companies that belong to eCOM-LAC member organizations, compose a considerable launching force.
BRAND BUILDING AND POSITIONING
.LAT Registry will implement an outreach and communication program to inform of the availability of the new TLD to create awareness and achieve positioning. The program will focus first on certain cities with the highest concentration of latin internet users. Some of the cities considered for this program are: Buenos Aires, Bogotá, Santiago, Mexico City, Chicago and New York.
The strategies consider partnering with relevant local organizations and individuals that can help in putting the word out for .LAT, for example: get feature articles on local newspapers, share information on the project with local bloggers, news shows appearances and interviews and also sponsoring of local internet related events, among other things. We are also considering for this first phase to include some urban advertising like panoramic ads, public buses and bus stops, and the subway system.
The brand building efforts will also include arrangements with some of the brands on the top of mind of consumers to use .LAT domain names on their advertising for the latin market, specially brands that have specially focused campaigns and distribution channels for latin consumers. In general, we’ll try to reach organizations that could have a positive impact in the TLD’s positioning.
.LAT will look for sponsoring opportunities on industry related events, to seize the opportunity to spread the word about .LAT and talk to industry protagonists and opinion leaders to find a way to aggregate efforts to promote the use of .LAT domain names.
In order to facilitate the adoption of the TLD, it’ll be necessary to develop the distribution channel, so .LAT will engage with latin registrars, most of them resellers, to help them get ICANN accredited whenever possible and convenient. On the same track, .LAT registry will work with accredited registrars that have a special interest on the latin market to invite them to carry the TLD, and develop or improve their reseller program to promote the entrance of new latin resellers and in that way, all work together to offer registrants TLD services on their own language.
.LAT will also develop a Discovery Program, oriented to early adopters that commit to invest in advertising for their projects and use a .LAT domain name. There will be an RFP that’ll focus on innovation; outreach and participation to ask for projects that will make an outstanding and innovative use of the desired .LAT domain name. We’ll try to find those projects that foster integration and creation of on-line communities to encourage creativity and entrepreneurship over the internet with latin identity.
Special consideration will be given to Social Networks; .LAT registry will conduct a highly specialized outreach campaign over Twitter and Facebook. Specialized consulting will be retained to design and conduct these campaigns to maximize the results.
MARKET DEVELOPMENT
The market development efforts will try to promote the use and recognition of .LAT domain names within latin individuals and institutions. These efforts will be oriented to create awareness and gain visibility of the new gTLD. The market development work will focus on:
* Establish the .LAT gTLD as a domain recognized for it’s global reach, but which emphasizes its presence in the latino market. This will provide an Internet domain with global recognition and coverage, but with a special focus on the latino market, targeted to satisfy the needs of the latino community in the Internet.
* A global focus. The .LAT will provide a specialized space to those global entities seeking to establish a presence in the latino community (for example, multinational companies).
* Become a reference point for the latino community vis-a-vis diverse private entities. Under this gTLD, the amount of domains, and the amount and quality of specialized third party contents, (with a global, regional or national coverage) targeted to the latino consumer, will thus be able to address them in their own language, and including references to their tastes and consumer preferences.
* Become a reference framework for events and organisms targeted to latinos. The .LAT will seek to become the official Internet platform for the diverse entities and events (public, private and civil society) interested in outreach to and from the latino community on the Internet.
* Support the growth of national companies in a multi-national environment. The .LAT will add value to the companies, because of its identification with the latino market, and due to its success in the marketing and sales of its products and services in this market. The .LAT domain will enable greater leverage to an Internet presence as a growth platform, making it increasingly attractive as an opportunity to reach a specific market, independently of its geographical distribution.
18(c). Describe operating rules to eliminate or minimize social costs or financial resource costs, various types of consumer vulnerabilities.
SOCIAL COSTS
LAT will not impose a social cost that is higher than the existing ones. As of today, there are dozens of ccTLDs that do not require registrants to demonstrate their place of residence to register a domain name. Nevertheless many of those ccTLDs are not widely used; they are used only by whom finds it relevant for their interests, or by whom shares the market focus of the TLD. Due to this it becomes especially important to have communications and positioning strategies specially tailored to promote the differentiation and specialized market focus of the .LAT on the latino market, as this will help potential registrars and internet users to decide if the .LAT is relevant for them or not.
MULTIPLE APPLICATIONS FOR A DOMAIN NAME
The .LAT is presented as an integrating element for latinos around the world through the Internet, as a tool that enables them to draw attention to their roots and interests, and the effort will be made to make this available to the community it intends to serve, while avoiding the price factor become an impediment for its adoption.
Nonetheless, we must consider the manner in which the domain names will be assigned to the registrants. The launching plan includes a sunrise period which will have special considerations for the rights of brand and intellectual property owners. Conflicting registrations received during the Sunrise Period will be resolved with clear policy, which will take into account trademark information validated by the Trademark Clearinghouse (TMC). The landrush will feature a first-come first-served approach with the use of a special pricing scheme. There will be no auctions for premium names previously reserved by the registry. The landrush will be followed by a traditional, first-come first-served registration process in the general availability launch.
All special names and words as specified in the Guidebook will be reserved and will not be available for registration.
COST BENEFITS
In order to facilitate the introduction and adoption of the .LAT, the marketing plans will include Price strategies that offer benefits to the registrants, through the registrars, enabling them to have access to preferential prices based on volume or during specific campaigns. Among the programs we intend to implement are the following:
* Discount campaigns during special seasons. The registry will actively participate in the promotion of the TLD, investing in advertising for positioning of the TLD, together with those registrars who elect to participate.
* Other appropiate discounts and offer to all participant registrars.
NIC Mexico was one of the first registries in the world that made important efforts in marketing and price strategies, in order to promote the positioning and growth of a TLD in its market, the .MX in this particular case. Due to the positive results achieved and the experience acquired, we believe it is possible to replicate some of these most successful strategies with the .LAT.
In order to minimize the social cost that .LAT may have, verification mechanisms required to increase the trustworthiness of the information will be implemented, including
* Thick Whois
* URS
* UDRP
* IP Claims
PRICING STRATEGIES
The Pricin strategy for the .LAT will aim to find a balance between offering an attractive margin to registrars while at the same time makeing it accessible to registrants, while obtaining the necessary resources for the promotion and positioning of .LAT in the target market. A plan will be proposed that will provide incentive to the growth of the base of domain names registered, promoting registration for 2 or more years, while simultaneously it will be sought that this plan achieve a renewal rate around 70%. The price increments will only occur when necessary, and in full compliance with the ICANN contract, giving notice in appropriate form and with required anticipation, as per the contract signed with ICANN.
.LAT Registry does not consider making contractual commitments with the registrants regarding price escalation other than the ones indicated by ICANN, as we think that it would be very difficult to regulate the pricing schemes that the registrars offer to final customers. However it is our goal to gradually reduce the tariff the registrars pay, if and when possible, enabling them to pass this benefit on to the registrants.
Community-based Designation
19. Is the application for a community-based TLD?
20(a). Provide the name and full description of the community that the applicant is committing to serve.
20(b). Explain the applicant's relationship to the community identified in 20(a).
20(c). Provide a description of the community-based purpose of the applied-for gTLD.
20(d). Explain the relationship between the applied-for gTLD string and the community identified in 20(a).
20(e). Provide a description of the applicant's intended registration policies in support of the community-based purpose of the applied-for gTLD.
20(f). Attach any written endorsements from institutions/groups representative of the community identified in 20(a).
Geographic Names
21(a). Is the application for a geographic name?
Protection of Geographic Names
22. Describe proposed measures for protection of geographic names at
the second and other levels in the applied-for gTLD.
PROTECTION OF GEOGRAPHICAL NAMES
Through the development of the Applicant Guidebook, ICANN put a great effort to protect the best interests of country and territory governments. .LAT has a strong commitment to protect geographical names as required in the Applicant Guidebook and according to GAC’s “Principles Regarding New gTLDs”.
.LAT registry will protect Geographic names at the second level as defined in the Applicant Guidebook following GAC’s principles and recommendations.
The following GAC Principles Regarding new gTLDs apply especially to geographic names:
2.2 ICANN should avoid country, territory or place names, and country, territory or regional language or people descriptions, unless in agreement with the relevant governments or public authorities.
2.7 Applicant registries for new gTLDs should pledge to:
a) Adopt, before the new gTLD is introduced, appropriate procedures for blocking, at no cost and upon demand of governments, public authorities or IGOs, names with national or geographic significance at the second level of any new gTLD.
b)Ensure procedures to allow governments, public authorities or IGOs to challenge abuses of names with national or geographic significance at the second level of any new gTLD.
.LAT Registry will reserve the following names at the second level prior to public availability of the .LAT TLD:
* The short form (in English) of all country and territory names contained on the ISO 3166-1 list, as updated from time to time, including the European Union.
* The United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and
* The list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names;
Registry Operator will propose a mechanism for the release of these reservations, following recommendations made by the Governmental Advisory Committee and approval by ICANN.
.LAT Registry considers registering domain names corresponding to all protected domain names on behalf of ICANN as the registrant of record of such domain names, as it was the case of .INFO TLD. A similar approach will be used for .LAT.
Registry Services
23. Provide name and full description of all the Registry Services to be provided.
REGISTRY SERVICES
Operating a TLD for the latin community requires a deep knowledge of the latin environment and also great expertise in addressing this market. Experience both as a Registry and as a Registrar is essential to understand the complexity of the technical infrastructure required to operate a gTLD. This experience would also provide for the communication skills and proved commercial strategies necessary to better serve this market which still has a great potential for development and growth.
Because of this, eCOM-LAC has relied on NIC Mexico to provide technical services for the .LAT TLD. NIC Mexico is the current Registry Operator of the .MX ccTLD, who is a market leader in the region for technology services specializing in DNS, and who has pioneered the use of cutting edge technology, in order to offer the highest level of services to the Internet community. NIC Mexico will participate in this project to take some of the critical internet infrastructure out of the most developed countries, by reinforcing its own technical infrastructure to increase its service portfolio and gain experience to be able to aid in the development of the internet in the region. This partnership guarantees an excellent level of service in all aspects for end users and registrars.
NIC Mexico was among the first registries to automatize the domain name registration process (before EPP definition) through a web-based solution back in the late 90’s. NIC Mexico also pioneered in DNS anycast implementation deploying its first anycast cloud in 2002. Then in 2004, it was by NIC Mexico’s initiative that a joint project with ISC, TELMEX, Alestra and Avantel brought the first Root Server mirror to Mexico. NIC Mexico coordinated the project that put a copy of the Root Server F managed by ISC in Mexico.
Today NIC Mexico has a fully compliant EPP registration system and a DNS implementation that features geographic and network diversity, complimented with contracts with two global DNS Anycast Cloud providers to secure overcapacity in case of a major contingency.
In 2009 NIC Mexico successfully launched second level domain registrations for the TLD .MX. This project included re-defining policies, processes and systems to make them compatible with the best practices in the industry. NIC Mexico maintains the biggest registrar base among the Latin American Registries (+200).
eCOM-LAC and NIC Mexico will offer .LAT domain name services to all ICANN Accredited Registrars and according to ICANN’s requirements for preserving the operational security and stability of the Internet. The services for .LAT TLD will match both business and technical industry standards to offer registrants a globally visible domain name with latin identity.
NIC Mexico will provide registry services for the .LAT TLD that cover the five critical registry functions:
A. Receipt of data from registrars concerning registration of domain names and name servers
B. Dissemination of TLD zone files.
C. Dissemination of contact or other information concerning domain name registrations (Whois service)
D. Internationalized Domain Names
E. DNS Security Extensions (DNSSEC)
.LAT Registry will offer the following services:
1. DOMAIN NAME REGISTRATION AT THE SECOND LEVEL
.LAT Registry will offer domain name registration following the industry’s best practices. The Registry will accept data from registrars for domain name registration on behalf of registrants. This includes:
* The desired domain name: It will be used first for availability check and then to continue with the registration process. .LAT will provide IDN registration in Spanish language at the second level.
* Name server information for delegation purposes, including glue records
* Contact information. Registrant, Administrative, Technical and Billing contacts will be supported
* DNSSEC related information. We will describe the DNSSEC implementation details further in the application.
.LAT Registry will provide Domain Name Registration by means of the Shared Registration System (SRS). The SRS is a long time proven in-house development built over a highly adaptable architecture, designed to provide the best performance at any time to all participant registrars. Security and stability are the main design drivers.
* The SRS relies on a long-proved architecture based on DELL high capacity servers and Oracle RDBMS for the main database. All network and processing equipment features full redundancy to provide for scalability and resiliency. Other elements of the registration system include the billing system, PBX, online-chat and CRM. Business managers and customer support agents will use specially designed applications to perform their activities.
* EPP Authentication will be made both at (transport) level with SSL certificates and at (application) level via username and password. The registrar will be able to register domain names for the desired term defined in yearly increments from two to ten years.
* NIC Mexico will provide technical support to registrars both for the initial setup and for the daily operations. The call center will be available on business hours to service support requests by phone and email; there will be also live-chat assistance. Outside business hours, there will be an emergency response team on-call for participating registrars.
* The accreditation process will be agile and will include signing of the .LAT annex to the Registrar Agreement. It also considers interoperability testing and verification using a test environment available to interested registrars to verify the correct integration of their systems and the .LAT SRS.
OTHER DOMAIN REGISTRATION SERVICES
.LAT Registry will offer domain renewal both automatic and upon request of the registrar of record of the domain name. Domain Transfers will follow the procedures described in the applicable RFC’s and the consensus policies like the Inter-Registrar Transfer Policy (now Policy on Transfer of Registrations between Registrars). .LAT Registry will also offer Domain Restore capabilities following RFC3915.
2. WHOIS SERVICE:
.LAT Registry will offer a whois service for dissemination of information concerning domain name registration, including contact and DNS delegation information.
* .LAT Registry will offer whois both as a TCP service through port 43 and via web.
* As required in the AGB .LAT Registry will implement a thick registry; this will allow the implementation of a centralized whois to better serving the public with the most up-to-date information about .LAT domain names.
* The contents and format of the query responses will be as required in Specification 4 of the Registry Agreement.
* The whois service will have a dedicated database (different from the SRS database) and dedicated servers for web and port 43 access. The whois database will be updated from the SRS database every 5 minutes.
* The whois systems will have abuse prevention measures in place like query quotas to limit access by origin IP address for both the port 43 and the web-based services. Repeted overflows of query quotas will result in the IP adress being blocked. In addition to query quotas, the web based whois service will feature a captcha to prevent automated systems from mining the database.
* NIC Mexico’s whois implementation is a long time proven in-house development built over a highly adaptable architecture, designed to provide the best performance at any time to all participant registrars and internet community. Security and stability are the main design drivers. DELL high capacity servers will provide processing power, and the database will be Oracle RDBMS optimized to deliver top performance from a read-only database.
* .LAT Registry will take every effort needed to balance the need for privacy with the need to provide access to records that contain information on the registrant and contacts of domain names in order to maintain security and stability of the DNS. .LAT registry will operate the WHOIS service in a way that is compatible with applicable privacy laws. .LAT will request from registrants the minimal set of information needed to perform the whois functions as required by ICANN.
3. DNS SERVICE.
.LAT Registry will offer domain name resolution through NIC Mexico’s DNS Infrastructure.
* NIC Mexico’s DNS Infrastructure is composed of 6 different anycast clouds (m, e, x, i, c, o.mx-ns.mx) or Name Servers in the classical terminology.
* NIC Mexico manages seven global nodes in different parts of the globe. Each node is capable of announcing in BGP any of the six anycast clouds.
* NIC Mexico announces a particular IPv4 ⁄24 prefix to receive the traffic of a particular anycast cloud. Two external anycast providers announce a ⁄23 covering prefix of each anycast cloud and NIC Mexico can stop announcing the ⁄24 so the external providers receive the traffic of a particular anycast cloud. The first external DNS anycast provider normally receive the traffic of one anycast cloud, the second external DNS anycast provider normally receive the traffic of two anycast clouds and NIC Mexico normally receive traffic of the remaining three anycast clouds. In case of a large attack that NIC Mexico is not able to cope with NIC Mexico can stop announcing the ⁄24 prefix allowing the external providers to receive part of the traffic.
* NIC Mexico announces an IPv6 ⁄32 and ⁄48 in order to provide IPv6 connectivity in two of the six anycast clouds. The external DNS anycast providers do not receive IPv6 traffic.
* NIC Mexico’s SRS updates two DNS stealth master servers in almost real-time (1 minute is the worst-case scenario for an update in the SRS to be transferred to the DNS stealth masters). These two DNS stealth master servers then transfer zone updates to the nodes and external DNS anycast cloud providers.
DNS Security Extensions
* NIC Mexico’s SRS implements RFC5910 in order to allow registrars to update DS RR information through EPP.
* NIC Mexico’s SRS Web Interface implements a web module where a registrar can update DS RR information.
* NIC Mexico does not verify if DS is valid with the child zone at registration time, but a batch process and configured to run daily to validate DS information and report any problems with DNSSEC chain of trust to registrars.
* NIC Mexico uses a FIPS 140-2 Level 4 to store the KSK. An m-of-n command structure is implemented in the HSM. The ZSK private key is stored in a server called “zone signing server” that can only communicate through a private network with the stealth masters.
* Zone signing is performed in the “zone signing server” and ZSK private key information is encrypted with an m-of-n shared secret.
4. OTHER SERVICES
REGISTRY LOCK
.LAT Registry will offer an advanced security service that will prevent a domain name from updates made online, by means of the SRS interfaces, web and EPP.
This service will be oriented to allow registrars of the .LAT TLD offer to registrants an increased security level for protection of their valuable domain names that are essential assets for business operations and brand protection. The Registry Lock service will add an extra layer of verification and control on operations affecting “locked” domains. Registrars will use it in combination with their own security measures to help registrars mitigate the risk of hijacking as well as unintended domain deletions, transfers and any other undesired update.
To setup the service for a domain name, the registrar must send a letter to the registry indicating:
* The domain name
* AuthInfo of the domain name
* Name and contact information of the individuals authorized to make changes to the domain name. It is intended that they should be the registrant or administrative contacts of the domain name.
* A password or pass phrase must be included to verify the identity of the contact.
To modify the information of a domain name that has the Registry Lock service activated, one of the appointed contacts must get in touch with the .LAT registry’s customer support by phone. After identity validation, the contact can instruct the customer support agent to update the domain name information.
Once the information has been updated, the SRS will send a notice to the registrant and administrative contact with the updated information of the domain name. This service is considered a premium service for the exceptional costs that it represents.
DOMAIN RESTORE
This service is included to protect registrars (and registrants) from inadvertent or undesired deletions. Some of the TLD registries currently active offer this service, as defined in the RFC3915.
When a registrar deletes a domain name, it enters into a Redemption Grace Period where the registrar of record can restore the domain name to an active status by issuing an EPP 〈rgp:restore〉 command, which is a billable operation. After the command execution, the domain name is put back in the zone file, but the restore will not be complete yet. Accordingly to RFC3915 the registrar still has to send an EPP 〈rgp:report〉 command to finalize the recovery process with all the required information as indicated in RFC3915.
Details on the implementation of de Domain Restore service will be provided further within the Domain Registration Life-Cycle.
SEARCHABLE WHOIS
.LAT registry will implement search capabilities on the whois to offer a way to find domain names registered within a TLD. This tool would prove useful when trying to locate domain names that could be in violation of intellectual property or that may be subject of criminal investigation. Search capabilities will be available for the web version only.
There will be some measures in place to deter abuses on the searchable whois. NIC Mexico will implement an incremental delay in the response to multiple queries from the same IP address per period. Another abuse prevention feature of the searchable whois will be blocking of IP address if the number of concurrent connections exceeds a certain threshold. The limits for incremental delays per number of queries and concurrent connection thresholds will be set at an initial number and then adjusted when more experience is gathered.
More details in que response to question 26.
Demonstration of Technical & Operational Capability
24. Shared Registration System (SRS) Performance
SHARED REGISTRATION SYSTEM (SRS) PERFORMANCE:
NIC Mexico will provide registry services for the .LAT TLD that cover the five critical registry functions:
A. Receipt of data from registrars concerning registration of domain names and name servers
B. Dissemination of TLD zone files.
C. Dissemination of contact or other information concerning domain name registrations (Whois service)
D. Internationalized Domain Names.
E. DNS Security Extensions (DNSSEC)
All of these functions will be supported by the Shared Registration System (SRS) as the point of entrance of all data to the registry database.
The SRS will enable registrars to provide domain registration services in the .LAT TLD, thus the SRS must be robust and reliable. .LAT registry will implement SRS according to the industry’s best practices including both EPP and web-based interfaces.
The EPP is widely adopted as the standard for domain name management in generic TLDs. It is also used by competitive ccTLDs that want to make their ccTLDs available to a wider market. NIC Mexico has a fully EPP compliant SRS that will make available for registrars all commands necessary for domain name provisioning for their clients..
The web interface will provide registrars with all other administrative tools needed to maintain their accounts within the registry. Services like billing, reporting and account management will be available to registrars via the web interface.
NIC Mexico’s SRS and EPP implementations comply with RFCs 5910, 5730, 5731, 5732, 5733 and 5734, according to Specification 6 of the Registry Agreement. It will also comply with RFC 3915 for the RGP implementation.
SRS DESCRIPTION AND PERFORMANCE
The SRS solution is an in-house development that has evolved through more than 10 years to achieve the required attributes needed to support the operations of the .MX ccTLD with high security, stability and performance. This evolution was the result of the availability of new and better technology, improvement of the skills of the technical staff and new business requirements that demanded technical improvements. NIC Mexico ´s SRS went from a monolithic system, to a pure Registry-Registrar mode currently supporting the operations of the .MX ccTLD with more than half a million domain names. Nevertheless, NIC Mexico’s SRS implementation can support up to 8X (4 million domain names) the actual load of the .MX registry without any degradation in performance. This capacity exceeds the requirements of a TLD of the planned size of the .LAT TLD, yet the system can still augment its capacity to handle more domain names if necessary.
The SRS is hosted in two carrier class datacenters located in Monterrey, MX. Triara is the main datacenter and Axtel is the secondary datacenter, which is equipped and configured to operate as a hot backup datacenter. The datacenters have the following certifications:
Triara has a Level 5 certification from ICREA (International Computer Room Expert Association) Level 5 refers to a HSHA-WCQA, High Security High Available-World Class Quality Assurance Data Center. Triara is the only datacenter with Level 5 certification in Latin America.
Axtel Data Center has a Level 3 certification from ICREA, which refers to S-WCQA, Safety-World Class Quality Assurance Data Center and is currently working on TIER 3 Certification.
NIC Mexico’s registry solution is built on top of a technical architecture designed to provide security, reliability and performance at all levels. All servers and devices installed in the infrastructure go through a hardening process following best practices. This architecture features a multiple layer design (See Attached File, Network Diagram):
INTERNET LAYER
This layer provides interconnection to ISPs and WAN interconnections. In each datacenter NIC Mexico deployed two routers which are connected to two different routers of the ISP using different links. NIC Mexico’s routers are connected to the edge routers of the ISPs. Telmex and Axtel are the main connectivity providers of NIC Mexico and they have multiple redundant links to major providers in the USA. Telmex is the largest ISP in Latin America and Axtel is the second largest ISP in Mexico.
NIC Mexico’s infrastructure is linked by three WAN links. Two WAN links of 100Mbps interconnect the infrastructure in Triara and Axtel datacenters. Redundancy is necessary because the databases on both sites are synchronized in almost real time. This link between datacenters is also used as a solution to provide multihoming to both sites. NIC Mexico’s main office is connected to Axtel datacenter by a WAN link of 48Mpbs. NIC Mexico’s main office is also connected to the Internet with a 100Mpbs broadband connection which can be used as backup in case the WAN link to Axtel is not working.
SECURITY LAYER
Firewalls, IDSs and VPN Gateways are located in this layer. All external traffic is handled in this layer and has to go through multiple security filters before it can reach the Application and Internal Network Layers. The firewalls implement algorithms to help mitigate DDoS attacks. An IDS analyzes all the traffic coming from the internet connections with ISP before it continues to the Internal Network Layer. If suspicions traffic is detected an alert is sent to the NOC team to perform further analysis. VPN gateways are deployed in the two datacenters and in the main office so that all traffic that goes through NIC Mexico’s Internal Networks is encrypted with IPSEC.
APPLICATION LAYER
In the application layer we find the server farms for the EPP, HTTP load balancers, WWW Extranet, WHOIS and DNS stealth servers. The servers located in this layer use High Availability Clustering and load balancing with DNS Round Robin. Auxiliary components that require Internet connectivity like the credit card payment components are also located in this layer.
INTERNAL NETWORK LAYER
In the Internal Network Layer communications between the different components and the database takes place. The Internal Network Layer also gives access to NIC Mexico’s specialized IT Staff to perform administrative and maintenance tasks On the SRS itself and all of its components.
ABOUT THE DATABASE
The database is fine tuned for high volume online transactions. All access is secured and monitored to maintain data integrity and prevent unauthorized access. The main database servers are DELL R910 servers.
SYNCHRONIZATION BETWEEN MAIN DATABASE AND MIRROR DATABASE
Updates at the primary datacenter are replicated to the database servers at the backup datacenter using a custom designed procedure that avoids database locking in case of communication problems in the wan links that interconnect both datacenters. The database server is configured to provide high availability and resilience. Redundancy is one of the main configuration directives for the hardware setup. LUNs are configured in RAID 1+0 and RAID1 arrays. The Oracle archiving system generates archive files that are synchronized in almost real-time with the secondary datacenter. This is possible because the primary and secondary datacenters are interconnected with redundant wan links.
HARDWARE AND SOFTWARE
Both interfaces, EPP and WEB are java-based and the software and the application containers are tuned to deliver top performance at any time. NIC Mexico keeps at least 2 spare servers that can be added to any service in case of an unusual peak of transactions to avoid any performance degradation.
RDBMS is provided by Oracle as the industry leader for relational databases. NIC Mexico has long experience using Oracle Database for its mission critical applications. IT Staff is highly experienced in the deployment and fine tuning of Oracle to provide for the best performance to .LAT Registry users.
Applications run in DELL M610 high capacity servers. NIC México has implemented 1+1 redundancy in all networking and processing hardware to provide for reliability and resiliency.
INTERACTION WITH OTHER SYSTEMS
The SRS interacts with other registry systems to provide integrated services to registrars. The main interfaces are EPP and the .LAT Registry Website. Both will operate together to provide a complete experience to the registrar. EPP will accept commands from registrars for the provisioning of registry objects, while the web page will offer EPP and account management functionality to registrars and other administrative tasks like reporting and account balance management. Other registry systems that interact with the SRS are:
Billing System. This system handles registrar’s payments and invoices. It works with the payment module to process payments with credit cards. The payment module supports multiple credit card processing service providers; it has a primary service provider and a backup in case of failure. This system tracks all registrars’ transactions and keeps their balance updated. The registrar can make credit card payments or wire deposits to its account on the .LAT Registry and the Billing System will debit all registry’s billable operations from its account.
Batch Scheduling System. The scheduler runs all automated processes like domain renewals, programmed deletions and sends all related warnings and notifications to registrars. All these processes run automatically and include a full execution report that is sent to NIC Mexico’s IT staff for verification. They also perform business rules validations and security checks and can send alerts to a system operator if anything needs attention.
Mailing System. It handles all e-mail communication initiated by the SRS and all related systems. It keeps a searchable archive available to registrars and system administrators.
Registry Intranet. Is the tool used to operate the Registry and also is used by the customer support agents to offer assistance to registrars. It includes management capabilities for all registry objects, also provides registrar activity tracking, configuration of registry parameters like grace periods, management of the firewall access control for registrars, and others. The application has fine-grain access control over system functions and users. Administrators can give privileges over certain functions of the application to predefined user groups or individual users. Special operations like domain deletion require confirmation by a supervisor using a second password scheme User authentication in the intranet is validated with an OTP solution.
RDDS (Whois). The SRS is the point of entry of all information in the .LAT Registry. All information delivered by the RDDS is taken from the SRS. A special automated process synchronizes the information in the RDDS with the last updates from the SRS. Both TCP port 43 and Web version of the RDDS use the same database different from the main database.
Zone File Manager System. The Zone File Management System takes care of maintaining the SRS database with domain name delegation information and the DNS zone files synchronized. The system polls the SRS database to generate journal files containing only updates since the last synchronization. The journal files are then transformed in AXFR and IXFR commands that are sent to DNS master servers to be propagated to the DNS anycast clouds. The Zone File Manager System verifies zone file integrity before and after sending any updates.
WORKING WITH ICANN ACCREDITED REGISTRARS.
Domain registration will be provided for all ICANN accredited registrars through the SRS via an EPP interface. Authentication will be made both at network level with TLS using certificates signed with .LAT registry’s CA, and at application level via username and password.
The registrars will be able to register domain names for the desired term defined in yearly increments from one to ten years.
NIC Mexico will provide technical support to registrars both for the initial setup and for the daily operations. The call center will be available on business ours to service support requests by phone and email. There will be also live-chat assistance. Outside business hours, there will be an emergency response team available on-call for participating registrars.
The accreditation process will be agile and will include signing of the LAT addendum to the Registrar Agreement and testing the interoperability of the registrar´s system with the SRS. .LAT registry will have a full featured test environment available to interested registrars to test and verify the correct integration of their systems with the .LAT SRS.
25. Extensible Provisioning Protocol (EPP)
EPP
As part of the SRS implementation .LAT registry will provide an EPP interface to registrars that fulfill the requirements to maintain objects within the LAT TLD. The EPP service is based in a long proved implementation by NIC México, currently in use for the .MX ccTLD. The EPP response messages currently support English and Spanish.
NIC Mexico’s implementation complies with all related RFC’s as required by the Applicant Guidebook and the Registry Agreement:
* RFC5730 Extensible Provisioning Protocol (EPP)
* RFC5731 Extensible Provisioning Protocol (EPP) Domain Name Mapping
* RFC5732 Extensible Provisioning Protocol (EPP) Host Mapping
* RFC5733 Extensible Provisioning Protocol (EPP) Contact Mapping
* RFC5734 Extensible Provisioning Protocol (EPP) Transport over TCP
* RFC5910 Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
* RFC3915 Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)
* RFC3735 Guidelines for Extending the Extensible Provisioning Protocol (EPP)
EXTENSIBLE PROVISIONING PROTOCOL IMPLEMENTATION
NIC Mexico’s EPP service is implemented over TCP transport, as it is the most widely used transport protocol. The technical staff has enough experience to work with the TCP transport having a long-time proved framework to implement any kind of service over the TCP transport.
SECURITY
Access to the EPP service is granted only to registrars that have signed the registrar agreement to operate with the .LAT TLD. Access is controlled in a multi-layered approach. The first level of security is a firewall whitelist where only allowed registrar’s IP addresses can establish a connection. The firewall is responsible for the TCP three way handshake and after it’s completed the connection is forwarded to the actual EPP backend server, this helps to mitigate the risk of TCP attacks like half-sync attacks. The registrar must use TLS with a certificate that will be issued by .LAT registry and that will be validated by the EPP LAT server. Once the TLS channel is in place, the registrar can send an EPP Login command with its username and password to open an EPP session.
In order to gain access to the EPP server, upon signing of the .LAT Registrar agreement, the registrars must send a CSR to the .LAT Registry to get a valid certificate to use on its EPP Client implementation. The CSR must be created using a rsa:1024 key to sign the certificate.
The .LAT EPP implementation is developed in house using JAVA as the programming language. The EPP XML formation and parsing libraries were developed in house and they will be made public to interested registrars of .LAT TLD.
.LAT REGISTRY EPP DATA COLLECTION POLICY
The .LAT Registry EPP privacy policy for data collection is described in the epp:greeting as shown in the following table:
Element Description
-------- ---------------------
Access ALL: Access is given to all identified data
Purpose ADMIN: Administrative purpose
CONTACT: Contact for market research only
OTHER: Other purposes
Recipient OURS: The data is processed by .LAT Registry
only for the completion of the stated purpose
Retention INDEFINITE: Data persists indefinitely.
Each registrar is allowed to have up to 10 concurrent connections by default. The LAT registry can allow more concurrent connections for a particular registrar after a justification from the registrar is reviewed and approved by the LAT registry.
After 10 failed authentication (origin IP address, TLS certificate, or username⁄password) attempts the registrar account is blocked and a manual procedure must be performed by LAT registry operators to unblock it. This is a security measure in case the registrar is compromised.
If the number of query commands or transformations commands per second is above a normal threshold the registry operators can choose to delay each response to the registrar. This is a security measure in case a registrar is being attacked and the attack is indirectly reaching the EPP system.
An established EPP TCP connection has a maximum time to live of 86400 seconds, after this TTL is reached the connection is closed by the EPP server. The connection timeout of the EPP TCP connection is 3600 seconds.
EPP COMMANDS
All EPP commands will be supported by the .LAT registry with exception of contact.delete, contact.transfer. Session Management, Query Commands and Transformation Commands will be implemented following the RFC5730. NIC Mexico’s implementation uses the message queue as defined by the EPP protocol as the principal mean to send information to registrars.
Following EPP standards all EPP commands are atomic (there is no partial success or partial failure) and designed so that they can be made idempotent (executing a command more than once has the same net effect on system state as successfully executing the command once). Also the responses to commands include response codes, along with response information, needed control or automate online and offline processes. The response also includes information of the EPP Service Message Queue.
EPP EXTENSIONS
NIC Mexico uses extension with its current clients. Although it is possible to register domain name without using the extensions, NIC Mexico encourages registrars to use them to fully interoperate with the SRS and take advantage of all its features.
Service Messages Extension: NIC Mexico’s implementation of the EPP protocol includes an extension to handle additional service message types. This is useful to send notifications to registrars related to both online and offline processes like any RPM related issues (UDRP, URS) or other notification related to other processes supported by the registry.
Domain extension for Administrative Status: This extension adds another piece of information to the domain:info command. The administrative status is introduced to track the domain status on special processes (mostly offline) that affect the visibility and manageability or of the domain name, for example a UDRP or URS process.
OBJECT MAPPING IMPLEMENTATION
NIC Mexico’s EPP implementation complies with the standards for the object mappings; nevertheless, NIC Mexico’s implementation enforces some additional business rules that may add slightly differences, especially in relation to mandatory data and supported operations. The following description of the EPP Registry Object Mappings describes only the additional verification included in NIC Mexico’s EPP implementation. Everything that is not mentioned will follow the corresponding RFC as –is.Domain Mapping
.LAT Registry will offer domain registration at the second level only, without any restrictions other than the ones described in the Applicant Guidebook and included in the Registry Agreement.
DOMAIN MAPPING: DOMAIN ATTRIBUTES
Additionally to domain object attributes included in RFC 5731 NIC Mexico defined an extension to include and Administrative Status, that as described above is used to track the domain status on special processes, mostly offline that affect the manageability and visibility of the domain name, for example a UDRP or URS process. The Administrative status can only be set by the Registry and will be included in the domain:info query command response. It will be discussed in detail in the corresponding extension specification.
The registrant and all domain contacts (admin, tech and billing) of a domain name are defined as mandatory in .LAT Registry implementation of the EPP domain mapping. The AuthInfo element is also mandatory.
.LAT Registry will implement a configurable limit for the host objects a domain name can be linked to. The current value is set to 5.
DOMAIN MAPPING: DOMAIN COMMANDS
Domain:check.
There is a configurable limit on the number of names that can be checked in the same command. The current value is set to 100.
Domain:info
The option to include an ROID attribute to specify that the authorization information provided corresponds to a contact object associated to the domain is not supported in the EPP implementation.
Domain:create
The attributes domain:registrant and domain:contact are mandatory in the implementation of EPP by NIC Mexico for .LAT Registry, then they must exist in the registry database prior to the creation of the domain name.
The registration period can be provided in months or years, but the period must be supported by the registry. Valid registration periods will be defined prior to launch but are expected to be complete years. The response to the domain:create command will include the optional element domain:exDate that contains the expiration date of the domain name that was created.
Domain:delete
If a domain object that has subordinated host objects is deleted, all existing links of the subordinated hosts with other domain objects will be removed and the subordinated host objects will also be deleted. All relations between internal hosts (.lat hosts) and .lat domain names are always complete by the previous rule. This enables the zone file generator to verify that all glue records included in the zone must also have its superordinate domain name also in the zone. In case contraire the glue records will be removed from the zone file.
Domain:renew
The response to the domain:renew command will include the updated expiration date of the domain name.
Domain:transfer
The domain:period attribute will not be supported. All transfers extend the domain name registration period by 1 year only. All subordinated host objects will be transferred altogether with the domain name. While the transfer operation is active, all involved objects will have a “pendingTransfer” status.
Information on a pending transfer will be available only to the registrars involved in the transfer. The exDate element is not included in the response to transfer query commands.
The option to include a ROID attribute to specify that the authorization information provided corresponds to a contact object associated to the domain object will not be supported in the .LAT EPP implementation.
Domain:update
There cannot be a domain name without a registrant so, to change the registrant contact it will be necessary to use the domain:chg element. In the same direction, the domain:authInfo element is mandatory for a domain name so, the .LAT registry will not allow to use the domain:null attribute to remove it.
To change any of the domain contacts it will be necessary to put the current contact in the 〈domain:rem〉 element of the command and the new one in the 〈domain:add〉 element. This will be validated by .LAT Registry.
HOST MAPPING
The EPP implementation will include host objects to handle delegation of domain names to be included in the zone files. Hosts that are internal to the .LAT registry will be created only by the sponsor of the superordinate domain name; in this way, internal host objects will be unique in the registry system but can be used by any registrar and can be linked to any domain name.
External hosts can be created by any registrar and will be unique to that registrar only. To simplify object relationships management every registrar can have his own copy of an external host object. Such hosts can be linked only to domain names sponsored by the registrar that created the external host.
If a domain name is not included in the zone file, neither will be their subordinated host objects (glue records).
HOST MAPPING: HOST COMMANDS
Host:check
There is a configurable limit on the number of names that can be checked in the same command. The current value is set to 100. The host:reason element will always be present in the response.
Host:create
Host objects store information of name servers. To create an internal host object the superordinate domain name object must exist in the registry database. The .LAT registry will not allow specifying IP addresses for external host objects.
Host:update
If a host:update command changes the name of an external host so it becomes an internal host and also a glue record, the required IP addresses must be added in the same command, or the command will fail. In the same sense, .LAT Registry implementation will not allow the complete removal of the IP addresses of an internal host object that is also a glue record.
If a host:update command changes the name of an internal host that is also a glue record so it becomes an external host, the existing IP addresses must be removed in the same command, or the command will fail.
Host:delete
The .LAT registry will not allow the deletion of a host object if it is linked to one or more domain objects. All links must be removed prior to the delete command. Nevertheless, if a domain object that has subordinate host objects is deleted then all links that the host objects could have will be removed automatically and the host objects will be deleted as well.
CONTACT MAPPING
The .LAT registry will use contact objects to store information of organizations and individuals that are related to domain names. Contact objects can be linked to domains as the registrant or administrative, technical or billing contact. .LAT Registry implementation will only support the localized postal info for contact objects.
CONTACT MAPPING: CONTACT COMMANDS
Contacts can be created and updated in the .LAT registry. Deletion and transfer will not be supported.
Contact:check
There is a configurable limit on the number of contacts that can be checked in the same command. The current value is set to 100. The contact:reason element will always be present in the response.
Contact:info
This command will return either of two information sets. A full information set will be returned for objects sponsored by the registrar that executes the command. A restricted information set will be showed for contacts sponsored by a different registrar. A non-sponsoring registrar can provide the contact:authInfo element within the command to get the full information set.
Contact:create
.LAT registry will only support contact:postalInfo of type=local. The address information will be mandatory. Also the contact disclose element will not be supported, even though .LAT registry could define a general policy for that matter in case necessary.
Contact:update
Mandatory information cannot be removed.
OTHER MAPPINGS.
DOMAIN REGISTRY GRACE PERIOD MAPPING
NIC Mexico’s EPP implementation will include the Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol. The implementation will follow RFC3915 and will include both the 〈rgp:restore〉 and 〈rgp:report〉 functionality to implement the domain recover functionality as described in the RFC3915 and also to comply with the Restored Names Accuracy Policy.
EPP EXTENSIONS
EPP ADMINISTRATIVE STATUS EXTENSION FOR .LAT REGISTRY
1. INTRODUCTION
The EPP protocol provides a complete description of EPP command and response structures. A thorough understanding of the base protocol specification is necessary to understand the mapping described in is document.
This document is written in consideration with the Guidelines for Extending the Extensible Provisioning Protocol as defined in [RFC3735].
This extension adds elements to the EPP 〈info〉 response, to allow LAT Registry show information about administrative statuses applied to a domain name.
2. OBJECT ATTRIBUTES
This extension adds additional elements to EPP domain object mapping described in [RFC5731]. Only new elements descriptions are described here.
2.1 Administrative Status
.LAT Registry introduces administrative status to EPP to track the domain status on special processes (mostly offline) that affect the manageability of the domain name, for example a UDRP or URS process, or an abuse complaint. The administrative status supported by .LAT registry is:
Status Description
--------------------------- ------------------------------------
suspendedByExternalAuthority The domain has been suspended on request
by an External Authority
suspendedByIllegalActivites The domain has been suspended because
of other Illegal Activities
3. EPP COMMAND MAPPING
A detailed description of the EPP syntax and semantics can be found in [RFC5730].
3.1. EPP Query Commands
This extension does not add any elements to the EPP 〈check〉, 〈poll〉 or 〈transfer〉 commands or responses.
3.1.2. EPP 〈info〉 Command
This extension does not add any elements to the EPP 〈info〉 command.
On the 〈info〉 response, if the queried domain is in a .LAT Registry Administrative status, the EPP 〈extension〉 element MUST contain a child 〈nicmx-as:adminStatus〉 element that identifies the administrative status for the domain name. The 〈nicmx-as:adminStatus〉 element contains the following child elements:
- A 〈nicmx-as:value〉 element that contains the current administrative status for the domain.
- A 〈nicmx-as:msg〉 element that contains the description of the administrative status. Contains an element 〈lang〉 that indicate the description language.
Example 〈info〉 response:
S:〈?xml version=ʺ1.0ʺ encoding=ʺISO-8859-1ʺ standalone=ʺnoʺ?〉
S:〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ〉
S: 〈response〉
S: 〈result code=ʺ1000ʺ〉
S: 〈msg lang=ʺenʺ〉Command completed successfully〈⁄msg〉
S: 〈⁄result〉
S: 〈msgQ count=ʺ10ʺ id=ʺ2659194ʺ⁄〉
S: 〈resData〉
S: 〈domain:infData xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ〉
S: 〈domain:name〉example.mx〈⁄domain:name〉
S: 〈domain:roid〉DOMAIN_11235813213455-MX〈⁄domain:roid〉
S: 〈domain:status s=ʺclientTransferProhibitedʺ⁄〉
S: 〈domain:registrant〉conexample〈⁄domain:registrant〉
S: 〈domain:contact type=ʺadminʺ〉conexample〈⁄domain:contact〉
S: 〈domain:contact type=ʺbillingʺ〉conexample〈⁄domain:contact〉
S: 〈domain:contact type=ʺtechʺ〉conexample〈⁄domain:contact〉
S: 〈domain:ns〉
S: 〈domain:hostObj〉ns.example.com〈⁄domain:hostObj〉
S: 〈⁄domain:ns〉
S: 〈domain:clID〉rar_example〈⁄domain:clID〉
S: 〈domain:crID〉rar_example〈⁄domain:crID〉
S: 〈domain:crDate〉2008-05-15T22:00:49.0Z〈⁄domain:crDate〉
S: 〈domain:upID〉rar_example〈⁄domain:upID〉
S: 〈domain:upDate〉2011-05-20T15:47:57.0Z〈⁄domain:upDate〉
S: 〈domain:exDate〉2012-05-14T05:00:00.0Z〈⁄domain:exDate〉
S: 〈domain:authInfo〉
S: 〈domain:pw〉*****〈⁄domain:pw〉
S: 〈⁄domain:authInfo〉
S: 〈⁄domain:infData〉
S: 〈⁄resData〉
S: 〈extension〉
S: 〈nicmx-as:adminStatus
S: xmlns:nicmx-as=ʺhttp:⁄⁄www.nic.mx⁄nicmx-admstatus-1.0ʺ〉
S: 〈nicmx-as:value〉suspendedByIllegalActivites〈⁄nicmx-as:value〉
S: 〈nicmx-as:msg lang=ʺenʺ〉The domain has been suspended because other Illegal Activities〈⁄nicmx-as:msg〉
S: 〈⁄nicmx-as:adminStatus〉
S: 〈⁄extension〉
S: 〈trID〉
S: 〈clTRID〉EXAMPLE-011235813〈⁄clTRID〉
S: 〈svTRID〉21345589144〈⁄svTRID〉
S: 〈⁄trID〉
S: 〈⁄response〉
S:〈⁄epp〉
3.2. EPP Transform Commands
This extension does not add any elements to the EPP 〈create〉, 〈delete〉, 〈renew〉, 〈update〉 nor 〈transfer〉 commands or responses.
4. FORMAL SYNTAX
An EPP object mapping is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances.
〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉
〈schema targetNamespace=ʺhttp:⁄⁄www.nic.mx⁄nicmx-admstatus-1.0ʺ
xmlns:nicmx-msg=ʺhttp:⁄⁄www.nic.mx⁄nicmx-admstatus-1.0ʺ
xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
xmlns:eppcom=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
elementFormDefault=ʺqualifiedʺ〉
〈!--
Import common element types.
--〉
〈import namespace=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
schemaLocation=ʺeppcom-1.0.xsdʺ ⁄〉
〈import namespace=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
schemaLocation=ʺepp-1.0.xsdʺ ⁄〉
〈annotation〉
〈documentation〉
Extensible Provisioning Protocol v1.0
NIC-MX Administrative Status Extension Schema v1.0
〈⁄documentation〉
〈⁄annotation〉
〈!--
Child element found in 〈extension〉 tag
--〉
〈element name=ʺnicmxʺ type=ʺnicmx-as:adminStatusTypeʺ ⁄〉
〈!--
Child Elements of nicmxAsType
--〉
〈complexType name=ʺadminStatusTypeʺ〉
〈sequence〉
〈element name=ʺvalueʺ type=ʺnicmx-as:adminStatusCodeTypeʺ⁄〉
〈element name=ʺmsgʺ type=ʺepp:msgTypeʺ minOccurs=ʺ0ʺ ⁄〉
〈⁄sequence〉
〈⁄complexType〉
〈simpleType name=ʺadminStatusCodeTypeʺ〉
〈restriction base=ʺtokenʺ〉
〈enumeration value=ʺsuspendedByExternalAuthorityʺ ⁄〉
〈enumeration value=ʺsuspendedByIllegalActivitesʺ ⁄〉
〈⁄restriction〉
〈⁄simpleType〉
〈!--
END of schema
--〉
〈⁄schema〉
SERVICE MESSAGE EXTENSION FOR LAT REGISTRY
1. INTRODUCTION
The EPP protocol provides a complete description of EPP command and response structures. A thorough understanding of the base protocol specification is necessary to understand the mapping described in is document.
This document is written in consideration with the Guidelines for Extending the Extensible Provisioning Protocol as defined in [RFC3735].
This extension adds new elements to the EPP 〈poll〉 request response, to allow .LAT Registry to send additional information in the service messages not specified in the EPP standard.
2 OBJECT ATTRIBUTES
This extension adds additional elements to EPP mapping described in [RFC5730]. Only new elements descriptions are described here.
2.1 Message Type
The message type element is used to provide additional information in the service messages. This type contains the message type identifier, the domain name related to the message and dates related with the message. Valid values for message type identifiers are defined by the EPP implementation.
msgTypeID Description
----------------- -------------------------------------
5 Domain delete notification
6 Domain auto-renew notification
9 Domain suspension by External Authority notification
11 Domain suspension by External Authority release notification
13 Domain delete redemption period notification
14 Domain restauration notification
15 Domain update by associated host deletion notification
3. EPP COMMAND MAPPING
A detailed description of the EPP syntax and semantics can be found in [RFC5730].
3.1. EPP Query Commands
This extension does not add any elements to the EPP 〈check〉, 〈info〉 or 〈transfer〉 commands nor responses.
3.1.1. EPP 〈poll〉 Command
This extension does not add any elements to the EPP 〈poll〉 command.
On the 〈poll〉 request response, if the message retrieved contains additional information from the .LAT Registry then the server MUST include a 〈extension〉 element in the EPP response with a child 〈nicmx-msg〉 element that identifies the additional information from .LAT Registry. The 〈nicmx-msg〉 element contains the following child elements:
- A 〈msgTypeID〉 element that contains the message type identifier.
- A 〈object〉 element that identified the object related to the message.
- A 〈msDate〉 element that contains the date of the action that triggered the message.
- An OPTIONAL 〈exDate〉 element that contains the expiration date from the domain included in this message.
Example 〈poll〉 request response:
S:〈?xml version=ʺ1.0ʺ encoding=ʺISO-8859-1ʺ standalone=ʺnoʺ?〉
S:〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ〉
S: 〈response〉
S: 〈result code=ʺ1301ʺ〉
S: 〈msg lang=ʺenʺ〉Command completed successfully; ack to dequeue〈⁄msg〉
S: 〈⁄result〉
S: 〈msgQ count=ʺ6ʺ id=ʺ3053565ʺ〉
S: 〈qDate〉2012-04-07T04:00:04.0Z〈⁄qDate〉
S: 〈msg lang=ʺenʺ〉Domain has been deleted〈⁄msg〉
S: 〈⁄msgQ〉
S: 〈extension〉
S: 〈nicmx-msg:nicmx xmlns:nicmx-msg=ʺhttp:⁄⁄www.nic.mx⁄nicmx-msg-1.0ʺ〉
S: 〈nicmx-msg:msgTypeID〉5〈⁄nicmx-msg:msgTypeID〉
S: 〈nicmx-msg:object〉example.mx〈⁄nicmx-msg:object〉
S: 〈nicmx-msg:msDate〉2012-04-07T04:00:04.0Z〈⁄nicmx-msg:msDate〉
S: 〈⁄nicmx-msg:nicmx〉
S: 〈⁄extension〉
S: 〈trID〉
S: 〈clTRID〉EXAMPLE-011235813〈⁄clTRID〉
S: 〈svTRID〉21345589144〈⁄svTRID〉
S: 〈⁄trID〉
S: 〈⁄response〉
S:〈⁄epp〉
3.2. EPP Transform Commands
This extension does not add any elements to the EPP 〈create〉, 〈delete〉, 〈renew〉, 〈update〉 nor 〈transfer〉 commands or responses.
4. FORMAL SYNTAX
An EPP object mapping is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances.
〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉
〈schema targetNamespace=ʺhttp:⁄⁄www.nic.mx⁄nicmx-msg-1.0ʺ
xmlns:nicmx-msg=ʺhttp:⁄⁄www.nic.mx⁄nicmx-msg-1.0ʺ
xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
xmlns:eppcom=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
elementFormDefault=ʺqualifiedʺ〉
〈!--
Import common element types.
--〉
〈import namespace=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
schemaLocation=ʺeppcom-1.0.xsdʺ ⁄〉
〈import namespace=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
schemaLocation=ʺepp-1.0.xsdʺ ⁄〉
〈annotation〉
〈documentation〉
Extensible Provisioning Protocol v1.0
NIC- MX Messages Extension Schema v1.0
〈⁄documentation〉
〈⁄annotation〉
〈!--
Child element found in 〈extension〉 tag
--〉
〈element name=ʺnicmxʺ type=ʺnicmx-msg:nicmxTypeʺ ⁄〉
〈!--
Child Element of nicmxMsgType
--〉
〈complexType name=ʺnicmxTypeʺ〉
〈sequence〉
〈element name=ʺmsgTypeIDʺ type=ʺunsignedShortʺ ⁄〉
〈element name=ʺobjectʺ type=ʺeppcom:labelTypeʺ ⁄〉
〈element name=ʺmsDateʺ type=ʺdateTimeʺ ⁄〉
〈element name=ʺexDateʺ type=ʺdateTimeʺ minOccurs=ʺ0ʺ ⁄〉
〈⁄sequence〉
〈⁄complexType〉
〈!--
END of schema
--〉
〈⁄schema〉
26. Whois
WHOIS
.LAT Registry will provide Registration Data Publication Services in the form of whois, in both port 43 and web, zone file access and also bulk access to thick registry data to ICANN in accordance with Specification 4 of the Registry agreement.
The Whois or Registration Data Directory Service (RDDS) is a tool designed to provide identifying information of a domain name. It should be the first reference to find information related to a domain name. Anything from finding contact information to buy a domain name to identifying suspects in a criminal investigation uses the information of the whois to find out who is responsible for the use of a domain name. Whois implementation
.LAT whois implementation will provide free public query-based access to the information in the registry’s database as required by ICANN in the format described in specification 4 to the registry agreement. Users will be able to query the following object types:
* Domain name: whois EXAMPLE.LAT
* Nameserver: whois ʺNS1.EXAMPLE.LATʺ or whois ʺnameserver (IP Address)ʺ
* Registrar: whois ʺregistrar Example Registrar, Inc.ʺ
The format of the data will conform to the mappings specified in EPP RFCs 5730-5734 so that the display of this information (or values return in WHOIS responses) can be uniformly processed and understood.
The format of responses will follow a semi-free text format as described in Specification 4, and will include a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
NIC Mexico’s current whois implementation provides a reliable, stable, secure platform to support the .LAT whois. The whois database is updated in a near real-time fashion with the latest information from the registry database to avoid user confusion. The whois will be available via the TCP port 43 or web at the .LAT registry website. .LAT whois implementation will comply with RFC391 (see attached diagram).
The whois protocol, by definition has no provisions for strong security, thus WHOIS protocol lacks mechanisms for access control, integrity, and confidentiality. Nevertheless .LAT implementation of whois considers some measures to avoid abuses. The web-based version will have a little more control on how information is accessed and .LAT registry will put the necessary effort needed to comply with data privacy laws in place.
The whois (RDDS) solution is an in-house development that has evolved over more than 10 years to achieve the required attributes needed to support the operations of the .MX ccTLD with high security, stability and performance. This evolution followed the availability of new and better technology, improvement of the skills of the technical staff and new business requirements. NIC Mexico currently supports the operations of the .MX ccTLD with more than half a million domain names using its long time proved whois implementation with great sucess; NIC Mexico’s whois implementation supports up to 8X (4 million domain names) the actual load without any degradation in the performance. This capacity exceeds the requirements for a TLD of the planned size of the .LAT TLD, yet the system can still augment its capacity to handle more domain names if necessary.
SECURITY
By definition, whois is not secure; it doesn’t offer access control mechanisms nor integrity or confidentiality. Nevertheless there will be a number of mechanisms to protect registry information and avoid abuse of the service.
Both port 43 and web services will be behind a firewall that only send TCP connections that completed the three way handshake to the back end server. There will be a limit on the number of requests that can be made from a single IP address in a certain period of time. If the limit is exceeded, the IP address will be blocked until the end of the period. The web whois additionally will feature a captcha to prevent query automation.
In IPv6 the number of public address at disposition of an attacker is enormous and NIC Mexico will periodically evaluate its abuse prevention and mitigation strategies to consider the operation realities of IPv6.
TECHNICAL INFRASTRUCTURE
The technical infrastructure to provide the service follows the same architecture as described in Question 24.
The port 43 and web implementations will have 2 servers each.
Due to NIC Mexico’s infrastructure design it is possible to add more servers to the farm in case of more processing power is needed without disrupting the operation of the whois.
Database power is provided by Oracle 11g as the industry leader for relational databases.
SEARCHABLE WHOIS
.LAT registry will implement search capabilities on the whois to offer a way to find domain names registered within a TLD. This tool would prove useful when trying to locate domain name that could be in violation of intellectual property or that may be subject of criminal investigation. An offender could be related to multiple domain names, or domain names could be completely unrelated with a very similar domain name, involved in illegal activities. A searchable whois would prove to be very useful to resolve many issues like the ones described above. Search capabilities will be provided for the web version only.
Search fields
In accordance with Specification 4 of the Registry Agreement .LAT Registry will offer partial match capabilities for the following fields:
* domain name,
* contacts and registrant’s name
* contact and registrant’s postal address, including all the sub-fields
.LAT Registry will offer exact-match capabilities, on the following fields:
* registrar id,
* name server name,
* name server’s IP address
To prevent abuses on the searchable whois, NIC Mexico will implement an incremental delay in responses to queries from the same IP address per period of time. Another abuse prevention feature of the searchable whois is the blocking of IP address if the number of concurrent connections exceeds a certain threshold. The incremental delay per number of queries and concurrent connection thresholds will be defined when more experience is gathered. Additionally, the searchable whois web interface will feature a captcha to prevent query automation.
In IPv6 the number of public address at disposition of an attacker is enormous and NIC Mexico will periodically evaluate its abuse prevention and mitigation strategies to consider the operation realities of IPv6.
ZONE FILE ACCESS
.LAT registry will comply with the Zone File Access requirement from Specification 4, Section 2 of the Registry Agreement.
.LAT Registry will enter into an agreement with any Internet user to grant him access to an Internet host server or servers designated by .LAT Registry and download zone file data. As indicated in Specification 4 the agreement will be standardized, facilitated and administered by an ICANN designated Centralized Zone Data Access Provider (the “CZDA Provider”). .LAT registry will collaborate with the CZDA Provider to successfully offer this service to legitimate users.
The basic agreement will be for a period of three months and will be offered at no cost to the user.
.LAT Registry will provide access to zone files generated according to section 2.1.4 of Specification. Parties interested in accessing the files must provide the credentials required in section 2.1.2 to obtain the user account and password to access a secure FTP server where the zone files will be hosted, otherwise the access will be denied. Legitimate users will be able to access and to transfer a copy of the top-level domain zone files. The FTP server directory structure and file naming will follow the scheme described in section 2.1.3 of Specification 4.
.LAT Registry will only allow access to the secure FTP server from the IP specified by the user, and will allow the user to download the files containing the zone information and the cryptographic checksum files for verification no more than once every 24 hours.
According with Specification 4, .LAT Registry will request valid credentials from any user that will permit correctly identify and locate the user, including company name, email address and the host name and IP address from where they will connect to access the files. .LAT Registry may reject the request for access of any user that does not provide correct or legitimate credentials under Section 2.1. 2 or where reasonably believes the user will violate the terms of Section 2.1.5 of Specification 4. .LAT Registry may revoke access of any user if Registry Operator has evidence to support that the user has violated the terms of Section 2.1.5.
As stated in Specification 4, .LAT Registry will permit user to use the zone file for lawful purposes; provided that, user takes all reasonable steps to protect against unauthorized access to and use and disclosure of the data. Furthermore, under no circumstances will .LAT Registry allow a user to use the data to transmit unsolicited messages to entities other than user’s own existing customers, or enable automated processes that send queries or data to the systems of .LAT Registry or any ICANN-accredited registrar. .LAT Registry will have a point of contact to handle violations and abuse complaints .LAT Registry may revoke access to any user if it has evidence to support that the user has violated the terms of Section 2.1.5.
According to Specification 4, .LAT Registry and NIC Mexico will cooperate with ICANN and the CZDA Provider to facilitate and maintain efficient access to zone file data by legitimate users. NIC Mexico will also provide ICANN and the designated Emergency Operator (EBERO) unrestricted and continuous access to zone files.
BULK REGISTRATION DATA ACCESS FOR ICANN
.LAT registry will comply with the Bulk Registration Data Access for ICANN requirement from Specification 4, Section 3 of the Registry Agreement.
.LAT will prepare a weekly file containing the registry’s Thin Registration Data on the day defined by ICANN to verify and ensure the operational stability of Registry Services as well as to facilitate compliance checks on accredited registrars. The requested information of domain names and registrar objects will follow the content and format specifications defined by ICANN in section 3.1.1 and 3.1.2, as defined in reference to data escrow format.
The files will be made available to ICANN via a SFTP server, or in the form requested in the future by ICANN.
In exceptional cases that require the transfer of domain names from a sponsoring registrar to another; .LAT registry will provide access to Thick Registration Data of a particular registrar upon request made by ICANN. The data will be provided in the format specified in Specification 2 for Data Escrow, with the file containing information related to the specified registrar only. The file will be made available to ICANN in 2 business days via a SFTP server, or in the form requested in the future by ICANN.
PERSONAL DATA PROTECTION
Recently in Mexico, the Federal Law for Protection of Personal Data in Possession of Private Entities was enacted. This law is aimed to protect personal data in possession of Private Entities, seeking to regulate the legitimate use of such data, in a transparent and informed fashion, in order to guarantee the privacy and right to informative self-determiation of persons.
This law establishes that anyone responsible for the treatment of personal data must implement and maintain administrative, technical and physical security measures that enable the protection of personal data from harm, loss, alteration, destruction, or unauthorized use, access and treatment.
NIC Mexico has paid due attention to the contents of this law, and performed the necessary actions to ensure that the .MX TLD operations fulfill this law. It should be noted that this law is one of the most strict with respect to personal data protection in other countries, and thus complying with it has meant a significant effort. At the same time, the .MX customers have gained greater security related to their personal data.
We consider that this experience with personal data protection, will allow us to fulfill all the legal requirements concerning personal data protection applicable to the .LAT, while providing a whois service according to the applicant guidebooki and that additionally, eCOM-LAC and NIC Mexico will employ the best practices in order to safeguard this sensitive information regarding the .LAT domains customers.
.LAT Registry will take every effort needed to balance the need for privacy with the need to provide access to records that contain information on the registrant and contacts of domain names in order to maintain security and stability of the DNS. .LAT registry will operate the WHOIS service in a way that is compatible with applicable privacy laws. .LAT will request from registrants the minimal set of information needed to perform the whois functions as required by ICANN.
27. Registration Life Cycle
DOMAIN REGISTRATION LIFE-CYCLE
eCOM-LAC will have NIC Mexico as the back-end operator for the .LAT registry. NIC Mexico has the required experience and skills to operate the technical infrastructure for a gTLD of the planned size of .LAT. NIC Mexico’s registry implementation has evolved over time following the development of technology and industry standards.
.LAT Registry will feature a Domain Registration Life-Cycle that is fully compatible with current industry practices. As such, .LAT registry implementation will consider different domain states to keep track of the domain name through the Life-Cycle.
.LAT Registry operations will be supported by NIC Mexico’s Operative Model, which is a fully EPP compatible Registry-Registrar model. This operative model has been proved and refined by NIC Mexico over the operation of .MX ccTLD, which as of today has more than 200 registrars working with its registry platform. About 20 of those registrars are ICANN accredited registrars that were easily integrated to the platform using EPP and the debit account scheme widely adopted by registries around the globe.
DOMAIN STATES
Domain states help to describe the different stages the domain name goes through during the Registration Life-Cycle. Domain States indicate the stage of the Life-Cycle that the domain is currently going through. The domain states are used as part of the business logic only and are not manageable by the registry or the registrar. They are used to support the implementation of the Registration Life-Cycle and describe it using consistent concepts and keywords. Each State defines the operations that can be executed on a domain name; an also considers specific events, automatic or manual to trigger the transition to another state.
DOMAIN STATUSES
Domain Statuses are used and managed by the registry and the registrar to indicate that the domain name has certain restrictions or has none, and also indicate that the domain name is going through a specific process within the Domain Registration Life – Cycle.
These statuses are defined by the EPP base standard, the EPP object mappings and the extensions to the protocol. .LAT Registry’s Registration Life-Cycle includes previsions to handle processes and statuses included in the RFC3915 that describes the Grace Period Mapping and a also the Administrative Status extension defined by NIC Mexico to describe additional processes that a domain name can go through, particularly off-line processes.
STATES OF A DOMAIN NAME
.LAT Registry’s Operative Model is described by the Domain States that are internal to the business logic of the registry, and are described as follows:
Registered
It is the default state of a domain name. When a domain is in the Registered State it is considered that it is within its normal registration period and there isn’t any administrative restriction applying to the domain name.
Expired
When a domain name reaches the end of its registration period, it is considered to be expired. In practice, there won’t be any domains in an Expired State, because the .LAT Registry will renew the domain name automatically upon expiration so the registration period will be extended, and the state of the domain will be restored to Registered.
Unavailable
If a domain name was deleted and wasn’t recovered or restored then it will enter into a Unavailable State. In this State, the domain name is not included in the zone file and also is no longer in control of the registrar of record; nevertheless it cannot be registered again, because it is not out of the Registration Life-Cycle yet. After a certain period (the pending delete period) the domain name will be released from the Registration Life-Cycle and will be available to be registered again.
Available
This State is included for completeness as the State of a domain name that is available for registration, but because of the domain name does not actually exist, there isn´t really an Available State
PERIODS OF THE REGISTRATION LIFE-CYCLE
Registration Period
The initial step to the domain name registration life-cycle is registration. First, the domain name must be available; this means that the domain name is not in any phase of the Registration Life-Cycle within the TLD. An Accredited Registrar can register a domain name for as long as 10 years, starting in one year and the following yearly increments, this is known as the Registration Period. The registration fee will be debited from the Registrar’s account (See attached Diagram LifeCycle .LAT)
The domain name will be added to the zone file once DNS delegation information has been provided. If DNS information was available at registration, the domain name will be added to the zone file in the next zone file update process following the registration.
Add Grace Period
Immediately after a domain name is registered it will enter into a 5 days Add Grace Period. In this period, the registrar can delete the domain name to get a refund of the registration fee. The domain name will be released from the Life-Cycle immediately, so it will be possible to register that same domain name again.
.LAT Registry will implement and enforce the AGP Limits consensus policy to avoid practices that abuse the Add Grace Period like domain tasting.
Auto-Renew Grace Period⁄ Renew Grace Period (See attached Diagram LifeCycle .LAT 2)
When a domain name reaches its expiration date, it is automatically renewed, and then enters into a 45 days Auto-Renew Grace Period. The domain name will continue to be in the zone file. If the registrar of record executes a 〈domain:renew〉 command on the domain name, then it enters into a 5 days Renew Grace Period. In both cases the renewal fee is debited from the registrar account.
In case the registrar prefers not to renew the domain name, he can delete domain name within this period to obtain a refund of the renewal fee. The domain name will enter into a Redemption Grace Period for 30 days. The domain is no longer included in the zone file.
Redemption Grace Period
When a domain name is deleted at any time outside of the Add Grace Period it enters the Redemption Grace Period for 30 days.
.LAT Registry will implement the Redemption Grace Period Extension described in RFC3915.
In this period, the registrar can restore de domain name sending an EPP extended domain update command with 〈rgp:restore〉 extension with the “request” option, which is a billable operation, to the registry. After the command is executed the domain name is put back in the zone file, but the restore will not be complete yet. Accordingly to RFC3915 the registrar still has to send an EPP 〈rgp:restore〉 extended update command with the “report” option to finalize the recovery process with all the required information as indicated in RFC3915.
Pending Delete Period
If the domain name is not restored within the Redemption Grace Period it will enter in a pendingDelete status for 5 days. At this moment, the domain name is not in the zone file and no EPP operations can be performed on it. After the 5 day period the domain name will be deleted and released from the Life-Cycle and will be available to be registered again.
EPP STATUS VALUES
.LAT Registry SRS and Registration Life-Cycle are fully compatible with standard EPP Status Values. According to EPP standards a domain name can have many EPP Status Values associated at a given time.
The EPP Status Values are self-explanatory:
ok
It is the default status of a domain name, and there will be no other status values associated with it. A domain name in OK status doesn’t have pending operations of prohibitions, so it can be updated, transferred, renewed or deleted. If it has name server information it will be included in the zone file.
clientHold
clientUpdateProhibited
clientDeleteProhibited
clientTransferProhibited
clientRenewProhibited
As the name indicates, these statuses can be set by the sponsoring registrar of the domain name only. clientHold means that the domain name will not be included in the zone file. The other values indicate that the referred action cannot be performed on the domain name; however, the clientRenewProhibited will not prevent the Auto-Renew operation.
serverHold
serverUpdateProhibited
serverDeleteProhibited
serverTransferProhibited
serverRenewProhibited
As the name indicates, the above statuses can be set by the .LAT registry only. serverHold means that the domain name will not be included in the zone file. The other values indicate that the referred action cannot be performed on the domain name; however, the serverRenewProhibited will not prevent the Auto-Renew operation.
Other EPP statuses are:
inactive
pendingCreate
pendingDelete
pendingRenew
pendingTransfer
pendingUpdate
Again, the statuses are self-explanatory. The inactive status refers to a domain name that is not associated with any host object, it means that it is not included in the zone file as it lacks of delegation information. The other statuses apply when there is a pending operation on the domain name. The only pending statuses used by the .LAT registry are pendingDelete and pendingTransfer.
ADDITIONAL ADMINISTRATIVE STATUS
.LAT Registry will have an EPP extension to add complementary administrative statuses to the SRS. These administrative statuses can only be set by the registry and will offer additional information for processes that are performed usually offline. The extension has been included in the response to Quesiton 25
suspendedByExternalAuthority
This administrative status applies when a domain name is involved in an ongoing URS or UDRP. When a domain name is in this status it cannot be modified, transferred, deleted or renewed. The only possible operation permitted on the domain name is to release it from suspendedByExternalAuthority status and this operation must be performed by the .LAT registry. While the domain name is in this status the domain name continues to be published in the DNS but it can be removed by the .LAT Registry if required. When a domain name is released from this status the domain name is automatically renewed to extend its registration period to include the actual date if necessary
OTHER ADMINISTRATIVE STATUSES
.LAT Registry will use this extension to provide information related to processes implemented as a result of new policy development.
DOMAIN UPDATES
A domain name can be updated anytime in the Registration Life-Cycle, except in the Redemption Grace Period, or during the Pending Delete period. The suspendedBy* administrative status and clientUpdateProhibited and serverUpdateProhibited statuses also prevent a domain name from being updated. All updates are applied immediately,
DOMAIN TRANSFER PROCESS
The Domain Transfer Process allows the change of the registrar of record of a domain name. The process is initiated when a registrant asks a registrar to manage its domain name, currently under management of a different registrar. The registrant must provide the AuthInfo of the domain name to the new registrar (the Gaining registrar) so it can make a request to the .LAT Registry in order to transfer the domain name from the current (the Losing) registrar.
Once the request is made, .LAT registry adds the pendiengTransfer status to the domain name, and sends a service message to the message queue of both registrars confirming the reception of the transfer request.
The current registrar has 10 calendar days to approve or reject the transfer request. If the current registrar rejects the transfer, it is cancelled immediately. If .LAT Registry receives an approve response from the current registrar, the domain name is immediately transferred. If .LAT Registry does not receive any response by the end of the 10 calendar days, the transfer is automatically approved. In all cases, .LAT registry will remove the pendingTransfer status and will send a service message to the message queue of both registrars to confirm the result of the transfer operation.
After requesting a transfer, if the registrant no longer wants to transfer the domain name, or if the registrar sent the transfer request by mistake, the Gaining Registrar has the option to cancel the transfer request as long as it is still pending. If that is the case, .LAT registry will remove the pendingTransfer status and will send a service message to the message queue of both registrars confirming the cancel of the transfer operation.
After a transfer is complete, there will be a Transfer Grace Period, where the Gaining Registrar can delete the domain name, entering into a Redemption Grace Period.
DOMAIN RESTORE PROCESS
The Restore Process can be initiated during the Redemption Grace Period following a domain deletion. The Process allows a registrar to restore a domain name that was previously deleted. The Domain Restore is a billable operation and the corresponding fee will be debited from the registrar’s account. If no restore request is received at the end of the Redemption Grace Period, the domain name will enter in a Pending Delete Period and will be released for the Registration Life-Cycle and will be available to be registered again.
Once a restore is requested, the domain name will be in a pendingRestore status and the registrar of record will have 10 days to send a restore report to provide a brief explanation of the reason for restoring the domain name and also a statement that it has not restored the domain name for its own use or with the intention of selling it. If no restore report is received at the end of 10 days, the domain name will start a new Redemption Grace Period.
This process is included with all details in RFC3915.
28. Abuse Prevention and Mitigation
ABUSE PREVENTION AND MITIGATION
NIC Mexico will provide the back-end registry services for the .LAT TLD. The services offered include the technical operation of the Registry and customer support including billing and collection. NIC Mexico will also be in charge of handling trademark and abuse related processes like UDRPs and any report received by the abuse contact. NIC Mexico is the current registry operator for the .MX ccTLD and has been not only a leading ccTLD in the region, but also a worldwide leader in policy and technology development.
NIC Mexico currently has in place practices to mitigate and prevent some forms of abuse. For example, special charges for deletion of domain names during Add Grace Period to discourage excessive domain tasting and full support of the UDRP to deal with Intellectual Property Infringements and Cybersquatting. For .LAT Registry NIC México will implement measures according to the open nature of the new TLD following ICANN advisory and industry’s best practices.
REGISTRATION AND USE ABUSE
As a Registry Operator, .LAT Registry will implement the Consensus Policies adopted by ICANN as established in the Registry Agreement. Additionally, .LAT Registry will implement the Uniform Rapid Suspension system, as proposed in the Applicant Guidebook to fight the most flagrant cases of cybersquatting or other forms of registration abuse, related to the use of trademarks.
Registration Abuse Policies Working Group (RAPWG), worked on a very ample report on the matter. Their findings and further recommendations were analyzed and applied where we found suitable and compatible with .LAT registry to complement current practices.
The following registration abuse practices were identified by the RAPWG, and will be addressed by .LAT Registry.
CYBERSQUATTING
Cybersquatting is recognized as the most notable form of registration abuse in the ICANN community; and the UDRP was originally created to address this abuse. This form of abuse is present in almost every TLD, and .LAT Registry will implement industry’s best practices to prevent it and mitigate it.
.LAT Registry will support UDRP as defined by ICANN Consensus Policies to fight Cybersquatting. Although it has had some areas of improvement pointed out; UDRP has proved to be affective against cybersquatting. Notwithstanding that it has been subject of abuse itself with Reverse Domain Name Hijacking cases, UDRP continues to be the first line of defense to discourage and fight Cybersquatting.
Other recurring registration practices, like Gripe Sites and Offensive Domain Names that use a brand owner’s trademark have been found by the RAPWG as a form of Cybersquatting that can be adequately addressed via UDRP.
.LAT Registry will implement a Sunrise period for trademark owners. This period will be conducted in full support of the procedures and requirements defined as part of the Trademark Clearing House implementation. Following the General Availability launch and extending for 60 days there will an IP Claims Service to provide notice to domain registrants of existing trademark rights, as well as notice to rights holders of relevant names being registered. Furthermore, a special feature of this service will allow
DOMAIN TASTING⁄KITING, FRONT-RUNNING
.LAT Registry will implement Add Grace Period (AGP) Limits Policy to prevent and mitigate domain tasting. Domain tasting and kiting were once a common practice, abusing the AGP originally meant for mistaken registrations. Front Running is also another form of registration abuse that has been largely affected by the AGP Limits policy for the benefit of registrants.
USE ABUSES
Althoug LAT Registry will require that domain names be used only for legitimate activities or purposes carried out in good faith, .LAT registry recognizes that it will not prevent use abuses on the domain names. One of the the most noticeable example of domain name use abuse is phishing:
PHISHING
For the last years, phishing has been a common practice to deceive internet users to reveal sensitive information by taking them to fake websites that resemble trusted sites they are familiarized with. The great majority of domains used for phishing are compromised or hacked by phishers, and the registrants are not responsible for the phishing therefore, prevention and mitigation actions must be handled carefully, prioritizing protection of the public without putting aside protection to the registrants. .LAT will work closely with the registrars to make sure innocent registrants are protected.
However, .LAT should not be part of the decision about what is and what is not a phishing website; with this in mind, .LAT registry will promote the creation of a Regional Anti-Domain Abuse Center (RADAC) that could evaluate phishing complaints, or about any form of use abuse, and determine if a site should be taken down in coordination with relevant law enforcement agencies.
This would enhance the capabilities in the region to attend the problems related to phishing and other domain use related abuses. In addition, it might drive experience to other TLDs in the region that do not have access to this kind of mechanisms and also catch the attention of other relevant actors in the latin community that could participate.
OTHER FORMS OF USE ABUSE
.LAT Registry will fully cooperate with ICANN and relevant law enforcement agencies to prevent and mitigate other forms of abuse like SPAM, Fast Flux Hosting, Distribution of malware and Distribution of Child Pornography
ABUSE PREVENTION AND MITIGATION IN .LAT REGISTRY
.LAT Registry is committed to operate the .LAT TLD maintaining at all times the security and stability of the internet, providing a reliable service and preventing and mitigating all forms of abuse. To achieve this .LAT Registry will implement ICANN Consensus Policies and will take all actions needed to comply with the Registry Agreement and its Specifications.
.LAT registry will take the following measures to prevent and mitigate domain name abuse
SINGLE ABUSE POINT OF CONTACT
As specified in the registry agreement .LAT Registry will provide to ICANN and publish on its website the information regarding its Single Abuse point of Contact. Information will include valid email and mailing address as well as a primary contact for handling inquires related to malicious conduct in the TLD, and will provide ICANN with prompt notice of any changes to such contact details.
The handling of abuse inquires will be in charge of the commercial operations team. The team has long experience working with UDRPs and will be readily available to collaborate with ICANN and relevant authorities in order to pursue abusive practices that result in criminal activities. Top priority will be given to abuse inquires, and a timely response will be provided to complaints concerning names registered in the TLD. Commercial operations team currently has the required tools to implement determinations from both UDRP and URS examination panels.
.LAT Registry will collaborate with ICANN to define mechanisms to respond to relevant authorities’ inquires in clear cases of abuse like phishing.
Procedure to respond to Abuse inquires and complaints.
Once the point of contact receives the abuse notice, it will pass it to the operations team to verify if the reported incident or situation corresponds to a form of abuse that is within .LAT Registry scope. If the team determines that effectively it is an abuse case within the .LAT TLD, a service executive will contact the affected or reporting party to provide further information of the actions that can be taken. .LAT registry anticipates that such actions will fall within one of the following options:
1. File a UDRP
2. File a URS
3. Contact a government agency, law-enforcement body or response center (RADAC) to analyze and prosecute the abusive activities.
.LAT Registry will invoke the Expedited Registry Security Request (ERSR) in case of a present or imminent security incident to the TLD and⁄or the DNS to request ICANN a contractual waiver to take immediate action to prevent or address the incident.
.LAT Registry will collaborate with industry partners sharing information regarding malicious or abuse behavior in cases of purely technical nature coordinated by ICANN, IETF, or some other instance appointed by ICANN.
In the case of requests to perform certain actions on a domain name received form law enforcement agencies, special care should be taken on whether the law enforcement agency has the required authority to request such actions. ICANN will be consulted to clear any discrepancy before answering any request. Whatever the case is, .LAT Registry will collaborate and share relevant information with relevant authorities appointed by ICANN
HANDLING OF ORPHAN GLUE RECORDS
Although glue records are actually necessary for the DNS function, sometimes, domain names are deleted and removed from the registry database, but the glue records are left in the zone file. Those records are known as orphan glue records, and pose a security threat to the DNS. Due to the security threat that orphan glue records represent to DNS .LAT registry will implement control mechanisms so that no orphan glue records are left in the zone file.
GLUE RECORDS POLICY
Glue records will be allowed only for host objects that are internal to the .LAT TLD, with this, only host objects of the form dns.example.lat will be allowed to have glue records. Furthermore, only the registrar of record of domain name example.lat will be allowed to create host objects under that domain name and provide glue records. Other registrars will only be able to associate their domain names with the host objects for delegation purposes. Glue records will not be allowed in the registry database for host objects external to the .LAT TLD.
To delete a host object, the registrar must first remove all links of the host with other domain names; howeverif a registrar sends a delete command for a domain name that has subordinate hosts with glue records, the SRS will delete the domain name and also all subordinate host objects. All information regarding that domain name, including glue records will be removed from the zone file. All links from the deleted host objects and other domain names will be removed, so some of them can end up being removed from the zone file. It is responsibility of the registrar to make sure that domain names and hosts objects are only deleted when they are no longer in use.
WILDCARDING
.LAT Registry will not implement or allow any wildcarding scheme on the .LAT DNS. The abuse contact will be available to receive complaints about any wildcarding-like behavior on any domain name. .LAT Registry will work with the registrar of record to analyze and resolve any situation. All domain names indicated by ICANN in the registry agreement will be reserved.
WHOIS ACCURACY
LAT Registry will implement Whois Data Reminder Consensus Policy to validate that contacts linked to domain names are reachable and aware of their responsibilities. Data Reminders will be sent to domain contacts at least once a year and will be asked to verify and confirm that the information is still valid, or to contact the registrar of record to make corrections as appropriate. Additionally .LAT Registry will send notifications to the registrants of domain names upon update of domain data.
ADDITIONAL PROTECTIONS FOR DOMAIN ABUSE
DOMAIN LOCKING SERVICE
.LAT Registry will offer an advanced security service that will prevent a domain name from being modified online, by means of the SRS interfaces, web and EPP.
This service will be oriented to allow registrars of the .LAT TLD offer to registrants an increased security level for protection of their valuable domain names that are essential assets for business operations and brand protection. Domain Lock will add an extra layer of verification and control on operations affecting “locked” domains. Registrars will use it in combination with their own security measures to help registrars mitigate the risk of hijacking as well as unintended domain deletions, transfers and any other undesired update.
NOTIFICATIONS OF DOMAIN ACTIVITIES BY THE .LAT REGISTRY
.LAT Registry will offer an opt-in feature to send notices to the registrant and administrative contacts of record of a domain name when the domain has been updated, transferred, or deleted, in order to detect and contain any abuse or unsolicited actions that could reveal abuses on the domain name. In case of the registrant was unaware of the modification, .LAT Registry will contact the registrar of record to determine if the update involved some form of abuse.
29. Rights Protection Mechanisms
RIGHTS PROTECTION MECHANISMS
Accordingly to the Applicant Guidebook and the Registry Agreement .LAT Registry will implement Rights Protection Mechanisms for the .LAT TLD. .LAT Registry will comply with ICANN policies and practices to minimize abusive registrations and other activities that affect the legal rights of others.
Rights Protection Mechanisms included in the Applicant Guidebook were defined after many hours of work under the counsel of experts and the experience of many participants of the day-to-day operations of the domain name environment. Registry Operators, Registrars, Lawyers and IT professionals worked together in Implementation Recommendation Team to design the mechanisms to protect Intellectual Property and Trademark Rights in the advent of the new gTLD program.
From the recommendations of the IRT, the following Rights Protection Mechanisms (RPMs) were adopted and included in the Applicant Guidebook as requirements for new gTLD Applicants.
Pre-Launch or Startup
* A Sunrise Period for rights holders
For ongoing operations
* Trademark Claims Services (for 60 days after start of operations)
* Uniform Domain Name Dispute Resolution Policy (UDRP),
* Uniform Rapid Suspension (URS)
.LAT Registry will implement all mandated Right Protection Mechanisms (RPMs) for the pre-launch, startup and ongoing operation of the .LAT TLD.
PRE-LAUNCH AND STARTUP PROTECTION MECHANISMS
To successfully launch a new gTLD, special care should be taken to allow existing rights holders to register their trademarks as domain names in the new gTLD in a form that allows taking advantage of the full potential of the new gTLD but without being a heavy burden, both economic and political.
The Implementation Recommendation Team took that into consideration to design the Trademark Clearinghouse (TMCH) that must be used by new registries as source of information to run their Sunrise Period and Trademark Claims feature.
.LAT Registry will implement a Sunrise Period and Trademark Claims service as defined in the Trademark Clearinghouse implementation specification.
SUNRISE PERIOD
The .LAT Sunrise period is intended to provide an orderly, transparent and equitable process for the launching of the .LAT TLD. This process is designed to deter abusive registrations while balancing the interests of legitimate rights owners. Eligible rights holders will have an early opportunity to register names in the TLD. Within the Sunrise, rights holders will be able to register domain names for use or for protecting their trademarks in the new gTLD. The .LAT Sunrise period will have a duration of three months.
SUNRISE ELIGIBILITY REQUIREMENTS (SERS)
The only SER to participle in .LAT’s sunrise period will be to have a valid registration to the Trademark Clearinghouse. All rights holders of trademarks registered in the Trademark Clearinghouse will be eligible to participate in the Sunrise and register a domain name that is identical to its mark, and using ASCII characters only.
.LAT Registry will rely in the Trademark Clearinghouse to verify that a prospective registrant trademark is eligible to be registered as a domain name during the Sunrise period.
.LAT Registry will communicate to prospective registrants that they must submit trademark data to the Clearinghouse’s entry points determined by ICANN prior to participate in the Sunrise. The communication will also include the criteria for a trademark to be included in the Clearinghouse:
* Nationally or regionally registered word marks from all jurisdictions.
* Any word mark that has been validated through a court of law or other judicial proceeding
* Any word mark protected by a statute or treaty in effect at the time the mark is submitted to the Clearinghouse for inclusion.
* Other marks that constitute intellectual property.
.LAT Registry will include in its communications that in order to participate in a Sunrise the Trademark Clearinghouse will verify that the prospective registrant have submitted the correspondent proof of use for their word mark to the Clearinghouse.
.LAT registry will send to the Clearinghouse all information needed to provide notice to all trademark holders in the Clearinghouse if someone is seeking a sunrise registration. This notice will be provided to holders of marks in the Clearinghouse that are an identical match to the name to be registered during Sunrise.
.LAT will publish on its website the detail of the trademark information that prospective registrants will be required to submit to participate in the sunrise. This information will be consistent with the information required by the Clearinghouse, including proof of use and date of trademark registration.
DOMAIN NAME ALLOCATION IN THE SUNRISE PERIOD
Due to the open nature of the TLD and the wide market that it is targeted to, it is very likely that there will be a considerable number of conflicting applications both on the Sunrise and open registration periods. This condition will be addressed differently in the Sunrise and open registration periods.
To avoid chaotic rush for domain names and preserve an orderly process, all applications received during the sunrise will be treated as received at the same time. Domain names that came from a single application will be allocated to the applicant if the information is verified with data from the Applicant Clearinghouse. For all domain names for which more than one application was received the registration requests will be subject to an additional verification against Clearinghouse data.
SUNRISE PLAN
The following plan provides a summary of the different phases of the .LAT Registry Sunrise Period.
Phase 1: Sunrise (30-60 days). Holders of registered marks, with a valid registration to the Trademark Clearinghouse will be able to apply for a .LAT domain name that is an exact match of their trademarks.
Phase 2: Quiet Period (30 days). All registration requests are revised and prepared for the next phase.
Phase 3: Sunrise Revision and Allocations (30-60 days). All conflicts of applicants competing for the same domain name will be resolved, and the registrant notified of the resolution.
GENERAL PROCESS FOR SUNRISE APPLICATIONS
.LAT Sunrise Period will be executed with a small number of registrars that will be granted limited connections to the .LAT application servers. All ICANN accredited registrars will be able to participate in the .LAT Sunrise but only those who sign the accreditation for the .LAT TLD and accept the terms of the Sunrise will be granted access to register domain names.
For Sunrise applications, applicants must submit the trademark and domain name to be registered and information on the company or rights holder in a way that it could be verified by the Trademark Clearinghouse. The applications must include the Trademark Clearinghouse registration number as a reference for validation. All applications that do not have a Trademark Clearinghouse registration number or that could not be verified will be declined.
ELIGIBLE TEXT STRINGS.
The domain name applied for must be an exact match with the trademark as included in the Clearinghouse. During the sunrise, .LAT Registry will not accept IDNs. Marks that contain characters in addition to Letter Digit Hyphen (LDH) elements may replace those characters with corresponding LDH for which the special punctuations are removed. The resulting string will be considered as a match with the registered mark. Once the general availability of the TLD has commenced, registrants of domain names will be able to register IDN variants in Spanish language for their domain names. For further details on IDN registration policy and procedures refer to question 44.
.LAT SUNRISE ALLOCATION PROCESS
As noted before, the open nature of the TLD and the wide market that it is targeted to, will much likely result in a considerable number of cases where two or more applications for the same domain name may be successfully verified with data from the Clearinghouse.
.LAT Registry will implement a tie breaking mechanism to resolve conflicting applications found and verified in the Sunrise period. -
Applications received during the Phase 1 of the Sunrise will be treated as received at the same time. Received applications will be verified against data records in the Trademark Clearinghouse and all those applicants that are successfully verified will be subject to an additional data verification to determine who will receive the domain name..LAT Registry will verify that the registrant holds a valid trademark recognized by the Trademark Clearinghouse. All registration requests that do not pass initial validation will be declined.
ADDITIONAL DATA VERIFICATION
For all prospective registrants that participated in the sunrise period and applied to register the same domain name, there will be an additional verification to determine the date that the trademark or word mark registration was granted, as recognized by the TMCH. The domain name will be allocated to the applicant with the oldest trademark registration date as recorded in the TMCH.
It must be noted that accordingly to ICANN, the Trademark Clearinghouse Implementation is an ongoing work. Details regarding validation and verification of trademark data entered into the Clearinghouse will be published by ICANN. Technical information on how to integrate the functionality provided by the Clearinghouse into the registrar’s and⁄or registries’ systems will be published on time for integration.
It is expected that the mechanisms and protocols that the Registry and the Clearinghouse will use to interact will be defined by ICANN and the Trademark Clearinghouse service provider. .LAT Registry will implement all required interfaces to connect with the Clearinghouse.
If the required information to serve as tie breaking criteria is not available in the TMCH then an equivalent data should be pointed out by the Clearinghouse. If there isn’t a suitable data to serve as tie breaker, then there will be an auction.
GENERAL AVAILABILITY, LANDRUSH PERIOD
The General Availability of the .LAT domain name will be initiated with a Landrush Period. For this period, there will not be a list of reserved premium names. All names will be made available at the same time in a transparent manner. Nevertheless .LAT Registry will implement an inverse auction scheme (Dutch Auction) to give opportunity that the public and the general interest help to determine the actual value of .LAT domain names. This scheme will be explained in detail in the financial section.
NIC Mexico implemented this scheme with great success (in terms of transparency and operations efficiency) during the re-launch of second level domain registration for .MX ccTLD.
POST-LAUNCH RIGHTS PROTECTION MECHANISMS
The Post-Launch Rights Protection Mechanisms are intended to protect rights holders following the general availability launch. .LAT Registry will implement a Trademark Claims Service and also will implement decisions rendered under the Unified Rapid Suspension System (URS) and Unified Dispute Resolution Process (UDRP).
.LAT Registry will provide Trademark Claims services during the initial launch period for trademarks in the Trademark Clearinghouse. As defined by ICANN, a Trademark Claims service is intended to provide clear notice to the prospective registrant of the scope of the mark holder’s rights in order to minimize the chilling effect on registrants.
The Trademark Claims service will provide notice to potential registrants of existing trademark rights, as well as notice to rights holders of relevant names being registered. Following ICANN’s requirements .LAT Registry will implement the Trademark Claims for 60 days following the general availability launch.
UDRP
.LAT Registry will adhere to the Uniform Domain Name Dispute Resolution Policy (UDRP) as incorporated by ICANN since 1999. .LAT Registry will participate and collaborate with the dispute-resolution providers to implement any decision rendered in relation with a dispute over a domain name under .LAT TLD.
NIC Mexico as registry service provider for .LAT TLD has long experience with the implementation of the UDRP, as it was incorporated to its operative policies since December 1st 2000. Since the first UDRP case NIC Mexico has had more than one hundred cases solved by WIPO as our panelists provider and also implemented the corresponding decisions.
.LAT Registry will “lock” the domain name during a UDRP process until the panel renders a resolution and the registry is notified. This means that the registry will restrict all changes to the registration data, including transfer and deletion of the domain name, but the name will continue to resolve.
.LAT Registry operations staff will have at their disposition a tool to query and manage the “lock” status for domain names going through a UDRP procedure. The “lock” action will be reflected on the domain name by adding the corresponding EPP status like ServerUpdateProhibited, ServerDeleteProhibited, ServerTransferProhibited. Also the Administrative Status SuspendedByExternalAuthority will be used with the corresponding EPP extension.
.LAT Registry will collaborate as needed during the process, by sending all information required to the provider upon request. On NIC Mexico’s experience, the dispute resolution provider generally requests for validated whois data of the domain name.
The remedies available to a complainant pursuant to any proceeding before a provider shall be limited to requiring the cancellation of the domain name or the transfer of the domain name registration to the complainant. .LAT Registry will implement the decisions rendered by the evaluation panels upon receipt of written notice (generally an e-mail) from the provider.
URS
The Applicant Guidebook includes a new process for trademark protection developed through community consultations, first with the recommendations of the Implementation Recommendations Team (IRT) and others, and feedback gathered in online fora and public meetings.
The Uniform Rapid Suspension System (URS) is designed to offer trademark owners a quick and low-cost procedure to take down infringing websites. .LAT Registry will implement the URS as defined in the Applicant Guidebook. The operations team will have the adequate tools available to implement the decisions of the URS provider. Case of a favorable decision for the complainant .LAT Registry will suspend the domain name and will point it to a mandatory URS placeholder page for the remaining registration period.
The URS procedures will be conducted by one of the ICANN appointed URS Providers that will send notifications to .LAT Registry as needed.
Upon reception of written notice from the URS Provider .LAT Registry will take all actions required by the procedure. To start, .LAT registry will “lock” the domain within 24 hours of receipt of the “Notice of Complaint”, 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.
Accordingly to the URS procedures, .LAT Registry will notify the URS Provider immediately upon locking the domain name (”Notice of Lock”).
.LAT Registry operations staff will have at their disposition a tool to handle of actions related to the URS, including query and manage the “lock” status. The “lock” action will be reflected on the domain name by adding the corresponding EPP status like ServerUpdateProhibited, ServerDeleteProhibited, ServerTransferProhibited. Also the Administrative Status SuspendedByExternalAuthority will be used with the corresponding EPP extension.
Determinations by the evaluation panel shall also be emailed by the URS Provider to the Registrant, the Complainant, the Registrar, and the Registry Operator, and shall specify the remedy and required actions of the registry operator to comply with the Determination. .LAT Registry will implement the required actions as requested by the URS Provider, depending on the findings concerning the URS procedure.
.LAT Registry tools will include the required functionality to implement the remedies available to a complainant pursuant to any URS proceeding before a provider:
* Ordering the suspension of the domain name for the remaining of the registration period, with the nameservers redirected to an informational web page provided by the URS Provider about the URS; or
* Requiring the removal of the “lock” of the domain name and return full control to the Registrant, with the nameservers resolving to the original web site.
ABUSE
.LAT Registry will always take reasonable steps to investigate and respond to any abuse reports from law enforcement and governmental agencies of illegal conduct in connection with the use of domain names under the TLD. The abuse contact will be available to receive such reports and special priority will be given to reports received from law enforcement agencies. All findings will be reported as appropriate but no action will be taken unless they come in the form of a UDRP or USR resolution or direct instructions from ICANN, for example as part of a ERSR execution.
30(a). Security Policy: Summary of the security policy for the proposed registry
SECURITY POLICY SUMMARY
NIC Mexico, has been selected by eCOM-LAC as back end registry service provider for .LAT Registry, and as such it is responsibility of NIC Mexicoʹs IT department to provide adequate security controls on registry data and software systems, whether held centrally or remotely, to ensure the continued availability of registry services to the internet community and to ensure the integrity of all registry data.
SECURITY POLICIES
The purpose and objective of the Security Policy is to provide a framework to guarantee availability of registry services and data. With this in mind NIC Mexico will implement security policies to:
* Guarantee availability, confidentiality and integrity of registry data and systems. Registry data and systems are always available for legitimate users and authorized staff only.
* Ensure that all operations executed within registry applications and systems are accountable and traceable.
* Encourage management and staff to maintain an appropriate level of awareness that help them to follow security measures and policy defined to safeguard information assets and systems.
* To ensure that the organization is able to continue its commercial activities in the event of significant contingencies of any nature.
NIC Mexico’s infrastructure featuring 1+1 redundancy and a high availability cluster design provide for high availability of services for legitimate users. In case of a contingency, the Hot Backup Site can be operational in 4 hours or less.
NIC Mexico´s security design includes features like 2-factor authentication, whitelisting and the use of strong passwords and VPN’s to provide access to registry systems to legitimate users and authorized personnel only. Furthermore, NIC Mexico’s registry systems include fine-grain access controls built-in into applications with per-user access control lists and with supervisor confirmation for specific operations on registry objects.
ACCOUNTABILITY AND TRACEABILITY
Access will be granted only to authorized personnel and users. All their activity in the system will be logged and linked to before-and-after data history objects. This provides for accountability and traceability in case of something goes wrong. With this, a registry object’s state can be recovered or traced back to find the origin of the failure.
ONGOING WORK
Currently, NIC Mexico is working with a consultancy firm to formalize NIC Mexicoʹs security capabilities to be able get certified by the Mexican Government as a highly secured organization to be able to offer specialized services to the Mexican IRS in the near future. The capabilities required by Mexican Government are a customized set of requirements based on ISO 27001 Standard, ITIL and COBIT.
All this guidelines and best practices are being integrated in an IT Governance Model and Information Technology Management framework.
An independent assessment report is provided as part of the answer to this question. This assessment is based on controls defined by the Mexican government to verify that interested enterprises have the necessary capabilities and potential to take part on providing the required services.
NIC Mexico will take advantage of this certification to get its security policy and procedures formalized in preparation to get certified on ISO 27001.
SECURITY CAPABILITIES
IT Department is in charge of NIC Mexico’s security. They are in charge of all security related to: physical access to the main offices, computer security and also secure access to services like e-mail, file servers and other business applications and all security related to the datacenters and registry services: SRS, Whois, Data Escrow, DNS, DNSSEC.
BACKGROUND CHECKS CONDUCTED ON SECURITY PERSONNEL;
NIC Mexicoʹs HR department performs background checks on all candidates to obtain a job position in the organization. Routine personal and past work’s reference checks are performed on all candidates. Additionally NIC Mexico makes complementary investigations in case the candidate omitted information that could reveal facts that would be relevant for his or her job application.
SPECIAL SECURITY CAPABILITIES
Additionally to all security controls maintained by NIC Mexico, there is one that can be described as an augmented security capability available on NIC Mexicoʹs implementation. Mexican companies can use the NOM-151 which is a Mexican government norm to store digital messages in a special format, so that they are recognized and accepted in a trial.
This NOM-151 defines a series of cryotographic requirements that all digital messages must comply to be considered equivalent with physical evidence. In NIC Mexicoʹs implementation for registry services every transaction is recorded and by the end of the day, the system generates a digest with the digital footprint from all the commands executed during that day. This daily log of operations is, digitally signed and sent to a certiification provider, or digital notary. The validation includes a new digital signature so all the elements included in the digest are then protected with features like origin autenticationn and non repudiation.
Whith this it is not possible to alter the outcomes of any previously executed command without breaking the signature chain as it will not be possible to generate de same digest again.
SECURITY COMMITMENTS WITH REGISTRANTS
.LAT registry is committed to maintain registration services and data available to accredited registrars at all time. Additional measures will be in place to guarantee security and integrity of all registration data. All operations will be traceable back to the originating party, so it will be possiblle to verify any allegued discrepancies.
SUMMARY OF SECURITY POLICIES
NIC Mexico’s security policies cover the following aspects
Datacenter security
* The datacenter is located in a zone free of high-impact risks like gas stations, explosive materials plants.
* The datacenter has structural protection like perimeter walls and security gates
* The datacenter has infrastructure protections like fire detection and suppression systems, air conditioning systems, electric system monitoring and structured cabling for electric power and networking.
* The datacenter has a Disaster Recovery Plan
Access Control, to Datacenters and Main Offices
* The datacenter has permanent security personnel
* The datacenter has in place procedures for surveillance and facilities’ access including logs, ID’s and security cameras.
* The datacenter maintains multiple-level electronic access controls
* The datacenter have secure and critical zones properly signaled.
* Security personnel escort any supplier or maintenance crew at all times.
Telecommunications
* The datacenter has redundant highly secured connections to the internet
* All telecommunication devices are protected from power surges, and unauthorized physical and network access.
Network
* NIC Mexico’s corporative network only provides internet access to registered equipment.
* Access to networked resources other than the internet connection is provided by means of a secured VPN
* Access to the VPN is protected by a 2 factor authentication scheme
* NIC Mexico’s IT Staff use a special separated VPN to perform administrative tasks .
Computer equipment
* Computer equipment is physically secured and protected against power surges.
* Operative Systems are frequently updated and patched
* The capacity and performance of computer equipment is constantly revised and evaluated
* The time of all computer equipment is synchronized using a GPS-based Time Server.
* There are adequate procedures to identification retirement and disposal of hard drives or any storage device involved in the registry services being from failure, obsolescence or any other reason.
* All commands executed on NIC Mexico’s servers are logged and stored in a secure facility.
User Applications
* The systems architecture for user application is designed for high availability and fault tolerance.
* User applications include multi-level access control mechanisms
* User applications include strong passwords and two factor authentication when possible.
* There is a procedure for password management and control for both users and system⁄business managers.
* There is a policy and procedures for password generation and management
* User applications include audit logs
* There is a policy and procedures in place for audit logs management and control
* All communication between applications use secure protocols
* There is a basic security configuration standard for all servers and system applications
* Penetration testing on all applications is performed at least each semester.
* Secure encryption protocols are used for storing passwords and for all network traffic through public networks.
Database and Backups Security
* Registry Database will be encrypted for added security
* Backups will include Operative Systems, Databases and Applications
* Backups will be encrypted for enhanced security.
* Backups will be performed closely enough to comply with the Recovery Time and Recovery Point Objectives
* Audit logs will be included in the backup scheme and encrypted
* Backups will have at least one additional copy stored in an off-site secure facility.
* There will be a procedure for the secure disposal of backup media
Risk Management
* There will be a Risk Management scheme for the registry
* The Risk Management Scheme will define a team to identify and classify risks
* The Risk Management team will define risk response options
* The scheme will be revised and updated periodically
Change management
* Change Management Procedures are implemented
* Change Management considers changes to applications, infrastructure and all hardware related to Registry Services.
* There is a team or committee in charge of defining and approving changes to the infrastructure.
Capacity Management
* There are Capacity Management Procedures
* There are key performance indicators defined according to performance specifications included in the Registry Agreement.
* The indicators are and evaluated to identify deviations to correct them and see if they match with the anticipated growth of the registry’s capacity.
Incident Response
* There is an Incident Response procedure
* The Incident Response procedure will include criteria and definitions for opening, follow-up and closing the incident.
* Incident Response procedure considers a single point of entry⁄reporting to guarantee that the procedures are applicable to all reported incidents.
RESOURCES
The security of .LAT Technical infrastructure and registry services will be managed by NIC Mexico’s IT Department. The resources committed to this task are responsible of preserving the security and stability of the operations of NIC Mexico’s infrastructure that will support both .MX and .LAT Registry operations. All roles will serve both .MX and .LAT technical infrastructure, except where indicated as exclusive for .LAT operations.
IT department is responsible for all security policy and implementation.
The resources assigned to the technical operation and security of .LAT are as follows:
Role: Operations VP - 1 FTE
The Operations VP is in charge of maintaining both .MX and .LAT operations in a secure manner. The role is responsible for maintaining the secure and continuous operation of the registry infrastructure. His involvement includes planning, provisioning coordination and deployment of the infrastructure that supports secure registry operations.
Role: Infrastructure Manager
Role: Security Manager
Both roles are covered with 1 FTE
Role: System and Network Administrator – 2FTE
In charge of maintaining the operations of .MX and .LAT registry’s systems: SRS, (www and EPP), Whois, DNS operations including DNSSEC, Data Escrow, Security.
Also in charge of network management of .MX and .LAT including broadband connections, wireless links, network equipment, VoIP, routing, network security, IP address management, both IPv4 and IPv6.
Technical product Manager – 1FTE, exclusive for .LAT Registry Systems, Level 3 Support
Systems Development – 1 FTE exclusive for the .LAT Registry Systems
In charge of maintaining the registry systems aligned with business rules, security policies and functions of the organization. The Technical product Manager has access to NIC Mexico’s system development team in a “on demand” basis to perform preventive and corrective maintenance tasks or implement new functionality.
DAY TO DAY OPERATIONS
Day to day operations and customer support will be provided by eCOM-LAC and NIC Mexico at different levels. Business related matters, like payments and notifications, and policy related processes like UDRP, URS, Transfers, etc, will be handled by eCOM-LAC. Also a first level of technical support like network access and incident reporting will also be handled by eCOM-LAC. For security incidents and other issues of technical nature there will be support from NIC Mexico’s IT personnel.
The resources assigned to the operation of .LAT are as follows:
Customer Support, On Call, 24x7 – 1FTE, exclusive for .LAT Registry
Available to respond to customer inquiries 24x7 (Level 1 Support)
NOC, 24x7 –5 FTE (System Operators)
Available to respond to incident reports 24x7 (Level 2 Support)
Systems operators are in charge of receiving inquiries regarding registry system operations regarding .MX and .LAT systems. Work hours distribution guarantee 24x7 availability.
© 2012 Internet Corporation For Assigned Names and Numbers.