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

[Sergio Salinas Porto]

+1

*Sergio Salinas Porto**Presidente Internauta Argentina - LACRALO/ICANN
<https://atlarge.icann.org/ralos/lacralo>**Asociación Argentina de
Usuarios de Internet <http://www.internauta.org.ar/>/FeTIA
<http://www.fetia.org.ar/>**FUILAC- Federación de Usuarios de Internet
de LAC <https://fuilac.org>**facebook: salinasporto
<http://www.facebook.com/salinasporto> **twitter:  sergiosalinas
<http://twitter.com/sergiosalinas>**Mobi:+54 9 223 5 215819**"Ojalá
podamos ser desobedientes, cada vez que recibimos órdenes que humillan
nuestra *

* conciencia o violan nuestro sentido común" Eduardo Galeano*



El vie, 19 abr 2024 a las 11:41, Evan Leibovitch via CPWG (<cpwg at icann.org>)
escribió:

> Thanks for the reply, Alan.
>
>
>> 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.
>>
>
> 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.
>
> 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.
>>
>
> ICANN sets out rules and provisions in its registry contracts and, one
> would imagine, also lays out consequences for breaking said rules.
> 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.
>
> 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.
>
> This is where the majority of the ALAC discussion and response ought to
> lie, but it begs a larger question:
> To what extent should ALAC be serving as ICANN's process police?
>
> 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.
>
> In other words: *Given its bylaw mandate*, 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?
>
> I look forward to a clear answer that does not fall back on a weaponized
> and amorphous appeal to "trust".
> Cheers,
>
> - 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/20240419/d72006c6/attachment.html>