2020-03-12 ICANN67 Cancun- New gTLD Subsequent Procedures PDP

AGENDA: 

1. Review Agenda/Updates to Statements of Interest
2. Discussion of Final Report Topics – see the documents at: https://docs.google.com/document/d/1xXu7gPKiblS3Vh4MCuK6NWfeRmMolXf9VF5sO7OG4VE/edit?usp=sharing
a. 2.7.3 Closed Generics
b. Public Interest Commitments (aka Registry Commitments) (in 2.3.2. Global Public Interest)
c. 2.8.1 Role of GAC Early Warnings/Advice
d. 2.5.4 Applicant Support
e. 2.9.1 Community Applications
3. AOB

Actions:

2.8.1 Role of GAC Early Warnings/Advice

Recommendation xx (rationale 1):

ACTION ITEM: Consider omitting the bracketed text and only referencing section 12.2.a of the Bylaws.

Recommendation xx (rationale 2):

ACTION ITEM: Rewrite the language to focus more on the operational problem vis-a-vis the timing of GAC advice, the need for predictability, and the desire to enable applications to be judged on their merits and not just as part of a class of applications.  Consider also rationale 1 and 3.

Recommendation xx (rationale 3):

ACTION ITEM: Reference the applicable sections of the Bylaws and rewrite in consideration with recommendations-rationale 1, 2, and 3.

Recommendation xx (rationale 4):

ACTION ITEM: Separate the recommendation into two sentences.

ACTION ITEM: Consider deleting the text, “and specific action requested of the applicant.”

ACTION ITEM: Re: “include both a written rationale/basis” with more collaborative language, such as “reason” or “explanation”. 

Recommendation xx (rationale 5):

ACTION ITEM: Accept and include the text in brackets “and GAC Advice”.

ACTION ITEM: Rewrite to clarify the opportunity for dialog and recognizing that some governments may not have the ability to engage in that dialog.

Recommendation xx (rationale 6):

ACTION ITEM: Consider whether the language can be rewritten to allow a balance with the GAC Early Warning and/or GAC Advice.

2.5.4 Applicant Support

Affirmation xx with modification (rationales 1 and 2):

ACTION ITEM: Consider rewriting as a recommendation.

ACTION ITEM: For affirmation 1 and 2, make it clear what is the original affirmation and what is new language.

Recommendation xx (rationale 4) and Implementation Guidance:

ACTION ITEMS: Review and rewrite the Implementation Guidance per the comments.  Consider deleting the term “middle applicant”.

ACTION ITEM: Reference the definitional work being done by ICANN.

Notes:

1. Updates to Statements of Interest: No updates provided.

2. Discussion of Final Report Topics – see the documents at: https://docs.google.com/document/d/1xXu7gPKiblS3Vh4MCuK6NWfeRmMolXf9VF5sO7OG4VE/edit?usp=sharing and attached as a PDF.

a. 2.8.1 Role of GAC Early Warnings/Advice

Recommendation xx (rationale 1): GAC Advice must include clearly articulated rationale, including the national or international law [and merits-based public policy reasons] [or merits-based public policy reasons] [and/or merits-based public policy reasons] upon which it is based. 

Discussion:

-- Question Re: the bracketed text -- do we have to choose one of these options? Or can we decide on something else?  Answer: No we don’t have to include any one of these.

-- Don’t think we should accept any of the options.

-- This recommendation should only refer to the Bylaws.

-- The bracketed text was suggested in the public comments.

-- Bylaws: Section 12.3. PROCEDURES of the ICANN Bylaws, which states that “. . .each Advisory Committee shall ensure that the advice provided to the Board by such Advisory Committee is communicated in a clear and unambiguous written statement, including the rationale for such advice.”

-- Including the bracketed text would limit the scope of GAC advice as opposed to what is provided in the Bylaws.

-- From section 12.2.a defining GAC role: "(i) The Governmental Advisory Committee should consider and provide advice on the activities of ICANN as they relate to concerns of governments, particularly matters where there may be an interaction between ICANN's policies and various laws and international agreements or where they may affect public policy issues."

