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

[Danny McPherson]

On 2020-05-06 14:38, Jeff Schmidt via NCAP-Discuss wrote:
> 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.

Jeff, you're the one that made noise about corp.com which largely occurs 
because of .CORP and you submitted a paper just last week saying there 
should be more outreach.  You can't have it both ways.


> 
> (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.

I don't need to repeat what I said previously beyond but if it's within 
the same namespace and nothing is colliding then it's not a collision.  
Because some people what to expand the scope to talk about registration 
of expanded domains is little more than deflection and outside of the 
scope of THIS work by the very definition that created it.
> (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.


I'd just like to see an actual analysis of controlled interruption and 
the efficacy, no one has done that but it's inherently reactive and not 
a "test" of riskiness.  ANY collision after the CI period (which there 
were a multitude) would suggest it's insufficient and as previously 
conveyed ignores all the serious attacks anyway -- its was the most 
expeditious solution you stated that's "the lowest risk and least cost 
[paraphrased]" - which doesn't mean best, but that's a matter of 
perspective and I know you don't want to hear that so I'm not going to 
repeat it any more.

As for the IP derived from peer-reviewed work (unlike CI) that is 
actually proactive and would provide the 'test" that Jeff and I agree 
should exist proactively before strings can be applied for rather than 
blindly letting stuff break when a delegation occurs., So yes, we stated 
the existence of the techniques and IP here multiple time and while we 
haven't said anything about licensing IF / when it's granted but I'd 
suspect _very favorable terms could be obtained.


-danny