April 2014 - council - lists.icann.org

TR: GNSO Council Abstention Notification Form [#145]
by Glen de Saint Géry May 8, 2014

May 8, 2014

FYI De : ICANN [mailto:no-reply@wufoo.com] Envoyé : mardi 22 avril 2014 22:18 À : gnso.secretariat(a)icann.org; council(a)gnso.icann.org Objet : GNSO Council Abstention Notification Form [#145] Name of Officer: * Steve DelBianco Officer Email Address: * sdelbianco(a)netchoice.org<mailto:sdelbianco@netchoice.org> Date Prepared: * Tuesday, April 22, 2014 GNSO Organization: * Business Constituency Officer Position or Title: * vice chair for policy coordination Voting Remedy: * Proxy Reason(s) for or condition(s) leading to the remedy: * BC Councilor Gabriela Szlak has a scheduled meeting that conflicts with the 8-May-2014 Council telecon Specific subject(s)/measure(s)/motion(s)/action(s) of the Council for which the remedy is being exercised: * For any matters coming before the Council. (Agenda not yet published) Date upon which the remedy will expire or terminate: [Note: may not exceed 3 months initially; may be renewed by sending an email with explanation to GNSO Secretariat] * Friday, May 9, 2014 I affirm that a voting position has been established on the matter(s) at issue pursuant to provisions contained in our Charter or Bylaws. * Yes Our GNSO Councilor has been instructed on how to vote on the matter(s). * Yes Please identify the GNSO Councilor who will serve as the voting proxy: * John Berard

2 2

Re: [council] A way forward on the Specification 13 question
by Winterfeldt, Brian J. May 8, 2014

May 8, 2014

Dear James and Volker: Please let me know if I understand correctly the RrSG position based your comments below: · The proposed amendment to Specification 13 is inconsistent with policy recommendation 19 because no discrimination between registrars should be permitted; · Dot Brands possess the sole ability to execute bulk transfers; · Dot Brands, as registrants, are able to choose their own preferred registrars; and · Dot Brands can implement registration policies and requirements to limit the services provided by registrars to only eligible registrants. Forgive me if my encapsulation is wrong, but if I understand the RrSG position correctly, then I am concerned that it may gloss over some important nuances. First, the RrSG position seems based on an assumption that dot Brand registries will be the sole registrant for bulk transfer and registrar selection purposes, whereas Specification Thirteen clearly permits Affiliates and Trademark Licensees to register names as well, thus complicating matters a bit. Second, the RrSG position seems to encourage dot brand registries to discriminate among registrars using registration policies, or perhaps other restrictions or side agreements among Affiliates and Trademark Licensees, at their own peril. Absent any assurances from ICANN legal regarding the propriety of these indirect work-around suggestions, I imagine that dot Brands would be much more comfortable with the direct and formal provision in the Registry Agreement that is presently under consideration by the Council. As I understand it, that is why the provision is necessary in the first place—so dot Brands cannot be alleged to violate the Registry Agreement in accrediting only one or two preferred corporate registrars. I look forward to your responsive feedback. Thank you, Brian Brian J. Winterfeldt Head of Internet Practice Katten Muchin Rosenman LLP 2900 K Street NW, North Tower - Suite 200 / Washington, DC 20007-5118 p / (202) 625-3562 f / (202) 339-8244 brian.winterfeldt(a)kattenlaw.com<mailto:brian.winterfeldt@kattenlaw.com> / www.kattenlaw.com<http://www.kattenlaw.com/> Re: [council] A way forward on the Specification 13 question * To: Volker Greimann <vgreimann@xxxxxxxxxxxxxxx>, Bret Fausett <bret@xxxxxxxx>, GNSO Council List <council@xxxxxxxxxxxxxx> * Subject: Re: [council] A way forward on the Specification 13 question * From: "James M. Bladel" <jbladel@xxxxxxxxxxx> * Date: Mon, 28 Apr 2014 16:12:52 +0000 * Accept-language: en-US * In-reply-to: <535E1AA3.6090807(a)key-systems.net<http://gnso.icann.org/mailing-lists/archives/council/msg16070.html>> * List-id: council@xxxxxxxxxxxxxx * Sender: owner-council@xxxxxxxxxxxxxx * Thread-index: Ac9U37pVNGMfDV+cTSyNSj0xaeNagAJSGHAAAKWMf0oAGtHogAAH4hAAAAWYJ4AAWH6IgAAEVA2A * Thread-topic: [council] A way forward on the Specification 13 question ________________________________ Just to add to Volker¹s comments: Registrars have had a vigorous discussion on this topic, and provided feedback from diverse viewpoints. But on the narrow question--whether Spec 13 is compatible with Rec 19‹we generally believe it is not. We recognize that dot-BRAND applicants and TLDs are a new part of the domain name ecosystem, and will have unique interests not shared by other TLDs. For example, we whole-heartedly agree with the proposed restrictions in Spec 13 on ICANN¹s ability to re-delegate a string that was formerly part of a dot-BRAND. However, we do not agree with the assertion that these TLDs must be formally allowed to discriminate among ICANN-accredited registrars. In response to the concerns raised by proponents of Spec 13, about being beholden to a single registrar/service provider, we would point out that, as the Registry and Registrant, they would possess sole authority to execute a bulk transfer to a new exclusive registrar/service provider under existing ICANN policy. Additionally, to address concerns about ³trusted² vs. ³untrusted² registrar/service providers, we would note that, as the Registrant, they would be able to choose the services of any registrar (or group of registrars) of their choosing, without the need to include this language in the Registry Agreement. In fact, this concern is only legitimate in the scenario where the dot-BRAND TLD later extends registrations to unaffiliated third parties. In summary, Registrars do not believe that this component of Spec 13 is compatible with Recommendation 19 of the original new gTLD policy, and that while dot-Brand are likely to encounter concerns unique to their new category of TLD, these issues can be addressed under existing policy. Thanks‹ J. From: Volker Greimann <vgreimann@xxxxxxxxxxxxxxx> Date: Monday, April 28, 2014 at 4:08 To: Bret Fausett <bret@xxxxxxxx>, GNSO Council List <council@xxxxxxxxxxxxxx> Subject: Re: [council] A way forward on the Specification 13 question Dear council-members, after extensive discussion of the question put before us, the RrSG has likewise found this excemption to be inconsistent with both the language as well as with the spirit of the recommendation. The question we have been asked is not whether we like the proposed exemption or can live with it, but rather a very simple one: Is the proposed incorporation of an ability to restrict nondiscriminatory registrar access to dotBrand TLDs is not consistent with the intent and wording of Recommendation 19, or is it not. The recommendation explicitly states that "Registries (...) may not discriminate among (ICANN) accredited registrars". In other words, the language of the Recommendation 19 contradicts the proposed exemption. Therefore, to find the additional language to be consistent with the recommendation requires substantial arguments to that effect that would allow such an interpretation. To find it consistent because one likes the result or can live with the result does not fulfill this requirement. For such cases where implementation would conflict with existing policy, further policy work adjusting or confirming the Policy Recommendation is required. The GNSO Council should take the lead in initiating this policy work. Beyond the grammatical inconsistency of the Recommendation, the intent of the Recommendation also indicates inconsistency. As detailed in the final report on the Introduction of New Generic Top Level Domains, the recommendation was supported by all GNSO Constituencies and Mrs Doria. According to the recollections of members of the new gTLD policy committee at the time the Recommendation was agreed upon, the concept of restricting registrar access was discussed in the context of community TLDs, which are in many ways similar to dotBrands. As registries have the ability under the Registry Agreement to restrict registrar access to their TLDs by establishing reasonable, nondiscriminatory accreditation criteria, it was ultimately agreed that discrimintation between registrars should not be permitted. In fact, the only public comment with regard to this recommendation came from the RyC, which was concerned that small, specialized registries may not be able to find a registrar to carry them. Note that this concern deals with a completely different problem. This concern led to the Vertical Integration Working group and the subsequent board decision allowing vertical integration. The idea of allowing only a few registrars does not appear in the Final Report. Finally, as registrants, dotBrands are perfectly free to discriminate between registrars. The Recommendation only deals with registries. By establishing certain registration requirements and policies, registries can further eliminate the ability of registrars to provide registry services beyond the eligible circle of registrants. Best regards, Volker Greimann Am 26.04.2014 16:54, schrieb Bret Fausett: Feedback: What we have been asked by the Board is to "advise ICANN as to whether the GNSO Council believes that this additional provision is inconsistent with the letter and intent of GNSO Policy Recommendation 19 on the Introduction of New Generic Top-Level Domains.² Policy Recommendation 19 reads: "Registries must use only ICANN accredited registrars in registering domain names and may not discriminate among such accredited registrars.² http://gnso.icann.org/en/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm The discussion section of this policy recommendation does not make for any exceptions for brands. Plainly, as I read the provisions of the .BRAND Specification 13, it is ³inconsistent with the letter and intent of GNSO Policy Recommendation 19.² Now, I personally happen to think that the draft Specification 13 for .BRAND TLDs is a tightly drafted, well-considered exception for a specialized type of TLD that was not being considered carefully when Recommendation 19 was prepared. BUT, it is definitely inconsistent with the policy recommendation we made in August, 2007. Let¹s think about what this means. -- Bret Fausett, Esq. € General Counsel, Uniregistry, Inc. 12025 Waterfront Drive, Suite 200 € Playa Vista, CA 90094-2536 310-496-5755 begin_of_the_skype_highlighting [skype-ie-addon-data://res/numbers_button_skype_logo.png] 310-496-5755 FREE end_of_the_skype_highlighting (T) € 310-985-1351 begin_of_the_skype_highlighting [skype-ie-addon-data://res/numbers_button_skype_logo.png] 310-985-1351 FREE end_of_the_skype_highlighting (M) € bret@xxxxxxxxxxxxxxx ‹ ‹ ‹ ‹ ‹ On Apr 26, 2014, at 5:14 AM, Thomas Rickert <rickert@xxxxxxxxxxx> wrote: Jonathan, I do hope to get more feedback. So far, I do not really have information to act on, but I am standing by to do what is necessary to meet the deadline. Thanks, Thomas Am 26.04.2014 um 10:29 schrieb Jonathan Robinson <jrobinson@xxxxxxxxxxxx>: Thanks Thomas, You will have seen that the motion deadline is Monday 28th 23h59 UTC so, assuming we will meet the 45 day deadline, we will need a motion on Monday. Let¹s hope we can do that in such a way as to reflect the feedback you have and retain flexibility to modify (if necessary) as we receive further feedback. Let¹s you and I talk on Monday. Jonathan From: Thomas Rickert [mailto:rickert@xxxxxxxxxxx] Sent: 25 April 2014 20:38 To: GNSO Council List Subject: Fwd: [council] A way forward on the Specification 13 question All, this is a gentle reminder to provide me with preliminary feedback. The motions and documents deadline is approaching rapidly and I have only received one response from the registrars so far. Also, I have reached out to Marilyn Cade (CBUC), Tony Holmes (ISPC), Kristina Rosette (IPC), Robin Gross (NCUC), Bruce Tonkin (Registrars) and Ken Stubbs (Registries) as they were listed in the final report of the PDP to cover their respective groups and since they hopefully have first-hand information on the discussions at the time. More people such as Avri, Bret and Alan are still here - please to chime in and respond. Thanks and kind regards, Thomas Anfang der weitergeleiteten Nachricht: Von: Thomas Rickert <rickert@xxxxxxxxxxx> Betreff: Aw: [council] A way forward on the Specification 13 question Datum: 22. April 2014 14:40:58 MESZ An: jrobinson@xxxxxxxxxxxx Kopie: GNSO Council List <council@xxxxxxxxxxxxxx> All, thanks to Jonathan for putting together and sending out the below message. I am more than happy to assist with making sure we get an answer prepared in time. Can I ask Councillors to get back to me offlist (in order not to swamp the list) with a status of the discussions with your respective groups? Certainly, one response per group is sufficient. If there is anything I can help with to facilitate your discussions, please let me know. The earlier I am provided with information on what direction your answers will take, the sooner I will be able to draft a motion and a letter to the NGPC for your review. Thanks, Thomas Am 10.04.2014 um 19:10 schrieb Jonathan Robinson <jrobinson@xxxxxxxxxxxx>: All, Following on from previous dialogue and the Council meeting today, it seems to me that the way forward is to focus as closely as possible on the question being asked and to make every attempt to respond in a timely and effective manner. This means that, assuming it is required, a motion to be voted on needs to be submitted to the Council by 28 April for consideration at the 8 May 2014 meeting. We are being asked (full letter attached for reference) to 1. Š advise ICANN as to whether the GNSO Council believes that this additional provision is inconsistent with the letter and intent of GNSO Policy Recommendation 19 on the Introduction of New Generic Top-Level Domains; or 2. advise ICANN that the GNSO Council needs additional time for review, including an explanation as to why additional time is required. I believe that the question to take to your respective stakeholder groups / constituencies is therefore: Is this additional provision inconsistent with the letter and intent of GNSO Policy Recommendation 19? It will be helpful to have as clear as possible an answer as soon as possible along the following lines: · No. It is not inconsistent (Š with the letter and intent Š). and · Possibly, an explanation as to why it is not inconsistent. and · Are there any other qualifying points that the Council should make in its response to the NGPC? OR · Yes. It is inconsistent ( Š with the letter and intent Š ). and · Possibly, an explanation as to why it is inconsistent. and · Is there a process by which the Council could assist the NGPC in resolving this issue and in what time frame? Please can you all act as quickly as possible to provide an answer to the above. The timing is very tight. We already have an indication of where the BC & the IPC stand on this i.e. no, it is not inconsistent. Someone will need to lead on drafting a motion (for submission to the Council on or before 28 April) and an associated letter to the NGPC. Given the time constraints, this should probably take place in parallel with the consultation work. Can we please have a volunteer to lead this effort and ensure it gets done? Thomas? I have tried to simplify and focus the problem here in the interest of providing a representative, timely and effective response. I trust that in doing so I have not discounted any material points in the discussion to date. Please correct me if I have. Jonathan -- Bret Fausett, Esq. € General Counsel, Uniregistry, Inc. 12025 Waterfront Drive, Suite 200 € Playa Vista, CA 90094-2536 310-496-5755 begin_of_the_skype_highlighting [skype-ie-addon-data://res/numbers_button_skype_logo.png] 310-496-5755 FREE end_of_the_skype_highlighting (T) € 310-985-1351 begin_of_the_skype_highlighting [skype-ie-addon-data://res/numbers_button_skype_logo.png] 310-985-1351 FREE end_of_the_skype_highlighting (M) € bret@xxxxxxxxxxxxxxx ‹ ‹ ‹ ‹ ‹ -- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 begin_of_the_skype_highlighting [skype-ie-addon-data://res/numbers_button_skype_logo.png] +49 (0) 6894 - 9396 901 FREE end_of_the_skype_highlighting Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@xxxxxxxxxxxxxxx Web: www.key-systems.net<http://www.key-systems.net> <http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> <http://www.RRPproxy.net>www.domaindiscount24.com<http://www.domaindiscount24.com> <http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> <http://www.BrandShelter.com> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> <http://www.facebook.com/KeySystems>www.twitter.com/key_systems<http://www.twitter.com/key_systems> <http://www.twitter.com/key_systems> Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> <http://www.keydrive.lu> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 begin_of_the_skype_highlighting [skype-ie-addon-data://res/numbers_button_skype_logo.png] +49 (0) 6894 - 9396 901 FREE end_of_the_skype_highlighting Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@xxxxxxxxxxxxxxx Web: www.key-systems.net<http://www.key-systems.net> <http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net> <http://www.RRPproxy.net>www.domaindiscount24.com<http://www.domaindiscount24.com> <http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com> <http://www.BrandShelter.com> Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems<http://www.facebook.com/KeySystems> <http://www.facebook.com/KeySystems>www.twitter.com/key_systems<http://www.twitter.com/key_systems> <http://www.twitter.com/key_systems> CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu<http://www.keydrive.lu> <http://www.keydrive.lu> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. ________________________________ * References: * Re: [council] A way forward on the Specification 13 question<http://gnso.icann.org/mailing-lists/archives/council/msg16070.html> * From: Volker Greimann ________________________________ <<<<http://gnso.icann.org/mailing-lists/archives/council/msg16073.html> Chronological Index<http://gnso.icann.org/mailing-lists/archives/council/index.html#16074> >>> <<<<http://gnso.icann.org/mailing-lists/archives/council/msg16072.html> Thread Index<http://gnso.icann.org/mailing-lists/archives/council/thrd268.html#16074> >>><http://gnso.icann.org/mailing-lists/archives/council/msg16022.html> ________________________________ Call Send SMS Add to Skype You'll need Skype CreditFree via Skype =========================================================== CIRCULAR 230 DISCLOSURE: Pursuant to Regulations Governing Practice Before the Internal Revenue Service, any tax advice contained herein is not intended or written to be used and cannot be used by a taxpayer for the purpose of avoiding tax penalties that may be imposed on the taxpayer. =========================================================== CONFIDENTIALITY NOTICE: This electronic mail message and any attached files contain information intended for the exclusive use of the individual or entity to whom it is addressed and may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information may be subject to legal restriction or sanction. Please notify the sender, by electronic mail or telephone, of any unintended recipients and delete the original message without making any copies. =========================================================== NOTIFICATION: Katten Muchin Rosenman LLP is an Illinois limited liability partnership that has elected to be governed by the Illinois Uniform Partnership Act (1997). ===========================================================

10 19

FW: Strategy Panel on ICANN Multistakeholder Innovation - Draft Report - Input from the GNSO Council
by Jonathan Robinson May 5, 2014

May 5, 2014

From: Jonathan Robinson [mailto:jonathan.robinson@ipracon.com] Sent: 30 April 2014 17:35 To: 'msipanel(a)icann.org' Cc: Theresa Swinehart (theresa.swinehart(a)icann.org) Subject: Strategy Panel on ICANN Multistakeholder Innovation - Draft Report - Input from the GNSO Council Dear Strategy Panel on ICANN Multistakeholder Innovation, Thank-you for the opportunity to provide input on the draft report of the Strategy Panel on ICANN Multistakeholder Innovation. Please see the attached for the carefully considered and respectfully submitted comments from the ICANN GNSO Council. Yours sincerely, Jonathan Robinson Jonathan Robinson Chair ICANN GNSO Council jonathan.robinson(a)ipracon.com Tel: +44 (0)20 7993 6103 skype: jonathan.m.r

2 2

Proposed Agenda for the GNSO Council Teleconference 8 May 2014
by Glen de Saint Géry April 30, 2014

April 30, 2014

Dear Councillors , Please find the draft agenda for the GNSO Council meeting on 8 May 2014 at 15:00 UTC posted at, and below in text: https://community.icann.org/display/gnsocouncilmeetings/Agenda+8+May+2014 http://gnso.icann.org/en/meetings/agenda-council-08may14-en.htm Proposed Agenda for the GNSO Council Teleconference 8 May 2014 This agenda was established according to the GNSO Council Operating Procedures approved 13 September 2012 for the GNSO Council and updated. <http://gnso.icann.org/en/council/op-procedures-13jun13-en.pdf > For convenience: * An excerpt of the ICANN Bylaws defining the voting thresholds is provided in Appendix 1 at the end of this agenda. * An excerpt from the Council Operating Procedures defining the absentee voting procedures is provided in Appendix 2 at the end of this agenda. Meeting Times 15:00 UTC http://tinyurl.com/q44vur2 Coordinated Universal Time 15:00 UTC 08:00 Los Angeles; 11:00 Washington; 16:00 London; 17:00 Brussels; 23:00 Perth Dial-in numbers will be sent individually to Council members. Councillors should notify the GNSO Secretariat in advance if a dial out call is needed. GNSO Council meeting audiocast http://stream.icann.org:8000/gnso.m3u Item 1: Administrative matters (10 mins) 1.1 Roll Call 1.2 Statement of interest updates Tony Holmes<https://community.icann.org/display/gnsosoi/Tony+Holmes+SOI> 1.3 Review/amend agenda 1.4. Note the status of minutes for the previous Council meeting per the GNSO Operating Procedures: Minutes of the GNSO Council meetings 27 February 2014<http://gnso.icann.org/en/meetings/minutes-council-27feb14-en.htm>, 26 March 2014<http://singapore49.icann.org/en/schedule/wed-gnso-council/minutes-gnso-coun…>, were posted as approved on 25 April and the GNSO Council meetings 10 April 2014<http://gnso.icann.org/en/meetings/minutes-council-10apr14-en.htm> were posted as approved on 30 April 2014. Item 2: Opening Remarks / Review of Projects & Action List (10 mins) Review focus areas and provide updates on specific key themes / topics Include review of Projects List<http://gnso.icann.org/meetings/projects-list.pdf> and Action List<https://community.icann.org/display/gnsocouncilmeetings/Action+Items>. Comments or questions arising. Item 3: Consent agenda (0 mins) Former GNSO Councillor Mikey O'Conner has resigned from the Data and Metrics for Policy Making non-PDP working group. The Council confirms the new Chair and Co-Chairs for the Data and Metrics for Policy Making non-PDP working group, namely Jonathan Zuck (IPC) as Chair as well as Rudy Vansnick (NPOC), Olevie Kouami (NPOC) and Cheryl Langdon-Orr (At-Large) as Co-Chairs. Confirmation of Avri Doria as member of the GAC / GNSO Consultation Group and replacement for Mikey O'Conner. Item 4: MOTION - Specification 13 to the New gTLD Registry Agreement (20 mins) The ICANN new gTLD Programme Committee (NGPC) has resolved to approve Specification 13 to the New gTLD Registry Agreement, see link<http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-annex-1…>. However, this does not currently include a proposed additional clause. Incorporation of the proposed additional clause (allowing a .Brand registry operator to designate a limited number of preferred registrars) is approved but will not be implemented until 45 days from the publication of the NGPC resolution in order to: (i) provide the GNSO Council with an opportunity to advise ICANN as to whether the GNSO Council believes that this additional provision is inconsistent with the letter and intent of GNSO Policy Recommendation 19 on the Introduction of New Generic Top-Level Domains; OR (ii) advise ICANN that the GNSO Council needs additional time for review, including an explanation as to why additional time is required. Here the Council will review and vote on a motion which deals with the issue of Specification 13 in so far as the Council attempts to answer the question posed by the NGPC. 4.1 - Motion<https://community.icann.org/display/gnsocouncilmeetings/Motions+8+May+2014> (Thomas Rickert) 4.2 - Discussion 4.3 - Vote Item 5: DISCUSSION - Internet Governance Issues (20 mins) The transition of the IANA function from the US government oversight is now firmly on the GNSO's agenda and the Council must determine its role and function with respect to this. A proposal was made in Singapore for the formation of a Cross-Community Working Group (CWG) to work on transition from NTIA and a very early stage initial draft of a potential charter for such a CWG was circulated. This has been modified a little since and is available here. http://gnso.icann.org/en/drafts/iana-transfer-process-charter-15apr14-en.pdf The existing CWG on internet governance has since commenced work on its own charter and indications are that such a charter will not include detailed work on the NTIA transition. In addition, indications are that the ccNSO may be interested in jointly initiating a new CWG on the NTIA transition together with the GNSO and that other AC/SO parts of ICANN will participate in such a CWG. Given the scope and impact of the IANA transition, it is likely that such a CWG will need to reach out beyond the ICANN community for participation and input. In this item, the Council will take the opportunity to comment and provide input into the formation and development of a CWG on the NTIA transition. 5.1 - Discussion 5.2 - Next steps Item 6: Update - Forthcoming review of the GNSO (15 mins) As part of a periodic review process that is built into the ICANN model, ICANN board initiated reviews of the GNSO (and the GNSO Council and related functions) will take place. The objective of the Review has been clarified as i.e. to examine the organizational effectiveness of the GNSO, including its components (GNSO Council, GNSO Working Groups, GNSO Stakeholder Groups and Constituencies). The review will be tightly scoped based on objective and quantifiable criteria provided to the independent examiner. A webinar to discuss this in more detail has been recently announced<http://www.icann.org/en/news/announcements/announcement-2-23apr14-en.htm>. The Structural Improvements Committee (SIC) is requesting that a GNSO Review Working Party be assembled to function as a liaison between the GNSO, the independent examiner and the SIC, to provide input on review criteria and the 360 Assessment, coordinate interviews and objectively supply clarification and responses to the draft findings and recommendations. The SIC envisages that once a final report is issued and the Board takes action on it, as appropriate, the GNSO Review Working Party will coordinate with the GNSO community to prepare an Implementation Plan and champion implementation of improvement activities. 6.1 - Update (Jennifer Wolfe) 6.2 - Discussion 6.3 - Next steps Item 7: Update - Work on IDN Variants (10 mins) IDN variants cannot be introduced into the root zone until a set of uniform Label Generation rule sets (LGRs) have been developed for each identified script and integrated into a uniform mechanism for permissible variant TLD labels. ICANN's IDN Variant Project is a multi-phase program that is currently working on the creation of these LGRs. Here ICANN staff will provide a brief primer on IDN variants and the Project, in order to ensure that the Council is informed and to facilitate deeper understanding of the issues and possible solutions. 7.1 - Staff Update (Naela Sarras / Steve Sheng) 7.2 - Discussion 7.3 - Next steps Item 8: Update - WHOIS Studies (10 mins) The last of the WHOIS studies commissioned by the GNSO were recently completed and published. In light of the ongoing work on WHOIS both within the GNSO and elsewhere, the GNSO will need to consider the utility and outcomes of these studies in relation to its policy work on WHOIS. 8.1 - Staff Update (Mary Wong) 8.2 - Discussion 8.3 - Next steps Item 9: UPDATE & DISCUSSION - Planning for London (10 mins) Making the most out of the face-to-face meeting time available at the ICANN Meeting in London will take planning. GNSO Council Vice Chair, Volker Greimann will lead this and will be working with the Council and staff on this effort. Here the Council has the opportunity to feed into plans and provide input based on past experience. Included in this item will be the opportunity to shape the approach to and substance of the Council's proposed meetings with other groups in such as the ccNSO, the GAC and the ICANN board. 9.1 - Update (Volker Greimann & Jonathan Robinson) 9.2 - Discussion 9.3 - Next steps Item 10: Any Other Business (5 mins) * Public comment on the Strategic Plan<https://www.icann.org/en/news/public-comment/stratplan-draft-09apr14-en.htm>? Appendix 1: GNSO Council Voting Thresholds (ICANN Bylaws, Article X, Section 3) 9. Except as otherwise specified in these Bylaws, Annex A hereto, or the GNSO Operating Procedures, the default threshold to pass a GNSO Council motion or other voting action requires a simple majority vote of each House. The voting thresholds described below shall apply to the following GNSO actions: a. Create an Issues Report: requires an affirmative vote of more than one-fourth (1/4) vote of each House or majority of one House. b. Initiate a Policy Development Process ("PDP") Within Scope (as described in Annex A<http://www.icann.org/en/about/governance/bylaws#AnnexA>): requires an affirmative vote of more than one-third (1/3) of each House or more than two-thirds (2/3) of one House. c. Initiate a PDP Not Within Scope: requires an affirmative vote of GNSO Supermajority. d. Approve a PDP Team Charter for a PDP Within Scope: requires an affirmative vote of more than one-third (1/3) of each House or more than two-thirds (2/3) of one House. e. Approve a PDP Team Charter for a PDP Not Within Scope: requires an affirmative vote of a GNSO Supermajority. f. Changes to an Approved PDP Team Charter: For any PDP Team Charter approved under d. or e. above, the GNSO Council may approve an amendment to the Charter through a simple majority vote of each House. g. Terminate a PDP: Once initiated, and prior to the publication of a Final Report, the GNSO Council may terminate a PDP only for significant cause, upon a motion that passes with a GNSO Supermajority Vote in favor of termination. h. Approve a PDP Recommendation Without a GNSO Supermajority: requires an affirmative vote of a majority of each House and further requires that one GNSO Council member representative of at least 3 of the 4 Stakeholder Groups supports the Recommendation. i. Approve a PDP Recommendation With a GNSO Supermajority: requires an affirmative vote of a GNSO Supermajority, j. Approve a PDP Recommendation Imposing New Obligations on Certain Contracting Parties: where an ICANN contract provision specifies that "a two-thirds vote of the council" demonstrates the presence of a consensus, the GNSO Supermajority vote threshold will have to be met or exceeded. k. Modification of Approved PDP Recommendation: Prior to Final Approval by the ICANN Board, an Approved PDP Recommendation may be modified or amended by the GNSO Council with a GNSO Supermajority vote. l. A "GNSO Supermajority" shall mean: (a) two-thirds (2/3) of the Council members of each House, or (b) three-fourths (3/4) of one House and a majority of the other House." Appendix 2: Absentee Voting Procedures (GNSO Operating Procedures 4.4<http://gnso.icann.org/council/gnso-operating-procedures-22sep11-en.pdf>) 4.4.1 Applicability Absentee voting is permitted for the following limited number of Council motions or measures. a. Initiate a Policy Development Process (PDP); b. Approve a PDP recommendation; c. Recommend amendments to the GNSO Operating Procedures (GOP) or ICANN Bylaws; d. Fill a Council position open for election. 4.4.2 Absentee ballots, when permitted, must be submitted within the announced time limit, which shall be 72 hours from the meeting's adjournment. In exceptional circumstances, announced at the time of the vote, the Chair may reduce this time to 24 hours or extend the time to 7 calendar days, provided such amendment is verbally confirmed by all Vice-Chairs present. 4.4.3 The GNSO Secretariat will administer, record, and tabulate absentee votes according to these procedures and will provide reasonable means for transmitting and authenticating absentee ballots, which could include voting by telephone, e- mail, web-based interface, or other technologies as may become available. 4.4.4 Absentee balloting does not affect quorum requirements. (There must be a quorum for the meeting in which the vote is initiated.) ---------------------------------------------------------------------------- Local time between March and October, Summer in the NORTHERN hemisphere ---------------------------------------------------------------------------- Reference (Coordinated Universal Time) UTC 15:00 ---------------------------------------------------------------------------- California, USA (PDT<http://www.timeanddate.com/library/abbreviations/timezones/na/pst.html>) UTC-7+1DST 08:00 Iowa City, USA (CST<http://fr.wikipedia.org/wiki/UTC%E2%88%9206:00>) UTC-6+1DST 10:00 New York/Washington DC, USA (EST) UTC-4+1DST 11:00 Rio de Janiero, Brazil (BRST) UTC-2+1DST 12:00 Montevideo, Uruguay (UYST<http://www.timeanddate.com/library/abbreviations/timezones/sa/uyst.html>) UTC-2+1DST 12:00 Buenos Aires, Argentina (ART<http://www.timeanddate.com/library/abbreviations/timezones/sa/art.html>) UTC-3+0DST 12:00 London, United Kingdom (BST) UTC+0DST 16:00 Bonn, Germany (CET) UTC+1+0DST 17:00 Stockholm, Sweden (CET) UTC+1+0DST 17:00 Cairo, Egypt, (EET) UTC+2+0DST 17:00 Istanbul, Turkey (EEST) UTC+2+0DST 18:00 Ramat Hasharon, Israel(IST<http://www.timeanddate.com/library/abbreviations/timezones/asia/ist-israel.…>) UTC+2+0DST 18:00 Beijing/Hong Kong, China (HKT ) UTC+8+0DST 23:00 Perth, Australia (WST<http://timeanddate.com/library/abbreviations/timezones/au/wst.html>) UTC+8+0DST 23:00 ---------------------------------------------------------------------------- DST starts/ends on last Sunday of October 2014, 2:00 or 3:00 local time (with exceptions) ---------------------------------------------------------------------- For other places see http://www.timeanddate.com http://tinyurl.com/q44vur2 Please let me know if you have any questions. Thank you. Kind regards, Glen Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0

TR: GNSO Council Abstention Notification Form [#146]
by Glen de Saint Géry April 30, 2014

April 30, 2014

FYI De : ICANN [mailto:no-reply@wufoo.com] Envoyé : mercredi 30 avril 2014 21:43 À : gnso.secretariat(a)icann.org; council(a)gnso.icann.org Objet : GNSO Council Abstention Notification Form [#146] Name of Officer: * Tony Holmes Officer Email Address: * tonyarholmes(a)btinternet.com<mailto:tonyarholmes@btinternet.com> Date Prepared: * Wednesday, April 30, 2014 GNSO Organization: * Internet Services Provider Constituency Officer Position or Title: * Chair ISPCP Constituency Voting Remedy: * Temporary Alternate Reason(s) for or condition(s) leading to the remedy: * Mikey O'Connor withdrew from ICANN, resigning all positions that he held including his position as a GNSO Councillor. The ISPCP Constituency have agreed a temporary replacement on Council up to and including the London meeting of ICANN in June. Across that period elections will be held with a view to the successful candidate taking that seat following the London meeting. Specific subject(s)/measure(s)/motion(s)/action(s) of the Council for which the remedy is being exercised: * THE ISPCP have appointed Tony Holmes as temporary alternate until the end of the ICANN meeting in London in June. Date upon which the remedy will expire or terminate: [Note: may not exceed 3 months initially; may be renewed by sending an email with explanation to GNSO Secretariat] * Wednesday, April 30, 2014 Please identify the individual (cannot be a current GNSO Councilor) who will serve as the abstaining Councilor's Temporary Alternate. [Note: if not already published and available, a short bio and Statement/Disclosure of Interest should be prepared by the Temporary Alternate and delivered to the GNSO Secretariat in advance of any discussion or voting scheduled to take place]. * Tony Holmes Temporary Alternate Email Address: * tonyarholmes(a)btinternet.com<mailto:tonyarholmes@btinternet.com>

1 0

Re: GAC / GNSO WG - Active participation / Contribution
by Avri Doria April 29, 2014

April 29, 2014

Hi, I was not able to make today's meeting, but am willing to help. avri On 29-Apr-14 14:38, Jonathan Robinson wrote: > All, > > > > A quick note to remind you of the call @ 13h00 UTC today and ask that we > have as active as possible participation from you both at the meetings > and in between meetings (on list). > > This is a small group with a high profile job which I think we need to > see succeed. > > > > If anyone feels that they are no longer able to participate as fully as > they might have envisaged or we might need, please speak up and we can > seek an alternative volunteer. > > > > Note 1: It looks like Avri may volunteer to fill Mikey’s vacated place > which is good news. > > Note 2: I know Volker has a regular commitment / clash at the time of > the calls. > > > > Thanks, > > > > > > Jonathan > > > > >

1 0

draft motion - response to NGPC letter - Rec 19/Spec 13
by Thomas Rickert April 29, 2014

April 29, 2014

All, please find attached a draft motion in response to the NGPC's letter with respect to Specification 13. We may need to continue our discussion but one clear message is that it is important to respond in a timely way to the deadline set by the NGPC. Therefore, any associated motion must meet the documents and motions deadline today for the upcoming GNSO Council telephone conference. The proposed motion encompasses the following messages, which I have heard and read so far: - There is an inconsistency between Recommendation 9 and Spec 13. - There is an understanding for and recognition of the .BRAND Registries' request. - The Council should respond to the NGPC's request and - in case an inconsistency is existent - make a constructive proposal on how to deal with this. Therefore, I have included additional clauses to state that the Council does not oppose the implementation of all of Spec 13 now, but requests that the Board make sure that appropriate safeguards are put in place in future rounds. Also, I have included a clause on the Council reserving the right to initiate a PDP if need be. I hope this is an acceptable compromise and I am more than happy to discuss this further. Thanks, Thomas

4 3

MSI Panel - updated response
by Jonathan Robinson April 29, 2014

April 29, 2014

All, Please see the proposed final response to the MSI Strategy Panel Output in both redline and clean versions. Thanks to Marika for assisting me in the preparation of these. This will be submitted by the deadline (tomorrow) unless I receive any other final comments. Thanks, Jonathan

2 1

A way forward on the Specification 13 question
by Jonathan Robinson April 28, 2014

April 28, 2014

All, Following on from previous dialogue and the Council meeting today, it seems to me that the way forward is to focus as closely as possible on the question being asked and to make every attempt to respond in a timely and effective manner. This means that, assuming it is required, a motion to be voted on needs to be submitted to the Council by 28 April for consideration at the 8 May 2014 meeting. We are being asked (full letter attached for reference) to 1. . advise ICANN as to whether the GNSO Council believes that this additional provision is inconsistent with the letter and intent of GNSO Policy Recommendation 19 on the Introduction of New Generic Top-Level Domains; or 2. advise ICANN that the GNSO Council needs additional time for review, including an explanation as to why additional time is required. I believe that the question to take to your respective stakeholder groups / constituencies is therefore: Is this additional provision inconsistent with the letter and intent of GNSO Policy Recommendation 19? It will be helpful to have as clear as possible an answer as soon as possible along the following lines: . No. It is not inconsistent (. with the letter and intent .). and . Possibly, an explanation as to why it is not inconsistent. and . Are there any other qualifying points that the Council should make in its response to the NGPC? OR . Yes. It is inconsistent ( . with the letter and intent . ). and . Possibly, an explanation as to why it is inconsistent. and . Is there a process by which the Council could assist the NGPC in resolving this issue and in what time frame? Please can you all act as quickly as possible to provide an answer to the above. The timing is very tight. We already have an indication of where the BC & the IPC stand on this i.e. no, it is not inconsistent. Someone will need to lead on drafting a motion (for submission to the Council on or before 28 April) and an associated letter to the NGPC. Given the time constraints, this should probably take place in parallel with the consultation work. Can we please have a volunteer to lead this effort and ensure it gets done? Thomas? I have tried to simplify and focus the problem here in the interest of providing a representative, timely and effective response. I trust that in doing so I have not discounted any material points in the discussion to date. Please correct me if I have. Jonathan

7 12

BC edits to the current proposed GNSO Council response to the call for Public Comment - ICANN Strategy Panels Draft Report
by john＠crediblecontext.com April 28, 2014

April 28, 2014

All, I had sent this directly to the drafting team but at Jonathan's suggestion, I now send them to the full Council. Cheers, Berard --------- Original Message --------- Subject: BC edits to the current proposed GNSO Council response to the call for Public Comment - ICANN Strategy Panels Draft Report From: john(a)crediblecontext.com Date: 4/22/14 7:13 am To: jrobinson(a)afilias.info, "Thomas Rickert" <rickert(a)anwaelte.de> Cc: "Gabriela Szlak" <gabrielaszlak(a)gmail.com> Jonathan, Thomas: At this point, the BC has confirmed is opposition to offering a comment as a matter of policy, but has little quarrel with the thrust of the comment. With this in mind, I offer the attached which redlines some of the language that can help make the point even as it reinforces the policy role of the Council. Cheers, Berard

2 1