[ALAC] Urgent - ALAC consideration of governance oversight and review mechanism for IDNA Label Generation Rules for the Root Zone

[Rinalia Abdul Rahim]

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