December 2012 - IDN-WG - lists.icann.org

Urgent - ALAC consideration of governance oversight and review mechanism for IDNA Label Generation Rules for the Root Zone
by Rinalia Abdul Rahim Dec. 18, 2012

Dec. 18, 2012

Dear ALAC, The IDN Working Group is currently working on a draft ALAC statement in response to the Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels – Second Public Comment Draft<http://www.icann.org/en/resources/idn/draft-lgr-procedure-07dec12-en.pdf> [PDF, 790 KB]. There is one critical aspect of this document that I believe merits an urgent ALAC discussion prior to the finalization of the statement: *The only governance oversight for the decisions of the Integration (Expert) Panel is **the ICANN Public Comments and there is no alternative formal review/appeal mechanism*. There appears to be a resistance to alternative forms of governance oversight. This resistance is premised on a position that the Integrated Panel of experts needs to be independent because what is at stake is the security and stability of the root, which affect all Internet users. The ALAC needs to consider whether there should be alternative governance and policy oversight as well as periodic review of the process as per other key aspects of ICANN work. In considering alternative options, the ALAC should consider both the advantages as well as the risks involved. I have requested Edmon Chung as the At-Large IDN Policy Liaison to lead this discussion at the ALAC level. The deadline for submitting a statement in response to the document is Jan 6, 2013. Given the upcoming holiday period and the need to address this critical matter satisfactorily, urgency is recommended. Below I have pasted what I consider to be relevant extracts from the document to help inform the discussion - I apologize for the length - the actual document is about 70 pages long. I highly recommend that ALAC members read the full document for a more comprehensive view. Best regards, Rinalia Abdul Rahim * Extracts related to the Public Comments Process as governance oversight mechanism* (bold emphasis is mine) "Submitting proposals: The generation panel, when it has completed its work, sends its proposals to the integration panel. At the same time, the generation panel’s proposals are posted for public comment using the ICANN public comment procedures then prevailing. This permits those who did not participate in the generation panel in question to make their views known to the integration panel. A well-functioning public comment procedure is a critical component of this procedure, because there is no formal appeal mechanism. If ICANN’s public comment procedures do not attract attention to the proposals, the procedure is at serious risk of capture by those who do take an interest." "A rejection of a proposal (by the Integration Panel) must be accompanied by a justification citing the specific issues with the proposal that gave rise to the rejection. The justification must include an accounting of which (if any) of the Principles the proposal violates according to the integration panel, as well as every other justification the integration panel has for its decision. Every rejection by the integration panel must be available on the Internet; a web-accessible archive of the decisions is sufficient to meet this requirement." "Decisions by the integration panel are required to be unanimous; any proposal that does not attract unanimous acceptance is automatically not accepted, on the grounds that any proposal that does not attract unanimous support within the integration panel (assuming that panel is doing its job) must be violating one or more of the Principles. The integration panel must take into account any public comments submitted in response to the posting of the generation panel’s output. The integration panel must also publish its decisions and rationales for public comment, and must explicitly take all public comments into account, and publish a report on this review (see B.4.5). Public comment is the only mechanism, short of dismissal of some (or every) integration panel member, by which the integration panel can be held accountable." "Since the integration panel is required to make its determination unanimously, a single objector in disagreement with the rest of the integration panel will prevent the integration panel from accepting a generation panel’s proposal. In case of such disagreement, the integration panel’s reasons for rejection should include an indication that the panel is divided, must include the reasoning behind the objection, and should include details of any disagreement within the panel." "Decision of the integration panel is atomic: The integration panel’s evaluation of a given generation panel’s output is atomic: either it accepts a proposal completely, or it rejects it completely. That is, the integration panel is free to reject a generation panel’s recommendations, but it is not free to amend the details of the generation panel’s proposal. It may, however, return a generation panel’s proposal with a suggestion about what would change the opinion of the integration panel. Most importantly, the integration panel is required to provide detailed reasoning for its rejection in every case. The integration panel’s decision is public; it cannot be appealed, but the generation panel is free to submit the proposal again (altered or unaltered)." *One exceptional review by ICANN Board specified in the document* "Panels, Conservatism, and the Limits of Knowledge: In all matters the integration panel’s judgment is to be governed by the Conservatism and Stability Principles. If the integration panel delivers a repertoire while there is still work to be done on other parts of Unicode, as is inevitable, we expect subsequent iterations of the repertoire. We expect those iterations to increase the size of the repertoire, and not to remove any code point or change any code point variant rules to reflect the new inclusions. *If an iteration of the process causes a subsequent repertoire to remove a code point that was in an earlier repertoire or to change an existing variant rule, all operation of the procedure must halt. A review of the process must ensue to determine whether it is effective at following the principles outlined in Section A.3, and whether it is possible (and how) to add additional checks to the procedure to avoid recurrence of similar failures. Because it is impossible to state in advance what the failure might be (since if we knew, we could write rules to avoid it), the ICANN Board will determine the nature and scope of the review, and will appoint the reviewers.* If such halts are called frequently, that is a reason to believe that this procedure does not work, in which case a new (likely more conservative) procedure will be needed. One effect of the overarching Conservatism Principle should be that these events will not happen frequently; but given the procedure’s reliance on human judgment, it may be necessary to tolerate errors from time to time." * **Overview of Two Pass Process involving Generation Panel and Integration Panel *Process for developing IDN TLD variant label generation rules consists of two passes. "The first pass creates a set of label generation rules specific to a given script, writing system, language, or all of these; this task is carried out by Rule Generation Panels composed of people with deep experience or interest in the script, writing system or language used by some community of Internet users - Generation Panel. These panels will submit their proposals for the LGR to an ICANN TLD IDN Label Generation Rule Integration Panel consisting of independent experts in DNS, Unicode and scripts that has responsibility for the second pass. This second pass involves integrating the proposals into a single unified LGR for the root zone, taking into account the need for a secure, stable and reliable DNS root zone. These two kinds of panels are assisted by advisors, who observe the activities of any or all active panels; who provide comment and advice on the topics of IDNA, Unicode, DNS, linguistics, ICANN policy and process, or other matters; but who do not otherwise have a formal role in making a decision..." * Composition of Integration Panel* (bold emphasis is mine to illustrate controls that should be in place to govern conduct of Panel members) "The integration panel, whether made of consultants, staff, or both, should consist entirely of experts selected by ICANN on the basis of established expertise. *The experts are to be duly qualified against ethical conflicts, in order to minimize the possibility, or any appearance, that the interested parties might capture the process. Experts are to be in a contractual relation with ICANN, so that ICANN may require, as part of its contract with the panelists, impartial and unbiased evaluation.* The panel requires at least one expert in Unicode issues, at least one expert in IDNA and DNS issues (or one for each), and at least one expert in linguistics and writing systems (who could be the same as the first expert, but need not and often will not be). It is worth emphasizing that the supply of actual general experts in any of the relevant areas of expertise is extremely limited. This represents a potential risk to the procedure. The integration panel is a technical working panel, not a representative or deliberative body. It should be kept small in the interest of efficiency, but should not contain fewer then three members at any time. The integration panel is expected to make extensive use of advisors to aid their deliberations. No current or past member of any generation panel may be a member of the integration panel, because the integration panel is responsible for reviewing output from the generation panels." *Label generation rule integration procedure* (bold emphasis is mine) "The integration panel reviews the output of every generation panel from which a proposal is available at the time the integration panel begins review. The integration panel evaluates each proposal. The integration panel first confirms that the proposal stays within the maximal set of code points for the root zone defined by the integration panel, and that it conforms to the other requirements for output set forth in this document. It then evaluates the proposal for consistency with the Principles and for the risk it presents, in the context of the maximal set of Unicode code points for the root zone.* Proposals that do not meet the principles or create, in the judgment of the integration panel, unacceptable systemic risk are rejected.* A generation panel's proposal may be to permanently exclude a code point, which would factor in this evaluation. The integration panel further ensures all proposals together form an internally coherent set of label generation rules, and rejects any proposals that are in conflict. It is at this stage that the integration panel reviews the whole-label evaluation rules, both in the context of the given generation panel proposal, as well as in the context of all such proposals. Based on the Simplicity and Predictability Principles, the integration panel ensures that structurally comparable writing systems have consistent whole-label evaluation rules. Finally, it reviews whether the proposals collectively meet any other requirements (e.g. symmetry) set forth in this document. Proposals that fail this review will be rejected. A rejection of a proposal must be accompanied by a justification citing the specific issues with the proposal that gave rise to the rejection. The justification must include an accounting of which (if any) of the Principles the proposal violates according to the integration panel, as well as every other justification the integration panel has for its decision. Every rejection by the integration panel must be available on the Internet; a web-accessible archive of the decisions is sufficient to meet this requirement. Unlike the generation panels, the integration panel will consider possible interactions with Unicode characters outside the proposed set of rules and, if necessary, reject the generation panel's proposal based on such issues. The integration panel includes in its evaluation possible sets of rules that are not yet proposed, as might happen when a writing system did not initially attract a generation panel but might be expected to attract one in future. Decisions by the integration panel are required to be unanimous; any proposal that does not attract unanimous acceptance is automatically not accepted, on the grounds that any proposal that does not attract unanimous support within the integration panel (assuming that panel is doing its job) must be violating one or more of the Principles. The integration panel must take into account any public comments submitted in response to the posting of the generation panel’s output. The integration panel must also publish its decisions and rationales for public comment, and must explicitly take all public comments into account, and publish a report on this review (see B.4.5). Public comment is the only mechanism, short of dismissal of some (or every) integration panel member, by which the integration panel can be held accountable. While there may be a “first mover advantage” to the establishment of generation panels, the order in which the integration panel would evaluate proposals would be based roughly on the order in which the generation panels produce their proposals, and in any case constrained by the need to evaluate all proposals in context of each other, and compared to the rest of the basic constrained repertoire. Since the integration panel is required to make its determination unanimously, a single objector in disagreement with the rest of the integration panel will prevent the integration panel from accepting a generation panel’s proposal. In case of such disagreement, the integration panel’s reasons for rejection should include an indication that the panel is divided, must include the reasoning behind the objection, and should include details of any disagreement within the panel." END

