August 2017 - Gnso-newgtld-wg

Recordings, Attendance & AC Chat from New gTLD Subsequent Procedures WG call on Tuesday, 29 August 2017
by Nathalie Peregrine 01 Sep '17

01 Sep '17

Dear All, Please find the attendance of the call attached to this email and the MP3 recording below for the New gTLD Subsequent Procedures Working Group call held on Tuesday, 29 August 2017 at 03:00 UTC. Attendance of the calls is also posted on the agenda wiki page: https://community.icann.org/x/egchB MP3: http://audio.icann.org/gnso/gnso-new-gtld-subsequent-29aug17-en.mp3 Adobe Connect Recording: https://participate.icann.org/p1a2xmy6015/ The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: http://gnso.icann.org/en/group-activities/calendar[gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> ** Please let me know if your name has been left off the list ** Mailing list archives: http://mm.icann.org/pipermail/gnso-newgtld-wg/ Wiki page: https://community.icann.org/x/egchB Thank you. Kind regards, Michelle ------------------------------- Adobe Connect chat transcript for Tuesday, 29 August 2017 Michelle DeSmyter:Dear All, Welcome to the New gTLD Subsequent Procedures WG call on Tuesday, 29 August 2017 at 03:00 UTC Michelle DeSmyter:Agenda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… Kavouss Arasteh:Hi Michelle Michelle DeSmyter:Hi there Kavouss! vanda scartezini:hi everyone Michael Flemming:Afternoon, everyone. Jeff Neuman:hello Anne Aikman-Scalese (IPC):yes Jeff Michael Flemming:Loud and clear. Krishna Seeburn (Kris):loud and clear Kavouss Arasteh:Hi everybody Jeff Neuman:hello Cheryl Langdon-Orr (CLO):hi all Anne Aikman-Scalese (IPC):Hi Cheryl Jeff Neuman:Starting call soon Kavouss Arasteh:Good time to all,the participants of the most popular and crowded group Anne Aikman-Scalese (IPC):Hey Kavouss - hope this is a good time of day for you! vanda scartezini:thanks kavouss Kavouss Arasteh:Hi avri, here is 05,00 local time, your voice is sounds sleepy Annebeth Lange, ccNSO:Hello, everyone Michael Flemming:Sarah Michael Flemming:We can't hear you too well Maxim Alzoba (FAITID):Hello All Karen Day:yes Rubens Kuhl:We can hear you. Sara Bockey:no worries Kavouss Arasteh:not sufficiently high level Michael Flemming:I turned up the speakers. It might've just been me Rubens Kuhl:Since WT2 is so light on topics, we will be sending Question 18 to them... ;-) Rubens Kuhl:(Actually WT2 and WT3) Heather Forrest:Very cruel, Rubens Heather Forrest:Great to hear that we have one co-leader for new WT5. Hope we can appoint others soon. Cheryl Langdon-Orr (CLO):Heather we just like to share ;-) Jeff Neuman:Nothing yet frm GAC, but I understand they may be discussing it on their leadership meeting later this week Heather Forrest:I can do my best (from GNSO Council Chair perspective) to answer any questions on the points Avri is raising re PDP guidelines Heather Forrest:No problem Avri - I'm just going to ask about our progress in nominating a GNSO co-leader 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://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_coun… 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. Cheryl Langdon-Orr (CLO):very clear... thank you Arrive 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. Greg Shatan:The role of the GNSO Council could be covered in the webinar as well. 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 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 Annebeth Lange, ccNSO:Thanks, Rubens 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? Heather Forrest:Do we address specifically in this document how it is determined that something is policy as opposed to implementation (and vice versa)? Michael Flemming:How about a sytem that allows the applications to be submitted in document format? Michael Flemming:Ah, my apologies. 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):We lost heather. Heather Forrest:We need to know what the vendor's timeline for fix is 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 community". I honestly don't know what that means in terms of decision-making. Heather Forrest:@Jeff - one of the factors is the stress on the system. Having a "round" or "window" only opened for a brief time, with a definite closing day makes this more of an issue. Kavouss Arasteh:Agree with Greg Jim Prendergast:I wouldn't say the don't care about it. ensuring the application process is secure and fair is critical to the trust int he program. Kavouss Arasteh: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? Kavouss Arasteh:Ifully agree with that 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. Kavouss Arasteh:There is a background tlks 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.... 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 Kavouss Arasteh:eff, may we avoid to use "Execution" as 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 avri doria:27 minutes left on meeting. Anne Aikman-Scalese (IPC):Msut leave Adobe - can stay on the phone 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... Rubens Kuhl:I'm not, sorry. Rubens Kuhl:(then we) 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. Kavouss Arasteh:Yes 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. avri doria:apologies: as Annne said ... 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 Michael Flemming:Greg has his hand raised 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. Rubens Kuhl:Trang, operations phase is so much better than execution. Execution reminds me of people being killed. ;-) vanda scartezini:quite clear Trang. avri doria:i do not think there are any inherent limitations in the amont of time an IRT serves. Rubens Kuhl:But I would hope that issues where the policy is silent on should go back to the IRT, because it looks like some policy guidance was expected but not available. avri doria:and the WG makes recommendations on how an IRT will be formed and run. Greg Shatan:If policy guidance is needed, then the P&IWG processes are supposed to be used. Greg Shatan:I don't think "confusion" is the issue.... avri doria:i agree a graphic will be useful. avri doria:15 minutes left to meeting Michael Flemming:Wouldn't it be an ORT in that case? Michael Flemming:poor joke, sorry Kavouss Arasteh:How we are ensured that such action does not have any impact on policy developped Kavouss Arasteh:How we are ensured that such action wuld 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. Kavouss Arasteh:There is some voice in the backgroud when Greg speaking Greg Shatan:Apologies, I have guests. My cousin has just arrived from Los Angeles. My wife is entertaining him while I do this. Maxim Alzoba (FAITID):I think multistakeholder model works with policy and not with at implementation Kavouss Arasteh:Maxim +1 Greg Shatan:I told them I was helping to run the Internet. They were not impressed. 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. Maxim Alzoba (FAITID):ICANN staff implements, and they do not allow us to interfere directly :) avri doria:I tend to beleive that all processes in ICANN should be mulitstakeholder at their base. Greg Shatan:Oh, those pesky multistakeholders. They keep wanting to stay in the room.... Greg Shatan:I don Greg Shatan:I don't consider the role of the community to be "interference". Rubens Kuhl:Greg, I like the multistakeholders in the room... but sometimes we need the ones directed affected by something to come forward. Greg Shatan:It is guidance and review. 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. avri doria:3 minutes Kavouss Arasteh:Any thing that slow down the process should be avoided Cheryl Langdon-Orr:lots to think ovver from todays call... Thanks everyone Maxim Alzoba (FAITID):bye all Heather Forrest:Thanks Avri and Jeff Sara Bockey:thanks all Cheryl Langdon-Orr:Bye for now then Aslam G Mohamed:Thanks everyone. See you in Abu Dhabi Greg Shatan:Bye all! vanda scartezini:thanks all Annebeth Lange, ccNSO:Bye

