[Gnso-newgtld-wg-wt4] Actions/Discussion Notes: Work Track 4 Sub Team Meeting 08 June

Thu Jun 8 21:37:52 UTC 2017

Dear Sub Team Members,

Please see below the action items and discussion notes captured by staff from the meeting on 08 June.  These high-level notes are designed to help Work Track Sub Team members navigate through the content of the call and are not meant to be a substitute for the recording.  Please also see the recording on the meetings page at: https://community.icann.org/display/NGSPP/Work+Track+4+Meetings. 

Note also that the referenced slides for today’s meeting are attached and excerpts from the chat room are included below.

Best regards,

Julie

Julie Hedlund, Policy Director

Action Items/Discussion Notes 08 June

1. Full Working Group Update

-- Our next meeting is Monday, 12 June at 20:00 UTC.  We are going to go over our plans for ICANN59 in Johannesburg including the Geo Names sessions.  

-- We will talk about the notion of first come, first serve, versions rounds, versus predictable application windows.

-- ICANN staff has taken the comments from CC2 and sorted them into documents corresponding to the work tracks and they will send that out.

2. Recap of WT4-related discussions during May events in Madrid 

Slide 6: 

--GDD Summit 09-11 May 2017

-- Listed on the slides are some sessions relating to Work Track 4.

-- DNS primer could be useful to understand the inner working of the DNS and how collisions happen.

-- ICANN DNS Symposium, 13 May -- three technical presentations: Garbage Traffic at the Root, Introduction to the OCTO Research Middlebox Lab, New Datasets Available for Colliding Domains -- most related to the Work Track 4 topics.  Given by Jeff Schmidt from JAS Advisors.

-- DNS OARC 26, 14-15 May: OARC Engineering Report, -- mention how the Day in the Life (DITL) machine is being updated; Dark Side of the DNS -- found instances of queries that were not real namecoin queries; attempt to disguise queries as namecoin.

-- SLA misses or near-misses: presentation about the SLA misses almost triggering an EBERO.  One of the possible linkages to Work Track 4 was presented by Donna Austin -- where could we have asked questions and additional testing that could have presented these misses from happening.  This is a question to GDD and we might take this into Work Track 4.  See:  https://www.icann.org/en/system/files/files/presentation-slam-13may17-en.pdf.  In scope for Work Track 4.  Some may have even gotten to the EBERO level, although ICANN had the discretion not to initiate EBERO.

3. Community Input on Name Collisions

Slides 9: Input received on name collisions: 

JAS Advisors:

-- Don't change the winning team

-- Look into SLD collisions (notifications)

-- Consider variations of 2012 problematic strings

-- Use DITL and ORDINAL datasets

SSAC -- Advice from previous advisories, but that still are applicable

-- Create a "do not apply" list -- SAC045

-- Create an "exercise care" list

-- Consider what to do with previously delegated TLDs

-- Identify private namespaces

-- Coordinate with IETF on special-use domain names (IETF also, problem statement last call).

Discussion:

-- No all agreements have a 2-year waiting period.  Perhaps that is something this group could look at.   There are parallels.

Slide 10: Input received on name collisions:

INTA: Avoid APD-type lists; if used, cannot contain trademarks

RySG and gTLD Registries:

-- Lack of predictability

-- No need to extend 2-year, 2-hour readiness

-- Reduce controlled-interruption period to 60 days

-- Assess risk instead of just quantity

Thomsen Trampedach: Initiate controlled interruption period sooner rather than later

OCTO: Read out to DNS-OARC, IETF DNSOP, RIPE DNS-WG, TEG

Slide 13: Name Collisions Framework For Subsequent Procedures (Aggregate Proposal 1/2) -- reading from the slide

Slide 14: Name Collisions Framework For Subsequent Procedures (Aggregate Proposal 2/2) -- reading from the slide

Discussion:

-- Before the final names collisions framework came out a suggestion was made that ICANN.org could even contact providers before delegation -- is that a question we could submit to ICANN?  ICANN refused to do that but didn't say why.  Regardless of what the name collision period is when someone enters into a contract ICANN could "delegate" those strings.  One response was that there weren't sure the collision would happen until the string was delegated.  They could argue that this is not foreseen in the application including in the costs.

-- Don't agree that this group should proceed without contracting for expert advice.  Maybe some feel confident based on their understanding of the technology to make policy decisions, but others would not be able to analyze the advice that has been provided.  Raise the procedural question again: developing questions for expert advice, seeking funds, and addressing these questions.

-- There is a lot of cooperation in Internet engineering without contracting for expert advice.  Much of the information is shared via relationships -- such as Requests for Comments.  That is how we got here.  We can hire advice if needed, but we should assume that because we haven't hired someone then we can't know that.  We have JAS Advice, SSAC advice, that we already have.

