Following up on my comments at the meeting today. I was asking if ALAC might make a statement about the Report from Board-GAC Joint Working Group http://www.icann.org/en/committees/board-gac-2009/board-gac-jwg-final-report... There is concern that GAC liason to the Board may not do an adequate job of comunication the Boards's thinking to the GAC.. it is vitally important for governments to have a clear and comprehensive understanding of ICANN's strategic thinking, focus areas, business planning and key operational decisions. It is recommended therefore that a formal Board Liaison to the GAC be established who would report to the GAC, both intersessionally and in person at GAC meetings, on major Board discussions and decisions relating to these high level matters. I seems that, under the current by-laws, the GAC's role is limited to advising the board, and it is under no obligation,to involve itself with the SO's or AC's or the PDPs. However provision is made in the bylaws. The JWG notes that the ICANN By Laws provide (Article XI, Section 2, g) that the GAC may designate a non-voting liaison to each Supporting Organization (SO) and Advisory Committee (AC) as it considers appropriate. The only reference to liaisons in the GAC Operating Principles is in Article XI, Principle 44, referring to the role of the GAC Secretariat. So, similarly to the Board, the recommendation is the establishment of "reverse liasons": While improvements in the interactions between the GAC and other SOs and ACs would be beneficial, it is not entirely clear that focusing solely on the role of GAC liaisons to each SO and AC would improve the effectiveness of the GAC’s contributions to ICANN’s policy development processes, which is the goal of recommendation 12 of the ATRT report. Recommendations 1. The GAC and the Board should develop, in consultation with the SOs and ACs, a common understanding regarding the scope and function of liaisons between and among the GAC and the SOs and ACs to ensure that each have shared expectations. 2. Consider experimenting with “reverse” liaisons, with each SO and AC identifying members of their respective constituencies to liaise with the GAC. 3. In the event that further discussions within ICANN suggest a shared understanding of the respective roles of all liaisons (e.g. GAC to SOs and ACs, and the “reverse” liaisons), the GAC and the SOs and ACs should develop agreed procedures for communications between such liaisons and their respective SOs and ACs, to ensure consistency in reporting and coordination. 4. In the event that GAC liaisons are agreed, the GAC will consider creating teams of GAC volunteers to serve as liaisons to all of the SOs and ACs on a rotating basis. In the event the normal work priorities of an individual GAC member prevent full-time liaison functions, another member of the GAC team would step in. 5. The Board and ICANN management should review the roles of ICANN staff assigned to support the work of the SOs and ACs to determine how their efforts could be expanded to include more routine information sharing or briefings for the GAC, as well as whether there are additional opportunities for information sharing on issues of interest to a cross-section of SOs and ACs. 6. Consider extending the model represented by the joint GAC-ccNSO working group for the IDN ccTLD “fast track” process to other issues and other SOs and ACs as appropriate. 7. Encourage the ICANN Board to jointly review with the GAC ways to include GAC advice at earlier stages in the policy development process. The JWG considers the recently developed “New GNSO Policy Development Process” a constructive starting point for this review. 8. Explore whether the ICANN ByLaws need to be amended to more affirmatively provide for GAC input to ICANN’s policy development processes (vice the current provisions which call for the provision of GAC advice directly to the Board). on that last point, it is noted that the GAC website could be improved.. For example, ICANN/IANA has not been referencing the 2005 GAC Principles and Guidelines for the Delegation and Administration of Country Code Top Level Domains (2005) but rather an earlier version of the document. How can this circumstance be avoided in the future? Some form of register, accessible on a public web-site, could be useful. For example, the SSAC website (see http://www.icann.org/en/committees/security/ssac-documents.htm) offers a comprehensive and up-to-date list of all SSAC "reports and advisories" since 2001. The GAC has no similar register to refer to. The public comment window on this report closed last Saturday, but I understand the ALAC can comment at any time. Should we support these recommendations? j -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- -