Dear Working Group members, Please see below the action items and notes from the meeting today. 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 or transcript. See the chat transcript, recording and call transcript at: https://community.icann.org/display/NGSPP/2017-08-29+New+gTLD+Subsequent+Pro.... Kind regards, Emily ACTION ITEM: Staff will develop a graphic to show the timing issue. Notes: 1) Welcome/SOIs - Avri Doria has an SOI update - contract project with Donuts has ended. 2) Work Track Updates - WT1: Next week the WT is continuing discussion on CC2, focus on Applicant Support and Communications. - WT2: Next week the WT is continuing discussion on Registrant Protections, CC2 comments on this topic. May also begin discussing Closed Generics. WT2 will have weekly meetings in September. - WT3: Meeting this week will continue to focus on CC2 comments on Objections, including GAC Advice and Independent Objector. - WT4: Last meeting focused on Registry Services and technical evaluation. Conversation on applicant evaluations will continue in the upcoming meeting. - WT5: Letters have gone out to GNSO, ccNSO, GAC, and ALAC inviting them to nominate a member for the leadership team. The ccNSO nominated Annebeth Lange. ALAC and GNSO are working on nominations. Cheryl Langdon-Orr is expected as ALAC lead. GNSO Council discussed WT5 during the Council meeting last week. Question was raised about whether this WT will take place within the GNSO PDP framework. The intention is that it will. - From the GNSO Council perspective, the appointment of leaders of WTs typically happens through the Working Group. This should be the same for WT5. - There have been conversations between WG chairs and potential candidates, but the leads are still working on this process. - There are still some concern about the procedures and in particular that the output will be considered by the full PDP. This might be a problem from the ccNSO perspective. - Question: Are the responsibilities of the co-leaders defined somewhere? Answer: The first item of business will be to run a draft TOR by the new co-leaders once they have been selected. Efforts will be made to make sure everyone is as comfortable as possible within the GNSO framework. - Intention is that all participants from the community will be participants on equal footing. chat excerpt: Rubens Kuhl: There are no minority or majority concepts in a consensus-based decision making. Kavouss Arasteh: Rubens, but there are some concerns about consensus meaning Rubens Kuhl: Kavouss, consensus in a GNSO PDP can only mean one thing... but it shares its properties with the IETF rough consensus tradition, where even one view can change the outcome. Rubens Kuhl: This is for instance the case of many encryption standards (TLS) where a single Google comment was able to change the outcome, since they were recognized as having the experience to point out things that don't work in scale. Kavouss Arasteh: Ihope there would be no more than one person from each 4 group Steve Chan: You can review GNSO PDP decision making rules under section 3.6 here in the WG guidelines: https://gnso.icann.org/en/council/annex-1-gnso-wg-guidelines-01sep16-en.pdf[gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_council_annex-2D1-2Dgnso-2Dwg-2Dguidelines-2D01sep16-2Den.pdf&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=mBQzlSaM6eYCHFBU-v48zs-QSrjHB0aWmHuE4X4drzI&m=5t7Vhc_Z21cemGHDSQV-uIWGXusO-BuOp4bxc6TdvEo&s=cCYjvt5miJCVOLgO9HQSvZ2ymXfllN1GiWRyYuM7mxo&e=> Heather Forrest: @Jeff, Avri, good to know that this is in progress, and in accordance with standard practice. I wouldn't anticipate that Council itself would make nominations (as that would come through the SSC) Rubens Kuhl: Kavouss, it's never about quantity. Kavouss Arasteh: That is not as simple as you qualified Robin Gross: Policy for generic names is guided by the GNSO under ICANNs bylaws. It sounds like some have a problem with the structure of ICANN. Anne Aikman-Scalese (IPC): I think it is a bit diifferent when ccNSO participates in a PDP. They don't really have quite the same policy-making process, do they? Annebeth Lange, ccNSO: I am happy to hear that, Avri, since geographical names are of special interest to more groups than GNSO than any other gTLDs Jim Prendergast: so just to recap. the ccNSO has put forth someone, waiting on GNSO and ALAC but they are moving on it and we think GAC may be addressing it this week on leadership call. is that correct? and what is the best guess on when the leadership will be settled? Robin Gross: When does the GNSO get to participate in CCnso policy making? Greg Shatan: Would it make sense to have a webinar on the GNSO PDP Working Group guidelines for those unfamiliar with them? Philip Corwin: I don't understand how sincere outreach in the cause of inclusion could be regarded as an attempt to construct an 'alibi". Rubens Kuhl: Anne, ccNSO does have PDPs... their PDPs are usually less time-sensitive and less controversial, but they share some DNSO origins with GNSO, including PDPs. Greg Shatan: That might allay some of these fears. Karen Day: Good thought Greg. Greg Shatan: It should be noted that GNSO PDP Working Groups are ALWAYS open to any participant from any group or no group. Rubens Kuhl: Jim, GNSO Council will not be putting a name forward for GNSO. Those names were referred to reach out to the full WG chairs (Jeff and Avri) and come forward with their application. Annebeth Lange, ccNSO: But Greg, in the end it will be the GNSO council that decides, will it not? Anne Aikman-Scalese (IPC): It is a very positive that GAC representatives and ccNSO participate actively in Sub Pro. Karen Day: @Kavouss - I can confirm that is the way this PDP is already operating with regard to work team co-leads. Robin Gross: I'm trying to imagine what it would be like for GNSO participants to have equal footing with GAC in their working groups. Greg Shatan: The Working Group's final report, after probably 2 rounds of public comment, and approval by the Working Group, will go to the Council for approval. But it is up to the WG to write and approve the report. Heather Forrest: The GNSO Council is required, under ICANN Bylaws, to vote on any recommendations of GNSO PDPs - but Council obviously respects the work of the PDP WGs Rubens Kuhl: Annebeth, GNSO Council is a process manager, not a legislative body... so the Council can verify if anything went outside of PDP process or conflicts with bylaws, but wouldn't replace the WG report with their own views on something. Heather Forrest: (Greg, Rubens and I have all just made the same point in different words - great minds think alike - and of course it would have to be that Council couldn't simply legislate on its own or we wouldn't have or need PDP WGs) Greg Shatan: Good points Rubens and Heather (both on Council, by the way). The GNSO Council is also NOT a policy development body - that is the job of the (always open) Working Groups. Annebeth Lange, ccNSO: I think there is a special sensitivity when it comes to geographical names among the other stakeholders, as many do not consider them "true generics". Since we only have 2 categories in TLDs, these naturally fall under gTLDs. However, what I was reporting here were the concerns I hear. Since ICANN Bylaws are as they are, we have to try to make the best out of it to avoid the same problems we had in the last round, when many years of discussion took place after the first AGB was produced. Rubens Kuhl: Annebeth, I offer another angle on this: having the GNSO policy on those names defined is a kind of insurance that makes that if those names are considered gTLDs, they are also protected by reasonable rules to assure they are not misused. Jim Prendergast: don't forget impact of GAC advice as well 3) Drafting Team Discussion – Predictability Framework - Background - there were a number of issues that were not expected in the original policy. Some issues are being addressed under the specific topic areas in the PDP. There may still be changes that need to take place in subsequent procedures. This framework seeks to address how to manage these types of issues if they do come up. - It is expected that the issues will not be as great as they were in the 2012 round. - For issues that arise when the IRT is operating, the IRT can address these issues. - There is still a question of what happens when the program launches and changes need to take place. - Some changes may only impact applicants, other issues came up after applications were revealed but before contract signing. Other issues surfaced and were raised to the community later. chat excerpt: Kavouss Arasteh: I suggest we say "SOME LEVEL"of preditabilty instead of "A LEVEL " Kavouss Arasteh: Ialso suggest to add the word"relative"before stability - Clarification on chat comment -- it is difficult to predict stability, and nothing is totally stable, therefore include the word "relative" before stability. - We are never going to be able to predict every change that needs to happen, but having a framework for managing these changes can help to provide additional predictability. chat excerpt: Michael Flemming: Jeff, question for clarity. Predictability in our discussion is limited to the process itself and not necessarily the outcome as in delay in some TLDs to launch/use their TLD, correct? - Correct -- this discussion is primarily about the predictability in the process itself. We may in the future also want to consider thresholds, but for the moment, the focus is on the process. - Example- imagine a flaw/glitch in application system. In 2012, ICANN staff put up a page saying that there was an issue and that updates would be provided. What would be an alternate way to handle this issue? - We need more predictability into the SLAs and community input into those SLAs, more transparency from those working on the issue. - If an issue came up where ICANN had to change application process, is this purely implementation? Is it something the community should weigh in on? chat excerpt: Maxim Alzoba (FAITID): RFP for system? Maxim Alzoba (FAITID): at the first place Greg Shatan: It seems like the processes created by the Policy & Implementation Working Group should be applied to many of these instances. Greg Shatan: Has this been considered? Anne Aikman-Scalese (IPC): Yes - Greg - I agree. The big issue here is Who should determine whether an issue involves policy or not. I think IRT should determine. I don't necessarily buy the notion that that staff or some informal discussion can determine whether or not policy issues are involved. Current draft of Predictability Framework says "staff will collaborate with the comm Heather Forrest: Looks like we have 2 different conversations here in the chat - one on policy vs implementation, the other on the system Anne Aikman-Scalese (IPC): @Heather - the policy and implementation WG determined that it is not valuable to try to decide whether or not an issue is policy or implementation - it is only important to determine how the policy maker (GNSO) decides to treat that topic - whether or not it involves policy. Michael Flemming: Depends on the issue, no? Heather Forrest: I agree with Jeff but it's not clear to me how we determine whether something goes back to the IRT or not Michael Flemming: Couldn't we have development of the system by one third party and then a risk analysis by another third party? Rubens Kuhl: I don't think we can avoid an IRT, since this is a PDP WG . Non-PDP WGs perhaps could chose that. Anne Aikman-Scalese (IPC): I have commented on the list that IRT should be "standing" - to be consulted whenever an issue arises. Greg Shatan: I think trying to say some of these are not implementation issues is causing confusion. Greg Shatan: Just as implementation problems raise policy issues, execution problems raise implementation issues. Kavouss Arasteh: Jeff, I have some difficulties with you new term execution versus implemenation Greg Shatan: Maybe we need an Implementation & Execution Working Group.... - What happens if changes arise once the program has already launched. There could be certain issues that arise that may not need to go to the IRT to get resolution. - Any issue where the implementation is not working should go back to the IRT. Any cases outside of this should be very narrowly drawn. Not clear what this alternate method should be dealing with. It would need to be more nimble. But in general we should be looking at the issues in terms of policy and implementation. - Maybe another word should be used - execution - example, what if information was exposed in the application system that should not have been exposed. Are there cases where issues do not have to go to the full IRT? - Policy and Implementation WG looked at a number of issues that came up in 2012 round and examined resolution. The distinction between implementation and execution is not clear. Your perspective may depend on which side of the issue you are on. The WG determined that trying to draw a distinction between policy and implementation is not always helpful. From the chat: Rubens Kuhl: Jeff, the type of issues you mentioned sounds similar to the IANA CSC (Customer Standing Committee) to me. Perhaps we could recomend something in that direction ? NTAG (New gTLD Applicant Group) and BRG (Brand Registry Group) both made interesting interactions with staff during the program. Kavouss Arasteh: Jeff, may we avoid to use "Execution" ias it may cause some confusion with implemenation Jeff Neuman: @Kavouss - is there a better word to use? Maxim Alzoba (FAITID): name collisions were poor third party report issue Jim Prendergast: name collision was actually a security and stability issue but your point is still valid Rubens Kuhl: Name collisions actually surfaced during policy development, nobody cared... surfaced during implementation, nobody cared... it ended up being defined at execution time, but it was not execution. Kavouss Arasteh: Not to use it at all but stay with implementation only Rubens Kuhl: If CSC doesn't have a say in preventing a matter to be discussed at IRT, then when don't have to discuss what is execution, what is implementation, what is policy... avri doria: if we decide to use execution, we will obviously need to define it. I suggest we try and base our discrimination between the two based on the analysis done by the GNSO and published as a report. avri doria: and as Anee said, it determined that the two were never completely disentagled, though at the beginning of a project it was mostly policy and at the end it was mostly implementation. - IRT has a definitive beginning and end, may be helpful to think about something like a standing committee remains to address issues down the line. - Perhaps such a standing committee could help determine whether the issue needs to go to the IRT or perhaps requires consultation with a group of experts. - How would standing committee differ from the IRT? - There is no concept of a standing IRT. - A standing committee would not necessarily be composed of GNSO volunteers. They could be experts that provide a different type of assistance. chat excerpt: Greg Shatan: How would the ExCSC differ from the IRT? Kavouss Arasteh: yes to the question you raised Rubens Kuhl: Greg, usually less members, with roles representing different parties. In IANA they are gTLD registries, non-registries GNSO, ccTLD registries, RIRs, protocols; Kavouss Arasteh: Jeff, as you suggested ,we need to give a hand to ICANN Staff in those circumstances - At times staff did want to consult with experts but did not have a mechanism to do so. - The CSC was created for a specific reason. Having a special group to look at customer concerns (those that deal directly with the IANA function) made sense in this case. - There is a risk of ICANN becoming a self-regulatory body. This is counter to the multistakeholder model. - Keeping things in the hands of the "customers" is a troubling development. - This discussion is heading in a direction that we should return from. chat excerpt: Rubens Kuhl: For a SubPro CSC, it could be "applicants", "current registries", "objectors" and "communities" or something like that. Trang Nguyen: The process documentation work that we recently did can help to clarify the phases. There is the policy development process, carried out by the community. Once the Board adopts, then it's the policy implementation phase carried out by ICANN and IRT. This phase concludes upon the effective date of the policy, which in this context would be the opening of the application process. Then it moves into the operations phase. The CPIF and IRT are applicable to the policy implementation phase. Once the policy is in operation and issues arise, we need some guidance on how to deal with issues, particularly issues where the policy is silent on. - One distinction is one on timing. This is something that can be better clarified in a graphic. ACTION ITEM: Staff will develop a graphic to show the timing issue. - What if ICANN changed the mechanism by which they conducted testing, which had an impact of pre-delegation testing? The change would still be achieving the same policy and criteria. This does not seem to be a policy or implementation issue, but more of an operational issue that impacts applicants. Would a different process be appropriate? - If someone cares and feels that it creates a different outcome, at the very least you have an implementation issue. - But if it impacts applicants, the applicants will care, even if it does not impact every constituency. - The testing provider released notes on the testing protocol, it was not something that the IRT was involved. - If people care about the issue, it should go back to the multistakeholder community, not just to those who have a vested interest in the outcome. chat excerpt: Kavouss Arasteh: How we are ensured that such action does not have any impact on policy developped Rubens Kuhl: @Kavouss, that can be a post-facto control: somebody would file an RfR (Request for Consideration) for such action. Rubens Kuhl: I did care a lot for that particular change Jeff mentioned. Maxim Alzoba (FAITID): I think multistakeholder model works with policy and not with at implementation Greg Shatan: I absolutely disagree with the idea that the multistakeholder model doesn't work with implemementation. Greg Shatan: IRTs are multistakeholder. Kavouss Arasteh: I also have difficulties the MSH be involved in the implementation process Trang Nguyen: The discussion around taking things back to IRTs imply that implementation needs to be changed/modified when in fact I think of the example about PDT test specs as operational evolution. From that perspective, I like Jeff's suggestion of a standing panel. avri doria: I tend to beleive that all processes in ICANN should be mulitstakeholder at their base. - Does an IRT have a specific end, or is the end of the first application period serve as a determinate end. We should go back to the documentation and see, but a long standing IRT may not be contrary to the rules. - Can we accept the changes in the document and begin working with a clean copy? - Idea of separation of responsibilities -- multistakeholder community guides policy but then implementation is a different responsibility. - Some people believe some functions should not involve the full IRT, others think the full IRT should not be the default for everything. Greg Shatan: It sounds like some people don't like the idea of IRTs? avri doria: i think that directly affected and indirectly affected are incredibly hard to disentangle. Greg Shatan: The indirectly affected can be more objective about the issues. Kavouss Arasteh: Any thing that slow down the process should be avoided