Thank you Rubens. I like Jeff's shorthand reference to "unicorn" high risk strings in relation to assessment of future applications. Is the text below the entire original e-mail from Jeff Schmidt? Did he provide an estimate for any further work in this arena? Also I know CI means Controlled Interruption, but can you please remind me what DITL is? Thank you, Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com _______________________________ Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com -----Original Message----- From: gnso-newgtld-wg-wt4-bounces@icann.org [mailto:gnso-newgtld-wg-wt4-bounces@icann.org] On Behalf Of Rubens Kuhl Sent: Friday, June 02, 2017 6:56 AM To: gnso-newgtld-wg-wt4@icann.org Subject: [Gnso-newgtld-wg-wt4] Fwd: Subsequent procedures PDP 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.
_______________________________________________ Gnso-newgtld-wg-wt4 mailing list Gnso-newgtld-wg-wt4@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt4 ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.