FW: Follow up from May 6th and CALL FOR SMALL GROUP
All, Following up on the call yesterday, we have revised the document on the Proposed New Predictability Model. You can find it here: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr.... The comments made during the call should be incorporated either as revised language itself, or as “comments” for draft language to be created. As we discussed, we would like to have a smaller group dedicated to working through the issues that remain on this topic so that a more comprehensive proposal can be presented to the full working group at a later date on the Predictability Framework. The group is open to any current Working Group members. However, if you join the small group, you are expected to put in some time to try and resolve whatever issues remain. The small group MAY have a call or two, but the hope is that all of the work can be done in e-mail and through the documents itself. We will create a mailing list to work on these issues. This is NOT a formal group. So far, I think we captured the following people to be on this group (from the call last night): Jeff Neuman Cheryl-Langdon Orr Kathy Kleiman Christopher Wilkinson Kristina Rosette There may have been others that already volunteered, but may not have captured, so please indicate your interest to us if you want to be a part of the smaller team. We will not be doing formal consensus calls as part of this smaller group, but rather just making the proposal better and filling in the holes to present to the full working group. Please let me know if you have any questions. Best regards, Jeffrey J. Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive , Suite 600 Mclean , VA 22102 UNITED STATES T: +1.703.635.7514 M: +1.202.549.5079 CONFIRMATION OF ORDERS: Please note that we always confirm receipt of orders. To assist us in identifying orders, please use the word ORDER in the subject line of your email. If you have sent us an order and have not received confirmation on the same working day (PST) it is possible that your order has not been received or has been trapped by our spam filter. In this case, please contact your client manager or admin@comlaude.com for confirmation that the order has been received and is being processed. Thank you. From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Julie Hedlund Sent: Monday, May 6, 2019 11:40 PM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 May 2019 Dear Working Group members, Please see below the notes from the meeting today, 06 May 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-05-06+New+gTLD+Subsequent+Pro.... Please also see the referenced documents at: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK.... Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Action Items: ACTION ITEM 1: Staff to incorporate edits as discussed into the 2.2.2 Predictability document. ACTION ITEM 2: Gather a small group to further develop the 2.2.2 Predictability document at: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr.... Jeff will send out a call for volunteers to the list. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson. Notes: 1. Updates to Statements of Interest (SOIs): No updates provided. 2. Review of Summary Documents – (see: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK...) a. Continued: 2.2.2 Predictability / 2.2.2.2 Clarity of Application Process: See: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr... -- Note: If we don’t come to consensus on a topic then the status quo will be as it was implemented in 2012. On the record that some do not support that approach. -- There are some different things relating to IRTs that could be new. 2.2.2 Predictability: -- Added bullet: The Predictability Model complements the existing GNSO processes and procedures and shall not in any way operate to be a substitute or replacement for those. In fact, they are incorporated into the Predictability Framework explicitly. Discussion: -- “they” references existing processes and procedures. -- To avoid any doubt in future we might want to add, “In the event of a conflict, existing GNSO processes and procedures take precedent.” -- Change from “shall not in any way operate to be” to “is not intended to be”. What are we proposing: B. Changes to ICANN Organization Internal Processes Discussion: -- Comfortable that we have a distinction for minor changes. -- For the first bullet under (b) -- re: “anything visible” -- what does that encompass? Add “change the application or any of the other processes set forth in the applicant guidebook”. Or “those parts of the application that are scored”? -- Third bullet -- New processes: Some examples have direct relevance for the entire community. Such as a new public comment platform. -- Standing IRT decides what is implementation or policy -- but some WG members disagree. -- Change to “Material adverse impact”? -- Second bullet -- “all non-minor changes” -- in written policy? Answer: The output of this whole thing will eventually be the AGB and if there are changes to the AGB they would be written. -- So not a reasonable response that a process will just take longer -- just being a communication. Seems like there should be more accountability. Add a comment/note to see if that falls under a different category. -- Filter out those things that can be dealt with in a practical matter. -- Third bullet: Need a gateway process before we get to these items. Wherever something affects the underlying rules has huge implications. -- Might need to clarify: “New public comment platform” means changes to the tools being used to submit. The rules for commenting is the same, but the platform is different. -- Second bullet: Not meant to be a change in the timing, but a change in a portal. -- Add a line after bullet three, “These proposed changes are intended to be only those that involve mechanisms with no substantive impact.” Question: How is that different from this text, “but rather a New ICANN Organization Internal Process and it is likely to have a materially [adverse] impact on applicants or community members…” Seems similar in meaning. -- An example of a change that wouldn’t be substantive but could have a material adverse impact would be requiring that Legal Rights Objections be filed through a proprietary platform instead of email. Wouldn't affect the substantive LRO (elements, standing, etc), but there may be some potential objectors that, for one reason or another, can't use that platform. -- Are timelines on filing objections seen as a different type of timeline as a third-party timeline? -- What might be a minor change for one party could be a major change to others. Adverse outcomes -- for whom? Should there be a policy gateway to determine? We don’t have a framework that would be considered to be predictable. -- If there is a gateway then that could delay any changes. -- Overriding principle is predictability. Trying to improve predictability from the last round. C. Fundamental Possible Policy Level Changes Discussion: -- Some examples seem to be out of scope for an IRT. -- Deciding something that is policy: a standing IRT can raise that issue and the GNSO Liaison can take that back to the Council. Any Council member also can raise something for consideration at the Council level. -- So a standing IRT can raise something, but only the Council can decide what is policy or implementation, but it sounds like we are setting up a separate gateway. The standing IRT cannot be the final arbiter, and the Council also can raise it directly. -- Add to the bullet point that the standing IRT can make a recommendation to the GNSO Council as to whether something is policy or implementation, but the GNSO will make the final decision. -- Ensure that this document is cross-referenced to the current policies and processes for IRTs. -- What do we mean by “Staff will collaborate with the community”? Answer: That is meant to first go to the standing IRT, which makes a recommendation for additional consideration, and then the GNSO decides how to handle it -- GNSO Input Process, EPDP, etc. -- Delete this text, “Staff will collaborate with the community to consider the issue and agree upon the mechanism by which the solution will be developed. Options could include:” And emphasize the point that this is meant to be a community+staff decision, not just staff. Mark them as redlined and to be replaced. Come back to this in another WG meeting. -- Helpful to have a workflow diagram for the Predictability Framework once concepts are agreed and reconcile with existing ones from IRT Guidelines. D. Fundamental Possible Policy Level New Proposals Discussion: -- Carry over changes from bullets under C. -- Reaching out to the community means staff reaching out to the standing IRT. But don’t think the standing IRT has the authority to decide if something is a policy or implementation change. Could have a new group that includes members of the IRT, and also Council members, and then decide if it goes to the standing IRT. -- Want to change what we call this because of previous problems with IRTs. Want to get the composition right so it is representative of the community. Meant to ensure that it is a gateway. -- A number of groups supported the recommendations in the Initial Report but also some dissenting views: ACTION: Form a smaller group to further develop this document for the full WG. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson. ________________________________ 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>
Dear WG members: Regarding the smaller group assembled to work on how staff and the proposed “post-launch Standing IRT” might determine whether an issue is policy or implementation, I would like to clarify again the history that led to the existing GNSO processes designed to address these issues whenever they arise –either Pre- or –Post launch: The Policy & Implementation Working Group grappled with this question of policy versus implementation for many months and concluded it was impossible to make determinations about that in advance because “one person’s policy is another person’s implementation”. That is exactly why we have the result we have in the form of GNSO Input (which is essentially for implementation issues), GNSO Guidance, and GNSO EPDP. In fact, it was Marika Koenigs who first suggested to the Policy & Implementation WG that, based on our case studies of issues that arose in the 2012 round, it was impossible to “predict” issues that might arise and label them as clearly policy or clearly implementation. Jeff has pointed out that applicants want more “predictability” in the process so that time delays do not result. Thus, the proposed “Predictability Framework” anticipates that ICANN staff and/or or some newly created body will be able to decide issues that arise post-launch. The “problem” Jeff is trying to resolve as Co-Chair is that if an issue reaches the GNSO, it may take too long to resolve and thus is not practical for registry applicants. However, as far as I know, we have not yet tried out these new processes (except for the EPDP on the Temp Spec) so it seems to me a bit premature to be inventing new processes and acronyms on top of the ones that have not yet been tried. It strikes me that for various Implementation issues that actually rise to the level of an issue post-launch, the existing GNSO Input process (which has not yet been used) is adequate and is in fact designed to operate in that fashion since GNSO can raise such a concern “at any time it deems appropriate”. Under existing GNSO processes established as a result of the work of the Policy & Implementation Working Group, the “gateway” is in fact a question of the interaction between and among Staff, an IRT (or Post-launch Standing IRT), and the GNSO Council. Staff can raise an issue, IRT can raise an issue, and ANY GNSO Council member can raise an issue and so these are the “gates”. (In other words, there are multiple gates and they all ultimately lead to oversight by GNSO Council.) My own view (having worked actively in the Policy & Implementation Working Group on several case studies of issues that arose Post-Launch in the 2012 round) is that if an issue is truly implementation, no one is going to raise the issue to the level of GNSO. Issues will only rise to that level if a stakeholder believes that GNSO Council should address it and that applies whether it’s merely implementation (“GNSO Input” Annex) or involves policy (“GNSO Guidance” Annex or “GNSO EPDP” Annex). Before the Sub Pro Initial Report issued, the Co-Chairs and staff ultimately agreed to make reference to the GNSO Input, Guidance, and EPDP processes but those processes were only referenced and footnoted, not actually explained to the ICANN community or the public. Importantly, the draft Initial Report language was clarified to delete the reference to the Standing IRT “deciding” an issue based on the Predictability Framework. Instead, in the Initial Report, there is a reference to the Standing IRT being able to “recommend” a resolution of the issue. In terms of ICANN governance and the ByLaws as modified after the Policy & Implementation WG finished its work, that is the correct stance. Establishing some other “gate” or some method for determining in advance what is policy and what is implementation when the existing processes adopted after a full WG process have not been tried does not make sense to me. By way of additional background, the whole Policy & Implementation Working Group evolved from the fact that then-CEO Fadi Chehade decided that the “Strawman Solution” in relation to trademarks was implementation, not policy. Fadi issued a public statement to this effect. GNSO Council members were upset about this and our Co-Chair Jeff Neuman wrote the letter to the ICANN Board stating that if the Board took action (such as the Strawman Solution) that amounted to a change in policy, they had to come back to GNSO for its views on the topic and more specifically, to make a determination as to whether the topic required more policy work or merely some GNSO input. Clearly the timing as to when an issue arises (either pre- or post- launch) is NOT a determiner of whether it is Policy or Implementation. So Chuck Gomes led the P & I WG as a result of the GNSO Council’s dissatisfaction with the handling of that issue (and others) that arose Post-Launch and we spent more than year (probably about 2 years) reviewing numerous issues that arose after applications were filed in the 2012 round. That is why the GNSO processes called Input, Guidance and EPDP were adopted by the GNSO Council and that is why the ICANN ByLaws were amended. Hopefully the above history helps to clarify why I was quoting existing GNSO Operating Procedures and Annexes. Again, I don’t think the public understood these processes when the Initial Report issued. The current Consensus Policy Implementation Framework (“CPIF”) of the GNSO makes specific reference to these processes and requires that IRT members be briefed on them. Anne From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Jeff Neuman Sent: Tuesday, May 7, 2019 1:57 AM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] FW: Follow up from May 6th and CALL FOR SMALL GROUP [EXTERNAL] ________________________________ All, Following up on the call yesterday, we have revised the document on the Proposed New Predictability Model. You can find it here: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr.... The comments made during the call should be incorporated either as revised language itself, or as “comments” for draft language to be created. As we discussed, we would like to have a smaller group dedicated to working through the issues that remain on this topic so that a more comprehensive proposal can be presented to the full working group at a later date on the Predictability Framework. The group is open to any current Working Group members. However, if you join the small group, you are expected to put in some time to try and resolve whatever issues remain. The small group MAY have a call or two, but the hope is that all of the work can be done in e-mail and through the documents itself. We will create a mailing list to work on these issues. This is NOT a formal group. So far, I think we captured the following people to be on this group (from the call last night): Jeff Neuman Cheryl-Langdon Orr Kathy Kleiman Christopher Wilkinson Kristina Rosette There may have been others that already volunteered, but may not have captured, so please indicate your interest to us if you want to be a part of the smaller team. We will not be doing formal consensus calls as part of this smaller group, but rather just making the proposal better and filling in the holes to present to the full working group. Please let me know if you have any questions. Best regards, Jeffrey J. Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive , Suite 600 Mclean , VA 22102 UNITED STATES T: +1.703.635.7514 M: +1.202.549.5079 CONFIRMATION OF ORDERS: Please note that we always confirm receipt of orders. To assist us in identifying orders, please use the word ORDER in the subject line of your email. If you have sent us an order and have not received confirmation on the same working day (PST) it is possible that your order has not been received or has been trapped by our spam filter. In this case, please contact your client manager or admin@comlaude.com<mailto:admin@comlaude.com> for confirmation that the order has been received and is being processed. Thank you. From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Julie Hedlund Sent: Monday, May 6, 2019 11:40 PM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 May 2019 Dear Working Group members, Please see below the notes from the meeting today, 06 May 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-05-06+New+gTLD+Subsequent+Pro.... Please also see the referenced documents at: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK.... Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Action Items: ACTION ITEM 1: Staff to incorporate edits as discussed into the 2.2.2 Predictability document. ACTION ITEM 2: Gather a small group to further develop the 2.2.2 Predictability document at: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr.... Jeff will send out a call for volunteers to the list. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson. Notes: 1. Updates to Statements of Interest (SOIs): No updates provided. 2. Review of Summary Documents – (see: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK...) a. Continued: 2.2.2 Predictability / 2.2.2.2 Clarity of Application Process: See: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr... -- Note: If we don’t come to consensus on a topic then the status quo will be as it was implemented in 2012. On the record that some do not support that approach. -- There are some different things relating to IRTs that could be new. 2.2.2 Predictability: -- Added bullet: The Predictability Model complements the existing GNSO processes and procedures and shall not in any way operate to be a substitute or replacement for those. In fact, they are incorporated into the Predictability Framework explicitly. Discussion: -- “they” references existing processes and procedures. -- To avoid any doubt in future we might want to add, “In the event of a conflict, existing GNSO processes and procedures take precedent.” -- Change from “shall not in any way operate to be” to “is not intended to be”. What are we proposing: B. Changes to ICANN Organization Internal Processes Discussion: -- Comfortable that we have a distinction for minor changes. -- For the first bullet under (b) -- re: “anything visible” -- what does that encompass? Add “change the application or any of the other processes set forth in the applicant guidebook”. Or “those parts of the application that are scored”? -- Third bullet -- New processes: Some examples have direct relevance for the entire community. Such as a new public comment platform. -- Standing IRT decides what is implementation or policy -- but some WG members disagree. -- Change to “Material adverse impact”? -- Second bullet -- “all non-minor changes” -- in written policy? Answer: The output of this whole thing will eventually be the AGB and if there are changes to the AGB they would be written. -- So not a reasonable response that a process will just take longer -- just being a communication. Seems like there should be more accountability. Add a comment/note to see if that falls under a different category. -- Filter out those things that can be dealt with in a practical matter. -- Third bullet: Need a gateway process before we get to these items. Wherever something affects the underlying rules has huge implications. -- Might need to clarify: “New public comment platform” means changes to the tools being used to submit. The rules for commenting is the same, but the platform is different. -- Second bullet: Not meant to be a change in the timing, but a change in a portal. -- Add a line after bullet three, “These proposed changes are intended to be only those that involve mechanisms with no substantive impact.” Question: How is that different from this text, “but rather a New ICANN Organization Internal Process and it is likely to have a materially [adverse] impact on applicants or community members…” Seems similar in meaning. -- An example of a change that wouldn’t be substantive but could have a material adverse impact would be requiring that Legal Rights Objections be filed through a proprietary platform instead of email. Wouldn't affect the substantive LRO (elements, standing, etc), but there may be some potential objectors that, for one reason or another, can't use that platform. -- Are timelines on filing objections seen as a different type of timeline as a third-party timeline? -- What might be a minor change for one party could be a major change to others. Adverse outcomes -- for whom? Should there be a policy gateway to determine? We don’t have a framework that would be considered to be predictable. -- If there is a gateway then that could delay any changes. -- Overriding principle is predictability. Trying to improve predictability from the last round. C. Fundamental Possible Policy Level Changes Discussion: -- Some examples seem to be out of scope for an IRT. -- Deciding something that is policy: a standing IRT can raise that issue and the GNSO Liaison can take that back to the Council. Any Council member also can raise something for consideration at the Council level. -- So a standing IRT can raise something, but only the Council can decide what is policy or implementation, but it sounds like we are setting up a separate gateway. The standing IRT cannot be the final arbiter, and the Council also can raise it directly. -- Add to the bullet point that the standing IRT can make a recommendation to the GNSO Council as to whether something is policy or implementation, but the GNSO will make the final decision. -- Ensure that this document is cross-referenced to the current policies and processes for IRTs. -- What do we mean by “Staff will collaborate with the community”? Answer: That is meant to first go to the standing IRT, which makes a recommendation for additional consideration, and then the GNSO decides how to handle it -- GNSO Input Process, EPDP, etc. -- Delete this text, “Staff will collaborate with the community to consider the issue and agree upon the mechanism by which the solution will be developed. Options could include:” And emphasize the point that this is meant to be a community+staff decision, not just staff. Mark them as redlined and to be replaced. Come back to this in another WG meeting. -- Helpful to have a workflow diagram for the Predictability Framework once concepts are agreed and reconcile with existing ones from IRT Guidelines. D. Fundamental Possible Policy Level New Proposals Discussion: -- Carry over changes from bullets under C. -- Reaching out to the community means staff reaching out to the standing IRT. But don’t think the standing IRT has the authority to decide if something is a policy or implementation change. Could have a new group that includes members of the IRT, and also Council members, and then decide if it goes to the standing IRT. -- Want to change what we call this because of previous problems with IRTs. Want to get the composition right so it is representative of the community. Meant to ensure that it is a gateway. -- A number of groups supported the recommendations in the Initial Report but also some dissenting views: ACTION: Form a smaller group to further develop this document for the full WG. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson. ________________________________ 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.
Good afternoon : In the question of the Implementation Review Teams (IRT's) by any other name, I come to this rather unexpectedly. So, before joining the 'SMALL GROUP' established by the PDP Call on 6 May, I would wish to just summarize and explain what I said during that call. 1. Predictability : It is a primary röle for the PDP to establish rules and procedures which give rise to predictability for all parties concerned. At present the PDP and the work Tracks, (particularly WT5) are far from creating a predictability framewlork. This is primarily because some participants express a tangible reluctance to accept rules and procedures that would be predictable for third parties. Thus, the primary responsibility of the PDP is to fix the predictability issues including those that have not been resolved at the Work Track level. Meanwhile,. It is not appropriate to charge IRTs with 'interlpreting' the consequences of unresolved policy issues. 2. Implementation vs. Policy : This risques becoming a false distinction. What is a minor issue for some could be a major issue for others. Specifically the resolution of a minor issue for one application could become a precedent for other applications. Any eventual IRT would inevitably be 'looking over its shoulder' to see what would be the consequences elsewhere i.e. Policy. Third Parties : The expansion of the DNS inevitably impinges on the interests of parties that are neither contdracted pardtdies, nor applicatns. To ignore this would absolutely guarantee a lack of predictability both for the applicants and for third parties concerned. There is a discontinuity between the presuppositions in the PDP andl the GNSO as to how matters should proceed, and the natural assumptions of concerned third lparties which are « Write to the Board » or « Write to the GAC member ». Thus considerably reducing the scope for eventual IRTs to handle questions that will rapidly go beyond their control, particularly it becomes a matter of Policy. 4. The 'Standing IRT?' Should it become necessary to create an entity 'between' the AGB process and the Staff on the one hand, and the GNSO and the Board on the other hand, we would be creating an entity with significant power. If so, it must be enhanced with full transparency, independence and accountability to the Community, that is to all Stakeholders, By dealing with unforeseen issues affecting applicants and third parties, the entity will inevitably create policy by precedent, if not by its intended decisions. 5. In Conclusion: I come back to the first point that is that the PDP and WT5 need to do a lot more concrete work to create predictability. With regard to third party interests, a lack of predictability will undermine predictability for applicants; unresolved issues will simply escalate and create delays and uncertainties. As before. Let us bear in mind that in future 'rounds' most applicants may not benefit from experience from 2012, nor from inside knowledge of the PDP and Work Tracks. An 'IRT' would not be able to resolve lacunae arising from the PDP itself. Regards Christopher Wilkinson Xàbia, 8 May 2019Good evening :
On 7 May 2019, at 22:05, Aikman-Scalese, Anne <AAikman@lrrc.com <mailto:AAikman@lrrc.com>> wrote:
Dear WG members: Regarding the smaller group assembled to work on how staff and the proposed “post-launch Standing IRT” might determine whether an issue is policy or implementation, I would like to clarify again the history that led to the existing GNSO processes designed to address these issues whenever they arise –either Pre- or –Post launch:
The Policy & Implementation Working Group grappled with this question of policy versus implementation for many months and concluded it was impossible to make determinations about that in advance because “one person’s policy is another person’s implementation”. That is exactly why we have the result we have in the form of GNSO Input (which is essentially for implementation issues), GNSO Guidance, and GNSO EPDP. In fact, it was Marika Koenigs who first suggested to the Policy & Implementation WG that, based on our case studies of issues that arose in the 2012 round, it was impossible to “predict” issues that might arise and label them as clearly policy or clearly implementation. Jeff has pointed out that applicants want more “predictability” in the process so that time delays do not result. Thus, the proposed “Predictability Framework” anticipates that ICANN staff and/or or some newly created body will be able to decide issues that arise post-launch. The “problem” Jeff is trying to resolve as Co-Chair is that if an issue reaches the GNSO, it may take too long to resolve and thus is not practical for registry applicants. However, as far as I know, we have not yet tried out these new processes (except for the EPDP on the Temp Spec) so it seems to me a bit premature to be inventing new processes and acronyms on top of the ones that have not yet been tried. It strikes me that for various Implementation issues that actually rise to the level of an issue post-launch, the existing GNSO Input process (which has not yet been used) is adequate and is in fact designed to operate in that fashion since GNSO can raise such a concern “at any time it deems appropriate”.
Under existing GNSO processes established as a result of the work of the Policy & Implementation Working Group, the “gateway” is in fact a question of the interaction between and among Staff, an IRT (or Post-launch Standing IRT), and the GNSO Council. Staff can raise an issue, IRT can raise an issue, and ANY GNSO Council member can raise an issue and so these are the “gates”. (In other words, there are multiple gates and they all ultimately lead to oversight by GNSO Council.) My own view (having worked actively in the Policy & Implementation Working Group on several case studies of issues that arose Post-Launch in the 2012 round) is that if an issue is truly implementation, no one is going to raise the issue to the level of GNSO. Issues will only rise to that level if a stakeholder believes that GNSO Council should address it and that applies whether it’s merely implementation (“GNSO Input” Annex) or involves policy (“GNSO Guidance” Annex or “GNSO EPDP” Annex).
Before the Sub Pro Initial Report issued, the Co-Chairs and staff ultimately agreed to make reference to the GNSO Input, Guidance, and EPDP processes but those processes were only referenced and footnoted, not actually explained to the ICANN community or the public. Importantly, the draft Initial Report language was clarified to delete the reference to the Standing IRT “deciding” an issue based on the Predictability Framework. Instead, in the Initial Report, there is a reference to the Standing IRT being able to “recommend” a resolution of the issue. In terms of ICANN governance and the ByLaws as modified after the Policy & Implementation WG finished its work, that is the correct stance. Establishing some other “gate” or some method for determining in advance what is policy and what is implementation when the existing processes adopted after a full WG process have not been tried does not make sense to me.
By way of additional background, the whole Policy & Implementation Working Group evolved from the fact that then-CEO Fadi Chehade decided that the “Strawman Solution” in relation to trademarks was implementation, not policy. Fadi issued a public statement to this effect. GNSO Council members were upset about this and our Co-Chair Jeff Neuman wrote the letter to the ICANN Board stating that if the Board took action (such as the Strawman Solution) that amounted to a change in policy, they had to come back to GNSO for its views on the topic and more specifically, to make a determination as to whether the topic required more policy work or merely some GNSO input.
Clearly the timing as to when an issue arises (either pre- or post- launch) is NOT a determiner of whether it is Policy or Implementation. So Chuck Gomes led the P & I WG as a result of the GNSO Council’s dissatisfaction with the handling of that issue (and others) that arose Post-Launch and we spent more than year (probably about 2 years) reviewing numerous issues that arose after applications were filed in the 2012 round. That is why the GNSO processes called Input, Guidance and EPDP were adopted by the GNSO Council and that is why the ICANN ByLaws were amended.
Hopefully the above history helps to clarify why I was quoting existing GNSO Operating Procedures and Annexes. Again, I don’t think the public understood these processes when the Initial Report issued. The current Consensus Policy Implementation Framework (“CPIF”) of the GNSO makes specific reference to these processes and requires that IRT members be briefed on them. Anne
<> From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org <mailto:gnso-newgtld-wg-bounces@icann.org>] On Behalf Of Jeff Neuman Sent: Tuesday, May 7, 2019 1:57 AM To: gnso-newgtld-wg@icann.org <mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] FW: Follow up from May 6th and CALL FOR SMALL GROUP
[EXTERNAL] All,
Following up on the call yesterday, we have revised the document on the Proposed New Predictability Model. You can find it here: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr... <https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr...>. The comments made during the call should be incorporated either as revised language itself, or as “comments” for draft language to be created.
As we discussed, we would like to have a smaller group dedicated to working through the issues that remain on this topic so that a more comprehensive proposal can be presented to the full working group at a later date on the Predictability Framework. The group is open to any current Working Group members. However, if you join the small group, you are expected to put in some time to try and resolve whatever issues remain. The small group MAY have a call or two, but the hope is that all of the work can be done in e-mail and through the documents itself. We will create a mailing list to work on these issues. This is NOT a formal group.
So far, I think we captured the following people to be on this group (from the call last night):
Jeff Neuman Cheryl-Langdon Orr Kathy Kleiman Christopher Wilkinson Kristina Rosette
There may have been others that already volunteered, but may not have captured, so please indicate your interest to us if you want to be a part of the smaller team.
We will not be doing formal consensus calls as part of this smaller group, but rather just making the proposal better and filling in the holes to present to the full working group.
Please let me know if you have any questions.
Best regards,
Jeffrey J. Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive , Suite 600 Mclean , VA 22102 UNITED STATES T: +1.703.635.7514 M: +1.202.549.5079
CONFIRMATION OF ORDERS: Please note that we always confirm receipt of orders. To assist us in identifying orders, please use the word ORDER in the subject line of your email. If you have sent us an order and have not received confirmation on the same working day (PST) it is possible that your order has not been received or has been trapped by our spam filter. In this case, please contact your client manager or admin@comlaude.com <mailto:admin@comlaude.com> for confirmation that the order has been received and is being processed. Thank you.
From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org <mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Julie Hedlund Sent: Monday, May 6, 2019 11:40 PM To: gnso-newgtld-wg@icann.org <mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 May 2019
Dear Working Group members,
Please see below the notes from the meeting today, 06 May 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-05-06+New+gTLD+Subsequent+Pro... <https://community.icann.org/display/NGSPP/2019-05-06+New+gTLD+Subsequent+Pro...>.
Please also see the referenced documents at: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK... <https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK...>.
Kind regards, Julie Julie Hedlund, Policy Director
Notes and Action Items:
Action Items:
ACTION ITEM 1: Staff to incorporate edits as discussed into the 2.2.2 Predictability document. ACTION ITEM 2: Gather a small group to further develop the 2.2.2 Predictability document at:https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr... <https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr...>. Jeff will send out a call for volunteers to the list. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson.
Notes:
1. Updates to Statements of Interest (SOIs): No updates provided.
2. Review of Summary Documents – (see: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK... <https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK...>)
a. Continued: 2.2.2 Predictability / 2.2.2.2 Clarity of Application Process: See:https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr... <https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr...>
-- Note: If we don’t come to consensus on a topic then the status quo will be as it was implemented in 2012. On the record that some do not support that approach. -- There are some different things relating to IRTs that could be new.
2.2.2 Predictability: -- Added bullet: The Predictability Model complements the existing GNSO processes and procedures and shall not in any way operate to be a substitute or replacement for those. In fact, they are incorporated into the Predictability Framework explicitly.
Discussion: -- “they” references existing processes and procedures. -- To avoid any doubt in future we might want to add, “In the event of a conflict, existing GNSO processes and procedures take precedent.” -- Change from “shall not in any way operate to be” to “is not intended to be”.
What are we proposing:
B. Changes to ICANN Organization Internal Processes
Discussion: -- Comfortable that we have a distinction for minor changes. -- For the first bullet under (b) -- re: “anything visible” -- what does that encompass? Add “change the application or any of the other processes set forth in the applicant guidebook”. Or “those parts of the application that are scored”? -- Third bullet -- New processes: Some examples have direct relevance for the entire community. Such as a new public comment platform. -- Standing IRT decides what is implementation or policy -- but some WG members disagree. -- Change to “Material adverse impact”? -- Second bullet -- “all non-minor changes” -- in written policy? Answer: The output of this whole thing will eventually be the AGB and if there are changes to the AGB they would be written. -- So not a reasonable response that a process will just take longer -- just being a communication. Seems like there should be more accountability. Add a comment/note to see if that falls under a different category. -- Filter out those things that can be dealt with in a practical matter. -- Third bullet: Need a gateway process before we get to these items. Wherever something affects the underlying rules has huge implications. -- Might need to clarify: “New public comment platform” means changes to the tools being used to submit. The rules for commenting is the same, but the platform is different. -- Second bullet: Not meant to be a change in the timing, but a change in a portal. -- Add a line after bullet three, “These proposed changes are intended to be only those that involve mechanisms with no substantive impact.” Question: How is that different from this text, “but rather a New ICANN Organization Internal Process and it is likely to have a materially [adverse] impact on applicants or community members…” Seems similar in meaning. -- An example of a change that wouldn’t be substantive but could have a material adverse impact would be requiring that Legal Rights Objections be filed through a proprietary platform instead of email. Wouldn't affect the substantive LRO (elements, standing, etc), but there may be some potential objectors that, for one reason or another, can't use that platform. -- Are timelines on filing objections seen as a different type of timeline as a third-party timeline? -- What might be a minor change for one party could be a major change to others. Adverse outcomes -- for whom? Should there be a policy gateway to determine? We don’t have a framework that would be considered to be predictable. -- If there is a gateway then that could delay any changes. -- Overriding principle is predictability. Trying to improve predictability from the last round.
C. Fundamental Possible Policy Level Changes
Discussion: -- Some examples seem to be out of scope for an IRT. -- Deciding something that is policy: a standing IRT can raise that issue and the GNSO Liaison can take that back to the Council. Any Council member also can raise something for consideration at the Council level. -- So a standing IRT can raise something, but only the Council can decide what is policy or implementation, but it sounds like we are setting up a separate gateway. The standing IRT cannot be the final arbiter, and the Council also can raise it directly. -- Add to the bullet point that the standing IRT can make a recommendation to the GNSO Council as to whether something is policy or implementation, but the GNSO will make the final decision. -- Ensure that this document is cross-referenced to the current policies and processes for IRTs. -- What do we mean by “Staff will collaborate with the community”? Answer: That is meant to first go to the standing IRT, which makes a recommendation for additional consideration, and then the GNSO decides how to handle it -- GNSO Input Process, EPDP, etc. -- Delete this text, “Staff will collaborate with the community to consider the issue and agree upon the mechanism by which the solution will be developed. Options could include:” And emphasize the point that this is meant to be a community+staff decision, not just staff. Mark them as redlined and to be replaced. Come back to this in another WG meeting. -- Helpful to have a workflow diagram for the Predictability Framework once concepts are agreed and reconcile with existing ones from IRT Guidelines.
D. Fundamental Possible Policy Level New Proposals
Discussion: -- Carry over changes from bullets under C. -- Reaching out to the community means staff reaching out to the standing IRT. But don’t think the standing IRT has the authority to decide if something is a policy or implementation change. Could have a new group that includes members of the IRT, and also Council members, and then decide if it goes to the standing IRT. -- Want to change what we call this because of previous problems with IRTs. Want to get the composition right so it is representative of the community. Meant to ensure that it is a gateway. -- A number of groups supported the recommendations in the Initial Report but also some dissenting views: ACTION: Form a smaller group to further develop this document for the full WG. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson.
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 seewww.comlaude.com <https://comlaude.com/>
This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521. _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org <mailto:Gnso-newgtld-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg <https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg>
Hi Christopher, Implementation Review Teams (IRTs) already exist and are accountable to GNSO Council. That is the current organizational structure for implementation of new gTLD policy. The guidelines for operation of an IRT and representative nature of an IRT can be found here so I suggest the small group maintain all of these guidelines when discussing any possible additional duties/ powers of the “Standing IRT”: IRT Principles and Guidelines: https://gnso.icann.org/sites/default/files/file/field-file-attach/2016-12/ir... I support the Standing IRT provided it is subject to all the same guidelines and the formal GNSO processes which were developed to deal with policy and implementation issues after the 2012 round. If the Predictability Framework is merely a tool that assists the Standing IRT in analyzing issues and does not stop anyone from raising an issue with GNSO and having it determined there, then that would make sense. I think the current draft provides that the GNSO processes override anything that is developed in the “Prediciability Framework” as to what constitutes “policy” and what constitutes “implementation”. In the ICANN structure, the ultimate determination of that question resides in the GNSO. (GAC can separately advise as to “public policy” and if it is “GAC Consensus Policy” and if there is a conflict between the two sets of policy advice, then you get a tough situation where the Board has to decide what to do and that often results in paralysis. ByLaws provide Board must have 2/3 vote to override a GNSO Policy recommendation and also provide Board must have 60% of Directors to vote against a GAC Consensus Public Policy advice. So no wonder the Board goes back to the community to say – can you please work this out? And that is what we can all expect but Jeff and Cheryl are just trying to get the Final Report done because history shows that trying to work things out prior to delivering a Final Report just does not work. Anne From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of lists@christopherwilkinson.eu Sent: Wednesday, May 8, 2019 5:59 AM To: gnso-newgtld-wg@icann.org Cc: ntfy-gnso-newgtld-wg-wt5@icann.org Subject: [Gnso-newgtld-wg] 'IRTs' - Regarding the 'smaller group Re: FW: Follow up from May 6th and CALL FOR SMALL GROUP [EXTERNAL] ________________________________ Good afternoon : In the question of the Implementation Review Teams (IRT's) by any other name, I come to this rather unexpectedly. So, before joining the 'SMALL GROUP' established by the PDP Call on 6 May, I would wish to just summarize and explain what I said during that call. 1. Predictability : It is a primary röle for the PDP to establish rules and procedures which give rise to predictability for all parties concerned. At present the PDP and the work Tracks, (particularly WT5) are far from creating a predictability framewlork. This is primarily because some participants express a tangible reluctance to accept rules and procedures that would be predictable for third parties. Thus, the primary responsibility of the PDP is to fix the predictability issues including those that have not been resolved at the Work Track level. Meanwhile,. It is not appropriate to charge IRTs with 'interlpreting' the consequences of unresolved policy issues. 2. Implementation vs. Policy : This risques becoming a false distinction. What is a minor issue for some could be a major issue for others. Specifically the resolution of a minor issue for one application could become a precedent for other applications. Any eventual IRT would inevitably be 'looking over its shoulder' to see what would be the consequences elsewhere i.e. Policy. 1. Third Parties : The expansion of the DNS inevitably impinges on the interests of parties that are neither contdracted pardtdies, nor applicatns. To ignore this would absolutely guarantee a lack of predictability both for the applicants and for third parties concerned. There is a discontinuity between the presuppositions in the PDP andl the GNSO as to how matters should proceed, and the natural assumptions of concerned third lparties which are « Write to the Board » or « Write to the GAC member ». Thus considerably reducing the scope for eventual IRTs to handle questions that will rapidly go beyond their control, particularly it becomes a matter of Policy. 4. The 'Standing IRT?' Should it become necessary to create an entity 'between' the AGB process and the Staff on the one hand, and the GNSO and the Board on the other hand, we would be creating an entity with significant power. If so, it must be enhanced with full transparency, independence and accountability to the Community, that is to all Stakeholders, By dealing with unforeseen issues affecting applicants and third parties, the entity will inevitably create policy by precedent, if not by its intended decisions. 5. In Conclusion: I come back to the first point that is that the PDP and WT5 need to do a lot more concrete work to create predictability. With regard to third party interests, a lack of predictability will undermine predictability for applicants; unresolved issues will simply escalate and create delays and uncertainties. As before. Let us bear in mind that in future 'rounds' most applicants may not benefit from experience from 2012, nor from inside knowledge of the PDP and Work Tracks. An 'IRT' would not be able to resolve lacunae arising from the PDP itself. Regards Christopher Wilkinson Xàbia, 8 May 2019Good evening : On 7 May 2019, at 22:05, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> wrote: Dear WG members: Regarding the smaller group assembled to work on how staff and the proposed “post-launch Standing IRT” might determine whether an issue is policy or implementation, I would like to clarify again the history that led to the existing GNSO processes designed to address these issues whenever they arise –either Pre- or –Post launch: The Policy & Implementation Working Group grappled with this question of policy versus implementation for many months and concluded it was impossible to make determinations about that in advance because “one person’s policy is another person’s implementation”. That is exactly why we have the result we have in the form of GNSO Input (which is essentially for implementation issues), GNSO Guidance, and GNSO EPDP. In fact, it was Marika Koenigs who first suggested to the Policy & Implementation WG that, based on our case studies of issues that arose in the 2012 round, it was impossible to “predict” issues that might arise and label them as clearly policy or clearly implementation. Jeff has pointed out that applicants want more “predictability” in the process so that time delays do not result. Thus, the proposed “Predictability Framework” anticipates that ICANN staff and/or or some newly created body will be able to decide issues that arise post-launch. The “problem” Jeff is trying to resolve as Co-Chair is that if an issue reaches the GNSO, it may take too long to resolve and thus is not practical for registry applicants. However, as far as I know, we have not yet tried out these new processes (except for the EPDP on the Temp Spec) so it seems to me a bit premature to be inventing new processes and acronyms on top of the ones that have not yet been tried. It strikes me that for various Implementation issues that actually rise to the level of an issue post-launch, the existing GNSO Input process (which has not yet been used) is adequate and is in fact designed to operate in that fashion since GNSO can raise such a concern “at any time it deems appropriate”. Under existing GNSO processes established as a result of the work of the Policy & Implementation Working Group, the “gateway” is in fact a question of the interaction between and among Staff, an IRT (or Post-launch Standing IRT), and the GNSO Council. Staff can raise an issue, IRT can raise an issue, and ANY GNSO Council member can raise an issue and so these are the “gates”. (In other words, there are multiple gates and they all ultimately lead to oversight by GNSO Council.) My own view (having worked actively in the Policy & Implementation Working Group on several case studies of issues that arose Post-Launch in the 2012 round) is that if an issue is truly implementation, no one is going to raise the issue to the level of GNSO. Issues will only rise to that level if a stakeholder believes that GNSO Council should address it and that applies whether it’s merely implementation (“GNSO Input” Annex) or involves policy (“GNSO Guidance” Annex or “GNSO EPDP” Annex). Before the Sub Pro Initial Report issued, the Co-Chairs and staff ultimately agreed to make reference to the GNSO Input, Guidance, and EPDP processes but those processes were only referenced and footnoted, not actually explained to the ICANN community or the public. Importantly, the draft Initial Report language was clarified to delete the reference to the Standing IRT “deciding” an issue based on the Predictability Framework. Instead, in the Initial Report, there is a reference to the Standing IRT being able to “recommend” a resolution of the issue. In terms of ICANN governance and the ByLaws as modified after the Policy & Implementation WG finished its work, that is the correct stance. Establishing some other “gate” or some method for determining in advance what is policy and what is implementation when the existing processes adopted after a full WG process have not been tried does not make sense to me. By way of additional background, the whole Policy & Implementation Working Group evolved from the fact that then-CEO Fadi Chehade decided that the “Strawman Solution” in relation to trademarks was implementation, not policy. Fadi issued a public statement to this effect. GNSO Council members were upset about this and our Co-Chair Jeff Neuman wrote the letter to the ICANN Board stating that if the Board took action (such as the Strawman Solution) that amounted to a change in policy, they had to come back to GNSO for its views on the topic and more specifically, to make a determination as to whether the topic required more policy work or merely some GNSO input. Clearly the timing as to when an issue arises (either pre- or post- launch) is NOT a determiner of whether it is Policy or Implementation. So Chuck Gomes led the P & I WG as a result of the GNSO Council’s dissatisfaction with the handling of that issue (and others) that arose Post-Launch and we spent more than year (probably about 2 years) reviewing numerous issues that arose after applications were filed in the 2012 round. That is why the GNSO processes called Input, Guidance and EPDP were adopted by the GNSO Council and that is why the ICANN ByLaws were amended. Hopefully the above history helps to clarify why I was quoting existing GNSO Operating Procedures and Annexes. Again, I don’t think the public understood these processes when the Initial Report issued. The current Consensus Policy Implementation Framework (“CPIF”) of the GNSO makes specific reference to these processes and requires that IRT members be briefed on them. Anne From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Jeff Neuman Sent: Tuesday, May 7, 2019 1:57 AM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] FW: Follow up from May 6th and CALL FOR SMALL GROUP [EXTERNAL] ________________________________ All, Following up on the call yesterday, we have revised the document on the Proposed New Predictability Model. You can find it here: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr.... The comments made during the call should be incorporated either as revised language itself, or as “comments” for draft language to be created. As we discussed, we would like to have a smaller group dedicated to working through the issues that remain on this topic so that a more comprehensive proposal can be presented to the full working group at a later date on the Predictability Framework. The group is open to any current Working Group members. However, if you join the small group, you are expected to put in some time to try and resolve whatever issues remain. The small group MAY have a call or two, but the hope is that all of the work can be done in e-mail and through the documents itself. We will create a mailing list to work on these issues. This is NOT a formal group. So far, I think we captured the following people to be on this group (from the call last night): Jeff Neuman Cheryl-Langdon Orr Kathy Kleiman Christopher Wilkinson Kristina Rosette There may have been others that already volunteered, but may not have captured, so please indicate your interest to us if you want to be a part of the smaller team. We will not be doing formal consensus calls as part of this smaller group, but rather just making the proposal better and filling in the holes to present to the full working group. Please let me know if you have any questions. Best regards, Jeffrey J. Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive , Suite 600 Mclean , VA 22102 UNITED STATES T: +1.703.635.7514 M: +1.202.549.5079 CONFIRMATION OF ORDERS: Please note that we always confirm receipt of orders. To assist us in identifying orders, please use the word ORDER in the subject line of your email. If you have sent us an order and have not received confirmation on the same working day (PST) it is possible that your order has not been received or has been trapped by our spam filter. In this case, please contact your client manager or admin@comlaude.com<mailto:admin@comlaude.com> for confirmation that the order has been received and is being processed. Thank you. From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Julie Hedlund Sent: Monday, May 6, 2019 11:40 PM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 May 2019 Dear Working Group members, Please see below the notes from the meeting today, 06 May 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-05-06+New+gTLD+Subsequent+Pro.... Please also see the referenced documents at: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK.... Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Action Items: ACTION ITEM 1: Staff to incorporate edits as discussed into the 2.2.2 Predictability document. ACTION ITEM 2: Gather a small group to further develop the 2.2.2 Predictability document at:https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr.... Jeff will send out a call for volunteers to the list. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson. Notes: 1. Updates to Statements of Interest (SOIs): No updates provided. 2. Review of Summary Documents – (see: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK...) a. Continued: 2.2.2 Predictability / 2.2.2.2 Clarity of Application Process: See:https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr... -- Note: If we don’t come to consensus on a topic then the status quo will be as it was implemented in 2012. On the record that some do not support that approach. -- There are some different things relating to IRTs that could be new. 2.2.2 Predictability: -- Added bullet: The Predictability Model complements the existing GNSO processes and procedures and shall not in any way operate to be a substitute or replacement for those. In fact, they are incorporated into the Predictability Framework explicitly. Discussion: -- “they” references existing processes and procedures. -- To avoid any doubt in future we might want to add, “In the event of a conflict, existing GNSO processes and procedures take precedent.” -- Change from “shall not in any way operate to be” to “is not intended to be”. What are we proposing: B. Changes to ICANN Organization Internal Processes Discussion: -- Comfortable that we have a distinction for minor changes. -- For the first bullet under (b) -- re: “anything visible” -- what does that encompass? Add “change the application or any of the other processes set forth in the applicant guidebook”. Or “those parts of the application that are scored”? -- Third bullet -- New processes: Some examples have direct relevance for the entire community. Such as a new public comment platform. -- Standing IRT decides what is implementation or policy -- but some WG members disagree. -- Change to “Material adverse impact”? -- Second bullet -- “all non-minor changes” -- in written policy? Answer: The output of this whole thing will eventually be the AGB and if there are changes to the AGB they would be written. -- So not a reasonable response that a process will just take longer -- just being a communication. Seems like there should be more accountability. Add a comment/note to see if that falls under a different category. -- Filter out those things that can be dealt with in a practical matter. -- Third bullet: Need a gateway process before we get to these items. Wherever something affects the underlying rules has huge implications. -- Might need to clarify: “New public comment platform” means changes to the tools being used to submit. The rules for commenting is the same, but the platform is different. -- Second bullet: Not meant to be a change in the timing, but a change in a portal. -- Add a line after bullet three, “These proposed changes are intended to be only those that involve mechanisms with no substantive impact.” Question: How is that different from this text, “but rather a New ICANN Organization Internal Process and it is likely to have a materially [adverse] impact on applicants or community members…” Seems similar in meaning. -- An example of a change that wouldn’t be substantive but could have a material adverse impact would be requiring that Legal Rights Objections be filed through a proprietary platform instead of email. Wouldn't affect the substantive LRO (elements, standing, etc), but there may be some potential objectors that, for one reason or another, can't use that platform. -- Are timelines on filing objections seen as a different type of timeline as a third-party timeline? -- What might be a minor change for one party could be a major change to others. Adverse outcomes -- for whom? Should there be a policy gateway to determine? We don’t have a framework that would be considered to be predictable. -- If there is a gateway then that could delay any changes. -- Overriding principle is predictability. Trying to improve predictability from the last round. C. Fundamental Possible Policy Level Changes Discussion: -- Some examples seem to be out of scope for an IRT. -- Deciding something that is policy: a standing IRT can raise that issue and the GNSO Liaison can take that back to the Council. Any Council member also can raise something for consideration at the Council level. -- So a standing IRT can raise something, but only the Council can decide what is policy or implementation, but it sounds like we are setting up a separate gateway. The standing IRT cannot be the final arbiter, and the Council also can raise it directly. -- Add to the bullet point that the standing IRT can make a recommendation to the GNSO Council as to whether something is policy or implementation, but the GNSO will make the final decision. -- Ensure that this document is cross-referenced to the current policies and processes for IRTs. -- What do we mean by “Staff will collaborate with the community”? Answer: That is meant to first go to the standing IRT, which makes a recommendation for additional consideration, and then the GNSO decides how to handle it -- GNSO Input Process, EPDP, etc. -- Delete this text, “Staff will collaborate with the community to consider the issue and agree upon the mechanism by which the solution will be developed. Options could include:” And emphasize the point that this is meant to be a community+staff decision, not just staff. Mark them as redlined and to be replaced. Come back to this in another WG meeting. -- Helpful to have a workflow diagram for the Predictability Framework once concepts are agreed and reconcile with existing ones from IRT Guidelines. D. Fundamental Possible Policy Level New Proposals Discussion: -- Carry over changes from bullets under C. -- Reaching out to the community means staff reaching out to the standing IRT. But don’t think the standing IRT has the authority to decide if something is a policy or implementation change. Could have a new group that includes members of the IRT, and also Council members, and then decide if it goes to the standing IRT. -- Want to change what we call this because of previous problems with IRTs. Want to get the composition right so it is representative of the community. Meant to ensure that it is a gateway. -- A number of groups supported the recommendations in the Initial Report but also some dissenting views: ACTION: Form a smaller group to further develop this document for the full WG. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson. ________________________________ 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 seewww.comlaude.com<https://comlaude.com/> ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521. _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org<mailto:Gnso-newgtld-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
Good afternoon : In the question of the Implementation Review Teams (IRT's) by any other name, I come to this rather unexpectedly. So, before joining the 'SMALL GROUP' established by the PDP Call on 6 May, I would wish to just summarize and explain what I said during that call. 1. Predictability : It is a primary röle for the PDP to establish rules and procedures which give rise to predictability for all parties concerned. At present the PDP and the work Tracks, (particularly WT5) are far from creating a predictability framewlork. This is primarily because some participants express a tangible reluctance to accept rules and procedures that would be predictable for third parties. Thus, the primary responsibility of the PDP is to fix the predictability issues including those that have not been resolved at the Work Track level. Meanwhile,. It is not appropriate to charge IRTs with 'interlpreting' the consequences of unresolved policy issues. 2. Implementation vs. Policy : This risques becoming a false distinction. What is a minor issue for some could be a major issue for others. Specifically the resolution of a minor issue for one application could become a precedent for other applications. Any eventual IRT would inevitably be 'looking over its shoulder' to see what would be the consequences elsewhere i.e. Policy. Third Parties : The expansion of the DNS inevitably impinges on the interests of parties that are neither contdracted pardtdies, nor applicatns. To ignore this would absolutely guarantee a lack of predictability both for the applicants and for third parties concerned. There is a discontinuity between the presuppositions in the PDP andl the GNSO as to how matters should proceed, and the natural assumptions of concerned third lparties which are « Write to the Board » or « Write to the GAC member ». Thus considerably reducing the scope for eventual IRTs to handle questions that will rapidly go beyond their control, particularly it becomes a matter of Policy. 4. The 'Standing IRT?' Should it become necessary to create an entity 'between' the AGB process and the Staff on the one hand, and the GNSO and the Board on the other hand, we would be creating an entity with significant power. If so, it must be enhanced with full transparency, independence and accountability to the Community, that is to all Stakeholders, By dealing with unforeseen issues affecting applicants and third parties, the entity will inevitably create policy by precedent, if not by its intended decisions. 5. In Conclusion: I come back to the first point that is that the PDP and WT5 need to do a lot more concrete work to create predictability. With regard to third party interests, a lack of predictability will undermine predictability for applicants; unresolved issues will simply escalate and create delays and uncertainties. As before. Let us bear in mind that in future 'rounds' most applicants may not benefit from experience from 2012, nor from inside knowledge of the PDP and Work Tracks. An 'IRT' would not be able to resolve lacunae arising from the PDP itself. Regards Christopher Wilkinson Xàbia, 8 May 2019Good evening :
On 7 May 2019, at 22:05, Aikman-Scalese, Anne <AAikman@lrrc.com <mailto:AAikman@lrrc.com>> wrote:
Dear WG members: Regarding the smaller group assembled to work on how staff and the proposed “post-launch Standing IRT” might determine whether an issue is policy or implementation, I would like to clarify again the history that led to the existing GNSO processes designed to address these issues whenever they arise –either Pre- or –Post launch:
The Policy & Implementation Working Group grappled with this question of policy versus implementation for many months and concluded it was impossible to make determinations about that in advance because “one person’s policy is another person’s implementation”. That is exactly why we have the result we have in the form of GNSO Input (which is essentially for implementation issues), GNSO Guidance, and GNSO EPDP. In fact, it was Marika Koenigs who first suggested to the Policy & Implementation WG that, based on our case studies of issues that arose in the 2012 round, it was impossible to “predict” issues that might arise and label them as clearly policy or clearly implementation. Jeff has pointed out that applicants want more “predictability” in the process so that time delays do not result. Thus, the proposed “Predictability Framework” anticipates that ICANN staff and/or or some newly created body will be able to decide issues that arise post-launch. The “problem” Jeff is trying to resolve as Co-Chair is that if an issue reaches the GNSO, it may take too long to resolve and thus is not practical for registry applicants. However, as far as I know, we have not yet tried out these new processes (except for the EPDP on the Temp Spec) so it seems to me a bit premature to be inventing new processes and acronyms on top of the ones that have not yet been tried. It strikes me that for various Implementation issues that actually rise to the level of an issue post-launch, the existing GNSO Input process (which has not yet been used) is adequate and is in fact designed to operate in that fashion since GNSO can raise such a concern “at any time it deems appropriate”.
Under existing GNSO processes established as a result of the work of the Policy & Implementation Working Group, the “gateway” is in fact a question of the interaction between and among Staff, an IRT (or Post-launch Standing IRT), and the GNSO Council. Staff can raise an issue, IRT can raise an issue, and ANY GNSO Council member can raise an issue and so these are the “gates”. (In other words, there are multiple gates and they all ultimately lead to oversight by GNSO Council.) My own view (having worked actively in the Policy & Implementation Working Group on several case studies of issues that arose Post-Launch in the 2012 round) is that if an issue is truly implementation, no one is going to raise the issue to the level of GNSO. Issues will only rise to that level if a stakeholder believes that GNSO Council should address it and that applies whether it’s merely implementation (“GNSO Input” Annex) or involves policy (“GNSO Guidance” Annex or “GNSO EPDP” Annex).
Before the Sub Pro Initial Report issued, the Co-Chairs and staff ultimately agreed to make reference to the GNSO Input, Guidance, and EPDP processes but those processes were only referenced and footnoted, not actually explained to the ICANN community or the public. Importantly, the draft Initial Report language was clarified to delete the reference to the Standing IRT “deciding” an issue based on the Predictability Framework. Instead, in the Initial Report, there is a reference to the Standing IRT being able to “recommend” a resolution of the issue. In terms of ICANN governance and the ByLaws as modified after the Policy & Implementation WG finished its work, that is the correct stance. Establishing some other “gate” or some method for determining in advance what is policy and what is implementation when the existing processes adopted after a full WG process have not been tried does not make sense to me.
By way of additional background, the whole Policy & Implementation Working Group evolved from the fact that then-CEO Fadi Chehade decided that the “Strawman Solution” in relation to trademarks was implementation, not policy. Fadi issued a public statement to this effect. GNSO Council members were upset about this and our Co-Chair Jeff Neuman wrote the letter to the ICANN Board stating that if the Board took action (such as the Strawman Solution) that amounted to a change in policy, they had to come back to GNSO for its views on the topic and more specifically, to make a determination as to whether the topic required more policy work or merely some GNSO input.
Clearly the timing as to when an issue arises (either pre- or post- launch) is NOT a determiner of whether it is Policy or Implementation. So Chuck Gomes led the P & I WG as a result of the GNSO Council’s dissatisfaction with the handling of that issue (and others) that arose Post-Launch and we spent more than year (probably about 2 years) reviewing numerous issues that arose after applications were filed in the 2012 round. That is why the GNSO processes called Input, Guidance and EPDP were adopted by the GNSO Council and that is why the ICANN ByLaws were amended.
Hopefully the above history helps to clarify why I was quoting existing GNSO Operating Procedures and Annexes. Again, I don’t think the public understood these processes when the Initial Report issued. The current Consensus Policy Implementation Framework (“CPIF”) of the GNSO makes specific reference to these processes and requires that IRT members be briefed on them. Anne
<> From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org <mailto:gnso-newgtld-wg-bounces@icann.org>] On Behalf Of Jeff Neuman Sent: Tuesday, May 7, 2019 1:57 AM To: gnso-newgtld-wg@icann.org <mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] FW: Follow up from May 6th and CALL FOR SMALL GROUP
[EXTERNAL] All,
Following up on the call yesterday, we have revised the document on the Proposed New Predictability Model. You can find it here: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr... <https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr...>. The comments made during the call should be incorporated either as revised language itself, or as “comments” for draft language to be created.
As we discussed, we would like to have a smaller group dedicated to working through the issues that remain on this topic so that a more comprehensive proposal can be presented to the full working group at a later date on the Predictability Framework. The group is open to any current Working Group members. However, if you join the small group, you are expected to put in some time to try and resolve whatever issues remain. The small group MAY have a call or two, but the hope is that all of the work can be done in e-mail and through the documents itself. We will create a mailing list to work on these issues. This is NOT a formal group.
So far, I think we captured the following people to be on this group (from the call last night):
Jeff Neuman Cheryl-Langdon Orr Kathy Kleiman Christopher Wilkinson Kristina Rosette
There may have been others that already volunteered, but may not have captured, so please indicate your interest to us if you want to be a part of the smaller team.
We will not be doing formal consensus calls as part of this smaller group, but rather just making the proposal better and filling in the holes to present to the full working group.
Please let me know if you have any questions.
Best regards,
Jeffrey J. Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive , Suite 600 Mclean , VA 22102 UNITED STATES T: +1.703.635.7514 M: +1.202.549.5079
CONFIRMATION OF ORDERS: Please note that we always confirm receipt of orders. To assist us in identifying orders, please use the word ORDER in the subject line of your email. If you have sent us an order and have not received confirmation on the same working day (PST) it is possible that your order has not been received or has been trapped by our spam filter. In this case, please contact your client manager or admin@comlaude.com <mailto:admin@comlaude.com> for confirmation that the order has been received and is being processed. Thank you.
From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org <mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Julie Hedlund Sent: Monday, May 6, 2019 11:40 PM To: gnso-newgtld-wg@icann.org <mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 May 2019
Dear Working Group members,
Please see below the notes from the meeting today, 06 May 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-05-06+New+gTLD+Subsequent+Pro... <https://community.icann.org/display/NGSPP/2019-05-06+New+gTLD+Subsequent+Pro...>.
Please also see the referenced documents at: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK... <https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK...>.
Kind regards, Julie Julie Hedlund, Policy Director
Notes and Action Items:
Action Items:
ACTION ITEM 1: Staff to incorporate edits as discussed into the 2.2.2 Predictability document. ACTION ITEM 2: Gather a small group to further develop the 2.2.2 Predictability document at:https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr... <https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr...>. Jeff will send out a call for volunteers to the list. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson.
Notes:
1. Updates to Statements of Interest (SOIs): No updates provided.
2. Review of Summary Documents – (see: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK... <https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK...>)
a. Continued: 2.2.2 Predictability / 2.2.2.2 Clarity of Application Process: See:https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr... <https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr...>
-- Note: If we don’t come to consensus on a topic then the status quo will be as it was implemented in 2012. On the record that some do not support that approach. -- There are some different things relating to IRTs that could be new.
2.2.2 Predictability: -- Added bullet: The Predictability Model complements the existing GNSO processes and procedures and shall not in any way operate to be a substitute or replacement for those. In fact, they are incorporated into the Predictability Framework explicitly.
Discussion: -- “they” references existing processes and procedures. -- To avoid any doubt in future we might want to add, “In the event of a conflict, existing GNSO processes and procedures take precedent.” -- Change from “shall not in any way operate to be” to “is not intended to be”.
What are we proposing:
B. Changes to ICANN Organization Internal Processes
Discussion: -- Comfortable that we have a distinction for minor changes. -- For the first bullet under (b) -- re: “anything visible” -- what does that encompass? Add “change the application or any of the other processes set forth in the applicant guidebook”. Or “those parts of the application that are scored”? -- Third bullet -- New processes: Some examples have direct relevance for the entire community. Such as a new public comment platform. -- Standing IRT decides what is implementation or policy -- but some WG members disagree. -- Change to “Material adverse impact”? -- Second bullet -- “all non-minor changes” -- in written policy? Answer: The output of this whole thing will eventually be the AGB and if there are changes to the AGB they would be written. -- So not a reasonable response that a process will just take longer -- just being a communication. Seems like there should be more accountability. Add a comment/note to see if that falls under a different category. -- Filter out those things that can be dealt with in a practical matter. -- Third bullet: Need a gateway process before we get to these items. Wherever something affects the underlying rules has huge implications. -- Might need to clarify: “New public comment platform” means changes to the tools being used to submit. The rules for commenting is the same, but the platform is different. -- Second bullet: Not meant to be a change in the timing, but a change in a portal. -- Add a line after bullet three, “These proposed changes are intended to be only those that involve mechanisms with no substantive impact.” Question: How is that different from this text, “but rather a New ICANN Organization Internal Process and it is likely to have a materially [adverse] impact on applicants or community members…” Seems similar in meaning. -- An example of a change that wouldn’t be substantive but could have a material adverse impact would be requiring that Legal Rights Objections be filed through a proprietary platform instead of email. Wouldn't affect the substantive LRO (elements, standing, etc), but there may be some potential objectors that, for one reason or another, can't use that platform. -- Are timelines on filing objections seen as a different type of timeline as a third-party timeline? -- What might be a minor change for one party could be a major change to others. Adverse outcomes -- for whom? Should there be a policy gateway to determine? We don’t have a framework that would be considered to be predictable. -- If there is a gateway then that could delay any changes. -- Overriding principle is predictability. Trying to improve predictability from the last round.
C. Fundamental Possible Policy Level Changes
Discussion: -- Some examples seem to be out of scope for an IRT. -- Deciding something that is policy: a standing IRT can raise that issue and the GNSO Liaison can take that back to the Council. Any Council member also can raise something for consideration at the Council level. -- So a standing IRT can raise something, but only the Council can decide what is policy or implementation, but it sounds like we are setting up a separate gateway. The standing IRT cannot be the final arbiter, and the Council also can raise it directly. -- Add to the bullet point that the standing IRT can make a recommendation to the GNSO Council as to whether something is policy or implementation, but the GNSO will make the final decision. -- Ensure that this document is cross-referenced to the current policies and processes for IRTs. -- What do we mean by “Staff will collaborate with the community”? Answer: That is meant to first go to the standing IRT, which makes a recommendation for additional consideration, and then the GNSO decides how to handle it -- GNSO Input Process, EPDP, etc. -- Delete this text, “Staff will collaborate with the community to consider the issue and agree upon the mechanism by which the solution will be developed. Options could include:” And emphasize the point that this is meant to be a community+staff decision, not just staff. Mark them as redlined and to be replaced. Come back to this in another WG meeting. -- Helpful to have a workflow diagram for the Predictability Framework once concepts are agreed and reconcile with existing ones from IRT Guidelines.
D. Fundamental Possible Policy Level New Proposals
Discussion: -- Carry over changes from bullets under C. -- Reaching out to the community means staff reaching out to the standing IRT. But don’t think the standing IRT has the authority to decide if something is a policy or implementation change. Could have a new group that includes members of the IRT, and also Council members, and then decide if it goes to the standing IRT. -- Want to change what we call this because of previous problems with IRTs. Want to get the composition right so it is representative of the community. Meant to ensure that it is a gateway. -- A number of groups supported the recommendations in the Initial Report but also some dissenting views: ACTION: Form a smaller group to further develop this document for the full WG. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson.
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 seewww.comlaude.com <https://comlaude.com/>
This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521. _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org <mailto:Gnso-newgtld-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg <https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg>
Hi All, I have read the discussion taking place and I still don't think the key issues or concerns have been addressed. I'm glad that the Board, the Community, GNSO Council members, Staff and Post-Launch Standing IRT members /*can *//*raise *//*Policy issues, Implementation issues and Policy/Implementation borderline issues. *//*But my question is who decides what category these questions (from all these Sources) fall into? */Someone has to look at a question and decide whether is it policy, implementation or borderline (implementation, with substantial policy implications). To a long-standing Post-Launch Standing IRT, at work for several years, most questions will appear to be implementation. Why? Because to a hammer, almost everything is a nail. The Post-Launch Standing IRT will be geared up to solve everything as efficiently as possible -- to make everything as /"predictable for applicants" /as possible. */Good, but what about the GAC, Non-Contracted Parties and the Community? /*We (this latter group) will have returned to our other Multistakeholder Policy duties, to our other ICANN deadlines and priorities, and frankly, to our day jobs. We won't be watching when Staff flags a question to the long-standing Post-Launch Standing IRT and they flag it as "implementation" due to their focus on application processing (when it is actually policy or implementation with a heavy policy impact, e.g., systems involving the processing of public comments or Objections). I'm not saying the lack of understanding of policy implications of an issue will be intentional -- it is likely inadvertent when seen through the prism of incumbents and applicants. How do I know this -- because virtually numerous IRTs in the last decade have -- or been strongly urged -- to rewrite policies (to rewrite consensus policies, agreed and accepted by the Multistakeholder Community & Board). A Gateway Group will review all new questions coming through -- hopefully in conjunction with a standing group of the GNSO Council, the Community and Non-Contracted Parties, the GAC and likely, a few members of the Post-Launch Standing IRT. Especially as Staff arives with questions arising from the application & comment process (policy/implementation questions), this Gateway Group can quickly sort these questions -- pointing them in the right direction: Council or IRT. The Gateway Group should be diverse, fast and light weight. The heavier implementation work, technical detail, etc, belongs to the IRT. Overall, IRTs are IRTs. They will be tempted (and urged) to rewrite policy; they will want to control as much as possible; for these applications, they will be dominated by contracted parties and applicants. That's the nature of the system; that's the way virtually all recent IRTs have worked; and their structure will incentivized to treat as much as "implementation" as possible. If we are going to have a Post-Launch Standing IRT, then we need one more step. Best, Kathy On 5/7/2019 4:05 PM, Aikman-Scalese, Anne wrote:
Dear WG members:
Regarding the smaller group assembled to work on how staff and the proposed “post-launch Standing IRT” might determine whether an issue is policy or implementation, I would like to clarify again the history that led to the existing GNSO processes designed to address these issues whenever they arise –either Pre- or –Post launch:
The Policy & Implementation Working Group grappled with this question of policy versus implementation for many months and concluded it was impossible to make determinations about that in advance because “one person’s policy is another person’s implementation”. That is exactly why we have the result we have in the form of GNSO Input (which is essentially for implementation issues), GNSO Guidance, and GNSO EPDP. In fact, it was Marika Koenigs who first suggested to the Policy & Implementation WG that, based on our case studies of issues that arose in the 2012 round, it was impossible to “predict” issues that might arise and label them as clearly policy or clearly implementation. Jeff has pointed out that applicants want more “predictability” in the process so that time delays do not result. Thus, the proposed “Predictability Framework” anticipates that ICANN staff and/or or some newly created body will be able to decide issues that arise post-launch. The “problem” Jeff is trying to resolve as Co-Chair is that if an issue reaches the GNSO, it may take too long to resolve and thus is not practical for registry applicants. However, as far as I know, we have not yet tried out these new processes (except for the EPDP on the Temp Spec) so it seems to me a bit premature to be inventing new processes and acronyms on top of the ones that have not yet been tried. *It strikes me that for various Implementation issues that actually rise to the level of an issue post-launch, the existing GNSO Input process (which has not yet been used) is adequate and is in fact designed to operate in that fashion since GNSO can raise such a concern “at any time it deems appropriate”.*
_Under existing GNSO processes established as a result of the work of the Policy & Implementation Working Group_, the “gateway” is in fact a question of the interaction between and among Staff, an IRT (or Post-launch Standing IRT), and the GNSO Council. Staff can raise an issue, IRT can raise an issue, and ANY GNSO Council member can raise an issue and so these are the “gates”. (In other words, there are multiple gates and they all ultimately lead to oversight by GNSO Council.) My own view (having worked actively in the Policy & Implementation Working Group on several case studies of issues that arose Post-Launch in the 2012 round) is that if an issue is truly implementation, no one is going to raise the issue to the level of GNSO. Issues will only rise to that level if a stakeholder believes that GNSO Council should address it and that applies whether it’s merely implementation (“GNSO Input” Annex) or involves policy (“GNSO Guidance” Annex or “GNSO EPDP” Annex).
Before the Sub Pro Initial Report issued, the Co-Chairs and staff ultimately agreed to make reference to the GNSO Input, Guidance, and EPDP processes but those processes were only referenced and footnoted, not actually explained to the ICANN community or the public. Importantly, the draft Initial Report language was clarified to delete the reference to the Standing IRT “deciding” an issue based on the Predictability Framework. Instead, in the Initial Report, there is a reference to the Standing IRT being able to “recommend” a resolution of the issue. In terms of ICANN governance and the ByLaws as modified after the Policy & Implementation WG finished its work, that is the correct stance. Establishing some other “gate” or some method for determining in advance what is policy and what is implementation when the existing processes adopted after a full WG process have not been tried does not make sense to me.
By way of additional background, the whole Policy & Implementation Working Group evolved from the fact that then-CEO Fadi Chehade decided that the “Strawman Solution” in relation to trademarks was implementation, not policy. Fadi issued a public statement to this effect. GNSO Council members were upset about this and our Co-Chair Jeff Neuman wrote the letter to the ICANN Board stating that if the Board took action (such as the Strawman Solution) that amounted to a change in policy, they had to come back to GNSO for its views on the topic and more specifically, to make a determination as to whether the topic required more policy work or merely some GNSO input.
Clearly the timing as to when an issue arises (either pre- or post- launch) is NOT a determiner of whether it is Policy or Implementation. So Chuck Gomes led the P & I WG as a result of the GNSO Council’s dissatisfaction with the handling of that issue (and others) that arose Post-Launch and we spent more than year (probably about 2 years) reviewing numerous issues that arose after applications were filed in the 2012 round. That is why the GNSO processes called Input, Guidance and EPDP were adopted by the GNSO Council and that is why the ICANN ByLaws were amended.
Hopefully the above history helps to clarify why I was quoting existing GNSO Operating Procedures and Annexes. Again, I don’t think the public understood these processes when the Initial Report issued. The current Consensus Policy Implementation Framework (“CPIF”) of the GNSO makes specific reference to these processes and requires that IRT members be briefed on them.
Anne
*From:* Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] *On Behalf Of *Jeff Neuman *Sent:* Tuesday, May 7, 2019 1:57 AM *To:* gnso-newgtld-wg@icann.org *Subject:* [Gnso-newgtld-wg] FW: Follow up from May 6th and CALL FOR SMALL GROUP
*[EXTERNAL]*
------------------------------------------------------------------------
All,
Following up on the call yesterday, we have revised the document on the Proposed New Predictability Model. You can find it here: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr.... The comments made during the call should be incorporated either as revised language itself, or as “comments” for draft language to be created.
As we discussed, we would like to have a smaller group dedicated to working through the issues that remain on this topic so that a more comprehensive proposal can be presented to the full working group at a later date on the Predictability Framework. The group is open to any current Working Group members. However, if you join the small group, you are expected to put in some time to try and resolve whatever issues remain. The small group MAY have a call or two, but the hope is that all of the work can be done in e-mail and through the documents itself. We will create a mailing list to work on these issues. This is NOT a formal group.
So far, I think we captured the following people to be on this group (from the call last night):
Jeff Neuman
Cheryl-Langdon Orr
Kathy Kleiman
Christopher Wilkinson
Kristina Rosette
There may have been others that already volunteered, but may not have captured, so please indicate your interest to us if you want to be a part of the smaller team.
We will not be doing formal consensus calls as part of this smaller group, but rather just making the proposal better and filling in the holes to present to the full working group.
Please let me know if you have any questions.
Best regards,
*Jeffrey J. Neuman* Senior Vice President
*Com Laude | Valideus *1751 Pinnacle Drive , Suite 600 Mclean , VA 22102 UNITED STATES T: +1.703.635.7514 M: +1.202.549.5079
CONFIRMATION OF ORDERS: Please note that we always confirm receipt of orders. To assist us in identifying orders, please use the word ORDER in the subject line of your email. If you have sent us an order and have not received confirmation on the same working day (PST) it is possible that your order has not been received or has been trapped by our spam filter. In this case, please contact your client manager or admin@comlaude.com <mailto:admin@comlaude.com> for confirmation that the order has been received and is being processed. Thank you.
*From:* Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org <mailto:gnso-newgtld-wg-bounces@icann.org>> *On Behalf Of *Julie Hedlund *Sent:* Monday, May 6, 2019 11:40 PM *To:* gnso-newgtld-wg@icann.org <mailto:gnso-newgtld-wg@icann.org> *Subject:* [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 May 2019
Dear Working Group members,
Please see below the notes from the meeting today, 06 May 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-05-06+New+gTLD+Subsequent+Pro....
Please also see the referenced documents at: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK....
Kind regards,
Julie
Julie Hedlund, Policy Director
*Notes and Action Items:*
*Action Items:*
ACTION ITEM 1: Staff to incorporate edits as discussed into the 2.2.2 Predictability document.
ACTION ITEM 2: Gather a small group to further develop the 2.2.2 Predictability document at: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr.... Jeff will send out a call for volunteers to the list. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson.
*Notes:*
1. Updates to Statements of Interest (SOIs): No updates provided.
2. Review of Summary Documents – (see: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK...)
a. Continued: 2.2.2 Predictability / 2.2.2.2 Clarity of Application Process: See: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr...
-- Note: If we don’t come to consensus on a topic then the status quo will be as it was implemented in 2012. On the record that some do not support that approach.
-- There are some different things relating to IRTs that could be new.
2.2.2 Predictability:
-- Added bullet: /The Predictability Model _complements_ the existing GNSO processes and procedures and shall not in any way operate to be a substitute or replacement for those. In fact, they are incorporated into the Predictability Framework explicitly./
_Discussion_:
-- “they” references existing processes and procedures.
-- To avoid any doubt in future we might want to add, “In the event of a conflict, existing GNSO processes and procedures take precedent.”
-- Change from “shall not in any way operate to be” to “is not intended to be”.
What are we proposing:
_B. Changes to ICANN Organization Internal Processes_
_Discussion:_
-- Comfortable that we have a distinction for minor changes.
-- For the first bullet under (b) -- re: “anything visible” -- what does that encompass? Add “change the application or any of the other processes set forth in the applicant guidebook”. Or “those parts of the application that are scored”?
-- Third bullet -- New processes: Some examples have direct relevance for the entire community. Such as a new public comment platform.
-- Standing IRT decides what is implementation or policy -- but some WG members disagree.
-- Change to “Material adverse impact”?
-- Second bullet -- “all non-minor changes” -- in written policy? Answer: The output of this whole thing will eventually be the AGB and if there are changes to the AGB they would be written.
-- So not a reasonable response that a process will just take longer -- just being a communication. Seems like there should be more accountability. Add a comment/note to see if that falls under a different category.
-- Filter out those things that can be dealt with in a practical matter.
-- Third bullet: Need a gateway process before we get to these items. Wherever something affects the underlying rules has huge implications.
-- Might need to clarify: “New public comment platform” means changes to the tools being used to submit. The rules for commenting is the same, but the platform is different.
-- Second bullet: Not meant to be a change in the timing, but a change in a portal.
-- Add a line after bullet three, “These proposed changes are intended to be only those that involve mechanisms with no substantive impact.” Question: How is that different from this text, “but rather a New ICANN Organization Internal Process and it is likely to have a materially [adverse] impact on applicants or community members…” Seems similar in meaning.
-- An example of a change that wouldn’t be substantive but could have a material adverse impact would be requiring that Legal Rights Objections be filed through a proprietary platform instead of email. Wouldn't affect the substantive LRO (elements, standing, etc), but there may be some potential objectors that, for one reason or another, can't use that platform.
-- Are timelines on filing objections seen as a different type of timeline as a third-party timeline?
-- What might be a minor change for one party could be a major change to others. Adverse outcomes -- for whom? Should there be a policy gateway to determine? We don’t have a framework that would be considered to be predictable.
-- If there is a gateway then that could delay any changes.
-- Overriding principle is predictability. Trying to improve predictability from the last round.
C. _Fundamental Possible Policy Level Changes_
_Discussion:_
-- Some examples seem to be out of scope for an IRT.
-- Deciding something that is policy: a standing IRT can raise that issue and the GNSO Liaison can take that back to the Council. Any Council member also can raise something for consideration at the Council level.
-- So a standing IRT can raise something, but only the Council can decide what is policy or implementation, but it sounds like we are setting up a separate gateway. The standing IRT cannot be the final arbiter, and the Council also can raise it directly.
-- Add to the bullet point that the standing IRT can make a recommendation to the GNSO Council as to whether something is policy or implementation, but the GNSO will make the final decision.
-- Ensure that this document is cross-referenced to the current policies and processes for IRTs.
-- What do we mean by “Staff will collaborate with the community”? Answer: That is meant to first go to the standing IRT, which makes a recommendation for additional consideration, and then the GNSO decides how to handle it -- GNSO Input Process, EPDP, etc.
-- Delete this text, “Staff will collaborate with the community to consider the issue and agree upon the mechanism by which the solution will be developed. Options could include:” And emphasize the point that this is meant to be a community+staff decision, not just staff. Mark them as redlined and to be replaced. Come back to this in another WG meeting.
-- Helpful to have a workflow diagram for the Predictability Framework once concepts are agreed and reconcile with existing ones from IRT Guidelines.
D. _Fundamental Possible Policy Level New Proposals_
_Discussion_:
-- Carry over changes from bullets under C.
-- Reaching out to the community means staff reaching out to the standing IRT. But don’t think the standing IRT has the authority to decide if something is a policy or implementation change. Could have a new group that includes members of the IRT, and also Council members, and then decide if it goes to the standing IRT.
-- Want to change what we call this because of previous problems with IRTs. Want to get the composition right so it is representative of the community. Meant to ensure that it is a gateway.
-- A number of groups supported the recommendations in the Initial Report but also some dissenting views: ACTION: Form a smaller group to further develop this document for the full WG. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson.
------------------------------------------------------------------------
The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com <https://comlaude.com>
------------------------------------------------------------------------
This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
_______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg
Thanks Kathy. This too will be moved over for now to the smaller list (when I get it confirmed that it has been set up). In talking with a number of people, the creation of two groups seems excessive and too much bureaucracy. If a Post-launch IRT is set up, we will have to have some level of trust that they will do the job put before them and only the job put before them. We should not set up a second group because we anticipate that the original group will naturally act beyond its mandate. If we employed that logic, then wouldn’t we need a third group to keep a watch of the second group and so on. With respect to everyone else “returning to their ICANN day jobs”, that too should not be a problem that we would need to address. One of the biggest failures of our current system is that we as a community do not have trust in anyone else or any other group to do the right thing. This leads unfortunately to a situation where everyone believes that they need to be involved in every issue and every group. But the reality is that there are groups that are functioning well without everyone being involved in everything. The Customer Standing Committee is one example. Their job is to monitor the performance of the IANA naming function and if performance issues are not remedied, they may escalate issues to the GNSO (and ccNSO). If we set up the group right, and we appoint responsible members to this post launch IRT, then we should trust them to do the job they are tasked with. We also should not be making assumptions that this new post-launch IRT will be dominated by contracted parties and applicants. We have the opportunity to establish the rules of this new group so that no one individual or group can control. Best regards, Jeffrey J. Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive , Suite 600 Mclean , VA 22102 UNITED STATES T: +1.703.635.7514 M: +1.202.549.5079 CONFIRMATION OF ORDERS: Please note that we always confirm receipt of orders. To assist us in identifying orders, please use the word ORDER in the subject line of your email. If you have sent us an order and have not received confirmation on the same working day (PST) it is possible that your order has not been received or has been trapped by our spam filter. In this case, please contact your client manager or admin@comlaude.com for confirmation that the order has been received and is being processed. Thank you. From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Kathy Kleiman Sent: Sunday, May 12, 2019 10:54 PM To: gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] FW: Follow up from May 6th and CALL FOR SMALL GROUP Hi All, I have read the discussion taking place and I still don't think the key issues or concerns have been addressed. I'm glad that the Board, the Community, GNSO Council members, Staff and Post-Launch Standing IRT members can raise Policy issues, Implementation issues and Policy/Implementation borderline issues. But my question is who decides what category these questions (from all these Sources) fall into? Someone has to look at a question and decide whether is it policy, implementation or borderline (implementation, with substantial policy implications). To a long-standing Post-Launch Standing IRT, at work for several years, most questions will appear to be implementation. Why? Because to a hammer, almost everything is a nail. The Post-Launch Standing IRT will be geared up to solve everything as efficiently as possible -- to make everything as "predictable for applicants" as possible. Good, but what about the GAC, Non-Contracted Parties and the Community? We (this latter group) will have returned to our other Multistakeholder Policy duties, to our other ICANN deadlines and priorities, and frankly, to our day jobs. We won't be watching when Staff flags a question to the long-standing Post-Launch Standing IRT and they flag it as "implementation" due to their focus on application processing (when it is actually policy or implementation with a heavy policy impact, e.g., systems involving the processing of public comments or Objections). I'm not saying the lack of understanding of policy implications of an issue will be intentional -- it is likely inadvertent when seen through the prism of incumbents and applicants. How do I know this -- because virtually numerous IRTs in the last decade have -- or been strongly urged -- to rewrite policies (to rewrite consensus policies, agreed and accepted by the Multistakeholder Community & Board). A Gateway Group will review all new questions coming through -- hopefully in conjunction with a standing group of the GNSO Council, the Community and Non-Contracted Parties, the GAC and likely, a few members of the Post-Launch Standing IRT. Especially as Staff arives with questions arising from the application & comment process (policy/implementation questions), this Gateway Group can quickly sort these questions -- pointing them in the right direction: Council or IRT. The Gateway Group should be diverse, fast and light weight. The heavier implementation work, technical detail, etc, belongs to the IRT. Overall, IRTs are IRTs. They will be tempted (and urged) to rewrite policy; they will want to control as much as possible; for these applications, they will be dominated by contracted parties and applicants. That's the nature of the system; that's the way virtually all recent IRTs have worked; and their structure will incentivized to treat as much as "implementation" as possible. If we are going to have a Post-Launch Standing IRT, then we need one more step. Best, Kathy On 5/7/2019 4:05 PM, Aikman-Scalese, Anne wrote: Dear WG members: Regarding the smaller group assembled to work on how staff and the proposed “post-launch Standing IRT” might determine whether an issue is policy or implementation, I would like to clarify again the history that led to the existing GNSO processes designed to address these issues whenever they arise –either Pre- or –Post launch: The Policy & Implementation Working Group grappled with this question of policy versus implementation for many months and concluded it was impossible to make determinations about that in advance because “one person’s policy is another person’s implementation”. That is exactly why we have the result we have in the form of GNSO Input (which is essentially for implementation issues), GNSO Guidance, and GNSO EPDP. In fact, it was Marika Koenigs who first suggested to the Policy & Implementation WG that, based on our case studies of issues that arose in the 2012 round, it was impossible to “predict” issues that might arise and label them as clearly policy or clearly implementation. Jeff has pointed out that applicants want more “predictability” in the process so that time delays do not result. Thus, the proposed “Predictability Framework” anticipates that ICANN staff and/or or some newly created body will be able to decide issues that arise post-launch. The “problem” Jeff is trying to resolve as Co-Chair is that if an issue reaches the GNSO, it may take too long to resolve and thus is not practical for registry applicants. However, as far as I know, we have not yet tried out these new processes (except for the EPDP on the Temp Spec) so it seems to me a bit premature to be inventing new processes and acronyms on top of the ones that have not yet been tried. It strikes me that for various Implementation issues that actually rise to the level of an issue post-launch, the existing GNSO Input process (which has not yet been used) is adequate and is in fact designed to operate in that fashion since GNSO can raise such a concern “at any time it deems appropriate”. Under existing GNSO processes established as a result of the work of the Policy & Implementation Working Group, the “gateway” is in fact a question of the interaction between and among Staff, an IRT (or Post-launch Standing IRT), and the GNSO Council. Staff can raise an issue, IRT can raise an issue, and ANY GNSO Council member can raise an issue and so these are the “gates”. (In other words, there are multiple gates and they all ultimately lead to oversight by GNSO Council.) My own view (having worked actively in the Policy & Implementation Working Group on several case studies of issues that arose Post-Launch in the 2012 round) is that if an issue is truly implementation, no one is going to raise the issue to the level of GNSO. Issues will only rise to that level if a stakeholder believes that GNSO Council should address it and that applies whether it’s merely implementation (“GNSO Input” Annex) or involves policy (“GNSO Guidance” Annex or “GNSO EPDP” Annex). Before the Sub Pro Initial Report issued, the Co-Chairs and staff ultimately agreed to make reference to the GNSO Input, Guidance, and EPDP processes but those processes were only referenced and footnoted, not actually explained to the ICANN community or the public. Importantly, the draft Initial Report language was clarified to delete the reference to the Standing IRT “deciding” an issue based on the Predictability Framework. Instead, in the Initial Report, there is a reference to the Standing IRT being able to “recommend” a resolution of the issue. In terms of ICANN governance and the ByLaws as modified after the Policy & Implementation WG finished its work, that is the correct stance. Establishing some other “gate” or some method for determining in advance what is policy and what is implementation when the existing processes adopted after a full WG process have not been tried does not make sense to me. By way of additional background, the whole Policy & Implementation Working Group evolved from the fact that then-CEO Fadi Chehade decided that the “Strawman Solution” in relation to trademarks was implementation, not policy. Fadi issued a public statement to this effect. GNSO Council members were upset about this and our Co-Chair Jeff Neuman wrote the letter to the ICANN Board stating that if the Board took action (such as the Strawman Solution) that amounted to a change in policy, they had to come back to GNSO for its views on the topic and more specifically, to make a determination as to whether the topic required more policy work or merely some GNSO input. Clearly the timing as to when an issue arises (either pre- or post- launch) is NOT a determiner of whether it is Policy or Implementation. So Chuck Gomes led the P & I WG as a result of the GNSO Council’s dissatisfaction with the handling of that issue (and others) that arose Post-Launch and we spent more than year (probably about 2 years) reviewing numerous issues that arose after applications were filed in the 2012 round. That is why the GNSO processes called Input, Guidance and EPDP were adopted by the GNSO Council and that is why the ICANN ByLaws were amended. Hopefully the above history helps to clarify why I was quoting existing GNSO Operating Procedures and Annexes. Again, I don’t think the public understood these processes when the Initial Report issued. The current Consensus Policy Implementation Framework (“CPIF”) of the GNSO makes specific reference to these processes and requires that IRT members be briefed on them. Anne From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Jeff Neuman Sent: Tuesday, May 7, 2019 1:57 AM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] FW: Follow up from May 6th and CALL FOR SMALL GROUP [EXTERNAL] ________________________________ All, Following up on the call yesterday, we have revised the document on the Proposed New Predictability Model. You can find it here: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr.... The comments made during the call should be incorporated either as revised language itself, or as “comments” for draft language to be created. As we discussed, we would like to have a smaller group dedicated to working through the issues that remain on this topic so that a more comprehensive proposal can be presented to the full working group at a later date on the Predictability Framework. The group is open to any current Working Group members. However, if you join the small group, you are expected to put in some time to try and resolve whatever issues remain. The small group MAY have a call or two, but the hope is that all of the work can be done in e-mail and through the documents itself. We will create a mailing list to work on these issues. This is NOT a formal group. So far, I think we captured the following people to be on this group (from the call last night): Jeff Neuman Cheryl-Langdon Orr Kathy Kleiman Christopher Wilkinson Kristina Rosette There may have been others that already volunteered, but may not have captured, so please indicate your interest to us if you want to be a part of the smaller team. We will not be doing formal consensus calls as part of this smaller group, but rather just making the proposal better and filling in the holes to present to the full working group. Please let me know if you have any questions. Best regards, Jeffrey J. Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive , Suite 600 Mclean , VA 22102 UNITED STATES T: +1.703.635.7514 M: +1.202.549.5079 CONFIRMATION OF ORDERS: Please note that we always confirm receipt of orders. To assist us in identifying orders, please use the word ORDER in the subject line of your email. If you have sent us an order and have not received confirmation on the same working day (PST) it is possible that your order has not been received or has been trapped by our spam filter. In this case, please contact your client manager or admin@comlaude.com<mailto:admin@comlaude.com> for confirmation that the order has been received and is being processed. Thank you. From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Julie Hedlund Sent: Monday, May 6, 2019 11:40 PM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 May 2019 Dear Working Group members, Please see below the notes from the meeting today, 06 May 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-05-06+New+gTLD+Subsequent+Pro.... Please also see the referenced documents at: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK.... Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Action Items: ACTION ITEM 1: Staff to incorporate edits as discussed into the 2.2.2 Predictability document. ACTION ITEM 2: Gather a small group to further develop the 2.2.2 Predictability document at: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr.... Jeff will send out a call for volunteers to the list. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson. Notes: 1. Updates to Statements of Interest (SOIs): No updates provided. 2. Review of Summary Documents – (see: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK...) a. Continued: 2.2.2 Predictability / 2.2.2.2 Clarity of Application Process: See: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr... -- Note: If we don’t come to consensus on a topic then the status quo will be as it was implemented in 2012. On the record that some do not support that approach. -- There are some different things relating to IRTs that could be new. 2.2.2 Predictability: -- Added bullet: The Predictability Model complements the existing GNSO processes and procedures and shall not in any way operate to be a substitute or replacement for those. In fact, they are incorporated into the Predictability Framework explicitly. Discussion: -- “they” references existing processes and procedures. -- To avoid any doubt in future we might want to add, “In the event of a conflict, existing GNSO processes and procedures take precedent.” -- Change from “shall not in any way operate to be” to “is not intended to be”. What are we proposing: B. Changes to ICANN Organization Internal Processes Discussion: -- Comfortable that we have a distinction for minor changes. -- For the first bullet under (b) -- re: “anything visible” -- what does that encompass? Add “change the application or any of the other processes set forth in the applicant guidebook”. Or “those parts of the application that are scored”? -- Third bullet -- New processes: Some examples have direct relevance for the entire community. Such as a new public comment platform. -- Standing IRT decides what is implementation or policy -- but some WG members disagree. -- Change to “Material adverse impact”? -- Second bullet -- “all non-minor changes” -- in written policy? Answer: The output of this whole thing will eventually be the AGB and if there are changes to the AGB they would be written. -- So not a reasonable response that a process will just take longer -- just being a communication. Seems like there should be more accountability. Add a comment/note to see if that falls under a different category. -- Filter out those things that can be dealt with in a practical matter. -- Third bullet: Need a gateway process before we get to these items. Wherever something affects the underlying rules has huge implications. -- Might need to clarify: “New public comment platform” means changes to the tools being used to submit. The rules for commenting is the same, but the platform is different. -- Second bullet: Not meant to be a change in the timing, but a change in a portal. -- Add a line after bullet three, “These proposed changes are intended to be only those that involve mechanisms with no substantive impact.” Question: How is that different from this text, “but rather a New ICANN Organization Internal Process and it is likely to have a materially [adverse] impact on applicants or community members…” Seems similar in meaning. -- An example of a change that wouldn’t be substantive but could have a material adverse impact would be requiring that Legal Rights Objections be filed through a proprietary platform instead of email. Wouldn't affect the substantive LRO (elements, standing, etc), but there may be some potential objectors that, for one reason or another, can't use that platform. -- Are timelines on filing objections seen as a different type of timeline as a third-party timeline? -- What might be a minor change for one party could be a major change to others. Adverse outcomes -- for whom? Should there be a policy gateway to determine? We don’t have a framework that would be considered to be predictable. -- If there is a gateway then that could delay any changes. -- Overriding principle is predictability. Trying to improve predictability from the last round. C. Fundamental Possible Policy Level Changes Discussion: -- Some examples seem to be out of scope for an IRT. -- Deciding something that is policy: a standing IRT can raise that issue and the GNSO Liaison can take that back to the Council. Any Council member also can raise something for consideration at the Council level. -- So a standing IRT can raise something, but only the Council can decide what is policy or implementation, but it sounds like we are setting up a separate gateway. The standing IRT cannot be the final arbiter, and the Council also can raise it directly. -- Add to the bullet point that the standing IRT can make a recommendation to the GNSO Council as to whether something is policy or implementation, but the GNSO will make the final decision. -- Ensure that this document is cross-referenced to the current policies and processes for IRTs. -- What do we mean by “Staff will collaborate with the community”? Answer: That is meant to first go to the standing IRT, which makes a recommendation for additional consideration, and then the GNSO decides how to handle it -- GNSO Input Process, EPDP, etc. -- Delete this text, “Staff will collaborate with the community to consider the issue and agree upon the mechanism by which the solution will be developed. Options could include:” And emphasize the point that this is meant to be a community+staff decision, not just staff. Mark them as redlined and to be replaced. Come back to this in another WG meeting. -- Helpful to have a workflow diagram for the Predictability Framework once concepts are agreed and reconcile with existing ones from IRT Guidelines. D. Fundamental Possible Policy Level New Proposals Discussion: -- Carry over changes from bullets under C. -- Reaching out to the community means staff reaching out to the standing IRT. But don’t think the standing IRT has the authority to decide if something is a policy or implementation change. Could have a new group that includes members of the IRT, and also Council members, and then decide if it goes to the standing IRT. -- Want to change what we call this because of previous problems with IRTs. Want to get the composition right so it is representative of the community. Meant to ensure that it is a gateway. -- A number of groups supported the recommendations in the Initial Report but also some dissenting views: ACTION: Form a smaller group to further develop this document for the full WG. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson. ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://comlaude.com> ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521. _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org<mailto:Gnso-newgtld-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg ________________________________ 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>
Hi Jeff -- thanks for encapsulating a bit of the problem and concern. We're (non-contracted parties and GAC) are not returning to our "ICANN day jobs," but to our real day jobs. It's the Contracted Parties who have "ICANN day jobs," who are paid to spend hours a day with ICANN,and hence who will be sitting on the long-standing IRT. It's an interesting addition of a word -- and underlies my concern. Also, past is prologue. Or (to reference a recent holiday): why is this IRT different from all other IRTs :-). Best regards, Kathy On 5/13/2019 2:41 PM, Jeff Neuman wrote:
Thanks Kathy. This too will be moved over for now to the smaller list (when I get it confirmed that it has been set up). In talking with a number of people, the creation of two groups seems excessive and too much bureaucracy.
If a Post-launch IRT is set up, we will have to have some level of trust that they will do the job put before them and only the job put before them. We should not set up a second group because we anticipate that the original group will naturally act beyond its mandate. If we employed that logic, then wouldn’t we need a third group to keep a watch of the second group and so on.
With respect to everyone else “returning to their ICANN day jobs”, that too should not be a problem that we would need to address. One of the biggest failures of our current system is that we as a community do not have trust in anyone else or any other group to do the right thing. This leads unfortunately to a situation where everyone believes that they need to be involved in every issue and every group. But the reality is that there are groups that are functioning well without everyone being involved in everything. The Customer Standing Committee is one example. Their job is to monitor the performance of the IANA naming function and if performance issues are not remedied, they may escalate issues to the GNSO (and ccNSO).
If we set up the group right, and we appoint responsible members to this post launch IRT, then we should trust them to do the job they are tasked with. We also should not be making assumptions that this new post-launch IRT will be dominated by contracted parties and applicants. We have the opportunity to establish the rules of this new group so that no one individual or group can control.
Best regards,
*Jeffrey J. Neuman* Senior Vice President
*Com Laude | Valideus *1751 Pinnacle Drive , Suite 600 Mclean , VA 22102 UNITED STATES
T: +1.703.635.7514 M: +1.202.549.5079
CONFIRMATION OF ORDERS: Please note that we always confirm receipt of orders. To assist us in identifying orders, please use the word ORDER in the subject line of your email. If you have sent us an order and have not received confirmation on the same working day (PST) it is possible that your order has not been received or has been trapped by our spam filter. In this case, please contact your client manager or admin@comlaude.com for confirmation that the order has been received and is being processed. Thank you.
*From:*Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> *On Behalf Of *Kathy Kleiman *Sent:* Sunday, May 12, 2019 10:54 PM *To:* gnso-newgtld-wg@icann.org *Subject:* Re: [Gnso-newgtld-wg] FW: Follow up from May 6th and CALL FOR SMALL GROUP
Hi All,
I have read the discussion taking place and I still don't think the key issues or concerns have been addressed. I'm glad that the Board, the Community, GNSO Council members, Staff and Post-Launch Standing IRT members */can raise Policy issues, Implementation issues and Policy/Implementation borderline issues. But my question is who decides what category these questions (from all these Sources) fall into? /*Someone has to look at a question and decide whether is it policy, implementation or borderline (implementation, with substantial policy implications).
To a long-standing Post-Launch Standing IRT, at work for several years, most questions will appear to be implementation. Why? Because to a hammer, almost everything is a nail. The Post-Launch Standing IRT will be geared up to solve everything as efficiently as possible -- to make everything as /"predictable for applicants" /as possible. */Good, but what about the GAC, Non-Contracted Parties and the Community? / *We (this latter group) will have returned to our other Multistakeholder Policy duties, to our other ICANN deadlines and priorities, and frankly, to our day jobs. We won't be watching when Staff flags a question to the long-standing Post-Launch Standing IRT and they flag it as "implementation" due to their focus on application processing (when it is actually policy or implementation with a heavy policy impact, e.g., systems involving the processing of public comments or Objections). I'm not saying the lack of understanding of policy implications of an issue will be intentional -- it is likely inadvertent when seen through the prism of incumbents and applicants.
How do I know this -- because virtually numerous IRTs in the last decade have -- or been strongly urged -- to rewrite policies (to rewrite consensus policies, agreed and accepted by the Multistakeholder Community & Board).
A Gateway Group will review all new questions coming through -- hopefully in conjunction with a standing group of the GNSO Council, the Community and Non-Contracted Parties, the GAC and likely, a few members of the Post-Launch Standing IRT. Especially as Staff arives with questions arising from the application & comment process (policy/implementation questions), this Gateway Group can quickly sort these questions -- pointing them in the right direction: Council or IRT. The Gateway Group should be diverse, fast and light weight. The heavier implementation work, technical detail, etc, belongs to the IRT.
Overall, IRTs are IRTs. They will be tempted (and urged) to rewrite policy; they will want to control as much as possible; for these applications, they will be dominated by contracted parties and applicants. That's the nature of the system; that's the way virtually all recent IRTs have worked; and their structure will incentivized to treat as much as "implementation" as possible. If we are going to have a Post-Launch Standing IRT, then we need one more step.
Best, Kathy
On 5/7/2019 4:05 PM, Aikman-Scalese, Anne wrote:
Dear WG members:
Regarding the smaller group assembled to work on how staff and the proposed “post-launch Standing IRT” might determine whether an issue is policy or implementation, I would like to clarify again the history that led to the existing GNSO processes designed to address these issues whenever they arise –either Pre- or –Post launch:
The Policy & Implementation Working Group grappled with this question of policy versus implementation for many months and concluded it was impossible to make determinations about that in advance because “one person’s policy is another person’s implementation”. That is exactly why we have the result we have in the form of GNSO Input (which is essentially for implementation issues), GNSO Guidance, and GNSO EPDP. In fact, it was Marika Koenigs who first suggested to the Policy & Implementation WG that, based on our case studies of issues that arose in the 2012 round, it was impossible to “predict” issues that might arise and label them as clearly policy or clearly implementation. Jeff has pointed out that applicants want more “predictability” in the process so that time delays do not result. Thus, the proposed “Predictability Framework” anticipates that ICANN staff and/or or some newly created body will be able to decide issues that arise post-launch. The “problem” Jeff is trying to resolve as Co-Chair is that if an issue reaches the GNSO, it may take too long to resolve and thus is not practical for registry applicants. However, as far as I know, we have not yet tried out these new processes (except for the EPDP on the Temp Spec) so it seems to me a bit premature to be inventing new processes and acronyms on top of the ones that have not yet been tried. *It strikes me that for various Implementation issues that actually rise to the level of an issue post-launch, the existing GNSO Input process (which has not yet been used) is adequate and is in fact designed to operate in that fashion since GNSO can raise such a concern “at any time it deems appropriate”.*
_Under existing GNSO processes established as a result of the work of the Policy & Implementation Working Group_, the “gateway” is in fact a question of the interaction between and among Staff, an IRT (or Post-launch Standing IRT), and the GNSO Council. Staff can raise an issue, IRT can raise an issue, and ANY GNSO Council member can raise an issue and so these are the “gates”. (In other words, there are multiple gates and they all ultimately lead to oversight by GNSO Council.) My own view (having worked actively in the Policy & Implementation Working Group on several case studies of issues that arose Post-Launch in the 2012 round) is that if an issue is truly implementation, no one is going to raise the issue to the level of GNSO. Issues will only rise to that level if a stakeholder believes that GNSO Council should address it and that applies whether it’s merely implementation (“GNSO Input” Annex) or involves policy (“GNSO Guidance” Annex or “GNSO EPDP” Annex).
Before the Sub Pro Initial Report issued, the Co-Chairs and staff ultimately agreed to make reference to the GNSO Input, Guidance, and EPDP processes but those processes were only referenced and footnoted, not actually explained to the ICANN community or the public. Importantly, the draft Initial Report language was clarified to delete the reference to the Standing IRT “deciding” an issue based on the Predictability Framework. Instead, in the Initial Report, there is a reference to the Standing IRT being able to “recommend” a resolution of the issue. In terms of ICANN governance and the ByLaws as modified after the Policy & Implementation WG finished its work, that is the correct stance. Establishing some other “gate” or some method for determining in advance what is policy and what is implementation when the existing processes adopted after a full WG process have not been tried does not make sense to me.
By way of additional background, the whole Policy & Implementation Working Group evolved from the fact that then-CEO Fadi Chehade decided that the “Strawman Solution” in relation to trademarks was implementation, not policy. Fadi issued a public statement to this effect. GNSO Council members were upset about this and our Co-Chair Jeff Neuman wrote the letter to the ICANN Board stating that if the Board took action (such as the Strawman Solution) that amounted to a change in policy, they had to come back to GNSO for its views on the topic and more specifically, to make a determination as to whether the topic required more policy work or merely some GNSO input.
Clearly the timing as to when an issue arises (either pre- or post- launch) is NOT a determiner of whether it is Policy or Implementation. So Chuck Gomes led the P & I WG as a result of the GNSO Council’s dissatisfaction with the handling of that issue (and others) that arose Post-Launch and we spent more than year (probably about 2 years) reviewing numerous issues that arose after applications were filed in the 2012 round. That is why the GNSO processes called Input, Guidance and EPDP were adopted by the GNSO Council and that is why the ICANN ByLaws were amended.
Hopefully the above history helps to clarify why I was quoting existing GNSO Operating Procedures and Annexes. Again, I don’t think the public understood these processes when the Initial Report issued. The current Consensus Policy Implementation Framework (“CPIF”) of the GNSO makes specific reference to these processes and requires that IRT members be briefed on them.
Anne
*From:* Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] *On Behalf Of *Jeff Neuman *Sent:* Tuesday, May 7, 2019 1:57 AM *To:* gnso-newgtld-wg@icann.org <mailto:gnso-newgtld-wg@icann.org> *Subject:* [Gnso-newgtld-wg] FW: Follow up from May 6th and CALL FOR SMALL GROUP
*[EXTERNAL]*
------------------------------------------------------------------------
All,
Following up on the call yesterday, we have revised the document on the Proposed New Predictability Model. You can find it here: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr.... The comments made during the call should be incorporated either as revised language itself, or as “comments” for draft language to be created.
As we discussed, we would like to have a smaller group dedicated to working through the issues that remain on this topic so that a more comprehensive proposal can be presented to the full working group at a later date on the Predictability Framework. The group is open to any current Working Group members. However, if you join the small group, you are expected to put in some time to try and resolve whatever issues remain. The small group MAY have a call or two, but the hope is that all of the work can be done in e-mail and through the documents itself. We will create a mailing list to work on these issues. This is NOT a formal group.
So far, I think we captured the following people to be on this group (from the call last night):
Jeff Neuman
Cheryl-Langdon Orr
Kathy Kleiman
Christopher Wilkinson
Kristina Rosette
There may have been others that already volunteered, but may not have captured, so please indicate your interest to us if you want to be a part of the smaller team.
We will not be doing formal consensus calls as part of this smaller group, but rather just making the proposal better and filling in the holes to present to the full working group.
Please let me know if you have any questions.
Best regards,
*Jeffrey J. Neuman* Senior Vice President
*Com Laude | Valideus *1751 Pinnacle Drive , Suite 600 Mclean , VA 22102 UNITED STATES T: +1.703.635.7514 M: +1.202.549.5079
CONFIRMATION OF ORDERS: Please note that we always confirm receipt of orders. To assist us in identifying orders, please use the word ORDER in the subject line of your email. If you have sent us an order and have not received confirmation on the same working day (PST) it is possible that your order has not been received or has been trapped by our spam filter. In this case, please contact your client manager or admin@comlaude.com <mailto:admin@comlaude.com> for confirmation that the order has been received and is being processed. Thank you.
*From:* Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org <mailto:gnso-newgtld-wg-bounces@icann.org>> *On Behalf Of *Julie Hedlund *Sent:* Monday, May 6, 2019 11:40 PM *To:* gnso-newgtld-wg@icann.org <mailto:gnso-newgtld-wg@icann.org> *Subject:* [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 May 2019
Dear Working Group members,
Please see below the notes from the meeting today, 06 May 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-05-06+New+gTLD+Subsequent+Pro....
Please also see the referenced documents at: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK....
Kind regards,
Julie
Julie Hedlund, Policy Director
*Notes and Action Items:*
*Action Items:*
ACTION ITEM 1: Staff to incorporate edits as discussed into the 2.2.2 Predictability document.
ACTION ITEM 2: Gather a small group to further develop the 2.2.2 Predictability document at: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr.... Jeff will send out a call for volunteers to the list. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson.
*Notes:*
1. Updates to Statements of Interest (SOIs): No updates provided.
2. Review of Summary Documents – (see: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK...)
a. Continued: 2.2.2 Predictability / 2.2.2.2 Clarity of Application Process: See: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr...
-- Note: If we don’t come to consensus on a topic then the status quo will be as it was implemented in 2012. On the record that some do not support that approach.
-- There are some different things relating to IRTs that could be new.
2.2.2 Predictability:
-- Added bullet: /The Predictability Model _complements_ the existing GNSO processes and procedures and shall not in any way operate to be a substitute or replacement for those. In fact, they are incorporated into the Predictability Framework explicitly./
_Discussion_:
-- “they” references existing processes and procedures.
-- To avoid any doubt in future we might want to add, “In the event of a conflict, existing GNSO processes and procedures take precedent.”
-- Change from “shall not in any way operate to be” to “is not intended to be”.
What are we proposing:
_B. Changes to ICANN Organization Internal Processes_
_Discussion:_
-- Comfortable that we have a distinction for minor changes.
-- For the first bullet under (b) -- re: “anything visible” -- what does that encompass? Add “change the application or any of the other processes set forth in the applicant guidebook”. Or “those parts of the application that are scored”?
-- Third bullet -- New processes: Some examples have direct relevance for the entire community. Such as a new public comment platform.
-- Standing IRT decides what is implementation or policy -- but some WG members disagree.
-- Change to “Material adverse impact”?
-- Second bullet -- “all non-minor changes” -- in written policy? Answer: The output of this whole thing will eventually be the AGB and if there are changes to the AGB they would be written.
-- So not a reasonable response that a process will just take longer -- just being a communication. Seems like there should be more accountability. Add a comment/note to see if that falls under a different category.
-- Filter out those things that can be dealt with in a practical matter.
-- Third bullet: Need a gateway process before we get to these items. Wherever something affects the underlying rules has huge implications.
-- Might need to clarify: “New public comment platform” means changes to the tools being used to submit. The rules for commenting is the same, but the platform is different.
-- Second bullet: Not meant to be a change in the timing, but a change in a portal.
-- Add a line after bullet three, “These proposed changes are intended to be only those that involve mechanisms with no substantive impact.” Question: How is that different from this text, “but rather a New ICANN Organization Internal Process and it is likely to have a materially [adverse] impact on applicants or community members…” Seems similar in meaning.
-- An example of a change that wouldn’t be substantive but could have a material adverse impact would be requiring that Legal Rights Objections be filed through a proprietary platform instead of email. Wouldn't affect the substantive LRO (elements, standing, etc), but there may be some potential objectors that, for one reason or another, can't use that platform.
-- Are timelines on filing objections seen as a different type of timeline as a third-party timeline?
-- What might be a minor change for one party could be a major change to others. Adverse outcomes -- for whom? Should there be a policy gateway to determine? We don’t have a framework that would be considered to be predictable.
-- If there is a gateway then that could delay any changes.
-- Overriding principle is predictability. Trying to improve predictability from the last round.
C. _Fundamental Possible Policy Level Changes_
_Discussion:_
-- Some examples seem to be out of scope for an IRT.
-- Deciding something that is policy: a standing IRT can raise that issue and the GNSO Liaison can take that back to the Council. Any Council member also can raise something for consideration at the Council level.
-- So a standing IRT can raise something, but only the Council can decide what is policy or implementation, but it sounds like we are setting up a separate gateway. The standing IRT cannot be the final arbiter, and the Council also can raise it directly.
-- Add to the bullet point that the standing IRT can make a recommendation to the GNSO Council as to whether something is policy or implementation, but the GNSO will make the final decision.
-- Ensure that this document is cross-referenced to the current policies and processes for IRTs.
-- What do we mean by “Staff will collaborate with the community”? Answer: That is meant to first go to the standing IRT, which makes a recommendation for additional consideration, and then the GNSO decides how to handle it -- GNSO Input Process, EPDP, etc.
-- Delete this text, “Staff will collaborate with the community to consider the issue and agree upon the mechanism by which the solution will be developed. Options could include:” And emphasize the point that this is meant to be a community+staff decision, not just staff. Mark them as redlined and to be replaced. Come back to this in another WG meeting.
-- Helpful to have a workflow diagram for the Predictability Framework once concepts are agreed and reconcile with existing ones from IRT Guidelines.
D. _Fundamental Possible Policy Level New Proposals_
_Discussion_:
-- Carry over changes from bullets under C.
-- Reaching out to the community means staff reaching out to the standing IRT. But don’t think the standing IRT has the authority to decide if something is a policy or implementation change. Could have a new group that includes members of the IRT, and also Council members, and then decide if it goes to the standing IRT.
-- Want to change what we call this because of previous problems with IRTs. Want to get the composition right so it is representative of the community. Meant to ensure that it is a gateway.
-- A number of groups supported the recommendations in the Initial Report but also some dissenting views: ACTION: Form a smaller group to further develop this document for the full WG. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson.
------------------------------------------------------------------------
The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com <https://comlaude.com>
------------------------------------------------------------------------
This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
_______________________________________________
Gnso-newgtld-wg mailing list
Gnso-newgtld-wg@icann.org <mailto:Gnso-newgtld-wg@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg
------------------------------------------------------------------------ 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>
Dear WG Members, Please note that the Predictability Framework small team mailing list has been created and shortly after you receive this note, members of that small team (see membership here: https://community.icann.org/display/NGSPP/Members+New+gTLD+Predictability+Fr...) will get a welcome message that invites them to continue this conversation on that new list. If you are interested in joining the team, please send a note to staff (gnso-secs@icann.org) as soon as possible and we will be happy to get you signed up. Best, Steve From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> on behalf of Kathy Kleiman <kathy@kathykleiman.com> Date: Monday, May 13, 2019 at 12:39 PM To: Jeff Neuman <jeff.neuman@comlaude.com>, "gnso-newgtld-wg@icann.org" <gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] FW: Follow up from May 6th and CALL FOR SMALL GROUP Hi Jeff -- thanks for encapsulating a bit of the problem and concern. We're (non-contracted parties and GAC) are not returning to our "ICANN day jobs," but to our real day jobs. It's the Contracted Parties who have "ICANN day jobs," who are paid to spend hours a day with ICANN,and hence who will be sitting on the long-standing IRT. It's an interesting addition of a word -- and underlies my concern. Also, past is prologue. Or (to reference a recent holiday): why is this IRT different from all other IRTs :-). Best regards, Kathy On 5/13/2019 2:41 PM, Jeff Neuman wrote: Thanks Kathy. This too will be moved over for now to the smaller list (when I get it confirmed that it has been set up). In talking with a number of people, the creation of two groups seems excessive and too much bureaucracy. If a Post-launch IRT is set up, we will have to have some level of trust that they will do the job put before them and only the job put before them. We should not set up a second group because we anticipate that the original group will naturally act beyond its mandate. If we employed that logic, then wouldn’t we need a third group to keep a watch of the second group and so on. With respect to everyone else “returning to their ICANN day jobs”, that too should not be a problem that we would need to address. One of the biggest failures of our current system is that we as a community do not have trust in anyone else or any other group to do the right thing. This leads unfortunately to a situation where everyone believes that they need to be involved in every issue and every group. But the reality is that there are groups that are functioning well without everyone being involved in everything. The Customer Standing Committee is one example. Their job is to monitor the performance of the IANA naming function and if performance issues are not remedied, they may escalate issues to the GNSO (and ccNSO). If we set up the group right, and we appoint responsible members to this post launch IRT, then we should trust them to do the job they are tasked with. We also should not be making assumptions that this new post-launch IRT will be dominated by contracted parties and applicants. We have the opportunity to establish the rules of this new group so that no one individual or group can control. Best regards, Jeffrey J. Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive , Suite 600 Mclean , VA 22102 UNITED STATES T: +1.703.635.7514 M: +1.202.549.5079 CONFIRMATION OF ORDERS: Please note that we always confirm receipt of orders. To assist us in identifying orders, please use the word ORDER in the subject line of your email. If you have sent us an order and have not received confirmation on the same working day (PST) it is possible that your order has not been received or has been trapped by our spam filter. In this case, please contact your client manager or admin@comlaude.com for confirmation that the order has been received and is being processed. Thank you. From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Kathy Kleiman Sent: Sunday, May 12, 2019 10:54 PM To: gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] FW: Follow up from May 6th and CALL FOR SMALL GROUP Hi All, I have read the discussion taking place and I still don't think the key issues or concerns have been addressed. I'm glad that the Board, the Community, GNSO Council members, Staff and Post-Launch Standing IRT members can raise Policy issues, Implementation issues and Policy/Implementation borderline issues. But my question is who decides what category these questions (from all these Sources) fall into? Someone has to look at a question and decide whether is it policy, implementation or borderline (implementation, with substantial policy implications). To a long-standing Post-Launch Standing IRT, at work for several years, most questions will appear to be implementation. Why? Because to a hammer, almost everything is a nail. The Post-Launch Standing IRT will be geared up to solve everything as efficiently as possible -- to make everything as "predictable for applicants" as possible. Good, but what about the GAC, Non-Contracted Parties and the Community? We (this latter group) will have returned to our other Multistakeholder Policy duties, to our other ICANN deadlines and priorities, and frankly, to our day jobs. We won't be watching when Staff flags a question to the long-standing Post-Launch Standing IRT and they flag it as "implementation" due to their focus on application processing (when it is actually policy or implementation with a heavy policy impact, e.g., systems involving the processing of public comments or Objections). I'm not saying the lack of understanding of policy implications of an issue will be intentional -- it is likely inadvertent when seen through the prism of incumbents and applicants. How do I know this -- because virtually numerous IRTs in the last decade have -- or been strongly urged -- to rewrite policies (to rewrite consensus policies, agreed and accepted by the Multistakeholder Community & Board). A Gateway Group will review all new questions coming through -- hopefully in conjunction with a standing group of the GNSO Council, the Community and Non-Contracted Parties, the GAC and likely, a few members of the Post-Launch Standing IRT. Especially as Staff arives with questions arising from the application & comment process (policy/implementation questions), this Gateway Group can quickly sort these questions -- pointing them in the right direction: Council or IRT. The Gateway Group should be diverse, fast and light weight. The heavier implementation work, technical detail, etc, belongs to the IRT. Overall, IRTs are IRTs. They will be tempted (and urged) to rewrite policy; they will want to control as much as possible; for these applications, they will be dominated by contracted parties and applicants. That's the nature of the system; that's the way virtually all recent IRTs have worked; and their structure will incentivized to treat as much as "implementation" as possible. If we are going to have a Post-Launch Standing IRT, then we need one more step. Best, Kathy On 5/7/2019 4:05 PM, Aikman-Scalese, Anne wrote: Dear WG members: Regarding the smaller group assembled to work on how staff and the proposed “post-launch Standing IRT” might determine whether an issue is policy or implementation, I would like to clarify again the history that led to the existing GNSO processes designed to address these issues whenever they arise –either Pre- or –Post launch: The Policy & Implementation Working Group grappled with this question of policy versus implementation for many months and concluded it was impossible to make determinations about that in advance because “one person’s policy is another person’s implementation”. That is exactly why we have the result we have in the form of GNSO Input (which is essentially for implementation issues), GNSO Guidance, and GNSO EPDP. In fact, it was Marika Koenigs who first suggested to the Policy & Implementation WG that, based on our case studies of issues that arose in the 2012 round, it was impossible to “predict” issues that might arise and label them as clearly policy or clearly implementation. Jeff has pointed out that applicants want more “predictability” in the process so that time delays do not result. Thus, the proposed “Predictability Framework” anticipates that ICANN staff and/or or some newly created body will be able to decide issues that arise post-launch. The “problem” Jeff is trying to resolve as Co-Chair is that if an issue reaches the GNSO, it may take too long to resolve and thus is not practical for registry applicants. However, as far as I know, we have not yet tried out these new processes (except for the EPDP on the Temp Spec) so it seems to me a bit premature to be inventing new processes and acronyms on top of the ones that have not yet been tried. It strikes me that for various Implementation issues that actually rise to the level of an issue post-launch, the existing GNSO Input process (which has not yet been used) is adequate and is in fact designed to operate in that fashion since GNSO can raise such a concern “at any time it deems appropriate”. Under existing GNSO processes established as a result of the work of the Policy & Implementation Working Group, the “gateway” is in fact a question of the interaction between and among Staff, an IRT (or Post-launch Standing IRT), and the GNSO Council. Staff can raise an issue, IRT can raise an issue, and ANY GNSO Council member can raise an issue and so these are the “gates”. (In other words, there are multiple gates and they all ultimately lead to oversight by GNSO Council.) My own view (having worked actively in the Policy & Implementation Working Group on several case studies of issues that arose Post-Launch in the 2012 round) is that if an issue is truly implementation, no one is going to raise the issue to the level of GNSO. Issues will only rise to that level if a stakeholder believes that GNSO Council should address it and that applies whether it’s merely implementation (“GNSO Input” Annex) or involves policy (“GNSO Guidance” Annex or “GNSO EPDP” Annex). Before the Sub Pro Initial Report issued, the Co-Chairs and staff ultimately agreed to make reference to the GNSO Input, Guidance, and EPDP processes but those processes were only referenced and footnoted, not actually explained to the ICANN community or the public. Importantly, the draft Initial Report language was clarified to delete the reference to the Standing IRT “deciding” an issue based on the Predictability Framework. Instead, in the Initial Report, there is a reference to the Standing IRT being able to “recommend” a resolution of the issue. In terms of ICANN governance and the ByLaws as modified after the Policy & Implementation WG finished its work, that is the correct stance. Establishing some other “gate” or some method for determining in advance what is policy and what is implementation when the existing processes adopted after a full WG process have not been tried does not make sense to me. By way of additional background, the whole Policy & Implementation Working Group evolved from the fact that then-CEO Fadi Chehade decided that the “Strawman Solution” in relation to trademarks was implementation, not policy. Fadi issued a public statement to this effect. GNSO Council members were upset about this and our Co-Chair Jeff Neuman wrote the letter to the ICANN Board stating that if the Board took action (such as the Strawman Solution) that amounted to a change in policy, they had to come back to GNSO for its views on the topic and more specifically, to make a determination as to whether the topic required more policy work or merely some GNSO input. Clearly the timing as to when an issue arises (either pre- or post- launch) is NOT a determiner of whether it is Policy or Implementation. So Chuck Gomes led the P & I WG as a result of the GNSO Council’s dissatisfaction with the handling of that issue (and others) that arose Post-Launch and we spent more than year (probably about 2 years) reviewing numerous issues that arose after applications were filed in the 2012 round. That is why the GNSO processes called Input, Guidance and EPDP were adopted by the GNSO Council and that is why the ICANN ByLaws were amended. Hopefully the above history helps to clarify why I was quoting existing GNSO Operating Procedures and Annexes. Again, I don’t think the public understood these processes when the Initial Report issued. The current Consensus Policy Implementation Framework (“CPIF”) of the GNSO makes specific reference to these processes and requires that IRT members be briefed on them. Anne From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Jeff Neuman Sent: Tuesday, May 7, 2019 1:57 AM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] FW: Follow up from May 6th and CALL FOR SMALL GROUP [EXTERNAL] All, Following up on the call yesterday, we have revised the document on the Proposed New Predictability Model. You can find it here: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr.... The comments made during the call should be incorporated either as revised language itself, or as “comments” for draft language to be created. As we discussed, we would like to have a smaller group dedicated to working through the issues that remain on this topic so that a more comprehensive proposal can be presented to the full working group at a later date on the Predictability Framework. The group is open to any current Working Group members. However, if you join the small group, you are expected to put in some time to try and resolve whatever issues remain. The small group MAY have a call or two, but the hope is that all of the work can be done in e-mail and through the documents itself. We will create a mailing list to work on these issues. This is NOT a formal group. So far, I think we captured the following people to be on this group (from the call last night): Jeff Neuman Cheryl-Langdon Orr Kathy Kleiman Christopher Wilkinson Kristina Rosette There may have been others that already volunteered, but may not have captured, so please indicate your interest to us if you want to be a part of the smaller team. We will not be doing formal consensus calls as part of this smaller group, but rather just making the proposal better and filling in the holes to present to the full working group. Please let me know if you have any questions. Best regards, Jeffrey J. Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive , Suite 600 Mclean , VA 22102 UNITED STATES T: +1.703.635.7514 M: +1.202.549.5079 CONFIRMATION OF ORDERS: Please note that we always confirm receipt of orders. To assist us in identifying orders, please use the word ORDER in the subject line of your email. If you have sent us an order and have not received confirmation on the same working day (PST) it is possible that your order has not been received or has been trapped by our spam filter. In this case, please contact your client manager or admin@comlaude.com for confirmation that the order has been received and is being processed. Thank you. From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Julie Hedlund Sent: Monday, May 6, 2019 11:40 PM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 May 2019 Dear Working Group members, Please see below the notes from the meeting today, 06 May 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-05-06+New+gTLD+Subsequent+Pro.... Please also see the referenced documents at: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK.... Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Action Items: ACTION ITEM 1: Staff to incorporate edits as discussed into the 2.2.2 Predictability document. ACTION ITEM 2: Gather a small group to further develop the 2.2.2 Predictability document at: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr.... Jeff will send out a call for volunteers to the list. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson. Notes: 1. Updates to Statements of Interest (SOIs): No updates provided. 2. Review of Summary Documents – (see: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK...) a. Continued: 2.2.2 Predictability / 2.2.2.2 Clarity of Application Process: See: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr... -- Note: If we don’t come to consensus on a topic then the status quo will be as it was implemented in 2012. On the record that some do not support that approach. -- There are some different things relating to IRTs that could be new. 2.2.2 Predictability: -- Added bullet: The Predictability Model complements the existing GNSO processes and procedures and shall not in any way operate to be a substitute or replacement for those. In fact, they are incorporated into the Predictability Framework explicitly. Discussion: -- “they” references existing processes and procedures. -- To avoid any doubt in future we might want to add, “In the event of a conflict, existing GNSO processes and procedures take precedent.” -- Change from “shall not in any way operate to be” to “is not intended to be”. What are we proposing: B. Changes to ICANN Organization Internal Processes Discussion: -- Comfortable that we have a distinction for minor changes. -- For the first bullet under (b) -- re: “anything visible” -- what does that encompass? Add “change the application or any of the other processes set forth in the applicant guidebook”. Or “those parts of the application that are scored”? -- Third bullet -- New processes: Some examples have direct relevance for the entire community. Such as a new public comment platform. -- Standing IRT decides what is implementation or policy -- but some WG members disagree. -- Change to “Material adverse impact”? -- Second bullet -- “all non-minor changes” -- in written policy? Answer: The output of this whole thing will eventually be the AGB and if there are changes to the AGB they would be written. -- So not a reasonable response that a process will just take longer -- just being a communication. Seems like there should be more accountability. Add a comment/note to see if that falls under a different category. -- Filter out those things that can be dealt with in a practical matter. -- Third bullet: Need a gateway process before we get to these items. Wherever something affects the underlying rules has huge implications. -- Might need to clarify: “New public comment platform” means changes to the tools being used to submit. The rules for commenting is the same, but the platform is different. -- Second bullet: Not meant to be a change in the timing, but a change in a portal. -- Add a line after bullet three, “These proposed changes are intended to be only those that involve mechanisms with no substantive impact.” Question: How is that different from this text, “but rather a New ICANN Organization Internal Process and it is likely to have a materially [adverse] impact on applicants or community members…” Seems similar in meaning. -- An example of a change that wouldn’t be substantive but could have a material adverse impact would be requiring that Legal Rights Objections be filed through a proprietary platform instead of email. Wouldn't affect the substantive LRO (elements, standing, etc), but there may be some potential objectors that, for one reason or another, can't use that platform. -- Are timelines on filing objections seen as a different type of timeline as a third-party timeline? -- What might be a minor change for one party could be a major change to others. Adverse outcomes -- for whom? Should there be a policy gateway to determine? We don’t have a framework that would be considered to be predictable. -- If there is a gateway then that could delay any changes. -- Overriding principle is predictability. Trying to improve predictability from the last round. C. Fundamental Possible Policy Level Changes Discussion: -- Some examples seem to be out of scope for an IRT. -- Deciding something that is policy: a standing IRT can raise that issue and the GNSO Liaison can take that back to the Council. Any Council member also can raise something for consideration at the Council level. -- So a standing IRT can raise something, but only the Council can decide what is policy or implementation, but it sounds like we are setting up a separate gateway. The standing IRT cannot be the final arbiter, and the Council also can raise it directly. -- Add to the bullet point that the standing IRT can make a recommendation to the GNSO Council as to whether something is policy or implementation, but the GNSO will make the final decision. -- Ensure that this document is cross-referenced to the current policies and processes for IRTs. -- What do we mean by “Staff will collaborate with the community”? Answer: That is meant to first go to the standing IRT, which makes a recommendation for additional consideration, and then the GNSO decides how to handle it -- GNSO Input Process, EPDP, etc. -- Delete this text, “Staff will collaborate with the community to consider the issue and agree upon the mechanism by which the solution will be developed. Options could include:” And emphasize the point that this is meant to be a community+staff decision, not just staff. Mark them as redlined and to be replaced. Come back to this in another WG meeting. -- Helpful to have a workflow diagram for the Predictability Framework once concepts are agreed and reconcile with existing ones from IRT Guidelines. D. Fundamental Possible Policy Level New Proposals Discussion: -- Carry over changes from bullets under C. -- Reaching out to the community means staff reaching out to the standing IRT. But don’t think the standing IRT has the authority to decide if something is a policy or implementation change. Could have a new group that includes members of the IRT, and also Council members, and then decide if it goes to the standing IRT. -- Want to change what we call this because of previous problems with IRTs. Want to get the composition right so it is representative of the community. Meant to ensure that it is a gateway. -- A number of groups supported the recommendations in the Initial Report but also some dissenting views: ACTION: Form a smaller group to further develop this document for the full WG. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson. The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521. _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg 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
All, Sorry it has taken me a while to respond as I was out at the GDD Summit. We will discuss these issues when the smaller group is convened. I just want to state that there are a number of assumptions in this e-mail which I am not sure that I agree with. I think what is missing from this analysis, though thorough from a historical perspective, are the core issues that arise because of the new gTLD program that make it very different from any of the other GNSO activities. More specifically are those issues that are neither policy, nor derived from the policy, but are issues nonetheless that need to be addressed. And those are not necessarily within the scope of any of the existing or new GNSO Processes. But that is the discussion we will have within the smaller group. For today we move on to the next issues. Jeffrey J. Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive , Suite 600 Mclean , VA 22102 UNITED STATES T: +1.703.635.7514 M: +1.202.549.5079 CONFIRMATION OF ORDERS: Please note that we always confirm receipt of orders. To assist us in identifying orders, please use the word ORDER in the subject line of your email. If you have sent us an order and have not received confirmation on the same working day (PST) it is possible that your order has not been received or has been trapped by our spam filter. In this case, please contact your client manager or admin@comlaude.com for confirmation that the order has been received and is being processed. Thank you. From: Aikman-Scalese, Anne <AAikman@lrrc.com> Sent: Tuesday, May 7, 2019 4:06 PM To: Jeff Neuman <jeff.neuman@comlaude.com>; gnso-newgtld-wg@icann.org Subject: RE: [Gnso-newgtld-wg] FW: Follow up from May 6th and CALL FOR SMALL GROUP Dear WG members: Regarding the smaller group assembled to work on how staff and the proposed “post-launch Standing IRT” might determine whether an issue is policy or implementation, I would like to clarify again the history that led to the existing GNSO processes designed to address these issues whenever they arise –either Pre- or –Post launch: The Policy & Implementation Working Group grappled with this question of policy versus implementation for many months and concluded it was impossible to make determinations about that in advance because “one person’s policy is another person’s implementation”. That is exactly why we have the result we have in the form of GNSO Input (which is essentially for implementation issues), GNSO Guidance, and GNSO EPDP. In fact, it was Marika Koenigs who first suggested to the Policy & Implementation WG that, based on our case studies of issues that arose in the 2012 round, it was impossible to “predict” issues that might arise and label them as clearly policy or clearly implementation. Jeff has pointed out that applicants want more “predictability” in the process so that time delays do not result. Thus, the proposed “Predictability Framework” anticipates that ICANN staff and/or or some newly created body will be able to decide issues that arise post-launch. The “problem” Jeff is trying to resolve as Co-Chair is that if an issue reaches the GNSO, it may take too long to resolve and thus is not practical for registry applicants. However, as far as I know, we have not yet tried out these new processes (except for the EPDP on the Temp Spec) so it seems to me a bit premature to be inventing new processes and acronyms on top of the ones that have not yet been tried. It strikes me that for various Implementation issues that actually rise to the level of an issue post-launch, the existing GNSO Input process (which has not yet been used) is adequate and is in fact designed to operate in that fashion since GNSO can raise such a concern “at any time it deems appropriate”. Under existing GNSO processes established as a result of the work of the Policy & Implementation Working Group, the “gateway” is in fact a question of the interaction between and among Staff, an IRT (or Post-launch Standing IRT), and the GNSO Council. Staff can raise an issue, IRT can raise an issue, and ANY GNSO Council member can raise an issue and so these are the “gates”. (In other words, there are multiple gates and they all ultimately lead to oversight by GNSO Council.) My own view (having worked actively in the Policy & Implementation Working Group on several case studies of issues that arose Post-Launch in the 2012 round) is that if an issue is truly implementation, no one is going to raise the issue to the level of GNSO. Issues will only rise to that level if a stakeholder believes that GNSO Council should address it and that applies whether it’s merely implementation (“GNSO Input” Annex) or involves policy (“GNSO Guidance” Annex or “GNSO EPDP” Annex). Before the Sub Pro Initial Report issued, the Co-Chairs and staff ultimately agreed to make reference to the GNSO Input, Guidance, and EPDP processes but those processes were only referenced and footnoted, not actually explained to the ICANN community or the public. Importantly, the draft Initial Report language was clarified to delete the reference to the Standing IRT “deciding” an issue based on the Predictability Framework. Instead, in the Initial Report, there is a reference to the Standing IRT being able to “recommend” a resolution of the issue. In terms of ICANN governance and the ByLaws as modified after the Policy & Implementation WG finished its work, that is the correct stance. Establishing some other “gate” or some method for determining in advance what is policy and what is implementation when the existing processes adopted after a full WG process have not been tried does not make sense to me. By way of additional background, the whole Policy & Implementation Working Group evolved from the fact that then-CEO Fadi Chehade decided that the “Strawman Solution” in relation to trademarks was implementation, not policy. Fadi issued a public statement to this effect. GNSO Council members were upset about this and our Co-Chair Jeff Neuman wrote the letter to the ICANN Board stating that if the Board took action (such as the Strawman Solution) that amounted to a change in policy, they had to come back to GNSO for its views on the topic and more specifically, to make a determination as to whether the topic required more policy work or merely some GNSO input. Clearly the timing as to when an issue arises (either pre- or post- launch) is NOT a determiner of whether it is Policy or Implementation. So Chuck Gomes led the P & I WG as a result of the GNSO Council’s dissatisfaction with the handling of that issue (and others) that arose Post-Launch and we spent more than year (probably about 2 years) reviewing numerous issues that arose after applications were filed in the 2012 round. That is why the GNSO processes called Input, Guidance and EPDP were adopted by the GNSO Council and that is why the ICANN ByLaws were amended. Hopefully the above history helps to clarify why I was quoting existing GNSO Operating Procedures and Annexes. Again, I don’t think the public understood these processes when the Initial Report issued. The current Consensus Policy Implementation Framework (“CPIF”) of the GNSO makes specific reference to these processes and requires that IRT members be briefed on them. Anne From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Jeff Neuman Sent: Tuesday, May 7, 2019 1:57 AM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] FW: Follow up from May 6th and CALL FOR SMALL GROUP [EXTERNAL] ________________________________ All, Following up on the call yesterday, we have revised the document on the Proposed New Predictability Model. You can find it here: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr.... The comments made during the call should be incorporated either as revised language itself, or as “comments” for draft language to be created. As we discussed, we would like to have a smaller group dedicated to working through the issues that remain on this topic so that a more comprehensive proposal can be presented to the full working group at a later date on the Predictability Framework. The group is open to any current Working Group members. However, if you join the small group, you are expected to put in some time to try and resolve whatever issues remain. The small group MAY have a call or two, but the hope is that all of the work can be done in e-mail and through the documents itself. We will create a mailing list to work on these issues. This is NOT a formal group. So far, I think we captured the following people to be on this group (from the call last night): Jeff Neuman Cheryl-Langdon Orr Kathy Kleiman Christopher Wilkinson Kristina Rosette There may have been others that already volunteered, but may not have captured, so please indicate your interest to us if you want to be a part of the smaller team. We will not be doing formal consensus calls as part of this smaller group, but rather just making the proposal better and filling in the holes to present to the full working group. Please let me know if you have any questions. Best regards, Jeffrey J. Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive , Suite 600 Mclean , VA 22102 UNITED STATES T: +1.703.635.7514 M: +1.202.549.5079 CONFIRMATION OF ORDERS: Please note that we always confirm receipt of orders. To assist us in identifying orders, please use the word ORDER in the subject line of your email. If you have sent us an order and have not received confirmation on the same working day (PST) it is possible that your order has not been received or has been trapped by our spam filter. In this case, please contact your client manager or admin@comlaude.com<mailto:admin@comlaude.com> for confirmation that the order has been received and is being processed. Thank you. From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Julie Hedlund Sent: Monday, May 6, 2019 11:40 PM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 May 2019 Dear Working Group members, Please see below the notes from the meeting today, 06 May 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-05-06+New+gTLD+Subsequent+Pro.... Please also see the referenced documents at: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK.... Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Action Items: ACTION ITEM 1: Staff to incorporate edits as discussed into the 2.2.2 Predictability document. ACTION ITEM 2: Gather a small group to further develop the 2.2.2 Predictability document at: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr.... Jeff will send out a call for volunteers to the list. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson. Notes: 1. Updates to Statements of Interest (SOIs): No updates provided. 2. Review of Summary Documents – (see: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK...) a. Continued: 2.2.2 Predictability / 2.2.2.2 Clarity of Application Process: See: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr... -- Note: If we don’t come to consensus on a topic then the status quo will be as it was implemented in 2012. On the record that some do not support that approach. -- There are some different things relating to IRTs that could be new. 2.2.2 Predictability: -- Added bullet: The Predictability Model complements the existing GNSO processes and procedures and shall not in any way operate to be a substitute or replacement for those. In fact, they are incorporated into the Predictability Framework explicitly. Discussion: -- “they” references existing processes and procedures. -- To avoid any doubt in future we might want to add, “In the event of a conflict, existing GNSO processes and procedures take precedent.” -- Change from “shall not in any way operate to be” to “is not intended to be”. What are we proposing: B. Changes to ICANN Organization Internal Processes Discussion: -- Comfortable that we have a distinction for minor changes. -- For the first bullet under (b) -- re: “anything visible” -- what does that encompass? Add “change the application or any of the other processes set forth in the applicant guidebook”. Or “those parts of the application that are scored”? -- Third bullet -- New processes: Some examples have direct relevance for the entire community. Such as a new public comment platform. -- Standing IRT decides what is implementation or policy -- but some WG members disagree. -- Change to “Material adverse impact”? -- Second bullet -- “all non-minor changes” -- in written policy? Answer: The output of this whole thing will eventually be the AGB and if there are changes to the AGB they would be written. -- So not a reasonable response that a process will just take longer -- just being a communication. Seems like there should be more accountability. Add a comment/note to see if that falls under a different category. -- Filter out those things that can be dealt with in a practical matter. -- Third bullet: Need a gateway process before we get to these items. Wherever something affects the underlying rules has huge implications. -- Might need to clarify: “New public comment platform” means changes to the tools being used to submit. The rules for commenting is the same, but the platform is different. -- Second bullet: Not meant to be a change in the timing, but a change in a portal. -- Add a line after bullet three, “These proposed changes are intended to be only those that involve mechanisms with no substantive impact.” Question: How is that different from this text, “but rather a New ICANN Organization Internal Process and it is likely to have a materially [adverse] impact on applicants or community members…” Seems similar in meaning. -- An example of a change that wouldn’t be substantive but could have a material adverse impact would be requiring that Legal Rights Objections be filed through a proprietary platform instead of email. Wouldn't affect the substantive LRO (elements, standing, etc), but there may be some potential objectors that, for one reason or another, can't use that platform. -- Are timelines on filing objections seen as a different type of timeline as a third-party timeline? -- What might be a minor change for one party could be a major change to others. Adverse outcomes -- for whom? Should there be a policy gateway to determine? We don’t have a framework that would be considered to be predictable. -- If there is a gateway then that could delay any changes. -- Overriding principle is predictability. Trying to improve predictability from the last round. C. Fundamental Possible Policy Level Changes Discussion: -- Some examples seem to be out of scope for an IRT. -- Deciding something that is policy: a standing IRT can raise that issue and the GNSO Liaison can take that back to the Council. Any Council member also can raise something for consideration at the Council level. -- So a standing IRT can raise something, but only the Council can decide what is policy or implementation, but it sounds like we are setting up a separate gateway. The standing IRT cannot be the final arbiter, and the Council also can raise it directly. -- Add to the bullet point that the standing IRT can make a recommendation to the GNSO Council as to whether something is policy or implementation, but the GNSO will make the final decision. -- Ensure that this document is cross-referenced to the current policies and processes for IRTs. -- What do we mean by “Staff will collaborate with the community”? Answer: That is meant to first go to the standing IRT, which makes a recommendation for additional consideration, and then the GNSO decides how to handle it -- GNSO Input Process, EPDP, etc. -- Delete this text, “Staff will collaborate with the community to consider the issue and agree upon the mechanism by which the solution will be developed. Options could include:” And emphasize the point that this is meant to be a community+staff decision, not just staff. Mark them as redlined and to be replaced. Come back to this in another WG meeting. -- Helpful to have a workflow diagram for the Predictability Framework once concepts are agreed and reconcile with existing ones from IRT Guidelines. D. Fundamental Possible Policy Level New Proposals Discussion: -- Carry over changes from bullets under C. -- Reaching out to the community means staff reaching out to the standing IRT. But don’t think the standing IRT has the authority to decide if something is a policy or implementation change. Could have a new group that includes members of the IRT, and also Council members, and then decide if it goes to the standing IRT. -- Want to change what we call this because of previous problems with IRTs. Want to get the composition right so it is representative of the community. Meant to ensure that it is a gateway. -- A number of groups supported the recommendations in the Initial Report but also some dissenting views: ACTION: Form a smaller group to further develop this document for the full WG. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson. ________________________________ 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>
HI Jeff – It always seemed to me that the “checks and balances” on implementation were the organizations governance powers left to both GNSO Council to raise an issue at any time (GNSO Input) and to take up a policy issue at any time via GNSO Guidance and GNSO EPDP. The GAC’s mechanism is Consensus Public Policy advice. In other words, if the GAC thinks an issue which arises in the implementation phase is a policy issue, it takes up that issue and provides Consensus Advise to the Board. Again I think most post-launch issues that actually ARE implementation and don’t involve policy deliberations will never “cause a stir” and will never need to rise to the GNSO or GAC level. But you can count on the fact that with proper representation on a Post-Launch Standing IRT, if there is a policy issue involved, it will get visibility as long as the IRT itself is properly constituted. My view is that adding some broader “Gateway Group” will not be “light and fast” in nature and will just create another hoop to jump through. The Standing IRT is the appropriate “hoop” itself and it does not have the power to make policy – not at all. If IRTs have been making policy, it’s because they have not been sufficiently representative or people have not been watching carefully enough what they were doing and then bringing that to GNSO Council. I think that if you create a new “Gateway Group” to decide what is policy and what is implementation, the whole notion of making implementation decisions “easier and faster” backfires. We have already added language that states that the GNSO Procedures override anything the Predictability Framework seeks to determine – in the event of any conflict on the determination, any single member of GNSO can step in and have the issue dealt with there. The TRUE issue at stake for the small group in my mind is the proper composition of the Standing IRT. Maybe Geo names require separate handling but I am not familiar enough with the issues there to express an opinion on that. Again, if governments are represented on the Standing IRT, then I think the problem takes care of itself. I would also include the GNSO Council liaison to the GAC on the Standing IRT. Anne From: Jeff Neuman [mailto:jeff.neuman@comlaude.com] Sent: Monday, May 13, 2019 11:20 AM To: Aikman-Scalese, Anne <AAikman@lrrc.com>; gnso-newgtld-wg@icann.org Subject: RE: [Gnso-newgtld-wg] FW: Follow up from May 6th and CALL FOR SMALL GROUP [EXTERNAL] ________________________________ All, Sorry it has taken me a while to respond as I was out at the GDD Summit. We will discuss these issues when the smaller group is convened. I just want to state that there are a number of assumptions in this e-mail which I am not sure that I agree with. I think what is missing from this analysis, though thorough from a historical perspective, are the core issues that arise because of the new gTLD program that make it very different from any of the other GNSO activities. More specifically are those issues that are neither policy, nor derived from the policy, but are issues nonetheless that need to be addressed. And those are not necessarily within the scope of any of the existing or new GNSO Processes. But that is the discussion we will have within the smaller group. For today we move on to the next issues. Jeffrey J. Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive , Suite 600 Mclean , VA 22102 UNITED STATES T: +1.703.635.7514 M: +1.202.549.5079 CONFIRMATION OF ORDERS: Please note that we always confirm receipt of orders. To assist us in identifying orders, please use the word ORDER in the subject line of your email. If you have sent us an order and have not received confirmation on the same working day (PST) it is possible that your order has not been received or has been trapped by our spam filter. In this case, please contact your client manager or admin@comlaude.com<mailto:admin@comlaude.com> for confirmation that the order has been received and is being processed. Thank you. From: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> Sent: Tuesday, May 7, 2019 4:06 PM To: Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com>>; gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: RE: [Gnso-newgtld-wg] FW: Follow up from May 6th and CALL FOR SMALL GROUP Dear WG members: Regarding the smaller group assembled to work on how staff and the proposed “post-launch Standing IRT” might determine whether an issue is policy or implementation, I would like to clarify again the history that led to the existing GNSO processes designed to address these issues whenever they arise –either Pre- or –Post launch: The Policy & Implementation Working Group grappled with this question of policy versus implementation for many months and concluded it was impossible to make determinations about that in advance because “one person’s policy is another person’s implementation”. That is exactly why we have the result we have in the form of GNSO Input (which is essentially for implementation issues), GNSO Guidance, and GNSO EPDP. In fact, it was Marika Koenigs who first suggested to the Policy & Implementation WG that, based on our case studies of issues that arose in the 2012 round, it was impossible to “predict” issues that might arise and label them as clearly policy or clearly implementation. Jeff has pointed out that applicants want more “predictability” in the process so that time delays do not result. Thus, the proposed “Predictability Framework” anticipates that ICANN staff and/or or some newly created body will be able to decide issues that arise post-launch. The “problem” Jeff is trying to resolve as Co-Chair is that if an issue reaches the GNSO, it may take too long to resolve and thus is not practical for registry applicants. However, as far as I know, we have not yet tried out these new processes (except for the EPDP on the Temp Spec) so it seems to me a bit premature to be inventing new processes and acronyms on top of the ones that have not yet been tried. It strikes me that for various Implementation issues that actually rise to the level of an issue post-launch, the existing GNSO Input process (which has not yet been used) is adequate and is in fact designed to operate in that fashion since GNSO can raise such a concern “at any time it deems appropriate”. Under existing GNSO processes established as a result of the work of the Policy & Implementation Working Group, the “gateway” is in fact a question of the interaction between and among Staff, an IRT (or Post-launch Standing IRT), and the GNSO Council. Staff can raise an issue, IRT can raise an issue, and ANY GNSO Council member can raise an issue and so these are the “gates”. (In other words, there are multiple gates and they all ultimately lead to oversight by GNSO Council.) My own view (having worked actively in the Policy & Implementation Working Group on several case studies of issues that arose Post-Launch in the 2012 round) is that if an issue is truly implementation, no one is going to raise the issue to the level of GNSO. Issues will only rise to that level if a stakeholder believes that GNSO Council should address it and that applies whether it’s merely implementation (“GNSO Input” Annex) or involves policy (“GNSO Guidance” Annex or “GNSO EPDP” Annex). Before the Sub Pro Initial Report issued, the Co-Chairs and staff ultimately agreed to make reference to the GNSO Input, Guidance, and EPDP processes but those processes were only referenced and footnoted, not actually explained to the ICANN community or the public. Importantly, the draft Initial Report language was clarified to delete the reference to the Standing IRT “deciding” an issue based on the Predictability Framework. Instead, in the Initial Report, there is a reference to the Standing IRT being able to “recommend” a resolution of the issue. In terms of ICANN governance and the ByLaws as modified after the Policy & Implementation WG finished its work, that is the correct stance. Establishing some other “gate” or some method for determining in advance what is policy and what is implementation when the existing processes adopted after a full WG process have not been tried does not make sense to me. By way of additional background, the whole Policy & Implementation Working Group evolved from the fact that then-CEO Fadi Chehade decided that the “Strawman Solution” in relation to trademarks was implementation, not policy. Fadi issued a public statement to this effect. GNSO Council members were upset about this and our Co-Chair Jeff Neuman wrote the letter to the ICANN Board stating that if the Board took action (such as the Strawman Solution) that amounted to a change in policy, they had to come back to GNSO for its views on the topic and more specifically, to make a determination as to whether the topic required more policy work or merely some GNSO input. Clearly the timing as to when an issue arises (either pre- or post- launch) is NOT a determiner of whether it is Policy or Implementation. So Chuck Gomes led the P & I WG as a result of the GNSO Council’s dissatisfaction with the handling of that issue (and others) that arose Post-Launch and we spent more than year (probably about 2 years) reviewing numerous issues that arose after applications were filed in the 2012 round. That is why the GNSO processes called Input, Guidance and EPDP were adopted by the GNSO Council and that is why the ICANN ByLaws were amended. Hopefully the above history helps to clarify why I was quoting existing GNSO Operating Procedures and Annexes. Again, I don’t think the public understood these processes when the Initial Report issued. The current Consensus Policy Implementation Framework (“CPIF”) of the GNSO makes specific reference to these processes and requires that IRT members be briefed on them. Anne From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Jeff Neuman Sent: Tuesday, May 7, 2019 1:57 AM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] FW: Follow up from May 6th and CALL FOR SMALL GROUP [EXTERNAL] ________________________________ All, Following up on the call yesterday, we have revised the document on the Proposed New Predictability Model. You can find it here: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr.... The comments made during the call should be incorporated either as revised language itself, or as “comments” for draft language to be created. As we discussed, we would like to have a smaller group dedicated to working through the issues that remain on this topic so that a more comprehensive proposal can be presented to the full working group at a later date on the Predictability Framework. The group is open to any current Working Group members. However, if you join the small group, you are expected to put in some time to try and resolve whatever issues remain. The small group MAY have a call or two, but the hope is that all of the work can be done in e-mail and through the documents itself. We will create a mailing list to work on these issues. This is NOT a formal group. So far, I think we captured the following people to be on this group (from the call last night): Jeff Neuman Cheryl-Langdon Orr Kathy Kleiman Christopher Wilkinson Kristina Rosette There may have been others that already volunteered, but may not have captured, so please indicate your interest to us if you want to be a part of the smaller team. We will not be doing formal consensus calls as part of this smaller group, but rather just making the proposal better and filling in the holes to present to the full working group. Please let me know if you have any questions. Best regards, Jeffrey J. Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive , Suite 600 Mclean , VA 22102 UNITED STATES T: +1.703.635.7514 M: +1.202.549.5079 CONFIRMATION OF ORDERS: Please note that we always confirm receipt of orders. To assist us in identifying orders, please use the word ORDER in the subject line of your email. If you have sent us an order and have not received confirmation on the same working day (PST) it is possible that your order has not been received or has been trapped by our spam filter. In this case, please contact your client manager or admin@comlaude.com<mailto:admin@comlaude.com> for confirmation that the order has been received and is being processed. Thank you. From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Julie Hedlund Sent: Monday, May 6, 2019 11:40 PM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 May 2019 Dear Working Group members, Please see below the notes from the meeting today, 06 May 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-05-06+New+gTLD+Subsequent+Pro.... Please also see the referenced documents at: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK.... Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Action Items: ACTION ITEM 1: Staff to incorporate edits as discussed into the 2.2.2 Predictability document. ACTION ITEM 2: Gather a small group to further develop the 2.2.2 Predictability document at: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr.... Jeff will send out a call for volunteers to the list. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson. Notes: 1. Updates to Statements of Interest (SOIs): No updates provided. 2. Review of Summary Documents – (see: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK...) a. Continued: 2.2.2 Predictability / 2.2.2.2 Clarity of Application Process: See: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGr... -- Note: If we don’t come to consensus on a topic then the status quo will be as it was implemented in 2012. On the record that some do not support that approach. -- There are some different things relating to IRTs that could be new. 2.2.2 Predictability: -- Added bullet: The Predictability Model complements the existing GNSO processes and procedures and shall not in any way operate to be a substitute or replacement for those. In fact, they are incorporated into the Predictability Framework explicitly. Discussion: -- “they” references existing processes and procedures. -- To avoid any doubt in future we might want to add, “In the event of a conflict, existing GNSO processes and procedures take precedent.” -- Change from “shall not in any way operate to be” to “is not intended to be”. What are we proposing: B. Changes to ICANN Organization Internal Processes Discussion: -- Comfortable that we have a distinction for minor changes. -- For the first bullet under (b) -- re: “anything visible” -- what does that encompass? Add “change the application or any of the other processes set forth in the applicant guidebook”. Or “those parts of the application that are scored”? -- Third bullet -- New processes: Some examples have direct relevance for the entire community. Such as a new public comment platform. -- Standing IRT decides what is implementation or policy -- but some WG members disagree. -- Change to “Material adverse impact”? -- Second bullet -- “all non-minor changes” -- in written policy? Answer: The output of this whole thing will eventually be the AGB and if there are changes to the AGB they would be written. -- So not a reasonable response that a process will just take longer -- just being a communication. Seems like there should be more accountability. Add a comment/note to see if that falls under a different category. -- Filter out those things that can be dealt with in a practical matter. -- Third bullet: Need a gateway process before we get to these items. Wherever something affects the underlying rules has huge implications. -- Might need to clarify: “New public comment platform” means changes to the tools being used to submit. The rules for commenting is the same, but the platform is different. -- Second bullet: Not meant to be a change in the timing, but a change in a portal. -- Add a line after bullet three, “These proposed changes are intended to be only those that involve mechanisms with no substantive impact.” Question: How is that different from this text, “but rather a New ICANN Organization Internal Process and it is likely to have a materially [adverse] impact on applicants or community members…” Seems similar in meaning. -- An example of a change that wouldn’t be substantive but could have a material adverse impact would be requiring that Legal Rights Objections be filed through a proprietary platform instead of email. Wouldn't affect the substantive LRO (elements, standing, etc), but there may be some potential objectors that, for one reason or another, can't use that platform. -- Are timelines on filing objections seen as a different type of timeline as a third-party timeline? -- What might be a minor change for one party could be a major change to others. Adverse outcomes -- for whom? Should there be a policy gateway to determine? We don’t have a framework that would be considered to be predictable. -- If there is a gateway then that could delay any changes. -- Overriding principle is predictability. Trying to improve predictability from the last round. C. Fundamental Possible Policy Level Changes Discussion: -- Some examples seem to be out of scope for an IRT. -- Deciding something that is policy: a standing IRT can raise that issue and the GNSO Liaison can take that back to the Council. Any Council member also can raise something for consideration at the Council level. -- So a standing IRT can raise something, but only the Council can decide what is policy or implementation, but it sounds like we are setting up a separate gateway. The standing IRT cannot be the final arbiter, and the Council also can raise it directly. -- Add to the bullet point that the standing IRT can make a recommendation to the GNSO Council as to whether something is policy or implementation, but the GNSO will make the final decision. -- Ensure that this document is cross-referenced to the current policies and processes for IRTs. -- What do we mean by “Staff will collaborate with the community”? Answer: That is meant to first go to the standing IRT, which makes a recommendation for additional consideration, and then the GNSO decides how to handle it -- GNSO Input Process, EPDP, etc. -- Delete this text, “Staff will collaborate with the community to consider the issue and agree upon the mechanism by which the solution will be developed. Options could include:” And emphasize the point that this is meant to be a community+staff decision, not just staff. Mark them as redlined and to be replaced. Come back to this in another WG meeting. -- Helpful to have a workflow diagram for the Predictability Framework once concepts are agreed and reconcile with existing ones from IRT Guidelines. D. Fundamental Possible Policy Level New Proposals Discussion: -- Carry over changes from bullets under C. -- Reaching out to the community means staff reaching out to the standing IRT. But don’t think the standing IRT has the authority to decide if something is a policy or implementation change. Could have a new group that includes members of the IRT, and also Council members, and then decide if it goes to the standing IRT. -- Want to change what we call this because of previous problems with IRTs. Want to get the composition right so it is representative of the community. Meant to ensure that it is a gateway. -- A number of groups supported the recommendations in the Initial Report but also some dissenting views: ACTION: Form a smaller group to further develop this document for the full WG. Volunteers thus far: Kristina Rosette, Kathy Kleiman and Christopher Wilkinson. ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://comlaude.com> ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521. ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://comlaude.com> ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
participants (5)
-
Aikman-Scalese, Anne -
Jeff Neuman -
Kathy Kleiman -
lists＠christopherwilkinson.eu -
Steve Chan