ICANN/GNSO GNSO Email List Archives

[council]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [council] Resolutions from ICANN Board meeting on 25 Aug


Thanks Bruce.

The rationale provided is very useful and a good development IMO.

Stéphane



Le 31 août 2011 à 00:01, Bruce Tonkin a écrit :

> 
> Hello All,
> 
> Below are the board resolutions from the  Board meeting of 25 August 2011.
> 
> Resolutions relevant to the GNSO include:
> 
> - approving the GNSO policy recommendation on transfers
> 
> - an update on the process for single character IDNs at the top level - with 
> the expectation that the work won't be complete in time for the Jan 2012 new 
> gTLD round
> 
> Regards,
> Bruce Tonkin
> 
> 
> 
> 
> From: http://www.icann.org/en/minutes/resolutions-25aug11-en.htm
> 
> Board Resolutions  Special Meeting of the ICANN Board
> 
> 25 August 2011
> 
> * Note: Where available, draft Rationale of the Board's actions is presented 
> under the associated Resolution. The draft Rationale is not final until 
> approved with the minutes of the Board meeting.
> 
> 1.Consent Agenda
> 
> 1.1. Approval of Minutes of 28 July 2011 ICANN Board Meeting
> 
> 1.2. Approval of Recommendation of GNSO Council on IRTP Part B
> Rationale for Resolutions 2011.08.25.02-05
> 
> 1.3. Approval of Receipt of Report from TR-WG
> Rationale for Resolution 2011.08.25.06
> 
> 2.Approval of NomCom Chair & Chair-Elect
> Rationale for Resolution 2011.08.25.07
> 
> 3.Approval of BGC Recommendation re Reconsideration Request 11-1
> Rationale for Resolution 2011.08.25.08
> 
> 4.Process Steps for Consideration of Board Remuneration
> Rationale for Resolutions 2011-08-25-09 – 15
> 
> 5.Single Character IDN Update
> Rationale for Resolution 2011.08.25.16
> 
> 
> 1.   Consent Agenda
> 
> 
> Resolved, the following resolutions in this Consent Agenda are approved:
> 
> 
> 1.1. Approval of Minutes of 28 July 2011 ICANN Board Meeting
> ============================================================
> 
> Resolved (2011.08.25.01), the Board approves the minutes of the 28 July 2011 
> ICANN Board Meeting.
> 
> 
> 1.2. Approval of Recommendation of GNSO Council on IRTP Part B
> ==============================================================
> 
> Whereas on 24 June 2009, the GNSO Council launched a Policy Development 
> Process (PDP) on the Inter-Registrar Transfer Procedure Part B (IRTP Part B) 
> addressing five charter questions, set forth at 
> https://community.icann.org/display/gnsoirtpb/3.+WG+Charter;
> 
> Whereas the PDP followed the prescribed PDP steps as stated in the Bylaws, 
> resulting in a Final Report delivered on 30 May 2011;
> 
> Whereas the IRTP Part B Working Group (WG) reached full consensus on the 
> recommendations in relation to each of the five issues outlined in the 
> Charter;
> 
> Whereas the GNSO Council reviewed, and discussed the recommendations of the 
> IRTP Part B WG, and adopted the Recommendations on 22 June 2011 by a 
> Supermajority and unanimous vote (see: 
> http://gnso.icann.org/resolutions/#201106);
> 
> Whereas the GNSO Council vote met and exceeded the required voting threshold 
> to impose new obligations on ICANN contracted parties.
> 
> Whereas after the GNSO Council vote, a 30-day public comment period was held 
> on the approved recommendations, and the comments have been summarized and 
> considered 
> (http://www.icann.org/en/public-comment/irtp-b-recommendations-08jul11-en.htm).
> 
> Resolved (2011.08.25.02) the Board adopts the GNSO Council Policy 
> Recommendations amending the Inter-Registrar Transfer Policy set forth at 
> http://www.icann.org/en/transfers/policy-en.htm.
> 
> Resolved (2011.08.25.03) the CEO is to develop and complete an implementation 
> plan for these Recommendations and continue communication with the community 
> on such work.
> 
> Resolved (2011.08.25.04) the CEO is directed to undertake the studies 
> identified by the GNSO Council at [identify resolutions here] to facilitate 
> further work on this issue.
> 
> Resolved (2011.08.25.05) the Board encourages the GNSO, the ALAC and all 
> other parts of the ICANN community to work together to promote the measures 
> outlined in the SSAC's report A Registrant's Guide to Protecting Domain Name 
> Registration Accounts (SAC 044), as identified within the GNSO Council 
> Resolutions.
> 
> 
> Rationale for Resolutions 2011.08.25.02-05
> 
> Why the Board is addressing the issue now?
> The Inter-Registrar Transfer Policy (IRTP) is a consensus policy that was 
> adopted in 2004 which provides for a straightforward process for registrants 
> to transfer domain names between registrars. The GNSO Council established a 
> series of five Working Groups (Parts A through E) to review and consider 
> various revisions to this policy.
> 
> The IRTP Part B PDP is the second in a series of five scheduled PDPs 
> addressing areas for improvements in the existing policy. The IRTP Part B 
> Working Group has addressed five issues focusing on domain hijacking, the 
> urgent return of an inappropriately transferred name, and lock status. The 
> IRTP Part B PDP Final Report received unanimous consensus support from the 
> IRTP Part B Working Group as well as the GNSO Council. Following the closing 
> of the public comment period on 8 August, the next step as outlined in Annex 
> A of the ICANN Bylaws is consideration by the ICANN Board of the 
> recommendations.
> 
> What is the proposal being considered?
> The following recommendations are being considered:
> ◦Requiring Registrars to provide a Transfer Emergency Action Contact (TEAC). 
> To this end proposed language to modify section 4 (Registrar Coordination) 
> and Section 6 (Registry Requirements) of the Inter-Registrar Transfer Policy 
> has been provided (see Annex for further details). The Transfer Emergency 
> Action Contact (TEAC) is a mechanism to facilitate urgent communications 
> relating to transfers. The goal of the TEAC is to quickly establish real time 
> communication between registrar representatives in case of emergency such as 
> a transfer as a result of a domain name hijacking so that the registrar can 
> take steps to resolving the issue. The TEAC only addresses establishing that 
> communication not resolving any disputes that may arise for which other 
> policies and procedures apply.
> ◦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. Requiring this notification would 
> alert the registrant at an earlier stage that a transfer has been requested, 
> which as a result would bring any potential conflicts to light before a 
> transfer has been completed and therefore might reduce the number of 
> conflicts between the admin contact and registrant that would require undoing 
> a transfer.
> ◦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. The 
> current language of denial reason #6 is not clear and leaves room for 
> interpretation especially in relation to the term ‘voluntarily' and it is 
> therefore recommended that this language is expanded and clarified to tailor 
> it more to explicitl!
> y address registrar-specific (i.e. non-EPP) locks in order to make it clear 
> that the registrant must give some sort of informed opt-in express consent to 
> having such a lock applied, and the registrant must be able to have the lock 
> removed upon reasonable notice and authentication.
> ◦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.
> 
> Which stakeholders or others were consulted?
> Public comment forums were held on the initiation of the PDP, the Initial 
> Report, the proposed Final Report and the recommendations subject to Board 
> Consideration, in additional to regular updates to the GNSO Council as well 
> as workshops to inform and solicit the input from the ICANN Community at 
> ICANN meetings (see for example, Brussels Meeting and San Francisco Meeting). 
> Constituency / Stakeholder Group Statements were submitted (see 
> https://community.icann.org/display/gnsoirtpb/IRTP+Part+B). All comments 
> received have been reviewed and considered by the IRTP Part B PDP WG (see 
> section 6 of the IRTP Part B Final Report [PDF, 972 KB]). In addition, as 
> prescribed by the ICANN Bylaws, a public comment forum was held on the 
> recommendations to be considered by the ICANN Board.
> 
> What concerns or issues were raised by the community?
> The only concern raised as part of the public comment forum on the 
> recommendations to be considered by the ICANN Board was with regard to the 
> four hour response time required as part of the Transfer Emergency Action 
> Contact (TEAC) recommendation. The commenter noted that it would put ‘too 
> much burden on small and medium sized registrars'. However, the commenter 
> seemed to assume that a resolution is required within four hours (‘A final 
> solution/ settlement can take place also after 1 or 2 days') instead of an 
> initial response, which is the only requirement under the proposed TEAC. As 
> the IRTP Part B PDP Working Group explained it in its Final Report ‘the goal 
> of the TEAC is to quickly establish real time communication between registrar 
> representatives who can take steps to resolving the issue, but this policy 
> only addresses establishing that communication not resolving any disputes 
> that may arise'. With regard to the four hour response time, the IRTP Part B 
> PDP Working!
>  Group noted that ‘even the smallest of registrars can simply rotate this 
> function among operational staff, just as they rotate other "emergency" 
> aspects of their business. The number of TEAC requests is likely to be very 
> small and quite infrequent, but when they occur there is a genuine emergency 
> that needs to be dealt with quickly'. It should be noted that both small as 
> well as big registrars participated in the deliberations of the IRTP Part B 
> Working Group and supported the recommendations.
> 
> What significant materials did the Board review?
> The Board reviewed the GNSO Council Report to the Board, as well as the 
> summary of public comments and Staff's response to those comments.
> 
> What factors the Board found to be significant?
> The recommendations were developed following the GNSO Policy Development 
> Process as outlined in Annex A of the ICANN Bylaws and have received the 
> unanimous support from the GNSO Council. As outlined in the ICANN Bylaws, the 
> Council's unanimous (supermajority) support for the motion obligates the 
> Board to adopt the recommendation unless by a vote of more than 66%, the 
> Board determines that the policy is not in the best interests of the ICANN 
> community or ICANN. In addition, transfer related issues are the number one 
> area of complaint according to data from ICANN Compliance. Improvements to 
> the IRTP have the potential to reduce the number of complaints, in addition 
> to providing clarity and predictability to registrants as well as registrars.
> 
> Are there positive or negative community impacts?
> Improvements to the IRTP have the potential to reduce the number of 
> complaints, in addition to providing clarity and predictability to 
> registrants as well as registrars. Adoption of the recommendations will 
> require changes in processes for registrars, but these are considered to have 
> a minimum impact and necessary in order to address the issues that are part 
> of this Policy Development Process. The recommendations, if implemented, 
> would usefully clarify and enhance the IRTP, to the advantage of all parties 
> concerned.
> 
> Are there fiscal impacts or ramifications on ICANN (strategic plan, operating 
> plan, budget); the community; and/or the public?
> Apart from those changes required in process for registrars as outlined 
> above, no other fiscal impacts or ramifications on ICANN; the community; 
> and/or the public are expected.
> 
> Are there any security, stability or resiliency issues relating to the DNS?
> There are no security, stability, or resiliency issues related to the DNS if 
> the Board approves the proposed recommendations.
> 
> 
> 
> 1.3. Approval of Receipt of Report from TR-WG
> ==============================================
> 
> Whereas, on 18 March 2011, the Board received a final report from the 
> independent reviewer for the TLG Review and resolved to establish a Board 
> Technical Relations Working Group, BTRWG, to address the recommendations of 
> the TLG Review final report. (Resolutions 2011.03.18.28-31)
> 
> Whereas, on 21 April 2011, the Board resolved to adopt the membership of the 
> BTRWG and the Charter for the BTRWG. (Resolutions 2011.04.21.05 and 
> 2011.04.21.12).
> 
> Whereas, the BTRWG has provided its draft final report, "Draft Final Report 
> from the Board Technical Relations Working Group", dated 22 August 2011, and 
> submitted it to the ICANN Board for consideration.
> 
> RESOLVED (2011.08.25.06), the Board acknowledges receipt of the document 
> "Draft Final Report from the Board Technical Relations Working Group", dated 
> 22 August 2011, thanks the BTRWG for its timely work and directs the SIC to 
> analyze the report and propose a course of action.
> 
> 
> Rationale for Resolution 2011.08.25.06
> 
> The proposed actions are in direct response to a request from the Board and 
> serve to advance the work on improvements in line with the agreed time plan. 
> The actions to be taken do not entail any budgetary consequences in and of 
> themselves, nor any potential negative effects. It is important to take these 
> actions now to timely prepare for future restructuring actions to be proposed 
> for the Board's consideration and decision.
> 
> 
> 2.  Approval of NomCom Chair & Chair-Elect
> ==========================================
> 
> 
> Whereas, the BGC has reviewed the Expressions of Interest from candidates for 
> the Nominating Committee ("NomCom") Chair and Chair-Elect.
> 
> Whereas, the BGC agreed upon a short list of candidates and invited 
> interested Board members to participate in interviews with those candidates, 
> which resulted in recommendations to the Board.
> 
> Resolved (2011.08.25.07), the Board adopts the recommendation of the BGC and 
> hereby appoints Vanda Scartezini as the 2012 NomCom Chair and Rob Hall as the 
> 2012 NomCom Chair-Elect.
> 
> 
> Rationale for Resolution 2011.08.25.07
> 
> ICANN's Bylaws require the Board to appoint the Nominating Committee (NomCom) 
> Chair and NomCom Chair-Elect. See Article VII, sections 2.1 and 2.2 at 
> http://www.icann.org/en/general/bylaws.htm#VII. The Board has delegated the 
> responsibility for recommending the NomCom Chair and Chair-Elect for Board 
> approval to the Board Governance Committee. See BGC Charter at 
> http://www.icann.org/en/committees/board-governance/charter.htm. The BGC 
> posted a call for expressions of interest (EOI), received and reviewed 
> several EOIs, and conducted interviews with some candidates before making 
> recommendations. The Board has considered and agrees with the BGC's 
> recommendations.
> 
> Appointing a NomCom Chair and Chair-Elect identified through a public EOI 
> process positively affects the transparency and accountability of ICANN. 
> Adopting the BGC's recommendation has no financial impact on ICANN and will 
> not negatively impact the systemic security, stability and resiliency of the 
> domain name system.
> 
> The Board notes that coordination is necessary with the NomCom and ICANN's 
> Supporting Organizations and Advisory Committees to standardize position 
> descriptions for the NomCom Chair and Chair-Elect, as well as for the 
> positions that the NomCom is responsible to fill within ICANN. In addition, 
> it is necessary to develop – in consultation with the NomCom – a standardized 
> set of conflict of interest identification practices for use by NomCom 
> members. The Board Governance Committee will continue dialogue with the 
> NomCom on these and other issues, including furtherance of work to meet the 
> recommendations of the Accountability and Transparency Review Team, at the 
> ICANN meeting in Dakar, Senegal.
> 
> 
> 3.  Approval of BGC Recommendation re Reconsideration Request 11-1
> ==================================================================
> 
> 
> Whereas, the BGC has reviewed Reconsideration Request 11-1 submitted by 
> Michael F. Gende on 15 June 2011 concerning the domain name zetamusic.com.
> 
> Whereas, the BGC has determined that Reconsideration Request 11-1 should be 
> denied.
> 
> Whereas, Reconsideration Request 11-1 and the BGC's recommendation have been 
> posted on the ICANN website at 
> http://www.icann.org/en/committees/board-governance/requests-for-reconsideration-en.htm.
> 
> Resolved (2011.08.25.08), the Board adopts the recommendation of the BGC that 
> Reconsideration Request 11-1 be denied as the requested action is not within 
> ICANN's power and the Reconsideration process is not the appropriate forum to 
> make domain name dispute complaints.
> 
> 
> Rationale for Resolution 2011.08.25.08
> 
> ICANN's Bylaws call for the Board Governance Committee to evaluate and make 
> recommendations to the Board with respect to Reconsideration Requests. See 
> Article IV, section 3 of the Bylaws 
> http://www.icann.org/en/general/bylaws.htm#IV. The Board has reviewed and 
> thoroughly discussed the BGC's recommendation with respect to Reconsideration 
> Request 11-1 and finds the analysis sound.
> 
> Having a Reconsideration process whereby the BGC reviews and makes a 
> recommendation to the Board for approval positively affects the transparency 
> and accountability of ICANN. It provides an avenue for the community to 
> ensure that staff and the Board are acting in accordance with ICANN's 
> policies, Bylaws and Articles of Incorporation. Adopting the BGC's 
> recommendation has no financial impact on ICANN and will not negatively 
> impact the systemic security, stability and resiliency of the domain name 
> system.
> 
> Here, the Reconsideration process was invoked to obtain the transfer of a 
> domain name registration and complaining of ICANN's earlier response 
> referring the requester to contact the registrant, the registrar, or follow 
> other appropriate alternatives that may assist him in obtaining the transfer 
> of the registration. Because the requested action is not within ICANN's power 
> or authority, this Request has been denied. The Board further notes that the 
> Reconsideration process is not the appropriate forum in which to assert 
> complaints over domain names. There are several other mechanisms by which 
> complaints can be levied and addressed.
> 
> Nevertheless, the Request, in line with ICANN's compliance processes, has 
> been forwarded to the registrar for further follow-up directly with the 
> requester.
> 4.
> Process Steps for Consideration of Board Remuneration
> 
> 
> Whereas, ICANN currently provides compensation to the Chair of its Board for 
> the services the Board Chair renders as a Chair of the Board.
> 
> Whereas, ICANN desires to investigate whether it is appropriate to expand the 
> availability of compensation for service on the Board to other Board members 
> ("Directors").
> 
> Whereas, ICANN is a nonprofit California public benefit corporation that is 
> exempt from Federal income tax under §501(a) of the Internal Revenue Code of 
> 1986, as amended (the "Code") as an organization described in §501(c)(3) of 
> the Code.
> 
> Whereas, ICANN may not pay directors more than Reasonable Compensation as 
> determined under the standards set forth in §53.4958-4(b) of the regulations 
> issued under §4958 of the Code (the "Regulations").
> 
> Resolved (2011.08.25.09), the Board shall direct staff to take all steps 
> necessary to consider the appropriateness of compensation for voting 
> Directors.
> 
> Resolved (2011.08.25.10), as part of the process of reviewing any Director 
> compensation, the Board shall retain an Independent Valuation Expert, as that 
> term is defined in §53.4958-1(d)(4)(iii)(C) of the Regulations (an "Expert"), 
> to consult with and to advise the Board regarding the appropriateness and 
> level of any Director compensation arrangements, and to issue to the Board a 
> Reasoned Written Opinion, as that term is defined in §53.4958-1(d)(4)(iii)(C) 
> of the Regulations (the "Opinion"), from such Expert regarding the ranges of 
> Reasonable Compensation for any such services by a Director.
> 
> Resolved (2011.08.25.11), the Expert's opinion shall include all factors the 
> Expert determines to be appropriate regarding the appropriateness and the 
> level of compensation to be paid a voting Director for services to ICANN as a 
> Director, including offices held on the Board, attendance at Board and 
> Committee meetings, the nature of service on the Board and on Board 
> Committees, and Appropriate Data as to Comparability, as that term is defined 
> in §53.4958-6(c)(2) of the Regulations, regarding director compensation 
> arrangements for U.S.-based, nonprofit, tax-exempt organizations possessing a 
> global employee base.
> 
> Resolved (2011.08.25.12), after having reviewed the Expert's Opinion, the 
> Board shall meet with the Expert to discuss the Expert's Opinion and to ask 
> questions of the Expert regarding the Opinion, the Comparability Data 
> obtained and relied upon, and the conclusions reached by the Expert.
> 
> Resolved (2011.08.25.13), that the Board shall adequately document the basis 
> for any determination the Board makes regarding Director compensation 
> arrangements concurrently with making that determination.
> 
> Resolved (2011.08.25.14), ICANN's General Counsel is authorized and directed 
> to retain Towers Watson as the Board's Independent Valuation Expert to 
> consult with and to advise the Board regarding Director compensation 
> arrangements and to issue to the Board the Reasoned Written Opinion described 
> above regarding the appropriateness of and ranges of Reasonable Compensation 
> for any such services by a Director.
> 
> Resolved (2011.08.25.15), ICANN's staff is herby directed to post for public 
> comment a proposed revised Conflicts of Interest Policy and proposed revised 
> Bylaws that will be required if the Board approves a recommendation that 
> eligible Board members should be compensated for services to ICANN as 
> Directors of ICANN.
> 
> 
> Rationale for Resolutions 2011-08-25-09 – 15
> 
> Over the past several years, ICANN has been considering issues surrounding 
> Board compensation. The Board has publicly discussed the matter and has 
> reviewed independent analysis and advice on the matter. For example: (i) 
> there were calls from the community in relation to ICANN Framework for 
> Accountability and Transparency that the entire Board be compensated; (ii) 
> budget contingency discussions since FY08 have involved the concept of 
> possible Board remuneration; (iii) independent evaluation experts provided 
> studies on other non-profit organizations and Board member remuneration; (iv) 
> the Boston Consulting Group ("BCG") that conducted the Board Review suggested 
> that relatively modest fees to compensate directors for time may be 
> appropriate; (v) the Board Review working group acknowledged general support 
> from BCG and community for director remuneration, but recommended further 
> study in coordination with General Counsel; and (vi) the Accountability and 
> Transparency Review Team s!
> pecifically recommended that the Board should implement a compensation scheme 
> for voting Directors.
> 
> In August of 2010, the Board approved compensation for the Board Chair. Since 
> that time a call for all voting directors to be compensated has continued, 
> most recently through Recommendation 5 from the Accountability and 
> Transparency Review Team.
> 
> Taking all steps necessary to ensure that consideration of voting director 
> compensation is done in accordance with all appropriate laws, rules and 
> regulations positively impacts the accountability and transparency of ICANN. 
> Further, informing the community through posting all of the process steps the 
> Board is following, as well as the proposed revisions for the Conflicts of 
> Interest Policy and the Bylaws, significantly enhances ICANN's transparency 
> in this matter.
> 
> Following these steps will have some fiscal impact on ICANN as it will cost 
> some to engage the Independent Valuation Expert, however that eventually was 
> budgeted for when the Board adopted the ATRT Recommendations. Taking these 
> steps will not negatively affect the security, stability or resiliency of the 
> domain name system.
> 
> 
> 5.  Single Character IDN Update
> =================================
> 
> 
> Whereas, the delegation of IDN TLDs in a way that promotes security and a 
> good user experience is a longstanding topic of importance to ICANN's Board 
> and the global community.
> 
> Whereas, the GNSO's Reserved Names Working Group concluded that, for IDNs, 
> there should not be a general restriction on single-character U-labels, and 
> recommended a case-by-case analysis.
> 
> Whereas, the IDN Implementation Working Team recommended that 
> single-character gTLDs should not be banned, but that further ramifications 
> of this issue should be addressed by policy bodies such as the ccNSO and GNSO.
> 
> Whereas, the Joint ccNSO-GNSO IDN Working Group (JIG) recommended that 
> single-character TLDs should be accepted in the IDN ccTLD Fast Track, as part 
> of the recommendations for overall policy in IDN ccPDP, and the New gTLD 
> Program.
> 
> Whereas, the Fast Track was designed to enable the introduction of a limited 
> number of non-contentious IDN ccTLDs to meet near-term demand while the 
> overall policy is being developed, using methods that do not pre-empt the 
> outcomes of the IDN ccPDP.
> 
> Whereas, the JIG Report raises certain questions, including (a) what suitable 
> process for consultation (including with relevant language communities), is 
> needed when considering new, single-character IDN TLD strings, and (b) 
> whether there would be a different policy conclusion if it were specified 
> that only ideographical scripts are acceptable for single-character IDN TLDs.
> 
> Whereas, these and all technical and policy considerations must be addressed 
> prior to delegation of any single-character TLDs.
> 
> Whereas the time necessary to adequately resource and consider these issues 
> is estimated to extend beyond the scheduled application submission period for 
> the first gTLD application round.
> 
> Resolved (2011.08.28.16) the Board, on the issue of delegation of single 
> character gTLDs:
> 
> 1. Requests specific advice on security & stability aspects of this issue 
> from the SSAC. 
> 
> 2. Requests the GAC to consider and provide specific advice on public policy 
> aspects of this issue. 
> 
> 3. Requests specific advice on the end-user/consumer aspects of this issue 
> from ALAC. 
> 
> 4. Directs the staff to consult with additional appropriate and knowledgeable 
> community participants across various languages/scripts on this topic, and to 
> provide the Board and community a report that reflects this input, to enable 
> consideration by the Board on delegation of single character IDN TLDs. 
> 
> 5. Directs staff to publish a timetable for this work, clearly indicating 
> that processes for delegation of single-character IDN TLDs will be made 
> available after the first gTLD application round and conclusion of IDN ccTLD 
> policy work. 
> 
> 
> Rationale for Resolution 2011.08.25.16
> 
> Why the Board is addressing the issue now?
> The Joint ccNSO-GNSO IDN Working Group (JIG) produced a final report 
> recommending that single-character IDNs be delegated in the New gTLD program 
> and the IDN ccTLD Fast Track. The GNSO Council and the ccNSO Council approved 
> the report on 7 April 2011 and 10 May 2011, respectively, and the report was 
> delivered to the Board on 11 May 2011.
> 
> What is the proposal being considered?
> The JIG report includes recommendations that:
> 
> a) Single Character IDN TLDs should be acceptable under the IDN ccTLD Fast 
> Track Process and as part of the recommendations for overall policy in IDN 
> ccPDP, taking into account the findings from the report;
> 
> b) The GNSO policy recommendation in the Final Report for the Introduction of 
> New Generic Top-Level Domains for Single Character IDN TLDs should be 
> implemented; and
> 
> c) Requested Single Character IDN TLD strings should be analyzed on a 
> case-by-case basis in the new gTLD process depending on the script and 
> language. Single Character IDN TLDs should be acceptable, but must not be 
> confusingly similar to single or two character ASCII TLDs. For alphabetic 
> script Single Character IDN TLDs, other technical aspects of confusability 
> may be taken into consideration, such as the likelihood of user slip with 
> relevance to keyboard layouts.
> 
> Implementing the report's recommendations would result in changes to the 
> approved versions of the gTLD Applicant Guidebook and the IDN ccTLD Fast 
> Track Implementation Plan.
> 
> Which stakeholders or others were consulted?
> The JIG consists of representatives from the ccNSO and GNSO communities. The 
> report has also been posted for public comment from all stakeholders.
> 
> Since receipt of the report, i nformal discussions have taken place with some 
> SSAC and Board Variant Working Group members regarding technical aspects of 
> the proposal.
> 
> What concerns or issues were raised by the community?
> 
> Issues raised by the community during the public consultation process include:
> ◦Timing of the potential introduction of single-character IDN TLDs in 
> relation to resolution of IDN variant management issues.
> ◦Suggestion of an IDN Evaluation Panel to review applications for Single 
> Character or Two Character IDN TLDs.
> ◦Procedures in the event that single characters represent geographic names or 
> other interests.
> ◦Potential for user confusion.
> ◦Potential usability issues with single-character IDN TLDs.
> ◦The distinction between gTLDs / ccTLDs.
> 
> What significant materials did the Board review?
> The Board reviewed the JIG's report.
> 
> What factors the Board found to be significant?
> The Board will consider technical issues, public policy issues, and user 
> experience. Accordingly, input is being sought from the various Advisory 
> Committees.
> 
> With regard to the New gTLD Program, issues raised in the JIG report that 
> could be addressed in the consultations are: (1) identifying a suitable 
> process for consultation (including with relevant language communities) when 
> considering new, single-character IDN gTLD strings; and (2) whether there 
> would be a different policy conclusion if it were specified that only 
> ideographical scripts are acceptable for Single Character IDN TLDs.
> 
> With regard to IDN ccTLDs, the policy development processes concerning IDN 
> ccTLDs could be informed by additional exploration of these issues. The IDN 
> ccTLD Fast Track was designed to enable the introduction of a limited number 
> of non-contentious IDN ccTLDs to meet near-term demand while the overall 
> policy is being developed, using methods that do not pre-empt the outcomes of 
> the IDN ccPDP. Accordingly, delegation of one-character TLDs is not currently 
> being considered for the Fast Track.
> 
> Are there positive or negative community impacts?
> The Board is requesting additional advice on the possible impacts before 
> proceeding.
> 
> Are there fiscal impacts or ramifications on ICANN (strategic plan, operating 
> plan, budget); the community; and/or the public?
> The recommended action should not cause any significant variance on 
> pre-planned expenditure.
> 
> Are there any security, stability or resiliency issues relating to the DNS?
> Initial analysis indicates that there are none; however, the matter is being 
> referred to the SSAC for additional consideration.
> 





<<< Chronological Index >>>    <<< Thread Index >>>