- Gnso-newgtld-wg-wt4 - lists.icann.org

WT4 Call Agenda
by Rubens Kuhl June 7, 2017

June 7, 2017

Dear WT4 members, The next call for the New gTLD Subsequent Procedures Sub Team – Track 4 - IDNs/Technical & Operations will take place for 60 minutes on Thursday, 8 June 2017 at 20:00 UTC, 22:00 Brussels, 21:00 London, 13:00 Los Angeles, 16:00 Washington DC; Friday, 9 May 2017 04:00 Singapore, 06:00 Sydney, 05:00 Tokyo. For other times: http://migre.me/wKRQg <http://migre.me/wKRQg> The proposed agenda is as follows: 1. Welcome 2. SOIs 3. Recap of WT4-related discussions during May events in Madrid 4. New gTLDs Name Collisions Framework 5. Input received through CC2, and from JAS and OCTO messages 6. AOB Adobe Connect room: https://participate.icann.org/newgtldsubteams/ <https://participate.icann.org/newgtldsubteams/> You can connect your audio by following instructions in the pop up in the AC room, or use the Connect Me option that is sent in the calendar invitation. Best, CLO & Rubens

1 0

Fwd: Subsequent procedures PDP
by Rubens Kuhl June 3, 2017

June 3, 2017

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.

2 6

Revised Reading List for Topics Under Discussion on 25 May/Meeting with SSAC Chair
by Julie Hedlund May 31, 2017

May 31, 2017

Dear Sub Team Members, Please see the attached revised reading list to include the latest SSAC Publication: SAC095: SSAC Comment on the CCWG-Accountability-WS2 Draft Framework of Interpretation for Human Rights (30 May 2017) at: https://www.icann.org/en/system/files/files/sac-096-en.pdf. Bets regards, Julie Julie Hedlund, Policy Director From: <gnso-newgtld-wg-wt4-bounces(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Thursday, May 11, 2017 at 6:17 PM To: "gnso-newgtld-wg-wt4(a)icann.org" <gnso-newgtld-wg-wt4(a)icann.org> Subject: [Gnso-newgtld-wg-wt4] Reading List for Topics Under Discussion on 25 May/Meeting with SSAC Chair Dear Sub Team Members, Please see the attached reading list of publications from the Security and Stability Advisory Committee (SSAC) and the Internet Engineering Task Force (IETF) to provide context for the discussion for the Work Track 4 meeting on 25 May. The Sub Team Chairs have invited Patrik Fältström, the SSAC Chair, to give a presentation, answer questions, and join in a discussion with the Sub Team during that meeting. The topic areas are: Internationalized Domain Names (IDNs), name collisions, conflicting TLD allocations, and root zone scaling. The reading list also has been uploaded to the meeting wiki at: https://community.icann.org/display/NGSPP/2017-05-25+New+gTLD+Subsequent+Pr…. Best regards, Julie Julie Hedlund, Policy Director

1 0

Recording, AC recording, AC Chat & Attendance from New gTLD Subsequent Procedures Sub Team Track 4 IDNs/Technical & Operations call on Thursday, 25 May 2017 15:00 UTC
by Terri Agnew May 25, 2017

May 25, 2017

