October 2019 - gnso-council-IDN-scoping

FW: Invitation to attend: IDN ccTLD policy review & next steps @ICANN66
by Steve Chan Oct. 30, 2019

Oct. 30, 2019

Hello All, You may be interested in the ccNSO’s session that will be talking about ccPDP 4, on IDN ccTLD policy. Please find the relevant information below. Best, Steve From: Kimberly Carlson <kimberly.carlson(a)icann.org> Date: Tuesday, October 29, 2019 at 6:47 AM To: "ccnso-members(a)icann.org" <ccnso-members(a)icann.org>, "ccTLDcommunity(a)cctld-managers.org" <ccTLDcommunity(a)cctld-managers.org> Cc: "ccnso-council(a)icann.org" <ccnso-council(a)icann.org>, Steve Chan <steve.chan(a)icann.org> Subject: Invitation to attend: IDN ccTLD policy review & next steps @ICANN66 Dear all, The ccNSO Council intends to launch the fourth ccNSO PDP to build the work of the second ccNSO PDP2, and the experience of the IDN ccTLD Fast Track Process. The fourth ccNSO PDP will address issues identified by the ccNSO IDN PDP2 Preliminary Review Team (PRT), which includes among others review of the confusing similarity review procedures and management and selection of IDN Variant (cc)TLDs. Purpose of this session is to inform and discuss with those who are interested in participating in developing IDN ccTLD policy work the next steps of IDN ccPDP 4 and preliminary timeline. All interested are welcome and encouraged to attend. Meeting details: IDN ccTLD policy review & next steps – Thursday, November 7th | 1030-1200 (block 2) | Rm 514a Remote participation: - https://icann.zoom.us/my/yul66.514a Thank you and safe travels to those attending in person. Best, Kim

1 0

Actions & Notes: GNSO IDN Scoping Team Meeting 24 October 3:00 UTC
by Ariel Liang Oct. 25, 2019

Oct. 25, 2019

Dear All, Please find below the action items and notes captured during the IDN Scoping Team call on Thursday, 24 October at 3:00-4:00 UTC. Staff has posted to the wiki space the action items and notes. Please note that these are high-level notes and are not meant as a substitute for the recording and chat room records, which are posted on the wiki at: https://community.icann.org/x/mYAzBw Best Regards, Ariel == Action Item - Edmon to reach out to Co-Chairs of SubPro PDP and ask whether they are willing to take on the IDN policy related work. - Edmon to propose draft language for recommending an EPDP as the potential mechanism to carry out the IDN policy work and publish the proposed language on the scoping team mailing list for feedback. - Staff to identify the part of the staff papers for IDN variant TLD management that can fit in an Issue Report. - Staff to organize scoping team meetings after ICANN66. NOTES - Are we comfortable to launch an EPDP? Or need to launch a regular PDP with the Issue Report? Consider whether a separate Issue Report needs to be prepared. - Maxim suggested that interested GNSO members with trademark expertise should join the scoping team too. - One option would be to ask SubPro PDP WG to take on IDN policy work, but treat it as a separate track so this doesn't cause delays in SubPro. SubPro is about future TLDs, so not an ideal place to look at IDN related work? SubPro has three work items related to current TLDs: (1) closed generics (2) collision readiness (3) collisions in 2LDs. - Two distinct areas the scoping team is discussing: 1) IDN implementation guidelines (second-level registrations) – not really consensus policy at this point, 2) top level variants – there are consensus policy being put forward, in addition to the original 2012 recommendations. For handling policy related to top level domains, a PDP is needed. - If punt the IDN policy work to SubPro, would only delay SubPro’s report on current TLDs, not future TLDs. Split SubPro final report into two to prevent delay of the report on future TLDs.  - Staff went through the problem Definition Outline section in the options paper. - For IDN guidelines, form a group of impacted parties to review the actual implementation of the guidelines. Certain elements of IDN guidelines should become policy, but they will be wrapped into the IDN variant TLD recommendations. - Policy development is required, even just to codify the recommendations in the staff papers. Nevertheless, future policy work is not beholden by those staff recommendations. - Ask the Co-Chairs of SubPro whether they want to take on this body of work? The IDN topic has a potentially wider scope (e.g., including impact to string requirements, EBERO, Registry Agreement, etc.) than what SubPro might be able to consider. - What does the Issue Report cover? Issue report is to understand and scope the problem at the very high level, and confirm it is within the scope for the GNSO to consider. Provide background, analysis, and data regarding the problem. This part is not so different from the staff paper already produced for the IDN variant TLD management. - https://gnso.icann.org/en/council/pdp-guide-v1 The issue report should: describe an issue but NOT explore options; provide directly relevant background and links; recommend whether to proceed or not; propose terms of reference for a Council WG; be provided to Council within the 15 day time frame laid out in the by-laws. - What is precisely is in the staff papers for the IDN variant TLD management? When those papers were developed, ICANN Org went step by step through the processes of applicant guidebook and ccTLD fast track process, and tried to identify all the relevant issues. - The objective of the policy work is to develop a solution to delegate the IDN variant TLDs. Each recommendation in the staff papers has called out a series of questions, which are candidates for the “charter questions” of the future (E)PDP. - Check page 8 of the recommendations/analysis section of the staff papers. Do they qualify as the appropriate content of an Issue Report? - No need to follow the exact template of the Issue Report when confirming the content in the staff papers. - If we recommend an EPDP, need to include some qualification so people don’t immediately jump into the wrong conclusion about the time constraints, etc. - Plan to make the call to solicit additional members for the scoping team during the Council meeting, but no formal process is needed. - ACTION ITEM: Edmon to reach out to Co-Chairs of SubPro PDP and ask whether they are willing to take on the IDN policy related work. - ACTION ITEM: Staff to identify the part of the staff papers for IDN variant TLD management that can fit in an Issue Report. - ACTION ITEM: Edmon to propose draft language for recommending an EPDP as the potential mechanism to carry out the IDN policy work and publish the proposed language on the scoping team mailing list for feedback. - ACTION ITEM: Staff to organize scoping team meetings after ICANN66.

1 0

Post call | IDN Scoping Team call | Thursday 24 October 2019 at 03:00 UTC
by Andrea Glandon Oct. 24, 2019

Oct. 24, 2019

Dear all, All recordings for the IDN Scoping Team call held on Thursday, 24 October 2019 at 03:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/mYAzBw> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-council-idn-scoping/> and the main wiki page<https://community.icann.org/x/b4HkBg>. Thank you. Kind regards, Andrea

1 0

Slides for the Council Meeting
by Ariel Liang Oct. 24, 2019

Oct. 24, 2019

Hello all, Following the scoping team call that just ended, staff are circulating the slides which will be used during the scoping team presentation in the Council meeting (12:00-14:00 UTC on Thursday, 24 October) as a FYI. Best, Ariel

1 0

Proposed Agenda
by Steve Chan Oct. 23, 2019

Oct. 23, 2019

Dear All, Apologies for not sending out a proposed agenda earlier. Please see below, which is a continuation from the previous meeting: Welcome and roll call Continued: identifying problems/issues with IDN variant TLD recommendations. What other policies/processes may be impacted (especially from the same-entity requirements)? GNSO Council for the 24 October GNSO Council Meeting – Confirmation on slides AOB Best, Steve From: gnso-council-IDN-scoping <gnso-council-idn-scoping-bounces(a)icann.org> on behalf of Ariel Liang via gnso-council-IDN-scoping <gnso-council-idn-scoping(a)icann.org> Reply-To: Ariel Liang <ariel.liang(a)icann.org> Date: Friday, October 11, 2019 at 2:31 PM To: "gnso-council-idn-scoping(a)icann.org" <gnso-council-idn-scoping(a)icann.org> Subject: [GNSO-Council-IDN-Scoping] Actions & Notes: GNSO IDN Scoping Team Meeting 10 October 13:00 UTC Dear All, Please find below the action items and notes captured during the IDN Scoping Team call on Thursday, 10 October at 13:00-14:00 UTC. Staff has posted to the wiki space the action items and notes. Please note that these are high-level notes and are not meant as a substitute for the recording and chat room records, which are posted on the wiki at: https://community.icann.org/x/sZECBw Best Regards, Ariel == Action Item - Staff to organize a scoping team call on Oct 24 at 3:00 UTC Notes 1. Welcome and roll call 2. What have we tentatively agreed to so far? Review of the summary captured in the Options document (see page 8) Question about whether a PDP is needed - A PDP is needed to adopt the recommendations. - Does the disagreement from the staff paper require additional policy work, or it is something that can be resolved internally? This particular group should not look at the substance of the recommendations. Our main job is to decide whether we have enough stuff to deliberate in a PDP. What we should recommend as the next steps? - If we are proposing a PDP to cover various aspects, it is surely for the PDP to work on this. It is not up to the scoping team to solve all the issues. Question about whether additional research/analysis is needed - Is there additional research and analysis needed? Do we have enough body of information that can be moved into policy work by a group? - If we don’t go down the path of strawman proposal, it would be hard to say what technical impact it would has. - Develop a strawman and see whether standards need to be put into place before a policy is finalized. This work does not seem as straightforward. Because the policy has technical and operational implications, we need to come up with a report, park it there, get the technical issues ironed out before we come back and finalize the policy report. - In the translation and transliteration PDP, there was a strawman of all possibilities as to how T/T may work. All the possible solutions are very detailed and clear, with technical input and pros/cons for each solution. It sounds like an approach that can be applied in IDN variant TLD management policy development. - Going down the path of a PDP, we need extra work done in order to understand the technical and operational impact before we can finalize the policy recommendations. - If we want to defer the technical analysis to an IRT, we can also do that too. If it is not within the knowledge of the group to do the technical analysis, we can leverage other staff like technical staff in GDD, or even consultant. - Park the PDP till some additional research is done to finalize the policy to be recommended. Question about whether an Issue Report is needed - Do we feel the work needs to be done in the preparation of the issue report before the GNSO can take on the subject, or deal with the analysis during the PDP? - This scoping team is trying to determine if the staff reports serve as adequate proxies for an issue report.  - The question about whether an issue report is needed helps guide the scoping team’s thought on the options for policy mechanism. - Option A: Leveraging existing PDPs is not the correct approach. - Option B: Create a stand-alone PDP or EPDP. The issue is well represented / understood in the staff document. A likely recommendation is to create an EPDP. - The work already done provides a reasonable set of documents, which can be used to start the PDP and get a sense what the policy might look like. - The scoping team is somewhat undecided about an EPDP or PDP. Maxim feels that some issues need additional work before the policy WG can consider the matter. Some other people feel the set of documents are sufficient and can launch the policy work right away. Take all the staff documents as the starting point of deliberations and add a few more items if needed. - The scoping team is hung up on the EPDP or PDP question. If we go the EPDP route, are we leaving something unaddressed? If we go the PDP route, but acknowledge that there is already existing work that can expedite the first step of the PDP, it wouldn’t be so bad? If we have a full PDP, we just say we have the report from staff and the issue report can be completed by leveraging existing work. - Does the future PDP have the ability to go against the recommendations? The PDP/EPDP would not need be beholden to the recommendations in the staff report. It could come up with different recommendations. Question about what a policy WG would look like - Understand what type of people need to be included in the PDP working group. Stress the importance of expertise in the field. We need to do technical analysis in the course of the PDP itself and need people with the knowledge / expertise. - Instead of restricting membership, we should at least get some members from registrars and some members who understand legal issues. Form a PDP WG with the people of needed expertise. Not a lot of new information needs to be collected. - Support the recommendation to move away from an open WG model, and encourage people with subject matter expertise to join. - If we are talking about trademark issues in this PDP, make sure to invite members from IPC, NCSG, etc. 3. Continued: identifying problems/issues with IDN variant TLD recommendations - Disagree with the report’s assertion that IDN tables could be more easily managed if IDN tables are represented in machine readable format, thus asking to consider the implementation of RFC7940 (LGR in XML format). RFC7940 is a format (like CSV, TXT) to represent something, in this case a label generation ruleset or IDN table. Registries have working implementations that do not necessarily are on XML. RFC7940 could be used to build a new registration system, but it is unpractical to think that registries will retrofit their existing systems with it. - The harmonization of the IDN tables by implementing RFC7940 is going too far. Those not familiar with RFC7940 would have a hard time to implement. We are not going to retrofit how the implementation works. If we are going to represent LGRs in machine readable format, it is one thing. To manage the IDN tables via implementing RFC7940 is another. - The intention for the IDN table recommendation is not to change the internal implementation. The intention is to publish the IDN tables and provide more precise definition. The intention is more output facing, but not for implementation internally. For registries what they publish is what they use internally too, so there is an implication for implementation. - Viability of implementing the “same entity” at the second level. The recommendation touches the surface as to how the “same entity” can be implemented at the second level and the subsequent changes needed to support other operations, like transfer and update operations, availability and RDDS queries. This area needs more research and analysis to find a solution that is widely supported by registries and registrars. - Same entity requirement in the second level is more complicated. Registry contact ID is required. Reality is that some registrars tend to not to reuse the registry contact ID registered by the same registrant. If registries potentially cannot get information from the registrars, they cannot validate who the registrants are. This impacts the transfer. Registries need to know who the losing registrant and winning registrant are, and how many domain names are involved in this transaction. These days, a transfer pertains to a single domain. So when variants are introduced, they are intended to travel as a group. - Policy implementation related to the transfer puts burden on registrars and confuse registrants. - One analogy is the RDAP profile. Registries, Registrars, and ICANN work together to produce a RDAP profile. This can perhaps happen to address the same entity issue. - No fundamental issues with the recommendations but have issues with how they can be implemented. 4. Agreement on what to share with the GNSO Council for the 24 Oct GNSO Council meeting - In terms of update to the Council, it is just what has been discussed so far, including a particular item about inviting other stakeholders to be part of the conversation. - We need to invite those with knowledge in RPMs to the scoping team. The scoping team only has registries/registrars and technical people, and legal people to some degree. If we make a decision on PDP/EPDP, not sure whether it would be accepted by people from IPC and non-commercial group people. Need to create an explanatory letter to the IPC / Non-Commercial people about why we should invite them. Do we need to make another call to specifically invite the IPC, Non-Commercial people? - As for the concerns about representation, that could be captured at a high-level in the options paper shared with Council. And the details would be captured in the Charter. 5. AOB - ACTION ITEM: Staff to organize a scoping team call on Oct 24 at 3:00 UTC

