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

[Rinalia Abdul Rahim]

Dear Holly,

Thank you for sharing your thoughts.

*On pool of talent (experts)*
During our IDN WG meeting in Toronto, the issue of limited pool of talent
was discussed with the representatives of the IDN Variant Team.  We had
suggested that ICANN take measures by providing incentives to ensure that
there continues to be a sufficient supply of talent for the work in the
future.  I think that the ALAC needs to make this recommendation (again)
and in more concrete terms.   I believe that the supply of talent needs to
be ensured for the following reasons:
- Different linguistic communities are at different levels of readiness to
develop label generation rules for their specific script, writing system
and language.  If the experts are only available in the immediate term and
not in the future, then the late comers will be unfairly disadvantaged.
- Having a sufficient supply of talent will make it easier to put in place
good governance measures at the level of the Integration panel.  For
example, fixed term (i.e., specific number of years for each term) and term
limits (eg., only 2 terms max).  These are typical measures to ward off
capture.

*Involvement of SSAC/RSSAC*
I believe that the SSAC is maintaining its distance and independence from
the Team so that it can provide independent comments.  I think that this
distance is important as a form of check and balance.  I certainly support
the idea of comprehensible SSAC/RSSAC reports on the proposals so that
communities can make informed interventions via the Public Comments
process.  The question of whether or not someone associated with SSAC/RSSAC
should be a member of the Integration Panel has not really been broached.
Perhaps it might be better if someone from the SSAC/RSSAC were to serve as
an advisor to the Integration Panel, which allows them to provide input in
the deliberation as well as provide independent assessments on the
proposals.

*Public Comment Process*
Reliance on the public comment process requires that ICANN fix whatever
issues/shortcomings there are associated with the process.  Perhaps the
ALAC should use this opportunity to highlight what needs to be fixed.  For
example, the call for public comments on this version of the LGR document
in the month of December is a disaster in terms of timing because people
are away for much of the time and communities cannot do proper
consultations.

*Additional oversight mechanism or process
*I'd like to hear the views of ALAC members on this as well as from Edmon.

Once again, thank you for responding to the issues, Holly.  Much
appreciated.

Best regards,

Rinalia

On Sun, Dec 16, 2012 at 12:40 PM, Holly Raiche <h.raiche at internode.on.net>wrote:

> Thanks Rinalia - It takes some thought just thinking through your email.
>
> some general points - this is a very specialised area, and as the text
> points out, the talent pool is not that large, so finding people with no
> actual or perceived conflict of interest will be a challenge.
>
> Next - while 3 is a small number, the size does make sense.
>
> Where it starts to fray is the anticipated use of experts - who are they,
> where from.  I trust the SSAC expertise will be called upon since there are
> huge security issues.
>
> And I agree - sole reliance of public comment is worrisome.  Most people
> will simply not have the expertise to comment.
>
> I'm not sure what you would add to the process, though.  My thought would
> be possibly that there be a publicly available - comprehensible - report
> from the SSAC at least on the panel's output, with clearly stated
> implications for what is being proposed.  Are there others who should
> comment.  And, in the end, suggestions for an additional process?
>
> Thank you for the effort and time.  we do need to think this one through
> carefully
>
> HOlly
>
>
> On 15/12/2012, at 4:08 AM, Rinalia Abdul Rahim wrote:
>
> > 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
> > _______________________________________________
> > ALAC mailing list
> > ALAC at atlarge-lists.icann.org
> > https://atlarge-lists.icann.org/mailman/listinfo/alac
> >
> > At-Large Online: http://www.atlarge.icann.org
> > ALAC Working Wiki:
> https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)
>
>