[Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC

[Cheryl Langdon-Orr]

Thanks Julie for these timely and useful high level notes, being in transit
between international flight now , but having had to "just miss" our call,
I appreciate how very useful they are...

Kindest regards

On Mon, Feb 10, 2020, 20:50 Julie Hedlund <julie.hedlund at icann.org> wrote:

> Dear Working Group members,
>
>
>
> Please see below the notes from the meeting on 10 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-10+New+gTLD+Subsequent+Procedures+PDP
> .
>
>
>
> Kind regards,
> Julie
>
>
>
> *Notes and Action Items:*
>
>
>
> *Actions:*
>
>
>
> 2.2.3 Applications Assessed in Rounds:
>
> *Implementation Guidance xx (see rationale 2)*:
>
>  ACTION ITEM: Take the contents of Jeff Neuman’s email into Implementation
> Guidance (amended for clarity as necessary).
>
> ACTION ITEM: WG members will be invited to present a minority view.
>
>
>
> *Proposal from Alexander Schubert*:  “If a string has been evaluated and
> is not approved by ICANN – the application will be withdrawn BY ICANN once
> all appeals and accountability mechanisms are exhausted (no input by the
> applicant required; prevents “blocking of a string forever”).”
>
> ACTION ITEM: Take the discussion of Alexander Schubert’s proposal to the
> email list.
>
>
>
> 2.2.6 RSP Pre-Approval:
>
> *Recommendation xx (Rationale 1)*:
>
> ACTION ITEM: Add after first sentence: “may receive pre-approval by ICANN
> if they pass the required technical evaluation and testing conducted by
> ICANN, or their selected third party provider.”
>
>
>
> *Implementation Guidance xx (rationale 7)*:
>
> ACTION ITEM: Re-write to clarify.
>
>
>
> *Recommendation xx (rationale 5):*
>
> ACTION ITEM: Add some language in a note about the comment from Donna
> Austen about whether we can get details concerning the costs.
>
>
>
> *Recommendation xx (rationale 6):*
>
> ACTION ITEM: Change the first sentence to read “The list of pre-approved
> RSPs must be published…”
>
>
>
> *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
>
>
>
> a. 2.2.3 Applications Assessed in Rounds (brief continued discussion –
> page 4)
>
>
>
> -- Spent a lot of time on how we perceived a subsequent round if there are
> still applications in process.
>
> -- Current language:
>
> *Implementation Guidance xx (see rationale 2)*: It should not be possible
> to apply for a string that is still being processed from a previous
> application round [PROVIDED THE APPLICANT(S) for that same string  FROM THE
> PRIOR ROUND HAVE AGREED IN WRITING TO FOLLOW ALL UPDATED POLICY provisions
> prior TO THE OPENING OF THE NEXT ROUND.  DING ADOPTED BY NEW POLICIES]. OR
> Do not process applications further than the reveal stage for a string that
> is still being processed from a previous application round, unless and/or
> until the applications from the previous round that match those strings
> have had their final disposition.
>
>
>
> Email from Jeff Neuman: See
> http://mm.icann.org/pipermail/gnso-newgtld-wg/2020-February/002434.html
>
>
>
> *Discussion*:
>
> -- Question: What does “on hold” mean?  Answer: Subject of GAC advice or
> challenge from right of first refusal; didn’t apply to many.  Means the
> application is still being processed.  Subject of an appeal or
> accountability mechanism. .IDN is still in an accountability mechanism.
>
> -- Question: What does Application Support mean as a category?  Answer:
> That the application is being evaluated for application support.
>
> -- Seems like most of the edge cases will have been addressed by the Board.
>
> -- The principle suggested by Anne Aikman-Scalese that there could be
> backup applications would not be allowed on the current suggested policy
> where there are policy issues involved (on hold, brand issue,
> appeal/accountability mechanisms).
>
> -- Allowing backup applications would add lots of complications and
> unintended consequences.  Simpler to have a rule to say if it is in any of
> these statuses you can’t apply for it.
>
> -- There should be pressure on prior applicants to meet new policy.
>
> -- But that assumes that there is new policy, and not sure we can assume
> that.
>
> -- Question: How long do you let an application "hang out" without any
> pending mechanisms on it? Answer: There are timelines for accountability
> mechanisms in the Bylaws and we’ll be setting implementation guidance when
> we discuss appeals.
>
> -- Why assume that people will want to apply for the problematic strings
> (those that had name collisions) and assume that those problems will be
> resolved?
>
> -- Anne Aikman-Scalese: I am not talking about 6.c "Not approved" only.  I
> am talking about most of your detailed categories - many of which prohibit
> back-up offers that will lock applicants out until another window opens up
> - perhaps much later, e.g. in the case of appeals and accountability
> mechanisms.
>
> ACTION ITEM: Take the contents of Jeff’s email into Implementation
> Guidance (amended for clarity as necessary).
>
> ACTION ITEM: WG members will be invited to present a minority view.
>
>
>
> Proposal from Alexander Schubert:  “If a string has been evaluated and is
> not approved by ICANN – the application will be withdrawn BY ICANN once all
> appeals and accountability mechanisms are exhausted (no input by the
> applicant required; prevents “blocking of a string forever”).”  See:
> http://mm.icann.org/pipermail/gnso-newgtld-wg/2020-February/002431.html
>
> Question: Currently there is no mechanism to force the withdrawal of an
> application for a string.  Should we create one?
>
>
>
> *Discussion*:
>
> -- Does this trigger the necessity to exhaust all remedies?
>
> -- Support Alexander’s proposal to include a provision to force
> withdrawals in the case where the Board says the application shouldn’t
> proceed and there should be a refund.
>
> -- What happens if the Board says the application won’t proceed for now --
> “not approved” is not the same as “rejected”?  We could always say that the
> Board needs to be explicit.
>
> -- Strings that were rejected due to objection - and can't move forward
> (e.g. a city or a religious community). Should be withdrawn to allow others
> to apply for it in the future.
>
> ACTION ITEM: Take the discussion of Alexander Schubert’s proposal to the
> email list.
>
>
>
> b. 2.2.6 RSP Pre-Approval (page 20)
>
>
>
> -- Email from Jim Predergast: Could we call this two phases of testing,
> rather than “pre-approval”.  Have two phases -- second phase would be
> everything in schedule A, that is unique to each TLD.  Avoid the
> implication of “pre-approval”.  So, call it “passed Phase 1 testing”.
>
> -- Assumption is that there will be a phase 2 of testing.
>
> -- We are trying to signify RSPs that have passed an initial evaluation.
> Is there a way of indicating that without using the word “approval”?
>
> -- We went to “pre-approval” to avoid the terminology of “certification”.
>
> -- Hard not to get bogged down in trying to find a word that is acceptable
> to all.
>
> -- We could add explanatory language as to what “pre-approval” means.
>
> -- New data from ICANN reinforces that there continue to be problems with
> registry back-end operators.
>
> -- Explanatory language would only work for insiders -- outsiders would
> see that as approval.
>
> -- Continue this discussion on the list.
>
> -- The testing part would apply to both, the only difference is the timing.
>
> -- Other terminology for Recommendation xx (Rationale 1): “... may receive
> pre-approval if they pass the required technical evaluation and testing
> conducted by ICANN, or their selected third party provider.”
>
> -- Or call it “Pre-testing Program” or “ Pre-qualification”.
>
> ACTION ITEM: Amend Recommendation xx (Rationale 1): add after first
> sentence: “may receive pre-approval by ICANN if they pass the required
> technical evaluation and testing conducted by ICANN, or their selected
> third party provider.”
>
>
>
> *Implementation Guidance xx (rationale 7)*:  With respect to each
> subsequent round, ICANN org may establish a separate more streamlined
> process for reassessments in terms of evaluation and testing than those
> entities seeking RSP pre-approval for the first time.
>
>
>
> *Discussion*:
>
> -- We don’t know how this will go in the next round.
>
> -- Probably easier to say that we stay the same as what we had before, but
> if there is an opportunity for ICANN to streamline the process they should
> be allowed to do so.
>
> -- We are saying that there could be a much more extensive pre-approval
> process, but for reassessment it might be less extensive.
>
> -- Need to clarify the wording.
>
> -- Should defer to the SSAC as technical experts and ICANN staff.
>
> -- Saying that RSPs do not have technical expertise might be wrong SSAC
> and ICANN does not necessarily have understanding of all aspects of the
> inner work of Registries backends.
>
> ACTION ITEM: Re-write to clarify.
>
>
>
> *Recommendation xx (rationale 5):*  The RSP pre-approval program must be
> funded by those seeking pre-approval on a cost-recovery basis. Costs of
> the program should be established during the implementation phase by the
> Implementation Review Team and/or ICANN org.
>
>
>
> *Discussion*:
>
> -- Really would like to understand what those costs are.
>
> -- Important, if possible, to get some indicative costs.  If the costs are
> prohibitive then we won’t get anyone using the pre-approval program.  Flag
> to come back to this.
>
> -- Not sure that we’ll have information on the costs during the PDP.
> Should have a better understanding during implementation.
>
> ACTION ITEM: Add some language in a note about the comment from Donna
> Austen about whether we can get details concerning the costs.
>
>
>
> *Recommendation xx (rationale 6):* Results of an RSP Pre-Approval Program
> must be published on ICANN’s website with all of the other new gTLD
> materials and must be available to be used by potential applicants with an
> adequate amount of time to determine if they wish to apply for a gTLD using
> a Pre-Approved RSP.
>
>
>
> *Discussion*:
>
> -- Could we narrow this so that there could be security purposes to not
> publish?
>
> -- Say that “the list of pre-approved RSPs will be published”.
>
> ACTION ITEM: Change the first sentence to read “The list of pre-approved
> RSPs must be published…”
>
>
>
> 3. Work Plan
>
>
>
> -- See email from Jim Prendergast on the Work Plan:
> http://mm.icann.org/pipermail/gnso-newgtld-wg/2020-February/002442.html.
>
> -- Topics for the next meeting at 0300 UTC on 13 February are: Universal
> Acceptance and Registry System Testing.
>
>
>
> 4. Topics for ICANN67
>
>
>
> -- Working with the GAC to identify topics.
>
> -- Will provide briefing documents to help guide discussions.
>
> -- GAC members will be able to attend the SubPro PDP WG meetings because
> they will not have conflicts for those sessions.
>
> _______________________________________________
> Gnso-newgtld-wg mailing list
> Gnso-newgtld-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20200210/590aedb3/attachment-0001.html>