<<<
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
>>>
|