On adult websites, inertia, and basic fairness
Hi all, On Wednesday, among other topics was a presentation suggesting the position that ALAC should take regarding renewal of the contract for the .XXX TLD. The presentation offered was a dissection of the substance of changes proposed by the ICM registry for its new contract. Responses to the assertion that the CPWG was engaging in mission-creep were, IMO, confused and disturbing. Some of the counter-arguments made were that the registry was reneging on previous commitments and that it was somehow breaking the rules. Now, if during the run of its contract to date the registry did not keep true to its commitments, that is a serious issue and, as Carlton said in the call, as much a matter for ICANN compliance as for the registry. But that's not what was presented. What I saw was the registry taking the opportunity of the contract renewal to request a change in its terms and it is totally legitimate of them to do so. This renegotiation, on its face, is not an abuse of process, but exactly how the process is supposed to work. If the concern is that ICM has proposed contract changes, especially to remove safeguards, then let's examine those requests on their merits, and *strictly* through the lens of end-user impact. Specifically, I find the notion that provisions in the previous contract that are the subject of change request should be rejected primarily because they existed in the previous contract is ... ill-considered. "Because we've always done things that way" is broadly considered to be a dangerous <https://www.forbes.com/sites/forbeslacouncil/2019/01/28/the-most-dangerous-p...> and regressive basis for decision-making. If there is a change request that specifically impacts end-users, absolutely bring it forward. I found little of that, mainly because there was such a broad scattering of out-of-scope complaints that legitimate ones were surely buried. Complaining that the registry wants to enable the use of the TLD by registrants that are not part of the adult industry, for instance, does not serve the interest of end-users. That is a choice for would-be registrants to make. The approach taken demonstrates quite well the mission-creep pervasive within ALAC and this committee. Such overreach reflects poorly on us and diminishes the likelihood that our advice will be heeded. Legitimate concerns risk being rejected alongside the extraneous ones. Recall that this is a particular case of a TLD application made under very charged and political circumstances. I was at the 2011 San Francisco meeting where it was up for delegation and saw the street protests up-close. And while ICANN likes to say that it doesn't regulate^H^H^H^H^H^H^H^Hcontract based on content, any controversy about .XXX at the time concerned nothing EXCEPT content. As a result I'm not surprised if the registry had to make extraordinary promises that have proven to be unsustainable in the dozen years that have passed. And now we have the benefit of hindsight. As it turns out, .XXX did not become the porn ghetto whose mass-blockage could keep the Internet clean by decree. A survey of the industry today reveals that NONE, not one, of the top 20 adult Internet destinations worldwide use .XXX. As a consequence, the singling out of .XXX for attention regarding sexual or child exploitation (etc), and insisting that it meet requirements not demanded of TLDs where the actual adult industry can be found, is the height of hypocrisy and political posturing. Either let's advocate to raise the mandatory standards of other TLDs to those demanded of .XXX, or allow it to relax its standards to the levels of other TLDs. What was ultimately most noteworthy to me about the debate was the use of "trust" to justify both the hypocrisy and the resistance to change. Indeed, this weaponization of "trust" on display was more obscene than anything found in the websites under .XXX. But that's a separate topic, best kept for another day. Cheers, Evan
I was not on the call on Wednesday and have not listened to the recording. However I was on previous calls and was particularly vocal, so let me say what I think are (or were?) the issues. 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. 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. There are (at least) two separate issues at play here, and it is important to keep them separate. I will listen to the regording when I have the time and see how the discussion evolved in my absence. Alan On Thu, Apr 18, 2024 at 6:11 PM Evan Leibovitch via CPWG <cpwg@icann.org> wrote:
Hi all,
On Wednesday, among other topics was a presentation suggesting the position that ALAC should take regarding renewal of the contract for the .XXX TLD.
The presentation offered was a dissection of the substance of changes proposed by the ICM registry for its new contract. Responses to the assertion that the CPWG was engaging in mission-creep were, IMO, confused and disturbing.
Some of the counter-arguments made were that the registry was reneging on previous commitments and that it was somehow breaking the rules.
Now, if during the run of its contract to date the registry did not keep true to its commitments, that is a serious issue and, as Carlton said in the call, as much a matter for ICANN compliance as for the registry. But that's not what was presented. What I saw was the registry taking the opportunity of the contract renewal to request a change in its terms and it is totally legitimate of them to do so. This renegotiation, on its face, is not an abuse of process, but exactly how the process is supposed to work.
If the concern is that ICM has proposed contract changes, especially to remove safeguards, then let's examine those requests on their merits, and *strictly* through the lens of end-user impact.
Specifically, I find the notion that provisions in the previous contract that are the subject of change request should be rejected primarily because they existed in the previous contract is ... ill-considered. "Because we've always done things that way" is broadly considered to be a dangerous <https://www.forbes.com/sites/forbeslacouncil/2019/01/28/the-most-dangerous-p...> and regressive basis for decision-making.
If there is a change request that specifically impacts end-users, absolutely bring it forward. I found little of that, mainly because there was such a broad scattering of out-of-scope complaints that legitimate ones were surely buried. Complaining that the registry wants to enable the use of the TLD by registrants that are not part of the adult industry, for instance, does not serve the interest of end-users. That is a choice for would-be registrants to make.
The approach taken demonstrates quite well the mission-creep pervasive within ALAC and this committee. Such overreach reflects poorly on us and diminishes the likelihood that our advice will be heeded. Legitimate concerns risk being rejected alongside the extraneous ones.
Recall that this is a particular case of a TLD application made under very charged and political circumstances. I was at the 2011 San Francisco meeting where it was up for delegation and saw the street protests up-close. And while ICANN likes to say that it doesn't regulate^H^H^H^H^H^H^H^Hcontract based on content, any controversy about .XXX at the time concerned nothing EXCEPT content. As a result I'm not surprised if the registry had to make extraordinary promises that have proven to be unsustainable in the dozen years that have passed.
And now we have the benefit of hindsight. As it turns out, .XXX did not become the porn ghetto whose mass-blockage could keep the Internet clean by decree. A survey of the industry today reveals that NONE, not one, of the top 20 adult Internet destinations worldwide use .XXX.
As a consequence, the singling out of .XXX for attention regarding sexual or child exploitation (etc), and insisting that it meet requirements not demanded of TLDs where the actual adult industry can be found, is the height of hypocrisy and political posturing. Either let's advocate to raise the mandatory standards of other TLDs to those demanded of .XXX, or allow it to relax its standards to the levels of other TLDs.
What was ultimately most noteworthy to me about the debate was the use of "trust" to justify both the hypocrisy and the resistance to change. Indeed, this weaponization of "trust" on display was more obscene than anything found in the websites under .XXX. But that's a separate topic, best kept for another day.
Cheers, Evan
_______________________________________________ CPWG mailing list CPWG@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.
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
+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@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@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.
Hi Evan, 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." In the cases here, the contract requirements which were not followed were, if I understand correctly, intended to protect end users. We might, of course, decide that those provisions were not fit for purpose, and so not worth our time to raise the issue. But if we think they were appropriate (at least at the time), I think we have an obligation to raise the issue. Regards, Bill Jouris Sent from Yahoo Mail on Android On Fri, Apr 19, 2024 at 7:41 AM, Evan Leibovitch via CPWG<cpwg@icann.org> wrote: _______________________________________________ CPWG mailing list CPWG@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.
Hi Bill, On Sun, Apr 21, 2024 at 1:26 PM Bill Jouris <b_jouris@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
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@icann.org> wrote:
Hi Bill,
On Sun, Apr 21, 2024 at 1:26 PM Bill Jouris <b_jouris@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@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.
Hi Carlton, On Mon, Apr 22, 2024 at 12:44 PM Carlton Samuels <carlton.samuels@gmail.com> wrote:
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).
[...]
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.
My agreement with this sentiment is basically why I didn't mention them. I consider them irrelevant for the reasons you mentioned. You can put lipstick on a PIC but that doesn't make it useful. - Evan
+1 Carlton On Thu, 18 Apr 2024, 5:11 pm Evan Leibovitch via CPWG, <cpwg@icann.org> wrote:
Hi all,
On Wednesday, among other topics was a presentation suggesting the position that ALAC should take regarding renewal of the contract for the .XXX TLD.
The presentation offered was a dissection of the substance of changes proposed by the ICM registry for its new contract. Responses to the assertion that the CPWG was engaging in mission-creep were, IMO, confused and disturbing.
Some of the counter-arguments made were that the registry was reneging on previous commitments and that it was somehow breaking the rules.
Now, if during the run of its contract to date the registry did not keep true to its commitments, that is a serious issue and, as Carlton said in the call, as much a matter for ICANN compliance as for the registry. But that's not what was presented. What I saw was the registry taking the opportunity of the contract renewal to request a change in its terms and it is totally legitimate of them to do so. This renegotiation, on its face, is not an abuse of process, but exactly how the process is supposed to work.
If the concern is that ICM has proposed contract changes, especially to remove safeguards, then let's examine those requests on their merits, and *strictly* through the lens of end-user impact.
Specifically, I find the notion that provisions in the previous contract that are the subject of change request should be rejected primarily because they existed in the previous contract is ... ill-considered. "Because we've always done things that way" is broadly considered to be a dangerous <https://www.forbes.com/sites/forbeslacouncil/2019/01/28/the-most-dangerous-p...> and regressive basis for decision-making.
If there is a change request that specifically impacts end-users, absolutely bring it forward. I found little of that, mainly because there was such a broad scattering of out-of-scope complaints that legitimate ones were surely buried. Complaining that the registry wants to enable the use of the TLD by registrants that are not part of the adult industry, for instance, does not serve the interest of end-users. That is a choice for would-be registrants to make.
The approach taken demonstrates quite well the mission-creep pervasive within ALAC and this committee. Such overreach reflects poorly on us and diminishes the likelihood that our advice will be heeded. Legitimate concerns risk being rejected alongside the extraneous ones.
Recall that this is a particular case of a TLD application made under very charged and political circumstances. I was at the 2011 San Francisco meeting where it was up for delegation and saw the street protests up-close. And while ICANN likes to say that it doesn't regulate^H^H^H^H^H^H^H^Hcontract based on content, any controversy about .XXX at the time concerned nothing EXCEPT content. As a result I'm not surprised if the registry had to make extraordinary promises that have proven to be unsustainable in the dozen years that have passed.
And now we have the benefit of hindsight. As it turns out, .XXX did not become the porn ghetto whose mass-blockage could keep the Internet clean by decree. A survey of the industry today reveals that NONE, not one, of the top 20 adult Internet destinations worldwide use .XXX.
As a consequence, the singling out of .XXX for attention regarding sexual or child exploitation (etc), and insisting that it meet requirements not demanded of TLDs where the actual adult industry can be found, is the height of hypocrisy and political posturing. Either let's advocate to raise the mandatory standards of other TLDs to those demanded of .XXX, or allow it to relax its standards to the levels of other TLDs.
What was ultimately most noteworthy to me about the debate was the use of "trust" to justify both the hypocrisy and the resistance to change. Indeed, this weaponization of "trust" on display was more obscene than anything found in the websites under .XXX. But that's a separate topic, best kept for another day.
Cheers, Evan
_______________________________________________ CPWG mailing list CPWG@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.
Hi all I would like to make a comment only on this paragraph: Recall that this is a particular case of a TLD application made under very charged and political circumstances. I was at the 2011 San Francisco meeting where it was up for delegation and saw the street protests up-close. And while ICANN likes to say that it doesn't regulate^H^H^H^H^H^H^H^Hcontract based on content, any controversy about .XXX at the time concerned nothing EXCEPT content. As a result I'm not surprised if the registry had to make extraordinary promises that have proven to be unsustainable in the dozen years that have passed. and specifically on the assertion “nothing EXCEPT content”. I was no longer on the Board when .xxx was finally delegated, but remember well the discussions when it was first presented to the Board, and rejected. My position of denying delegation was based exclusively on the consideration that the proposers failed to fulfil one of the necessary requirements of an sTLD, that is the consensus of the community it aimed at serving. This is, to me, of the paramount importance, because the rationale for having a new round was to allow TLDs that were targeting a specific and well identified community. The problem with the .xxx proposal was that they were unable to show support of the adult industry: they did indeed have some support, but there were large parts who where against (for reasons that are beyond the scope of this discussion). This has absolutely nothing to do with contents. This said, Evan might be right in saying that in 2011 the situation might have been different. My personal opinion, having followed things only from the distance after my departure from the Board, is that the delegation was done under pressure to avoid potential lawsuits - again not related to “content”. This said, on the specific matter on ALAC’s position on the renewal, I do not have a definite opinion. Best regards, Roberto
Hi Roberto,
I was no longer on the Board when .xxx was finally delegated, but remember well the discussions when it was first presented to the Board, and rejected. My position of denying delegation was based exclusively on the consideration that the proposers failed to fulfil one of the necessary requirements of an sTLD, that is the consensus of the community it aimed at serving.
Thanks for the refresh. While I was never quite the fan of community TLDs -- a concept that has not aged well -- I appreciate the context you offer. My personal opinion, having followed things only from the distance after my
departure from the Board, is that the delegation was done under pressure to avoid potential lawsuits - again not related to “content”.
In retrospect, I think you are correct. And if I recall right, that potential lawsuit was from ICM suing ICANN for arbitrarily subjecting it to greater scrutiny than other applicants. I wonder what reasons they would have argued would have caused the special treatment ... but we'll never know. 😉 Cheers, - Evan
participants (6)
-
Alan Greenberg -
Bill Jouris -
Carlton Samuels -
Evan Leibovitch -
Roberto Gaetano -
Sergio Salinas Porto