[NA-Discuss] Report from Board-GAC Joint Working Group

Joly MacFie joly at punkcast.com
Mon Aug 8 21:45:58 UTC 2011

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

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.


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

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

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


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

More information about the NA-Discuss mailing list