Notes and Action Items - New gTLD Subsequent Procedures PDP Working Group - 2 October 2018 at 3:00 UTC
Dear Working Group members, Please see below the notes from the meeting today, 2 October 2018. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/x/4QirBQ. Kind regards, Emily ---------------------------------------------------------------------------------------------------------- Notes and Action Items: 1. Agenda review/SOIs -- None 2. Supplemental Report: Review of sections 1.1, 1.2, 1.3, 1.4, and 1.5 continued -- Goal is to publish the report no later than 12 Oct 2018. -- Comments from several members sent to the list recently, not incorporated into the draft. -- The draft has captured all changes in a cumulative manner. Section 1.1 -- Changes include a potential limit to the number of auctions an applicant could participate in -- ICANN Board has concerns about private auctions -- Could the auction be front-loaded? At the time of application, applicant puts forth the maximum amount they would be willing to pay. If contested, winner is the highest bid, paying the second highest bid amount. Benefits include an accurate valuation to each of the participants, potentially. Would need an applicant support element integrated. Action Item: Sarah L to submit write-up of proposal described above. Rubens Kuhl: One of the challenges for those applying to more than 1 TLD, either 2 or an infinite number of them, is to submit maximum bids for each string, since if hey lose one, they have more resources to pay in another one. -- Do the losing bidders pay anything? Receive any benefit? -- Front-loading the auction flips the emphasis of the current auction of last resort. Would the mony need to go into escrow? Could be fairness issues as there may be subconscious biases related to the bid amouts. -- How would community applications be considered in this process? -- Sarah built off of Greg's idea to front-load contention resolution. Sealed price sealed bid auction. Funds collected should go to public benefit. The highest bidder goes through the initial evaluation process, paying the second highest bid. From the chat: Anne Aikman-Scalese: COMMENT: The way to resolve that may be give Community applicants a priority round. Then you are only resolving contention among community applicants. Then in the general round, the bid could be a "silent auction". COMMENT Michael Casadevall: COMMENT: I can see a tie. Two companies bidding the same nice round number. - When would evaluators know the highest bidder, if ever? It seems like in the beginning, as that seems to drive the evaluation order of the contention set. -- Add additional text as suggested by Anne Aikman-Scalese via email, at the end of the second paragraph. Section 1.2 - Unsure of why emphasis is only on private auctions. Is the issue more about the parties that did not win the string are ending up getting paid off? Are other private resolutions problematic as well? Could result in every contention set ending up in auction. It would be odd to ban private auctions, but not other private resolution methods. From the chat: Rubens Kuhl: Curiously, people seem to be in favor of private resolution by constituing joint-ventures. Rubens Kuhl: But Jon is right, you can't have the cake and eat it too. Michael Casadevall: Well, forming a JV is somewhat different since it's "everyone wins" Jim Prendergast: ff memory serves correct - I think the suggestion for a determination draw was to replace both private auction and ICANN last resort auction Michael Casadevall: It should be noted that banning private resolutions except X is an option. Rubens Kuhl: I can sell shares in a JV for the highest bidder. Justine Chew: Correct, we need to be clear on what should be encouraged vs discouraged (or disallowed). Rubens Kuhl: There's no way to implement such discretionary approach to private resolutions. It's all or nothing. -- Joint ventures seem less objectionable to many. Allowing for changes to strings has been considered as well. - Include concerns about the private resolutions in the private auctions section. Seems like it needs to be all private resolutions are allowed or none are allowed. - Suggestion to pull the preliminary recommendation out of section (c). Prior to Jon's intervention, it seemed like that was the direction of the group previously. - Private auctions is a sub set of private resolutions. There may be some forms of private resolution that could be acceptable, while private auctions may indeed be the most problematic element. Action Item: leadership team to reevaluate how to organize section, given new issues raised by Jon. -- There is still a general sentiment that private auctions are problematic. From the chat: Anne Aikman-Scalese: QUESTION: If the award goes to a certain entity and if the entity changes, ICANN approval is needed, right? Does that reduce gaming in the suggested solutions? QUESTION Anne Aikman-Scalese: Its a question related to whether any system we devise could be easily "gamed". -- Change in entity prior to contract signing, additional due diligence is needed. After contract signing, due diligence needed as well. -- There are public comments to the Initial Report that may be of relevance to the supplemental report. Statistics on auctions from Rubens: From the chat: Rubens Kuhl: Michael, https://newgtlds.icann.org/en/program-status/statistics [newgtlds.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__newgtlds.icann.org_en_p...> has the numbers. Rubens Kuhl: Total Contention Sets 234 Rubens Kuhl: Resolved Contention Sets 226 Rubens Kuhl: Contention Sets Resolved via ICANN Auction 16 Rubens Kuhl: Unresolved Contention Sets 8 Rubens Kuhl: Applications Pending Contention Resolution 24 Michael Casadevall: Maybe it's just me, but I haven't heard much support for auctions in general, even as a public last resort. -- Options to auctions are provided, but there is an argument made in section 1.1 for the fairness of auctions. From the chat: Jim Prendergast: here is the Board comment on private auctions - Regarding question 2.7.4.e.2 on “gaming” or abuse of private auction, the Boardbelieves that applications should not be submitted as a means to engage in privateauctions, including for the purpose of using private auctions as a method of financingtheir other applications. This not only increases the workload on processing but putsundue financial pressure on other applicants who have business plans and financingbased on their intention to execute the plan described in the application. In particular, weare concerned about how gaming for the purpose of financing other applications, or withno intent to operate the gTLD as stated in the application, can be reconciled withICANN's Commitments and Core Values. Jon Nevett: Perhaps we should refer to private sales vs. private auctions? Section 1.3 -- No changes since last meeting. Section 1.4 -- Talks about change requests that may allow for contention resolution (e.g., joint ventures and string change). -- No changes since last meeting. - If in a contention set and you are able to choose another string, does it prevent choosing a string that puts you in another contention set? Action Item: Include language above. Section 1.5 -- Added elements about asking registrars for advice. - Is the intention to create a retail space for registry's that are failing? Are we interfering in the marketplace? Is ICANN acting as a regulator by serving in a registrar? Is there a compliance issue here as well? Action Item: Jim P to circulate text to strengthen section concerning elements above. Perhaps create a question. -- ICANN is not just regulating types of things, but it's also regulating how it's distributed. There is already manipulation of the market. From the chat: Jon Nevett: Jim +1 -- if a registry isn't getting sufficient registrar support, it could start its own - Some have noted challenges with starting a registrar, as well as challenges meet the requirements of the code of conduct, especially for smaller organizations. From the chat: Christopher Wilkinson: Section 1.5: just to recall that I hae already posted my comments to the List. Rubens Kuhl: Jon, that doesn't work in practice due to (1) high cost of registrar accreditation when used to sell a single TLD (2) registrants inertia or preferrence to use a single registrar/reseller for all their domain registrations. Michael Casadevall: I see Jim's point, but I have concerns that a registar may refuse to carry a gTLD for non-technical/non-financal reasons. I want to see Jim's comments before I dig in deeper though. Jon Nevett: in the 2005-8 policy debate on use of registrars, the key was that the protections required in the RAA are required for all registrations -- protections could be integrated into the Registry Agreement. From the chat: Rubens Kuhl: Michael, must-carry obligations were deemed to be over the top. So this doesn't seem to have much traction indeed. Jim Prendergast: Michael - do you envision a scenario where ICANN shoudl force a registrar to carry a TLD? --Everyone should review text, especially questions, options, etc. a. Draft of the additional Supplemental Report sections. - Jeff added additional context about why this supplemental report is being issued. Noted that public comments related to these subjects will not have been considered. -- Was there a Work Track involved in reviewing these issues? -- If relevant, the relevant section is cited in the sections. However, most topics are mostly new. -- When reviewing comments, will try to identify where those comments may be relevant to the supplemental report. 3. Initial assessment of work required for Final CCT-RT Report -- Overview of columns included in the document -- Recommendation 9: Reading through the What Else Needs to Be Done (final column)? -- Any objections to the approach suggested in this column? - no objections raised. -- Anne Aikman-Scalese - Submitted a question to the list about this document. On recommendation 9, the RPM process is not a PDP. It is a review. General question about recommendations coming out of reviews and how the WG is expected to address these. Please see comment/question on list. From the chat: Anne Aikman-Scalese: I sent questions to the list on this document. Anne Aikman-Scalese: RPM Review is not a PDP so the question relates to how results of mandated Reviews are considered procedurally. Same basic question applies to CCT-RT Review and relationship of those Recommendations to the PDP. There may be public comment on these questions - not sure. Jeff Neuman: The RPM Review is a PDP Jeff Neuman: It is charged with reviewing and making recommendations Jon Nevett: https://gnso.icann.org/sites/default/files/file/field-file-attach/projects-l... [gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_de...> Jon Nevett: cite to show it is a PDP -- This comment from Anne does not appear to be contrary to the comments in the "What Else Needs To Be Done?" Due to the overlapping nature of the charters, it will be necessary to take into account the work that this group has done. -- Recommendation 12: reading through "What Else Needs To Be Done?" -- There is a broader question about how this Working Group is required to consider the results of the reviews, including the CCT-RT. From the chat: Jeff Neuman: The CCT-RT is just advice to the Board -- Main takeway: WG members should look at the recommendations and look at the last column about what needs to be done from our perspective. -- This week on the leadership team call, the leadership team will give some thought on the approach to reviewing this documents and the CCT-RT recommendations. - At this stage the recommendations are recommendations to the Board and not the PDP, but if the Board asks the PDP how it is considering the reocmmendations, it would be helpful for the group to complete an initial review of the items directed at the PDP. From the chat: Anne Aikman-Scalese: Okay thanks for clarifying that Review reports are recommendations to the Board. My concern is sending differing recommendations from two different groups. If the Board has to resolve, that slows things down. - Clarification: It is not so much that the Board needs to resolve this. To complete the review, the Board will need to provide additional guidance about whether it accepts the recommendations. The Board will provide direction to the GNSO Council, which will direct the PDP. 4. AOB 4.1 Update on the Initial Report public comment review process - Public comments received on Intiial Report - public comment period closed on Wednesday. Close to 70 comments were received including from many of the SO/AC/SG/Cs, GDD, ICANN Board and a number of ccTLDs. - This is a large number of comments. There is a lot of work underway to organize and tabulate comments to support the WG's review of comments. -- Staff has created three Google Sheets that are similiar to the ones used for reviewing CC2. - There is one Google Doc per review SubTeam and one tab per topic area. Each preliminary recommendation, option, and question has a section within the sheet. - Where the specific preliminary recommendation, option, or question is referenced, this excerise is straightforward. Please check staff's categorization of the other comments. -- Goal is to have initial tabulation complete sometime next week, well in advance of ICANN63. Emily Barabas | Policy Manager ICANN | Internet Corporation for Assigned Names and Numbers Email: emily.barabas@icann.org | Phone: +31 (0)6 84507976
All, Attached are my comments on the draft Supplemental Report. (I’ve come up for air from the EPDP WG long enough to get caught up on the transcripts for meetings I’ve missed – except for last night’s.) Please let me know if you have any questions. K Kristina Rosette Senior Corporate Counsel, IP – Domains rosettek@amazon.com<mailto:rosettek@amazon.com> | 703.407.1354 From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Emily Barabas Sent: Tuesday, October 02, 2018 5:51 AM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP Working Group - 2 October 2018 at 3:00 UTC Dear Working Group members, Please see below the notes from the meeting today, 2 October 2018. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/x/4QirBQ. Kind regards, Emily ---------------------------------------------------------------------------------------------------------- Notes and Action Items: 1. Agenda review/SOIs -- None 2. Supplemental Report: Review of sections 1.1, 1.2, 1.3, 1.4, and 1.5 continued -- Goal is to publish the report no later than 12 Oct 2018. -- Comments from several members sent to the list recently, not incorporated into the draft. -- The draft has captured all changes in a cumulative manner. Section 1.1 -- Changes include a potential limit to the number of auctions an applicant could participate in -- ICANN Board has concerns about private auctions -- Could the auction be front-loaded? At the time of application, applicant puts forth the maximum amount they would be willing to pay. If contested, winner is the highest bid, paying the second highest bid amount. Benefits include an accurate valuation to each of the participants, potentially. Would need an applicant support element integrated. Action Item: Sarah L to submit write-up of proposal described above. Rubens Kuhl: One of the challenges for those applying to more than 1 TLD, either 2 or an infinite number of them, is to submit maximum bids for each string, since if hey lose one, they have more resources to pay in another one. -- Do the losing bidders pay anything? Receive any benefit? -- Front-loading the auction flips the emphasis of the current auction of last resort. Would the mony need to go into escrow? Could be fairness issues as there may be subconscious biases related to the bid amouts. -- How would community applications be considered in this process? -- Sarah built off of Greg's idea to front-load contention resolution. Sealed price sealed bid auction. Funds collected should go to public benefit. The highest bidder goes through the initial evaluation process, paying the second highest bid. From the chat: Anne Aikman-Scalese: COMMENT: The way to resolve that may be give Community applicants a priority round. Then you are only resolving contention among community applicants. Then in the general round, the bid could be a "silent auction". COMMENT Michael Casadevall: COMMENT: I can see a tie. Two companies bidding the same nice round number. - When would evaluators know the highest bidder, if ever? It seems like in the beginning, as that seems to drive the evaluation order of the contention set. -- Add additional text as suggested by Anne Aikman-Scalese via email, at the end of the second paragraph. Section 1.2 - Unsure of why emphasis is only on private auctions. Is the issue more about the parties that did not win the string are ending up getting paid off? Are other private resolutions problematic as well? Could result in every contention set ending up in auction. It would be odd to ban private auctions, but not other private resolution methods. From the chat: Rubens Kuhl: Curiously, people seem to be in favor of private resolution by constituing joint-ventures. Rubens Kuhl: But Jon is right, you can't have the cake and eat it too. Michael Casadevall: Well, forming a JV is somewhat different since it's "everyone wins" Jim Prendergast: ff memory serves correct - I think the suggestion for a determination draw was to replace both private auction and ICANN last resort auction Michael Casadevall: It should be noted that banning private resolutions except X is an option. Rubens Kuhl: I can sell shares in a JV for the highest bidder. Justine Chew: Correct, we need to be clear on what should be encouraged vs discouraged (or disallowed). Rubens Kuhl: There's no way to implement such discretionary approach to private resolutions. It's all or nothing. -- Joint ventures seem less objectionable to many. Allowing for changes to strings has been considered as well. - Include concerns about the private resolutions in the private auctions section. Seems like it needs to be all private resolutions are allowed or none are allowed. - Suggestion to pull the preliminary recommendation out of section (c). Prior to Jon's intervention, it seemed like that was the direction of the group previously. - Private auctions is a sub set of private resolutions. There may be some forms of private resolution that could be acceptable, while private auctions may indeed be the most problematic element. Action Item: leadership team to reevaluate how to organize section, given new issues raised by Jon. -- There is still a general sentiment that private auctions are problematic. From the chat: Anne Aikman-Scalese: QUESTION: If the award goes to a certain entity and if the entity changes, ICANN approval is needed, right? Does that reduce gaming in the suggested solutions? QUESTION Anne Aikman-Scalese: Its a question related to whether any system we devise could be easily "gamed". -- Change in entity prior to contract signing, additional due diligence is needed. After contract signing, due diligence needed as well. -- There are public comments to the Initial Report that may be of relevance to the supplemental report. Statistics on auctions from Rubens: From the chat: Rubens Kuhl: Michael, https://newgtlds.icann.org/en/program-status/statistics [newgtlds.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__newgtlds.icann.org_en_p...> has the numbers. Rubens Kuhl: Total Contention Sets 234 Rubens Kuhl: Resolved Contention Sets 226 Rubens Kuhl: Contention Sets Resolved via ICANN Auction 16 Rubens Kuhl: Unresolved Contention Sets 8 Rubens Kuhl: Applications Pending Contention Resolution 24 Michael Casadevall: Maybe it's just me, but I haven't heard much support for auctions in general, even as a public last resort. -- Options to auctions are provided, but there is an argument made in section 1.1 for the fairness of auctions. From the chat: Jim Prendergast: here is the Board comment on private auctions - Regarding question 2.7.4.e.2 on “gaming” or abuse of private auction, the Boardbelieves that applications should not be submitted as a means to engage in privateauctions, including for the purpose of using private auctions as a method of financingtheir other applications. This not only increases the workload on processing but putsundue financial pressure on other applicants who have business plans and financingbased on their intention to execute the plan described in the application. In particular, weare concerned about how gaming for the purpose of financing other applications, or withno intent to operate the gTLD as stated in the application, can be reconciled withICANN's Commitments and Core Values. Jon Nevett: Perhaps we should refer to private sales vs. private auctions? Section 1.3 -- No changes since last meeting. Section 1.4 -- Talks about change requests that may allow for contention resolution (e.g., joint ventures and string change). -- No changes since last meeting. - If in a contention set and you are able to choose another string, does it prevent choosing a string that puts you in another contention set? Action Item: Include language above. Section 1.5 -- Added elements about asking registrars for advice. - Is the intention to create a retail space for registry's that are failing? Are we interfering in the marketplace? Is ICANN acting as a regulator by serving in a registrar? Is there a compliance issue here as well? Action Item: Jim P to circulate text to strengthen section concerning elements above. Perhaps create a question. -- ICANN is not just regulating types of things, but it's also regulating how it's distributed. There is already manipulation of the market. From the chat: Jon Nevett: Jim +1 -- if a registry isn't getting sufficient registrar support, it could start its own - Some have noted challenges with starting a registrar, as well as challenges meet the requirements of the code of conduct, especially for smaller organizations. From the chat: Christopher Wilkinson: Section 1.5: just to recall that I hae already posted my comments to the List. Rubens Kuhl: Jon, that doesn't work in practice due to (1) high cost of registrar accreditation when used to sell a single TLD (2) registrants inertia or preferrence to use a single registrar/reseller for all their domain registrations. Michael Casadevall: I see Jim's point, but I have concerns that a registar may refuse to carry a gTLD for non-technical/non-financal reasons. I want to see Jim's comments before I dig in deeper though. Jon Nevett: in the 2005-8 policy debate on use of registrars, the key was that the protections required in the RAA are required for all registrations -- protections could be integrated into the Registry Agreement. From the chat: Rubens Kuhl: Michael, must-carry obligations were deemed to be over the top. So this doesn't seem to have much traction indeed. Jim Prendergast: Michael - do you envision a scenario where ICANN shoudl force a registrar to carry a TLD? --Everyone should review text, especially questions, options, etc. a. Draft of the additional Supplemental Report sections. - Jeff added additional context about why this supplemental report is being issued. Noted that public comments related to these subjects will not have been considered. -- Was there a Work Track involved in reviewing these issues? -- If relevant, the relevant section is cited in the sections. However, most topics are mostly new. -- When reviewing comments, will try to identify where those comments may be relevant to the supplemental report. 3. Initial assessment of work required for Final CCT-RT Report -- Overview of columns included in the document -- Recommendation 9: Reading through the What Else Needs to Be Done (final column)? -- Any objections to the approach suggested in this column? - no objections raised. -- Anne Aikman-Scalese - Submitted a question to the list about this document. On recommendation 9, the RPM process is not a PDP. It is a review. General question about recommendations coming out of reviews and how the WG is expected to address these. Please see comment/question on list. From the chat: Anne Aikman-Scalese: I sent questions to the list on this document. Anne Aikman-Scalese: RPM Review is not a PDP so the question relates to how results of mandated Reviews are considered procedurally. Same basic question applies to CCT-RT Review and relationship of those Recommendations to the PDP. There may be public comment on these questions - not sure. Jeff Neuman: The RPM Review is a PDP Jeff Neuman: It is charged with reviewing and making recommendations Jon Nevett: https://gnso.icann.org/sites/default/files/file/field-file-attach/projects-l... [gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_de...> Jon Nevett: cite to show it is a PDP -- This comment from Anne does not appear to be contrary to the comments in the "What Else Needs To Be Done?" Due to the overlapping nature of the charters, it will be necessary to take into account the work that this group has done. -- Recommendation 12: reading through "What Else Needs To Be Done?" -- There is a broader question about how this Working Group is required to consider the results of the reviews, including the CCT-RT. From the chat: Jeff Neuman: The CCT-RT is just advice to the Board -- Main takeway: WG members should look at the recommendations and look at the last column about what needs to be done from our perspective. -- This week on the leadership team call, the leadership team will give some thought on the approach to reviewing this documents and the CCT-RT recommendations. - At this stage the recommendations are recommendations to the Board and not the PDP, but if the Board asks the PDP how it is considering the reocmmendations, it would be helpful for the group to complete an initial review of the items directed at the PDP. From the chat: Anne Aikman-Scalese: Okay thanks for clarifying that Review reports are recommendations to the Board. My concern is sending differing recommendations from two different groups. If the Board has to resolve, that slows things down. - Clarification: It is not so much that the Board needs to resolve this. To complete the review, the Board will need to provide additional guidance about whether it accepts the recommendations. The Board will provide direction to the GNSO Council, which will direct the PDP. 4. AOB 4.1 Update on the Initial Report public comment review process - Public comments received on Intiial Report - public comment period closed on Wednesday. Close to 70 comments were received including from many of the SO/AC/SG/Cs, GDD, ICANN Board and a number of ccTLDs. - This is a large number of comments. There is a lot of work underway to organize and tabulate comments to support the WG's review of comments. -- Staff has created three Google Sheets that are similiar to the ones used for reviewing CC2. - There is one Google Doc per review SubTeam and one tab per topic area. Each preliminary recommendation, option, and question has a section within the sheet. - Where the specific preliminary recommendation, option, or question is referenced, this excerise is straightforward. Please check staff's categorization of the other comments. -- Goal is to have initial tabulation complete sometime next week, well in advance of ICANN63. Emily Barabas | Policy Manager ICANN | Internet Corporation for Assigned Names and Numbers Email: emily.barabas@icann.org<mailto:emily.barabas@icann.org> | Phone: +31 (0)6 84507976
I agree with Kristina on the RK4 comment below and note that this is now more than one WG member who has weighed in: [cid:image001.png@01D45A68.17300A70] I also agree with her Comment 10 shown below: [cid:image002.png@01D45A68.17300A70] Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image004.png@01D45A68.36FFF630] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 2000 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Rosette, Kristina via Gnso-newgtld-wg Sent: Tuesday, October 02, 2018 1:47 PM To: gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP Working Group - 2 October 2018 at 3:00 UTC All, Attached are my comments on the draft Supplemental Report. (I’ve come up for air from the EPDP WG long enough to get caught up on the transcripts for meetings I’ve missed – except for last night’s.) Please let me know if you have any questions. K Kristina Rosette Senior Corporate Counsel, IP – Domains rosettek@amazon.com<mailto:rosettek@amazon.com> | 703.407.1354 From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Emily Barabas Sent: Tuesday, October 02, 2018 5:51 AM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP Working Group - 2 October 2018 at 3:00 UTC Dear Working Group members, Please see below the notes from the meeting today, 2 October 2018. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/x/4QirBQ. Kind regards, Emily ---------------------------------------------------------------------------------------------------------- Notes and Action Items: 1. Agenda review/SOIs -- None 2. Supplemental Report: Review of sections 1.1, 1.2, 1.3, 1.4, and 1.5 continued -- Goal is to publish the report no later than 12 Oct 2018. -- Comments from several members sent to the list recently, not incorporated into the draft. -- The draft has captured all changes in a cumulative manner. Section 1.1 -- Changes include a potential limit to the number of auctions an applicant could participate in -- ICANN Board has concerns about private auctions -- Could the auction be front-loaded? At the time of application, applicant puts forth the maximum amount they would be willing to pay. If contested, winner is the highest bid, paying the second highest bid amount. Benefits include an accurate valuation to each of the participants, potentially. Would need an applicant support element integrated. Action Item: Sarah L to submit write-up of proposal described above. Rubens Kuhl: One of the challenges for those applying to more than 1 TLD, either 2 or an infinite number of them, is to submit maximum bids for each string, since if hey lose one, they have more resources to pay in another one. -- Do the losing bidders pay anything? Receive any benefit? -- Front-loading the auction flips the emphasis of the current auction of last resort. Would the mony need to go into escrow? Could be fairness issues as there may be subconscious biases related to the bid amouts. -- How would community applications be considered in this process? -- Sarah built off of Greg's idea to front-load contention resolution. Sealed price sealed bid auction. Funds collected should go to public benefit. The highest bidder goes through the initial evaluation process, paying the second highest bid. From the chat: Anne Aikman-Scalese: COMMENT: The way to resolve that may be give Community applicants a priority round. Then you are only resolving contention among community applicants. Then in the general round, the bid could be a "silent auction". COMMENT Michael Casadevall: COMMENT: I can see a tie. Two companies bidding the same nice round number. - When would evaluators know the highest bidder, if ever? It seems like in the beginning, as that seems to drive the evaluation order of the contention set. -- Add additional text as suggested by Anne Aikman-Scalese via email, at the end of the second paragraph. Section 1.2 - Unsure of why emphasis is only on private auctions. Is the issue more about the parties that did not win the string are ending up getting paid off? Are other private resolutions problematic as well? Could result in every contention set ending up in auction. It would be odd to ban private auctions, but not other private resolution methods. From the chat: Rubens Kuhl: Curiously, people seem to be in favor of private resolution by constituing joint-ventures. Rubens Kuhl: But Jon is right, you can't have the cake and eat it too. Michael Casadevall: Well, forming a JV is somewhat different since it's "everyone wins" Jim Prendergast: ff memory serves correct - I think the suggestion for a determination draw was to replace both private auction and ICANN last resort auction Michael Casadevall: It should be noted that banning private resolutions except X is an option. Rubens Kuhl: I can sell shares in a JV for the highest bidder. Justine Chew: Correct, we need to be clear on what should be encouraged vs discouraged (or disallowed). Rubens Kuhl: There's no way to implement such discretionary approach to private resolutions. It's all or nothing. -- Joint ventures seem less objectionable to many. Allowing for changes to strings has been considered as well. - Include concerns about the private resolutions in the private auctions section. Seems like it needs to be all private resolutions are allowed or none are allowed. - Suggestion to pull the preliminary recommendation out of section (c). Prior to Jon's intervention, it seemed like that was the direction of the group previously. - Private auctions is a sub set of private resolutions. There may be some forms of private resolution that could be acceptable, while private auctions may indeed be the most problematic element. Action Item: leadership team to reevaluate how to organize section, given new issues raised by Jon. -- There is still a general sentiment that private auctions are problematic. From the chat: Anne Aikman-Scalese: QUESTION: If the award goes to a certain entity and if the entity changes, ICANN approval is needed, right? Does that reduce gaming in the suggested solutions? QUESTION Anne Aikman-Scalese: Its a question related to whether any system we devise could be easily "gamed". -- Change in entity prior to contract signing, additional due diligence is needed. After contract signing, due diligence needed as well. -- There are public comments to the Initial Report that may be of relevance to the supplemental report. Statistics on auctions from Rubens: From the chat: Rubens Kuhl: Michael, https://newgtlds.icann.org/en/program-status/statistics [newgtlds.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__newgtlds.icann.org_en_p...> has the numbers. Rubens Kuhl: Total Contention Sets 234 Rubens Kuhl: Resolved Contention Sets 226 Rubens Kuhl: Contention Sets Resolved via ICANN Auction 16 Rubens Kuhl: Unresolved Contention Sets 8 Rubens Kuhl: Applications Pending Contention Resolution 24 Michael Casadevall: Maybe it's just me, but I haven't heard much support for auctions in general, even as a public last resort. -- Options to auctions are provided, but there is an argument made in section 1.1 for the fairness of auctions. From the chat: Jim Prendergast: here is the Board comment on private auctions - Regarding question 2.7.4.e.2 on “gaming” or abuse of private auction, the Boardbelieves that applications should not be submitted as a means to engage in privateauctions, including for the purpose of using private auctions as a method of financingtheir other applications. This not only increases the workload on processing but putsundue financial pressure on other applicants who have business plans and financingbased on their intention to execute the plan described in the application. In particular, weare concerned about how gaming for the purpose of financing other applications, or withno intent to operate the gTLD as stated in the application, can be reconciled withICANN's Commitments and Core Values. Jon Nevett: Perhaps we should refer to private sales vs. private auctions? Section 1.3 -- No changes since last meeting. Section 1.4 -- Talks about change requests that may allow for contention resolution (e.g., joint ventures and string change). -- No changes since last meeting. - If in a contention set and you are able to choose another string, does it prevent choosing a string that puts you in another contention set? Action Item: Include language above. Section 1.5 -- Added elements about asking registrars for advice. - Is the intention to create a retail space for registry's that are failing? Are we interfering in the marketplace? Is ICANN acting as a regulator by serving in a registrar? Is there a compliance issue here as well? Action Item: Jim P to circulate text to strengthen section concerning elements above. Perhaps create a question. -- ICANN is not just regulating types of things, but it's also regulating how it's distributed. There is already manipulation of the market. From the chat: Jon Nevett: Jim +1 -- if a registry isn't getting sufficient registrar support, it could start its own - Some have noted challenges with starting a registrar, as well as challenges meet the requirements of the code of conduct, especially for smaller organizations. From the chat: Christopher Wilkinson: Section 1.5: just to recall that I hae already posted my comments to the List. Rubens Kuhl: Jon, that doesn't work in practice due to (1) high cost of registrar accreditation when used to sell a single TLD (2) registrants inertia or preferrence to use a single registrar/reseller for all their domain registrations. Michael Casadevall: I see Jim's point, but I have concerns that a registar may refuse to carry a gTLD for non-technical/non-financal reasons. I want to see Jim's comments before I dig in deeper though. Jon Nevett: in the 2005-8 policy debate on use of registrars, the key was that the protections required in the RAA are required for all registrations -- protections could be integrated into the Registry Agreement. From the chat: Rubens Kuhl: Michael, must-carry obligations were deemed to be over the top. So this doesn't seem to have much traction indeed. Jim Prendergast: Michael - do you envision a scenario where ICANN shoudl force a registrar to carry a TLD? --Everyone should review text, especially questions, options, etc. a. Draft of the additional Supplemental Report sections. - Jeff added additional context about why this supplemental report is being issued. Noted that public comments related to these subjects will not have been considered. -- Was there a Work Track involved in reviewing these issues? -- If relevant, the relevant section is cited in the sections. However, most topics are mostly new. -- When reviewing comments, will try to identify where those comments may be relevant to the supplemental report. 3. Initial assessment of work required for Final CCT-RT Report -- Overview of columns included in the document -- Recommendation 9: Reading through the What Else Needs to Be Done (final column)? -- Any objections to the approach suggested in this column? - no objections raised. -- Anne Aikman-Scalese - Submitted a question to the list about this document. On recommendation 9, the RPM process is not a PDP. It is a review. General question about recommendations coming out of reviews and how the WG is expected to address these. Please see comment/question on list. From the chat: Anne Aikman-Scalese: I sent questions to the list on this document. Anne Aikman-Scalese: RPM Review is not a PDP so the question relates to how results of mandated Reviews are considered procedurally. Same basic question applies to CCT-RT Review and relationship of those Recommendations to the PDP. There may be public comment on these questions - not sure. Jeff Neuman: The RPM Review is a PDP Jeff Neuman: It is charged with reviewing and making recommendations Jon Nevett: https://gnso.icann.org/sites/default/files/file/field-file-attach/projects-l... [gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_de...> Jon Nevett: cite to show it is a PDP -- This comment from Anne does not appear to be contrary to the comments in the "What Else Needs To Be Done?" Due to the overlapping nature of the charters, it will be necessary to take into account the work that this group has done. -- Recommendation 12: reading through "What Else Needs To Be Done?" -- There is a broader question about how this Working Group is required to consider the results of the reviews, including the CCT-RT. From the chat: Jeff Neuman: The CCT-RT is just advice to the Board -- Main takeway: WG members should look at the recommendations and look at the last column about what needs to be done from our perspective. -- This week on the leadership team call, the leadership team will give some thought on the approach to reviewing this documents and the CCT-RT recommendations. - At this stage the recommendations are recommendations to the Board and not the PDP, but if the Board asks the PDP how it is considering the reocmmendations, it would be helpful for the group to complete an initial review of the items directed at the PDP. From the chat: Anne Aikman-Scalese: Okay thanks for clarifying that Review reports are recommendations to the Board. My concern is sending differing recommendations from two different groups. If the Board has to resolve, that slows things down. - Clarification: It is not so much that the Board needs to resolve this. To complete the review, the Board will need to provide additional guidance about whether it accepts the recommendations. The Board will provide direction to the GNSO Council, which will direct the PDP. 4. AOB 4.1 Update on the Initial Report public comment review process - Public comments received on Intiial Report - public comment period closed on Wednesday. Close to 70 comments were received including from many of the SO/AC/SG/Cs, GDD, ICANN Board and a number of ccTLDs. - This is a large number of comments. There is a lot of work underway to organize and tabulate comments to support the WG's review of comments. -- Staff has created three Google Sheets that are similiar to the ones used for reviewing CC2. - There is one Google Doc per review SubTeam and one tab per topic area. Each preliminary recommendation, option, and question has a section within the sheet. - Where the specific preliminary recommendation, option, or question is referenced, this excerise is straightforward. Please check staff's categorization of the other comments. -- Goal is to have initial tabulation complete sometime next week, well in advance of ICANN63. Emily Barabas | Policy Manager ICANN | Internet Corporation for Assigned Names and Numbers Email: emily.barabas@icann.org<mailto:emily.barabas@icann.org> | Phone: +31 (0)6 84507976 ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
Good afternoon: What exactly do you mean by Freedom of Speech? I understand that at the Second or Third Level, but in a TLD itself? Presumably a new gTLD is not going to 'filter' applications for domains on the basis of whatever 'speech' is required or permitted, I don't understand what you are getting at. In any event, how can this PDP's view of generic EN TLDs translate into other cultures and languages which may have a different conception of Freedom of Speech? Thanks and Regards CW
El 3 de octubre de 2018 a las 0:54 "Aikman-Scalese, Anne" <AAikman@lrrc.com> escribió:
I agree with Kristina on the RK4 comment below and note that this is now more than one WG member who has weighed in:
I also agree with her Comment 10 shown below:
Anne E. Aikman-Scalese
Of Counsel
520.629.4428 office
520.879.4725 fax
AAikman@lrrc.com mailto:AAikman@lrrc.com
_____________________________
Lewis Roca Rothgerber Christie LLP
One South Church Avenue, Suite 2000
Tucson, Arizona 85701-1611
lrrc.com http://lrrc.com/
From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Rosette, Kristina via Gnso-newgtld-wg Sent: Tuesday, October 02, 2018 1:47 PM To: gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP Working Group - 2 October 2018 at 3:00 UTC
All,
Attached are my comments on the draft Supplemental Report. (I’ve come up for air from the EPDP WG long enough to get caught up on the transcripts for meetings I’ve missed – except for last night’s.)
Please let me know if you have any questions.
K
Kristina Rosette
Senior Corporate Counsel, IP – Domains
rosettek@amazon.com mailto:rosettek@amazon.com | 703.407.1354
From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Emily Barabas Sent: Tuesday, October 02, 2018 5:51 AM To: gnso-newgtld-wg@icann.org mailto:gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP Working Group - 2 October 2018 at 3:00 UTC
Dear Working Group members,
Please see below the notes from the meeting today, 2 October 2018. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/x/4QirBQ.
Kind regards,
Emily
----------------------------------------------------------------------------------------------------------
Notes and Action Items:
1. Agenda review/SOIs
-- None
2. Supplemental Report: Review of sections 1.1, 1.2, 1.3, 1.4, and 1.5 continued
-- Goal is to publish the report no later than 12 Oct 2018.
-- Comments from several members sent to the list recently, not incorporated into the draft.
-- The draft has captured all changes in a cumulative manner.
Section 1.1
-- Changes include a potential limit to the number of auctions an applicant could participate in
-- ICANN Board has concerns about private auctions
-- Could the auction be front-loaded? At the time of application, applicant puts forth the maximum amount they would be willing to pay. If contested, winner is the highest bid, paying the second highest bid amount. Benefits include an accurate valuation to each of the participants, potentially. Would need an applicant support element integrated.
Action Item: Sarah L to submit write-up of proposal described above.
Rubens Kuhl: One of the challenges for those applying to more than 1 TLD, either 2 or an infinite number of them, is to submit maximum bids for each string, since if hey lose one, they have more resources to pay in another one.
-- Do the losing bidders pay anything? Receive any benefit?
-- Front-loading the auction flips the emphasis of the current auction of last resort. Would the mony need to go into escrow? Could be fairness issues as there may be subconscious biases related to the bid amouts.
-- How would community applications be considered in this process?
-- Sarah built off of Greg's idea to front-load contention resolution. Sealed price sealed bid auction. Funds collected should go to public benefit. The highest bidder goes through the initial evaluation process, paying the second highest bid.
From the chat:
Anne Aikman-Scalese: COMMENT: The way to resolve that may be give Community applicants a priority round. Then you are only resolving contention among community applicants. Then in the general round, the bid could be a "silent auction". COMMENT
Michael Casadevall: COMMENT: I can see a tie. Two companies bidding the same nice round number.
- When would evaluators know the highest bidder, if ever? It seems like in the beginning, as that seems to drive the evaluation order of the contention set.
-- Add additional text as suggested by Anne Aikman-Scalese via email, at the end of the second paragraph.
Section 1.2
- Unsure of why emphasis is only on private auctions. Is the issue more about the parties that did not win the string are ending up getting paid off? Are other private resolutions problematic as well? Could result in every contention set ending up in auction. It would be odd to ban private auctions, but not other private resolution methods.
From the chat:
Rubens Kuhl: Curiously, people seem to be in favor of private resolution by constituing joint-ventures.
Rubens Kuhl: But Jon is right, you can't have the cake and eat it too.
Michael Casadevall: Well, forming a JV is somewhat different since it's "everyone wins"
Jim Prendergast: ff memory serves correct - I think the suggestion for a determination draw was to replace both private auction and ICANN last resort auction
Michael Casadevall: It should be noted that banning private resolutions except X is an option.
Rubens Kuhl: I can sell shares in a JV for the highest bidder.
Justine Chew: Correct, we need to be clear on what should be encouraged vs discouraged (or disallowed).
Rubens Kuhl: There's no way to implement such discretionary approach to private resolutions. It's all or nothing.
-- Joint ventures seem less objectionable to many. Allowing for changes to strings has been considered as well.
- Include concerns about the private resolutions in the private auctions section. Seems like it needs to be all private resolutions are allowed or none are allowed.
- Suggestion to pull the preliminary recommendation out of section (c). Prior to Jon's intervention, it seemed like that was the direction of the group previously.
- Private auctions is a sub set of private resolutions. There may be some forms of private resolution that could be acceptable, while private auctions may indeed be the most problematic element.
Action Item: leadership team to reevaluate how to organize section, given new issues raised by Jon.
-- There is still a general sentiment that private auctions are problematic.
From the chat:
Anne Aikman-Scalese: QUESTION: If the award goes to a certain entity and if the entity changes, ICANN approval is needed, right? Does that reduce gaming in the suggested solutions? QUESTION
Anne Aikman-Scalese: Its a question related to whether any system we devise could be easily "gamed".
-- Change in entity prior to contract signing, additional due diligence is needed. After contract signing, due diligence needed as well.
-- There are public comments to the Initial Report that may be of relevance to the supplemental report.
Statistics on auctions from Rubens:
From the chat:
Rubens Kuhl: Michael, https://newgtlds.icann.org/en/program-status/statistics [newgtlds.icann.org] https://urldefense.proofpoint.com/v2/url?u=https-3A__newgtlds.icann.org_en_p... has the numbers.
Rubens Kuhl: Total Contention Sets 234
Rubens Kuhl: Resolved Contention Sets 226
Rubens Kuhl: Contention Sets Resolved via ICANN Auction 16
Rubens Kuhl: Unresolved Contention Sets 8
Rubens Kuhl: Applications Pending Contention Resolution 24
Michael Casadevall: Maybe it's just me, but I haven't heard much support for auctions in general, even as a public last resort.
-- Options to auctions are provided, but there is an argument made in section 1.1 for the fairness of auctions.
From the chat:
Jim Prendergast: here is the Board comment on private auctions - Regarding question 2.7.4.e.2 on “gaming” or abuse of private auction, the Boardbelieves that applications should not be submitted as a means to engage in privateauctions, including for the purpose of using private auctions as a method of financingtheir other applications. This not only increases the workload on processing but putsundue financial pressure on other applicants who have business plans and financingbased on their intention to execute the plan described in the application. In particular, weare concerned about how gaming for the purpose of financing other applications, or withno intent to operate the gTLD as stated in the application, can be reconciled withICANN's Commitments and Core Values.
Jon Nevett: Perhaps we should refer to private sales vs. private auctions?
Section 1.3
-- No changes since last meeting.
Section 1.4
-- Talks about change requests that may allow for contention resolution (e.g., joint ventures and string change).
-- No changes since last meeting.
- If in a contention set and you are able to choose another string, does it prevent choosing a string that puts you in another contention set?
Action Item: Include language above.
Section 1.5
-- Added elements about asking registrars for advice.
- Is the intention to create a retail space for registry's that are failing? Are we interfering in the marketplace? Is ICANN acting as a regulator by serving in a registrar? Is there a compliance issue here as well?
Action Item: Jim P to circulate text to strengthen section concerning elements above. Perhaps create a question.
-- ICANN is not just regulating types of things, but it's also regulating how it's distributed. There is already manipulation of the market.
From the chat:
Jon Nevett: Jim +1 -- if a registry isn't getting sufficient registrar support, it could start its own
- Some have noted challenges with starting a registrar, as well as challenges meet the requirements of the code of conduct, especially for smaller organizations.
From the chat:
Christopher Wilkinson: Section 1.5: just to recall that I hae already posted my comments to the List.
Rubens Kuhl: Jon, that doesn't work in practice due to (1) high cost of registrar accreditation when used to sell a single TLD (2) registrants inertia or preferrence to use a single registrar/reseller for all their domain registrations.
Michael Casadevall: I see Jim's point, but I have concerns that a registar may refuse to carry a gTLD for non-technical/non-financal reasons. I want to see Jim's comments before I dig in deeper though.
Jon Nevett: in the 2005-8 policy debate on use of registrars, the key was that the protections required in the RAA are required for all registrations
-- protections could be integrated into the Registry Agreement.
From the chat:
Rubens Kuhl: Michael, must-carry obligations were deemed to be over the top. So this doesn't seem to have much traction indeed.
Jim Prendergast: Michael - do you envision a scenario where ICANN shoudl force a registrar to carry a TLD?
--Everyone should review text, especially questions, options, etc.
a. Draft of the additional Supplemental Report sections.
- Jeff added additional context about why this supplemental report is being issued. Noted that public comments related to these subjects will not have been considered.
-- Was there a Work Track involved in reviewing these issues?
-- If relevant, the relevant section is cited in the sections. However, most topics are mostly new.
-- When reviewing comments, will try to identify where those comments may be relevant to the supplemental report.
3. Initial assessment of work required for Final CCT-RT Report
-- Overview of columns included in the document
-- Recommendation 9: Reading through the What Else Needs to Be Done (final column)?
-- Any objections to the approach suggested in this column? - no objections raised.
-- Anne Aikman-Scalese - Submitted a question to the list about this document. On recommendation 9, the RPM process is not a PDP. It is a review. General question about recommendations coming out of reviews and how the WG is expected to address these. Please see comment/question on list.
From the chat: Anne Aikman-Scalese: I sent questions to the list on this document. Anne Aikman-Scalese: RPM Review is not a PDP so the question relates to how results of mandated Reviews are considered procedurally. Same basic question applies to CCT-RT Review and relationship of those Recommendations to the PDP. There may be public comment on these questions - not sure. Jeff Neuman: The RPM Review is a PDP Jeff Neuman: It is charged with reviewing and making recommendations Jon Nevett: https://gnso.icann.org/sites/default/files/file/field-file-attach/projects-l... [gnso.icann.org] https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_de... Jon Nevett: cite to show it is a PDP
-- This comment from Anne does not appear to be contrary to the comments in the "What Else Needs To Be Done?" Due to the overlapping nature of the charters, it will be necessary to take into account the work that this group has done. -- Recommendation 12: reading through "What Else Needs To Be Done?" -- There is a broader question about how this Working Group is required to consider the results of the reviews, including the CCT-RT.
From the chat: Jeff Neuman: The CCT-RT is just advice to the Board
-- Main takeway: WG members should look at the recommendations and look at the last column about what needs to be done from our perspective. -- This week on the leadership team call, the leadership team will give some thought on the approach to reviewing this documents and the CCT-RT recommendations. - At this stage the recommendations are recommendations to the Board and not the PDP, but if the Board asks the PDP how it is considering the reocmmendations, it would be helpful for the group to complete an initial review of the items directed at the PDP.
From the chat: Anne Aikman-Scalese: Okay thanks for clarifying that Review reports are recommendations to the Board. My concern is sending differing recommendations from two different groups. If the Board has to resolve, that slows things down.
- Clarification: It is not so much that the Board needs to resolve this. To complete the review, the Board will need to provide additional guidance about whether it accepts the recommendations. The Board will provide direction to the GNSO Council, which will direct the PDP.
4. AOB
4.1 Update on the Initial Report public comment review process
- Public comments received on Intiial Report - public comment period closed on Wednesday. Close to 70 comments were received including from many of the SO/AC/SG/Cs, GDD, ICANN Board and a number of ccTLDs.
- This is a large number of comments. There is a lot of work underway to organize and tabulate comments to support the WG's review of comments.
-- Staff has created three Google Sheets that are similiar to the ones used for reviewing CC2.
- There is one Google Doc per review SubTeam and one tab per topic area. Each preliminary recommendation, option, and question has a section within the sheet.
- Where the specific preliminary recommendation, option, or question is referenced, this excerise is straightforward. Please check staff's categorization of the other comments.
-- Goal is to have initial tabulation complete sometime next week, well in advance of ICANN63.
Emily Barabas | Policy Manager
ICANN | Internet Corporation for Assigned Names and Numbers
Email: emily.barabas@icann.org mailto:emily.barabas@icann.org | Phone: +31 (0)6 84507976
---------------------------------------------
This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
_______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg
Christopher, Applicant Freedom of Expression was a guiding Principle of the new gTLD program. This has been discussed at length in Work Track 3. I’m not sure which Subgroup you are joining but this Principle has come up in relation to Objection Procedures for new gTLD applications and also in relation to the definition of “community” in Community Applications. Some in Work Track 3, notably the leaders I think, want to exclude economic communities from the definition of community. In connection with TLD applications, Freedom of Expression is especially important in Community Applications. This is true whether we see the particular community as “good” or “bad”. (I’m sure King George saw the US revolutionaries as a “bad” community.) I’m also sure there are repressive governments that may see .lesbian as a “bad” community. There are some within ICANN who see economic communities or corporate communities as “bad” in terms of giving them community status. These are not value judgments that ICANN should be making and Kristina points out that judging content is outside ICANN’s Mission and By-Laws. We have asked some questions about this in the Initial Report and this Supplemental Report poses the same concerns. I think everyone acknowledges that freedom of speech and expression are not acknowledged in every country and are not acknowledged in the same way in countries where these rights are supposedly guaranteed, even if the countries signed on to the UN Convention and the EU Human Rights Convention and Charter of Fundamental Rights. Witness what the Spanish government did at the .cat office - http://fortune.com/2017/09/23/spanish-dot-cat-domain-name/ I certainly find some of the definitions of “illegal speech” quite disturbing in terms of where they may lead. According to Voltaire’s oft-quoted statement (after a book-burning incident), Monsieur l’abbé, je déteste ce que vous écrivez, mais je donnerai ma vie pour que vous puissiez continuer à écrire. Or – slang translation: “I detest what you write, but will defend unto death your right to continue to write.” Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image001.png@01D45B16.91DC2980] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 2000 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: lists@christopherwilkinson.eu Wilkinson [mailto:lists@christopherwilkinson.eu] Sent: Wednesday, October 03, 2018 9:41 AM To: Aikman-Scalese, Anne; Rosette, Kristina Cc: gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP Working Group - 2 October 2018 at 3:00 UTC Good afternoon: What exactly do you mean by Freedom of Speech? I understand that at the Second or Third Level, but in a TLD itself? Presumably a new gTLD is not going to 'filter' applications for domains on the basis of whatever 'speech' is required or permitted, I don't understand what you are getting at. In any event, how can this PDP's view of generic EN TLDs translate into other cultures and languages which may have a different conception of Freedom of Speech? Thanks and Regards CW El 3 de octubre de 2018 a las 0:54 "Aikman-Scalese, Anne" <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> escribió: I agree with Kristina on the RK4 comment below and note that this is now more than one WG member who has weighed in: [cid:image006.png@01D45B10.A22EFDE0] I also agree with her Comment 10 shown below: [cid:image007.png@01D45B10.A22EFDE0] Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image008.png@01D45B10.A22EFDE0] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 2000 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Rosette, Kristina via Gnso-newgtld-wg Sent: Tuesday, October 02, 2018 1:47 PM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP Working Group - 2 October 2018 at 3:00 UTC All, Attached are my comments on the draft Supplemental Report. (I’ve come up for air from the EPDP WG long enough to get caught up on the transcripts for meetings I’ve missed – except for last night’s.) Please let me know if you have any questions. K Kristina Rosette Senior Corporate Counsel, IP – Domains rosettek@amazon.com<mailto:rosettek@amazon.com> | 703.407.1354 From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Emily Barabas Sent: Tuesday, October 02, 2018 5:51 AM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP Working Group - 2 October 2018 at 3:00 UTC Dear Working Group members, Please see below the notes from the meeting today, 2 October 2018. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/x/4QirBQ. Kind regards, Emily ---------------------------------------------------------------------------------------------------------- Notes and Action Items: 1. Agenda review/SOIs -- None 2. Supplemental Report: Review of sections 1.1, 1.2, 1.3, 1.4, and 1.5 continued -- Goal is to publish the report no later than 12 Oct 2018. -- Comments from several members sent to the list recently, not incorporated into the draft. -- The draft has captured all changes in a cumulative manner. Section 1.1 -- Changes include a potential limit to the number of auctions an applicant could participate in -- ICANN Board has concerns about private auctions -- Could the auction be front-loaded? At the time of application, applicant puts forth the maximum amount they would be willing to pay. If contested, winner is the highest bid, paying the second highest bid amount. Benefits include an accurate valuation to each of the participants, potentially. Would need an applicant support element integrated. Action Item: Sarah L to submit write-up of proposal described above. Rubens Kuhl: One of the challenges for those applying to more than 1 TLD, either 2 or an infinite number of them, is to submit maximum bids for each string, since if hey lose one, they have more resources to pay in another one. -- Do the losing bidders pay anything? Receive any benefit? -- Front-loading the auction flips the emphasis of the current auction of last resort. Would the mony need to go into escrow? Could be fairness issues as there may be subconscious biases related to the bid amouts. -- How would community applications be considered in this process? -- Sarah built off of Greg's idea to front-load contention resolution. Sealed price sealed bid auction. Funds collected should go to public benefit. The highest bidder goes through the initial evaluation process, paying the second highest bid. From the chat: Anne Aikman-Scalese: COMMENT: The way to resolve that may be give Community applicants a priority round. Then you are only resolving contention among community applicants. Then in the general round, the bid could be a "silent auction". COMMENT Michael Casadevall: COMMENT: I can see a tie. Two companies bidding the same nice round number. - When would evaluators know the highest bidder, if ever? It seems like in the beginning, as that seems to drive the evaluation order of the contention set. -- Add additional text as suggested by Anne Aikman-Scalese via email, at the end of the second paragraph. Section 1.2 - Unsure of why emphasis is only on private auctions. Is the issue more about the parties that did not win the string are ending up getting paid off? Are other private resolutions problematic as well? Could result in every contention set ending up in auction. It would be odd to ban private auctions, but not other private resolution methods. From the chat: Rubens Kuhl: Curiously, people seem to be in favor of private resolution by constituing joint-ventures. Rubens Kuhl: But Jon is right, you can't have the cake and eat it too. Michael Casadevall: Well, forming a JV is somewhat different since it's "everyone wins" Jim Prendergast: ff memory serves correct - I think the suggestion for a determination draw was to replace both private auction and ICANN last resort auction Michael Casadevall: It should be noted that banning private resolutions except X is an option. Rubens Kuhl: I can sell shares in a JV for the highest bidder. Justine Chew: Correct, we need to be clear on what should be encouraged vs discouraged (or disallowed). Rubens Kuhl: There's no way to implement such discretionary approach to private resolutions. It's all or nothing. -- Joint ventures seem less objectionable to many. Allowing for changes to strings has been considered as well. - Include concerns about the private resolutions in the private auctions section. Seems like it needs to be all private resolutions are allowed or none are allowed. - Suggestion to pull the preliminary recommendation out of section (c). Prior to Jon's intervention, it seemed like that was the direction of the group previously. - Private auctions is a sub set of private resolutions. There may be some forms of private resolution that could be acceptable, while private auctions may indeed be the most problematic element. Action Item: leadership team to reevaluate how to organize section, given new issues raised by Jon. -- There is still a general sentiment that private auctions are problematic. From the chat: Anne Aikman-Scalese: QUESTION: If the award goes to a certain entity and if the entity changes, ICANN approval is needed, right? Does that reduce gaming in the suggested solutions? QUESTION Anne Aikman-Scalese: Its a question related to whether any system we devise could be easily "gamed". -- Change in entity prior to contract signing, additional due diligence is needed. After contract signing, due diligence needed as well. -- There are public comments to the Initial Report that may be of relevance to the supplemental report. Statistics on auctions from Rubens: From the chat: Rubens Kuhl: Michael, https://newgtlds.icann.org/en/program-status/statistics [newgtlds.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__newgtlds.icann.org_en_p...> has the numbers. Rubens Kuhl: Total Contention Sets 234 Rubens Kuhl: Resolved Contention Sets 226 Rubens Kuhl: Contention Sets Resolved via ICANN Auction 16 Rubens Kuhl: Unresolved Contention Sets 8 Rubens Kuhl: Applications Pending Contention Resolution 24 Michael Casadevall: Maybe it's just me, but I haven't heard much support for auctions in general, even as a public last resort. -- Options to auctions are provided, but there is an argument made in section 1.1 for the fairness of auctions. From the chat: Jim Prendergast: here is the Board comment on private auctions - Regarding question 2.7.4.e.2 on “gaming” or abuse of private auction, the Boardbelieves that applications should not be submitted as a means to engage in privateauctions, including for the purpose of using private auctions as a method of financingtheir other applications. This not only increases the workload on processing but putsundue financial pressure on other applicants who have business plans and financingbased on their intention to execute the plan described in the application. In particular, weare concerned about how gaming for the purpose of financing other applications, or withno intent to operate the gTLD as stated in the application, can be reconciled withICANN's Commitments and Core Values. Jon Nevett: Perhaps we should refer to private sales vs. private auctions? Section 1.3 -- No changes since last meeting. Section 1.4 -- Talks about change requests that may allow for contention resolution (e.g., joint ventures and string change). -- No changes since last meeting. - If in a contention set and you are able to choose another string, does it prevent choosing a string that puts you in another contention set? Action Item: Include language above. Section 1.5 -- Added elements about asking registrars for advice. - Is the intention to create a retail space for registry's that are failing? Are we interfering in the marketplace? Is ICANN acting as a regulator by serving in a registrar? Is there a compliance issue here as well? Action Item: Jim P to circulate text to strengthen section concerning elements above. Perhaps create a question. -- ICANN is not just regulating types of things, but it's also regulating how it's distributed. There is already manipulation of the market. From the chat: Jon Nevett: Jim +1 -- if a registry isn't getting sufficient registrar support, it could start its own - Some have noted challenges with starting a registrar, as well as challenges meet the requirements of the code of conduct, especially for smaller organizations. From the chat: Christopher Wilkinson: Section 1.5: just to recall that I hae already posted my comments to the List. Rubens Kuhl: Jon, that doesn't work in practice due to (1) high cost of registrar accreditation when used to sell a single TLD (2) registrants inertia or preferrence to use a single registrar/reseller for all their domain registrations. Michael Casadevall: I see Jim's point, but I have concerns that a registar may refuse to carry a gTLD for non-technical/non-financal reasons. I want to see Jim's comments before I dig in deeper though. Jon Nevett: in the 2005-8 policy debate on use of registrars, the key was that the protections required in the RAA are required for all registrations -- protections could be integrated into the Registry Agreement. From the chat: Rubens Kuhl: Michael, must-carry obligations were deemed to be over the top. So this doesn't seem to have much traction indeed. Jim Prendergast: Michael - do you envision a scenario where ICANN shoudl force a registrar to carry a TLD? --Everyone should review text, especially questions, options, etc. a. Draft of the additional Supplemental Report sections. - Jeff added additional context about why this supplemental report is being issued. Noted that public comments related to these subjects will not have been considered. -- Was there a Work Track involved in reviewing these issues? -- If relevant, the relevant section is cited in the sections. However, most topics are mostly new. -- When reviewing comments, will try to identify where those comments may be relevant to the supplemental report. 3. Initial assessment of work required for Final CCT-RT Report -- Overview of columns included in the document -- Recommendation 9: Reading through the What Else Needs to Be Done (final column)? -- Any objections to the approach suggested in this column? - no objections raised. -- Anne Aikman-Scalese - Submitted a question to the list about this document. On recommendation 9, the RPM process is not a PDP. It is a review. General question about recommendations coming out of reviews and how the WG is expected to address these. Please see comment/question on list. From the chat: Anne Aikman-Scalese: I sent questions to the list on this document. Anne Aikman-Scalese: RPM Review is not a PDP so the question relates to how results of mandated Reviews are considered procedurally. Same basic question applies to CCT-RT Review and relationship of those Recommendations to the PDP. There may be public comment on these questions - not sure. Jeff Neuman: The RPM Review is a PDP Jeff Neuman: It is charged with reviewing and making recommendations Jon Nevett: https://gnso.icann.org/sites/default/files/file/field-file-attach/projects-l... [gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_de...> Jon Nevett: cite to show it is a PDP -- This comment from Anne does not appear to be contrary to the comments in the "What Else Needs To Be Done?" Due to the overlapping nature of the charters, it will be necessary to take into account the work that this group has done. -- Recommendation 12: reading through "What Else Needs To Be Done?" -- There is a broader question about how this Working Group is required to consider the results of the reviews, including the CCT-RT. From the chat: Jeff Neuman: The CCT-RT is just advice to the Board -- Main takeway: WG members should look at the recommendations and look at the last column about what needs to be done from our perspective. -- This week on the leadership team call, the leadership team will give some thought on the approach to reviewing this documents and the CCT-RT recommendations. - At this stage the recommendations are recommendations to the Board and not the PDP, but if the Board asks the PDP how it is considering the reocmmendations, it would be helpful for the group to complete an initial review of the items directed at the PDP. From the chat: Anne Aikman-Scalese: Okay thanks for clarifying that Review reports are recommendations to the Board. My concern is sending differing recommendations from two different groups. If the Board has to resolve, that slows things down. - Clarification: It is not so much that the Board needs to resolve this. To complete the review, the Board will need to provide additional guidance about whether it accepts the recommendations. The Board will provide direction to the GNSO Council, which will direct the PDP. 4. AOB 4.1 Update on the Initial Report public comment review process - Public comments received on Intiial Report - public comment period closed on Wednesday. Close to 70 comments were received including from many of the SO/AC/SG/Cs, GDD, ICANN Board and a number of ccTLDs. - This is a large number of comments. There is a lot of work underway to organize and tabulate comments to support the WG's review of comments. -- Staff has created three Google Sheets that are similiar to the ones used for reviewing CC2. - There is one Google Doc per review SubTeam and one tab per topic area. Each preliminary recommendation, option, and question has a section within the sheet. - Where the specific preliminary recommendation, option, or question is referenced, this excerise is straightforward. Please check staff's categorization of the other comments. -- Goal is to have initial tabulation complete sometime next week, well in advance of ICANN63. Emily Barabas | Policy Manager ICANN | Internet Corporation for Assigned Names and Numbers Email: emily.barabas@icann.org<mailto:emily.barabas@icann.org> | Phone: +31 (0)6 84507976 ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521. _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org<mailto:Gnso-newgtld-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
I agree that ICANN risks being violation of its bylaws if it regulates content (geographic words). Freedom of expression is an important principle of the gtld program -- Principle G of the policy explicitly states that applicants' freedom of expression rights shall be protected. Regulating words with geographic meaning violates Principle G, ICANN’s bylaws, and the free expression guarantees in international treaties, such as Article 19 of UNDHR which guarantees "the right to seek, receive, and impart information and ideas in any medium and regardless of frontiers.” ICANN cannot just ignore these legal obligations because a segment of the community wants to regulate those words and control the flow of information and ideas. Robin
On Oct 2, 2018, at 3:54 PM, Aikman-Scalese, Anne <AAikman@lrrc.com> wrote:
I agree with Kristina on the RK4 comment below and note that this is now more than one WG member who has weighed in:
<image001.png>
I also agree with her Comment 10 shown below:
<image002.png>
Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com <mailto:AAikman@lrrc.com> _____________________________ <image004.png> Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 2000 Tucson, Arizona 85701-1611 lrrc.com <http://lrrc.com/>
From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org <mailto:gnso-newgtld-wg-bounces@icann.org>] On Behalf Of Rosette, Kristina via Gnso-newgtld-wg Sent: Tuesday, October 02, 2018 1:47 PM To: gnso-newgtld-wg@icann.org <mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP Working Group - 2 October 2018 at 3:00 UTC
All,
Attached are my comments on the draft Supplemental Report. (I’ve come up for air from the EPDP WG long enough to get caught up on the transcripts for meetings I’ve missed – except for last night’s.)
Please let me know if you have any questions.
K
Kristina Rosette Senior Corporate Counsel, IP – Domains rosettek@amazon.com <mailto:rosettek@amazon.com> | 703.407.1354
From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org <mailto:gnso-newgtld-wg-bounces@icann.org>] On Behalf Of Emily Barabas Sent: Tuesday, October 02, 2018 5:51 AM To: gnso-newgtld-wg@icann.org <mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP Working Group - 2 October 2018 at 3:00 UTC
Dear Working Group members,
Please see below the notes from the meeting today, 2 October 2018. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/x/4QirBQ <https://community.icann.org/x/4QirBQ>.
Kind regards, Emily
----------------------------------------------------------------------------------------------------------
Notes and Action Items:
1. Agenda review/SOIs -- None
2. Supplemental Report: Review of sections 1.1, 1.2, 1.3, 1.4, and 1.5 continued -- Goal is to publish the report no later than 12 Oct 2018. -- Comments from several members sent to the list recently, not incorporated into the draft. -- The draft has captured all changes in a cumulative manner.
Section 1.1 -- Changes include a potential limit to the number of auctions an applicant could participate in -- ICANN Board has concerns about private auctions -- Could the auction be front-loaded? At the time of application, applicant puts forth the maximum amount they would be willing to pay. If contested, winner is the highest bid, paying the second highest bid amount. Benefits include an accurate valuation to each of the participants, potentially. Would need an applicant support element integrated.
Action Item: Sarah L to submit write-up of proposal described above.
Rubens Kuhl: One of the challenges for those applying to more than 1 TLD, either 2 or an infinite number of them, is to submit maximum bids for each string, since if hey lose one, they have more resources to pay in another one.
-- Do the losing bidders pay anything? Receive any benefit? -- Front-loading the auction flips the emphasis of the current auction of last resort. Would the mony need to go into escrow? Could be fairness issues as there may be subconscious biases related to the bid amouts. -- How would community applications be considered in this process? -- Sarah built off of Greg's idea to front-load contention resolution. Sealed price sealed bid auction. Funds collected should go to public benefit. The highest bidder goes through the initial evaluation process, paying the second highest bid.
From the chat: Anne Aikman-Scalese: COMMENT: The way to resolve that may be give Community applicants a priority round. Then you are only resolving contention among community applicants. Then in the general round, the bid could be a "silent auction". COMMENT Michael Casadevall: COMMENT: I can see a tie. Two companies bidding the same nice round number.
- When would evaluators know the highest bidder, if ever? It seems like in the beginning, as that seems to drive the evaluation order of the contention set. -- Add additional text as suggested by Anne Aikman-Scalese via email, at the end of the second paragraph.
Section 1.2 - Unsure of why emphasis is only on private auctions. Is the issue more about the parties that did not win the string are ending up getting paid off? Are other private resolutions problematic as well? Could result in every contention set ending up in auction. It would be odd to ban private auctions, but not other private resolution methods.
From the chat: Rubens Kuhl: Curiously, people seem to be in favor of private resolution by constituing joint-ventures. Rubens Kuhl: But Jon is right, you can't have the cake and eat it too. Michael Casadevall: Well, forming a JV is somewhat different since it's "everyone wins" Jim Prendergast: ff memory serves correct - I think the suggestion for a determination draw was to replace both private auction and ICANN last resort auction Michael Casadevall: It should be noted that banning private resolutions except X is an option. Rubens Kuhl: I can sell shares in a JV for the highest bidder. Justine Chew: Correct, we need to be clear on what should be encouraged vs discouraged (or disallowed). Rubens Kuhl: There's no way to implement such discretionary approach to private resolutions. It's all or nothing.
-- Joint ventures seem less objectionable to many. Allowing for changes to strings has been considered as well. - Include concerns about the private resolutions in the private auctions section. Seems like it needs to be all private resolutions are allowed or none are allowed. - Suggestion to pull the preliminary recommendation out of section (c). Prior to Jon's intervention, it seemed like that was the direction of the group previously. - Private auctions is a sub set of private resolutions. There may be some forms of private resolution that could be acceptable, while private auctions may indeed be the most problematic element.
Action Item: leadership team to reevaluate how to organize section, given new issues raised by Jon.
-- There is still a general sentiment that private auctions are problematic.
From the chat: Anne Aikman-Scalese: QUESTION: If the award goes to a certain entity and if the entity changes, ICANN approval is needed, right? Does that reduce gaming in the suggested solutions? QUESTION Anne Aikman-Scalese: Its a question related to whether any system we devise could be easily "gamed".
-- Change in entity prior to contract signing, additional due diligence is needed. After contract signing, due diligence needed as well. -- There are public comments to the Initial Report that may be of relevance to the supplemental report.
Statistics on auctions from Rubens:
From the chat: Rubens Kuhl: Michael, https://newgtlds.icann.org/en/program-status/statistics [newgtlds.icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__newgtlds.icann.org_en_p...> has the numbers. Rubens Kuhl: Total Contention Sets 234 Rubens Kuhl: Resolved Contention Sets 226 Rubens Kuhl: Contention Sets Resolved via ICANN Auction 16 Rubens Kuhl: Unresolved Contention Sets 8 Rubens Kuhl: Applications Pending Contention Resolution 24 Michael Casadevall: Maybe it's just me, but I haven't heard much support for auctions in general, even as a public last resort.
-- Options to auctions are provided, but there is an argument made in section 1.1 for the fairness of auctions.
From the chat: Jim Prendergast: here is the Board comment on private auctions - Regarding question 2.7.4.e.2 on “gaming” or abuse of private auction, the Boardbelieves that applications should not be submitted as a means to engage in privateauctions, including for the purpose of using private auctions as a method of financingtheir other applications. This not only increases the workload on processing but putsundue financial pressure on other applicants who have business plans and financingbased on their intention to execute the plan described in the application. In particular, weare concerned about how gaming for the purpose of financing other applications, or withno intent to operate the gTLD as stated in the application, can be reconciled withICANN's Commitments and Core Values. Jon Nevett: Perhaps we should refer to private sales vs. private auctions?
Section 1.3 -- No changes since last meeting.
Section 1.4 -- Talks about change requests that may allow for contention resolution (e.g., joint ventures and string change). -- No changes since last meeting. - If in a contention set and you are able to choose another string, does it prevent choosing a string that puts you in another contention set?
Action Item: Include language above.
Section 1.5 -- Added elements about asking registrars for advice. - Is the intention to create a retail space for registry's that are failing? Are we interfering in the marketplace? Is ICANN acting as a regulator by serving in a registrar? Is there a compliance issue here as well?
Action Item: Jim P to circulate text to strengthen section concerning elements above. Perhaps create a question.
-- ICANN is not just regulating types of things, but it's also regulating how it's distributed. There is already manipulation of the market.
From the chat: Jon Nevett: Jim +1 -- if a registry isn't getting sufficient registrar support, it could start its own
- Some have noted challenges with starting a registrar, as well as challenges meet the requirements of the code of conduct, especially for smaller organizations.
From the chat: Christopher Wilkinson: Section 1.5: just to recall that I hae already posted my comments to the List. Rubens Kuhl: Jon, that doesn't work in practice due to (1) high cost of registrar accreditation when used to sell a single TLD (2) registrants inertia or preferrence to use a single registrar/reseller for all their domain registrations. Michael Casadevall: I see Jim's point, but I have concerns that a registar may refuse to carry a gTLD for non-technical/non-financal reasons. I want to see Jim's comments before I dig in deeper though. Jon Nevett: in the 2005-8 policy debate on use of registrars, the key was that the protections required in the RAA are required for all registrations
-- protections could be integrated into the Registry Agreement.
From the chat: Rubens Kuhl: Michael, must-carry obligations were deemed to be over the top. So this doesn't seem to have much traction indeed. Jim Prendergast: Michael - do you envision a scenario where ICANN shoudl force a registrar to carry a TLD?
--Everyone should review text, especially questions, options, etc.
a. Draft of the additional Supplemental Report sections.
- Jeff added additional context about why this supplemental report is being issued. Noted that public comments related to these subjects will not have been considered. -- Was there a Work Track involved in reviewing these issues? -- If relevant, the relevant section is cited in the sections. However, most topics are mostly new. -- When reviewing comments, will try to identify where those comments may be relevant to the supplemental report. 3. Initial assessment of work required for Final CCT-RT Report
-- Overview of columns included in the document
-- Recommendation 9: Reading through the What Else Needs to Be Done (final column)?
-- Any objections to the approach suggested in this column? - no objections raised.
-- Anne Aikman-Scalese - Submitted a question to the list about this document. On recommendation 9, the RPM process is not a PDP. It is a review. General question about recommendations coming out of reviews and how the WG is expected to address these. Please see comment/question on list.
From the chat: Anne Aikman-Scalese: I sent questions to the list on this document. Anne Aikman-Scalese: RPM Review is not a PDP so the question relates to how results of mandated Reviews are considered procedurally. Same basic question applies to CCT-RT Review and relationship of those Recommendations to the PDP. There may be public comment on these questions - not sure. Jeff Neuman: The RPM Review is a PDP Jeff Neuman: It is charged with reviewing and making recommendations Jon Nevett: https://gnso.icann.org/sites/default/files/file/field-file-attach/projects-l... [gnso.icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_de...> Jon Nevett: cite to show it is a PDP
-- This comment from Anne does not appear to be contrary to the comments in the "What Else Needs To Be Done?" Due to the overlapping nature of the charters, it will be necessary to take into account the work that this group has done. -- Recommendation 12: reading through "What Else Needs To Be Done?" -- There is a broader question about how this Working Group is required to consider the results of the reviews, including the CCT-RT.
From the chat: Jeff Neuman: The CCT-RT is just advice to the Board
-- Main takeway: WG members should look at the recommendations and look at the last column about what needs to be done from our perspective. -- This week on the leadership team call, the leadership team will give some thought on the approach to reviewing this documents and the CCT-RT recommendations. - At this stage the recommendations are recommendations to the Board and not the PDP, but if the Board asks the PDP how it is considering the reocmmendations, it would be helpful for the group to complete an initial review of the items directed at the PDP.
From the chat: Anne Aikman-Scalese: Okay thanks for clarifying that Review reports are recommendations to the Board. My concern is sending differing recommendations from two different groups. If the Board has to resolve, that slows things down.
- Clarification: It is not so much that the Board needs to resolve this. To complete the review, the Board will need to provide additional guidance about whether it accepts the recommendations. The Board will provide direction to the GNSO Council, which will direct the PDP.
4. AOB
4.1 Update on the Initial Report public comment review process
- Public comments received on Intiial Report - public comment period closed on Wednesday. Close to 70 comments were received including from many of the SO/AC/SG/Cs, GDD, ICANN Board and a number of ccTLDs. - This is a large number of comments. There is a lot of work underway to organize and tabulate comments to support the WG's review of comments. -- Staff has created three Google Sheets that are similiar to the ones used for reviewing CC2. - There is one Google Doc per review SubTeam and one tab per topic area. Each preliminary recommendation, option, and question has a section within the sheet. - Where the specific preliminary recommendation, option, or question is referenced, this excerise is straightforward. Please check staff's categorization of the other comments. -- Goal is to have initial tabulation complete sometime next week, well in advance of ICANN63.
Emily Barabas | Policy Manager ICANN | Internet Corporation for Assigned Names and Numbers Email: emily.barabas@icann.org <mailto:emily.barabas@icann.org> | Phone: +31 (0)6 84507976
This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521. _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org <mailto:Gnso-newgtld-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg <https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg>
Dear Robin, Freedom of Expression is certainly one right we have to consider, but we have to balance it with other rights: ICANN also has to take into respect national law – e.g. in Germany names of cities are protected and can only be used by themselves (naming right according to § 12 BGB). In other countries this might as well be the case. Best regards, Katrin DOTZON GmbH - digital identities for tomorrow Akazienstrasse 28 10823 Berlin Deutschland - Germany Tel: +49 30 49802722 Fax: +49 30 49802727 Mobile: +49 173 2019240 ohlmer@dotzon.consulting<mailto:ohlmer@dotzon.consulting> www.dotzon.consulting<http://www.dotzon.consulting> DOTZON GmbH Registergericht: Amtsgericht Berlin-Charlottenburg, HRB 118598 Geschäftsführer: Katrin Ohlmer Sitz der Gesellschaft: Akazienstrasse 28, 10823 Berlin Von: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> Im Auftrag von Robin Gross Gesendet: Donnerstag, 4. Oktober 2018 23:19 An: gnso-newgtld-wg@icann.org Betreff: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP Working Group - 2 October 2018 at 3:00 UTC I agree that ICANN risks being violation of its bylaws if it regulates content (geographic words). Freedom of expression is an important principle of the gtld program -- Principle G of the policy explicitly states that applicants' freedom of expression rights shall be protected. Regulating words with geographic meaning violates Principle G, ICANN’s bylaws, and the free expression guarantees in international treaties, such as Article 19 of UNDHR which guarantees "the right to seek, receive, and impart information and ideas in any medium and regardless of frontiers.” ICANN cannot just ignore these legal obligations because a segment of the community wants to regulate those words and control the flow of information and ideas. Robin On Oct 2, 2018, at 3:54 PM, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> wrote: I agree with Kristina on the RK4 comment below and note that this is now more than one WG member who has weighed in: <image001.png> I also agree with her Comment 10 shown below: <image002.png> Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ <image004.png> Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 2000 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Rosette, Kristina via Gnso-newgtld-wg Sent: Tuesday, October 02, 2018 1:47 PM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP Working Group - 2 October 2018 at 3:00 UTC All, Attached are my comments on the draft Supplemental Report. (I’ve come up for air from the EPDP WG long enough to get caught up on the transcripts for meetings I’ve missed – except for last night’s.) Please let me know if you have any questions. K Kristina Rosette Senior Corporate Counsel, IP – Domains rosettek@amazon.com<mailto:rosettek@amazon.com> | 703.407.1354 From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Emily Barabas Sent: Tuesday, October 02, 2018 5:51 AM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP Working Group - 2 October 2018 at 3:00 UTC Dear Working Group members, Please see below the notes from the meeting today, 2 October 2018. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/x/4QirBQ. Kind regards, Emily ---------------------------------------------------------------------------------------------------------- Notes and Action Items: 1. Agenda review/SOIs -- None 2. Supplemental Report: Review of sections 1.1, 1.2, 1.3, 1.4, and 1.5 continued -- Goal is to publish the report no later than 12 Oct 2018. -- Comments from several members sent to the list recently, not incorporated into the draft. -- The draft has captured all changes in a cumulative manner. Section 1.1 -- Changes include a potential limit to the number of auctions an applicant could participate in -- ICANN Board has concerns about private auctions -- Could the auction be front-loaded? At the time of application, applicant puts forth the maximum amount they would be willing to pay. If contested, winner is the highest bid, paying the second highest bid amount. Benefits include an accurate valuation to each of the participants, potentially. Would need an applicant support element integrated. Action Item: Sarah L to submit write-up of proposal described above. Rubens Kuhl: One of the challenges for those applying to more than 1 TLD, either 2 or an infinite number of them, is to submit maximum bids for each string, since if hey lose one, they have more resources to pay in another one. -- Do the losing bidders pay anything? Receive any benefit? -- Front-loading the auction flips the emphasis of the current auction of last resort. Would the mony need to go into escrow? Could be fairness issues as there may be subconscious biases related to the bid amouts. -- How would community applications be considered in this process? -- Sarah built off of Greg's idea to front-load contention resolution. Sealed price sealed bid auction. Funds collected should go to public benefit. The highest bidder goes through the initial evaluation process, paying the second highest bid. From the chat: Anne Aikman-Scalese: COMMENT: The way to resolve that may be give Community applicants a priority round. Then you are only resolving contention among community applicants. Then in the general round, the bid could be a "silent auction". COMMENT Michael Casadevall: COMMENT: I can see a tie. Two companies bidding the same nice round number. - When would evaluators know the highest bidder, if ever? It seems like in the beginning, as that seems to drive the evaluation order of the contention set. -- Add additional text as suggested by Anne Aikman-Scalese via email, at the end of the second paragraph. Section 1.2 - Unsure of why emphasis is only on private auctions. Is the issue more about the parties that did not win the string are ending up getting paid off? Are other private resolutions problematic as well? Could result in every contention set ending up in auction. It would be odd to ban private auctions, but not other private resolution methods. From the chat: Rubens Kuhl: Curiously, people seem to be in favor of private resolution by constituing joint-ventures. Rubens Kuhl: But Jon is right, you can't have the cake and eat it too. Michael Casadevall: Well, forming a JV is somewhat different since it's "everyone wins" Jim Prendergast: ff memory serves correct - I think the suggestion for a determination draw was to replace both private auction and ICANN last resort auction Michael Casadevall: It should be noted that banning private resolutions except X is an option. Rubens Kuhl: I can sell shares in a JV for the highest bidder. Justine Chew: Correct, we need to be clear on what should be encouraged vs discouraged (or disallowed). Rubens Kuhl: There's no way to implement such discretionary approach to private resolutions. It's all or nothing. -- Joint ventures seem less objectionable to many. Allowing for changes to strings has been considered as well. - Include concerns about the private resolutions in the private auctions section. Seems like it needs to be all private resolutions are allowed or none are allowed. - Suggestion to pull the preliminary recommendation out of section (c). Prior to Jon's intervention, it seemed like that was the direction of the group previously. - Private auctions is a sub set of private resolutions. There may be some forms of private resolution that could be acceptable, while private auctions may indeed be the most problematic element. Action Item: leadership team to reevaluate how to organize section, given new issues raised by Jon. -- There is still a general sentiment that private auctions are problematic. From the chat: Anne Aikman-Scalese: QUESTION: If the award goes to a certain entity and if the entity changes, ICANN approval is needed, right? Does that reduce gaming in the suggested solutions? QUESTION Anne Aikman-Scalese: Its a question related to whether any system we devise could be easily "gamed". -- Change in entity prior to contract signing, additional due diligence is needed. After contract signing, due diligence needed as well. -- There are public comments to the Initial Report that may be of relevance to the supplemental report. Statistics on auctions from Rubens: From the chat: Rubens Kuhl: Michael, https://newgtlds.icann.org/en/program-status/statistics [newgtlds.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__newgtlds.icann.org_en_p...> has the numbers. Rubens Kuhl: Total Contention Sets 234 Rubens Kuhl: Resolved Contention Sets 226 Rubens Kuhl: Contention Sets Resolved via ICANN Auction 16 Rubens Kuhl: Unresolved Contention Sets 8 Rubens Kuhl: Applications Pending Contention Resolution 24 Michael Casadevall: Maybe it's just me, but I haven't heard much support for auctions in general, even as a public last resort. -- Options to auctions are provided, but there is an argument made in section 1.1 for the fairness of auctions. From the chat: Jim Prendergast: here is the Board comment on private auctions - Regarding question 2.7.4.e.2 on “gaming” or abuse of private auction, the Boardbelieves that applications should not be submitted as a means to engage in privateauctions, including for the purpose of using private auctions as a method of financingtheir other applications. This not only increases the workload on processing but putsundue financial pressure on other applicants who have business plans and financingbased on their intention to execute the plan described in the application. In particular, weare concerned about how gaming for the purpose of financing other applications, or withno intent to operate the gTLD as stated in the application, can be reconciled withICANN's Commitments and Core Values. Jon Nevett: Perhaps we should refer to private sales vs. private auctions? Section 1.3 -- No changes since last meeting. Section 1.4 -- Talks about change requests that may allow for contention resolution (e.g., joint ventures and string change). -- No changes since last meeting. - If in a contention set and you are able to choose another string, does it prevent choosing a string that puts you in another contention set? Action Item: Include language above. Section 1.5 -- Added elements about asking registrars for advice. - Is the intention to create a retail space for registry's that are failing? Are we interfering in the marketplace? Is ICANN acting as a regulator by serving in a registrar? Is there a compliance issue here as well? Action Item: Jim P to circulate text to strengthen section concerning elements above. Perhaps create a question. -- ICANN is not just regulating types of things, but it's also regulating how it's distributed. There is already manipulation of the market. From the chat: Jon Nevett: Jim +1 -- if a registry isn't getting sufficient registrar support, it could start its own - Some have noted challenges with starting a registrar, as well as challenges meet the requirements of the code of conduct, especially for smaller organizations. From the chat: Christopher Wilkinson: Section 1.5: just to recall that I hae already posted my comments to the List. Rubens Kuhl: Jon, that doesn't work in practice due to (1) high cost of registrar accreditation when used to sell a single TLD (2) registrants inertia or preferrence to use a single registrar/reseller for all their domain registrations. Michael Casadevall: I see Jim's point, but I have concerns that a registar may refuse to carry a gTLD for non-technical/non-financal reasons. I want to see Jim's comments before I dig in deeper though. Jon Nevett: in the 2005-8 policy debate on use of registrars, the key was that the protections required in the RAA are required for all registrations -- protections could be integrated into the Registry Agreement. From the chat: Rubens Kuhl: Michael, must-carry obligations were deemed to be over the top. So this doesn't seem to have much traction indeed. Jim Prendergast: Michael - do you envision a scenario where ICANN shoudl force a registrar to carry a TLD? --Everyone should review text, especially questions, options, etc. a. Draft of the additional Supplemental Report sections. - Jeff added additional context about why this supplemental report is being issued. Noted that public comments related to these subjects will not have been considered. -- Was there a Work Track involved in reviewing these issues? -- If relevant, the relevant section is cited in the sections. However, most topics are mostly new. -- When reviewing comments, will try to identify where those comments may be relevant to the supplemental report. 3. Initial assessment of work required for Final CCT-RT Report -- Overview of columns included in the document -- Recommendation 9: Reading through the What Else Needs to Be Done (final column)? -- Any objections to the approach suggested in this column? - no objections raised. -- Anne Aikman-Scalese - Submitted a question to the list about this document. On recommendation 9, the RPM process is not a PDP. It is a review. General question about recommendations coming out of reviews and how the WG is expected to address these. Please see comment/question on list. From the chat: Anne Aikman-Scalese: I sent questions to the list on this document. Anne Aikman-Scalese: RPM Review is not a PDP so the question relates to how results of mandated Reviews are considered procedurally. Same basic question applies to CCT-RT Review and relationship of those Recommendations to the PDP. There may be public comment on these questions - not sure. Jeff Neuman: The RPM Review is a PDP Jeff Neuman: It is charged with reviewing and making recommendations Jon Nevett: https://gnso.icann.org/sites/default/files/file/field-file-attach/projects-l... [gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_de...> Jon Nevett: cite to show it is a PDP -- This comment from Anne does not appear to be contrary to the comments in the "What Else Needs To Be Done?" Due to the overlapping nature of the charters, it will be necessary to take into account the work that this group has done. -- Recommendation 12: reading through "What Else Needs To Be Done?" -- There is a broader question about how this Working Group is required to consider the results of the reviews, including the CCT-RT. From the chat: Jeff Neuman: The CCT-RT is just advice to the Board -- Main takeway: WG members should look at the recommendations and look at the last column about what needs to be done from our perspective. -- This week on the leadership team call, the leadership team will give some thought on the approach to reviewing this documents and the CCT-RT recommendations. - At this stage the recommendations are recommendations to the Board and not the PDP, but if the Board asks the PDP how it is considering the reocmmendations, it would be helpful for the group to complete an initial review of the items directed at the PDP. From the chat: Anne Aikman-Scalese: Okay thanks for clarifying that Review reports are recommendations to the Board. My concern is sending differing recommendations from two different groups. If the Board has to resolve, that slows things down. - Clarification: It is not so much that the Board needs to resolve this. To complete the review, the Board will need to provide additional guidance about whether it accepts the recommendations. The Board will provide direction to the GNSO Council, which will direct the PDP. 4. AOB 4.1 Update on the Initial Report public comment review process - Public comments received on Intiial Report - public comment period closed on Wednesday. Close to 70 comments were received including from many of the SO/AC/SG/Cs, GDD, ICANN Board and a number of ccTLDs. - This is a large number of comments. There is a lot of work underway to organize and tabulate comments to support the WG's review of comments. -- Staff has created three Google Sheets that are similiar to the ones used for reviewing CC2. - There is one Google Doc per review SubTeam and one tab per topic area. Each preliminary recommendation, option, and question has a section within the sheet. - Where the specific preliminary recommendation, option, or question is referenced, this excerise is straightforward. Please check staff's categorization of the other comments. -- Goal is to have initial tabulation complete sometime next week, well in advance of ICANN63. Emily Barabas | Policy Manager ICANN | Internet Corporation for Assigned Names and Numbers Email: emily.barabas@icann.org<mailto:emily.barabas@icann.org> | Phone: +31 (0)6 84507976 ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521. _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org<mailto:Gnso-newgtld-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg
Dear Robin: I am quite familiar with the antecedents to Freedom of Speech, having - inter alia - traced Paul Revere's Ride, in the event, on a bicycle. However, in the case of future TLDs I find that your interpretation of Freedom of Speech to be unduly expensive. The Freedom of Speech of users carries greater weight than the Freedom of Speech of the - eventual - applicants. Particularly as - differing from most other circumstances - a TLD constitutes a monopoly over the use of the 'string'. Regards CW
El 5 de octubre de 2018 a las 8:26 Katrin Ohlmer | DOTZON GmbH <ohlmer@dotzon.com> escribió:
Dear Robin,
Freedom of Expression is certainly one right we have to consider, but we have to balance it with other rights: ICANN also has to take into respect national law – e.g. in Germany names of cities are protected and can only be used by themselves (naming right according to § 12 BGB).
In other countries this might as well be the case.
Best regards,
Katrin
DOTZON GmbH - digital identities for tomorrow Akazienstrasse 28 10823 Berlin Deutschland - Germany Tel: +49 30 49802722 Fax: +49 30 49802727 Mobile: +49 173 2019240 ohlmer@dotzon.consulting mailto:ohlmer@dotzon.consulting http://www.dotzon.consulting
DOTZON GmbH Registergericht: Amtsgericht Berlin-Charlottenburg, HRB 118598 Geschäftsführer: Katrin Ohlmer Sitz der Gesellschaft: Akazienstrasse 28, 10823 Berlin
Von: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> Im Auftrag von Robin Gross Gesendet: Donnerstag, 4. Oktober 2018 23:19 An: gnso-newgtld-wg@icann.org Betreff: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP Working Group - 2 October 2018 at 3:00 UTC
I agree that ICANN risks being violation of its bylaws if it regulates content (geographic words).
Freedom of expression is an important principle of the gtld program -- Principle G of the policy explicitly states that applicants' freedom of expression rights shall be protected. Regulating words with geographic meaning violates Principle G, ICANN’s bylaws, and the free expression guarantees in international treaties, such as Article 19 of UNDHR which guarantees "the right to seek, receive, and impart information and ideas in any medium and regardless of frontiers.”
ICANN cannot just ignore these legal obligations because a segment of the community wants to regulate those words and control the flow of information and ideas.
Robin
> >
On Oct 2, 2018, at 3:54 PM, Aikman-Scalese, Anne <AAikman@lrrc.com mailto:AAikman@lrrc.com > wrote:
I agree with Kristina on the RK4 comment below and note that this is now more than one WG member who has weighed in:
<image001.png>
I also agree with her Comment 10 shown below:
<image002.png>
Anne E. Aikman-Scalese
Of Counsel
520.629.4428 office
520.879.4725 fax
AAikman@lrrc.com mailto:AAikman@lrrc.com
_____________________________
<image004.png>
Lewis Roca Rothgerber Christie LLP
One South Church Avenue, Suite 2000
Tucson, Arizona 85701-1611
lrrc.com http://lrrc.com/
From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org mailto:gnso-newgtld-wg-bounces@icann.org ] On Behalf Of Rosette, Kristina via Gnso-newgtld-wg Sent: Tuesday, October 02, 2018 1:47 PM To: gnso-newgtld-wg@icann.org mailto:gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP Working Group - 2 October 2018 at 3:00 UTC
All,
Attached are my comments on the draft Supplemental Report. (I’ve come up for air from the EPDP WG long enough to get caught up on the transcripts for meetings I’ve missed – except for last night’s.)
Please let me know if you have any questions.
K
Kristina Rosette
Senior Corporate Counsel, IP – Domains
rosettek@amazon.com mailto:rosettek@amazon.com | 703.407.1354
From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org mailto:gnso-newgtld-wg-bounces@icann.org ] On Behalf Of Emily Barabas Sent: Tuesday, October 02, 2018 5:51 AM To: gnso-newgtld-wg@icann.org mailto:gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP Working Group - 2 October 2018 at 3:00 UTC
Dear Working Group members,
Please see below the notes from the meeting today, 2 October 2018. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/x/4QirBQ https://community.icann.org/x/4QirBQ .
Kind regards,
Emily
----------------------------------------------------------------------------------------------------------
Notes and Action Items:
1. Agenda review/SOIs
-- None
2. Supplemental Report: Review of sections 1.1, 1.2, 1.3, 1.4, and 1.5 continued
-- Goal is to publish the report no later than 12 Oct 2018.
-- Comments from several members sent to the list recently, not incorporated into the draft.
-- The draft has captured all changes in a cumulative manner.
Section 1.1
-- Changes include a potential limit to the number of auctions an applicant could participate in
-- ICANN Board has concerns about private auctions
-- Could the auction be front-loaded? At the time of application, applicant puts forth the maximum amount they would be willing to pay. If contested, winner is the highest bid, paying the second highest bid amount. Benefits include an accurate valuation to each of the participants, potentially. Would need an applicant support element integrated.
Action Item: Sarah L to submit write-up of proposal described above.
Rubens Kuhl: One of the challenges for those applying to more than 1 TLD, either 2 or an infinite number of them, is to submit maximum bids for each string, since if hey lose one, they have more resources to pay in another one.
-- Do the losing bidders pay anything? Receive any benefit?
-- Front-loading the auction flips the emphasis of the current auction of last resort. Would the mony need to go into escrow? Could be fairness issues as there may be subconscious biases related to the bid amouts.
-- How would community applications be considered in this process?
-- Sarah built off of Greg's idea to front-load contention resolution. Sealed price sealed bid auction. Funds collected should go to public benefit. The highest bidder goes through the initial evaluation process, paying the second highest bid.
From the chat:
Anne Aikman-Scalese: COMMENT: The way to resolve that may be give Community applicants a priority round. Then you are only resolving contention among community applicants. Then in the general round, the bid could be a "silent auction". COMMENT
Michael Casadevall: COMMENT: I can see a tie. Two companies bidding the same nice round number.
- When would evaluators know the highest bidder, if ever? It seems like in the beginning, as that seems to drive the evaluation order of the contention set.
-- Add additional text as suggested by Anne Aikman-Scalese via email, at the end of the second paragraph.
Section 1.2
- Unsure of why emphasis is only on private auctions. Is the issue more about the parties that did not win the string are ending up getting paid off? Are other private resolutions problematic as well? Could result in every contention set ending up in auction. It would be odd to ban private auctions, but not other private resolution methods.
From the chat:
Rubens Kuhl: Curiously, people seem to be in favor of private resolution by constituing joint-ventures.
Rubens Kuhl: But Jon is right, you can't have the cake and eat it too.
Michael Casadevall: Well, forming a JV is somewhat different since it's "everyone wins"
Jim Prendergast: ff memory serves correct - I think the suggestion for a determination draw was to replace both private auction and ICANN last resort auction
Michael Casadevall: It should be noted that banning private resolutions except X is an option.
Rubens Kuhl: I can sell shares in a JV for the highest bidder.
Justine Chew: Correct, we need to be clear on what should be encouraged vs discouraged (or disallowed).
Rubens Kuhl: There's no way to implement such discretionary approach to private resolutions. It's all or nothing.
-- Joint ventures seem less objectionable to many. Allowing for changes to strings has been considered as well.
- Include concerns about the private resolutions in the private auctions section. Seems like it needs to be all private resolutions are allowed or none are allowed.
- Suggestion to pull the preliminary recommendation out of section (c). Prior to Jon's intervention, it seemed like that was the direction of the group previously.
- Private auctions is a sub set of private resolutions. There may be some forms of private resolution that could be acceptable, while private auctions may indeed be the most problematic element.
Action Item: leadership team to reevaluate how to organize section, given new issues raised by Jon.
-- There is still a general sentiment that private auctions are problematic.
From the chat:
Anne Aikman-Scalese: QUESTION: If the award goes to a certain entity and if the entity changes, ICANN approval is needed, right? Does that reduce gaming in the suggested solutions? QUESTION
Anne Aikman-Scalese: Its a question related to whether any system we devise could be easily "gamed".
-- Change in entity prior to contract signing, additional due diligence is needed. After contract signing, due diligence needed as well.
-- There are public comments to the Initial Report that may be of relevance to the supplemental report.
Statistics on auctions from Rubens:
From the chat:
Rubens Kuhl: Michael, https://newgtlds.icann.org/en/program-status/statistics [newgtlds.icann.org] https://urldefense.proofpoint.com/v2/url?u=https-3A__newgtlds.icann.org_en_p... has the numbers.
Rubens Kuhl: Total Contention Sets 234
Rubens Kuhl: Resolved Contention Sets 226
Rubens Kuhl: Contention Sets Resolved via ICANN Auction 16
Rubens Kuhl: Unresolved Contention Sets 8
Rubens Kuhl: Applications Pending Contention Resolution 24
Michael Casadevall: Maybe it's just me, but I haven't heard much support for auctions in general, even as a public last resort.
-- Options to auctions are provided, but there is an argument made in section 1.1 for the fairness of auctions.
From the chat:
Jim Prendergast: here is the Board comment on private auctions - Regarding question 2.7.4.e.2 on “gaming” or abuse of private auction, the Boardbelieves that applications should not be submitted as a means to engage in privateauctions, including for the purpose of using private auctions as a method of financingtheir other applications. This not only increases the workload on processing but putsundue financial pressure on other applicants who have business plans and financingbased on their intention to execute the plan described in the application. In particular, weare concerned about how gaming for the purpose of financing other applications, or withno intent to operate the gTLD as stated in the application, can be reconciled withICANN's Commitments and Core Values.
Jon Nevett: Perhaps we should refer to private sales vs. private auctions?
Section 1.3
-- No changes since last meeting.
Section 1.4
-- Talks about change requests that may allow for contention resolution (e.g., joint ventures and string change).
-- No changes since last meeting.
- If in a contention set and you are able to choose another string, does it prevent choosing a string that puts you in another contention set?
Action Item: Include language above.
Section 1.5
-- Added elements about asking registrars for advice.
- Is the intention to create a retail space for registry's that are failing? Are we interfering in the marketplace? Is ICANN acting as a regulator by serving in a registrar? Is there a compliance issue here as well?
Action Item: Jim P to circulate text to strengthen section concerning elements above. Perhaps create a question.
-- ICANN is not just regulating types of things, but it's also regulating how it's distributed. There is already manipulation of the market.
From the chat:
Jon Nevett: Jim +1 -- if a registry isn't getting sufficient registrar support, it could start its own
- Some have noted challenges with starting a registrar, as well as challenges meet the requirements of the code of conduct, especially for smaller organizations.
From the chat:
Christopher Wilkinson: Section 1.5: just to recall that I hae already posted my comments to the List.
Rubens Kuhl: Jon, that doesn't work in practice due to (1) high cost of registrar accreditation when used to sell a single TLD (2) registrants inertia or preferrence to use a single registrar/reseller for all their domain registrations.
Michael Casadevall: I see Jim's point, but I have concerns that a registar may refuse to carry a gTLD for non-technical/non-financal reasons. I want to see Jim's comments before I dig in deeper though.
Jon Nevett: in the 2005-8 policy debate on use of registrars, the key was that the protections required in the RAA are required for all registrations
-- protections could be integrated into the Registry Agreement.
From the chat:
Rubens Kuhl: Michael, must-carry obligations were deemed to be over the top. So this doesn't seem to have much traction indeed.
Jim Prendergast: Michael - do you envision a scenario where ICANN shoudl force a registrar to carry a TLD?
--Everyone should review text, especially questions, options, etc.
a. Draft of the additional Supplemental Report sections.
- Jeff added additional context about why this supplemental report is being issued. Noted that public comments related to these subjects will not have been considered.
-- Was there a Work Track involved in reviewing these issues?
-- If relevant, the relevant section is cited in the sections. However, most topics are mostly new.
-- When reviewing comments, will try to identify where those comments may be relevant to the supplemental report.
3. Initial assessment of work required for Final CCT-RT Report
-- Overview of columns included in the document
-- Recommendation 9: Reading through the What Else Needs to Be Done (final column)?
-- Any objections to the approach suggested in this column? - no objections raised.
-- Anne Aikman-Scalese - Submitted a question to the list about this document. On recommendation 9, the RPM process is not a PDP. It is a review. General question about recommendations coming out of reviews and how the WG is expected to address these. Please see comment/question on list.
From the chat: Anne Aikman-Scalese: I sent questions to the list on this document. Anne Aikman-Scalese: RPM Review is not a PDP so the question relates to how results of mandated Reviews are considered procedurally. Same basic question applies to CCT-RT Review and relationship of those Recommendations to the PDP. There may be public comment on these questions - not sure. Jeff Neuman: The RPM Review is a PDP Jeff Neuman: It is charged with reviewing and making recommendations Jon Nevett: https://gnso.icann.org/sites/default/files/file/field-file-attach/projects-l... [gnso.icann.org] https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_de... Jon Nevett: cite to show it is a PDP
-- This comment from Anne does not appear to be contrary to the comments in the "What Else Needs To Be Done?" Due to the overlapping nature of the charters, it will be necessary to take into account the work that this group has done. -- Recommendation 12: reading through "What Else Needs To Be Done?" -- There is a broader question about how this Working Group is required to consider the results of the reviews, including the CCT-RT.
From the chat: Jeff Neuman: The CCT-RT is just advice to the Board
-- Main takeway: WG members should look at the recommendations and look at the last column about what needs to be done from our perspective. -- This week on the leadership team call, the leadership team will give some thought on the approach to reviewing this documents and the CCT-RT recommendations. - At this stage the recommendations are recommendations to the Board and not the PDP, but if the Board asks the PDP how it is considering the reocmmendations, it would be helpful for the group to complete an initial review of the items directed at the PDP.
From the chat: Anne Aikman-Scalese: Okay thanks for clarifying that Review reports are recommendations to the Board. My concern is sending differing recommendations from two different groups. If the Board has to resolve, that slows things down.
- Clarification: It is not so much that the Board needs to resolve this. To complete the review, the Board will need to provide additional guidance about whether it accepts the recommendations. The Board will provide direction to the GNSO Council, which will direct the PDP.
4. AOB
4.1 Update on the Initial Report public comment review process
- Public comments received on Intiial Report - public comment period closed on Wednesday. Close to 70 comments were received including from many of the SO/AC/SG/Cs, GDD, ICANN Board and a number of ccTLDs.
- This is a large number of comments. There is a lot of work underway to organize and tabulate comments to support the WG's review of comments.
-- Staff has created three Google Sheets that are similiar to the ones used for reviewing CC2.
- There is one Google Doc per review SubTeam and one tab per topic area. Each preliminary recommendation, option, and question has a section within the sheet.
- Where the specific preliminary recommendation, option, or question is referenced, this excerise is straightforward. Please check staff's categorization of the other comments.
-- Goal is to have initial tabulation complete sometime next week, well in advance of ICANN63.
Emily Barabas | Policy Manager
ICANN | Internet Corporation for Assigned Names and Numbers
Email: emily.barabas@icann.org mailto:emily.barabas@icann.org | Phone: +31 (0)6 84507976
---------------------------------------------
This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521. _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org mailto:Gnso-newgtld-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg
>
_______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg
participants (6)
-
Aikman-Scalese, Anne -
Emily Barabas -
Katrin Ohlmer | DOTZON GmbH -
lists＠christopherwilkinson.eu Wilkinson -
Robin Gross -
Rosette, Kristina