Application Details
Last published on: 7 October 2026 at 15:34 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.
ORDRE DES AVOCATS COUR APPEL
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.
Barreau de Bordeaux
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.
Professional order
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.
France
Provide the website URL of the applying entity, if available.
https://www.barreau-bordeaux.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).
false
Choose Yes or No.
false
33
Provide the primary business phone number without including the country code.
556442076
Provide the primary business email address of the applying entity.
contact@barreau-bordeaux.com
Enter the street address (no PO Box).
Maison de l’Avocat - Ordre des Avocats de Bordeaux
1 rue de Cursol
Enter the city, village, municipality, etc.
BORDEAUX
Enter the state, province, department, territory, prefecture, oblast, etc., if applicable.
GIRONDE
1. Enter the postal code, if applicable. 2. If a postal code does not exist, type “Not Applicable”.
33000
FR
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.
Stéphane GUITARD, Marie TASTET
Stéphane GUITARD, Marie TASTET, Nicolas WEISSENBACHER
Section: Self-Certification
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.
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.
avocat
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"
attorney
Provide a representation of the string according to the International Phonetic Alphabet.
a.vɔ.kɑ
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.
See attachment 133 Mission and purpose of the applied-for gTLD
Section: Community
This question set collects information specific to Community gTLDs. However, question 133 (Mission & Purpose) must be answered by all applying entities.
General
Yes
1. Provide the name of the community that the applying entity is committing to serve. 2. Describe the distinct aspects of the community.
The .AVOCAT domain is intended exclusively for the community of attorneys registered with a French bar, as well as for professional entities linked to the legal profession: law firms, bar associations, unions, associations, and representative bodies.
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.
See attachment 134 categorize your community
Organization
Describe and provide evidence of the relationship between the applying entity and the identified community.
See attachment135 connection with community
Describe and provide evidence related to the community organization, any relevant organizing bodies, and any relevant leaders within the community.
See attachment 136 How is the community organized
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).
See attachment 137 membership requirements
Provide the primary location of the community.
The Communauté professionnelle des Avocats is present throughout French territory. Its members are registered on the Tableaux of the 164 Barreaux established within the jurisdiction of the French judicial courts.
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.
The Communauté professionnelle des Avocats comprises approximately 78,000 Avocats as a natural person in France and about 30,000 entities through which the Profession d’avocat is practised, distributed among the 164 Barreaux.
Provide the estimated size of the community that is administered or represented by each relevant organizing body in the identified community.
Each Ordre des Avocats represent Avocats registered in the Barreau they administer. The CNB, represents all the Avocats registered in France. Finally, the Conférence des Bâtonniers represents approximately 45,000 Avocats.
Engagement
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.
See attachment 141 efforts to engage with the community
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.
See attachment142 role of the applying entity in the engagement efforts
Awareness
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.
See attachment 143 community awareness
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.
See attachment 144 gTLD application awareness
Established Presence
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;
See attachment 146 outside awareness
Longevity
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.
See attachment 147 enduring and sustainability
Nexus
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.
See attachment 148 string match community
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.
See attachment 149 general public awareness
Community Registration Policy
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.
Community Registration Policy - Eligibility of Registrants The Registry Operator must reserve the registration of domain names in the “.AVOCAT” TLD exclusively for natural persons and legal entities belonging to the Communauté professionnelle des Avocats, as defined in the eligibility rules published by the Registry Operator. The Registry Operator must define and publish the categories of holders eligible to register a “.AVOCAT” domain name, comprising: • The Avocats; • The Ordres; • The Conseil National des Barreaux (CNB); • The Conférence des Bâtonniers; • The Centres Régionaux de Formation Professionnelle des Avocats (CRFPA); • The Caisses Autonomes des Règlements Pécuniaires des Avocats (CARPA); • The Conseils de discipline; • The Syndicats and Associations d’avocats; • The ad hoc structures mandated by the Institutions de la Profession d’avocat; • The social and/or technical bodies mandated by the Institutions de la Profession d’avocat. Before registering a “.AVOCAT” domain name, the Registry Operator must verify that the applicant satisfies the eligibility criteria applicable to the relevant holder category, including the applicant's identity, membership of the Communauté professionnelle des Avocats and, where applicable, effective registration on the Tableau of a Barreau. The Registry Operator must ensure that the holder's eligibility is validated before any “.AVOCAT” domain name is created in the registry database. The Registry Operator must not permit the automatic registration of a “.AVOCAT” domain name solely on the basis of an application submitted by a Registrar without prior validation of the holder's eligibility in accordance with the eligibility rules published by the Registry Operator.
Please see full instructions in AGB Q151.1.
Obligations Applicable to Registrars The Registry Operator will include the following provisions in its Registry-Registrar Agreement: the Registrar must collect from the applicant the information and supporting documents necessary to verify the applicant's eligibility and transmit them to the Registry Operator in accordance with the procedures established by the Registry Operator. The Registry Operator will include the following provisions in its Registry-Registrar Agreement: the Registrar must not register a “.AVOCAT” domain name without first obtaining validation of the holder's eligibility from the Registry Operator. The Registry Operator will include the following provisions in its Registry-Registrar Agreement: the Registrar must retain the necessary information relating to the registration application and cooperate with the Registry Operator in connection with any review concerning a holder's eligibility.
Please see full instructions in AGB Q151.1.
Obligations Relating to Registration Agreements The Registry Operator will include a provision requiring Registrars to include in their Registration Agreements a provision requiring the holder to maintain eligibility to register a “.AVOCAT” domain name throughout the term of the domain name registration. The Registry Operator will include a provision requiring Registrars to include in their Registration Agreements a provision requiring the holder to notify any change that may affect eligibility for the “.AVOCAT” TLD. The Registry Operator will include a provision requiring Registrars to include in their Registration Agreements a provision prohibiting the holder from providing inaccurate, incomplete or misleading information concerning eligibility for the “.AVOCAT” TLD.
Please see full instructions in AGB Q151.1.
Retention of Evidence and Compliance Monitoring The Registry Operator must retain the information and supporting documents demonstrating the eligibility of registered holders throughout the term of the domain name registration. The Registry Operator must implement a monitoring mechanism to verify that holders of “.AVOCAT” domain names continue to satisfy the applicable eligibility criteria throughout the term of the domain name registration. The Registry Operator must establish a procedure applicable where a holder no longer satisfies the eligibility requirements of the “.AVOCAT” TLD, including loss of Avocat status, removal from the Tableau, dissolution of an entity through which Avocats practise or cessation of membership of the Communauté professionnelle des Avocats.
Please see full instructions in AGB Q151.1.
Publication and Review of the Policy The Registry Operator must develop, implement and publish on its website a registration eligibility policy defining the categories of holders authorised to register a “.AVOCAT” domain name no later than the date on which the “.AVOCAT” TLD is delegated in the DNS. The Registry Operator must review the registration eligibility policy annually and publish the results of that review, including any amendment to the policy, within thirty (30) days after each anniversary of the effective date of the Registry Agreement.
Please see full instructions in AGB Q151.1.
Limitation of the Policy This Community Registration Policy applies throughout the entire period of operation of the “.AVOCAT” TLD. The eligibility restrictions set out in this policy apply to all registrations, renewals and transfers of “.AVOCAT” domain names throughout the entire period of operation of the TLD.
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.
1. General principles applicable to name selection The Registry Operator must reserve the registration of second-level domain names under the “.AVOCAT” TLD for names that comply with the selection criteria set out in the naming policy published by the Registry Operator. The Registry Operator must ensure that every “.AVOCAT” domain name registered by a member of the Communauté professionnelle des Avocats constitutes an authenticatable digital identifier having a direct, verifiable and objective connection with the identity, official name or institutional capacity of the registrant. The Registry Operator must verify that the requested domain name corresponds to: • The name of the registrant who is an individual Avocat, as registered on the Tableau; • The full or abbreviated name of the registrant entity through which Avocats practise, as registered on the Tableau; • The official name, recognised acronym or validated institutional identity, where the registrant is an institutional member of the Communauté professionnelle des Avocats. The Registry Operator must not authorise the registration of a “.AVOCAT” domain name that has no identifiable connection with the applicant’s name, as registered on the Tableau; full or abbreviated name, as registered on the Tableau; official name; recognised acronym; or institutional capacity. The Registry Operator must not authorise the registration of a “.AVOCAT” domain name that generically evokes the title of Avocat or a potentially misleading title, a field of law or an activity falling within those of an Avocat, unless expressly approved in accordance with the rules published by the Registry Operator.
Please see full instructions in AGB Q152.1.
2. Criteria applicable to individual Avocats The Registry Operator must permit an individual Avocat to register only domain names corresponding to their name as registered on the Tableau and as evidenced by the information validated during the eligibility review. The Registry Operator must permit the following formats by default: • surname.avocat; • first-name-surname.avocat. Examples: • dupont.avocat; • jean-dupont.avocat. The Registry Operator must reserve and block the registration of the format consisting solely of the concatenation of the first name and surname without a separator where that format is liable to cause confusion as to identity. Example: • jeandupont.avocat.
Please see full instructions in AGB Q152.1.
3. Management of identical-name situations involving individual Avocats The Registry Operator must implement an objective and published procedure for resolving identical-name situations involving individual Avocats who satisfy the eligibility requirements. Where the name of an Avocat as registered on the Tableau cannot be allocated because another registrant has a prior right to that name, the Registry Operator must permit the following alternative formats: • Addition of a parent’s surname (i); • Addition of the spouse’s surname where it constitutes a legally recognised customary name (ii); • Replacement of the full first name with its initial (iii). Examples: • jean-dupont-martin.avocat (i); • jean-dupont-durand.avocat (ii); • j-dupont.avocat (iii); • jdupont.avocat (iii). The Registry Operator must apply an order of priority among the alternative solutions based on transparent and published criteria, taking into account the supporting documents provided by the applicant.
Please see full instructions in AGB Q152.1.
4. Criteria applicable to entities through which Avocats practise The Registry Operator must permit the registration of a “.AVOCAT” domain name by an entity through which Avocats practise only where the requested name corresponds to its full or abbreviated name as registered on the Tableau. The Registry Operator must permit variants with or without a hyphen where they correspond to the same full or abbreviated name as registered on the Tableau. Examples: • cabinet-dupont.avocat; • cabinetdupont.avocat. The Registry Operator must apply a normalisation rule removing the generic terms “avocat” and “avocats” where they appear in the official name of an entity through which Avocats practise, in order to avoid duplication with the “.AVOCAT” extension. Example: Cabinet Dupont Avocats Becomes: cabinetdupont.avocat. The Registry Operator must not authorise the registration of a domain name based exclusively on: • A trademark; • A trade name; • An initialism; • An acronym; • A diminutive; • An abbreviated form. Where those elements do not correspond to the full or abbreviated name as registered on the Tableau, unless approved in accordance with the Registry’s published rules.
Please see full instructions in AGB Q152.1.
5. Criteria applicable to institutional members of the Communauté professionnelle des Avocats The Registry Operator must permit institutional members of the Communauté professionnelle des Avocats to register domain names corresponding to their official name, recognised acronym or institutional identity validated by the Registry Operator. This provision applies in particular to: • Ordres; • Conseil National des Barreaux; • Conférence des Bâtonniers; • Centres Régionaux de Formation Professionnelle des Avocats; • Caisses Autonomes des Règlements Pécuniaires des Avocats; • Conseils de discipline; • Syndicats and Associations d’avocats; • Structures mandated by the Institutions de la Profession d’avocat.
Please see full instructions in AGB Q152.1.
6. Trademarks and distinctive signs The Registry Operator must provide that the existence of a prior right in a trademark, trade name or any other distinctive sign does not, by itself, confer an automatic right to register a “.AVOCAT” domain name. The Registry Operator must not authorise the registration of a “.AVOCAT” domain name by an applicant that does not satisfy the criteria for membership of the Communauté professionnelle des Avocats and the name selection rules applicable to the “.AVOCAT” TLD.
Please see full instructions in AGB Q152.1.
7. Reserved and blocked names The Registry Operator must establish, maintain and publish a list of reserved or blocked names in order to preserve public trust, the general interest of the Communauté professionnelle des Avocats and the security of the “.AVOCAT” TLD. The Registry Operator must not authorise the registration of those names unless their use is expressly approved in accordance with the rules published by the Registry Operator. Reserved or blocked names include in particular: • Names corresponding to French municipalities; • Names generically evoking the title of avocat or a potentially misleading title; • Names evoking a field of law or an activity falling within those of an avocat; • Terms contrary to public policy or accepted principles of morality; • Any term having institutional, professional-ethics or security significance for the TLD.
Please see full instructions in AGB Q152.1.
8. Technical selection and normalisation rules The Registry Operator must define and publish the rules applicable to: • Permitted characters; • Separators; • Spelling variants; • Normalisation rules; • Any linguistic variants applicable to “.AVOCAT” domain names. The Registry Operator must apply those rules uniformly to all registration applications.
Please see full instructions in AGB Q152.1.
9. Transfer and continued compliance of the registered name The Registry Operator must not authorise the transfer of a “.AVOCAT” domain name where the new registrant does not satisfy the name selection criteria and eligibility requirements applicable to the “.AVOCAT” TLD. The Registry Operator must apply the name selection criteria to registrations, renewals and transfers of “.AVOCAT” domain names.
Please see full instructions in AGB Q152.1.
10. Objective compliance measures The Registry Operator must develop, implement and publish on its website a name selection policy applicable to second-level domain names under “.AVOCAT” no later than the date on which the “.AVOCAT” TLD is delegated in the DNS. The Registry Operator must retain the records demonstrating that registered names comply with the applicable selection criteria throughout the registration period of the relevant domain names. The Registry Operator must review the name selection policy annually and publish the results of that review, including any amendments, within thirty (30) days following each anniversary of the effective date of the Registry Agreement.
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.
Community Registration Policy – Continued Eligibility and Professional Status Monitoring of Registrants Registry Operator must implement a continued-eligibility policy for registrants of “.AVOCAT” domain names to ensure that registrants remain members of the Communauté professionnelle des Avocats throughout the registration term of their domain names. Registry Operator must verify that registrants of “.AVOCAT” domain names continue to satisfy the membership requirements of the Communauté professionnelle des Avocats applicable to their registrant category throughout the registration term of the domain name. Registry Operator must implement cooperation procedures with the Institutions de la Profession d’avocat in order to receive the information necessary to verify registrants’ continued eligibility for “.AVOCAT” domain names. Registry Operator must establish a procedure applicable when a registrant of a “.AVOCAT” domain name ceases to satisfy the membership requirements of the Communauté professionnelle des Avocats, including removal from the Tableau of a Barreau, cessation of professional activity, dissolution of an entity through which Avocats practise, or loss of the status that permitted registration of the domain name. Registry Operator must define in its continued-eligibility policy the conditions governing temporary suspension and permanent deletion of a “.AVOCAT” domain name where a registrant no longer satisfies the applicable eligibility criteria. Registry Operator must address any identified loss of eligibility in accordance with the published policy applicable to the “.AVOCAT” TLD and apply the measures provided for in that policy concerning the maintenance, temporary suspension, or permanent deletion of the relevant domain name. Registry Operator must establish a procedure for giving prior notice to the registrant before any suspension or deletion of a “.AVOCAT” domain name resulting from a loss of eligibility, except where such action is necessary to prevent an immediate risk to the security or integrity of the TLD or to public trust.
Please see full instructions in AGB Q153.1.
Obligations Applicable to Registrars Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar must cooperate with Registry Operator in verification procedures relating to the continued eligibility of registrants of “.AVOCAT” domain names. Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar must not maintain a “.AVOCAT” domain name where Registry Operator has notified it of a suspension or deletion decision based on the registrant’s loss of eligibility in accordance with the applicable policies of the “.AVOCAT” TLD.
Please see full instructions in AGB Q153.1.
Obligations Relating to Registration Agreements Registry Operator will include a provision requiring registrars to include in their Registration Agreements a provision requiring the registrant to notify the registrar of any change that may affect the registrant’s membership of the Communauté professionnelle des Avocats. Registry Operator will include a provision requiring registrars to include in their Registration Agreements a provision prohibiting the registrant from retaining a “.AVOCAT” domain name where the registrant no longer satisfies the eligibility requirements applicable to the “.AVOCAT” TLD. Registry Operator will include a provision requiring registrars to include in their Registration Agreements a provision requiring the registrant to satisfy the applicable eligibility requirements upon any transfer of a “.AVOCAT” domain name to a new registrant.
Please see full instructions in AGB Q153.1.
Record Retention and Traceability Registry Operator must retain the records necessary to demonstrate implementation of this policy throughout the registration term of the relevant domain names. Registry Operator must retain the records supporting any decision to suspend or delete a “.AVOCAT” domain name on the basis of a loss of eligibility.
Please see full instructions in AGB Q153.1.
Publication and Compliance Monitoring Registry Operator must develop, implement, and publish on its website a continued-eligibility policy for registrants of “.AVOCAT” domain names no later than the date on which the “.AVOCAT” TLD is delegated in the DNS. Registry Operator must review the registrant continued-eligibility policy annually and publish the results of that review, including any amendment to the policy, within thirty (30) days following each anniversary of the Effective Date of the Registry Agreement.
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.
Not applicable
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.
See attachment 155 Registry Commitments Evaluation criteria compliance
Community Endorsement
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).
See attachment 156 Community Endorsement + 14 support letters
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.
See attachment 157 absence of community opposition
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.
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. 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.
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.
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