January 2017 - Gnso-newgtld-wg-wt1

recording, Attendance & AC Chat for New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue
by Terri Agnew Jan. 31, 2017

Jan. 31, 2017

Dear All, Please find the attendance and recording of the call attached to this email and the AC Chat below for the New gTLD Subsequent Procedures Sub Team - Track 1 - Overall Process/Support/Outreach Issue held on Tuesday, 31 January 2017 at 20:00 UTC. <https://urldefense.proofpoint.com/v2/url?u=http-3A__audio.icann.org_gnso_gn so-2Dnew-2Dgtld-2Dsubsequent-2D16may16-2Den.mp3&d=DQMF-g&c=FmY1u3PJp6wrcrwll 3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=_ fjAZ8X8f1kW0l0GMcnTYAJub8JIzI-nbGkDB_FNy0s&s=Xc2HCgoInyY4sazVMVxejDycY3Vw2SB D9TFBrxEGM60&e=> The recordings of the calls are posted on the GNSO Master Calendar page: <http://gnso.icann.org/en/group-activities/calendar> http://gnso.icann.org/en/group-activities/calendar ** Please let me know if your name has been left off the list ** Mailing list archives: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1> http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1 Wiki page: <https://community.icann.org/x/SbPDAw> https://community.icann.org/x/SbPDAw Thank you. Kind regards, Terri ------------------------------- Adobe Connect chat transcript for 31 January 2017 Terri Agnew:Welcome to the New gTLD Subsequent Procedures Sub Team - Track 1 - Overall Process/Support/Outreach Issue call on Tuesday, 31 January 2017 at 20:00 UTC. Terri Agnew:wiki agenda page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_S bPDAw <https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_ SbPDAw&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpC IgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=c_pDZyAeBhAPJgAZAcBoWpAtMU0PNiGObWx1b7l87H 8&s=j94kSGThskTNFTXyuO5LUAHU3fHhQRd36JDgoUykQBs&e> &d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXh FzL7ar9Qfqa0AIgn-H4xR2EBk&m=c_pDZyAeBhAPJgAZAcBoWpAtMU0PNiGObWx1b7l87H8&s=j9 4kSGThskTNFTXyuO5LUAHU3fHhQRd36JDgoUykQBs&e= Emily Barabas:at the moment everyone can scroll for themselves Emily Barabas:but we can control the slides if you prefer Jeff Neuman:@Steve - We will come up with something to call it other than "lottery" Jeff Neuman:We can call it "Randomization Process" for now Steve Chan:Thanks. I have an open request to ICANN legal for input on the viability of the prioritization draw, or similar, in the future. Donna Austin, Neustar:Hi All, sorry for the delay in joining. Kurt Pritz:ICANN called it a "raffle" for important reasons. I thin we should adopt that wording if we are indicating that we want to recommend the same process Sara Bockey:Thank you, Kurt. We will note that. Jeff Neuman:it is a good question to ask the community, but it would be helpful for this group to discuss as well Julie Hedlund:@Jeff has his hand up. Donna Austin, Neustar:Agree with Jeff, that there is a distinction in communication between the first v subsequent window application/ Jim Prendergast:yes - agreed Jon Nevett:No weight? Jim Prendergast:When does cost recovery from previous round stop and cost recovery for this next procedure/round start? Phil Buckingham:+1 Donna , so we have two application fee elements ? a fixed price + variable cost plus ? Jeff Neuman:Correct, I dont think what groups paid in the first round should have any weight Jeff Neuman:It didnt have any weight in the 2005 round or the 2012 round Jon Nevett:cause it went up Donna Austin, Neustar:I think the same applies with regard to what financial information is required, ie. if there is no requirement for a COI. Jeff Neuman:Technically the first TLDs paid nothing.......but the 2000 round did not argue for parity Jim Prendergast:I think we need to ask ICANN why they insisted on evaluating RSP over and over and see if those reasons still stand. We can make all the arguments we want but if ICANN legal says that we did it for liablity prevention reasons, I don tthink our outcome whill change that Jeff Neuman:@Jim - if you read the implementation plan, they did not indicate that they did that for any liability reasons Jon Nevett:Agree with Donna that the $185K should have some weight Jeff Neuman:In fact, I believe their input was the opposite..... Jeff Neuman:sorry I meant the ICANN Implementation review Kurt Pritz:One way to think about it: if the cost is $20K, do we agree with cost recovery; if the cost is $50K do we agree with cost recovery; if the cost is $100K do we agree with cost recovery? Jon Nevett:needs more explanation Jeff Neuman:you may need to repeat Donna Austin, Neustar:What invoicing are we reffering to? Jim Prendergast:application fee invoicing Jon Nevett:invoicing the $185K? Jeff Neuman:I think all we are saying is that we agree that there should be an invoicing process when applying for TLDs Donna Austin, Neustar:Wasn't there an initial $5k fee to sign up and then the remainder was due on completion? Jeff Neuman:As opposed to having to get in the money a few weeks before or whatever the process was Jeff Neuman:Many big companies have rules that they can only pay after receiving a valid invoice Steve Chan:Or make it available on request? I recall, maybe incorrectly, someone saying that having an invoice is actually problematic? Yasmin Omer - Amazon Registry Services:Applicants that needed a statement/invoice (generally larger companies and governments) had to request such from ICANN for the 185k and ICANN eventually provided something Jim Prendergast:Xavier has a few years to figure that out Jon Nevett:ahh -- ok -- seems like an implementation issue not a policy one Yasmin Omer - Amazon Registry Services:perhaps refer to what ICANN provided last time and make it available upon request Donna Austin, Neustar:Agree Jon Trang Nguyen:@Jon, agree. We can figure that out in implementation. Yasmin Omer - Amazon Registry Services:correct Jon, this is very much an implementation issue Emily Barabas:staff is prepared to do a topic summary if you would like Emily Barabas:yes Phil Buckingham:Exactly Jim . Jeff Neuman:all of these topics were referred to us by the GNSO whether considered policy or implementation. IF we want to provide guidance, we should.....if not, that is fine too Jeff Neuman:The systems issue is not really policy either, but more implementation...but it is part of the subsequent procedures Jon Nevett:if get into that level of detail on every issue, 2020 will be optimistic Jeff Neuman:I am not sure we are getting too deep. We are just recommending that an invoicing process be made available. Jon Nevett:Systems should be safe and secure -- avoiding glitches and data breaches that we have had in the past Jeff Neuman:For systems, we may recommend better usability........ability to copy applications....ability to do non-ASCII Jon Nevett:ok and better user experience Emily Barabas:https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_e n_system_files_files_program-2Dreview-2D29jan16-2Den.pdf&d=DwIFaQ&c=FmY1u3PJ p6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4x R2EBk&m=c_pDZyAeBhAPJgAZAcBoWpAtMU0PNiGObWx1b7l87H8&s=BOI2FGTt9aGdRTuJJNsOhL CxZCcRW_s7eeBpgHVbciA&e= Jeff Neuman:Perhaps for the next call, we can summarize the ICANN staff recommendations...and if they make sense, just sign off on them Donna Austin, Neustar 2:The recommendations on this should be high level and not in the weeds. Emily Barabas:@jeff, staff can do this Phil Buckingham:we require changes to the CZDS . For starters - not to have toreapply every 90 days to every single Registry ! Jeff Neuman:@Phil...I am not sure that CZDS falls within our mandate Jeff Neuman:The requirement to provide a zone file as a requirement would be, but not sure that that system is for us Emily Barabas:https://urldefense.proofpoint.com/v2/url?u=http-3A__newgtlds.icann.o rg_en_about_historical-2D&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4 I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=c_pDZyAeBhAPJgAZAcBoWpA tMU0PNiGObWx1b7l87H8&s=kg_hwuKqbmoU3yiS69d62rxctgGzbDEnsWtEVayZlqQ&e= documentation/matrix-plans Emily Barabas:The program implementation review document discusses Communications on pg 189 Emily Barabas:https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_e n_system_files_files_program-2Dreview-2D29jan16-2Den.pdf&d=DwIFaQ&c=FmY1u3PJ p6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4x R2EBk&m=c_pDZyAeBhAPJgAZAcBoWpAtMU0PNiGObWx1b7l87H8&s=BOI2FGTt9aGdRTuJJNsOhL CxZCcRW_s7eeBpgHVbciA&e= Jeff Neuman:Agree with Donna on communications after applications were submitted. But someone needs to go through the application knowledge database and clean that up. Emily Barabas:staff can provide a summary of these recommendations as well on the next call Christa Taylor:Perhaps we can pull some metrics out of there Jeff Neuman:Because communications during the application phase was not the greatest Phil Buckingham:@ jeff , I agree CZDS is outside our mandate , but Registry reporting of their zone file data is ? Terri Agnew:New gTLD Subsequent Procedures Sub Team - Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, 14 February 2017 at 3:00 UTC. Cheryl Langdon-Orr (CLO):bye for now then Donna Austin, Neustar 2:Thanks Sara and Christa Trang Nguyen:Thank you! Bye!

