Please see my comments in ​red below. From: Aikman-Scalese, Anne <AAikman@lrrc.com> [Anne] Initial Report and Public Comment. The Initial Report recommended a "Standing IRT". There is a common understanding in the ICANN community about what an IRT does, how it is constituted, and what its powers are and are not. The documentation in GNSO procedures lays out the rules re IRT, including the composition of such a team which requires broad representation across the community. These understandings are codified in the GNSO Council Operating Procedures and in the Consensus Policy Implementation Framework. If the proposed body is renamed, this would require additional public comment which would include the need to specify how such a body would be constituted and what is powers would be. [Jeff] I do not agree that simply changing the name of the body would require additional public comment. In fact we could state in the report something to the effect of: "Because of the confusion caused between the term we used in the Initial Report, and how that term is generally used to describe a team responsible for the implementation of GNSO policies, we have changed the name to the "Standing New gTLD Advisory Group" (SNAG). Though we have changed the name, this new group should abide by the same rules and procedures generally applicable to Implementation Review Teams as set forth in existing GNSO Procedures". Why would that not solve the issue? [Anne] Effect on Existing GNSO Procedures and ICANN ByLaws. Once you apply a new name to this proposed new body designed specifically to address implementation issues post-launch, you have an animal that is not recognized in the Consensus Policy Implementation Framework nor in the GNSO Input, Guidance, and EPDP processes and is thus not incorporated into the language of those processes. Therefore, you will either have created a need for massive redrafting (including redrafting of the ICANN ByLaws) OR you will have removed that new body from the application of those processes. Jeff says there is no intention to change the applicability of the GNSO Input, Guidance, and EPDP process post-launch so it does not really make sense to name a new type of team that would require significant changes to existing procedures (and maybe even the ByLaws.) Thus, a "name change" for this body creates more questions than it answers. [Jeff] Applying the same language above would fix all of this. We are not modifying any existing process. [Anne] Prior Work of the Policy and Implementation WG. This has been a long-standing issue in Sub Pro since Leadership initially took the position that the GNSO Input, Guidance, and EPDP processes do not apply after launch. This is categorically not true. ​[Jeff] I know this has been your argument all along, but the documentation does not support your view. See https://www.icann.org/policy/implementation and https://www.icann.org/uploads/ckeditor/CPIF_v2.0_2019CLEAN.pdf. These all show that the IRT's work is prior to the Policy Effective Date. For the new gTLD process, that would be the day that the application window launches. I don't see anything that supports your view. [Anne] The Policy and Implementation Working Group examined numerous examples of issues that arose “post-launch” in the 2012 round. We ultimately concluded it is fruitless to try to characterize issues as either “policy” or “implementation” since one person’s policy is another’s implementation and vice versa. The mechanisms that were developed after the 2012 round to address these issues were specifically developed to apply WHENEVER the issue arise and to keep control of the issues at GNSO Council in a very transparent manner. It would be a massive change of policy to offer a new construct that either (1) causes the results of that PDP to have to be amended or (2) creates a new body that operates outside the established procedures already adopted by the Board and the GNSO. [Jeff] I dont disagree that distinguishing between policy and implementation is difficult. But this Predictability Framework does not change anything regarding transparency or any existing process. [Anne] If everyone is anxious to simply clarify the time period in which the Team will operate, why not just call the teams the “Pre-launch IRT” and the “Post-launch IRT”. Much simpler and more predictable – and requires a lot less redrafting. [Jeff] For the reasons above, I do not share the view that calling something a Pre-Launch or a Post Launch IRT will clear up the confusion or require much re-drafting. Lets see what others in the group think. Jeff Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive Suite 600, McLean VA 22102, USA M: +1.202.549.5079 D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> www.comlaude.com<http://www.comlaude.com/> [cid:e7ffb128-9fe6-4e6f-ba6b-b1a17b0dae7f] ________________________________ From: Aikman-Scalese, Anne <AAikman@lrrc.com> Sent: Tuesday, April 30, 2019 5:36 PM To: Julie Hedlund; gnso-newgtld-wg@icann.org Cc: Jeff Neuman Subject: RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 30 April 2019 Regarding yesterday's call and the attempt to measure consensus on the recommendation for a “Standing IRT”, changing the name of that recommended body actually creates more confusion rather than less. The reasons are: Initial Report and Public Comment. The Initial Report recommended a "Standing IRT". There is a common understanding in the ICANN community about what an IRT does, how it is constituted, and what its powers are and are not. The documentation in GNSO procedures lays out the rules re IRT, including the composition of such a team which requires broad representation across the community. These understandings are codified in the GNSO Council Operating Procedures and in the Consensus Policy Implementation Framework. If the proposed body is renamed, this would require additional public comment which would include the need to specify how such a body would be constituted and what is powers would be. Effect on Existing GNSO Procedures and ICANN ByLaws. Once you apply a new name to this proposed new body designed specifically to address implementation issues post-launch, you have an animal that is not recognized in the Consensus Policy Implementation Framework nor in the GNSO Input, Guidance, and EPDP processes and is thus not incorporated into the language of those processes. Therefore, you will either have created a need for massive redrafting (including redrafting of the ICANN ByLaws) OR you will have removed that new body from the application of those processes. Jeff says there is no intention to change the applicability of the GNSO Input, Guidance, and EPDP process post-launch so it does not really make sense to name a new type of team that would require significant changes to existing procedures (and maybe even the ByLaws.) Thus, a "name change" for this body creates more questions than it answers. Prior Work of the Policy and Implementation WG. This has been a long-standing issue in Sub Pro since Leadership initially took the position that the GNSO Input, Guidance, and EPDP processes do not apply after launch. This is categorically not true. The Policy and Implementation Working Group examined numerous examples of issues that arose “post-launch” in the 2012 round. We ultimately concluded it is fruitless to try to characterize issues as either “policy” or “implementation” since one person’s policy is another’s implementation and vice versa. The mechanisms that were developed after the 2012 round to address these issues were specifically developed to apply WHENEVER the issue arise and to keep control of the issues at GNSO Council in a very transparent manner. It would be a massive change of policy to offer a new construct that either (1) causes the results of that PDP to have to be amended or (2) creates a new body that operates outside the established procedures already adopted by the Board and the GNSO. If everyone is anxious to simply clarify the time period in which the Team will operate, why not just call the teams the “Pre-launch IRT” and the “Post-launch IRT”. Much simpler and more predictable – and requires a lot less redrafting. Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image003.png@01D4FF62.117141E0] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Julie Hedlund Sent: Tuesday, April 30, 2019 8:38 AM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 30 April 2019 [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting today, 30 April 2019. 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/2019-04-30+New+gTLD+Subsequent+Pro.... Please also see the referenced document at: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK.... Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Action Items: -- Staff will check on the ICANN Board response to the GAC advice in the Helsinki Communique’ on new gTLDs. -- WG to come up with a different name for the “standing IRT”. Maybe “Post Application Advisory Team”. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review of Summary Documents – (see: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK...) 2.2.1 Continuing Subsequent Procedures Policy Goals / What the WG is Seeking to Accomplish -- First bullet: replace “rounds” with “procedures”. 2.2.1.c.1: The Working Group recommends no changes to the existing policy calling for subsequent application rounds introduced in an ongoing, orderly, timely and predictable manner. -- Support from most commenters New Ideas/Concepts for Deliberations: -- GAC Advice and BC: Support for new rounds but no rounds started until reviews (CCT-RT) are complete. Need to do a cost-benefit analysis before starting new round. -- WG is taking into consideration the CCT-RT recommendations. Discussion: -- Policy does not have a demand component. -- Action Item: Board response to GAC Advice in the Helskinki Communique’. -- Note that the CCT-RT did have an economic study done by the Analysis Group, although perhaps not a full cost-benefit analysis. -- Concerns with maintaining the current policy unless there are objections. -- Unless there is a consensus on changing precedent we should stay on the same path. -- Can build on what we have learned, but hard to do analysis on what people might want. -- If the WG wants to request for an assessment to be done that will have to be approved by the Council. -- Calling for rounds introduced in an ongoing orderly timely and predictable manner support came from pretty much every group that responded in public comments to the Initial Report. -- We have some qualifications from the GAC. 2.2.1.e.1: The 2007 Final Report noted that success metrics would be developed around the New gTLD Program. What are some specific metrics that the program should be measured against? -- Support from most commenters. New Ideas/Concepts for Deliberations: ALAC, BRG, BC, RySG – New Ideas Discussion: -- Good proposals for different types of metrics. -- Need to define what we mean by success; CCT-RT referred that issue to the SubPro WG. -- Questions and issues in the CCT-RT could put some of these issues to rest. -- This WG could come up with a half dozen categories (elements of the program) and develop definitions of success for those – or develop targets, which is a less loaded word. -- Good conversation to continue on email. -- You could have a high-level structure from the 2012 round (to foster diversity, encourage competition, and enhance the utility of the DNS), then create specific targets within that structure within that framework. 2.2.2 Predictability -- Support from most commenters -- BC/RySG/IPC/ALAC (in response to e.1): New Idea - The Standing IRT must be representative of the community, but must also allow for the appointment of experts where needed. New Ideas/Concepts for Deliberations -- ICANN Org: Concerns/New Ideas Discussion: -- Can things in the model be improved so that you can support it? If not, what takes its place? -- Don’t think it’s in our authority to replace the GNSO policy process. -- We're not changing any of the policies or processes that have been established. -- Changes to policies after the launch need to go through the GNSO policy process; the predictability framework is for issues that come up outside of that process and guidance to the standing IRT. In the report we called it a standing IRT, but that seems to be confusing so we should change the name. Could call it a “gateway” to decide what is policy and what is not, and only looking at non-policy issues. -- Need to be more conscious of the need for predictability for third party interests. We use the term “affected parties” for that reason. -- WG needs to come up with a different name for the “standing IRT”. Maybe a Post Application Advisory Team. ________________________________ 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>