-- Come back to this issue.

-- FYI:  Someone reminded me that in the .amazon IRP, it states:  "The Panel recommends that the Board of ICANN promptly re-evaluate Amazon’s

applications in light of the Panel’s declarations above. In its re-evaluation of the

applications, the Board should make an objective and independent judgment regarding

whether there are, in fact, well-founded, merits-based public policy reasons for denying

Amazon’s applications. "  I believe this is where the language from Rec 1 came from.  By posting this I am not taking a position one way or the other.  Just publishing the source for that rec.

ACTION ITEM: Consider omitting the bracketed text and only referencing section 12.2.a of the Bylaws.

Recommendation xx (rationale 2): To provide predictability to applicants as well as the Internet community, future GAC Advice for categories of gTLDs (if any), and Board action thereupon, must be issued prior to the finalization of the next Applicant Guidebook. Any GAC Advice issued after the application period has begun must apply to individual strings only, based on the merits and details of the applications for that string, not on groups or classes of applications.

Discussion:

-- GAC understands the need to provide more predictability, there are situations that are not foreseeable.  The unpredictability of such situations will be much lower, but we cannot exclude that possibility.  There will be classes of applications that will require similar treatment and that can’t be known until after the applications are submitted.  We have to balance predictability and that there are policies that require homogeneous treatment where GAC can provide a role.  Request more flexibility in this text.  It is putting GAC advice in a straight jacket.  

-- <COMMENT> It is really odd to codify somewhere in a procedure that an AC cannot advise on something in certain circumstances; it is not compatible (again) with the bylaws.<COMMENT>

-- We are trying to balance the timing of the GAC advice and predictability for applicants.  In 2012 there was advice that came after the fact.  Unfortunately the GAC advice tends to put applicants into a straight jacket, after they have submitted an application assuming that their application meets the necessary requirements.

-- These recommendations are attempts to solve problems, but in a sense we are talking around the problems.  The issue is the problem we are trying to solve: GAC advice just on the basis of timing isn’t fit for purpose -- that is, fitting into the application process.  If we are looking for a way for the GAC to participate meaningfully, that is where we need to go.

-- The problem is not so much GAC advice, it is that we cannot foresee everything.  There are things that appear after the fact; only after we’ve seen all of the applications that have been presented, and some of the advice may pertain to a class of applications.

-- We should be more sophisticated in how we approach this, and see the policy problem as the problem -- balancing the need for predictability and the need to allow flexibility to address GAC advice relating to a class of applications.  

<COMMENT> agree that timeliness is important: maybe the recommendation can be phrased differently; GAC is urged to provide advice, if any, on .... before... <COMMENT>

-- A timeline would be helpful for GAC advice but also for the Board response.

-- I have no issue with advice as to categories of TLDs.  The more that the GAC can contribute during the AGB phase, the better off we will be when the applications are being reviewed.  But I don’t think the GAC can be limited to Advice prior to the applications being revealed.

-- It would make sense for the GAC to consider each application individually.  Even where things come up after the fact, look at the merits of each application.

-- A couple of the reasons we were making this recommendation: 1) some applicants who had particular conditions already in their application got held up in a category; 2) there is a danger if global advice is given about a category, unless those strings are set out exhaustively there is a danger that something gets missed.  In identifying the category the individual strings should be identified and evaluated on their own merit.

-- The problem with the category advice is that it was treated as “one-size-fits-all” advice.  This should be resolvable.

-- The biggest problem we are trying to address is the issue of delay if an applicant is held too long.  The timing of receiving the advice is the issue, but it will depend on the number of applications.

-- Part of the problem with the GAC advice was the Board's inability to respond to the GAC advice in a timely manner and that should be addressed as well.


-- So where the application refers to "compliance" with existing GAC Advice, ICANN Org will verify with GAC that that is the case, if not then that is open to GAC Advice for a specified time period and Board reaction also within a specified time period.

