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