Last published on: 7 October 2026 at 15:32 UTC
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.
Te Kāhui Raraunga Charitable Trust
Provide the name under which the applying entity is doing business, if different from the full legal name answered in Question 1. Such a name must be registered with appropriate local jurisdiction or public authority.
Te Kāhui Raraunga
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.
Te Kāhui Raraunga Charitable Trust
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.
New Zealand
Provide the website URL of the applying entity, if available.
https://www.kahuiraraunga.io/
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).
false
Choose Yes or No.
false
64
Provide the primary business phone number without including the country code.
220 715 531
Provide the primary business email address of the applying entity.
Admin@kahuiraraunga.io
Enter the street address (no PO Box).
Level 2
1172 Haupapa Street
Enter the city, village, municipality, etc.
Rotorua
Enter the state, province, department, territory, prefecture, oblast, etc., if applicable.
Bay of Plenty
1. Enter the postal code, if applicable. 2. If a postal code does not exist, type “Not Applicable”.
3010
NZ
This question set collects information related to the individuals who will have access to TAMS, manage the application, and receive inquiries.
Stanley Rahui Papa, Tekou Rikirangi Gage, Liana Poutu
Provide a single document for Self-Certification question Q4.2-1. The document must include only the SC4.2-1.1, SC4.2-1.2, or SC4.2-1.3 statements. Do not modify any of the Self-Certification statements.
1. Provide a single document for Self-Certification question Q4.2-1. 2. The document must include only the SC4.2-1.1 through SC4.2-1.3 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC4.2-1.1 through SC4.2-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC4.2-1.1 through SC4.2-1.3 statements.
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.
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.
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.
aio
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"
aio meaning Ancestral Intelligence Offering - the offering of knowledge from one's ancestors. Representing indigenous belief systems and values; it’s an inherited consciousness that provides ultimate wellbeing for all species. Aio means peace in English
If an IDN, provide the script of the string (both in English and as referenced by the RZ-LGR/ISO 15924)
Latin
Provide a representation of the string according to the International Phonetic Alphabet.
ə aɪ əʊ
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.
Te Kāhui Raraunga Charitable Trust (TKR) established in 2019, is an indigenous peoples mandated representative organisation of over 85 iwi-Māori (approximate population 800,000). TKR is entrusted to advocate for indigenous data rights and progress indigenous data practices. TKR recognise that our goals are not unique to our context but part of the wider global Indigenous Peoples pursuit for self-determination. Indigenous Peoples make up approximately 6.2% of the global population including 90 countries, 5000 cultures and 6000 Indigenous languages with 1500 of those at risk. One of the greatest challenges faced by our community is access to the Internet acknowledged by The United Nations in their UN Agenda for Sustainable Development. They aim to close the digital divide by 2030. Given the colonial impacts on Indigenous Peoples across the globe, there is a lack of trust in digital ventures that are not Indigenous-led or regulated. The .aio TLD is an opportunity to create a trusted space, have a presence and share, with appropriate care and protections, knowledge and information including ancestral knowledge. .aio is an acronym for Ancestral Intelligence Offering. Indigenous Peoples are stewards and custodians of the natural world. Indigenous peoples share the belief that knowledge is handed down through generations and kinship. This includes connections to and with the natural world. This responsibility is a common thread of connection across Indigenous Peoples (The .aio Community) globally and forms a central component to a shared worldview, belief systems and values; celebrating and uniting indigeneity worldwide, since time immemorial. Aio is also an Indigenous Māori word for peace and tranquility. Peace in this sense is also a destination. From an Indigenous worldview if the planet is in a state of peace, it must be in a state of harmony; where all humans and the natural world are in absolute balance. Given the climate, economic and technological challenges the world is currently faced with, it is becoming increasingly understood that Indigenous knowledge can emancipate the globe from these pressures in pursuit of absolute peace and balance for all nations, and all environments. TKR recognises that there is value in enabling Indigenous Peoples and their communities, nations and tribes by providing a trusted, clear, and identifiable .aio mark to assert Indigenous self-determination; recognise Indigenous data sovereignty principles to protect Indigenous rights, heritage and aspirations, underpinned by sustainable models of Indigenous governance. This includes the elevation of Indigenous ways of being, dedicated to bringing trust, equity and peace to Indigenous wellbeing. Across the Internet and its digital ecosystem universally, this is yet to be realised. TKR respects the self-defining and self-organising mechanisms of Indigenous Peoples. The development of an Indigenous Peoples’ Data Trust as an overarching governance body will ensure credibility, equity and access, underpinned by the CARE Principles, promoting collective benefit, authority to control, responsibility and ethics honouring Indigenous rights. The CARE Principles are foundational to achieving and sustaining the intentions of the .aio TLD. The Data Sovereignty for self-determination of Indigenous Peoples’ honouring ancestral intelligence community (The .aio Community) is longstanding with over 30 years of established and committed global efforts. The .aio TLD is an extension and advancement of this collective movement intended for Indigenous Peoples to assert their self-determination and other value-aligned Peoples who wish to join our efforts in progressing Indigenous data rights, practices and wellbeing. The Indigenous Peoples’ Data Trust will be a self-organised governance group to ensure credibility and access to .aio Community, accountability with the policy settings and upholding the CARE Principles for Indigenous data governance.
This question set collects information specific to Community gTLDs. However, question 133 (Mission & Purpose) must be answered by all applying entities.
Yes
1. Provide the name of the community that the applying entity is committing to serve. 2. Describe the distinct aspects of the community.
Data Sovereignty for Self-Determination of Indigenous Peoples’ Honouring Ancestral Intelligence.
Enter a category that best describes your community. Some examples of community categories could include, but are not limited to: activity-based and volunteer groups, online or social media groups, religious or political groups, diasporic communities, linguistic communities, celebrity or sports team supporters.
The Data Sovereignty for self-determination of Indigenous Peoples’ honouring ancestral intelligence Community (The .aio Community) is categorised as advocating and supporting indigenous data sovereignty for self-determination. This includes the well-being of indigenous peoples and the natural world we live in, advocating for indigenous peoples to assert their rights across all spaces, including data collection, provenance, access, use, management and dissemination, and led by indigenous worldviews, which connects peoples and honours ancestral intelligences. It Includes; (a) Indigenous representative or governance bodies; (b) Indigenous community-based, cultural, educational or service organisations; (c) Indigenous community-benefitting service organisations, projects or enterprises; and (d) individuals and organisations with a genuine and demonstrable connection to the .aio TLD Community. Indigenous Data Sovereignty Indigenous data sovereignty reinforces the rights of indigenous peoples to engage in decision-making in accordance with their indigenous values and collective interests. Data have important implications for Indigenous Peoples’ ability to exercise their individual and collective rights for self-determination. Indigenous Peoples are often excluded from decision-making fora and their knowledge marginalised when such knowledge exists only as part of an oral tradition. The UN Declaration on the Rights of Indigenous Peoples (UNDRIP) affirms Indigenous Peoples’ rights to self-governance and authority to control their Indigenous cultural heritage embedded in their languages, knowledge, practices, technologies, natural resources, and territories (including Indigenous data). Indigenous data, includes data about indigenous peoples and about the natural world indigenous peoples connect to, it includes data collected by indigenous peoples, data collected by others including governments and institutions about Indigenous Peoples and their territories, and are intrinsic to Indigenous Peoples’ capacity and capability to realise their human rights and responsibilities to all of creation. The CARE Principles for Indigenous Data Governance developed by GIDA in 2019 are people and purpose-oriented, reflecting the crucial role of data in advancing Indigenous innovation and self-determination. These principles are an alternative to the existing FAIR principles encouraging data movements to consider both people and purpose in their advocacy and pursuits. The CARE principles promote collective benefit, authority to control, responsibility and ethics. The CARE principles align to the values of TKR of whakapapa (genealogy), aroha (love) and manaaki (care) and together enable and support the practical expression of indigenous worldviews. The Data Sovereignty for self-determination of Indigenous Peoples’ honouring ancestral intelligence Community is categorised as a community that develops and progresses Indigenous data sovereignty for self-determination.
Describe and provide evidence of the relationship between the applying entity and the identified community.
Te Kāhui Raraunga Charitable Trust (TKR) established in 2019, is an indigenous peoples and mandated representative organisation of over 85 iwi-Māori (approximate population 800,000). TKR is entrusted to advocate for indigenous data rights and progress Indigenous data practices. TKR recognise that our goals are not unique to our context but part of the wider global Indigenous Peoples pursuit for self-determination. TKR has been advocating for Māori data governance and Māori data sovereignty rights well-before its formal establishment. It is a regular contributor, leader, collaborator, participant and trusted advocate across the indigenous data eco-system worldwide. This includes capability and capacity programme development, publishing resources and training materials, submitting or providing policy advice and developing bespoke solutions for indigenous communities. Applying for the .aio TLD on behalf of our Community is an extension of TKR’s advocacy and goal to further embed indigenous ways of thinking, knowing and doing into layers of the internet to give expression to Indigenous Data Sovereignty for self-determination. Operationally we envisage establishing a global Indigenous Peoples’ ‘Data Trust’ as a governance model to support activities such as a reserved list of domain names for Indigenous Peoples (communities, nations, tribes, commerce, environment etc.). The CARE principles act as a pre-requisite and filter in pre-registration of all domain names. Advocacy for Indigenous data governance and sovereignty rights and interests is growing worldwide and Indigenous Peoples are active in their communities, nations and tribes across a highly collaborative and participatory environment. One key component to the monitoring and protection approach that the Indigenous Data Peoples’ Trust will ensure is to recognize that Indigenous Peoples are self-organizing and support how the .aio TLD can advance their aspirations across society; cultural, socio-economic, political, environment, technology and commercial needs. It is through an ancestral approach to organizing ourselves that will also show the unique governance model to be established recognizing the provenance and prominence of each of our respective stories, and kinship to our data. TKR is a member of the Global Indigenous Data Alliance (GIDA) that is an international network that advances Indigenous data sovereignty and governance, asserts Indigenous Peoples rights and interests in data, advocates for data for the self-determined wellbeing of Indigenous Peoples and reinforces the rights to engage in decision-making in accordance with Indigenous values and collective interests. The three attachments provide evidence of our connection as TKR and relationship to the Community we are part of and serve. Refer: - Connection to Community: TKR_Speaking Engagements_19Jul26.pdf - Map of network and tribal nations: TKR_IDSov Global Network Map_11Aug26.pdf - List of networks: TKR_Indigenous_Data_Sovereignty_Networks_and_Tribal_Nations_11Aug26
Describe and provide evidence related to the community organization, any relevant organizing bodies, and any relevant leaders within the community.
Indigenous self-definition centres on a deep, continuous connection to ancestral knowledge and lands predating colonisation. Indigenous peoples define themselves through specific tribal names, genealogical ties to family and homelands, creation stories, and a collective will to protect their unique cultures and distinct societies centred on their natural environments. Self-identification is a core pillar of indigeneity and self-determination. The core elements of Indigenous Self-Definition are acknowledged by international frameworks, such as those discussed by the United Nations Permanent Forum on Indigenous Issues, stating that Indigenous communities possess the inherent right to define their own identities. Key aspects of how Indigenous individuals and groups express this identity include: Genealogy and Kinship, Land and Creation, Cultural Distinctiveness and Self-Determination. The .aio Community is founded on self-identification, and this includes its organisation. Various topics and issues that are presented to the .aio Community are voiced and acknowledged as they appear and form focal points of discussion and forums to collectivise efforts and address challenges. Such efforts include international-led initiatives as well as localised and or regional lead work. They include self-organising bodies built on high trust, value alignment, and a connection to indigeneity. While there is no single organising body. The community are united by their experiences and historical impacts on their indigeneity. The .aio Community is self-administrative and is represented by its self-defining processes and ancestral heritage. Today, there are multiple organisations that support the Community, with three prominent organisations paving the way; i) First Nations Information Governance Centre (FNIGC), established in 2009 with a mandate from the Assembly of First Nations’ Chiefs-in-Assembly to strengthen First Nations data sovereignty in Canada in alignment with their distinct worldview. FNIGC support the First Nations Data Governance Strategy and steward the First Nations Principles of OCAP®; ownership, control, access and possession of First nations information by First Nations. CEO Jonathan Dewar and FNIGC have provided their support for this TLD application in the attached Letter of Support. ii) Local Contexts, established in 2010, is a non-profit with global reach in indigenous communities across Aotearoa New Zealand, Australia, Canada, the Cook Islands, Colombia, Ecuador, French Polynesia, Guatemala, Sierra Leone, and the United States. It supports indigenous data sovereignty and cultural authority providing training, resources and tools to communities, nations and tribes. Executive Director Hop Hopkins and Local Contexts have endorsed this TLD application in the attached Letter of Support. iii) the Global Indigenous Data Alliance (GIDA), established in 2019 is an international leader in Indigenous Data Sovereignty; a global network of regional and nation state-based Indigenous Data Sovereignty networks and collectives. Through the GIDA biannual conferences, opportunities for knowledge sharing, policy advocacy and collaboration on statements and topics of interest affecting indigenous data governance and data sovereignty. Chair of the Executive Committee, Stephanie Russo Carroll and GIDA have endorsed this TLD application in the attached Letter of Support. The three attachments provide evidence of these organisations and their advocacy of indigenous data governance and indigenous data sovereignty rights for self-determination and support for this TLD application. Refer: - FNIGC, TKR_Letter of Support_FNIGC_22Jul26.pdf - Local Contexts, TKR_Letter of Support_Local Contexts_01Aug26.pdf - GIDA, TKR_Letter of Support_GIDA_03Aug26.pdf
1. Describe any formal membership process, if there is one. 2. If there is no formal membership process, provide evidence related to how an individual can join the identified community (i.e., “self-identify” as a community member).
There is no formal membership process, members will self-identify into one of the following four categories within the community named in Q132: a) Indigenous representative or governance bodies b) Indigenous community-based, cultural, educational or service organisations c) Indigenous community-benefitting, service organisations, projects or enterprises d) Individuals and organisations with a genuine and demonstrable connection to members of categories A through C. Example evidence for self-identifying members of the above categories could include but is not limited to: proof of standing, recognition, mandate, registration documents, a trust deed, constitution, an endorsement, support letter, a form of confirmation from a recognised representative body or agreed community authority, supporting evidence from a recognised representative body, adviser, partner, or other relevant source. This approach leverages existing high-trust models of self-identification across the indigenous data sovereignty network today such as event and conference participation, collaborations, and research. This is also in accordance with UNDRIP, the right for indigenous peoples striving for recognition of indigenous identities, their ways of life, their right to traditional lands, territories, natural resources, including their data. Members can join the Community by exercising their right to self-determination and their active participation.
Provide the primary location of the community.
Te Kahui Raraunga Charitable Trust (TKR), the steward of .aio TLD is based in Aotearoa, New Zealand. It is one location of many communities, nations and tribes across the world (Canada, USA, Sth America, Australia, NZ, northern Europe, Asia).
1. Provide the estimated size of the community. The size should be in number format (e.g., “1,000,000 members”). 2. If the community is divided by group, region, sector, etc., this should include estimated size for each group.
120,442. This is a minimum of the international network of networks of indigenous nations, collectives, businesses and individuals. With 476M indigenous peoples, our Community includes Canada, USA, Sth America, Australia, NZ, northern Europe, Asia.
Provide the estimated size of the community that is administered or represented by each relevant organizing body in the identified community.
A high proportion of existing indigenous data sovereignty networks. An estimated community size of 13 regions, 10 nations, 7 US federal state, 85 tribes, 350+ member collectives, organisations, individuals and un-recognized tribes, and peoples.
1. Provide evidence of any documented practices of community efforts to date 2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: a) Offering support; b) Sharing information; c) Responding to specific community needs; d) Fostering and strengthening relationships within the community.
Our community is founded on active and consistent efforts to engage and connect with The Data Sovereignty for Self-Determination of Indigenous Peoples’ Honouring Ancestral Intelligence Community (The .aio Community). The .aio Community is significant because of its values underpinned by the CARE Principles. These principles, together with the unique self-identification process of Indigenous Peoples, extend the community's efforts to potential members interested in joining. It is important to acknowledge that not all Indigenous Peoples are resourced to access, participate and lead and this, while being a disadvantage to our growing community, is an encouragement for our community aspirations to include all of the world's Indigenous Peoples. The .aio TLD presents that opportunity to create a safe space for our community to learn about resources, efforts and access to develop and or inform self-determination. Active and consistent efforts to engage and connect with not only our community but those yet to join are critical to the well-being of our practises as Indigenous Peoples. A unique part of many Indigenous Peoples is our uniqueness for sharing and retaining our ancestral knowledge offerings. It is through engagement that our connection to each other is strengthened and united. Such efforts include the self-organising groups, collectives, alliances and initiatives formed to create engagement on Indigenous challenges and/or opportunities. Te Kāhui Raraunga Charitable Trust (TKR) is a regular contributor, leader, collaborator, participant and trusted advocate across the indigenous data eco-system worldwide. This includes capability and capacity programme development, publishing resources and training materials, submitting or providing policy advice and developing bespoke solutions for indigenous communities. Evidence of examples demonstrating active and consistent efforts to engage and connect with the .aio Community are included as attachments. Refer: - Offering Support: Iwi Data Roadshows, TKR_Iwi Data Roadshow Pamphlet_p1_01Jul25 and TKR_Iwi Data Roadshow Pamphlet_p2_01Jul25 - Sharing Information: TKR Māori Data Governance Model, Te Kahui Raraunga_Maori Data Governance Model_2023 - Responding to Specific Community Needs: - GIDA IDGov and Universities, GIDA+Communique+IDGov+Universities_FINAL_2023 - Fostering and strengthening relationships with Community, TKR_Speaking Engagements_19Jul26.pdf.
1. Describe whether the applying entity has a role in any of the activities listed in Question 141. 2. If the applying entity does play a role, provide evidence of the applying entity’s role. If the applying entity does not play a role, describe why this is the case.
The evidence provided to support Question 141 includes a list of speaking engagements held across our community that were attended by representatives of TKR. On numerous occasions, TKR were invited to share and address topics at many of these events. This includes sharing capability and capacity programme development (Te Mana Whakatipu), knowledge sharing (GIDA IDSov and AI Workshop), publishing resources (Māori Data Governance Model and Māori AI Governance A Framework for Ethical Governance of AI) and developing bespoke solutions for indigenous communities (Te Pā Tūwatawata - Self-Sovereign Data Storage Network). The Global Indigenous Data Alliance (GIDA) for example is an international network of networks advancing Indigenous Data Sovereignty and Governance, asserting Indigenous Peoples rights and interests in data, advocating for data for the self-determined wellbeing of Indigenous Peoples, and reinforcing the rights to engage in decision-making in accordance with Indigenous values and collective interests. TKR has collaborated with GIDA member networks from Aotearoa New Zealand to the US Indigenous Data Sovereignty Network. GIDA considers Te Kāhui Raraunga to be a trusted partner, with the technical, governance, and relational skills that has been invited to share ancestral knowledge offerings in joint efforts to advance our community. TKR’s role is to be that trusted member of our community that helps lift and advance The Data Sovereignty for Self-Determination of Indigenous Peoples’ Honouring Ancestral Intelligence Community (The .aio community). Evidence of role of TKR in fostering and strengthening relationships and engagement with Community. Refer: - TKR_Speaking Engagements_19Jul26.pdf. - Māori AI Governance – A Framework for Ethical Governance of AI, TKR_AI Governance Framework 2025 - GIDA IDSov and AI workshop_Mexico_2026 - Te Pā Tūwatawata, TKR_Te Pa Tuwatawata Brochure_2026
1. Provide evidence that demonstrates that community members are aware of the identified community and the different member groups or segments within the identified community. 2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: a) Surveys conducted; b) Records of activities involving a diversity of community groups, segments, or members.
Yes. The Data Sovereignty for Self-Determination of Indigenous Peoples’ Honouring Ancestral Intelligence Community (The .aio Community) is aware of itself, members and the international network of networks that are part of the Community. Again, through self-defining processes, Indigenous Peoples will make themselves known and or participate in their own right. The use of surveys conflicts with Indigenous Peoples' rights to their own data and is not aligned with the CARE Principles. Our awareness of our own networks, members and broader relationships is maintained by active engagement, collaboration and attendance at events and or activities. The need to demonstrate membership and awareness of the community itself is not prescribed by official paperwork; rather, it is sustained through high trust, shared needs, interests, and active participation. The .aio Community aspires to include all Indigenous Peoples and/or value-aligned groups who want to join and require no permanent or official registration other than meeting the pre-registration requirements set out in the various policies described inQ151-Q155. The .aio Community is a growing one and will in time grow larger as more Indigenous Peoples become resourced and the world's population grows. The three attachments provide evidence that i) demonstrates that community members are aware of the identified community, the different member groups or segments within the identified community, ii) provide documentation of the following practices, which should have occurred within the two years leading up to application submission such as records of activities involving a diversity of community groups, segments, or members. Refer: - Map of network and tribal nations: TKR_IDSov Global Network Map_11Aug26 - List of networks: TKR_Indigenous_Data_Sovereignty_Networks_and_Tribal_Nations_11Aug26 - Connection to Community: TKR_Speaking Engagements_19Jul26.pdf
1. Provide evidence of community members’ awareness of the applying entity and its intent to apply for a community gTLD. 2. If there is no such evidence, explain why not.
Yes, the .aio Community members are aware that TKR is applying for a Community TLD. Letters of support from our .aio Community for the TLD application are attached. In addition to letters received, TKR has also received verbal support from across the Community. Refer: - TKR_2026 All Support Letters_ICANN Application_10Aug26
Provide evidence of the established presence of the community prior to the opening of the application submission period.
1. Provide evidence that demonstrates that individuals and groups outside of the community show an awareness of the identified community. 2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: a) Media or other public information regarding the community and its activities or members; b) Discussion of the community in various fora, whether online or in person; c) Evidence of partnerships or collaborations with groups outside of the identified community; d) Evidence of the chartering or organization of the community prior to the opening of the application submission window; e) Evidence of contributions (for example, cultural or scientific) to a larger society or population;
Yes, individuals and groups outside of the identified community are aware of the existence of the Community. Indigenous Peoples have many relationships with governments, state-like departments and/or leadership, organisational groups, companies, etc., that they interface with and/or connect with on various subjects and/or topics. Evidence includes; - TKR have two Mana Ōrite Relationship Agreements with New Zealand government agencies; Statistics New Zealand (30 October 2019) and the Department of Internal Affairs (22 June 2021). These Agreements are unique to TKR and are a pathway for continuous advocacy for indigenous data sovereignty for self-determination. Available online here: Refer: StatsNZ: https://www.kahuiraraunga.io/manaorite?lightbox=dataItem-llbq8hzi1 Refer: DIA: https://www.kahuiraraunga.io/manaorite?lightbox=dataItem-llbq9yxa1 - TKR Major Media releases, TKR_Ngā Pāpāho_TKR Major releases_07Jul26 - Discussion of the community as above. - Evidence of partnerships or collaborations with groups outside the identified community, TKR_Environmental impacts of hyper data centres_2026 and TKR_Speaking Engagements_19Jul26.pdf (ANZSOG Deputies Leadership Program, UNDP Global Flagship Event, Canterbury Tech Summit, CA ANZ IT, BIO AI, Embassy of Ireland, Genomic Standards Consortium).
1. Provide evidence of the longevity of the community. 2. The applying entity should provide documentation of the following practices which should have occurred within the two years leading up to application submission: a) Evidence of recurring or scheduled activities that demonstrate continuity over time; b) Documented records of past activities that demonstrate a long-standing tradition or practice; c) Records of discussions emphasizing the community’s enduring presence or its cultural significance.
The pursuits of The Data Sovereignty for Self-Determination of Indigenous Peoples’ Honouring Ancestral Intelligence Community (The .aio community) are enduring and sustainable as the issues, needs and challenges of Indigenous Peoples are long, enduring and self-identified. Accounting for 6.2% of the global population, recognition of Indigenous Peoples by UNDRIP, in the UN Sustainability Agenda 2030 and International Day of the World’s Indigenous Peoples on August 9th every year are indicators that indigenous peoples are recognised and through the United Nations, there is a permanent forum to raise issues of importance to indigenous peoples. Events of a recurring nature relating to indigenous data sovereignty include the Global Indigenous Data Sovereignty Conference - a biannual conference hosted by GIDA which marked 10 years at the most recent Conference in Ngunnawal and Ngambri Country (Canberra) Australia, 31March-3 April 2025. This was followed by an IDSov and AI workshop in Mexico 25-27 February 2026. TKR has participated in all conferences, events and workshops and is actively involved in a range of activities from facilitating masterclasses, to drafting communiques, knowledge sharing and strategic planning. Refer GIDA+Communiqué-+CARE+Directs+Us+Home-+Prioritizing+Indigenous+Peoples’+Community+Standards_2025 and GIDA IDSov and AI workshop_Mexico_2026. Upcoming events with an indigenous data sovereignty component include Indigenous Genomics Standards Consortium (Aug 2026), Ngā Pae o Te Māramatanga International Indigenous Research Conference (Nov 2026), IAPP ANZ Summit 2026 (Dec 2026) and Global Indigenous Data Sovereignty Conference (Feb 2027) to name a few. This community has existed to protect and advocate for Indigenous data rights and its needs are ever-growing and evolving. The .aio Community is an opportunity to safeguard Indigenous Peoples, their self-determination and their ancestral intelligence offerings. TKR has been actively involved as evidenced in the TKR_Speaking Engagements_19Jul26.pdf which documents involvement from 2023-2026. Indigenous Peoples have an enduring presence, and their cultural significance makes up their uniqueness as peoples. TKR’s collaborations are far reaching; whether with communities, nations, tribes and/or with global collectives, the letters of support from the .aio Community of indigenous peoples for this TLD application is testament to the confidence of indigenous peoples in the ability of TKR to continue to have an enduring presence, from promoting and advocating for indigenous data sovereignty for self-determination to managing a Community TLD and establishing an Indigenous Peoples’ Data Trust as a governance model for the TLD. Refer TKR_2026 All Support Letters_ICANN Application_10Aug26.
Explain how the applied-for string matches the name of the community or is a well-known alternative name (whether long or short form) of the community.
Yes. The .aio string references the acronym - Ancestral Intelligence Offering - in the Community name, Data Sovereignty for Self-Determination of Indigenous Peoples’ Honouring Ancestral Intelligence.
1. Explain how the applied-for string clearly relates to or represents the community 2. Explain whether the applied-for string has any other significant meaning beyond identifying the community or community members described in the application. The applying entity may wish to provide pertinent information regarding any particular geography, region, or themes that may be alluded to by the string, of which the community may or may not be a part.
Yes, when people read the .aio string, acronym (A.I.O) and its meaning (Ancestral Intelleigence Offering), there is a natural connection between the .aio string, the acronym and the Community name. Data Sovereignty for Self-Determination of Indigenous Peoples’ Honouring Ancestral Intelligence.
Select from Radio Buttons - Yes/No. Notes: 1. Community Registration Policies are conditions that community gTLD registry operators impose upon registrants within their gTLDs. 2. If you select “Yes” to this question, the applying entity is required to pay the conditional Registry Commitments Evaluation fee, and Community Registration Policies that are approved by ICANN will be scored in the CPE (if the applying entity elects to participate) and included in Specification 12 of the applicable Base RA. 3. If you select “No,” then the application cannot proceed as a community application.
Yes
1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA. 2. Enter a single proposed Community Registration Policy with respect to registrant eligibility in each response field. Up to 10 Community Registration Policies can be submitted. 3. Follow this format to propose what the Registry Operator must do and/or must not do: a) “Registry Operator shall___”; and/or b) “Registry Operator shall not___”. 4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars ,: a) "Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or b) "Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”. 5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements: a) "Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring ___"; and/or b) "Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting ___". 6. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example: a) Registry Operator shall develop and implement a registration eligibility policy and publish this policy on its website no later than the date on which the TLD is delegated in the DNS. b) Registry Operator shall review the registration policy described in (a) at least once per year, and publish the results of such review (including any updates to the registration policy) on its website within thirty (30) days following the anniversary of the Effective Date. 7. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a registrant eligibility restriction is time-limited, the applying entity must state if the restriction will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___). 8. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.
Registry Operator shall restrict registrations in the .aio TLD to applicants that satisfy at least one eligibility category stated in the Community Registration Policy. Registry Operator shall limit eligibility to: (a) Indigenous representative or governance bodies; (b) Indigenous community-based, cultural, educational or service organisations; (c) Indigenous community-benefitting service organisations, projects or enterprises; and (d) individuals and organisations with a genuine and demonstrable connection to the .aio TLD Community. Registry Operator shall publish the eligibility categories, required registration attestations and verification processes on its public website no later than the date on which the .aio TLD is delegated in the DNS. Registry Operator shall maintain an eligibility validation system under which every applicant must pass a pre-registration eligibility review before a domain name registration is activated. Registry Operator will include a provision in its Registry-Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring each applicant, at the time of registration, to select one eligibility category and provide a binding attestation that the applicant satisfies that category and that the registration and intended use of the domain name will comply with the Community Registration Policy. Registry Operator will include a provision in its Registry-Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring each applicant to provide sufficient information for Registry Operator or its nominee to determine the applicant’s eligibility and to acknowledge that Registry Operator or its nominee shall decline the application if the information provided is insufficient to establish eligibility. Registry Operator shall require each applicant to provide, at the point of registration, sufficient documentary evidence to establish that the applicant satisfies a published eligibility category and that the proposed registration complies with the Community Registration Policy. Registry Operator or its nominee shall validate each application before registration by reviewing the applicant’s selected eligibility category, attestation, registration data, documentary evidence and any supporting information requested for the review. Registry Operator shall not approve a registration unless the evidence provided establishes that the applicant satisfies the attested eligibility category. Registry Operator will include a provision in its Registry-Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring each registrant, throughout the registration term, to maintain accurate registrant data, respond to eligibility enquiries and provide supporting information when requested, and acknowledging that failure to re-establish eligibility is grounds for suspension, lock, transfer denial or deletion.
1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Base Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA. 2. Enter a single proposed Community Registration Policy with respect to name selection criteria or rules for the applied-for string in each response field. Up to 10 Community Registration Policies can be submitted. 3. These criteria or rules should align with the community objectives of the applied-for gTLD string. 4. Follow this format to propose what the Registry Operator must do and/or must not do: a) “Registry Operator shall___”; and/or b) “Registry Operator shall not___”. 5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars: a) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or b) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”. 6. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements: a) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring___""; and/or b) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting ___"". 7. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example: a) Registry Operator shall develop and implement a name selection rule and publish it on its website no later than the date on which the TLD is delegated in the DNS. b) Registry Operator shall review the name selection rule described in (a) at least once per year, and publish the results of such review (including any updates to the rule) on its website within thirty (30) days following the anniversary of the Effective Date. 8. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a name selection rule is time-limited, the applying entity must state if the rule will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___). 9. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.
Registry Operator shall require every second-level domain name registered in the .aio TLD to have a clear and reasonable connection to the registrant’s selected eligibility category or attested intended use. Registry Operator shall not permit registration of a domain name that implies authority, representation or affiliation that the registrant does not possess. Registry Operator shall maintain a Reserved and Restricted Names Policy and a Reserved and Restricted Names List covering names required to be reserved under ICANN requirements, names subject to legal restrictions, names of specific cultural significance or cultural sensitivity, and names identified under the policy as misleading, impersonating, offensive, abusive or inconsistent with the .aio TLD mission. Registry Operator shall publish its Name Selection Policy and Reserved and Restricted Names Policy on its public website no later than the date on which the .aio TLD is delegated in the DNS. Registry Operator will include a provision in its Registry-Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring each applicant, at the time of registration, to attest that the selected domain name complies with the Name Selection Policy and the Reserved and Restricted Names Policy. Registry Operator will include a provision in its Registry-Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring each registrant, on request, to provide information demonstrating the connection between the selected domain name and the registrant’s eligibility category or intended use. Registry Operator or its nominee shall examine, before allocation, each applied-for name that appears on the Reserved and Restricted Names List or otherwise matches the criteria specified in the published Name Selection Policy. Registry Operator shall approve a restricted name only where the applicant provides sufficient information to establish that the proposed registration satisfies the eligibility and name-selection requirements. Registry Operator shall investigate each credible complaint alleging that a domain name is misleading, impersonating, culturally harmful, inconsistent with the registrant’s attestations, or otherwise contrary to the published Name Selection Policy or Reserved and Restricted Names Policy. Registry Operator shall suspend, lock, delete or decline renewal of a domain name where the registrant fails to establish compliance with the published Name Selection Policy or Reserved and Restricted Names Policy.
1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA. 2. Enter a single proposed Community Registration Policy in each response field. Up to 10 Community Registration Policies can be submitted. 3. Follow the format to propose what the Registry Operator must do and/or must not do: a) “Registry Operator shall___”; and/or b) “Registry Operator shall not___”. 4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars: a) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or b) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”. 5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements: a) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring___""; and/or b) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting___"". 6. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example: a) Registry Operator shall develop and implement a Community Registration policy and publish this policy on its website no later than the date on which the TLD is delegated in the DNS. b) Registry Operator shall review the Community Registration Policy described in (a) at least once per year, and publish the results of such review (including any updates to the registration policy) on its website within thirty (30) days following the anniversary of the Effective Date. 7. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a commitment is time-limited, the applying entity must state if the rule will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___). 8. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.
Registry Operator shall require each domain name to be used in a manner consistent with the Community Registration Policy, the registrant’s selected eligibility category, the registrant’s attestation of intended use and the published Acceptable Use Policy. Registry Operator shall publish the Acceptable Use Policy on its public website no later than the date on which the .aio TLD is delegated in the DNS. Registry Operator will include the following provision in its Registry-Registrar Agreement: Registrar shall require each registrant to comply with the Community Registration Policy and Acceptable Use Policy throughout the registration term. Registry Operator will include a provision in its Registry-Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring registrants to maintain accurate contact information, use each registered domain consistently with the eligibility attestation and stated intended use, respond to compliance enquiries, cease prohibited use when notified, and acknowledge that breach of the Community Registration Policy or Acceptable Use Policy is grounds for suspension, lock, deletion, non-renewal or another proportionate enforcement response. Registry Operator shall operate a published complaints process covering DNS abuse, eligibility, name selection and acceptable-use concerns. Registry Operator shall acknowledge receipt of a complaint within five business days where the complainant provides contact details. Registry Operator shall provide the registrant not less than 14 calendar days to respond to notice of an alleged breach, unless immediate action is required to address DNS abuse, legal harm or material community harm. Registry Operator shall maintain records of complaints, investigations, determinations and enforcement actions for the applicable retention period specified in its privacy policy.
1. If you are proposing any limitation to a proposed Community Registration Policy in Questions 151-153, please provide a rationale in this response field. Please see Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria. 2. If you are not proposing any limitation to a proposed Community Registration Policy in Questions 151-153, please type ""Not Applicable"" in this response field.
The proposed .aio Community Registration Policies are limited in scope because .aio will operate a dedicated community namespace, rather than a general-purpose open top-level domain, and must apply its commitments in a practical, measurable and resource-conscious manner. The limitations proposed in Questions 151–153 are necessary to protect the mission of .aio. They recognise and seek to address challenges associated with administering the .aio namespace and its broad, globally diverse community membership. The limitations establish a framework for registration and use that supports the authority of .aio community members while remaining responsible, ethical, measurable and enforceable. The limitations reflect a deliberate decision by the .aio applicant, in consultation with prospective community members, to require evidence at the point of registration. The .aio applicant recognises that universal pre-registration validation may impose an additional administrative burden compared with a less restrictive post-registration validation model. The applicant has considered this risk, including the operational demands of the proposed approach. Prospective members of the .aio community have nevertheless expressed a firm preference for pre-registration validation, and the .aio applicant has adopted it as a core feature of this application. The proposed model requires every applicant to make a mandatory eligibility and use attestation and provide sufficient evidence before a domain name registration can be activated. It requires registrars to collect registrant information and flow down the required obligations. It also enables the .aio registry operator or its nominee—likely a dedicated, formally constituted Indigenous Peoples-led forum—to assess eligibility and name selection before registration. Tailored review will apply to restricted names within specified categories, including names of cultural significance or that are otherwise culturally sensitive. Complaint investigation and risk-based post-registration audits will remain available as supplementary safeguards. Acceptable-use compliance will be complaint-based, risk-based and evidence-based to avoid impractical content-monitoring obligations. Enforcement will focus on objective policy breaches, including impersonation, false claims of authority, material community harm and DNS abuse. These limitations are proportionate because they give effect to the community’s expressed preference for pre-registration validation while focusing validation, review, subsequent monitoring and compliance enforcement on evidence relevant to eligibility, name selection and intended use. The policies will apply for the life of the .aio TLD unless amended through ICANN-approved processes.
1. Provide an explanation of how the proposed Community Registration Policies meet the Registry Commitments Evaluation criteria 4 and 5 using the considerations in the Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria. 2. Consider whether the proposed Community Registration Policy could be argued to be duplicative of a requirement under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies. There may be circumstances in which a Community Registration Policy that would duplicate requirements under applicable consensus policy or law could be approved at ICANN’s sole discretion. If not duplicative, please explain why you believe the Community Registration Policy is not duplicative. If yes, please specify such a requirement and explain why you believe duplication in the Base RA is necessary. 3. Consider whether the proposed Community Registration Policy could be argued to be contrary to a requirement under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies. ICANN will not approve any Community Registration Policies that are found to be contrary to applicable laws, ICANN agreements and policies. Please share your views on this issue in the answer to this question. 4. Consider whether the proposed Community Registration Policy could be argued to be incompatible with ICANN’s Bylaws. ICANN will not approve any Community Registration Policies that are found to be incompatible with the ICANN Bylaws. See background at the ICANN Board resolution 2024.06.08.08-2024.06.08.10. Please share your views on this issue in the answer to this question. 5. Consider whether the proposed Community Registration Policy requires the operation of an additional Registry Service. The applying entity shall engage its selected RSP to discuss the implementation of such an additional Registry Service, which must be evaluated through the RSP Program and approved by ICANN.
The proposed .aio Community Registration Policies meet Registry Commitments Evaluation criteria 4 and 5 because they are specific, additional and operationally feasible. They are capable of enforcement through the Registry Agreement, the Registry-Registrar Agreement, Registrar Registration Agreements and the .aio published policies. The .aio Community Registration Policies are not duplicative of requirements under applicable law, ICANN agreements, ICANN Consensus Policies or Temporary Policies. ICANN’s baseline requirements address matters including registry operations, DNS abuse, registration data accuracy and registrar obligations, but they do not determine who is eligible to register a .aio domain name; how a .aio name must relate to the registrant or community purpose; or how .aio’s mission is protected through eligibility attestations, targeted review, complaint handling and audits. To the extent that a policy overlaps with DNS abuse or legal-compliance obligations, that overlap is necessary and appropriate because the policy applies those obligations in a TLD-specific community context and provides additional contractual consequences for conduct inconsistent with the .aio mission. The policies are not contrary to applicable law, ICANN agreements, ICANN Consensus Policies or Temporary Policies. They do not require registrars or registrants to act unlawfully, do not require discriminatory treatment, and do not require disclosure of information beyond what is reasonably necessary for eligibility verification, name selection and complaint handling. The policies are compatible with ICANN’s Bylaws and mission because they operate through aio’s domain name registration rules and registry compliance mechanisms. The .aio registry operator or nominee, rather than ICANN, will administer the eligibility, name-selection, acceptable-use, complaints and enforcement policies under published rules. The policies do not require ICANN to regulate website content or make subjective cultural determinations. ICANN’s role will be limited to enforcing commitments incorporated into the Registry Agreement. The policies do not require an additional Registry Service. They can be implemented using ordinary registry functions and compliance processes, including registrar flow-down commitments, EPP registration management, reserved-names administration, and industry-recognised abuse and compliance processes. The .aio registry operator can demonstrate compliance through publication of its policies, and retention of complaint and enforcement outcome . If the .aio applicant later proposes a new technical registry service outside the approved Registry Services, it shall engage its selected Registry Service Provider and obtain any evaluation or approval required by ICANN before implementation.
Please provide evidence of support for the applying entity’s application by attaching written endorsements from the organizing bodies relevant to the identified community (related to Question 136).
Te Kāhui Raraunga Charitable Trust (TKR) has support from across The Data Sovereignty for Self-Determination of Indigenous Peoples’ Honouring Ancestral Intelligence Community (The .aio community) to apply for and operate the .aio TLD from Aotearoa, New Zealand. Refer evidence in the letters of support attached. - Communities, Nations, Tribes, Global Collectives: TKR_2026 All Support Letters_ICANN Application_10Aug26. - Mandate and Authority through Data Iwi Leader’s Group of the National Iwi Chairs Forum: TKR_2026 RetaTautoko_TeHikuMedia_30Jul26.
Provide an explanation of why opposition may or may not be relevant or how the applying entity intends to address or resolve the opposition, if applicable.
No.
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.
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. 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
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
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
This question set collects any additional information that the applying entity would like to provide, including any supporting materials.
1. An applying entity may use this response field to submit any additional, optional information or documentation that the applying entity believes enhances understanding of its application or may be of interest to the general public. This could include, but is not limited to, the applying entity’s: a) Individual registry policies; b) Separate agreement with a third-party to fulfill certain commitments; c) Terms of use; d) Additional Community Registration Policies not intended for RA inclusion; e) Other materials that clarify the applying entity’s mission, values, or intended use of the gTLD. Notes: 1. This question is optional and for informational purposes only. 2. The information provided here will not be evaluated as part of the application, or be contractually binding on the applying entity. 3. All submissions to this question will be posted for the public to review and comment.
Additional supporting policy documents for this .aio TLD application include: -TKR Policy Suite Introduction and Full Policy - .AIO TLD Registration Policy_11Aug26 -TKR Policy Suite Introduction and Full Policy - .AIO TLD Reserved & Restricted Names Policy_11Aug26 -TKR Policy Suite Introduction and Full Policy - .AIO TLD Acceptable Use Policy_11Aug26 -TKR Policy Suite Introduction and Full Policy - .AIO TLD Internationalised Domain Name Policy_11Aug26 -TKR Policy Suite Introduction and Full Policy - .AIO TLD Launch Policy_11Aug26 One policy document not uploaded due to space constraints includes: -TKR Policy Suite Introduction and Full Policy - .AIO TLD Sunrise and Alternative Dispute Resolution Policy_11Aug26
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