- gnso-council-IDN-scoping - lists.icann.org

Proposed Agenda: IDN Scoping Team Call on Thursday, 05 December 2019 at 03:00 UTC
by Steve Chan Dec. 5, 2019

Dec. 5, 2019

Dear All, Please see below the proposed agenda for this week’s meeting on Thursday, 05 December 2019 at 03:00 UTC: Welcome and roll call Review of new Issue Scoping Document here: https://docs.google.com/document/d/13tO5IP64EAnFebdefRahK3vuhIBzUEdl1oeGFBn… After discussing agenda item 2, revisiting the options paper: https://docs.google.com/document/d/1o_9bfnkKufrSxiJGxpNcOcfTK2VLWp5XYQvwe5q… Possible next steps AOB For item 2, this new issue scoping document was drafted to respond to this action item identified from a previous meeting: “Staff to identify the part of the staff papers for IDN variant TLD management that can fit in an Issue Report.” This new document is intended to help determine if there is sufficient existing background documentation and resources that might make a formal Issue Report unnecessary. 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

2 1

Re: [GNSO-Council-IDN-Scoping] Next step
by Tan Tanaka, Dennis Nov. 30, 2019

Nov. 30, 2019

This is useful, Steve. Thank you. I will be available in those dates. Best, Dennis From: Steve Chan <steve.chan(a)icann.org> Date: Monday, November 25, 2019 at 2:47 PM To: Dennis Tan Tanaka <dtantanaka(a)verisign.com>, Steve Chan via gnso-council-IDN-scoping <gnso-council-idn-scoping(a)icann.org> Subject: [EXTERNAL] Re: [GNSO-Council-IDN-Scoping] Next step Hi Dennis, all, We are looking to get a couple of meetings scheduled for 4/5 Dec and 11/12 Dec, but are trying to work out the times before getting them added to the calendar. In the meantime, staff is working on this action item: “Staff to identify the part of the staff papers for IDN variant TLD management that can fit in an Issue Report.” Thanks for checking in. Best, Steve From: gnso-council-IDN-scoping <gnso-council-idn-scoping-bounces(a)icann.org> on behalf of "Tan Tanaka, Dennis via gnso-council-IDN-scoping" <gnso-council-idn-scoping(a)icann.org> Reply-To: "Tan Tanaka, Dennis" <dtantanaka(a)verisign.com> Date: Monday, November 25, 2019 at 10:58 AM To: Steve Chan via gnso-council-IDN-scoping <gnso-council-idn-scoping(a)icann.org> Subject: [GNSO-Council-IDN-Scoping] Next step Hi Steve, et al Just doing a check-in and wonder if this group is planning to resume in the remainder of the year. I will be on holiday from Dec 14 ‘til Jan 1, but can probably make myself available during that time if provided advanced notice (except dates Dec 19-21 because I will be in a location with possibly unreliable internet connection). Best, Dennis

2 1

Re: [GNSO-Council-IDN-Scoping] Next step
by Steve Chan Nov. 25, 2019

Nov. 25, 2019

Hi Dennis, all, We are looking to get a couple of meetings scheduled for 4/5 Dec and 11/12 Dec, but are trying to work out the times before getting them added to the calendar. In the meantime, staff is working on this action item: “Staff to identify the part of the staff papers for IDN variant TLD management that can fit in an Issue Report.” Thanks for checking in. Best, Steve From: gnso-council-IDN-scoping <gnso-council-idn-scoping-bounces(a)icann.org> on behalf of "Tan Tanaka, Dennis via gnso-council-IDN-scoping" <gnso-council-idn-scoping(a)icann.org> Reply-To: "Tan Tanaka, Dennis" <dtantanaka(a)verisign.com> Date: Monday, November 25, 2019 at 10:58 AM To: Steve Chan via gnso-council-IDN-scoping <gnso-council-idn-scoping(a)icann.org> Subject: [GNSO-Council-IDN-Scoping] Next step Hi Steve, et al Just doing a check-in and wonder if this group is planning to resume in the remainder of the year. I will be on holiday from Dec 14 ‘til Jan 1, but can probably make myself available during that time if provided advanced notice (except dates Dec 19-21 because I will be in a location with possibly unreliable internet connection). Best, Dennis

1 0

Next step
by Tan Tanaka, Dennis Nov. 25, 2019

Nov. 25, 2019

Hi Steve, et al Just doing a check-in and wonder if this group is planning to resume in the remainder of the year. I will be on holiday from Dec 14 ‘til Jan 1, but can probably make myself available during that time if provided advanced notice (except dates Dec 19-21 because I will be in a location with possibly unreliable internet connection). Best, Dennis

1 0

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