<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta name=Generator content="Microsoft Word 12 (filtered medium)"><base href="x-msg://2565/"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=FR link=blue vlink=purple style='word-wrap: break-word;-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'><div class=WordSection1><div><div><div><div><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif";color:#1F497D'> </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>Dear All,</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'> </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>Ahead of the official Council minutes, please find the<span class=apple-converted-space> </span><a name="Motions22June2011-Motion%26nbsp%3B1onthe"></a><a name="Motions22June2011-Motion1%26nbsp%3Bonthe"></a>resolutions passed by the GNSO Council today, 22 June 2011 in Singapore:</span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'> </span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><b><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>Motion 1 on the Adoption of the IRTP Part B Final Report and Recommendations</span></b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><p class=MsoNormal style='margin-bottom:7.5pt;line-height:13.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>WHEREAS on 24 June 2009, the GNSO Council launched a Policy Development Process (PDP) on IRTP Part B addressing the following five charter questions:</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:7.5pt;line-height:13.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>a. Whether a process for urgent return/resolution of a domain name should be developed, as discussed within the SSAC hijacking report<br>(</span><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'><a href="http://www.icann.org/announcements/hijacking-report-12jul05.pdf"><span lang=EN-US style='color:windowtext'>http://www.icann.org/announcements/hijacking-report-12jul05.pdf</span></a></span><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>); see also (</span><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'><a href="http://www.icann.org/correspondence/cole-to-tonkin-14mar05.htm"><span lang=EN-US style='color:windowtext'>http://www.icann.org/correspondence/cole-to-tonkin-14mar05.htm</span></a></span><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>);</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:7.5pt;line-height:13.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>b. Whether additional provisions on undoing inappropriate transfers are needed, especially with regard to disputes between a Registrant and Admin Contact (AC). The policy is clear that the Registrant can overrule the AC, but how this is implemented is currently at the discretion of the registrar;</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:7.5pt;line-height:13.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>c. Whether special provisions are needed for a change of registrant when it occurs near the time of a change of registrar. The policy does not currently deal with change of registrant, which often figures in hijacking cases;</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:7.5pt;line-height:13.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>d. Whether standards or best practices should be implemented regarding use of a Registrar Lock status (e.g. when it may/may not, should/should not be applied);</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:7.5pt;line-height:13.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>e. Whether, and if so, how best to clarify denial reason #7: A domain name was already in 'lock status' provided that the Registrar provides a readily<br>accessible and reasonable means for the Registered Name Holder to remove the lock status.</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:7.5pt;line-height:13.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>WHEREAS this PDP has followed the prescribed PDP steps as stated in the Bylaws, resulting in a Final Report delivered on 30 May 2011;</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:7.5pt;line-height:13.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>WHEREAS the IRTP Part B WG has reached full consensus on the recommendations in relation to each of the five issues outlined above;</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:7.5pt;line-height:13.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>WHEREAS the GNSO Council has reviewed and discussed these recommendations.</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0 style='margin-left:.75pt;border-collapse:collapse'><tr><td valign=top style='border:solid #DDDDDD 1.0pt;padding:3.75pt 3.75pt 3.75pt 3.75pt'><p class=MsoNormal style='margin-bottom:3.75pt;line-height:13.0pt'><b><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>Resolved</span></b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></td></tr><tr><td valign=top style='border:solid #DDDDDD 1.0pt;border-top:none;padding:3.75pt 3.75pt 3.75pt 3.75pt;border-top-width:initial;border-top-color:initial'><div><p class=MsoNormal style='line-height:13.0pt'><b><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>RESOLVED (A)</span></b><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>, the GNSO Council recommends to the ICANN Board of Directors:<span class=apple-converted-space> </span><br>1. Requiring Registrars to provide a Transfer Emergency Action Contact (TEAC). To this end the language of section 4 (Registrar Coordination) and Section 6 (Registry Requirements of the Inter-Registrar Transfer Policy should be updated as follows:<span class=apple-converted-space> </span><br>Transfer Emergency Action Contact (Append to Section 4)<span class=apple-converted-space> </span><br>Registrars will establish a Transfer Emergency Action Contact (TEAC) for urgent communications relating to transfers. The goal of the TEAC is to quickly establish a real-time conversation between registrars (in a language that both parties can understand) in an emergency. Further actions can then be taken towards a resolution, including initiating existing (or future) transfer dispute or undo processes.<span class=apple-converted-space> </span><br>Communications to TEACs will be reserved for use by ICANN-Accredited Registrars, gTLD Registry Operators and ICANN Staff. The TEAC point of contact may be designated as a telephone number or some other real-time communication channel and will be recorded in, and protected by, the ICANN RADAR system.<span class=apple-converted-space> </span><br>Communications to a TEAC must be initiated in a timely manner, within a reasonable period of time following the alleged unauthorized loss of a domain.<span class=apple-converted-space> </span><br>Messages sent via the TEAC communication channel must generate a non-automated response by a human representative of the gaining Registrar. The person or team responding must be capable and authorized to investigate and address urgent transfer issues. Responses are required within 4 hours of the initial request, although final resolution of the incident may take longer.<span class=apple-converted-space> </span><br>The losing registrar will report failures to respond to a TEAC communication to ICANN Compliance and the registry operator. Failure to respond to a TEAC communication may result in a transfer-undo in accordance with Section 6 of this policy and may also result in further action by ICANN, up to and including non-renewal or termination of accreditation.<span class=apple-converted-space> </span><br>Both parties will retain correspondence in written or electronic form of any TEAC communication and responses, and share copies of this documentation with ICANN and the registry operator upon request. This documentation will be retained in accordance with Section 3.4 of the Registrar Accreditation Agreement (RAA). Users of the TEAC communication channel should report non-responsive Registrars to ICANN. Additionally, ICANN may conduct periodic tests of the Registrar TEAC communication channel in situations and a manner deemed appropriate to ensure that registrars are indeed responding to TEAC messages.<span class=apple-converted-space> </span><br>(Append to Section 6) 6 iv. Documentation provided by the Registrar of Record prior to transfer that the Gaining Registrar has not responded to a message via the TEAC within the timeframe specified in Section 4.<span class=apple-converted-space> </span><br>In addition, update section 6 to reflect that the registry, in case of a transfer undo, will reverse the transfer and reset the registrar of record filed to its original state (‘In such case, the transfer will be reversed and the Registrar of Record field reset to its original state'). (IRTP Part B Recommendation #1)<span class=apple-converted-space> </span><br>2. Modifying section 3 of the IRTP to require that the Registrar of Record/Losing Registrar be required to notify the Registered Name Holder/Registrant of the transfer out. The Registrar of Record has access to the contact information for the Registrant and could modify their systems to automatically send out the Standardized Form for Losing Registrars ("Confirmation FOA") to the Registrant. (IRTP Part B Recommendation #5)<span class=apple-converted-space> </span><br>3. Modifying Reason for Denial #6 as follows: Express objection to the transfer by the authorized Transfer Contact. Objection could take the form of specific request (either by paper or electronic means) by the authorized Transfer Contact to deny a particular transfer request, or a general objection to all transfer requests received by the Registrar, either temporarily or indefinitely. In all cases, the objection must be provided with the express and informed consent of the authorized Transfer Contact on an opt-in basis and upon request by the authorized Transfer Contact, the Registrar must remove the lock or provide a reasonably accessible method for the authorized Transfer Contact to remove the lock within five (5) calendar days. (IRTP Part B Recommendation #6)<span class=apple-converted-space> </span><br>4. Deleting denial reason #7 as a valid reason for denial under section 3 of the IRTP as it is technically not possible to initiate a transfer for a domain name that is locked, and hence cannot be denied, making this denial reason obsolete.<span class=apple-converted-space> </span></span><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>(IRTP Part B Recommendation #9 - part 1)</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div></td></tr><tr><td valign=top style='border:solid #DDDDDD 1.0pt;border-top:none;padding:3.75pt 3.75pt 3.75pt 3.75pt;border-top-width:initial;border-top-color:initial'><p class=MsoNormal style='margin-bottom:3.75pt;line-height:13.0pt'><b><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>RESOLVED (B),</span></b><span class=apple-converted-space><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'> </span></span><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>the GNSO Council recommends the promotion by ALAC and other ICANN structures of the measures outlined in the recent report of the Security and Stability Advisory Committee on A Registrant's Guide to Protecting Domain Name Registration Accounts (SAC 044). In particular, the GNSO Council recommends that registrants consider the measures to protect domain registrar accounts against compromise and misuse described in SAC044, Section 5. These include practical measures that registrants can implement "in house", such as ways to protect account credentials and how to incorporate domain name registrations into employee or resource management programs typically found in medium and large businesses. It suggests ways that registrants can use renewal and change notifications from registrars as part of an early warning or alerting system for possible account compromise. The GNSO Council Chair will reach out to the ALAC and other ICANN structures to inform them of this recommendation and discuss how the GNSO may contribute to this promotion.<span class=apple-converted-space> </span></span><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>(IRTP Part B Recommendation #2)</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></td></tr><tr><td valign=top style='border:solid #DDDDDD 1.0pt;border-top:none;padding:3.75pt 3.75pt 3.75pt 3.75pt;border-top-width:initial;border-top-color:initial'><p class=MsoNormal style='margin-bottom:3.75pt;line-height:13.0pt'><b><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>Resolved (C),</span></b><span class=apple-converted-space><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'> </span></span><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>the GNSO Council acknowledges receipt of IRTP Part B Recommendation #7 and will consider this recommendation when it considers the Final Issue Report on the Current State of the UDRP.</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></td></tr><tr><td valign=top style='border:solid #DDDDDD 1.0pt;border-top:none;padding:3.75pt 3.75pt 3.75pt 3.75pt;border-top-width:initial;border-top-color:initial'><p class=MsoNormal style='margin-bottom:3.75pt;line-height:13.0pt'><b><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>RESOLVED (D),</span></b><span class=apple-converted-space><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'> </span></span><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>prior to the consideration of approval of the recommendation which states: "denial reason #7 should be replaced by adding a new provision in a different section of the IRTP on when and how domains may be locked or unlocked", the GNSO Council requests ICANN Staff to provide a proposal for such a new provision, taking into account the IRTP Part B WG deliberations in relation to this issue (see IRTP Part B Final Report - (Recommendation #9 - part 2). Upon review of the proposal, the GNSO Council will consider whether to approve the recommendation.</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></td></tr><tr><td valign=top style='border:solid #DDDDDD 1.0pt;border-top:none;padding:3.75pt 3.75pt 3.75pt 3.75pt;border-top-width:initial;border-top-color:initial'><p class=MsoNormal style='margin-bottom:3.75pt;line-height:13.0pt'><b><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>RESOLVED (E),</span></b><span class=apple-converted-space><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'> </span></span><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>prior to the consideration of approval of the recommendation regarding the standardizing and clarifying WHOIS status messages regarding Registrar Lock status, the GNSO Council requests ICANN staff to provide a proposal designed to ensure a technically feasible approach can be developed to meet this recommendation. Staff should take into account the IRTP Part B WG deliberations in relation to this issue (see IRTP Part B Final Report). (IRTP Part B Recommendation #8). The goal of these changes is to clarify why the Lock has been applied and how it can be changed. Upon review of the proposed plan, the GNSO Council will consider whether to approve the recommendation.</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></td></tr><tr><td valign=top style='border:solid #DDDDDD 1.0pt;border-top:none;padding:3.75pt 3.75pt 3.75pt 3.75pt;border-top-width:initial;border-top-color:initial'><p class=MsoNormal style='margin-bottom:3.75pt;line-height:13.0pt'><b><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>Resolved (F),</span></b><span class=apple-converted-space><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'> </span></span><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>the GNSO Council will consider IRTP Part B Recommendation #3 concerning the request of an Issue Report on the requirement of 'thick' WHOIS for all incumbent gTLDs at its next meeting on 21 July.</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></td></tr><tr><td valign=top style='border:solid #DDDDDD 1.0pt;border-top:none;padding:3.75pt 3.75pt 3.75pt 3.75pt;border-top-width:initial;border-top-color:initial'><p class=MsoNormal style='margin-bottom:3.75pt;line-height:13.0pt'><b><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>RESOLVED (G),</span></b><span class=apple-converted-space><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'> </span></span><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>the GNSO Council requests an Issue Report on IRTP Part C, which should include:<span class=apple-converted-space> </span><br>- "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. (IRTP Part B Recommendation #4)<span class=apple-converted-space> </span><br>- Whether provisions on time-limiting </span><span lang=EN-US> </span><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>Form Of Authentification</span><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'> (FOA<span style='color:#1F497D'>)</span>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.<span class=apple-converted-space> </span><br>- Whether the process could be streamlined by a requirement that registries use IANA IDs for registrars rather than proprietary IDs.</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></td></tr></table><p class=MsoNormal style='margin-bottom:3.0pt'><a name="Motions22June2011-MOTION2.%26nbsp%3BRE.R"></a><b><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>MOTION 2. RE. REVISION OF THE GNSO COUNCIL OPERATING PROCEDURES RELATING TO PROXY VOTING</span></b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:7.5pt;line-height:13.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>Made by: Wolf-Ulrich Knoben<br>Seconded by: Stéphane van Gelder</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:7.5pt;line-height:13.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>WHEREAS, the GNSO Council recently identified areas for improvement in the GNSO Council Operating Procedures that would simplify and clarify the procedures relating to proxy voting;</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:7.5pt;line-height:13.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>WHEREAS, the GNSO Council tasked the Operations Steering Committee (OSC) with completing a revision to improve the procedures relating to proxy voting;</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:7.5pt;line-height:13.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>WHEREAS, the OSC submitted to the GNSO Council on 14 June 2011 recommended revisions</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:7.5pt;line-height:13.0pt'><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'><a href="http://gnso.icann.org/drafts/osc-recommended-revisions-proxy-voting-14jun11-en.pdf"><span lang=EN-US style='color:windowtext'>http://gnso.icann.org/drafts/osc-recommended-revisions-proxy-voting-14jun11-en.pdf</span></a></span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:7.5pt;line-height:13.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'> to the GNSO Council Operating Procedures to simplify and clarify the procedures relating to proxy voting;</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:7.5pt;line-height:13.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>NOW THEREFORE, BE IT:</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:7.5pt;line-height:13.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>RESOLVED, that the GNSO Council acknowledges receipt of the recommended revisions submitted by the OSC and directs Staff 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.</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:7.5pt;line-height:13.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>RESOLVED FURTHER, that the GNSO Council shall take formal action on these recommendations, including potential modification, as soon as possible after the conclusion of the public comment period. </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><div><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'> </span><span style='font-size:10.5pt;font-family:Consolas'><o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>Please let me know if you have any questions.</span><span style='font-size:10.5pt;font-family:Consolas'><o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>Thank you.</span><span style='font-size:10.5pt;font-family:Consolas'><o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>Kind regards,</span><span style='font-size:10.5pt;font-family:Consolas'><o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'> </span><span style='font-size:10.5pt;font-family:Consolas'><o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'>Glen</span><span style='font-size:10.5pt;font-family:Consolas'><o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Arial","sans-serif"'> </span><span style='font-size:10.5pt;font-family:Consolas'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>Glen de Saint Géry</span><span style='font-size:10.5pt;font-family:Consolas'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'>GNSO Secretariat</span><span style='font-size:10.5pt;font-family:Consolas'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif"'><a href="mailto:gnso.secretariat@gnso.icann.org">gnso.secretariat@gnso.icann.org</a></span><span style='font-size:10.5pt;font-family:Consolas'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:Consolas'><a href="http://gnso.icann.org">http://gnso.icann.org</a><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:Consolas'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:Consolas'> <o:p></o:p></span></p></div></div></div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>