Dear WG Members, Please see below the action items and discussion notes captured by staff from the meeting on 06 February 2018. These high-level notes are designed to help PDP WG members navigate through the content of the call and are not meant as a substitute for the transcript or recording. The MP3, transcript, and chat room notes will be provided separately. For reference see the following link to the Predictability Framework document and excerpts from the chat below: https://docs.google.com/spreadsheets/d/1BN5aJEJ-j57k0zcw0z2b4Smqaf6rRt6ahcid.... Best regards, Julie Julie Hedlund, Policy Director Actions/Discussion Notes 1. SOI Updates: No updates. 2. Work Track Updates: Work Track 4: -- Discussing Financial Evaluations -- will continue on the next call. -- Today did Technical Evaluation and Operational Evaluation. -- Responses back from RSSAC, SSAC, and ICANN Org -- be more concerned with the rate of change; RSSAC no more than 5% per month growth. -- Asking for a clarfication from the RSSAC. -- Additional questions about new TLDs from cognificant science and library science. Work Track 3: -- 30 January meeting: limited public interest objection and community objection. -- Independent objector. --  Next meeting applicant freedom of expression, etc. Work Track 1:  16 January last meeting; next call 06 February -- Applicant Support. Work Track 2: -- Next WT2 call is February 8 at 21:00 UTC -- Topic scheduled: Vertical Integration. Work Track 5: -- 07 February at 14:00 UTC. -- 8 February 2018 - 19:00 UTC   New gTLD Subsequent Procedures Sub Team –Work Track 5 – Webinar on the History of Geographic Names at the Top Level at ICANN 3.  Overarching Issue: Predictability Framework (https://docs.google.com/document/d/1lzXxBLMtFr03BKnHsa-Ss7kR7EAJt7pCI1EP3H81...) ICANN Org changing form custom application interface to Salesforce.com -- I depends on the scope and magnitude of the change. -- Need stability.  Need to analyze the scope of change and solution. Depends on the type of change. -- Determine if an issue arises what is the process to resolve that issue. -- If it merely involves an organizational change to ICANN and had no impact on operational parties -- any issues?  What do we mean by operational changes?  A description of what we mean by operational changes. Change in Delegation Testing -- Change in registry agreement to measure support. -- Some scenarios could give rise to using the procedures (see the chat below). Change from Digital Archery to Priority Draw: -- Who are the impacted parties?  Those that actually applied to the string -- when ICANN switched from digital archery to a priority draw, there was no change in processing in the real world. -- Changes to ICANN organizational internal operations. Standing IRT: Support for the motion: Discussion: --- Perception of a conflict; Issue of what constitutes a conflict is different. -- Difficult to say which contracted parties don't have a conflict. -- Conflict is something more than a stakeholder.  Could have a Statement of Interest, but not a conflict of interest.  Make interest more transparent. -- Look for the conflicts we want to avoid with this panel of IRT. -- A model that has been used is to establish a standing committee.  There is one on the budget process in the GNSO Council, but supplemented by people with subject matter expertise.  A model that could be used.  Doesn't require another structure. -- Disagreement on this model.

From the chat:

