Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 03 February 1500 UTC
Dear Working Group members, Please see below the notes from the meeting on 03 February 1500 UTC. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2020-02-03+New+gTLD+Subsequent+Pro.... Kind regards, Julie Notes and Action Items: Actions: 2.5.3 Application Submission Period: ACTION ITEM 1: Change the language of the recommendation in brackets as follows: “The Working Group recommends that for the next application window and subsequent application windows, [absent “extenuating or extraordinary” circumstances] the application submission period must be a fixed period of 13 weeks” Delete “three (3) months” [and should not begin or end on a weekend.] 2.5.5 Terms and Conditions: ACTION ITEM 2: First recommendation: Change “should” to “must” and delete “only be permitted to” from the first sentence: “Recommendation xx (rationale 1): Unless required under specific laws or the ICANN Bylaws, ICANN [must]should reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, the ICANN organization [must]should cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaws for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round.” Implementation Guidance xx: A framework for ICANN to make transparent changes to the Applicant Guidebook should be provided (see recommendations under Section Predictability). This framework should include available recourse for applicants, including the right to change an application or withdraw an application from ICANN’s consideration in exchange for a full refund, where applicable. This Implementation Guidance constitutes a revision to Section 14 of the Terms and Conditions from the 2012 round. Implementation Guidance xx: If the true risk of name collisions will be determined after the application is filed, ICANN should provide a full refund to applicants in cases where a new gTLD is applied for but later is disqualified because of risk of Name Collision. ACTION ITEM 3: Check the terminology -- Use consistent terminology - "not approved" or "will not proceed" and cross-reference the application change section. Re: The Working Group discussed the issue of confidentiality with respect to the Recommendation xx that ICANN should specify the reason that it has rejected an application. ACTION ITEM 4: Add Implementation Guidance language on confidentiality. ACTION ITEM 5: Add “Application Changes” to the list of dependencies. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review draft final recommendations – see attached Working Document and here:https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52.... Overview: -- Question: What was the relationship between “affirmations” and “consensus”? Answer: These are two different concepts. We will be taking consensus calls on everything -- whether it is an affirmation, recommendation, or implementation guideline. -- Question: Affirmation seems quite intertwined with the concept of consensus. How does that relate to people who don’t agree with that affirmation? Answer: We hope you would let us know prior to taking a consensus call -- perhaps by changing the language, or changing it to a different type, such as a recommendation. We’ll also have a preamble that will explain what are the different categories. -- Think of it as an affirmative recommendation. Default to the 2012 round will be stated differently -- noting that not everyone agreed. -- Question: If we have default where we don’t agree, what about things we didn’t discuss? a. 2.5.3 Application Submission Period Recommendation xx: The Working Group recommends that for the next application window and subsequent application windows, the application submission period must be a fixed period of three (3) months. -- We aren’t really affirming what happened last time (as we don’t agree), but making a recommendation. -- What we talked about and had agreement in the comments we said at least 3 months, but that leaves open a whole bunch of different possibilities. This recommendation says 3 months, but there was discussion about longer periods. Discussion: -- In this discussion there might be a dependency relating for time for translation of the AGB in all of the different languages -- it should be consistent. -- On the translations issue we had implementation guidance that the non-English version should come out at or the same time as the English version. -- It should be a fixed period of time and should be consistent. -- Not just due to circumstances — it should changeable based on policy considerations and objectives -- 90-120 day. -- If it's not a fixed time, then who decides and when? -- Agree not less than 90 nor more than 120. -- Hence 12 weeks works and applies a reasonable structure . -- The implementation guidelines could say that the period should not end over a weekend, or say that it ends on a Wednesday. Say that the week runs from a Wednesday to a Wednesday. ACTION ITEM: Change the language of the recommendation in brackets as follows: “The Working Group recommends that for the next application window and subsequent application windows, [absent “extenuating or extraordinary” circumstances] the application submission period must be a fixed period of 13 weeks” Delete “three (3) months” [and should not begin or end on a weekend.] b. 2.5.5 Terms and Conditions Recommendation xx (rationale 1): Unless required under specific laws or the ICANN Bylaws, ICANN must only be permitted to reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, the ICANN organization must cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaw for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round. Discussion: -- Question: If we say “must” instead of “should” are we putting the Board in a position of not adopting a recommendation subject to GAC advice. Answer: The GAC advice led to unpredictability so this is a pretty strong recommendation from the comments that we got in on the Initial Report. -- Question: Are we able to accommodate name collisions, or things that we didn’t think about? Answer: That is in the first sentence. -- This should be viewed as a compromise position since ICANN shouldn’t be able to avoid having it’s decisions challenged in court. -- If ICANN acts inconsistently with the AGB or the Bylaws there are ways to challenge the decisions. This is all challengeable in some way and allows for accountability. -- Should we delete “be permitted” in the first sentence? ACTION ITEM: First recommendation: Change “should” to “must” and delete “only be permitted to” from the first sentence: “Recommendation xx (rationale 1): Unless required under specific laws or the ICANN Bylaws, ICANN [must]should reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, the ICANN organization [must]should cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaws for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round.” Implementation Guidance xx: A framework for ICANN to make transparent changes to the Applicant Guidebook should be provided (see recommendations under Section Predictability). This framework should include available recourse for applicants, including the right to change an application or withdraw an application from ICANN’s consideration in exchange for a full refund, where applicable. This Implementation Guidance constitutes a revision to Section 14 of the Terms and Conditions from the 2012 round. Discussion: -- What does the “where applicable” comes from - is it because of the difference between those who may not get a full refund. -- Putting in a full refund for any change to the AGB could be challenging. Not sure the WG could decide where a full refund should be made available. It is a qualifier that a full refund is not provided in all circumstances. -- Does the WG have a suggestion for the types of changes that would require a full refund? This doesn’t take into account that there are portions of the program that don’t get implemented until the end so there is a potential for changes. -- When we talk about application changes we provide more detail. Where and ICANN change materially changes the nature of an application, for example. ACTION ITEM: Check the terminology -- Use consistent terminology - "not approved" or "will not proceed" and cross-reference the application change section. c. New issues raised in deliberations since publication of the Initial Report, if applicable: The Working Group discussed the issue of confidentiality with respect to the Recommendation xx that ICANN should specify the reason that it has rejected an application. The Working Group considered feedback received through public comment regarding who should have access to this information provided by ICANN org. The Working Group reviewed one perspective that this information should be completely confidential and only available to the applicant, as well as the perspective that disclosure should be to the applicant exclusively if confidential information of the applicant might otherwise be revealed. The Working Group did not put forward a specific recommendation on this issue and notes that it may be considered further in the implementation phase. Discussion: -- This seems to make sense. This is a good inclusion. -- The reason for rejecting an application should be confidential, but binding on ICANN, not on the applicant. -- Question: Is that for any reason an application be rejected? Or just based on confidential information submitted by the applicant? Answer: It seems practically that the confidentiality would flow from the confidential disclosure. ACTION ITEM: Add Implementation Guidance language on confidentiality. -- Question: Should we link to the NCAP on name collisions as an “external effort”? Answer: Staff will determine the most efficient way to include links. ACTION ITEM 5: Add “Application Changes” to the list of dependencies.
Julie, There appears to be an error in ACTIN ITEM 2. The word “only” was not supposed to be deleted. The word “only” should remain in the text or it does not express what the WG was agreeing on the call. The meaning is to limit the grounds for rejection to the provisions of the AGB. The deletion is “be permitted to”. Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Julie Hedlund Sent: Monday, February 3, 2020 9:45 AM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 03 February 1500 UTC [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting on 03 February 1500 UTC. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2020-02-03+New+gTLD+Subsequent+Pro.... Kind regards, Julie Notes and Action Items: Actions: 2.5.3 Application Submission Period: ACTION ITEM 1: Change the language of the recommendation in brackets as follows: “The Working Group recommends that for the next application window and subsequent application windows, [absent “extenuating or extraordinary” circumstances] the application submission period must be a fixed period of 13 weeks” Delete “three (3) months” [and should not begin or end on a weekend.] 2.5.5 Terms and Conditions: ACTION ITEM 2: First recommendation: Change “should” to “must” and delete “only be permitted to” from the first sentence: “Recommendation xx (rationale 1): Unless required under specific laws or the ICANN Bylaws, ICANN [must]should reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, the ICANN organization [must]should cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaws for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round.” Implementation Guidance xx: A framework for ICANN to make transparent changes to the Applicant Guidebook should be provided (see recommendations under Section Predictability). This framework should include available recourse for applicants, including the right to change an application or withdraw an application from ICANN’s consideration in exchange for a full refund, where applicable. This Implementation Guidance constitutes a revision to Section 14 of the Terms and Conditions from the 2012 round. Implementation Guidance xx: If the true risk of name collisions will be determined after the application is filed, ICANN should provide a full refund to applicants in cases where a new gTLD is applied for but later is disqualified because of risk of Name Collision. ACTION ITEM 3: Check the terminology -- Use consistent terminology - "not approved" or "will not proceed" and cross-reference the application change section. Re: The Working Group discussed the issue of confidentiality with respect to the Recommendation xx that ICANN should specify the reason that it has rejected an application. ACTION ITEM 4: Add Implementation Guidance language on confidentiality. ACTION ITEM 5: Add “Application Changes” to the list of dependencies. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review draft final recommendations – see attached Working Document and here:https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52.... Overview: -- Question: What was the relationship between “affirmations” and “consensus”? Answer: These are two different concepts. We will be taking consensus calls on everything -- whether it is an affirmation, recommendation, or implementation guideline. -- Question: Affirmation seems quite intertwined with the concept of consensus. How does that relate to people who don’t agree with that affirmation? Answer: We hope you would let us know prior to taking a consensus call -- perhaps by changing the language, or changing it to a different type, such as a recommendation. We’ll also have a preamble that will explain what are the different categories. -- Think of it as an affirmative recommendation. Default to the 2012 round will be stated differently -- noting that not everyone agreed. -- Question: If we have default where we don’t agree, what about things we didn’t discuss? a. 2.5.3 Application Submission Period Recommendation xx: The Working Group recommends that for the next application window and subsequent application windows, the application submission period must be a fixed period of three (3) months. -- We aren’t really affirming what happened last time (as we don’t agree), but making a recommendation. -- What we talked about and had agreement in the comments we said at least 3 months, but that leaves open a whole bunch of different possibilities. This recommendation says 3 months, but there was discussion about longer periods. Discussion: -- In this discussion there might be a dependency relating for time for translation of the AGB in all of the different languages -- it should be consistent. -- On the translations issue we had implementation guidance that the non-English version should come out at or the same time as the English version. -- It should be a fixed period of time and should be consistent. -- Not just due to circumstances — it should changeable based on policy considerations and objectives -- 90-120 day. -- If it's not a fixed time, then who decides and when? -- Agree not less than 90 nor more than 120. -- Hence 12 weeks works and applies a reasonable structure . -- The implementation guidelines could say that the period should not end over a weekend, or say that it ends on a Wednesday. Say that the week runs from a Wednesday to a Wednesday. ACTION ITEM: Change the language of the recommendation in brackets as follows: “The Working Group recommends that for the next application window and subsequent application windows, [absent “extenuating or extraordinary” circumstances] the application submission period must be a fixed period of 13 weeks” Delete “three (3) months” [and should not begin or end on a weekend.] b. 2.5.5 Terms and Conditions Recommendation xx (rationale 1): Unless required under specific laws or the ICANN Bylaws, ICANN must only be permitted to reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, the ICANN organization must cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaw for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round. Discussion: -- Question: If we say “must” instead of “should” are we putting the Board in a position of not adopting a recommendation subject to GAC advice. Answer: The GAC advice led to unpredictability so this is a pretty strong recommendation from the comments that we got in on the Initial Report. -- Question: Are we able to accommodate name collisions, or things that we didn’t think about? Answer: That is in the first sentence. -- This should be viewed as a compromise position since ICANN shouldn’t be able to avoid having it’s decisions challenged in court. -- If ICANN acts inconsistently with the AGB or the Bylaws there are ways to challenge the decisions. This is all challengeable in some way and allows for accountability. -- Should we delete “be permitted” in the first sentence? ACTION ITEM: First recommendation: Change “should” to “must” and delete “only be permitted to” from the first sentence: “Recommendation xx (rationale 1): Unless required under specific laws or the ICANN Bylaws, ICANN [must]should reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, the ICANN organization [must]should cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaws for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round.” Implementation Guidance xx: A framework for ICANN to make transparent changes to the Applicant Guidebook should be provided (see recommendations under Section Predictability). This framework should include available recourse for applicants, including the right to change an application or withdraw an application from ICANN’s consideration in exchange for a full refund, where applicable. This Implementation Guidance constitutes a revision to Section 14 of the Terms and Conditions from the 2012 round. Discussion: -- What does the “where applicable” comes from - is it because of the difference between those who may not get a full refund. -- Putting in a full refund for any change to the AGB could be challenging. Not sure the WG could decide where a full refund should be made available. It is a qualifier that a full refund is not provided in all circumstances. -- Does the WG have a suggestion for the types of changes that would require a full refund? This doesn’t take into account that there are portions of the program that don’t get implemented until the end so there is a potential for changes. -- When we talk about application changes we provide more detail. Where and ICANN change materially changes the nature of an application, for example. ACTION ITEM: Check the terminology -- Use consistent terminology - "not approved" or "will not proceed" and cross-reference the application change section. c. New issues raised in deliberations since publication of the Initial Report, if applicable: The Working Group discussed the issue of confidentiality with respect to the Recommendation xx that ICANN should specify the reason that it has rejected an application. The Working Group considered feedback received through public comment regarding who should have access to this information provided by ICANN org. The Working Group reviewed one perspective that this information should be completely confidential and only available to the applicant, as well as the perspective that disclosure should be to the applicant exclusively if confidential information of the applicant might otherwise be revealed. The Working Group did not put forward a specific recommendation on this issue and notes that it may be considered further in the implementation phase. Discussion: -- This seems to make sense. This is a good inclusion. -- The reason for rejecting an application should be confidential, but binding on ICANN, not on the applicant. -- Question: Is that for any reason an application be rejected? Or just based on confidential information submitted by the applicant? Answer: It seems practically that the confidentiality would flow from the confidential disclosure. ACTION ITEM: Add Implementation Guidance language on confidentiality. -- Question: Should we link to the NCAP on name collisions as an “external effort”? Answer: Staff will determine the most efficient way to include links. ACTION ITEM 5: Add “Application Changes” to the list of dependencies. ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
participants (2)
-
Aikman-Scalese, Anne -
Julie Hedlund