12:58:11 From Kimberly Carlson to All panelists : Video should work for you now 13:00:50 From Greg Shatan to All panelists : Thank you for sharing. 13:01:22 From Warren Kumari to All panelists : Phew, I'm glad the prior wasn't being recorded... 13:01:50 From Steve Crocker to All panelists : I’m sorry I missed it :) 13:01:57 From Kimberly Carlson to All panelists : Welcome to today’s NCAP Discussion Group Teleconference on 27 May at 13:00 UTC. In the interest of time, there will be no roll call. Apologies received from Matt Thomas and Russ Mundy. As a reminder, all calls are recorded and recordings posted on the public wiki. Please mute your phones and microphones when not speaking to avoid background noise and echoing. This call is governed under ICANN’s Expected Standards of Behavior. https://www.icann.org/resources/pages/expected-standards-2016-06-28-en 13:02:58 From Warren Kumari to All panelists : @Steve: It was just Barry (and everyone else) commenting on how handsome I am, so nothing you haven't heard before.... 13:03:40 From Kimberly Carlson to All panelists : https://docs.google.com/document/d/1Inx_1ndmQOvT3CFpMjhL7JvRcE2iESG1NnCwx-sR6Rs/edit 13:03:44 From Kimberly Carlson to All panelists : Link to the document 13:04:34 From Steve Crocker to All panelists : :) 13:09:20 From Jeff Neuman to All panelists : you can do a google search :) 13:09:24 From Jeff Neuman to All panelists : that was joke 13:11:57 From Rubens Kuhl to All panelists : The public reports are somewhat limited. ICANN-received reports are a bit more interesting, but only ICANN or a contractor could look into them. 13:15:07 From Rubens Kuhl to All panelists : Being anecdotal doesn't bother me, don't worry. 13:18:12 From Rubens Kuhl to All panelists : Resolver data is mentioned in the document, which doesn't suffer from QNAME minimisation and aggressive NSEC caching. 13:19:16 From Rubens Kuhl to All panelists : But convincing resolver operators to share data might be harder than curing COVID-19. 13:19:35 From Warren Kumari to All panelists : S/doesn't suffer/suffers less/ 13:20:36 From Rubens Kuhl to All panelists : Point taken Warren. I've seen some cases of resolver chaining that could cause that. 13:20:42 From Warren Kumari to All panelists : (Lots of public resolvers get forwarded queries, instead of actual client queries) 13:22:30 From Rubens Kuhl to All panelists : I like the criteria used for the root key rollover, but some in the group already mentioned not liking it for this application. 13:24:00 From Rubens Kuhl to All panelists : On removing from the list, a mitigation framework that would cause the string to have the same risk level that would cause it to be delegated. 13:24:40 From Jeff Neuman to All panelists : "capability to cure the issue" 13:27:52 From Rubens Kuhl to All panelists : But, it would be useful for ICANN to run the process with the top-N strings at the root before the application period. 13:29:41 From Rubens Kuhl to All panelists : JAS 13:29:55 From Jeff Schmidt to All panelists : I can answer that 13:31:10 From Justine Chew : Sorry, I have to drop off now for another call. 13:32:38 From Rubens Kuhl to All panelists : mail also had mostly dotless mail queries, different from home/corp. 13:33:34 From Jaap Akkerhuis to All panelists : Dritz Boxes ae not phased out 13:33:42 From Jaap Akkerhuis to All panelists : SD/F 13:34:17 From Warren Kumari to All panelists : @Jaap: Indeed. There are also many more appearing / increasing. 13:34:31 From Warren Kumari to All panelists : Link, totolink, consul,etc... 13:34:42 From Rubens Kuhl to All panelists : DLink is a classic, still showing. 13:34:53 From Rubens Kuhl to All panelists : Consul and OpenStack are newcomers. 13:34:58 From Warren Kumari to All panelists : Yup. 13:35:14 From Jeff Neuman to All panelists : And then it becomes a value assessment...do we reward current unsanctioned use 13:35:25 From Warren Kumari to All panelists : And this shows (to me) that the current advice isn't being heard. 13:35:32 From Jeff Neuman to All panelists : or do we ignore 13:35:35 From Warren Kumari to All panelists : Consul is a new application. 13:36:43 From Danny McPherson to All panelists : A good reason why longitudinal collection of root data is valuable 13:36:54 From Warren Kumari to All panelists : @Danny: Indeed. 13:37:33 From Jeff Schmidt to All panelists : I feel a different duty to protect someone making up a new tld in 2020 13:37:39 From Jeff Schmidt to All panelists : than historic uses 13:37:59 From Jeff Schmidt to All panelists : ie Consel vs corp 13:38:07 From Rod Rasmussen to All panelists : @Jeff S. - was there any query threshold you had to determine which strings to examine further? In other words, what fell into the “random noise” bucket vs. something you’d spend time researching based on where it came in the long tail. 13:38:21 From Rod Rasmussen to All panelists : Or - what is “N” for Top-N”? 13:38:57 From Brantly Millegan to All panelists : I’ve had my hand up for a while. Am I not doing something I’d need to do in order to be called on? 13:39:16 From Danny McPherson to All panelists : Just sent PDF to email list that illustrates .MAIL and changes over time… 13:39:23 From Suzanne Woolf to All panelists : +1 to Jeff/Danny….important to have data that’s (relatively) independent of any incentive to game it. 13:39:48 From Rubens Kuhl to All panelists : Rod, I would go with top-20 with pre-assessed strings, but any string could be a collision one so it would just filter out cases we know need more attention. 13:40:34 From Jeff Schmidt to All panelists : @rod we looked pretty deep numerically but focused on patterns not a hard numeric cutoff. I’d have to go look at our report. 13:41:31 From Jeff Schmidt to All panelists : @rod we started with the assumption that a low numeric frequency could be “very” bad. so we didn’t want to short circuit. 13:42:29 From Rod Rasmussen to All panelists : @Jeff S - that makes sense, but with millions of potential candidates in the long tail, there is some practical cut-off. It 13:42:40 From Jeff Neuman to All panelists : Right....so "ease of mitigation" should be criteria when identifying a collision string 13:43:05 From Rubens Kuhl to All panelists : Rod, the number of applied for strings will be the limit for the analysis process since it's case by case. 13:44:11 From Rod Rasmussen to All panelists : Whoops - hit enter instead of apostrophe! Meant to finish - “It’s a bit of art and science, but there is some practical limit on what you can dig into. Perhaps examining semantic meaning of the potential collision string makes some sense too?” 13:44:25 From Danny McPherson to All panelists : ++mthomas 13:44:57 From Jeff Neuman to All panelists : @Rod, I agree with Rubens, that unless there are real Unicorns out there, it will be a case by case analysis and that would be limited to the amount of applications 13:45:49 From Jeff Schmidt to All panelists : yes. one of the more interesting things we did in our report was fit regular expressions to the Amanda 13:45:56 From Jeff Schmidt to All panelists : qnames 13:46:18 From Jeff Schmidt to All panelists : to observe the sorts of patterns Warren refers to. ++ 13:46:57 From Rod Rasmussen to All panelists : @Ruben - the applicant strings are certainly ones that would have to be examined, but being able to tell folks ahead of time if their particular string is already problematic (i.e. studies prior to new applications) would clearly be helpful for people not wasting money or at least understanding there is a risk to a particular application. 13:48:11 From Warren Kumari to All panelists : ML FTW! 13:48:13 From Jeff Neuman to All panelists : @Warren - sounds like a great holiday for you :) 13:48:29 From Rubens Kuhl to All panelists : @Rod, I agree, but for this preemptive analysis, I would cut at the 20 top-N queries at the root. 13:48:53 From Warren Kumari to All panelists : It turns out to be a text book classification problem. 13:50:04 From Steve Crocker to All panelists : How can we see these visual regular expressions? Can you give the pointer to the report? 13:50:24 From Danny McPherson to All panelists : To Jeff’s point, same applies to the Interisle report, and the ACM / IEEE papers we’ve cited.. 13:50:54 From Warren Kumari to All panelists : @Steve: https://www.icann.org/en/system/files/files/name-collision-mitigation-final-28oct15-en.pdf (I think) 13:52:30 From Danny McPherson to All panelists : Yep, we can spit out any spatial / other classification analysis near real-time now from the data we have from A & J root…. Just need the candidate string 13:53:39 From Suzanne Woolf to All panelists : It may also be possible to get data from other root servers, and this data can vary quite strikingly across RSO clouds. 13:54:35 From Rubens Kuhl to All panelists : The most distributed root server nowadays is ICANN's own L, so that data would likely work well. 13:55:04 From Steve Crocker to All panelists : Please send this chat to all of us so we can refer to the mentioned documents. Thanks. 13:55:46 From Kimberly Carlson to All panelists : Hi Steve, I will post the chat on the wiki. https://community.icann.org/x/U4bsBw 13:55:48 From Warren Kumari to All panelists : L - 165 sites F - 252 sites 13:56:32 From Steve Crocker to All panelists : @kimberly Thanks. 13:56:44 From Suzanne Woolf to All panelists : @warren footprints vary in interesting ways as well 13:56:48 From Suzanne Woolf to All panelists : “More data better" 13:56:56 From Warren Kumari to All panelists : Also, all of F's are IPv6, only a subset of Ls are v6. 13:57:09 From Warren Kumari to All panelists : @Suz: Yup, fully agree... 13:57:40 From Warren Kumari to All panelists : #sites != reach, visibility, etc. 13:58:23 From Kimberly Carlson to All panelists : Thank you all, bye 13:58:23 From Warren Kumari to All panelists : But,... 13:58:25 From Jaap Akkerhuis : bye all 13:58:27 From Danny McPherson to All panelists : thx 13:58:32 From Brantly Millegan to All panelists : Thanks!