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

Fri Jun 2 21:28:28 UTC 2017

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 at 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 at icann.org [mailto:gnso-newgtld-wg-wt4-bounces at icann.org] On Behalf Of Rubens Kuhl
Sent: Friday, June 02, 2017 6:56 AM
To: gnso-newgtld-wg-wt4 at 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 at 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.