September 2008 - council - lists.icann.org

GNSO Council motion 25 September 2008
by Glen de Saint Géry 25 Sep '08

25 Sep '08

[To: council[at]gnso.icann.org] Dear Council Members, Ahead of the complete minutes, please find the motion that was passed by the GNSO Council on Thursday, 25 September 2008. Kind regards, Glen .............................................................................................................. Motion proposing an Issues Report on aspects of Registry-Registrar Agreements Motion proposed by Mike Rodenbaugh, seconded by Greg Ruth with friendly amendments from Tim Ruiz and Chuck Gomes. Whereas: 1. ICANN's mission is to ensure the security and stability of the DNS, and to develop policy reasonably related to that mission. 2. Various forms of DNS abuse, in isolation and/or in the aggregate, cause a less secure and stable DNS. 3. Some of ICANN's gTLD registry agreements and appended registry-registrar agreements contain a provision such as Section 3.6.5 of the.info Registry Agreement, Appendix 8 : 3.6.5. (Registrars) acknowledge and agree that Afilias reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, that it deems necessary, in its discretion; (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of Afilias, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement or (5) to correct mistakes made by Afilias or any Registrar in connection with a domain name registration. Afilias also reserves the right to place upon registry lock, hold or similar status a domain name during resolution of a dispute. 4. Afilias, the dotInfo Registry Operator, per its recent RSTEP request, has sought to clarify and implement its specific abusive registration policy with respect to this provision. This request has been approved by ICANN. 5. Some of ICANN's gTLD registry agreements, notably the Verisign contracts for .com and .net, have no such provision. Other gTLD registry agreements do contain such provision, but the registry operators have not developed or have inconsistently developed abusive registration policies. The GNSO Council resolves to request an Issues Report from ICANN Staff within 30 days with respect to the following: 1. To identify and describe the various provisions in existing and previous gTLD registry and registry-registrar agreements which relate to contracting parties' ability to take action in response to abuse. 2. To identify and describe various provisions in a representative sampling of gTLD registration agreements which relate to contracting parties' and/or registrants rights and obligations with respect to abuse. 3. To identify and describe any previous discussion in ICANN fora which substantively pertains to provisions of this nature in any of these agreements. 4. To request an opinion of ICANN Staff as to which aspects of registration abuse policies as discussed above may be within the scope of GNSO policy development. 11 votes in favour: Philip Sheppard, Mike Rodenbaugh, Zahid Jamil, Kristina Rosette, Greg Ruth, Robin Gross, Olga Cavalli (one vote each) Tim Ruiz, Chuck Gomes (two votes each) Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0

Fwd: Redemption Grace Period and associated rights
by Alan Greenberg 25 Sep '08

25 Sep '08

As per my announcement today at the end of today's Council meeting, following is the solicitation for support and help sent to the ALAC and At-Large. It is not a definitive description of the issue, but rather a hopefully understandable summary for this who do not spend their days thinking about domain registration processes. The overall intent is to end up in an environment where registrants have a reasonable, predictable way to recover an expired domain regardless of whether the reason for expiration was lack of appropriate action on the part of the registrant, registrar or an act of some other third party. My understanding is that this was the original intent prior to the domain industry becoming such a large business in its own right. The ALAC is certainly interested in hearing from any constituencies who support the initiative, and in particular, any individuals who can help us craft the request for an Issues Report. Alan >Date: Wed, 24 Sep 2008 01:37:26 -0400 >To: At-Large Worldwide <at-large(a)atlarge-lists.icann.org>, ALAC >Working List <alac(a)atlarge-lists.icann.org> >From: Alan Greenberg <alan.greenberg(a)mcgill.ca> >Subject: Redemption Grace Period and associated rights > >Four weeks ago, Danny Younger raised the issue of the Redemption >Grace Period (RGP) with the North American RALO. A copy of his >e-mail can be found at >https://st.icann.org/alac/index.cgi?redemption_grace_period_danny_younger. > >In essence, about six years ago, the RGP was proposed and >implemented to allow a registrant to recover a domain name after it >had expired and been deleted by the registrar. The reason for the >deletion could be that a registrant did not receive the required >notices of expiry, or they were not sent, or they simply forgot. >Under the RGP, when a registry (such as VeriSign for .com) receives >a request to delete a name, it is put in a hold status for 30 days. >During this period, the name does not resolve, and if nothing else >had caught the registrant's eye before, this usually will. During >this time, a registrant can recover the name for a fee. The fee is >currently set $40 but can and generally is marked up by the registrar. > >The RGP was implemented voluntarily as a Registry Service by all of >the non-sponsored gTLDs. A registrar is not required to offer the >RGP however, so the existence of this registry service did not >guarantee that a registrant who neglected to renew could effectively >use the RGP. It was hoped that as Registrar contracts were >renegotiated, the requirement to make the RGP available would be >added, but this did not happen. A consensus policy could have been >created which would force them to offer the service, but this also >did not happen. > > From the point of registries, domains automatically renew, but the > registrar can reverse this retroactively during the "auto-renew > grace period" (ARGP - typically 45 days). > >Since that time the situation has changed in that registrars have >generally added conditions in their registrant agreements that give >the registrar the right to transfer or sell or auction an expired >domain to some other party (the so called "direct transfer" right). >Often, during the AGRP, they may monetize the domain temporarily to >see if it attracts much traffic and therefore has commercial value. >During this time, they *may* be willing to sell the domain back to >the original registrant. The price may depend on how much traffic >they saw in the interim. Once a value is determined, the domain may >be kept by the registrar (perhaps via a related company), or sold or >auctioned. Since the domain is never actually deleted at the >registry (it still maintains its original creation date), it never >gets a chance to enter the RGP. > >As complicated as this may sound, it is the short version. There was >an excellent tutorial on these practices given at the Lisbon ICANN >meeting in March 2007. A transcript can be found at >http://www.icann.org/en/meetings/lisbon/transcript-tutorial-expiring-25mar0…. > >The NARALO has agreed that this is a good project to take on, and >has requested that the ALAC pursue it. The issue was on the ALAC >meeting agenda of September 9, but unfortunately time ran out before >we got to it. However, since that meeting there have been a number >of conversations that indicate that this is an issue of importance >and that there is sufficient interest among At-Large that ALAC >should pursue it. > >In summary, we are looking for a way to ensure that registrants have >a reasonably and fairly priced way to retain a domain name, even if >it had inadvertently expired in the recent past. We are essentially >looking at it from two main perspectives: > >- Impact on registrants who lose control of their domain name, >potentially with significant financial or other impact; and >- Impact on users who can no longer access web sites and services >that they rely on. > >If we an find sufficient interest in At-Large and the RALOs to >support this project, I would like to see the ALAC request an Issues >Report from ICANN staff, which is the first step in initiating a >Policy Development Process (PDP). Following the delivery of the >Issues report, the GNSO Council would need to vote to decide to >initiate a PDP. Informal conversations indicate there may be >reasonable support for this on Council; assuming ICANN staff decide >that this is an issues within the scope of the GNSO, initiation >requires only a >33% vote. > >If we work quickly, I believe we can formally decide to proceed at >the ALAC's October 14th meeting, and issue the request for the >Issues Report in Cairo. > >I solicit general statements of support from ALSs and RALOs, and a >few volunteers to help work on the request. Volunteers must either >be knowledgeable in the issues being discussed, or be willing to >learn very quickly. > >Alan > >PS For this who want to understand more of the history of the RGP, >you can refer to: >http://www.icann.org/en/registrars/redemption-proposal-14feb02.htm >http://www.icann.org/en/registrars/redemption-supplement-20feb02.htm >http://www.icann.org/en/meetings/accra/redemption-topic.htm >http://www.icann.org/en/minutes/prelim-report-14mar02.htm#RedemptionGracePe…

1 0

RE: [council] Proposed amendment to motion in item 10 - intended friendly
by Mike Rodenbaugh 25 Sep '08

25 Sep '08

-----Original Message----- From: Mike Rodenbaugh [mailto:mike@rodenbaugh.com] Sent: Thursday, September 25, 2008 6:48 AM To: 'council(a)gnso.icann.org' Subject: RE: [council] Proposed amendment to motion in item 10 - intended friendly How about if we delete my #4 and make Tim's point #4 -- as follows: 4. To request an opinion of ICANN Staff Council as to which aspects of registration abuse policies as discussed above may be within the scope of GNSO policy development. -----Original Message----- From: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Tim Ruiz Sent: Thursday, September 25, 2008 4:59 AM To: council(a)gnso.icann.org Subject: [council] Proposed amendment to motion in item 10 - intended friendly I would like to propose an amendment to the motion on the abusive registrations issues report. The purpose is to first get an opinion on what aspects may or may not be in scope of GNSO policy work (within registry picket fence, for example). Will explain further on the call. The ammended motion would read: Whereas: 1. ICANN's mission is to ensure the security and stability of the DNS, and to develop policy reasonably related to that mission. 2. Various forms of DNS abuse, in isolation and/or in the aggregate, cause a less secure and stable DNS. 3. Some of ICANN's gTLD registry agreements and appended registry-registrar agreements contain a provision such as Section 3.6.5 of the.info Registry Agreement, Appendix 8 : 3.6.5. (Registrars) acknowledge and agree that Afilias reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, that it deems necessary, in its discretion; (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of Afilias, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement or (5) to correct mistakes made by Afilias or any Registrar in connection with a domain name registration. Afilias also reserves the right to place upon registry lock, hold or similar status a domain name during resolution of a dispute. 4. Afilias, the dotInfo Registry Operator, per its recent RSEP request, has sought to clarify and implement its specific abusive registration policy with respect to this provision. This request has been approved by ICANN. 5. Some of ICANN's gTLD registry agreements, notably the Verisign contracts for .com and .net, have no such provision. Other gTLD registry agreements do contain such provision, but the registry operators have not developed or have inconsistently developed abusive registration policies. The GNSO Council is considering whether or not to request an Issues Report from ICANN Staff with respect to the following: 1. To identify and describe the various provisions in existing and previous gTLD registry and registry-registrar agreements which relate to contracting parties' ability to take action in response to abuse. 2. To identify and describe various provisions in a representative sampling of gTLD registration agreements which relate to contracting parties' and/or registrants rights and obligations with respect to abuse. 3. To identify and describe any previous discussion in ICANN fora which substantively pertains to provisions of this nature in any of these agreements. 4. To identify and describe potential options for further Council consideration, relating to consistency and propriety of provisions of this nature in all of these agreements. Therefore the GNSO Council resolves to request an opinion of ICANN Staff Council as to which aspects of registration abuse policies as discussed above may be within the scope of GNSO policy development. Tim -------- Original Motion -------- Motion on request for issues report on Registration Abuse Policies. (10 mins) Motion: Mike Rodenbaugh Second: Greg Ruth Whereas: 1. ICANN's mission is to ensure the security and stability of the DNS, and to develop policy reasonably related to that mission. 2. Various forms of DNS abuse, in isolation and/or in the aggregate, cause a less secure and stable DNS. 3. Some of ICANN's gTLD registry agreements and appended registry-registrar agreements contain a provision such as Section 3.6.5 of the.info Registry Agreement, Appendix 8 : 3.6.5. (Registrars) acknowledge and agree that Afilias reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, that it deems necessary, in its discretion; (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of Afilias, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement or (5) to correct mistakes made by Afilias or any Registrar in connection with a domain name registration. Afilias also reserves the right to place upon registry lock, hold or similar status a domain name during resolution of a dispute. 4. Afilias, the dotInfo Registry Operator, per its recent RSEP request, has sought to clarify and implement its specific abusive registration policy with respect to this provision. This request has been approved by ICANN. 5. Some of ICANN's gTLD registry agreements, notably the Verisign contracts for .com and .net, have no such provision. Other gTLD registry agreements do contain such provision, but the registry operators have not developed or have inconsistently developed abusive registration policies. The GNSO Council resolves to request an Issues Report from ICANN Staff with respect to the following: 1. To identify and describe the various provisions in existing and previous gTLD registry and registry-registrar agreements which relate to contracting parties' ability to take action in response to abuse. 2. To identify and describe various provisions in a representative sampling of gTLD registration agreements which relate to contracting parties' and/or registrants rights and obligations with respect to abuse. 3. To identify and describe any previous discussion in ICANN fora which substantively pertains to provisions of this nature in any of these agreements. 4. To identify and describe potential options for further Council consideration, relating to consistency and propriety of provisions of this nature in all of these agreements.

1 0

Proposed amendment to motion in item 10 - intended friendly
by Tim Ruiz 25 Sep '08

25 Sep '08

I would like to propose an amendment to the motion on the abusive registrations issues report. The purpose is to first get an opinion on what aspects may or may not be in scope of GNSO policy work (within registry picket fence, for example). Will explain further on the call. The ammended motion would read: Whereas: 1. ICANN's mission is to ensure the security and stability of the DNS, and to develop policy reasonably related to that mission. 2. Various forms of DNS abuse, in isolation and/or in the aggregate, cause a less secure and stable DNS. 3. Some of ICANN's gTLD registry agreements and appended registry-registrar agreements contain a provision such as Section 3.6.5 of the.info Registry Agreement, Appendix 8 : 3.6.5. (Registrars) acknowledge and agree that Afilias reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, that it deems necessary, in its discretion; (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of Afilias, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement or (5) to correct mistakes made by Afilias or any Registrar in connection with a domain name registration. Afilias also reserves the right to place upon registry lock, hold or similar status a domain name during resolution of a dispute. 4. Afilias, the dotInfo Registry Operator, per its recent RSEP request, has sought to clarify and implement its specific abusive registration policy with respect to this provision. This request has been approved by ICANN. 5. Some of ICANN's gTLD registry agreements, notably the Verisign contracts for .com and .net, have no such provision. Other gTLD registry agreements do contain such provision, but the registry operators have not developed or have inconsistently developed abusive registration policies. The GNSO Council is considering whether or not to request an Issues Report from ICANN Staff with respect to the following: 1. To identify and describe the various provisions in existing and previous gTLD registry and registry-registrar agreements which relate to contracting parties' ability to take action in response to abuse. 2. To identify and describe various provisions in a representative sampling of gTLD registration agreements which relate to contracting parties' and/or registrants rights and obligations with respect to abuse. 3. To identify and describe any previous discussion in ICANN fora which substantively pertains to provisions of this nature in any of these agreements. 4. To identify and describe potential options for further Council consideration, relating to consistency and propriety of provisions of this nature in all of these agreements. Therefore the GNSO Council resolves to request an opinion of ICANN Staff Council as to which aspects of registration abuse policies as discussed above may be within the scope of GNSO policy development. Tim -------- Original Motion -------- Motion on request for issues report on Registration Abuse Policies. (10 mins) Motion: Mike Rodenbaugh Second: Greg Ruth Whereas: 1. ICANN's mission is to ensure the security and stability of the DNS, and to develop policy reasonably related to that mission. 2. Various forms of DNS abuse, in isolation and/or in the aggregate, cause a less secure and stable DNS. 3. Some of ICANN's gTLD registry agreements and appended registry-registrar agreements contain a provision such as Section 3.6.5 of the.info Registry Agreement, Appendix 8 : 3.6.5. (Registrars) acknowledge and agree that Afilias reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, that it deems necessary, in its discretion; (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of Afilias, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement or (5) to correct mistakes made by Afilias or any Registrar in connection with a domain name registration. Afilias also reserves the right to place upon registry lock, hold or similar status a domain name during resolution of a dispute. 4. Afilias, the dotInfo Registry Operator, per its recent RSEP request, has sought to clarify and implement its specific abusive registration policy with respect to this provision. This request has been approved by ICANN. 5. Some of ICANN's gTLD registry agreements, notably the Verisign contracts for .com and .net, have no such provision. Other gTLD registry agreements do contain such provision, but the registry operators have not developed or have inconsistently developed abusive registration policies. The GNSO Council resolves to request an Issues Report from ICANN Staff with respect to the following: 1. To identify and describe the various provisions in existing and previous gTLD registry and registry-registrar agreements which relate to contracting parties' ability to take action in response to abuse. 2. To identify and describe various provisions in a representative sampling of gTLD registration agreements which relate to contracting parties' and/or registrants rights and obligations with respect to abuse. 3. To identify and describe any previous discussion in ICANN fora which substantively pertains to provisions of this nature in any of these agreements. 4. To identify and describe potential options for further Council consideration, relating to consistency and propriety of provisions of this nature in all of these agreements.

1 0

RE: [council] Draft GNSO Council Agenda 25 September 2008
by Tim Ruiz 25 Sep '08

25 Sep '08

I'd like to move item 10 and perhaps item 5 ahead of item 4, or move item 10 to right after item 5. Both have motions that may result in a vote and we always seem to lose Councilors from the call toward the end. Tim -------- Original Message -------- Subject: [council] Draft GNSO Council Agenda 25 September 2008 From: Glen_de_Saint_Géry <Glen(a)icann.org> Date: Thu, September 18, 2008 11:05 am To: "council(a)gnso.icann.org" <council(a)gnso.icann.org> Dear Councilors, Proposed GNSO Council Agenda 25 September 2008 This agenda was established according to the Rules of Procedure for the GNSO Council Coordinated Universal Time12:00 UTC - see below for local times (05:00 Los Angeles, 08:00 Washington DC, 13:00 London, 14:00 Brussels, 22:00 Melbourne) Chuck Gomes will be chairing the GNSO Council meeting Scheduled time for meeting 120 mins. Dial-in numbers sent individually to Council members. Item 0: Roll call of Council members Item 1: Update any statements of interest Item 2: Review/amend agenda Item 3: Approve GNSO Council minutes of 4 September 2008 (Items 0-3 10 mins ) Item 4: Status Update (15 mins) 4.1 ICANN Board 4.2 Fast Flux PDP WG 4.3 Inter-Registrar Transfer Policy (IRTP) Part A PDP 4.4 New gTLDs 4.5 Fast Track 4.6 AGP 4.7 RAA Amendments Item 5: Discussion on GNSO Response concerning Geo Regions (15 mins) ICANN Geographic Regions -- Constituency feedback -- Next Steps Item 6: Discussion/Decision GNSO Restructuring and Plan (25 mins) -- Overview of Plan https://st.icann.org/gnso_transition/index.cgi?gnso_improvements Item 7: ICANN subsidization of GNSO travel expenses (10 mins). - longer term procedure --Next Steps Item 8: Planning for Cairo (15 mins) 8.1 Proposal for Trans-Silo Joint meeting (ccNSO, GNSO, GAC, ALAC) on Monday 3 November 2008 8.2 Thursday 6 November 2008 Proposed Topics: * Issues at the cross-section of implementation of New gTLD (LDH & IDN), and Fast Track IDNccTLDs * ICANN Transition and the PSC 8.3 Other Item 9: Whois Hypotheses Study Group (10 mins) http://gnso.icann.org/issues/whois/whois-study-hypothesis-group-report-to-c… -- Constituency feedback -- Next Steps Item 10: Motion on request for issues report on Registration Abuse Policies. (10 mins) Motion: Mike Rodenbaugh Second: Greg Ruth Whereas: 1. ICANN's mission is to ensure the security and stability of the DNS, and to develop policy reasonably related to that mission. 2. Various forms of DNS abuse, in isolation and/or in the aggregate, cause a less secure and stable DNS. 3. Some of ICANN's gTLD registry agreements and appended registry-registrar agreements contain a provision such as Section 3.6.5 of the.info Registry Agreement, Appendix 8 : 3.6.5. (Registrars) acknowledge and agree that Afilias reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, that it deems necessary, in its discretion; (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of Afilias, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement or (5) to correct mistakes made by Afilias or any Registrar in connection with a domain name registration. Afilias also reserves the right to place upon registry lock, hold or similar status a domain name during resolution of a dispute. 4. Afilias, the dotInfo Registry Operator, per its recent RSEP request, has sought to clarify and implement its specific abusive registration policy with respect to this provision. This request has been approved by ICANN. 5. Some of ICANN's gTLD registry agreements, notably the Verisign contracts for .com and .net, have no such provision. Other gTLD registry agreements do contain such provision, but the registry operators have not developed or have inconsistently developed abusive registration policies. The GNSO Council resolves to request an Issues Report from ICANN Staff with respect to the following: 1. To identify and describe the various provisions in existing and previous gTLD registry and registry-registrar agreements which relate to contracting parties' ability to take action in response to abuse. 2. To identify and describe various provisions in a representative sampling of gTLD registration agreements which relate to contracting parties' and/or registrants rights and obligations with respect to abuse. 3. To identify and describe any previous discussion in ICANN fora which substantively pertains to provisions of this nature in any of these agreements. 4. To identify and describe potential options for further Council consideration, relating to consistency and propriety of provisions of this nature in all of these agreements. Item 11: Any Other Business (5 mins) (05:00 Los Angeles, 08:00 Washington DC, 13:00 London, 14:00 Brussels, 22:00 Melbourne) ---------------------------------------------------------------------------- Local time between March and October, Summer in the NORTHERN hemisphere ---------------------------------------------------------------------------- Reference (Coordinated Universal Time) UTC 12:00 ---------------------------------------------------------------------------- California, USA (PST) UTC-7+1DST 05:00 New York/Washington DC, USA (EST) UTC-4+1DST 08:00 Buenos Aires, Argentina UTC-3+0DST 09:00 Rio de Janeiro, Brazil UTC-3+0DST 09:00 London, United Kingdom (BST) UTC+1DST 13:00 Brussels, Belgium (CEST) UTC+1+1DST 14:00 Karlsruhe, Germany (CEST) UTC+1+1DST 14:00 Barcelona, Spain (CEST) UTC+1+1DST 14:00 Oslo, Norway (CEST) UTC+1+1DST 14:00 Karachi, Pakistan UTC+5+1DST 18:00 Phnom Penh, Cambodia UTC+7+0DST 19:00 Hong Kong, China UTC+8+0DST 20:00 Singapore, Singapore UTC+8+0DST 20:00 Melbourne, Australia (EST) UTC+10+0DST 22:00 ---------------------------------------------------------------------------- The DST starts/ends on last Sunday of October 2008, 2:00 or 3:00 local time (with exceptions) ---------------------------------------------------------------------- For other places see http://www.timeanddate.com Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0

RE: [council] Updated GNSO Improvements Implementation Plan for Council consideration
by Gomes, Chuck 24 Sep '08

24 Sep '08

Please note that Rob Hoggarth will be providing a brief overview of this draft plan in our Council meeting tomorrow. Constituency reps are asked to distribute to and discuss this draft plan with their members ASAP in preparatiin for Council action on the plan on 16 October. Chuck Sent from my GoodLink Wireless Handheld (www.good.com) -----Original Message----- From: Liz Gasster [mailto:liz.gasster@icann.org] Sent: Wednesday, September 24, 2008 02:19 PM Eastern Standard Time To: council(a)gnso.icann.org Subject: [council] Updated GNSO Improvements Implementation Plan for Council consideration All, Attached please find an updated GNSO Improvements Implementation Plan, incorporating edits from recent planning team meetings. Thanks, Liz

1 0

Improving Institutional Confidence Consultation Enters Second Comment Period
by Glen de Saint Géry 24 Sep '08

24 Sep '08

[To: council[at]gnso.icann.org; liaison6c[at]gnso.icann.org] [To: ga[at]gnso.icann.org; announce[at]gnso.icann.org] [To: regional-liaisons[at]icann.org] Improving Institutional Confidence Consultation Enters Second Comment Period 19 September 2008 The Improving Institutional Confidence (IIC) in ICANN consultation has entered a second public comment period that will run until Monday 20 October 2008. In an effort to progress the consultation, an interactive forum has been set up that focuses comments and discussion on the individuals points and suggestions included in the revised documents. Please visit that forum at http://comment.icann.org/content/iic/. Alternatively, we have set up email addresses for each of the five main areas. Emails sent to each will appear in a specific "emailed comments" folder within this area's folder on the discussion forum (see below for more details). As part of the ongoing consultation process, and following comments received so far in the process, the IIC documents initially released in June have been revised. The latest versions of the consultation documents are: Transition Action Plan Improving Institutional Confidence in ICANN A Frequently Asked Questions document is also available. Changes made to the document Improving Institutional Confidence include: The inclusion of "Suggestions" into the text at relevant points, reflecting comments and advice received so far. They include: the provision of public statements of interest; voting restrictions; Board review mechanisms; more detailed information on a no-confidence vote in the Board; and more information on the question of "legal presences" Greater information and clarity on the issue of legal presences Reference added to operational areas of ICANN's work (such as compliance) The addition of a discussion of operational efficiency measures under the IANA procurement agreement with the United States Department of Commerce Inclusion of text about greater participation within ICANN processes Other changes: A number of changes have also been to the Transition Action Plan, including: A footnote covering the phrase "private sector led", as requested by respondents An adjustment to the consultation timeline (comment period extended to 20 October) Other feedback During the course of the first comment period, a number of suggested additions were made to the IIC consultation areas. The majority of those additions concerned ongoing ICANN activities such as: review and reform of existing supporting organisations and advisory committees; policy development work on IDNs, new gTLDs, DNSSEC and others; and operational matters such as contractual compliance. Those matters will continue to be addressed through ICANN's usual policy development and public comment processes. The process from here The body charged with leading the Improving Institutional Confidence (IIC) consultation, the President's Strategy Committee (PSC), will continue to receive comment on the key areas outlined in the document at a series of regional consultative consultations. Summaries of those meetings, in additional to comment made in the first comment period, and the feedback received during this second comment period, will then be used to make changes to the documents in time for a special IIC session at ICANN's international public meeting in Cairo on 2-7 November. Full details of the regional meetings can be found at: http://www.icann.org/en/jpa/iic/regional-meetings.htm. For those seeking more information on the consultation process, including published comment summaries, and the IIC documents under discussion, please visit the IIC's dedicated webpages at http://icann.org/en/jpa/iic. If you wish to be kept informed of the latest developments, please sign up to the dedicated IIC newsletter at: http://www.icann.org/en/jpa/iic/iic-newsletter.htm. The public comment forum Full links to the different discussion areas, including email addresses are given below: Capture [email] | Accountability [email] | Globalization [email] | Finances [email] | Security and Stability [email] Background: More than two years ago, the President's Strategy Committee (PSC) commenced a series of consultations on how to strengthen and complete the ICANN multi-stakeholder model. In addition, the recent Midterm Review of the Joint Project Agreement (JPA) between the United States Department of Commerce and ICANN produced useful comments about ICANN's performance and future. Most commentators in that consultation believe ICANN has made significant progress, but that some key areas need to be improved in order to complete the transition to an agreed model of multi-stakeholder coordination of the Internet's unique identifiers. The PSC has developed three papers that outline those key areas and possible responses to address them. The PSC wants to be clear - all these suggestions are for discussion. They are the work of the Committee alone. They are not fixed positions. But they are also positions that are the result of long-term work over two years by the PSC that also incorporate recent input from the community. The PSC has provided the following three documents to launch a discussion with the community PSC about how to complete the transition of the organization after the conclusion of the Joint Project Agreement. Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0

Updated GNSO Improvements Implementation Plan for Council consideration
by Liz Gasster 24 Sep '08

24 Sep '08

All, Attached please find an updated GNSO Improvements Implementation Plan, incorporating edits from recent planning team meetings. Thanks, Liz

1 0

ICANN Board meeting agenda - 30 Sept 2008
by Bruce Tonkin 24 Sep '08

24 Sep '08

From: http://www.icann.org/en/minutes/ 30 September 2008 / 1 October 2008 Special Meeting of the ICANN Board of Directors 1) Approval of Minutes from 28 August 2008 2) President's Monthly Report 3) Approval of the ICANN Board of Director's Code of Conduct 4) De-accredited Registrar Transition Procedure 5) Financial Approval of Contractor Agreement for Multiple Language Algorithms - Relating to Aspect of New gTLD Implementation 6) Review of .COOP and .MOBI Contractual Amendments 7) GNSO Council Re-structuring 8) President's Strategy Committee Report and Approval of Associated Director's Travel 9) Approval of Board Governance Committee's Recommendation for ICANN SSAC Review TOR, RFP, and Working Group Charter 10) Approval of Board Governance Committee's Recommendation for ICANN's RSSAC Review Independent Review Contractor 11) Approval of Finance Committee's Recommendation for Approval of IT Equipment Purchase 12) Independent Reviews Status Report 13) Board Finance Committee Report 14) Board Governance Committee Report 15) Update on Annual Audit 16) Other Business 17) Board Executive Session

1 0

Proposed Bylaws Revision Open For Comment
by Glen de Saint Géry 24 Sep '08

24 Sep '08

[To: council[at]gnso.icann.org; liaison6c[at]gnso.icann.org] [To: ga[at]gnso.icann.org; announce[at]gnso.icann.org] [To: regional-liaisons[at]icann.org] http://www.icann.org/en/announcements/announcement-23sep08-en.htm Proposed Bylaws Revision Open For Comment 23 September 2008 Today ICANN is opening a public comment period on a proposed bylaw revision [PDF, 21K] from the ICANN Nominating Committee. The proposed revision would update the diversity requirements for selecting ICANN Board members to include domicile with country of citizenship. Over the past several years, the Nominating Committee has expressed concern that being required to count more than one country of citizenship for diversity purposes often makes it difficult to select the best candidates for the Board seats that the Nominating Committee is mandated to fill. In carrying out its responsibilities to fill Seats 1 through 8, the Nominating Committee shall seek to ensure that the ICANN Board is composed of members who in the aggregate display diversity in geography, culture, skills, experience, and perspective, by applying the criteria set forth in Bylaws. The Nominating Committee also noted that some of the candidates have often lived in a country for many years, and thereby better represent the interests of that country than any country of which the candidates may be citizens. In the proposal, domicile, not just citizenship, is to be considered in the diversity calculation. The Nominating Committee members unanimously agreed that the proposed Bylaws revisions would alleviate the concerns. During the 28 August 2008 meeting of the ICANN Board of Directors, the Board passed the following resolution: Whereas, the Nominating Committee has expressed concern that, pursuant to the Bylaws mandated diversity requirements that no more than five Board members be citizens of any one geographic region, the Nominating Committee is required to count all countries of citizenship for each candidate. Whereas, the Nominating Committee has noted that the requirement to count all countries of citizenship has caused some selection difficulties each year over the past several years. Whereas, the Nominating Committee has also expressed concern that the calculation is presently limited to citizenship given that many people have lived for long periods of time in, and represent the interests of, countries in which they may not be citizens. Whereas, making a diversity calculation pursuant to the ICANN Bylaws as it relates to Board member selection for seats 1 through 14 should be consistent. It is hereby resolved (2008.08.28.03) that the following proposed revisions to Article VI, Sections 2.2 and 2.3, shall be posted for public comment in accordance with ICANN's normal process for proposed Bylaw revisions. Comments on the proposed bylaw revision may be submitted to nomcom-bylaw-revision(a)icann.org will be considered until 23 October 2008 23:59 UTC. Comments may be viewed at http://forum.icann.org/lists/nomcom-bylaw-revision/. Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0