Section I: Description, Explanation, and Purpose ICANN Staff requests community feedback concerning implementation plans [PDF, 876 KB] for three specific Accountability and Transparency Review Team (ATRT) recommendations (#15, 16, and 17) that affect the way ICANN publishes and manages Public Comments. These ATRT recommendations, which comprise Phase II of the Public Comments Improvement program, address: Stratification : Categorize topics to assist the community understand the subject matter and inform a participation decision. Prioritization : Assist community members in determining the importance or urgency of a solicitation by providing key information. Comment/Reply Cycles : Structure the community’s input process into an initial period for submitting new comments followed by a separate reply period during which community respondents would be able to address and rebut arguments raised in opposing parties’ previous comments. A fourth area involving Technical Forum Improvements is also incorporated into this solicitation. A Focus Group was organized in July 2011 to provide input concerning various implementation scenarios related to the topics mentioned above. The Focus Group held its deliberations in ICANN’s Wiki environment from 20 July 2011 through 19 August 2011. A summary report [PDF, 162 KB] of the group’s activities has been prepared and the Wiki space in which the Focus Group worked is accessible for viewing at: https://community.icann.org/x/74MKAQ . The attached report [PDF, 148 KB] addresses the four enhancement areas each in a separate section that incorporates Staff implementation recommendations, Focus Group input where applicable, and additional questions to stimulate community feedback concerning these processes. Note : As an initial test of this concept, the comment forum on this paper will introduce a Reply Cycle. At the conclusion of the initial comment period (30 September) and assuming that on-topic submissions have been received, the comment period will be extended for an additional 15 days (15 October). During this extension, contributors are asked to address any additional submissions to previously posted comments. For each such reply, it will be helpful to everyone for the contributor to cite the original poster’s name, comment date, and any particular text that is pertinent. At the conclusion of the full comment period, ICANN plans to seek feedback concerning the process and what changes or enhancements might make it more useful and productive. A consolidated report of the forum submissions will incorporate both the initial comment and subsequent reply periods. Section II: Background The Accountability and Transparency Review Team (ATRT) submitted a report to the ICANN Board on 31 December 2010 containing 27 recommendations, three of which (#15, 16, and 17) address improvements concerning how Public Comments are announced, published, and managed. At its 24 June 2011 meeting, ICANN Board accepted the implementation plans developed by ICANN Staff regarding these recommendations. These plans were organized into two major phases based upon complexity and the ability to effectuate short-term improvements. A set of Phase I activities was implemented effective 30 June 2011. In that first phase, Staff completely redesigned web pages, added new navigation menus, streamlined Announcement and Public Comment Box formats, and introduced an “Upcoming Topics” feature. Staff also created internal document templates to facilitate publication and ensure presentation consistency. We also added new standardized data fields across all solicitations (e.g., Originating Organization, Purpose, Current Status, Next Steps) and clarified opening and closing dates and times. Phase II of this initiative addresses enhancements involving: Stratification, Prioritization, Comment/Reply Cycles, and Technical Forum Improvements. Please see the attached report [PDF, 148 KB] for further information on each of these improvement areas. Section III: Document and Resource Links The following documents and reference links are provided to assist community members in contributing to this solicitation: Main Report: Public Comments Proposed Process Enhancements-Phase II [PDF, 148 KB] Board Action on, and Implementation of, the Accountability & Transparency Review Team Final Report June 2011 [PDF, 876 KB] Public Comment Focus Group Report [PDF, 162 KB] Public Comment Focus Group Wiki Forum Comment Period Deadlines Open Date: 31 August 2011 Close Date: Comments : 30 Sep 2011 Replies : 15 Oct 2011 (see note in Section I) Important Information Links Public Comment Box To Submit Your Comments (Forum) View Comments Submitted This ICANN announcement was sourced from: www.icann.org/en/announcements/announcement-31aug11-en.htm

The Generic Names Supporting Organization approved at its meeting on 21 July 2011 the recommendations on the Post-Expiration Domain Name Recovery Policy Development Process (PDP). The resolution, which is pending for Board action, proposes: Define ‘Registered Name Holder at Expiration’ (RNHaE) as the entity or individual that was eligible to renew the domain name registration immediately prior to expiration. If the domain name registration was modified pursuant to a term of the Registration Agreement authorizing the modification of registration data for the purposes of facilitating renewal but not at the explicit request of the registrant, the RNHaE is the entity or individual identified as the registrant immediately prior to that modification. For at least 8 consecutive days, at some point following expiration, the original DNS resolution path specified by the RNHaE, at the time of expiration, must be interrupted1 by the registrar, to the extent that the registry permits such interruptions 1, and the domain must be renewable by the RNHaE until the end of that period. This 8-day period may occur at any time following expiration. At any time during the 8 day period, the Registered Name Holder at Expiration may renew the domain with the Registrar and the Registrar, within a commercially reasonable delay, will restore the domain name to resolve to its original DNS resolution path prior to expiration. Notwithstanding, the Registrar may delete the domain at any time during the Autorenew grace period. If at any time after expiration when the Registered Name is still renewable by the RNHaE, the Registrar changes the DNS resolution path to effect a different landing website than the one used by the RNHaE prior to expiration, the page shown must explicitly say that the domain has expired and give instructions on how to recover the domain. Wording in the policy must make clear that ¡°instructions¡± may be as simple as directing the RNHaE to a specific web site. The RNHaE cannot be prevented from renewing a domain name registration as a result of WHOIS changes made by the Registrar that were not at the RNHaE.s request. The registration agreement must include or point to any fee(s) charged for the post expiration renewal of a domain name. If the Registrar operates a website for registration or renewal, it should state, both at the time of registration and in a clear place on its website, any fee(s) charged for the post-expiration renewal of a domain name or the recovery of a domain name during the Redemption Grace Period. The registration agreement and Registrar web site (if one is used) must clearly indicate what methods will be used to deliver pre- and post-expiration notifications, or must point to the location where such information can be found. What destination address/number will be used must also be specified, if applicable. Registrar must notify Registered Name Holder of impending expiration no less than two times. One such notice must be sent one month or 30 days prior to expiration (+/- 4 days) and one must be sent one week prior to expiration (+/- 3 days). If more that two alert notifications are sent, the timing of two of them must be comparable to the timings specified. Unless the Registered Name is renewed or deleted by the Registrar, at least one notification to the RNHaE, which includes renewal instructions, must be sent after expiration. Notifications of impending expiration must include method(s) that do not require explicit registrant action other than standard e-mail receipt in order to receive such notifications. With the exception of sponsored gTLDs, all gTLD Registries shall offer the Redemption Grace Period (RGP). For currently existing unsponsored gTLDs that do not currently offer the RGP, a transition period shall be allowed. All new gTLDs must offer the RGP. As part of the implementation, ICANN Staff should consider the Technical Steering Group’s Implementation Proposal (see http://www.icann.org/en/meetings/bucharest/redemption-topic.htm ) If a Registrar offers registrations in a gTLD that supports the RGP, the Registrar must allow the Registered Name Holder at Expiration to redeem the Registered Name after it has entered RGP. A transfer of a domain name during the RGP should not be allowed. In the event that ICANN gives reasonable notice to Registrars that ICANN has published web content as described in PEDNR Recommendation #16: Registrars, who have a web presence, must provide a link to the ICANN content on any website it may operate for domain name registration or renewal clearly displayed to its Registered Name Holders at least as clearly as its links to policies or notifications required to be displayed under ICANN Consensus Policies. Registrars may also host similar material adapted to their specific practices and processes. Registrar must point to the ICANN material in a communication sent to the registrant immediately following initial registration as well as in the mandated annual WHOIS reminder. Note: Some of these recommendations may need special consideration in the context of existing provisions in the Uniform Dispute Resolution Policy (UDRP), the proposed Uniform Rapid Suspension System (URS) or exceptions due to fraud, breach of registration agreement or other substantive reasons and the GNSO Council, therefore, recommends that such considerations are taken into account as part of the implementation of these recommendations, once adopted. The GNSO Council recommends the following best practices for promotion by ICANN and the Registrar Stakeholder Group: If post-expiration notifications are normally sent to a point of contact using the domain in question, and delivery is known to have been interrupted by post-expiration actions, post-expiration notifications should be sent to some other contact point associated with the registrant if one exists. The notification method explanation should include the registrar’s email address from which notification messages are sent and a suggestion that registrants save this email address as a ‘safe sender’ to avoid notification emails being blocked by spam filter software. Registrars should advise registrants to provide a secondary email point of contact that is not associated with the domain name itself so that in case of expiration reminders can be delivered to this secondary email point of contact. The GNSO Council recommends that ICANN, in consultation with Registrars, ALAC and other interested parties, will develop educational materials about how to properly steward a domain name and how to prevent unintended loss. Such material may include registrant responsibilities and the gTLD domain life-cycle and guidelines for keeping domain name records current. (PEDNR Recommendation #16). ICANN Compliance is requested to provide updates to the GNSO Council on a regular basis in relation to the implementation and effectiveness of the proposed recommendations, either in the form of a report that details amongst others the number of complaints received in relation to renewal and/or post-expiration related matters or in the form of audits that assess if the policy has been implemented as intended. The GNSO Council shall convene a PEDNR Implementation Review Team to assist ICANN Staff in developing the implementation details for the new policy should it be approved by the ICANN Board. The Implementation Review Team will be tasked with evaluating the proposed implementation of the policy recommendations as approved by the Board and is expected to work with ICANN Staff to ensure that the resultant implementation meets the letter and intent of the approved policy. If the PEDNR Implementation Review Team identifies any potential modifications to the policy or new PEDNR policy recommendations, the PEDNR Implementation Review Team shall refer these to the GNSO Council for its consideration and follow-up, as appropriate. Following adoption by the ICANN Board of the recommendations, the GNSO Secretariat is authorized to issue a call for volunteers for a PEDNR Implementation Review Team to the members of the PEDNR Working Group. You are invited to submit your comments on these recommendations until 15 September before final consideration by the ICANN Board. Section II: Background At the ICANN Meeting in Cairo in November 2008, the At-Large Advisory Committee (ALAC), voted to request an Issues Report on the subject of registrants being able to recover domain names after their formal expiration date. The ALAC request was submitted to ICANN policy staff and the GNSO Council on 20 November 2008. The Issues Report on Post-Expiration Domain Name Recovery [PDF, 422 KB] was submitted to the GNSO Council on 5 December 2008. The GNSO Council initiated a PDP on 7 May 2009 and tasked a Working Group to answer the following charter questions: Whether adequate opportunity exists for registrants to redeem their expired domain names; Whether expiration-related provisions in typical registration agreements are clear and conspicuous enough; Whether adequate notice exists to alert registrants of upcoming expirations; Whether additional measures need to be implemented to indicate that once a domain name enters the Auto-Renew Grace Period, it has expired (e.g., hold status, a notice on the site with a link to information on how to renew, or other options to be determined); Whether to allow the transfer of a domain name during the RGP. The Post-Expiration Domain Name Recovery (PEDNR) PDP Working Group started its deliberations in July 2009. The WG published an Initial Report [PDF, 1.02 MB], a Proposed Final Report [PDF, 972 KB] and submitted its Final Report [PDF, 999 KB] to the GNSO Council on 14 June 2011. The GNSO Council unanimously approved all the recommendations contained in the Final Report at its meeting on 21 July 2011. Section III: Document and Resource Links GNSO Council Resolution on the Adoption of the PEDNR Final Report and Recommendations PEDNR Final Report [PDF, 998 KB] PEDNR PDP Proposed Final Report [PDF, 972 KB] PEDNR PDP Initial Report [PDF, 1.02 MB] Comment Period Deadlines Open Date: 15 August 2011 Close Date: 15 September 2011 Important Information Links Public Comment Box To Submit Your Comments (Forum) View Comments Submitted This ICANN announcement was sourced from: www.icann.org/en/announcements/announcement-15aug11-en.htm

ICANN is today publishing a proposed version 3.0 of the Internationalized Domain Name (IDN) Implementation Guidelines [PDF, 196 KB] for public comment. The IDN Guidelines are a list of general standards that all top-level domain registries deploying IDNs are required to follow based on the Internationalized Domain Names for Applications (IDNA) protocol standard from the IETF. This draft was developed by the IDN Guidelines Revision Working Group (comprised of ccTLD and gTLD registry representatives with IDN experience supported by ICANN staff). The new draft modifies the current Version 2.2 to reflect the IDNABIS revision (”IDNA2008 protocol”) of the initial IDNA protocol (”IDNA2003″). ICANN previously published a discussion draft prior to the ICANN meeting in Cartagena, Colombia in November 2010 (see www.icann.org/en/announcements/announcement-4-15nov10-en.htm ). Section II: Background The current version of the IDN Guidelines is available at www.icann.org/en/topics/idn/implementation-guidelines.htm (version 2.2 published 26 April 2007). A redline of changes in version 3.0 against the version published November 2010 is also available at www.icann.org/en/topics/idn/idn-guidelines-discussion-draft-redline-25jul11-en.pdf [PDF, 348 KB]. Section III: Document and Resource Links Comments are welcomed from the community on version 3.0 and may be submitted to at idn-guidelines-v3-revision@icann.org by 26 August 2011 23:59 UTC. Comments may be viewed at forum.icann.org/lists/idn-guidelines-v3-revision . Section IV: Additional Information The Internationalized Domain Names for Applications (IDNA) protocol is the technical standard for the implementation of IDNs for TLD registries, registrars and software developers that make IDNs available for their customers. The IDNA protocol references and further detail about the 2008 revision can be found here: www.icann.org/en/topics/idn/rfcs.htm . Comment Period Deadlines Open Date: 27 July 2011 Close Date: 26 August 2011 Important Information Links Public Comment Box To Submit Your Comments (Forum) View Comments Submitted This ICANN announcement was sourced from: www.icann.org/en/announcements/announcement-27jul11-en.htm

Section I: Description, Explanation, and Purpose ICANN Staff is seeking comments on the Preliminary Issue Report on the Inter-Registrar Transfer Policy Part C [PDF, 572 MB]. Specifically, this Report addresses: “Change of Control” function, including an investigation of how this function is currently achieved, if there are any applicable models in the country-code name space that can be used as a best practice for the gTLD space, and any associated security concerns. It should also include a review of locking procedures, as described in Reasons for Denial #8 and #9, with an aim to balance legitimate transfer activity and security. Whether provisions on time-limiting Form Of Authorization (FOA)s should be implemented to avoid fraudulent transfers out. For example, if a Gaining Registrar sends and receives an FOA back from a transfer contact, but the name is locked, the registrar may hold the FOA pending adjustment to the domain name status, during which time the registrant or other registration information may have changed. Whether the process could be streamlined by a requirement that registries use IANA IDs for registrars rather than proprietary IDs This Public Comment solicitation represents an opportunity for the ICANN community to provide its views on the issues outlined above and on whether a Policy Development Process should be initiated. Further data and supporting information on issues b) and c) are especially welcomed as these issues were originally raised in 2005. This Preliminary Issue Report will be updated to reflect community feedback submitted through this forum. A Final Issue Report will then be presented to the Generic Names Supporting Organization (GNSO) Council for its consideration. Section II: Background The Inter-Registrar Transfer Policy (IRTP) is an existing community consensus policy that was implemented in late 2004 and is now being reviewed by the GNSO. The IRTP aims to provide a straightforward procedure for domain name holders to transfer their names from one ICANN-accredited registrar to another should they wish to do so. The policy also provides standardized requirements for registrar handling of such transfer requests from domain name holders. The IRTP Part C is the third in a series of five Policy Development Processes (PDPs) that address areas for improvements in the existing Inter-Registrar Transfer Policy.  The GNSO Council requested an Issue Report on IRTP Part C at its meeting on 22 June 2011 (see gnso.icann.org/resolutions/#201106 ). Section III: Document and Resource Links Preliminary Issue Report on the Inter-Registrar Transfer Policy Part C [PDF, 572 MB] Inter-Registrar Transfer Policy Comment Period Deadlines Open Date: 25 July 2011 Close Date: 25 August 2011 Important Information Links Public Comment Box To Submit Your Comments (Forum) View Comments Submitted This ICANN announcement was sourced from: www.icann.org/en/announcements/announcement-25jul11-en.htm

( Third proposal for handling recovered IPv4 address space) Purpose of this document This document provides a background report on the progress of an active Global Policy proposal, “Global Policy Proposal for Post Exhaustion IPv4 Allocation Mechanisms by IANA”. It is intended as a background briefing for the ICANN Board and the wider community. Introduction Global Internet Number Resource Policies are defined by the ASO MOU – between ICANN and the NRO – as “Internet number resource policies that have the agreement of all RIRs according to their policy development processes and ICANN, and require specific actions or outcomes on the part of IANA or any other external ICANN-related body in order to be implemented”. Attachment A of this MOU describes the Development Process of Global Internet Number Resource Policies, including the adoption by every RIR of a global policy to be forwarded to the ICANN Board by the ASO 1 , as well as its ratification by the ICANN Board. In this context, the ICANN Board adopted its own Procedures for the Review of Internet Number Resource Policies Forwarded by the ASO for Ratification. Among other features, these Procedures state that the Board will decide, as and when appropriate, that ICANN staff should follow the development of a particular global policy, undertaking an “early awareness” tracking of proposals in the addressing community. To this end, staff should issue background reports periodically, forwarded to the Board, to all ICANN Supporting Organizations and Advisory Committees and posted at the ICANN web site. At its meeting on 21 April 2011, the Board resolved to request tracking of the development of a “Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA”, under discussion in the addressing community. The status overview presented below is compiled in response to this request and will be further updated as developments proceed, for information to ICANN entities and the wider community. This is the second background report on this proposal. Status Overview The purpose of the proposal is to enable IANA to allocate returned IPv4 blocks to RIRs. IANA would place IPv4 blocks returned by the RIRs in a Recovered IPv4 Pool. This Pool would be declared active when one RIR has less than half its last /8 left. IANA would then allocate an “IPv4 allocation unit” (minimum size /24) to each RIR, if the Pool size so permits. If the space available in the Pool is too limited, allocation would be deferred in 6 month intervals until space is available. Following list discussions over slightly different draft versions early in 2011, the second version of this global policy proposal was first formally introduced in the APNIC region on 20 February 2011 and has since been introduced on the policy mailing lists of all the other RIRs. The proposal has been adopted in APNIC and is in discussion in the other RIRs. Process history On 3 February 2011, the ASO AC 2 recognized the proposal as fulfilling the formal requirements as a candidate for a Global Policy. Once the proposal has been adopted in all RIRs, i.e. AfriNIC, APNIC, ARIN, LACNIC and RIPE, the proposal will be handled by the NRO EC 3 and the ASO AC according to their procedures before being submitted to the ICANN Board for ratification. As a background to this policy proposal, it should be noted that a previous proposal for handling recovered IPv4 address space, “Global Policy Proposal for the Allocation of IPv4 Blocks to Regional Internet Registries” was introduced in 2009 but abandoned by the NRO EC in view of version differences across the RIRs. For more information on that proposal, see the corresponding background report . That proposal is denoted as the first proposal in the table below. Also, a second proposal on this theme “Global Policy Proposal for the Allocation of IPv4 by IANA Post Exhaustion” was introduced in 2010. This proposal was rapidly adopted in ARIN, but abandoned in APNIC and withdrawn in RIPE, making it unlikely that the proposal would advance to become a global policy. For more information on that proposal, see the corresponding background report . That proposal is denoted as the second proposal in the table below. The proposal that is the object of the current background report – for direct access to the proposal text click here [TXT, 12 KB] – is denoted as the third proposal in the table below, where the significant differences between the proposals are summarized. Proposal/features Third proposal Second proposal First proposal RIR return to IANA Not mentioned Voluntary Mandatory vs. voluntary RIR Eligibility Simultaneous for all RIRs Per RIR, when it has less than a /8 in stock Simultaneous for all RIRs ASO reference GPP-IPv4-2011 GPP-IPv4-2010 GPP-IPv4-2009 An overview of these proposals is also provided on the ASO website, see http://aso.icann.org/global-policy-proposals/ The table below outlines the steps taken within each RIR for the current proposal. Hyperlinks are included for easy access. Status of Global Policy Proposal for Post Exhaustion IPv4 Allocation Mechanisms by IANA (GPP-IPv4-2011) RIR AfriNIC APNIC ARIN LACNIC RIPE Proposal Introduced 7 Feb 2011 list message 28 April 2011 list message 25 Jan 2011 list message prop-097 20 Feb 2011 version 2 8 Mar 2011 list message prop 137 18 Mar 2011 list message prop 2011-05 21 Mar 2011   list message prop 2011-01 Discussion list Resource Policy Disc. List SIG-Policy Public Policy Mailing List Politicas – Policy Mailing List Address Policy WG Public Forum AfriNIC 14 4 – 10 June 2011 consensus APNIC 31 21  – 25 Feb 2011 consensus LACNIC XV 15 – 20 May 2011 – presentation [PDF, 241 KB] RIPE 62 2 – 6 May 2011 Final Call for Comments 1 Mar – 26 Apr 2011 27 May – 11 July 2011 Next Public Forum (AfriNIC-15 19 – 25 Nov 2011) ( APNIC 32 29 Aug  – 2 Sept 2011 ) ARIN XXVIII 12 – 14 Oct 2011 LACNIC XVI 4 – 7 Oct 2011 RIPE 63 31 Oct – 4 Nov 2011 Adoption Endorsed by APNIC EC 6 May 2011 Link to document AFPUB-2011-v4-004-draft-01 prop-097-v002 Proposal 137 LAC-2011-05 [PDF, 241 KB] (EN) LAC-2011-05 [PDF, 345 KB] (ES) LAC-2011-05 [PDF, 360 KB] (PT) Proposal 2011 – 01 Link to Policy Development Process Policy Development Process Policy Development Process Policy Development Process Policy Development Process Policy Development Process Status Consensus, awaiting final call Adopted In discussion Final call closed In discussion 1 The ASO MoU states that the NRO shall fulfill the role, responsibilities and functions of the ASO (Address Supporting Organization). 2 The ASO AC (Address Council) consists of elected representatives from each RIR’s policy making community and membership. 3 The NRO EC (Executive Council) consists of the CEOs of the five RIRs. This ICANN announcement was sourced from: www.icann.org/en/announcements/announcement-26apr11-en.htm

Section I: Description, Explanation, and Purpose The GNSO Council recently identified areas for improvement in the GNSO Council Operating Procedures gnso.icann.org/council/gnso-op-procedures-05aug10-en.pdf [PDF, 427 KB] that would simplify and clarify the procedures relating to proxy voting. At its meeting in Singapore on 22 June 2011 the GNSO Council approved a resolution https://community.icann.org/display/gnsocouncilmeetings/Motions+22+June+2011 directing Staff to produce a redlined revision of the GNSO Council Operating Procedures incorporating proposed revisions and to post this document for twenty-one (21) days in the ICANN Public Comment Forum. ICANN Staff is seeking comments on Proposed Revisions to Chapters 3 and 4 of the GNSO Council Operating Procedures Relating to Proxy Voting [PDF,158 KB]. Section II: Background The GNSO Council recently identified areas for improvement in the GNSO Council Operating Procedures http://gnso.icann.org/council/gnso-op-procedures-05aug10-en.pdf [PDF, 427 KB] that would simplify and clarify the procedures relating to proxy voting and tasked the Operations Steering Committee (OSC) with completing a revision to improve the procedures.  On 14 June 2011 the OSC submitted to the GNSO Council recommended revisions. At its meeting in Singapore on 22 June 2011 the GNSO Council acknowledged receipt of the recommended revisions submitted by the OSC and approved a resolution https://community.icann.org/display/gnsocouncilmeetings/Motions+22+June+2011 directing Staff to produce a redlined revision of the GNSO Council Operating Procedures incorporating the recommended revisions and to post this document for twenty-one (21) days in the ICANN Public Comment Forum.   The proposed revisions affect the following sections of the GNSO Council Operating Procedures:  Chapter 3 GNSO Council Meetings, Section 3.8 Absences and Vacancies; Chapter 4 Voting, Section 4.5.3 Remedies to Avoid Abstaining on a Vote; 4.5.3b Proxy Voting; and 4.5.3c Temporary Alternate. The OSC found that the original procedures could be simplified and also that they contradicted the internal procedures of certain constituencies. The OSC simplified the procedures in terms of how the proxy giver assigns a vote to the proxy holder.  In particular, the proxy giver can give the proxy to any other Councilor.  The revision does, however, maintain the requirement that a Council member is not permitted to be a proxy holder for more than one proxy giver.  The OSC also simplified the procedures in terms of the proxy vote to three rules: 1) it may either be directed, if applicable, by the proxy giver’s appointing organization; 2) the proxy giver may instruct the proxy holder how to cast the vote; 3) in the absence of any instruction the proxy holder may vote freely on conscience. Section III: Document and Resource Links GNSO Council Operating Procedures gnso.icann.org/council/gnso-op-procedures-05aug10-en.pdf [PDF, 427 KB] GNSO Council Resolution https://community.icann.org/display/gnsocouncilmeetings/Motions+22+June+2011 Proposed Revisions to Chapters 3 and 4 of the GNSO Council Operating Procedures Relating to Proxy Voting [PDF, 158 KB] Comment Period Deadlines Open Date: 19 July 2011 Close Date: 9 August 2011 Important Information Links Public Comment Box To Submit Your Comments (Forum) View Comments Submitted This ICANN announcement was sourced from: www.icann.org/en/announcements/announcement-19jul11-en.htm

The delegation and management of variant TLDs remains an important issue. The ICANN community seeks to develop solutions to enable the delegation of Variant TLDs for the benefit of users around the world.