June 2013 - ALAC - lists.icann.org

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