- ALAC - lists.icann.org

Revised Rationale for Rejection of NCSG Reconsideration Request
by Alan Greenberg June 28, 2013

June 28, 2013

I call your attention to <http://www.icann.org/en/groups/board/governance/reconsideration/recommendat…>http://www.icann.org/en/groups/board/governance/reconsideration/recommendat…. I find this revised version far more palatable. I particularly note: "... we have no intention of our Recommendation being seen as against the on-going, community-wide discussion about policy and implementation. Further, it is important to note that this Recommendation should not be construed as discounting the importance of consulting with community members. Community consultation is at the heart of the multistakeholder model, and is critical whether the community is acting as a policy development body or during the implementation of policy." This matches my belief that the current Policy vs Implementation discussion may be important, but whatever the dividing line, it does not remove the need for community involvement as long as decisions are being made which substantively affect us. Alan

1 0

Fwd: [council] Agenda ICANN Board meeting - 27 June 2013
by Alan Greenberg June 21, 2013

June 21, 2013

From: http://www.icann.org/en/groups/board/documents/agenda-27jun13-en.htm Agenda for ICANN Special Board Meeting 27 June 2013 Consent Agenda: Approval of Minutes of the 18 May Regular Meeting of the ICANN Board Redelegation of .ID Redelegation of .EE Delegation of .ÍÏÎ Appointment of Ben Butler to the Security & Stability Advisory Committee Officer Appointment Recommendation Main Agenda: AROS Contract Agreement Approval (pending BFC approval) Approval of 2013 RAA Update to the IDN ccTLD Fast Track Implementation

1 0

Agenda for Board Governance Committee meeting on 25 June 2013
by Alan Greenberg June 21, 2013

June 21, 2013

From: http://www.icann.org/en/groups/board/documents/agenda-bgc-25jun13-en.htm *Reconsideration Request 13-3

1 0

Agenda for new gTLD Program Committee meeting on 25 June 2013
by Alan Greenberg June 21, 2013

June 21, 2013

From: http://www.icann.org/en/groups/board/documents/agenda-new-gtld-25jun13-en.h… Agenda | New gTLD Program Committee 25 June 2013 Consent Agenda: * Approval of Minutes of 4 June 2013 Main Agenda: * Safeguards Applicable to all New gTLDs * Category 2 Safeguard Advice re Exclusive Registry Access * Singular & Plural Versions of the Same String as a TLD * IGO Protection * ALAC Statement on TMCH/Variants * AOB

1 0

Re: [ALAC] BGC Recommendation on Reconsideration Request 13-3
by Alan Greenberg June 19, 2013

June 19, 2013

