<div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">My question:</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">1.</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">In her blog recapping the January workshop, Tripti suggested that the Board 'anticipates making incremental decisions leading up to the final decision on opening a new application window for new gTLDs'. Can you elaborate on what 'incremental decisions' are to be expected?</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">2.</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">Applicant Support is a topic dear to the heart of NCSG. In the SubPro ODA, it was suggested that the applicant support program starts 18 months prior to the anticipated application submission period opening. The ODA also offered 2 options for implementing SubPro outputs, where option 2 only requires 18 months of implementation. While the GGP continues its work, it seems impossible to incorporate the Applicant Support Program in time for the next round in the aggressive timeline of Option 2. While we appreciate the org's effort in mitigating risks and enhancing efficiency by developing option 2, the next round would be meaningless if we open it without a meaningful and genuinely effective applicant support program. We have received questions from the Board about how to be agile and come up with new ways of working on issues to increase efficiency,. However, we fear this desire to move things forward can damage the inclusive, diverse multistakeholder model that defines ICANN. And Option 2 could be the exact example. How does the Board plan to balance the desire to be agile without compromising the due process, inclusiveness, and diversity of the multistakeholder model in its deliberations, including SubPro ODA?</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">The second question is a bit wordy and I'm afraid not as clear. Appreciate if anyone would help editing/rephrasing to make it clearer!</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">Best,</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">Manju</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 1, 2023 at 4:59 PM Johan Helsingius <<a href="mailto:julf@julf.com">julf@julf.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Just as a reminder, here are the questions from our last<br>
session with the board:<br>
<br>
PDPs Effectiveness and Volunteer fatigue<br>
<br>
NCSG would like to discuss Board Approval, implementation by ICANN <br>
org and delays of several PDPs - something we have already discussed <br>
with you in previous occasions. If we look at processes such as the EPDP <br>
related ones I think we can find a good example due<br>
<br>
to the fact that even despite the fact that the board didn't yet <br>
approve phase 2 recommendation, which were submitted in 2020, there is <br>
talk about the design paper of SSAD light. And in the past years, I <br>
guess we started gathering more examples of where the development <br>
process drags on for far too long and the implementation becomes the <br>
place de facto to redo policy recommendations. So NCSG would like to <br>
request the board for comments about the current speed or even how do <br>
you plan to work together with GNSO and its groups on possible <br>
improvements to the PDPs timeline and so on.<br>
<br>
What efforts are channeled to keep the people in the community <br>
from volunteer fatigue?<br>
<br>
<br>
<br>
Whois Disclosure System<br>
<br>
The recently published Whois Disclosure System design paper <br>
mentioned a risk that the system might not provide actionable data for <br>
use to answer questions raised by the SSAD ODA and this makes us a <br>
little concerned about the EPDP recommendations. The direction this work <br>
is going seems to point towards the intention to throw away the EPDP <br>
recommendations related to SSAD. I'd like to know what the board thinks <br>
about this concern.<br>
<br>
<br>
<br>
ICANN Leadership positions<br>
<br>
What is the Board’s take on the phenomenon of ICANN recycling <br>
veterans for leadership positions. Does the Board think it’s beneficial <br>
for the community to have the usual suspects rotating between leadership <br>
roles of different stakeholder groups? How do we fix this if we agree <br>
this is a problem? How does the Board imagine its role in assisting the <br>
community to recruit more new blood?<br>
<br>
<br>
NomCom<br>
<br>
NCSG has been talking for a long time about the lack of proper <br>
representation at the NomCom, the current state of things is that this <br>
part of the community only holds one seat at the group - currently held <br>
by NCUC - and we trust this configuration is not really representative <br>
of the diversity of stakeholders within GNSO or even proportional if we <br>
consider that other SGs hold more than just one seat. Therefore we have <br>
a very simple question: is there a possibility of rebalancing the NomCom?<br>
<br>
Julf<br>
_______________________________________________<br>
NCSG-PC mailing list<br>
<a href="mailto:NCSG-PC@lists.ncsg.is" target="_blank">NCSG-PC@lists.ncsg.is</a><br>
<a href="https://lists.ncsg.is/mailman/listinfo/ncsg-pc" rel="noreferrer" target="_blank">https://lists.ncsg.is/mailman/listinfo/ncsg-pc</a><br>
</blockquote></div>