The call for the New gTLD Subsequent Procedures Working Group will take place on Monday, 03 February 2020 at 15:00 UTC for 90 minutes.

For other places see: https://tinyurl.com/wdeaqda

PROPOSED AGENDA


  1. Review Agenda/Statements of Interest
  2. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing. The goal of this exercise is intended to accomplish at least a couple of things, 1) Ensure that the format and level of detail, which emphasizes the recommendations/implementation guidance/affirmations and rationale rather than comprehensive deliberations (and which follows the model established by Work Track 5), is supported by the WG, and 2) Give the WG the opportunity to make substantive progress on finalizing topics.
    1. 2.5.3 Application Submission Period
    2. 2.5.5 Terms and Conditions

BACKGROUND DOCUMENTS



RECORDINGS


Audio Recording

Zoom Recording

Chat Transcript 

GNSO transcripts are located on the GNSO Calendar

PARTICIPATION

Notes/ 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/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing.


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.


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.

  • No labels