Anne For clarification, I did not remove any text in my reply. If you look back, my reply was to your first email (that did not have the citations), not to your e-mail to Kathy, which did have the citations. First of all I appreciate the discussion on the word "generally". Truth is I drafted that language off-the cuff to be illustrative and not as definitive language to use. But it sounds like the concept of stating that this new entity (whatever we call it) will follow those rules helps to clarify certain things. That's progress! Comparing the ePDP on the Temp Spec to this is like apples and oranges. It doesn't relate. The ePDP did not come out of the launch of a program derived from a process that was started by the GNSO and implemented by an IRT. The ePDP was a response to proposed mechanisms created by ICANN staff to respond to an external legal situation. The GNSO Council then believed this mechanism involved a change to previous Consensus Policies and then launched the ePDP. In this case, we have our PDP which will be followed by implementation of the policies derived from this Working Group and implemented by ICANN staff with the help of an IRT. Then the new gTLD program will launch. Once it launches, if there is truly a proposed change that would implicate policy, then the GNSO can (and should) initiate the normal GNSO processes as the Council deems appropriate. The Standing New gTLD Advisory Group (formerly "standing IRT") would not have a role. This would clearly be the case if ICANN wanted to change material portions of the legal agreement, or change a rule like allowing/not allowing closed generics, etc. But for the more minor changes, the ones that do not implicate policy or even implementation (but rather implicate execution), the GNSO processes do not address these situations and they can be way to bureaucratic to handle. For example,take ICANN's decision to change Digital Archery to a Random Drawing, or it changes the mechanics of the Pre-delegation testing. There was NO policy or even implementation process that was impacted and therefore arguably No role for the GNSO. But there were no processes to deal with those changes at all and ICANN therefore shot from the hip. It announced the changes, but did not solicit feedback from the impacted parties. It was a disaster from a predictability standpoint. The Predictability Framework attempts to deal with this a create a predictable process where none exists. I know you are arguing that the GNSO processes do account for these, but I and much of the community disagree with your view. We cannot invoke an ePDP or even GNSO input process for these types of issues. We cannot just tell ICANN they cant do anything that deviates at all even if circumstances necessitate changes. But we do need to have a predictable framework to deal with these. Lets hear from others please. Jeff Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive Suite 600, McLean VA 22102, USA M: +1.202.549.5079 D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> www.comlaude.com<http://www.comlaude.com/> [cid:8c56ffb7-b601-42fd-8c04-bcd200476cdf] ________________________________ From: Aikman-Scalese, Anne <AAikman@lrrc.com> Sent: Tuesday, April 30, 2019 9:39 PM To: Jeff Neuman; Julie Hedlund; gnso-newgtld-wg@icann.org Subject: RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 30 April 2019 Jeff, please don’t delete portions of my comments or cites to text from the Operating Procedures when you reply to my input. When you do, that makes things difficult for those who are only reading from the latest message and scrolling down. Thank you in advance for respecting this request. It is helpful that you suggest that the newly named entity would abide by the same GNSO rules and procedures as an IRT. Not sure why your statement is conditioned upon the word “generally” or why you would call it anything other than a “Post-Launch IRT”. The word “generally” leaves too much wiggle room when the WG solicited public comment on a “Standing IRT”. If you call it a “Post-Launch Standing IRT”, you eliminate ALL confusion and you don’t’ have to use the word “generally” or go out for more public comment if you have Consensus. (You also don’t have to create a new ICANN acronym that no one understands unless they have been on this Working Group.) Regarding our disagreement as to the time frame for applicability of the GNSO Annexes, I don’t see any references to “pre-launch” and “post-launch” in the Consensus Policy Implementation Framework (CPIF) or any references to new issues that arise post-launch. The only reference in the CPIF is to “Policy Effective Date”. The new recommendation in the Initial Report would modify the CPIF because it would provide for a Standing IRT post-launch. Please note the CPIF states the IRT has to be briefed on the GNSO Input and GNSO Guidance processes and this same briefing should be required for any Post-Launch IRT in order to ensure GNSO oversight is in place post-launch. (Thus my conclusion that there is too much wiggle room in your use of the word “generally”.) Obviously the GNSO Annexes for further Council work apply at any time, including post-launch. Otherwise, how could GNSO have possibly initiated and conducted an EPDP on the Temp Spec when that Annex came out of the same recommendations? In this regard, please note that the three processes specifically refer to “new issues”. Hopefully you are not suggesting that GNSO Council loses its oversight authority or ability to avail itself of these Input and Guidance processes after an application window opens? See again the highlighted language below from GNSO Guidance and GNSO Input Annexes which states, for example, as to GNSO Input that a “ GIP MAY BE INITIATED BY THE GNSO COUNCIL AT ANY TIME IT CONSIDERS APPROPRIATE”. - PLEASE DON’T DELETE THIS LANGUAGE OR THE HIGHLIGHTED PORTION OF THE TEXT FROM THE MANUALS WHEN YOU REPLY: GNSO Input Process Manual - https://gnso.icann.org/sites/default/files/file/field-file-attach/annex-3-in... GNSO Input Process (GIP) Introduction: A GIP is the process through which the GNSO provides input on matters that may not involve gTLD policy, for example in response to a request from the ICANN Board or in response to a public comment forum as further described in this GIP Manual. Any such requests should include as much information as possible. A GIP may be initiated by the GNSO Council at any time it considers appropriate, for example, when a request for GNSO input is received from the ICANN Board or other entity that does not involve the creation of new obligations for ICANN contracted parties and does not relate to a topic otherwise suitable for a GNSO Policy Development Process or GNSO Guidance Process, for example providing GNSO Input to a public comment forum. GNSO Guidance Manual - https://gnso.icann.org/sites/default/files/file/field-file-attach/annex-5-gg... GNSO Guidance Process Manual1.GGP Manual –Introduction: These guidelines and processes supplement the requirements for GGPs described in Annex D of the ICANN Bylaws [include link]. A GGP may be initiated by the GNSO Council when a request for input relating to gTLDs (either a new issue or in relation to previous policy recommendations) has been received from the ICANN Board or a gTLD issue has been identified by the GNSO Council that would benefit from GNSO Guidance, and it has determined that the intended outcome of the GGP is not expected to create new “Consensus Policy” recommendations including, but not limited to, any new contractual obligations for contracted parties (in which case a PDP would need to be initiated). However, the GGP may provide interpretation or assist in providing clarity with regards to the implementation of GNSO policy recommendations. The GGP should not be used as a tool to reopen a previously explored policy issue only because a constituency or stakeholder group was not satisfied with outcome of a previously held process on the same policy issue, unless the circumstances have changed and/or new information is available Anne Anne From: Jeff Neuman [mailto:jeff.neuman@comlaude.com] Sent: Tuesday, April 30, 2019 5:50 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 - 30 April 2019 [EXTERNAL] ________________________________ Please see my comments in ​red below. From: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> [Anne] Initial Report and Public Comment. The Initial Report recommended a "Standing IRT". There is a common understanding in the ICANN community about what an IRT does, how it is constituted, and what its powers are and are not. The documentation in GNSO procedures lays out the rules re IRT, including the composition of such a team which requires broad representation across the community. These understandings are codified in the GNSO Council Operating Procedures and in the Consensus Policy Implementation Framework. If the proposed body is renamed, this would require additional public comment which would include the need to specify how such a body would be constituted and what is powers would be. [Jeff] I do not agree that simply changing the name of the body would require additional public comment. In fact we could state in the report something to the effect of: "Because of the confusion caused between the term we used in the Initial Report, and how that term is generally used to describe a team responsible for the implementation of GNSO policies, we have changed the name to the "Standing New gTLD Advisory Group" (SNAG). Though we have changed the name, this new group should abide by the same rules and procedures generally applicable to Implementation Review Teams as set forth in existing GNSO Procedures". Why would that not solve the issue? [Anne] Effect on Existing GNSO Procedures and ICANN ByLaws. Once you apply a new name to this proposed new body designed specifically to address implementation issues post-launch, you have an animal that is not recognized in the Consensus Policy Implementation Framework nor in the GNSO Input, Guidance, and EPDP processes and is thus not incorporated into the language of those processes. Therefore, you will either have created a need for massive redrafting (including redrafting of the ICANN ByLaws) OR you will have removed that new body from the application of those processes. Jeff says there is no intention to change the applicability of the GNSO Input, Guidance, and EPDP process post-launch so it does not really make sense to name a new type of team that would require significant changes to existing procedures (and maybe even the ByLaws.) Thus, a "name change" for this body creates more questions than it answers. [Jeff] Applying the same language above would fix all of this. We are not modifying any existing process. [Anne] Prior Work of the Policy and Implementation WG. This has been a long-standing issue in Sub Pro since Leadership initially took the position that the GNSO Input, Guidance, and EPDP processes do not apply after launch. This is categorically not true. ​[Jeff] I know this has been your argument all along, but the documentation does not support your view. See https://www.icann.org/policy/implementation and https://www.icann.org/uploads/ckeditor/CPIF_v2.0_2019CLEAN.pdf. These all show that the IRT's work is prior to the Policy Effective Date. For the new gTLD process, that would be the day that the application window launches. I don't see anything that supports your view. [Anne] The Policy and Implementation Working Group examined numerous examples of issues that arose “post-launch” in the 2012 round. We ultimately concluded it is fruitless to try to characterize issues as either “policy” or “implementation” since one person’s policy is another’s implementation and vice versa. The mechanisms that were developed after the 2012 round to address these issues were specifically developed to apply WHENEVER the issue arise and to keep control of the issues at GNSO Council in a very transparent manner. It would be a massive change of policy to offer a new construct that either (1) causes the results of that PDP to have to be amended or (2) creates a new body that operates outside the established procedures already adopted by the Board and the GNSO. [Jeff] I dont disagree that distinguishing between policy and implementation is difficult. But this Predictability Framework does not change anything regarding transparency or any existing process. [Anne] If everyone is anxious to simply clarify the time period in which the Team will operate, why not just call the teams the “Pre-launch IRT” and the “Post-launch IRT”. Much simpler and more predictable – and requires a lot less redrafting. [Jeff] For the reasons above, I do not share the view that calling something a Pre-Launch or a Post Launch IRT will clear up the confusion or require much re-drafting. Lets see what others in the group think. Jeff Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive Suite 600, McLean VA 22102, USA M: +1.202.549.5079 D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> www.comlaude.com<http://www.comlaude.com/> [cid:image001.jpg@01D4FF7E.A2B7E570] ________________________________ From: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> Sent: Tuesday, April 30, 2019 5:36 PM To: Julie Hedlund; gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Cc: Jeff Neuman Subject: RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 30 April 2019 Regarding yesterday's call and the attempt to measure consensus on the recommendation for a “Standing IRT”, changing the name of that recommended body actually creates more confusion rather than less. The reasons are: Initial Report and Public Comment. The Initial Report recommended a "Standing IRT". There is a common understanding in the ICANN community about what an IRT does, how it is constituted, and what its powers are and are not. The documentation in GNSO procedures lays out the rules re IRT, including the composition of such a team which requires broad representation across the community. These understandings are codified in the GNSO Council Operating Procedures and in the Consensus Policy Implementation Framework. If the proposed body is renamed, this would require additional public comment which would include the need to specify how such a body would be constituted and what is powers would be. Effect on Existing GNSO Procedures and ICANN ByLaws. Once you apply a new name to this proposed new body designed specifically to address implementation issues post-launch, you have an animal that is not recognized in the Consensus Policy Implementation Framework nor in the GNSO Input, Guidance, and EPDP processes and is thus not incorporated into the language of those processes. Therefore, you will either have created a need for massive redrafting (including redrafting of the ICANN ByLaws) OR you will have removed that new body from the application of those processes. Jeff says there is no intention to change the applicability of the GNSO Input, Guidance, and EPDP process post-launch so it does not really make sense to name a new type of team that would require significant changes to existing procedures (and maybe even the ByLaws.) Thus, a "name change" for this body creates more questions than it answers. Prior Work of the Policy and Implementation WG. This has been a long-standing issue in Sub Pro since Leadership initially took the position that the GNSO Input, Guidance, and EPDP processes do not apply after launch. This is categorically not true. The Policy and Implementation Working Group examined numerous examples of issues that arose “post-launch” in the 2012 round. We ultimately concluded it is fruitless to try to characterize issues as either “policy” or “implementation” since one person’s policy is another’s implementation and vice versa. The mechanisms that were developed after the 2012 round to address these issues were specifically developed to apply WHENEVER the issue arise and to keep control of the issues at GNSO Council in a very transparent manner. It would be a massive change of policy to offer a new construct that either (1) causes the results of that PDP to have to be amended or (2) creates a new body that operates outside the established procedures already adopted by the Board and the GNSO. If everyone is anxious to simply clarify the time period in which the Team will operate, why not just call the teams the “Pre-launch IRT” and the “Post-launch IRT”. Much simpler and more predictable – and requires a lot less redrafting. Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image002.png@01D4FF7E.A2B7E570] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Julie Hedlund Sent: Tuesday, April 30, 2019 8:38 AM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 30 April 2019 [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting today, 30 April 2019. 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/2019-04-30+New+gTLD+Subsequent+Pro.... Please also see the referenced document at: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK.... Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Action Items: -- Staff will check on the ICANN Board response to the GAC advice in the Helsinki Communique’ on new gTLDs. -- WG to come up with a different name for the “standing IRT”. Maybe “Post Application Advisory Team”. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review of Summary Documents – (see: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK...) 2.2.1 Continuing Subsequent Procedures Policy Goals / What the WG is Seeking to Accomplish -- First bullet: replace “rounds” with “procedures”. 2.2.1.c.1: The Working Group recommends no changes to the existing policy calling for subsequent application rounds introduced in an ongoing, orderly, timely and predictable manner. -- Support from most commenters New Ideas/Concepts for Deliberations: -- GAC Advice and BC: Support for new rounds but no rounds started until reviews (CCT-RT) are complete. Need to do a cost-benefit analysis before starting new round. -- WG is taking into consideration the CCT-RT recommendations. Discussion: -- Policy does not have a demand component. -- Action Item: Board response to GAC Advice in the Helskinki Communique’. -- Note that the CCT-RT did have an economic study done by the Analysis Group, although perhaps not a full cost-benefit analysis. -- Concerns with maintaining the current policy unless there are objections. -- Unless there is a consensus on changing precedent we should stay on the same path. -- Can build on what we have learned, but hard to do analysis on what people might want. -- If the WG wants to request for an assessment to be done that will have to be approved by the Council. -- Calling for rounds introduced in an ongoing orderly timely and predictable manner support came from pretty much every group that responded in public comments to the Initial Report. -- We have some qualifications from the GAC. 2.2.1.e.1: The 2007 Final Report noted that success metrics would be developed around the New gTLD Program. What are some specific metrics that the program should be measured against? -- Support from most commenters. New Ideas/Concepts for Deliberations: ALAC, BRG, BC, RySG – New Ideas Discussion: -- Good proposals for different types of metrics. -- Need to define what we mean by success; CCT-RT referred that issue to the SubPro WG. -- Questions and issues in the CCT-RT could put some of these issues to rest. -- This WG could come up with a half dozen categories (elements of the program) and develop definitions of success for those – or develop targets, which is a less loaded word. -- Good conversation to continue on email. -- You could have a high-level structure from the 2012 round (to foster diversity, encourage competition, and enhance the utility of the DNS), then create specific targets within that structure within that framework. 2.2.2 Predictability -- Support from most commenters -- BC/RySG/IPC/ALAC (in response to e.1): New Idea - The Standing IRT must be representative of the community, but must also allow for the appointment of experts where needed. New Ideas/Concepts for Deliberations -- ICANN Org: Concerns/New Ideas Discussion: -- Can things in the model be improved so that you can support it? If not, what takes its place? -- Don’t think it’s in our authority to replace the GNSO policy process. -- We're not changing any of the policies or processes that have been established. -- Changes to policies after the launch need to go through the GNSO policy process; the predictability framework is for issues that come up outside of that process and guidance to the standing IRT. In the report we called it a standing IRT, but that seems to be confusing so we should change the name. Could call it a “gateway” to decide what is policy and what is not, and only looking at non-policy issues. -- Need to be more conscious of the need for predictability for third party interests. We use the term “affected parties” for that reason. -- WG needs to come up with a different name for the “standing IRT”. Maybe a Post Application Advisory Team. ________________________________ 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>

I know Jeff is interested to hear from others, but unfortunately I’ve become confused by the email discussion and can no longer discern what the problem is we are trying to solve. It would be helpful if the problem could be articulated along with the key points of the respective arguments or concerns. Thanks Donna From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Aikman-Scalese, Anne Sent: Wednesday, May 01, 2019 12:31 PM 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 - 30 April 2019 Thanks Jeff. Sorry for the confusion as to which email you were responding to on the list. The EPDP was a process ALREADY IN PLACE in the ICANN ByLaws (Annex E) and the GNSO Operating Procedures long before the Temp Spec issue arose specifically because the GNSO Policy and Implementation Working Group developed it years ago after the 2012 round launched and put it in place for application at ANY TIME if needed. That process was NOT developed just as a “response to a situation”. ( Please note that Annex IV refers to EPDP, not ePDP and that this process is codified in the amendments to the ICANN ByLaws as Annex E which occurred long before the Temp Spec issue arose.) The same is true of the GNSO Guidance and GNSO Input processes. These processes apply post-launch and were developed with SPECIFIC reference to issues that arose post-launch in 2012. Their applicability was not restricted to the “next round” pre-launch phase by any stretch of the imagination. No one is saying that ICANN org and IRT have to bring every issue in front of GNSO Council. On the other hand, no one should be trying to use the “Predictability Framework’ to eliminate GNSO oversight post-launch as reflected in these established processes. It is absolutely untrue that GNSO has to “check out” once a program launches. That would be very bad policy indeed. As a former active member of the Policy and Implementation Working Group, I would be happy to discuss your theory that GNSO oversight using these processes does not apply after launch in a live update session with GNSO at the meeting in Marrakech. But looking at the plain language, “ A GIP may be initiated by the GNSO Council at any time it considers appropriate should contribute to our understanding. Anne From: Jeff Neuman [mailto:jeff.neuman@comlaude.com] Sent: Tuesday, April 30, 2019 7:08 PM 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 - 30 April 2019 [EXTERNAL] ________________________________ Anne For clarification, I did not remove any text in my reply. If you look back, my reply was to your first email (that did not have the citations), not to your e-mail to Kathy, which did have the citations. First of all I appreciate the discussion on the word "generally". Truth is I drafted that language off-the cuff to be illustrative and not as definitive language to use. But it sounds like the concept of stating that this new entity (whatever we call it) will follow those rules helps to clarify certain things. That's progress! Comparing the ePDP on the Temp Spec to this is like apples and oranges. It doesn't relate. The ePDP did not come out of the launch of a program derived from a process that was started by the GNSO and implemented by an IRT. The ePDP was a response to proposed mechanisms created by ICANN staff to respond to an external legal situation. The GNSO Council then believed this mechanism involved a change to previous Consensus Policies and then launched the ePDP. In this case, we have our PDP which will be followed by implementation of the policies derived from this Working Group and implemented by ICANN staff with the help of an IRT. Then the new gTLD program will launch. Once it launches, if there is truly a proposed change that would implicate policy, then the GNSO can (and should) initiate the normal GNSO processes as the Council deems appropriate. The Standing New gTLD Advisory Group (formerly "standing IRT") would not have a role. This would clearly be the case if ICANN wanted to change material portions of the legal agreement, or change a rule like allowing/not allowing closed generics, etc. But for the more minor changes, the ones that do not implicate policy or even implementation (but rather implicate execution), the GNSO processes do not address these situations and they can be way to bureaucratic to handle. For example,take ICANN's decision to change Digital Archery to a Random Drawing, or it changes the mechanics of the Pre-delegation testing. There was NO policy or even implementation process that was impacted and therefore arguably No role for the GNSO. But there were no processes to deal with those changes at all and ICANN therefore shot from the hip. It announced the changes, but did not solicit feedback from the impacted parties. It was a disaster from a predictability standpoint. The Predictability Framework attempts to deal with this a create a predictable process where none exists. I know you are arguing that the GNSO processes do account for these, but I and much of the community disagree with your view. We cannot invoke an ePDP or even GNSO input process for these types of issues. We cannot just tell ICANN they cant do anything that deviates at all even if circumstances necessitate changes. But we do need to have a predictable framework to deal with these. Lets hear from others please. Jeff Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive Suite 600, McLean VA 22102, USA M: +1.202.549.5079 D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> www.comlaude.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.comlaude.com_&d=DwMG...> [cid:image001.jpg@01D5003C.715F81E0] ________________________________ From: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> Sent: Tuesday, April 30, 2019 9:39 PM To: Jeff Neuman; Julie Hedlund; gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 30 April 2019 Jeff, please don’t delete portions of my comments or cites to text from the Operating Procedures when you reply to my input. When you do, that makes things difficult for those who are only reading from the latest message and scrolling down. Thank you in advance for respecting this request. It is helpful that you suggest that the newly named entity would abide by the same GNSO rules and procedures as an IRT. Not sure why your statement is conditioned upon the word “generally” or why you would call it anything other than a “Post-Launch IRT”. The word “generally” leaves too much wiggle room when the WG solicited public comment on a “Standing IRT”. If you call it a “Post-Launch Standing IRT”, you eliminate ALL confusion and you don’t’ have to use the word “generally” or go out for more public comment if you have Consensus. (You also don’t have to create a new ICANN acronym that no one understands unless they have been on this Working Group.) Regarding our disagreement as to the time frame for applicability of the GNSO Annexes, I don’t see any references to “pre-launch” and “post-launch” in the Consensus Policy Implementation Framework (CPIF) or any references to new issues that arise post-launch. The only reference in the CPIF is to “Policy Effective Date”. The new recommendation in the Initial Report would modify the CPIF because it would provide for a Standing IRT post-launch. Please note the CPIF states the IRT has to be briefed on the GNSO Input and GNSO Guidance processes and this same briefing should be required for any Post-Launch IRT in order to ensure GNSO oversight is in place post-launch. (Thus my conclusion that there is too much wiggle room in your use of the word “generally”.) Obviously the GNSO Annexes for further Council work apply at any time, including post-launch. Otherwise, how could GNSO have possibly initiated and conducted an EPDP on the Temp Spec when that Annex came out of the same recommendations? In this regard, please note that the three processes specifically refer to “new issues”. Hopefully you are not suggesting that GNSO Council loses its oversight authority or ability to avail itself of these Input and Guidance processes after an application window opens? See again the highlighted language below from GNSO Guidance and GNSO Input Annexes which states, for example, as to GNSO Input that a “ GIP MAY BE INITIATED BY THE GNSO COUNCIL AT ANY TIME IT CONSIDERS APPROPRIATE”. - PLEASE DON’T DELETE THIS LANGUAGE OR THE HIGHLIGHTED PORTION OF THE TEXT FROM THE MANUALS WHEN YOU REPLY: GNSO Input Process Manual - https://gnso.icann.org/sites/default/files/file/field-file-attach/annex-3-input-process-manual-18jun18-en.pdf<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_default_files_file_field-2Dfile-2Dattach_annex-2D3-2Dinput-2Dprocess-2Dmanual-2D18jun18-2Den.pdf&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=bzWrxmspMkeDJwJLq86fMSW_IyuAZP_F7XyBcgTfta0&e=> GNSO Input Process (GIP) Introduction: A GIP is the process through which the GNSO provides input on matters that may not involve gTLD policy, for example in response to a request from the ICANN Board or in response to a public comment forum as further described in this GIP Manual. Any such requests should include as much information as possible. A GIP may be initiated by the GNSO Council at any time it considers appropriate, for example, when a request for GNSO input is received from the ICANN Board or other entity that does not involve the creation of new obligations for ICANN contracted parties and does not relate to a topic otherwise suitable for a GNSO Policy Development Process or GNSO Guidance Process, for example providing GNSO Input to a public comment forum. GNSO Guidance Manual - https://gnso.icann.org/sites/default/files/file/field-file-attach/annex-5-ggp-manual-18jun18-en.pdf<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_default_files_file_field-2Dfile-2Dattach_annex-2D5-2Dggp-2Dmanual-2D18jun18-2Den.pdf&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=PQxaL7Lv7CpEbUNA5DhB18eORlzFL-2BJO3wQhoaFDQ&e=> GNSO Guidance Process Manual1.GGP Manual –Introduction: These guidelines and processes supplement the requirements for GGPs described in Annex D of the ICANN Bylaws [include link]. A GGP may be initiated by the GNSO Council when a request for input relating to gTLDs (either a new issue or in relation to previous policy recommendations) has been received from the ICANN Board or a gTLD issue has been identified by the GNSO Council that would benefit from GNSO Guidance, and it has determined that the intended outcome of the GGP is not expected to create new “Consensus Policy” recommendations including, but not limited to, any new contractual obligations for contracted parties (in which case a PDP would need to be initiated). However, the GGP may provide interpretation or assist in providing clarity with regards to the implementation of GNSO policy recommendations. The GGP should not be used as a tool to reopen a previously explored policy issue only because a constituency or stakeholder group was not satisfied with outcome of a previously held process on the same policy issue, unless the circumstances have changed and/or new information is available Anne Anne From: Jeff Neuman [mailto:jeff.neuman@comlaude.com] Sent: Tuesday, April 30, 2019 5:50 PM 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 - 30 April 2019 [EXTERNAL] ________________________________ Please see my comments in ​red below. From: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> [Anne] Initial Report and Public Comment. The Initial Report recommended a "Standing IRT". There is a common understanding in the ICANN community about what an IRT does, how it is constituted, and what its powers are and are not. The documentation in GNSO procedures lays out the rules re IRT, including the composition of such a team which requires broad representation across the community. These understandings are codified in the GNSO Council Operating Procedures and in the Consensus Policy Implementation Framework. If the proposed body is renamed, this would require additional public comment which would include the need to specify how such a body would be constituted and what is powers would be. [Jeff] I do not agree that simply changing the name of the body would require additional public comment. In fact we could state in the report something to the effect of: "Because of the confusion caused between the term we used in the Initial Report, and how that term is generally used to describe a team responsible for the implementation of GNSO policies, we have changed the name to the "Standing New gTLD Advisory Group" (SNAG). Though we have changed the name, this new group should abide by the same rules and procedures generally applicable to Implementation Review Teams as set forth in existing GNSO Procedures". Why would that not solve the issue? [Anne] Effect on Existing GNSO Procedures and ICANN ByLaws. Once you apply a new name to this proposed new body designed specifically to address implementation issues post-launch, you have an animal that is not recognized in the Consensus Policy Implementation Framework nor in the GNSO Input, Guidance, and EPDP processes and is thus not incorporated into the language of those processes. Therefore, you will either have created a need for massive redrafting (including redrafting of the ICANN ByLaws) OR you will have removed that new body from the application of those processes. Jeff says there is no intention to change the applicability of the GNSO Input, Guidance, and EPDP process post-launch so it does not really make sense to name a new type of team that would require significant changes to existing procedures (and maybe even the ByLaws.) Thus, a "name change" for this body creates more questions than it answers. [Jeff] Applying the same language above would fix all of this. We are not modifying any existing process. [Anne] Prior Work of the Policy and Implementation WG. This has been a long-standing issue in Sub Pro since Leadership initially took the position that the GNSO Input, Guidance, and EPDP processes do not apply after launch. This is categorically not true. ​[Jeff] I know this has been your argument all along, but the documentation does not support your view. See https://www.icann.org/policy/implementation<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_policy_implementation&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=fGYI02A0z8Rt2vMHDzRZO89Z15edVRNF23fgudLvYDk&e=> and https://www.icann.org/uploads/ckeditor/CPIF_v2.0_2019CLEAN.pdf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_uploads_ckeditor_CPIF-5Fv2.0-5F2019CLEAN.pdf&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=uY4fujh1pLZJcb3MVAFVqis1l-Y_dtm637IAO4OPRrI&e=>. These all show that the IRT's work is prior to the Policy Effective Date. For the new gTLD process, that would be the day that the application window launches. I don't see anything that supports your view. [Anne] The Policy and Implementation Working Group examined numerous examples of issues that arose “post-launch” in the 2012 round. We ultimately concluded it is fruitless to try to characterize issues as either “policy” or “implementation” since one person’s policy is another’s implementation and vice versa. The mechanisms that were developed after the 2012 round to address these issues were specifically developed to apply WHENEVER the issue arise and to keep control of the issues at GNSO Council in a very transparent manner. It would be a massive change of policy to offer a new construct that either (1) causes the results of that PDP to have to be amended or (2) creates a new body that operates outside the established procedures already adopted by the Board and the GNSO. [Jeff] I dont disagree that distinguishing between policy and implementation is difficult. But this Predictability Framework does not change anything regarding transparency or any existing process. [Anne] If everyone is anxious to simply clarify the time period in which the Team will operate, why not just call the teams the “Pre-launch IRT” and the “Post-launch IRT”. Much simpler and more predictable – and requires a lot less redrafting. [Jeff] For the reasons above, I do not share the view that calling something a Pre-Launch or a Post Launch IRT will clear up the confusion or require much re-drafting. Lets see what others in the group think. Jeff Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive Suite 600, McLean VA 22102, USA M: +1.202.549.5079 D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> www.comlaude.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.comlaude.com_&d=DwMG...> [cid:image001.jpg@01D5003C.715F81E0] ________________________________ From: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> Sent: Tuesday, April 30, 2019 5:36 PM To: Julie Hedlund; gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Cc: Jeff Neuman Subject: RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 30 April 2019 Regarding yesterday's call and the attempt to measure consensus on the recommendation for a “Standing IRT”, changing the name of that recommended body actually creates more confusion rather than less. The reasons are: Initial Report and Public Comment. The Initial Report recommended a "Standing IRT". There is a common understanding in the ICANN community about what an IRT does, how it is constituted, and what its powers are and are not. The documentation in GNSO procedures lays out the rules re IRT, including the composition of such a team which requires broad representation across the community. These understandings are codified in the GNSO Council Operating Procedures and in the Consensus Policy Implementation Framework. If the proposed body is renamed, this would require additional public comment which would include the need to specify how such a body would be constituted and what is powers would be. Effect on Existing GNSO Procedures and ICANN ByLaws. Once you apply a new name to this proposed new body designed specifically to address implementation issues post-launch, you have an animal that is not recognized in the Consensus Policy Implementation Framework nor in the GNSO Input, Guidance, and EPDP processes and is thus not incorporated into the language of those processes. Therefore, you will either have created a need for massive redrafting (including redrafting of the ICANN ByLaws) OR you will have removed that new body from the application of those processes. Jeff says there is no intention to change the applicability of the GNSO Input, Guidance, and EPDP process post-launch so it does not really make sense to name a new type of team that would require significant changes to existing procedures (and maybe even the ByLaws.) Thus, a "name change" for this body creates more questions than it answers. Prior Work of the Policy and Implementation WG. This has been a long-standing issue in Sub Pro since Leadership initially took the position that the GNSO Input, Guidance, and EPDP processes do not apply after launch. This is categorically not true. The Policy and Implementation Working Group examined numerous examples of issues that arose “post-launch” in the 2012 round. We ultimately concluded it is fruitless to try to characterize issues as either “policy” or “implementation” since one person’s policy is another’s implementation and vice versa. The mechanisms that were developed after the 2012 round to address these issues were specifically developed to apply WHENEVER the issue arise and to keep control of the issues at GNSO Council in a very transparent manner. It would be a massive change of policy to offer a new construct that either (1) causes the results of that PDP to have to be amended or (2) creates a new body that operates outside the established procedures already adopted by the Board and the GNSO. If everyone is anxious to simply clarify the time period in which the Team will operate, why not just call the teams the “Pre-launch IRT” and the “Post-launch IRT”. Much simpler and more predictable – and requires a lot less redrafting. Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image002.png@01D5003C.715F81E0] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__lrrc.com_&d=DwMGaQ&c=MOp...> From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Julie Hedlund Sent: Tuesday, April 30, 2019 8:38 AM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 30 April 2019 [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting today, 30 April 2019. 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/2019-04-30+New+gTLD+Subsequent+Procedures+PDP<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_display_NGSPP_2019-2D04-2D30-2BNew-2BgTLD-2BSubsequent-2BProcedures-2BPDP&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=Kq9-Q1TqcXzyiOxZOdjPTNNzTi7qJEiptbSsIH4W9v4&e=>. Please also see the referenced document at: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-w/edit?usp=sharing<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-2Dw_edit-3Fusp-3Dsharing&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=iUz100Ji1JrIGzccYRbuxnvYKRWaET41282e2eHpY9Q&e=>. Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Action Items: -- Staff will check on the ICANN Board response to the GAC advice in the Helsinki Communique’ on new gTLDs. -- WG to come up with a different name for the “standing IRT”. Maybe “Post Application Advisory Team”. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review of Summary Documents – (see: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-w/edit?usp=sharing<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-2Dw_edit-3Fusp-3Dsharing&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=iUz100Ji1JrIGzccYRbuxnvYKRWaET41282e2eHpY9Q&e=>) 2.2.1 Continuing Subsequent Procedures Policy Goals / What the WG is Seeking to Accomplish -- First bullet: replace “rounds” with “procedures”. 2.2.1.c.1: The Working Group recommends no changes to the existing policy calling for subsequent application rounds introduced in an ongoing, orderly, timely and predictable manner. -- Support from most commenters New Ideas/Concepts for Deliberations: -- GAC Advice and BC: Support for new rounds but no rounds started until reviews (CCT-RT) are complete. Need to do a cost-benefit analysis before starting new round. -- WG is taking into consideration the CCT-RT recommendations. Discussion: -- Policy does not have a demand component. -- Action Item: Board response to GAC Advice in the Helskinki Communique’. -- Note that the CCT-RT did have an economic study done by the Analysis Group, although perhaps not a full cost-benefit analysis. -- Concerns with maintaining the current policy unless there are objections. -- Unless there is a consensus on changing precedent we should stay on the same path. -- Can build on what we have learned, but hard to do analysis on what people might want. -- If the WG wants to request for an assessment to be done that will have to be approved by the Council. -- Calling for rounds introduced in an ongoing orderly timely and predictable manner support came from pretty much every group that responded in public comments to the Initial Report. -- We have some qualifications from the GAC. 2.2.1.e.1: The 2007 Final Report noted that success metrics would be developed around the New gTLD Program. What are some specific metrics that the program should be measured against? -- Support from most commenters. New Ideas/Concepts for Deliberations: ALAC, BRG, BC, RySG – New Ideas Discussion: -- Good proposals for different types of metrics. -- Need to define what we mean by success; CCT-RT referred that issue to the SubPro WG. -- Questions and issues in the CCT-RT could put some of these issues to rest. -- This WG could come up with a half dozen categories (elements of the program) and develop definitions of success for those – or develop targets, which is a less loaded word. -- Good conversation to continue on email. -- You could have a high-level structure from the 2012 round (to foster diversity, encourage competition, and enhance the utility of the DNS), then create specific targets within that structure within that framework. 2.2.2 Predictability -- Support from most commenters -- BC/RySG/IPC/ALAC (in response to e.1): New Idea - The Standing IRT must be representative of the community, but must also allow for the appointment of experts where needed. New Ideas/Concepts for Deliberations -- ICANN Org: Concerns/New Ideas Discussion: -- Can things in the model be improved so that you can support it? If not, what takes its place? -- Don’t think it’s in our authority to replace the GNSO policy process. -- We're not changing any of the policies or processes that have been established. -- Changes to policies after the launch need to go through the GNSO policy process; the predictability framework is for issues that come up outside of that process and guidance to the standing IRT. In the report we called it a standing IRT, but that seems to be confusing so we should change the name. Could call it a “gateway” to decide what is policy and what is not, and only looking at non-policy issues. -- Need to be more conscious of the need for predictability for third party interests. We use the term “affected parties” for that reason. -- WG needs to come up with a different name for the “standing IRT”. Maybe a Post Application Advisory Team. ________________________________ 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.proofpoint.com/v2/url?u=https-3A__comlaude.com&d=DwMGaQ&c...> ________________________________ 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.proofpoint.com/v2/url?u=https-3A__comlaude.com&d=DwMGaQ&c...> ________________________________ 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.

+1, I tried to formulate a cogent response last night but realized I was also lost. From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Mike Rodenbaugh Sent: Wednesday, May 01, 2019 9:34 AM To: Austin, Donna <Donna.Austin@team.neustar> Cc: gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 30 April 2019 +1 Thanks, Mike Mike Rodenbaugh RODENBAUGH LAW tel/fax: +1.415.738.8087 http://rodenbaugh.com On Tue, Apr 30, 2019, 11:42 PM Austin, Donna via Gnso-newgtld-wg <gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org>> wrote: I know Jeff is interested to hear from others, but unfortunately I’ve become confused by the email discussion and can no longer discern what the problem is we are trying to solve. It would be helpful if the problem could be articulated along with the key points of the respective arguments or concerns. Thanks Donna 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: Wednesday, May 01, 2019 12:31 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: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 30 April 2019 Thanks Jeff. Sorry for the confusion as to which email you were responding to on the list. The EPDP was a process ALREADY IN PLACE in the ICANN ByLaws (Annex E) and the GNSO Operating Procedures long before the Temp Spec issue arose specifically because the GNSO Policy and Implementation Working Group developed it years ago after the 2012 round launched and put it in place for application at ANY TIME if needed. That process was NOT developed just as a “response to a situation”. ( Please note that Annex IV refers to EPDP, not ePDP and that this process is codified in the amendments to the ICANN ByLaws as Annex E which occurred long before the Temp Spec issue arose.) The same is true of the GNSO Guidance and GNSO Input processes. These processes apply post-launch and were developed with SPECIFIC reference to issues that arose post-launch in 2012. Their applicability was not restricted to the “next round” pre-launch phase by any stretch of the imagination. No one is saying that ICANN org and IRT have to bring every issue in front of GNSO Council. On the other hand, no one should be trying to use the “Predictability Framework’ to eliminate GNSO oversight post-launch as reflected in these established processes. It is absolutely untrue that GNSO has to “check out” once a program launches. That would be very bad policy indeed. As a former active member of the Policy and Implementation Working Group, I would be happy to discuss your theory that GNSO oversight using these processes does not apply after launch in a live update session with GNSO at the meeting in Marrakech. But looking at the plain language, “ A GIP may be initiated by the GNSO Council at any time it considers appropriate should contribute to our understanding. Anne From: Jeff Neuman [mailto:jeff.neuman@comlaude.com] Sent: Tuesday, April 30, 2019 7:08 PM 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 - 30 April 2019 [EXTERNAL] ________________________________ Anne For clarification, I did not remove any text in my reply. If you look back, my reply was to your first email (that did not have the citations), not to your e-mail to Kathy, which did have the citations. First of all I appreciate the discussion on the word "generally". Truth is I drafted that language off-the cuff to be illustrative and not as definitive language to use. But it sounds like the concept of stating that this new entity (whatever we call it) will follow those rules helps to clarify certain things. That's progress! Comparing the ePDP on the Temp Spec to this is like apples and oranges. It doesn't relate. The ePDP did not come out of the launch of a program derived from a process that was started by the GNSO and implemented by an IRT. The ePDP was a response to proposed mechanisms created by ICANN staff to respond to an external legal situation. The GNSO Council then believed this mechanism involved a change to previous Consensus Policies and then launched the ePDP. In this case, we have our PDP which will be followed by implementation of the policies derived from this Working Group and implemented by ICANN staff with the help of an IRT. Then the new gTLD program will launch. Once it launches, if there is truly a proposed change that would implicate policy, then the GNSO can (and should) initiate the normal GNSO processes as the Council deems appropriate. The Standing New gTLD Advisory Group (formerly "standing IRT") would not have a role. This would clearly be the case if ICANN wanted to change material portions of the legal agreement, or change a rule like allowing/not allowing closed generics, etc. But for the more minor changes, the ones that do not implicate policy or even implementation (but rather implicate execution), the GNSO processes do not address these situations and they can be way to bureaucratic to handle. For example,take ICANN's decision to change Digital Archery to a Random Drawing, or it changes the mechanics of the Pre-delegation testing. There was NO policy or even implementation process that was impacted and therefore arguably No role for the GNSO. But there were no processes to deal with those changes at all and ICANN therefore shot from the hip. It announced the changes, but did not solicit feedback from the impacted parties. It was a disaster from a predictability standpoint. The Predictability Framework attempts to deal with this a create a predictable process where none exists. I know you are arguing that the GNSO processes do account for these, but I and much of the community disagree with your view. We cannot invoke an ePDP or even GNSO input process for these types of issues. We cannot just tell ICANN they cant do anything that deviates at all even if circumstances necessitate changes. But we do need to have a predictable framework to deal with these. Lets hear from others please. Jeff Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive Suite 600, McLean VA 22102, USA M: +1.202.549.5079 D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> www.comlaude.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.comlaude.com_&d=DwMG...> [cid:image001.jpg@01D5003C.715F81E0] ________________________________ From: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> Sent: Tuesday, April 30, 2019 9:39 PM To: Jeff Neuman; Julie Hedlund; gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 30 April 2019 Jeff, please don’t delete portions of my comments or cites to text from the Operating Procedures when you reply to my input. When you do, that makes things difficult for those who are only reading from the latest message and scrolling down. Thank you in advance for respecting this request. It is helpful that you suggest that the newly named entity would abide by the same GNSO rules and procedures as an IRT. Not sure why your statement is conditioned upon the word “generally” or why you would call it anything other than a “Post-Launch IRT”. The word “generally” leaves too much wiggle room when the WG solicited public comment on a “Standing IRT”. If you call it a “Post-Launch Standing IRT”, you eliminate ALL confusion and you don’t’ have to use the word “generally” or go out for more public comment if you have Consensus. (You also don’t have to create a new ICANN acronym that no one understands unless they have been on this Working Group.) Regarding our disagreement as to the time frame for applicability of the GNSO Annexes, I don’t see any references to “pre-launch” and “post-launch” in the Consensus Policy Implementation Framework (CPIF) or any references to new issues that arise post-launch. The only reference in the CPIF is to “Policy Effective Date”. The new recommendation in the Initial Report would modify the CPIF because it would provide for a Standing IRT post-launch. Please note the CPIF states the IRT has to be briefed on the GNSO Input and GNSO Guidance processes and this same briefing should be required for any Post-Launch IRT in order to ensure GNSO oversight is in place post-launch. (Thus my conclusion that there is too much wiggle room in your use of the word “generally”.) Obviously the GNSO Annexes for further Council work apply at any time, including post-launch. Otherwise, how could GNSO have possibly initiated and conducted an EPDP on the Temp Spec when that Annex came out of the same recommendations? In this regard, please note that the three processes specifically refer to “new issues”. Hopefully you are not suggesting that GNSO Council loses its oversight authority or ability to avail itself of these Input and Guidance processes after an application window opens? See again the highlighted language below from GNSO Guidance and GNSO Input Annexes which states, for example, as to GNSO Input that a “ GIP MAY BE INITIATED BY THE GNSO COUNCIL AT ANY TIME IT CONSIDERS APPROPRIATE”. - PLEASE DON’T DELETE THIS LANGUAGE OR THE HIGHLIGHTED PORTION OF THE TEXT FROM THE MANUALS WHEN YOU REPLY: GNSO Input Process Manual - https://gnso.icann.org/sites/default/files/file/field-file-attach/annex-3-input-process-manual-18jun18-en.pdf<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_default_files_file_field-2Dfile-2Dattach_annex-2D3-2Dinput-2Dprocess-2Dmanual-2D18jun18-2Den.pdf&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=bzWrxmspMkeDJwJLq86fMSW_IyuAZP_F7XyBcgTfta0&e=> GNSO Input Process (GIP) Introduction: A GIP is the process through which the GNSO provides input on matters that may not involve gTLD policy, for example in response to a request from the ICANN Board or in response to a public comment forum as further described in this GIP Manual. Any such requests should include as much information as possible. A GIP may be initiated by the GNSO Council at any time it considers appropriate, for example, when a request for GNSO input is received from the ICANN Board or other entity that does not involve the creation of new obligations for ICANN contracted parties and does not relate to a topic otherwise suitable for a GNSO Policy Development Process or GNSO Guidance Process, for example providing GNSO Input to a public comment forum. GNSO Guidance Manual - https://gnso.icann.org/sites/default/files/file/field-file-attach/annex-5-ggp-manual-18jun18-en.pdf<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_default_files_file_field-2Dfile-2Dattach_annex-2D5-2Dggp-2Dmanual-2D18jun18-2Den.pdf&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=PQxaL7Lv7CpEbUNA5DhB18eORlzFL-2BJO3wQhoaFDQ&e=> GNSO Guidance Process Manual1.GGP Manual –Introduction: These guidelines and processes supplement the requirements for GGPs described in Annex D of the ICANN Bylaws [include link]. A GGP may be initiated by the GNSO Council when a request for input relating to gTLDs (either a new issue or in relation to previous policy recommendations) has been received from the ICANN Board or a gTLD issue has been identified by the GNSO Council that would benefit from GNSO Guidance, and it has determined that the intended outcome of the GGP is not expected to create new “Consensus Policy” recommendations including, but not limited to, any new contractual obligations for contracted parties (in which case a PDP would need to be initiated). However, the GGP may provide interpretation or assist in providing clarity with regards to the implementation of GNSO policy recommendations. The GGP should not be used as a tool to reopen a previously explored policy issue only because a constituency or stakeholder group was not satisfied with outcome of a previously held process on the same policy issue, unless the circumstances have changed and/or new information is available Anne Anne From: Jeff Neuman [mailto:jeff.neuman@comlaude.com] Sent: Tuesday, April 30, 2019 5:50 PM 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 - 30 April 2019 [EXTERNAL] ________________________________ Please see my comments in ​red below. From: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> [Anne] Initial Report and Public Comment. The Initial Report recommended a "Standing IRT". There is a common understanding in the ICANN community about what an IRT does, how it is constituted, and what its powers are and are not. The documentation in GNSO procedures lays out the rules re IRT, including the composition of such a team which requires broad representation across the community. These understandings are codified in the GNSO Council Operating Procedures and in the Consensus Policy Implementation Framework. If the proposed body is renamed, this would require additional public comment which would include the need to specify how such a body would be constituted and what is powers would be. [Jeff] I do not agree that simply changing the name of the body would require additional public comment. In fact we could state in the report something to the effect of: "Because of the confusion caused between the term we used in the Initial Report, and how that term is generally used to describe a team responsible for the implementation of GNSO policies, we have changed the name to the "Standing New gTLD Advisory Group" (SNAG). Though we have changed the name, this new group should abide by the same rules and procedures generally applicable to Implementation Review Teams as set forth in existing GNSO Procedures". Why would that not solve the issue? [Anne] Effect on Existing GNSO Procedures and ICANN ByLaws. Once you apply a new name to this proposed new body designed specifically to address implementation issues post-launch, you have an animal that is not recognized in the Consensus Policy Implementation Framework nor in the GNSO Input, Guidance, and EPDP processes and is thus not incorporated into the language of those processes. Therefore, you will either have created a need for massive redrafting (including redrafting of the ICANN ByLaws) OR you will have removed that new body from the application of those processes. Jeff says there is no intention to change the applicability of the GNSO Input, Guidance, and EPDP process post-launch so it does not really make sense to name a new type of team that would require significant changes to existing procedures (and maybe even the ByLaws.) Thus, a "name change" for this body creates more questions than it answers. [Jeff] Applying the same language above would fix all of this. We are not modifying any existing process. [Anne] Prior Work of the Policy and Implementation WG. This has been a long-standing issue in Sub Pro since Leadership initially took the position that the GNSO Input, Guidance, and EPDP processes do not apply after launch. This is categorically not true. ​[Jeff] I know this has been your argument all along, but the documentation does not support your view. See https://www.icann.org/policy/implementation<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_policy_implementation&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=fGYI02A0z8Rt2vMHDzRZO89Z15edVRNF23fgudLvYDk&e=> and https://www.icann.org/uploads/ckeditor/CPIF_v2.0_2019CLEAN.pdf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_uploads_ckeditor_CPIF-5Fv2.0-5F2019CLEAN.pdf&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=uY4fujh1pLZJcb3MVAFVqis1l-Y_dtm637IAO4OPRrI&e=>. These all show that the IRT's work is prior to the Policy Effective Date. For the new gTLD process, that would be the day that the application window launches. I don't see anything that supports your view. [Anne] The Policy and Implementation Working Group examined numerous examples of issues that arose “post-launch” in the 2012 round. We ultimately concluded it is fruitless to try to characterize issues as either “policy” or “implementation” since one person’s policy is another’s implementation and vice versa. The mechanisms that were developed after the 2012 round to address these issues were specifically developed to apply WHENEVER the issue arise and to keep control of the issues at GNSO Council in a very transparent manner. It would be a massive change of policy to offer a new construct that either (1) causes the results of that PDP to have to be amended or (2) creates a new body that operates outside the established procedures already adopted by the Board and the GNSO. [Jeff] I dont disagree that distinguishing between policy and implementation is difficult. But this Predictability Framework does not change anything regarding transparency or any existing process. [Anne] If everyone is anxious to simply clarify the time period in which the Team will operate, why not just call the teams the “Pre-launch IRT” and the “Post-launch IRT”. Much simpler and more predictable – and requires a lot less redrafting. [Jeff] For the reasons above, I do not share the view that calling something a Pre-Launch or a Post Launch IRT will clear up the confusion or require much re-drafting. Lets see what others in the group think. Jeff Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive Suite 600, McLean VA 22102, USA M: +1.202.549.5079 D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> www.comlaude.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.comlaude.com_&d=DwMG...> [cid:image001.jpg@01D5003C.715F81E0] ________________________________ From: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> Sent: Tuesday, April 30, 2019 5:36 PM To: Julie Hedlund; gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Cc: Jeff Neuman Subject: RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 30 April 2019 Regarding yesterday's call and the attempt to measure consensus on the recommendation for a “Standing IRT”, changing the name of that recommended body actually creates more confusion rather than less. The reasons are: Initial Report and Public Comment. The Initial Report recommended a "Standing IRT". There is a common understanding in the ICANN community about what an IRT does, how it is constituted, and what its powers are and are not. The documentation in GNSO procedures lays out the rules re IRT, including the composition of such a team which requires broad representation across the community. These understandings are codified in the GNSO Council Operating Procedures and in the Consensus Policy Implementation Framework. If the proposed body is renamed, this would require additional public comment which would include the need to specify how such a body would be constituted and what is powers would be. Effect on Existing GNSO Procedures and ICANN ByLaws. Once you apply a new name to this proposed new body designed specifically to address implementation issues post-launch, you have an animal that is not recognized in the Consensus Policy Implementation Framework nor in the GNSO Input, Guidance, and EPDP processes and is thus not incorporated into the language of those processes. Therefore, you will either have created a need for massive redrafting (including redrafting of the ICANN ByLaws) OR you will have removed that new body from the application of those processes. Jeff says there is no intention to change the applicability of the GNSO Input, Guidance, and EPDP process post-launch so it does not really make sense to name a new type of team that would require significant changes to existing procedures (and maybe even the ByLaws.) Thus, a "name change" for this body creates more questions than it answers. Prior Work of the Policy and Implementation WG. This has been a long-standing issue in Sub Pro since Leadership initially took the position that the GNSO Input, Guidance, and EPDP processes do not apply after launch. This is categorically not true. The Policy and Implementation Working Group examined numerous examples of issues that arose “post-launch” in the 2012 round. We ultimately concluded it is fruitless to try to characterize issues as either “policy” or “implementation” since one person’s policy is another’s implementation and vice versa. The mechanisms that were developed after the 2012 round to address these issues were specifically developed to apply WHENEVER the issue arise and to keep control of the issues at GNSO Council in a very transparent manner. It would be a massive change of policy to offer a new construct that either (1) causes the results of that PDP to have to be amended or (2) creates a new body that operates outside the established procedures already adopted by the Board and the GNSO. If everyone is anxious to simply clarify the time period in which the Team will operate, why not just call the teams the “Pre-launch IRT” and the “Post-launch IRT”. Much simpler and more predictable – and requires a lot less redrafting. Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image002.png@01D5003C.715F81E0] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__lrrc.com_&d=DwMGaQ&c=MOp...> From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Julie Hedlund Sent: Tuesday, April 30, 2019 8:38 AM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 30 April 2019 [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting today, 30 April 2019. 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/2019-04-30+New+gTLD+Subsequent+Procedures+PDP<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_display_NGSPP_2019-2D04-2D30-2BNew-2BgTLD-2BSubsequent-2BProcedures-2BPDP&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=Kq9-Q1TqcXzyiOxZOdjPTNNzTi7qJEiptbSsIH4W9v4&e=>. Please also see the referenced document at: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-w/edit?usp=sharing<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-2Dw_edit-3Fusp-3Dsharing&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=iUz100Ji1JrIGzccYRbuxnvYKRWaET41282e2eHpY9Q&e=>. Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Action Items: -- Staff will check on the ICANN Board response to the GAC advice in the Helsinki Communique’ on new gTLDs. -- WG to come up with a different name for the “standing IRT”. Maybe “Post Application Advisory Team”. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review of Summary Documents – (see: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-w/edit?usp=sharing<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-2Dw_edit-3Fusp-3Dsharing&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=iUz100Ji1JrIGzccYRbuxnvYKRWaET41282e2eHpY9Q&e=>) 2.2.1 Continuing Subsequent Procedures Policy Goals / What the WG is Seeking to Accomplish -- First bullet: replace “rounds” with “procedures”. 2.2.1.c.1: The Working Group recommends no changes to the existing policy calling for subsequent application rounds introduced in an ongoing, orderly, timely and predictable manner. -- Support from most commenters New Ideas/Concepts for Deliberations: -- GAC Advice and BC: Support for new rounds but no rounds started until reviews (CCT-RT) are complete. Need to do a cost-benefit analysis before starting new round. -- WG is taking into consideration the CCT-RT recommendations. Discussion: -- Policy does not have a demand component. -- Action Item: Board response to GAC Advice in the Helskinki Communique’. -- Note that the CCT-RT did have an economic study done by the Analysis Group, although perhaps not a full cost-benefit analysis. -- Concerns with maintaining the current policy unless there are objections. -- Unless there is a consensus on changing precedent we should stay on the same path. -- Can build on what we have learned, but hard to do analysis on what people might want. -- If the WG wants to request for an assessment to be done that will have to be approved by the Council. -- Calling for rounds introduced in an ongoing orderly timely and predictable manner support came from pretty much every group that responded in public comments to the Initial Report. -- We have some qualifications from the GAC. 2.2.1.e.1: The 2007 Final Report noted that success metrics would be developed around the New gTLD Program. What are some specific metrics that the program should be measured against? -- Support from most commenters. New Ideas/Concepts for Deliberations: ALAC, BRG, BC, RySG – New Ideas Discussion: -- Good proposals for different types of metrics. -- Need to define what we mean by success; CCT-RT referred that issue to the SubPro WG. -- Questions and issues in the CCT-RT could put some of these issues to rest. -- This WG could come up with a half dozen categories (elements of the program) and develop definitions of success for those – or develop targets, which is a less loaded word. -- Good conversation to continue on email. -- You could have a high-level structure from the 2012 round (to foster diversity, encourage competition, and enhance the utility of the DNS), then create specific targets within that structure within that framework. 2.2.2 Predictability -- Support from most commenters -- BC/RySG/IPC/ALAC (in response to e.1): New Idea - The Standing IRT must be representative of the community, but must also allow for the appointment of experts where needed. New Ideas/Concepts for Deliberations -- ICANN Org: Concerns/New Ideas Discussion: -- Can things in the model be improved so that you can support it? If not, what takes its place? -- Don’t think it’s in our authority to replace the GNSO policy process. -- We're not changing any of the policies or processes that have been established. -- Changes to policies after the launch need to go through the GNSO policy process; the predictability framework is for issues that come up outside of that process and guidance to the standing IRT. In the report we called it a standing IRT, but that seems to be confusing so we should change the name. Could call it a “gateway” to decide what is policy and what is not, and only looking at non-policy issues. -- Need to be more conscious of the need for predictability for third party interests. We use the term “affected parties” for that reason. -- WG needs to come up with a different name for the “standing IRT”. Maybe a Post Application Advisory Team. ________________________________ 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.proofpoint.com/v2/url?u=https-3A__comlaude.com&d=DwMGaQ&c...> ________________________________ 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.proofpoint.com/v2/url?u=https-3A__comlaude.com&d=DwMGaQ&c...> ________________________________ 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