Source: http://tierra-aoi.net/1815.html
Timestamp: 2019-04-23 22:26:39+00:00

Document:
The string ʺblogʺ consists of 4 ASCII characters, each of which currently occurs as part of existing and operational gTLD strings. We are not aware of any possible rendering problems concerning the string ʺblogʺ.
We are aware of the issue of universal acceptability and accept that some incorrectly configured third-party software may consider ʺblogʺ to be an invalid string, in the same way that other TLDs such as ʺ.INFOʺ and “.MUSEUMʺ are also at times considered ʺinvalid.ʺ MLG and CentralNic will work to raise awareness of the issue of universal acceptance of .BLOG and other new gTLDs. CentralNic has previously contributed to similar efforts, such as by publication of TLD Verification code for the PHP programming language.
We are aware that a significant fraction of queries sent to the DNS root servers are for invalid TLDs such as ʺ.LOCALʺ or ʺ.LANʺ, and that the delegation of these TLDs could cause previously undiscovered configuration errors to result in operational problems for other operators. We have reviewed the research in this area, including the SAC 045 report from ICANNʹs Security and Stability Advisory Committee, data from the Day In The Life of the Internet project, and other sources, and are not aware of any significant volume of invalid root server queries related to .BLOG. Therefore we are confident that the delegation of this string will not result in any operation problems for Internet users.
The mission of the .BLOG TLD is to be the designated namespace for all individuals, groups, businesses, organizations, and other related entities that engage in activities related to blogging.
The .BLOG TLD is the online standard for blogging and blog related products and services.
The .BLOG TLD will be an Internet space that facilitates the ongoing growth of blogging as a means of communication and social networking by means of, but not limited to, websites, social networks, email, and other technologies. MLG will be adapting and broadening the scale and scope of these activities to ensure the successful launch of the .BLOG TLD.
MLG has a plan to develop, build, and sustain a unique value proposition for the .BLOG TLD, and a marketing strategy to ensure that the maximum number of people and organizations are aware of how a .BLOG domain can enhance their value proposition. A .BLOG domain will provide a competitive advantage to registrants through a multitude of scenarios. MLG’s delivery of the .BLOG value proposition will provide an additional incentive for registrants acquiring .BLOG domains to leverage their resources and capabilities and develop their unique place on the World Wide Web.
(7) leverages assets, resources, and competencies to effectively and efficiently establish a registration base from target registrant markets and all other members of the global community and public who can benefit from an ever expanding .BLOG TLD.
MLG affirms that the Internet is a transformative technology that continues to empower people around the globe, spur innovation, facilitate trade and commerce, and enable the free and unfettered flow of information. The expanding role and influence of blogs and bloggers on the Internet has demonstrated the potential of the Internet as a transformative technology.  MLG envisions .BLOG domains to be registered and used by anyone who is interested in communicating about and providing blogs or blog related products, services, or information. .BLOG domain registrations will not be restricted and everyone will have an opportunity to register a .BLOG domain name.
The introduction of a .BLOG TLD offers numerous benefits and opportunities to anyone that engages in blogging or provides blog related content or services on the Internet, as well as to the consumers of such information and services.  MLG will work closely with CentralNic and Internet registrars to implement a focused marketing strategy with an emphasis on ensuring that the traditional blogging community adopts and builds on the .BLOG foundation while also encouraging innovative uses of .BLOG by the emerging blogging community. MLG is committed to fostering competition, consumer trust, and consumer choice within the .BLOG TLD Internet space and the broader global marketplace. MLG and its partners understand the intrinsic value, rarity, and non-imitability of the .BLOG TLD and have the expertise, strategy, and capacity to ensure the successful establishment and growth of the .BLOG TLD. Through our goals, policies, and operating rules, MLG is committed to managing the .BLOG TLD in a manner that maximizes benefits and mitigates costs for all stakeholders.
The goal of the .BLOG TLD is to provide a distinct online presence for all individuals, groups, businesses, organizations, and other related entities that engage in activities related to blogging and the provision of blog related products, services, and information.
An ample supply of relevant .BLOG domains will be made available for interested persons to claim within the .BLOG domain space. Currently, there is no generic TLD specifically devoted to blogging. Instead, relevant online blog content is dispersed among a variety of existing generic and country-code TLDs without the benefit of a unifying string.
The creation and consumption of blog content has become one of the most popular activities on the Internet.  A .BLOG TLD will help bloggers and blog related service and information providers to realize greater benefits and capitalize on more opportunities provided by the Internet. A .BLOG TLD presents an opportunity for all individuals, groups, businesses, organizations, and other related entities that engage in activities related to blogging to garner a more effective and differentiated online presence.
The .BLOG TLD will be a specialized domain space which will be developed into the online standard for blogging and blog related products and services.
The .BLOG TLD is a distinctive, succinct, and memorable TLD that epitomizes the global blogging industry.  MLG’s vision is to make .BLOG domain names prevalent among people, entities, and organizations that seek and supply blog related content, products, and services.
Bloggers by definition already have an online presence. However, a .BLOG TLD allows for greater differentiation on the Internet, simplifies users’ choice when interacting and consuming blog content and services, and offers new benefits and opportunities to anyone that engages in activities related to blogging. Almost any individual could be a prospective registrant and will be accorded all the opportunities and benefits of the .BLOG TLD.
A .BLOG TLD will help level the playing field by providing a new, distinct channel for the production and consumption of blogs by Internet users. A .BLOG domain name will provide an enhanced platform for individuals and groups to broadcast and communicate their information to an online population which now numbers over two billion.
The opportunity to carry out our mission and deliver our value proposition will always be contingent upon providing benefits that matter to our registrants, Internet users, and the online population. To that end, MLG will strive to ensure that the .BLOG TLD provides the best value for creating and developing an online blog related presence. MLG’s long term strategy is to ensure that .BLOG domains become a “must-have” for all individuals, groups, businesses, organizations, and other related entities that engage in activities related to the creation of blog content or the provision of blog related products and services.
A .BLOG domain will be the “best bang for the buck” registration by providing the best value for creating and developing  distinct, clear, and credible online presence. MLG will ensure that .BLOG domains provide the best quality-to-price ratios by offering competitive registration pricing and leveraging the core competencies of MLG and CentralNic.
MLG believes that .BLOG registrants will offer a variety services and content related to blogging. .BLOG target markets are broad enough to maintain a financially viable TLD and distinct enough that the .BLOG TLD will not become ‘just another .info’. A .BLOG TLD will provide a unique space on the Internet for blogging information and services. It will allow anyone to register a domain name and develop a blog or a blog related product or service. MLG’s vision for the .BLOG TLD mirrors the Internet’s growth as a transformative technology that enables the free and unfettered flow of information.
The introduction of the .BLOG TLD to the Internet will increase competition, provide opportunities for differentiation, and promote innovation.
The .BLOG TLD will provide an alternative to the current TLDs by focusing on blogs and catering specifically to all individuals, groups, businesses, organizations, and other related entities that engage in activities related to blogging and the the provision of blog related products and services. .BLOG will serve as a force for differentiation as a distinctive namespace that simplifies users’ choice to interact and communicate through blogs. MLG expects that users will be able to navigate to .BLOG domains and subdomains intuitively, saving them time and resources.
The .BLOG TLD will introduce more relevant domain names into the Internet domain space. This will increase competition which should compel other TLDs to increase the quality-to-price ratios of their online presence offerings.
MLG hopes that the use of .BLOG domains will increase differentiation on the Internet. It is expected that the .BLOG TLD will substantially meet the online needs of its registrants.  One of MLG’s goals with the introduction of the .BLOG TLD is to ensure that our target market registrants do not have to engage in unnecessary defensive registrations with other generic TLDs and country code TLDs. MLG will be marketing and branding the .BLOG TLD using strategies that continuously support and enhance the .BLOG TLD value proposition.  MLG will continually invest in the .BLOG TLD brand to ensure that .BLOG registrants have a strong incentive to maintain their websites with substantive, regularly updated content that will lead to unique and sustained web traffic.
Currently it is difficult to find relevant and easily recognizable domain names from existing TLDs. Even if one is found, pricing can be prohibitive where the domain name is only available on the secondary market. The .BLOG TLD will allow people, businesses, organizations and entities with an interest in blogs to register a relevant domain name immediately and the freedom to develop as many uses for their .BLOG online presence as they can imagine. An ample supply of relevant, generic .BLOG domain names will be available immediately and the innovative uses for these domain names will pay dividends for the online community in ways that are not currently quantifiable.
The .BLOG TLD will enhance users’ Internet experience.
The .BLOG TLD will function with leading-edge technologies and adopt business practices to ensure a trustworthy and positive user experience. MLG will work with registrants and relevant stakeholders through a .BLOG Advisory Board that will continuously garner feedback, advice, and suggestions, and when appropriate, suggest practices, technology, and policies that help meet and exceed the expectations of .BLOG TLD users. One of MLG’s goals for the .BLOG TLD is to ensure that the .BLOG online infrastructure and aggregation of websites and services encourages Internet users to interact online more frequently and to rely on .BLOG domains for all their blogging needs.
MLG intends for users to recognize the .BLOG TLD as a trustworthy platform of online blog content and information. MLG will adopt industry leading standards and policies to provide a safe and legitimate Internet space, enhance user experience by mitigating security-associated risks which are further described in our responses to Questions 26, 27, 28, and 29.
The .BLOG TLD will adopt contemporary registration policies.
The .BLOG TLD will be open and unrestricted, allowing anyone to select an appropriate .BLOG domain name for their own legitimate purposes. Illegal uses of .BLOG domain names will not be tolerated. MLG will implement an Acceptable Use Policy as further described in response to Question 28, and will implement the UDRP, URS, and all other ICANN-required rights protection mechanisms. Further, MLG will implement additional rights protection mechanisms as described in response to Questions 28 and 29.  Registrants offering services not related to blogging will have lessened interest in the .BLOG domain because .BLOG has limited intuitive appeal outside the blog realm. The price point of .BLOG will help ensure that .BLOG domains are competitive against other TLDs.
The .BLOG TLD will adopt contemporary privacy policies.
We recognize and affirm the need for security of private and personal information on the Internet. We also recognize that the operation of a TLD necessarily involves the collection of personal information. MLG intends for users to recognize the TLD as a trustworthy indicator of the source of online information and services. User trust is enhanced when users are confident that their private or confidential information is securely protected. We intend to minimize any risks to our registrants by maintaining industry standard protocols for the protection of the personal and confidential information of registrants. With respect to Whois data, MLG will comply with ICANN policies and otherwise to ensure that complete and accurate Whois information is readily accessible for every .BLOG domain name.  Moreover, MLG will offer additional Whois verification of each registrant’s email address as discussed in response to Questions 26, 28 and 29.
MLG will deploy DNSSEC and to comply with all of the other policies and practices required by ICANN in the Registry Agreement and⁄or via any Consensus Policy. And of course, MLG will comply with all applicable laws and regulations relating to Internet security and the privacy of users’ confidential information. Furthermore, CentralNic already employs commercially reasonable practices with respect to the security of online transactions and users’ private or confidential information.
1. Our Whois service is rate limited to prevent ʺdictionaryʺ attacks where attackers try to obtain large volumes of Whois records by making repeated queries.
2. Contact objects associated with natural (as opposed to legal) persons can ʺopt outʺ of display in the Whois service, though their information is still made available via the secure Searchable Whois Service (SWS).
Additional details can be found in our response to Question 26.
The use of .BLOG domains will effectively communicate the availability of the TLD to the intended audience, not only for the specific purpose at hand but also for more general or intuitive purposes. For example, a user who first sees an advertisement for ‘productname.blog’ may later directly navigate to ‘company.blog’ to search for other products of that producer. In addition to MLG’s own specific efforts to communicate the new TLD to its intended audience, MLG expects that audience and relevant media to further communicate the TLD as they discover the many domain names, websites and services located at .BLOG domains. As the first generic TLD targeted to the blogging and blog related products and services, MLG expects a substantial degree of publicity and a high level of word-of-mouth marketing within that market.
The .BLOG TLD will function with leading-edge technologies and adopt business practices that ensure a trustworthy and positive user experience. MLG will work with registrants and relevant stakeholders through a .BLOG Advisory Board that will continuously garner feedback, advice, and suggestions and when appropriate, suggest practices, technology and policies that help meet and exceed the expectations of .BLOG TLD users. One of MLG’s goals for the .BLOG TLD is to ensure that the .BLOG online infrastructure and aggregation of websites and services encourages Internet users to interact online more frequently and rely on .BLOG domains for all their blog related needs.
MLG intends for users to perceive the .BLOG TLD as a trustworthy platform of online blog information. MLG will adopt industry leading standards and policies to provide a safe and legitimate Internet space, enhance user experience by mitigating security-associated risks which are further described in our responses to Questions 26, 27, 28 and 29.
MLG will adopt policies that develop the .BLOG TLD in a manner that provides an easily navigable and predictable domain name space--for example, ‘geographicalname.blog’ for localized websites, and ‘product.blog’ for blog content related to the product. All of this will enhance users’ experience online by lessening confusion when browsing and interacting online.
A volunteer .BLOG Advisory Council will be established.
We recognize that there are significant interests at stake in the .BLOG TLD. We believe that members of the blogging community, including bloggers, blog service providers, and consumers of blogging sites in general will have suggestions and concerns regarding the continued operation and growth of the .BLOG TLD.  We believe that these groups should be heard. MLG will establish a non-commercial volunteer .BLOG Advisory Council and additional web-based feedback mechanisms for interested parties. This combination will provide a foundation for all interested parties to express their thoughts and ideas, and will help us develop policies so that the intended benefits of the .BLOG TLD are realized and maximized.
The Advisory Council will be made up of representatives from a broad spectrum of associations, organizations and institutions who have and will indicate an interest in the .BLOG TLD. In addition to representation from MLG and CentralNic, we anticipate including members who will represent bloggers, the business community, the international community, and the Internet using public. The Council will be invited to provide MLG with feedback on specific issues as well as valuable advice to the .BLOG management team. These issues may range from policy to the introduction of new services, and the Council will serve as a resource for management as it seeks to incorporate the broadest possible input for important decisions.
A .BLOG TLD dedicated feedback website will be established.
Members of the broad Internet community should have a means of learning about and commenting on initiatives underway with the .BLOG TLD. Similarly, .BLOG management should be able to tap into the community for input on important issues. To facilitate this communication, MLG will establish a .BLOG feedback website to both inform and solicit input from interested parties. Key elements of the site will include (1) a news feed for up to date information on the development of .BLOG, (2) Discussion forums for posting comments and other items of interest to .BLOG, (3) A polling capability in order to assess interests or needs of the community from time to time.
The .BLOG TLD will adopt current domain name contention policies.
.BLOG will comply with all of ICANN’s requirements for implementation of rights protection mechanisms, including the Trademark Clearinghouse, the Uniform Domain-Name Dispute Resolution Policy and the Uniform Rapid Suspension Policy.  MLG will offer additional rights protection mechanisms as described in response to Questions 26, 28 and 29.
MLG will offer a phased launch, consistent with many prior generic TLD domain name launches. First, a Sunrise Period will be offered as required by ICANN, for trademark holders to register domain names that correspond to their marks. If there is more than one qualified Sunrise applicant, then they will be invited to participate in an auction to select the registrant of the contested name. After the close of the Sunrise Period, MLG will conduct a Premium Name Availability Period, accepting applications for registrations of any available .BLOG domain names. In the event of more than one applicant contending for any domain during this Period, all such applicants will be invited to participate in an auction to select the registrant of the contested name. After the Premium Name Availability Period, MLG will make unreserved names generally available for open registration by any interested person or entity, on a first-come⁄first-served basis.
Any changes to pricing plans or other .BLOG policies will be announced well in advance via e-mail to the registered owner of any domains, and via public announcement to all registrars that offer .BLOG registrations – all as required by the Registry Agreement.  MLG also will make contractual commitments to registrants regarding the magnitude of price escalation upon renewal.
In accordance with Specification 5 of the New gTLD Registry Agreement, the Registry Operator must initially reserve all geographic names at the second level and at all other levels within the TLD at which the Registry Operator provides for registrations.
Names on this reserved list in the TLD registry will be prevented from registration, unless and until any such names are released from reservation per MLG’s release procedures generally described below.
A corresponding list of geographic names will be made available to the public via the Registry Operator’s website in order to inform Registrars and potential Registrants of the reserved status of such names. The lists previously noted, will be regularly monitored for revisions and the reserved list, both within the registry and publicly facing, will continually be updated to reflect any changes.
In addition to these requirements, CentralNic is able to support the wishes of MLG in regards to the reservation of additional terms on a case by case basis. The .BLOG TLD registry allows such additions to the reserved list to be made by appropriately authorized staff, with no further system development changes required.
4. DNS queries for reserved domain names will result in an NXDOMAIN response.
We understand that if and when MLG wishes to release any reserved names at a later date, this will require further approval from ICANN.
In order to release reserved names, MLG will have in place a special release mechanism, described below.
Consistent with the .info release of geographic names, as referenced in the New GTLD Application, MLG will present the GAC Representatives with an option, at no charge, of objecting to release and use of  any initially reserved names at the second level.  The at-no-charge objection will remain an option for the GAC Representatives, in compliance with current ICANN requirements regarding geographic reserved names.
Generally, it is extremely unlikely that MLGʹs authorized use of any countryname.blog or cc.blog domain name could be confusing to users, or otherwise offensive to any country. To the extent that use of any .BLOG domain was ever deemed confusing or offensive, MLG will have a strong desire to resolve the situation quickly and respectfully to any affected country’s sovereign interests. At minimum, MLG will ensure that its designated abuse contact is aware of the additional sensitivities that may potentially arise with respect to use of cc.blog or countryname.blog domains, such that any complaints of this nature are prioritized accordingly.
MLG has chosen CentralNic as the registry infrastructure provider for the .BLOG TLD (see Appendix 23.1 for the acceptance letter from CentralNic.) Any information regarding technical and operational capability of the proposed TLD registry (answers to questions 23 – 44) therefore refers to CentralNic’s registry infrastructure systems.
MLG and CentralNic confirm that all registry services explained below are engineered and will be provided in compliance with the new gTLD Registry Agreement, ICANN consensus policies (such as Inter-Registrar Transfer Policy and AGP Limits Policy), and applicable technical standards. Except for the registry services described herein, no other services will be provided by the Registry that relate to (i) receipt of data from registrars concerning registrations of domain names and name servers; (ii) provision to registrars of status information relating to the zone servers for the TLD; (iii) dissemination of TLD zone files; (iv) operation of the Registry zone servers; or (v) dissemination of contact and other information concerning domain name server registrations in the TLD as required by the Registry Agreement.
Except as described herein, there are no other products or services that the Registry Operator will provide by reason of (i) the establishment of a Consensus Policy, or (ii) MLG being designated as the Registry Operator.
Any changes to the registry services that may be required in the course of MLG operating the registry will be addressed using rules and procedures established by ICANN, such as the Registry Services Evaluation Policy.
CentralNic will operate a Shared Registry System (SRS) for the TLD. The SRS consists of a database of registered domain names, host objects, and contact objects accessible via an Extensible Provisioning Protocol (EPP) interface and a web based Registrar Console. Registrars will use these interfaces to provide registration data to the registry.
The SRS will be hosted at CentralNicʹs primary operations centre in London, UK. The primary operations centre comprises a resilient, fault-tolerant network infrastructure with multiple high quality redundant links to backbone Internet carriers. The primary operations centre is hosted in Level 3ʹs flagship European data centre and boasts significant physical security capabilities, including 24x7 patrols, CCTV, and card-based access controls.
CentralNicʹs existing SRS system currently supports more than 250,000 domain names managed by over 1,500 registrars. CentralNic has effective and efficient 24x7 customer support capabilities to support these domain names and registrars, and this capability will be expanded to meet the requirements of the .BLOG TLD and provide additional capacity during periods of elevated activity (such as during Sunrise periods).
MLG will allow any Internet user to enter into an agreement allowing the user to access an Internet host server or servers designated by MLG and download zone file data. The agreement will be standardized, facilitated and administered by a Centralized Zone Data Access Provider (the “CZDA Provider”). MLG will provide access to zone file data using the file format described in Section 2.1.4 of Specification 4 of the New gTLD Registry Agreement.
MLG, facilitated by CZDA Provider, will request each user to provide it with information sufficient to correctly identify and locate the user. Such user information will include, without limitation, company name, contact name, address, telephone number, facsimile number, email address, and the Internet host machine name and IP address.
MLG will provide the Zone File FTP (or other Registry supported) service for an ICANN-specified and managed URL for the user to access the Registry’s zone data archives. MLG will grant the user a non-exclusive, non-transferable, limited right to access MLG’s Zone File FTP server, and to transfer a copy of the top-level domain zone files and any associated cryptographic checksum files no more than once per 24 hour period using FTP or other data transport and access protocols that may be prescribed by ICANN.
MLG will provide zone files using a sub-format of the standard Master File format as originally defined in RFC 1035, Section 5, including all the records present in the actual zone used in the public DNS.
MLG, through CZDA Provider, will provide each user with access to the zone file for a period of not less than three (3) months. MLG will allow users to renew their Grant of Access.
MLG will provide (and CZDA Provider will facilitate) access to the zone file to users at no cost.
The TLD zone will be served from CentralNicʹs authoritative DNS system. This system has operated at 100% service availability since 1996 and is a secure and stable platform for domain resolution. Partnering with Community DNS, CentralNicʹs DNS system includes nameservers in more than forty cities on five continents. The DNS system fully complies with all relevant RFCs and all ICANN specifications, and has been engineered to ensure resilience and stability in the face of denial-of-service attacks, with substantial overhead and geographical dispersion.
CentralNic will operate a Whois service for the TLD. The Whois service will provide information about domain names, contact objects, and name server objects stored in the Shared Registry System via a port-43 service that complies with RFC 3912. The Whois service will permit interested parties to obtain information about the Registered Name Holder, as well as Administrative, Technical and Billing contacts for domain names. The Whois service will return records in a standardised format which complies with ICANN specifications.
CentralNicʹs DNSSEC implementation complies with RFCs 4033, 4034, 4035, and 4509 and follows the best practices described in RFC 4641. Hashed Authenticated Denial of Existence (NSEC3) will be implemented, which complies with RFC 5155. The SRS will accept public-key material from child domain names in a secure manner according to industry best practices (specifically the secDNS EPP extension, described in RFC 5910). CentralNic will also publish on its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys, and secure acceptance of registrants’ public-key material. CentralNic will publish its DPS following the format described in the “DPS-framework” Internet Draft within 180 days of that draft becoming an RFC.
Applicant will provide all mandatory Rights Protection Mechanisms that are specified in the Applicant Guidebook (version 11 January 2012), namely Trademark Claims Service (section 6.1) and Sunrise service (section 6.2). All the required RPM-related policies and procedures such as UDRP, URS, PDDRP, and RRDRP will be adopted and used in the TLD. More information is available in §29.
In addition to such RPMs, MLG may develop and implement additional RPMs that discourage or prevent registration of domain names that violate or abuse another party’s legal rights. MLG will include all ICANN mandated and independently developed RPMs in the registry-registrar agreement entered into by ICANN-accredited registrars authorised to register names in the TLD. MLG will implement these mechanisms in accordance with requirements established by ICANN for each of the mandatory RPMs set forth in the Trademark Clearinghouse.
CentralNic will leverage its 16 years of experience of supporting over 1,500 registrars to provide high-quality 24x7 support and account management for the .BLOG TLD registrars. CentralNicʹs experienced technical and customer support personnel will assist the TLD registrars during the on-boarding and OT&E process, and provide responsive personal support via email, phone, and a web based support ticketing system.
Applicant and CentralNic will compile and transmit a monthly report to ICANN for the .BLOG TLD. This report will comply with Specification 3 of the New gTLD Registry Agreement.
The technical, operations, and support functions of the registry will performed in-house by CentralNicʹs personnel. These personnel perform these functions on a full-time basis.
Technical Operations refers to the deployment, maintenance, monitoring, and security of the registry system, including the SRS and the other critical registry functions. Technical Operations staff design, build, deploy, and maintain the technical infrastructure that supports the registry system, including power distribution, network design, access control, monitoring and logging services, and server and database administration. Internal helpdesk and incident reporting is also performed by the Technical Operations team. The Technical Operations team performs 24x7 monitoring and support for the registry system and mans the Network Operations Centre (NOC) from which all technical activities are co-ordinated.
The Technical Development team develops and maintains the software which implements the critical registry functions, including the EPP, Whois, Zone file generation, data escrow, reporting, backoffice, web-based management systems (intranet and extranet), and open-source registrar toolkit software. All critical registry software has been developed and maintained in-house by this team.
Technical Support refers to 1st, 2nd, and 3rd line support for registrars and end-users. Areas of support include technical support for systems and services, billing, and account management. Support personnel also deal with compliance and legal issues such as UDRP and URS proceedings, abuse reports, and enquiries from law enforcement.
1st line support issues are normally dealt with by these personnel. 2nd and 3rd line support issues (relating to functional or operational issues with the registry system) are escalated to Technical Operations or Technical Development as necessary.
Gavin has worked at CentralNic since 2001, becoming CTO in 2005. He has overall responsibility for all aspects of the SRS, Whois, DNS, and DNSSEC systems. He is a respected figure in the domain industry and has been published in several professional technical journals, and co-authored a book on the Perl programming language. He also participates in a number of technical, public policy, and advocacy groups as well as several open source projects. Gavin has a BSc (hons) in Physics from the University of Kent.
Adam has recently joined CentralNic as Senior Operations Engineer. In this role he is responsible for the operation and development of the system and network infrastructure for the registry system. Adam has previously worked at a number of large UK ISPs including Jersey Telecom and Packet Exchange. He is also the lead developer of Observium, a network management system used by ICANN (amongst others). Adam has brought his strong knowledge of network design, management, and security to bear at CentralNic and will oversee the operation of the SRS for the TLD.
Milos has worked at CentralNic since 2009. He has a background in building rich web applications and protocol servers. His main areas of responsibility are the Registrar Console, EPP, and backoffice functions.
Mary has worked at CentralNic since 2008. She plays an integral role in the ongoing design, development, and maintenance of the registry as a whole and has specific experience with the EPP system, Registrar Console, and Staff Console. Mary has a 1st class Honors degree in Computer Science from University College Cork and has previously worked for Intel and QAD Ireland.
Operations Engineers assist in the maintenance and development of the network and server infrastructure of the registry system. Operations Engineers have a good knowledge of the TCP⁄IP protocol stack and related technologies, and are familiar with best practice in the areas of network design and management and system administration. They should be competent system administrators with a good knowledge of Unix system administration, and some knowledge of shell scripting, software development, and databases. Operations Engineers have 1-2 yearʹs relevant commercial experience. Operations Engineers report to and work with the Senior Operations Engineer, who provides advice and mentoring. Operations Engineers participate in manning the NOC on a 24x7 basis and participate in the on-call shift rota.
Security Engineers enhance and assure the security of the registry system. Day-to-day responsibilities are: responding to security incidents, performing analysis and remediating vulnerabilities, conducting tests of access controls, refining system configuration to improve security, training other team members, reviewing source code, maintaining security policies and procedures, and gathering intelligence relating to threats to the registry. Security Engineers have 1-2 years of relevant commercial experience. Staff in this role report to and work with the Senior Operations Engineer and CTO. Security Engineers participate in manning the NOC on a 24x7 basis and participate in the on-call shift rota.
Technical Developers maintain the software which supports the registry. Day-to-day responsibilities are developing new systems in response to requests from management and customers, and correcting bugs and improving performance of existing software. Technical Developers have a good knowledge of general programming practices including use of revision control and code review systems. Developers have an awareness of security issues, such as those described in advisories published by the oWASP Project. Developers have at least one year of commercial experience in developing applications in programming languages such as PHP, Perl, and Python, although knowledge of domain technologies such as EPP and DNS is not critical. Technical Developers work as part of a team with advice and mentoring from the Senior Technical Developers, to whom they report.
A copy of the Resourcing Matrix is included as Appendix 23.2. It is important to note that the available resources cover the operation of CentralNicʹs entire registry operations, including CentralNicʹs own domain registry portfolio (uk.com, us.com, etc), the .LA ccTLD, as well as the gTLDs which CentralNic will provides registry service for.
The actual proportion of human technical resources required specifically for the .BLOG TLD is determined by the relative size of the TLD to the rest of CentralNicʹs operations. This calculation is based on the projected number of domains after three years of operation.  The optimistic scenario is used to ensure that sufficient personnel are on hand to meet periods of enhanced demand.
CentralNic has calculated that, if all of its TLD clients are successful in their applications and in meeting their optimistic projections after three years, the .BLOG TLD will require less than 9% of CentralNicʹs total available HR resources in order operate fully and correctly. In the event that registration volumes exceed projections, CentralNic will proactively increase the size of the Technical Operations, Technical Development, and other support teams to ensure that the needs of the TLD are fully met. Revenues from the additional registration volumes will fund the salaries of new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of the TLD for at least the first 18 months of operation.
Except where specified, this answer refers to the operations of the Applicantʹs outsource Registry Service Provider, CentralNic.
The SRS is hosted at CentralNicʹs primary operations centre in London. It is connected to the public Internet via two upstream connections, one of which is provided by Qube. Figure 32.1 provides a diagram of the outbound network connectivity. Interconnection with upstream transit providers is via two BGP routers which connect to the firewalls which implement access controls over registry services.
The load balancers pass sessions to the EPP protocol servers. Load is distributed using a weighted-least-connections algorithm. The protocol servers run the Apache web server with the mod_epp and mod_proxy_balancer modules. These servers process session commands (〈hello〉, 〈login〉 and 〈logout〉) and function as reverse proxies for query and transform commands, converting them into plain HTTP requests which are then distributed to the application servers. EPP commands are distributed using a weighted-least-connections algorithm.
Application servers receive EPP commands as plain HTTP requests, which are handled using application business logic. Application servers process commands and prepare responses which are sent back to the protocol servers, which return responses to clients over EPP sessions.
Each component of the system is resilient: multiple inbound connections, redundant power, high availability firewalls, load balancers and application server clusters enable seamless operation in the event of component failure. This architecture also allows for arbitrary horizontal scaling: commodity hardware is used throughout the system and can be rapidly added to the system without disruption to meet an unexpected growth in demand.
mod_proxy_balancer is a core Apache module. Combined with the mod_proxy module, it implements a load-balancing reverse proxy and includes a number of load balancing algorithms and automated failover between members of a cluster. CentralNic uses mod_proxy_balancer to distribute EPP commands to backend application servers.
These figures include an approximate latency of 2.4ms due to the distance between the monitoring site and the EPP system. They were recorded during normal weekday operations during the busiest time of the day (around 1300hrs UTC) and compare very favourably to the requirement of 4,000ms for session commands and 2,000ms for query commands defined in the new gTLD Service Level Agreement. RTTs for overseas registrars will be higher than this due to the greater distances involved, but will remain well within requirements.
Horizontal scaling is preferred over vertical scaling. Horizontal scaling refers to the introduction of additional nodes into a cluster, while vertical scaling involves using more powerful equipment (more CPU cores, RAM etc) in a single system. Horizontal scaling also incorporates effective mechanisms that ensure high-availability and eliminate single points of failure in the system.
The Registrar Console currently sustains an average of 6 page requests per minute during normal operations, with peak volumes of around 8 requests per minute. Volumes during weekends are significantly lower (less than 1 request per minute). Additional load resulting from this and other new gTLDs is expected to result in a trivial increase in Registrar Console request volumes, and CentralNic does not expect additional hardware resources to be required to support it.
Registry system updates are performed on an ongoing basis, with any user-facing updates (i.e. changes to the behaviour of the EPP interface) being scheduled at specific times. Disruptive maintenance is scheduled for periods during which activity is lowest.
CentralNic operates a complex billing system for domain name registry services to ensure registry billing and collection services are feature rich, accurate, secure, and accessible to all registrars. The goal of the system is to maintain the integrity of data and create reports which are accurate, accessible, secured, and scalable. Debit accounts established for each registrar are the basis of the process. CentralNic will withdraw all domain fees from the registrar’s account on a per-transaction basis. CentralNic will provide fee-incurring services (e.g., domain registrations, registrar transfers, domain renewals) to a registrar for as long as that registrar’s account shows a positive balance.
•	1st Level: initial support level responsible for basic customer issues. The first job of 1st Level personnel is to gather the customer’s information and to determine the customer’s issue by analyzing the symptoms and figuring out the underlying problem.
•	2nd Level: more in-depth technical support level than 1st Level support containing experienced and more knowledgeable personnel on a particular product or service. Technicians at this level are responsible for assisting 1st Level personnel solve basic technical problems and for investigating elevated issues by confirming the validity of the problem and seeking for known solutions related to these more complex issues.
•	3rd Level: the highest level of support in a three-tiered technical support model responsible for handling the most difficult or advanced problems. Level 3 personnel are experts in their fields and are responsible for not only assisting both 1st and 2nd level personnel, but with the research and development of solutions to new or unknown issues.
1.	Normal: general enquiry, usage question, or feature enhancement request. Handled by 1st level support.
2.	Elevated: issue with a non-critical feature for which a work-around may or may not exist. Handled by 1st level support.
3.	Severe: serious issue with a primary feature necessary for daily operations for which no work-around has been discovered and which completely prevents the feature from being used. Handled by 2nd level support.
4.	Critical: A major production system is down or severely impacted. These issues are catastrophic outages that affect the overall Registry System operations. Handled by 3rd level support.
1.	Replication of data between active and standby servers (see §33). CentralNic implements redundancy in its database system by means of an active⁄standby database cluster. The database system used by CentralNic supports native real-time replication of data allowing operation of a reliable hot standby server. Automated heartbeat monitoring and failover is implemented to ensure continued access to the database following a failure of the primary database system.
2.	Replication is used to synchronise the primary operations centre with the Disaster Recovery site hosted in the Isle of Man (see §34). Database updates are replicated to the DR site in real-time via a secured VPN, providing a ʺhotʺ backup site which can be used to provide registry services in the event of a failure at the primary site.
CentralNicʹs resourcing model assumes that the ʺdedicatedʺ resourcing required for the TLD (i.e., resourcing required to deal with issues related specifically to the TLD and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that the TLD will use. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, this TLD will require less than 9% of the total resources available for this area of the registry system.
In the event that registration volumes exceed projections, CentralNic will proactively increase the size of the Technical Operations, Technical Development, and support teams to ensure that the needs of the TLD are fully met. Revenues from the additional registration volumes will fund the salaries of new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of the TLD for at least the first 18 months of operation.
1.	domains must comply with the syntax described in RFC 1035 §2.3.1. Additionally, the first label of the name must be between 3 and 63 characters in length.
2.	domains must have a registrant attribute which is associated with a contact object in the database.
3.	domains must have an administrative contact attribute which is associated with a contact object in the database.
4.	domains must have a technical contact which attribute is associated with a contact object in the database.
5.	domains may have an billing contact attribute which is associated with a contact object in the database.
7.	the host object model for domains is used rather than the host attribute model.
8.	domains may have a number of status codes. The presence of certain status codes indicates the domainʹs position in the lifecycle, described further in §27.
9.	where policy requires, the server may respond to a 〈domain:create〉 command with an ʺObject Pendingʺ (1001) response. When this occurs, the domain is placed onto the pendingCreate status while an out-of-band validation process takes place.
10.	when registered, the expiry date of a domain may be set up to ten years from the initial date of registration. Registrars can specify registration periods in one-year increments from one to ten.
11.	when renewed, the expiry date of a domain may be set up to ten years from the current expiry date. Registrars can specify renewal periods in one-year increments from one to ten. domains which auto-renew are renewed for one year at a time.
12.	domains must have an authInfo code which is used to authenticate inter-registrar transfer requests. This authInfo code may contain up to 48 bytes of UTF-8 character data.
13.	domains may have one or more DS records associated with them. DS records are managed via the secDNS EPP extension, as specified in RFC 5910.
14.	only the sponsoring registrar of the domain may submit 〈update〉, 〈renew〉 or 〈delete〉 commands for the domain.
1.	host names must comply with RFC 1035. The maximum length of the host name may not exceed 255 characters.
2.	in-bailiwick hosts must have an IPv4 address. They may optionally have an IPv6 address.
3.	multiple IP addresses are not currently permitted.
4.	sponsorship of hosts is determined as follows: if an object is in-bailwick (ie child of a domain in the database, and therefore also child to a TLD in the system), then the sponsor is the sponsor of the parent domain. If the object is out-of-bailiwick, the sponsor is the registrar which created the contact.
5.	if a registrar submits a change to the name of a host object, if the new host name is subordinate to an in-bailiwick domain, then that registrar must be the sponsor of the new parent domain.
6.	registrars are not permitted to create hosts that are subordinate to a non-existent in-bailiwick domain, or to change the name of a host object so that it us subordinate to a non-existent in-bailiwick domain.
7.	a host cannot be deleted if one or more domains are delegated to it (the registry deletes hosts to remove orphan glue, see §28).
8.	inter-registrar transfers are not permitted.
9.	only the sponsoring registrar of the host may submit 〈update〉 or 〈delete〉 commands for the object.
1.	contact IDs may only contain characters from the set A-Z, 0-9, . (period), - (hyphen) and - (underscore) and are case-insensitive.
2.	phone numbers and email addresses must be valid as described in RFC 5733 §2.5 and §2.6.
3.	contact information is accepted and stored in ʺinternationalizedʺ format only: that is, contact objects only have a single 〈contact:postalInfo〉 element and the type attribute is always ʺintʺ.
4.	the 〈contact:org〉, 〈contact:sp〉, 〈contact:pc〉, 〈contact:phone〉 and 〈contact:fax〉 elements are optional.
5.	contacts must have an authInfo code which is used in inter-registrar transfers. This code may contain up to 48 bytes of UTF-8 character data.
6.	a contact cannot be deleted if one or more domains are associated with it.
7.	only the sponsoring registrar of the contact may submit 〈update〉 or 〈delete〉 commands for the object.
1.	Developers maintain their own development environment in which new code is written and changes are prepared. Development environments are configured with the highest level of debugging and strictness to provide early detection of faults.
2.	All changes to the EPP system are subjected to peer review: other developers in the team must review, test and sign off the changes before being committed (or, if developed on a branch, being merged into the stable branch).
3.	Changes to EPP system code are then deployed in the OT&E environment. Registrars continually test this system as part of their own QA processes, and this additional phase provides an additional level of quality assurance.
CentralNic will monitor its Whois system to confirm compliance. Monitoring stations will check the behaviour and response of the Whois service to ensure the correctness of Whois records. CentralNic will maintain a public Whois contact to which bug reports and other questions about the Whois service can be directed. The Whois service will additionally comply with all requisite data protection laws (with regards to the collection and retention of personal data), including all relevant European Union privacy directives.
An example of a domain whois response is included in Appendix 26.1. The Domain ROID is the Repository Object Identifier as described in RFC 5730, §2.8. The ROID field corresponds to the 〈domain:roid〉 element of EPP 〈info〉 responses.
•	PENDING CREATE - a 〈domain:create〉 command has been received through the SRS, but the registration has not yet been finalised as an out-of-band review process has not yet been completed.
•	OK - present if none of the above apply.
Users can query for information about a contact by submitting a query of the form ʺcontact IDʺ, where ʺIDʺ is the contact ID equivalent to the 〈contact:id〉 element in EPP 〈info〉 responses. This is also the ID used when referring to contacts in domain responses.
The Referral URL is the website of the Sponsoring Registrar for this host. If the host is subordinate to a domain name in the TLD, this will be the sponsoring registrar of the parent name. If the host is out-of-bailiwick, then the sponsoring registrar is the registrar who issued the original 〈create〉 request.
CentralNic provides a web interface to the Whois service on its website. In addition, MLG will provide a similar service on the TLD registry website. The web Whois acts as a proxy to the port 43 Whois service: users enter a query into a form, and a server-side process submits the query to the Whois server, and displays the response. This service will not be subjected to the rate limiting described above, but users will be required to complete a CAPTCHA to prevent high-volume automated access.
CentralNicʹs resourcing model assumes that the ʺdedicatedʺ resourcing required for the TLD (ie, that required to deal with issues related specifically to the TLD and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that the TLD will use. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, this TLD will require less than 9% of the total resources available for this area of the registry system.
In the event that registration volumes exceed projections, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of the TLD are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of the TLD for at least the first 18 months of operation.
The domain is not registered. No delegation (or any other records) exist in the DNS, and the whois system will return a ʺNOT FOUNDʺ response to queries. An EPP 〈check〉 command will return an ʺavailʺ status of 1.
A registar submits an EPP 〈create〉 command or registers the domain name via the Registrar Console. The registration fee is deducted from the registrarʹs balance. The initial registration period may be any whole number of years between one (1) and ten (10).
While the domain is registered, it is delegated to the specified name servers and will resolve normally. During this time, the registrar may update the domain nameʹs DNS settings, lock statuses and contact associations, and may extend the registration period (subject to a maximum of ten (10) years) by submitting a 〈renew〉 EPP command or using the Registrar Console.
The Renew Grace Period is the five (5) calendar days following the renewal of the domain via an EPP 〈renew〉 command, or via the Registrar Console.
This status may be set by registrars using an EPP 〈update〉 command, or via the Registrar Console. Domains with this status are removed from the DNS and will not resolve.
This status may be set by registrars using an EPP 〈update〉 command, or via the Registrar Console. When set, all attempts by the registrar to delete the domain using an EPP 〈delete〉 command will be refused with EPP response code 2304 (Status Prohibits Operation). Registrars must remove the code using an EPP 〈update〉 command before they can delete the domain.
This status may be set by registrars using an EPP 〈update〉 command, or via the Registrar Console. When set, all attempts by the registrar to renew the domain using an EPP 〈renew〉 command will be refused with EPP response code 2304 (Status Prohibits Operation). Registrars must remove the code using an EPP 〈update〉 command before they can renew the domain.
This status may be set by registrars using an EPP 〈update〉 command, or via the Registrar Console. When set, all attempts by the registrar to update the domain using an EPP 〈update〉 command will be refused with EPP response code 2304 (Status Prohibits Operation), unless the 〈update〉 request frame includes a 〈rem〉 element to remove this status. Once the status has been removed, subsequent 〈update〉 commands will succeed.
This status may be set by registrars using an EPP 〈update〉 command, or via the Registrar Console. When set, all attempts by other registrars to submit a transfer request for the the domain using an EPP 〈transfer〉 command, or via the Registrar Console, will be refused with EPP response code 2304 (Status Prohibits Operation). The sponsoring registrar must remove this status before any other registrar can submit a transfer request.
This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to delete the domain using an EPP 〈delete〉 command will be refused with EPP response code 2304 (Status Prohibits Operation).
This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to update the domain using an EPP 〈update〉 command will be refused with EPP response code 2304 (Status Prohibits Operation).
This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to renew the domain using an EPP 〈renew〉 command will be refused with EPP response code 2304 (Status Prohibits Operation).
This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to transfer the domain using an EPP 〈transfer〉 command will be refused with EPP response code 2304 (Status Prohibits Operation).
The Registry system supports the ʺpendingCreateʺ status for domain names, as described in RFC 5731, §3.3. Domains in this state are fully registered in the database (subsequent 〈create〉 commands would fail with an Object Exists error) but are not present in the DNS.
Top Level Domain registries stand in a unique position within the global DNS infrastructure.
TLD registries collect registrants’ registration data and thus often “know” the entity responsible for a particular domain name. TLD registries record associations between domain names, registrars, and registrants and therefore are at the core of the control chain for every domain name in the TLD. Registries also directly control the delegation records and therefore have the power to enable or disable a particular domain name in the DNS.
This unique position gives power and calls for responsibility. MLG, as a future TLD registry, recognizes its important role in maintaining law and order and is committed to acting in the best interests of the public.
The following is a description of the principles and procedures we will apply to mitigate abusive conduct.
To streamline the information flow and to facilitate ease of communication with the public, MLG will dedicate a single abuse point of contact responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning all names registered in the TLD. The contact information will consist of at least an email address and a telephone number. This point of contact will be prominently published on the registry website by the commencement of the Sunrise period.
•	Abuse contact information will be kept current and will be updated should it ever change in a timely manner.
Messages received through the published abuse point of contact will be processed via the same procedure and within the same timeframe as the signals coming from the monitoring systems. Each message, both via email and phone channels, triggers the creation of a support ticket in a dedicated queue and procedures for ticket escalation exist. Messages originating from law enforcement authorities are by default assigned an escalated level. For critical tickets, personnel are available 24x7 to react accordingly.
MLG and CentralNic commit to responding to all abuse complaints within 24 hours of receipt (on a 24x7 basis). During the time periods when its global offices are open (typically 8am-6pm in London, Los Angeles and Dubai) response times are expected to be substantially faster, at around 2-3 hours.
MLG is prepared to deal with situations where registry intervention may be required in order to stop illegal activity, prevent abusive conduct, or to enforce the law.
MLG will adopt a comprehensive Acceptable Use Policy that will establish what constitutes acceptable use of the domain and will contain a description of registry procedures that will apply to enforce the Policy. The initial draft of this policy is provided in answer to Question 29.
An enforcement action may be triggered by a variety of events including complaints from the public, registrars, or ICANN, or from decisions of a competent dispute resolution provider, outreach from a governmental agency, or findings produced by internal investigation or monitoring processes.
The .BLOG Acceptable Use Policy will be incorporated into the Registry-Registrar agreements. Registrars will be required to pass on to registrants the requirements to comply with the policy. MLG will take reasonable steps to investigate and respond to any reports of illegal activity in connection with the use of the TLD and will cooperate with competent governmental agencies in such investigations.
MLG will utilize the expert services of its registry services provider CentralNic to implement and enforce all of our anti-abuse policies in our TLD. CentralNic has dedicated and scalable resources for this function, described below.
CentralNic has long experience in the domain registry business, and is an industry leader with respect to its anti-abuse policies. CentralNic has a dedicated Dispute Resolution Policy in place with WIPO, found at WIPO’s website: http:⁄⁄www.wipo.int⁄amc⁄en⁄domains⁄gtld⁄cnic⁄index.html. This policy mirrors the UDRP policy for new gTLDs and, as a result, CentralNic already has real-time experience working with WIPO to implement and execute a similar policy.  CentralNic has trained personnel who handle interaction with WIPO, to ensure that panelists’ decisions are carried out expeditiously as required by the DRP.
Firstly, the Shared Registry System will reject any request to create host object that is the child of a non-existent domain name. That is, if EXAMPLE.BLOG does not exist, then NS0.EXAMPLE.BLOG cannot be created. If the parent domain name does exist, then only the sponsoring registrar of that domain is permitted to create child host objects.
MLG will operate a “thick” WHOIS system, in which all registrants’ contact information will be stored in a single database maintained by the registry. Accredited registrars will have the ability to change the records in that database through the Shared Registration System. The Registry-Registrar agreement requires registrars to ensure that the WHOIS data is accurate at the time of submission and also requires the information provided on the system to be updated in a timely manner in case of any changes. Corresponding provisions also exist in the Registrar Accreditation Agreement (RAA), para. 3.7.7.
In addition to the standard measures described above, the .BLOG WHOIS system will feature extra levels of reliability with regards to Whois information.
•	Verify that the domain holder receives email at the addresses listed in WHOIS as registrant’s email address and administrative contact email address, by requiring them to click a unique web link that is sent to those addresses.
•	delete the domain name(s).
MLG and CentralNic will provide abuse response on a 24x7 basis. The resourcing to fulfill this function will be provided by a combined team of support and operations personnel. The first response function will be provided by support agents during normal office hours, with this responsibility being passed to the Network Operations Centre (NOC) during 24x7 operations.
As can be seen in the Resourcing Matrix found in Appendix 23.2, CentralNic will maintain a team of full-time developers and engineers who will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to 75% of a full-time role.
MLG acknowledges that new types of abusive behaviour emerge in cyber space and is prepared to take steps to counter any new types of abuse. MLG will periodically (once every 12 months, or more frequently depending on the circumstances) require CentralNic to provide reports regarding the received abuse-related complaints. Such reports should contain categorisation of the abusive behaviour reported, actions taken, and response time. MLG will analyse the reports and will review its anti-abuse policies to continually improve the handling of abuse complaints.
MLG affirms that providing appropriate mechanisms to protect legal rights of others is one of the core objectives of the Registry. MLG will follow rules and policies developed by ICANN with regards to Rights Protection Mechanisms (RPMs). MLG will fully comply with Specification 7 of the new gTLD registry agreement and will provide additional rights protection mechanisms over and above the ICANN requirements. Both standard and additional RPMs are described below.
Prior to the open registration phase MLG will offer a priority registration period for owners of trademarks and service marks. This period will last at least 30 days.
MLG will support Trademark Clearinghouse (TCH) once it is implemented by ICANN. Owners of trademarks pre-validated by the Clearinghouse will be able to secure their domain registrations during the Sunrise period without further verification of their intellectual property rights.
•	Marks that are specifically protected by a statute or treaty.
The result of the evaluation of Sunrise applications will be published on the Registry website. A process will be in place to allow third parties to dispute the registrant rights to own a domain name. MLG will engage a reputable adjudicator to manage the Sunrise challenge process. The adjudicator will charge a reasonable fee for Sunrise challenges.
•	the trademark registration on which the domain name registrant based its Sunrise registration did not issue on or before the effective date of the Registry Agreement and was not applied for on or before ICANN announced the applications received.
The Trademark Claims service will be launched by the registry as soon as the open registration period starts and will be provided for at least 90 days (exceeding the period mandated by ICANN). MLG will review the effect of the Trademark Claims service and based on the results of such review, MLG is prepared to consider providing the Trademark Claims service on an ongoing basis.
Operational rules of the Trademark Claims service are heavily dependent on the specific implementation of the Trademark Clearinghouse which is not yet available in writing. Therefore full details of the Trademark Claims service will be finalized after the TCH is implemented by ICANN and full documentation, policies, terms, and conditions become available.
.BLOG will comply with the Uniform Domain Name Dispute Resolution Policy or with any successor thereof. The UDRP will be incorporated by reference into Registry-Registrar Agreements. Similarly, Registrars will be required to incorporate it into their Domain Registration agreements with the Registrants.
The UDRP process does not provide for any participation by the Registry and is fully borne by the Registrar, Registrant, Complainant, and the Dispute Resolution Provider. However, MLG is prepared to collaborate with all relevant stakeholders to ensure UDRP decisions are implemented.
CentralNic, MLG’s registry services provider, has maintained a similar dispute resolution policy with WIPO which is available at http:⁄⁄www.wipo.int⁄amc⁄en⁄domains⁄gtld⁄cnic⁄index.html. CentralNic has dedicated personnel trained to address these types of complaints and to communicate with WIPO and other relevant stakeholders.
As opposed to the UDRP procedure, registries are required to participate in the URS procedure and enforcement of the URS decisions. MLG will comply with the URS policy once implemented by ICANN.
The URS compliance function will be performed by CentralNic and overseen by MLG. Given CentralNic’s long-standing experience in dealing with trademark-related disputes in domain names, MLG has no doubt that this function will be performed by CentralNic flawlessly.
MLG notes this is CentralNic’s current policy for its current registry businesses. MLG may make modifications to this Policy, without limitation by charging a reasonable fee and⁄or by specifying the mediation mechanism, as its business plans develop prior to launch of the TLD. However, MLG remains committed to offering a less formal and less expensive procedure than the UDRP, and perhaps even the URS, to the extent commercially feasible.
•	MLG will dedicate a single abuse point of contact. Correspondence and complaints coming through that point of contact will be continuously monitored and responded to within 24 hours.
•	MLG will adopt a comprehensive Eligibility and⁄or Acceptable Use Policy that will set forth the limits of acceptable use of domains and the procedures the Registry will apply in case of violations of applicable laws or policies, including takedown procedures. The initial Acceptable Use Policy is provided in this section below.
•	MLG will delete orphan glue records once the parent domain is deleted to prevent abuse of these orphan glue records.
•	MLG will require registrars to perform extra checks on WHOIS data to improve its accuracy.
•	MLG will perform random audits of WHOIS data and will flag suspicious registrations via registrars.
MLG reaffirms its intent to comply with the ICANN-mandated Post-Delegation Dispute Resolution Procedure (PDDRP).
MLG believes that its choice of TLD string and the way the TLD is intended to be operated represents a good faith offering of Top Level Domain Registry service and does not infringe on any legitimate third party trademark rights.
MLG also reaffirms its commitment to maintain .BLOG free of violations of third party trademark rights through second level domain registration and use. MLG has all the required resources, policies and procedures in place to address any situations of abuse without the need to invoke the PDDRP procedure.
This policy is subject to all ICANN requirements for new gTLDs, including the URS and UDRP, and will be made compliant with any future ICANN requirements as and when necessary.
CentralNicʹs Information Security Management System (ISMS) complies with ISO 27001. CentralNic is working towards achieving full ISO 27001 certification and has secured the services of Lloydʹs Register Quality Assurance (LRQA), a UKAS accredited certifier for its ISO 27001 certification. A letter from LRQA confirming this engagement is included in Appendix 30(a).1. Stage One of this process is scheduled during May 2012, with Stage Two occurring in July 2012. The ISMS is part of a larger Management System which includes policies and procedures compliant to ISO 9001.
MLG believes that the TLD requires no additional security levels above those expected of any gTLD registry operator. Nevertheless, MLG and CentralNic will operate the TLD to a high level of security and stability in keeping with its status as a component of critical Internet infrastructure.
•	The SRS will be operated in a secure manner. Controls will be in place to prevent unauthorised access and modification of registry data.
•	The Whois service will prevent unauthorised bulk access to domain name registration data, and provide tools to protect personal information.
•	The DNS system will be designed to provide effective defence against DDoS attacks. The registry will proactively monitor the DNS system to provide early warning against threats to the stability of the TLD.
•	The DNSSEC system will be operated in accordance with best practices and recommendations as described in the relevant RFC documents (described in §43).
•	Security incidents reported by registrars, registrants and other stakeholders will be acted upon in accordance with the Security Incident Response Policy (see below).
•	Security vulnerabilities reported to the registry will be acknowledged and remediated as quickly as possible.
•	Registrars will be promptly notified of all incidents that affect the security and stability of the registry system and their customers, and will be kept informed as incidents develop.
￼￼￼CentralNic operates a Security Incident Response Policy which applies to all events and incidents as defined by the policy, and to all computer systems and networks operated by CentralNic.
•	Review and monitor information security threats and incidents.
•	Approve initiatives and methodologies to enhance information security.
•	Agree and review the security policy, objectives and responsibilities.
•	Review client requirements concerning information security.
•	Promote the visibility of business support for information security company-wide.
•	Perform internal audits with the assistance of Blackmores.
MLG will have strict security policies in place for all offices, staff, and equipment in regards to all gTLD operations.
All offices established for the operation of the gTLD will be physically separated from the general offices of MLG.  In the case that gTLD offices are established within existing MLG office space, the gTLD office will have its own fire rated security doors which will be access restricted to gTLD staff, and which will remain locked at all times.  Access to gTLD offices will be gained via scannable ID cards, which will automatically unlock the doors and will create a log of traffic in and out of the office.  These records will be audited regularly to ensure compliance with security policies, and any discrepancies will be investigated by the Managing Director of the gTLD and the Executive Director of MLG. Visitors to the gTLD office will sign in and out and will be escorted by a staff member at all times.
All workstations and servers will be audited to ensure they adhere to best-practices for security, including needing a password to log in, which will comply with complexity requirements, and must be changed a minimum of every 30 days.  Workstations and servers will be locked at all times not in use.  All hard drives will be encrypted using PGP Hybrid Cryptographic Optimizer (HCO) technology, and will be FIPS 140-2 validated, CAPS-approved, DIPCOG-approved, CC EAL 4+ certified.  Any data that needs to be kept on removable media for any reason will be encrypted using the same standards, and said media will be kept in a fire rated locked safe.
There will be regular audits to ensure that physical security, computer software (including anti-virus and anti-malware), and firmware are kept up to date and patched to fix the latest vulnerabilities.  There are no plans to have any wireless access in the office due to security concerns with such technology.  No computer cabling will extend outside the office, and all servers and network equipment will be kept in a secure room with separate locks and cooling.  This server room will be kept locked at all times and only Brendon Ralfe and Evatt Merchant will have access to open this room for inspection, maintenance, or other purposes.  All server and network equipment will have a redundant power supply.  All servers will be backed up off-site to a 3rd party using 128 bit encryption and stored there for disaster recovery on encrypted hard drives at a minimum of 2 locations.
The offices will be secured with both a monitored alarm system, and 24 hour digital CCTV surveillance, footage from which will be kept for a minimum of 6 months.
MLG is working with CentralNic and other security experts to enhance site and network security measures in addition to policy development, employee training, and enhanced physical security measures.

References: §29
 §33
 §34
 §2
 §27
 §28
 §2
 §2
 §2
 §3
 §43