Dear All, Please find the attendance and recording of the call attached to this email. The Adobe Connect recording and AC Chat are below for the New gTLD Subsequent Procedures Sub Team – Track 4 – IDNs/Technical & Operations held on Thursday, 25 May 2017 at 15:00 UTC. Adobe Connect recording: <https://participate.icann.org/p6inqxs1wgj/?OWASP_CSRFTOKEN=1d0b66cd3929354d…> https://participate.icann.org/p6inqxs1wgj/ The recordings of the calls are posted on the GNSO Master Calendar page: http://gnso.icann.org/en/group-activities/calendar ** Please let me know if your name has been left off the list ** Mailing list archives: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4> http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4 Agenda Wiki page: https://community.icann.org/x/KdTRAw Thank you. Kind regards, Terri ------------------------------- Adobe Connect chat transcript for 25 May 2017 Terri Agnew:Welcome to the The call for the New gTLD Subsequent Procedures Sub Team – Track 4 – IDNs/Technical & Operations on Thursday, 25 May 2017 at 15:00 UTC for 60 minutes. Terri Agnew:agenda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… <https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_…> &d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=QwTuQlm0jgowtzfTbWlT05Zo65nhmIajCNh4xKJxQ10&s=7MIqZ-8OjtawU3pIyFP5hd6NUF91yQjFGLitK96UnmY&e= Julie Hedlund:@Patrik: You are a presenter and can move the slides. Cheryl Langdon-Orr (CLO):yes we appreciate the aggregation of points with SAC094 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. 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. Steve Chan:@Rubens, I will check with the staff support for that PDP 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. Julie Hedlund:@All: The Emoji document will be published today. Staff will send the link to this list when published. Cheryl Langdon-Orr (CLO):thanks Julie Rubens Kuhl:I think the Emoji fans response is just :-( Cheryl Langdon-Orr (CLO)::-) Rubens Kuhl:Full-disclosure:, co-chair hat off I don't think Emoji should be used in domain names. 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 & .gno be subjected to the RFC 6761 process avri doria:i meant .gnu not .gno 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" Julie Hedlund:@Did we lose Patrik? Rubens Kuhl:Patrik, we can't hear you. Rubens Kuhl:Now we can. Patrik Fältström, SSAC Chair:Yes, you can always ask me for clarifications. You can and should also send more specific questions to SSAC when you have them, and do not wait until you have a formal report done. Patrik Fältström, SSAC Chair:Then I am leaving the call. Thanks! Nathaniel Edwards:Thank you, Patrik Dietmar Lenden - Valideus:thank you Patrick Terri Agnew:New gTLD Subsequent Procedures Sub Team – Track 4 – IDNs/Technical & Operations will take place on Thursday, 08 June 2017 at 20:00 UTC for 60 minutes. Julie Hedlund:@Cheryl: We'll add SAC095 on Emoji to the reading list and SAC094 on CC2. Rubens Kuhl:Not from me. Rubens Kuhl:Bye all, thanks for coming! avri doria:bye Julie Hedlund:@Cheryl -- That also is addressed in the SSAC's response to CC2.

1 0

Actions/Discussion Notes: Work Track 4 Sub Team Meeting 25 May
by Julie Hedlund May 25, 2017

May 25, 2017

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.

1 0

Topic Intersection: Work Tracks 1 & 4
by Emily Barabas May 22, 2017

May 22, 2017

Dear Work Track 4 members, A recent discussion in Work Track 1 touched on topics within the scope of Work Track 4. At the request of the Sub Team co-leads, I am sharing the recording and notes from the discussion for your reference: https://community.icann.org/display/NGSPP/2017-05-16+New+gTLD+Subsequent+Pr…. The Work Track 1 discussion on 16 May focused on the topic of a potential program for registry service provider certification/accreditation. There are two parts to this discussion: · the process for such a program (within the scope of WT1) · standards for evaluation and testing (within the scope of WT4) Since the two discussions inform one another, it is helpful for members of the two Work Tracks to remain informed about conversations underway throughout the PDP. Kind regards, Emily Emily Barabas | Policy Specialist ICANN | Internet Corporation for Assigned Names and Numbers Email: emily.barabas(a)icann.org | Phone: +31 (0)6 84507976

2 1

Fwd: [council] Fyi INVITATION: IETF Overview and Special-Use Domain Names Problem Statement Last Call Webex - Tuesday May 23, at 1700-1830 UTC
by Rubens Kuhl May 17, 2017

May 17, 2017

