[Gnso-newgtld-wg-wt4] Fwd: Subsequent procedures PDP

Rubens Kuhl rubensk at nic.br
Fri Jun 2 13:56:30 UTC 2017


HI there. 

Jeff Schmidt from JAS Advisors kindly answered our consultation on name collisions. Here are the questions we sent him and the answers he provided; we'll be discussing them in our next WT4 call, June 8. 


Rubens





> 
> 
>> What general guidance for namespace collisions would you like the community to consider for the next application process, and why ?
> 
> Like other large dynamic namespaces (phone numbers, postal addresses and codes, etc), reassignments/change of control (“collisions” in general) are a fact of life.  They are not limited to newly created namespaces (new TLDs) or even the top level of the DNS – impactful collisions due to reassignment/change of control occur in every namespace for a wide range of reasons – corp.com being the poster child.  In fact, every time an expired name is registered by a new registrant, there is the potential for potentially harmful collisions.  Collisions will never be reduced to zero.  The best the next round can do is to recognize the phenomena, create a “buffer” between legacy and new operators (ala controlled interruption), and create emergency response procedures should something unanticipated occur that reaches a bright danger threshold (danger to human life being the one we suggested and still advocate).  There is precedent for all of this in the phone and postal systems.  
> 
> A CI period for registrations that changed hands rapidly (for example, a “drop caught” expiration) would also be prudent to notify the legacy users that the name is now under new administrative control.  This is how mature namespaces like phone numbers and postal deliveries work.
> 
>> Were there non-applied for strings that would fall into a high risk profile that would be suggested to not be allowed for the time 
>> being in subsequent new gTLD procedures ? Which ones ?
> 
> JAS did not specifically research non-applied-for strings and, aside from the already-reserved “.local” nothing jumped out.  It is possible that another “corp” sort of situation could emerge in future rounds for strange and unknown reasons (it really wasn’t foreseeable that “corp” was such a special string until the specific string was researched).  Subsequent rounds should have mechanisms designed to detect these sorts of unicorns given applied-for strings.  I’m not sure it’s possible to identify the universe of problematic strings in general – rather a list of applied-for strings must be evaluated for risk and prior use.  Personal gut opinion: I’d be particularly vigilant to IDN variants, transliterations, and colloquial linguistic representations of the problematic Latin/English strings we’ve found so far.
> 
>> What data sources could/should be used for analyzing namespace collisions for subsequent procedures ?
> 
> DITL is exceedingly valuable for this purpose and should be consulted in the future.  Non-DITL data from root server operators and large recursive operators (Google, Comcast, etc) would also be helpful.  The corp.com and friends collisions research dataset as announced at the Symposium (ORDINAL) would also be helpful.
> 
>> Based on experience from the 2012 round, can the controlled interruption period be reduced in future procedures, if controlled 
>> interruption is suggested to be used ?
> 
> Philosophically, we need a way to raise awareness and notify legacy users of the new use cases.  This takes time since it depends on a human noticing an anomaly.  Here and now in mid- 2017, I can’t think of anything better than the plan we proposed in 2014 – which included controlled interruption and a set of emergency procedures.  I also think history has shown the suggested approach to be effective – so I’m not sure I’d change anything (approach, timing, length, etc).  It’s become relatively well known and predictable so there is good reason to stick with it. There is broad awareness of controlled interruption (specifically 127.0.53.53) and even some technical messaging baked into browsers like Chrome.  It would be silly *not* to take advantage of this pre-existing knowledge and exposure for future rounds.  Based on personal gut feel only, a CI period of 90 days is on the short end of where I’d feel comfortable – I wouldn’t suggest going any shorter.  The value rapidly diminishes at some point – probably around 120 or 150 days – if the operator hasn’t noticed by then they probably never will, so the sweet spot is somewhere in that range.



More information about the Gnso-newgtld-wg-wt4 mailing list