[CCWG-ACCT] Resolution of Mission Language related to regulation and contract

George Sadowsky george.sadowsky at gmail.com
Wed Nov 25 01:48:09 UTC 2015


Malcolm,

Thanks for a concise, well-articulated set of responses to my questions.  It's exactly what I was hoping to receive.

Regards,

George


> On Nov 24, 2015, at 7:43 PM, Malcolm Hutty <malcolm at linx.net> wrote:
> 
> 
> 
>> On 24 Nov 2015, at 17:29, George Sadowsky <george.sadowsky at gmail.com> wrote:
>> 
>> Andrew,
>> 
>> I'm sympathetic to your arguments, but they have implications.  Here are some questions:
> 
> George,
> 
> As one of the people who has been particularly vocal about the need for the clause that gave rise to this thread, I am taking the liberty of cluttering your inbox with my own answers, to illustrate that for me at least this clause isn't intended to provoke these issues
> 
> 
>> 1. Can ICANN Inc. make policies regarding which strings they will delegate?  What are the degrees of freedom under which they can make them?
> 
> Yes. Essentially unlimited discretion as to content of the policy for the the decisions it takes; its bylaws will limit/specify process for the adoption and application of that policy (and does so in a way that merges this with Question 2). I suppose it's possible that certain core values might limit this discretion in certain outlier cases (I'm thinking of the proscription on discriminatory behaviour), but this should be marginal. In any case, the clause that gave rise to this thread isn't implicated in this question at all. 
> 
>> 2. Can the "ICANN community" make policies regarding which strings they will delegate?  What are the degrees of freedom under which they can make them?
> 
> See previous question. Under the bylaws, the elements of the ICANN community have various prescribed roles in the development of the policy in question. 
> 
>> 3. Milton might argue that there should be complete freedom to propose any string you'd like, and it should be accepted.  Do you agree with that?  (Does Milton?)
> 
> If Milton does take that position, I would disagree with him (but my suspicion is that your expectation of this view is misplaced). ICANN has unlimited discretion to adopt policies that limit the strings that it will delegate, but it must follow the process set out for adopting such policies. 
> 
>> 4. Under what conditions, if any, should the semantic content of a natural language string be grounds for refusal to consider it as a new gTLD, in any future nGTLD round?
> 
> Any grounds set out in properly adopted consensus policy applicable to that decision.
> 
>> 5. The problem is that these strings are read by both computers and by people, and are processed very differently, with very different reactions.  Are we to ignore that?
> 
> I'm not sure what you mean, but in any case it is within the legitimate scope of applicable consensus policy to take note of, or ignore, this or any other factor. 
> 
>> These are questions that will come up and will be important in the future.  Do you think that there is unanimity regarding the answers?  It doesn't matter what you or I believe if there is no unanimity, because these questions will recur and the resulting policies may not be what we or others might want.
> 
> I believe that the bylaws the CCWG is proposing would lead an independent and unbiased observer with suitable expertise in applying bylaws language to determine that those bylaws objectively required the answers I have given above. 
> 
> I would also contend that that, rather than perfect unanimity, is the relevant test. 
> 
> Malcolm. 
> 
>> 
>> George
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Nov 24, 2015, at 5:11 PM, Andrew Sullivan <ajs at anvilwalrusden.com> wrote:
>>> 
>>> On Tue, Nov 24, 2015 at 04:39:56PM -0500, George Sadowsky wrote:
>>>> So let's probe this a bit.
>>>> 
>>>> Does that mean that future guidebooks can't disallow any future strings from consideration, unlike round 1?  I think you'll find a lot of people who would disagree that
>>>> 
>>>>   .horribly_insulting_string
>>> 
>>> This is the reason I included the "use in natual language" bit.  The
>>> reason that string is "horribly insulting" is because of the
>>> linguistic context, not the DNS.  The DNS doesn't carry the meaning,
>>> but there's nothing wrong with ICANN making policies about strings it
>>> will delegate.  It does that all the time.  It also has a policy, for
>>> instance, that it won't delegate ASCII strings outside the LDH range,
>>> and that strings that have "-" in the second and third positions MUST
>>> be A-labels, and so on.  ICANN also won't delegate underscore labels,
>>> at least not yet.  None of these restrictions come from the DNS
>>> either.
>>> 
>>>> Much as I'd like to treat domain names as arbitrary strings that
>>>> have no meaning for the computers that parse them, they do have
>>>> semantic content, sometimes very strong and offensive semantic
>>>> content, and they will evoke strong reactions
>>> 
>>> I think you're conflating "how things get used in natural languages"
>>> and "how things get used globally".  There's a whole literature (much
>>> of it full of urban legends) about brands that didn't translate well
>>> across cultural borders because of supposed meaning in the new
>>> language.  (My favourite urban legend one is the Chevy Nova, which
>>> supposedly meant "doesn't go" in Spanish.  From what I saw of my
>>> neighbour's car, that's what it meant in English too.)
>>> 
>>> ICANN is no more in the business of deciding what strings are
>>> offensive than it is in the business of deciding what's a country.
>>> Instead, it can appeal to other sources for decisions -- ISO or
>>> community consensus or whatever -- for that reasoning, and merely
>>> needs to be interested in how domain names (especially at or near the
>>> root) are used by people.  That _certainly_ includes thinking about
>>> their natural languages (and then appealing to those other sources for
>>> decisions).
>>> 
>>>> BTW, if they didn't have semantic content, they really would be
>>>> useless to us, wouldn't they?  If that were the case, we might as
>>>> well go back to using numbers instead.  POTS, anyone?
>>> 
>>> About 40% of the people I interact with over the Internet realise that
>>> "anvilwalrusden" is an anagram of "andrewsullivan".  Does
>>> "anvilwalrusden" have semantic content?  Well, it does to me (and
>>> probably to all of you now, too -- quick, don't think of a pink
>>> elephant!), but I'll wager a pretty good lunch that it has negligible
>>> semantic content to anyone I've never met in (say) West Vancouver, to
>>> say nothing of South Korea.  Canadians always know exactly what I mean
>>> when I give them my email address, <ajs at crankycanuck.ca>; USians can't
>>> even pronounce it unless they live near the border.  And lots of
>>> labels in the DNS have at best ambiguous semantics anyway -- this is
>>> why certain country codes are able to sell expensive domain names to
>>> television celebrities or those wanting a domain name that looks like
>>> an adverb in English.  And what is the meaning of ns1?  How about
>>> _dkim?  In Korean?  In Urdu?  ICANN gets into very deep water when it
>>> starts trying to be a meaning-maker.  I don't think you want that.
>>> 
>>>> I think we had better get this right at the beginning rather than
>>>> having it bedevil us in future new gTLD rounds.
>>> 
>>> If we don't talk about "meaning" and instead talk about the way
>>> people use them, we'll be just fine.
>>> 
>>> Best regards,
>>> 
>>> A
>>> 
>>> -- 
>>> Andrew Sullivan
>>> ajs at anvilwalrusden.com
>> 
>> _______________________________________________
>> Accountability-Cross-Community mailing list
>> Accountability-Cross-Community at icann.org
>> https://mm.icann.org/mailman/listinfo/accountability-cross-community



More information about the Accountability-Cross-Community mailing list