I forward this note from Bruce Tonkin to the GNSO Council. It raises a number of issues that I think warrant discussion within the ALAC. I will give my veiw on some of these issues in a few days, but wanted to let everyone think about it in parallel. Alan >From: Bruce Tonkin <Bruce.Tonkin(a)melbourneit.com.au> >To: "council(a)gnso.icann.org" <council(a)gnso.icann.org> >Subject: [council] RE: BGC Recommendation on Reconsideration Request 13-3 >Date: Wed, 19 Jun 2013 00:35:54 +0000 > >Hello All, > >Thank you for the letter from the GNSO Council >regarding Reconsideration Request 13-3. > >Just an update. > >The Board Governance Committee had an extensive >discussion around this topic in its meeting >today. Staff will be reviewing the text of >the rationale following the discussion. The >current plan is for the Board Governance >Committee to meet again on 25 June 2013 to review the rationale. > >In terms of a discussion in Durban, I suggest we >have the discussion around GNSO advice, and >involvement of the GNSO in the implementation of >policies, outside of the context of the wording >of the rationale. I.e. I think we should >discuss this at a broader level - ie what are >the lessons learned from this case - rather than debate the case itself. > >The Board Governance Committee is also having >discussions about the broader topic and would >welcome further discussions in Durban. It is >also a useful topic for the Board as a whole, >and certainly has been a topic of the past two public ICANN meetings. > >As I see it, we have a detailed process in the >bylaws that sets out how the GNSO develops >policy recommendations, and how the Board >approves those recommendations to form ICANN >policy. The GNSO is free to create policy >recommendations using the PDP on any of the new >gTLD topics - including the trademark >clearinghouse. These policy recommendations >may change current policies, or current >implementations of policies (e.g. . various >implementation details of the transfers policy). > >As Jeff and others have pointed out, the bylaws >are less clear on how the Board and staff should >treat advice from the GNSO Council on >implementations of ICANN policies >etc. Presently this is primarily treated via >the various public comment forums but there is >no special standing for the GNSO in those >forums, and through the various meetings between >the Board and the GNSO Council at its public >meetings. There is no defined process at this >point however. In contrast the bylaws do set >out formal processes for responding to GAC >advice which frequently focus on implementation of policies. > >I note that in most of the Board/GNSO Council >meetings - both parties mostly hear the views of >individual members. There is not usually a >discussion on a formal piece of GNSO >Advice. One thing the GAC tends to do, >after meetings between the Board and the GAC, is >formulate its views as the formal GAC Communique >that is assumed to represent a consensus of the >GAC on a particular topic that was >discussed. The Board then has an option to >subsequently meet with the GAC to specifically >go through the GAC Communiqué. I believe this >will happen in Durban with respect to some >points from their Beijing Communiqué. > >Regards, >Bruce Tonkin >Chair, Board Governance Committee

1 0

Fwd: ALAC Statement to the Board Regarding Security and Stability Implications of New gTLDs
by Olivier MJ Crepin-Leblond June 12, 2013

June 12, 2013

Dear ALAC members, as you know, the ALAC has recently voted to ratify the "ALAC Statement to the Board Regarding Security an Stability Implications of New gTLDs". Prior to sending this to the ICANN Chair of the Board as well as the Chair of the New gTLD Program Committee, ICANN has made an announcement regarding "Security Studies on the Use of Non-Delegated TLDs, and Dotless Names": https://www.icann.org/en/news/announcements/announcement-28may13-en.htm With our Statement in hand, I took the opportunity of asking Julie Hammer about the opportunity to have a strongly worded cover letter accompany the ALAC Statement to be sent to the Chairs mentioned above. At the end of last week, I have worked in haste with the Executive Committee as well as our ALAC Liaison to the SSAC, to draft such a letter and with time being of the essence, since our Statement was completed a week earlier, I have sent the Statement plus the strong Cover Letter to the Board Chair, New gTLD Programme Committee Chair, copying the GAC Chair, the ICANN CEO, the SSAC Chair and the ATRT2 Chair. If you believe that we should send an even stronger message, I offer that the ALAC could decide to use parts of the cover letter to generate another ALAC Statement. So far, I have not received a reply from the Board but it is early days to judge response, considering the importance of the message conveyed. May I suggest to see what kind of response we receive to our earlier Statement prior to issuing another Statement? Having been unavailable over the week end, I apologise for the time it took me to forward this to you but in the interest of transparency it is important that you are aware of this concern and of the fact that we are pushing hard to make sure the message is understood and taken into account by ICANN. The Security and Stability of the Internet's domain name identifiers is of utmost importance. Best regards, Olivier MJ Crépin-Leblond ALAC Chair -------- Original Message -------- Subject: ALAC Statement to the Board Regarding Security and Stability Implications of New gTLDs Date: Fri, 07 Jun 2013 18:38:26 +0200 From: Olivier MJ Crepin-Leblond <ocl(a)gih.com> To: Steve Crocker <steve(a)*.com>, Cherine Chalaby <cherine(a)*.co.uk> CC: Heather.Dryden Dryden <Heather.Dryden(a)*.*.ca>, Fadi Chehade <fadi.chehade(a)*.org>, Patrik Fältström <patrik(a)*.se>, Brian Cute <bcute(a)*.org>, Olivier MJ Crepin-Leblond <ocl(a)*.com>, ICANN AtLarge Staff <staff(a)*.*.org> Dear Steve, Dear Cherine, please be so kind to find attached: - a "correspondence" which raises several points which I am sending you with the support of the ALAC Executive Committee; - an ALAC Statement to the Board Regarding Security and Stability Implications of New gTLDs which should be shared with the Board The correspondence serves as a cover letter to the ALAC Statement. In the absence of an actual open public comment process at this point in time, the ALAC is submitting this Statement directly to you, in line with its ability to submit its Advice to the Board at any time. The issue raised in this Statement is of high priority and we therefore look forward to a response from the ICANN Board on the Matter. Best regards, Olivier MJ Crépin-Leblond ALAC Chair

2 2

Draft ALAC Statement on the Implementation of IDN Variant Top Level Domains
by Rinalia Abdul Rahim June 10, 2013

June 10, 2013

Dear IDN Working Group Members and ALAC Colleagues, In response to the ICANN Board's request for guidance on the implementation of IDN Variant TLDs as well as the release of the “IDN Variant TLD Program - Risk Analysis Studies” dated May 2013, Edmon and I have developed a draft statement for the ALAC's consideration. Text of the drafted statement is pasted below. WIKI Page for your comments is located here: https://community.icann.org/display/alacpolicydev/ALAC+Statement+on+the+Imp… Please try your best to provide your comments via the wiki by June 16th. Best regards, Rinalia *ALAC Statement on the Implementation of IDN Variant Top Level Domains * *[Version 10 June 2013]* The ICANN Board has requested guidance from the community regarding the implementation of the Recommendations contained within the Report on User Experience Implications of Active Variant TLDs ( http://www.icann.org/en/groups/board/documents/prelim-report-11apr13-en.htm…) After reviewing the Report as well as the “IDN Variant TLD Program - Risk Analysis Studies” dated May 2013, the At-Large Advisory Committee (ALAC) advises the following: *Introduce IDN Variant TLDs carefully and implement complementary IDN policies concurrently * - Facilitate the introduction of IDN Variant TLDs carefully so as to nurture growth of the IDN market. The successful implementation of the initial set of IDN TLDs and IDN Variant TLDs will create higher visibility for IDNs and can be expected to stimulate further demand. - The prioritized implementation of IDN new gTLDs must be accompanied with the concurrent execution of complementary and enabling policies, specifically: - Implementation of policies that support the Universal Acceptance of IDNs, - Implementation of IDN Variant TLDs; and - Inclusion of IDN variant support in the Trademark Clearinghouse (TMCH). * * *Bundle the delegation of TLDs and variant TLDs appropriately* - In cases where variants are well defined and understood, and where they are essential for the communication needs of user communities, IDN Variant TLDs must be delegated together with IDN TLDs to ensure consumer trust among the implicated user communities. - Concurrently, variant support in the Trademark Clearinghouse (TMCH) must be included in time to accommodate the delegation of appropriate TLDs to address the issues of user confusion as well as effective trademark protection. *Prepare user communities via dedicated outreach* - Release appropriate educational materials and conduct awareness-raising initiatives widely on the use and impact of variants on different user communities well in advance of IDN Variant TLD delegation. - These outreach efforts should target IDN users as well as non-IDN users to address any trust issues that they may have. See the following as an example of research findings indicating the need for more education and awareness-raising about IDNs in developed economies - http://www.domainnews.com/en/afilias-research-75-of-uk-and-us-consumers-obl… . *Demonstrate a strong commitment to multilingualism * The introduction of IDN Variant TLDs is a policy choice, which requires the strong commitment of ICANN and the ICANN community to multilingualism. The competing perspectives between the technical (conservative) and linguistic (comprehensive) communities need to be balanced carefully within an overarching commitment to multilingualism. A demonstrated commitment to multilingualism will encourage collaboration between the two communities in finding workable solutions and common ground in introducing IDN Variant TLDs without undermining the security and stability of the Domain Name System. *Expedite the implementation of the Root LGR process * - Expedite the implementation of the Label Generation Rules (LGR) process for the Root Zone to address the risks that have been identified in the “IDN Variant TLD Program - Risk Analysis Studies.” - Ensure that lack of expertise is not a reason for delaying or prolonging the implementation of the process. The inadequate supply and availability of the right kind of experts have been identified as a possible bottleneck for the Root LGR process. We note that a call for subject matter experts has been issued on 6 June 2013. Should the response prove to be inadequate, measures would be required to seek expertise outside of the ICANN community. - Expedite the delivery of the Han script ruleset in the Root LGR process. Among all the writing systems studied by ICANN in the IDN Variant Issues Project* (*VIP), the Han script variants are the most well defined and understood. ICANN experts (Andrew Sullivan and Asmus Freytag) concurred during the ICANN 46th Meeting in Beijing that the Han script is possibly the only exception in this regard. * * *Involve the community in the governance of the Root LGR Process* Involve the ICANN community (Supporting Organizations and Advisory Committee) in the implementation planning and delivery of IDN Variant TLDs as well as in the governance oversight of the Label Generation Rules (LGR) for the Root Zone process, which is crucial for deriving a comprehensive and consistent treatment for variants across the board. In particular, - Ensure that the LGR process is accountable and transparent. - Address its weaknesses (i.e., the lack of a review and appeals process, insufficient supply and availability of experts as well as mechanisms for avoiding capture) - Address the weaknesses of the ICANN Public Comments process (a core feedback mechanism for the LGR process) to enable a more open and meaningful stakeholder participation. The ALAC’s advice as indicated above is consistent with the following statements that we have issued regarding IDNs and IDN Variants: - ALAC Statement on Trademark Clearinghouse and IDN Variants - ALAC Statement on IDN Variant TLD Program – Interim Report Examining the User Experience Implications of Active Variant TLDs<https://community.icann.org/download/attachments/2261148/ALAC%2BStatement%2…> - ALAC Statement on the IDN Variant TLD Program – Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels<https://community.icann.org/display/alacdocs/ALAC+Read+Only+Document+Store>- Second Public Comment Draft - ALAC Statement on the IDN Variant TLD Program – Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels<https://community.icann.org/download/attachments/2261148/ALAC+Statement+on+…> - ALAC Statement on the Draft Recommendations Overall Policy for the Selection of IDN ccTLD Strings<https://community.icann.org/display/alacdocs/ALAC+Read+Only+Document+Store> - ALAC Statement on the IDN Prioritization in the New gTLD Program Targeted at the ICANN Board<https://community.icann.org/download/attachments/2261148/ALAC+Statement+on+…> - ALAC Statement on the Internationalized Domain Name (IDN) Variant Issues Project (VIP) Proposed Project Plan for Next Steps<https://community.icann.org/download/attachments/2261148/ALAC+Statement+on+…> END

1 0

Fwd: Re: [council] Discussion Item: Changes to ICANN Bylaws
by Alan Greenberg June 6, 2013

June 6, 2013

My reply (issued purely on my own behalf). I strongly support this move, since to not do so implies that the GNSO PDP is the ONLY way to enact gTLD policy, and I strongly feel that this should not be the case. There must be faster methods when the rigour of the PDP is not required, or where the WG model has proven to be unsatisfactory. As you will see, I am also supporting the de facto process of having the community involved in substantive implementations. This has been the practice until the recent TM+5o proposal, and it is essential that staff do not have the option of ignoring the community if something does not meet the "policy" definition. That makes it a "multi-stakeholder unless we want to ignore them model" and that is not what we all put our time and effort in for. I request that the ALAC take time in its future discussions (whether e-mail, wiki, teleconference or Durban) to discuss these issues and consider issuing advice to the Board. Alan >Date: Thu, 06 Jun 2013 11:58:31 -0400 >To: "Neuman, Jeff" <Jeff.Neuman(a)neustar.us>, >"'GNSO Council (council(a)gnso.icann.org)'" <council(a)gnso.icann.org> >From: Alan Greenberg <alan.greenberg(a)mcgill.ca> >Subject: Re: [council] Discussion Item: Changes to ICANN Bylaws >Cc: "Neuman, Jeff" <Jeff.Neuman(a)neustar.us> > >As a member of the PDP development team and as >someone who has long preached that the formal >PDP should not be the only way to develop policy >(if it is not to be a picket-fence Consensus >Policy or utilized the 2/3 rejection clause), I support this. > >Although perhaps this is a separate discussion, >I would go further, and put an onus on ICANN and >the Board to discus substantive issues of >implementation with the GNSO and the community. >The multi-year New gTLD implementation and the >STI in particular establish this precedent, and >it should be enshrined in the Bylaws. > >Alan (speaking on my own behalf) > >At 06/06/2013 11:29 AM, Neuman, Jeff wrote: >>All, >> >>In the rationale used in the BGCs >>recommendation against the NCSGs Reconsideration Request, the BGC argues that: >> >>There is no defined policy process within >>ICANN that requires Board or staff consultation >>with the GNSO Council if the Board or staff is >>acting in contravention to a statement made by >>the GNSO Council outside of the Policy >>Development Process. Therefore, even if >>staffs action here was in direct contravention >>to the GNSO Council statement in a letter, the >>Bylaws requirement for consultation does not apply >> >>Technically and legally, the BGC is >>correct. As much as this goes against the very >>nature of the multi-stakeholder model (and >>frankly the message ICANN delivers to the >>world), the ICANN Board/staff is free to ignore >>the GNSO Council (and thus has no >>accountability for these actions). This is >>true despite the fact that the Bylaws also >>state: There shall be a policy-development >>body known as the Generic Names Supporting >>Organization (GNSO), which shall be responsible >>for developing and recommending to the ICANN >>Board substantive policies relating to generic >>top-level domains. Therefore, what the BGC is >>telling us is that despite the fact that the >>Bylaws charges the GNSO with developing and >>recommending substantive policies, it can >>ignore the GNSO community at any time if the >>issue did not go through a formal PDP. >> >>I personally believe that is >>broken. Therefore, I would like for the >>Council to consider recommending to the ICANN >>Board a change to the Bylaws for an additional >>measure of accountability that at a minimum >>would require some form of consultation if the >>GNSO Council (on behalf of the GNSO Community) >>issues a recommendation or develops policy >>outside of a formal PDP. As the former chair >>of the PDP Working Group that helped revise the >>PDP process, I can tell you that we were >>encouraged by the community to allow other >>mechanisms for developing policy outside of >>formal PDPs. We spent countless hours on this >>very topic. Yes, if it does not go through a >>formal PDP, it may not trigger a 2/3 Board vote >>to overturn the recommendation, but it was >>never our intention that after going through >>that process, the Board to IGNORE the GNSO >>Community. At a time when the community is >>trying to find ways to develop policies outside >>of the stringent PDP, this is NOT an incentive for doing that. >> >>Therefore, I would like to see the following >>changes made to the Bylaws (no pride in >>authorship hereso feel free to suggest other >>words). This is language that is VERY similar >>to the language the GAC has in the Bylaws: >> >> >> >>The substantive policies and recommendations of >>the Generic Names Supporting Organization >>relating to generic top-level domains shall be >>duly taken into account, both in the >>formulation and adoption of policies, whether >>or not the policy development process as set >>forth in Article X, section 6 were followed. In >>the event that the ICANN Board determines to >>take an action that is not consistent with the >>GNSO policies or recommendations, it shall so >>inform the GNSO and state the reasons why it >>decided not to follow that advice. The GNSO and >>the ICANN Board will then try, in good faith >>and in a timely and efficient manner, to find a >>mutually acceptable solution. If no such >>solution can be found, the ICANN Board will >>state in its final decision the reasons why the >>GNSO recommendations or policies were not followed. >> >>If the multi-stakeholder model truly has any >>meaning, I view these changes as >>non-controversial and essential to preserve >>what so many have so long been advocating. >> >>Thanks. >> >>Jeffrey J. Neuman >>Neustar, Inc. / Vice President, Business Affairs >>46000 Center Oak Plaza, Sterling, VA 20166 >>Office: +1.571.434.5772 Mobile: >>+1.202.549.5079 Fax: +1.703.738.7965 / >><mailto:jeff.neuman@neustar.biz>jeff.neuman(a)neustar.biz / www.neustar.biz >>

1 0

Fwd: [council] Discussion Item: Changes to ICANN Bylaws
by Alan Greenberg June 6, 2013

June 6, 2013

I call your attention to this recent message. It follows one asking the Board New gTLD Committee to defer acting on the NCSG decision until after the next GNSO Council meeting, to allow the GNSO to discuss the issue (http://gnso.icann.org/mailing-lists/archives/council/msg14630.html) a request that the Chair of the New gTLD Committee has agreed to. I will follow this message with my reply in which I support this change. We have long made the case that the PDP should not be the only way to enact policy, and this action of the BGC does serve to negate that effort. Alan >From: "Neuman, Jeff" <Jeff.Neuman(a)neustar.us> >To: "'GNSO Council (council(a)gnso.icann.org)'" <council(a)gnso.icann.org> >CC: "Neuman, Jeff" <Jeff.Neuman(a)neustar.us> >Subject: [council] Discussion Item: Changes to ICANN Bylaws >Date: Thu, 6 Jun 2013 15:29:34 +0000 > >All, > >In the rationale used in the BGCs >recommendation against the NCSGs Reconsideration Request, the BGC argues that: > >There is no defined policy process within ICANN >that requires Board or staff consultation with >the GNSO Council if the Board or staff is acting >in contravention to a statement made by the GNSO >Council outside of the Policy Development >Process. Therefore, even if staffs action here >was in direct contravention to the GNSO Council >statement in a letter, the Bylaws requirement for consultation does not apply > >Technically and legally, the BGC is correct. As >much as this goes against the very nature of the >multi-stakeholder model (and frankly the message >ICANN delivers to the world), the ICANN >Board/staff is free to ignore the GNSO Council >(and thus has no accountability for these >actions). This is true despite the fact that >the Bylaws also state: There shall be a >policy-development body known as the Generic >Names Supporting Organization (GNSO), which >shall be responsible for developing and >recommending to the ICANN Board substantive >policies relating to generic top-level >domains. Therefore, what the BGC is telling us >is that despite the fact that the Bylaws charges >the GNSO with developing and recommending >substantive policies, it can ignore the GNSO >community at any time if the issue did not go through a formal PDP. > >I personally believe that is broken. Therefore, >I would like for the Council to consider >recommending to the ICANN Board a change to the >Bylaws for an additional measure of >accountability that at a minimum would require >some form of consultation if the GNSO Council >(on behalf of the GNSO Community) issues a >recommendation or develops policy outside of a >formal PDP. As the former chair of the PDP >Working Group that helped revise the PDP >process, I can tell you that we were encouraged >by the community to allow other mechanisms for >developing policy outside of formal PDPs. We >spent countless hours on this very topic. Yes, >if it does not go through a formal PDP, it may >not trigger a 2/3 Board vote to overturn the >recommendation, but it was never our intention >that after going through that process, the Board >to IGNORE the GNSO Community. At a time when >the community is trying to find ways to develop >policies outside of the stringent PDP, this is NOT an incentive for doing that. > >Therefore, I would like to see the following >changes made to the Bylaws (no pride in >authorship hereso feel free to suggest other >words). This is language that is VERY similar >to the language the GAC has in the Bylaws: > > > >The substantive policies and recommendations of >the Generic Names Supporting Organization >relating to generic top-level domains shall be >duly taken into account, both in the formulation >and adoption of policies, whether or not the >policy development process as set forth in >Article X, section 6 were followed. In the event >that the ICANN Board determines to take an >action that is not consistent with the GNSO >policies or recommendations, it shall so inform >the GNSO and state the reasons why it decided >not to follow that advice. The GNSO and the >ICANN Board will then try, in good faith and in >a timely and efficient manner, to find a >mutually acceptable solution. If no such >solution can be found, the ICANN Board will >state in its final decision the reasons why the >GNSO recommendations or policies were not followed. > >If the multi-stakeholder model truly has any >meaning, I view these changes as >non-controversial and essential to preserve what >so many have so long been advocating. > >Thanks. > >Jeffrey J. Neuman >Neustar, Inc. / Vice President, Business Affairs >46000 Center Oak Plaza, Sterling, VA 20166 >Office: +1.571.434.5772 Mobile: >+1.202.549.5079 Fax: +1.703.738.7965 / ><mailto:jeff.neuman@neustar.biz>jeff.neuman(a)neustar.biz / www.neustar.biz >

1 0

Re: [ALAC] [ALAC-Announce] VOTE ANNOUNCEMENT: ALAC Statement on the Proposed Final 2013 RAA
by Olivier MJ Crepin-Leblond May 30, 2013

May 30, 2013

Dear All, you will have seen the Vote Announcement below in your mailbox a week ago. Furthermore, you will have heard during the ALAC monthly call that a few amendments were to be made, although the vote had already started. As a result, we have extended the voting time until 3 June 2013. The amendments are as follows: > While we are inclined to support all the major accompanying documents > with the Contract, the details of some specifications very critical to > deciding our full support remain in limbo. The Privacy/Proxy > Specifications is one such example. > > Until such time as these are decided, this Statement records our > qualified support for the Final RAA 2013 as published. replaced by > While we are inclined to support all the major accompanying documents > with the Contract, we regret that some areas, such as the > Privacy/Proxy Specifications, did not go further in defining > registrant rights and obligations that would conserve the public > interest. and > Nevertheless, some have argued the intent in this clause undermines > the consensus policy making that has produced this RAA. replaced by > Nevertheless, some have argued the intent in this clause undermines > the bottom-up multi-stakeholder model on which ICANN is built. You can see the redlined changes on: https://community.icann.org/pages/diffpages.action?pageId=41880001&original… This is what ALAC members need to do before 3 June: - If you have not voted, please review the latest statement and vote. - If you have voted already and do not wish to change your vote, do nothing. - If you have voted already and wish to change your vote, email matt.ashtiani(a)icann.org with your new vote This statement was very important so it was important that we get the language right. I appreciate the length to which the main pen-holders of this Statement went to reach consensus. Best regards, Olivier MJ Crépin-Leblond ALAC Chair On 23/05/2013 23:54, ICANN At-Large Staff wrote: > Dear All, > > Olivier Crépin-Leblond, Chair of the ALAC, has asked that a vote be held by the ALAC on the proposed "ALAC Statement on the Proposed Final 2013 RAA<https://community.icann.org/x/wQl-Ag>" for communication to the relevant parties. > > ***** > Question: Do you support the ratification of the "ALAC Statement on the Proposed Final 2013 RAA<https://community.icann.org/x/wQl-Ag>" for communication to the relevant parties? > ***** > > Additional information on this Statement can be found on the At-Large Proposed Final 2013 RAA Workspace<https://community.icann.org/x/wQl-Ag>. > > Please note that the poll will be open from 23-May-2012 23:59 UTC to 30-May-2012 23:59 UTC. > > Regards, > > Heidi Ullrich, Silvia Vivanco, Matt Ashtiani, Gisella Gruber, Nathalie Peregrine and Julia Charvolen > ICANN Policy Staff in support of ALAC > > E-mail: staff(a)atlarge.icann.org<mailto:staff@atlarge.icann.org> > _______________________________________________ > ALAC-Announce mailing list > ALAC-Announce(a)atlarge-lists.icann.org > https://atlarge-lists.icann.org/mailman/listinfo/alac-announce > > At-Large Official Site: http://www.atlarge.icann.org > -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html

1 0