Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC
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+Pro.... 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/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52... 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.
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@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+Pro... .
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/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52...
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@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.
Dear Cheryl, We’re so glad that you find them to be useful. Thanks so much for letting us know! Kind regards, Julie From: Cheryl Langdon-Orr <langdonorr@gmail.com> Date: Monday, February 10, 2020 at 12:05 PM To: Julie Hedlund <julie.hedlund@icann.org> Cc: "gnso-newgtld-wg@icann.org" <gnso-newgtld-wg@icann.org> Subject: [Ext] Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC 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@icann.org<mailto:julie.hedlund@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+Pro.... 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/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52... [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_documen...> 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@icann.org<mailto:Gnso-newgtld-wg@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 [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p...>) and the website Terms of Service (https://www.icann.org/privacy/tos [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t...>). 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.
Hi Julie – one addition on the Actions from 2.2.6 RSP Pre-Approval Its buried in the notes but the action item should be to come up with a term that describes the program but replaces the term “Approval” because of the implications that may convey in light of the recent EBERO/SLAM data we received. Concerns are further described in my email to the list from Jan 30 - https://mm.icann.org/pipermail/gnso-newgtld-wg/2020-January/002400.html and supported by Rubes on list and a few others on the call earlier today. Jim Prendergast The Galway Strategy Group +1 202-285-3699 From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Julie Hedlund Sent: Monday, February 10, 2020 11:51 AM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC 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+Pro.... 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/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52... 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.
Thanks Jim for this note. Would “RSP Preliminary Qualification” work for you? Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Jim Prendergast Sent: Monday, February 10, 2020 1:48 PM To: Julie Hedlund <julie.hedlund@icann.org>; gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC [EXTERNAL] ________________________________ Hi Julie – one addition on the Actions from 2.2.6 RSP Pre-Approval Its buried in the notes but the action item should be to come up with a term that describes the program but replaces the term “Approval” because of the implications that may convey in light of the recent EBERO/SLAM data we received. Concerns are further described in my email to the list from Jan 30 - https://mm.icann.org/pipermail/gnso-newgtld-wg/2020-January/002400.html and supported by Rubes on list and a few others on the call earlier today. Jim Prendergast The Galway Strategy Group +1 202-285-3699 From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Julie Hedlund Sent: Monday, February 10, 2020 11:51 AM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC 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+Pro.... 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/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52... 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. ________________________________ 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.
The “RSP Pre-Qualification Process”? I think that could work. Jim? Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Aikman-Scalese, Anne Sent: Monday, February 10, 2020 4:12 PM To: Jim Prendergast <jim@GALWAYSG.COM>; Julie Hedlund <julie.hedlund@icann.org>; gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC Thanks Jim for this note. Would “RSP Preliminary Qualification” work for you? Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Jim Prendergast Sent: Monday, February 10, 2020 1:48 PM To: Julie Hedlund <julie.hedlund@icann.org<mailto:julie.hedlund@icann.org>>; gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC [EXTERNAL] ________________________________ Hi Julie – one addition on the Actions from 2.2.6 RSP Pre-Approval Its buried in the notes but the action item should be to come up with a term that describes the program but replaces the term “Approval” because of the implications that may convey in light of the recent EBERO/SLAM data we received. Concerns are further described in my email to the list from Jan 30 - https://mm.icann.org/pipermail/gnso-newgtld-wg/2020-January/002400.html and supported by Rubes on list and a few others on the call earlier today. Jim Prendergast The Galway Strategy Group +1 202-285-3699 From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Julie Hedlund Sent: Monday, February 10, 2020 11:51 AM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC 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+Pro.... 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/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52... 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. ________________________________ 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. ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://comlaude.com>
How about The RSP Testing Program… and if an RSP passes evaluation they are referred to as having passed the RSP Testing Program and can be put on an RSP Testing Program Pass List. And if there is a need for additional testing, they have passed Phase 1. And proceed to Phase 2. Jim Prendergast The Galway Strategy Group +1 202-285-3699 From: Jeff Neuman <jeff.neuman@comlaude.com> Sent: Tuesday, February 11, 2020 11:44 AM To: Aikman-Scalese, Anne <AAikman@lrrc.com>; Jim Prendergast <jim@GALWAYSG.COM>; Julie Hedlund <julie.hedlund@icann.org>; gnso-newgtld-wg@icann.org Subject: RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC The “RSP Pre-Qualification Process”? I think that could work. Jim? Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Aikman-Scalese, Anne Sent: Monday, February 10, 2020 4:12 PM To: Jim Prendergast <jim@GALWAYSG.COM<mailto:jim@GALWAYSG.COM>>; Julie Hedlund <julie.hedlund@icann.org<mailto:julie.hedlund@icann.org>>; gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC Thanks Jim for this note. Would “RSP Preliminary Qualification” work for you? Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Jim Prendergast Sent: Monday, February 10, 2020 1:48 PM To: Julie Hedlund <julie.hedlund@icann.org<mailto:julie.hedlund@icann.org>>; gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC [EXTERNAL] ________________________________ Hi Julie – one addition on the Actions from 2.2.6 RSP Pre-Approval Its buried in the notes but the action item should be to come up with a term that describes the program but replaces the term “Approval” because of the implications that may convey in light of the recent EBERO/SLAM data we received. Concerns are further described in my email to the list from Jan 30 - https://mm.icann.org/pipermail/gnso-newgtld-wg/2020-January/002400.html and supported by Rubes on list and a few others on the call earlier today. Jim Prendergast The Galway Strategy Group +1 202-285-3699 From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Julie Hedlund Sent: Monday, February 10, 2020 11:51 AM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC 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+Pro.... 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/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52... 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. ________________________________ 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. ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://comlaude.com>
Thanks Jim. This has been a discussion item for the leadership team all day today and we believe we have come up with the perfect name………………………….. Bu you need to be on the call in 5 hours or so to find out 😊 Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> From: Jim Prendergast <jim@GALWAYSG.COM> Sent: Wednesday, February 12, 2020 4:28 PM To: Jeff Neuman <jeff.neuman@comlaude.com>; Aikman-Scalese, Anne <AAikman@lrrc.com>; Julie Hedlund <julie.hedlund@icann.org>; gnso-newgtld-wg@icann.org Subject: RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC How about The RSP Testing Program… and if an RSP passes evaluation they are referred to as having passed the RSP Testing Program and can be put on an RSP Testing Program Pass List. And if there is a need for additional testing, they have passed Phase 1. And proceed to Phase 2. Jim Prendergast The Galway Strategy Group +1 202-285-3699 From: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com>> Sent: Tuesday, February 11, 2020 11:44 AM To: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>>; Jim Prendergast <jim@GALWAYSG.COM<mailto:jim@GALWAYSG.COM>>; Julie Hedlund <julie.hedlund@icann.org<mailto:julie.hedlund@icann.org>>; gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC The “RSP Pre-Qualification Process”? I think that could work. Jim? Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Aikman-Scalese, Anne Sent: Monday, February 10, 2020 4:12 PM To: Jim Prendergast <jim@GALWAYSG.COM<mailto:jim@GALWAYSG.COM>>; Julie Hedlund <julie.hedlund@icann.org<mailto:julie.hedlund@icann.org>>; gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC Thanks Jim for this note. Would “RSP Preliminary Qualification” work for you? Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Jim Prendergast Sent: Monday, February 10, 2020 1:48 PM To: Julie Hedlund <julie.hedlund@icann.org<mailto:julie.hedlund@icann.org>>; gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC [EXTERNAL] ________________________________ Hi Julie – one addition on the Actions from 2.2.6 RSP Pre-Approval Its buried in the notes but the action item should be to come up with a term that describes the program but replaces the term “Approval” because of the implications that may convey in light of the recent EBERO/SLAM data we received. Concerns are further described in my email to the list from Jan 30 - https://mm.icann.org/pipermail/gnso-newgtld-wg/2020-January/002400.html and supported by Rubes on list and a few others on the call earlier today. Jim Prendergast The Galway Strategy Group +1 202-285-3699 From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Julie Hedlund Sent: Monday, February 10, 2020 11:51 AM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC 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+Pro.... 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/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52... 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. ________________________________ 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. ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://comlaude.com> ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://comlaude.com>
participants (5)
-
Aikman-Scalese, Anne -
Cheryl Langdon-Orr -
Jeff Neuman -
Jim Prendergast -
Julie Hedlund