2 1

Actions & Notes: GNSO IDN Scoping Team Meeting 10 October 13:00 UTC
by Ariel Liang Oct. 11, 2019

Oct. 11, 2019

Dear All, Please find below the action items and notes captured during the IDN Scoping Team call on Thursday, 10 October at 13:00-14:00 UTC. Staff has posted to the wiki space the action items and notes. Please note that these are high-level notes and are not meant as a substitute for the recording and chat room records, which are posted on the wiki at: https://community.icann.org/x/sZECBw Best Regards, Ariel == Action Item - Staff to organize a scoping team call on Oct 24 at 3:00 UTC Notes 1. Welcome and roll call 2. What have we tentatively agreed to so far? Review of the summary captured in the Options document (see page 8) Question about whether a PDP is needed - A PDP is needed to adopt the recommendations. - Does the disagreement from the staff paper require additional policy work, or it is something that can be resolved internally? This particular group should not look at the substance of the recommendations. Our main job is to decide whether we have enough stuff to deliberate in a PDP. What we should recommend as the next steps? - If we are proposing a PDP to cover various aspects, it is surely for the PDP to work on this. It is not up to the scoping team to solve all the issues. Question about whether additional research/analysis is needed - Is there additional research and analysis needed? Do we have enough body of information that can be moved into policy work by a group? - If we don’t go down the path of strawman proposal, it would be hard to say what technical impact it would has. - Develop a strawman and see whether standards need to be put into place before a policy is finalized. This work does not seem as straightforward. Because the policy has technical and operational implications, we need to come up with a report, park it there, get the technical issues ironed out before we come back and finalize the policy report. - In the translation and transliteration PDP, there was a strawman of all possibilities as to how T/T may work. All the possible solutions are very detailed and clear, with technical input and pros/cons for each solution. It sounds like an approach that can be applied in IDN variant TLD management policy development. - Going down the path of a PDP, we need extra work done in order to understand the technical and operational impact before we can finalize the policy recommendations. - If we want to defer the technical analysis to an IRT, we can also do that too. If it is not within the knowledge of the group to do the technical analysis, we can leverage other staff like technical staff in GDD, or even consultant. - Park the PDP till some additional research is done to finalize the policy to be recommended. Question about whether an Issue Report is needed - Do we feel the work needs to be done in the preparation of the issue report before the GNSO can take on the subject, or deal with the analysis during the PDP? - This scoping team is trying to determine if the staff reports serve as adequate proxies for an issue report.  - The question about whether an issue report is needed helps guide the scoping team’s thought on the options for policy mechanism. - Option A: Leveraging existing PDPs is not the correct approach. - Option B: Create a stand-alone PDP or EPDP. The issue is well represented / understood in the staff document. A likely recommendation is to create an EPDP. - The work already done provides a reasonable set of documents, which can be used to start the PDP and get a sense what the policy might look like. - The scoping team is somewhat undecided about an EPDP or PDP. Maxim feels that some issues need additional work before the policy WG can consider the matter. Some other people feel the set of documents are sufficient and can launch the policy work right away. Take all the staff documents as the starting point of deliberations and add a few more items if needed. - The scoping team is hung up on the EPDP or PDP question. If we go the EPDP route, are we leaving something unaddressed? If we go the PDP route, but acknowledge that there is already existing work that can expedite the first step of the PDP, it wouldn’t be so bad? If we have a full PDP, we just say we have the report from staff and the issue report can be completed by leveraging existing work. - Does the future PDP have the ability to go against the recommendations? The PDP/EPDP would not need be beholden to the recommendations in the staff report. It could come up with different recommendations. Question about what a policy WG would look like - Understand what type of people need to be included in the PDP working group. Stress the importance of expertise in the field. We need to do technical analysis in the course of the PDP itself and need people with the knowledge / expertise. - Instead of restricting membership, we should at least get some members from registrars and some members who understand legal issues. Form a PDP WG with the people of needed expertise. Not a lot of new information needs to be collected. - Support the recommendation to move away from an open WG model, and encourage people with subject matter expertise to join. - If we are talking about trademark issues in this PDP, make sure to invite members from IPC, NCSG, etc. 3. Continued: identifying problems/issues with IDN variant TLD recommendations - Disagree with the report’s assertion that IDN tables could be more easily managed if IDN tables are represented in machine readable format, thus asking to consider the implementation of RFC7940 (LGR in XML format). RFC7940 is a format (like CSV, TXT) to represent something, in this case a label generation ruleset or IDN table. Registries have working implementations that do not necessarily are on XML. RFC7940 could be used to build a new registration system, but it is unpractical to think that registries will retrofit their existing systems with it. - The harmonization of the IDN tables by implementing RFC7940 is going too far. Those not familiar with RFC7940 would have a hard time to implement. We are not going to retrofit how the implementation works. If we are going to represent LGRs in machine readable format, it is one thing. To manage the IDN tables via implementing RFC7940 is another. - The intention for the IDN table recommendation is not to change the internal implementation. The intention is to publish the IDN tables and provide more precise definition. The intention is more output facing, but not for implementation internally. For registries what they publish is what they use internally too, so there is an implication for implementation. - Viability of implementing the “same entity” at the second level. The recommendation touches the surface as to how the “same entity” can be implemented at the second level and the subsequent changes needed to support other operations, like transfer and update operations, availability and RDDS queries. This area needs more research and analysis to find a solution that is widely supported by registries and registrars. - Same entity requirement in the second level is more complicated. Registry contact ID is required. Reality is that some registrars tend to not to reuse the registry contact ID registered by the same registrant. If registries potentially cannot get information from the registrars, they cannot validate who the registrants are. This impacts the transfer. Registries need to know who the losing registrant and winning registrant are, and how many domain names are involved in this transaction. These days, a transfer pertains to a single domain. So when variants are introduced, they are intended to travel as a group. - Policy implementation related to the transfer puts burden on registrars and confuse registrants. - One analogy is the RDAP profile. Registries, Registrars, and ICANN work together to produce a RDAP profile. This can perhaps happen to address the same entity issue. - No fundamental issues with the recommendations but have issues with how they can be implemented. 4. Agreement on what to share with the GNSO Council for the 24 Oct GNSO Council meeting - In terms of update to the Council, it is just what has been discussed so far, including a particular item about inviting other stakeholders to be part of the conversation. - We need to invite those with knowledge in RPMs to the scoping team. The scoping team only has registries/registrars and technical people, and legal people to some degree. If we make a decision on PDP/EPDP, not sure whether it would be accepted by people from IPC and non-commercial group people. Need to create an explanatory letter to the IPC / Non-Commercial people about why we should invite them. Do we need to make another call to specifically invite the IPC, Non-Commercial people? - As for the concerns about representation, that could be captured at a high-level in the options paper shared with Council. And the details would be captured in the Charter. 5. AOB - ACTION ITEM: Staff to organize a scoping team call on Oct 24 at 3:00 UTC

