[Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 25 June at 20:00 UTC

[Julie Hedlund]

Dear Working Group members,

Please see below the notes from the meeting on 25 June at 20:00 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-06-25+New+gTLD+Subsequent+Procedures+PDP.

Kind regards,
Julie

Notes and Action Items:

Actions:

Predictability Framework:

The SPIRT may develop policy and undermine Council remit.
ACTION ITEM: Revised to include the bracketed text: “The SPIRT’s functions include issue triage and providing advice on operational issues. It is not a policy-making body [and will not knowingly develop policy].
ACTION ITEM: Update the table on page 8.
ACTION ITEM: Revise to include the bracket text: “The SPIRT’s functions include issue triage and providing advice on [non-minor] operational issues.”

The SPIRT could be subject to the influence of lobbying (e.g., targeting other applications, re-opening issues, invoking the Framework in the first place, other?).
ACTION ITEM: Add “The SPIRT cannot assign itself work; it must be assigned by the GNSO Council, the ICANN Board, or ICANN org.

ICANN Org will be able to make certain decisions on its own without consulting with the community (i.e., bucket 1). This could include mis-categorizing an issue (either purposely or as a matter of subjectivity).
ACTION ITEM: Add
-- A recommendation/IG for ICANN Org to maintain a change log (and allow for subscriptions).
-- Council maintains a supervisory role over the SPIRT.
-- All recommendations are subject to the review and oversight of the GNSO Council, who maintains the discretion on whether or not to adopt the recommendations made to the Council.

It is unclear why the SPIRIT is better positioned compared to others in determining what is policy versus implementation.
ACTION ITEM: Add as IG about making the Framework and SPIRIT clear.

Determining which ”bucket” something is in will not always be clear.
ACTION ITEM: Add a recommendation/IG for ICANN Org to maintain a change log (and allow for subscriptions).

The Framework and SPIRT are too complicated and GAC Concern [it is not clear that they create value versus existing mechanisms for issue mitigation.]
ACTION ITEM: Create a “PR” document.

GAC Concern - The Framework and SPIRT may undermine existing roles and responsibilities afforded to the ICANN organizations under the ICANN Bylaws.
ACTION ITEM: Add “The SPIRIT is representative.”
ACTION ITEM: Add a recommendation/IG for ICANN Org to maintain a change log (and allow for subscriptions).

"Can't Live With" comments on Package 5:

2.8.2 Limited Challenge/Appeal Mechanism
a. Recommendations and/or implementation guidelines

Affirmation xx (rationale 1): [Proposed alternate text to Affirmation xx (rationale 1), in order to match text in section Objections: Affirmation xx with modification (rationale 1): Recommendation 12 from 2007 states: “Dispute resolution and challenge processes must be established prior to the start of the process.” Consistent with Implementation Guidance xx below, the Working Group affirms Recommendation 12 with the following modification in italicized text: “Dispute resolution and challenge processes must be established prior to the start of the process, the details of which must be published in the Applicant Guidebook.”]
ACTION ITEM: The WG agreed to adopt the revised text.

Recommendation xx (rationale 2): The Working Group recommends that ICANN establish a mechanism that allows specific parties to challenge or appeal certain types of actions or inactions that [are] [appear to be] inconsistent with the Applicant Guidebook.
ACTION ITEM: The WG agreed to include the bracketed language.

“The Working Group recommends that the limited challenge/appeal mechanism applies to the following types of evaluations and [formal] objections decisions”
KK5.2 - Kathy Kleiman proposed adding the word "formal" to this sentence. Rationale: "The term “formal objection” comes from the current AGB (see current Module 3) and it may help to flag readers to understand the important distinction of evaluation changes and objection appeals – a clarity issue."
ACTION ITEM: The WG agreed to include the bracketed language, but make sure we are being consistent in our report.

Implementation Guidance xx (rationale 5):
ACTION ITEM: Change Annex xx to add the ability of challenging “standing” as a ground for appeal.

Implementation Guidance xx (rationale 6):
ACTION ITEM: The WG agrees to the change to "New panel with different RSTEP panelists selected from the standing roster."

Implementation Guidance xx (rationale 7):
ACTION ITEM: Check in the AGB to see how that situation is handled and add to the rationale.

Rationale for Affirmation xx (rationale 1):
ACTION ITEM: The WG agrees to the update based on previous suggestion from Justine.

Rationale for Implementation Guidance xx (rationale 4): In general, the Working Group believes that parties affected by an evaluation or objections decision should have the opportunity to file a challenge/appeal [under limited circumstances]. The affected parties for each type of evaluation and objection under different circumstances are outlined in Annex xx.
ACTION ITEM: The WG agrees to include the text in brackets.

Notes:

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

2. Continue to review the Predictability Framework, see: https://docs.google.com/document/d/1vBckhFQCCQ-zyvfGGcDB3NWQhodVsffdqbyb6kTwXL4/edit?usp=sharing and the attached chart.

General Discussion:
-- Concerns about not having time to review the document.
-- Make sure we are following the rules for IRT.  We did incorporate that into the framework document.
-- SPIRT should be the screening tool for everything that arises, not staff.

The SPIRT may develop policy and undermine Council remit.
-- Could we add a bullet that says the SPIRIT will not knowingly develop Policy.
-- re: “The SPIRT’s functions include issue triage and providing advice on operational issues. It is not a policy-making body.”   How does "operational issues" reconcile with "operational changes"?  Is the table on page 8 outdated --- yes.
-- So back to the 2nd bullet mitigation for the 1st concern .... should it be ....."NON-MINOR operational issues"?

ACTION ITEM: Revise to include the bracketed text: “The SPIRT’s functions include issue triage and providing advice on operational issues. It is not a policy-making body [and will not knowingly develop policy].
ACTION ITEM: Update the table on page 8.
ACTION ITEM: Revise to include the bracket text: “The SPIRT’s functions include issue triage and providing advice on [non-minor] operational issues.”

The SPIRT could be subject to the influence of lobbying (e.g., targeting other applications, re-opening issues, invoking the Framework in the first place, other?).
-- Missing from the mitigation about lobbying – SPIRT cannot assign itself work.

ACTION ITEM: Add “The SPIRT cannot assign itself work; it must be assigned by the GNSO Council, the ICANN Board, or ICANN org.

ICANN Org will be able to make certain decisions on its own without consulting with the community (i.e., bucket 1). This could include mis-categorizing an issue (either purposely or as a matter of subjectivity).
-- Every decision should involve the SPIRT before ICANN Org would implement it – that is, ICANN Org would not be able to make any implementation decisions.
-- Concerns about the SPIRT becoming a bottleneck.
-- Could be a change log.
-- But the notion that you are going to have staff determining when an issue arises whether it should be referred to the SPIRT or not brings us back to the original problem.
-- We tend to think of major changes, but the WG should think about changes like last time where ICANN Org  created a custom-made ticketing system for support, but it didn’t work so ICANN Org went to an off-the-shelf software.  Do we really want the SPIRT to make that decision?
-- Suggest that when staff "encounters an issue" during the implementation phase, they need to advise GNSO Council and the SPIRT of the change.
-- Could add that “The GNSO Council retains review and oversight.”
-- Could add “Council maintains a supervisory role over the SPIRT.”

ACTION ITEM: Add
-- A recommendation/IG for ICANN Org to maintain a change log (and allow for subscriptions).
-- Council maintains a supervisory role over the SPIRT.
-- All recommendations are subject to the review and oversight of the GNSO Council, who maintains the discretion on whether or not to adopt the recommendations made to the Council.

It is unclear why the SPIRIT is better positioned compared to others in determining what is policy versus implementation.
-- This seems like a marketing issue – the mitigation point is that staff/somebody will come up with a simple guide on how the SPIRT works.

ACTION ITEM: Add as IG about making the Framework and SPIRIT clear.

Determining which ”bucket” something is in will not always be clear.

ACTION ITEM: Add a recommendation/IG for ICANN Org to maintain a change log (and allow for subscriptions).

The Framework and SPIRT are too complicated and GAC Concern [it is not clear that they create value versus existing mechanisms for issue mitigation.]

ACTION ITEM: Create a “PR” document.

GAC Concern - The Framework and SPIRT may undermine existing roles and responsibilities afforded to the ICANN organizations under the ICANN Bylaws.
-- We also don't want to limit to "from", since this would restrict membership. For instance, GAC Secretariat is not a GAC Member.

ACTION ITEM: Add “The SPIRIT is representative.”
ACTION ITEM: Add a recommendation/IG for ICANN Org to maintain a change log (and allow for subscriptions).

What to do with this document?  Could be included as an annex, but might be cleaner to include it as rationale, particularly where there is new Implementation Guidance.  Update the text of the documents and the flow chart and schedule for the meeting on Thursday, 02 July.

3. Continue to review "Can't Live With" comments on Package 5, start on page 80: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQLuQuo/edit?usp=sharing (time permitting)

2.8.2 Limited Challenge/Appeal Mechanism

a. Recommendations and/or implementation guidelines

Affirmation xx (rationale 1): The Working Group affirms Recommendation 12 from 2007, which states: “Dispute resolution and challenge processes must be established prior to the start of the process.”

[Proposed alternate text to Affirmation xx (rationale 1), in order to match text in section Objections: Affirmation xx with modification (rationale 1): Recommendation 12 from 2007 states: “Dispute resolution and challenge processes must be established prior to the start of the process.” Consistent with Implementation Guidance xx below, the Working Group affirms Recommendation 12 with the following modification in italicized text: “Dispute resolution and challenge processes must be established prior to the start of the process, the details of which must be published in the Applicant Guidebook.”]

JC5.3 - Justine notes that there is an inconsistency between the above affirmation and the affirmation with modification under section Objections. Suggested solution: "Perhaps, adopt the (final) text for the affirmation of Recommendation 12 under “Objections”?" Rationale: "Insofar as the topic of Objections serves as an antecedent to this topic of Limited Challenge/Appeal Mechanism, is there an inconsistency with the approach the WG is taking in (possibly) affirming Recommendation 12 with modification under the topic of Objections?"

Discussion:
-- Good suggestion.  Original language is vague.  In line with what we state in the Objections section.

ACTION ITEM: The WG agreed to adopt the revised text.

Recommendation xx (rationale 2): The Working Group recommends that ICANN establish a mechanism that allows specific parties to challenge or appeal certain types of actions or inactions that [are] [appear to be] inconsistent with the Applicant Guidebook.
KK5.1 - Kathy Kleiman proposed replacing the word "are" with "appear to be." Rationale: "It’s not inconsistent with the Applicant Guidebook until there is a finding as such. Until then, the applicant is making an allegation!"

ACTION ITEM: The WG agreed to include the bracketed language.

The Working Group recommends that the limited challenge/appeal mechanism applies to the following types of evaluations and [formal] objections decisions
KK5.2 - Kathy Kleiman proposed adding the word "formal" to this sentence. Rationale: "The term “formal objection” comes from the current AGB (see current Module 3) and it may help to flag readers to understand the important distinction of evaluation changes and objection appeals – a clarity issue."

ACTION ITEM: The WG agreed to include the bracketed language, but make sure we are being consistent in our report.

Implementation Guidance xx (rationale 5): The type of decision that may be challenged/appealed should vary depending on the process being challenged/appealed. The Working Group’s guidance on this issue is summarized in Annex xx.

JC5.5 - The nature of this intervention is more inquisitorial at this point and as pointed out earlier, the topic of Limited Challenge/Appeal Mechanism with Annex xx is very much connected to the topic of Objections. I am happy to take this up again when we consider the topic of Objections provided that Annex xx is still open for further edits. The key question here is whether the draft recommendation and/or Implementation Guidance under Objections which confirms the ALAC as an established institution for the purposes of a Community Objection, altogether removes any requirement on the part of the DRSP to find on the issue of standing to object vis a vis the ALAC. If the answer is yes, then Annex xx is necessarily complete. If the answer is no, then Annex xx may need to be clarified to include “standing” as a ground of appeal.

Discussion:
-- We did discuss this in the Sub Group on Objections and didn’t agree to make any changes.
-- Need to change the Annex to the grounds of “standing”.
-- ALAC is likely to disagree with this change.
-- This is just about the availability of an appeal, not whether a group has standing.

ACTION ITEM: Change Annex xx to add the ability of challenging “standing” as a ground for appeal.

Implementation Guidance xx (rationale 6):
RK5.3 - See https://docs.google.com/spreadsheets/d/1R4eU7C-HI5ikF5RtVhp5JRXKVVRn6R8WX8fIU0IOwu8/edit#gid=0<https://www.google.com/url?q=https://docs.google.com/spreadsheets/d/1R4eU7C-HI5ikF5RtVhp5JRXKVVRn6R8WX8fIU0IOwu8/edit%23gid%3D0&sa=D&ust=1593116396396000&usg=AFQjCNGAmEu-zDQ8We2phqcvMwHphxIflA> (Tab 1, cell E14). For challenge of Registry Services Evaluation decision, the arbiter of the challenge is currently listed as: "Existing evaluator entity - different ultimate decision maker(s) within the entity." Rubens Kuhl proposes changing this to "New panel with different RSTEP panelists selected from the standing roster." Rationale: "RSTEP is not done by entities, so the arbiter of challenge needs to be changed."

ACTION ITEM: The WG agrees to the change to "New panel with different RSTEP panelists selected from the standing roster."

Implementation Guidance xx (rationale 7): For all types of appeals to objections, the parties to a proceeding must be given the opportunity to mutually agree upon a single panelist or a three-person panel, bearing the costs accordingly.

KK5.4 - Kathy Kleiman asked a question: "What if the parties don’t agree, e.g., one wants a single panelist (or that is all they can afford) and the other party(ies) want three panelists? Default perhaps one panelist?"

ACTION ITEM: Check in the AGB to see how that situation is handled and add to the rationale.

b. Deliberations and rationale for recommendations and/or implementation guidelines

Rationale for Affirmation xx (rationale 1): The Working Group believes that it is important for New gTLD Program elements to be predictable for applicants and other interested parties. By establishing dispute resolution and challenge processes in advance, ICANN provides a greater degree of predictability. Therefore, the Working Group affirms Recommendation 12 from the 2007 policy.

JC5.4 - Rationale requires update corresponding to JC5.3 above.

ACTION ITEM: The WG agrees to the update.

Rationale for Implementation Guidance xx (rationale 4): In general, the Working Group believes that parties affected by an evaluation or objections decision should have the opportunity to file a challenge/appeal [under limited circumstances]. The affected parties for each type of evaluation and objection under different circumstances are outlined in Annex xx.

ACTION ITEM: The WG agrees to include the text in brackets.

2.4 Application Change Requests

Recommendation xx (rationale 3):
[Proposed new Implementation Guidance: Implementation Guidance xx (rationale 3): Insofar as it is feasible, ICANN org should explore the possibility of allowing applicants to delay evaluation pending early submission of an applicant change request on the basis of business combination or other forms of joint ventures, so as to facilitate evaluation (instead of re-evaluation) of the new combined venture or entity, in an effort to save time and cost.]

JC5.6 - Justine Chew proposed adding new Implementation Guidance. Rationale: "In the interest of transparency and predictability, it should be clarified if application change requests are allowed immediately after close of the application period and when all applied-for strings and corresponding applicants are revealed.  Where permissible, we should consider allowing applicants which have applied for exactly matching strings or strings which in their belief run the risk of being confusingly similar an opportunity to delay their evaluation/reviews pending submission of an applicant change request on the basis of business combination or other forms of joint ventures.  Having to evaluate just the new combined venture or entity will help avoid need for re-evaluation, also save time and costs.
Withdrawals of application and corresponding refunds should be allowed."

Discussion:
-- This causes an undue delay to a community applicant.
-- Do we want to put in some qualifier?  Define “early”?  Instead of making a broad change.
-- Return to this item on the next meeting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20200625/9a201983/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Predictability Framework_Concerns and Mitigation.pdf
Type: application/pdf
Size: 61367 bytes
Desc: Predictability Framework_Concerns and Mitigation.pdf
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20200625/9a201983/PredictabilityFramework_ConcernsandMitigation-0001.pdf>