<div dir="auto"><div>I think I am in Alan's corner here. Any independent structure needs to purposefully minimise friction with icann org. as far as that is possible. So a PTI look-alike should be deemed not suitable in this case. It is not impossible that outsourcing everything except an equal ICANN board and ICANN community oversight will be cost effective.</div><div dir="auto"> I am inclined to agree that it is all about implementation criteria that will most probably win the day. This is not an easy call, by any means, but we owe it to the underserved regions of the world in attempting to narrow the ever increasing digital divide.</div><div dir="auto"><br></div><div dir="auto">RD</div><div dir="auto"><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Fri, Jul 26, 2019, 16:31 Alan Greenberg <<a href="mailto:alan.greenberg@mcgill.ca">alan.greenberg@mcgill.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Based on a number of discussions here and privately among the <br>
At-Large Members, I would like to make a proposal.<br>
<br>
We have been focusing on "mechanisms" for the last LONG while. <br>
Perhaps that was a wrong approach.<br>
<br>
Based on recent comments from Maartin and Sam, ANY mechanism will use <br>
an arms-length project review process and it will not be ICANN <br>
employees making the decisions. So let's put that to bed.<br>
<br>
ANY of the mechanisms we have been looking at could be implemented so <br>
that they meet our goals, albeit in different ways and potentially <br>
for different costs. But any of them could also fail. For instance, a <br>
Foundation has been discussed with the presumption that it will be <br>
"independent" and not be subject to any direct ICANN involvement. But <br>
as an example, PTI is a corporation separate from ICANN, but a <br>
controlling majority of its Board is selected by ICANN and it <br>
out-sources significant services from ICANN. If we were to implement <br>
the Foundation that way, many among us would believe that it is not <br>
at all independent.<br>
<br>
So it is not the name that matters, or the corporate structure, but <br>
the details of HOW it is implemented that matters.<br>
<br>
Perhaps we should not worry about the "mechanism" and focus instead <br>
on criteria. Based on that, I suspect the mechanism choice will be a <br>
simple business decision and not the political (or religious?) <br>
decision it now is.<br>
<br>
One clear criteria is that the project selection should be done <br>
independent of ICANN - already agreed upon by all.<br>
<br>
What else is there that we feel might differentiate a good <br>
implementation from a bad one?<br>
<br>
Perhaps: Do not build processes/staff if the service can be readily <br>
and economically outsourced?<br>
<br>
Perhaps: Do not replicate services already available from ICANN if <br>
they do not impact the integrity of the granting process (which <br>
includes advertising, granting, project outcome evaluation, reporting)<br>
<br>
There are likely more, but I suspect there are not actually that many.<br>
<br>
Alan<br>
<br>
<br>
<br>
_______________________________________________<br>
Ccwg-auctionproceeds mailing list<br>
<a href="mailto:Ccwg-auctionproceeds@icann.org" target="_blank" rel="noreferrer">Ccwg-auctionproceeds@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/ccwg-auctionproceeds" rel="noreferrer noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/ccwg-auctionproceeds</a><br>
_______________________________________________<br>
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy" rel="noreferrer noreferrer" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" rel="noreferrer noreferrer" target="_blank">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.<br>
</blockquote></div></div></div>