July 2021 - GNSO-TPR - lists.icann.org

Notes and action items - TPR Meeting #07 - 06 July 2021
by Julie Hedlund July 6, 2021

July 6, 2021

Dear TPR Working Group, Please find below the notes and action items from today’s TPR meeting. The next meeting will be Tuesday, 27 July at 16:00 UTC. The meetings on 13 and 20 July are cancelled. Best regards, Emily, Caitlin, Berry, and Julie -- Action Items ACTION ITEM: Deadline by Thursday, 08 July 2021 at 23:59 UTC -- Call for volunteers for a small team to develop draft answers to the charter questions. Volunteers captured from today’s meeting: Jothan Frakes, Volker Greimann, Jody Kolker. ACTION ITEM: Staff to cancel the full WG meeting on 13 July 2021. Schedule a small team meeting either at the same time or another time. Also see the project workplan [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1FunWaz3g…> for action items. Transfer Policy Review Phase 1 - Meeting #07 Proposed Agenda Tuesday 06 July at 16.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 3. Work Plan (15 minutes) – See attached. Presentation by Berry Cobb: A few highlights and comments about the Work Plan: * Per PDP3.0, Working Groups are now required to submit its proposed schedule of milestones and deliverable dates to the GNSO Council as the managers of the Policy Development Process. * The intent of this requirement is to increase predictability for managing current and future policy work in the pipeline for the GNSO. This is also about increasing the accountability of the Working Group, Leadership and Staff to deliver on schedule per its charter requirements. * The proposed key milestone dates: * 16 Jun 2022 – Deliver Phase 1A Initial Report on Transfer Policy for public comment, begin Phase 1B deliberations on Change of Registrant * 14 Sep 2022 – Conclude review Phase 1A comments * 30 Mar 2023 – Deliver Phase 1B Initial Report for public comment * 28 Jun 2023 – Conclude review of Phase 1B public comments * 16 Aug 2023 – Deliver Phase 1A, 1B Final Report to the GNSO Council * Phase 2 is not in scope for this plan, but this process will be repeated when it begins. * Assumptions: * meeting once per week; * doesn’t account for downtime (such as US holidays); * there is padding built into the plan, but some is accounted for (such as for holidays); * Format: deliberate on charter questions; develop recommendations and draft report; repeat. * On the Gantt chart we are taking the work sequentially – initial report for two phases and then final report. * This not a plan based solely on calendar days. * Less than 80 hours of call time before June of next year to deliver the Phase 1A Initial Report. * Committing to this timeline is under promising and over delivering. But still a risk if we can’t meet this plan. Better served to be more aggressive up front. Do have tools such as extending meeting time and increasing meetings if necessary, or working some topics in parallel. * Need to send this to the GNSO Council for consideration by next Monday, 12 July. It is on the agenda for the 22 July Council meeting. * This is a leadership team work product to maintain an accurate representation of the WG’s efforts and schedule. To make up for this, staff will also maintain a more tactical work plan and track the WG’s action items here: https://docs.google.com/spreadsheets/d/1FunWaz3gNZl8mPi5pNKti2GsfPC_9_DTt8u… [docs.google.com]<https://docs.google.com/spreadsheets/d/1FunWaz3gNZl8mPi5pNKti2GsfPC_9_DTt8u…>. At the conclusion of each month, staff will also produce a project package that contains a compilation of several work products for us to communicate the status and health of this project to the community. 4. Continued discussion of AuthInfo Codes: Charter Questions B3, B4, and (time permitting) B5 (60 minutes) From last week’s discussion re: Question b3) The Transfer Policy currently requires registrars to provide the AuthInfo Code to the registrant within [up to] five [calendar] days of a request. Is this an appropriate SLA for the registrar’s provision of the AuthInfo Code, or does it need to be updated? [amendments in strikeout/brackets] * Seems from the discussion that five calendar days was right. * Could suggest a slight change to “up to five calendar days”. * Not sure where the five calendar days came from. Charter questions b4, b5, and b6: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…>. Archive of earlier versions: https://community.icann.org/x/e4P8CQ. For easy reference, the questions are: * b4) The Transfer Policy does not currently require a standard Time to Live (TTL) for the AuthInfo Code. Should there be a standard Time To Live (TTL) for the AuthInfo Code? In other words, should the AuthInfo Code expire after a certain amount of time (hours, calendar days, etc.)?’ * Could set a TTL, but perhaps improve the end-user experience with a one-time authorization code. Look at what is a standard/best practice TTL. * In Tech Ops discussions 14 days was suggested. * Questions to think about: As you decide whether 14 days is enough, consider the overall business process and what is going on here. If the code gets used, expect that part of the system the registry would clear the code and not allow it to be used. So 14 days longer than 5 days would not be right. There is a relationship among these parts. 14 days could be too long given the one-time use principle. * Consider that many transfers are initiated that never go through. * Does TTL have any real-world benefits/scenarios? If there are none then there is no reason to have TTL. * Why do we have to stick to some number of days before it gets deleted? * Assume that the 14 days start only when the customer has been given the tag. * There would not be an AuthCode on a domain until a transfer is initiated. Once the transfer is complete the AuthCode is deleted. * Assume that if the transfer wasn’t completed in 14 days then the registrar would need to request a new AuthCode. * Is the 14 days a security risk (with the 5 calendar days)? Yes, the email could be hacked. Seems like 14 days is too long. * Consider a shortened TTL for important registrants or domain names. * Another example: having a TTL is a good security practice, but there is a relationship between the TTL and the security principle of one-time use. Need to map out the business process to decide whether to have a TTL and its length; could have a minimum TTL as a principle. Critical question is who controls the TTL. The registrar should own that, but how does the registry know there is a TTL and what it is? Registrars may want to have different lengths of TTLs for different reasons. Need to think of these questions in the overall security picture. * If we go down the path of one-time use then the TTL is the maximum time for that one-time use. * In many cases the relationship between the registrar and registrant is not a direct one. A request for an AuthCode could go to a reseller or other provider for example, creating a feedback-loop. A registrar may not even know that the request has been made. Need to remember the different models. Whoever does the EPP would know about the request for an AuthCode, so the registrar would know if he does the EPP. * More reason to have a short TTL when the AuthCode passes through many hands – not just registrar to registrant. * Need to consider how long it will take to implement this. Flexibility depends on who is setting the TTL. For important/high-value domains the registrar may want to set a very short TTL for liability purposes. * We will need to revisit this question when we discuss bulk transfers. * High value domain names should be protected by Registry Lock or similar, hence an intense dialog between the registrant/owner and the registrar will be needed to make the label ready for a transfer. * Consider a manual revocation of the AuthCode, such as if the registrant decides not to transfer. * Think about policy versus saying “yes, you can do this” or “no, you can’t do this”. * b5) Should the ability for registrants to request AuthInfo Codes in bulk be streamlined and codified? If so, should additional security measures be considered? * Talked about this a couple of times. * Good question as to whether there is a need for it. * What you find with a lot of domainers they tend to be more security conscious. Could look at adding security for bulk transfers. * In the past the AuthCode has always been unique for each domain name. But some domainers might not be well served to receive one code per domain when they have bulk domains. * Not sure there is an issue if you want to do requests in bulk; could just leave it up to the registrar. Just keep it simple and leave the solution to the registrar. * Do we get an advantage of trying to standardize across registrars, or leave it up to each registrar and their business models? * b6) Does the CPH TechOps research provide a logical starting point for future policy work on AuthInfo Codes, or should other options be considered? Note: As a starting point, the Support Staff Team has included relevant portions of the CPH TechOps paper under the relevant charter questions; however, this does not prevent the WG from considering both the pros and cons of the TechOps suggestions and alternative proposals. * What is missing from the TechOps paper that we should be considering? * Already started using a lot of what the TechOps provided. * b7) Should required differentiated control panel access also be considered, i.e., the registered name holder is given greater access (including access to the auth code), and additional users, such as web developers would be given lower grade access in order to prevent domain name hijacking? Note: As a starting point, this charter question was included in response to the following feedback from the Transfer Policy Status Report Survey, “I am concerned about who receive[s] [the AuthCode][.] [I]f we could confirm that only [the] registrant can receive [the AuthCode], then we may no longer need FOA.” * This is a business practice and an overstep by ICANN to set as a policy. * This could not be a recommendation, but just a comment that these security measures are out there. * Sounds like there is agreement that this is out of scope for this PDP; could just create a list of other security practices that the WG considered, but decided not to make them policies. General Discussion: * Is there one solution scenario that we can create – TechOps, WG recommendations, etc. – pull together to make a close-to-complete model for AuthInfo Codes and provide them to TechOps for consideration? * We can definitely pull some draft recommendations/suggestions to pose to TechOps. There is a benefit to pose questions to TechOps. * Would like to bring up the potential of having a Proof of Ownership field. Some overlap with DNS. Ways to do this now as a paid service. If you had a field you could change you could prove that you have editing ability for that domain. You want to follow the ownership chain back to show that you have the authority to make changes to the DNS. * On the losing side proof of ownership is already there. * Helpful to transfer this conversation to the list with a proposal from John Woodworth. * Need to start coming up with draft recommendations for AuthInfo codes – do this via a small group, or via the full WG? * Do we have a threshold question that we need to determine before handing this work to TechOps? * What will be important for this next phase is that it is kept in the context of the current requirements for AuthInfo codes – such as whether there are recommendations for any of the current requirements need to change, or what are recommendations for additional policy requirements. * Could cancel next week’s meeting and use it for the small team meeting, or could schedule a different time. ACTION ITEM: Deadline by Thursday, 8 July 2021 at 23:59 UTC -- Call for volunteers for a small team to develop draft answers to the charter questions. Volunteers captured from today’s meeting: Jothan Frakes, Volker Greimann, Jody Kolker. 6. AOB (5 minutes) - Next meeting: 13 July 2021 @ 16.00 UTC * SSAD ODP webinar schedule at the same time as our meeting next week. Need to decide if that is an issue. * Several people wish to attend the SSAD ODP. * Meeting on 20 July is already cancelled. * Next meeting is 27 July. ACTION ITEM: Staff to cancel the full WG meeting on 13 July 2021. Schedule a small team meeting either at the same time or another time.

2 1

Post Call | Transfer Policy Review PDP WG | Tuesday, 06 July 2021 at 16:00 UTC
by Julie Bisland July 6, 2021

July 6, 2021

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 06 July 2021 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/WgTpCQ> (attendance included) and the GNSO Master calendar [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. 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) * Transcript As a reminder only members and alternates can join the call as a Panelist, observers can join as an Attendee to listen. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-tpr/> and the main wiki page<https://community.icann.org/x/P4aUCQ>. Thank you. With kind regards, Julie

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 27 July 2021 at 16:00 UTC
by Julie Bisland July 6, 2021

July 6, 2021

As a reminder the meetings scheduled for 13 July 2021 and 20 July 2021 have been cancelled. The next call information is below: Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 27 July 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> Visit the Wiki Agenda meeting page: https://community.icann.org/x/YATpCQ Check your time zone: https://tinyurl.com/upysw9e6 ONLY FOR MEMBERS & ALTERNATES: * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Members (and alternates replacing members), please select Panelists and Attendees when posting to the chat in order for everyone to see and to be captured afterwards. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Please rename your line by adding THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

Canceled: Transfer Policy Review PDP WG
by ICANN Policy Calendar July 6, 2021

July 6, 2021

**13 July 2021 has been cancelled** Meeting: Transfer Policy Review PDP WG Date/Time: Recurring call every Tuesday at 16:00 UTC for 90 minutes, 29 June 2021 through 31 August 2021 Join the Zoom Webinar: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 Passcode: @TP/^*4wg# ALL: Before joining the call: Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> Visit the 29 June Wiki Agenda meeting page: https://community.icann.org/x/VwTpCQ (see left side for other meeting dates) Check your time zone: https://tinyurl.com/5k3u34hf ONLY for Members & Alternates: * Please join via the above Zoom Webinar link and staff will promote you to Panelist * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form<https://docs.google.com/forms/d/e/1FAIpQLScXP3-H595xH4EFgaR3ydOr-1o9BLAVGUI…> to communicate who the alternate is replacing and for which period. This information will be posted to the Alternate Log-Transfer Policy Review PDP wiki page<https://community.icann.org/x/V4aUCQ>. * Members and alternates replacing members, please select Panelists and Attendees when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates (not replacing a member): Please rename your line in Zoom by adding THREE Zs “zzz” before your name, and in parentheses, (your affiliation - alternate), after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. For Audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6

1 0

**15-minute reminder** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 06 July 2021 at 16:00 UTC
by Julie Bisland July 6, 2021

July 6, 2021

**15-minute reminder** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 06 July 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> Visit the Wiki Agenda meeting page: https://community.icann.org/x/WgTpCQ Check your time zone: https://tinyurl.com/3zvakspb [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/3zvakspb__;!!PtGJab4!prNjmFk…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Members (and alternates replacing members), please select Panelists and Attendees when posting to the chat in order for everyone to see and to be captured afterwards. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Please rename your line by adding THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Andrea

1 0

Transfer Policy Review PDP WG
by ICANN Policy Calendar July 2, 2021

July 2, 2021

Meeting: Transfer Policy Review PDP WG Date/Time: Recurring call every Tuesday at 16:00 UTC for 90 minutes, 29 June 2021 through 31 August 2021 Join the Zoom Webinar: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 Passcode: @TP/^*4wg# ALL: Before joining the call: Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> Visit the Wiki Agenda meeting page: https://community.icann.org/x/WgTpCQ Check your time zone: https://tinyurl.com/3zvakspb ONLY for Members & Alternates: * Please join via the above Zoom Webinar link and staff will promote you to Panelist * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form<https://docs.google.com/forms/d/e/1FAIpQLScXP3-H595xH4EFgaR3ydOr-1o9BLAVGUI…> to communicate who the alternate is replacing and for which period. This information will be posted to the Alternate Log-Transfer Policy Review PDP wiki page<https://community.icann.org/x/V4aUCQ>. * Members and alternates replacing members, please select Panelists and Attendees when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates (not replacing a member): Please rename your line in Zoom by adding THREE Zs “zzz” before your name, and in parentheses, (your affiliation - alternate), after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. For Audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6

1 0

Re: [GNSO-TPR] Proposed agenda for meeting #07 on Tuesday 6 July 2021 at 16.00 UTC
by policy＠bacinblack.com July 2, 2021

July 2, 2021

Hi All, Per agenda item #3 below, please find attached the TPR’s proposed project schedule for delivery of a Final Report for Phases 1A & 1B. A few highlights and comments about this: * Per PDP3.0, Working Groups are now required to submit its proposed schedule of milestones and deliverable dates to the GNSO Council as the managers of the Policy Development Process. * The intent of this requirement is to increase predictability for managing current and future policy work in the pipeline for the GNSO. This is also about increasing the accountability of the Working Group, Leadership and Staff to deliver on schedule per its charter requirements. * The proposed key milestone dates: * 16 Jun 2022 – Deliver Phase 1A Initial Report on Transfer Policy for public comment, begin Phase 1B deliberations on Change of Registrant * 14 Sep 2022 – Conclude review Phase 1A comments * 30 Mar 2023 – Deliver Phase 1B Initial Report for public comment * 28 Jun 2023 – Conclude review of Phase 1B public comments * 16 Aug 2023 – Deliver Phase 1A, 1B Final Report to the GNSO Council * Phase 2 is not in scope for this plan, but this process will be repeated when it begins. * The first page of the PDF is a summary timeline and the remaining pages contain the expanded view of tasks, duration, dependencies, and target dates. Roger and I will speak in more detail about how this schedule was developed and the assumptions that went into it. We must deliver the plan to the GNSO Council by 12 July for their acknowledgement and thus begins our commitment to this schedule. I have no expectation for members of this group to study in detail and use this project schedule regularly. It’s an eye-sore and many do not prefer Gantt charts. This is a leadership team work product to maintain an accurate representation of the WG’s efforts and schedule. To make up for this, staff will also maintain a more tactical work plan and track the WG’s action items here: https://docs.google.com/spreadsheets/d/1FunWaz3gNZl8mPi5pNKti2GsfPC_9_DTt8u…. At the conclusion of each month, staff will also produce a project package that contains a compilation of several work products for us to communicate the status and health of this project to the community. You can see an example from the EPDP-P2A, https://community.icann.org/x/dggNCQ. In the meantime, should you have questions, please feel free to ask them on the list. Thank you. B Berry Cobb GNSO Policy Consultant Principal | BAC in Black Consulting <http://bacinblack.com/> Mob: +1 (720) 839-5735 <https://twitter.com/berrycobb> <https://www.linkedin.com/in/berrycobb/> From: GNSO-TPR <gnso-tpr-bounces(a)icann.org> On Behalf Of Emily Barabas Sent: Friday, July 2, 2021 07:21 To: gnso-tpr(a)icann.org Subject: [GNSO-TPR] Proposed agenda for meeting #07 on Tuesday 6 June 2021 at 16.00 UTC Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 6 June 2021 at 16.00 UTC. Before the call, please take some time to reflect on charter questions b4, b5, and b6 and add your ideas, perspectives, and concerns as comments to the working document: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…. This will help support Tuesday’s discussion. For easy reference, the questions are: b3) The Transfer Policy currently requires registrars to provide the AuthInfo Code to the registrant within five [calendar] days of a request. Is this an appropriate SLA for the registrar’s provision of the AuthInfo Code, or does it need to be updated? b4) The Transfer Policy does not currently require a standard Time to Live (TTL) for the AuthInfo Code. Should there be a standard Time To Live (TTL) for the AuthInfo Code? In other words, should the AuthInfo Code expire after a certain amount of time (hours, calendar days, etc.)? b5) Should the ability for registrants to request AuthInfo Codes in bulk be streamlined and codified? If so, should additional security measures be considered? An additional email will follow with materials to support agenda item 3 regarding the WG work plan. Kind regards, Emily, Julie, Caitlin, and Berry Transfer Policy Review Phase 1 - Meeting #07 Proposed Agenda Tuesday 6 July 2021 at 16.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 3. Work Plan (15 minutes) 4. Continued discussion of AuthInfo Codes: Charter Questions B3, B4, and (time permitting) B5 (60 minutes) - “Live” version of Working Document: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…. Archive of earlier versions: https://community.icann.org/x/e4P8CQ 6. AOB (5 minutes) - Next meeting: 13 July 2021 @ 16.00 UTC Emily Barabas Policy Manager, GNSO Policy Development Support Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org <http://www.icann.org/>

1 0

Re: [GNSO-TPR] Proposed agenda for meeting #07 on Tuesday 6 July 2021 at 16.00 UTC
by Emily Barabas July 2, 2021

July 2, 2021

Correction to the below -- the upcoming meeting is (of course) 6 JULY 2021. From: Emily Barabas <emily.barabas(a)icann.org> Date: Friday, 2 July 2021 at 13:20 To: "gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> Subject: Proposed agenda for meeting #07 on Tuesday 6 July 2021 at 16.00 UTC Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 6 July 2021 at 16.00 UTC. Before the call, please take some time to reflect on charter questions b4, b5, and b6 and add your ideas, perspectives, and concerns as comments to the working document: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…. This will help support Tuesday’s discussion. For easy reference, the questions are: b3) The Transfer Policy currently requires registrars to provide the AuthInfo Code to the registrant within five [calendar] days of a request. Is this an appropriate SLA for the registrar’s provision of the AuthInfo Code, or does it need to be updated? b4) The Transfer Policy does not currently require a standard Time to Live (TTL) for the AuthInfo Code. Should there be a standard Time To Live (TTL) for the AuthInfo Code? In other words, should the AuthInfo Code expire after a certain amount of time (hours, calendar days, etc.)? b5) Should the ability for registrants to request AuthInfo Codes in bulk be streamlined and codified? If so, should additional security measures be considered? An additional email will follow with materials to support agenda item 3 regarding the WG work plan. Kind regards, Emily, Julie, Caitlin, and Berry Transfer Policy Review Phase 1 - Meeting #07 Proposed Agenda Tuesday 6 July 2021 at 16.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 3. Work Plan (15 minutes) 4. Continued discussion of AuthInfo Codes: Charter Questions B3, B4, and (time permitting) B5 (60 minutes) - “Live” version of Working Document: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…. Archive of earlier versions: https://community.icann.org/x/e4P8CQ 6. AOB (5 minutes) - Next meeting: 13 July 2021 @ 16.00 UTC Emily Barabas Policy Manager, GNSO Policy Development Support Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0

Re: [GNSO-TPR] [Ext] RE: Final Reminder - Deadline for feedback 24 June:Draft outreach document requesting early input from SO/AC/SG/Cs
by Emily Barabas July 2, 2021

July 2, 2021

Hi Barbara, Thanks for continuing the discussion on this issue. In looking again at the clarification text I shared below, and realizing that it might be helpful to frame this a little differently to explain why we are talking about “thin” Registries: The Gaining Registrar has a choice under the Transfer Policy between looking at Whois data from the Registrar of Record or the Registry. There are cases where the Gaining Registrar decides to go to the Registry rather than the Registrar of Record, even though the Registry is "thin" and displays less information than the Registrar of Record. As a result of making this choice, the Gaining Registrar does not access the necessary information to send a Gaining FOA, and proceeds with the workaround in which the Registrant manually re-enters information with the Gaining Registrar. The Registrant does not need to follow COR requirements in this scenario even if the information they enter with the Gaining Registrar is different from the information used with the Registrar of Record. Please let me know if this summary helps to clarify. Kind regards, Emily From: "Knight, Barbara" <bknight(a)verisign.com> Date: Thursday, 24 June 2021 at 18:44 To: Emily Barabas <emily.barabas(a)icann.org>, "swyld(a)tucows.com" <swyld(a)tucows.com>, "gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> Subject: [Ext] RE: [GNSO-TPR] Final Reminder - Deadline for feedback 24 June:Draft outreach document requesting early input from SO/AC/SG/Cs Hi Emily, I am fine with the clarification but still contend that for it to be accurate, you will need to change “thin” (highlighted below) to “thick” as it is my understanding that thin is intended to refer to the registry and registries that are thin do not have registrant or other contact information associated with domain names. Registrars would only be able to obtain the data from registries that are “thick”. Thanks. Regards, Barbara From: Emily Barabas <emily.barabas(a)icann.org> Sent: Wednesday, June 23, 2021 3:15 PM To: Knight, Barbara <bknight(a)verisign.com>; swyld(a)tucows.com; gnso-tpr(a)icann.org Subject: [EXTERNAL] Re: [GNSO-TPR] Final Reminder - Deadline for feedback 24 June:Draft outreach document requesting early input from SO/AC/SG/Cs Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Barbara and Sarah, Please find below a clarification regarding the scenario described in charter question d3: * Gaining Registrar allows a new customer to input the Registrant information when requesting an inbound inter-registrar transfer. The information entered by the customer does not match Registration Data available in the Whois display. * In the case of “thin” domain names, the Gaining Registrar obtains information from the Registry. These two items are interrelated and describe the situation when the Losing Registrar’s RDDS displayed the registration data at the time of transfer request, and the Gaining Registrar did not use Losing Registrar’s RDDS to verify the authenticity of a transfer request, but obtained information from the Registry RDDS output and therefore registration data was not available to send a Gaining FOA (when cases involve “thin” domain names, Registry RDDS does not list the Registrant data, while Registrar RDDS still displays it). Section I.A.1.1. of the Transfer Policy states, “Registrars may use Whois data from either the Registrar of Record or the relevant Registry for the purpose of verifying the authenticity of a transfer request; or from another data source as determined by a consensus policy.” It appeared the Gaining Registrar could use either the Registrar or Registry output. This was also relevant because the Gaining Registrar would then not be required to follow COR requirements because Appendix G Section 1.2 states if the Gaining Registrar is unable to gain access to then-current Registration Data for a domain name subject of a transfer, “Registrant MUST independently re-enter Registration Data with the Gaining Registrar. In such instance, the Gaining Registrar is not REQUIRED to follow the Change of Registrant Process as provided in Section II.C. of the Transfer Policy.” Because there is no requirement in the Transfer Policy that requires a Gaining Registrar to obtain registration data from the Losing Registrar, ICANN Compliance is unable to point out a specific section when the Gaining Registrar does not apply the COR process even when the Registration Data is available from the Losing Registrar’s RDDS output. Kind regards, Emily From: GNSO-TPR <gnso-tpr-bounces(a)icann.org<mailto:gnso-tpr-bounces@icann.org>> on behalf of "Knight, Barbara via GNSO-TPR" <gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>> Reply to: "Knight, Barbara" <bknight(a)verisign.com<mailto:bknight@verisign.com>> Date: Wednesday, 23 June 2021 at 20:38 To: "swyld(a)tucows.com<mailto:swyld@tucows.com>" <swyld(a)tucows.com<mailto:swyld@tucows.com>>, "gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>" <gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>> Subject: Re: [GNSO-TPR] Final Reminder - Deadline for feedback 24 June:Draft outreach document requesting early input from SO/AC/SG/Cs I agree with Sarah’s comments relating to the questions relating to DNS. With regard to the alternative language to correct the “thin” issue, I think that we have to be careful on this one. Even in cases where the Registry holds the data relating to the registrant and admin contacts, technically, the registrar data is authoritative. Further, if there is a proxy or privacy service or the data is redacted due to privacy laws, the registry would most likely not have the underlying data. Given this, I am not sure what the answer is on how to clarify. Regards, Barbara From: GNSO-TPR <gnso-tpr-bounces(a)icann.org<mailto:gnso-tpr-bounces@icann.org>> On Behalf Of Sarah Wyld Sent: Wednesday, June 23, 2021 2:08 PM To: Roger D Carney via GNSO-TPR <gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>> Subject: [EXTERNAL] Re: [GNSO-TPR] Final Reminder - Deadline for feedback 24 June:Draft outreach document requesting early input from SO/AC/SG/Cs Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi all, I thought we had confirmed at recent meetings that transferring DNS settings is not in scope for this PDP as it was not included in the scoping paper, issues report, etc. As such, I’m concerned that if we add in questions on that topic to our request for early input it will confuse responders and set inaccurate expectations about what is in scope here. I do agree with the comment on point d4, "thin” is out of place. Perhaps it could say “In cases where the Registry holds registration data, the Gaining Registrar obtains information from the Registry.” Thanks, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/her swyld(a)tucows.com<mailto:swyld@tucows.com> +1.416 535 0123 Ext. 1392 [cid:image001.png@01D7683D.15EFCD90] From: Steve Crocker<mailto:steve@shinkuro.com> Sent: June 23, 2021 1:54 PM To: Emily Barabas<mailto:emily.barabas@icann.org> Cc: gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org> Subject: Re: [GNSO-TPR] Final Reminder - Deadline for feedback 24 June:Draft outreach document requesting early input from SO/AC/SG/Cs Emily, et al, I have added some words related to coordination of DNS operations during a change of registrar. I was not able to edit the document directly via Google docs, so I downloaded the document and inserted changes. Tracking is turned on. I inserted my suggested changes between "c" and "d" so I used the letter x. I believe this belongs in this phase, 1a, because phase 1b looks like it's focused specifically on a change of registrant. The question of coordination of DNS operation could be relevant during a change of registrant but will be much more likely to be relevant during a change of registrar without a change of registrant. Thanks, Steve On Wed, Jun 23, 2021 at 6:08 AM Emily Barabas <emily.barabas(a)icann.org<mailto:emily.barabas@icann.org>> wrote: Dear Working Group members, Tomorrow, Thursday, 24 June is the last day to suggest edits to the outreach letter to SO/AC/SG/Cs: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… [drive.google.com]<https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> As a point of clarification, the current task is to make sure that the text of the letter is acceptable and determine if any additional questions need to be asked of SO/AC/SG/Cs as part of this request for input beyond the listed charter questions. Once the WG has finalized the letter, it will be sent to SO/AC/SG/Cs who will have approximately five weeks to respond. Please feel free to reach out with any questions. Kind regards, Emily, Julie, Caitlin, and Berry From: GNSO-TPR <gnso-tpr-bounces(a)icann.org<mailto:gnso-tpr-bounces@icann.org>> on behalf of Emily Barabas <emily.barabas(a)icann.org<mailto:emily.barabas@icann.org>> Date: Monday, 21 June 2021 at 11:39 To: "gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>" <gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>> Subject: [GNSO-TPR] Reminder - Deadline for feedback 24 June: Draft outreach document requesting early input from SO/AC/SG/Cs Dear Working Group members, As a reminder, if you would like suggest additional questions to include in the request for early input to SO/AC/SG/Cs, please add these questions to the Google Doc no later than this Thursday, 24 June: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… [drive.google.com]<https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> Kind regards, Emily, Julie, Caitlin, and Berry From: Emily Barabas <emily.barabas(a)icann.org<mailto:emily.barabas@icann.org>> Date: Tuesday, 8 June 2021 at 19:28 To: "gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>" <gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>> Subject: Deadline for feedback 24 June: Draft outreach document requesting early input from SO/AC/SG/Cs Dear Working Group members, As discussed on today’s call, the leadership team has prepared a draft outreach document to send to SO/AC/SG/Cs requesting early input on the topics within the TRP PDP’s charter. You can find the draft here: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… [drive.google.com]<https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> If you would like to propose edits to the text or would like to suggest additional questions for early input to include in the document, please add comments directly into the Google Document. If anyone is unable to use Google Drive, Word and PDF versions are attached for reference. You can also use Google Doc comments to provide feedback on questions or edits that have been proposed by other members. Please provide your input no later than 24 June 2021. The Working Group call on 29 June will be focused on finalizing this document for submission to the SO/AC/SG/Cs. Kind regards, Emily, Julie, Caitlin, and Berry Emily Barabas Policy Manager, GNSO Policy Development Support Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org [secure-web.cisco.com]<https://urldefense.com/v3/__http:/secure-web.cisco.com/1oS_8dAlACq_cWvUqN4f…> _______________________________________________ GNSO-TPR mailing list GNSO-TPR(a)icann.org<mailto:GNSO-TPR@icann.org> https://mm.icann.org/mailman/listinfo/gnso-tpr [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1ILLIILxFHVpSlgFinN…>

2 1

Proposed agenda for meeting #07 on Tuesday 6 June 2021 at 16.00 UTC
by Emily Barabas July 2, 2021

July 2, 2021

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 6 June 2021 at 16.00 UTC. Before the call, please take some time to reflect on charter questions b4, b5, and b6 and add your ideas, perspectives, and concerns as comments to the working document: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…. This will help support Tuesday’s discussion. For easy reference, the questions are: b3) The Transfer Policy currently requires registrars to provide the AuthInfo Code to the registrant within five [calendar] days of a request. Is this an appropriate SLA for the registrar’s provision of the AuthInfo Code, or does it need to be updated? b4) The Transfer Policy does not currently require a standard Time to Live (TTL) for the AuthInfo Code. Should there be a standard Time To Live (TTL) for the AuthInfo Code? In other words, should the AuthInfo Code expire after a certain amount of time (hours, calendar days, etc.)? b5) Should the ability for registrants to request AuthInfo Codes in bulk be streamlined and codified? If so, should additional security measures be considered? An additional email will follow with materials to support agenda item 3 regarding the WG work plan. Kind regards, Emily, Julie, Caitlin, and Berry Transfer Policy Review Phase 1 - Meeting #07 Proposed Agenda Tuesday 6 June 2021 at 16.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 3. Work Plan (15 minutes) 4. Continued discussion of AuthInfo Codes: Charter Questions B3, B4, and (time permitting) B5 (60 minutes) - “Live” version of Working Document: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…. Archive of earlier versions: https://community.icann.org/x/e4P8CQ 6. AOB (5 minutes) - Next meeting: 13 July 2021 @ 16.00 UTC Emily Barabas Policy Manager, GNSO Policy Development Support Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0