February 2014 - council - lists.icann.org

Additional MSI Panel proposals posted
by Marika Konings Feb. 27, 2014

Feb. 27, 2014

Dear All, For your information, please note that the following MSI Panel proposals have been posted: * Enhance decision-making legitimacy by experimenting with innovative voting techniques (http://thegovlab.org/proposal-6-for-icann-enhance-decision-making-legitimac y-by-experimenting-with-innovative-voting-techniques/) * Increase transparency by using open data & open contracting (http://thegovlab.org/proposal-7-for-icann-increase-transparency-by-using-op en-data-open-contracting/) * Increase accountability through participatory budgeting (http://thegovlab.org/proposal-8-for-icann-increase-accountability-through-p articipatory-budgeting/) * Get inclusive by imposing rotating term limits (http://thegovlab.org/proposal-11-for-icann-get-inclusive-by-imposing-rotati ng-term-limits/) * Become more inclusive by moving from stakeholder engagement to global engagement (http://thegovlab.org/proposal-9-for-icann-become-more-inclusive-by-moving-f rom-stakeholder-engagement-to-global-engagement/) * Become agile adaptive and responsive by embracing evidence (http://thegovlab.org/proposal-10-for-icann-become-agile-adaptive-and-respon sive-by-embracing-evidence/) * Enhance learning by encouraging games (http://thegovlab.org/proposal-12-for-icann-enhance-learning-by-encouraging- games/) Best regards, Marika

1 0

FYI conference in Singapore: "ICANN and Global Internet Governance: The Road to São Paulo, and Beyond"
by Maria Farrell Feb. 26, 2014

Feb. 26, 2014

Dear fellow Councillors, FYI below is the just-finalised programme for a one-day conference on ICANN and Internet governance to be held in Singapore the Friday before our meeting there starts. All the best, Maria *"ICANN and Global Internet Governance: The Road to São Paulo, and Beyond"* A conference to be held on Friday 21 March 2014 at the ICANN 49 meeting venue, the Raffles City Convention Centre, Singapore, in the Olivia Room, from 10:00 to 18:00. Organized by the NonCommercial Users Constituency (NCUC) of the Generic Names Supporting Organization, with the generous support of ICANN. Logistical information, conference registration (important!) and the program are now online at http://www.ncuc.org/singapore2014/ We very much want this to be an inclusive cross-community dialogue, so we hope people will consider attending, either in person or remotely, and please do share this with potentially interested colleagues. We are compiling some background materials related to the session topics for addition to the web site, and personal/organizational written inputs would be very much welcome. *Overview of the meeting* 10:00-10:15 Welcome and Overview 10:15-10:45 Update on the Sao Paulo Meeting 10:45-12:00 Panel 1 - Setting the Scene: Overview of Recent Agenda-Setting Initiatives 12:00-13:00 Lunch 13:00-14:15 Panel 2 - Internet Governance Principles 14:15-15:45 Panel 3 - Roadmap for Ecosystem Evolution: Globalization 15:45-16:00 Coffee break 16:00-17:30 Panel 4 - Roadmap for Ecosystem Evolution: Institutional Innovation 17:15-17:45 Keynote Assessment by Larry Strickling, Asst. Secretary of Commerce, Government of the United States 17:45-18:00 Concluding Observations 18:00-19:30 Reception with Fadi Chehadé, CEO of ICANN

2 1

Response to Strategic Panel Blueprint
by Klaus Stoll Feb. 26, 2014

Feb. 26, 2014

Dear GNSO Councilors Greetings. NPOC under the very able leadership of Sam Lanfranco had a very fruitful discussion about the ICANN Strategic Panel on Multi Stakeholder Innovation blueprint document "The Quest for a 21rst Century ICANN". I am happy to attach a paper on the preliminary outcomes of the ongoing discussion for your information and input. We hope that this papers will help to support the discussion of the GNSO council. As the blueprint went far bejond the panels remit, the paper also goes far beyond the issues raised of the blueprint and touches on some ICANN "fundamentals". In the hope to be able to make a constructive contribution to the ongoing discussions and deliberations, Yours Klaus

4 4

FYI - Quick Look at Strategy Panel Recommendations - Provide Your Comments Today
by Marika Konings Feb. 26, 2014

Feb. 26, 2014

Quick Look at Strategy Panel Recommendations - Provide Your Comments Today (http://www.icann.org/en/news/announcements/announcement-2-25feb14-en.htm) <http://www.icann.org/en/news/announcements/announcement-2-25feb14-en.htm#> 25 February 2014 More than 40 diverse practitioners, subject matter experts and thought leaders have been working together since October 2013 as members of the ICANN Strategy Panels to support development of ICANN's strategic and operational future. Strategy Panels are advisory in nature and report to the ICANN President and CEO. Their quintessential objective is to inform and support ICANN's planning process. As highlighted at the opening ceremony at ICANN's public meeting Durban (July 2013), the Strategy Panels' work and output is designed to be informative and will not go straight to implementation. Each of the four panels has now published its draft recommendations, which are being translated into the five additional UN languages and are open for public comment <http://www.icann.org/en/news/public-comment/strategy-panels-25feb14-en.htm> . The recommendations are varied and wide-reaching, from partnering in a study to define an architectural vision for DNS in 2020 to organizing participants by topic rather than constituency groups to adapting ICANN's cultural to a multi-lingual and multi-cultural one. Highlights of recommendations by each panel are included below. For more information, please refer to each panel's draft report. Identifier Technology Innovation Recommendations <http://www.icann.org/en/about/planning/strategic-engagement/identifier-tech nology/report-21feb14-en.pdf> [PDF, 1.76 MB] Email: itipanel(a)icann.org * DNS use in the infrastructure will continue to grow; DNS use in the User Interface (UI) is challenged by search-based alternatives, mobile interfaces, etc. * ICANN should publish more DNSSEC signed data for reserved labels, etc. * In cooperation with IETF et al, do a study to define an architectural vision for DNS in 2020. * Design & prototype open root publication. * Design a shared zone control system for the root. * Perform collision exercises to test the ease of implementing [ICANN 2013]. ICANN Multistakeholder Innovation Recommendations <http://www.icann.org/en/about/planning/strategic-engagement/multistakeholde r-innovation/quest-blueprint-30jan14-en.pdf> [PDF, 424 KB] Email: msipanel(a)icann.org * ICANN should adopt an evolutionary approach that embraces experimentation and empirical evidence. The 16 proposals identified include the following: > * Making all of ICANN's data freely available and downloadable in > machine-readable formats. > * Moving from stakeholder engagement to global engagement. > * Using expert networks to provide oversight to ICANN officials. Public Responsibility Framework Recommendations <http://www.icann.org/en/about/planning/strategic-engagement/public-responsi bility/outline-23feb14-en> [PDF, 811 KB] Email: prfpanel(a)icann.org * Streamlining of current ICANN public responsibility activities under a Public Responsibility Department (PRD). * Strengthening ICANN Regional Engagement Strategies. * Commissioning research to enhance understanding of links between Internet Governance and Development. * Exploring the establishment of an external foundation to operate in the philanthropic space. ICANN's Role in the Internet Governance Ecosystem Recommendations <http://www.icann.org/en/about/planning/strategic-engagement/governance-ecos ystem/report-23feb14-en.pdf> [PDF, 1.78 MB] Email: ioepanel(a)icann.org * Consolidation and simplification of root zone management. * Globalize, not internationalize, the structure of ICANN and its associated or related institutions. * ICANN develop tailored AOC documents to be used to establish bilateral or multilateral, documented relationships between and among ICANN and ecosystem partners that wish to participate. * Globalize the process for accountability within Internet ecosystem. Share your thoughts today! We encourage you to review each draft report and provide your perspective by sending your comments to the email address for each panel's mailing list. Input will be welcome through 30 April 2014; all input sent to the mailing lists is publicly archived. Each panel will consider feedback received before finalizing their reports, so make your voice heard. To support community consideration and input, an interactive webinar will be held in early March 2014. A public session also will be conducted at the upcoming ICANN 49 meeting in Singapore (March 2014). Details will be shared in due course. Public comments and output will help inform ICANN's strategic and operational plans.

1 0

Guiding the Evolution of the IANA Protocol Parameter Registries
by Bruce Tonkin Feb. 25, 2014

Feb. 25, 2014

For info: The IETF is trying to document a set of principles for Evolution of the IANA Protocol Parameter Registries, as part of input into the current Internet Governance debates: From: IAB Chair To: IETF Announce Subject: Guiding the Evolution of the IANA Protocol Parameter Registries Existing IETF and IAB consensus concerning Internet registry functions and IANA are documented in a variety of RFCs and IAB communications [RFC2860,RFC6220,IAB1,IAB2]. Since registry functions and IANA are likely to be the subject of discussion in a number of venues outside the IETF over the coming months and years, the IAB is seeking community feedback about operating principles to use when they find themselves involved in those discussions. While dealing with these issues the IAB has consistently approached the issues from a set of (implicit) principles. Since the registry functions are subject of discussion in various fora, the IAB has tried to make these operating principles explicit and seeks to confirm these with the community. The IAB are planning to use part of the time in the IGOVUPDATE session at IETF 89 (6 March 2014, 17:00-18:30 GMT) for a discussion of such operating principles. But we wanted to kick-start that discussion with a few thoughts about principles that the IAB and IETF have articulated in various documents already and some that have emerged over time but may not have been written down. What we are interested in is an articulation of what the IETF community values. What other parties (ICANN, RIRs, governments, etc.) value when they think about registry functions is interesting, but we want to focus this discussion on the IETF and not those other parties. This is a first cut of making the principles more explicit for which we seek your views. Some of these might seem a bit generic, but it is difficult to predict the nature of future discussions in which IETF and IAB leaders might find themselves, so generality helps in that regard. On behalf of the IAB, Russ Housley IAB Chair = = = = = = = = Principles Guiding the Evolution of the IANA Protocol Parameter Registries 1. The IETF protocol parameters function has been and continues to be capably provided by the Internet community. The strength and stability of the function and its foundation within the Internet community are both important given how critical protocol parameters are to the proper functioning of IETF protocols. We think the structures that sustain the protocol parameters function needs be strong enough that they can be offered independently by the Internet community, without the need for backing from external parties. And we believe we largely are there already, although the system can be strengthened further, and continuous improvements are being made. 2. The administration of the protocol parameters function by ICANN is working well for the Internet and the IETF. We are pleased with the publication and maintenance of the protocol parameter function and the coordination of the evaluation of registration requests through the IANA function provided by ICANN. 3. The IETF protocol parameters function requires openness, transparency, and accountability. Existing documentation of how the function is administered and overseen is good [RFC2860,RFC6220], but further articulation and clarity may be beneficial. It is important that the whole Internet community can understand how the function works, and that the processes for registering parameters and holding those who oversee the protocol parameter function accountable for following those processes are understood by all interested parties. We are committed to making improvements here if necessary. 4. Any contemplated changes to the protocol parameters function should use the current RFCs and model as the starting point. The protocol parameters function is working well, and as a result wholesale changes to the role of the IETF vis a vis the function are not warranted. The IETF/IANA Memorandum of Understanding [RFC2860] is a good model to work from in the event that other parties do want to contemplate changes. Put quite simply: evolution, not revolution. 5. The Internet architecture requires and receives capable service by Internet registries. The stability of the Internet depends on capable provision of not just IETF protocol parameters, but IP numbers, domain names, and other registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined protocols. Thus we expect the role of the IETF in standards development, architectural guidance, and allocation of certain name/number parameters to continue. IP multicast addresses and special-use DNS names are two examples where close coordination is needed. The IETF will continue to coordinate with ICANN, the RIRs, and other parties that are mutually invested in the continued smooth operation of the Internet registries. We fully understand the need to work together. 6. The IETF will continue its direction and stewardship of the protocol parameters function as an integral component of the IETF standards process and the use of resulting protocols. RFC 6220 specifies the role and function of the protocol parameters registry, which is critical to IETF standards processes and IETF protocols. We see no need to revisit or reconsider our current approach with regard to protocol parameters, including the ability to delegate operational responsibility for registries to other organizations. [RFC2860] http://www.rfc-editor.org/rfc/rfc2860.txt [RFC6220] http://www.rfc-editor.org/rfc/rfc6220.txt [IAB1] http://www.iab.org/wp-content/IAB-uploads/2011/03/2009-06-08-IAB-NTIA-NOI-f… [IAB2] http://www.iab.org/wp-content/IAB-uploads/2011/07/IANA-IAB-FNOI-2011.pdf

1 0

TR: GNSO Council Abstention Notification Form [#142]
by Glen de Saint Géry Feb. 23, 2014

Feb. 23, 2014

FYI De : ICANN [mailto:no-reply@wufoo.com] Envoyé : dimanche 23 février 2014 09:42 À : gnso.secretariat(a)icann.org; council(a)gnso.icann.org Objet : GNSO Council Abstention Notification Form [#142] Name of Officer: * rafik dammak Officer Email Address: * rafik.dammak(a)gmail.com<mailto:rafik.dammak@gmail.com> Date Prepared: * Sunday, February 23, 2014 GNSO Organization: * Non-Commercial Stakeholder Group Officer Position or Title: * chair Voting Remedy: * Proxy Reason(s) for or condition(s) leading to the remedy: * Avri won't be able to attend the GNSO council call since she will be travelling Specific subject(s)/measure(s)/motion(s)/action(s) of the Council for which the remedy is being exercised: * Maria Farell will submit Avri's vote by proxy for the motions to be approved, and any other matters needing a vote. 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, February 28, 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: * maria farell

1 0

SAC065: SSAC Advisory on DDoS Attacks using the DNS
by Bruce Tonkin Feb. 22, 2014

Feb. 22, 2014

Hello All, Attached is an advisory from SSAC on DDoS attacks: Specifically, the SSAC strongly recommends that: 1. ICANN should help facilitate an Internet-wide community effort to reduce the number of open resolvers and networks that allow network spoofing. This effort should involve measurement efforts and outreach. 2. All network operators should take immediate steps to prevent network address spoofing. 3. Recursive DNS server operators should take immediate steps to secure open recursive DNS servers. 4. Authoritative DNS server operators should support efforts to investigate authoritative response rate limiting. 5. DNS server operators should put in place operational processes to ensure that their DNS software is regularly updated and communicate with their software vendors to keep abreast of the latest developments. 6. Manufacturers and/or configurators of customer premise networking equipment, including home networking equipment, should take immediate steps to secure these devices and ensure that they are field upgradable when new software is available to fix security vulnerabilities, and aggressively replace the installed base of non-upgradeable devices with upgradeable devices. Regards, Bruce Tonkin

1 0

RE: Second Accountability and Transparency Review Team (ATRT 2) Final Report & Recommendations
by Jonathan Robinson Feb. 21, 2014

Feb. 21, 2014

PLEASE RESPOND WITHIN 8 HOURS From: Jonathan Robinson [mailto:jonathan.robinson@ipracon.com] Sent: 20 February 2014 09:38 To: council(a)gnso.icann.org Subject: RE: Second Accountability and Transparency Review Team (ATRT 2) Final Report & Recommendations All, The deadline for submission of public comment on the ends approximately 36 hours from now. I am OK to submit a letter in substantially the same for as that distributed to you on 14 Feb (see below) and re-attached to this letter. BUT I need your support to do so. Accordingly, even if you simply provide support without any comment on the content, that will be helpful. PLEASE RESPOND WITHIN 24 HOURS Thank-you. Jonathan From: Jonathan Robinson [mailto:jrobinson@afilias.info] Sent: 14 February 2014 17:21 To: council(a)gnso.icann.org Subject: Second Accountability and Transparency Review Team (ATRT 2) Final Report & Recommendations Importance: High All, If you are not already, please be aware of the following: http://www.icann.org/en/news/public-comment/atrt2-recommendations-09jan14-en .htm The opportunity to provide comments ends one week from today 23h59 UTC on 21 Feb 2014. The ATRT2 interacted with many in the community during the course of its work, including directly with the GNSO Council which was certainly appreciated. We now have an opportunity to comment on the final report. If we do intend to comment, my opinion is that we should at least submit an indication of intent, if not the primary comment, in the initial comment period and not wait for the reply period. Given the tight time frame, I have taken the unusual step of drafting a council response for your consideration. The ATRT2 deals with some critical areas of GNSO work and function and so it seems to me that we should respond to the call for comments, specifically in so far as the report deals with GNSO Policy and directly related areas. I am aware that some of you were on the ATRT2 and others actively worked on Council interaction with the ATRT2. Therefore, you may well have strong views on the subject matter. I look forward to your input and any suggestions. Thanks, Jonathan

10 18

Revised Updated Proposed Agenda for the GNSO Council Teleconference 27 February 2014 at 11:00 UTC
by Glen de Saint Géry Feb. 21, 2014

Feb. 21, 2014

Dear Councillors, Please find the updated proposed agenda for the GNSO Council Teleconference 27 February 2014 at 11:00 UTC. http://gnso.icann.org/en/meetings/agenda-council-27feb14-en.htm https://community.icann.org/display/gnsocouncilmeetings/Agenda+27+February+… The revised update is that Items 4 and 6 have been switched. Proposed Agenda for the GNSO Council Teleconference 27 February 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 <http://gnso.icann.org/en/council/op-procedures-13jun13-en.pdf%20> > 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 11:00 UTC http://tinyurl.com/nkaf7dk Coordinated Universal Time 11:00 UTC 03:00 Los Angeles; 06:00 Washington; 11:00 London; 12:00 Brussels; 19: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 Maria Farrell https://community.icann.org/display/gnsosoi/Maria+Farrell+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 23 January 2014<http://gnso.icann.org/en/meetings/minutes-council-23jan14-en.htm> were posted as approved on 17 February 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) Item 4: UPDATE & DISCUSSION - International Internet Governance Issues (20 mins) Discussions and activity relating to international Internet Governance issues are attracting a great deal of attention in ICANN and related groups. This item is on the agenda to provide an opportunity for discussion within the Council about how this impacts the role and work of the Council and mindful of the scope and remit of the Council, what action the Council should or could be taking. 4.1 - Status update (Sally Costerton) 4.2 - Discussion 4.3 - Next steps Item 5: UPDATE - PDP Working Group on Translation & Transliteration of Contact Information (10 mins) The GNSO Council recently initiated a Policy Development Process<http://gnso.icann.org/en/basics/pdp-process.htm> (PDP) on the Translation and Transliteration of Contact Information. As part of its efforts to obtain broad input from the ICANN Community at an early stage of its deliberations, the Working Group has requested input from the Supporting Organizations (including the GNSO) and Advisory Committees on several questions relating to the issues identified in the PDP Final Issue Report. 5.1 - Update (Ching Chiao) 5.2 - Discussion 5.3 - Next steps Item 6: UPDATE & DISCUSSION - GNSO Engagement with the work of the ICANN Strategy Panels (15 mins) Here the Council will receive an update on any relevant interaction with and output from the strategy panels and discuss any appropriate action going forward. 6.1 - Status update 6.2 - Discussion 6.3 - Next steps Item 7: UPDATE & DISCUSSION - GAC Engagement - the work of the Joint GAC / GNSO Consultation Group (15 mins) Here the Council will receive an update and discuss any action going forward. 7.1 - Status update 7.2 - Discussion 7.3 - Next steps Item 8: UPDATE & DISCUSSION - Forthcoming review of the GNSO (10 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) are expected. In order to be informed and effectively prepared for this work, we have begun to engage with the body that commissions such reviews (the structural improvements committee) through its chair, Ray Plazk. The Council will track the planning work of the SIC and, where appropriate; provide relevant input to the process. We will also prepare to undertake a form of self-review in a similar format to that which we expect to arise out of the work of the SIC. A self-review will ensure that we are not only prepared for the board initiated work but also able to flag areas for potential improvement in as timely as possible a manner. 8.1 - Update (Jennifer Wolfe) 8.2 - Discussion 8.3 - Next steps Item 9: UPDATE & DISCUSSION - Planning for Singapore (15 mins) Making the most out of the face-to-face meeting time available at the ICANN Meeting in Buenos Aires will take planning. GNSO Council Vice Chair, David Cake 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 (David Cake & Jonathan Robinson) 9.2 - Discussion 9.3 - Next steps Item 10: Any Other Business (10 mins) * Community budget requests * ICANN Board Seat 14 - NCPH - additional Council meeting Thursday, 10 April 2014 at 14:00 UTC * Note the Root Server System Advisory Committee (RSSAC) presence in Singapore 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 October and March, Winter in the NORTHERN hemisphere ---------------------------------------------------------------------------- Reference (Coordinated Universal Time) UTC 11:00 ---------------------------------------------------------------------------- California, USA (PDT<http://www.timeanddate.com/library/abbreviations/timezones/na/pst.html>) UTC-7+1DST 03:00 Iowa City, USA (CST<http://fr.wikipedia.org/wiki/UTC%E2%88%9206:00>) UTC-6+1DST 05:00 New York/Washington DC, USA (EST) UTC-4+1DST 06:00 Rio de Janiero, Brazil (BRST) UTC-2+1DST 08:00 Montevideo, Uruguay (UYST<http://www.timeanddate.com/library/abbreviations/timezones/sa/uyst.html>) UTC-2+1DST 09:00 Buenos Aires, Argentina (ART<http://www.timeanddate.com/library/abbreviations/timezones/sa/art.html>) UTC-3+0DST 08:00 London, United Kingdom (BST) UTC+0DST 11:00 Bonn, Germany (CET) UTC+1+0DST 12:00 Stockholm, Sweden (CET) UTC+1+0DST 12:00 Cairo, Egypt, (EET) UTC+2+0DST 13:00 Istanbul, Turkey (EEST) UTC+2+0DST 13:00 Ramat Hasharon, Israel(IST<http://www.timeanddate.com/library/abbreviations/timezones/asia/ist-israel.…>) UTC+2+0DST 13:00 Beijing/Hong Kong, China (HKT ) UTC+8+0DST 19:00 Perth, Australia (WST<http://timeanddate.com/library/abbreviations/timezones/au/wst.html>) UTC+8+0DST 19:00 ---------------------------------------------------------------------------- DST starts/ends on last Sunday of March 2014, 2:00 or 3:00 local time (with exceptions) ---------------------------------------------------------------------- For other places see http://www.timeanddate.com http://tinyurl.com/nkaf7dk 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<mailto:gnso.secretariat@gnso.icann.org> http://gnso.icann.org

1 0

FW: ATRT2 Final Report - GNSO Council Public Comment
by Jonathan Robinson Feb. 21, 2014

Feb. 21, 2014

Thanks for the help in and input. Jonathan From: Jonathan Robinson [mailto:jonathan.robinson@ipracon.com] Sent: 21 February 2014 20:27 To: 'comments-atrt2-recommendations-09jan14(a)icann.org' Subject: ATRT2 Final Report - GNSO Council Public Comment Dear ATRT2 Colleagues, Please see attached for comments from the ICANN GNSO Council on your Final Report. Respectfully submitted for and on behalf of the GNSO Council. Sincerely, Jonathan Robinson Chair GNSO Council

1 0