<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)">Hi Bill,<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 21, 2024 at 1:26 PM Bill Jouris <<a href="mailto:b_jouris@yahoo.com">b_jouris@yahoo.com</a>> wrote:<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>In response to your question: </div><div><span style="color:rgb(11,83,148);font-family:tahoma,sans-serif">To what extent should ALAC be serving as ICANN's process police?</span><br></div><div>I think the answer should be: "To the extent that the failure to follow ICANN's process in a particular instance had a negative impact on end users." </div></blockquote><div><br></div><div><div style="font-family:tahoma,sans-serif;color:rgb(11,83,148)" class="gmail_default">I agree.</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">But Alan's comment -- with which I also agree -- suggests that ICM's change requests were mostly reasonable, and generally bring .XXX to be consistent with other gTLDs that did not have to go through ICM's needlessly-extraordinary approval process.<br></div><br></div><div><div style="font-family:tahoma,sans-serif;color:rgb(11,83,148)" class="gmail_default">So in this case, the correct result happened but (if indeed process abuse took place) came about in an incorrect way. The OUTCOME of all this, process abuse or not, did not have a negative impact on end-users. Indeed I would assert that the impact is positive. Most of the public just sees the end result: reasonable changes to the renewed contract. Only insiders are aware that the way it was done was not strictly kosher. <br></div><div style="font-family:tahoma,sans-serif;color:rgb(11,83,148)" class="gmail_default"><br>Based on your answer, then, this is not an instance where At-Large's intervention is warranted because there is no negative impact based on the outcomes. It is up to ICANN and ICM's peers to determine whether any breach of process was serious enough to warrant consequences. Now, if end users are impacted by any judgment that ICANN may assess as a result of ICM infractions, then ALAC response might be appropriate. But no such action to date has been taken.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>In the cases here, the contract requirements which were not followed were, if I understand correctly, intended to protect end users.</div></blockquote><div><br></div><div><div style="font-family:tahoma,sans-serif;color:rgb(11,83,148)" class="gmail_default">Which ones were they? I didn't see any in Michael's presentation.<br></div></div><div><br></div><div><div style="font-family:tahoma,sans-serif;color:rgb(11,83,148)" class="gmail_default">From my PoV, the extraordinary requirements had nothing to do with protection of the public. In my analysis they were intended to establish .XXX being the primary collection of content seen by some as objectionable, that could then be easily mass-blocked by censor-minded entities. I personally consider facilitation of blocking ANY part of the Internet well beyond ICANN's mandate, and I welcome any moves that render .XXX to be Just Another gTLD.<br></div><br></div><div><div style="font-family:tahoma,sans-serif;color:rgb(11,83,148)" class="gmail_default">- Evan<br></div></div></div><br></div>