[Gnso-newgtld-wg-wt4] WT4 Call Agenda

[Rubens Kuhl]

> On Jun 8, 2017, at 7:25 AM, Aikman-Scalese, Anne <AAikman at lrrc.com> wrote:
> 
> Technical Advice Needed
>  
> 1.       How to deal with new applications that may present high risk strings in an orderly fashion that does not subject applicants and others to investment of time and money that is wasted. 

Fortunately SSAC had already thought of that in SAC045, and reminded us of it in SAC094. What was clear from the 2012 round is that ICANN simply saying "do your own due diligence" doesn't cut it for this particular topic. We should also note that this discussion is strongly correlated to the predictability discussions we are having in the WG. 


> (This should include advice as to how to coordinate evaluation of special names with IETF.)

This has one more nuance: it's not only IETF, but software development community in general. For instance. while .bit was proposed in IETF special names process for NameCoin, but never got traction there, there is actual software out there that intercepts any request for .bit and makes a NameCoin request instead of a DNS request. As Prof. Lawrence Lessig reminds us, "code is law". 


> 2.       Updated technical advice on DITL as the most valuable measure of name collision issues (as per “off the cuff” advice from JAS recently received.)   Are you saying that we use DITL, but don’t use any apd information?  Or are you saying use apd information, but apply controlled interruption to those names?  If so, does controlled interruption answer the concerns of brands where brand names are purchased during Sunrise and then subject to controlled interruption procedures?

What ICANN Org already mentioned is to not do a per-label proceeding of any kind, and I fully agree with that. So even DITL being a solid data source for research, using it blindly (as happened with APD) leads to suffering. 

> 3.       Updated technical advice on the period of controlled interruption – can and should it be shortened?  (RySG comments mention Interisle and talk about seeking additional technical advice.  RySG notes that Advisors should not have any conflicts of interest.)

I believe the ground rule of this PDP of by default keeping the current policies should be taken into consideration as well. 


> 4.       Technical advice on individual label review.

Isn't that part of the evaluation process ? 

> 5.       Technical advice on the overall restructuring of the current version of the Name Collision Framework to the extent we believe changes should be considered.   (Please note the existing Name Collision Framework  does not contain a process for identifying high risk strings).   The existing Name Collision Framework should be submitted to technical experts along with any recommendations and questions we may have for the purpose of getting expert advice on the best methods for updating the Framework for the next round.

We do have a suggestion from ICANN's CTO to do some outreach on that. Will talk of it later today. 

>  
> Put more bluntly, if we do not obtain more updated expert technical advice on name collision issues and how to handle them going forward, we are the ones “guessing”.

While some knowledge in this area may have evolved, most of it is pretty known for a long time. I believe the single factor that was new in this area was the internal certificates issue, which was dealt with for the 2012-round and is now gone due to new certificate authority practices. 

Note both SSAC and JAS advice are of last month, so they look pretty "fresh" to me. 



Rubens






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20170608/f83485b2/attachment.html>