-- Strongly encourage that everyone read the JAS Advisor's final report.  That is expert advice.  They reviewed how everything went from the last round.  If we want to develop certain recommendations -- such as shortening the 90-period -- then perhaps we could run that by an expert group, but we need to take into consideration the advice that is already provided.

-- The strings in the 2012 round that have been reserved have been applied for and won't be eligible to be applied for new gTLDs.  There is a concern that what we do here would apply retroactively to those high-risk strings, although we can make it clear that it doesn't.  Don't start the issue from scratch but look at what has happend.

>From the Chat:

Jeff Neuman: In the brand TLDs (Spec 13), there is a required 2 year waiting period.  Perhaps applying that general rule to all.  Identifying private namespaces is very difficult because they are by their nature "private".  An example of one such network was .gprs and .grx operated by the GSM Assocation (again a reference to a previous telephone world).  That is a private ENUM-related service

Anne Aikman-Scalese (IPC): Does anyone know whether this ICANN report has ever been updated since 2014?  https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf

Donna Austin, Neustar: The RySG provided comments on Name Collision on the CC2 and more recently there was a discussion prior to sending the RySG letter to the PDP WG. The wording agreed for the latter was: we believe there should be a formal review of the duration of the controlled interruption period, which was the key mitigation measure used for gTLDs in the 2012 round.  It is unclear whether a 90 day period is necessary in order to identify and mitigate collisions.  Such a review should include an analysis of TLDs that did require mitigation

Cheryl Langdon-Orr (CLO): also to note from previous At-Large open-and-shut consequently ALAC Advice is strong support for the often conservative approach taken in SSAC Advice,  noting also ALAC and SSAC meet at most ICANN Meetings to discuss such Advise and therefore probably hold great comfort and understanding of views and rationale 

Sarah L:  I think there are a number of things that we should remember before we start thinking about reducing the length of the name collision period…… First of all, ICANN received at least 37 formal reports of name collisions, and from what I remember there were more that may not have been formally reported… a number of academics published illustrations of where controlled interruption as designed was not effective in dealing with a large and unpredictable number of attack scenarios and let’s not forget that  recommended actions such as an IPv6 solution for controlled interruption have still not at all been acted upon.  Bearing all of that in mind, it seems apt that we would establish a new and informed position on this topic and not just…. dismiss the security implications of name collisions in lieu of expediency again.  

Cheryl Langdon-Orr (CLO): try again...  personally I agree Sarah 

Jeff Neuman: @Anne - SSAC 45 is here:  https://www.icann.org/en/system/files/files/sac-045-en.pdf.  A reasonable reading of that hardly screams anything other than registries should be educated on the potential risks.,,,,,

Anne Aikman-Scalese (IPC): Agree with Sarah

Anne Aikman-Scalese (IPC): @Jeff - SSAC 062 dated November 12, 2013. and asopted by the Board March 27, 2014.  We need to keep in mind the existing Board resolutions on this topic.

Nathaniel Edwards: Also agree with Sarah. Much of the collision conjecture is conclusory and could prove deeply regrettable if adopted as policy without significantly more information/data.

Jeff Neuman: @Anne - my response was to your comment (and the SSAC's comment) that has we listened to the SSAC in 2010 we may not have waited so much time

Jeff Neuman: The JAS Final report was expert advice

avri doria: problen with expert advice is that sometimes you need more than one.  JAS as a lot to defend in the way the last round went off.  I do not think we can accept that as the only advice.

Anne Aikman-Scalese (IPC): @Jeff -  Are you saying our policy development will be relying on the JAS Final Report from the 2012 round?

Anne Aikman-Scalese (IPC): @Avri - it doesn't have to be from JAS.  My point is that if it is not formal advice that is paid for, it is not the same in terms of independent objective verification.

Anne Aikman-Scalese (IPC): @Jeff.  But we are suggesting changes to the JAS final report.

Anne Aikman-Scalese (IPC): IN addition, the JAS final report does not deal with how you vet new strings for the high-risk assessment?

Anne Aikman-Scalese (IPC): @ Jeff - Why would you want to include a statement that policy adopted here should not be evaluated in relation to recent requests from applicants for the Board to resolve name collision issues in relation to .home, .corp, .mail?  Why wouldn't they?

Jeff Neuman: @Anne - you are making an assumption that there are future high risk strings.  That may be the case....or may not be.  Perhaps that is a question

Rubens Kuhl: .ltd, .ltda also corporate identifiers, but .corp has an additional issue as Microsoft suggested using .corp... and that doesn't translate to other languages. 

Anne Aikman-Scalese (IPC): @Jeff - Current advice from JAS and SSAC says we do need to consider there could be other high risk-string.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20170608/ed19a0c5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SubPro WT4 Meeting #12.pdf
Type: application/pdf
Size: 571277 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20170608/ed19a0c5/SubProWT4Meeting12-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4630 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20170608/ed19a0c5/smime-0001.p7s>