ACTION ITEM: Rewrite the language to focus more on the operational problem vis-a-vis the timing of GAC advice, the need for predictability, and the desire to enable applications to be judged on their merits and not just as part of a class of applications.  Consider also rationale 1 and 3.

Recommendation xx (rationale 3): Consistent with the updated ICANN Bylaws, omit in future editions of the Applicant Guidebook language included in the 2012 AGB section 3.1 that GAC Advice “will create a strong presumption for the ICANN Board that the application should not be approved.” The Working Group believes that this language is not only unnecessary in light of the Bylaws, but has the unintended consequence of hampering the ability for applicants, ICANN org, and the GAC to mitigate concerns, which could allow an application to proceed.

Discussion:

-- GAC advice should not be constrained by the AGB nor should it be expanded beyond what is allowed in the Bylaws.

-- Redraft the recommendations-rationale 1, 2, and 3.

-- Applicants do need some kind of heads up on what the Bylaws actually say.  Need to understand the GAC advice process.  May need to include a reference.

-- Can just connect this to what the Bylaws say.

ACTION ITEM: Reference the applicable sections of the Bylaws and rewrite in consideration with recommendations-rationale 1, 2, and 3.

Recommendation xx (rationale 4): To the extent that there is a decision to allow a longer period for the GAC to provide Early Warnings (above and beyond the public comment period), the application process should define a specific time period during which GAC Early Warnings can be issued and require that the government(s) issuing such Warning(s) include both a written rationale/basis and specific action requested of the applicant. 

Discussion:

-- Think that the recommendation is saying two things but it is a bit mixed.  The first phrase is about the extended time period for GAC early warnings and on the 4th line up to “require” should be a separate sentence because we don’t want to limit that to a specific time period, but something we want in general.  That there is a rationale and specific action requested on the applicant.  Separate into two sentences.

-- Re: “application process should define” should say, “the Applicant Guidebook should define”.  Not meant to imply that there was a separate process.

-- This is trying to say that when a GAC member submits an Early Warning they should make themselves available to an applicant to work things out.

-- Re: “and specific action requested of the applicant.” -- this could be problematic as the government might simply request that the applicant should withdraw the application.  Suggest deleting that text.

-- Why require “rationale” from the GAC?  Maybe replace with “reason” or “explanation” or some other term.

ACTION ITEM: Separate the recommendation into two sentences.

ACTION ITEM: Consider deleting the text, “and specific action requested of the applicant.”

ACTION ITEM: Re: “include both a written rationale/basis” with more collaborative language, such as “reason” or “explanation”. 

Recommendation xx (rationale 5): The applicant must have an opportunity to engage in direct dialogue in response to GAC Early Warnings [and GAC Advice] and amend the application during a specified time period.

-- Good idea for GAC early warnings and GAC advice.

-- The reason why GAC Advice is in brackets is because the original language didn’t include it.  The feedback is supportive of including “and GAC Advice”.

-- Concerned about the use of the word “dialog” as well as the implication that the applicant has some sort of right.  That some governments may not have the ability to engage in that dialog.

ACTION ITEM: Accept and include the text in brackets “and GAC Advice”.

ACTION ITEM: Rewrite to clarify the opportunity for dialog and recognizing that some governments may not have the ability to engage in that dialog.

Recommendation xx (rationale 6): Applicants must be allowed to change the application, including the addition or modification of Registry Voluntary Commitments (RVCs, formerly Voluntary PICs), in response to GAC Early Warnings and/or GAC Advice.

Discussion:

-- Suggestion changing “in response to GAC Early Warnings and/or GAC Advice” to “which address GAC Early Warnings and/or GAC Advice.”  Combine with rationale 5.

-- Wondering whether there are any qualifiers about same strings or contention sets and the applicability of GAC Advice.  There were circumstances in 2012 where some strings in a contention set were problematic and others weren’t re: GAC Advice.

