[SubPro-IRT] On Predicabilty

[jeff at jjnsolutions.com]

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 at icann.org>
To "subpro-irt at icann.org" <subpro-irt at 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_Ax47U/edit?usp=sharing> 
>(with only the comment function enabled).
>
>
>
>If you cannot access the document, please contact document: 
>nextround_policyimplementation at 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-report-newgtld-subsequent-procedures-pdp-02feb21-en.pdf> 
>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.
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/subpro-irt/attachments/20230622/da8983a5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jywqgcre.png
Type: image/png
Size: 11989 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/subpro-irt/attachments/20230622/da8983a5/jywqgcre-0001.png>