[NCAP-Discuss] Additional comments on the comments to the Scarfone Draft

[Jeff Schmidt]

Ok, reviewing the comments to the document I'll call out a few elephants in the room:


(1) To those that continually point to collisions reports to ICANN as insufficient data, recall that formal reports to ICANN are only a small part of the "reporting" that has occurred over the past 6 years.  ICANN rolled out 1,200 of these things globally and undertook a global marketing/awareness campaign.  Sure, only a handful of formal reports made it to ICANN, but that's a small part of the story.  To discard 6 years of relevant global operational experience adding a large number of labels to the root is simply incredulous.  As is discarding the comments online in technical fora.  Consider, what would have happened if there were serious problems? Do you think we *wouldn't* know about them by now? In these circles?  There would be lots of noise.  There would be letters and lawsuits in this litigious ICANN environment.  There would be papers and presentations.  The absence of really any interest in collisions at all - and certainly the absence of this sort of affirmative evidence - affirmative evidence that *would exist if there were problems* - is certainly instructive and must not be discarded.  Think of it like bacteria in a petri dish; if the culture grows it is affirmative evidence of the bacteria.  If the culture doesn't grow, it is affirmative evidence of no bacteria.  I don't hear my doctor say: "I don't really know if you have strep throat because... absence of evidence is not evidence of absence... we need more tests and more data! Commission more studies!"

Every time I read "absence of evidence is not evidence of absence" I will remind folks not to commit the equally subtle and dangerous "appeal to ignorance" fallacy.  It must be true if it cannot be proven false.  

(2) Some continually advocate a self-serving definition of "collisions" so narrow and artificial (and disparate from SSAC definitions) that it is impossible for them to occur anywhere other than newly delegated (g and cc) labels.

SAC62 defines collisions thusly:
"In the context of top level domains, the term "name collision" refers to the situation in
which a name that is properly defined in the global Domain Name System (DNS)
namespace (defined in the root zone as published by the root management partners -
ICANN, U.S. Dept. of Commerce National Telecommunication Information
Administration (NTIA), and VeriSign) may appear in a privately defined namespace (in
which it is also syntactically valid), where users, software, or other functions in that
domain may misinterpret it."

SAC66 liberalized slightly more:
"The term "name collision" refers to the situation where a name that is defined and used in
one namespace may also appear in another. Users and applications intending to use a
name in one namespace may actually use it in a different one, and unexpected behavior
may result where the intended use of the name is not the same in both namespaces."

Collisions as defined by either SSAC definition can occur in existing g and cc space.   Despite the efforts and wishes of some, collisions are a DNS problem, not a new gTLD problem.  The SSAC definitions, correctly, focus on the "misinterpretation" and "unexpected behavior" aspects - the potentially harmful aspects not arcane technicalities.


(3) One of the firms that routinely questions the efficacy of Controlled Interruption has apparently *patented* a competing approach.  Controlled Interruption is unpatented, widely deployed, and free for everyone to use; the commercial terms of use of the *patented* competing approach are unknown.

Jeff