3 3

Correction: Notes and Action Items: New gTLD Subsequent Procedures PDP WG - 29 August 2017
by Emily Barabas 30 Aug '17

30 Aug '17

Dear Working Group members, Please note that there was an error in the meeting notes that I circulated earlier for the 29 August call. Please see correction below in red. My apologies for any confusion this may have caused. It was due to a misunderstanding on my part. The notes have also been updated on the wiki. Kind regards, Emily From: Emily Barabas <emily.barabas(a)icann.org> Date: Tuesday 29 August 2017 at 13:48 To: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: Notes and Action Items: New gTLD Subsequent Procedures PDP WG - 29 August 2017 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+Pr…. 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. Cheryl Langdon-Orr plans to be an active participant in WT5. Any role from ALAC is TBD. 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…<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_coun…> 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

1 0

Notes and Action Items: New gTLD Subsequent Procedures PDP WG - 29 August 2017
by Emily Barabas 29 Aug '17

29 Aug '17

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+Pr…. 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…<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_coun…> 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

1 0

Re: [Gnso-newgtld-wg] [Ntfy-gnso-newgtld-wg] Meeting Invitation: New gTLD Subsequent Procedures Working Group call on Tuesday, 29 August 2017 03:00 UTC
by Aikman-Scalese, Anne 28 Aug '17

28 Aug '17

Jeff and Avri, The question I had was about where the REVISIONS to the Implementation Framework came from. In other words, who authored them and what changes do the new provisions make to the existing Framework that resulted from the community-wide multi-stakeholder collaboration that Alan described? That is the procedural question. Separately, I think that if we now develop a category called “operational implementation”, we may be creating yet another dichotomy that will cause “road bumps” in the next round. Most of the issues that the Policy and Implementation Working Group considered as “case studies” could also have been characterized as either “policy implementation” or “operational implementation”. One big point of consensus in the Policy and Implementation WG was that the definition should not be controlling. What was controlling was the notion that the matter “in controversy” (or if you will the “operational implementation question” ) needed to go back to the GNSO for ITS determination as to whether the issue involved policy or not. (To use the new terminology mentioned on the call today, a GNSO determination as to whether the issue involves “policy implementation” or “operational implementation”.) It may be more useful to talk about WHEN a problem arises rather than what type of problem it is. For example, I believe that under the existing Framework, while IRT (Implementation Review Team) is still convened, IRT is supposed to figure out whether the issue needs to be raised with GNSO or not. If we are trying to create a mechanism that will operate once IRT is disbanded, that is another story - who makes the call? (Someone asked a question in the doc about the possible need for a Standing IRT.) On the merits: At issue here is “who decides whether an issue arising during the implementation phase is sufficiently controversial as to require GNSO advice?” My point is that we should not revert to a system where ICANN staff is making the determination itself as to whether GNSO needs to consider the issue. That was the whole reason behind the Policy and Implementation Working Group work. Issues like “digital archery”, “name collision”, and changes in the terms of Registry Agreement can easily fall into the bucket of needing to be considered by the GNSO for either “Input”, “Guidance”, “Expedited PDP”, or “PDP”. Labeling an issue as “operational implementation” doesn’t change that. This is because, as we have learned with the history of the new gTLD program, if you are for the solution that ICANN.org develops to the issue that arises during implementation, then it is “operational implementation”. On the other hand, if you are against the solution, it’s “policy implementation”. Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman(a)lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image003.png@01D30F94.29F53AB0] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: ntfy-gnso-newgtld-wg-bounces(a)icann.org [mailto:ntfy-gnso-newgtld-wg-bounces@icann.org] On Behalf Of Michelle DeSmyter Sent: Monday, August 07, 2017 2:34 PM To: ntfy-gnso-newgtld-wg(a)icann.org Cc: gnso-secs(a)icann.org Subject: [Ntfy-gnso-newgtld-wg] Meeting Invitation: New gTLD Subsequent Procedures Working Group call on Tuesday, 29 August 2017 03:00 UTC Dear all, The following call for the New gTLD Subsequent Procedures Working Group call on Tuesday, 29 August 2017 at 03:00 UTC. 20:00 PDT, 23:00 EDT, 04:00 London, 05:00 CEST for other places see: http://tinyurl.com/y94xsmxx ADOBE CONNECT Room : https://participate.icann.org/newgtldswg If you require a dial-out, please email me with your preferred contact number at gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> Let me know if you have any questions. Thank you. Kind regards, Michelle ____________________________________________________________________________ Participant passcode: NEW GTLD Dial in numbers: Country Toll Numbers Freephone/ Toll Free Number ARGENTINA 0800-777-0519 AUSTRALIA ADELAIDE: 61-8-8121-4842 1-800-657-260 AUSTRALIA BRISBANE: 61-7-3102-0944 1-800-657-260 AUSTRALIA CANBERRA: 61-2-6100-1944 1-800-657-260 AUSTRALIA MELBOURNE: 61-3-9010-7713 1-800-657-260 AUSTRALIA PERTH: 61-8-9467-5223 1-800-657-260 AUSTRALIA SYDNEY: 61-2-8205-8129 1-800-657-260 AUSTRIA 43-1-92-81-113 0800-005-259 BELGIUM 32-2-400-9861 0800-3-8795 BRAZIL SAO PAULO: 55-11-3958-0779 0800-7610651 CHILE 1230-020-2863 CHINA CHINA A: 86-400-810-4789 10800-712-1670 CHINA CHINA B: 86-400-810-4789 10800-120-1670 COLOMBIA 01800-9-156474 CROATIA 080-08-06-309 CZECH REPUBLIC 420-2-25-98-56-64 800-700-177 DENMARK 45-7014-0284 8088-8324 EGYPT 0800000-9029 ESTONIA 800-011-1093 FINLAND 358-9-5424-7162 0-800-9-14610 FRANCE LYON: 33-4-26-69-12-85 080-511-1496 FRANCE MARSEILLE: 33-4-86-06-00-85 080-511-1496 FRANCE PARIS: 33-1-70-70-60-72 080-511-1496 GERMANY 49-69-2222-20362 0800-664-4247 GREECE 30-80-1-100-0687 00800-12-7312 HONG KONG 852-3001-3863 800-962-856 HUNGARY 36-1-700-8856 06-800-12755 INDIA INDIA A: 000-800-852-1268 INDIA INDIA B: 000-800-001-6305 INDIA INDIA C: 1800-300-00491 INDONESIA 001-803-011-3982 IRELAND 353-1-246-7646 1800-992-368 ISRAEL 1-80-9216162 ITALY MILAN: 39-02-3600-6007 800-986-383 ITALY ROME: 39-06-8751-6018 800-986-383 ITALY TORINO: 39-011-510-0118 800-986-383 JAPAN OSAKA: 81-6-7878-2631 0066-33-132439 JAPAN TOKYO: 81-3-6868-2631 0066-33-132439 LATVIA 8000-3185 LUXEMBOURG 352-27-000-1364 8002-9246 MALAYSIA 1-800-81-3065 MEXICO GUADALAJARA (JAL): 52-33-3208-7310 001-866-376-9696 MEXICO MEXICO CITY: 52-55-5062-9110 001-866-376-9696 MEXICO MONTERREY: 52-81-2482-0610 001-866-376-9696 NETHERLANDS 31-20-718-8588 0800-023-4378 NEW ZEALAND 64-9-970-4771 0800-447-722 NORWAY 47-21-590-062 800-15157 PANAMA 011-001-800-5072065 PERU 0800-53713 PHILIPPINES 63-2-858-3716 1800-111-42453 POLAND 00-800-1212572 PORTUGAL 351-2-10054705 8008-14052 ROMANIA 40-31-630-01-79 RUSSIA 8-10-8002-0144011 SAUDI ARABIA 800-8-110087 SINGAPORE 65-6883-9230 800-120-4663 SLOVAK REPUBLIC 421-2-322-422-25 0800-002066 SOUTH AFRICA 080-09-80414 SOUTH KOREA 82-2-6744-1083 00798-14800-7352 SPAIN 34-91-414-25-33 800-300-053 SWEDEN 46-8-566-19-348 0200-884-622 SWITZERLAND 41-44-580-6398 0800-120-032 TAIWAN 886-2-2795-7379 00801-137-797 THAILAND 001-800-1206-66056 TURKEY 00-800-151-0516 UNITED ARAB EMIRATES 8000-35702370 UNITED KINGDOM BIRMINGHAM: 44-121-210-9025 0808-238-6029 UNITED KINGDOM GLASGOW: 44-141-202-3225 0808-238-6029 UNITED KINGDOM LEEDS: 44-113-301-2125 0808-238-6029 UNITED KINGDOM LONDON: 44-20-7108-6370 0808-238-6029 UNITED KINGDOM MANCHESTER: 44-161-601-1425 0808-238-6029 URUGUAY 000-413-598-3421 USA 1-517-345-9004 866-692-5726 VENEZUELA 0800-1-00-3702 VIETNAM 120-11751 ________________________________ 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.

