Urgent - ALAC consideration of governance oversight and review mechanism for IDNA Label Generation Rules for the Root Zone
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
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@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+(ALA...)
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@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@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+(ALA...)
participants (2)
-
Holly Raiche -
Rinalia Abdul Rahim