2 2

Fwd: Re: ALAC Statement on the IDN Variant TLD Program Interim Report Examining the User Experience Implications of Active Variant TLDs
by Olivier MJ Crepin-Leblond Dec. 17, 2012

Dec. 17, 2012

Dear IDN-WG, FYI - well done! Kind regards, Olivier -------- Original Message -------- Subject: Re: ALAC Statement on the IDN Variant TLD Program Interim Report Examining the User Experience Implications of Active Variant TLDs Date: Mon, 17 Dec 2012 14:24:35 -0800 From: Steve Sheng <steve.sheng(a)icann.org> To: ICANN At-Large Staff <staff(a)atlarge.icann.org>, "interim-variant-ux(a)icann.org" <interim-variant-ux(a)icann.org> CC: Olivier Crépin-Leblond <ocl(a)gih.com> Dear all, On behalf of IDN variant team project 6 on user experience, let me thank ALAC for this substantive comment. Kind regards, Steve From: ICANN At-Large Staff <staff(a)atlarge.icann.org <mailto:staff@atlarge.icann.org>> Date: Thursday, December 13, 2012 4:19 PM To: "interim-variant-ux(a)icann.org <mailto:interim-variant-ux@icann.org>" <interim-variant-ux(a)icann.org <mailto:interim-variant-ux@icann.org>> Cc: Steve Sheng <steve.sheng(a)icann.org <mailto:steve.sheng@icann.org>>, Olivier Crépin-Leblond <ocl(a)gih.com <mailto:ocl@gih.com>>, ICANN At-Large Staff <staff(a)atlarge.icann.org <mailto:staff@atlarge.icann.org>> Subject: ALAC Statement on the IDN Variant TLD Program Interim Report Examining the User Experience Implications of Active Variant TLDs Dear All, Please find attached the /ALAC Statement on the IDN Variant TLD Program – Interim Report Examining the User Experience Implications of Active Variant TLDs/. On 13 December 2012, Staff confirmed that the online vote resulted in the ALAC endorsing the Statement with 14 votes in favor, 0 votes against, and 0 abstentions. You may review the result independently under: https://www.bigpulse.com/pollresults?code=28169ZtpN7yRxSZcxEI5z3vc Heidi Ullrich, Silvia Vivanco, Matt Ashtiani, Gisella Gruber, Nathalie Peregrine and Julia Charvolen ICANN Policy Staff in support of ALAC E-mail: staff(a)atlarge.icann.org <mailto:staff@atlarge.icann.org>

1 0

IDN Variant TLD Program Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels Second Public Comment Draft
by Matt Ashtiani Dec. 14, 2012

Dec. 14, 2012

Dear Edmon, Please note that a new PC regarding IDN Variants has been opened. Can you please advise if you will be writing a Statement on the At-Large IDN Variant TLD Program – Procedure to Develop <https://community.icann.org/x/7YxEAg> and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels – Second Public Comment Draft Workspace<https://community.icann.org/x/7YxEAg>? If so, when do you intend to submit it? Regards, Matt Ashtiani Policy Specialist ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 USA

3 3

IDN Variant TLD Program Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels
by Matt Ashtiani Dec. 3, 2012

Dec. 3, 2012

Dear Edmon, Can you please confirm if the IDN WG will be submitting a Statement on the IDN Variant TLD Program – Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels<https://community.icann.org/x/I5AoAg>? Please note that the reply close for this Statement is 9-Nov-2012. As such we would need a Statement as soon as possible. Regards, Matt Ashtiani At-Large Coordination Officer ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 USA

4 7