<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)">Thanks for the reply, Alan.<br></div></div> <div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The world has moved on since .xxx had to make all of its commitments to (narrowly) get approved. Other 2012-round adult registries exist that did not have to jump though the same hurdles. So the changes by-and-large are probably reasonable.</div></div></blockquote><div><br></div><div><div style="font-family:tahoma,sans-serif;color:rgb(11,83,148)" class="gmail_default">That sounds right to me. And yet comment on the substance formed a majority of the presentation as well as the discussion, and I presume was intended to be a significant part of ALAC's response to the renewal. I leave it to you to watch the recording and see for yourself.<br></div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>What is less reasonable is that many of the changes have already been put in place without going through the proper (RSEP) processes to change registry conditions and apparently (to be verified) this was done with no action from compliance. Moreover, putting these new terms in a renewed contract is effectively rewarding the registry for ignoring the rules and that is a scary precedent in that they will no longer be answerable to their apparent prior contract violations.</div></div></blockquote><div><br></div><div><div style="font-family:tahoma,sans-serif;color:rgb(11,83,148)" class="gmail_default">ICANN sets out rules and provisions in its registry contracts and, one would imagine, also lays out consequences for breaking said rules.</div><div style="font-family:tahoma,sans-serif;color:rgb(11,83,148)" class="gmail_default">If the registry agreement was breached and ICANN did not act, one would reasonably infer that either the compliance department was ineffective or that ICANN was OK with the way things were done. In either case, any blame for the lack of consequences lies with ICANN, not the registry.<br></div></div><div><br></div><div><div style="font-family:tahoma,sans-serif;color:rgb(11,83,148)" class="gmail_default">If, on the other hand, what ICM did was allowed by the contract but not "proper", the cause for objection is massively weaker but still legitimate. An explanation from ICANN compliance regarding why it did not act, and advice based on that followup, may seem warranted. <br></div><br><div style="font-family:tahoma,sans-serif;color:rgb(11,83,148)" class="gmail_default">This is where the majority of the ALAC discussion and response ought to lie, but it begs a larger question:</div><div style="font-family:tahoma,sans-serif;color:rgb(11,83,148)" class="gmail_default">To what extent should ALAC be serving as ICANN's process police?</div>

</div><div><br></div><div><div style="font-family:tahoma,sans-serif;color:rgb(11,83,148)" class="gmail_default">The "we can't let them get away with this" tone of this analysis is a purely emotional response. If anything, other registries should be offering the greatest objections if ICM is perceived to obtain a benefit unavailable to the rest of them. This unfairness affects THEM, not us. <br><br>In other words: <u>Given its bylaw mandate</u>, exactly why is this ALAC's business? How does an internal breach of process by a registry, that is un-acted upon but still leads to reasonable outcomes, directly impact the Internet end-user?<br><br>I look forward to a clear answer that does not fall back on a weaponized and amorphous appeal to "trust".<br></div></div><div><div style="font-family:tahoma,sans-serif;color:rgb(11,83,148)" class="gmail_default"></div></div><div><div style="font-family:tahoma,sans-serif;color:rgb(11,83,148)" class="gmail_default">Cheers,</div><div style="font-family:tahoma,sans-serif;color:rgb(11,83,148)" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif;color:rgb(11,83,148)" class="gmail_default">- Evan<br></div></div><br></div></div>