[council] Resolutions from ICANN Board meeting on 25 Aug

["Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>]

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 explicitly 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 specifically 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.