3 4

Proposed Agenda: New gTLD Subsequent Procedures Working Group, 29 August 2017 at 03:00 UTC
by Steve Chan 25 Aug '17

25 Aug '17

Dear WG Members, Below, please find the proposed agenda for the New gTLD Subsequent Procedures WG meeting scheduled for Tuesday (Monday for some), 29 August 2017 at 03:00 UTC. Please note, this call is scheduled for 90 minutes. Welcome/SOIs Work Track Updates Drafting Team Discussion – Predictability Framework (https://docs.google.com/document/d/1lzXxBLMtFr03BKnHsa-Ss7kR7EAJt7pCI1EP3H8…) AOB Best, Steve Steven Chan  Policy Director, GNSO Support ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536  steve.chan(a)icann.org mobile: +1.310.339.4410 office tel: +1.310.301.5800 office fax: +1.310.823.8649 Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages. Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO Follow the GNSO on Facebook: https://www.facebook.com/icanngnso/ http://gnso.icann.org/en/

2 1

Recordings, Attendance, AC Chat New gTLD Subsequent Procedures Working Group call on Monday, 07 August 2017 20:00 UTC
by Michelle DeSmyter 07 Aug '17

07 Aug '17

Dear All, Please find the attendance of the call attached to this email and the MP3 recording below for the New gTLD Subsequent Procedures Working Group call held on Monday, 07 August 2017 at 20:00 UTC. Attendance of the calls is also posted on the agenda wiki page: https://community.icann.org/x/wAAhB MP3: http://audio.icann.org/gnso/gnso-new-gtld-subsequent-07aug17-en.mp3 Adobe Connect Recording: https://participate.icann.org/p25mnmq00e8/ The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: http://gnso.icann.org/en/group-activities/calendar[gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> ** Please let me know if your name has been left off the list ** Mailing list archives: http://mm.icann.org/pipermail/gnso-newgtld-wg/ Wiki page: https://community.icann.org/x/wAAhB Thank you. Kind regards, Michelle ------------------------------- Adobe Connect chat transcript for Monday, 07 August 2017 Michelle DeSmyter:Dear All, Welcome to the New gTLD Subsequent Procedures WG call Monday, 07 August 2017 at 20:00 UTC Michelle DeSmyter:Agenda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… Annebeth Lange:Good evening from Norway! Jeff Neuman:Good afternoon from DC Katrin Ohlmer, DOTZON:Good evening! Anne Aikman-Scalese (IPC):Supposedly I have joined the call but I cannot hear anything. Jeff Neuman:@Anne - did you hear me > Anne Aikman-Scalese (IPC):Yes thanks Jeff Jeff Neuman:ok...2 minute warning Maxim Alzoba (FAITID):hello all! Cheryl Langdon-Orr (CLO):hi all Vanda Scartezini:hi everyone. Bruna Santos:Hello, everyone! Kavouss Arasteh:pls kindly speak more slowly Kavouss Arasteh:Dear All, Heather Forrest:I'm having trouble with computer speakers and can't hear so will re-start and be back very shortly Kavouss Arasteh: pls kindly speak slowly Maxim Alzoba (FAITID):example of .wine? Emily Barabas:The recording from the most recent WT3 call is available here: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… Susan Payne:dotAmazon involved the IO too Avri Heather Forrest:I'm back and sound is working now - apologies Maxim Alzoba (FAITID):distorted sound Vanda Scartezini:too close to the mic Anne Aikman-Scalese (IPC):COMMENT: RE next steps we reviewed in Work Track 4, Rubens asked what additional advice we thought would be necessary. I expressed the opinion that I would need to see the proposed draft Framework for Name Collision in order to understand whether or not we needed additional technical advice. Emily Barabas:The upcoming call for WT1 will be 3:00 UTC tomorrow, Tuesday 8 August Vanda Scartezini:difficult to hear Hadia Elminiawi:can not hear ypu phil Aslam G Mohamed:Hi All. My apologies for getting in a bit late. It's bad weather here in New York. Aslam Mohamed. Anne Aikman-Scalese (IPC):COMMENT: In Work Track 4, name collisions, two issues relate to who will make the judgment as to whether a string applied for represents a low, medium, or high risk string. Second question relates to when ICANN.org may grant a discretionary waiver in relation to the 90 day controlled interruption period. We may need technical advice on these two points. Susan Payne:can you confirm what will be discussed on 10 August - it wasn't very clear Emily Barabas:The two "matrix" documents related the reserved names are available here -- Top-Level Reserved Names: https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_spread… Reserved Names: https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_spread… Emily Barabas:sorry, the links published a bit oddly Susan Payne:thanks - sound was a bit muffled for me Emily Barabas:Top-Level Reserved Names: https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_spread… Emily Barabas:Second-Level Reserved Names: https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_spread… Tom Dale:Jeff, the GAC Chair is on leave. Can you please send to me so I can forward to the GAC leadership group. Steve Chan:Tom, thank you for letting us know. We will forward the message to you for distribution to the GAC leadership group. Mark Carvell GAC UK rep:GAC Vice Chairs of whom I'm one will advise Thomas on his return from leave. Jim Prendergast:notes answerd my question - thanks Kurt Pritz:Paste the link in here? Steve Chan:Kurt, here: https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume… Annebeth Lange:It will be important for WT5 that the number of members attending are balanced between the different stakeholdergroups Kurt Pritz:Gracçias Steve Chan:And agenda item 5 is here: https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume… Cheryl Langdon-Orr (CLO):indeed Annabeth Kavouss Arasteh:Jeff, are we discussing the title"requirement Considered *? Heather Forrest:@Kavouss, I believe Jeff is discussing the heading 'Application Submission Periods' Vanda Scartezini:raounds is the option I beleive Alexander Schubert:ICANN will provide us with an annual rate of application processing. E.g.: 2,500 applications per year. Annebeth Lange:Do we expect that when the next round opens, the AGB (or whatever it will be called) then will be the same for later rounds? Vanda Scartezini:we did a survey in this region about the intention to apply Maxim Alzoba (FAITID):@Alexander, as I understand it is more like 1000 applications per year now Alexander Schubert:If we get 5,000 applications then for 2 years ICANN won't be able to process any new application submissions anyway. So we have those years to make adjustments. Kavouss Arasteh:"Remedial Period " or "Adjustment Period " instead of " review Period " Alexander Schubert:So number of applications divided by ICANN's processing speed determines the earliest start of the next round! Phil Buckingham: @ alexander - it is a question of what delegation rate the root zone can take . 10000 per year possible ? Kavouss Arasteh:Jeff , That seems an option to establish "Stading Panel is Maxim Alzoba (FAITID):Alexander@ I think some ICANN letters might give a hint on a next round time, like https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_syste… Kavouss Arasteh:Kavouss Arasteh: Jeff , That seems an option to establish "Stading Panel Kurt Pritz:old Vanda Scartezini: i beleive 1.5 years after the end of the first round looks great Alexander Schubert:Why allowing application submissions when knowing that ICANN can't process any for X years? Let's pile up demand - why avoiding competition? Maxim Alzoba (FAITID):@Alexander, I think it might be an interest rate or something, for example 26k applications give 25 years for the last thousand Maxim Alzoba (FAITID):so finances are secured and it gives some stability Kurt Pritz:I think if you paid someone 185K per application, they could be processed "infinitely" quickly Maxim Alzoba (FAITID):I hope we do not see auctions for queue Maxim Alzoba (FAITID):numbers Susan Payne:well I think there are some things we are discussing which could assist on the evaluation rate - pre-certifying RSPs for example would speed up subsequent evaluation Paul McGrady:+1 Susan. Why evaluate and revaluate and revaluate and revaluate and revaluate the same people endlessly. Alexander Schubert:Precisely. And some here want to reduce the effective application cost to just $50k - then we easily get a 5 figure application roster. Jeff Neuman:I am trying to put a fence around the unknowns Phil Buckingham:i dont think the number of evaluators will be a limiting factor . This can be scaled up . accordingly Cheryl Langdon-Orr (CLO):I suppose many would agree with not having money held Alan Cheryl Langdon-Orr (CLO):WT4 has asked for clarification on that Alan Cheryl Langdon-Orr (CLO):the 1k "limit" I mean Maxim Alzoba (FAITID):Also companies bleeding money during the time in the queue, and it is more than 185 for the single application (in case a single TLD applicand) Vanda Scartezini:for me limiting 1,000 for each round and considering time we had last round ( around 1.5 year) keep the same lenght looks viable Alexander Schubert:Maybe we simply double the application fee next round - and depending on demand only lower it if ICANN can process fast enough. Trang Nguyen:2.1.4.2 of the PIRR has some information regarding evaluation timeframe. Per the timeline provided for in the AGB, the estimated timeline for processing 1930 applications is 25 months. ICANN completed IE in 18 months, that's with prioritization taking place late in the process (December of 2012) and with additional time (outreach process) for applicants to respond to CQs. Maxim Alzoba (FAITID):@Vanda, the last time it was 2000 and not 1000 Jeff Neuman:Ultimately, I would love to be able to give ICANN a list of the types of variables for them to model out. Maxim Alzoba (FAITID):digital archery attempt of the queueing Vanda Scartezini:yes - i am considering limiting for 1,000 just to have a number and time enough to not expend too much paying large groups to evaluation Steve Chan:To Trang's comment, PIRR stands for Program Implementation Review Report and is available here: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_news_ann… Gg Levine (NABP):GAC Advice may be an additional variable Robin Gross:There will always be "glitches" ;-) Jeff Neuman:hopefully less minor glitches in the future Maxim Alzoba (FAITID):@Vanda, given the 7-8 years between rounds (what we see now), 1000 might not be enough Maxim Alzoba (FAITID):@Jeff, also we need to hope not to have major ones too Trang Nguyen:ICANN's criteria for vendor selection in the 2012 round was that the firms had to be global with the ability to scale because we did not know what the volume would be. Trang Nguyen:All 3 firms engaged for financial and technical evaluation had the ability to scale. Vanda Scartezini:maxim, i am proposing 1.5 years between rounds - and for this new round I am not betting on more than 1,000 Aslam G Mohamed:To scale up ICANN can also consider outsourcing? Donna Austin, Neustar:Trang: will ICANN be starting from scratch in terms of building a replacement to TAS or is something else in train? Robin Gross:That makes sense, Jeff. Kavouss Arasteh:Dear Secretariat, pls capture my thoughts in summary Maxim Alzoba (FAITID):as I understand the current model - applicants pay and then , over time , the plan is revealed (or created) Maxim Alzoba (FAITID):in mathimatics attempts to optimize model with too many independent variables usually have no real solutions Trang Nguyen:@Donna, TAS was retired after Initial Evaluation of the 2012 round and it's not expected that we will resurrect it. Donna Austin, Neustar:@Trang, so you intend to build a new system? Maxim Alzoba (FAITID):Most probably new GDD portal have applicants part over the time Phil Buckingham:is this a top down or bottom up. approach . Ultimately it is down to an ICANN budget allocated ., which needs to flexed Trang Nguyen:@Donna, yes a new tool to accept applications will be developed. Emily Barabas:Drafting team sign up: https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume… Christa Taylor:Perhaps the type of application and the difference in processing time should be considered and whether it impacts the ceiling volume i.e. if a brand only takes 75% of the time a generic application takes than it might change the equation Jeff Neuman:we hear you avri Michelle DeSmyter:trying to locate the line Hadia Elminiawi:we hear the beep too Paul McGrady:Yay! Aslam G Mohamed:Flood Warning ⚠️?! Anne Aikman-Scalese (IPC):So a new application submission system could have its own issues. Maxim Alzoba (FAITID):hopefully it is beta tested unlike the old one Maxim Alzoba (FAITID):before the applicants pay Kavouss Arasteh:Additional interval to be added to the initial basic period or interval period should calculated with the aid of a variable curve or variable lines with some logical mathematic process interval ,rather than we decide arbitrarily to add additional time with arbitrarily selected application number Paul McGrady:I guess I don't understand what the issue is? This document, whether or not drafted by Staff, seems to flow directly from GNSO Principle A on new gTLDs. "New generic top-level domains (gTLDs) must be introduced in an orderly, timely and predictable way." Plus, we are being given a chance to review it (on this call). Steve Chan:There is a footnote in the document to the existing framework that ICANN uses now to implement Consensus Policies: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_policy_i… Kurt Pritz:Following Paul's comment, the current policy is: "All applicants for a new gTLD registry should therefore be evaluated against transparent and predictable criteria, fully available to the applicants prior to the initiation of the process. Normally, therefore, no subsequent additional selection criteria should be used in the selection process." What edits are we proposing? Jeff Neuman:Take an example.......How to process applications for purposes of queueing.......In 2012, it was Digital Archery......well, we found out that implementation of that was flawed. It took MONTHS to figure out a new queuing mechanism. Hopefully having this framework will result in having a MUCH smaller delay if something like that comes up again Jeff Neuman:(Ignore the example), but focus on the principle Anne Aikman-Scalese (IPC):@Paul - issues arising during implementation was the whole point of Policy and Implementation Working Group work where participants from all stakeholders was open. Who exactly is working on the revisions to the Framework? Kavouss Arasteh:Predictability IS A COMPLEX PROCESS WHICH DEPENDS ON MANY FACTORS ON WHICH WE MAY NOT HAVE ALL INPUTS Kavouss Arasteh:Sorry for CAP , I repeat, Kavouss Arasteh:Predictability is a complex process which depends on many factors on which we may not have all inputs Steve Chan:Thanks Trang, I had raised by head to try and draw that distinction. Kavouss Arasteh:We need to separate the policy development and its implementation Jeff Neuman:"Implementation of Policy" is different than implementation of the program Kurt Pritz:@ Jeff - Can you explain? Kavouss Arasteh:Policy and implementation are two different things Kavouss Arasteh:How we could implement the policy? Aslam G Mohamed:bye Anne Aikman-Scalese (IPC):COMMENT: Jeff, I see your point but you may recall there was huge disagreement in 2012 over what was policy and what was implementation. Similarly we could easily have folks disagreeing in the next round as to whether something is implementation of policy or operational implementation. You go back down the same hole. Vanda Scartezini:thanks you Avri Anne Aikman-Scalese (IPC):COMMENT: Reminder that the whole issue in 2012 was that ICANN CEO and staff considered items implementation whereas GNSO considered them policy. You actually authored the letter to the Board telling them they had to come back to the GNSO. So why would your new category of "operational implementation" be any different? Phil Buckingham:29 th for Europeans 03.00 UTC Vanda Scartezini:thank you all. leaving now Emily Barabas:upcoming schedule of topics to be considered in WTs: https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_spread… Sara Bockey:thanks all Robin Gross:Thanks Avri and Jeff. Bye all! Alexander Schubert:Bye...... Cheryl Langdon-Orr (CLO):good call everyonr bye ðŸ‘‹ the time being Katrin Ohlmer, DOTZON:thanks and bye! Hadia Elminiawi:thanks jeff and all Hadia Elminiawi:bye

1 0

Actions/Discussion Notes: New gTLD Subsequent Procedures PDP WG 07 August
by Julie Hedlund 07 Aug '17

07 Aug '17

Dear WG Members, Please see below the action items and discussion notes captured by staff from the meeting on 07 August. 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. See the referenced documents: Drafting Team Discussion – Applications Assessed in Rounds (https://docs.google.com/document/d/1u3UzvZIXzjnxtklgPmqArqff6dyckUbyuzWyLz7…) Drafting Team Discussion – Predictability Framework (https://docs.google.com/document/d/1lzXxBLMtFr03BKnHsa-Ss7kR7EAJt7pCI1EP3H8…) Excerpts from the chat room are included for ease of reference. Best regards, Julie Julie Hedlund, Policy Director Actions/Discussion Notes 1. Work Track Updates: Work Track 1: Christa Taylor -- We have a call on 08 August at 0300 UTC. Looking at the CC2 responses on systems and applications fees. Work Track 2: Phil Buckingham -- We began to review the CC2 input on reserved names and proposed changes to the AGB. Looking at the matrix on reserved names at the top and second level. Next call is 10 August at 2100 UTC. -- The two "matrix" documents related the reserved names are available here -- Top-Level Reserved Names: https://docs.google.com/spreadsheets/d/1x74w58a9UaTTVulCMmrI45iTiHao6Hf1s8e… Reserved Names: https://docs.google.com/spreadsheets/d/1WgsYlUpKI_QGuIOlOxtu4uBBj8ZWgD0bTw8… -- See: Top-Level Reserved Names: https://docs.google.com/spreadsheets/d/1x74w58a9UaTTVulCMmrI45iTiHao6Hf1s8e…; See: Second-Level Reserved Names: https://docs.google.com/spreadsheets/d/1WgsYlUpKI_QGuIOlOxtu4uBBj8ZWgD0bTw8… -- Note that this discussion excludes geographic names at the top level, which will form the basis for Work Track 5. -- Question: On reserved names on registries having a certain number or a limited number of names. That became an issue. What was the public comment on that and where does the group stand? Response: That is one of the topics in the matrix. Work Track 3: Robin Gross -- Met last week to go over some of the legal rights objection questions and independent objector issues. We got as far as 3.1.7. Next call is Tuesday, 15 August. We will get into some of the community objection issues. -- Question: Are we on a correct track to have an independent objector? What is our experience? -- That issue is ongoing in the Work Track. There have been positives and negatives about the independent objection. There was a discussion about the statistics too. People are re-reading the independent objector's report. Recordings are available from the last discussion. The recording from the most recent WT3 call is available here: https://community.icann.org/x/twAhB -- Question: Which track is addressing independent review? Response: Work Track 3. Work Track 4: Cheryl Langdon-Orr -- Met last week with a continuing discussion on CC2 responses and proposed text we may be making. We will continue the discussion with the coming meeting. Last week we focused on Universal Acceptance. Next call is 17 August at 0300 UTC. Finalizing the CC2 responses. Other pieces of work that are poised to be done. Work Track 5: Jeff Neuman -- Sent emails to the chairs of the SOs and ACs -- GAC, ccNSO, GNSO, and ALAC -- asking for them to put forward representatives to be co-chairs. Goal is to have a call with the co-chairs in August. Then we will put out a call for volunteers for the community. Hoping to have a scope ready by mid-September. -- Question: What is the mandate for this group and how many representatives will participate from each SO/AC? Response: At this point we've asked for one leader to be nominated from each SO/AC. Then we will hold an initial call to discussion membership, voting, etc. All working groups are open to everyone so membership will be open to everyone. The leaders will discuss question on how voting will be taken. Terms of reference have not been drafted yet. The PDP WG is working on an outline. >From the chat: Anne Aikman-Scalese (IPC): COMMENT: In Work Track 4, name collisions, two issues relate to who will make the judgment as to whether a string applied for represents a low, medium, or high risk string. Second question relates to when ICANN.org may grant a discretionary waiver in relation to the 90 day controlled interruption period. We may need technical advice on these two points. 2. Drafting Team Discussion – Applications Assessed in Rounds: See: https://docs.google.com/document/d/1u3UzvZIXzjnxtklgPmqArqff6dyckUbyuzWyLz7… -- Change title to "Application Submission Periods". The Google Document is open to anyone to edit. Requirements Considered -- look at future methodology: -- On the last call the feeling from the group was that we acknowledged that the first application period will be that of a round. A time period in which we would collect applications, then stop, and then go into an evaluation period -- rather than first come, first served. -- Criteria that we should measure any methodology against -- clarify and predictabililty; no undefined gaps between processing and acceptance; choice of methodology must address the impact on other areas of the program; should not negatively impact operational effectiveness and the fiscal feasibility of the program. -- In 2012 we had a round that started in January and closed in early June or late May. Between that time period and today we are over 5 years past that and no definitive application period has been announced. So there still is a lack of clarity and predictability. Assume that there will be more predictability. -- Question we started talking about last week was whether or not review periods should be built in at least from the next application window and whatever we do after that. Some said no and others were advocating for review periods. Discussion: -- Don't see how we can presume that there will be no problems in the round so no potential adjustments. Don't see how we can't allow for some level of review. -- Perference is just to move forward with the next round. Rather find another mechanism to do some tweaking rather than going through the process as we are doing now. Move forward as quickly as possible. -- Perhaps we should call them "adjustments" rather than a "review". -- What do we mean by "review"? Is it an ongoing process or do we stop everything? Could we calendar multiple rounds? Need to define this. -- Sounds like -- to recap -- there is a feeling by some that we should go straight into a following round, but also a sense that there should be some kind of lightweight adjustment period. Questions: 1) If we have this adjustment period when would be start that -- what would be a triggering event? When the application period closes? 2) If we get more applications than expected that would be one variable to think about extend the period between one ending and the next one starting. What would increase or decrease that time-period between rounds? Discussion: -- On other variables: the processing rate of applications. Currently only 1000 per year. Ask SSAC or someone else to come up with another figure. -- We have a policy in place that says we are going to have a round 1 year after the last one, which we didn't do. We can make a recommendation but without agonizing over our words there since we have no way of controlling what happens after this next round. -- Two choices: 1) recommend a round and a follow up; 2) recommend a round and then the open sort of application period. -- Other ways to think about how we would recommend an adjustment period -- such as a standing committee that looks at issues that arrive to some level and then they have to solve the issues within a certain amount of time. It is a tough issue and there are intervening events. -- Even if we said that the third round should be 1 year after the close of the acceptance window for applications, we know that the number of applications could be a variable in the delay in the next round, as well as the rate in processing applications -- 1) 1,000 per year for delegation, and 2) rate at which ICANN could process the evaluations. -- Perhaps we just fix one year and then say depending on the number of applications. -- The real question is where do we want a delay to be. Are we really serious about worrying about 1,000 per year being the limiting factor? Some information could be useful there. -- If we can map out the variables then we can provide for predictability. -- One of the reasons we had the long delay in getting TLDs to delegation was not necessarily the processing but the substantive discussions on plural, name collisions, changes to RAA, which took a long time to reserve. Otherwise we would have seen a faster delegation rate. -- Question: Can we have some information from ICANN on the processing capability based on type of application? Response: An outcome could be from this WG to present ICANN with variables -- how long would it take you to process if we present these scenarios. Once we present these variables it isn't going to be a definitive number but will be a scale. -- Reasonable assumption that even when this round opens there will be road bumps. There also is the issue of how long it takes to get SSAC advice. Also, the name collision evaluation will take time. >From the chat: Alexander Schubert: ICANN will provide us with an annual rate of application processing. E.g.: 2,500 applications per year. Annebeth Lange: Do we expect that when the next round opens, the AGB (or whatever it will be called) then will be the same for later rounds? Vanda Scartezini: we did a survey in this region about the intention to apply Maxim Alzoba (FAITID): @Alexander, as I understand it is more like 1000 applications per year now Alexander Schubert: If we get 5,000 applications then for 2 years ICANN won't be able to process any new application submissions anyway. So we have those years to make adjustments. Kavouss Arasteh: "Remedial Period " or "Adjustment Period " instead of " review Period " Alexander Schubert: So number of applications divided by ICANN's processing speed determines the earliest start of the next round! Phil Buckingham: @ alexander - it is a question of what delegation rate the root zone can take . 10000 per year possible ? Kavouss Arasteh: Jeff , That seems an option to establish "Stading Panel is Maxim Alzoba (FAITID): Alexander@ I think some ICANN letters might give a hint on a next round time, like https://www.icann.org/en/system/files/correspondence/crocker-to-diaz-26jul1… Kavouss Arasteh: Kavouss Arasteh: Jeff , That seems an option to establish "Stading Panel Vanda Scartezini: i beleive 1.5 years after the end of the first round looks great Alexander Schubert: Why allowing application submissions when knowing that ICANN can't process any for X years? Let's pile up demand - why avoiding competition? Maxim Alzoba (FAITID): @Alexander, I think it might be an interest rate or something, for example 26k applications give 25 years for the last thousand Maxim Alzoba (FAITID): so finances are secured and it gives some stability Kurt Pritz: I think if you paid someone 185K per application, they could be processed "infinitely" quickly Maxim Alzoba (FAITID): I hope we do not see auctions for queue Maxim Alzoba (FAITID): numbers Susan Payne: well I think there are some things we are discussing which could assist on the evaluation rate - pre-certifying RSPs for example would speed up subsequent evaluation Paul McGrady: +1 Susan. Why evaluate and revaluate and revaluate and revaluate and revaluate the same people endlessly. Alexander Schubert: Precisely. And some here want to reduce the effective application cost to just $50k - then we easily get a 5 figure application roster. Cheryl Langdon-Orr (CLO): I suppose many would agree with not having money held Alan Cheryl Langdon-Orr (CLO): WT4 has asked for clarification on that Alan Cheryl Langdon-Orr (CLO): the 1k "limit" I mean Maxim Alzoba (FAITID): Also companies bleeding money during the time in the queue, and it is more than 185 for the single application (in case a single TLD applicand) Vanda Scartezini: for me limiting 1,000 for each round and considering time we had last round ( around 1.5 year) keep the same lenght looks viable Alexander Schubert: Maybe we simply double the application fee next round - and depending on demand only lower it if ICANN can process fast enough. Trang Nguyen: 2.1.4.2 of the PIRR has some information regarding evaluation timeframe. Per the timeline provided for in the AGB, the estimated timeline for processing 1930 applications is 25 months. ICANN completed IE in 18 months, that's with prioritization taking place late in the process (December of 2012) and with additional time (outreach process) for applicants to respond to CQs. Maxim Alzoba (FAITID): @Vanda, the last time it was 2000 and not 1000 Jeff Neuman: Ultimately, I would love to be able to give ICANN a list of the types of variables for them to model out. Maxim Alzoba (FAITID): digital archery attempt of the queueing Vanda Scartezini: yes - i am considering limiting for 1,000 just to have a number and time enough to not expend too much paying large groups to evaluation Steve Chan: To Trang's comment, PIRR stands for Program Implementation Review Report and is available here: https://www.icann.org/news/announcement-2016-01-29-en Gg Levine (NABP): GAC Advice may be an additional variable Robin Gross: There will always be "glitches" ;-) Jeff Neuman: hopefully less minor glitches in the future Maxim Alzoba (FAITID): @Vanda, given the 7-8 years between rounds (what we see now), 1000 might not be enough Maxim Alzoba (FAITID): @Jeff, also we need to hope not to have major ones too Trang Nguyen: ICANN's criteria for vendor selection in the 2012 round was that the firms had to be global with the ability to scale because we did not know what the volume would be. Trang Nguyen: All 3 firms engaged for financial and technical evaluation had the ability to scale. anda Scartezini: maxim, i am proposing 1.5 years between rounds - and for this new round I am not betting on more than 1,000 Aslam G Mohamed: To scale up ICANN can also consider outsourcing? Donna Austin, Neustar: Trang: will ICANN be starting from scratch in terms of building a replacement to TAS or is something else in train? Robin Gross: That makes sense, Jeff. Kavouss Arasteh: Dear Secretariat, pls capture my thoughts in summary Maxim Alzoba (FAITID): as I understand the current model - applicants pay and then , over time , the plan is revealed (or created) Maxim Alzoba (FAITID): in mathimatics attempts to optimize model with too many independent variables usually have no real solutions Trang Nguyen: @Donna, TAS was retired after Initial Evaluation of the 2012 round and it's not expected that we will resurrect it. 3. Drafting Team Discussion – Predictability Framework: See: https://docs.google.com/document/d/1lzXxBLMtFr03BKnHsa-Ss7kR7EAJt7pCI1EP3H8…) -- If there are no objections as we walk through the document we will start accepting changes. Anticipated Outcome -- Second paragraph talks about policy implementation and governed by the Consensus Policy Implementation Framework -- compliment that and not to change it. Community Engagement -- Last time the process was to put together a general policy framework with a few implementation guidelines. -- Method of developing policy has gotten more complicated. Strive for "clear recommendations that can be implemented in order to result in a program where there is minimal ambiguity or change needed." -- Hopefully we are producing something that won't be a surprise for people. -- Question: Trying to understand difference between the Consensus Policy Implementation Framework and in the manuals that were developed for implemation in the GNSO procedures? Responses: The Expedited PDP has been implemented. They are part of the framework for developing the policy now approved. -- Question: Where did the problem statement come from and where did this policy come from? Response: This is the policy process established by the GNSO. This is one of the overarching issues. The original charter for the PDP WG had issues. We grouped the issues logically so they would be in discrete work tracks. This one is on a predictable model. -- The community collaborated in the development of the Consensus Policy Implementation Framework. This document is not meant to substitute for the Framework, but provide a predictable way to resolve issues. -- The CPIF was established by GDD at the same time as we were revising the rules about the intersection of policy and implementation. We are talking about how to deal with issues that come up during implementation. What this does is accompany that document and say if this kind of process change is happening this is what needs to happen. How can we do this within the CPIF and within GNSO consensus policy approved by the Board. -- On the GDD Framework that was one of the most collaborative effort between ICANN and the community. -- Don't know how we can get predictability unless we can hold the GNSO and its WGs to schedules. -- For this topic we think about things that came up where we wondered how to resolve the situation (such as digital archery). There may be issues like that that arise for which we need to have a framework in place to resolve the issues without too much delay. -- From ICANN's perspective we are looking at two phases: 1) policy and implementation phase following the PDP with the IRT and the CPIF; 2) issues that came up when the program is in operation -- an operational phase. It would be great to have guidance and a framework for the issues that arise in the operational phase. This is predominantly for the operational phase. Does not replace the existing framework. -- The point is to have processes that can resolve issues in the operational phase. Where does this takes us to the possiblity of a faster process, but is it a result of multi-stakeholder participation? -- There is nothing inconsistent in this proposal with the existing framework. -- Challenge from the last round: If the policy was silent is it an implementation issue or do we have to go back to the GNSO? -- There is a difference between implementation of the policy and implementation of the program. Issues of intellectual property rights, for example -- very different than digital archery didn't work so we need a new solution to queue applications, or name collisions. Things that had nothing to do with policy but for which we needed a predicable framework. -- Implementation is different from policy. -- Suggest that people read this and also the discussion on the role of the implementation review team. Anyone who has thoughts should comment on the document and to suggest changes and edits. >From the chat: Paul McGrady: I guess I don't understand what the issue is? This document, whether or not drafted by Staff, seems to flow directly from GNSO Principle A on new gTLDs. "New generic top-level domains (gTLDs) must be introduced in an orderly, timely and predictable way." Plus, we are being given a chance to review it (on this call). Steve Chan: There is a footnote in the document to the existing framework that ICANN uses now to implement Consensus Policies: https://www.icann.org/policy/implementation Kurt Pritz: Following Paul's comment, the current policy is: "All applicants for a new gTLD registry should therefore be evaluated against transparent and predictable criteria, fully available to the applicants prior to the initiation of the process. Normally, therefore, no subsequent additional selection criteria should be used in the selection process." What edits are we proposing? Jeff Neuman: Take an example.......How to process applications for purposes of queueing.......In 2012, it was Digital Archery......well, we found out that implementation of that was flawed. It took MONTHS to figure out a new queuing mechanism. Hopefully having this framework will result in having a MUCH smaller delay if something like that comes up again Jeff Neuman: (Ignore the example), but focus on the principle Anne Aikman-Scalese (IPC): @Paul - issues arising during implementation was the whole point of Policy and Implementation Working Group work where participants from all stakeholders was open. Who exactly is working on the revisions to the Framework? Kavouss Arasteh: Predictability is a complex process which depends on many factors on which we may not have all inputs Steve Chan: Thanks Trang, I had raised by head to try and draw that distinction. Kavouss Arasteh: We need to separate the policy development and its implementation Jeff Neuman: "Implementation of Policy" is different than implementation of the program Kurt Pritz: @ Jeff - Can you explain? Kavouss Arasteh: Policy and implementation are two different things Kavouss Arasteh: How we could implement the policy? Anne Aikman-Scalese (IPC): COMMENT: Jeff, I see your point but you may recall there was huge disagreement in 2012 over what was policy and what was implementation. Similarly we could easily have folks disagreeing in the next round as to whether something is implementation of policy or operational implementation. You go back down the same hole. Anne Aikman-Scalese (IPC): COMMENT: Reminder that the whole issue in 2012 was that ICANN CEO and staff considered items implementation whereas GNSO considered them policy. You actually authored the letter to the Board telling them they had to come back to the GNSO. So why would your new category of "operational implementation" be any different? 4. Next Meeting: -- Next call is in three weeks: 29 August at 0300 UTC. Work Tracks are still meeting. Google Doc calendar is available at: https://docs.google.com/spreadsheets/d/1O_NpWTXFMNHkJARveqCapEssRt1CaEqwWe8… -- As soon as Work Track 5 meetings are established we will send a note to the list.

1 0

Proposed Agenda: New gTLD Subsequent Procedures Working Group, 7 August 2017 at 20:00 UTC
by Steve Chan 04 Aug '17

04 Aug '17

Dear WG Members, Below, please find the proposed agenda for the New gTLD Subsequent Procedures WG meeting scheduled for Monday, 7 August 2017 at 20:00 UTC. Please note, this call is scheduled for 90 minutes. Welcome/SOIs Work Track Updates Update on Work Track 5 (geographic names at the top-level) Drafting Team Discussion – Applications Assessed in Rounds (https://docs.google.com/document/d/1u3UzvZIXzjnxtklgPmqArqff6dyckUbyuzWyLz7…) Drafting Team Discussion – Predictability Framework (https://docs.google.com/document/d/1lzXxBLMtFr03BKnHsa-Ss7kR7EAJt7pCI1EP3H8…) AOB Best, Steve Steven Chan  Policy Director, GNSO Support ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536  steve.chan(a)icann.org mobile: +1.310.339.4410 office tel: +1.310.301.5800 office fax: +1.310.823.8649 Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages. Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO Follow the GNSO on Facebook: https://www.facebook.com/icanngnso/ http://gnso.icann.org/en/

1 0

Working Group Newsletter - August 2017
by Emily Barabas 04 Aug '17

04 Aug '17

Dear Working Group members, The August edition of the New gTLD Subsequent Procedures PDP Working Group newsletter is now available: https://gnso.icann.org/en/news/working-group-newsletters/newsletter-new-gtl…. Please feel free to share this newsletter with individuals and groups who may be interested in the Working Group’s activities. An archive of previous editions of the newsletter is available on the WG wiki<https://community.icann.org/pages/viewpage.action?pageId=58001970> and on the GNSO website<https://gnso.icann.org/en/news/working-group-newsletters>. Kind regards, Emily Emily Barabas | Policy Specialist ICANN | Internet Corporation for Assigned Names and Numbers Email: emily.barabas(a)icann.org | Phone: +31 (0)6 84507976

1 0

Re: [Gnso-newgtld-wg] Fwd: Letter from the RySG's RSP Discussion Group
by Vanda Scartezini 02 Aug '17

02 Aug '17

Thank you jeff. Some groups from this discussion group will certainly be aligned with for instance, our track 1. May be the best way to go forward with this alignment is to have “liaisons” working in both groups to guarantee real exchange of ideas and avoid duplication of effort. Best to all Vanda Scartezini Polo Consultores Associados Av. Paulista 1159, cj 1004 01311-200- Sao Paulo, SP, Brazil Land Line: +55 11 3266.6253 Mobile: + 55 11 98181.1464 Sorry for any typos. From: <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> on behalf of Jeff Neuman <jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com>> Date: Tuesday, July 18, 2017 at 08:56 To: "gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>" <gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>> Subject: [Gnso-newgtld-wg] Fwd: Letter from the RySG's RSP Discussion Group Forwarding this on to the entire New gTLD Working Group as an FYI. This most likely affects both Work Tracks 1 and 2, but I thought everyone should see it. Best regards, Jeffrey J. Neuman Senior Vice President Com Laude USA / Valideus USA 1751 Pinnacle Dr., Suite 600 McLean, VA 22102 Jeff.Neuman(a)comlaude.com<mailto:Jeff.Neuman@comlaude.com> +1 (202) 549-5079 Begin forwarded message: From: "svg(a)milathan.ltd<mailto:svg@milathan.ltd>" <svg(a)milathan.ltd<mailto:svg@milathan.ltd>> Date: July 18, 2017 at 6:21:48 AM EDT To: Jeff Neuman <jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com>>, Avri Doria <avri(a)acm.org<mailto:avri@acm.org>> Cc: "rsp-program-discussion(a)googlegroups.com<mailto:rsp-program-discussion@googlegroups.com>" <rsp-program-discussion(a)googlegroups.com<mailto:rsp-program-discussion@googlegroups.com>>, Graeme Bunton <gbunton(a)tucows.com<mailto:gbunton@tucows.com>> Subject: Letter from the RySG's RSP Discussion Group Avril, Jeff, Please find attached a correspondance from the Registry Service Provider’s Discussion Group. Graeme, please share this letter with the registrars as you see fit. Best, Stéphane Van Gelder Chairman and Managing Director Milathan LTD "Internet Intelligence - Strategic Advice" ———————— Discover The Milathan Post on http://post.milathan.com<http://post.milathan.com/> Follow me on Twitter: @stephvg ————————

8 7