1 0

Post call | IDN Scoping Team call | Thursday 10 October 2019 at 13:00 UTC
by Nathalie Peregrine Oct. 10, 2019

Oct. 10, 2019

Dear all, All recordings for the IDN Scoping Team call held on Thursday, 10 October 2019 at 13:00 UTC can be found on the agenda wiki page<https://community.icann.org/display/IDNST/2019-10-10+IDN+Scoping+Team+Call> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-council-idn-scoping/> and the main wiki page<https://community.icann.org/x/b4HkBg>. Thank you. Kind regards, Nathalie

1 0

Re: [GNSO-Council-IDN-Scoping] Actions & Notes: GNSO IDN Scoping Team Meeting 3 October 8:00 UTC
by Tan Tanaka, Dennis Oct. 10, 2019

Oct. 10, 2019

Hi Steve, all Sorry for the late post. I re-read the material and have a few topics that we can use to start the discussion: 1) Is there disagreement with the conclusions? if so, which ones and why * I disagree with the report’s assertion that IDN tables could be more easily managed if IDN tables are represented in machine readable format, thus asking to consider the implementation of RFC7940 (LGR in XML format). RFC7940 is a format (like CSV, TXT) to represent something, in this case a label generation ruleset or IDN table. Registries have working implementations that do not necessarily are on XML. RFC7940 could be used to build a new registration system, but it is unpractical to think that registries will retrofit their existing systems with it. 2) Is there additional research and analysis needed? * Viability of implementing the “same entity” at the second level. The recommendation touches the surface as to how the “same entity” can be implemented at the second level and the subsequent changes needed to support other operations, like transfer and update operations, availability and RDDS queries. I think this area needs more research and analysis to find a solution that is widely supported by registries and registrars. 3) Do you agree with the recommendations, but think there are details or precision missing? In other words, are there gaps in the recommendations? * In general agreement with the above caveats. Talk to you tomorrow. Best, Dennis From: gnso-council-IDN-scoping <gnso-council-idn-scoping-bounces(a)icann.org> on behalf of Steve Chan via gnso-council-IDN-scoping <gnso-council-idn-scoping(a)icann.org> Reply-To: Steve Chan <steve.chan(a)icann.org> Date: Wednesday, October 9, 2019 at 12:52 AM To: Ariel Liang <ariel.liang(a)icann.org>, "gnso-council-idn-scoping(a)icann.org" <gnso-council-idn-scoping(a)icann.org> Subject: [EXTERNAL] Re: [GNSO-Council-IDN-Scoping] Actions & Notes: GNSO IDN Scoping Team Meeting 3 October 8:00 UTC Hello all, Having not seen any discussion on list yet, this is a friendly reminder to review the email below and try and share some of your thoughts in advance of the upcoming meeting on Thursday. Best, Steve From: gnso-council-IDN-scoping <gnso-council-idn-scoping-bounces(a)icann.org> on behalf of Steve Chan via gnso-council-IDN-scoping <gnso-council-idn-scoping(a)icann.org> Reply-To: Steve Chan <steve.chan(a)icann.org> Date: Friday, October 4, 2019 at 1:38 PM To: Ariel Liang <ariel.liang(a)icann.org>, "gnso-council-idn-scoping(a)icann.org" <gnso-council-idn-scoping(a)icann.org> Subject: Re: [GNSO-Council-IDN-Scoping] Actions & Notes: GNSO IDN Scoping Team Meeting 3 October 8:00 UTC Thanks Ariel, all, For the first action item, staff would like to suggest that the group concentrate on the IDN Variant TLD Implementation documentation and in particular, document number 3, which provides the recommendations, rationale, and some considerations about actions that the GNSO might need to take in the consideration of the recommendations. The collection of documents is here: https://www.icann.org/resources/pages/idn-variant-tld-implementation-2018-0… and document 3 is directly available here: https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations…. As suggested by Edmon, it would be helpful if the group starts the discussion now on list, in advance of the meeting, about these recommendations. It may be helpful to consider the recommendations from the perspective of the questions posed previously: 1) Is there disagreement with the conclusions? if so, which ones and why 2) Is there additional research and analysis needed? 3) Do you agree with the recommendations, but think there are details or precision missing? In other words, are there gaps in the recommendations? Separately, please note that the Options document has been updated (still in red-line) to try and memorialize some of the draft agreements related to the IDN Guidelines (see page 8): https://docs.google.com/document/d/1o_9bfnkKufrSxiJGxpNcOcfTK2VLWp5XYQvwe5q…. Best, Steve From: gnso-council-IDN-scoping <gnso-council-idn-scoping-bounces(a)icann.org> on behalf of Ariel Liang via gnso-council-IDN-scoping <gnso-council-idn-scoping(a)icann.org> Reply-To: Ariel Liang <ariel.liang(a)icann.org> Date: Friday, October 4, 2019 at 12:40 PM To: "gnso-council-idn-scoping(a)icann.org" <gnso-council-idn-scoping(a)icann.org> Subject: [GNSO-Council-IDN-Scoping] Actions & Notes: GNSO IDN Scoping Team Meeting 3 October 8:00 UTC Dear All, Please find below the action items and notes captured during the IDN Scoping Team call on Thursday, 3 October at 8:00-9:00 UTC. Staff has posted to the wiki space the action items and notes. Please note that these are high-level notes and are not meant as a substitute for the recording and chat room records, which are posted on the wiki at: https://community.icann.org/x/UIcCBw Best Regards, Ariel == ACTION ITEMS - Staff to recirculate the relevant documents for the scoping team to review and identify which variant TLD recommendations would be appropriate to address in this potential IDN (e)PDP. - Staff to find an alternative timeslot for a meeting on Thursday, 10 Oct (possibly day time in NA). NOTES - It is hard to separate the second level items clearly from the IDN variant management issues. Need to find a way to reconcile them. - There is agreement on having one PDP and one process. If additional tasks needed to be added, it can be incorporate through charter amendment, etc. - The root zone document is different from the IDN guidelines and the variant management recommendations document. It was not originally scoping team’s plan to discuss. - The RZ-LGR recommendations might be relevant. If the Board accepts the RZ-LGR recommendations, and if/when a PDP is initiated for this work, future policy work related to RZ-LGR recommendations will need to be incorporated in the scope of the IDNs related PDP. - RZ-LGR stemmed from the lack of definition of variants. Different generation panels came together to propose LGRs for the script. Right now, RZ-LGR has not been adopted. There is no policy process to make them official. RZ-LGR will produce more consistency and predictability. - RZ-LGR is developed by the language community. The very origin is the last round of new gTLDs. - Separate the purely technical/linguistic aspects from the tech/operational/legal aspects. - Use an open PDP working group model, so members/experts from the ccNSO can participate. - There is already an existing process of updating the RZ-LGR: https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resource…>. Should we review the LGR process at this time, focusing on its inclusiveness? - LGR implementation process took 10 years (stemmed from an earlier PDP recommendation). - There can be two streams of work. May not have enough volunteers to participate in the two workstreams. - PDP 3.0 recommends making the scope of effort as lean as possible, focusing on the things that need to be done. - Should we look at the IDN variant TLD recommendation, and see which one(s) can be a potential target for policy work? In this way, when a PDP is launched, we have a clear understanding what needs to be done. - Include the RZ-LGR document as part of the reference document of the future PDP. The process includes a chartering group to define the scope of the PDP. Scoping team is the ‘traffic cop’? - The expectation from the Council is that this scoping team needs to provide guidance on the actual scope of the effort. The Council will rely on the expertise and experience of the scoping team to develop the charter, hence the scoping team includes people outside the Council. - Does RZ-LGR have enough overlap with other IDN issues? There should only be one PDP. - It’s not necessarily about a narrow scope, but make the scope only as wide as it needs to be. It’s easy to end up with a bloated scope (see SubPro PDP). - Don’t lump IDN issues into SubPro PDP; don’t use an expert group. Having a separate PDP is the way to go. - SubPro is about future TLDs, and the variant TLD policy will impact existing TLDs (i.e. existing contracts). - The difference between an EPDP and a PDP is that there is no Issue Report for an EPDP. There are several staff reports published already and they went through the community comments. The chartering process is to identify the relevant items for the EPDP. The scoping team should recommend the mechanism, but up to the Council to decide. - Scoping team should be in the position to report to the Council during its October meeting. - ACTION ITEM: Staff to recirculate the relevant documents for the scoping team to review and identify which variant TLD recommendations would be appropriate to address in this potential IDN (e)PDP. - ACTION ITEM: Staff to find an alternative timeslot for a meeting on Thursday, 10 Oct (possibly day time in NA).