1 0

Actions/Discussion Notes: Work Track 1 Sub Team Meeting 31 January
by Julie Hedlund Jan. 31, 2017

Jan. 31, 2017

Dear Sub Team Members, Please see below the action items and discussion notes captured by staff from the meeting on 31 January. These high-level notes are designed to help Work Track Sub Team members navigate through the content of the call and are not a substitute for the recording. Please also see the recording on the meetings page at: https://community.icann.org/display/NGSPP/Work+Track+1+Meetings. Please note also that the slides referenced below are attached and for ease of reference chat excerpts are included below. Best, Julie Julie Hedlund, Policy Director Notes and Action Items 31 January 1. Recap of outcomes from Jan 10th call a. Application Queuing (slide 4) -- "Lottery" was the way to go. -- In the last round in 2012 there was a decision by the Board to prioritize IDN applications (randomized them first). Then randomized the non-IDN application. If you wanted to enter the randomization process you paid a fee. Then randomized those that didn't want to be in the "lottery". Should talk about whether there should be some priority on IDNs this time or not. -- Question: IDNs were prioritized to facilitate their entrance in the market -- correct? Yes. There was a political desire to have IDNs introduced in the market first. -- CC2 draft question -- whether or not certain application types should be moved to the front of the queue. -- What might help that we do have information that could be useful as to whether putting IDNs first was worthwhile -- gather some data on whether those applications who received prioritizatioin took advantage of that. -- No feedback/objections on the "lottery" ("raffle") approach. -- No insight/feedback on further discussion questions. Will recirculate. >From the Chat: Jeff Neuman: We can call it "Randomization Process" for now. Kurt Pritz: ICANN called it a "raffle" for important reasons. I think we should adopt that wording if we are indicating that we want to recommend the same process. b. Application Submission Period (slide 5) -- We should talk about the communication period for the first application window as opposed to subsequent communication periods. Would assume that would be longer and for subsequent ones if there is some sort of regular process (from the drafting team on overarching issues) -- such as 2 windows a year -- that may overlap with other things going on. Push that off until we get some work product from the drafting team. -- Also ties into a couple of other topics. >From the Chat: Donna Austin, Neustar: Agree with Jeff, that there is a distinction in communication between the first v subsequent window application/ Jim Prendergast: yes - agreed c. Application Fees/Variable Fees (Slides 6 and 7) -- As we move these processes we probably need to have a few fundamental conversations, such as around categories. Where we end up might influence this conversation and in the legal/regulatory track. -- Not sure agree that there will be differences in time and effort for different applications, but can't know that without doing the research. What you need to factor in is what you are applying for is unique and has cost associations. -- Not sure that we should give any weight to the fact that applicants in the last round paid $185k. Decide on the core methodology -- cost recovery or cost recovery+. -- We could get agreement from the group that a registry backend provider would only get evaluated once, which could eliminate the technical evaluation from every other application. -- Efficiencies could be gained in a bunch of the processes. >From the chat: Jim Prendergast: When does cost recovery from previous round stop and cost recovery for this next procedure/round start? Phil Buckingham: +1 Donna , so we have two application fee elements ? a fixed price + variable cost plus ? Jon Nevett: No weight? Jeff Neuman: Correct, I dont think what groups paid in the first round should have any weight. It didnt have any weight in the 2005 round or the 2012 round. Jon Nevett: cause it went up. Donna Austin, Neustar: I think the same applies with regard to what financial information is required, ie. if there is no requirement for a COI. Jeff Neuman: Technically the first TLDs paid nothing.......but the 2000 round did not argue for parity Jim Prendergast: I think we need to ask ICANN why they insisted on evaluating RSP over and over and see if those reasons still stand. We can make all the arguments we want but if ICANN legal says that we did it for liablity prevention reasons, I don think our outcome whill change that. Jeff Neuman: @Jim - if you read the implementation plan, they did not indicate that they did that for any liability reasons. Jon Nevett: Agree with Donna that the $185K should have some weight. Jeff Neuman: In fact, I believe their input was the opposite...sorry I meant the ICANN Implementation review. Kurt Pritz: One way to think about it: if the cost is $20K, do we agree with cost recovery; if the cost is $50K do we agree with cost recovery; if the cost is $100K do we agree with cost recovery? d. Invoice Challenges (Slide 7): -- Do we agree that there should be an invoicing system? -- ICANN had challenges on the ability to invoice, which caused some issues for some applicants. >From the chat: Jeff Neuman: I think all we are saying is that we agree that there should be an invoicing process when applying for TLDs. As opposed to having to get in the money a few weeks before or whatever the process was. Many big companies have rules that they can only pay after receiving a valid invoice. Steve Chan: Or make it available on request? I recall, maybe incorrectly, someone saying that having an invoice is actually problematic? Yasmin Omer - Amazon Registry Services: Applicants that needed a statement/invoice (generally larger companies and governments) had to request such from ICANN for the 185k and ICANN eventually provided something. 2. Systems (Slide 9) Our task: WG may want to consider providing implementation guidance, such as a minimum set of security and infrastructure standards, for consideration by ICANN during implementation of subsequent procedures (https://community.icann.org/display/NGSPP/4.2.9+Systems?preview=/58735915/5… ). -- Context (from the Issue Report): No guidance in the 2007 final report, so this is a new topic. We are talking about applicant-facing systems: (from slide 9) TLD application System (TAS), Customer Portal, additional support solutions -- Digital Archery, Centralized Zone Data Service, Application Comments Forum. See: https://www.icann.org/en/system/files/files/program-review-29jan16-en.pdf. -- Take into consideration that we have moved on quite a bit from this. The best we can do is some high-level recommendations that go to a better user experience. -- If we get the summary from staff and agree that would be a good thing. -- We need to balance that with the needs of those that have to evaluate the applications at the end of the day. >From the chat: Jeff Neuman: all of these topics were referred to us by the GNSO whether considered policy or implementation. IF we want to provide guidance, we should.....if not, that is fine too. The systems issue is not really policy either, but more implementation...but it is part of the subsequent procedures Jon Nevett: if get into that level of detail on every issue, 2020 will be optimistic Jeff Neuman: I am not sure we are getting too deep. We are just recommending that an invoicing process be made available. Jon Nevett: Systems should be safe and secure -- avoiding glitches and data breaches that we have had in the past. Jeff Neuman: For systems, we may recommend better usability........ability to copy applications....ability to do non-ASCII. Jon Nevett: ok and better user experience. Jeff Neuman: Perhaps for the next call, we can summarize the ICANN staff recommendations...and if they make sense, just sign off on them Donna Austin, Neustar 2: The recommendations on this should be high level and not in the weeds. Phil Buckingham: we require changes to the CZDS . For starters - not to have to reapply every 90 days to every single Registry ! Jeff Neuman: @Phil...I am not sure that CZDS falls within our mandate. The requirement to provide a zone file as a requirement would be, but not sure that that system is for us. Phil Buckingham: @ jeff , I agree CZDS is outside our mandate , but Registry reporting of their zone file data is ? 3. Communications (Slide 10) Our task: Consider suggesting targeted groups or sectors, communication methods, as well as metrics to help identify if the communications plan was effective. A PDP-WG may also want to consider what themes should be conveyed and to what parties, as it may be beneficial to customize messaging based on the needs of the particular demeographic…consider providing implementation guidance related to communication methods, goals for communications, success criteria and other elements. (https://community.icann.org/display/NGSPP/4.2.11+Communications?preview=/58…) 2011 Communications Plan: See: http://newgtlds.icann.org/en/about/historical- documentation/matrix-plans. The program implementation review document discusses Communications on pg 189. https://www.icann.org/en/system/files/files/program-review-29jan16-en.pdf -- Concerns: Whether communications were enough, adequate, and timely. Lack of outreach to developing countries. -- Could provide guidance on methods, goals, measuring success, groups to target, etc. -- Touched on having a database that is easily searchable. Could be part of the applications process discussion. -- This another area where things improved over time. Things are now running a lot smoother. Registry Stakeholder Group had a running dialogue with the GDD. -- Staff can provide a summary of recommendations on the next call. -- Agree that after applications were submitted they improved communications. ICANN posted advisories but not everyone knew to look for them. Look at a better mechanism, such as a subscription. >From the Chat: Jeff Neuman: Agree with Donna on communications after applications were submitted. But someone needs to go through the application knowledge database and clean that up. 4. Accreditation (Slide 11) -- Call for volunteers from ICANN. Not sure there will be a group. Trying to find out if there is a group and what we should take on. Will give an update on the next call.

