March 2017 - Gnso-newgtld-wg-wt1

Recording, Attendance & AC Chat from New gTLD Subsequent Procedures Sub Team Track 1 - Overall Process/Support/Outreach Issue call on Tuesday, 28 March 2017
by Terri Agnew March 28, 2017

March 28, 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, 28 March 2017 at 15:00 UTC. Adobe Connect Recording: <https://participate.icann.org/p48f7ic8n8f/?OWASP_CSRFTOKEN=0c7bb89de470d93f 84a162222187b6d01d5528430967df8b53079b097215aeae> https://participate.icann.org/p48f7ic8n8f/ 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> http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1 Agenda wiki page: https://community.icann.org/x/9rDRAw Thank you. Kind regards, Terri ------------------------------- Adobe Connect chat transcript for 28 March 2017 Terri Agnew:New gTLD Subsequent Procedures Sub Team - Track 1 - Overall Process/Support/Outreach Issue call on Tuesday, 28 March 2017 at 15:00 UTC. Terri Agnew:agenda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_9 rDRAw <https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_ 9rDRAw&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpC IgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=i_l-dP0VOvyrnTat__0NItdjqrWNaAEtw0MFMzJraX s&s=wNsJoXLd-bo2PWTZdo31sLs0OOagjbkpxmtbiGTrGgY&e> &d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXh FzL7ar9Qfqa0AIgn-H4xR2EBk&m=i_l-dP0VOvyrnTat__0NItdjqrWNaAEtw0MFMzJraXs&s=wN sJoXLd-bo2PWTZdo31sLs0OOagjbkpxmtbiGTrGgY&e= Sara Bockey:Good day all. I'm working from home today - having some work done on the house. I apologize in advance for background noise or dogs barking. Emily Barabas 2:The slides are unsynced. Everyone can scroll for themselves. Alexander Schubert:Why "cost recovery" in the first place? What if the cost goes down to 5k USD? We face hundreds of thousands of gTLDs? Alexander Schubert:There must be a SUBSTENTIAL hurdle to overcome for applying for a gTLD. The easiest hurdle is a monitary one. If there is no entry barrier we will be FLOODED with applications by "hobby-gTLD-makers". Trang Nguyen:One big development cost for the next round is the system development cost. Steve Chan:I would imagine the development cost would be dependent upon the recommendations from this group. Trang Nguyen:TAS has been retired so we would need to do new system development. Now much work depends on how many changes from the 2012 round there will be. Jeff Neuman:@Steve - of course to some extent. Donna Austin, Neustar:@Alexander, we did have some discussion about the challenges associates with setting a low application fee. Jeff Neuman:But to be honest some of that "development cost" was not wisely spent....especially in trying to develop a home grown customized one time solution Steve Chan:@Alexander, there is a question related to a pricing floor in CC2 Alexander Schubert:TNX Jeff Neuman:I would really like for us to set forth all of the reasons for which we believe that a floor should be set (as that would be a change in policy) Alexander Schubert:There is also a "cost" to "society", brands, the Intellectual Property community! If 100,000 gTLDs are being applied for because they "cost" only 10k USD - then the "cost" to the wider community is BIG! Donna Austin, Neustar:@Greg, agree about getting the reserves back up, but ICANN shouldn't be using excess fees from a future round to do that. I know that's not what you were suggesting, but I just wanted to put that on the record. Greg Shatan:Donna, I wouldn't consider those to be "excess fees." It's simply revenue. And I don't see why revenue should not be used to bolster reserves. Greg Shatan:On this point, since the first round fees were so significant, a floor was irrelevant. Greg Shatan:How far short is ICANN's reserves from best practices amounts of 110-120% of annual revenue? How does that compare to the $90 million of "excess" fees? Samantha Demetriou:One argument in favor of keeping the cost high is that it acts as a sort of gating mechanisms, where only businesses/organizations of a certain size can apply. Being able to foot a high application cost implies that these organizations are more financially stable. If this were to be replaced, the evaluators would have to look much more closely at financials and business plans included in the applications. Michael Flemming:I agree with keeping the cost higher. Cost recovery is the right idea as long as that costs come back. My firm and I feel that for our customers, the value of a gTLD can be seen in its price. Brands in the first round paid a high price for a resource and that becomes minimized if the price of that resource goes down too much for future application windows. Jeff Neuman:@Alexander - To sum up your concerns: (i) IF too low, we may have unsophisticated Buyers of TLDs - threat to security/stability; (ii) If too low, we may hae squatting activities, abuse Donna Austin, Neustar:@Greg, they wouldn't be excess fees if the cost-recovery model was not applied, but my point was more that I don't believe it is appropriate to raise funds to bolster the reserve fund by opening up another round of TLDs. Alexander Schubert:I suggest to ask whether we RAISE the amount to US $500,000 Michael Flemming:Could we just see a list of hands to see who is for the cost-recovery model and who is against? Jeff Neuman:@Michael - I think it is too soon for such a poll Michael Flemming:Just an idea Jeff Neuman:I think we should focus on the pros and cons of each method. Michael Flemming:To grab the storm, because I am curious about who we are trying to convince to change it? Greg Shatan:ICANN does plenty of things that cost money -- that's where the "excess"" of revenues from any income-producing activity goes, as a generic point. Non-profit does not mean non-revenue-generating.... Greg Shatan:I am not suggesting ICANN turn gTLD applications into a "cash cow" but there's a big range between the lowest non-money-losing price and a massive cash cow. Trang Nguyen:Does the concept of floor mean a floor above the cost recovery of processing applications, or some arbitrary floor? It's not clear to me. Michael Flemming:Clarification to cost coming back: Meaning that the excess is used for an agreed upon benefit or that it is returned to applicants/registries. Jeff Neuman:@Michael - but those brands that bought now have a huge first movers advantage (up to 7 years in theory). That is worth a higher price Carlton Samuels:Given what we now know of the market situation, Is there a sense that a new gTLD program should be demand-driven? And, iff we agree with that in principle, it would be a dead easy step to agree in principle the administrative costs to ICANN - the corporation - should be on a cost recovery basis Michael Flemming:Yes, but those same brands don't agree to loweing the price. Jeff Neuman:Trang - the floor means that essentially we would look at cost recovery, but if cost recovery is not as high as the arbitrary price floor, then the price becomes the floor Trang Nguyen:Thanks, Jeff! Jeff Neuman:@Michael - is this really a decision that should be made by existing registries (that may be viewed as a competition concern) Greg Shatan:Maybe we turn every new gTLD application into a potential auction, i.e., applications are public and others can offer a higher price. Not suggesting this is a good idea, but it is an alternative to the current model. Michael Flemming:When those same registries consider applying in subpro, yes it is a high concern. Michael Flemming:applying for more, I mean. Michael Flemming:I think we can move on. Carlton Samuels:@Greg: Hmmm.....maybe in conjunction with the idea of a floor price, we would work that in as an alternative Christa Taylor:It's Sara who is speaking Donna Austin, Neustar:@Trang, I think if we went forward with the current AGB, ICANN could also provide some kind of 'how to' guide based on the experiene from 2012. Trang Nguyen:@Donna, yes, absolutely Phil Buckingham:surely the goal for Round 2 should be to minimise clarifying questions as much as possible . A huge number were re the Q50 question to which a solution will be found for Round 2 Jeff Neuman:This subject will be a primary topic for the next WT 1 call in 2 weeks Donna Austin, Neustar:Christa, I think its an implementation issue. Terri Agnew:Next meeting: New gTLD Subsequent Procedures Sub Team - Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, 11 April 2017 at 20:00 UTC. Michael Flemming:Great meeting! Katrin Ohlmer, DOTZON:thanks, everybody - bye. Michael Flemming:thanks

