Responses to Questions re: Community Commitments vs. RVCs vs. CPE
Dear IRT members, In follow-up to our discussion last week and in preparation for further discussion in a few hours, I have prepared some responses to the questions that came up last week regarding community commitments as it relates to CPE. I’d like to propose that we spend maybe only the first 10 minutes of our discussion on this and then move to a review of the criteria. Thank you, Jared Question(s) from IRT: What is the difference between an RVC and a Community Commitment? Do an applicant's Community Commitments have to be an RVC? Are all Community Commitments evaluated in the same way as RVCs? What are examples of Community Commitments? As set out by the SubPro Final Report, there are different types of gTLDs. A “community” gTLD string is a specific type of application, and, if delegated, the gTLD is differentiated from a generic gTLD by having a Specification 12. Community commitments are required by every community applicant (regardless of contention status), which are enshrined in Spec 12. It is not necessarily true that they would be part of Spec 11 (for RVCs) but could be depending on the applicant's choice and/or any objections/GAC advice. The draft AGB text on PICs/RVCs notes that the community registration policies must be evaluated and meet the same criteria as those that will be applied to the evaluation of RVCs. However, there are some key distinctions between “community commitments”, RVCs, and the Community Priority Evaluation (CPE) criteria. When an applicant designates its application as “community” the applicant will be asked to answer a series of additional questions that are specific to community gTLD applications and will be used to evaluate the application against the CPE criteria. These questions will cover the following areas: · Criterion 1: Community Establishment · Criterion 2: Nexus · Criterion 3: Registration Policies · Criterion 4: Community Endorsement The “community commitments” that will be evaluated using the “RVC evaluation criteria” are the “community registration policies” that are called for in Criterion 3 above. The current draft AGB PICs/RVCs text is proposing to evaluate these registrations policies related to Criterion 3 against the RVC criteria and NOT the information provided for Criteria 1, 2, and 4, because registration policies are the only “commitments” that will result in binding additional commitments in the applicable RA. The other criteria require the applicant to demonstrate, at the time of application, the existence of a community, the string’s nexus to the community, and endorsement of the community, but this type of information would not be expected to result in ongoing, enforceable commitments in the applicable RA. To summarize, registration policies proposed by applicants for community gTLDs will be evaluated using the criteria developed for the evaluation of registry voluntary commitments. These community registration policies could look very similar to commitments proposed as RVCs by non-community applicants, but they will live in Specification 12 because the applied-for gTLD is a community gTLD. ICANN is preparing guidelines and questions to assist applicants in their preparation of RVCs. -- Jared Erwin Director, New gTLD Program Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) jared.erwin@icann.org<mailto:jared.erwin@icann.org>
Thanks Jared. This is very helpful. I think my question in our last session was focused on advising community applicants IN ADVANCE that all "Registration Policies" will be evaluated as RVCs. Some on the call seemed to think this was not the case, but I think your email confirms that this is in fact, true. So TRUE or FALSE: All Community Applicant Registration Policies will be evaluated as RVCs. And if a Registration Policy fails the RVC test, is there any effect in Community Priority Evaluation if that process has already commenced? Or are we saying Registration Policies passing the RVC evaluation criteria is a prerequisite to eligibility for CPE? I'm happy that others (e.g. Justine, Cheryl, and Avri) seem to understand the interrelationships here much better than I do, but I don't think the entire IRT has a high level of experience with Community Applications so I appreciate your taking the time to clarify the proposed Implementation. My main concern is making sure Community Applicants know what is expected of them and what the process will be. Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com On Thu, Oct 24, 2024 at 9:14 AM Jared Erwin via SubPro-IRT < subpro-irt@icann.org> wrote:
Dear IRT members,
In follow-up to our discussion last week and in preparation for further discussion in a few hours, I have prepared some responses to the questions that came up last week regarding community commitments as it relates to CPE. I’d like to propose that we spend maybe only the first 10 minutes of our discussion on this and then move to a review of the criteria.
Thank you,
Jared
*Question(s) from IRT: What is the difference between an RVC and a Community Commitment? Do an applicant's Community Commitments have to be an RVC? Are all Community Commitments evaluated in the same way as RVCs? What are examples of Community Commitments?*
As set out by the SubPro Final Report, there are different types of gTLDs. A “community” gTLD string is a specific type of application, and, if delegated, the gTLD is differentiated from a generic gTLD by having a Specification 12. Community commitments are required by every community applicant (regardless of contention status), which are enshrined in Spec 12. It is not necessarily true that they would be part of Spec 11 (for RVCs) but could be depending on the applicant's choice and/or any objections/GAC advice.
The draft AGB text on PICs/RVCs notes that the community registration policies must be evaluated and meet the same criteria as those that will be applied to the evaluation of RVCs. However, there are some key distinctions between “community commitments”, RVCs, and the Community Priority Evaluation (CPE) criteria. When an applicant designates its application as “community” the applicant will be asked to answer a series of additional questions that are specific to community gTLD applications and will be used to evaluate the application against the CPE criteria. These questions will cover the following areas:
· Criterion 1: Community Establishment
· Criterion 2: Nexus
· Criterion 3: Registration Policies
· Criterion 4: Community Endorsement
The “community commitments” that will be evaluated using the “RVC evaluation criteria” are the “community registration policies” that are called for in Criterion 3 above. The current draft AGB PICs/RVCs text is proposing to evaluate these registrations policies related to Criterion 3 against the RVC criteria and NOT the information provided for Criteria 1, 2, and 4, because registration policies are the only “commitments” that will result in binding additional commitments in the applicable RA. The other criteria require the applicant to demonstrate, at the time of application, the existence of a community, the string’s nexus to the community, and endorsement of the community, but this type of information would not be expected to result in ongoing, enforceable commitments in the applicable RA.
To summarize, registration policies proposed by applicants for community gTLDs will be evaluated using the criteria developed for the evaluation of registry voluntary commitments. These community registration policies could look very similar to commitments proposed as RVCs by non-community applicants, but they will live in Specification 12 because the applied-for gTLD is a community gTLD.
ICANN is preparing guidelines and questions to assist applicants in their preparation of RVCs.
--
Jared Erwin
Director, New gTLD Program
Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)
jared.erwin@icann.org
_______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Dear Anne, I see where you're coming from, and if you will allow me to frame 2 simple questions for Jared and his team: 1. To what extent do community registration policies have to meet the RVC framework? 2. If such registration policies must pass the RVC framework (to the same extent as other non-community RVCs) then would failing the RVC framework: (a) Exclude them from being included in Spec 12 altogether? Subject to an opportunity for the applicant to submit a Change Request to enable such restrictions/policies to be reformulated to meet the RVC framework? (b) Exclude them from being utilized and evaluated for the purposes of CPE Criterion 3? Kind regards, Justine On Tue, 29 Oct 2024 at 00:13, Anne ICANN via SubPro-IRT < subpro-irt@icann.org> wrote:
Thanks Jared. This is very helpful. I think my question in our last session was focused on advising community applicants IN ADVANCE that all "Registration Policies" will be evaluated as RVCs. Some on the call seemed to think this was not the case, but I think your email confirms that this is in fact, true. So TRUE or FALSE: All Community Applicant Registration Policies will be evaluated as RVCs.
And if a Registration Policy fails the RVC test, is there any effect in Community Priority Evaluation if that process has already commenced? Or are we saying Registration Policies passing the RVC evaluation criteria is a prerequisite to eligibility for CPE?
I'm happy that others (e.g. Justine, Cheryl, and Avri) seem to understand the interrelationships here much better than I do, but I don't think the entire IRT has a high level of experience with Community Applications so I appreciate your taking the time to clarify the proposed Implementation. My main concern is making sure Community Applicants know what is expected of them and what the process will be.
Thank you, Anne
Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com
On Thu, Oct 24, 2024 at 9:14 AM Jared Erwin via SubPro-IRT < subpro-irt@icann.org> wrote:
Dear IRT members,
In follow-up to our discussion last week and in preparation for further discussion in a few hours, I have prepared some responses to the questions that came up last week regarding community commitments as it relates to CPE. I’d like to propose that we spend maybe only the first 10 minutes of our discussion on this and then move to a review of the criteria.
Thank you,
Jared
*Question(s) from IRT: What is the difference between an RVC and a Community Commitment? Do an applicant's Community Commitments have to be an RVC? Are all Community Commitments evaluated in the same way as RVCs? What are examples of Community Commitments?*
As set out by the SubPro Final Report, there are different types of gTLDs. A “community” gTLD string is a specific type of application, and, if delegated, the gTLD is differentiated from a generic gTLD by having a Specification 12. Community commitments are required by every community applicant (regardless of contention status), which are enshrined in Spec 12. It is not necessarily true that they would be part of Spec 11 (for RVCs) but could be depending on the applicant's choice and/or any objections/GAC advice.
The draft AGB text on PICs/RVCs notes that the community registration policies must be evaluated and meet the same criteria as those that will be applied to the evaluation of RVCs. However, there are some key distinctions between “community commitments”, RVCs, and the Community Priority Evaluation (CPE) criteria. When an applicant designates its application as “community” the applicant will be asked to answer a series of additional questions that are specific to community gTLD applications and will be used to evaluate the application against the CPE criteria. These questions will cover the following areas:
· Criterion 1: Community Establishment
· Criterion 2: Nexus
· Criterion 3: Registration Policies
· Criterion 4: Community Endorsement
The “community commitments” that will be evaluated using the “RVC evaluation criteria” are the “community registration policies” that are called for in Criterion 3 above. The current draft AGB PICs/RVCs text is proposing to evaluate these registrations policies related to Criterion 3 against the RVC criteria and NOT the information provided for Criteria 1, 2, and 4, because registration policies are the only “commitments” that will result in binding additional commitments in the applicable RA. The other criteria require the applicant to demonstrate, at the time of application, the existence of a community, the string’s nexus to the community, and endorsement of the community, but this type of information would not be expected to result in ongoing, enforceable commitments in the applicable RA.
To summarize, registration policies proposed by applicants for community gTLDs will be evaluated using the criteria developed for the evaluation of registry voluntary commitments. These community registration policies could look very similar to commitments proposed as RVCs by non-community applicants, but they will live in Specification 12 because the applied-for gTLD is a community gTLD.
ICANN is preparing guidelines and questions to assist applicants in their preparation of RVCs.
--
Jared Erwin
Director, New gTLD Program
Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)
jared.erwin@icann.org
_______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
I want to make sure we are clear - the no-content in RVC policy does not dictate community (or other application) registration policies - the only question is whether or not ICANN can enforce them, and that dictates whether or not they are in the contract - NOT whether they can exist J. Beckwith Burr HWG LLP 1919 M Street NW, The Eighth Floor Washington DC 20036 ________________________________ From: Anne ICANN via SubPro-IRT <subpro-irt@icann.org> Sent: Monday, October 28, 2024 12:12 PM To: Jared Erwin <jared.erwin@icann.org> Cc: subpro-irt@icann.org <subpro-irt@icann.org> Subject: [SubPro-IRT] Re: Responses to Questions re: Community Commitments vs. RVCs vs. CPE Thanks Jared. This is very helpful. I think my question in our last session was focused on advising community applicants IN ADVANCE that all "Registration Policies" will be evaluated as RVCs. Some on the call seemed to think this was not the case, but I think your email confirms that this is in fact, true. So TRUE or FALSE: All Community Applicant Registration Policies will be evaluated as RVCs. And if a Registration Policy fails the RVC test, is there any effect in Community Priority Evaluation if that process has already commenced? Or are we saying Registration Policies passing the RVC evaluation criteria is a prerequisite to eligibility for CPE? I'm happy that others (e.g. Justine, Cheryl, and Avri) seem to understand the interrelationships here much better than I do, but I don't think the entire IRT has a high level of experience with Community Applications so I appreciate your taking the time to clarify the proposed Implementation. My main concern is making sure Community Applicants know what is expected of them and what the process will be. Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Thu, Oct 24, 2024 at 9:14 AM Jared Erwin via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: Dear IRT members, In follow-up to our discussion last week and in preparation for further discussion in a few hours, I have prepared some responses to the questions that came up last week regarding community commitments as it relates to CPE. I’d like to propose that we spend maybe only the first 10 minutes of our discussion on this and then move to a review of the criteria. Thank you, Jared Question(s) from IRT: What is the difference between an RVC and a Community Commitment? Do an applicant's Community Commitments have to be an RVC? Are all Community Commitments evaluated in the same way as RVCs? What are examples of Community Commitments? As set out by the SubPro Final Report, there are different types of gTLDs. A “community” gTLD string is a specific type of application, and, if delegated, the gTLD is differentiated from a generic gTLD by having a Specification 12. Community commitments are required by every community applicant (regardless of contention status), which are enshrined in Spec 12. It is not necessarily true that they would be part of Spec 11 (for RVCs) but could be depending on the applicant's choice and/or any objections/GAC advice. The draft AGB text on PICs/RVCs notes that the community registration policies must be evaluated and meet the same criteria as those that will be applied to the evaluation of RVCs. However, there are some key distinctions between “community commitments”, RVCs, and the Community Priority Evaluation (CPE) criteria. When an applicant designates its application as “community” the applicant will be asked to answer a series of additional questions that are specific to community gTLD applications and will be used to evaluate the application against the CPE criteria. These questions will cover the following areas: • Criterion 1: Community Establishment • Criterion 2: Nexus • Criterion 3: Registration Policies • Criterion 4: Community Endorsement The “community commitments” that will be evaluated using the “RVC evaluation criteria” are the “community registration policies” that are called for in Criterion 3 above. The current draft AGB PICs/RVCs text is proposing to evaluate these registrations policies related to Criterion 3 against the RVC criteria and NOT the information provided for Criteria 1, 2, and 4, because registration policies are the only “commitments” that will result in binding additional commitments in the applicable RA. The other criteria require the applicant to demonstrate, at the time of application, the existence of a community, the string’s nexus to the community, and endorsement of the community, but this type of information would not be expected to result in ongoing, enforceable commitments in the applicable RA. To summarize, registration policies proposed by applicants for community gTLDs will be evaluated using the criteria developed for the evaluation of registry voluntary commitments. These community registration policies could look very similar to commitments proposed as RVCs by non-community applicants, but they will live in Specification 12 because the applied-for gTLD is a community gTLD. ICANN is preparing guidelines and questions to assist applicants in their preparation of RVCs. -- Jared Erwin Director, New gTLD Program Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) jared.erwin@icann.org<mailto:jared.erwin@icann.org> _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org<mailto:subpro-irt@icann.org> To unsubscribe send an email to subpro-irt-leave@icann.org<mailto:subpro-irt-leave@icann.org> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Becky, What would happen if Spec 12 in a contract contains an outside reference to policies ? Like in “Follow all policies published at nic.TLD”, and then the policies there contain content-related policies ? Rubens
Em 28 de out. de 2024, à(s) 20:28, Becky Burr via SubPro-IRT <subpro-irt@icann.org> escreveu:
I want to make sure we are clear - the no-content in RVC policy does not dictate community (or other application) registration policies - the only question is whether or not ICANN can enforce them, and that dictates whether or not they are in the contract - NOT whether they can exist
J. Beckwith Burr HWG LLP 1919 M Street NW, The Eighth Floor Washington DC 20036 From: Anne ICANN via SubPro-IRT <subpro-irt@icann.org> Sent: Monday, October 28, 2024 12:12 PM To: Jared Erwin <jared.erwin@icann.org> Cc: subpro-irt@icann.org <subpro-irt@icann.org> Subject: [SubPro-IRT] Re: Responses to Questions re: Community Commitments vs. RVCs vs. CPE
Thanks Jared. This is very helpful. I think my question in our last session was focused on advising community applicants IN ADVANCE that all "Registration Policies" will be evaluated as RVCs. Some on the call seemed to think this was not the case, but I think your email confirms that this is in fact, true. So TRUE or FALSE: All Community Applicant Registration Policies will be evaluated as RVCs.
And if a Registration Policy fails the RVC test, is there any effect in Community Priority Evaluation if that process has already commenced? Or are we saying Registration Policies passing the RVC evaluation criteria is a prerequisite to eligibility for CPE?
I'm happy that others (e.g. Justine, Cheryl, and Avri) seem to understand the interrelationships here much better than I do, but I don't think the entire IRT has a high level of experience with Community Applications so I appreciate your taking the time to clarify the proposed Implementation. My main concern is making sure Community Applicants know what is expected of them and what the process will be.
Thank you, Anne
Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com <mailto:anneicanngnso@gmail.com>
On Thu, Oct 24, 2024 at 9:14 AM Jared Erwin via SubPro-IRT <subpro-irt@icann.org <mailto:subpro-irt@icann.org>> wrote: Dear IRT members,
In follow-up to our discussion last week and in preparation for further discussion in a few hours, I have prepared some responses to the questions that came up last week regarding community commitments as it relates to CPE. I’d like to propose that we spend maybe only the first 10 minutes of our discussion on this and then move to a review of the criteria.
Thank you,
Jared
Question(s) from IRT: What is the difference between an RVC and a Community Commitment? Do an applicant's Community Commitments have to be an RVC? Are all Community Commitments evaluated in the same way as RVCs? What are examples of Community Commitments?
As set out by the SubPro Final Report, there are different types of gTLDs. A “community” gTLD string is a specific type of application, and, if delegated, the gTLD is differentiated from a generic gTLD by having a Specification 12. Community commitments are required by every community applicant (regardless of contention status), which are enshrined in Spec 12. It is not necessarily true that they would be part of Spec 11 (for RVCs) but could be depending on the applicant's choice and/or any objections/GAC advice.
The draft AGB text on PICs/RVCs notes that the community registration policies must be evaluated and meet the same criteria as those that will be applied to the evaluation of RVCs. However, there are some key distinctions between “community commitments”, RVCs, and the Community Priority Evaluation (CPE) criteria. When an applicant designates its application as “community” the applicant will be asked to answer a series of additional questions that are specific to community gTLD applications and will be used to evaluate the application against the CPE criteria. These questions will cover the following areas:
· Criterion 1: Community Establishment · Criterion 2: Nexus · Criterion 3: Registration Policies · Criterion 4: Community Endorsement
The “community commitments” that will be evaluated using the “RVC evaluation criteria” are the “community registration policies” that are called for in Criterion 3 above. The current draft AGB PICs/RVCs text is proposing to evaluate these registrations policies related to Criterion 3 against the RVC criteria and NOT the information provided for Criteria 1, 2, and 4, because registration policies are the only “commitments” that will result in binding additional commitments in the applicable RA. The other criteria require the applicant to demonstrate, at the time of application, the existence of a community, the string’s nexus to the community, and endorsement of the community, but this type of information would not be expected to result in ongoing, enforceable commitments in the applicable RA.
To summarize, registration policies proposed by applicants for community gTLDs will be evaluated using the criteria developed for the evaluation of registry voluntary commitments. These community registration policies could look very similar to commitments proposed as RVCs by non-community applicants, but they will live in Specification 12 because the applied-for gTLD is a community gTLD.
ICANN is preparing guidelines and questions to assist applicants in their preparation of RVCs.
--
Jared Erwin Director, New gTLD Program Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) jared.erwin@icann.org <mailto:jared.erwin@icann.org>
_______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org <mailto:subpro-irt@icann.org> To unsubscribe send an email to subpro-irt-leave@icann.org <mailto:subpro-irt-leave@icann.org>
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
participants (5)
-
Anne ICANN -
Becky Burr -
Jared Erwin -
Justine Chew -
Rubens Kuhl