|Vote Open||Vote |
|Vote Close||Date of Submission||Staff Contact and Email||Statement Number|
|25.10.2012||Community Input and Advice Process|
|Comment/Reply Periods (*)||Important Information Links|
|Comment Open:||24 September 2012|
|Comment Close:||25 October 2012|
|Close Time (UTC):||23:59 UTC||Public Comment Announcement|
|Reply Open:||26 October 2012||To Submit Your Comments (Forum)|
|Reply Close:||14 November 2012||View Comments Submitted|
|Close Time (UTC):||23:59 UTC||Report of Public Comments|
|Originating Organization:||ICANN Policy Department|
|Purpose (Brief):||This discussion document is posted at the request of the Board Governance Committee to solicit views from the ICANN community on ways to enhance the process by which the Board seeks advice from the ICANN community beyond the traditional public comment process. This issue stems from the work undertaken by Staff in fulfillment of recommendation No. 6 from the Accountability and Transparency Review Team, and highlights an area where improvements can lead to predictability and consistency for future Board actions. A session is scheduled in Toronto to explore this important issue further.|
|Current Status:||This document is posted for discussion purposes at the Toronto Meeting.|
|Next Steps:||Upon closing of the public comment forum, Staff will post a summary of community input received in Toronto and in this public comment forum. Staff expects to develop a proposal for a streamlined process to be used for the Community Input and Advice Function, for further consideration by theICANN Community.|
|Staff Contact:||Margie Milam||Email:||firstname.lastname@example.org|
|Section I: Description, Explanation, and Purpose|
In fulfillment of Accountability and Transparency Review Team (ATRT) Recommendation No. 6, Staff has identified topics that are subject to formal policy development processes, and those that are generally within the ICANN Board level Organizational Administration Function. While Recommendation 6 has been completed, the work performed identified an area in which improvement is required – how the Board obtains the advice that it needs from the ICANN community beyond the traditional public comment process.
The document posted for public comment is intended to guide discussions in Toronto on enhancing the process by which the ICANN Board seeks advice from the community on topics that are not subject to formal policy development processes. It is hoped that these discussions could lead to a consistent and predictable process to be adopted by the ICANN Board for such inquiries.
|Section II: Background|
ATRT Recommendation No. 6. States that:
In fulfillment of this Recommendation No. 6, a document was produced that specifically set forth the topics that are subject to policy development processes, and those that are generally within the ICANN Board level Organizational Administration Function. While Recommendation 6 has been completed, the work performed identified an area in which improvement is required – how the Board obtains the advice that it needs from the ICANN community beyond the traditional public comment process. Recently, issues have surfaced where the Board has sought in-depth input or advice from the community, and has specifically requested portions of the community to come together for that purpose.
Through the completion of this work, the BGC identified an area where process improvement will benefit the ICANNcommunity, namely, how the Board seeks community input and advice outside of the formal policy development processes. A brief discussion of some of the hallmarks of this "Community Input & Advice Process" is described in the document posted for public comment. As seen in the rise of cross-community working groups on issues such applicant support in the New gTLD Program, or the Implementation Recommendations Team providing expert guidance on trademark protections, having well-defined mechanisms to provide input and guidance to the Board is necessary.
In Toronto, a working session is scheduled to begin discussions on whether such a mechanism should be formalized to allow for clear understanding of the consultation mechanisms and the issues for which it is helpful to be invoked.
|Section III: Document and Resource Links|
|Section IV: Additional Information|
(*) Comments submitted after the posted Close Date/Time are not guaranteed to be considered in any final summary, analysis, reporting, or decision-making that takes place once this period lapses.
Draft comment created by Alan Greenberg, 18 October 2012
1. Should standardized processes be created for the Board’s receipt of community input and advice?
The short answer is that it might conceptually be a good idea, but in practice, creating such processes is likely to be a time-consuming process itself (and ironically, one requiring cross-community input), and it is far from clear that a single process will meet the needs of undefined requirements for input in the future.
2. If so, should such a procedure be standardized across ICANN SOs/ACs, aligned with the current existing procedures, or should there be some flexibility among the SOs/ACs (certain parts are required for all, while other parts may be developed by the respective SOs/ACs).
If a process were to be defined, it would certainly need flexibility. Indeed, given the vastly different processes currently followed by SOs and ACs, it is difficult to imagine a procedure that simultaneously could be “standardized” while also being “aligned to current existing procedures”.
3. How should the Board request this input and advice?
This call for comments requesting THIS input said “To date, the Board has made these requests through Board resolution or by letter, but neither process is sufficiently formal to ensure that the relevant SOs or ACs are fully aware of the request or address/provide the input or advice requested.” It is hard to imagine a process which would be MORE formal that a Board resolution or letter.
The reality is that at times, the ACs and SOs are so overwhelmed with the need to work on a huge portfolio of issues that none gets the attention that it might deserve. No doubt requests from the Board often suffer due to this.
Threats and near-impossible deadlines have been used in the past with some level of success, but this is surely not a good model for routine use.
A resolution or letter is as good a start as any, but it is not a complete answer. What is required will be addressed later in this statement.
4. What is [the] most effective and efficient method to deal with the issue topic identified? Should it be a working group, could current procedures be used? Who determines which method will be used?
5. Should working groups be chartered for each initiative?
6. How are different parts of the ICANN community expected to work together in these efforts?
Currently there are no procedures for how cross-community working groups should function. Each AC and SO has its own rules, practices and traditions, and they are VERY different from each other.
The call for comments made reference to “Some examples of where this Function has already been used within ICANN”, specifically the Special Trademark Issues (STI) team and the Joint Applicant Support Working Group (JAS). Both bear some examination.
The STI was not a cross-community effort. It was a GNSO group created at the request of the Board (gnso.icann.org/correspondence/beckstrom-to-gnso-council-12oct09-en.pdf) – one of those with a ridiculously short deadline and the clear threat of unilateral Board action. As per normal GNSO practice, since the ALAC had a Liaison working with Council, At-Large was given the opportunity to participate in the STI and was allocated two seats, the same as several other SGs and Constituencies. At the very last moment, Council unilaterally reduced At-Large participation to one member and one non-speaking alternate largely on the grounds that the At-Large was not part of the GNSO and the Liaison was not a full Council member. So the STI was FAR from a cross-community effort. That being said, once the group was formed, even with its restricted participation, the At-Large representatives were both active and effective in getting the group to reach consensus and there was certainly no discernible negative feelings to the At-Large participants within the group. It must be noted that this attitude toward At-Large had not been seen before this occurrence, or since – a very good thing.
JAS was in fact a cross-community WG of the ALAC and the GNSO. However the history of its creation, participation, re-chartering and report approval demonstrates that just calling something a cross-community WG does not really make it so. And the processes that have followed that have tried to formulize more acceptable ways of creating such groups have also been fraught with misunderstandings and the lack of effective progress.
So in reply to the last question, How are different parts of the ICANN community expected to work together in these efforts? The answer is not clear, other than hopefully better than some of the past experiences.
On the other hand, there have been some notable successes. The DSSA group coalesced effectively with all groups in opposition to a staff-led effort, and having a common enemy seems to be a sufficient motivator allowing disparate groups to work together.
The various IDN efforts have similarly been successful.
7. What minimum public consultation requirements, if any, should be required within this function?
On the presumption that the normal public consultation process improves and actually attracts more of the public (and public interest) and is not just an opportunity for those who did not get what they wanted during a previous effort to restate their position, yes, public consultation is needed.
8. Are there any topics that should not be subject to this function?
Given that SOs have specific functional mandates and scope, and the ACs cross those boundaries, it is hard to imagine an issue that does not involve at least one of those intersections. However, most issues will be of great interest to some parts of ICANN, and of no interest to others.
9. Who within ICANN lead this effort?
The Board certainly needs to take a lead in this, which brings us to the questions that were not asked. This consultation focuses on how the Board should receive advice and on how the various component groups of ICANN should work together to generate that advice.
It is both interesting and curious that there is a general belief that to reach consensus and compromise, the various players need to talk to each other. Certainly a part of this community, the ALAC hopes that when reaching its own decisions, the Board members talk to each other. Yet the standard method for communication between the parts of the community and the Board is to throw documents over the wall at each other. There is virtually no dialog and no engagement in either direction. On the rare occasions where there are meetings or Board involvement, it is almost always in the form of stone-faced listening or occasionally extended preaching.
ICANN and its constituent bodies are and will continue to be grappling with some very difficult problems. They are not going to go away and they will not be addressed with report, no matter how salient. Moreover, difficult problems with subtle arguments do not lend themselves to short, concise reports, yet we are regularly told that if a report is long, it will be summarized by staff and most Board members will not read it. That does not sound like a recipe for success.
Finding sufficient time to talk is difficult, and some Board members feel that there must be no involvement of the Board in reaching community consensus. But no matter how successful any of the efforts implied by the set of Board questions might be, we must ultimately have Board interactions so that the problem and its constraints are well understood, and that the ultimate recommendations are useful, understandable and implementable. That will not happen without active and effective Board dialog. And dialog is defined as an exchange of ideas of ideas via conversation. Not throwing documents over walls and not one group talking at the other without receiving feedback. We need engagement, not only among the constituent bodies of ICANN, but with its Board.