<div dir="ltr">Hi all<div><br></div><div>Some brief comments on the report where I try not to repeat things others have said. Also not to repeat things discussed on WP1 calls. May be some repetition however.</div><div><br></div><div>First - thanks to the staff for doing a great job with this. </div><div><br></div><div>In the Main Report:</div><div><br></div><div>P5 - this sentence "<span style="font-size:11pt;font-family:Helvetica">Workable consensus reforms that enhance the role
</span><span style="font-size:11pt;font-family:Helvetica">of the community and ICANN’s Mission should be consistent with ICANN’s interest as a corporate
</span><span style="font-size:11pt;font-family:Helvetica">entity.</span>" - I think like Steve it needs to be deleted. I *assume* what it means is "they should be consistent so ICANN wouldn't try to block it", but I think it reads as "reforms that aren't in ICANN's corporate interests won't happen" - the first is fine the second is not.</div><div><br></div><div>P8 and elsewhere - the order of the recommendations and the annexes is wrong. We should start with the powers we are granting the community (#4), then how they are used (EEE - #2), then the model for enforceability of those powers (#1) and then onto the bylaws etc (#3 and on). Otherwise we are telling the story the wrong way around.</div><div><br></div><div>P9 and elsewhere - the CCWG did not change from SM to SD because of the "risks" - that language is too strong. There were concerns about perceived risks and those concerns led to a change, which was acceptable because Sole Designator could meet our requirements. So the subheading of the previous section is fine ("Concerns with a sole member model") --- but the first sentence of the next section has to talk about concerns, not risks.</div><div><br></div><div>P10 and elsewhere - in the detail requirements list #1 - this sentence is the wrong way around. The form the Empowered Community takes is of a California-based unincorporated association, and it is to have legal standing as a Sole Designator.</div><div><br></div><div>P11 and elsewhere - Rec 2 - the point of this process is not to prevent disagreements happening, it is to resolve disagreements constructively. The language should reflect that.</div><div><br></div><div>P. 28 and elsewhere - all the starting timelines to exercise powers that the community initiates or that start by Board action need to be from the date the Board action is announced, not the date the decision is made. People can't start to act on a decision they don't know about. This needs to be consistent throughout the proposal.</div><div><br></div><div><br></div><div>Annex 1:</div><div>P1 - the idea of NTIA as a "perceived enforcement body" is misleading and wrong. The language we used in the Second Draft Report is more honest and more accurate - something like "With the end of the iANA Functions Contract between ICANN and NTIA, and the perceived backstop accountability this provided..."</div><div><br></div><div>P1 - the Sole Designator legal entity does not only have the power to add/remove directors. It also has the power under law to be required to agree to bylaw changes. I think we need to clarify that. A quick chat with the lawyers should answer the point.</div><div><br></div><div>P4 - members of the Empowered Community UA - we have to be clear that the decisions are taken in the SOs and ACs, and vitally, that that applies no matter whether or not that SO or AC has a 'real live human being' as a participant in the Empowered Community UA. This is because otherwise we risk re-creating concerns about the "avatar problem" that dogged our First Draft Proposal membership system, and because some SOs or ACs might find it impossible to appoint an individual to such a role.</div><div><br></div><div>Annex 2: </div><div>P9 - it needs to be clear that the community can commence using the Board Recall power even if an IRP is under way (since the Board Recall power is unconstrained in the "cause" sense).</div><div><br></div><div>Annex 3: </div><div>- we should apply an approvals process to the Articles. I am not concerned whether it's on the same co-approval basis as for Fundamental Bylaws, or rejection basis as for Standard Bylaws, but it needs to be one or the other.</div><div><br></div><div>Annex 4:</div><div>- need to include Community IRP and IFR material. Don't care if this gets relabelled 7 powers to accommodate. </div><div>- It's also probably the logical location for the table setting out decision thresholds.</div><div><br></div><div><br></div><div>A couple of final broader points:</div><div><br></div><div>- the IANA Functions Review needs to be spelled out in more detail somewhere</div><div>- I agree with Greg's comments about principles</div><div>- I agree with Steve's points about AOC reviews and the Summary part of the main report needs to be clear that it's more than just the Reviews being ported in from the AOC</div><div>- timelines for powers - we probably need to extend the petition phase a little to make sure the (new, higher) threshold of two SOs/ACs can get their act together.</div><div><br></div><div><br></div><div>Hope this helps</div><div><br></div><div>Jordan</div><div><br></div><div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr" style="font-size:small">Jordan Carter<br><br>Chief Executive <br><b>InternetNZ</b><br></div><div dir="ltr" style="font-size:small"><br>+64-4-495-2118 (office) | +64-21-442-649 (mob)<br>Email: <a href="mailto:jordan@internetnz.net.nz" style="color:rgb(17,85,204)" target="_blank">jordan@internetnz.net.nz</a> <br>Skype: jordancarter<br></div><div style="font-size:small">Web: <a href="http://www.internetnz.nz" target="_blank">www.internetnz.nz</a> </div><div dir="ltr" style="font-size:small"><br><i>A better world through a better Internet </i></div><br></div></div></div></div></div></div></div></div>
</div></div>