-- To restate: it should not be codified in this recommendation. I was not suggestion that all governments should not have the opportunity, but under no circumstances should the process be held up waiting for 'all' governments to comment.

-- Figure out if there is a different way to state the recommendation.

ACTION ITEM: Consider whether the language can be rewritten to allow a balance with the GAC Early Warning and/or GAC Advice.

b. 2.5.4 Applicant Support

Affirmation xx with modification (rationale 2):

Discussion:

-- Starts as an affirmation but then the language used suggests a recommendation.

-- Affirming the modification of the language from 2012.  But we can state it as a recommendation if that is less confusing.

-- Define the term “non-financial assistance”.

For affirmation 1 and 2, make it clear what is the original affirmation and what is new language.

ACTION ITEM: Consider rewriting as a recommendation.

ACTION ITEM: For affirmation 1 and 2, make it clear what is the original affirmation and what is new language.

Recommendation xx (rationale 3): The Working Group recommends expanding the scope of financial support provided to Applicant Support Program beneficiaries beyond the application fee to also cover costs such as application writing fees, attorney fees related to the application process, and ongoing ICANN registry-level fees.

Discussion:

-- How are we addressing that a registry is able to financially and stably operate their TLD?

-- They also may have non-financial assistance such as a back-end operator may agree to run the TLD for them.  Recognition that there could be a need for support for ongoing ICANN registry-level fees.

Recommendation xx (rationale 4): The Working Group recommends that ICANN seek opportunities to improve outreach, education, application evaluation, and program evaluation elements of the Applicant Support Program, as proposed in the Implementation Guidance below. 

Also, see related Implementation Guidance.

Discussion:

-- Don’t need to say “recommends that ICANN seek opportunities to improve outreach” but just “ICANN improves outreach” -- render into active voice.

-- Can we bracket the recommendation that registry fees be waived or financial support provided please?

-- Replace “education” with “increase awareness”.

-- It seems that the point of departure the group is taking is the Application Support program, rather than the report that lead to the implementation documents.  There were some recommendations in the report that were not implemented in the last round, but the Board asked that they be considered in future.  Do we think the IRT would be the group to look at that?  Then we need to point back to the Joint-Applicant Support Report.

-- What we are saying here is that the GNSO policy process using has just one implementation team, but we are saying we want two implementation teams, one of which is dedicated to the Applicant Support Program.  Also consider regional efforts/documentation.

-- Concern about creating a class of registries that will fail.

-- GAC Underserved Regions will look at these recommendations and come back with comments.

-- Drop “middle countries”.

-- RySG comment: The RySG believes that ICANN's support should be limited to financial support for the application fee. Further involvement in the operational, technical and business aspects of a registry/registrar will only serve to unnecessarily involve ICANN in the operations of a registry/registrar and will serve as a de facto endorsement of certain registries/registrars and set a negative precedent for future entities that want to enter the registry/registrar business.

ACTION ITEMS: Review and rewrite the Implementation Guidance per the comments.  Consider deleting the term “middle applicant”.

c. New issues raised in deliberations since publication of the Initial Report, if applicable.

In considering public comments, the Working Group discussed prioritization of successful Applicant Support applications. Specifically, the Working Group considered whether there should be any changes to the 2012 approach of establishing priority between applications if there are more qualified applicants than funds available. The Working Group did not come to a conclusion on these points, and therefore did not recommend a departure from the 2012 implementation.

Discussion:

-- In terms of At Large discussions, there were thoughts about approaching this from a regional perspective -- maybe having a quota based on regions.  

-- Add something that provides equity among regions.

-- Seems that it would be simpler if the ASP was run as a separate operation to the new gTLD program in some way.  there needs to be separate before any potential application comes into the ASP.  Hard to determine if we don’t know how much funding is available and how many applicants will seek support.

-- That’s why we have the recommendation that ICANN should establish a pool.

-- Need to reference the definitional work being done by ICANN.  Referenced in d. but maybe include in the rationale.

ACTION ITEM: Reference in rationale 4 the definitional work being done by ICANN.