3 3

Proposed Agenda: IDN Scoping Team Call - Thursday, 10 October 2019 at 13:00 UTC
by Steve Chan Oct. 9, 2019

Oct. 9, 2019

Dear All, Please see the proposed agenda for this week’s meeting on Thursday, 10 October 2019 at 13:00 UTC: 1. Welcome and roll call 2. What have we tentatively agreed to so far? Review of the summary captured in the Options document (see page 8 here: https://docs.google.com/document/d/1o_9bfnkKufrSxiJGxpNcOcfTK2VLWp5XYQvwe5q…) 3. Continued: identifying problems/issues with IDN variant TLD recommendations 4. Agreement on what to share with the GNSO Council for the 24 October GNSO Council Meeting 5. AOB For Item 3, the collection of relevant documents is here: https://www.icann.org/resources/pages/idn-variant-tld-implementation-2018-0… and document 3 is directly available here: https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations…. Best, Steve Steven Chan  Policy Director, GNSO Support Internet Corporation for Assigned Names and Numbers (ICANN) 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536  Email: steve.chan(a)icann.org Skype: steve.chan55 Mobile: +1.310.339.4410 Find out more about the GNSO by visiting: https://learn.icann.org/ Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar See All SO and AC events on the ICANN Global calendar [features.icann.org]

1 0

Actions & Notes: GNSO IDN Scoping Team Meeting 3 October 8:00 UTC
by Ariel Liang Oct. 9, 2019

Oct. 9, 2019

Dear All, Please find below the action items and notes captured during the IDN Scoping Team call on Thursday, 3 October at 8:00-9:00 UTC. Staff has posted to the wiki space the action items and notes. Please note that these are high-level notes and are not meant as a substitute for the recording and chat room records, which are posted on the wiki at: https://community.icann.org/x/UIcCBw Best Regards, Ariel == ACTION ITEMS - Staff to recirculate the relevant documents for the scoping team to review and identify which variant TLD recommendations would be appropriate to address in this potential IDN (e)PDP. - Staff to find an alternative timeslot for a meeting on Thursday, 10 Oct (possibly day time in NA). NOTES - It is hard to separate the second level items clearly from the IDN variant management issues. Need to find a way to reconcile them. - There is agreement on having one PDP and one process. If additional tasks needed to be added, it can be incorporate through charter amendment, etc. - The root zone document is different from the IDN guidelines and the variant management recommendations document. It was not originally scoping team’s plan to discuss. - The RZ-LGR recommendations might be relevant. If the Board accepts the RZ-LGR recommendations, and if/when a PDP is initiated for this work, future policy work related to RZ-LGR recommendations will need to be incorporated in the scope of the IDNs related PDP. - RZ-LGR stemmed from the lack of definition of variants. Different generation panels came together to propose LGRs for the script. Right now, RZ-LGR has not been adopted. There is no policy process to make them official. RZ-LGR will produce more consistency and predictability. - RZ-LGR is developed by the language community. The very origin is the last round of new gTLDs. - Separate the purely technical/linguistic aspects from the tech/operational/legal aspects. - Use an open PDP working group model, so members/experts from the ccNSO can participate. - There is already an existing process of updating the RZ-LGR: https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en. Should we review the LGR process at this time, focusing on its inclusiveness? - LGR implementation process took 10 years (stemmed from an earlier PDP recommendation). - There can be two streams of work. May not have enough volunteers to participate in the two workstreams. - PDP 3.0 recommends making the scope of effort as lean as possible, focusing on the things that need to be done. - Should we look at the IDN variant TLD recommendation, and see which one(s) can be a potential target for policy work? In this way, when a PDP is launched, we have a clear understanding what needs to be done. - Include the RZ-LGR document as part of the reference document of the future PDP. The process includes a chartering group to define the scope of the PDP. Scoping team is the ‘traffic cop’? - The expectation from the Council is that this scoping team needs to provide guidance on the actual scope of the effort. The Council will rely on the expertise and experience of the scoping team to develop the charter, hence the scoping team includes people outside the Council. - Does RZ-LGR have enough overlap with other IDN issues? There should only be one PDP. - It’s not necessarily about a narrow scope, but make the scope only as wide as it needs to be. It’s easy to end up with a bloated scope (see SubPro PDP). - Don’t lump IDN issues into SubPro PDP; don’t use an expert group. Having a separate PDP is the way to go. - SubPro is about future TLDs, and the variant TLD policy will impact existing TLDs (i.e. existing contracts). - The difference between an EPDP and a PDP is that there is no Issue Report for an EPDP. There are several staff reports published already and they went through the community comments. The chartering process is to identify the relevant items for the EPDP. The scoping team should recommend the mechanism, but up to the Council to decide. - Scoping team should be in the position to report to the Council during its October meeting. - ACTION ITEM: Staff to recirculate the relevant documents for the scoping team to review and identify which variant TLD recommendations would be appropriate to address in this potential IDN (e)PDP. - ACTION ITEM: Staff to find an alternative timeslot for a meeting on Thursday, 10 Oct (possibly day time in NA).

2 2

Re: [GNSO-Council-IDN-Scoping] Alternative Time for 10 October Meeting
by Tan Tanaka, Dennis Oct. 4, 2019

Oct. 4, 2019

It’s fine with me, Ariel. Thanks, Dennis From: gnso-council-IDN-scoping <gnso-council-idn-scoping-bounces(a)icann.org> on behalf of Ariel Liang via gnso-council-IDN-scoping <gnso-council-idn-scoping(a)icann.org> Reply-To: Ariel Liang <ariel.liang(a)icann.org> Date: Thursday, October 3, 2019 at 2:43 PM To: "gnso-council-idn-scoping(a)icann.org" <gnso-council-idn-scoping(a)icann.org> Subject: [EXTERNAL] [GNSO-Council-IDN-Scoping] Alternative Time for 10 October Meeting Dear All, Per action item, staff would like to check whether scoping team members are available for a call at 13:00 UTC on Thursday, 10 October as an alternative meeting time. It is not too late in Hong Kong (evening) and during the day time for Europe (afternoon) and North America (morning). If no objection, staff will schedule the call according to the suggested time. Best Regards, Ariel

2 1

Alternative Time for 10 October Meeting
by Ariel Liang Oct. 3, 2019

Oct. 3, 2019

Dear All, Per action item, staff would like to check whether scoping team members are available for a call at 13:00 UTC on Thursday, 10 October as an alternative meeting time. It is not too late in Hong Kong (evening) and during the day time for Europe (afternoon) and North America (morning). If no objection, staff will schedule the call according to the suggested time. Best Regards, Ariel

1 0

Post call | IDN Scoping Team call | Thursday 03 October 2019 at 08:00 UTC
by Nathalie Peregrine Oct. 3, 2019

Oct. 3, 2019

Dear all, All recordings for the IDN Scoping Team call held on Thursday, 03 October 2019 at 08:00 UTC can be found on the agenda wiki page<https://community.icann.org/x/UIcCBw> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-council-idn-scoping/> and the main wiki page<https://community.icann.org/x/b4HkBg>. Thank you. Kind regards, Nathalie

1 0

FW: Request to forward: Recommendations on Technical Utilization of RZ-LGR
by Steve Chan Oct. 3, 2019

Oct. 3, 2019

Dear IDN Scoping Team, FYI, just forwarded the attached documents around the Recommendations for the Technical Utilization of the Root Zone Label Generation Rules (RZ-LGR) to the GNSO Council leadership team. Edmon and Dennis will of course already be familiar with them. Please see the note to Council leadership for additional context. Best, Steve From: Steve Chan <steve.chan(a)icann.org> Date: Wednesday, October 2, 2019 at 10:34 AM To: <gnso-chairs(a)icann.org> Subject: FW: Request to forward: Recommendations on Technical Utilization of RZ-LGR Keith, Pam, Rafik, As noted by Sarmad below, “Please find attached the Recommendations for the Technical Utilization of the Root Zone Label Generation Rules (RZ-LGR) developed by the RZ-LGR Study Group (SG) and a cover note by the SG for the SO/AC chairs.” Per the cover letter, the next step is publication of the report and recommendations, along with Board consideration. If these technical recommendations are adopted by the Board, they should be considered in conjunction with the IDN variant recommendations already adopted and being discussed by the IDNs Scoping Team. At this time, I do not believe there is any action needed and these documents are being sent in advance of publication as a courtesy, though we may want to also forward to the IDN Scoping Team. We’re happy to do so if you agree. Best, Steve From: Sarmad Hussain <sarmad.hussain(a)icann.org> Date: Tuesday, October 1, 2019 at 7:31 AM To: Steve Sheng <steve.sheng(a)icann.org>, Steve Chan <steve.chan(a)icann.org>, Heidi Ullrich <Heidi.Ullrich(a)icann.org>, Bart Boswinkel <bart.boswinkel(a)icann.org> Subject: Request to forward: Recommendations on Technical Utilization of RZ-LGR Dear all, Please find attached the Recommendations for the Technical Utilization of the Root Zone Label Generation Rules (RZ-LGR) developed by the RZ-LGR Study Group (SG) and a cover note by the SG for the SO/AC chairs. May I request you to please help forward these to the chairs of the respective SOs and ACs which you support (SSAC, ALAC, GNSO and ccNSO) on behalf of the SG. I would appreciate if you can confirm sending this across, for me to report back to the SG. Regards, Sarmad

1 0

Proposed agenda 3 October 2019, 08:00 UTC
by Steve Chan Oct. 2, 2019

Oct. 2, 2019

Dear All, With apologies, I just realized I neglected to send an agenda for the IDN Scoping team call, I think partially because it’s likely rather clear what we will discuss. However, please find the proposed agenda below: Welcome, roll call & staff update Continued: Identifying problems/issues with IDN variant TLD recommendations AOB For item 2, it may be helpful to think of that item in the context of the questions posed to the list and responded to by both Dennis and Edmon (which I see was only sent to Dennis, Ariel, and me). You can find Edmon’s response below. Best, Steve From: Edmon <edmon(a)registry.asia> Date: Thursday, September 26, 2019 at 12:11 AM To: "'Tan Tanaka, Dennis'" <dtantanaka(a)verisign.com>, Steve Chan <steve.chan(a)icann.org>, Ariel Liang <ariel.liang(a)icann.org> Subject: [Ext] RE: [GNSO-Council-IDN-Scoping] Actions & Notes: GNSO IDN Scoping Team Meeting 12 September 3:00 UTC Apologies again for the change in schedule, and thanks for the flexibility to accommodate the change. Am currently at the CDNC meetings in Taipei. Thanks also Steve for kicking off the discussions. Please do take a look and give your thoughts. In general, as mentioned at the end of last meeting, I am in rough agreement with the conclusions. And the roughness is due to a big uncertainty about the integrity of the IDN Variant concept of considering the base/primary IDN and its corresponding IDN Variants as an integral application/registration/etc by policy. In short I personally think that it is important for the community to go through the Policy process to make this clarification and direction more concrete (even though the concept has been included in the previous GNSO Policy within the IDN Outcomes report) or if it is to be . Most of the gaps in the recommendations can be addressed I think in implementation except for this overarching issue. But I think a PDP (whether E or not) would make sense to not only clarify this overarching concept (integrity of base/primary IDN with its set of IDN Variants as defined by the relevant LGR) as well as the other recommendations should be useful. The previous IDN Outcomes report is in any case more than 10 years old and should be updated, even though when I read it recently many of the principles remain relevant. My personal view of it, but I am hoping to get other’s thoughts on Steve’s questions as well. Edmon From: gnso-council-IDN-scoping [mailto:gnso-council-idn-scoping-bounces@icann.org] On Behalf Of Tan Tanaka, Dennis via gnso-council-IDN-scoping Sent: Tuesday, September 24, 2019 9:36 PM To: Steve Chan <steve.chan(a)icann.org>; Ariel Liang <ariel.liang(a)icann.org>; gnso-council-idn-scoping(a)icann.org Subject: Re: [GNSO-Council-IDN-Scoping] Actions & Notes: GNSO IDN Scoping Team Meeting 12 September 3:00 UTC Steve, all Thanks for setting this up and appreciate this week’s meeting being rescheduled for next week. I will have more time to prepare. About the below questions. I agree, they are a good starting point. Best, Dennis From: gnso-council-IDN-scoping <gnso-council-idn-scoping-bounces(a)icann.org> on behalf of Steve Chan via gnso-council-IDN-scoping <gnso-council-idn-scoping(a)icann.org> Reply-To: Steve Chan <steve.chan(a)icann.org> Date: Monday, September 23, 2019 at 7:46 PM To: Ariel Liang <ariel.liang(a)icann.org>, "gnso-council-idn-scoping(a)icann.org" <gnso-council-idn-scoping(a)icann.org> Subject: [EXTERNAL] Re: [GNSO-Council-IDN-Scoping] Actions & Notes: GNSO IDN Scoping Team Meeting 12 September 3:00 UTC Hello Team, The agenda of the upcoming meeting will focus on continuing the discussion from last meeting: Identifying problems/issues with IDN variant TLD recommendations. In advance of the next meeting, staff thought it might be useful to try and get conversation started on this topic over email, which from our perspective was helpful to think along the lines below as identified in the last meeting. In respect of the IDN Variant TLD Implementation [icann.org] 1) Is there disagreement with the conclusions? if so, which ones and why 2) Is there additional research and analysis needed? 3) Do you agree with the recommendations, but think there are details or precision missing? In other words, are there gaps in the recommendations? This is not intended to limit the discussion in any way but rather to initiate discussion and hopefully streamline the conversation during the actual meeting. The logic in thinking through the issues and expected level of work is that you then have better information to make a decision on the proper policy development vehicle (i.e., new PDP, new EPDP, leverage in-flight PDPs). Best, Steve From: gnso-council-IDN-scoping <gnso-council-idn-scoping-bounces(a)icann.org> on behalf of Ariel Liang via gnso-council-IDN-scoping <gnso-council-idn-scoping(a)icann.org> Reply-To: Ariel Liang <ariel.liang(a)icann.org> Date: Thursday, September 12, 2019 at 8:44 AM To: "gnso-council-idn-scoping(a)icann.org" <gnso-council-idn-scoping(a)icann.org> Subject: [GNSO-Council-IDN-Scoping] Actions & Notes: GNSO IDN Scoping Team Meeting 12 September 3:00 UTC Dear All, Please find below the action items and notes captured during the IDN Scoping Team call on Thursday, 12 September at 3:00-4:00 UTC. Staff has posted to the wiki space the action items and notes. Please note that these are high-level notes and are not meant as a substitute for the recording and chat room records, which are posted on the wiki at: https://community.icann.org/x/VY7kBg Best Regards, Ariel == Action Item None Notes 1. Welcome, roll call & staff - Katrina sent a letter to the ICANN Board, requesting the Board to officially end ccNSO PDP2, so that ccNSO can launch PDP4 which focuses on outlining the difference between string similarity and IDN variant, as well as selection of IDN ccTLD strings, etc. https://ccnso.icann.org/sites/default/files/field-attached/sataki-to-chalab… [ccnso.icann.org] - Will better understand the timeline of ccNSO PDP4 following the ccNSO Council meeting next Thursday. GNSO staff will keep coordinating with the ccNSO staff and keep the scoping team informed about the timeline. 2. Conclude identifying problems/issues related to the IDN guidelines/IDN tables (2nd level) - On sending liaison(s) to the ccPDP on IDN ccTLDs, the scoping team plans to ask the GNSO Council to call for volunteer(s) to serve as liaison(s) with the understanding that 1) the liaisons should have some expertise on the subject matter and, 2) not be limited Council members. - There may be some limitations on the number of people who will volunteer for the liaison position. - When the ccNSO PDP4 working group charter is being developed, the liaison aspect will be integrated. GNSO & ccNSO staff will also discuss the number of liaisons in the next coordination call. - For PDPs, the Council usually only assigns a single liaison. - Liaison represents one mechanism for coordination between the ccNSO and GNSO. The Scoping Team may consider holding off sending the Council the request to call for volunteer, and thinking about other mechanisms for coordination. GNSO Council does not need to rush to select liaison(s) yet. - Working conclusion of the IDN Tables/IDN Implementation Guidelines (2nd level): On the topic of ICANN IDN Implementation Guidelines the Scoping Team will propose for the GNSO to set up 2 working groups: 1) an expert group that should include policy/legal and technical/operations expertise to address outstanding issues of the implementation of the guidelines 4.0 and its implications on operations, change of backend registry and the Registry Agreement in particular as it relates to Exhibit A and Spec 6; 2) a policy working group that would look into the appropriate future processes and updates of the IDN Implementation Guidelines, including where it may be appropriate to distinguish/separate from the ccNSO, and how it fits into the broader policy context and technical/operational requirements of gTLDs. - Good to give the Council some indication on the progress and provide an update on the preliminary recommendations for the IDN Tables/IDN Implementation Guidelines. - Staff have been updating the option paper by adding the problem definition outline and will make it compatible with Edmon’s phrasing about the working conclusions. 3. Identifying problems/issues with IDN variant TLD recommendations - Presentation by Sarmad on IDN Variant TLD recommendations - Now is time to consider developing policy regarding the allocation and delegation of the variant TLD recommendations. It may be safe to say that a PDP is probably required. A PDP should probably start from the staff documents for the IDN Variant TLD recommendations. - The scope of work will help inform the selection of mechanism. Helpful questions to think of 1) is there disagreement with the conclusions? if so, which ones and why 2) is there additional research and analysis needed? 3) do you agree with the recommendations, but think there are details or precision missing? in other words, are there gaps in the recommendations? - For example, if additional research and analysis are not needed, then an Issue Report can be skipped and can request the Council to launch an EPDP, and the staff paper could serve as the Issue Report. - What would be the outcome of the GNSO PDP? Even if people agree with all the IDN variant TLD management recommendations, we will still need an official process to validate the recommendations. We could potentially rely on some inflight PDPs (RPM, SubPro) to validate those recommendations. - Maybe some part of the recommendations can be deliberated by SubPro, but some other parts cannot work, as it is forward looking. GNSO Council can also change the scope of SubPro PDP, if necessary.  - One of the problems with the recommendation is about the multiple applicant for variant TLDs. 4. AOB

1 0