Anne Aikman-Scalese (IPC): Okay  Jeff - so we are saying one through 3 do not fit there? Rubens Kuhl: The change from digital archery to priority draw changed the balance among ICANN regions, so it's something that definitely should have gone to a community consultation. Maxim Alzoba(FAITID): To say more - offshore applicants were added to EU region Maxim Alzoba(FAITID): even islands from ocean, which was far from Europe , and it changed balance for EU applicants Anne Aikman-Scalese (IPC): COMMENT - which of your "use cases" already fall within the description of issues in relation to "GNSO  Guidance", "GNSO Input", Expedited PDP, or PDP.  The question that has to be asked is which of your use cases ALREADY fit within that Policy and Implementation framework already established. Maxim Alzoba(FAITID): I have an example Rubens Kuhl: In this use case, provided the Terms and Conditions are kept the same as before Anne Aikman-Scalese (IPC):     COMMENT:  I am going to have to express reservations on this Predictiability Framework since this entire question and various use cases were addressed by the Policy and Implementation Working Group.  I know that Jeff feels there are changes that can be made by staff that are not covered by the work product of the Policy  & Implementation Working Group.  Since the recommendations of that group were adopted by the GNSO  and then also by the Board, I think that we should only be focusing on "internal operations change" that does not (theoretically) fall within any of the cases specified by the GNSO and the ICANN Board to come under "GNSO INput" or "Expedited PDP" or "PDP"   In other words, those procedures already apply and we are duplicating.  COMMENT Maxim Alzoba(FAITID): @Jeff: please add this use case: Need to transfer contacts from Applicant to Registry in ICANN systems (or replacement with the Registry contacts) when RA executed (or right before the moment).in our case The RA was executed and ICANN was still trying to obtain approvals  (such as passwords change, in situation where ICANN staff changed it "for our security") from the Applicant contact (consultant company) after RA execution.This created a deadlock  (Applicant contact has no formal  contract with the new Registry, and ICANN staff explicitly requests approvals from them, and not from RA , whith whom ICANN has an agreement.Given that the passwords were changed without confirmation from Applicant or Registry )which we had to resolve by mentioning that ICANN effectively sabotages execution of our RA.it looks to be Revised Pocess Kristina Rosette (Amazon Registry): Would the proposed revised NSP ToU fall in this category? Maxim Alzoba(FAITID): @Michelle , please read my example, it is too early here an I can not us mic Maxim Alzoba(FAITID): *use Maxim Alzoba(FAITID): with correction "and not from RO" Kristina Rosette (Amazon Registry): Maxim's comment/question should take priority over mine (as far as I'm concerned). Anne Aikman-Scalese (IPC): @JEFF - The Policy and Implementation Working Group determined after a lot of work that there is no way to define what is policy and what is implementation.  We should not be duplicating that work and there is not nearly enough cross-reference going on in this discussion with the work already done and adopted by the GNSO and subsequently by the ICANN Board. Kristina Rosette (Amazon Registry): OK, thanks. Kristina Rosette (Amazon Registry): Maxim's comment/question should take priority over mine (as far as I'm concerned). Anne Aikman-Scalese (IPC): @JEFF - The Policy and Implementation Working Group determined after a lot of work that there is no way to define what is policy and what is implementation.  We should not be duplicating that work and there is not nearly enough cross-reference going on in this discussion with the work already done and adopted by the GNSO and subsequently by the ICANN Board. Kristina Rosette (Amazon Registry): OK, thanks. Anne Aikman-Scalese (IPC): @ Jeff - the whole purpose of the WG was to address issues that arise AFTER go live.  We examined use cases just like these and that is why that framework developed. Anne Aikman-Scalese (IPC): @Jeff - Please just ask Chuck Gomes Maxim Alzoba(FAITID): as I understand, we discuss processes between going live and execution of RA with the new Registries Anne Aikman-Scalese (IPC): Also ask Marika - she was the ICANN policy person and Chuck Gomes led the WG Maxim Alzoba(FAITID): and processes specific to the next new gtld round, and not to other policies Anne Aikman-Scalese (IPC): COMMENT:  No one is looking at how the framework already adopted by the Board in relation to issues arising after the applications are accepted interacts with this so-called Predictability Framework.  Rubens Kuhl: On measuring position of impacted parties, the registry agreement amendment process has some useful precedents. Rubens Kuhl: Defining where a change is supported or not by impacted parties. Maxim Alzoba(FAITID): few year of approval/negotiations for annual process of RA amendment Anne Aikman-Scalese (IPC): COMMENT - which of your "use cases" already fall within the description of issues in relation to "GNSO  Guidance", "GNSO Input", Expedited PDP, or PDP.  The question that has to be asked is which of your use cases ALREADY fit within that Policy and Implementation framework already established. Anne Aikman-Scalese (IPC): Okay  Jeff - so we are saying one through 3 do not fit there? Rubens Kuhl: The change from digital archery to priority draw changed the balance among ICANN regions, so it's something that definitely should have gone to a community consultation. Maxim Alzoba(FAITID): To say more - offshore applicants were added to EU region Maxim Alzoba(FAITID): even islands from ocean, which was far from Europe , and it changed balance for EU applicants Rubens Kuhl: entire community in that case Maxim Alzoba(FAITID): +1 Trang Nguyen: How does the role of the ICANN CEO as the top executive with operational oversight and the role of the ICANN Board as an escalation path for ICANN org fit into this framework? Kavouss Arasteh 3: Jeff, we need to examine and decide on the scope ,magnitude of change, the entity or entities requesting and submitting the chane, the threshold for accepting changes, the manner and means to examine those changes , justification for changes, implementation of changes and more importantly the impact of change i.e. retroactivity or otherwise of changes if and when  implemented Rubens Kuhl: Because it was not just the randomization, there was also a regional balance. Rubens Kuhl: DA had a per region system. Rubens Kuhl: Not able to speak anymore, late here. Anne Aikman-Scalese (IPC): QUESTION:  How do you determine which party is affected and how big the effect is?  Who makes that determination? Maxim Alzoba(FAITID): also regional balance was shifted due to addition of applicants from some offshore jurisdictions to EU Maxim Alzoba(FAITID): without geo reasons (tiny islands in ocean are not in EU region) Anne Aikman-Scalese (IPC): name collision definitely comes under the Policy & Implementation Working Group framework - at the very least GNSO Guidance. Anne Aikman-Scalese (IPC): COMMENT:  Standing IRT is a GREAT idea! Rubens Kuhl: Specifically on topics of security and stability, RSTEP could also be invoked. Greg Shatan: Also support the Standing IRT. Mike Rodenbaugh: I don't think a standing IRT sounds very realistic, since any of a myriad of issues could arise, so the team to evaluate them might need different skillsets. Rubens Kuhl: The panel. The process would require some tweaks. Trang Nguyen: Currently, org goes to the GNSO when we have policy questions. It seems if the recommendation is for org to go to an IRT instead, that the GNSO should weigh in on that recommendation. Justine Chew: @Mike: composition of IRT can address that Anne Aikman-Scalese (IPC): @Trang - the way the IRT works, it brings issues to the attention of GNSO if needed. Kristina Rosette (Amazon Registry): My concern is that the potential IRT panel members with the relevant skills are also most likely to be the folks who have an interest (financial, conflict of, etc.) in the panel's determination.  Maxim Alzoba(FAITID): @Kristina, most probably Mike Rodenbaugh: +1 Kristina.  Maybe a standing IRT composed of subset of the GNSO Council might make most sense. Kristina Rosette (Amazon Registry): @Mike - like that idea. Justine Chew: and TOR  for IRT should be specific Rubens Kuhl: They being here. ;-) Steve Chan: There could be a model were the GNSO Council members make decisions, but be supplemented with subject matter expertise as necessary? Rubens Kuhl: IRT, not IRP Greg Shatan: IRT = "Implementation Review Team" Kristina Rosette (Amazon Registry): Thinking back to those Council as PDP days gives me a headache.  Raises the issue, though, that having the IRT be subset of Council could overload a group of folks with extreme bandwidth issues to start with. Mike Rodenbaugh: for sure Anne Aikman-Scalese (IPC): Disagree with Kavouss - this is exactly the best and highest use of the IRT Mike Rodenbaugh: but I can't see a realistic vetting and selection process for such an IRT, outside of existing Council members, especially without knowing the specific issue(s) it might address Anne Aikman-Scalese (IPC): COMMENT:  ICANN should have a procedure for participants to identify when they should recuse themselves. Greg Shatan: Acronym Collision Greg Shatan: The IRT is typically a subset of the WG.  Often those hardy enough to remain engaged.... Justine Chew 2: Every group should be subject to Conflict of Interest policy, if not already Rubens Kuhl: In case of consensus-based groups like WGs, having published SOIs is considered enough. Rubens Kuhl: But that assumes that less than the majority of members are non-conflicted. Mike Rodenbaugh: remember that nearly half the Board recused itself from the NGPC Maxim Alzoba(FAITID): is request to extend history of text windows in Adobe Connect fall into minor changes (this tool might be used in the next round :) Maxim Alzoba(FAITID): *does Anne Aikman-Scalese (IPC): Do not support "perception or appearance of a conflict""    It disqualifies too Anne Aikman-Scalese (IPC): Disqualiffies too many people Maxim Alzoba(FAITID): and registrars too Maxim Alzoba(FAITID): the issue is - industry is not large, and excluding all experts with "perception of appearance of a conflict" will make it full of totally non-relevant persons into the team ... I doubt that outcome will be great Mike Rodenbaugh: agreed, Maxim -- that is EXCTLY what happened with NGPC and it was a disaster, imho Justine Chew 2: Where a member of group gets into a position of where a conflct of interest is reasonably likely to arise should recuse herself, and only in respect of a decision that can greatly influence the outcome? Just thinking out loud. Maxim Alzoba(FAITID): and diversity requirement might help in finding balance (so , for example registries are outweighted by registrants e.t.c.) Anne Aikman-Scalese (IPC): I think a direct conflict could merit recusal.  For example, there could be specific strings implicated in a particular issue .  Direct Greg Shatan: Steve, that group is intended for "Council-level" review and comment on the Budget.  Each of the SGs and Cs also comment individually on the Budget.  So I don't think it is usable here. Anne Aikman-Scalese (IPC): Agree with Jeff here Steve Chan: Actually, one comment I forgot to raise is that the Council is ultimately responsible for initiating the GNSO Expedited PDP and Guidance Process Trang Nguyen: Also, as the issues are wide ranging, it would be important to ensure that the process allows for relevant expertise to be consulted (i.e., SSAC/RSSAC/other technical communities on technical issues). Greg Shatan: @Steve, true, that is consistent with their policy management role. Anne Aikman-Scalese (IPC): There was GAC advice that would have stopped certain applications from moving forward.  The PIC process was developed to address that but GNSO definitely should have been consulted.  Kristina Rosette (Amazon Registry): and registrars, eventually. Steve Chan: Sure Jeff, I'll grab your suggestion from the transcript. Anne Aikman-Scalese (IPC): Yes Jeff  _ i think that is right Maxim Alzoba(FAITID): as I understand the current GDD Portal is intended to be used later by applicants (now used by Registries, and will be used by Greg Shatan: Now the call is interrupted.... Justine Chew 2: Steve Chan is speaking Steve Chan: Maxim Alzoba(FAITID): @Jeff: please add this use case: Need to transfer contacts from Applicant to Registry in ICANN systems (or replacement with the Registry contacts) when RA executed (or right before the moment).in our case The RA was executed and ICANN was still trying to obtain approvals  (such as passwords change, in situation where ICANN staff changed it "for our security") from the Applicant contact (consultant company) after RA execution.This created a deadlock  (Applicant contact has no formal  contract with the new Registry, and ICANN staff explicitly requests approvals from them, and not from RA , whith whom ICANN has an agreement.Given that the passwords were changed without confirmation from Applicant or Registry )which we had to resolve by mentioning that ICANN effectively sabotages execution of our RA.it looks to be Revised Process Steve Chan: That's easier than reading into the record!