Application Details
Last published on: 7 October 2026 at 15:23 UTC
Application Responses
Section: Applying Entity Information
This question set collects information regarding the legal entity that would enter into a Registry Agreement with ICANN upon successful completion of all relevant application processes. The information collected is intended to be used for background screening.
Provide the full legal name of the applying entity as it appears on the official registration documents. Do not use abbreviations.
Internet DotTrademark Organisation Limited
Provide the long form (no acronyms) of the legal entity form/business structure of the applying entity as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation. No additional information should be provided as this will be used for the automatic population of the Registry Agreement.
Private Limited Company/Body Corporate
The jurisdiction indicates the location in which the business of the applying entity is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the applying entity is registered. No additional information should be provided as this will be used for the automatic population of the Base Registry Agreement. Examples include "Delaware", "Germany", etc.
Hong Kong, China
Provide the website URL of the applying entity, if available.
https://www.trademarkdomain.com/
1. Choose Yes or No. 2. Use the definition of Affiliate from the Base Registry Agreement (see https://www.icann.org/en/registry-agreements/base-agreement).
true
1. Specify if the applying entity is an existing registry operator, ICANN accredited registrar, and/or an Affiliate of a registry operator and/or registrar. 2. If the applying entity is an Affiliate, provide the details of such Affiliate relationship, including the name of the affiliated registry operator and/or registrar. 3. If the applying entity is an ICANN accredited registrar, specify the registrar ID number.
The applying entity is an existing registry operator for the TLDs .xn--czr694b and .xn--imr513n. The applying entity (Internet DotTrademark Organisation Limited, Hong-Kong SAR) and ShangYu Global Technology Co., Ltd. are entities subject to the same ultimate controlling party. Both entities are ultimately controlled by the same natural-person controller through an intermediate Cayman Islands holding company. ShangYu Global Technology Co., Ltd. (IANA ID 3813) is an ICANN-accredited registrar. Jiang Yu Liang Cai Technology Company Limited, a wholly-owned subsidiary of ShangYu Global Technology Co., Ltd., acts as the registry operator for the delegated gTLD .xn--otu796d. There is no direct shareholding between the Hong Kong-based applicant entity and either the accredited registrar or its registry operator subsidiary. Ultimate control is exercised via the top-level Cayman Islands holding platform.
Choose Yes or No.
false
86
Provide the primary business phone number without including the country code.
13521738308
Provide the primary business email address of the applying entity.
sunxuejie@tdnnic.org
Enter the street address (no PO Box).
Rm 1502, Building 7, No. 9 Shouti South Road, Haidian District
Enter the city, village, municipality, etc.
Beijing
Enter the state, province, department, territory, prefecture, oblast, etc., if applicable.
Beijing
1. Enter the postal code, if applicable. 2. If a postal code does not exist, type “Not Applicable”.
100037
CN
If applicable, provide the full legal name as it appears on the official registration documents of the Direct Parent Company of the applying entity. Do not use abbreviations.
DotTrademark Holding Limited
Provide the long form (no acronyms) of the legal entity form/business structure of the Direct Parent Company as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation.
Business Company Limited by Shares/Body Corporate
The jurisdiction indicates the location in which the business of the Direct Parent Company is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the Direct Parent Company is registered. Examples include "Delaware", "Germany", etc.
British Virgin Islands
If applicable, provide the full legal name as it appears on the official registration documents of the Ultimate Parent Company of the applying entity. Do not use abbreviations. "Ultimate Parent Company" means, with respect to an Applicant (and, if applicable, a Direct Parent Company), the top-level entity that directly or indirectly possesses the power to direct the management and policies of such Applicant (and, if applicable, a Direct Parent Company) through the ownership of voting securities, as a general partner, as a managing member, by contract, or otherwise. An Ultimate Parent Company is not controlled by any other entity. If there are no intermediary entities between the Applicant and the Ultimate Parent Company, the Ultimate Parent Company would be the same entity as the Direct Parent Company.
DotTrademark Holding Group
Provide the long form (no acronyms) of the legal entity form/business structure of the Ultimate Parent Company as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation.
Exempted Company Limited by Shares/Body Corporate
The jurisdiction indicates the location in which the business of the Ultimate Parent Company is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the Direct Parent Company is registered. Examples include "Delaware", "Germany", etc.
Cayman Islands
Section: Applying Entity Background and Organization
This question set collects information related to the individuals who will have access to TAMS, manage the application, and receive inquiries.
Xiongwei Huang
Xiongwei Huang, Yangyi Wu
DotTrademark Holding Limited
Xiongwei Huang
Xiongwei Huang
Section: Self-Certification
Provide a single document for Self-Certification question Q2.2-1. The document must include only the SC2.2-1.1, SC2.2-1.2, or SC2.2-1.3 statements. Do not modify any of the Self-Certification statements.
1. Provide a single document for Self-Certification question Q2.2-1. 2. The document must include only the SC2.2-1.1 through SC2.2-1.3 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC2.2-1.1 through SC2.2-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC2.2-1.1 through SC2.2-1.3 statements.
Section: Operational/Planning
The document for Q2.3.1 must be a PDF. The document for Q2.3-2 must be an Excel (.xlsx) file.
The document for Q2.3-1 must be a PDF.
Section: Security Policy and Planning
Provide a single document for Self-Certification question AGB Q220, Q5.1-1. The document must include only the SC5.1-1.1 through SC5.1-1.3 statements. Do not modify any of the Self-Certification statements. If the applicant cannot Self-Certify SC5.1-1.1 through SC5.1-1.3 statements, provide a document that explains why the entity cannot Self-Certify the SC5.1-1.1 through SC5.1-1.3 statements.
1. Provide a single document for Self-Certification question Q5.1-1. 2. The document must include only the SC5.1-1.1 through SC5.1-1.3 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC5.1-1.1 through SC5.1-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.1-1.1 through SC5.1.1-3 statements.
Section: DNS Abuse
Provide a single document for Self-Certification question AGB Q221, Q5.2-1. The document must include only the SC5.2-1.1 through SC5.2-1.7 statements. Do not modify any of the Self-Certification statements. If the applicant cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements.
1. Provide a single document for Self-Certification question Q5.2-1. 2. The document must include only the SC5.2-1.1 through SC5.2-1.7 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements.
Section: Primary String
This question set collects basic information regarding the string that is being applied for (for example, a-label, meaning, script). If the applying entity opts to designate a replacement string, it must answer the same set of questions for the replacement string from the AGB Question Set 5 on.
xn--gmqz0qc7o
机器人
U+673A U+5668 U+4EBA
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 applying entity. If there is no literal meaning in English (for example, a brand name or a proper noun without a translation) simply state "No English Translation"
"机器人" means "Robot" in Chinese. In our opinion, the string literally represents an intelligent robotic system, automation platform, or device.
If an IDN, provide the script of the string (both in English and as referenced by the RZ-LGR/ISO 15924)
Chinese (Han)
Provide a representation of the string according to the International Phonetic Alphabet.
/tɕi˥ tɕʰi˥ ʐən˧˥/
Confirm the statement using a checkbox.
true
1. Describe the mission and purpose of the applied-for gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose. 1a. If applying for a variant of an existing gTLD, please also describe the mission and purpose of the existing gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose. 2. Explain how this purpose is sustainable over time.
Mission and Purpose The IDN gTLD "机器人" is a purpose-driven generic top-level domain created to serve the global robotics industry, with special relevance to Chinese-speaking communities worldwide. Its mission is to provide a trusted, secure, and intuitive namespace that hosts authoritative interfaces for robotic product management, monitoring, and consumer interaction. Through recognizable domains such as brand.机器人, users gain a secure, authenticated entry point to official control dashboards, teleoperation management portals, over-the-air (OTA) firmware updates, and customer support ecosystems, thereby enhancing operational safety, user satisfaction, and brand loyalty. Target Registrants The 机器人 TLD is intended exclusively for entities within the robotics ecosystem. Eligible registrants include industrial robot manufacturers, collaborative robot (cobot) producers, service robot companies, robotics software and platform developers, system integrators, Robot-as-a-Service providers, and accredited research institutions. Target Users Primary users are robot operators, fleet managers, maintenance engineers, and end consumers who interact with robotic systems in daily life. By navigating through a 机器人 domain, users can securely access real-time status monitoring portals, remote diagnostics interfaces, centralized management systems, and service scheduling platforms. Secondary users include procurement officers and business partners who rely on the 机器人 TLD to identify authentic robotics vendors, reducing risks from counterfeit or unsafe products in Chinese-speaking markets. Activities to Fulfill the Mission 1. Eligibility Verification: Enforce strict registration policies requiring comprehensive proof of robotics industry involvement prior to domain allocation to eliminate speculative or malicious registrations. 2. Awareness Campaigns: Partner with leading robotics associations, international trade exhibitions, and Chinese-language tech media to promote 机器人 as the definitive online identity standard for the sector. 3. Security Guidance: Provide best-practice technical documentation for DNSSEC implementation, TLS encryption, and anti-phishing measures tailored to web-based remote robot management, including 5G and cloud robotics scenarios. Long-Term Sustainability The 机器人 TLD is fundamentally rooted in strong, secular global trends: the international robotics market is expanding exponentially, with China establishing itself as the world's largest consumer and manufacturing hub. Simultaneously, the deployment of 5G, edge AI, and digital twin technologies has made remote fleet management and teleoperation an absolute operational necessity. As robotic systems proliferate across manufacturing, logistics, healthcare, and domestic environments, the systemic risk of DNS spoofing, hijacking, or phishing targeting robot control interfaces intensifies severely, presenting unique threats that could directly result in physical harm or operational sabotage. A dedicated, certified 机器人 namespace acts as a critical cyber-physical authenticity anchor, ensuring that end-users, engineers, and automated platforms connect exclusively to authorized devices and verified corporate infrastructure. Steady, predictable registration and renewal revenues generated from a global pool of commercial robotics stakeholders will continuously and robustly fund long-term core operations, including proactive registry-level security enhancements, ongoing compliance policy updates, and global marketing outreach. Based in Hong Kong and leveraging deep, systemic ties to worldwide Chinese-speaking tech communities, the registry operator will remain highly agile, keeping pace with rapid technological evolutions while preserving cultural and linguistic relevance. This ensures that the gTLD stabilizes its financial and operational viability over the long term.
Section: Variant String(s)
This question set collects basic information regarding any variants of the primary string (AGB Question Set 5) that are being applied for. Loop over multiple variant strings if the string has multiple variant strings.
xn--gmqz0qc4r
機器人
U+6A5F U+5668 U+4EBA
Provide the script of the variant string (both in English and as referenced by the RZ-LGR/ISO 15924)
Chinese (Han)
Select an option.
New TLD
Provide the meaning or intended meaning (for non-dictionary words) of each of the applied-for variant string(s), including sources. If there is no literal meaning in English (for example, a brand name or a proper noun without a translation) simply state "no English Translation/Meaning".
“機器人” is the standard traditional‑Chinese character form for "robot". In our opinion, the string literally represents an intelligent robotic system, automation platform, or device.
Provide at least three bona-fide examples to support the explanation. (for example, evidence of trademark use by showing real world use cases).
Linguistic Equivalence & Community Perception The primary applied-for string “机器人” (Simplified Chinese) and the variant string “機器人” (Traditional Chinese) are orthographically and semantically identical. They represent the exact same lexical word meaning "robot" across all Chinese-speaking communities worldwide (including Mainland China, Taiwan, Hong Kong, Macao, Singapore, and global Chinese diaspora). In Chinese orthography, the character “机” is the simplified equivalent of the traditional character “機”, while “器” and “人” are identical (or standardized orthographic variants) in both scripts. Chinese internet users naturally recognize “机器人” and “機器人” as two script variations of the same underlying term. To avoid user confusion, phishing, and fragmentation of the internet, Chinese-speaking users expect both strings to be bound together as variants. Furthermore, this relationship is formalized under the ICANN Root Zone Label Generation Rules (RZ-LGR) for the Chinese Script as well as RFC 3743 (Joint Engineering Terms for IDN), where “机” and “機” are officially defined as allocatable/blocked variants of one another. Bona-Fide Examples Supporting Script & Semantic Equivalence: 1. Domain Name Registry IDN Rules (CNNIC & TWNIC): Domain registries servicing Chinese-speaking communities (e.g., CNNIC for .cn and TWNIC for .tw) enforce automatic variant mapping rules. When a domain containing 机器人 is registered in Simplified Chinese, the corresponding Traditional Chinese string 機器人 is automatically bundled/reserved for the same registrant. This real-world registry practice demonstrates that the domain industry and user communities treat them as the exact same string. 2. Cross-Regional Brand & Commercial Usage (e.g., Tesla / Sony / Xiaomi): Global technological enterprises market the same products using both script forms based on target geography. For instance, Tesla's humanoid robot ("Optimus") is branded as “Tesla 人形机器人” in Simplified Chinese channels (Mainland China) and as “Tesla 人形機器人” in Traditional Chinese channels (Taiwan and Hong Kong). Both terms refer to the identical commercial product and entity without any change in meaning. 3. Search Engine & Knowledge Base Script Equivalency (Google, Baidu, Wikipedia): Major search engines (Google, Baidu) and universal reference platforms (Wikipedia) treat 机器人 and 機器人 as fully equivalent keywords. A query for 機器人 on Google automatically yields indexed results containing 机器人 without loss of relevance. Similarly, Wikipedia maintains a single unified article entry with real-time automatic script conversion (zh.wikipedia.org/wiki/机器人 ⇄ zh.wikipedia.org/wiki/機器人), confirming that the global internet community considers them semantically inseparable.
1. Applying entities shall explain why one label is insufficient and two or more labels are necessary to satisfy regional, linguistic, or cultural drivers. 2. Identify the user communities served by primary and for each of the variant TLDs. 3. How are these user community needs reflected by differences or similarities in the design of the IDN tables offered for the primary and the each variant TLD.
1. Necessity of Both Labels (Linguistic, Cultural, and Regional Drivers) A single label is insufficient to serve the global Chinese-speaking population due to the dual-script nature of the Chinese language system, which comprises Simplified Chinese (SC) and Traditional Chinese (TC). • Linguistic & Cultural Drivers: SC and TC are two official orthographic standards representing the same language. "机器人" (SC) and "機器人" (TC) are semantically identical ("robot"). Restricting the TLD to a single script would exclude or inconvenience millions of users who exclusively use the other script in their daily, education, and business communications. • User Experience & Safety Drivers: Forcing Traditional Chinese users to input Simplified Chinese (or vice versa) creates artificial navigational friction, keyboard input barriers, and brand confusion. Furthermore, delegating only one script creates security vulnerabilities, such as phishing and cybersquatting risks, if the unallocated variant is exploited by unauthorized third parties. Offering both labels as a bundled pair ensures universal accessibility, cultural respect, and internet security. 2. User Communities Served The introduction of both the primary and variant TLDs serves distinct yet overlapping user communities across the global Chinese diaspora: • Primary String (“机器人” - Simplified Chinese): o Primary Community: Internet users, enterprises, and institutions in Mainland China, Singapore, and Malaysia where Simplified Chinese is the official and predominant writing system. o Reach: Approximately 1.4+ billion native Chinese speakers. • Variant String (“機器人” - Traditional Chinese): o Primary Community: Internet users, enterprises, and institutions in Taiwan, Hong Kong, Macao, and traditional overseas Chinese communities (e.g., North America, Europe, Australia) where Traditional Chinese is the primary script. o Reach: Over 30+ million native Chinese speakers and global diaspora. • Global Robotics & AI Ecosystem (Unified Community): o AI research institutes, robotics manufacturers, automation industries, and tech consumers worldwide who require seamless cross-border identity and multilingual accessibility across both Chinese-speaking regions. 3. IDN Table Design and Synchronization Across TLDs To reflect and safeguard the needs of these user communities, the IDN tables for both the primary string (“机器人”) and the variant string (“機器人”) are designed with total structural alignment and technical consistency: • LGR Compliance: Both IDN tables strictly adhere to the ICANN Root Zone Label Generation Rules for the Chinese Script (RZ-LGR) and the RFC 3743 (Joint Engineering Terms for IDN) framework. • Symmetric Character Mapping: The IDN tables incorporate identical 1:1 character mapping rules (e.g., mapping "机" [U+673A] symmetrically to "機" [U+6A5F]). • Synchronized Registration Policies: Any second-level domain (SLD) registered under “机器人” will automatically trigger identical variant processing (bundling, blocking, or mirrored allocation) under “機器人” according to the registry's IDN table rules. • User Benefit: This mirror-image IDN table design guarantees that regardless of which script a user types or which TLD they navigate to, the registration behavior, domain resolution, and security policies remain completely uniform across both strings, preventing user fragmentation and spoofing.
Provide steps and descriptions that adequately demonstrate all defined criteria are met. See Section 7.6 Variant String Evaluation and Section 3.1.9.2.1 Application Submission of New Primary IDN and its Variant Strings. Notes: Commitments made by an applicant to minimize the noted operational and management complexities will form the basis of contractual requirements to be included in the applicable Registry Agreement.
To minimize operational and management complexities for Registrars, Resellers, and Registrants arising from the introduction of the primary TLD “.机器人” and its variant TLD “.機器人”, the Applicant will implement an integrated, automated, and synchronized Registry Architecture. Both TLDs will be operated as a unified "Variant TLD Set" managed through a single Shared Registration System (SRS) back-end platform. The applying entity commits to the following concrete steps: Step 1: Unified Registry-Registrar Integration • Single Registry-Registrar Agreement (RRA): Registrars will sign a single, consolidated RRA covering both .机器人 and .機器人. Registrars will not be required to undergo separate accreditation, legal, or administrative processes for each TLD. • Automated EPP Variant Mapping: The Registry SRS will deploy standardized EPP extensions (compliant with ICANN IDN Variant guidelines and RFC 3743/4290 frameworks). When a Registrar issues a command (e.g., check, create, renew, transfer, or delete) for a label under .机器人, the SRS will automatically evaluate and process the corresponding variant under .機器人 within the same transaction. • Simplified Billing and Pricing: To eliminate accounting complexity, the Registry will offer a "Bundled Pricing Model". A single fee will cover the allocation and renewal of the primary string and its variant. Registrars will manage a single financial account for both TLDs, eliminating duplicate invoicing, balance tracking, or currency reconciliation friction. Step 2: Automated DNS & Lifecycle Synchronization • Single Registrant Ownership (Mandatory Bundling): Second-Level Domains (SLDs) across the variant TLD set will be strictly tied to a single Registrant Contact ID. A variant SLD under .機器人 cannot be registered by, transferred to, or owned by a party different from the holder of the corresponding SLD under .机器人. • Atomic Lifecycle Operations: All domain lifecycle events will be processed atomically across both TLDs: o Registration/Renewal: Registering or renewing example.机器人 automatically registers or renews example.機器人 for the same term. o Transfer & Update: Updating registrant contact details or transferring a domain automatically applies to all mapped variants in the set simultaneously. o Deletion/Expiration: Domain grace periods, redemption states, and pending deletions will execute concurrently across the variant set to prevent asynchronous domain hijacking. • Automated Name Server Mirroring: To eliminate DNS configuration complexity for registrants, update of NS records or DNSSEC parameters on the primary domain will automatically mirror to the variant domain zone file, ensuring consistent technical resolution without manual duplicate setup. Step 3: Streamlined Dispute Resolution & Rights Protection • Unified Rights Protection Mechanisms: Sunrise periods, Trademark Claims services, UDRP, and URS procedures will apply to the primary and variant SLD set as a single subject. A trademark owner filing a dispute against example.机器人 will automatically cover example.機器人, reducing legal costs and administrative burden for brand owners and registrants. • Consolidated RDAP Services: The Registry’s RDAP output for any domain will clearly display and link its active variant SLDs, providing full transparency to the public, law enforcement, and registrars regarding the unified ownership status. Step 4: Registrar Technical Enablement and Support • OT&E Testing Environment: The Registry will provide an OT&E environment with pre-configured variant test cases to allow Registrars and Resellers to seamlessly validate their front-end interfaces before public launch. • Comprehensive Technical Documentation & SDKs: Standardized API documentation and sample EPP client codes will be distributed to all accredited Registrars to minimize technical integration costs and ramp-up time.
Confirm the statement using the checkbox.
true
Section: Safeguard Identification
This question set collects information related to determining whether certain Safeguard Public Interest Commitments (Safeguard PICs) are required for the applied-for gTLD string. See Section 7.8.2.3 Safeguard PICs. Answers to these questions will inform assessment by ICANN on whether and which Safeguard PICs must be incorporated in the applicable Registry Agreement (RA) if the string proceeds to delegation. The answers themselves will not automatically make such a determination.
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
Yes
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
Yes
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. I-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. I-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
Select Yes or No. Notes: 1. ICANN will evaluate whether an applied-for gTLD string requires one or more Safeguard Public Interest Commitments (Safeguard PICs) to be included in the Base RA). 2. In addition to the Mandatory Public Interest Commitments (PICs) that must be included in each Base RA, a subset of Base RAs must include Safeguard PICs based on ICANN’s Safeguard Assessment. See Section 7.8.2.3 Safeguard PICs. 3. Applying entities for TLDs that are not found to require Safeguard PICs can elect to add them to the applicable Base RAs voluntarily to, for example, further their business objectives, help address issues or concerns that are raised or could be raised with respect to their applications, or avoid the need for the evaluation and implementation of customized Registry Voluntary Commitment (RVC). See Section 7.8.3 Registry Voluntary Commitments (RVCs).
No
Section: Registry Voluntary Commitments (RVCs)
This question set collects information related to any Registry Voluntary Commitments (RVCs) that the applying entity is submitting. The decision to submit an RVC is typically voluntary, except for those recognized by ICANN to resolve an objection or to address GAC Consensus Advice. See Section 7.8.3 Registry Voluntary Commitments for more information.
1. Select Yes or No. 2. In addition to Safeguard Public Interest Commitments (PICs), an applying entity will be permitted to propose one or more Registry Voluntary Commitments (RVCs) to provide additional safeguards with regard to the registry operator’s operation of an applied-for gTLD string. See Section 7.8.3 Registry Voluntary Commitments (RVCs). 3. RVCs are separate from Community Registration Policies. See Section 7.8.3 Registry Voluntary Commitments (RVCs) and Section 7.8.4 Community Registration Policies for more information. If you are applying for a Community gTLD, please submit the Community Registration Policies by answering Questions 150-155. However, if you propose to include additional Registry Voluntary Commitments in the RA beyond the Community Registration Policies, you may answer "yes" and proceed to answer the following questions. 4. You are encouraged to consider whether there are other means, separate from including commitment(s) in the Base RA, that could be used to further your business objectives or help resolve any anticipated or actual issue(s) raised regarding the applied-for gTLD string or application. See Section 7.8.3 Registry Voluntary Commitments (RVCs). Notes: If you select “yes” to this question, you are required to pay the conditional Registry Commitments Evaluation fee, and commitments that are approved by ICANN will be included in Specification 11 of the applicable Base RA as specific voluntary public interest commitments as contractual obligations.
No
Section: Brand & Code of Conduct Exemptions
This question set collects information related to whether the applied-for gTLD string is a .Brand (see Section 7.3) or if the applying entity is seeking a Code of Conduct exemption (see Section 7.4).
Select Yes or No
No
This serves as an indication of intent to apply for an exemption to Specification 9 and that the applying entity is NOT requesting to be designated a .Brand TLD, pursuant to Specification 13.
No
Section: Additional Information and Supporting Materials
This question set collects any additional information that the applying entity would like to provide, including any supporting materials.
Section: Bona Fide Intent and Prohibited Communications
This question set contains attestations related to the applying entity’s acknowledgment of bona fide intent and prohibited communications.
Confirm the statement using the checkbox.
true
Confirm the statement using the checkbox.
true