<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div>Hi all,</div>
<div>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.</div>
<div><br>
</div>
<div>Kind regards,</div>
<div>Thomas</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Thank you for the opportunity to share a few thoughts on the GDS Liaison Guidelines. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>In 3.1. of the Guidelines for Board Members, the role of the Board member is described as follows:</div>
<div>
<div class="page" title="Page 2">
<div class="layoutArea">
<div class="column">
<p>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:</p>
<p>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.</p>
<p>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).</p>
<p>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).</p>
<p>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.</p>
</div>
</div>
</div>
<div><br>
</div>
<div><br>
</div>
<div>It is great the Role of the GDS Liaison include (Section 3):</div>
<div><br>
</div>
<div>
<div class="page" title="Page 3">
<div class="layoutArea">
<div class="column">
<ul style="list-style-type: none;">
<li>
<p>● Submit clarifying questions and advise the PDP Working Group on the clarity of policy recommendation language as it pertains to implementation.</p>
</li><li>
<p>● 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.</p>
</li><li>
<p>● Share information and updates on PDP work in progress, including questions and implementation-related issues, with affected functions within the organization.</p>
</li><li>
<p>● Prepare and provide analysis of the impact of policy recommendations on existing</p>
<p>policies, as needed.</p>
</li><li>
<p>● Provide or coordinate the provision of relevant data or background information</p>
<p>requested by the PDP Working Group.</p>
</li><li>
<p>● Provide information or estimates to the PDP Working Group regarding the budget</p>
<p>and resources required to fulfill implementation requirements.</p>
</li><li>
<p>● Support the transition to the Operational Design Phase (ODP) and development of</p>
<p>the Operational Design Assessment (ODA), where an ODP is undertaken.</p>
</li><li>
<p>● Support the transition from the PDP (and ODP, as applicable) to implementation</p>
<p>following the approval of PDP Recommendations by the GNSO and ICANN Board.</p>
</li></ul>
</div>
</div>
</div>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
</div>
</body>
</html>