1 0

Agenda - Work Track 1
by Sara Bockey Jan. 30, 2017

Jan. 30, 2017

Dear All, The call for the New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, 31 January 2017 at 20:00 UTC. The proposed agenda is as follows: 1. Welcome 2. SOIs 3. Recap of outcomes from Jan 10th call * Application Queuing * Application Submission Period * Application Fees/Variable Fees 4. Systems * Our task: WG may want to consider providing implementation guidance, such as a minimum set of security and infrastructure standards, for consideration by ICANN during implementation of subsequent procedures (https://community.icann.org/display/NGSPP/4.2.9+Systems?preview=/58735915/5… ) 1. Communications * Our task: Consider suggesting targeted groups or sectors, communication methods, as well as metrics to help identify if the communications plan was effective. A PDP-WG may also want to consider what themes should be conveyed and to what parties, as it may be beneficial to customize messaging based on the needs of the particular demeographic…consider providing implementation guidance related to communication methods, goals for communications, success criteria and other elements. (https://community.icann.org/display/NGSPP/4.2.11+Communications?preview=/58… ) 1. Accreditation Program 2. AOB Attached for your convenience are excerpts from the final report on Systems and Communications, which further outline the question(s) we are to address. Please review this material prior to the call to assist in topical, focused discussions. Thanks, sara bockey policy manager | GoDaddy™ sbockey(a)godaddy.com 480-366-3616 skype: sbockey This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.

1 0

WT1 Jan 10th Call Outcomes, Follow-Ups, Further Discussion and Future Topics
by Christa Taylor Jan. 30, 2017

Jan. 30, 2017

Thank-you to all who joining the WT1 call this morning (January 10th). As mentioned, we will be utilizing more email lists to solicit feedback and making progress to meet deadlines. Application Queuing Outcomes: * First come, first served was discussed and the lottery system which was the method used in round one was thought to be most relevant. * Vote on whether to keep the current lottery system: yes/no -- lottery system 10 approvals and no objections. This is based on the assumption that rounds will be used and are similar to the first round, a prioritization based on the type of application such as IDNs can be used. * We seem to have consensus but please send an email to the chairs, co-chairs and working group along with an explanation why the decision is believed to be in error in time for the next meeting. Next meeting, we will review the above along with any comments received to ensure we have full consensus. Follow-ups: * Need to confirm ICANN can/will continue to use the lottery license/system in future rounds Further discussion: * If rounds are not going to be used, then what method should be used? * If it's a continuous application period - how will we deal with application queuing? First come first served? What is appropriate? Application Submission Period Outcomes: * For approval: Initial period is three months, subsequent period is two months -- 7 approvals and no objections. This is based on the window to submit applications based on the pretense that there is sufficient length of time between communicating when the window will open and the submission period beginning. The length of this initial communication to application submission can vary depending on the circumstances. * We seem to have consensus but please send an email to the chairs, co-chairs and working group along with an explanation why the decision is believed to be in error in time for the next meeting. Next meeting, we will review the above along with any comments received to ensure we have full consensus. * Based on the next application periods based on rounds (see further discussion below). Follow-ups: * Need to draft the language re: above as there is currently no guidance for the length of time. Further discussion: * Does the application submission period of 3 months and 2 months have any implications on applicant support? * If we have a few next 'rounds' followed by continuous application periods, how should the application submission period be handled? Application Fees Outcomes: * n/a Follow-ups: Alternatives to cost recovery keeping in mind that any alternatives other than cost recovery could impact ICANN's Not-For-Profit (NFP) status. However, profits from fees could be used exclusively for promoting its stated goals. However, activities that a NFP should not be engaging in include: goods and services are not restricted to members and their guests and operation on a profit basis rather than a cost-recovery basis. Further discussion: * Existing policy is based on cost recovery. * Impact to variable fees based on application types (topic for next meeting) * Should we implement cost floors/ceilings? Seems like we might be more concerned about a floor. What are the implications if we choose a methodology other than cost recovery? * Current overages from the first round have no policy Variable Fees Outcomes: * One Fee Fits All approach Follow-ups: * Applicant support fees discount Further discussion: * The $90m first round overages have no policy on how the money will be used which is outside the scope of our discussion however, we should be mindful of this in future rounds i.e. how accepting will applicants be of fees that exceed costs and the policy or other items that should be included in the variable fees to deal with such overages? Next Call Preparation: * Further discussion items from today's call (see above) * Systems: "may want to consider providing implementation guidance, such as a minimum set of security and infrastructure standards, for consideration by ICANN during implementation of subsequent procedures" (https://community.icann.org/display/NGSPP/4.2.9+Systems?preview=/58735915/5 8737114/Section%204.2.9.pdf ) * Communications: "consider suggesting targeted groups or sectors, communication methods, as well as metrics to help identify if the communications plan was effective. A PDP-WG may also want to consider what themes should be conveyed and to what parties, as it may be beneficial to customize messaging based on the needs of the particular demeographic.consider providing implementation guidance related to communication methods, goals for communications, success criteria and other elements" (https://community.icann.org/display/NGSPP/4.2.11+Communications?preview=/58 735919/58737118/Section%204.2.11.pdf ) * Accreditation based on carve out on new working group and this WT CCT2 Questions * Application Fees: Given that fees are to be for cost recovery, and given the surplus from the last round, do you believe cost recovery based on the existing cost structure is still appropriate? With cost recovery in mind, should there be a floor/ceiling threshold? * Variable Fees: Should the New gTLD application fee be variable based on such factors as application type (e.g., open or closed registries), multiple identical applications, or other factors? * Application Submission Period: Is three months the proper amount of time? Is the concept of a fixed period of time for accepting applications the right approach? We welcome all input from the working group to expand this list of question Christa Taylor, B. Tech, CPA, CMA, MBA Mobile: 604-961-9460 Skype: christat13 <mailto:christa@dottba.com> christa(a)dottba.com <http://www.dottba.com/> www.dottba.com

2 1

Actions/Discussion Notes: Work Track 1 Sub Team Meeting 10 January
by Julie Hedlund Jan. 10, 2017

Jan. 10, 2017

Dear Sub Team Members, Please see below the action items and discussion notes captured by staff from the meeting on 10 January. These high-level notes are designed to help Work Track Sub Team members navigate through the content of the call and are not a substitute for the recording. Please also see the recording on the meetings page at: https://community.icann.org/display/NGSPP/Work+Track+1+Meetings. Please note also that the slides referenced below are attached and for ease of reference chat excerpts are included below. Best, Julie Julie Hedlund, Policy Director Notes and Action Items 10 January 1. Work Track Progress Status [reading from slide 3] -- Good progress on all of the topics -- Adjusting the work plan a bit -- Focus to see if we can close a few topics -- Accreditation -- had hoped to close by mid-December but still discussing -- Still on track for applicant support -- Need more discussion on clarity of application process, application fees, and variable fees -- application queuing and submission period will fall under clarity of application process 2. Clarity of application process [reading from slide 4] Accreditation -- new working group and carving out policies for WT1 to focus on for the next meeting Clarify of application process [reading from slide 5] -- Any additions to what is on the slide? -- Will put forward what we have to the list for consideration Application Queuing [reading from slide 6] -- Need feedback on whether we still believe that first come, first served is relevant, or if another mechanism is more appropriate -- If it is a round is first come, first served relevant? Could be some other method after that. -- This just the order that the application is reviewed. -- Not sure how this would play out in an application period. Two options -- wait for the last one in the contention set or everyone gets the benefit of the first one selected -- all applications for the same TLD would be evaluated. -- To be clear we are talking about the substantive processing, which could potentially go all the way through to delegation. Processing on contention sets has to be done on all of the applications. -- First what would happen is ICANN woudl time stamp the applications as received, wait until the end of the period, determine the contention sets, they would do the review application 1, 2, etc. Use the priority numbers to release the intial results, but that wouldn't be processing everything, just the priority number for initial processing. -- The question we are trying to address is whether first come, first served is still relevant. -- First come, first served: Yes/No; lottery system: yes/no -- lottery system 9 approvals and no objections. -- Went away from first come, first served to the lottery. We are seeing a preference for a lottery and not seeing why we should go back to first come, first served. -- Could hold multiple lotteries within categories (as with IDNs). -- Should not use the term "lottery". Cannot get a license for that process. Action Items: 1. Put forward lottery system to the list. 2. Ask staff what they would need to do to keep their lottery license to continue to do lotteries >From the chat: Rubens Kuhl: As long as we are doing rounds, it is not relevant. Rubens Kuhl: Changes are required at least to reflect what has already been done. Alexander Schubert: 1stcome1stserve would only benefit the portfolio guys with their unlimited rescources! Alexander Schubert: In a gTLD round! Jeff Neuman: So, is everyone comfortable with the randomization/lottery that ICANN held Steve Chan: The current guidance should be viewed in contrast with the prioritization. Jeff Neuman: (assuming ICANN can maintain the license to run lotteries)? Michael Flemming: Firstly in rounds, then yes as long as we have objections of course :) Jeff Neuman: If we do rounds, I would not be comfortable with first come first served. I think the lottery was the only fair way to go. Michael Flemming: once again are we talking about rounds? Jeff Neuman: I think a question needs to go to staff (legal) to see whether they can maintain their license to run the lottery Alexander Schubert: +1 Jeff - two scenarios: Round and ongoing application period Michael Flemming: secondly, if a long term period, then first come first serve as long as we have objections of course :) Ashley Roberts: Agree some kind of randomised assignment of priority numbers is preferable to FCFS Laura Watkins (Nominet): +1 Ashley Alexander Schubert: How about prioritizing GEo's - as they are usually clear cut cases with no contention (as they usually require the OK of the Government) Rubens Kuhl: FCFS is an invitation to dropcatch-like practices where people will bomb the application system to hell so their TLDs go first in application processing. Michael Flemming: I'm with Jeff Trang Nguyen: In the current round, the priority numbers were used to release IE results. Alexander Schubert: Another idea: Have 10% of slots being prioritized by the Internet Community! So the 10% strings the Internet Users in the world value as potentially most impacting would be awarded the top 10% slots? Negative: Potential gaming. Rubens Kuhl: We can let every applicant point one other string as their main competitor, and the process would honor those requests so the results would be released in the same time. Steve Chan: The priority numbers were also used for contracting, PDT, and transition to delegation, if I'm not mistaken. Jeff Neuman: So again, we need to ask ICANN legal whether they could maintain the license to run the "lotteries" and what they need to do to maintain that license. Rubens Kuhl: But if not in the policy, it should be written that processing would always favor and only be based on process efficiencies. Queueing would be only applied, if applied, to release of results. Alexander Schubert: +1 Rubens: We should NOT honor drop-catchers! Trang Nguyen: Perhaps one question that the group could consider is what was the intent behing the GNSO policy recommendation of first come first served, and given objections/string contention, whether the intent could be achieved. Jeff Neuman: @Steve - that was the theory, but not sure how much that was honored given all of the interruptions in the application processing Trang Nguyen: There is a negative aspect to using priority numbers... the ability to normalize priori to releasing IE results. Alexander Schubert: Lottery and some system whereby e.g. GEO applications (with no contention) get prioirity as they serve communities? Michael Flemming: I'd prefer the lottery Laura Watkins (Nominet): Agree Alexander. It makes sense that applications less likely to have contention gets priority Justine Chew: If FCFS caused issues, then keeping the lottery system makes sense 3. Application Submission Period [reading from slide 7] Assuming that the next round is for a fixed period of time, is three months sufficient? -- Suggestion: 3 months is long enough for the first of the application windows as long as there is a long enough communication period prior to the start. Each subsequent window could be shorter, such as 30 or 60 days. -- In writing the Issue Report for this topic we didn't see that there was guidance for the exact length of time for the application period, but guidance of when to start after the request for proposal. This was not a policy issue identified in the Issue Report, but the WT could draft some language if it wishes. -- In considering the example of applicant support in order to apply, would 3 months be relevant in considering those parties? Or do we want to address that in the applicant support area? -- Think it would be in the applicant support area. -- For approval: Initial period is 3 months, subsequent period is 2 months -- 7 approvals. -- Approved assuming we are talking about rounds and a delay before the next round, and in no other areas, such as applicant support. >From the chat: Jeff Neuman: So again my proposal would be a three month submission period for the first application window, but to have a shorter 60 day application window for subsequent application windows Rubens Kuhl: Preparing can be done before application window. If the community needs time, postpone the begining of the application period Rubens Kuhl: Until we know how Applicant Support would play out, it's premature to determine something to support it. Steve Chan: Policy recommendations could potentially be less specific than an actual number of months. Laura Watkins (Nominet): If applications are to be batched anyway should the submission period(s) relate to number of applications received rather tha running for a set time? Justine Chew: I abstain. Not comfortable with questions surrounding the AGB. Jeff Neuman: @Alan - Agree we need to sync with other recommendations 4. Application Fees [reading from slide 8] -- Methodology was cost recovery. -- Are we requiring more substance to understand the methodology? "It may be useful to evaluate how well costing estimates compared to actual costs incurred by ICANN...consider providing implementation guidance to be taken into account when ICAN works with the community to develop the costing methodology for subsequent procedures." -- Need to determine how we address overages. -- Should we implement cost floors/ceilings? Seems like we might be more concerned about a floor. What are the implications if we choose a methodology other than cost recovery? Look at comments on the list. >From the chat: Alexander Schubert: The fees should NOT be lowered in the next round. We are inviting speculators otherwise. A good .com is much more expensive than the gTLD application fee. Rubens Kuhl: If we are arbitrating fees, than it's not cost-recovery. Phil Buckingham: + 1 Alan . should Applicant support applications to go through a separate process channel Alexander Schubert: Actually 500k USD would be more appropriate. Michael Flemming: I disagree. I think costs need to be lowered to a more realistic cost. More substance would help to determine a realistic fee. Jeff Neuman: existing plicy is cost recovery at this point. Phil Buckingham: Should be free . Fund it from auction funds and Round 1 "profit excess ",. Michael Flemming: I think you need to set a cost analysis per TLD category. Rubens Kuhl: Arbitrating fees to market value could put ICANN non-profit status in jeopardy. Trang Nguyen: One thing to note is that we have much more information based on this round than we did when we estimated the cost of the program (from a cost recovery perspective). The learnings from this round can be used to better estimate the actual cost for next round. Alexander Schubert: ICANN could do it at a cost of $US 15k probably - we would have 25,000 applications then...... Michael Flemming: Some TLD types require much less check and the process can. e much more streamlined to be cost effective. Justine Chew: Having a surplus is a good problem to have. For starters can use some of this to fund application support, no? Phil Buckingham: Dont need a legal contingency fund (1/3 ) anymore for a Round 2 ?? Rubens Kuhl: Phil, .africa and .merck are showing that legal contingencies could be needed... and we don't yet if .amazon will turn into another legal battle. Jeff Neuman: I agree with Trang. I also believe that having such a large contingency fund (legal fund) for future rounds would be unnecessary. Rubens Kuhl: Size of the fund can be argued, though. Variable fees: Seemed to be consensus that there should be one fee. Is that still the case or do we want to revisit this? May need to revisit. >From the chat: Laura Watkins (Nominet): Agree fixed fee - except in the situation of applicant support - those fees could effectively be discounted in some way maybe Cheryl Langdon-Orr (CLO): indeed Alan good points Trang Nguyen: There was no difference in application processing costs for applications this round.

1 0

recording, Attendance & AC Chat for New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue
by Terri Agnew Jan. 10, 2017

Jan. 10, 2017

Dear All, Please find the attendance and recording of the call attached to this email and the AC Chat below for the New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue held on Tuesday, 10 January 2017 at 15:00 UTC. <https://urldefense.proofpoint.com/v2/url?u=http-3A__audio.icann.org_gnso_gn…> The recordings of the calls are posted on the GNSO Master Calendar page: http://gnso.icann.org/en/group-activities/calendar ** Please let me know if your name has been left off the list ** Mailing list archives: http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1 Wiki page: https://community.icann.org/x/7AObAw Thank you. Kind regards, Terri ------------------------------- Adobe Connect chat transcript for 10 January 2017 Terri Agnew:Welcome to the the New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue on Tuesday, 10 January 2017 at 15:00 UTC Terri Agnew:agenda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… Alan Greenberg:Number ending in 9001 is me. Terri Agnew:@Alan, I have renamed the line Rubens Kuhl:As long as we are doing rounds, it is not relevant. Rubens Kuhl:Changes are required at least to reflect what has already been done. Alexander Schubert:1stcome1stserve would only benefit the portfolio guys with their unlimited rescources! Alexander Schubert:In a gTLD round! Jeff Neuman:So, is everyone comfortable with the randomization/lottery that ICANN held Steve Chan:The current guidance should be viewed in contrast with the prioritization. Jeff Neuman:(assuming ICANN can maintain the license to run lotteries)? Michael Flemming:once again are we talking about rounds? Rubens Kuhl:Not comfortable with Bingo, Jeff... Michael Flemming:Firstly in rounds, then yes as long as we have objections of course :) Jeff Neuman:If we do rounds, I would not be comfortable with first come first served. I think the lottery was the only fair way to go Jeff Neuman:I think a question needs to go to staff (legal) to see whether they can maintain their license to run the lottery Alexander Schubert:+1 Jeff - two scenarios: Round and ongoing application period Michael Flemming:secondly, if a long term period, then first come first serve as long as we have objections of course :) Rubens Kuhl:ZZzzzZZzzz... ;-) Ashley Roberts:Agree some kind of randomised assignment of priority numbers is preferable to FCFS Laura Watkins (Nominet):+1 Ashley Cheryl Langdon-Orr (CLO):thx Jeff Alexander Schubert:How about prioritizing GEo's - as they are usually clear cut cases with no contention (as they usually require the OK of the Government) Rubens Kuhl:FCFS is an invitation to dropcatch-like practices where people will bomb the application system to hell so their TLDs go first in application processing. Michael Flemming:I'm with Jeff Trang Nguyen:In the current round, the priority numbers were used to release IE results. Alexander Schubert:Another idea: Have 10% of slots being prioritized by the Internet Community! So the 10% strings the Internet Users in the world value as potentially most impacting would be awarded the top 10% slots? Negative: Potential gaming. Rubens Kuhl:We can let every applicant point one other string as their main competitor, and the process would honor those requests so the results would be released in the same time. Steve Chan:The priority numbers were also used for contracting, PDT, and transition to delegation, if I'm not mistaken. Jeff Neuman:So again, we need to ask ICANN legal whether they could maintain the license to run the "lotteries" and what they need to do to maintain that license. Rubens Kuhl:But if not in the policy, it should be written that processing would always favor and only be based on process efficiencies. Queueing would be only applied, if applied, to release of results. Alexander Schubert:+1 Rubens: We should NOT honor drop-catchers! Trang Nguyen:Perhaps one question that the group could consider is what was the intent behing the GNSO policy recommendation of first come first served, and given objections/string contention, whether the intent could be achieved. Jeff Neuman:@Steve - that was the theory, but not sure how much that was honored given all of the interruptions in the application processing Trang Nguyen:There is a negative aspect to using priority numbers... the ability to normalize priori to releasing IE results. Alexander Schubert:Lottery and some system whereby e.g. GEO applications (with no contention) get prioirity as they serve communities? Michael Flemming:I'd prefer the lottery Jeff Neuman:I think for now, we need to just consider the main method for queing before determining whether certain types of applications should get priority in thelottery Cheryl Langdon-Orr (CLO):yes Alan agree Justine Chew:Agree with Alan Rubens Kuhl:We will make Digital Archery Great Again. Alexander Schubert:+1 Alan Laura Watkins (Nominet):Agree Alexander. It makes sense that applications less likely to have contention gets priority Justine Chew:If FCFS caused issues, then keeping the lottery system makes sense Alan Greenberg:I think we should appoint Rubens President! Laura Watkins (Nominet):Eeek! I can't figure out how to vote! Michael Flemming:consensus reached? Rubens Kuhl:Laura, it's the same button to raise hand. Jeff Neuman:9 approvals Alexander Schubert:9 approvals? Laura Watkins (Nominet):Aaah got it - thanks Rubens. done it now Alexander Schubert:Alan disappeared again :-) Jeff Neuman:10 now Terri Agnew:@Laura, top tool bar, select icon that has person with raised hand. Rubens Kuhl:Steve has his hand up. Rubens Kuhl:And Jeff too. Rubens Kuhl:Just an implementation note: bundle the lottery ticket with the application fee so there is need for a separate payment. Christa Taylor:Just like we did with IDNs in the last round Christa Taylor:agreed Alexander Schubert:+1 Jeff Christa Taylor:draw Rubens Kuhl:Bingo Justine Chew:Random picking Christopher Niemi:'priority draw' Jeff Neuman:"Game of chance" Michael Flemming:draw straws Trang Nguyen:@Rubens, I believe a nominal fee must be collected for the priority draw for legal reasons. Alexander Schubert:Well, the application system could assign a random number when you apply - the number is stored (and nobody can see it) - and it is later used to avoid a lottery! Trang Nguyen:We can look into whether that can be collected with teh application fee, or has to be separate. Jeff Neuman:Thanks Trang Rubens Kuhl:@Trang, yes, but it can be bundled. US$85,000 - application fee ; US$85 - draw ticket. Deposit of US$ 85085 to clear both. Phil Buckingham:@ Trang - thats my understanding . Phil Buckingham:I thought i was $100 per lottery ticket Jeff Neuman:I think this is a good question for CC2 Sara Bockey:I agree Jeff Rubens Kuhl:Shorter is better. Longer periods invite events of chance. Justine Chew:Assuming there is enough support to assist applicants in preparing and submitting their applications? Trang Nguyen:@Phil, yes, each draw ticket was $100 USD Michael Flemming:Forgot about the Applicant Guidebook for a minute. Jeff Neuman:So again my proposal would be a three month submission period for the first application window, but to have a shorter 60 day application window for subsequent application windows Rubens Kuhl:Preparing can be done before application window. If the community needs time, postpone the begining of the application period. Michael Flemming:Sorry my question has relevance now. Justine Chew:Yes, hence my question before! Rubens Kuhl:Until we know how Applicant Support would play out, it's premature to determine something to support it. Steve Chan:Policy recommendations could potentially be less specific than an actual number of months. Laura Watkins (Nominet):If applications are to be batched anyway should the submission period(s) relate to number of applications received rather tha running for a set time? Justine Chew:I abstain. Not comfortable with questions surrounding the AGB. Jeff Neuman:@Alan - Agree we need to sync with other recommendations Justine Chew:+1 Alan Alexander Schubert:The fees should NOT be lowered in the next round. We are inviting speculators otherwise. A good .com is much more expensive than the gTLD application fee. Rubens Kuhl:If we are arbitrating fees, than it's not cost-recovery. Phil Buckingham:+ 1 Alan . should Applicant support applications to go through a separate process channel Alexander Schubert:Actually 500k USD would be more appropriate. Michael Flemming:I disagree. I think costs need to be lowered to a more realistic cost. More substance would help to determine a realistic fee. Jeff Neuman:existing plicy is cost recovery at this point. Phil Buckingham:Should be free . Fund it from auction funds and Round 1 "profit excess ",. Michael Flemming:I think you need to set a cost analysis per TLD category. Rubens Kuhl:Arbitrating fees to market value could put ICANN non-profit status in jeopardy. Trang Nguyen:One thing to note is that we have much more information based on this round than we did when we estimated the cost of the program (from a cost recovery perspective). The learnings from this round can be used to better estimate the actual cost for next round. Alexander Schubert:ICANN could do it at a cost of $US 15k probably - we would have 25,000 applications then...... Michael Flemming:Some TLD types require much less check and the process can. e much more streamlined to be cost effective. Justine Chew:Having a surplus is a good problem to have. For starters can use some of this to fund application support, no? Phil Buckingham:Dont need a legal contingency fund (1/3 ) anymore for a Round 2 ?? Alexander Schubert:If it is "free" we have ".xyz"-times :-) Rubens Kuhl:Phil, .africa and .merck are showing that legal contingencies could be needed... and we don't yet if .amazon will turn into another legal battle. Jeff Neuman:I agree with Trang. I also believe that having such a large contingency fund (legal fund) for future rounds would be unnecessary Rubens Kuhl:Size of the fund can be argued, though. Alan Greenberg:I think we should say we will determine the cost only after we know how many appilications there are. That wasy we can predict costs more accurately. And limit applications to only those with near infinite money. Alan Greenberg:(That was a joke) Michael Flemming:haha Rubens Kuhl:Alan, although a joke, it's an alert that some organizations are not that price-sensitive as others. Michael Flemming:I'm surprised no one came up with a Trump joke Phil Buckingham:Rubens - I m just lobbing out the Q - I agree with you actually . ICANN will need all of it going forward Alan Greenberg:@Rubens. Indeed. When you look at profit made by some in the self-auctions, the cost from ICANN was never meant to indicate the VALUE of the TLD. Michael Flemming:I thought this meeting runs for another half hour Julie Hedlund:@Michael: That was an error. The meeting is for 60 minutes. Michael Flemming:Thank you. Michael Flemming:I would like to revisit Rubens Kuhl:I have to drop at the hour anyways... Laura Watkins (Nominet):Agree fixed fee - except in the situation of applicant support - those fees could effectively be discounted in some way maybe Cheryl Langdon-Orr (CLO):indeed Alan good points Trang Nguyen:There was no difference in application processing costs for applications this round. Trang Nguyen:Except for CPE. Cheryl Langdon-Orr (CLO):thx everyone... bye for now... good progress Justine Chew:Thanks, Christa, Sara for leading the discussions on calls and looking forward to the email list discussions. avri doria:bye Alexander Schubert:Bye! Ashley Roberts:thanks Michael Flemming:great meeting Katrin Ohlmer, DOTZON:thanks and bye , everyone. Phil Buckingham:Great job , Christa and Sara

1 0

Agenda - Work Track 1
by Sara Bockey Jan. 9, 2017

Jan. 9, 2017

Dear All, The call for the New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, Jan 10, 2017 at 15:00 UTC. The proposed agenda is as follows: 1. Welcome 2. SOIs 3. Work Track Progress Status 4. Clarity of Application Process 5. Application Submission Period 6. Application Queuing 7. CCT2 questions (if there is time) 8. AOB Attached for your convenience are excerpts from the final report on Application Submission Period and Application Queuing, which outline the question(s) we are to address. As we are currently behind numerous timelines, please review this material prior to the call to assist in topical, focused discussions. Thanks, sara bockey policy manager | GoDaddy™ sbockey(a)godaddy.com 480-366-3616 skype: sbockey This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.

1 0