Dear Sub Team Members, Please see below the action items and discussion notes captured by staff from the meeting on 09 February. 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. Best regards, Julie Julie Hedlund, Policy Director Action Items/Discussion Notes 09 February 1. Full WG Update: -- Call for volunteers for three drafting teams: - Volunteer on the link to the sign-up sheet: https://docs.google.com/document/d/1g-OoBec_Q6nnBofBvcTnfAotFh7yq07HUM7kxh62... 1) Different TLD Types -- see: https://community.icann.org/x/Nz2AAw    2) Predictability/Community Engagement -- see: https://community.icann.org/x/Nz2AAw and https://community.icann.org/x/IT2AAw 3) Applications Assessed in Rounds – see: https://community.icann.org/x/Jz2AAw 2. IDN Program Update (see slides from Sarmad Hussain: IDN Program Update – WT4.pdf) Overview of Projects (slide 2) -- IDNs at Top Level: IDN TLD Program: Label Generation Rules, LGR Toolset, IDN Variant TLD implementation, etc. IDN TLD Program (slide 3) -- Phase 1 -- Case Studies -- Phase 2 -- Integrated Issues Report -- Phase 3 -- Projects: P1, P2.1, P6 -- Phase 4 -- Projects: P1, P2.2, P7 Root Zone LGR Procedure (slide 4) -- One Generation Panel per script or writing system -- Generation Panel flows into Integration Panel -- Integration Panel flows into rules Status of Root Zone LGR (slide 5) -- work in progress Status of Generation Panels (slide 6) -- 28+ scripts; 19+ GPs LGR Specification and Toolset (beta) (slide 7) -- Online beta deployment at: https://lgrtool.icann.org/ -- Open source license IDN Variant TLD Implementation (slide 8) -- applications indicate variant TLDs -- 25 September 2010 -- no variants of gTLDs delegated until appropriate variant managements solutions developed -- Integrated Issues Report (2012) -- Solutions: Root zone LGR procedure to define valid labels and variants; determine variant management mechanism. IDN Country Code Top-Level Domains (slide 9) IDN ccTLD Fast Track Process (slide 10) -- Currently under review: issues with EPSRP -- ccNSO reviewed; finalized recommendations and under consideration by the Board. IDN Implementation Guidelines (slide 11) -- Guidelines for IDN registration policies and practices at the second level to address end-user concerns (minimize confusion) -- Contractually binding for registrars and registries -- Recommended for IDN ccTLDs -- GNSO requested updating the guidelines (current is 2011) -- Update is in progress. IDN Guidelines WG Members (slide 12) Summary of Items Covered by the Guidelines (slide 13) -- Detailed text of the recommendations at IDNGWG Wiki: https://community.icann.org/display/IDN/IDN+implementation+Guidelines. Reference Second Level LGRs (slides 14 & 15) -- Project to develop reference language tables -- Public comments: process for development and maintenance; guidelines for LGR Development; reference second level LGRs published Junee 2016. -- LGRs being developed and published since Oct 2016. Discussion: Q: Why are emoji TLDs not allowed ? A: The code points we can support are from IDNA2008 -- we can't do it independently.  Would have to be taken up at the IETF platform.

From the chat room:

Jeff Neuman: Q: Who is doing the work on whether and how vairiants can be used at the top level?  Should this group be working on this, or is another group? A: What was suggested was that there has to be some technical solutions that need to be evaluated.  An internal exercise is to find out what are the issues and what would be possible solutions.  Bring solutions back to the community and get guidance.  Maybe in the next couple of months. -- Until those come out the prohibition from 2010 should still apply -- right? Yes.  Might look to this group as to how the solutions should be adopted into the policy, or what is relevant. Q: Would a TLD pass PDT today if it did not follow the reference LGRs?  What did .se (IIS) use to pass TLD applicants through PDT?  A: We are separately publishing reference IDN tables for the second level for the root zone LGR.  A TLD can use those and if it does it will pass the test, but that does not mean it must follow them and can propose its own solutions, but then security and stability testing would be needed. -- We should probably consider putting that guidance into an AGB. Q: In 2012, registries were prohibited from applying for single-character IDNs at the top level. Do you see any reasons, policy or technical, why we should or should not continue this ban on a going forward basis? A: There is an SSAC advisory that explains why single character IDNs present a risk and suggesting that they should not be allowed.  See: https://www.icann.org/en/system/files/files/sac-052-en.pdf. We could go back to the SSAC to see if that is a discussion to go back to them. -- Single characters in these languages so now is a really good time to engage in that work to see if there are any technical issues with single-character IDNs. -- That is noted. avri doria: But SSAC is just advice and their conclusions might need verification and discussion. Rubens Kuhl: The SSAC makes two recommendations:1. Given the potential for user confusion and the currently unfinished work on string similarity and IDN variants, the SSAC recommends a very conservative approach o the delegation of single-character IDN top-level domains. In particular, ICANN should disallow by default the delegation of all single-character IDN TLDs in all scripts; exceptions are possible, but only after careful consideration of each individual case.2. Because important relevant work on string similarity, IDN variant issues, and TLD label syntax is currently underway within ICANN, the Internet Engineering Task Force (IETF), and other bodies, ICANN should review the Findings of this report, and any policies that it adopts in response to recommendations made in this document, no later than one year after the three work items mentioned above have been completed. Rubens Kuhl: Citing this advice is a circular reference: it just said that AT THAT TIME the work was not ready. Kurt Pritz: Some single-character IDNs are very similar to single-character ASCII: for example, è.  The community found no way to parse between Latin-character IDNS and Pictographs (if that is the right term) such as Chinese.  But it seems we could white-list scripts where single characters are allowed. Cheryl Langdon-Orr (CLO): well worth considering @Kurt Jeff Neuman: should probably add SSAC to last bullet Cheryl Langdon-Orr (CLO): indeed @Jeff. all the more reason to coordinate with them in my view. Jeff Neuman: I think the Board would never contradict SSAC advice, so going it alone is not a viable option. Kurt Pritz: I would change the third bullet to creating a white list based upon being a ideograph and that a committee has passed on them somehow.  (CLO -- Agree to include.) Jeff Neuman: @CLO, i agree that coordination with the SSAC should start ASAP on this.  Even if it is a letter from us that states that we are considering whether the ban on single character IDN TLDs should be lifted.  It has been seven years since SSAC 52, and we request that the SSAC re-evaluate the notion of allowing single-character IDNs at the top-level. IDNs: Consensus Call on 1-character IDN TLDs (slide 7 from SubPro WT4_9Feb2017.pdf) Possible language: "IDN 1-char gLTDs won't be disallowed for script/language combinations where a character is an ideograph (or ideogram), provided they are not country and/or territory names." Discussion: -- Coordination with ccNSO and GAC consultations [add SSAC?] might be advisable. If and if so, when to start them? -- Ask the plenary for an early start on this matter so it can go in parallel. -- Comments on one-character IDN TLD why it may cause security issue: One of the arguments presented is that the chances of confusability increases if it is a shorter string.  Second is that calling out ideographs -- normally they are script based, not language based, so there could be an argument that if they don't have a meaning if a particular script allowed why is another character of another script not allowed (question limit to ideographs). -- If you have a longer string you have a context, but if you have a single character there is no context. -- From a staff perspective we would agree that reaching out to the SSAC is a priority, but I am not sure we have agreed that there is a need for a single character, to perhaps update their existing advice.  Staff will consider a proposal on how to reach out to the SSAC and present that the the WT.

From the Chat:

avri doria: i would argue against that, in a longer string the bogus character can hide better. Kurt Pritz: Right, which are more confusing: a vs e; or  dictionary vs dictionery. Jeff Neuman: Good example Kurt. Kurt Pritz: I agree with Sarmad (if I understood the point correctly) on defining what is an ideograph and that leading to confusion. Jeff Neuman: Just because things may be more likely to be confusing does not mean we should disallow it completely Cheryl Langdon-Orr (CLO): True Jeff IDNs: Consensus Call on Variant TLDs (slide 8) Possible Language: "IDN gTLDs deemed to be variants of already existing or applied for TLDs won't be disallowed provided: (1) they have the same registry operator implementing, by force of agreement, technical bundling (as defined in RSEP 2014012) among the members of the TLD set; (2) top-level LGRs and second-level LGRs already established for the script/language at evaluation time." Discussion: -- I thought Sarmad said they are studing this and until that is done this might be premature.  Need guidance on when that study is done. -- In this case if we have arguments based on consensus I see no harm in making them.  I am not sure we need to necessarily postpone a first cut, if the group is ready. -- Part of the work we (ICANN) have been doing -- currently the solutions .china ccTLD for example, We have actually seen that there is more than one solution technically.

From the Chat:

Jeff Neuman: Could we add something to the end that makes this recommendation pending any findings by the SSAC that the delegation of variant TLDs do not cause issues of security or stability, and do any of those 3 implementations cause technical problems? avri doria: it may be sufficient that there are set of possible solution to enable the policy discussion. we do not necessarily have to require a specific solution.