1 0

Correction: Actions/Discussion Notes: Work Track 1 Sub Team Meeting 28 March 2017
by Julie Hedlund March 28, 2017

March 28, 2017

Dear Sub Team Members, Please see the correct slides attached. These also are posted to the wiki. Best regards, Julie From: <gnso-newgtld-wg-wt1-bounces(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Tuesday, March 28, 2017 at 12:07 PM To: "gnso-newgtld-wg-wt1(a)icann.org" <gnso-newgtld-wg-wt1(a)icann.org> Subject: [Gnso-newgtld-wg-wt1] Actions/Discussion Notes: Work Track 1 Sub Team Meeting 28 March 2017 Dear Sub Team Members, Please see below the action items and discussion notes captured by staff from the meeting on 28 March. 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 Actions/Discussion Notes: 1. Recap & Discussion from ICANN58 a. Holistic Costing Approach to Multiple Rounds (Slide 3) -- Good feedback from ICANN58 (as follows). -- Would cost recovery in the next round be in isolation. Question: is anyone looking at this holistically or only in isolation. -- Consider a first-come, first-served process. -- We have already brought up concerns about surplus and application fees. -- We don't know the number of rounds. Need more information to make it work. -- Recollection from the start of the process: original intent was that the original round would be cost recovery. After the price was set the development took longer than planned and development costs went up radically. Address by spreading development costs over future rounds, presumed not enough money from $185,000. -- Correct that was the original intent: 1) recover historical costs and the development; 2) evaluations; 3) litigation/contingency fund. Because of the surplus and because we've baked in historical costs and no ramp up to begin a new round -- doesn't seem that historical costs need to be built into the round going forward. Leaves the notion that if we want to do a cost-recovery type model need to build in what the costs should and should not be, assuming not a huge ramp up. -- Should be some resusable elements of the system, but need to hear from ICANN staff re: development costs. -- Have the flexibility to decide if new rounds should be isolated or not. -- Development costs were approximately $27,000 per application (part of hte $185,000). So, the question is: should costs be in isolation or not? -- Concern that cost recovery was a pricing ceiling rather than floor. Talking about setting a floor price, which would be a change in policy. -- Unclear economically if we are talking about cross-collateralizing rounds -- assume that there was a net profit from the first round. One could say that if cost recovery is the concept, consider the fact that ICANN dug into its reserves to fund the transition. ICANN has to look at getting its reserves back up. Talking about this in the abstract is a little rough; but mere cost recovery and ignoring other potential costs is narrow minded and needs to be looked at in a much bigger picture. -- Take a few minutes now: existing policy is cost recovery -- do we think there should be a change to that policy, such as a floor. Put down all the reasons to have a floor/to change the policy. -- Why is "Cost" to "society" -- IP community an issue? -- Need to consider why to keep current policy. -- If we do set a price above what it would cost what do we do with the surplus? -- Not sure that dropping the price would result in a large increase. Not sure that an increase in price would lower the number of applications. Price elasticity isn't clear. -- What about having different fees for different types of applications? Action Item: Helpful for WT1 members to share thoughts re questions below with Sara and Christa. 1. Why to have a floor/what happens if price is too low? -- Funding for reserve funds -- Piece of Internet real estate -- If price is too low too easy -- cost for IP community of so many TLDs, many which may fail 2. What if price is too high? -- Anti-competitive 3. Why keep the current policy? >From the chat: Alexander Schubert: Why "cost recovery" in the first place? What if the cost goes down to 5k USD? We face hundreds of thousands of gTLDs? There must be a SUBSTENTIAL hurdle to overcome for applying for a gTLD. The easiest hurdle is a monitary one. If there is no entry barrier we will be FLOODED with applications by "hobby-gTLD-makers". Trang Nguyen: One big development cost for the next round is the system development cost. Steve Chan: I would imagine the development cost would be dependent upon the recommendations from this group. Trang Nguyen: TAS has been retired so we would need to do new system development. Now much work depends on how many changes from the 2012 round there will be. Jeff Neuman: @Steve - of course to some extent. Donna Austin, Neustar: @Alexander, we did have some discussion about the challenges associates with setting a low application fee. Jeff Neuman: But to be honest some of that "development cost" was not wisely spent....especially in trying to develop a home grown customized one time solution. Steve Chan: @Alexander, there is a question related to a pricing floor in CC2. Alexander Schubert: TNX Jeff Neuman: I would really like for us to set forth all of the reasons for which we believe that a floor should be set (as that would be a change in policy). Alexander Schubert: There is also a "cost" to "society", brands, the Intellectual Property community! If 100,000 gTLDs are being applied for because they "cost" only 10k USD - then the "cost" to the wider community is BIG! Donna Austin, Neustar: @Greg, agree about getting the reserves back up, but ICANN shouldn't be using excess fees from a future round to do that. I know that's not what you were suggesting, but I just wanted to put that on the record. Greg Shatan: Donna, I wouldn't consider those to be "excess fees." It's simply revenue. And I don't see why revenue should not be used to bolster reserves. On this point, since the first round fees were so significant, a floor was irrelevant. How far short is ICANN's reserves from best practices amounts of 110-120% of annual revenue? How does that compare to the $90 million of "excess" fees? Michael Flemming: I agree with keeping the cost higher. Cost recovery is the right idea as long as that costs come back. My firm and I feel that for our customers, the value of a gTLD can be seen in its price. Brands in the first round paid a high price for a resource and that becomes minimized if the price of that resource goes down too much for future application windows. Jeff Neuman: @Alexander - To sum up your concerns: (i) IF too low, we may have unsophisticated Buyers of TLDs - threat to security/stability; (ii) If too low, we may hae squatting activities, abuse Donna Austin, Neustar: @Greg, they wouldn't be excess fees if the cost-recovery model was not applied, but my point was more that I don't believe it is appropriate to raise funds to bolster the reserve fund by opening up another round of TLDs. Alexander Schubert: I suggest to ask whether we RAISE the amount to US $500,000. Michael Flemming: Could we just see a list of hands to see who is for the cost-recovery model and who is against? Jeff Neuman: @Michael - I think it is too soon for such a poll Michael Flemming: Just an idea Jeff Neuman: I think we should focus on the pros and cons of each method. Michael Flemming: To grab the storm, because I am curious about who we are trying to convince to change it? Greg Shatan: ICANN does plenty of things that cost money -- that's where the "excess"" of revenues from any income-producing activity goes, as a generic point. Non-profit does not mean non-revenue-generating...I am not suggesting ICANN turn gTLD applications into a "cash cow" but there's a big range between the lowest non-money-losing price and a massive cash cow. Trang Nguyen: Does the concept of floor mean a floor above the cost recovery of processing applications, or some arbitrary floor? It's not clear to me. Michael Flemming: Clarification to cost coming back: Meaning that the excess is used for an agreed upon benefit or that it is returned to applicants/registries. Jeff Neuman: @Michael - but those brands that bought now have a huge first movers advantage (up to 7 years in theory). That is worth a higher price Carlton Samuels: Given what we now know of the market situation, Is there a sense that a new gTLD program should be demand-driven? And, iff we agree with that in principle, it would be a dead easy step to agree in principle the administrative costs to ICANN - the corporation - should be on a cost recovery basis. Michael Flemming: Yes, but those same brands don't agree to loweing the price. Jeff Neuman: Trang - the floor means that essentially we would look at cost recovery, but if cost recovery is not as high as the arbitrary price floor, then the price becomes the floor Trang Nguyen: Thanks, Jeff! Jeff Neuman: @Michael - is this really a decision that should be made by existing registries (that may be viewed as a competition concern) Greg Shatan: Maybe we turn every new gTLD application into a potential auction, i.e., applications are public and others can offer a higher price. Not suggesting this is a good idea, but it is an alternative to the current model. Michael Flemming: When those same registries consider applying in subpro, yes it is a high concern. b. Clarity of Application Process (Slide 4) -- Feedback from ICANN58: Make application process more clear/predictable. -- Question re: If AGB went with no changes would clarifying questions change? Applicants will be smarter about it; help them understand the nature of the questions -- so clarifying questions could be reduced. Also, be smarter in designing the question form. >From the chat: Donna Austin, Neustar: @Trang, I think if we went forward with the current AGB, ICANN could also provide some kind of 'how to' guide based on the experience from 2012. Trang Nguyen: @Donna, yes, absolutely. Phil Buckingham: Surely the goal for Round 2 should be to minimise clarifying questions as much as possible . A huge number were re the Q50 question to which a solution will be found for Round 2. c. RSP Program (Slides 5 and 6) -- At call on 11 April will discuss the proposal from Donna Austin. -- Helpful to have a discussion on the interpretation of the rules concerning testing -- implementation and policy issue. >From the chat: Jeff Neuman: This subject will be a primary topic for the next WT 1 call in 2 weeks. Donna Austin, Neustar: Christa, I think its an implementation issue.

1 0

Actions/Discussion Notes: Work Track 1 Sub Team Meeting 28 March 2017
by Julie Hedlund March 28, 2017

March 28, 2017

Dear Sub Team Members, Please see below the action items and discussion notes captured by staff from the meeting on 28 March. 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 Actions/Discussion Notes: 1. Recap & Discussion from ICANN58 a. Holistic Costing Approach to Multiple Rounds (Slide 3) -- Good feedback from ICANN58 (as follows). -- Would cost recovery in the next round be in isolation. Question: is anyone looking at this holistically or only in isolation. -- Consider a first-come, first-served process. -- We have already brought up concerns about surplus and application fees. -- We don't know the number of rounds. Need more information to make it work. -- Recollection from the start of the process: original intent was that the original round would be cost recovery. After the price was set the development took longer than planned and development costs went up radically. Address by spreading development costs over future rounds, presumed not enough money from $185,000. -- Correct that was the original intent: 1) recover historical costs and the development; 2) evaluations; 3) litigation/contingency fund. Because of the surplus and because we've baked in historical costs and no ramp up to begin a new round -- doesn't seem that historical costs need to be built into the round going forward. Leaves the notion that if we want to do a cost-recovery type model need to build in what the costs should and should not be, assuming not a huge ramp up. -- Should be some resusable elements of the system, but need to hear from ICANN staff re: development costs. -- Have the flexibility to decide if new rounds should be isolated or not. -- Development costs were approximately $27,000 per application (part of hte $185,000). So, the question is: should costs be in isolation or not? -- Concern that cost recovery was a pricing ceiling rather than floor. Talking about setting a floor price, which would be a change in policy. -- Unclear economically if we are talking about cross-collateralizing rounds -- assume that there was a net profit from the first round. One could say that if cost recovery is the concept, consider the fact that ICANN dug into its reserves to fund the transition. ICANN has to look at getting its reserves back up. Talking about this in the abstract is a little rough; but mere cost recovery and ignoring other potential costs is narrow minded and needs to be looked at in a much bigger picture. -- Take a few minutes now: existing policy is cost recovery -- do we think there should be a change to that policy, such as a floor. Put down all the reasons to have a floor/to change the policy. -- Why is "Cost" to "society" -- IP community an issue? -- Need to consider why to keep current policy. -- If we do set a price above what it would cost what do we do with the surplus? -- Not sure that dropping the price would result in a large increase. Not sure that an increase in price would lower the number of applications. Price elasticity isn't clear. -- What about having different fees for different types of applications? Action Item: Helpful for WT1 members to share thoughts re questions below with Sara and Christa. 1. Why to have a floor/what happens if price is too low? -- Funding for reserve funds -- Piece of Internet real estate -- If price is too low too easy -- cost for IP community of so many TLDs, many which may fail 2. What if price is too high? -- Anti-competitive 3. Why keep the current policy? >From the chat: Alexander Schubert: Why "cost recovery" in the first place? What if the cost goes down to 5k USD? We face hundreds of thousands of gTLDs? There must be a SUBSTENTIAL hurdle to overcome for applying for a gTLD. The easiest hurdle is a monitary one. If there is no entry barrier we will be FLOODED with applications by "hobby-gTLD-makers". Trang Nguyen: One big development cost for the next round is the system development cost. Steve Chan: I would imagine the development cost would be dependent upon the recommendations from this group. Trang Nguyen: TAS has been retired so we would need to do new system development. Now much work depends on how many changes from the 2012 round there will be. Jeff Neuman: @Steve - of course to some extent. Donna Austin, Neustar: @Alexander, we did have some discussion about the challenges associates with setting a low application fee. Jeff Neuman: But to be honest some of that "development cost" was not wisely spent....especially in trying to develop a home grown customized one time solution. Steve Chan: @Alexander, there is a question related to a pricing floor in CC2. Alexander Schubert: TNX Jeff Neuman: I would really like for us to set forth all of the reasons for which we believe that a floor should be set (as that would be a change in policy). Alexander Schubert: There is also a "cost" to "society", brands, the Intellectual Property community! If 100,000 gTLDs are being applied for because they "cost" only 10k USD - then the "cost" to the wider community is BIG! Donna Austin, Neustar: @Greg, agree about getting the reserves back up, but ICANN shouldn't be using excess fees from a future round to do that. I know that's not what you were suggesting, but I just wanted to put that on the record. Greg Shatan: Donna, I wouldn't consider those to be "excess fees." It's simply revenue. And I don't see why revenue should not be used to bolster reserves. On this point, since the first round fees were so significant, a floor was irrelevant. How far short is ICANN's reserves from best practices amounts of 110-120% of annual revenue? How does that compare to the $90 million of "excess" fees? Michael Flemming: I agree with keeping the cost higher. Cost recovery is the right idea as long as that costs come back. My firm and I feel that for our customers, the value of a gTLD can be seen in its price. Brands in the first round paid a high price for a resource and that becomes minimized if the price of that resource goes down too much for future application windows. Jeff Neuman: @Alexander - To sum up your concerns: (i) IF too low, we may have unsophisticated Buyers of TLDs - threat to security/stability; (ii) If too low, we may hae squatting activities, abuse Donna Austin, Neustar: @Greg, they wouldn't be excess fees if the cost-recovery model was not applied, but my point was more that I don't believe it is appropriate to raise funds to bolster the reserve fund by opening up another round of TLDs. Alexander Schubert: I suggest to ask whether we RAISE the amount to US $500,000. Michael Flemming: Could we just see a list of hands to see who is for the cost-recovery model and who is against? Jeff Neuman: @Michael - I think it is too soon for such a poll Michael Flemming: Just an idea Jeff Neuman: I think we should focus on the pros and cons of each method. Michael Flemming: To grab the storm, because I am curious about who we are trying to convince to change it? Greg Shatan: ICANN does plenty of things that cost money -- that's where the "excess"" of revenues from any income-producing activity goes, as a generic point. Non-profit does not mean non-revenue-generating...I am not suggesting ICANN turn gTLD applications into a "cash cow" but there's a big range between the lowest non-money-losing price and a massive cash cow. Trang Nguyen: Does the concept of floor mean a floor above the cost recovery of processing applications, or some arbitrary floor? It's not clear to me. Michael Flemming: Clarification to cost coming back: Meaning that the excess is used for an agreed upon benefit or that it is returned to applicants/registries. Jeff Neuman: @Michael - but those brands that bought now have a huge first movers advantage (up to 7 years in theory). That is worth a higher price Carlton Samuels: Given what we now know of the market situation, Is there a sense that a new gTLD program should be demand-driven? And, iff we agree with that in principle, it would be a dead easy step to agree in principle the administrative costs to ICANN - the corporation - should be on a cost recovery basis. Michael Flemming: Yes, but those same brands don't agree to loweing the price. Jeff Neuman: Trang - the floor means that essentially we would look at cost recovery, but if cost recovery is not as high as the arbitrary price floor, then the price becomes the floor Trang Nguyen: Thanks, Jeff! Jeff Neuman: @Michael - is this really a decision that should be made by existing registries (that may be viewed as a competition concern) Greg Shatan: Maybe we turn every new gTLD application into a potential auction, i.e., applications are public and others can offer a higher price. Not suggesting this is a good idea, but it is an alternative to the current model. Michael Flemming: When those same registries consider applying in subpro, yes it is a high concern. b. Clarity of Application Process (Slide 4) -- Feedback from ICANN58: Make application process more clear/predictable. -- Question re: If AGB went with no changes would clarifying questions change? Applicants will be smarter about it; help them understand the nature of the questions -- so clarifying questions could be reduced. Also, be smarter in designing the question form. >From the chat: Donna Austin, Neustar: @Trang, I think if we went forward with the current AGB, ICANN could also provide some kind of 'how to' guide based on the experience from 2012. Trang Nguyen: @Donna, yes, absolutely. Phil Buckingham: Surely the goal for Round 2 should be to minimise clarifying questions as much as possible . A huge number were re the Q50 question to which a solution will be found for Round 2. c. RSP Program (Slides 5 and 6) -- At call on 11 April will discuss the proposal from Donna Austin. -- Helpful to have a discussion on the interpretation of the rules concerning testing -- implementation and policy issue. >From the chat: Jeff Neuman: This subject will be a primary topic for the next WT 1 call in 2 weeks. Donna Austin, Neustar: Christa, I think its an implementation issue.

1 0

WT1 Agenda
by Sara Bockey March 27, 2017

March 27, 2017

Dear All, The next call for the New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, 28 March 2017 at 15:00 UTC. The proposed agenda is as follows: 1. Welcome & Agenda Overview 2. SOIs 3. Recap & Discussion from ICANN 58 * Costing * Clarity of Application Process * RSP Program Thanks, Sara 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

Actions/Discussion Notes: New gTLD Subsequent Procedures PDP WG Meeting - Sub Team 1 - 28 February 2017
by Emily Barabas March 1, 2017

March 1, 2017

Dear All, Please see below the action items and discussion notes captured by staff from the Sub Team 1 meeting on 28 February 2017. These high-level notes are designed to help Working Group members navigate through the content of the call and are not a substitute for the recording. The recording is available at https://community.icann.org/x/l7PDAw. Kind regards, Emily Agenda: 1. Welcome & Agenda Overview 2. SOIs 3. Communications & Systems a. From the New gTLD Program Implementation Review provided several recommendations that the group may want to consider in developing implementation guidance on Systems and Communications. https://www.icann.org/en/system/files/files/program-review-29jan16-en.pdf i. Systems (see page 174) ii. Communications (see page 198) 4. Application Guidebook,https://community.icann.org/display/NGSPP/4.2.5+Applicant+Guidebo… 5. CC2 Questions, https://docs.google.com/document/d/1iZBCVEAJPBYEDg7jLsMHKkNczR_b6-jH2Wl5eVH…<https://docs.google.com/document/d/1iZBCVEAJPBYEDg7jLsMHKkNczR_b6-jH2Wl5eVH…> 6. AOB Action Items: ACTION ITEM: WT1 leads will circulate request for input on CC2 questions by email. Notes: 2. SOIs - No updates. 4. Application Guidebook - Introduction: - Background: The AGB is different from some of the other subjects the group is considering in that it is not the result of consensus policy. - The AGB was the vehicle for implementation of the policy. There were 9 versions of the AGB over 4 years. Used as a guide for staff in the implementation. - Questions & Concerns: Some DG members suggested dividing the AGB into sections by audience or making it a procedural guide with background separated out in a different section. Some suggested that the AGB was not the right vehicle although no alternative was proposed. - Rationale for policy development - the DG did not anticipate policy development, but the WG may want to make suggestions for changing the AGB structure or approach. The WG could also recommend an alternate vehicle to the AGB. - Discussion: - Is the AGB the right methodology? - The AGB is as good as any other potential vehicle, we don't need to completely revamp it. There is a lot of rationale and background, legalese. - There is an opportunity to do an "idiot's guide" or a stripped down version with the things applicants need to know (rationale in a different section or document). - How can the current AGB be improved? By type of application? Can it be made more readable? - Not necessarily by type of application. As things currently stand, the information would be similar for different application types. - It may be helpful to break out certain information, for example information for technical providers and registry operators if there is a RSP program. - Should it be step-based depending on the type of application? - No additional comments. From the chat: Ashley Roberts: I'm happy with the AGB as the correct methodology. There may be a case for small changes based on individual implementation changes, but in general the AGB does the job. Vanda Scartezini: agree with jeff. not by the kind of application. 3. Communications & Systems a. Systems: - Review of recommendations from the Implementation Review on Systems (8.1.a and 8.1.b). - Discussion and findings to date indicate a need for: 1. Improvements to security and stability 2. Ability to use non-ASCII 3. Systems should be capable of sending automated invoices. - Applicants and registries don't "own" correspondence because it is held in ICANN's portals. Security concerns - risk of data loss. There is also a risk associated with ownership of the correspondence if there is a dispute or legal action. - Clarification regarding invoices - the requirement would be for making invoices available, not about the specific system. From the chat: Jeff Neuman: Part of the problem was that ICANN believed it had to develop cusomized systems at the beignning as opposed to looking at what was out there. Rather than cusomizations, ICANN should look now at what is out there and not wait until the next round starts Jeff Neuman: On beta testing, this is something that we did propose for the last round, but ICANN was afraid that giving some of us access for beta testing purposes would be some kind of advantage in the application process Jeff Neuman: I didnt agree, but that was their view Trang Nguyen: Is the requirement for the system to be able to generate invoices, or to just send? invoices might need to be generated in a different system than the application system. Christa Taylor: Trang - idea is to be able to generate and send an invoice if they need it for their own internal purposes for payment systems Jon Nevett: I am sure that we discussed this before, but systems need to be secure -- the data breach -- where highly confidential information was accessed -- was very problematic for many applicants Ashley Roberts: A possible solution to the issue I raised could be to have the systems automatically email a copy of any new added correspondence to applicants so that they have an email copy as well as in the portal. Alan Greenberg: Issue is not, I presume, whether invoice is delivered through portal, but that it can be requested. b. Review of recommendations in the Program Implementation Review regarding Communications (8.4.a and 8.4.b) - Discussions and findings to date indicate need for: 1. the knowledge base to be made more timely and searchable 2. better communication of applicant advisories. consolidation of program information into a single site 3. Leverage GSE team to promote awareness about the new gTLD program 4. metrics to understand level of success. - There was lots of discussion of the communication plan in the Implementation Review, but little discussion of timing of communications period, budget of communications period, languages, etc. - This topic is connected to customer service, and we should probably spend some time on that. There was a phone line before the application period started, but that was eliminated during the application period. Email was much slower. - Recommend real-time customer support. if phone is not possible, maybe a chat function could be implemented. - ICANN doesn't send you communication, it sends you a note that there is an update in the portal. It would be helpful if you could get messages through email rather than having to log into the portal to get messages. - The policy process was still going on for some topics (for example RPMs) while the New gTLD Program was being implemented. There was a strict prohibition on ICANN staff talking to applicants, but they could talk to other community members in policy discussions, which seems unfair. From the chat: Phil Buckingham: should not invoicing be done through ICANN's accounting system .., which should be totally separate from the application syatem ,. The overriding requirement must be to absolutely elliminate any attempt (s) of a breach of the application portal , this time . Trang Nguyen: For background and context, phone support was provided during the application window for technical issues related to accessing TAS. To ensure equal access to information, ICANN developed knowledge articles when a question is received, and then point to it to respond. Jeff Neuman: Fear of communicating with applicants led to ICANN not being clear with applicants...this led to I believe an increase in having to issue Clarifying questions Jeff Neuman: @Trang, but it was impossible to really search the knowledge database and get the answers Jeff Neuman: On the TAS system, I am not sure why the submission of applications had to only be in ASCII, no links, no diagrams, etc. Trang Nguyen: Yes, the search capability of the knowledge base had room for improvement. Jeff Neuman: Lots of complaints about that Ashley Roberts: Tagging onto Jeff's point, any applicant information should be easy to locate and preferably stored in one place. In the first round information was stored in various locations - the AGB, the knowledge base, FAQs, etc, making it hard to fiind what you were looking for. Phil Buckingham: + 1 Ashley Jeff Neuman: And if you had a question,customer support took days to answer because all answers needed to be approved by legal Jeff Neuman: and other parties Trang Nguyen: @Jeff, to ensure equal access to information, we had to generalize questions received, draft responses, run the draft responses by subject matter experts to ensure accuracy, post and then answer the question, pointing the applicant to the knowledge article. This takes time and did impact response time. But, if the same question is asked again, response time is within 24 hours for those where existing content exists. Jeff Neuman: @Trang, the issue is that the questions are never asked the same way....so getting a quick response was rare. I believe the equal access argument was overplayed. Equal access would only apply to any NEW information. Not answering questions about existing systems, processes, etc. Trang Nguyen: customer service stats: http://archive.icann.org/en/meetings/costarica2012/bitcache/New%20gTLD%20Pr…<https://urldefense.proofpoint.com/v2/url?u=http-3A__archive.icann.org_en_me…> Average resolution tme is 1.6 days. 80% responded within 24 hours. 5. CC2 Questions Revisions to CC2 questions: - Cost recovery - the real word should be "break even," the point where total revenue and total expenses are equal. - Language has been revised on cost floor and ceiling. - Question on the use of shortage or surplus of funds. On the last call, the group agreed to keep it "out of the weeds" and make recommendations at a high policy level. Request for the group to review the language. - 1.4.3 - asks about how floor and ceiling amounts should be set. - 1.4.2 – question for the group - is this question still valid? - Questions about language related to use of excess funds. - New language added to 1.4.3 regarding use of surplus for underserved regions. - 1.5.3 - Is there something specific that we want to address regarding the volume of applications? - 1.1.11 - regarding funding of an RSP program - do edits properly represent discussion on 14 Feb call? ACTION ITEM: WT1 leads will circulate request for input on CC2 questions by email. From the chat: Jeff Neuman: I think the use of excess funds needs further exploration. From a policy level, we should just state that the AG should set forth the use of excess funds if any From the chat: Jeff Neuman: I believe that IF there is an RSP Program it should be self funded Jeff Neuman: meaninig that it should be paid for by those participating 6. AOB - none.

1 0

Recording, Attendance & AC Chat from New gTLD Subsequent Procedures Sub Team Track 1 - Overall Process/Support/Outreach Issue call on Tuesday, 28 February 2017
by Michelle DeSmyter March 1, 2017

March 1, 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, 28 February 2017 at 20:00 UTC. <http://audio.icann.org/gnso/gnso-new-gtld-subsequent-16may16-en.mp3> 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#nov> ** 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/l7PDAw Thank you. Kind regards, Michelle ------------------------------- Adobe Connect chat transcript for 28 February 2017 Michelle DeSmyter:Welcome to the New gTLD Subsequent Procedures Sub Team – Track 1 – Overall/Process/Support/Outreach Issue call on Tuesday, 28 February 2017 at 20:00 UTC Michelle DeSmyter:Meeting page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… Sara Bockey:please mute if not speaking Ashley Roberts:I'm happy with the AGB as the correct methodology. There may be a case for small changes based on individual implementation changes, but in general the AGB does the job. Alan Greenberg:Sorry to be late. Vanda Scartezini:sorry to be late, it is carnival here - very noise place - just listen. Vanda Scartezini:agree with jeff. not by the kind of application Christa Taylor:Thanks Vanda. Jeff Neuman:Part of the problem was that ICANN believed it had to develop cusomized systems at the beignning as opposed to looking at what was out there. Rather than cusomizations, ICANN should look now at what is out there and not wait until the next round starts Jeff Neuman:On beta testing, this is something that we did propose for the last round, but ICANN was afraid that giving some of us access for beta testing purposes would be some kind of advantage in the application process Jeff Neuman:I didnt agree, but that was their view Trang Nguyen:Is the requirement for the system to be able to generate invoices, or to just send? invoices might need to be generated in a different system than the application system. Vanda Scartezini:yes. many studies ahve been done from underserved regions that can be used Jon Nevett:I am sure that we discussed this before, but systems need to be secure -- the data breach -- where highly confidential information was accessed -- was very problematic for many applicants Christa Taylor:Trang - idea is to be able to generate and send an invoice if they need it for their own internal purposes for payment systems Ashley Roberts:A possible solution to the issue I raised could be to have the systems automatically email a copy of any new added correspondence to applicants so that they have an email copy as well as in the portal. Alan Greenberg:Issue is not, I presume, whether invoice is delivered through portal, but that it can be requested. Jeff Neuman:Customer support was in the "Communications" section of the Implementation Review documnet from ICANN, so I assumed it belonged here Karen Day:+1 Jon Phil Buckingham:should not invoicing be done through ICANN's accounting system .., which should be totally separate from the application syatem ,. The overriding requirement must be to absolutely elliminate any attempt (s) of a breach of the application portal , this time . Trang Nguyen:For background and context, phone support was provided during the application window for technical issues related to accessing TAS. To ensure equal access to information, ICANN developed knowledge articles when a question is received, and then point to it to respond. Jeff Neuman:Fear of communicating with applicants led to ICANN not being clear with applicants...this led to I believe an increase in having to issue Clarifying questions Jeff Neuman:@Trang, but it was impossible to really search the knowledge database and get the answers Jeff Neuman:On the TAS system, I am not sure why the submission of applications had to only be in ASCII, no links, no diagrams, etc. Trang Nguyen:Yes, the search capability of the knowledge base had room for improvement. Jeff Neuman:Lots of complaints about that Ashley Roberts:Tagging onto Jeff's point, any applicant information should be easy to locate and preferably stored in one place. In the first round information was stored in various locations - the AGB, the knowledge base, FAQs, etc, making it hard to fiind what you were looking for. Phil Buckingham:+ 1 Ashley Jeff Neuman:And if you had a question,customer support took days to answer because all answers needed to be approved by legal Jeff Neuman:and other parties Jeff Neuman:I think the use of excess funds needs further exploration. From a policy level, we should just state that the AG should set forth the use of excess funds if any Trang Nguyen:@Jeff, to ensure equal access to information, we had to generalize questions received, draft responses, run the draft responses by subject matter experts to ensure accuracy, post and then answer the question, pointing the applicant to the knowledge article. This takes time and did impact response time. But, if the same question is asked again, response time is within 24 hours for those where existing content exists. Jeff Neuman:@Trang, the issue is that the questions are never asked the same way....so getting a quick response was rare. I believe the equal access argument was overplayed. Equal access would only apply to any NEW information. Not answering questions about existing systems, processes, etc. Jeff Neuman:I believe that IF there is an RSP Program it should be self funded Jeff Neuman:meaninig that it should be paid for by those participating Cheryl Langdon-Orr (CLO):... Safe travels to those going to ICANN 58thanks everyone... bye for now Jeff Neuman:thanks Trang Nguyen:customer service stats: https://urldefense.proofpoint.com/v2/url?u=http-3A__archive.icann.org_en_me… . Average resolution tme is 1.6 days. 80% responded within 24 hours. Vanda Scartezini:safe traveks to all kisses

1 0

Recording, Attendance & AC Chat for New gTLD Subsequent Procedures Sub Team Track 1 - Overall Process/Support/Outreach Issue call on Tuesday, 28 February 2017
by Michelle DeSmyter March 1, 2017

March 1, 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, 28 February 2017 at 20:00 UTC. <http://audio.icann.org/gnso/gnso-new-gtld-subsequent-16may16-en.mp3> 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#nov> ** 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/l7PDAw Thank you. Kind regards, Michelle ------------------------------- Adobe Connect chat transcript for 28 February 2017 Michelle DeSmyter:Welcome to the New gTLD Subsequent Procedures Sub Team – Track 1 – Overall/Process/Support/Outreach Issue call on Tuesday, 28 February 2017 at 20:00 UTC Michelle DeSmyter:Meeting page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… Sara Bockey:please mute if not speaking Ashley Roberts:I'm happy with the AGB as the correct methodology. There may be a case for small changes based on individual implementation changes, but in general the AGB does the job. Alan Greenberg:Sorry to be late. Vanda Scartezini:sorry to be late, it is carnival here - very noise place - just listen. Vanda Scartezini:agree with jeff. not by the kind of application Christa Taylor:Thanks Vanda. Jeff Neuman:Part of the problem was that ICANN believed it had to develop cusomized systems at the beignning as opposed to looking at what was out there. Rather than cusomizations, ICANN should look now at what is out there and not wait until the next round starts Jeff Neuman:On beta testing, this is something that we did propose for the last round, but ICANN was afraid that giving some of us access for beta testing purposes would be some kind of advantage in the application process Jeff Neuman:I didnt agree, but that was their view Trang Nguyen:Is the requirement for the system to be able to generate invoices, or to just send? invoices might need to be generated in a different system than the application system. Vanda Scartezini:yes. many studies ahve been done from underserved regions that can be used Jon Nevett:I am sure that we discussed this before, but systems need to be secure -- the data breach -- where highly confidential information was accessed -- was very problematic for many applicants Christa Taylor:Trang - idea is to be able to generate and send an invoice if they need it for their own internal purposes for payment systems Ashley Roberts:A possible solution to the issue I raised could be to have the systems automatically email a copy of any new added correspondence to applicants so that they have an email copy as well as in the portal. Alan Greenberg:Issue is not, I presume, whether invoice is delivered through portal, but that it can be requested. Jeff Neuman:Customer support was in the "Communications" section of the Implementation Review documnet from ICANN, so I assumed it belonged here Karen Day:+1 Jon Phil Buckingham:should not invoicing be done through ICANN's accounting system .., which should be totally separate from the application syatem ,. The overriding requirement must be to absolutely elliminate any attempt (s) of a breach of the application portal , this time . Trang Nguyen:For background and context, phone support was provided during the application window for technical issues related to accessing TAS. To ensure equal access to information, ICANN developed knowledge articles when a question is received, and then point to it to respond. Jeff Neuman:Fear of communicating with applicants led to ICANN not being clear with applicants...this led to I believe an increase in having to issue Clarifying questions Jeff Neuman:@Trang, but it was impossible to really search the knowledge database and get the answers Jeff Neuman:On the TAS system, I am not sure why the submission of applications had to only be in ASCII, no links, no diagrams, etc. Trang Nguyen:Yes, the search capability of the knowledge base had room for improvement. Jeff Neuman:Lots of complaints about that Ashley Roberts:Tagging onto Jeff's point, any applicant information should be easy to locate and preferably stored in one place. In the first round information was stored in various locations - the AGB, the knowledge base, FAQs, etc, making it hard to fiind what you were looking for. Phil Buckingham:+ 1 Ashley Jeff Neuman:And if you had a question,customer support took days to answer because all answers needed to be approved by legal Jeff Neuman:and other parties Jeff Neuman:I think the use of excess funds needs further exploration. From a policy level, we should just state that the AG should set forth the use of excess funds if any Trang Nguyen:@Jeff, to ensure equal access to information, we had to generalize questions received, draft responses, run the draft responses by subject matter experts to ensure accuracy, post and then answer the question, pointing the applicant to the knowledge article. This takes time and did impact response time. But, if the same question is asked again, response time is within 24 hours for those where existing content exists. Jeff Neuman:@Trang, the issue is that the questions are never asked the same way....so getting a quick response was rare. I believe the equal access argument was overplayed. Equal access would only apply to any NEW information. Not answering questions about existing systems, processes, etc. Jeff Neuman:I believe that IF there is an RSP Program it should be self funded Jeff Neuman:meaninig that it should be paid for by those participating Cheryl Langdon-Orr (CLO):... Safe travels to those going to ICANN 58thanks everyone... bye for now Jeff Neuman:thanks Trang Nguyen:customer service stats: https://urldefense.proofpoint.com/v2/url?u=http-3A__archive.icann.org_en_me… . Average resolution tme is 1.6 days. 80% responded within 24 hours. Vanda Scartezini:safe traveks to all kisses

1 0