Dear IRT members, In drafting the text for the Predictability framework, we would you to confirm our understanding of Annex E and our approach to implementing the categories of operational and policy issues – per our questions contained in the text below. Please note, we also uploaded the question to the IRT’s google drive<https://docs.google.com/document/d/1Wuq5GgdaeM5pyIpd_I4WEUfUk10NgVEgk1b5P_Ax...> (with only the comment function enabled). If you cannot access the document, please contact document: nextround_policyimplementation@icann.org<mailto:nextround_policyimplementation@icann.org>. We are looking forward to hearing back on this issues. Best wishes, Lars Dear IRT members, In developing the Predictability Framework we would like to propose to make the Framework as efficient and transparent as possible. As a reminder, the intent of the Framework is to ensure that there is transparency and predictability about any changes that are made to the next round of the New gTLD Program (the Program) after it is launched. To this end, we ask that you confirm our understanding of Annex E and our approach to implementing the categories of operational and policy issues. Annex E of the Final Report<https://gnso.icann.org/sites/default/files/file/field-file-attach/final-repo...> provides three categories of operational issues and two categories of policy issues: 1. Minor operational issue 2. Non-minor operational issue 3. New operational process or significant operational issue 4. Changes that may have a policy implication 5. New proposals that have have policy implication To make the Framework more transparent and efficient, we propose (A) to combine categories 2 and 3 because regardless of whether an issue is identified as “non-minor” or a “new operational process or significant operational issue”, ICANN must consult the SPIRT and SPIRT has the option to collaborate with ICANN. We also propose (B) to combine categories 4 and 5 because in both categories the Council either determines that policy work is required or that, in fact, the issue requires an operational solution, which would move it automatically into one of the operational categories. A. Rationale for combining categories 2 and 3 The main procedural difference between category 1 and categories 2 and 3 is, according to Annex E, that the Standing Predictability Implementation Review Team (SPIRT) has the option to collaborate on solutions with ICANN org on issues that fall within categories 2 and 3. The difference between categories 2 and 3 is that in category 3, the GNSO Council and the ICANN Board can ‘initiate action’. It is our understanding that any issue that requires Council action is by definition a policy issue that requires a change to (or new) policy and would thus make it an issue that must fall into the ‘policy’ category. The ability of the Board to act is unaffected by the Framework. Therefore, we propose to reduce the categories of operational issues to minor and non-minor, with the procedural distinction that the latter gives SPIRT the option to collaborate with ICANN org on the solution. 1. Regarding the operational issues: We understand that the Council has only two tools to develop policies: a PDP or an EPDP. With regard to the impact on the Program, whether the GNSO amends existing policy or develops new policy, only a PDP or EPDP can achieve this. We also note in this context that the Council had previously confirmed to the ODP that policy changes can only affect subsequent rounds, never the current one. If the SPIRT refers an issue to the Council because it or ICANN believes that a policy change may be required, and the Council determines that no policy change is required, then ICANN org will address the issue via an operational change, in accordance with the Framework. Therefore, we propose to combine categories 4 and 5 into one category of ‘changes that require policy development’. ICANN org believes that this approach is consistent with recommendation 2.1 that “ICANN must establish predictable, transparent, and fair processes and procedures for managing issues that arise in the New gTLD Program after the Applicant Guidebook is approved which may result in changes to the Program and its supporting processes.” ICANN org has used the predictability framework outlined in Annex E to the Final Report as its guidance in proposing this approach to implement the framework with the goal of predictability in mitigating issues.
Thanks Lars for these questions. I provide these answers in my own personal capacity based on my in depth understanding about the SubPro Recommendations and PDP. First, I believe we must also consider that changes or new proposals not only impact ICANN Org and the GNSO Council, but rather can potentially have significant impacts on Applicants and members of the community that participate in the various processes such as commenters, objectors, etc. I have no issue with combining numbers 2 and 3 provided that ICANN follows the standard set forth in c, and not the standard set forth in b of Annex E. Though both (b) and (c) require collaboration with the SPIRT, New Processes and/or significant changes to Internal Processes (c), require agreement on changes whereas (b) does not require. In other words, if you combine them both into one category, then agreement of the SPIRT to implement any of the changes or new processes will be required. You cant take the lower standard of only collaboration (in b) and use that as the new standard for (c). That is a material difference. I am still looking at the combination of 4 and 5. Sincerely, Jeff ------ Original Message ------
From "Lars Hoffmann" <lars.hoffmann@icann.org> To "subpro-irt@icann.org" <subpro-irt@icann.org> Date 6/22/2023 7:56:31 AM Subject [SubPro-IRT] On Predicabilty
Dear IRT members,
In drafting the text for the Predictability framework, we would you to confirm our understanding of Annex E and our approach to implementing the categories of operational and policy issues – per our questions contained in the text below. Please note, we also uploaded the question to the IRT’s google drive <https://docs.google.com/document/d/1Wuq5GgdaeM5pyIpd_I4WEUfUk10NgVEgk1b5P_Ax...> (with only the comment function enabled).
If you cannot access the document, please contact document: nextround_policyimplementation@icann.org.
We are looking forward to hearing back on this issues.
Best wishes,
Lars
Dear IRT members,
In developing the Predictability Framework we would like to propose to make the Framework as efficient and transparent as possible. As a reminder, the intent of the Framework is to ensure that there is transparency and predictability about any changes that are made to the next round of the New gTLD Program (the Program) after it is launched. To this end, we ask that you confirm our understanding of Annex E and our approach to implementing the categories of operational and policy issues.
Annex E of the Final Report <https://gnso.icann.org/sites/default/files/file/field-file-attach/final-repo...> provides three categories of operational issues and two categories of policy issues:
Minor operational issue Non-minor operational issue New operational process or significant operational issue Changes that may have a policy implication New proposals that have have policy implication
To make the Framework more transparent and efficient, we propose (A) to combine categories 2 and 3 because regardless of whether an issue is identified as “non-minor” or a “new operational process or significant operational issue”, ICANN must consult the SPIRT and SPIRT has the option to collaborate with ICANN.
We also propose (B) to combine categories 4 and 5 because in both categories the Council either determines that policy work is required or that, in fact, the issue requires an operational solution, which would move it automatically into one of the operational categories.
A. Rationale for combining categories 2 and 3
The main procedural difference between category 1 and categories 2 and 3 is, according to Annex E, that the Standing Predictability Implementation Review Team (SPIRT) has the option to collaborate on solutions with ICANN org on issues that fall within categories 2 and 3.
The difference between categories 2 and 3 is that in category 3, the GNSO Council and the ICANN Board can ‘initiate action’.
It is our understanding that any issue that requires Council action is by definition a policy issue that requires a change to (or new) policy and would thus make it an issue that must fall into the ‘policy’ category.
The ability of the Board to act is unaffected by the Framework.
Therefore, we propose to reduce the categories of operational issues to minor and non-minor, with the procedural distinction that the latter gives SPIRT the option to collaborate with ICANN org on the solution.
Regarding the operational issues:
We understand that the Council has only two tools to develop policies: a PDP or an EPDP. With regard to the impact on the Program, whether the GNSO amends existing policy or develops new policy, only a PDP or EPDP can achieve this. We also note in this context that the Council had previously confirmed to the ODP that policy changes can only affect subsequent rounds, never the current one.
If the SPIRT refers an issue to the Council because it or ICANN believes that a policy change may be required, and the Council determines that no policy change is required, then ICANN org will address the issue via an operational change, in accordance with the Framework. Therefore, we propose to combine categories 4 and 5 into one category of ‘changes that require policy development’.
ICANN org believes that this approach is consistent with recommendation 2.1 that “ICANN must establish predictable, transparent, and fair processes and procedures for managing issues that arise in the New gTLD Program after the Applicant Guidebook is approved which may result in changes to the Program and its supporting processes.” ICANN org has used the predictability framework outlined in Annex E to the Final Report as its guidance in proposing this approach to implement the framework with the goal of predictability in mitigating issues.
Thank you for the input, Jeff. I suggest we address the substance of your and any other comments that may come in together during our next call. One suggestion that may be helpful not just to staff but also to fellow IRT members: if additional is provided, like Jeff did below, it would be helpful to point to relevant sections in the Final Report<https://gnso.icann.org/sites/default/files/file/field-file-attach/final-repo...>, so that it is clear to everyone whether it is based on a recommendation, an implementation guidance or other relevant text. In Jeff’s case, I assume he is referring to the process description c. on page 319-320 (Annex E) of the Final Report: “ICANN org must inform the SPIRT of issues arising in this category and the SPIRT will have the option to collaborate with ICANN org as a solution is developed. The GNSO Council or ICANN Board may also initiate action on an issue they believe to be in this category and request assistance from the SPIRT. Once changes are agreed, changes should be communicated to all impacted (or reasonably foreseeable impacted) parties prior to deployment of the change, and shall be reported on subsequent to their implementation in a change log, or similar.” Best wishes, Lars From: "jeff@jjnsolutions.com" <jeff@jjnsolutions.com> Reply to: "jeff@jjnsolutions.com" <jeff@jjnsolutions.com> Date: Thursday, 22 June 2023 at 22:41 To: Lars Hoffmann <lars.hoffmann@icann.org>, "subpro-irt@icann.org" <subpro-irt@icann.org> Subject: [Ext] Re: [SubPro-IRT] On Predicabilty Thanks Lars for these questions. I provide these answers in my own personal capacity based on my in depth understanding about the SubPro Recommendations and PDP. First, I believe we must also consider that changes or new proposals not only impact ICANN Org and the GNSO Council, but rather can potentially have significant impacts on Applicants and members of the community that participate in the various processes such as commenters, objectors, etc. I have no issue with combining numbers 2 and 3 provided that ICANN follows the standard set forth in c, and not the standard set forth in b of Annex E. Though both (b) and (c) require collaboration with the SPIRT, New Processes and/or significant changes to Internal Processes (c), require agreement on changes whereas (b) does not require. In other words, if you combine them both into one category, then agreement of the SPIRT to implement any of the changes or new processes will be required. You cant take the lower standard of only collaboration (in b) and use that as the new standard for (c). That is a material difference. I am still looking at the combination of 4 and 5. Sincerely, Jeff [cid:image001.png@01D9A5D6.8F0FC4E0] ------ Original Message ------ From "Lars Hoffmann" <lars.hoffmann@icann.org<mailto:lars.hoffmann@icann.org>> To "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Date 6/22/2023 7:56:31 AM Subject [SubPro-IRT] On Predicabilty Dear IRT members, In drafting the text for the Predictability framework, we would you to confirm our understanding of Annex E and our approach to implementing the categories of operational and policy issues – per our questions contained in the text below. Please note, we also uploaded the question to the IRT’s google drive [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1Wuq5GgdaeM5py...> (with only the comment function enabled). If you cannot access the document, please contact document: nextround_policyimplementation@icann.org<mailto:nextround_policyimplementation@icann.org>. We are looking forward to hearing back on this issues. Best wishes, Lars Dear IRT members, In developing the Predictability Framework we would like to propose to make the Framework as efficient and transparent as possible. As a reminder, the intent of the Framework is to ensure that there is transparency and predictability about any changes that are made to the next round of the New gTLD Program (the Program) after it is launched. To this end, we ask that you confirm our understanding of Annex E and our approach to implementing the categories of operational and policy issues. Annex E of the Final Report [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/file/f...> provides three categories of operational issues and two categories of policy issues: 1. Minor operational issue 2. Non-minor operational issue 3. New operational process or significant operational issue 4. Changes that may have a policy implication 5. New proposals that have have policy implication To make the Framework more transparent and efficient, we propose (A) to combine categories 2 and 3 because regardless of whether an issue is identified as “non-minor” or a “new operational process or significant operational issue”, ICANN must consult the SPIRT and SPIRT has the option to collaborate with ICANN. We also propose (B) to combine categories 4 and 5 because in both categories the Council either determines that policy work is required or that, in fact, the issue requires an operational solution, which would move it automatically into one of the operational categories. A. Rationale for combining categories 2 and 3 The main procedural difference between category 1 and categories 2 and 3 is, according to Annex E, that the Standing Predictability Implementation Review Team (SPIRT) has the option to collaborate on solutions with ICANN org on issues that fall within categories 2 and 3. The difference between categories 2 and 3 is that in category 3, the GNSO Council and the ICANN Board can ‘initiate action’. It is our understanding that any issue that requires Council action is by definition a policy issue that requires a change to (or new) policy and would thus make it an issue that must fall into the ‘policy’ category. The ability of the Board to act is unaffected by the Framework. Therefore, we propose to reduce the categories of operational issues to minor and non-minor, with the procedural distinction that the latter gives SPIRT the option to collaborate with ICANN org on the solution. 1. Regarding the operational issues: We understand that the Council has only two tools to develop policies: a PDP or an EPDP. With regard to the impact on the Program, whether the GNSO amends existing policy or develops new policy, only a PDP or EPDP can achieve this. We also note in this context that the Council had previously confirmed to the ODP that policy changes can only affect subsequent rounds, never the current one. If the SPIRT refers an issue to the Council because it or ICANN believes that a policy change may be required, and the Council determines that no policy change is required, then ICANN org will address the issue via an operational change, in accordance with the Framework. Therefore, we propose to combine categories 4 and 5 into one category of ‘changes that require policy development’. ICANN org believes that this approach is consistent with recommendation 2.1 that “ICANN must establish predictable, transparent, and fair processes and procedures for managing issues that arise in the New gTLD Program after the Applicant Guidebook is approved which may result in changes to the Program and its supporting processes.” ICANN org has used the predictability framework outlined in Annex E to the Final Report as its guidance in proposing this approach to implement the framework with the goal of predictability in mitigating issues.
Hi Lars Thanks for your proposals regarding the combining of categories in the Predictability Framework. As Council Liaisons, Anne and I discussed this (although not the specific language you have now shared) and we do not oppose in principle combining categories 4 and 5 (changes and new proposals that have policy implications), if that is what the IRT supports, since the potential options available for both categories, as set out in Annex E, are the same. For the avoidance of doubt, however, we wanted to flag that although you are correct when you say that the only mechanisms available to develop policy, if required, for these categories would be a PDP or EPDP, there may be other mechanisms suitable for something which has policy implications but does not require policy development. Annex E does envisage that where something is determined not to rise to the level of requiring a change to existing policy or development of new policy it may still be appropriate for the issue to be referred to Council to consider whether another mechanism is suitable, such as a GIP or GGP. Regards Susan Susan Payne Head of Legal Policy Com Laude T +44 (0) 20 7421 8250 Ext 255 [image]<https://comlaude.com/> We are pleased to launch our new YouTube channel<https://t-uk.xink.io/Tracking/Index/bhkAAGVfAADw_RQA0> From: SubPro-IRT <subpro-irt-bounces@icann.org> On Behalf Of Lars Hoffmann Sent: Thursday, June 22, 2023 12:57 PM To: subpro-irt@icann.org Subject: [SubPro-IRT] On Predicabilty Dear IRT members, In drafting the text for the Predictability framework, we would you to confirm our understanding of Annex E and our approach to implementing the categories of operational and policy issues - per our questions contained in the text below. Please note, we also uploaded the question to the IRT's google drive<https://docs.google.com/document/d/1Wuq5GgdaeM5pyIpd_I4WEUfUk10NgVEgk1b5P_Ax...> (with only the comment function enabled). If you cannot access the document, please contact document: nextround_policyimplementation@icann.org<mailto:nextround_policyimplementation@icann.org>. We are looking forward to hearing back on this issues. Best wishes, Lars Dear IRT members, In developing the Predictability Framework we would like to propose to make the Framework as efficient and transparent as possible. As a reminder, the intent of the Framework is to ensure that there is transparency and predictability about any changes that are made to the next round of the New gTLD Program (the Program) after it is launched. To this end, we ask that you confirm our understanding of Annex E and our approach to implementing the categories of operational and policy issues. Annex E of the Final Report<https://gnso.icann.org/sites/default/files/file/field-file-attach/final-repo...> provides three categories of operational issues and two categories of policy issues: 1. Minor operational issue 2. Non-minor operational issue 3. New operational process or significant operational issue 4. Changes that may have a policy implication 5. New proposals that have have policy implication To make the Framework more transparent and efficient, we propose (A) to combine categories 2 and 3 because regardless of whether an issue is identified as "non-minor" or a "new operational process or significant operational issue", ICANN must consult the SPIRT and SPIRT has the option to collaborate with ICANN. We also propose (B) to combine categories 4 and 5 because in both categories the Council either determines that policy work is required or that, in fact, the issue requires an operational solution, which would move it automatically into one of the operational categories. A. Rationale for combining categories 2 and 3 The main procedural difference between category 1 and categories 2 and 3 is, according to Annex E, that the Standing Predictability Implementation Review Team (SPIRT) has the option to collaborate on solutions with ICANN org on issues that fall within categories 2 and 3. The difference between categories 2 and 3 is that in category 3, the GNSO Council and the ICANN Board can 'initiate action'. It is our understanding that any issue that requires Council action is by definition a policy issue that requires a change to (or new) policy and would thus make it an issue that must fall into the 'policy' category. The ability of the Board to act is unaffected by the Framework. Therefore, we propose to reduce the categories of operational issues to minor and non-minor, with the procedural distinction that the latter gives SPIRT the option to collaborate with ICANN org on the solution. 1. Regarding the operational issues: We understand that the Council has only two tools to develop policies: a PDP or an EPDP. With regard to the impact on the Program, whether the GNSO amends existing policy or develops new policy, only a PDP or EPDP can achieve this. We also note in this context that the Council had previously confirmed to the ODP that policy changes can only affect subsequent rounds, never the current one. If the SPIRT refers an issue to the Council because it or ICANN believes that a policy change may be required, and the Council determines that no policy change is required, then ICANN org will address the issue via an operational change, in accordance with the Framework. Therefore, we propose to combine categories 4 and 5 into one category of 'changes that require policy development'. ICANN org believes that this approach is consistent with recommendation 2.1 that "ICANN must establish predictable, transparent, and fair processes and procedures for managing issues that arise in the New gTLD Program after the Applicant Guidebook is approved which may result in changes to the Program and its supporting processes." ICANN org has used the predictability framework outlined in Annex E to the Final Report as its guidance in proposing this approach to implement the framework with the goal of predictability in mitigating issues. ________________________________ 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 Com Laude Group Limited (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 is a limited company registered in England and Wales with company number 10689074 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England. 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 6181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com<https://comlaude.com/>
participants (3)
-
jeff＠jjnsolutions.com -
Lars Hoffmann -
Susan Payne