Hi all,
Plase find below a comment on the GDS Liaison Guidelines, which was marked an actin item for me. Just let me know if you have any further input, comments or objections.

Kind regards,
Thomas



Thank you for the opportunity to share a few thoughts on the GDS Liaison Guidelines. 

In Section 1, the guidelines make reference to the set of guidelines for Board Members serving as Liaisons to ICANN Community Groups, on which they follow.

Whilst it is good to build on these to ensure consistency, these are obviously parallel processes. It would be good if there were connections between the two functions or lines of communication. 

In 3.1. of the Guidelines for Board Members, the role of the Board member is described as follows:

The Board Member as liaison is an interface between the Community and the Board on a certain topic and in a given Community Group. The liaison is expected to:

3.1.1 Keep the Board/caucus informed of the progress of the project the liaison has been appointed to. In the event that the Board forms a Board Caucus to follow development in a particular process, the Board Liaison may be asked to head that group. A process for regular communication between the Board liaison and the ICANN Board/Board Caucus is expected to be in place. This could be in the form of written or oral updates at set times or meetings.

3.1.2.  Identify any potential challenges that could be mitigated by the ICANN Board or could pose challenges in meeting the timeline or objectives that could impact the Board’s planning (early warning).

3.1.3.  Convey any formal or informal Board input that is intended to help inform the deliberations of the respective project, either at the request of the project or at the direction of the ICANN Board. This would also include providing factual information (correcting misinformation).

3.1.4.  Indicate in a timely manner if recommendations are unlikely to be approved by the ICANN Board, without attempting to dictate a preferred outcome.



It is great the Role of the GDS Liaison include (Section 3):

  • ●  Submit clarifying questions and advise the PDP Working Group on the clarity of policy recommendation language as it pertains to implementation.

  • ●  Where possible, provide the PDP Working Group with advance notice of any implementation-related issues or concerns and collaborate with relevant parties to attempt to address the issue. Such issues or concerns may be noted: at fixed milestones related to the PDP, such as at the time of completion of the Initial Report; or, in response to a request from the WG; and/or proactively when deliberations progress towards a preliminary outcome.

  • ●  Share information and updates on PDP work in progress, including questions and implementation-related issues, with affected functions within the organization.

  • ●  Prepare and provide analysis of the impact of policy recommendations on existing

    policies, as needed.

  • ●  Provide or coordinate the provision of relevant data or background information

    requested by the PDP Working Group.

  • ●  Provide information or estimates to the PDP Working Group regarding the budget

    and resources required to fulfill implementation requirements.

  • ●  Support the transition to the Operational Design Phase (ODP) and development of

    the Operational Design Assessment (ODA), where an ODP is undertaken.

  • ●  Support the transition from the PDP (and ODP, as applicable) to implementation

    following the approval of PDP Recommendations by the GNSO and ICANN Board.


If these tasks are carried out in an efficient manner, the role of the GDS liaison can actually help avoid that the WG comes up with recommendations that are not implementable at all, too expensive or too cumbersome to implement. That helps avoid situations in which the GNSO Council adopts recommendations that are then not approved by the Board because of such issues. Let me add that I understand the risk of the Board not approving recommendations because they are not in the best interest of the ICANN community or ICANN Org cannot be fully eliminated with this.

In my view, it would, however, be good, to formalise this a bit more and tasks the GDS liaison with offering an „implementation preview“ to illustrate dependencies with other projects so that ideally there are no issues with Board approval and also limit the need for a formal ODP. 

As mentioned above, due to roles and responsibilities in ICANN (Org), the processes are parallel, wich means that the Board liaison role does not encompass the operational aspects and the GDS liaison does not cover risks for Board approval.

The GNSO and its community need both, though. WGs and the GNSO Council would hugely benefit from information on issues with implementation as well as issues preventing Board approval. 

Maybe the role of the GDS liaison can be extended so that it also liaises with the Board liaison or the Board to ensure cohesive feedback and an "early warning system“ from both the Org and the Board.