ICANN ICANN Email List Archives

[soac-mapo]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [soac-mapo] On "universal resolvability" and useful questions that emerged yesterday

  • To: Stuart Lawley <stuart@xxxxxxxxxx>
  • Subject: Re: [soac-mapo] On "universal resolvability" and useful questions that emerged yesterday
  • From: Antony Van Couvering <avc@xxxxxxxxxxxxxxxxxxxx>
  • Date: Tue, 31 Aug 2010 08:35:14 -0700

It is no secret, and certainly no offense meant to Stuart, that a salient 
selling point of .XXX is that it will help segregate x-rated material into a 
particular TLD, which can then be easily blocked by parents, governments, etc., 
who do not want their wards to view such things.  This is what I meant by 
"exists to be blocked."   How much it is blocked will be a decent measure of 
how successful Stuart is in getting everyone with x-rated sites to use .XXX.   
It will not decrease the use of such sites, but if it works will let everyone 
know where to find them -- and make it easy to block them. 

It is clear to me that our discussion has nothing to do with the prevention of 
hateful, violence-inciting, or religiously intolerant content, *except insofar 
as that content is contained within the name itself.*  That is a very high bar, 
because as Philip points out, "incest" and "killer" do not fall within the 
ambit of that standard within the EU, because there are perfectly innocent 
descriptive uses of these words.

A reasonable standard to me at this point looks like this:

-- Does the existence of the string itself incite people to violence, religious 
intolerance, pedophilia, cannibalism, or whatever semi-universal taboo we 
enumerate ?
-- Does the applicant or its principals have a proven history of trying to 
incite such things?
-- Is the meaning of the string unambiguous (there are no other innocent uses 
for it)?

If the "quick look" answer to all these three questions is yes, then it should 
go to a broad-based panel, which might include outside experts.  Upon this 
panel's recommendation to the Board to reject the TLD, the Board may block the 
application by a supermajority vote.  This procedure should happen early in the 
process so that no-one is put through the Seven Years of Hell that Stuart went 
through.  This process should be separate and independent of objections on 
other grounds. 

Antony

On Aug 31, 2010, at 7:53 AM, Stuart Lawley wrote:

> I will keep my powder dry on Antonys description on this one Bertrand ;-)
> 
> 
> 
> On Aug 31, 2010, at 10:44 AM, Bertrand de La Chapelle wrote:
> 
>> Anthony,
>> 
>> It's only a paradox if you interpret universal availability as a principle 
>> that should apply to any possible string proposition (as if there is a sort 
>> of "right to be in the root"). But the objective is universal availability 
>> of the strings that will be accepted in the root (those rejected will be for 
>> many reasons, ie : all the diverse objections listed in the DAG). The 
>> ambition is that strings that are in the global common root are as 
>> universally available as possible. But you are right in a certain way : 
>> there is potentially a sort of intellectual feedback loop there.
>> 
>> Interesting qualification of .xxx as "existing to be blocked" :-) Not sure 
>> this is what Stuart had or has in mind ... 
>> 
>> Best
>> 
>> Bertrand
>> 
>> 
>> 
>> On Tue, Aug 31, 2010 at 4:24 PM, Antony Van Couvering 
>> <avc@xxxxxxxxxxxxxxxxxxxx> wrote:
>> Bertrand,
>> 
>> Thank you for this resume and overview.  It is very helpful.
>> 
>> At the heart of your argument is an interesting paradox.  Shall we set up 
>> rules to block certain strings in order to preserve universal availability?  
>> If a string is blocked, it is available to no-one at all, and hence is the 
>> opposite of universally available.  If it is blocked only partially, for 
>> example by certain governments, then it is not universally available, but it 
>> is nonetheless far more available than if it had never seen the light of day 
>> at all.
>> 
>> What are your thoughts then on .XXX, which exists to be blocked?
>> 
>> Antony
>> 
>> 
>> On Aug 31, 2010, at 4:56 AM, Bertrand de La Chapelle wrote:
>> 
>> > Dear all,
>> >
>> > Following Milton's request, I'm trying here to reformulate more clearly 
>> > what I said at the end of the discussion yesterday regarding universal 
>> > resolvability. This is an attempt to reframe the issue we are facing to 
>> > make it more addressable. I am not speaking on behalf of the whole GAC 
>> > here, as this has not been discussed in that level of detail yet.
>> >
>> > 1) It is true that there is no absolute universal resolvability today at 
>> > the Top Level. However, among the 270 TLDs or so, blocking of a whole TLD 
>> > is an extremely rare case and only done (from what I've heard) by a very 
>> > limited number of countries. Hence, we can consider that there is a 
>> > general situation of universal resolvability, with some rare exceptions. 
>> > (universal resolvability here is not understood in the pure technical 
>> > sense of the term but more as "universal availability"). This has clearly 
>> > been a positive situation for the Internet as a whole.
>> >
>> > 2) However, the desirable opening up of the domain name space is likely to 
>> > introduce more cases where the string may not be considered universally 
>> > objectionable (by whatever criteria or process), but nonetheless would be 
>> > sufficiently "sensitive" in some countries for them to decide to block it. 
>> > This is what the GAC alludes to (in its gTLD principles) when it says that 
>> > TLDs should respect sensitivities regarding terms of national, cultural, 
>> > geographic or religious significance.
>> >
>> > 3) To handle such sensitive cases, there are two extreme approaches : 
>> > either making no limitations whatsoever at the root level and potentially 
>> > reducing significantly the universal accessibility because many countries 
>> > would block many TLDs; or at the other extreme, giving a de facto veto 
>> > right to every individual government on what gets into the root. Both 
>> > approaches seem inappropriate, or at least, unlikely to gather consensus 
>> > in the group.
>> >
>> > 4) In other terms, the expansion of the TLD space means that there will be 
>> > some strings that will be in the root and blocked at the Top Level in some 
>> > countries. This is regrettable but probably unavoidable.
>> >
>> > 5) As we finalize the new gTLD program, I believe there is a legitimate 
>> > common and public interest objective of having/keeping as much universal 
>> > resolvability/availability as possible and as little blocking of whole 
>> > TLDs at the national level as possible. Therefore, we should probably not 
>> > speak of a "principle of universal resolvability" but of an "objective of 
>> > universal availability, with limited exceptions".
>> >
>> > 6) Such national exceptions should, building on the mechanisms of the UDHR 
>> > or the Treaty of Paris (often used as reference to MaPO provisions), be 
>> > made by law and be based upon national norms of morality and public order 
>> > (here MaPO norms are at the national level and this is OK). Moreover, with 
>> > respect to the traditional principle of proportionality, any blocking 
>> > should ideally be conducted at the lowest granular level possible, which 
>> > means that blocking of a whole TLD should remain an extreme and 
>> > exceptional measure.
>> >
>> > 7) Therefore, I believe the challenge we are trying to address is to find 
>> > ways, at the global level, to handle such cases in the most predictable 
>> > and objective manner, so that objections can be formulated, evaluated, and 
>> > ultimately measured with respect to the global public interest (ie : the 
>> > benefits of a new TLD outweigh the inconvenients).
>> >
>> > I hope this clarifies what I tried to convey yesterday.
>> >
>> > Finally, I would like to highlight some very interesting questions that 
>> > came up in the good discussion yesterday evening and could structure part 
>> > of our future interactions :
>> >
>> > - how early in the overall process should MaPO/public interest/sensitivity 
>> > objections be handled ?
>> > - are we talking "string only" or is the applicant also a relevant element 
>> > ?
>> > - would a panel (however it is formed) provide "expert advice" or amount 
>> > to full "outsourcing" (Frank) ? in other terms, how binding would the 
>> > recommendations of such a panel be ?
>> > - does the Board have to make an explicit decision for every TLD (even if 
>> > it's a mere endorsement of the result of the process, like in the IDN 
>> > ccTLD FT) or does the final decision rest with the staff determination or 
>> > the different panels ?
>> > - how much flexibility and direct responsibility would/should the Board 
>> > have in the final decision, in particular in the case of sensitive strings 
>> > ?
>> > - would it be useful to explore a mechanism of supermajority for the Board 
>> > to refuse a TLD and/or to overrule a negative recommendation by the panel 
>> > or objections by some governments ?
>> >
>> > Looking forward to further discussions on the list and conference calls.
>> >
>> > Best
>> >
>> > Bertrand
>> >
>> > --
>> > ____________________
>> > Bertrand de La Chapelle
>> > Délégué Spécial pour la Société de l'Information / Special Envoy for the 
>> > Information Society
>> > Ministère des Affaires Etrangères et Européennes/ French Ministry of 
>> > Foreign and European Affairs
>> > Tel : +33 (0)6 11 88 33 32
>> >
>> > "Le plus beau métier des hommes, c'est d'unir les hommes" Antoine de Saint 
>> > Exupéry
>> > ("there is no greater mission for humans than uniting humans")
>> 
>> 
>> 
>> 
>> -- 
>> ____________________
>> Bertrand de La Chapelle
>> Délégué Spécial pour la Société de l'Information / Special Envoy for the 
>> Information Society
>> Ministère des Affaires Etrangères et Européennes/ French Ministry of Foreign 
>> and European Affairs
>> Tel : +33 (0)6 11 88 33 32
>> 
>> "Le plus beau métier des hommes, c'est d'unir les hommes" Antoine de Saint 
>> Exupéry
>> ("there is no greater mission for humans than uniting humans")
> 



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy