Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC
Dear Working Group members, Please see below the notes from the meeting on 06 February 2000 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-06+New+gTLD+Subsequent+Pro.... Kind regards, Julie Notes and Action Items: Actions: Work Plan: ACTION ITEM: Staff will send a link to the revised work plan/timeline. 2.2.1 Continuing Subsequent Procedures ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. ACTION ITEM: Change text as follows: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Notes: 1. Updates to Statements of Interest: -- Avri Doria will be participating as one of the Board Liaisons to the WG. The other Board Liaison is Becky Burr. -- Question: What does that mean in terms of the role of the Board Liaison? Answer: Largely a constrained role; carrying things back and forth between the Board caucus that will be following it -- bringing questions and possibly answers. -- The goal is not for us to be participants in the PDP, but we want to avoid surprises, such as something that the Board wouldn’t be able to do. 2. Work Plan -- GNSO Council is trying to ensure realistic deadlines for the PDP WGs and to manage the policy development work. -- One of the PDP 3.0 recommendations that has been implemented is the need for Project Change Requests when the dates of deliverables cannot be met. As you may know the RPMs PDP WG submitted a Project Change Request for the GNSO Council meeting in January and is revising that request. -- The SubPro PDP WG Co-Chairs have been asked to submit a modified work plan along with the Project Change Request for the Council to consider at its meeting on 20 February. -- This is a worst case scenario to avoid having to do another request, but we expect to be able to shave some time off of this. -- New work plan shows the schedule of meetings to cover all of the topics. -- Unless the WG can work faster it would be delivering a Final Report by the end of 2020. -- This is just a preview; a link will be sent later. -- This is assuming a two meetings per week schedule. -- Some of these topics may not take two full meetings, but we’ve built that in as a buffer. -- Some things we could do to streamline this. One that we’ll suggest to the WG and GNSO Council is to have a couple of extended sessions in April and May -- in lieu of face-to-face meetings. Such as two 3-hour sessions in April and May we could save a month or more. -- New working method: Take after EPDP and ask the WG members to consider what they can live with, with an emphasis on suggesting solutions. -- Goal is to get the revised work plan and Project Change Request to the Council by early next week. -- Agree that we would need to schedule longer sessions well in advance, say two months. ACTION ITEM: Staff will send a link to the revised work plan/timeline. 3. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52.... Structure: -- Affirmations are confirming the 2012 policy/AGB. -- Recommendations are things that must happen. -- Implementation Guidance are things that should happen. a. 2.2.1 Continuing Subsequent Procedures Affirmation xx (see rationale 1): The Working Group recommends that the existing policy contained in the 2012 Applicant Guidebook, that a “systematized manner of applying for gTLDs be developed in the long term,” be maintained. Affirmation xx (see rationale 2): The Working Group affirms Principle A and recommends that the New gTLD Program must continue to be administered “in an ongoing, orderly, timely and predictable manner.” Affirmation xx (see rationale 3): The Working Group affirms that the primary purposes of new gTLDs are to foster diversity, encourage competition, and enhance the utility of the DNS. Recommendation xx (see rationale 3). Accordingly, the Working Group recommends that meaningful metrics must be identified to understand the impact of the New gTLD Program. The metrics, broadly speaking, should focus on the areas of trust, competition, and choice. To review metrics, data must be collected at a logical time to create a basis against which future data can be compared. Discussion: -- On the recommendation: Should we cite section 5 of the CCT-RT Final Report for the types of data? There is still some uncertainty as to what will be adopted from that Final Report, so it would be preferable that this could be part of Implementation Guidance. Not trying to override ICANN Org’s plans. -- Re: metrics -- never seen any commitment from ICANN Org to collect and publish the metrics as recommended by the CCT Final Report. Don’t see how these can be collected. -- There was discussion in the SubPro Initial Report and in the CCT-RT Final Report; ICANN is aware of the discussions and has a schedule concerning the recommendations. -- Question from ICANN Org re: the recommendation: Is this some other framework that gets set up to measure the trust, competition, and choice goals over time. Answer: Some of it would be part of the implementation; we wanted a general recommendation about collecting data, but didn’t want to get into a debate on the details. We wanted to leave it to implementation as to what types of data would be collected and how. -- Question: Was this particular recommendation adopted by the Board or no? Should we refer to data gathering in accordance with whatever Board adopts in relation to the CCT recommendation? Answer: We will add this as Implementation Guidance. ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. b. 2.2.3 Applications Assessed in Rounds Affirmation xx (with modification) (see rationale 1): The Working Group affirms recommendation 13 from the 2007 policy, which states: “Applications must initially be assessed in rounds until the scale of demand is clear.” However, the Working Group believes that the words “initially” and “until the scale of demand is clear” be removed from the sentence and should just read “Applications must be assessed in rounds.” Recommendation xx (see rationale 2): Upon the commencement of the next Application Submission Period, there must be clarity around the timing and/or criteria for initiating subsequent procedures from that point forth. More specifically, prior to the commencement of the next Application Submission Period, ICANN shall publish either (a) the date in which the next subsequent introduction of new gTLDs will take place or (b) the specific set of criteria and/or events that must occur prior to the opening up of the next subsequent process. Implementation Guidance xx (see rationale 2): A new round may initiate even if steps related to application processing and delegation from previous application windows have not been completed. 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 opportunity. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application opportunity, unless and/or until the applications from the previous round that match those strings have had their final disposition. Discussion: -- Comment: May be worth seeing if the WG can narrow in on a preference here. Or perhaps this makes sense as an unless in a sense, so the date is the preference, unless there is non-exhaustive list of things that would prevent the timely launch? Question: Preference for ICANN Org to set a date, or instead to say what has to happen before a next round? -- In Implementation Guidance we suggested two options since comments were widely varied. -- The first option adds to predictability for applicants. Else applicants may be in limbo for an unknown period of time. -- The second option gets pretty complicated when you are trying to determine contention sets. Not sure how you would do it. -- This is not meant to allow someone to get into an already existing contention set. In both of these cases nothing is going to be processed in a subsequent round until every contention set is resolved and done from the previous round. -- Recommendation: preference is that ICANN publish a date. -- Implementation Guidance: preference is that it should not be possible to apply for a string that is still being processed from a previous application opportunity. -- Disagree that strings from last round should be prohibited. Second option supports the notion of Applicant freedom of expression. -- From a process perspective the above comment would add complications that really aren't warranted. -- No evaluation of the new applicant would occur until the 2012 applications are resolved. The new applicants would have to accept that risk. -- Concerns about treating moribund applications made a decade ago as reservations for the next round. Are the strings that are withdrawn due to name collisions undergoing a process, or are they just on hold? -- What is the harm in keeping a particular string closed for new apps until all the previous applicants have fallen by the wayside. Then it opens up again for all. -- Because the window for application is closed at that point and we haven't said that a new window could open if they all fail. -- If there is agreement that rounds are the path forward, then if a string does not go through in one round it will become available in another round. -- That's one of our recommendations that there will be a series of windows. -- Is there any WG member that would die in a ditch over this option: “It should not be possible to apply for a string in a subsequent round that is still being processed from a previous application round.”? -- Favor the second option. -- Can't live with prohibiting applications for the same string. If "shall not proceed" means new applicants can still apply, I can live with that. -- What about applications that have not progressed on purpose? Or for technical reasons? -- From a pragmatic perspective if we allow for applicants to submit applications for a string that is already in process that adds layers of complexity to the process. If a string hasn’t gone forward to delegation and it becomes available again then it can be applied for. -- We don’t have a system in place that allows for continuing application periods, we have rounds. People should be waiting their turn but they can get in line -- violates applicants’ freedom of expression if they can’t apply. -- The point of the first recommendation is that ICANN Org will set a date certain or criteria that must occur. We are trying to get to a steady state process. -- If someone could apply for a string that is still in process, what we may be encouraging is applicants who might not be fully processed to apply in the next round if they think they are going to fail in the previous round. Need to define in implementation what “in process” means. -- If it would be possible to file applications for the same string in future rounds the door is open for gaming and unknown consequences: applicant(s) from the first round might consider future applicants in their behaviour and decisions. -- Surely, all delegated TLDs or those in process, are off limits. -- I think applicant freedom of expression means you can apply for any string you want, but I don't think that extends to TLDs already in existence or those that are in process in some way. -- Delegated TLDs are not under discussion. -- The point here are those that are not “in process”, so we need to define “in process”. -- Old applications that were denied for a policy reason should have to step up to new policy recommendations if they are going to prevail/ proceed and they should be encouraged to do so by knowing there may be applicants standing in line who are willing to do so. (No stonewalling on new policy recommendations - no blocking based on old policy positions.) -- We already have many categories of Application Status (Active, Applicant Support, Delegated, etc.) -- Question: What about the status “Not Approved”? Answer: That only applies when an application has gone through all of the steps. There will be one or two edge cases. -- Let’s say that we are talking about the names collisions issues and strings that were not delegated -- if new policy is developed by NCAP and may come out of the Board. If there isn’t a new policy they shouldn’t be able to block new applicants. -- An applicant from a prior round who does not want to meet new policy recommendations can block a string forever by not withdrawing a Not Approved application. ACTION ITEM: Change Implementation Guidance to: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Recommendation xx (see rationale 2): Application procedures must take place at predictable, regularly occurring intervals without indeterminable periods of review unless the GNSO Council recommends pausing the program and such recommendation is approved by the Board. Unless and until other procedures are recommended by the GNSO Council and approved by the ICANN Board, ICANN must only use “rounds” as part of the New gTLD Program. Recommendation xx (see rationale 2): Absent extraordinary circumstances, future reviews and/or policy development processes, including the next CCT Review, should take place concurrently with subsequent application rounds. In other words, future reviews and/or policy development processes must not stop or delay subsequent new gTLD rounds. Recommendation xx (See rationale 2). If the outputs of any reviews and/or policy development processes has, or could reasonably have, a material impact on the manner in which application procedures are conducted, such changes must only apply to the opening of the application procedure subsequent to the adoption of the relevant recommendations by the ICANN Board. Discussion: -- Look at these recommendations together. -- If we are clear that applications need to follow all of the timelines before becoming “Not Approved” then they cannot block in future rounds. -- If you have a new policy in the next round that eliminated the problem that blocked a previous string then it should be able to be applied for in the next round. -- Let’s say that .home can move forward but only as a closed generic or .brand where there is a one registrant TLD. What if one of the applicants for .home has no interest in that? Their application needs to be dead. -- Those (.home, .corp, .mail) are not withdrawn even though "not approved". If the Board adopts new name collision policy, old applicants should be willing to step up to the new name collision policy and not be able to refuse to do so and block the string forever by not withdrawing the application. -- Rules should apply in each round to those applicants. -- If you can’t live with the language please suggest new language. -- Problem seems to be how to fix the “Not Approved” applications from the previous round. Board may have to decide how to deal with them. That is out of scope for this WG.
Thanks Julie – Were you able to capture in the notes the views put forward to the effect that a proposal to ban new applications for strings not yet withdrawn is in fact “Policy” and not “Implementation Guidance”? Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Julie Hedlund Sent: Thursday, February 6, 2020 3:02 PM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting on 06 February 2000 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-06+New+gTLD+Subsequent+Pro.... Kind regards, Julie Notes and Action Items: Actions: Work Plan: ACTION ITEM: Staff will send a link to the revised work plan/timeline. 2.2.1 Continuing Subsequent Procedures ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. ACTION ITEM: Change text as follows: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Notes: 1. Updates to Statements of Interest: -- Avri Doria will be participating as one of the Board Liaisons to the WG. The other Board Liaison is Becky Burr. -- Question: What does that mean in terms of the role of the Board Liaison? Answer: Largely a constrained role; carrying things back and forth between the Board caucus that will be following it -- bringing questions and possibly answers. -- The goal is not for us to be participants in the PDP, but we want to avoid surprises, such as something that the Board wouldn’t be able to do. 2. Work Plan -- GNSO Council is trying to ensure realistic deadlines for the PDP WGs and to manage the policy development work. -- One of the PDP 3.0 recommendations that has been implemented is the need for Project Change Requests when the dates of deliverables cannot be met. As you may know the RPMs PDP WG submitted a Project Change Request for the GNSO Council meeting in January and is revising that request. -- The SubPro PDP WG Co-Chairs have been asked to submit a modified work plan along with the Project Change Request for the Council to consider at its meeting on 20 February. -- This is a worst case scenario to avoid having to do another request, but we expect to be able to shave some time off of this. -- New work plan shows the schedule of meetings to cover all of the topics. -- Unless the WG can work faster it would be delivering a Final Report by the end of 2020. -- This is just a preview; a link will be sent later. -- This is assuming a two meetings per week schedule. -- Some of these topics may not take two full meetings, but we’ve built that in as a buffer. -- Some things we could do to streamline this. One that we’ll suggest to the WG and GNSO Council is to have a couple of extended sessions in April and May -- in lieu of face-to-face meetings. Such as two 3-hour sessions in April and May we could save a month or more. -- New working method: Take after EPDP and ask the WG members to consider what they can live with, with an emphasis on suggesting solutions. -- Goal is to get the revised work plan and Project Change Request to the Council by early next week. -- Agree that we would need to schedule longer sessions well in advance, say two months. ACTION ITEM: Staff will send a link to the revised work plan/timeline. 3. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52.... Structure: -- Affirmations are confirming the 2012 policy/AGB. -- Recommendations are things that must happen. -- Implementation Guidance are things that should happen. a. 2.2.1 Continuing Subsequent Procedures Affirmation xx (see rationale 1): The Working Group recommends that the existing policy contained in the 2012 Applicant Guidebook, that a “systematized manner of applying for gTLDs be developed in the long term,” be maintained. Affirmation xx (see rationale 2): The Working Group affirms Principle A and recommends that the New gTLD Program must continue to be administered “in an ongoing, orderly, timely and predictable manner.” Affirmation xx (see rationale 3): The Working Group affirms that the primary purposes of new gTLDs are to foster diversity, encourage competition, and enhance the utility of the DNS. Recommendation xx (see rationale 3). Accordingly, the Working Group recommends that meaningful metrics must be identified to understand the impact of the New gTLD Program. The metrics, broadly speaking, should focus on the areas of trust, competition, and choice. To review metrics, data must be collected at a logical time to create a basis against which future data can be compared. Discussion: -- On the recommendation: Should we cite section 5 of the CCT-RT Final Report for the types of data? There is still some uncertainty as to what will be adopted from that Final Report, so it would be preferable that this could be part of Implementation Guidance. Not trying to override ICANN Org’s plans. -- Re: metrics -- never seen any commitment from ICANN Org to collect and publish the metrics as recommended by the CCT Final Report. Don’t see how these can be collected. -- There was discussion in the SubPro Initial Report and in the CCT-RT Final Report; ICANN is aware of the discussions and has a schedule concerning the recommendations. -- Question from ICANN Org re: the recommendation: Is this some other framework that gets set up to measure the trust, competition, and choice goals over time. Answer: Some of it would be part of the implementation; we wanted a general recommendation about collecting data, but didn’t want to get into a debate on the details. We wanted to leave it to implementation as to what types of data would be collected and how. -- Question: Was this particular recommendation adopted by the Board or no? Should we refer to data gathering in accordance with whatever Board adopts in relation to the CCT recommendation? Answer: We will add this as Implementation Guidance. ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. b. 2.2.3 Applications Assessed in Rounds Affirmation xx (with modification) (see rationale 1): The Working Group affirms recommendation 13 from the 2007 policy, which states: “Applications must initially be assessed in rounds until the scale of demand is clear.” However, the Working Group believes that the words “initially” and “until the scale of demand is clear” be removed from the sentence and should just read “Applications must be assessed in rounds.” Recommendation xx (see rationale 2): Upon the commencement of the next Application Submission Period, there must be clarity around the timing and/or criteria for initiating subsequent procedures from that point forth. More specifically, prior to the commencement of the next Application Submission Period, ICANN shall publish either (a) the date in which the next subsequent introduction of new gTLDs will take place or (b) the specific set of criteria and/or events that must occur prior to the opening up of the next subsequent process. Implementation Guidance xx (see rationale 2): A new round may initiate even if steps related to application processing and delegation from previous application windows have not been completed. 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 opportunity. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application opportunity, unless and/or until the applications from the previous round that match those strings have had their final disposition. Discussion: -- Comment: May be worth seeing if the WG can narrow in on a preference here. Or perhaps this makes sense as an unless in a sense, so the date is the preference, unless there is non-exhaustive list of things that would prevent the timely launch? Question: Preference for ICANN Org to set a date, or instead to say what has to happen before a next round? -- In Implementation Guidance we suggested two options since comments were widely varied. -- The first option adds to predictability for applicants. Else applicants may be in limbo for an unknown period of time. -- The second option gets pretty complicated when you are trying to determine contention sets. Not sure how you would do it. -- This is not meant to allow someone to get into an already existing contention set. In both of these cases nothing is going to be processed in a subsequent round until every contention set is resolved and done from the previous round. -- Recommendation: preference is that ICANN publish a date. -- Implementation Guidance: preference is that it should not be possible to apply for a string that is still being processed from a previous application opportunity. -- Disagree that strings from last round should be prohibited. Second option supports the notion of Applicant freedom of expression. -- From a process perspective the above comment would add complications that really aren't warranted. -- No evaluation of the new applicant would occur until the 2012 applications are resolved. The new applicants would have to accept that risk. -- Concerns about treating moribund applications made a decade ago as reservations for the next round. Are the strings that are withdrawn due to name collisions undergoing a process, or are they just on hold? -- What is the harm in keeping a particular string closed for new apps until all the previous applicants have fallen by the wayside. Then it opens up again for all. -- Because the window for application is closed at that point and we haven't said that a new window could open if they all fail. -- If there is agreement that rounds are the path forward, then if a string does not go through in one round it will become available in another round. -- That's one of our recommendations that there will be a series of windows. -- Is there any WG member that would die in a ditch over this option: “It should not be possible to apply for a string in a subsequent round that is still being processed from a previous application round.”? -- Favor the second option. -- Can't live with prohibiting applications for the same string. If "shall not proceed" means new applicants can still apply, I can live with that. -- What about applications that have not progressed on purpose? Or for technical reasons? -- From a pragmatic perspective if we allow for applicants to submit applications for a string that is already in process that adds layers of complexity to the process. If a string hasn’t gone forward to delegation and it becomes available again then it can be applied for. -- We don’t have a system in place that allows for continuing application periods, we have rounds. People should be waiting their turn but they can get in line -- violates applicants’ freedom of expression if they can’t apply. -- The point of the first recommendation is that ICANN Org will set a date certain or criteria that must occur. We are trying to get to a steady state process. -- If someone could apply for a string that is still in process, what we may be encouraging is applicants who might not be fully processed to apply in the next round if they think they are going to fail in the previous round. Need to define in implementation what “in process” means. -- If it would be possible to file applications for the same string in future rounds the door is open for gaming and unknown consequences: applicant(s) from the first round might consider future applicants in their behaviour and decisions. -- Surely, all delegated TLDs or those in process, are off limits. -- I think applicant freedom of expression means you can apply for any string you want, but I don't think that extends to TLDs already in existence or those that are in process in some way. -- Delegated TLDs are not under discussion. -- The point here are those that are not “in process”, so we need to define “in process”. -- Old applications that were denied for a policy reason should have to step up to new policy recommendations if they are going to prevail/ proceed and they should be encouraged to do so by knowing there may be applicants standing in line who are willing to do so. (No stonewalling on new policy recommendations - no blocking based on old policy positions.) -- We already have many categories of Application Status (Active, Applicant Support, Delegated, etc.) -- Question: What about the status “Not Approved”? Answer: That only applies when an application has gone through all of the steps. There will be one or two edge cases. -- Let’s say that we are talking about the names collisions issues and strings that were not delegated -- if new policy is developed by NCAP and may come out of the Board. If there isn’t a new policy they shouldn’t be able to block new applicants. -- An applicant from a prior round who does not want to meet new policy recommendations can block a string forever by not withdrawing a Not Approved application. ACTION ITEM: Change Implementation Guidance to: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Recommendation xx (see rationale 2): Application procedures must take place at predictable, regularly occurring intervals without indeterminable periods of review unless the GNSO Council recommends pausing the program and such recommendation is approved by the Board. Unless and until other procedures are recommended by the GNSO Council and approved by the ICANN Board, ICANN must only use “rounds” as part of the New gTLD Program. Recommendation xx (see rationale 2): Absent extraordinary circumstances, future reviews and/or policy development processes, including the next CCT Review, should take place concurrently with subsequent application rounds. In other words, future reviews and/or policy development processes must not stop or delay subsequent new gTLD rounds. Recommendation xx (See rationale 2). If the outputs of any reviews and/or policy development processes has, or could reasonably have, a material impact on the manner in which application procedures are conducted, such changes must only apply to the opening of the application procedure subsequent to the adoption of the relevant recommendations by the ICANN Board. Discussion: -- Look at these recommendations together. -- If we are clear that applications need to follow all of the timelines before becoming “Not Approved” then they cannot block in future rounds. -- If you have a new policy in the next round that eliminated the problem that blocked a previous string then it should be able to be applied for in the next round. -- Let’s say that .home can move forward but only as a closed generic or .brand where there is a one registrant TLD. What if one of the applicants for .home has no interest in that? Their application needs to be dead. -- Those (.home, .corp, .mail) are not withdrawn even though "not approved". If the Board adopts new name collision policy, old applicants should be willing to step up to the new name collision policy and not be able to refuse to do so and block the string forever by not withdrawing the application. -- Rules should apply in each round to those applicants. -- If you can’t live with the language please suggest new language. -- Problem seems to be how to fix the “Not Approved” applications from the previous round. Board may have to decide how to deal with them. That is out of scope for this WG. ________________________________ 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.
Just to clarify Anne, are you saying that the proposal to ban new applications for string not yet withdrawn should be labeled as a “recommendation” and opposed to “Implementation Guidance?” If it something different, than please explain. 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: Thursday, February 6, 2020 5:42 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 - 06 February 2000 UTC Thanks Julie – Were you able to capture in the notes the views put forward to the effect that a proposal to ban new applications for strings not yet withdrawn is in fact “Policy” and not “Implementation Guidance”? Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Julie Hedlund Sent: Thursday, February 6, 2020 3:02 PM 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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting on 06 February 2000 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-06+New+gTLD+Subsequent+Pro.... Kind regards, Julie Notes and Action Items: Actions: Work Plan: ACTION ITEM: Staff will send a link to the revised work plan/timeline. 2.2.1 Continuing Subsequent Procedures ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. ACTION ITEM: Change text as follows: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Notes: 1. Updates to Statements of Interest: -- Avri Doria will be participating as one of the Board Liaisons to the WG. The other Board Liaison is Becky Burr. -- Question: What does that mean in terms of the role of the Board Liaison? Answer: Largely a constrained role; carrying things back and forth between the Board caucus that will be following it -- bringing questions and possibly answers. -- The goal is not for us to be participants in the PDP, but we want to avoid surprises, such as something that the Board wouldn’t be able to do. 2. Work Plan -- GNSO Council is trying to ensure realistic deadlines for the PDP WGs and to manage the policy development work. -- One of the PDP 3.0 recommendations that has been implemented is the need for Project Change Requests when the dates of deliverables cannot be met. As you may know the RPMs PDP WG submitted a Project Change Request for the GNSO Council meeting in January and is revising that request. -- The SubPro PDP WG Co-Chairs have been asked to submit a modified work plan along with the Project Change Request for the Council to consider at its meeting on 20 February. -- This is a worst case scenario to avoid having to do another request, but we expect to be able to shave some time off of this. -- New work plan shows the schedule of meetings to cover all of the topics. -- Unless the WG can work faster it would be delivering a Final Report by the end of 2020. -- This is just a preview; a link will be sent later. -- This is assuming a two meetings per week schedule. -- Some of these topics may not take two full meetings, but we’ve built that in as a buffer. -- Some things we could do to streamline this. One that we’ll suggest to the WG and GNSO Council is to have a couple of extended sessions in April and May -- in lieu of face-to-face meetings. Such as two 3-hour sessions in April and May we could save a month or more. -- New working method: Take after EPDP and ask the WG members to consider what they can live with, with an emphasis on suggesting solutions. -- Goal is to get the revised work plan and Project Change Request to the Council by early next week. -- Agree that we would need to schedule longer sessions well in advance, say two months. ACTION ITEM: Staff will send a link to the revised work plan/timeline. 3. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52.... Structure: -- Affirmations are confirming the 2012 policy/AGB. -- Recommendations are things that must happen. -- Implementation Guidance are things that should happen. a. 2.2.1 Continuing Subsequent Procedures Affirmation xx (see rationale 1): The Working Group recommends that the existing policy contained in the 2012 Applicant Guidebook, that a “systematized manner of applying for gTLDs be developed in the long term,” be maintained. Affirmation xx (see rationale 2): The Working Group affirms Principle A and recommends that the New gTLD Program must continue to be administered “in an ongoing, orderly, timely and predictable manner.” Affirmation xx (see rationale 3): The Working Group affirms that the primary purposes of new gTLDs are to foster diversity, encourage competition, and enhance the utility of the DNS. Recommendation xx (see rationale 3). Accordingly, the Working Group recommends that meaningful metrics must be identified to understand the impact of the New gTLD Program. The metrics, broadly speaking, should focus on the areas of trust, competition, and choice. To review metrics, data must be collected at a logical time to create a basis against which future data can be compared. Discussion: -- On the recommendation: Should we cite section 5 of the CCT-RT Final Report for the types of data? There is still some uncertainty as to what will be adopted from that Final Report, so it would be preferable that this could be part of Implementation Guidance. Not trying to override ICANN Org’s plans. -- Re: metrics -- never seen any commitment from ICANN Org to collect and publish the metrics as recommended by the CCT Final Report. Don’t see how these can be collected. -- There was discussion in the SubPro Initial Report and in the CCT-RT Final Report; ICANN is aware of the discussions and has a schedule concerning the recommendations. -- Question from ICANN Org re: the recommendation: Is this some other framework that gets set up to measure the trust, competition, and choice goals over time. Answer: Some of it would be part of the implementation; we wanted a general recommendation about collecting data, but didn’t want to get into a debate on the details. We wanted to leave it to implementation as to what types of data would be collected and how. -- Question: Was this particular recommendation adopted by the Board or no? Should we refer to data gathering in accordance with whatever Board adopts in relation to the CCT recommendation? Answer: We will add this as Implementation Guidance. ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. b. 2.2.3 Applications Assessed in Rounds Affirmation xx (with modification) (see rationale 1): The Working Group affirms recommendation 13 from the 2007 policy, which states: “Applications must initially be assessed in rounds until the scale of demand is clear.” However, the Working Group believes that the words “initially” and “until the scale of demand is clear” be removed from the sentence and should just read “Applications must be assessed in rounds.” Recommendation xx (see rationale 2): Upon the commencement of the next Application Submission Period, there must be clarity around the timing and/or criteria for initiating subsequent procedures from that point forth. More specifically, prior to the commencement of the next Application Submission Period, ICANN shall publish either (a) the date in which the next subsequent introduction of new gTLDs will take place or (b) the specific set of criteria and/or events that must occur prior to the opening up of the next subsequent process. Implementation Guidance xx (see rationale 2): A new round may initiate even if steps related to application processing and delegation from previous application windows have not been completed. 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 opportunity. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application opportunity, unless and/or until the applications from the previous round that match those strings have had their final disposition. Discussion: -- Comment: May be worth seeing if the WG can narrow in on a preference here. Or perhaps this makes sense as an unless in a sense, so the date is the preference, unless there is non-exhaustive list of things that would prevent the timely launch? Question: Preference for ICANN Org to set a date, or instead to say what has to happen before a next round? -- In Implementation Guidance we suggested two options since comments were widely varied. -- The first option adds to predictability for applicants. Else applicants may be in limbo for an unknown period of time. -- The second option gets pretty complicated when you are trying to determine contention sets. Not sure how you would do it. -- This is not meant to allow someone to get into an already existing contention set. In both of these cases nothing is going to be processed in a subsequent round until every contention set is resolved and done from the previous round. -- Recommendation: preference is that ICANN publish a date. -- Implementation Guidance: preference is that it should not be possible to apply for a string that is still being processed from a previous application opportunity. -- Disagree that strings from last round should be prohibited. Second option supports the notion of Applicant freedom of expression. -- From a process perspective the above comment would add complications that really aren't warranted. -- No evaluation of the new applicant would occur until the 2012 applications are resolved. The new applicants would have to accept that risk. -- Concerns about treating moribund applications made a decade ago as reservations for the next round. Are the strings that are withdrawn due to name collisions undergoing a process, or are they just on hold? -- What is the harm in keeping a particular string closed for new apps until all the previous applicants have fallen by the wayside. Then it opens up again for all. -- Because the window for application is closed at that point and we haven't said that a new window could open if they all fail. -- If there is agreement that rounds are the path forward, then if a string does not go through in one round it will become available in another round. -- That's one of our recommendations that there will be a series of windows. -- Is there any WG member that would die in a ditch over this option: “It should not be possible to apply for a string in a subsequent round that is still being processed from a previous application round.”? -- Favor the second option. -- Can't live with prohibiting applications for the same string. If "shall not proceed" means new applicants can still apply, I can live with that. -- What about applications that have not progressed on purpose? Or for technical reasons? -- From a pragmatic perspective if we allow for applicants to submit applications for a string that is already in process that adds layers of complexity to the process. If a string hasn’t gone forward to delegation and it becomes available again then it can be applied for. -- We don’t have a system in place that allows for continuing application periods, we have rounds. People should be waiting their turn but they can get in line -- violates applicants’ freedom of expression if they can’t apply. -- The point of the first recommendation is that ICANN Org will set a date certain or criteria that must occur. We are trying to get to a steady state process. -- If someone could apply for a string that is still in process, what we may be encouraging is applicants who might not be fully processed to apply in the next round if they think they are going to fail in the previous round. Need to define in implementation what “in process” means. -- If it would be possible to file applications for the same string in future rounds the door is open for gaming and unknown consequences: applicant(s) from the first round might consider future applicants in their behaviour and decisions. -- Surely, all delegated TLDs or those in process, are off limits. -- I think applicant freedom of expression means you can apply for any string you want, but I don't think that extends to TLDs already in existence or those that are in process in some way. -- Delegated TLDs are not under discussion. -- The point here are those that are not “in process”, so we need to define “in process”. -- Old applications that were denied for a policy reason should have to step up to new policy recommendations if they are going to prevail/ proceed and they should be encouraged to do so by knowing there may be applicants standing in line who are willing to do so. (No stonewalling on new policy recommendations - no blocking based on old policy positions.) -- We already have many categories of Application Status (Active, Applicant Support, Delegated, etc.) -- Question: What about the status “Not Approved”? Answer: That only applies when an application has gone through all of the steps. There will be one or two edge cases. -- Let’s say that we are talking about the names collisions issues and strings that were not delegated -- if new policy is developed by NCAP and may come out of the Board. If there isn’t a new policy they shouldn’t be able to block new applicants. -- An applicant from a prior round who does not want to meet new policy recommendations can block a string forever by not withdrawing a Not Approved application. ACTION ITEM: Change Implementation Guidance to: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Recommendation xx (see rationale 2): Application procedures must take place at predictable, regularly occurring intervals without indeterminable periods of review unless the GNSO Council recommends pausing the program and such recommendation is approved by the Board. Unless and until other procedures are recommended by the GNSO Council and approved by the ICANN Board, ICANN must only use “rounds” as part of the New gTLD Program. Recommendation xx (see rationale 2): Absent extraordinary circumstances, future reviews and/or policy development processes, including the next CCT Review, should take place concurrently with subsequent application rounds. In other words, future reviews and/or policy development processes must not stop or delay subsequent new gTLD rounds. Recommendation xx (See rationale 2). If the outputs of any reviews and/or policy development processes has, or could reasonably have, a material impact on the manner in which application procedures are conducted, such changes must only apply to the opening of the application procedure subsequent to the adoption of the relevant recommendations by the ICANN Board. Discussion: -- Look at these recommendations together. -- If we are clear that applications need to follow all of the timelines before becoming “Not Approved” then they cannot block in future rounds. -- If you have a new policy in the next round that eliminated the problem that blocked a previous string then it should be able to be applied for in the next round. -- Let’s say that .home can move forward but only as a closed generic or .brand where there is a one registrant TLD. What if one of the applicants for .home has no interest in that? Their application needs to be dead. -- Those (.home, .corp, .mail) are not withdrawn even though "not approved". If the Board adopts new name collision policy, old applicants should be willing to step up to the new name collision policy and not be able to refuse to do so and block the string forever by not withdrawing the application. -- Rules should apply in each round to those applicants. -- If you can’t live with the language please suggest new language. -- Problem seems to be how to fix the “Not Approved” applications from the previous round. Board may have to decide how to deal with them. That is out of scope for this WG. ________________________________ 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>
I am just noting that at least three active participants said the whatever we ultimately conclude on this point is policy. I think Greg raised this, with Justine saying +1 and I agreed it’s Policy and then Kathy K. chimed in. In our report, we have the categories you describe. I know Karen said that Implementation Guidance carries strong weight, but it seemed that the point being made was that the issue was a Policy issue rather than Implementation issue. The distinction likely becomes important for the IRT. Thank you for asking. Anne From: Jeff Neuman <jeff.neuman@comlaude.com> Sent: Friday, February 7, 2020 9:47 AM To: 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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Just to clarify Anne, are you saying that the proposal to ban new applications for string not yet withdrawn should be labeled as a “recommendation” and opposed to “Implementation Guidance?” If it something different, than please explain. 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: Thursday, February 6, 2020 5:42 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 - 06 February 2000 UTC Thanks Julie – Were you able to capture in the notes the views put forward to the effect that a proposal to ban new applications for strings not yet withdrawn is in fact “Policy” and not “Implementation Guidance”? Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Julie Hedlund Sent: Thursday, February 6, 2020 3:02 PM 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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting on 06 February 2000 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-06+New+gTLD+Subsequent+Pro.... Kind regards, Julie Notes and Action Items: Actions: Work Plan: ACTION ITEM: Staff will send a link to the revised work plan/timeline. 2.2.1 Continuing Subsequent Procedures ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. ACTION ITEM: Change text as follows: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Notes: 1. Updates to Statements of Interest: -- Avri Doria will be participating as one of the Board Liaisons to the WG. The other Board Liaison is Becky Burr. -- Question: What does that mean in terms of the role of the Board Liaison? Answer: Largely a constrained role; carrying things back and forth between the Board caucus that will be following it -- bringing questions and possibly answers. -- The goal is not for us to be participants in the PDP, but we want to avoid surprises, such as something that the Board wouldn’t be able to do. 2. Work Plan -- GNSO Council is trying to ensure realistic deadlines for the PDP WGs and to manage the policy development work. -- One of the PDP 3.0 recommendations that has been implemented is the need for Project Change Requests when the dates of deliverables cannot be met. As you may know the RPMs PDP WG submitted a Project Change Request for the GNSO Council meeting in January and is revising that request. -- The SubPro PDP WG Co-Chairs have been asked to submit a modified work plan along with the Project Change Request for the Council to consider at its meeting on 20 February. -- This is a worst case scenario to avoid having to do another request, but we expect to be able to shave some time off of this. -- New work plan shows the schedule of meetings to cover all of the topics. -- Unless the WG can work faster it would be delivering a Final Report by the end of 2020. -- This is just a preview; a link will be sent later. -- This is assuming a two meetings per week schedule. -- Some of these topics may not take two full meetings, but we’ve built that in as a buffer. -- Some things we could do to streamline this. One that we’ll suggest to the WG and GNSO Council is to have a couple of extended sessions in April and May -- in lieu of face-to-face meetings. Such as two 3-hour sessions in April and May we could save a month or more. -- New working method: Take after EPDP and ask the WG members to consider what they can live with, with an emphasis on suggesting solutions. -- Goal is to get the revised work plan and Project Change Request to the Council by early next week. -- Agree that we would need to schedule longer sessions well in advance, say two months. ACTION ITEM: Staff will send a link to the revised work plan/timeline. 3. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52.... Structure: -- Affirmations are confirming the 2012 policy/AGB. -- Recommendations are things that must happen. -- Implementation Guidance are things that should happen. a. 2.2.1 Continuing Subsequent Procedures Affirmation xx (see rationale 1): The Working Group recommends that the existing policy contained in the 2012 Applicant Guidebook, that a “systematized manner of applying for gTLDs be developed in the long term,” be maintained. Affirmation xx (see rationale 2): The Working Group affirms Principle A and recommends that the New gTLD Program must continue to be administered “in an ongoing, orderly, timely and predictable manner.” Affirmation xx (see rationale 3): The Working Group affirms that the primary purposes of new gTLDs are to foster diversity, encourage competition, and enhance the utility of the DNS. Recommendation xx (see rationale 3). Accordingly, the Working Group recommends that meaningful metrics must be identified to understand the impact of the New gTLD Program. The metrics, broadly speaking, should focus on the areas of trust, competition, and choice. To review metrics, data must be collected at a logical time to create a basis against which future data can be compared. Discussion: -- On the recommendation: Should we cite section 5 of the CCT-RT Final Report for the types of data? There is still some uncertainty as to what will be adopted from that Final Report, so it would be preferable that this could be part of Implementation Guidance. Not trying to override ICANN Org’s plans. -- Re: metrics -- never seen any commitment from ICANN Org to collect and publish the metrics as recommended by the CCT Final Report. Don’t see how these can be collected. -- There was discussion in the SubPro Initial Report and in the CCT-RT Final Report; ICANN is aware of the discussions and has a schedule concerning the recommendations. -- Question from ICANN Org re: the recommendation: Is this some other framework that gets set up to measure the trust, competition, and choice goals over time. Answer: Some of it would be part of the implementation; we wanted a general recommendation about collecting data, but didn’t want to get into a debate on the details. We wanted to leave it to implementation as to what types of data would be collected and how. -- Question: Was this particular recommendation adopted by the Board or no? Should we refer to data gathering in accordance with whatever Board adopts in relation to the CCT recommendation? Answer: We will add this as Implementation Guidance. ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. b. 2.2.3 Applications Assessed in Rounds Affirmation xx (with modification) (see rationale 1): The Working Group affirms recommendation 13 from the 2007 policy, which states: “Applications must initially be assessed in rounds until the scale of demand is clear.” However, the Working Group believes that the words “initially” and “until the scale of demand is clear” be removed from the sentence and should just read “Applications must be assessed in rounds.” Recommendation xx (see rationale 2): Upon the commencement of the next Application Submission Period, there must be clarity around the timing and/or criteria for initiating subsequent procedures from that point forth. More specifically, prior to the commencement of the next Application Submission Period, ICANN shall publish either (a) the date in which the next subsequent introduction of new gTLDs will take place or (b) the specific set of criteria and/or events that must occur prior to the opening up of the next subsequent process. Implementation Guidance xx (see rationale 2): A new round may initiate even if steps related to application processing and delegation from previous application windows have not been completed. 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 opportunity. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application opportunity, unless and/or until the applications from the previous round that match those strings have had their final disposition. Discussion: -- Comment: May be worth seeing if the WG can narrow in on a preference here. Or perhaps this makes sense as an unless in a sense, so the date is the preference, unless there is non-exhaustive list of things that would prevent the timely launch? Question: Preference for ICANN Org to set a date, or instead to say what has to happen before a next round? -- In Implementation Guidance we suggested two options since comments were widely varied. -- The first option adds to predictability for applicants. Else applicants may be in limbo for an unknown period of time. -- The second option gets pretty complicated when you are trying to determine contention sets. Not sure how you would do it. -- This is not meant to allow someone to get into an already existing contention set. In both of these cases nothing is going to be processed in a subsequent round until every contention set is resolved and done from the previous round. -- Recommendation: preference is that ICANN publish a date. -- Implementation Guidance: preference is that it should not be possible to apply for a string that is still being processed from a previous application opportunity. -- Disagree that strings from last round should be prohibited. Second option supports the notion of Applicant freedom of expression. -- From a process perspective the above comment would add complications that really aren't warranted. -- No evaluation of the new applicant would occur until the 2012 applications are resolved. The new applicants would have to accept that risk. -- Concerns about treating moribund applications made a decade ago as reservations for the next round. Are the strings that are withdrawn due to name collisions undergoing a process, or are they just on hold? -- What is the harm in keeping a particular string closed for new apps until all the previous applicants have fallen by the wayside. Then it opens up again for all. -- Because the window for application is closed at that point and we haven't said that a new window could open if they all fail. -- If there is agreement that rounds are the path forward, then if a string does not go through in one round it will become available in another round. -- That's one of our recommendations that there will be a series of windows. -- Is there any WG member that would die in a ditch over this option: “It should not be possible to apply for a string in a subsequent round that is still being processed from a previous application round.”? -- Favor the second option. -- Can't live with prohibiting applications for the same string. If "shall not proceed" means new applicants can still apply, I can live with that. -- What about applications that have not progressed on purpose? Or for technical reasons? -- From a pragmatic perspective if we allow for applicants to submit applications for a string that is already in process that adds layers of complexity to the process. If a string hasn’t gone forward to delegation and it becomes available again then it can be applied for. -- We don’t have a system in place that allows for continuing application periods, we have rounds. People should be waiting their turn but they can get in line -- violates applicants’ freedom of expression if they can’t apply. -- The point of the first recommendation is that ICANN Org will set a date certain or criteria that must occur. We are trying to get to a steady state process. -- If someone could apply for a string that is still in process, what we may be encouraging is applicants who might not be fully processed to apply in the next round if they think they are going to fail in the previous round. Need to define in implementation what “in process” means. -- If it would be possible to file applications for the same string in future rounds the door is open for gaming and unknown consequences: applicant(s) from the first round might consider future applicants in their behaviour and decisions. -- Surely, all delegated TLDs or those in process, are off limits. -- I think applicant freedom of expression means you can apply for any string you want, but I don't think that extends to TLDs already in existence or those that are in process in some way. -- Delegated TLDs are not under discussion. -- The point here are those that are not “in process”, so we need to define “in process”. -- Old applications that were denied for a policy reason should have to step up to new policy recommendations if they are going to prevail/ proceed and they should be encouraged to do so by knowing there may be applicants standing in line who are willing to do so. (No stonewalling on new policy recommendations - no blocking based on old policy positions.) -- We already have many categories of Application Status (Active, Applicant Support, Delegated, etc.) -- Question: What about the status “Not Approved”? Answer: That only applies when an application has gone through all of the steps. There will be one or two edge cases. -- Let’s say that we are talking about the names collisions issues and strings that were not delegated -- if new policy is developed by NCAP and may come out of the Board. If there isn’t a new policy they shouldn’t be able to block new applicants. -- An applicant from a prior round who does not want to meet new policy recommendations can block a string forever by not withdrawing a Not Approved application. ACTION ITEM: Change Implementation Guidance to: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Recommendation xx (see rationale 2): Application procedures must take place at predictable, regularly occurring intervals without indeterminable periods of review unless the GNSO Council recommends pausing the program and such recommendation is approved by the Board. Unless and until other procedures are recommended by the GNSO Council and approved by the ICANN Board, ICANN must only use “rounds” as part of the New gTLD Program. Recommendation xx (see rationale 2): Absent extraordinary circumstances, future reviews and/or policy development processes, including the next CCT Review, should take place concurrently with subsequent application rounds. In other words, future reviews and/or policy development processes must not stop or delay subsequent new gTLD rounds. Recommendation xx (See rationale 2). If the outputs of any reviews and/or policy development processes has, or could reasonably have, a material impact on the manner in which application procedures are conducted, such changes must only apply to the opening of the application procedure subsequent to the adoption of the relevant recommendations by the ICANN Board. Discussion: -- Look at these recommendations together. -- If we are clear that applications need to follow all of the timelines before becoming “Not Approved” then they cannot block in future rounds. -- If you have a new policy in the next round that eliminated the problem that blocked a previous string then it should be able to be applied for in the next round. -- Let’s say that .home can move forward but only as a closed generic or .brand where there is a one registrant TLD. What if one of the applicants for .home has no interest in that? Their application needs to be dead. -- Those (.home, .corp, .mail) are not withdrawn even though "not approved". If the Board adopts new name collision policy, old applicants should be willing to step up to the new name collision policy and not be able to refuse to do so and block the string forever by not withdrawing the application. -- Rules should apply in each round to those applicants. -- If you can’t live with the language please suggest new language. -- Problem seems to be how to fix the “Not Approved” applications from the previous round. Board may have to decide how to deal with them. That is out of scope for this WG. ________________________________ 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> ________________________________ 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.
Ok, I tried to clarify because I think I may have said something that inadvertently triggered the policy vs. implementation discussion. What I said was something to the effect of “We could say that the policy is that we will not accept any applications for a string that was applied for in the past round so long as that application was still being processed.” And then I followed that up with something like “and we can leave it to the Implementation team to define what it means to still “be in process”. I must not have communicated that as well as I should have because that is when people started saying that this issue was policy as opposed to implementation (Which was not the point of what I was trying to make). SO, bottom line, no one said on the call, nor am I aware of anyone that believes, that this issue in general is “policy.” However, if we cannot agree on every little detail, then we can leave some of those details to the Implementation Review Team. I hope that helps. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> From: Aikman-Scalese, Anne <AAikman@lrrc.com> Sent: Friday, February 7, 2020 1:32 PM To: Jeff Neuman <jeff.neuman@comlaude.com>; Julie Hedlund <julie.hedlund@icann.org>; gnso-newgtld-wg@icann.org Subject: RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC I am just noting that at least three active participants said the whatever we ultimately conclude on this point is policy. I think Greg raised this, with Justine saying +1 and I agreed it’s Policy and then Kathy K. chimed in. In our report, we have the categories you describe. I know Karen said that Implementation Guidance carries strong weight, but it seemed that the point being made was that the issue was a Policy issue rather than Implementation issue. The distinction likely becomes important for the IRT. Thank you for asking. Anne From: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com>> Sent: Friday, February 7, 2020 9:47 AM To: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Just to clarify Anne, are you saying that the proposal to ban new applications for string not yet withdrawn should be labeled as a “recommendation” and opposed to “Implementation Guidance?” If it something different, than please explain. 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: Thursday, February 6, 2020 5:42 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 - 06 February 2000 UTC Thanks Julie – Were you able to capture in the notes the views put forward to the effect that a proposal to ban new applications for strings not yet withdrawn is in fact “Policy” and not “Implementation Guidance”? Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Julie Hedlund Sent: Thursday, February 6, 2020 3:02 PM 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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting on 06 February 2000 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-06+New+gTLD+Subsequent+Pro.... Kind regards, Julie Notes and Action Items: Actions: Work Plan: ACTION ITEM: Staff will send a link to the revised work plan/timeline. 2.2.1 Continuing Subsequent Procedures ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. ACTION ITEM: Change text as follows: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Notes: 1. Updates to Statements of Interest: -- Avri Doria will be participating as one of the Board Liaisons to the WG. The other Board Liaison is Becky Burr. -- Question: What does that mean in terms of the role of the Board Liaison? Answer: Largely a constrained role; carrying things back and forth between the Board caucus that will be following it -- bringing questions and possibly answers. -- The goal is not for us to be participants in the PDP, but we want to avoid surprises, such as something that the Board wouldn’t be able to do. 2. Work Plan -- GNSO Council is trying to ensure realistic deadlines for the PDP WGs and to manage the policy development work. -- One of the PDP 3.0 recommendations that has been implemented is the need for Project Change Requests when the dates of deliverables cannot be met. As you may know the RPMs PDP WG submitted a Project Change Request for the GNSO Council meeting in January and is revising that request. -- The SubPro PDP WG Co-Chairs have been asked to submit a modified work plan along with the Project Change Request for the Council to consider at its meeting on 20 February. -- This is a worst case scenario to avoid having to do another request, but we expect to be able to shave some time off of this. -- New work plan shows the schedule of meetings to cover all of the topics. -- Unless the WG can work faster it would be delivering a Final Report by the end of 2020. -- This is just a preview; a link will be sent later. -- This is assuming a two meetings per week schedule. -- Some of these topics may not take two full meetings, but we’ve built that in as a buffer. -- Some things we could do to streamline this. One that we’ll suggest to the WG and GNSO Council is to have a couple of extended sessions in April and May -- in lieu of face-to-face meetings. Such as two 3-hour sessions in April and May we could save a month or more. -- New working method: Take after EPDP and ask the WG members to consider what they can live with, with an emphasis on suggesting solutions. -- Goal is to get the revised work plan and Project Change Request to the Council by early next week. -- Agree that we would need to schedule longer sessions well in advance, say two months. ACTION ITEM: Staff will send a link to the revised work plan/timeline. 3. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52.... Structure: -- Affirmations are confirming the 2012 policy/AGB. -- Recommendations are things that must happen. -- Implementation Guidance are things that should happen. a. 2.2.1 Continuing Subsequent Procedures Affirmation xx (see rationale 1): The Working Group recommends that the existing policy contained in the 2012 Applicant Guidebook, that a “systematized manner of applying for gTLDs be developed in the long term,” be maintained. Affirmation xx (see rationale 2): The Working Group affirms Principle A and recommends that the New gTLD Program must continue to be administered “in an ongoing, orderly, timely and predictable manner.” Affirmation xx (see rationale 3): The Working Group affirms that the primary purposes of new gTLDs are to foster diversity, encourage competition, and enhance the utility of the DNS. Recommendation xx (see rationale 3). Accordingly, the Working Group recommends that meaningful metrics must be identified to understand the impact of the New gTLD Program. The metrics, broadly speaking, should focus on the areas of trust, competition, and choice. To review metrics, data must be collected at a logical time to create a basis against which future data can be compared. Discussion: -- On the recommendation: Should we cite section 5 of the CCT-RT Final Report for the types of data? There is still some uncertainty as to what will be adopted from that Final Report, so it would be preferable that this could be part of Implementation Guidance. Not trying to override ICANN Org’s plans. -- Re: metrics -- never seen any commitment from ICANN Org to collect and publish the metrics as recommended by the CCT Final Report. Don’t see how these can be collected. -- There was discussion in the SubPro Initial Report and in the CCT-RT Final Report; ICANN is aware of the discussions and has a schedule concerning the recommendations. -- Question from ICANN Org re: the recommendation: Is this some other framework that gets set up to measure the trust, competition, and choice goals over time. Answer: Some of it would be part of the implementation; we wanted a general recommendation about collecting data, but didn’t want to get into a debate on the details. We wanted to leave it to implementation as to what types of data would be collected and how. -- Question: Was this particular recommendation adopted by the Board or no? Should we refer to data gathering in accordance with whatever Board adopts in relation to the CCT recommendation? Answer: We will add this as Implementation Guidance. ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. b. 2.2.3 Applications Assessed in Rounds Affirmation xx (with modification) (see rationale 1): The Working Group affirms recommendation 13 from the 2007 policy, which states: “Applications must initially be assessed in rounds until the scale of demand is clear.” However, the Working Group believes that the words “initially” and “until the scale of demand is clear” be removed from the sentence and should just read “Applications must be assessed in rounds.” Recommendation xx (see rationale 2): Upon the commencement of the next Application Submission Period, there must be clarity around the timing and/or criteria for initiating subsequent procedures from that point forth. More specifically, prior to the commencement of the next Application Submission Period, ICANN shall publish either (a) the date in which the next subsequent introduction of new gTLDs will take place or (b) the specific set of criteria and/or events that must occur prior to the opening up of the next subsequent process. Implementation Guidance xx (see rationale 2): A new round may initiate even if steps related to application processing and delegation from previous application windows have not been completed. 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 opportunity. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application opportunity, unless and/or until the applications from the previous round that match those strings have had their final disposition. Discussion: -- Comment: May be worth seeing if the WG can narrow in on a preference here. Or perhaps this makes sense as an unless in a sense, so the date is the preference, unless there is non-exhaustive list of things that would prevent the timely launch? Question: Preference for ICANN Org to set a date, or instead to say what has to happen before a next round? -- In Implementation Guidance we suggested two options since comments were widely varied. -- The first option adds to predictability for applicants. Else applicants may be in limbo for an unknown period of time. -- The second option gets pretty complicated when you are trying to determine contention sets. Not sure how you would do it. -- This is not meant to allow someone to get into an already existing contention set. In both of these cases nothing is going to be processed in a subsequent round until every contention set is resolved and done from the previous round. -- Recommendation: preference is that ICANN publish a date. -- Implementation Guidance: preference is that it should not be possible to apply for a string that is still being processed from a previous application opportunity. -- Disagree that strings from last round should be prohibited. Second option supports the notion of Applicant freedom of expression. -- From a process perspective the above comment would add complications that really aren't warranted. -- No evaluation of the new applicant would occur until the 2012 applications are resolved. The new applicants would have to accept that risk. -- Concerns about treating moribund applications made a decade ago as reservations for the next round. Are the strings that are withdrawn due to name collisions undergoing a process, or are they just on hold? -- What is the harm in keeping a particular string closed for new apps until all the previous applicants have fallen by the wayside. Then it opens up again for all. -- Because the window for application is closed at that point and we haven't said that a new window could open if they all fail. -- If there is agreement that rounds are the path forward, then if a string does not go through in one round it will become available in another round. -- That's one of our recommendations that there will be a series of windows. -- Is there any WG member that would die in a ditch over this option: “It should not be possible to apply for a string in a subsequent round that is still being processed from a previous application round.”? -- Favor the second option. -- Can't live with prohibiting applications for the same string. If "shall not proceed" means new applicants can still apply, I can live with that. -- What about applications that have not progressed on purpose? Or for technical reasons? -- From a pragmatic perspective if we allow for applicants to submit applications for a string that is already in process that adds layers of complexity to the process. If a string hasn’t gone forward to delegation and it becomes available again then it can be applied for. -- We don’t have a system in place that allows for continuing application periods, we have rounds. People should be waiting their turn but they can get in line -- violates applicants’ freedom of expression if they can’t apply. -- The point of the first recommendation is that ICANN Org will set a date certain or criteria that must occur. We are trying to get to a steady state process. -- If someone could apply for a string that is still in process, what we may be encouraging is applicants who might not be fully processed to apply in the next round if they think they are going to fail in the previous round. Need to define in implementation what “in process” means. -- If it would be possible to file applications for the same string in future rounds the door is open for gaming and unknown consequences: applicant(s) from the first round might consider future applicants in their behaviour and decisions. -- Surely, all delegated TLDs or those in process, are off limits. -- I think applicant freedom of expression means you can apply for any string you want, but I don't think that extends to TLDs already in existence or those that are in process in some way. -- Delegated TLDs are not under discussion. -- The point here are those that are not “in process”, so we need to define “in process”. -- Old applications that were denied for a policy reason should have to step up to new policy recommendations if they are going to prevail/ proceed and they should be encouraged to do so by knowing there may be applicants standing in line who are willing to do so. (No stonewalling on new policy recommendations - no blocking based on old policy positions.) -- We already have many categories of Application Status (Active, Applicant Support, Delegated, etc.) -- Question: What about the status “Not Approved”? Answer: That only applies when an application has gone through all of the steps. There will be one or two edge cases. -- Let’s say that we are talking about the names collisions issues and strings that were not delegated -- if new policy is developed by NCAP and may come out of the Board. If there isn’t a new policy they shouldn’t be able to block new applicants. -- An applicant from a prior round who does not want to meet new policy recommendations can block a string forever by not withdrawing a Not Approved application. ACTION ITEM: Change Implementation Guidance to: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Recommendation xx (see rationale 2): Application procedures must take place at predictable, regularly occurring intervals without indeterminable periods of review unless the GNSO Council recommends pausing the program and such recommendation is approved by the Board. Unless and until other procedures are recommended by the GNSO Council and approved by the ICANN Board, ICANN must only use “rounds” as part of the New gTLD Program. Recommendation xx (see rationale 2): Absent extraordinary circumstances, future reviews and/or policy development processes, including the next CCT Review, should take place concurrently with subsequent application rounds. In other words, future reviews and/or policy development processes must not stop or delay subsequent new gTLD rounds. Recommendation xx (See rationale 2). If the outputs of any reviews and/or policy development processes has, or could reasonably have, a material impact on the manner in which application procedures are conducted, such changes must only apply to the opening of the application procedure subsequent to the adoption of the relevant recommendations by the ICANN Board. Discussion: -- Look at these recommendations together. -- If we are clear that applications need to follow all of the timelines before becoming “Not Approved” then they cannot block in future rounds. -- If you have a new policy in the next round that eliminated the problem that blocked a previous string then it should be able to be applied for in the next round. -- Let’s say that .home can move forward but only as a closed generic or .brand where there is a one registrant TLD. What if one of the applicants for .home has no interest in that? Their application needs to be dead. -- Those (.home, .corp, .mail) are not withdrawn even though "not approved". If the Board adopts new name collision policy, old applicants should be willing to step up to the new name collision policy and not be able to refuse to do so and block the string forever by not withdrawing the application. -- Rules should apply in each round to those applicants. -- If you can’t live with the language please suggest new language. -- Problem seems to be how to fix the “Not Approved” applications from the previous round. Board may have to decide how to deal with them. That is out of scope for this WG. ________________________________ 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> ________________________________ 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 Jeff. I think the degree of discussion on the call confirms that the issue is not about “every little detail”. It’s a “high level” policy issue. PROBLEM WE NEED TO SOLVE: As I see it, the biggest problem with the first option is that a prior applicant could effectively block new applicants for a string forever by refusing to withdraw an application that is “Not Approved” for policy reasons and by refusing to adopt the new policy. This is not limited to applications from 2012, it’s about policy going forward and relates to applications we have not yet seen. The issues involved could extend well beyond name collisions in to areas no one has yet anticipated. PROPOSED COMPROMISE LANGUAGE: Pursuant to your request, I have entered language with a proposed compromise that would accept the first Option but with the caveat that the applicant(s) from the prior round would confirm in writing to the Global Domains Division that they are willing to comply with new policy and the new AGB and that they do so prior to the opening of the window for the next round. If they are unwilling to do so, then new applicants should be permitted to apply for the string in a “back-up offer” position. Anne From: Jeff Neuman <jeff.neuman@comlaude.com> Sent: Friday, February 7, 2020 11:49 AM To: 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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Ok, I tried to clarify because I think I may have said something that inadvertently triggered the policy vs. implementation discussion. What I said was something to the effect of “We could say that the policy is that we will not accept any applications for a string that was applied for in the past round so long as that application was still being processed.” And then I followed that up with something like “and we can leave it to the Implementation team to define what it means to still “be in process”. I must not have communicated that as well as I should have because that is when people started saying that this issue was policy as opposed to implementation (Which was not the point of what I was trying to make). SO, bottom line, no one said on the call, nor am I aware of anyone that believes, that this issue in general is “policy.” However, if we cannot agree on every little detail, then we can leave some of those details to the Implementation Review Team. I hope that helps. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> From: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> Sent: Friday, February 7, 2020 1:32 PM To: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.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 - 06 February 2000 UTC I am just noting that at least three active participants said the whatever we ultimately conclude on this point is policy. I think Greg raised this, with Justine saying +1 and I agreed it’s Policy and then Kathy K. chimed in. In our report, we have the categories you describe. I know Karen said that Implementation Guidance carries strong weight, but it seemed that the point being made was that the issue was a Policy issue rather than Implementation issue. The distinction likely becomes important for the IRT. Thank you for asking. Anne From: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com>> Sent: Friday, February 7, 2020 9:47 AM To: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Just to clarify Anne, are you saying that the proposal to ban new applications for string not yet withdrawn should be labeled as a “recommendation” and opposed to “Implementation Guidance?” If it something different, than please explain. 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: Thursday, February 6, 2020 5:42 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 - 06 February 2000 UTC Thanks Julie – Were you able to capture in the notes the views put forward to the effect that a proposal to ban new applications for strings not yet withdrawn is in fact “Policy” and not “Implementation Guidance”? Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Julie Hedlund Sent: Thursday, February 6, 2020 3:02 PM 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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting on 06 February 2000 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-06+New+gTLD+Subsequent+Pro.... Kind regards, Julie Notes and Action Items: Actions: Work Plan: ACTION ITEM: Staff will send a link to the revised work plan/timeline. 2.2.1 Continuing Subsequent Procedures ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. ACTION ITEM: Change text as follows: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Notes: 1. Updates to Statements of Interest: -- Avri Doria will be participating as one of the Board Liaisons to the WG. The other Board Liaison is Becky Burr. -- Question: What does that mean in terms of the role of the Board Liaison? Answer: Largely a constrained role; carrying things back and forth between the Board caucus that will be following it -- bringing questions and possibly answers. -- The goal is not for us to be participants in the PDP, but we want to avoid surprises, such as something that the Board wouldn’t be able to do. 2. Work Plan -- GNSO Council is trying to ensure realistic deadlines for the PDP WGs and to manage the policy development work. -- One of the PDP 3.0 recommendations that has been implemented is the need for Project Change Requests when the dates of deliverables cannot be met. As you may know the RPMs PDP WG submitted a Project Change Request for the GNSO Council meeting in January and is revising that request. -- The SubPro PDP WG Co-Chairs have been asked to submit a modified work plan along with the Project Change Request for the Council to consider at its meeting on 20 February. -- This is a worst case scenario to avoid having to do another request, but we expect to be able to shave some time off of this. -- New work plan shows the schedule of meetings to cover all of the topics. -- Unless the WG can work faster it would be delivering a Final Report by the end of 2020. -- This is just a preview; a link will be sent later. -- This is assuming a two meetings per week schedule. -- Some of these topics may not take two full meetings, but we’ve built that in as a buffer. -- Some things we could do to streamline this. One that we’ll suggest to the WG and GNSO Council is to have a couple of extended sessions in April and May -- in lieu of face-to-face meetings. Such as two 3-hour sessions in April and May we could save a month or more. -- New working method: Take after EPDP and ask the WG members to consider what they can live with, with an emphasis on suggesting solutions. -- Goal is to get the revised work plan and Project Change Request to the Council by early next week. -- Agree that we would need to schedule longer sessions well in advance, say two months. ACTION ITEM: Staff will send a link to the revised work plan/timeline. 3. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52.... Structure: -- Affirmations are confirming the 2012 policy/AGB. -- Recommendations are things that must happen. -- Implementation Guidance are things that should happen. a. 2.2.1 Continuing Subsequent Procedures Affirmation xx (see rationale 1): The Working Group recommends that the existing policy contained in the 2012 Applicant Guidebook, that a “systematized manner of applying for gTLDs be developed in the long term,” be maintained. Affirmation xx (see rationale 2): The Working Group affirms Principle A and recommends that the New gTLD Program must continue to be administered “in an ongoing, orderly, timely and predictable manner.” Affirmation xx (see rationale 3): The Working Group affirms that the primary purposes of new gTLDs are to foster diversity, encourage competition, and enhance the utility of the DNS. Recommendation xx (see rationale 3). Accordingly, the Working Group recommends that meaningful metrics must be identified to understand the impact of the New gTLD Program. The metrics, broadly speaking, should focus on the areas of trust, competition, and choice. To review metrics, data must be collected at a logical time to create a basis against which future data can be compared. Discussion: -- On the recommendation: Should we cite section 5 of the CCT-RT Final Report for the types of data? There is still some uncertainty as to what will be adopted from that Final Report, so it would be preferable that this could be part of Implementation Guidance. Not trying to override ICANN Org’s plans. -- Re: metrics -- never seen any commitment from ICANN Org to collect and publish the metrics as recommended by the CCT Final Report. Don’t see how these can be collected. -- There was discussion in the SubPro Initial Report and in the CCT-RT Final Report; ICANN is aware of the discussions and has a schedule concerning the recommendations. -- Question from ICANN Org re: the recommendation: Is this some other framework that gets set up to measure the trust, competition, and choice goals over time. Answer: Some of it would be part of the implementation; we wanted a general recommendation about collecting data, but didn’t want to get into a debate on the details. We wanted to leave it to implementation as to what types of data would be collected and how. -- Question: Was this particular recommendation adopted by the Board or no? Should we refer to data gathering in accordance with whatever Board adopts in relation to the CCT recommendation? Answer: We will add this as Implementation Guidance. ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. b. 2.2.3 Applications Assessed in Rounds Affirmation xx (with modification) (see rationale 1): The Working Group affirms recommendation 13 from the 2007 policy, which states: “Applications must initially be assessed in rounds until the scale of demand is clear.” However, the Working Group believes that the words “initially” and “until the scale of demand is clear” be removed from the sentence and should just read “Applications must be assessed in rounds.” Recommendation xx (see rationale 2): Upon the commencement of the next Application Submission Period, there must be clarity around the timing and/or criteria for initiating subsequent procedures from that point forth. More specifically, prior to the commencement of the next Application Submission Period, ICANN shall publish either (a) the date in which the next subsequent introduction of new gTLDs will take place or (b) the specific set of criteria and/or events that must occur prior to the opening up of the next subsequent process. Implementation Guidance xx (see rationale 2): A new round may initiate even if steps related to application processing and delegation from previous application windows have not been completed. 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 opportunity. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application opportunity, unless and/or until the applications from the previous round that match those strings have had their final disposition. Discussion: -- Comment: May be worth seeing if the WG can narrow in on a preference here. Or perhaps this makes sense as an unless in a sense, so the date is the preference, unless there is non-exhaustive list of things that would prevent the timely launch? Question: Preference for ICANN Org to set a date, or instead to say what has to happen before a next round? -- In Implementation Guidance we suggested two options since comments were widely varied. -- The first option adds to predictability for applicants. Else applicants may be in limbo for an unknown period of time. -- The second option gets pretty complicated when you are trying to determine contention sets. Not sure how you would do it. -- This is not meant to allow someone to get into an already existing contention set. In both of these cases nothing is going to be processed in a subsequent round until every contention set is resolved and done from the previous round. -- Recommendation: preference is that ICANN publish a date. -- Implementation Guidance: preference is that it should not be possible to apply for a string that is still being processed from a previous application opportunity. -- Disagree that strings from last round should be prohibited. Second option supports the notion of Applicant freedom of expression. -- From a process perspective the above comment would add complications that really aren't warranted. -- No evaluation of the new applicant would occur until the 2012 applications are resolved. The new applicants would have to accept that risk. -- Concerns about treating moribund applications made a decade ago as reservations for the next round. Are the strings that are withdrawn due to name collisions undergoing a process, or are they just on hold? -- What is the harm in keeping a particular string closed for new apps until all the previous applicants have fallen by the wayside. Then it opens up again for all. -- Because the window for application is closed at that point and we haven't said that a new window could open if they all fail. -- If there is agreement that rounds are the path forward, then if a string does not go through in one round it will become available in another round. -- That's one of our recommendations that there will be a series of windows. -- Is there any WG member that would die in a ditch over this option: “It should not be possible to apply for a string in a subsequent round that is still being processed from a previous application round.”? -- Favor the second option. -- Can't live with prohibiting applications for the same string. If "shall not proceed" means new applicants can still apply, I can live with that. -- What about applications that have not progressed on purpose? Or for technical reasons? -- From a pragmatic perspective if we allow for applicants to submit applications for a string that is already in process that adds layers of complexity to the process. If a string hasn’t gone forward to delegation and it becomes available again then it can be applied for. -- We don’t have a system in place that allows for continuing application periods, we have rounds. People should be waiting their turn but they can get in line -- violates applicants’ freedom of expression if they can’t apply. -- The point of the first recommendation is that ICANN Org will set a date certain or criteria that must occur. We are trying to get to a steady state process. -- If someone could apply for a string that is still in process, what we may be encouraging is applicants who might not be fully processed to apply in the next round if they think they are going to fail in the previous round. Need to define in implementation what “in process” means. -- If it would be possible to file applications for the same string in future rounds the door is open for gaming and unknown consequences: applicant(s) from the first round might consider future applicants in their behaviour and decisions. -- Surely, all delegated TLDs or those in process, are off limits. -- I think applicant freedom of expression means you can apply for any string you want, but I don't think that extends to TLDs already in existence or those that are in process in some way. -- Delegated TLDs are not under discussion. -- The point here are those that are not “in process”, so we need to define “in process”. -- Old applications that were denied for a policy reason should have to step up to new policy recommendations if they are going to prevail/ proceed and they should be encouraged to do so by knowing there may be applicants standing in line who are willing to do so. (No stonewalling on new policy recommendations - no blocking based on old policy positions.) -- We already have many categories of Application Status (Active, Applicant Support, Delegated, etc.) -- Question: What about the status “Not Approved”? Answer: That only applies when an application has gone through all of the steps. There will be one or two edge cases. -- Let’s say that we are talking about the names collisions issues and strings that were not delegated -- if new policy is developed by NCAP and may come out of the Board. If there isn’t a new policy they shouldn’t be able to block new applicants. -- An applicant from a prior round who does not want to meet new policy recommendations can block a string forever by not withdrawing a Not Approved application. ACTION ITEM: Change Implementation Guidance to: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Recommendation xx (see rationale 2): Application procedures must take place at predictable, regularly occurring intervals without indeterminable periods of review unless the GNSO Council recommends pausing the program and such recommendation is approved by the Board. Unless and until other procedures are recommended by the GNSO Council and approved by the ICANN Board, ICANN must only use “rounds” as part of the New gTLD Program. Recommendation xx (see rationale 2): Absent extraordinary circumstances, future reviews and/or policy development processes, including the next CCT Review, should take place concurrently with subsequent application rounds. In other words, future reviews and/or policy development processes must not stop or delay subsequent new gTLD rounds. Recommendation xx (See rationale 2). If the outputs of any reviews and/or policy development processes has, or could reasonably have, a material impact on the manner in which application procedures are conducted, such changes must only apply to the opening of the application procedure subsequent to the adoption of the relevant recommendations by the ICANN Board. Discussion: -- Look at these recommendations together. -- If we are clear that applications need to follow all of the timelines before becoming “Not Approved” then they cannot block in future rounds. -- If you have a new policy in the next round that eliminated the problem that blocked a previous string then it should be able to be applied for in the next round. -- Let’s say that .home can move forward but only as a closed generic or .brand where there is a one registrant TLD. What if one of the applicants for .home has no interest in that? Their application needs to be dead. -- Those (.home, .corp, .mail) are not withdrawn even though "not approved". If the Board adopts new name collision policy, old applicants should be willing to step up to the new name collision policy and not be able to refuse to do so and block the string forever by not withdrawing the application. -- Rules should apply in each round to those applicants. -- If you can’t live with the language please suggest new language. -- Problem seems to be how to fix the “Not Approved” applications from the previous round. Board may have to decide how to deal with them. That is out of scope for this WG. ________________________________ 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> ________________________________ 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> ________________________________ 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.
Suggestion: * 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”). Thanks, Alexander.berlin From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Aikman-Scalese, Anne Sent: Freitag, 7. Februar 2020 14:00 To: Jeff Neuman <jeff.neuman@comlaude.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 - 06 February 2000 UTC Thanks Jeff. I think the degree of discussion on the call confirms that the issue is not about “every little detail”. It’s a “high level” policy issue. PROBLEM WE NEED TO SOLVE: As I see it, the biggest problem with the first option is that a prior applicant could effectively block new applicants for a string forever by refusing to withdraw an application that is “Not Approved” for policy reasons and by refusing to adopt the new policy. This is not limited to applications from 2012, it’s about policy going forward and relates to applications we have not yet seen. The issues involved could extend well beyond name collisions in to areas no one has yet anticipated. PROPOSED COMPROMISE LANGUAGE: Pursuant to your request, I have entered language with a proposed compromise that would accept the first Option but with the caveat that the applicant(s) from the prior round would confirm in writing to the Global Domains Division that they are willing to comply with new policy and the new AGB and that they do so prior to the opening of the window for the next round. If they are unwilling to do so, then new applicants should be permitted to apply for the string in a “back-up offer” position. Anne From: Jeff Neuman <jeff.neuman@comlaude.com <mailto:jeff.neuman@comlaude.com> > Sent: Friday, February 7, 2020 11:49 AM To: Aikman-Scalese, Anne <AAikman@lrrc.com <mailto:AAikman@lrrc.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 - 06 February 2000 UTC [EXTERNAL] _____ Ok, I tried to clarify because I think I may have said something that inadvertently triggered the policy vs. implementation discussion. What I said was something to the effect of “We could say that the policy is that we will not accept any applications for a string that was applied for in the past round so long as that application was still being processed.” And then I followed that up with something like “and we can leave it to the Implementation team to define what it means to still “be in process”. I must not have communicated that as well as I should have because that is when people started saying that this issue was policy as opposed to implementation (Which was not the point of what I was trying to make). SO, bottom line, no one said on the call, nor am I aware of anyone that believes, that this issue in general is “policy.” However, if we cannot agree on every little detail, then we can leave some of those details to the Implementation Review Team. I hope that helps. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: <mailto:jeff.neuman@comlaude.com> jeff.neuman@comlaude.com From: Aikman-Scalese, Anne <AAikman@lrrc.com <mailto:AAikman@lrrc.com> > Sent: Friday, February 7, 2020 1:32 PM To: Jeff Neuman <jeff.neuman@comlaude.com <mailto:jeff.neuman@comlaude.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 - 06 February 2000 UTC I am just noting that at least three active participants said the whatever we ultimately conclude on this point is policy. I think Greg raised this, with Justine saying +1 and I agreed it’s Policy and then Kathy K. chimed in. In our report, we have the categories you describe. I know Karen said that Implementation Guidance carries strong weight, but it seemed that the point being made was that the issue was a Policy issue rather than Implementation issue. The distinction likely becomes important for the IRT. Thank you for asking. Anne From: Jeff Neuman <jeff.neuman@comlaude.com <mailto:jeff.neuman@comlaude.com> > Sent: Friday, February 7, 2020 9:47 AM To: Aikman-Scalese, Anne <AAikman@lrrc.com <mailto:AAikman@lrrc.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 - 06 February 2000 UTC [EXTERNAL] _____ Just to clarify Anne, are you saying that the proposal to ban new applications for string not yet withdrawn should be labeled as a “recommendation” and opposed to “Implementation Guidance?” If it something different, than please explain. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: <mailto:jeff.neuman@comlaude.com> 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: Thursday, February 6, 2020 5:42 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 - 06 February 2000 UTC Thanks Julie – Were you able to capture in the notes the views put forward to the effect that a proposal to ban new applications for strings not yet withdrawn is in fact “Policy” and not “Implementation Guidance”? Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org <mailto:gnso-newgtld-wg-bounces@icann.org> > On Behalf Of Julie Hedlund Sent: Thursday, February 6, 2020 3:02 PM 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 - 06 February 2000 UTC [EXTERNAL] _____ Dear Working Group members, Please see below the notes from the meeting on 06 February 2000 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-06+New+gTLD+Subsequent+Pro.... Kind regards, Julie Notes and Action Items: Actions: Work Plan: ACTION ITEM: Staff will send a link to the revised work plan/timeline. 2.2.1 Continuing Subsequent Procedures ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. ACTION ITEM: Change text as follows: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Notes: 1. Updates to Statements of Interest: -- Avri Doria will be participating as one of the Board Liaisons to the WG. The other Board Liaison is Becky Burr. -- Question: What does that mean in terms of the role of the Board Liaison? Answer: Largely a constrained role; carrying things back and forth between the Board caucus that will be following it -- bringing questions and possibly answers. -- The goal is not for us to be participants in the PDP, but we want to avoid surprises, such as something that the Board wouldn’t be able to do. 2. Work Plan -- GNSO Council is trying to ensure realistic deadlines for the PDP WGs and to manage the policy development work. -- One of the PDP 3.0 recommendations that has been implemented is the need for Project Change Requests when the dates of deliverables cannot be met. As you may know the RPMs PDP WG submitted a Project Change Request for the GNSO Council meeting in January and is revising that request. -- The SubPro PDP WG Co-Chairs have been asked to submit a modified work plan along with the Project Change Request for the Council to consider at its meeting on 20 February. -- This is a worst case scenario to avoid having to do another request, but we expect to be able to shave some time off of this. -- New work plan shows the schedule of meetings to cover all of the topics. -- Unless the WG can work faster it would be delivering a Final Report by the end of 2020. -- This is just a preview; a link will be sent later. -- This is assuming a two meetings per week schedule. -- Some of these topics may not take two full meetings, but we’ve built that in as a buffer. -- Some things we could do to streamline this. One that we’ll suggest to the WG and GNSO Council is to have a couple of extended sessions in April and May -- in lieu of face-to-face meetings. Such as two 3-hour sessions in April and May we could save a month or more. -- New working method: Take after EPDP and ask the WG members to consider what they can live with, with an emphasis on suggesting solutions. -- Goal is to get the revised work plan and Project Change Request to the Council by early next week. -- Agree that we would need to schedule longer sessions well in advance, say two months. ACTION ITEM: Staff will send a link to the revised work plan/timeline. 3. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52.... Structure: -- Affirmations are confirming the 2012 policy/AGB. -- Recommendations are things that must happen. -- Implementation Guidance are things that should happen. a. 2.2.1 Continuing Subsequent Procedures Affirmation xx (see rationale 1): The Working Group recommends that the existing policy contained in the 2012 Applicant Guidebook, that a “systematized manner of applying for gTLDs be developed in the long term,” be maintained. Affirmation xx (see rationale 2): The Working Group affirms Principle A and recommends that the New gTLD Program must continue to be administered “in an ongoing, orderly, timely and predictable manner.” Affirmation xx (see rationale 3): The Working Group affirms that the primary purposes of new gTLDs are to foster diversity, encourage competition, and enhance the utility of the DNS. Recommendation xx (see rationale 3). Accordingly, the Working Group recommends that meaningful metrics must be identified to understand the impact of the New gTLD Program. The metrics, broadly speaking, should focus on the areas of trust, competition, and choice. To review metrics, data must be collected at a logical time to create a basis against which future data can be compared. Discussion: -- On the recommendation: Should we cite section 5 of the CCT-RT Final Report for the types of data? There is still some uncertainty as to what will be adopted from that Final Report, so it would be preferable that this could be part of Implementation Guidance. Not trying to override ICANN Org’s plans. -- Re: metrics -- never seen any commitment from ICANN Org to collect and publish the metrics as recommended by the CCT Final Report. Don’t see how these can be collected. -- There was discussion in the SubPro Initial Report and in the CCT-RT Final Report; ICANN is aware of the discussions and has a schedule concerning the recommendations. -- Question from ICANN Org re: the recommendation: Is this some other framework that gets set up to measure the trust, competition, and choice goals over time. Answer: Some of it would be part of the implementation; we wanted a general recommendation about collecting data, but didn’t want to get into a debate on the details. We wanted to leave it to implementation as to what types of data would be collected and how. -- Question: Was this particular recommendation adopted by the Board or no? Should we refer to data gathering in accordance with whatever Board adopts in relation to the CCT recommendation? Answer: We will add this as Implementation Guidance. ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. b. 2.2.3 Applications Assessed in Rounds Affirmation xx (with modification) (see rationale 1): The Working Group affirms recommendation 13 from the 2007 policy, which states: “Applications must initially be assessed in rounds until the scale of demand is clear.” However, the Working Group believes that the words “initially” and “until the scale of demand is clear” be removed from the sentence and should just read “Applications must be assessed in rounds.” Recommendation xx (see rationale 2): Upon the commencement of the next Application Submission Period, there must be clarity around the timing and/or criteria for initiating subsequent procedures from that point forth. More specifically, prior to the commencement of the next Application Submission Period, ICANN shall publish either (a) the date in which the next subsequent introduction of new gTLDs will take place or (b) the specific set of criteria and/or events that must occur prior to the opening up of the next subsequent process. Implementation Guidance xx (see rationale 2): A new round may initiate even if steps related to application processing and delegation from previous application windows have not been completed. 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 opportunity. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application opportunity, unless and/or until the applications from the previous round that match those strings have had their final disposition. Discussion: -- Comment: May be worth seeing if the WG can narrow in on a preference here. Or perhaps this makes sense as an unless in a sense, so the date is the preference, unless there is non-exhaustive list of things that would prevent the timely launch? Question: Preference for ICANN Org to set a date, or instead to say what has to happen before a next round? -- In Implementation Guidance we suggested two options since comments were widely varied. -- The first option adds to predictability for applicants. Else applicants may be in limbo for an unknown period of time. -- The second option gets pretty complicated when you are trying to determine contention sets. Not sure how you would do it. -- This is not meant to allow someone to get into an already existing contention set. In both of these cases nothing is going to be processed in a subsequent round until every contention set is resolved and done from the previous round. -- Recommendation: preference is that ICANN publish a date. -- Implementation Guidance: preference is that it should not be possible to apply for a string that is still being processed from a previous application opportunity. -- Disagree that strings from last round should be prohibited. Second option supports the notion of Applicant freedom of expression. -- From a process perspective the above comment would add complications that really aren't warranted. -- No evaluation of the new applicant would occur until the 2012 applications are resolved. The new applicants would have to accept that risk. -- Concerns about treating moribund applications made a decade ago as reservations for the next round. Are the strings that are withdrawn due to name collisions undergoing a process, or are they just on hold? -- What is the harm in keeping a particular string closed for new apps until all the previous applicants have fallen by the wayside. Then it opens up again for all. -- Because the window for application is closed at that point and we haven't said that a new window could open if they all fail. -- If there is agreement that rounds are the path forward, then if a string does not go through in one round it will become available in another round. -- That's one of our recommendations that there will be a series of windows. -- Is there any WG member that would die in a ditch over this option: “It should not be possible to apply for a string in a subsequent round that is still being processed from a previous application round.”? -- Favor the second option. -- Can't live with prohibiting applications for the same string. If "shall not proceed" means new applicants can still apply, I can live with that. -- What about applications that have not progressed on purpose? Or for technical reasons? -- From a pragmatic perspective if we allow for applicants to submit applications for a string that is already in process that adds layers of complexity to the process. If a string hasn’t gone forward to delegation and it becomes available again then it can be applied for. -- We don’t have a system in place that allows for continuing application periods, we have rounds. People should be waiting their turn but they can get in line -- violates applicants’ freedom of expression if they can’t apply. -- The point of the first recommendation is that ICANN Org will set a date certain or criteria that must occur. We are trying to get to a steady state process. -- If someone could apply for a string that is still in process, what we may be encouraging is applicants who might not be fully processed to apply in the next round if they think they are going to fail in the previous round. Need to define in implementation what “in process” means. -- If it would be possible to file applications for the same string in future rounds the door is open for gaming and unknown consequences: applicant(s) from the first round might consider future applicants in their behaviour and decisions. -- Surely, all delegated TLDs or those in process, are off limits. -- I think applicant freedom of expression means you can apply for any string you want, but I don't think that extends to TLDs already in existence or those that are in process in some way. -- Delegated TLDs are not under discussion. -- The point here are those that are not “in process”, so we need to define “in process”. -- Old applications that were denied for a policy reason should have to step up to new policy recommendations if they are going to prevail/ proceed and they should be encouraged to do so by knowing there may be applicants standing in line who are willing to do so. (No stonewalling on new policy recommendations - no blocking based on old policy positions.) -- We already have many categories of Application Status (Active, Applicant Support, Delegated, etc.) -- Question: What about the status “Not Approved”? Answer: That only applies when an application has gone through all of the steps. There will be one or two edge cases. -- Let’s say that we are talking about the names collisions issues and strings that were not delegated -- if new policy is developed by NCAP and may come out of the Board. If there isn’t a new policy they shouldn’t be able to block new applicants. -- An applicant from a prior round who does not want to meet new policy recommendations can block a string forever by not withdrawing a Not Approved application. ACTION ITEM: Change Implementation Guidance to: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Recommendation xx (see rationale 2): Application procedures must take place at predictable, regularly occurring intervals without indeterminable periods of review unless the GNSO Council recommends pausing the program and such recommendation is approved by the Board. Unless and until other procedures are recommended by the GNSO Council and approved by the ICANN Board, ICANN must only use “rounds” as part of the New gTLD Program. Recommendation xx (see rationale 2): Absent extraordinary circumstances, future reviews and/or policy development processes, including the next CCT Review, should take place concurrently with subsequent application rounds. In other words, future reviews and/or policy development processes must not stop or delay subsequent new gTLD rounds. Recommendation xx (See rationale 2). If the outputs of any reviews and/or policy development processes has, or could reasonably have, a material impact on the manner in which application procedures are conducted, such changes must only apply to the opening of the application procedure subsequent to the adoption of the relevant recommendations by the ICANN Board. Discussion: -- Look at these recommendations together. -- If we are clear that applications need to follow all of the timelines before becoming “Not Approved” then they cannot block in future rounds. -- If you have a new policy in the next round that eliminated the problem that blocked a previous string then it should be able to be applied for in the next round. -- Let’s say that .home can move forward but only as a closed generic or .brand where there is a one registrant TLD. What if one of the applicants for .home has no interest in that? Their application needs to be dead. -- Those (.home, .corp, .mail) are not withdrawn even though "not approved". If the Board adopts new name collision policy, old applicants should be willing to step up to the new name collision policy and not be able to refuse to do so and block the string forever by not withdrawing the application. -- Rules should apply in each round to those applicants. -- If you can’t live with the language please suggest new language. -- Problem seems to be how to fix the “Not Approved” applications from the previous round. Board may have to decide how to deal with them. That is out of scope for this WG. _____ 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> _____ 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> _____ 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.
Jeff, I said on the call that this issue is policy. The call transcript is not available yet, but this is in the chat transcript, responding to me: 01:26:52 Justine Chew: +1 Greg on this being a policy issue not IG 01:27:56 Anne Aikman-Scalese: +1 to Greg and Justine - this is a policy issue and it will likely apply in the future to strings we are not even considering at this point. The discussion went on from there, both in the chat transcript (attached) and on the call. The chat transcript mentions "policy" 21 times. There's no definitive test for "policy vs. implementation." All attempts to create one have failed AFAIK. However, one informal "barometer" I use on "policy vs. implementation" is what I call the "WTF Test." If you look at a policy, and the intention is clear and there would be little disagreement about what the implementation would look like (regardless of your "position"), you're good. Anything more detailed tends to be implementation. But, if you look at a policy and say "WTF" (e.g., "WTF were they thinking?", "WTF did they mean by that?", "WTF are we supposed to do with this?") then there's still policy work to be done. In this case, there's still policy work to be done. The range of outcomes discussed were broad and contradictory and the dividing lines that produced one result over another were unclear. There's no clear existing policy or policy recommendation to guide the group, or the implementation team. We need to come out of this with a clear rule about what to do with new applications for strings where there are prior round applications for the same string (or possibly, an overly "similar" string) with these two statuses: - *Not Approved* – The application is not approved and shall not continue in the New gTLD Program as a result of a resolution passed by the ICANN Board of Directors or a Committee of the ICANN Board, such as the New gTLD Program Committee. - *Will Not Proceed* – The application has completed a Program process, and based on the outcome will not continue, as defined in the AGB. This could include process outcomes including but not limited to not passing evaluation, not prevailing a dispute resolution proceeding, not prevailing in contention resolution. Alexander's suggestion makes sense, though I would extend it to both categories above. Perhaps terminated applicants could get a discount if they reapply for the same string. Best regards, Greg On Fri, Feb 7, 2020 at 2:57 PM Alexander Schubert <alexander@schubert.berlin> wrote:
Suggestion:
· 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”).
Thanks,
Alexander.berlin
*From:* Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] *On Behalf Of *Aikman-Scalese, Anne *Sent:* Freitag, 7. Februar 2020 14:00 *To:* Jeff Neuman <jeff.neuman@comlaude.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 - 06 February 2000 UTC
Thanks Jeff. I think the degree of discussion on the call confirms that the issue is not about “every little detail”. It’s a “high level” policy issue.
PROBLEM WE NEED TO SOLVE: As I see it, the biggest problem with the first option is that a prior applicant could effectively block new applicants for a string forever by refusing to withdraw an application that is “Not Approved” for policy reasons and by refusing to adopt the new policy. This is not limited to applications from 2012, it’s about policy going forward and relates to applications we have not yet seen. The issues involved could extend well beyond name collisions in to areas no one has yet anticipated.
PROPOSED COMPROMISE LANGUAGE: Pursuant to your request, I have entered language with a proposed compromise that would accept the first Option but with the caveat that the applicant(s) from the prior round would confirm in writing to the Global Domains Division that they are willing to comply with new policy and the new AGB and that they do so prior to the opening of the window for the next round. If they are unwilling to do so, then new applicants should be permitted to apply for the string in a “back-up offer” position.
Anne
*From:* Jeff Neuman <jeff.neuman@comlaude.com> *Sent:* Friday, February 7, 2020 11:49 AM *To:* 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 - 06 February 2000 UTC
*[EXTERNAL]* ------------------------------
Ok, I tried to clarify because I think I may have said something that inadvertently triggered the policy vs. implementation discussion. What I said was something to the effect of “We could say that the policy is that we will not accept any applications for a string that was applied for in the past round so long as that application was still being *processed.”* And then I followed that up with something like “and we can leave it to the Implementation team to define what it means to still “be in process”.
I must not have communicated that as well as I should have because that is when people started saying that this issue was policy as opposed to implementation (Which was not the point of what I was trying to make).
SO, bottom line, no one said on the call, nor am I aware of anyone that believes, that this issue in general is “policy.” However, if we cannot agree on every little detail, then we can leave some of those details to the Implementation Review Team.
I hope that helps.
*Jeff Neuman*
Senior Vice President
*Com Laude | Valideus*
D: +1.703.635.7514
E: *jeff.neuman@comlaude.com <jeff.neuman@comlaude.com>*
*From:* Aikman-Scalese, Anne <AAikman@lrrc.com> *Sent:* Friday, February 7, 2020 1:32 PM *To:* Jeff Neuman <jeff.neuman@comlaude.com>; Julie Hedlund < julie.hedlund@icann.org>; gnso-newgtld-wg@icann.org *Subject:* RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC
I am just noting that at least three active participants said the whatever we ultimately conclude on this point is policy. I think Greg raised this, with Justine saying +1 and I agreed it’s Policy and then Kathy K. chimed in.
In our report, we have the categories you describe. I know Karen said that Implementation Guidance carries strong weight, but it seemed that the point being made was that the issue was a Policy issue rather than Implementation issue. The distinction likely becomes important for the IRT.
Thank you for asking.
Anne
*From:* Jeff Neuman <jeff.neuman@comlaude.com> *Sent:* Friday, February 7, 2020 9:47 AM *To:* 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 - 06 February 2000 UTC
*[EXTERNAL]* ------------------------------
Just to clarify Anne, are you saying that the proposal to ban new applications for string not yet withdrawn should be labeled as a “recommendation” and opposed to “Implementation Guidance?”
If it something different, than please explain.
*Jeff Neuman*
Senior Vice President
*Com Laude | Valideus*
D: +1.703.635.7514
E: *jeff.neuman@comlaude.com <jeff.neuman@comlaude.com>*
*From:* Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> *On Behalf Of *Aikman-Scalese, Anne *Sent:* Thursday, February 6, 2020 5:42 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 - 06 February 2000 UTC
Thanks Julie – Were you able to capture in the notes the views put forward to the effect that a proposal to ban new applications for strings not yet withdrawn is in fact “Policy” and not “Implementation Guidance”?
Anne
*From:* Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> *On Behalf Of *Julie Hedlund *Sent:* Thursday, February 6, 2020 3:02 PM *To:* gnso-newgtld-wg@icann.org *Subject:* [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC
*[EXTERNAL]* ------------------------------
Dear Working Group members,
Please see below the notes from the meeting on 06 February 2000 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-06+New+gTLD+Subsequent+Pro... .
Kind regards, Julie
*Notes and Action Items:*
*Actions:*
Work Plan:
ACTION ITEM: Staff will send a link to the revised work plan/timeline.
2.2.1 Continuing Subsequent Procedures
ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote.
ACTION ITEM: Change text as follows: “*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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.”
*Notes:*
1. Updates to Statements of Interest:
-- Avri Doria will be participating as one of the Board Liaisons to the WG. The other Board Liaison is Becky Burr.
-- Question: What does that mean in terms of the role of the Board Liaison? Answer: Largely a constrained role; carrying things back and forth between the Board caucus that will be following it -- bringing questions and possibly answers.
-- The goal is not for us to be participants in the PDP, but we want to avoid surprises, such as something that the Board wouldn’t be able to do.
2. Work Plan
-- GNSO Council is trying to ensure realistic deadlines for the PDP WGs and to manage the policy development work.
-- One of the PDP 3.0 recommendations that has been implemented is the need for Project Change Requests when the dates of deliverables cannot be met. As you may know the RPMs PDP WG submitted a Project Change Request for the GNSO Council meeting in January and is revising that request.
-- The SubPro PDP WG Co-Chairs have been asked to submit a modified work plan along with the Project Change Request for the Council to consider at its meeting on 20 February.
-- This is a worst case scenario to avoid having to do another request, but we expect to be able to shave some time off of this.
-- New work plan shows the schedule of meetings to cover all of the topics.
-- Unless the WG can work faster it would be delivering a Final Report by the end of 2020.
-- This is just a preview; a link will be sent later.
-- This is assuming a two meetings per week schedule.
-- Some of these topics may not take two full meetings, but we’ve built that in as a buffer.
-- Some things we could do to streamline this. One that we’ll suggest to the WG and GNSO Council is to have a couple of extended sessions in April and May -- in lieu of face-to-face meetings. Such as two 3-hour sessions in April and May we could save a month or more.
-- New working method: Take after EPDP and ask the WG members to consider what they can live with, with an emphasis on suggesting solutions.
-- Goal is to get the revised work plan and Project Change Request to the Council by early next week.
-- Agree that we would need to schedule longer sessions well in advance, say two months.
ACTION ITEM: Staff will send a link to the revised work plan/timeline.
3. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52... .
Structure:
-- Affirmations are confirming the 2012 policy/AGB.
-- Recommendations are things that must happen.
-- Implementation Guidance are things that should happen.
a. 2.2.1 Continuing Subsequent Procedures
*Affirmation xx (see rationale 1)*: The Working Group recommends that the existing policy contained in the 2012 Applicant Guidebook, that a “systematized manner of applying for gTLDs be developed in the long term,” be maintained.
*Affirmation xx (see rationale 2)*: The Working Group affirms Principle A and recommends that the New gTLD Program must continue to be administered “in an ongoing, orderly, timely and predictable manner.”
*Affirmation xx (see rationale 3)*: The Working Group affirms that the primary purposes of new gTLDs are to foster diversity, encourage competition, and enhance the utility of the DNS*. *
*Recommendation xx (see rationale 3). *Accordingly, the Working Group recommends that meaningful metrics must be identified to understand the impact of the New gTLD Program. The metrics, broadly speaking, should focus on the areas of trust, competition, and choice. To review metrics, data must be collected at a logical time to create a basis against which future data can be compared.
*Discussion*:
-- On the recommendation: Should we cite section 5 of the CCT-RT Final Report for the types of data? There is still some uncertainty as to what will be adopted from that Final Report, so it would be preferable that this could be part of Implementation Guidance. Not trying to override ICANN Org’s plans.
-- Re: metrics -- never seen any commitment from ICANN Org to collect and publish the metrics as recommended by the CCT Final Report. Don’t see how these can be collected.
-- There was discussion in the SubPro Initial Report and in the CCT-RT Final Report; ICANN is aware of the discussions and has a schedule concerning the recommendations.
-- Question from ICANN Org re: the recommendation: Is this some other framework that gets set up to measure the trust, competition, and choice goals over time. Answer: Some of it would be part of the implementation; we wanted a general recommendation about collecting data, but didn’t want to get into a debate on the details. We wanted to leave it to implementation as to what types of data would be collected and how.
-- Question: Was this particular recommendation adopted by the Board or no? Should we refer to data gathering in accordance with whatever Board adopts in relation to the CCT recommendation? Answer: We will add this as Implementation Guidance.
ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote.
b. 2.2.3 Applications Assessed in Rounds
*Affirmation xx (with modification) (see rationale 1)*: The Working Group affirms recommendation 13 from the 2007 policy, which states: “Applications must initially be assessed in rounds until the scale of demand is clear.” However, the Working Group believes that the words “initially” and “until the scale of demand is clear” be removed from the sentence and should just read “Applications must be assessed in rounds.”
*Recommendation xx (see rationale 2)*: Upon the commencement of the next Application Submission Period, there must be clarity around the timing and/or criteria for initiating subsequent procedures from that point forth. More specifically, prior to the commencement of the next Application Submission Period, ICANN shall publish either (a) the date in which the next subsequent introduction of new gTLDs will take place or (b) the specific set of criteria and/or events that must occur prior to the opening up of the next subsequent process.
*Implementation Guidance xx (see rationale 2)*: A new round may initiate even if steps related to application processing and delegation from previous application windows have not been completed.
*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 opportunity. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application opportunity, unless and/or until the applications from the previous round that match those strings have had their final disposition.
*Discussion*:
-- Comment: May be worth seeing if the WG can narrow in on a preference here. Or perhaps this makes sense as an unless in a sense, so the date is the preference, unless there is non-exhaustive list of things that would prevent the timely launch? Question: Preference for ICANN Org to set a date, or instead to say what has to happen before a next round?
-- In Implementation Guidance we suggested two options since comments were widely varied.
-- The first option adds to predictability for applicants. Else applicants may be in limbo for an unknown period of time.
-- The second option gets pretty complicated when you are trying to determine contention sets. Not sure how you would do it.
-- This is not meant to allow someone to get into an already existing contention set. In both of these cases nothing is going to be processed in a subsequent round until every contention set is resolved and done from the previous round.
-- Recommendation: preference is that ICANN publish a date.
-- Implementation Guidance: preference is that it should not be possible to apply for a string that is still being processed from a previous application opportunity.
-- Disagree that strings from last round should be prohibited. Second option supports the notion of Applicant freedom of expression.
-- From a process perspective the above comment would add complications that really aren't warranted.
-- No evaluation of the new applicant would occur until the 2012 applications are resolved. The new applicants would have to accept that risk.
-- Concerns about treating moribund applications made a decade ago as reservations for the next round. Are the strings that are withdrawn due to name collisions undergoing a process, or are they just on hold?
-- What is the harm in keeping a particular string closed for new apps until all the previous applicants have fallen by the wayside. Then it opens up again for all.
-- Because the window for application is closed at that point and we haven't said that a new window could open if they all fail.
-- If there is agreement that rounds are the path forward, then if a string does not go through in one round it will become available in another round.
-- That's one of our recommendations that there will be a series of windows.
-- Is there any WG member that would die in a ditch over this option: “It should not be possible to apply for a string in a subsequent round that is still being processed from a previous application round.”?
-- Favor the second option.
-- Can't live with prohibiting applications for the same string. If "shall not proceed" means new applicants can still apply, I can live with that.
-- What about applications that have not progressed on purpose? Or for technical reasons?
-- From a pragmatic perspective if we allow for applicants to submit applications for a string that is already in process that adds layers of complexity to the process. If a string hasn’t gone forward to delegation and it becomes available again then it can be applied for.
-- We don’t have a system in place that allows for continuing application periods, we have rounds. People should be waiting their turn but they can get in line -- violates applicants’ freedom of expression if they can’t apply.
-- The point of the first recommendation is that ICANN Org will set a date certain or criteria that must occur. We are trying to get to a steady state process.
-- If someone could apply for a string that is still in process, what we may be encouraging is applicants who might not be fully processed to apply in the next round if they think they are going to fail in the previous round. Need to define in implementation what “in process” means.
-- If it would be possible to file applications for the same string in future rounds the door is open for gaming and unknown consequences: applicant(s) from the first round might consider future applicants in their behaviour and decisions.
-- Surely, all delegated TLDs or those in process, are off limits.
-- I think applicant freedom of expression means you can apply for any string you want, but I don't think that extends to TLDs already in existence or those that are in process in some way.
-- Delegated TLDs are not under discussion.
-- The point here are those that are not “in process”, so we need to define “in process”.
-- Old applications that were denied for a policy reason should have to step up to new policy recommendations if they are going to prevail/ proceed and they should be encouraged to do so by knowing there may be applicants standing in line who are willing to do so. (No stonewalling on new policy recommendations - no blocking based on old policy positions.)
-- We already have many categories of Application Status (Active, Applicant Support, Delegated, etc.)
-- Question: What about the status “Not Approved”? Answer: That only applies when an application has gone through all of the steps. There will be one or two edge cases.
-- Let’s say that we are talking about the names collisions issues and strings that were not delegated -- if new policy is developed by NCAP and may come out of the Board. If there isn’t a new policy they shouldn’t be able to block new applicants.
-- An applicant from a prior round who does not want to meet new policy recommendations can block a string forever by not withdrawing a Not Approved application.
ACTION ITEM: Change Implementation Guidance to: “*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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.”
*Recommendation xx (see rationale 2)*: Application procedures must take place at predictable, regularly occurring intervals without indeterminable periods of review unless the GNSO Council recommends pausing the program and such recommendation is approved by the Board. Unless and until other procedures are recommended by the GNSO Council and approved by the ICANN Board, ICANN must only use “rounds” as part of the New gTLD Program.
*Recommendation xx (see rationale 2)*: Absent extraordinary circumstances, future reviews and/or policy development processes, including the next CCT Review, should take place concurrently with subsequent application rounds. In other words, future reviews and/or policy development processes must not stop or delay subsequent new gTLD rounds.
*Recommendation xx (See rationale 2). *If the outputs of any reviews and/or policy development processes has, or could reasonably have, a material impact on the manner in which application procedures are conducted, such changes must only apply to the opening of the application procedure subsequent to the adoption of the relevant recommendations by the ICANN Board.
*Discussion*:
-- Look at these recommendations together.
-- If we are clear that applications need to follow all of the timelines before becoming “Not Approved” then they cannot block in future rounds.
-- If you have a new policy in the next round that eliminated the problem that blocked a previous string then it should be able to be applied for in the next round.
-- Let’s say that .home can move forward but only as a closed generic or .brand where there is a one registrant TLD. What if one of the applicants for .home has no interest in that? Their application needs to be dead.
-- Those (.home, .corp, .mail) are not withdrawn even though "not approved". If the Board adopts new name collision policy, old applicants should be willing to step up to the new name collision policy and not be able to refuse to do so and block the string forever by not withdrawing the application.
-- Rules should apply in each round to those applicants.
-- If you can’t live with the language please suggest new language.
-- Problem seems to be how to fix the “Not Approved” applications from the previous round. Board may have to decide how to deal with them. That is out of scope for this WG.
------------------------------
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>
------------------------------
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>
------------------------------
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. _______________________________________________ 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.
Regardless of whether this is a policy or implementation issue, I just want to note that there were 20+ people on the call and I’d like to understand how we’re taking into account the views of others that had expressed a different opinion to Greg, Anne, Justine and Kathy who came in very very late in the call about the substance of the issue. Donna From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Greg Shatan Sent: Friday, February 07, 2020 12:55 PM To: Alexander Schubert <alexander@schubert.berlin> Cc: gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC Jeff, I said on the call that this issue is policy. The call transcript is not available yet, but this is in the chat transcript, responding to me: 01:26:52 Justine Chew: +1 Greg on this being a policy issue not IG 01:27:56 Anne Aikman-Scalese: +1 to Greg and Justine - this is a policy issue and it will likely apply in the future to strings we are not even considering at this point. The discussion went on from there, both in the chat transcript (attached) and on the call. The chat transcript mentions "policy" 21 times. There's no definitive test for "policy vs. implementation." All attempts to create one have failed AFAIK. However, one informal "barometer" I use on "policy vs. implementation" is what I call the "WTF Test." If you look at a policy, and the intention is clear and there would be little disagreement about what the implementation would look like (regardless of your "position"), you're good. Anything more detailed tends to be implementation. But, if you look at a policy and say "WTF" (e.g., "WTF were they thinking?", "WTF did they mean by that?", "WTF are we supposed to do with this?") then there's still policy work to be done. In this case, there's still policy work to be done. The range of outcomes discussed were broad and contradictory and the dividing lines that produced one result over another were unclear. There's no clear existing policy or policy recommendation to guide the group, or the implementation team. We need to come out of this with a clear rule about what to do with new applications for strings where there are prior round applications for the same string (or possibly, an overly "similar" string) with these two statuses: · Not Approved – The application is not approved and shall not continue in the New gTLD Program as a result of a resolution passed by the ICANN Board of Directors or a Committee of the ICANN Board, such as the New gTLD Program Committee. · Will Not Proceed – The application has completed a Program process, and based on the outcome will not continue, as defined in the AGB. This could include process outcomes including but not limited to not passing evaluation, not prevailing a dispute resolution proceeding, not prevailing in contention resolution. Alexander's suggestion makes sense, though I would extend it to both categories above. Perhaps terminated applicants could get a discount if they reapply for the same string. Best regards, Greg On Fri, Feb 7, 2020 at 2:57 PM Alexander Schubert <alexander@schubert.berlin<mailto:alexander@schubert.berlin>> wrote: Suggestion: • 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”). Thanks, Alexander.berlin From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>] On Behalf Of Aikman-Scalese, Anne Sent: Freitag, 7. Februar 2020 14:00 To: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.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 - 06 February 2000 UTC Thanks Jeff. I think the degree of discussion on the call confirms that the issue is not about “every little detail”. It’s a “high level” policy issue. PROBLEM WE NEED TO SOLVE: As I see it, the biggest problem with the first option is that a prior applicant could effectively block new applicants for a string forever by refusing to withdraw an application that is “Not Approved” for policy reasons and by refusing to adopt the new policy. This is not limited to applications from 2012, it’s about policy going forward and relates to applications we have not yet seen. The issues involved could extend well beyond name collisions in to areas no one has yet anticipated. PROPOSED COMPROMISE LANGUAGE: Pursuant to your request, I have entered language with a proposed compromise that would accept the first Option but with the caveat that the applicant(s) from the prior round would confirm in writing to the Global Domains Division that they are willing to comply with new policy and the new AGB and that they do so prior to the opening of the window for the next round. If they are unwilling to do so, then new applicants should be permitted to apply for the string in a “back-up offer” position. Anne From: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com>> Sent: Friday, February 7, 2020 11:49 AM To: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Ok, I tried to clarify because I think I may have said something that inadvertently triggered the policy vs. implementation discussion. What I said was something to the effect of “We could say that the policy is that we will not accept any applications for a string that was applied for in the past round so long as that application was still being processed.” And then I followed that up with something like “and we can leave it to the Implementation team to define what it means to still “be in process”. I must not have communicated that as well as I should have because that is when people started saying that this issue was policy as opposed to implementation (Which was not the point of what I was trying to make). SO, bottom line, no one said on the call, nor am I aware of anyone that believes, that this issue in general is “policy.” However, if we cannot agree on every little detail, then we can leave some of those details to the Implementation Review Team. I hope that helps. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> From: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> Sent: Friday, February 7, 2020 1:32 PM To: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.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 - 06 February 2000 UTC I am just noting that at least three active participants said the whatever we ultimately conclude on this point is policy. I think Greg raised this, with Justine saying +1 and I agreed it’s Policy and then Kathy K. chimed in. In our report, we have the categories you describe. I know Karen said that Implementation Guidance carries strong weight, but it seemed that the point being made was that the issue was a Policy issue rather than Implementation issue. The distinction likely becomes important for the IRT. Thank you for asking. Anne From: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com>> Sent: Friday, February 7, 2020 9:47 AM To: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Just to clarify Anne, are you saying that the proposal to ban new applications for string not yet withdrawn should be labeled as a “recommendation” and opposed to “Implementation Guidance?” If it something different, than please explain. 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: Thursday, February 6, 2020 5:42 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 - 06 February 2000 UTC Thanks Julie – Were you able to capture in the notes the views put forward to the effect that a proposal to ban new applications for strings not yet withdrawn is in fact “Policy” and not “Implementation Guidance”? Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Julie Hedlund Sent: Thursday, February 6, 2020 3:02 PM 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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting on 06 February 2000 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-06+New+gTLD+Subsequent+Procedures+PDP<https://urldefense.com/v3/__https:/community.icann.org/display/NGSPP/2020-02-06*New*gTLD*Subsequent*Procedures*PDP__;KysrKys!!N14HnBHF!s4tj4qIGGIEtRUSiY5ZWvIw3ZZR0JYvJefEekRkbL4V03SkujCraUkAOfPgsleKdHoc0$>. Kind regards, Julie Notes and Action Items: Actions: Work Plan: ACTION ITEM: Staff will send a link to the revised work plan/timeline. 2.2.1 Continuing Subsequent Procedures ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. ACTION ITEM: Change text as follows: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Notes: 1. Updates to Statements of Interest: -- Avri Doria will be participating as one of the Board Liaisons to the WG. The other Board Liaison is Becky Burr. -- Question: What does that mean in terms of the role of the Board Liaison? Answer: Largely a constrained role; carrying things back and forth between the Board caucus that will be following it -- bringing questions and possibly answers. -- The goal is not for us to be participants in the PDP, but we want to avoid surprises, such as something that the Board wouldn’t be able to do. 2. Work Plan -- GNSO Council is trying to ensure realistic deadlines for the PDP WGs and to manage the policy development work. -- One of the PDP 3.0 recommendations that has been implemented is the need for Project Change Requests when the dates of deliverables cannot be met. As you may know the RPMs PDP WG submitted a Project Change Request for the GNSO Council meeting in January and is revising that request. -- The SubPro PDP WG Co-Chairs have been asked to submit a modified work plan along with the Project Change Request for the Council to consider at its meeting on 20 February. -- This is a worst case scenario to avoid having to do another request, but we expect to be able to shave some time off of this. -- New work plan shows the schedule of meetings to cover all of the topics. -- Unless the WG can work faster it would be delivering a Final Report by the end of 2020. -- This is just a preview; a link will be sent later. -- This is assuming a two meetings per week schedule. -- Some of these topics may not take two full meetings, but we’ve built that in as a buffer. -- Some things we could do to streamline this. One that we’ll suggest to the WG and GNSO Council is to have a couple of extended sessions in April and May -- in lieu of face-to-face meetings. Such as two 3-hour sessions in April and May we could save a month or more. -- New working method: Take after EPDP and ask the WG members to consider what they can live with, with an emphasis on suggesting solutions. -- Goal is to get the revised work plan and Project Change Request to the Council by early next week. -- Agree that we would need to schedule longer sessions well in advance, say two months. ACTION ITEM: Staff will send a link to the revised work plan/timeline. 3. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing<https://urldefense.com/v3/__https:/docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing__;!!N14HnBHF!s4tj4qIGGIEtRUSiY5ZWvIw3ZZR0JYvJefEekRkbL4V03SkujCraUkAOfPgsleDAw8U2$>. Structure: -- Affirmations are confirming the 2012 policy/AGB. -- Recommendations are things that must happen. -- Implementation Guidance are things that should happen. a. 2.2.1 Continuing Subsequent Procedures Affirmation xx (see rationale 1): The Working Group recommends that the existing policy contained in the 2012 Applicant Guidebook, that a “systematized manner of applying for gTLDs be developed in the long term,” be maintained. Affirmation xx (see rationale 2): The Working Group affirms Principle A and recommends that the New gTLD Program must continue to be administered “in an ongoing, orderly, timely and predictable manner.” Affirmation xx (see rationale 3): The Working Group affirms that the primary purposes of new gTLDs are to foster diversity, encourage competition, and enhance the utility of the DNS. Recommendation xx (see rationale 3). Accordingly, the Working Group recommends that meaningful metrics must be identified to understand the impact of the New gTLD Program. The metrics, broadly speaking, should focus on the areas of trust, competition, and choice. To review metrics, data must be collected at a logical time to create a basis against which future data can be compared. Discussion: -- On the recommendation: Should we cite section 5 of the CCT-RT Final Report for the types of data? There is still some uncertainty as to what will be adopted from that Final Report, so it would be preferable that this could be part of Implementation Guidance. Not trying to override ICANN Org’s plans. -- Re: metrics -- never seen any commitment from ICANN Org to collect and publish the metrics as recommended by the CCT Final Report. Don’t see how these can be collected. -- There was discussion in the SubPro Initial Report and in the CCT-RT Final Report; ICANN is aware of the discussions and has a schedule concerning the recommendations. -- Question from ICANN Org re: the recommendation: Is this some other framework that gets set up to measure the trust, competition, and choice goals over time. Answer: Some of it would be part of the implementation; we wanted a general recommendation about collecting data, but didn’t want to get into a debate on the details. We wanted to leave it to implementation as to what types of data would be collected and how. -- Question: Was this particular recommendation adopted by the Board or no? Should we refer to data gathering in accordance with whatever Board adopts in relation to the CCT recommendation? Answer: We will add this as Implementation Guidance. ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. b. 2.2.3 Applications Assessed in Rounds Affirmation xx (with modification) (see rationale 1): The Working Group affirms recommendation 13 from the 2007 policy, which states: “Applications must initially be assessed in rounds until the scale of demand is clear.” However, the Working Group believes that the words “initially” and “until the scale of demand is clear” be removed from the sentence and should just read “Applications must be assessed in rounds.” Recommendation xx (see rationale 2): Upon the commencement of the next Application Submission Period, there must be clarity around the timing and/or criteria for initiating subsequent procedures from that point forth. More specifically, prior to the commencement of the next Application Submission Period, ICANN shall publish either (a) the date in which the next subsequent introduction of new gTLDs will take place or (b) the specific set of criteria and/or events that must occur prior to the opening up of the next subsequent process. Implementation Guidance xx (see rationale 2): A new round may initiate even if steps related to application processing and delegation from previous application windows have not been completed. 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 opportunity. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application opportunity, unless and/or until the applications from the previous round that match those strings have had their final disposition. Discussion: -- Comment: May be worth seeing if the WG can narrow in on a preference here. Or perhaps this makes sense as an unless in a sense, so the date is the preference, unless there is non-exhaustive list of things that would prevent the timely launch? Question: Preference for ICANN Org to set a date, or instead to say what has to happen before a next round? -- In Implementation Guidance we suggested two options since comments were widely varied. -- The first option adds to predictability for applicants. Else applicants may be in limbo for an unknown period of time. -- The second option gets pretty complicated when you are trying to determine contention sets. Not sure how you would do it. -- This is not meant to allow someone to get into an already existing contention set. In both of these cases nothing is going to be processed in a subsequent round until every contention set is resolved and done from the previous round. -- Recommendation: preference is that ICANN publish a date. -- Implementation Guidance: preference is that it should not be possible to apply for a string that is still being processed from a previous application opportunity. -- Disagree that strings from last round should be prohibited. Second option supports the notion of Applicant freedom of expression. -- From a process perspective the above comment would add complications that really aren't warranted. -- No evaluation of the new applicant would occur until the 2012 applications are resolved. The new applicants would have to accept that risk. -- Concerns about treating moribund applications made a decade ago as reservations for the next round. Are the strings that are withdrawn due to name collisions undergoing a process, or are they just on hold? -- What is the harm in keeping a particular string closed for new apps until all the previous applicants have fallen by the wayside. Then it opens up again for all. -- Because the window for application is closed at that point and we haven't said that a new window could open if they all fail. -- If there is agreement that rounds are the path forward, then if a string does not go through in one round it will become available in another round. -- That's one of our recommendations that there will be a series of windows. -- Is there any WG member that would die in a ditch over this option: “It should not be possible to apply for a string in a subsequent round that is still being processed from a previous application round.”? -- Favor the second option. -- Can't live with prohibiting applications for the same string. If "shall not proceed" means new applicants can still apply, I can live with that. -- What about applications that have not progressed on purpose? Or for technical reasons? -- From a pragmatic perspective if we allow for applicants to submit applications for a string that is already in process that adds layers of complexity to the process. If a string hasn’t gone forward to delegation and it becomes available again then it can be applied for. -- We don’t have a system in place that allows for continuing application periods, we have rounds. People should be waiting their turn but they can get in line -- violates applicants’ freedom of expression if they can’t apply. -- The point of the first recommendation is that ICANN Org will set a date certain or criteria that must occur. We are trying to get to a steady state process. -- If someone could apply for a string that is still in process, what we may be encouraging is applicants who might not be fully processed to apply in the next round if they think they are going to fail in the previous round. Need to define in implementation what “in process” means. -- If it would be possible to file applications for the same string in future rounds the door is open for gaming and unknown consequences: applicant(s) from the first round might consider future applicants in their behaviour and decisions. -- Surely, all delegated TLDs or those in process, are off limits. -- I think applicant freedom of expression means you can apply for any string you want, but I don't think that extends to TLDs already in existence or those that are in process in some way. -- Delegated TLDs are not under discussion. -- The point here are those that are not “in process”, so we need to define “in process”. -- Old applications that were denied for a policy reason should have to step up to new policy recommendations if they are going to prevail/ proceed and they should be encouraged to do so by knowing there may be applicants standing in line who are willing to do so. (No stonewalling on new policy recommendations - no blocking based on old policy positions.) -- We already have many categories of Application Status (Active, Applicant Support, Delegated, etc.) -- Question: What about the status “Not Approved”? Answer: That only applies when an application has gone through all of the steps. There will be one or two edge cases. -- Let’s say that we are talking about the names collisions issues and strings that were not delegated -- if new policy is developed by NCAP and may come out of the Board. If there isn’t a new policy they shouldn’t be able to block new applicants. -- An applicant from a prior round who does not want to meet new policy recommendations can block a string forever by not withdrawing a Not Approved application. ACTION ITEM: Change Implementation Guidance to: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Recommendation xx (see rationale 2): Application procedures must take place at predictable, regularly occurring intervals without indeterminable periods of review unless the GNSO Council recommends pausing the program and such recommendation is approved by the Board. Unless and until other procedures are recommended by the GNSO Council and approved by the ICANN Board, ICANN must only use “rounds” as part of the New gTLD Program. Recommendation xx (see rationale 2): Absent extraordinary circumstances, future reviews and/or policy development processes, including the next CCT Review, should take place concurrently with subsequent application rounds. In other words, future reviews and/or policy development processes must not stop or delay subsequent new gTLD rounds. Recommendation xx (See rationale 2). If the outputs of any reviews and/or policy development processes has, or could reasonably have, a material impact on the manner in which application procedures are conducted, such changes must only apply to the opening of the application procedure subsequent to the adoption of the relevant recommendations by the ICANN Board. Discussion: -- Look at these recommendations together. -- If we are clear that applications need to follow all of the timelines before becoming “Not Approved” then they cannot block in future rounds. -- If you have a new policy in the next round that eliminated the problem that blocked a previous string then it should be able to be applied for in the next round. -- Let’s say that .home can move forward but only as a closed generic or .brand where there is a one registrant TLD. What if one of the applicants for .home has no interest in that? Their application needs to be dead. -- Those (.home, .corp, .mail) are not withdrawn even though "not approved". If the Board adopts new name collision policy, old applicants should be willing to step up to the new name collision policy and not be able to refuse to do so and block the string forever by not withdrawing the application. -- Rules should apply in each round to those applicants. -- If you can’t live with the language please suggest new language. -- Problem seems to be how to fix the “Not Approved” applications from the previous round. Board may have to decide how to deal with them. That is out of scope for this WG. ________________________________ 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://urldefense.com/v3/__https:/comlaude.com__;!!N14HnBHF!s4tj4qIGGIEtRUS...> ________________________________ 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://urldefense.com/v3/__https:/comlaude.com__;!!N14HnBHF!s4tj4qIGGIEtRUS...> ________________________________ 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. _______________________________________________ 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<https://urldefense.com/v3/__https:/mm.icann.org/mailman/listinfo/gnso-newgtld-wg__;!!N14HnBHF!s4tj4qIGGIEtRUSiY5ZWvIw3ZZR0JYvJefEekRkbL4V03SkujCraUkAOfPgslTa0psJZ$> _______________________________________________ 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<https://urldefense.com/v3/__https:/www.icann.org/privacy/policy__;!!N14HnBHF!s4tj4qIGGIEtRUSiY5ZWvIw3ZZR0JYvJefEekRkbL4V03SkujCraUkAOfPgslRawcG16$>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://urldefense.com/v3/__https:/www.icann.org/privacy/tos__;!!N14HnBHF!s4tj4qIGGIEtRUSiY5ZWvIw3ZZR0JYvJefEekRkbL4V03SkujCraUkAOfPgslUaU6myt$>). 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.
Thanks for raising this Donna, there is a big difference between a few people being heard vs the group agreeing to adopt what they say. Jeff, thanks for the detailed listing of outcomes which makes it suitably clear and puts the issue into perspective (as was also attempted on the call by others). Keeping it simple, your text could be lifted and used as implementation guidance, supporting the policy that no applications can be accepted for previously applied strings that are delegated or in process. Kind regards, Martin Sent from my iPhone On 9 Feb 2020, at 00:56, Austin, Donna via Gnso-newgtld-wg <gnso-newgtld-wg@icann.org> wrote: Regardless of whether this is a policy or implementation issue, I just want to note that there were 20+ people on the call and I’d like to understand how we’re taking into account the views of others that had expressed a different opinion to Greg, Anne, Justine and Kathy who came in very very late in the call about the substance of the issue. Donna From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Greg Shatan Sent: Friday, February 07, 2020 12:55 PM To: Alexander Schubert <alexander@schubert.berlin> Cc: gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC Jeff, I said on the call that this issue is policy. The call transcript is not available yet, but this is in the chat transcript, responding to me: 01:26:52 Justine Chew: +1 Greg on this being a policy issue not IG 01:27:56 Anne Aikman-Scalese: +1 to Greg and Justine - this is a policy issue and it will likely apply in the future to strings we are not even considering at this point. The discussion went on from there, both in the chat transcript (attached) and on the call. The chat transcript mentions "policy" 21 times. There's no definitive test for "policy vs. implementation." All attempts to create one have failed AFAIK. However, one informal "barometer" I use on "policy vs. implementation" is what I call the "WTF Test." If you look at a policy, and the intention is clear and there would be little disagreement about what the implementation would look like (regardless of your "position"), you're good. Anything more detailed tends to be implementation. But, if you look at a policy and say "WTF" (e.g., "WTF were they thinking?", "WTF did they mean by that?", "WTF are we supposed to do with this?") then there's still policy work to be done. In this case, there's still policy work to be done. The range of outcomes discussed were broad and contradictory and the dividing lines that produced one result over another were unclear. There's no clear existing policy or policy recommendation to guide the group, or the implementation team. We need to come out of this with a clear rule about what to do with new applications for strings where there are prior round applications for the same string (or possibly, an overly "similar" string) with these two statuses: · Not Approved – The application is not approved and shall not continue in the New gTLD Program as a result of a resolution passed by the ICANN Board of Directors or a Committee of the ICANN Board, such as the New gTLD Program Committee. · Will Not Proceed – The application has completed a Program process, and based on the outcome will not continue, as defined in the AGB. This could include process outcomes including but not limited to not passing evaluation, not prevailing a dispute resolution proceeding, not prevailing in contention resolution. Alexander's suggestion makes sense, though I would extend it to both categories above. Perhaps terminated applicants could get a discount if they reapply for the same string. Best regards, Greg On Fri, Feb 7, 2020 at 2:57 PM Alexander Schubert <alexander@schubert.berlin<mailto:alexander@schubert.berlin>> wrote: Suggestion: • 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”). Thanks, Alexander.berlin From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>] On Behalf Of Aikman-Scalese, Anne Sent: Freitag, 7. Februar 2020 14:00 To: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.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 - 06 February 2000 UTC Thanks Jeff. I think the degree of discussion on the call confirms that the issue is not about “every little detail”. It’s a “high level” policy issue. PROBLEM WE NEED TO SOLVE: As I see it, the biggest problem with the first option is that a prior applicant could effectively block new applicants for a string forever by refusing to withdraw an application that is “Not Approved” for policy reasons and by refusing to adopt the new policy. This is not limited to applications from 2012, it’s about policy going forward and relates to applications we have not yet seen. The issues involved could extend well beyond name collisions in to areas no one has yet anticipated. PROPOSED COMPROMISE LANGUAGE: Pursuant to your request, I have entered language with a proposed compromise that would accept the first Option but with the caveat that the applicant(s) from the prior round would confirm in writing to the Global Domains Division that they are willing to comply with new policy and the new AGB and that they do so prior to the opening of the window for the next round. If they are unwilling to do so, then new applicants should be permitted to apply for the string in a “back-up offer” position. Anne From: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com>> Sent: Friday, February 7, 2020 11:49 AM To: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Ok, I tried to clarify because I think I may have said something that inadvertently triggered the policy vs. implementation discussion. What I said was something to the effect of “We could say that the policy is that we will not accept any applications for a string that was applied for in the past round so long as that application was still being processed.” And then I followed that up with something like “and we can leave it to the Implementation team to define what it means to still “be in process”. I must not have communicated that as well as I should have because that is when people started saying that this issue was policy as opposed to implementation (Which was not the point of what I was trying to make). SO, bottom line, no one said on the call, nor am I aware of anyone that believes, that this issue in general is “policy.” However, if we cannot agree on every little detail, then we can leave some of those details to the Implementation Review Team. I hope that helps. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> From: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> Sent: Friday, February 7, 2020 1:32 PM To: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.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 - 06 February 2000 UTC I am just noting that at least three active participants said the whatever we ultimately conclude on this point is policy. I think Greg raised this, with Justine saying +1 and I agreed it’s Policy and then Kathy K. chimed in. In our report, we have the categories you describe. I know Karen said that Implementation Guidance carries strong weight, but it seemed that the point being made was that the issue was a Policy issue rather than Implementation issue. The distinction likely becomes important for the IRT. Thank you for asking. Anne From: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com>> Sent: Friday, February 7, 2020 9:47 AM To: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Just to clarify Anne, are you saying that the proposal to ban new applications for string not yet withdrawn should be labeled as a “recommendation” and opposed to “Implementation Guidance?” If it something different, than please explain. 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: Thursday, February 6, 2020 5:42 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 - 06 February 2000 UTC Thanks Julie – Were you able to capture in the notes the views put forward to the effect that a proposal to ban new applications for strings not yet withdrawn is in fact “Policy” and not “Implementation Guidance”? Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Julie Hedlund Sent: Thursday, February 6, 2020 3:02 PM 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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting on 06 February 2000 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-06+New+gTLD+Subsequent+Procedures+PDP<https://urldefense.com/v3/__https:/community.icann.org/display/NGSPP/2020-02-06*New*gTLD*Subsequent*Procedures*PDP__;KysrKys!!N14HnBHF!s4tj4qIGGIEtRUSiY5ZWvIw3ZZR0JYvJefEekRkbL4V03SkujCraUkAOfPgsleKdHoc0$>. Kind regards, Julie Notes and Action Items: Actions: Work Plan: ACTION ITEM: Staff will send a link to the revised work plan/timeline. 2.2.1 Continuing Subsequent Procedures ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. ACTION ITEM: Change text as follows: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Notes: 1. Updates to Statements of Interest: -- Avri Doria will be participating as one of the Board Liaisons to the WG. The other Board Liaison is Becky Burr. -- Question: What does that mean in terms of the role of the Board Liaison? Answer: Largely a constrained role; carrying things back and forth between the Board caucus that will be following it -- bringing questions and possibly answers. -- The goal is not for us to be participants in the PDP, but we want to avoid surprises, such as something that the Board wouldn’t be able to do. 2. Work Plan -- GNSO Council is trying to ensure realistic deadlines for the PDP WGs and to manage the policy development work. -- One of the PDP 3.0 recommendations that has been implemented is the need for Project Change Requests when the dates of deliverables cannot be met. As you may know the RPMs PDP WG submitted a Project Change Request for the GNSO Council meeting in January and is revising that request. -- The SubPro PDP WG Co-Chairs have been asked to submit a modified work plan along with the Project Change Request for the Council to consider at its meeting on 20 February. -- This is a worst case scenario to avoid having to do another request, but we expect to be able to shave some time off of this. -- New work plan shows the schedule of meetings to cover all of the topics. -- Unless the WG can work faster it would be delivering a Final Report by the end of 2020. -- This is just a preview; a link will be sent later. -- This is assuming a two meetings per week schedule. -- Some of these topics may not take two full meetings, but we’ve built that in as a buffer. -- Some things we could do to streamline this. One that we’ll suggest to the WG and GNSO Council is to have a couple of extended sessions in April and May -- in lieu of face-to-face meetings. Such as two 3-hour sessions in April and May we could save a month or more. -- New working method: Take after EPDP and ask the WG members to consider what they can live with, with an emphasis on suggesting solutions. -- Goal is to get the revised work plan and Project Change Request to the Council by early next week. -- Agree that we would need to schedule longer sessions well in advance, say two months. ACTION ITEM: Staff will send a link to the revised work plan/timeline. 3. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing<https://urldefense.com/v3/__https:/docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing__;!!N14HnBHF!s4tj4qIGGIEtRUSiY5ZWvIw3ZZR0JYvJefEekRkbL4V03SkujCraUkAOfPgsleDAw8U2$>. Structure: -- Affirmations are confirming the 2012 policy/AGB. -- Recommendations are things that must happen. -- Implementation Guidance are things that should happen. a. 2.2.1 Continuing Subsequent Procedures Affirmation xx (see rationale 1): The Working Group recommends that the existing policy contained in the 2012 Applicant Guidebook, that a “systematized manner of applying for gTLDs be developed in the long term,” be maintained. Affirmation xx (see rationale 2): The Working Group affirms Principle A and recommends that the New gTLD Program must continue to be administered “in an ongoing, orderly, timely and predictable manner.” Affirmation xx (see rationale 3): The Working Group affirms that the primary purposes of new gTLDs are to foster diversity, encourage competition, and enhance the utility of the DNS. Recommendation xx (see rationale 3). Accordingly, the Working Group recommends that meaningful metrics must be identified to understand the impact of the New gTLD Program. The metrics, broadly speaking, should focus on the areas of trust, competition, and choice. To review metrics, data must be collected at a logical time to create a basis against which future data can be compared. Discussion: -- On the recommendation: Should we cite section 5 of the CCT-RT Final Report for the types of data? There is still some uncertainty as to what will be adopted from that Final Report, so it would be preferable that this could be part of Implementation Guidance. Not trying to override ICANN Org’s plans. -- Re: metrics -- never seen any commitment from ICANN Org to collect and publish the metrics as recommended by the CCT Final Report. Don’t see how these can be collected. -- There was discussion in the SubPro Initial Report and in the CCT-RT Final Report; ICANN is aware of the discussions and has a schedule concerning the recommendations. -- Question from ICANN Org re: the recommendation: Is this some other framework that gets set up to measure the trust, competition, and choice goals over time. Answer: Some of it would be part of the implementation; we wanted a general recommendation about collecting data, but didn’t want to get into a debate on the details. We wanted to leave it to implementation as to what types of data would be collected and how. -- Question: Was this particular recommendation adopted by the Board or no? Should we refer to data gathering in accordance with whatever Board adopts in relation to the CCT recommendation? Answer: We will add this as Implementation Guidance. ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. b. 2.2.3 Applications Assessed in Rounds Affirmation xx (with modification) (see rationale 1): The Working Group affirms recommendation 13 from the 2007 policy, which states: “Applications must initially be assessed in rounds until the scale of demand is clear.” However, the Working Group believes that the words “initially” and “until the scale of demand is clear” be removed from the sentence and should just read “Applications must be assessed in rounds.” Recommendation xx (see rationale 2): Upon the commencement of the next Application Submission Period, there must be clarity around the timing and/or criteria for initiating subsequent procedures from that point forth. More specifically, prior to the commencement of the next Application Submission Period, ICANN shall publish either (a) the date in which the next subsequent introduction of new gTLDs will take place or (b) the specific set of criteria and/or events that must occur prior to the opening up of the next subsequent process. Implementation Guidance xx (see rationale 2): A new round may initiate even if steps related to application processing and delegation from previous application windows have not been completed. 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 opportunity. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application opportunity, unless and/or until the applications from the previous round that match those strings have had their final disposition. Discussion: -- Comment: May be worth seeing if the WG can narrow in on a preference here. Or perhaps this makes sense as an unless in a sense, so the date is the preference, unless there is non-exhaustive list of things that would prevent the timely launch? Question: Preference for ICANN Org to set a date, or instead to say what has to happen before a next round? -- In Implementation Guidance we suggested two options since comments were widely varied. -- The first option adds to predictability for applicants. Else applicants may be in limbo for an unknown period of time. -- The second option gets pretty complicated when you are trying to determine contention sets. Not sure how you would do it. -- This is not meant to allow someone to get into an already existing contention set. In both of these cases nothing is going to be processed in a subsequent round until every contention set is resolved and done from the previous round. -- Recommendation: preference is that ICANN publish a date. -- Implementation Guidance: preference is that it should not be possible to apply for a string that is still being processed from a previous application opportunity. -- Disagree that strings from last round should be prohibited. Second option supports the notion of Applicant freedom of expression. -- From a process perspective the above comment would add complications that really aren't warranted. -- No evaluation of the new applicant would occur until the 2012 applications are resolved. The new applicants would have to accept that risk. -- Concerns about treating moribund applications made a decade ago as reservations for the next round. Are the strings that are withdrawn due to name collisions undergoing a process, or are they just on hold? -- What is the harm in keeping a particular string closed for new apps until all the previous applicants have fallen by the wayside. Then it opens up again for all. -- Because the window for application is closed at that point and we haven't said that a new window could open if they all fail. -- If there is agreement that rounds are the path forward, then if a string does not go through in one round it will become available in another round. -- That's one of our recommendations that there will be a series of windows. -- Is there any WG member that would die in a ditch over this option: “It should not be possible to apply for a string in a subsequent round that is still being processed from a previous application round.”? -- Favor the second option. -- Can't live with prohibiting applications for the same string. If "shall not proceed" means new applicants can still apply, I can live with that. -- What about applications that have not progressed on purpose? Or for technical reasons? -- From a pragmatic perspective if we allow for applicants to submit applications for a string that is already in process that adds layers of complexity to the process. If a string hasn’t gone forward to delegation and it becomes available again then it can be applied for. -- We don’t have a system in place that allows for continuing application periods, we have rounds. People should be waiting their turn but they can get in line -- violates applicants’ freedom of expression if they can’t apply. -- The point of the first recommendation is that ICANN Org will set a date certain or criteria that must occur. We are trying to get to a steady state process. -- If someone could apply for a string that is still in process, what we may be encouraging is applicants who might not be fully processed to apply in the next round if they think they are going to fail in the previous round. Need to define in implementation what “in process” means. -- If it would be possible to file applications for the same string in future rounds the door is open for gaming and unknown consequences: applicant(s) from the first round might consider future applicants in their behaviour and decisions. -- Surely, all delegated TLDs or those in process, are off limits. -- I think applicant freedom of expression means you can apply for any string you want, but I don't think that extends to TLDs already in existence or those that are in process in some way. -- Delegated TLDs are not under discussion. -- The point here are those that are not “in process”, so we need to define “in process”. -- Old applications that were denied for a policy reason should have to step up to new policy recommendations if they are going to prevail/ proceed and they should be encouraged to do so by knowing there may be applicants standing in line who are willing to do so. (No stonewalling on new policy recommendations - no blocking based on old policy positions.) -- We already have many categories of Application Status (Active, Applicant Support, Delegated, etc.) -- Question: What about the status “Not Approved”? Answer: That only applies when an application has gone through all of the steps. There will be one or two edge cases. -- Let’s say that we are talking about the names collisions issues and strings that were not delegated -- if new policy is developed by NCAP and may come out of the Board. If there isn’t a new policy they shouldn’t be able to block new applicants. -- An applicant from a prior round who does not want to meet new policy recommendations can block a string forever by not withdrawing a Not Approved application. ACTION ITEM: Change Implementation Guidance to: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Recommendation xx (see rationale 2): Application procedures must take place at predictable, regularly occurring intervals without indeterminable periods of review unless the GNSO Council recommends pausing the program and such recommendation is approved by the Board. Unless and until other procedures are recommended by the GNSO Council and approved by the ICANN Board, ICANN must only use “rounds” as part of the New gTLD Program. Recommendation xx (see rationale 2): Absent extraordinary circumstances, future reviews and/or policy development processes, including the next CCT Review, should take place concurrently with subsequent application rounds. In other words, future reviews and/or policy development processes must not stop or delay subsequent new gTLD rounds. Recommendation xx (See rationale 2). If the outputs of any reviews and/or policy development processes has, or could reasonably have, a material impact on the manner in which application procedures are conducted, such changes must only apply to the opening of the application procedure subsequent to the adoption of the relevant recommendations by the ICANN Board. Discussion: -- Look at these recommendations together. -- If we are clear that applications need to follow all of the timelines before becoming “Not Approved” then they cannot block in future rounds. -- If you have a new policy in the next round that eliminated the problem that blocked a previous string then it should be able to be applied for in the next round. -- Let’s say that .home can move forward but only as a closed generic or .brand where there is a one registrant TLD. What if one of the applicants for .home has no interest in that? Their application needs to be dead. -- Those (.home, .corp, .mail) are not withdrawn even though "not approved". If the Board adopts new name collision policy, old applicants should be willing to step up to the new name collision policy and not be able to refuse to do so and block the string forever by not withdrawing the application. -- Rules should apply in each round to those applicants. -- If you can’t live with the language please suggest new language. -- Problem seems to be how to fix the “Not Approved” applications from the previous round. Board may have to decide how to deal with them. That is out of scope for this WG. ________________________________ 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://urldefense.com/v3/__https:/comlaude.com__;!!N14HnBHF!s4tj4qIGGIEtRUS...> ________________________________ 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://urldefense.com/v3/__https:/comlaude.com__;!!N14HnBHF!s4tj4qIGGIEtRUS...> ________________________________ 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. _______________________________________________ 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<https://urldefense.com/v3/__https:/mm.icann.org/mailman/listinfo/gnso-newgtld-wg__;!!N14HnBHF!s4tj4qIGGIEtRUSiY5ZWvIw3ZZR0JYvJefEekRkbL4V03SkujCraUkAOfPgslTa0psJZ$> _______________________________________________ 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<https://urldefense.com/v3/__https:/www.icann.org/privacy/policy__;!!N14HnBHF!s4tj4qIGGIEtRUSiY5ZWvIw3ZZR0JYvJefEekRkbL4V03SkujCraUkAOfPgslRawcG16$>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://urldefense.com/v3/__https:/www.icann.org/privacy/tos__;!!N14HnBHF!s4tj4qIGGIEtRUSiY5ZWvIw3ZZR0JYvJefEekRkbL4V03SkujCraUkAOfPgslUaU6myt$>). 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. _______________________________________________ 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.
Following this interesting discussion and the detailed listing by Jeff, which clarified matters for me, I must say that I agree with the statements by Donna and Martin. It makes sense to keep it simple, and I agree that the text proposed by Jeff could be lifted and used as implementation guidance, supporting the policy that no applications can be accepted for previously applied strings that are delegated or in process. After all, we are talking about very few strings. Best regards Annebeth
9. feb. 2020 kl. 08:56 skrev Martin Sutton <martin@brandregistrygroup.org>:
Thanks for raising this Donna, there is a big difference between a few people being heard vs the group agreeing to adopt what they say.
Jeff, thanks for the detailed listing of outcomes which makes it suitably clear and puts the issue into perspective (as was also attempted on the call by others). Keeping it simple, your text could be lifted and used as implementation guidance, supporting the policy that no applications can be accepted for previously applied strings that are delegated or in process.
Kind regards,
Martin
Sent from my iPhone
On 9 Feb 2020, at 00:56, Austin, Donna via Gnso-newgtld-wg <gnso-newgtld-wg@icann.org> wrote:
Regardless of whether this is a policy or implementation issue, I just want to note that there were 20+ people on the call and I’d like to understand how we’re taking into account the views of others that had expressed a different opinion to Greg, Anne, Justine and Kathy who came in very very late in the call about the substance of the issue.
Donna
From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Greg Shatan Sent: Friday, February 07, 2020 12:55 PM To: Alexander Schubert <alexander@schubert.berlin> Cc: gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC
Jeff,
I said on the call that this issue is policy. The call transcript is not available yet, but this is in the chat transcript, responding to me:
01:26:52 Justine Chew: +1 Greg on this being a policy issue not IG
01:27:56 Anne Aikman-Scalese: +1 to Greg and Justine - this is a policy issue and it will likely apply in the future to strings we are not even considering at this point.
The discussion went on from there, both in the chat transcript (attached) and on the call. The
chat transcript mentions "policy" 21 times.
There's no definitive test for "policy vs. implementation." All attempts to create one have failed AFAIK. However, one informal "barometer" I use on "policy vs. implementation" is what I call the "WTF Test." If you look at a policy, and the intention is clear and there would be little disagreement about what the implementation would look like (regardless of your "position"), you're good. Anything more detailed tends to be implementation.
But, if you look at a policy and say "WTF" (e.g., "WTF were they thinking?", "WTF did they mean by that?", "WTF are we supposed to do with this?") then there's still policy work to be done.
In this case, there's still policy work to be done. The range of outcomes discussed were broad and contradictory and the dividing lines that produced one result over another were unclear. There's no clear existing policy or policy recommendation to guide the group, or the implementation team.
We need to come out of this with a clear rule about what to do with new applications for strings where there are prior round applications for the same string (or possibly, an overly "similar" string) with these two statuses:
· Not Approved – The application is not approved and shall not continue in the New gTLD Program as a result of a resolution passed by the ICANN Board of Directors or a Committee of the ICANN Board, such as the New gTLD Program Committee. · Will Not Proceed – The application has completed a Program process, and based on the outcome will not continue, as defined in the AGB. This could include process outcomes including but not limited to not passing evaluation, not prevailing a dispute resolution proceeding, not prevailing in contention resolution. Alexander's suggestion makes sense, though I would extend it to both categories above. Perhaps terminated applicants could get a discount if they reapply for the same string.
Best regards,
Greg
On Fri, Feb 7, 2020 at 2:57 PM Alexander Schubert <alexander@schubert.berlin> wrote: Suggestion:
· 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”).
Thanks,
Alexander.berlin
From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Aikman-Scalese, Anne Sent: Freitag, 7. Februar 2020 14:00 To: Jeff Neuman <jeff.neuman@comlaude.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 - 06 February 2000 UTC
Thanks Jeff. I think the degree of discussion on the call confirms that the issue is not about “every little detail”. It’s a “high level” policy issue.
PROBLEM WE NEED TO SOLVE: As I see it, the biggest problem with the first option is that a prior applicant could effectively block new applicants for a string forever by refusing to withdraw an application that is “Not Approved” for policy reasons and by refusing to adopt the new policy. This is not limited to applications from 2012, it’s about policy going forward and relates to applications we have not yet seen. The issues involved could extend well beyond name collisions in to areas no one has yet anticipated.
PROPOSED COMPROMISE LANGUAGE: Pursuant to your request, I have entered language with a proposed compromise that would accept the first Option but with the caveat that the applicant(s) from the prior round would confirm in writing to the Global Domains Division that they are willing to comply with new policy and the new AGB and that they do so prior to the opening of the window for the next round. If they are unwilling to do so, then new applicants should be permitted to apply for the string in a “back-up offer” position.
Anne
From: Jeff Neuman <jeff.neuman@comlaude.com> Sent: Friday, February 7, 2020 11:49 AM To: 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 - 06 February 2000 UTC
[EXTERNAL] Ok, I tried to clarify because I think I may have said something that inadvertently triggered the policy vs. implementation discussion. What I said was something to the effect of “We could say that the policy is that we will not accept any applications for a string that was applied for in the past round so long as that application was still being processed.” And then I followed that up with something like “and we can leave it to the Implementation team to define what it means to still “be in process”.
I must not have communicated that as well as I should have because that is when people started saying that this issue was policy as opposed to implementation (Which was not the point of what I was trying to make).
SO, bottom line, no one said on the call, nor am I aware of anyone that believes, that this issue in general is “policy.” However, if we cannot agree on every little detail, then we can leave some of those details to the Implementation Review Team.
I hope that helps.
Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman@comlaude.com
From: Aikman-Scalese, Anne <AAikman@lrrc.com> Sent: Friday, February 7, 2020 1:32 PM To: Jeff Neuman <jeff.neuman@comlaude.com>; Julie Hedlund <julie.hedlund@icann.org>; gnso-newgtld-wg@icann.org Subject: RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC
I am just noting that at least three active participants said the whatever we ultimately conclude on this point is policy. I think Greg raised this, with Justine saying +1 and I agreed it’s Policy and then Kathy K. chimed in.
In our report, we have the categories you describe. I know Karen said that Implementation Guidance carries strong weight, but it seemed that the point being made was that the issue was a Policy issue rather than Implementation issue. The distinction likely becomes important for the IRT.
Thank you for asking. Anne
From: Jeff Neuman <jeff.neuman@comlaude.com> Sent: Friday, February 7, 2020 9:47 AM To: 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 - 06 February 2000 UTC
[EXTERNAL] Just to clarify Anne, are you saying that the proposal to ban new applications for string not yet withdrawn should be labeled as a “recommendation” and opposed to “Implementation Guidance?”
If it something different, than please explain.
Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman@comlaude.com
From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Aikman-Scalese, Anne Sent: Thursday, February 6, 2020 5:42 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 - 06 February 2000 UTC
Thanks Julie – Were you able to capture in the notes the views put forward to the effect that a proposal to ban new applications for strings not yet withdrawn is in fact “Policy” and not “Implementation Guidance”? Anne
From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Julie Hedlund Sent: Thursday, February 6, 2020 3:02 PM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC
[EXTERNAL] Dear Working Group members,
Please see below the notes from the meeting on 06 February 2000 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-06+New+gTLD+Subsequent+Pro....
Kind regards, Julie
Notes and Action Items:
Actions:
Work Plan: ACTION ITEM: Staff will send a link to the revised work plan/timeline.
2.2.1 Continuing Subsequent Procedures ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote.
ACTION ITEM: Change text as follows: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.”
Notes:
1. Updates to Statements of Interest:
-- Avri Doria will be participating as one of the Board Liaisons to the WG. The other Board Liaison is Becky Burr. -- Question: What does that mean in terms of the role of the Board Liaison? Answer: Largely a constrained role; carrying things back and forth between the Board caucus that will be following it -- bringing questions and possibly answers. -- The goal is not for us to be participants in the PDP, but we want to avoid surprises, such as something that the Board wouldn’t be able to do.
2. Work Plan
-- GNSO Council is trying to ensure realistic deadlines for the PDP WGs and to manage the policy development work. -- One of the PDP 3.0 recommendations that has been implemented is the need for Project Change Requests when the dates of deliverables cannot be met. As you may know the RPMs PDP WG submitted a Project Change Request for the GNSO Council meeting in January and is revising that request. -- The SubPro PDP WG Co-Chairs have been asked to submit a modified work plan along with the Project Change Request for the Council to consider at its meeting on 20 February. -- This is a worst case scenario to avoid having to do another request, but we expect to be able to shave some time off of this. -- New work plan shows the schedule of meetings to cover all of the topics. -- Unless the WG can work faster it would be delivering a Final Report by the end of 2020. -- This is just a preview; a link will be sent later. -- This is assuming a two meetings per week schedule. -- Some of these topics may not take two full meetings, but we’ve built that in as a buffer. -- Some things we could do to streamline this. One that we’ll suggest to the WG and GNSO Council is to have a couple of extended sessions in April and May -- in lieu of face-to-face meetings. Such as two 3-hour sessions in April and May we could save a month or more. -- New working method: Take after EPDP and ask the WG members to consider what they can live with, with an emphasis on suggesting solutions. -- Goal is to get the revised work plan and Project Change Request to the Council by early next week. -- Agree that we would need to schedule longer sessions well in advance, say two months. ACTION ITEM: Staff will send a link to the revised work plan/timeline.
3. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52....
Structure: -- Affirmations are confirming the 2012 policy/AGB. -- Recommendations are things that must happen. -- Implementation Guidance are things that should happen.
a. 2.2.1 Continuing Subsequent Procedures
Affirmation xx (see rationale 1): The Working Group recommends that the existing policy contained in the 2012 Applicant Guidebook, that a “systematized manner of applying for gTLDs be developed in the long term,” be maintained.
Affirmation xx (see rationale 2): The Working Group affirms Principle A and recommends that the New gTLD Program must continue to be administered “in an ongoing, orderly, timely and predictable manner.”
Affirmation xx (see rationale 3): The Working Group affirms that the primary purposes of new gTLDs are to foster diversity, encourage competition, and enhance the utility of the DNS.
Recommendation xx (see rationale 3). Accordingly, the Working Group recommends that meaningful metrics must be identified to understand the impact of the New gTLD Program. The metrics, broadly speaking, should focus on the areas of trust, competition, and choice. To review metrics, data must be collected at a logical time to create a basis against which future data can be compared.
Discussion: -- On the recommendation: Should we cite section 5 of the CCT-RT Final Report for the types of data? There is still some uncertainty as to what will be adopted from that Final Report, so it would be preferable that this could be part of Implementation Guidance. Not trying to override ICANN Org’s plans. -- Re: metrics -- never seen any commitment from ICANN Org to collect and publish the metrics as recommended by the CCT Final Report. Don’t see how these can be collected. -- There was discussion in the SubPro Initial Report and in the CCT-RT Final Report; ICANN is aware of the discussions and has a schedule concerning the recommendations. -- Question from ICANN Org re: the recommendation: Is this some other framework that gets set up to measure the trust, competition, and choice goals over time. Answer: Some of it would be part of the implementation; we wanted a general recommendation about collecting data, but didn’t want to get into a debate on the details. We wanted to leave it to implementation as to what types of data would be collected and how. -- Question: Was this particular recommendation adopted by the Board or no? Should we refer to data gathering in accordance with whatever Board adopts in relation to the CCT recommendation? Answer: We will add this as Implementation Guidance. ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote.
b. 2.2.3 Applications Assessed in Rounds
Affirmation xx (with modification) (see rationale 1): The Working Group affirms recommendation 13 from the 2007 policy, which states: “Applications must initially be assessed in rounds until the scale of demand is clear.” However, the Working Group believes that the words “initially” and “until the scale of demand is clear” be removed from the sentence and should just read “Applications must be assessed in rounds.”
Recommendation xx (see rationale 2): Upon the commencement of the next Application Submission Period, there must be clarity around the timing and/or criteria for initiating subsequent procedures from that point forth. More specifically, prior to the commencement of the next Application Submission Period, ICANN shall publish either (a) the date in which the next subsequent introduction of new gTLDs will take place or (b) the specific set of criteria and/or events that must occur prior to the opening up of the next subsequent process.
Implementation Guidance xx (see rationale 2): A new round may initiate even if steps related to application processing and delegation from previous application windows have not been completed.
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 opportunity. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application opportunity, unless and/or until the applications from the previous round that match those strings have had their final disposition.
Discussion: -- Comment: May be worth seeing if the WG can narrow in on a preference here. Or perhaps this makes sense as an unless in a sense, so the date is the preference, unless there is non-exhaustive list of things that would prevent the timely launch? Question: Preference for ICANN Org to set a date, or instead to say what has to happen before a next round? -- In Implementation Guidance we suggested two options since comments were widely varied. -- The first option adds to predictability for applicants. Else applicants may be in limbo for an unknown period of time. -- The second option gets pretty complicated when you are trying to determine contention sets. Not sure how you would do it. -- This is not meant to allow someone to get into an already existing contention set. In both of these cases nothing is going to be processed in a subsequent round until every contention set is resolved and done from the previous round. -- Recommendation: preference is that ICANN publish a date. >> -- Implementation Guidance: preference is that it should not be possible to apply for a string that is still being processed from a previous application opportunity. -- Disagree that strings from last round should be prohibited. Second option supports the notion of Applicant freedom of expression. -- From a process perspective the above comment would add complications that really aren't warranted. -- No evaluation of the new applicant would occur until the 2012 applications are resolved. The new applicants would have to accept that risk. -- Concerns about treating moribund applications made a decade ago as reservations for the next round. Are the strings that are withdrawn due to name collisions undergoing a process, or are they just on hold? -- What is the harm in keeping a particular string closed for new apps until all the previous applicants have fallen by the wayside. Then it opens up again for all. -- Because the window for application is closed at that point and we haven't said that a new window could open if they all fail. -- If there is agreement that rounds are the path forward, then if a string does not go through in one round it will become available in another round. -- That's one of our recommendations that there will be a series of windows. -- Is there any WG member that would die in a ditch over this option: “It should not be possible to apply for a string in a subsequent round that is still being processed from a previous application round.”? -- Favor the second option. -- Can't live with prohibiting applications for the same string. If "shall not proceed" means new applicants can still apply, I can live with that. -- What about applications that have not progressed on purpose? Or for technical reasons? -- From a pragmatic perspective if we allow for applicants to submit applications for a string that is already in process that adds layers of complexity to the process. If a string hasn’t gone forward to delegation and it becomes available again then it can be applied for. -- We don’t have a system in place that allows for continuing application periods, we have rounds. People should be waiting their turn but they can get in line -- violates applicants’ freedom of expression if they can’t apply. -- The point of the first recommendation is that ICANN Org will set a date certain or criteria that must occur. We are trying to get to a steady state process. -- If someone could apply for a string that is still in process, what we may be encouraging is applicants who might not be fully processed to apply in the next round if they think they are going to fail in the previous round. Need to define in implementation what “in process” means. -- If it would be possible to file applications for the same string in future rounds the door is open for gaming and unknown consequences: applicant(s) from the first round might consider future applicants in their behaviour and decisions. -- Surely, all delegated TLDs or those in process, are off limits. -- I think applicant freedom of expression means you can apply for any string you want, but I don't think that extends to TLDs already in existence or those that are in process in some way. -- Delegated TLDs are not under discussion. -- The point here are those that are not “in process”, so we need to define “in process”. -- Old applications that were denied for a policy reason should have to step up to new policy recommendations if they are going to prevail/ proceed and they should be encouraged to do so by knowing there may be applicants standing in line who are willing to do so. (No stonewalling on new policy recommendations - no blocking based on old policy positions.) >> -- We already have many categories of Application Status (Active, Applicant Support, Delegated, etc.) -- Question: What about the status “Not Approved”? Answer: That only applies when an application has gone through all of the steps. There will be one or two edge cases. -- Let’s say that we are talking about the names collisions issues and strings that were not delegated -- if new policy is developed by NCAP and may come out of the Board. If there isn’t a new policy they shouldn’t be able to block new applicants. -- An applicant from a prior round who does not want to meet new policy recommendations can block a string forever by not withdrawing a Not Approved application. ACTION ITEM: Change Implementation Guidance to: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.”
Recommendation xx (see rationale 2): Application procedures must take place at predictable, regularly occurring intervals without indeterminable periods of review unless the GNSO Council recommends pausing the program and such recommendation is approved by the Board. Unless and until other procedures are recommended by the GNSO Council and approved by the ICANN Board, ICANN must only use “rounds” as part of the New gTLD Program.
Recommendation xx (see rationale 2): Absent extraordinary circumstances, future reviews and/or policy development processes, including the next CCT Review, should take place concurrently with subsequent application rounds. In other words, future reviews and/or policy development processes must not stop or delay subsequent new gTLD rounds.
Recommendation xx (See rationale 2). If the outputs of any reviews and/or policy development processes has, or could reasonably have, a material impact on the manner in which application procedures are conducted, such changes must only apply to the opening of the application procedure subsequent to the adoption of the relevant recommendations by the ICANN Board.
Discussion: -- Look at these recommendations together. -- If we are clear that applications need to follow all of the timelines before becoming “Not Approved” then they cannot block in future rounds. -- If you have a new policy in the next round that eliminated the problem that blocked a previous string then it should be able to be applied for in the next round. -- Let’s say that .home can move forward but only as a closed generic or .brand where there is a one registrant TLD. What if one of the applicants for .home has no interest in that? Their application needs to be dead. -- Those (.home, .corp, .mail) are not withdrawn even though "not approved". If the Board adopts new name collision policy, old applicants should be willing to step up to the new name collision policy and not be able to refuse to do so and block the string forever by not withdrawing the application. -- Rules should apply in each round to those applicants. -- If you can’t live with the language please suggest new language. -- Problem seems to be how to fix the “Not Approved” applications from the previous round. Board may have to decide how to deal with them. That is out of scope for this WG.
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
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
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. _______________________________________________ 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. _______________________________________________ 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.
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.
Anne, Thanks for this language, but I am still a little confused. There is an assumption in your problem that Applicants will be able to “block new applicants for a string forever by refusing to withdraw an application that is “Not Approved”…. But I am saying that we should not make that assumption. I am saying that by narrowing down what it means to have an application “in process”, we can prevent that assumption. So, lets play out the different scenarios. 1. If a TLD has already been delegated, no application for that string will be allowed for a string in a subsequent round. 2. If there is an application is “Active”, “Applicant Support”, “In Contracting”, “On-hold” or “In PDT”, an application will not be allowed for that string in a subsequent round. 3. If all applications for a particular string have been Withdrawn, new applications for the string will be allowed in a subsequent round. 4. If a Registry Operator has terminated its Registry Agreement and (i) the TLD has not been reassigned to a different Registry Operator, and (ii) in the case of a Specification 13 Brand TLD, it is more than 2 years following the Expiration Date (See RA Section 4.5(a)), then applications will be allowed to be submitted during a subsequent round. 5. If all applications for a given string have a status of “will not proceed”, an application for the TLD will only be allowed if: * All appeals and/or accountability mechanisms have proceeded through final disposition and no applications for the string have succeeded in such appeals and/or accountability mechanisms; or * All applicable time limitations (statute of limitations) have expired such that all applicants for a particular string would not be in a position to file an appeal or accountability mechanism with respect to the string; and 1. If a TLD has a status of “Not Approved”, an application for the TLD will only be allowed if: * All appeals and/or accountability mechanisms have proceeded through final disposition and no applications for the string have succeeded in such appeals and/or accountability mechanisms; or * All applicable time limitations (statute of limitations) have expired such that all applicants for a particular string would not be in a position to file an appeal or accountability mechanism with respect to the string; and * The ICANN Board has not approved new policies or procedures that would allow one or more of the applicants from the prior round to cure the reasons for which it was placed in the “Not Approved” category, but has approved new policies or procedures that would allow an applicant to apply for the string in any subsequent round. **For purposes of 6(c) above, in the event that there are new policies or procedures put into place which would allow the application of strings which were “not approved” in a prior round, the ICANN Board must make a determination as to whether the applicants in the prior round have any preferential rights for those strings at the time such policies or procedures are put into place. Please note that there are currently only 7 strings (10 applications) from the previous round that are in the “not approved category” where applicants have not withdrawn their strings: 1. .islam 2. .home 3. .mail (3 applications) 4. .corp (2 applications) 5. .halal 6. .persiangulf 7. .gcc I believe that .corp, .home and .mail are being discussed by NCAP (after a resolution of the Board to not proceed); the others are still in various stages of accountability mechanisms (I believe). Therefore, under the above rules (IF OUR RULES APPLIED RETROACTIVELY – WHICH THEY WOULD NOT BECAUSE WE DON’T HAVE THAT JURISDICTION), no applications would be accepted in a subsequent round for these strings. To put this into perspective, this the “not approved” status only occurred for .581% of the application. Lets try to keep this simple. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> From: Aikman-Scalese, Anne <AAikman@lrrc.com> Sent: Friday, February 7, 2020 2:00 PM To: Jeff Neuman <jeff.neuman@comlaude.com>; Julie Hedlund <julie.hedlund@icann.org>; gnso-newgtld-wg@icann.org Subject: RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC Thanks Jeff. I think the degree of discussion on the call confirms that the issue is not about “every little detail”. It’s a “high level” policy issue. PROBLEM WE NEED TO SOLVE: As I see it, the biggest problem with the first option is that a prior applicant could effectively block new applicants for a string forever by refusing to withdraw an application that is “Not Approved” for policy reasons and by refusing to adopt the new policy. This is not limited to applications from 2012, it’s about policy going forward and relates to applications we have not yet seen. The issues involved could extend well beyond name collisions in to areas no one has yet anticipated. PROPOSED COMPROMISE LANGUAGE: Pursuant to your request, I have entered language with a proposed compromise that would accept the first Option but with the caveat that the applicant(s) from the prior round would confirm in writing to the Global Domains Division that they are willing to comply with new policy and the new AGB and that they do so prior to the opening of the window for the next round. If they are unwilling to do so, then new applicants should be permitted to apply for the string in a “back-up offer” position. Anne From: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com>> Sent: Friday, February 7, 2020 11:49 AM To: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Ok, I tried to clarify because I think I may have said something that inadvertently triggered the policy vs. implementation discussion. What I said was something to the effect of “We could say that the policy is that we will not accept any applications for a string that was applied for in the past round so long as that application was still being processed.” And then I followed that up with something like “and we can leave it to the Implementation team to define what it means to still “be in process”. I must not have communicated that as well as I should have because that is when people started saying that this issue was policy as opposed to implementation (Which was not the point of what I was trying to make). SO, bottom line, no one said on the call, nor am I aware of anyone that believes, that this issue in general is “policy.” However, if we cannot agree on every little detail, then we can leave some of those details to the Implementation Review Team. I hope that helps. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> From: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> Sent: Friday, February 7, 2020 1:32 PM To: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.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 - 06 February 2000 UTC I am just noting that at least three active participants said the whatever we ultimately conclude on this point is policy. I think Greg raised this, with Justine saying +1 and I agreed it’s Policy and then Kathy K. chimed in. In our report, we have the categories you describe. I know Karen said that Implementation Guidance carries strong weight, but it seemed that the point being made was that the issue was a Policy issue rather than Implementation issue. The distinction likely becomes important for the IRT. Thank you for asking. Anne From: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com>> Sent: Friday, February 7, 2020 9:47 AM To: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Just to clarify Anne, are you saying that the proposal to ban new applications for string not yet withdrawn should be labeled as a “recommendation” and opposed to “Implementation Guidance?” If it something different, than please explain. 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: Thursday, February 6, 2020 5:42 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 - 06 February 2000 UTC Thanks Julie – Were you able to capture in the notes the views put forward to the effect that a proposal to ban new applications for strings not yet withdrawn is in fact “Policy” and not “Implementation Guidance”? Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Julie Hedlund Sent: Thursday, February 6, 2020 3:02 PM 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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting on 06 February 2000 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-06+New+gTLD+Subsequent+Pro.... Kind regards, Julie Notes and Action Items: Actions: Work Plan: ACTION ITEM: Staff will send a link to the revised work plan/timeline. 2.2.1 Continuing Subsequent Procedures ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. ACTION ITEM: Change text as follows: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Notes: 1. Updates to Statements of Interest: -- Avri Doria will be participating as one of the Board Liaisons to the WG. The other Board Liaison is Becky Burr. -- Question: What does that mean in terms of the role of the Board Liaison? Answer: Largely a constrained role; carrying things back and forth between the Board caucus that will be following it -- bringing questions and possibly answers. -- The goal is not for us to be participants in the PDP, but we want to avoid surprises, such as something that the Board wouldn’t be able to do. 2. Work Plan -- GNSO Council is trying to ensure realistic deadlines for the PDP WGs and to manage the policy development work. -- One of the PDP 3.0 recommendations that has been implemented is the need for Project Change Requests when the dates of deliverables cannot be met. As you may know the RPMs PDP WG submitted a Project Change Request for the GNSO Council meeting in January and is revising that request. -- The SubPro PDP WG Co-Chairs have been asked to submit a modified work plan along with the Project Change Request for the Council to consider at its meeting on 20 February. -- This is a worst case scenario to avoid having to do another request, but we expect to be able to shave some time off of this. -- New work plan shows the schedule of meetings to cover all of the topics. -- Unless the WG can work faster it would be delivering a Final Report by the end of 2020. -- This is just a preview; a link will be sent later. -- This is assuming a two meetings per week schedule. -- Some of these topics may not take two full meetings, but we’ve built that in as a buffer. -- Some things we could do to streamline this. One that we’ll suggest to the WG and GNSO Council is to have a couple of extended sessions in April and May -- in lieu of face-to-face meetings. Such as two 3-hour sessions in April and May we could save a month or more. -- New working method: Take after EPDP and ask the WG members to consider what they can live with, with an emphasis on suggesting solutions. -- Goal is to get the revised work plan and Project Change Request to the Council by early next week. -- Agree that we would need to schedule longer sessions well in advance, say two months. ACTION ITEM: Staff will send a link to the revised work plan/timeline. 3. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52.... Structure: -- Affirmations are confirming the 2012 policy/AGB. -- Recommendations are things that must happen. -- Implementation Guidance are things that should happen. a. 2.2.1 Continuing Subsequent Procedures Affirmation xx (see rationale 1): The Working Group recommends that the existing policy contained in the 2012 Applicant Guidebook, that a “systematized manner of applying for gTLDs be developed in the long term,” be maintained. Affirmation xx (see rationale 2): The Working Group affirms Principle A and recommends that the New gTLD Program must continue to be administered “in an ongoing, orderly, timely and predictable manner.” Affirmation xx (see rationale 3): The Working Group affirms that the primary purposes of new gTLDs are to foster diversity, encourage competition, and enhance the utility of the DNS. Recommendation xx (see rationale 3). Accordingly, the Working Group recommends that meaningful metrics must be identified to understand the impact of the New gTLD Program. The metrics, broadly speaking, should focus on the areas of trust, competition, and choice. To review metrics, data must be collected at a logical time to create a basis against which future data can be compared. Discussion: -- On the recommendation: Should we cite section 5 of the CCT-RT Final Report for the types of data? There is still some uncertainty as to what will be adopted from that Final Report, so it would be preferable that this could be part of Implementation Guidance. Not trying to override ICANN Org’s plans. -- Re: metrics -- never seen any commitment from ICANN Org to collect and publish the metrics as recommended by the CCT Final Report. Don’t see how these can be collected. -- There was discussion in the SubPro Initial Report and in the CCT-RT Final Report; ICANN is aware of the discussions and has a schedule concerning the recommendations. -- Question from ICANN Org re: the recommendation: Is this some other framework that gets set up to measure the trust, competition, and choice goals over time. Answer: Some of it would be part of the implementation; we wanted a general recommendation about collecting data, but didn’t want to get into a debate on the details. We wanted to leave it to implementation as to what types of data would be collected and how. -- Question: Was this particular recommendation adopted by the Board or no? Should we refer to data gathering in accordance with whatever Board adopts in relation to the CCT recommendation? Answer: We will add this as Implementation Guidance. ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. b. 2.2.3 Applications Assessed in Rounds Affirmation xx (with modification) (see rationale 1): The Working Group affirms recommendation 13 from the 2007 policy, which states: “Applications must initially be assessed in rounds until the scale of demand is clear.” However, the Working Group believes that the words “initially” and “until the scale of demand is clear” be removed from the sentence and should just read “Applications must be assessed in rounds.” Recommendation xx (see rationale 2): Upon the commencement of the next Application Submission Period, there must be clarity around the timing and/or criteria for initiating subsequent procedures from that point forth. More specifically, prior to the commencement of the next Application Submission Period, ICANN shall publish either (a) the date in which the next subsequent introduction of new gTLDs will take place or (b) the specific set of criteria and/or events that must occur prior to the opening up of the next subsequent process. Implementation Guidance xx (see rationale 2): A new round may initiate even if steps related to application processing and delegation from previous application windows have not been completed. 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 opportunity. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application opportunity, unless and/or until the applications from the previous round that match those strings have had their final disposition. Discussion: -- Comment: May be worth seeing if the WG can narrow in on a preference here. Or perhaps this makes sense as an unless in a sense, so the date is the preference, unless there is non-exhaustive list of things that would prevent the timely launch? Question: Preference for ICANN Org to set a date, or instead to say what has to happen before a next round? -- In Implementation Guidance we suggested two options since comments were widely varied. -- The first option adds to predictability for applicants. Else applicants may be in limbo for an unknown period of time. -- The second option gets pretty complicated when you are trying to determine contention sets. Not sure how you would do it. -- This is not meant to allow someone to get into an already existing contention set. In both of these cases nothing is going to be processed in a subsequent round until every contention set is resolved and done from the previous round. -- Recommendation: preference is that ICANN publish a date. -- Implementation Guidance: preference is that it should not be possible to apply for a string that is still being processed from a previous application opportunity. -- Disagree that strings from last round should be prohibited. Second option supports the notion of Applicant freedom of expression. -- From a process perspective the above comment would add complications that really aren't warranted. -- No evaluation of the new applicant would occur until the 2012 applications are resolved. The new applicants would have to accept that risk. -- Concerns about treating moribund applications made a decade ago as reservations for the next round. Are the strings that are withdrawn due to name collisions undergoing a process, or are they just on hold? -- What is the harm in keeping a particular string closed for new apps until all the previous applicants have fallen by the wayside. Then it opens up again for all. -- Because the window for application is closed at that point and we haven't said that a new window could open if they all fail. -- If there is agreement that rounds are the path forward, then if a string does not go through in one round it will become available in another round. -- That's one of our recommendations that there will be a series of windows. -- Is there any WG member that would die in a ditch over this option: “It should not be possible to apply for a string in a subsequent round that is still being processed from a previous application round.”? -- Favor the second option. -- Can't live with prohibiting applications for the same string. If "shall not proceed" means new applicants can still apply, I can live with that. -- What about applications that have not progressed on purpose? Or for technical reasons? -- From a pragmatic perspective if we allow for applicants to submit applications for a string that is already in process that adds layers of complexity to the process. If a string hasn’t gone forward to delegation and it becomes available again then it can be applied for. -- We don’t have a system in place that allows for continuing application periods, we have rounds. People should be waiting their turn but they can get in line -- violates applicants’ freedom of expression if they can’t apply. -- The point of the first recommendation is that ICANN Org will set a date certain or criteria that must occur. We are trying to get to a steady state process. -- If someone could apply for a string that is still in process, what we may be encouraging is applicants who might not be fully processed to apply in the next round if they think they are going to fail in the previous round. Need to define in implementation what “in process” means. -- If it would be possible to file applications for the same string in future rounds the door is open for gaming and unknown consequences: applicant(s) from the first round might consider future applicants in their behaviour and decisions. -- Surely, all delegated TLDs or those in process, are off limits. -- I think applicant freedom of expression means you can apply for any string you want, but I don't think that extends to TLDs already in existence or those that are in process in some way. -- Delegated TLDs are not under discussion. -- The point here are those that are not “in process”, so we need to define “in process”. -- Old applications that were denied for a policy reason should have to step up to new policy recommendations if they are going to prevail/ proceed and they should be encouraged to do so by knowing there may be applicants standing in line who are willing to do so. (No stonewalling on new policy recommendations - no blocking based on old policy positions.) -- We already have many categories of Application Status (Active, Applicant Support, Delegated, etc.) -- Question: What about the status “Not Approved”? Answer: That only applies when an application has gone through all of the steps. There will be one or two edge cases. -- Let’s say that we are talking about the names collisions issues and strings that were not delegated -- if new policy is developed by NCAP and may come out of the Board. If there isn’t a new policy they shouldn’t be able to block new applicants. -- An applicant from a prior round who does not want to meet new policy recommendations can block a string forever by not withdrawing a Not Approved application. ACTION ITEM: Change Implementation Guidance to: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Recommendation xx (see rationale 2): Application procedures must take place at predictable, regularly occurring intervals without indeterminable periods of review unless the GNSO Council recommends pausing the program and such recommendation is approved by the Board. Unless and until other procedures are recommended by the GNSO Council and approved by the ICANN Board, ICANN must only use “rounds” as part of the New gTLD Program. Recommendation xx (see rationale 2): Absent extraordinary circumstances, future reviews and/or policy development processes, including the next CCT Review, should take place concurrently with subsequent application rounds. In other words, future reviews and/or policy development processes must not stop or delay subsequent new gTLD rounds. Recommendation xx (See rationale 2). If the outputs of any reviews and/or policy development processes has, or could reasonably have, a material impact on the manner in which application procedures are conducted, such changes must only apply to the opening of the application procedure subsequent to the adoption of the relevant recommendations by the ICANN Board. Discussion: -- Look at these recommendations together. -- If we are clear that applications need to follow all of the timelines before becoming “Not Approved” then they cannot block in future rounds. -- If you have a new policy in the next round that eliminated the problem that blocked a previous string then it should be able to be applied for in the next round. -- Let’s say that .home can move forward but only as a closed generic or .brand where there is a one registrant TLD. What if one of the applicants for .home has no interest in that? Their application needs to be dead. -- Those (.home, .corp, .mail) are not withdrawn even though "not approved". If the Board adopts new name collision policy, old applicants should be willing to step up to the new name collision policy and not be able to refuse to do so and block the string forever by not withdrawing the application. -- Rules should apply in each round to those applicants. -- If you can’t live with the language please suggest new language. -- Problem seems to be how to fix the “Not Approved” applications from the previous round. Board may have to decide how to deal with them. That is out of scope for this WG. ________________________________ 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> ________________________________ 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> ________________________________ 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 Jeff – I think WG members will need to take a closer look at your proposal for further discussion on Monday. The big difference between what I have said and what you are saying in relation to “Not Approved” applications in Item 6. below is that you are stating that new applications for the string are barred if the applicant COULD agree to new policies in order to clear the “Not Approved” status whereas I am saying that an applicant MUST agree to the new policies prior to the opening of the window or else new applications for the same string should be allowed. The fact that a prior applicant for that “Not Approved” string COULD agree to the new policies does not mean that it will agree and for that reason, it should not block back-up offers. Anne From: Jeff Neuman <jeff.neuman@comlaude.com> Sent: Friday, February 7, 2020 2:11 PM To: 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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Anne, Thanks for this language, but I am still a little confused. There is an assumption in your problem that Applicants will be able to “block new applicants for a string forever by refusing to withdraw an application that is “Not Approved”…. But I am saying that we should not make that assumption. I am saying that by narrowing down what it means to have an application “in process”, we can prevent that assumption. So, lets play out the different scenarios. 1. If a TLD has already been delegated, no application for that string will be allowed for a string in a subsequent round. 2. If there is an application is “Active”, “Applicant Support”, “In Contracting”, “On-hold” or “In PDT”, an application will not be allowed for that string in a subsequent round. 3. If all applications for a particular string have been Withdrawn, new applications for the string will be allowed in a subsequent round. 4. If a Registry Operator has terminated its Registry Agreement and (i) the TLD has not been reassigned to a different Registry Operator, and (ii) in the case of a Specification 13 Brand TLD, it is more than 2 years following the Expiration Date (See RA Section 4.5(a)), then applications will be allowed to be submitted during a subsequent round. 5. If all applications for a given string have a status of “will not proceed”, an application for the TLD will only be allowed if: * All appeals and/or accountability mechanisms have proceeded through final disposition and no applications for the string have succeeded in such appeals and/or accountability mechanisms; or * All applicable time limitations (statute of limitations) have expired such that all applicants for a particular string would not be in a position to file an appeal or accountability mechanism with respect to the string; and 1. If a TLD has a status of “Not Approved”, an application for the TLD will only be allowed if: * All appeals and/or accountability mechanisms have proceeded through final disposition and no applications for the string have succeeded in such appeals and/or accountability mechanisms; or * All applicable time limitations (statute of limitations) have expired such that all applicants for a particular string would not be in a position to file an appeal or accountability mechanism with respect to the string; and * The ICANN Board has not approved new policies or procedures that would allow one or more of the applicants from the prior round to cure the reasons for which it was placed in the “Not Approved” category, but has approved new policies or procedures that would allow an applicant to apply for the string in any subsequent round. **For purposes of 6(c) above, in the event that there are new policies or procedures put into place which would allow the application of strings which were “not approved” in a prior round, the ICANN Board must make a determination as to whether the applicants in the prior round have any preferential rights for those strings at the time such policies or procedures are put into place. Please note that there are currently only 7 strings (10 applications) from the previous round that are in the “not approved category” where applicants have not withdrawn their strings: a. .islam b. .home c. .mail (3 applications) d. .corp (2 applications) e. .halal f. .persiangulf g. .gcc I believe that .corp, .home and .mail are being discussed by NCAP (after a resolution of the Board to not proceed); the others are still in various stages of accountability mechanisms (I believe). Therefore, under the above rules (IF OUR RULES APPLIED RETROACTIVELY – WHICH THEY WOULD NOT BECAUSE WE DON’T HAVE THAT JURISDICTION), no applications would be accepted in a subsequent round for these strings. To put this into perspective, this the “not approved” status only occurred for .581% of the application. Lets try to keep this simple. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> From: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> Sent: Friday, February 7, 2020 2:00 PM To: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.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 - 06 February 2000 UTC Thanks Jeff. I think the degree of discussion on the call confirms that the issue is not about “every little detail”. It’s a “high level” policy issue. PROBLEM WE NEED TO SOLVE: As I see it, the biggest problem with the first option is that a prior applicant could effectively block new applicants for a string forever by refusing to withdraw an application that is “Not Approved” for policy reasons and by refusing to adopt the new policy. This is not limited to applications from 2012, it’s about policy going forward and relates to applications we have not yet seen. The issues involved could extend well beyond name collisions in to areas no one has yet anticipated. PROPOSED COMPROMISE LANGUAGE: Pursuant to your request, I have entered language with a proposed compromise that would accept the first Option but with the caveat that the applicant(s) from the prior round would confirm in writing to the Global Domains Division that they are willing to comply with new policy and the new AGB and that they do so prior to the opening of the window for the next round. If they are unwilling to do so, then new applicants should be permitted to apply for the string in a “back-up offer” position. Anne From: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com>> Sent: Friday, February 7, 2020 11:49 AM To: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Ok, I tried to clarify because I think I may have said something that inadvertently triggered the policy vs. implementation discussion. What I said was something to the effect of “We could say that the policy is that we will not accept any applications for a string that was applied for in the past round so long as that application was still being processed.” And then I followed that up with something like “and we can leave it to the Implementation team to define what it means to still “be in process”. I must not have communicated that as well as I should have because that is when people started saying that this issue was policy as opposed to implementation (Which was not the point of what I was trying to make). SO, bottom line, no one said on the call, nor am I aware of anyone that believes, that this issue in general is “policy.” However, if we cannot agree on every little detail, then we can leave some of those details to the Implementation Review Team. I hope that helps. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> From: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> Sent: Friday, February 7, 2020 1:32 PM To: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.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 - 06 February 2000 UTC I am just noting that at least three active participants said the whatever we ultimately conclude on this point is policy. I think Greg raised this, with Justine saying +1 and I agreed it’s Policy and then Kathy K. chimed in. In our report, we have the categories you describe. I know Karen said that Implementation Guidance carries strong weight, but it seemed that the point being made was that the issue was a Policy issue rather than Implementation issue. The distinction likely becomes important for the IRT. Thank you for asking. Anne From: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com>> Sent: Friday, February 7, 2020 9:47 AM To: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Just to clarify Anne, are you saying that the proposal to ban new applications for string not yet withdrawn should be labeled as a “recommendation” and opposed to “Implementation Guidance?” If it something different, than please explain. 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: Thursday, February 6, 2020 5:42 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 - 06 February 2000 UTC Thanks Julie – Were you able to capture in the notes the views put forward to the effect that a proposal to ban new applications for strings not yet withdrawn is in fact “Policy” and not “Implementation Guidance”? Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Julie Hedlund Sent: Thursday, February 6, 2020 3:02 PM 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 - 06 February 2000 UTC [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting on 06 February 2000 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-06+New+gTLD+Subsequent+Pro.... Kind regards, Julie Notes and Action Items: Actions: Work Plan: ACTION ITEM: Staff will send a link to the revised work plan/timeline. 2.2.1 Continuing Subsequent Procedures ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. ACTION ITEM: Change text as follows: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Notes: 1. Updates to Statements of Interest: -- Avri Doria will be participating as one of the Board Liaisons to the WG. The other Board Liaison is Becky Burr. -- Question: What does that mean in terms of the role of the Board Liaison? Answer: Largely a constrained role; carrying things back and forth between the Board caucus that will be following it -- bringing questions and possibly answers. -- The goal is not for us to be participants in the PDP, but we want to avoid surprises, such as something that the Board wouldn’t be able to do. 2. Work Plan -- GNSO Council is trying to ensure realistic deadlines for the PDP WGs and to manage the policy development work. -- One of the PDP 3.0 recommendations that has been implemented is the need for Project Change Requests when the dates of deliverables cannot be met. As you may know the RPMs PDP WG submitted a Project Change Request for the GNSO Council meeting in January and is revising that request. -- The SubPro PDP WG Co-Chairs have been asked to submit a modified work plan along with the Project Change Request for the Council to consider at its meeting on 20 February. -- This is a worst case scenario to avoid having to do another request, but we expect to be able to shave some time off of this. -- New work plan shows the schedule of meetings to cover all of the topics. -- Unless the WG can work faster it would be delivering a Final Report by the end of 2020. -- This is just a preview; a link will be sent later. -- This is assuming a two meetings per week schedule. -- Some of these topics may not take two full meetings, but we’ve built that in as a buffer. -- Some things we could do to streamline this. One that we’ll suggest to the WG and GNSO Council is to have a couple of extended sessions in April and May -- in lieu of face-to-face meetings. Such as two 3-hour sessions in April and May we could save a month or more. -- New working method: Take after EPDP and ask the WG members to consider what they can live with, with an emphasis on suggesting solutions. -- Goal is to get the revised work plan and Project Change Request to the Council by early next week. -- Agree that we would need to schedule longer sessions well in advance, say two months. ACTION ITEM: Staff will send a link to the revised work plan/timeline. 3. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52.... Structure: -- Affirmations are confirming the 2012 policy/AGB. -- Recommendations are things that must happen. -- Implementation Guidance are things that should happen. a. 2.2.1 Continuing Subsequent Procedures Affirmation xx (see rationale 1): The Working Group recommends that the existing policy contained in the 2012 Applicant Guidebook, that a “systematized manner of applying for gTLDs be developed in the long term,” be maintained. Affirmation xx (see rationale 2): The Working Group affirms Principle A and recommends that the New gTLD Program must continue to be administered “in an ongoing, orderly, timely and predictable manner.” Affirmation xx (see rationale 3): The Working Group affirms that the primary purposes of new gTLDs are to foster diversity, encourage competition, and enhance the utility of the DNS. Recommendation xx (see rationale 3). Accordingly, the Working Group recommends that meaningful metrics must be identified to understand the impact of the New gTLD Program. The metrics, broadly speaking, should focus on the areas of trust, competition, and choice. To review metrics, data must be collected at a logical time to create a basis against which future data can be compared. Discussion: -- On the recommendation: Should we cite section 5 of the CCT-RT Final Report for the types of data? There is still some uncertainty as to what will be adopted from that Final Report, so it would be preferable that this could be part of Implementation Guidance. Not trying to override ICANN Org’s plans. -- Re: metrics -- never seen any commitment from ICANN Org to collect and publish the metrics as recommended by the CCT Final Report. Don’t see how these can be collected. -- There was discussion in the SubPro Initial Report and in the CCT-RT Final Report; ICANN is aware of the discussions and has a schedule concerning the recommendations. -- Question from ICANN Org re: the recommendation: Is this some other framework that gets set up to measure the trust, competition, and choice goals over time. Answer: Some of it would be part of the implementation; we wanted a general recommendation about collecting data, but didn’t want to get into a debate on the details. We wanted to leave it to implementation as to what types of data would be collected and how. -- Question: Was this particular recommendation adopted by the Board or no? Should we refer to data gathering in accordance with whatever Board adopts in relation to the CCT recommendation? Answer: We will add this as Implementation Guidance. ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. b. 2.2.3 Applications Assessed in Rounds Affirmation xx (with modification) (see rationale 1): The Working Group affirms recommendation 13 from the 2007 policy, which states: “Applications must initially be assessed in rounds until the scale of demand is clear.” However, the Working Group believes that the words “initially” and “until the scale of demand is clear” be removed from the sentence and should just read “Applications must be assessed in rounds.” Recommendation xx (see rationale 2): Upon the commencement of the next Application Submission Period, there must be clarity around the timing and/or criteria for initiating subsequent procedures from that point forth. More specifically, prior to the commencement of the next Application Submission Period, ICANN shall publish either (a) the date in which the next subsequent introduction of new gTLDs will take place or (b) the specific set of criteria and/or events that must occur prior to the opening up of the next subsequent process. Implementation Guidance xx (see rationale 2): A new round may initiate even if steps related to application processing and delegation from previous application windows have not been completed. 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 opportunity. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application opportunity, unless and/or until the applications from the previous round that match those strings have had their final disposition. Discussion: -- Comment: May be worth seeing if the WG can narrow in on a preference here. Or perhaps this makes sense as an unless in a sense, so the date is the preference, unless there is non-exhaustive list of things that would prevent the timely launch? Question: Preference for ICANN Org to set a date, or instead to say what has to happen before a next round? -- In Implementation Guidance we suggested two options since comments were widely varied. -- The first option adds to predictability for applicants. Else applicants may be in limbo for an unknown period of time. -- The second option gets pretty complicated when you are trying to determine contention sets. Not sure how you would do it. -- This is not meant to allow someone to get into an already existing contention set. In both of these cases nothing is going to be processed in a subsequent round until every contention set is resolved and done from the previous round. -- Recommendation: preference is that ICANN publish a date. -- Implementation Guidance: preference is that it should not be possible to apply for a string that is still being processed from a previous application opportunity. -- Disagree that strings from last round should be prohibited. Second option supports the notion of Applicant freedom of expression. -- From a process perspective the above comment would add complications that really aren't warranted. -- No evaluation of the new applicant would occur until the 2012 applications are resolved. The new applicants would have to accept that risk. -- Concerns about treating moribund applications made a decade ago as reservations for the next round. Are the strings that are withdrawn due to name collisions undergoing a process, or are they just on hold? -- What is the harm in keeping a particular string closed for new apps until all the previous applicants have fallen by the wayside. Then it opens up again for all. -- Because the window for application is closed at that point and we haven't said that a new window could open if they all fail. -- If there is agreement that rounds are the path forward, then if a string does not go through in one round it will become available in another round. -- That's one of our recommendations that there will be a series of windows. -- Is there any WG member that would die in a ditch over this option: “It should not be possible to apply for a string in a subsequent round that is still being processed from a previous application round.”? -- Favor the second option. -- Can't live with prohibiting applications for the same string. If "shall not proceed" means new applicants can still apply, I can live with that. -- What about applications that have not progressed on purpose? Or for technical reasons? -- From a pragmatic perspective if we allow for applicants to submit applications for a string that is already in process that adds layers of complexity to the process. If a string hasn’t gone forward to delegation and it becomes available again then it can be applied for. -- We don’t have a system in place that allows for continuing application periods, we have rounds. People should be waiting their turn but they can get in line -- violates applicants’ freedom of expression if they can’t apply. -- The point of the first recommendation is that ICANN Org will set a date certain or criteria that must occur. We are trying to get to a steady state process. -- If someone could apply for a string that is still in process, what we may be encouraging is applicants who might not be fully processed to apply in the next round if they think they are going to fail in the previous round. Need to define in implementation what “in process” means. -- If it would be possible to file applications for the same string in future rounds the door is open for gaming and unknown consequences: applicant(s) from the first round might consider future applicants in their behaviour and decisions. -- Surely, all delegated TLDs or those in process, are off limits. -- I think applicant freedom of expression means you can apply for any string you want, but I don't think that extends to TLDs already in existence or those that are in process in some way. -- Delegated TLDs are not under discussion. -- The point here are those that are not “in process”, so we need to define “in process”. -- Old applications that were denied for a policy reason should have to step up to new policy recommendations if they are going to prevail/ proceed and they should be encouraged to do so by knowing there may be applicants standing in line who are willing to do so. (No stonewalling on new policy recommendations - no blocking based on old policy positions.) -- We already have many categories of Application Status (Active, Applicant Support, Delegated, etc.) -- Question: What about the status “Not Approved”? Answer: That only applies when an application has gone through all of the steps. There will be one or two edge cases. -- Let’s say that we are talking about the names collisions issues and strings that were not delegated -- if new policy is developed by NCAP and may come out of the Board. If there isn’t a new policy they shouldn’t be able to block new applicants. -- An applicant from a prior round who does not want to meet new policy recommendations can block a string forever by not withdrawing a Not Approved application. ACTION ITEM: Change Implementation Guidance to: “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 [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Recommendation xx (see rationale 2): Application procedures must take place at predictable, regularly occurring intervals without indeterminable periods of review unless the GNSO Council recommends pausing the program and such recommendation is approved by the Board. Unless and until other procedures are recommended by the GNSO Council and approved by the ICANN Board, ICANN must only use “rounds” as part of the New gTLD Program. Recommendation xx (see rationale 2): Absent extraordinary circumstances, future reviews and/or policy development processes, including the next CCT Review, should take place concurrently with subsequent application rounds. In other words, future reviews and/or policy development processes must not stop or delay subsequent new gTLD rounds. Recommendation xx (See rationale 2). If the outputs of any reviews and/or policy development processes has, or could reasonably have, a material impact on the manner in which application procedures are conducted, such changes must only apply to the opening of the application procedure subsequent to the adoption of the relevant recommendations by the ICANN Board. Discussion: -- Look at these recommendations together. -- If we are clear that applications need to follow all of the timelines before becoming “Not Approved” then they cannot block in future rounds. -- If you have a new policy in the next round that eliminated the problem that blocked a previous string then it should be able to be applied for in the next round. -- Let’s say that .home can move forward but only as a closed generic or .brand where there is a one registrant TLD. What if one of the applicants for .home has no interest in that? Their application needs to be dead. -- Those (.home, .corp, .mail) are not withdrawn even though "not approved". If the Board adopts new name collision policy, old applicants should be willing to step up to the new name collision policy and not be able to refuse to do so and block the string forever by not withdrawing the application. -- Rules should apply in each round to those applicants. -- If you can’t live with the language please suggest new language. -- Problem seems to be how to fix the “Not Approved” applications from the previous round. Board may have to decide how to deal with them. That is out of scope for this WG. ________________________________ 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> ________________________________ 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> ________________________________ 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> ________________________________ 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.
participants (8)
-
Aikman-Scalese, Anne -
Alexander Schubert -
Annebeth Lange -
Austin, Donna -
Greg Shatan -
Jeff Neuman -
Julie Hedlund -
Martin Sutton