> Begin forwarded message: > > From: Nathalie Peregrine <nathalie.peregrine(a)icann.org> > Subject: [council] Fyi INVITATION: IETF Overview and Special-Use Domain Names Problem Statement Last Call Webex - Tuesday May 23, at 1700-1830 UTC > Date: May 17, 2017 at 9:54:25 AM GMT-3 > To: "council(a)gnso.icann.org" <council(a)gnso.icann.org> > Cc: "gnso-secs(a)icann.org" <gnso-secs(a)icann.org> > > *Forwarding on behalf of the IETF* > > > INVITATION FROM THE IETF TO THE ICANN COMMUNITY > > This session is intended to help the ICANN community understand the IETF process and productively participate in the discussion of a document on Special Use Names that may be of interest. > > The DNSOP Working Group within the IETF has recently completed work on > a problem statement document on Special-Use Domain Names > (draft-ietf-dnsop-sutld-ps-03 - > https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/[datatracker.iet… <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_d…> ). The > IETF will soon be initiating their final comment period for the document – the > IETF Last Call. The IETF would like to invite the ICANN community to share their input > on the document. > > This session will start with an overview of the IETF last call process and how it works. > It will then have a short summary of the SUTLD document, and describe > how to provide comments. > > It would be helpful for participants to have read "The Tao of IETF: A > Novice's Guide to the Internet Engineering Task Force" > (https://www.ietf.org/tao.html[ietf.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_tao.html&…> ) > > This session will be held via WebEx on Tuesday, May 23, at 1700 -1830 UTC. Webex participation details are included below. > > Meeting Link: https://ietf.webex.com/ietf/j.php?MTID=m1333532ce167e4a5a09b1d42d002b632[ie… <https://urldefense.proofpoint.com/v2/url?u=https-3A__ietf.webex.com_ietf_j.…> (going to this link in advance of the meeting will allow you to generate a calendar invitation) > > Join by phone: > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > > Meeting number: 310 638 156 > Meeting password: LastCall > > > > _______________________________________________ > Gnso-secs mailing list > Gnso-secs(a)icann.org <mailto:Gnso-secs@icann.org> > https://mm.icann.org/mailman/listinfo/gnso-secs____________________________… <https://mm.icann.org/mailman/listinfo/gnso-secs____________________________…> > council mailing list > council(a)gnso.icann.org <mailto:council@gnso.icann.org> > https://mm.icann.org/mailman/listinfo/council <https://mm.icann.org/mailman/listinfo/council>

1 0

Reading List for Topics Under Discussion on 25 May/Meeting with SSAC Chair
by Julie Hedlund May 15, 2017

May 15, 2017

Dear Sub Team Members, Please see the attached reading list of publications from the Security and Stability Advisory Committee (SSAC) and the Internet Engineering Task Force (IETF) to provide context for the discussion for the Work Track 4 meeting on 25 May. The Sub Team Chairs have invited Patrik Fältström, the SSAC Chair, to give a presentation, answer questions, and join in a discussion with the Sub Team during that meeting. The topic areas are: Internationalized Domain Names (IDNs), name collisions, conflicting TLD allocations, and root zone scaling. The reading list also has been uploaded to the meeting wiki at: https://community.icann.org/display/NGSPP/2017-05-25+New+gTLD+Subsequent+Pr…. Best regards, Julie Julie Hedlund, Policy Director

2 1

Re: [Gnso-newgtld-wg-wt4] Work Track 4 agenda for 4 May 2017
by Aikman-Scalese, Anne May 15, 2017

May 15, 2017

Thanks Rubens. Not sure I get the logic of this in relation to applicants asking the Board to change the policy set up in the Framework. Bears further discussion I think. https://www.icann.org/en/system/files/files/name-collision-framework-30jul1… (See Paragraph 5) In connection with the next call (or rather the one after that given that Patrik will be presenting in our next call), I really think our WT needs to focus on the existing Name Collision Occurrence Framework paragraph by paragraph. The Framework was not developed within a GNSO policy process, but it IS the existing policy until it is replaced by something. Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman(a)lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image003.png@01D2C8F8.D84E9940] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: Rubens Kuhl [mailto:rubensk@nic.br] Sent: Tuesday, May 09, 2017 2:37 PM To: Aikman-Scalese, Anne Cc: Jeff Neuman; gnso-newgtld-wg-wt4(a)icann.org; Cheryl Langdon-Orr (langdonorr(a)gmail.com) Subject: Re: [Gnso-newgtld-wg-wt4] Work Track 4 agenda for 4 May 2017 On May 9, 2017, at 9:44 PM, Aikman-Scalese, Anne <AAikman(a)lrrc.com<mailto:AAikman@lrrc.com>> wrote: Thanks Rubens. I do not think that these specific TLD strings have to be specifically mentioned in our Charter. They simply fall under the category of name collisions, clearly within scope. As you point out, it is not because something became an issue in the first round that it falls outside our remit. The topic should have been mentioned, not the specific strings. Like "Closed Generics" were mentioned applying to the 2012-round, even though not mentioning specific strings. This is what we have in the charter: "Name collisions: How should name collisions be incorporated into future new gTLD rounds? What measures may be needed to manage risks for 2012-round gTLDs beyond their 2 year anniversary of delegation, or gTLDs delegated prior to the 2012 round?" So, for 2012-round gTLDs, we can only look at measures for delegated gTLDs. At least with the charter as it is now. Don’t we say it’s the GNSO that makes policy, not the Board? You said that as to new applications for very risky names, “That's one of the policy questions I mentioned.” It makes no sense to me that cases of very risky name collision strings going forward are within the scope of Sub Pro but that very risky name collision issues identified with .home, .corp, and .mail are dealt with directly by the Board. Shouldn’t the same consistent policy (developed according to a Multi-Stakeholder bottom-up process with ample opportunity for public comment) apply to very risk name collision strings regardless of application date? The next procedures might have very different application rules, depending on the outcome of this PDP; those applications were made with the 2012 rules, and unless for topics specifically punted for this PDP (like closed generics), they are the ones in force, not what we discuss here. Same applies for other contentious issues like community applications, where some 2012 applications are still pending but will be judged against the 2012 criteria. Why would the Board be in charge of name collision mitigation policy for very risky names in connection with 2012 round applications, while Sub Pro and GNSO are in charge of name collision mitigation policy for very risky names not yet applied for? Actually, the Board acted within what was specified in the 2007 GNSO Policy for such issues. Principle D: "A set of technical criteria must be used for assessing a new gTLD registry applicant to minimise the risk of harming the operational stability, security and global interoperability of the Internet." Recommendation 4: "Strings must not cause any technical instability." We might have disagreements with the implementation, specially since it at least contradicted principle A (predictability), but we didn't have in 2012 the implementation oversight mechanisms that are mandated since September 2015, output of a work that started exactly due to implementation issues seen in the 2012-round. Rubens ________________________________ 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.

2 1

Small sample of possible collisions
by Rubens Kuhl May 13, 2017

May 13, 2017

For those curious on what possible strings could have more collisions (quantity-wise), the L-root servers (the group of root servers operated by ICANN, and by far the most globally distributed of the root servers), I generated a 2-week snapshot at stat.dns.icann.org <http://stat.dns.icann.org/> ; a cached copy of the snapshot is available at http://stats.dns.icann.org/plotcache/L-Root/qtype_vs_othertld/2017-05-01T00… <http://stats.dns.icann.org/plotcache/L-Root/qtype_vs_othertld/2017-05-01T00…> , but the list of most queried not delegated TLDs in that snapshot are (in most to least queried order): . home local zghjccbob3n0 dhcp lan ip localdomain z gateway localhost belkin dlink gw== internal invalid corp workgroup homestation dlinkrouter 012 davolink domain null blinkap no-use-now intra loc netis 217 router iptime 1 cpe totolink pk5001z html telus 176 pvt The two patterns in the string are strings suggestive of internal networks (like .corp, .lan and .intra) and strings suggestive of router devices (router vendor names), and some could be both (.home, .gateway). Rubens

1 0