[CPWG] On adult websites, inertia, and basic fairness

[Carlton Samuels]

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.

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.

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.

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.

And let's be clear: ICANN won't be caught dead acting like a regulator.

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.

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.

History will absolve me.

Carlton

==============================
*Carlton A Samuels*

*Mobile: 876-818-1799Strategy, Process, Governance, Assessment & Turnaround*
=============================


On Sun, 21 Apr 2024 at 16:19, Evan Leibovitch via CPWG <cpwg at icann.org>
wrote:

> Hi Bill,
>
> On Sun, Apr 21, 2024 at 1:26 PM Bill Jouris <b_jouris at yahoo.com> wrote:
>
>
>> In response to your question:
>> To what extent should ALAC be serving as ICANN's process police?
>> 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."
>>
>
> I agree.
>
> 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.
>
> 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.
>
> 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.
>
>
>> In the cases here, the contract requirements which were not followed
>> were, if I understand correctly, intended to protect end users.
>>
>
> Which ones were they? I didn't see any in Michael's presentation.
>
> 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.
>
> - Evan
>
> _______________________________________________
> CPWG mailing list
> CPWG at icann.org
> https://mm.icann.org/mailman/listinfo/cpwg
>
> _______________________________________________
> 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 (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/cpwg/attachments/20240422/8bb007d0/attachment-0001.html>