Dear Sub Team Members, Please see below the action items and discussion notes captured by staff from the meeting on 25 May. 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, and links to referenced documents, are included below. Best regards, Julie Julie Hedlund, Policy Director Action Items/Discussion Notes 25 May 1. Presentation from Patrik Fältström, SSAC Chair re: Name Collisions and IDNs SAC094: SSAC Response to the New gTLD Subsequent Procedures PDP Working Community Comment 2 (22 May 2017) – See: https://www.icann.org/en/system/files/files/sac-094-en.pdf Slide 2: -- The latest document is SAC094, which talks about the New gTLD Subsequent Procedures Community Comment 2. -- Revisited past advisories and curated advice relevant to many of the Working Group's questions. -- We are working with the ICANN Board on a tracker to track the recommendations that we have given. -- Tracking which have been taken into account, status, and whether/how implemented. -- Either the Board implemented, or may decide to do something else. SAC090: SSAC Advisory on the Stability of the Domain Namespace (22 December 2016) – See: https://www.icann.org/en/system/files/files/sac-090-en.pdf Slide 4: Stability of the Domain Namespace -- Discussing for a very long time. -- Set of all possible domain names that can be assembled from a tree-structured hierarchy of individual labels. -- Also used in environments that are intended to be separate from the global public DNS. Competing domain names must be taken into account. -- Really difficult to have a rigid scope in practice. Slide 5: Names External to ICANN Universe -- "Special-Use" Names (.onion, .local, etc.) -- "Private Use" Names (.mail, .home, etc.) -- Other Names (.bit, .gnu, etc) -- How to measure this private use? -- SSAC members participate in the IETF work, such as Suzanne Woolf and Warren Kumari, who are very active. We have got good cross-facilitation between the SSAC and the IETF. Slide 6: SAC090 Findings -- Uncoordinated use of the domain namespace in different environments can lead to ambiguity when those environments overlap and their names collide. -- Need for coordination among the activities: ICANN, IETF, others. -- .home, .mail, .corp used long before ICANN existed TLDs existed. No intent originally. .home, .mail, and .corp were not on a reserved list for the previous round. -- Don't have any protocol police. Slide 7: SAC090 Recommendations -- Board take steps to establish definitive and unambiguous criteria whether or not a label could be a TLD. -- There is a need for names to be used locally. -- Board establish effective collaboration with relevant groups, including IETF. -- Complete this work before adding new TLD names. -- Biggest task is to coordinate between ICANN and the IETF. -- SSAC has not said who should be deciding, just that the overlap is unfortunate. -- Come up with a predictable policy and evaluation criteria. -- Re: TMCH there have been lots of discussion with TMCH people, but there are multiple other issues.
From the chat:
Rubens Kuhl: While IETF only takes personal input, not organisational input, it would be useful if SSAC members raise their concerns in the upcoming Last-Call of the problem statement of TLD coordination between ICANN and IETF. avri doria: to some people, like myself personally,another word for "private use" is squatting Rubens Kuhl: Question: would you currently recommend .bit and .gnu not to be offered in new gTLD subsequent procedures ? Or are they squatters ? Nathaniel Edwards: Squatting implies some intent. That is not the case for .mail, .home and.corp. Used for a very, very long time. avri doria: i think of squatting as something to be discouraged for the future and instance that exist need mitigation (mostly not a SubPro issue) . Nathaniel Edwards: What would be the motivation for many thousands of private persons/entities to "squat" on "private use" names with the goal of creating a name collision risk to stop delegation of a TLD? Rubens Kuhl: If policy staff could forward this SSAC comment on TMCH to the RPM Review PDP WG, it would be interesting... unless it's already been taken into account. Steve Chan: @Rubens, I will check with the staff support for that PDP Nathaniel Edwards: I apologize, Patrik, that question was directed at Avri. avri doria: Nathaniel, i personally beleive that if people know they can just grab and use and that there will be no effort to unwind or mitigate such unauthorized use, there will be more. avri doria: Nathaniel, I beleive we have educate the world on what not to do and why and how to work around it. avri doria: Nathaniel, and we have to figure out how to mitigate the case where it has happened or may happen in the future. avri doria: But those are jus personal views, not co-chair views. Internationalized Domain Names Slide 9: Internationalized domain names -- Principles of Label Inclusion from SAC084: SSAC Comments on Guidelines for the Extended Process Similarity Review Panel for the IDN ccTLD Fast Track Process (31 August 2016) – See: https://www.icann.org/en/system/files/files/sac-084-en.pdf -- Very much context sensitive -- Definition of unicode creates large problems Overarching principles: Conservative principle and Inclusion Principle -- Be conservative -- only add things when you have decided they are okay. Slide 10: Principles of Label Inclusion Cont. -- Stability Principle: List of permitted labels in the root zone should change at a rate that does not negatively impact the stability of the root of the DNS. -- Reflected in ICANN IDN guidelines. Slide 11: Additional Points from SAC088 -- Confusability is a Security Concern -- Harmonization needed for Confusability between ccTLDs and gTLDs. -- Phishing and other social engineering attacks based on domain name confusion are a security problem for end users. -- Clear and consistent set of rules for 'confusing similarity' should be developed and the resulting rules should be applied to both ccTLDs and gTLDs. Slide 12: Collisions due to False Positives (see chart) -- Unfortunate to not see a push for use of IDNA2008. Good if more people strictly used it. Slide 13: Emoji in Domain Names -- Emojis are not allowed in IDN2008. -- Some ccTLDs to register domains with emojis, violating IDN2008. -- Recommends ICANN Board reject any TLD that includes emoji. -- Strongly discourages the registration of any domain name that includes emoji in any label. -- Advises registrants of domain names with emoji that they may not function consistenly or be universally acceptable.
From the chat:
Rubens Kuhl: Full-disclosure:, co-chair hat off I don't think Emoji should be used in domain names. Questions: Question: would you currently recommend .bit and .gnu not to be offered in new gTLD subsequent procedures ? Or are they squatters? -- SSAC doesn’t make statements on specific strings unless there is a specific reason. We have pointed out how much various labels are in use. .bit and .gnu are floating around in the IETF. It is very important that ICANN take into account that there are these various proposals. The IAB for .homenet proposal if someone really wants something that might leak it should be on .arba, so .homenet.arpa. Don't know if .bit and .gnu should be in .arba, or be TLDs, or should be block, but the SSAC won't make conclusions. Has ICANN taken any action in response to Rec 7 of SSAC 66: "ICANN should in due course publish information about not yet disclosed issues [regarding name collision risks]"? -- ICANN had published some more information in the final report. Some information could not be published (sensitive). -- SSAC suggested that when you want a TLD that is to be allocated in the root zone -- statistics could be collected regarding lookups and use so one could draw conclusions. But ICANN was concerned for privacy reasons so it chose a different path. ICANN do believe that ICANN could gather and publish more data, but might require changes in registrar agreements. Should .gnu and .bit be subjected to the RFC 6761 process? -- Don't know whether they can. For .bit they are using the DNS protocol a little more than .onion do. Might could be use more than locally, just like .home. That is a question for IETF. -- .home, .mail, and .corp there was an Internet draft. Got the impression for ICANN to follow the SSAC advice it would require a review of every code point -- do you agree? -- Yes and no. We do have the label generation panels that for every script they look at the code points in IDN2008 and the confusability and the subset of characters that can be used in DNS -- safe to use. That is the right path foward. Lots of this work is already done. Would personally like to see recognition of the LGR work. When improvements are done that could be re-used in other places, such as the cc process. -- ICANN could re-use the building blocks that already exist for IDN. .onion has a commercial use with tor as opposed to .local - could this be a point of differential which does not qualify .onion "special use"? -- Already ruled as special use.
From the chat:
Rubens Kuhl: Slide 6 or 7: Question: would you currently recommend .bit and .gnu not to be offered in new gTLD subsequent procedures ? Or are they squatters ? Nathaniel Edwards: Patrik, has ICANN taken any action in response to Rec 7 of SSAC 66: "ICANN should in due course publish information about not yet disclosed issues [regarding name collision risks]"? avri doria: can .bit & .gnu be subjected to the RFC 6761 process avri doria: SSAc also suggested at one point that registries be warned if they were applying for a known collision risk at the time of applications Rubens Kuhl: I remember an expired I-D (Internet Draft) for .bit. Quoc Pham: .onion has a commercial use with tor as opposed to .local - could this be a point of differential which does not qualify .onion "special use" 2. Next Steps for WTs and PDP WG Update: Full WG Update: -- Last meeting -- Took one of the 3 pending issues where there is a drafting team and went into detail on the base document that was produced by staff. -- Talking about categories -- looking at how that is both an application issue and a contract issue. -- Looking at attributes -- Moved into a discussion of whether we were doing rounds, or first come first served. -- Plan: Take the other two issues in the full WG meetings -- flexibility and community engagement, and the one on rounds or first come first served. -- We need to make specific decisions on whether we are recommending changes to the current policy. Sub Team Work: -- Came up with the CC2 comments and that period has closed (22 May) -- Staff are compiling comments. -- Look at those comments, resolve what can be resolved, if we notice hard issues put them to the full WG and continuing discussion. -- Make a pass through all the issues doing the comment review analysis. -- Third pass will be to look at each of the issues and ask: "Do we have a consensus for recommending a change and do we have a consensus on what that change might be?" -- Document intractable issues and send them to the full WG. -- Each work track will have a report on what they came to on each issue. -- Gather into the full group to produce initial recommendations to go out for review. -- May come back to a work track sub team in case they need to dig in a bit more. -- Initial recommendations will go out for public comment.