<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif"><p style="border:0px solid rgb(227,227,227);box-sizing:border-box;margin:0px 0px 1.25em;color:rgb(13,13,13);font-family:Söhne,ui-sans-serif,system-ui,-apple-system,"Segoe UI",Roboto,Ubuntu,Cantarell,"Noto Sans",sans-serif,"Helvetica Neue",Arial,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Noto Color Emoji";font-size:14px">I appreciate Evan for providing some context to this discussion. It's encouraging to see constructive thinking in the midst of this situation. Let's keep it up.</p><p style="border:0px solid rgb(227,227,227);box-sizing:border-box;margin:1.25em 0px;color:rgb(13,13,13);font-family:Söhne,ui-sans-serif,system-ui,-apple-system,"Segoe UI",Roboto,Ubuntu,Cantarell,"Noto Sans",sans-serif,"Helvetica Neue",Arial,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Noto Color Emoji";font-size:14px">One thing I wish Evan had addressed is the issue of singular and extended agreements in Registry Agreements (RAs), particularly those that are Registry Voluntary Commitments (RVCs). These agreements only matter if there is a dependable and assured mechanism for enforcing compliance.</p><p style="border:0px solid rgb(227,227,227);box-sizing:border-box;margin:1.25em 0px;color:rgb(13,13,13);font-family:Söhne,ui-sans-serif,system-ui,-apple-system,"Segoe UI",Roboto,Ubuntu,Cantarell,"Noto Sans",sans-serif,"Helvetica Neue",Arial,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Noto Color Emoji";font-size:14px">Here's the crux of the matter: Any worthwhile addition to the base RA, whether voluntary or not, will inevitably impact a business case or extend an operational process for a valid reason. From my years of regulatory compliance practice, I believe ICANN would be wise to avoid interfering in any business case.</p><p style="border:0px solid rgb(227,227,227);box-sizing:border-box;margin:1.25em 0px;color:rgb(13,13,13);font-family:Söhne,ui-sans-serif,system-ui,-apple-system,"Segoe UI",Roboto,Ubuntu,Cantarell,"Noto Sans",sans-serif,"Helvetica Neue",Arial,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Noto Color Emoji";font-size:14px">Furthermore, any compliance action in these areas should be properly defined as regulatory actions. If they must be enforced by agency of ICANN Compliance, they should be assessed and judged as ex ante regulation.</p><p style="border:0px solid rgb(227,227,227);box-sizing:border-box;margin:1.25em 0px;color:rgb(13,13,13);font-family:Söhne,ui-sans-serif,system-ui,-apple-system,"Segoe UI",Roboto,Ubuntu,Cantarell,"Noto Sans",sans-serif,"Helvetica Neue",Arial,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Noto Color Emoji";font-size:14px">And let's be clear: ICANN won't be caught dead acting like a regulator.</p><p style="border:0px solid rgb(227,227,227);box-sizing:border-box;margin:1.25em 0px;color:rgb(13,13,13);font-family:Söhne,ui-sans-serif,system-ui,-apple-system,"Segoe UI",Roboto,Ubuntu,Cantarell,"Noto Sans",sans-serif,"Helvetica Neue",Arial,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Noto Color Emoji";font-size:14px">I'll say it again: The RVCs and any other additions to the base RA, without a commitment to enforcement, are not worth a bucket of warm spit. They were never meant to be taken seriously because there has never been, and never will be, any appetite for ICANN to act as a regulator.</p><p style="border:0px solid rgb(227,227,227);box-sizing:border-box;margin:1.25em 0px;color:rgb(13,13,13);font-family:Söhne,ui-sans-serif,system-ui,-apple-system,"Segoe UI",Roboto,Ubuntu,Cantarell,"Noto Sans",sans-serif,"Helvetica Neue",Arial,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Noto Color Emoji";font-size:14px">ICM's request for the removal of a previous commitment in the RA that was itself unenforceable holds little importance, starting with ICANN Compliance. The ex ante outcome shall be the same as the ex post outcome. Let's avoid unnecessary vexations and save the outrage.</p><p style="border:0px solid rgb(227,227,227);box-sizing:border-box;margin:1.25em 0px 0px;color:rgb(13,13,13);font-family:Söhne,ui-sans-serif,system-ui,-apple-system,"Segoe UI",Roboto,Ubuntu,Cantarell,"Noto Sans",sans-serif,"Helvetica Neue",Arial,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Noto Color Emoji";font-size:14px">History will absolve me.</p></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Carlton </div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><br>==============================<br><i><font face="comic sans ms, sans-serif">Carlton A Samuels</font></i><br><font face="comic sans ms, sans-serif"><i>Mobile: 876-818-1799<br><font color="#33CC00">Strategy, Process, Governance, Assessment & Turnaround</font></i></font><br>=============================</div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 21 Apr 2024 at 16:19, Evan Leibovitch via CPWG <<a href="mailto:cpwg@icann.org">cpwg@icann.org</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"><div dir="ltr"><div dir="ltr"><div 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" target="_blank">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)">I agree.</div><div style="font-family:tahoma,sans-serif;color:rgb(11,83,148)"><br></div><div style="font-family:tahoma,sans-serif;color:rgb(11,83,148)">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)">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)"><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)">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)">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)">- Evan<br></div></div></div><br></div>
_______________________________________________<br>
CPWG mailing list<br>
<a href="mailto:CPWG@icann.org" target="_blank">CPWG@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/cpwg" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/cpwg</a><br>
<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" 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" 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.</blockquote></div></div>