At-Large Community Input and Advice Process Workspace

(*) 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.

FINAL DRAFT

Please click here to download a copy of the final version.

Draft comment created by Alan Greenberg, 18 October 2012

 PDF Version

Questions posed:

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.