January 2023 - GNSO-TPR - lists.icann.org

Post Call | Transfer Policy Review PDP WG | Tuesday, 31 January 2023
by Devan Reed Jan. 31, 2023

Jan. 31, 2023

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 31 January 2023 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/I4w-DQ> (attendance included) and the GNSO Master calendar<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance * Audio recording * Zoom recording (including audio, visual, rough transcript, and chat.) * 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, Devan

1 0

Notes and action items - TPR WG Meeting #79 - 31 January 2023 at 16:00 UTC
by Julie Hedlund Jan. 31, 2023

Jan. 31, 2023

Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be in two weeks on Tuesday, 14 February 2023 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: Actions from Meeting on 31 January: 1. Re: Recommendation 13 small group work on TTL enforcement: https://docs.google.com/document/d/1Wq4dHcIFR5XogoutSh0klkCyhZFUlS1z7cl2ilv… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1Wq4dHcIFR5Xo…> 1) Rick Wilhelm to post to the list thoughts about the proposal of the registry for flexibility to shorten the TTL. 2) WG members to suggest language, if any, relating to disallowing long-lived TACs. 2. Re: Recap of Phase 1B deliberations, including touchpoints for Phase 2 topics, WG members should review the document at: https://docs.google.com/document/d/1sVvWazAu6TR-W191wOO_ZYKmZxGP7-lxB_AxaIf… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1sVvWazAu6TR-…>. Notes: Transfer Policy Review - Meeting #79 Proposed Agenda 31 January 2023 1. Roll Call & SOI updates 2. Welcome and Chair Updates * Today we are wrapping up deliberations for now on Phase 1A topics and then briefly recapping Phase 1B deliberations to date before starting Phase 2 discussions the week after next. * There will be no call next week on 07 February. * We'll share the Project Change Request with the WG this week and submit to Council on Monday. * The next redline of the Initial Report is coming out soon. Folks can be reviewing that in the background while we get started on Phase 2 deliberations. There will be a few things you haven’t seen before – ensuring every recommendation has a rationale and making them consistent, among other things. Not recommendation text, but still important, so please review that new text too. * Any updates from the threat vectors small team? Not hearing any, staff will take a first stab at providing some placeholder text and we encourage comments/edits from the small team. 3. Proposed revisions based on 24 January call (Recommendations 2, 16, 17, and new Recommendation yy on record keeping) and continued discussion of outstanding questions on transfer confirmation/Losing FOA (Recommendation 2, see inline for discussion questions): https://docs.google.com/document/d/10lRyhg9t8vY_HGB5GsCMIQmmafnBecuNoQA5Dja… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/10lRyhg9t8vY_…> * Came to some convergence last week. We will summarize: * Record keeping: * New Draft Language: “The working group acknowledges that with the elimination of the Gaining FOA requirement, the AuthInfo code becomes even more important for the transaction and for any Compliance investigation related to it. The working group further agrees that it is important to properly document and retain all notifications related to the transfer sent by the Losing Registrar, so that information about such records can be sent to ICANN Compliance when investigating a complaint, as needed. Therefore, the working group is providing a specific recommendation on requirements regarding the retention of these records and provision to ICANN upon reasonable notice.” * Preliminary Recommendation yy: The Registrar MUST retain all records pertaining to the provision of the TAC to a Registered Name Holder, as well as all notifications sent per the requirements under this Transfer Policy. At a minimum, the records retained in accordance with this section shall MUST document the date/time and, means and contact(s) to whom the TAC and notifications are sent. The Registrar MUST shall maintain these records for the shorter of 15 months or the longest period permitted by applicable law, and during such period, MUST provide such records to ICANN upon reasonable notice. Rationale for Preliminary Recommendation yy: This recommendation seeks to ensure that the necessary information is available to ICANN org in the case of a Compliance investigation related to an inter-Registrar transfer. The 15-month retention period specified in this recommendation is consistent with requirements anticipated to be included in the Registration Data Policy. * Question: Is this doable for registrars? Answer: Most registrar do this anyway. They are already retaining records concerning AuthInfo code provision. Can’t provide customer support without logging. Although this type of record keeping shouldn’t be taken as a given. * Recommendations 16 & 17: Minor adjustments to clarify that the new 30-day requirement would replace any existing 60-day requirements. Also a suggestion to include the number of hours and the word “calendar”: * Preliminary Recommendation 16: The Registrar MUST restrict the RNH from transferring a domain name to a new Registrar within 30 calendar days / 720 hours of the initial registration date. To the extent that a Registry and/or Registrar has an existing policy and/or practice of restricting the RNH from transferring a domain name to a new Registrar for a different period of time following initial registration, all policies and practices MUST be updated to be consistent with this new requirement. * Preliminary Recommendation 17 : The Registrar MUST restrict the RNH from transferring a domain name to a new Registrar within 30 calendar days / 720 hours of the completion of an inter-Registrar transfer. To the extent that a Registry and/or Registrar has an existing policy and/or practice of restricting the RNH from transferring a domain name to a new Registrar for a different period of time following an inter-Registrar transfer, all policies and practices MUST be updated to be consistent with this new requirement. * Some support but not enough to put into the recommendations right now. Pick back up in Phase 2. * Recommendation 2 – new text: “[The timeframe of five (5) calendar days specified in section I.A.3.5 of the policy MUST be expressed in both calendar days and hours, “Failure by the Registrar of Record to respond within five (5) calendar days / 120 hours to a notification from the Registry regarding a transfer request will result in a default "approval" of the transfer.”] [As with the new notifications described in Preliminary Recommendations 3 and 4, the working group recognizes that this notification MAY be sent via email, SMS, or other secure messaging system. These examples are not intended to be limiting, and it is understood that additional methods of notification MAY be created that were not originally anticipated by the working group.]”. This is a new item for discussion. * “Or other secure messaging system” – some would argue that mail is not secure. May want to tweak that language. Or drop the word “secure”. * There's a mixed sentiment on this - the FOA that provides NAK agency to the RnH being furnished out of band to a possibly compromised system. If the API is compromised - the FoA can be bypassed. * I think we are talking about delivering payload via the SMS. Not sure these are the same situations. Don’t want to suggest that SMS is secure. * It sounds like the language in a footnote for Recs 3 and 4 – WG members provide feedback on that footnote/language. * Question: whether this group want to make changes to the mechanism for delivering the TAC in the losing FOA in the status quo. Is the status quo correct or not? If there is no momentum to change the status quo on the Losing FOA --- then this language would only be included for Recs 3 and 4, and not for Rec 2. * No concerns about the change to hours and calendar days. 4. Recommendation 13 small group work on TTL enforcement: https://docs.google.com/document/d/1Wq4dHcIFR5XogoutSh0klkCyhZFUlS1z7cl2ilv… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1Wq4dHcIFR5Xo…> New language: * For accuracy: if the sponsoring Registrar is required to expire the TAC by updating it to null, there is a possibility that at the time when the TAC is set to expire, either the Registrar or Registry systems have an outage (or there is a communication interruption), this means that the TAC expiration would be delayed until the transaction could be completed, opening a window for possible usage of a TAC that the sponsoring registrar had deemed expired. * For consistency: having a centralized approach at the registry allows prospective gaining registrars to know that every TAC will be expired at 14 days regardless of the sponsoring/provisioning registrar * For security: having every TAC in a registry have a maximum lifetime that is enforced consistently prevents the existence of any long-lived TAC which could be used at part of an unauthorized or unintended inter-registrar transfer Discussion: * New rationale --- having the timeout at the registry is more accurate. * Sarah Wyld may have some minor changes. * This has support from the RySG. * Re: “must be valid for” enforces a minimum, but not a maximum. So maybe we need to tweak the wording. This also doesn’t seem to allow a registry to have a standard less than 14 days. * Also update to make consistent with use of hours. * What if we say “the TAC MUST [normally] be valid for”? * Don’t think you should leave it up to the registrar to shorten that period. * The original goal was to stop love-lived TACs – not trying to prevent a minimum. * Suggestion: “The TAC TTL MUST not exceed 14 calendar days..” * Could there be a 13.1.1 – allowing the registry to shorten to a standard of less than 15 days as long as it is consistently enforced? * With small team hat on: MUST = low variation (ie no variation) - this being consistent across gTLDs is good -- altering this to "MUST not exceed" will introduce variation opportunities that will complicate integrations and customer service, which IMHO is less good. * Suggest going back to the standard of 14 days. * Why would registrar be able to shorten but not registry? This is a new concept not discussed before. * Is there a way to define which TLD Ry's would have the option to shorten it (to include .bank)? OR the suggestion is any could? * Needs to be an edit to disallow long-lived TACs – continue this discussion on the list. Note also the recommendation should be read along with the rationale that makes it clear that the TTL is no longer than 14 days. * Recap: For now for the redline use the existing language from the small team but add hours to be consistent. Also adopt the new rationale for the redline. ACTION ITEM: Re: Recommendation 13 small group work on TTL enforcement: https://docs.google.com/document/d/1Wq4dHcIFR5XogoutSh0klkCyhZFUlS1z7cl2ilv… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1Wq4dHcIFR5Xo…> 1) Rick Wilhelm to post to the list thoughts about the proposal of the registry for flexibility to shorten the TTL. 2) WG members to suggest language, if any, relating to disallowing long-lived TACs. 5. Recap of Phase 1B deliberations, including touchpoints for Phase 2 topics: https://docs.google.com/document/d/1sVvWazAu6TR-W191wOO_ZYKmZxGP7-lxB_AxaIf… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1sVvWazAu6TR-…> * Purpose is to remind everyone where we were in our discussions – a refresher. It will be a while before we go back to COR, but for homework WG members should review the document. ACTION ITEM: Re: Recap of Phase 1B deliberations, including touchpoints for Phase 2 topics, WG members should review the document at: https://docs.google.com/document/d/1sVvWazAu6TR-W191wOO_ZYKmZxGP7-lxB_AxaIf… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1sVvWazAu6TR-…> 6. AOB

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 14 February 2023
by Devan Reed Jan. 31, 2023

Jan. 31, 2023

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 14 February 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <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 <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/JYw-DQ * For other places see: https://tinyurl.com/bddt8ucr ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments 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): Rename your line by adding 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * 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, Devan

1 0

15 MINUTES | Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 31 January 2023
by Devan Reed Jan. 31, 2023

Jan. 31, 2023

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 31 January 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <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 <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/I4w-DQ * For other places see: https://tinyurl.com/ycybvka3 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/ycybvka3__;!!PtGJab4!8iX7nD7…> ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments 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): Rename your line by adding 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * 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

Proposed agenda for meeting #79 on Tuesday 31 January 2023 at 16:00 UTC
by Emily Barabas Jan. 30, 2023

Jan. 30, 2023

Dear Working Group members, Please find below the proposed agenda for the next meeting scheduled to take place on Tuesday 31 January at 16:00 UTC. Kind regards, Caitlin, Berry, Julie, and Emily Transfer Policy Review - Meeting #79 Proposed Agenda 31 January 2023 1. Roll Call & SOI updates 2. Welcome and Chair Updates 3. Proposed revisions based on 24 January call (Recommendations 2, 16, 17, and new Recommendation yy on record keeping) and continued discussion of outstanding questions on transfer confirmation/Losing FOA (Recommendation 2, see inline for discussion questions): https://docs.google.com/document/d/10lRyhg9t8vY_HGB5GsCMIQmmafnBecuNoQA5Dja… 4. Recommendation 13 small group work on TTL enforcement: https://docs.google.com/document/d/1Wq4dHcIFR5XogoutSh0klkCyhZFUlS1z7cl2ilv… 5. Recap of Phase 1B deliberations, including touchpoints for Phase 2 topics: https://docs.google.com/document/d/1sVvWazAu6TR-W191wOO_ZYKmZxGP7-lxB_AxaIf… 6. AOB

1 0

REMINDER | Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 31 January 2023
by Devan Reed Jan. 30, 2023

Jan. 30, 2023

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 31 January 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <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 <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/I4w-DQ * For other places see: https://tinyurl.com/ycybvka3 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/ycybvka3__;!!PtGJab4!8iX7nD7…> ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments 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): Rename your line by adding 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * 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

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 31 January 2023
by Julie Bisland Jan. 24, 2023

Jan. 24, 2023

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 31 January 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <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 <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/I4w-DQ * For other places see: https://tinyurl.com/ycybvka3 ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments 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): Rename your line by adding 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * 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

Post Call | Transfer Policy Review PDP WG | Tuesday, 24 January 2023
by Julie Bisland Jan. 24, 2023

Jan. 24, 2023

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 24 January 2023 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/IYw-DQ> (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 * Audio recording * Zoom recording (including audio, visual, rough transcript, and chat.) * 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

Notes and action items - TPR WG Meeting #78 - 24 January 2023 at 16:00 UTC
by Julie Hedlund Jan. 24, 2023

Jan. 24, 2023

Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be on Tuesday, 31 January 2023 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: Ongoing Actions: 1. Small Team on Recommendation 13 TTL: Provide revised rationale. 2. Small Team on threat vectors: Provide language. Actions from Meeting on 24 January: 1. Re: Recordkeeping: Staff will draft a standalone recommendation with 15 months to insert into the next redline. 2. Re: Recommendation 17: WG members to take the language and suggested revisions back to their groups and provide to the WG at least informal feedback whether the proposed change is supported or not. See attached redline and screenshot. 3. Re: Recommendations 16 & 17: Staff to suggest language to include in Recommendations 16 and 17 re: 30-day restriction replacing existing restrictions (such as 60-day locks). Notes: Transfer Policy Review - Meeting #78 Proposed Agenda 24 January 2023 1. Roll Call & SOI updates 2. Welcome and Chair Updates * Need rationale from the small team on Rec 13 TTL in the next week. No update provided at this time. * Need a write up from the small team on threat vectors in the next week. No update provided at this time. 3. Input received on 21 December redline (recommendations 10-22): https://docs.google.com/document/d/1Zoh8D2GuulpIDbyqwYsfRCSJkiGpa19k02eiEE-… * No comments received. * Given no comments, we think that means that WG members are comfortable with it so that there won’t be any surprises later. 4. Proposed language from ICANN Contractual Compliance on record keeping: https://mm.icann.org/pipermail/gnso-tpr/2023-January/000740.html “Registrar shall retain all records pertaining to the provision of the TAC to a Registered Name Holder, as well as all notifications sent per the requirements under this Transfer Policy. At a minimum, the records retained in accordance with this section shall document the date/time, means and contact(s) to whom the TAC and notifications are sent. Registrar shall maintain these records for the shorter of two (2) years or the longest period permitted by applicable law, and during such period, shall provide such records to ICANN upon reasonable notice.” * Drafted in accordance with the current RAA and doesn’t prevent the Registrars from setting their own records retention policies. Discussion: * Question: Was the gTLD Registration Data policy (not yet finished the IRT) considered? I think it spoke to retention periods. Answer: This was considered, but this is open for discussion. Drafted Reg. Data policy suggests 15 months – consider aligning. * Does there need to be anything said about data processing agreements? * Seems that the text makes sense. * Confirming that staff will draft a standalone recommendation with 15 months to insert into the next redline. ACTION ITEM: Re: Recordkeeping: Staff will draft a standalone recommendation with 15 months to insert into the next redline. 5. Continued discussion on proposed redline from Small Group on Exemption for Recommendation 17 (see attached) Discussion: * Suggestions from Sarah Wyld (see attached screen shot): Changes to help clarify: “Registrar will remove the registrar lock…” and change to “fewer than 30 days” (from “less than 30 days”), add “at the Registrar’s discretion” to replace “for the purpose of an inter-registrar transfer”. * Small team: Suggest not removing “for the purpose of an inter-registrar transfer”. I think also we should keep “at the Registrar’s discretion” as well as “ClientTransferProhibited”. * At least one WG member is against the change. Disabling ability to prevent registrar-hopping. Also, dependencies on dispute discussions in future. * Note that the report uses the term “restriction” rather than “lock”. * Think it is a good point to ask why this was introduced since registrar-hopping is an important consideration and it isn’t currently tracked. Will also be interdependent with possible rollbacks in the next phase. If we define this now, will we be able to come back to it? * If we decide something later that breaks something we’ve already said we’ll have to revisit it. * No decision from the WG at this time – doesn’t seem like there is strong support at this time. Would be good to have a Stakeholder Group discussion on this and at least informal support or not. * Note that this exception would apply only post transfer. ACTION ITEM: Recommendation 17: WG members to take the language and suggested revisions back to their groups and provide to the WG at least informal feedback whether the proposed change is supported or not. See attached redline and screenshot. Additional Issues: * Question: If we create a 30-day restriction should we explicitly say that any existing 60-day restrictions would go away? Answer: Important to document – should we put language in the policy or otherwise to make this clear? * As staff understands it in today’s world most of the requirements are set, are set by varying contracted parties outside of the RA/RAA, so we need to be precise in the policy itself. * Need to specify in order to enforce. * Question: Where to put the language? Should be in the body of the recommendation. ACTION ITEM: Recommendations 16 & 17: Staff to suggest language to include in Recommendations 16 and 17 re: 30-day restriction replacing existing restrictions (such as 60-day locks). 6. Possible minor modifications to Losing FOA (see bracketed text below) Preliminary Recommendation 2: The working group did not reach agreement to eliminate or substantially change the Obligations of the Registrar of Record described in Section I.A.3.1 - I.A.3.6 of the Transfer Policy. Therefore, the working group anticipates that these requirements will largely remain in place. The working group recommends the following minor modifications: * The term [“Transfer Confirmation”] must be used in place of “Standardized Form of Authorization (FOA).” * [The [Transfer Confirmation] must include the Gaining Registrar’s IANA ID] * [The [Transfer Confirmation] must include both an opportunity for the RNH to proactively accept the transfer AND an option to cancel the transfer] * [The [Transfer Confirmation] must be provided in English and the language of the registration agreement and may also be provided in other languages] General Discussion: * Question: Also include a name in addition to IANA ID? (Many ccTLD registrars do not have an IANA ID) Could potentially include language as in Rec 14 to provide flexibility. * Concerns from Sarah re: “opportunity for the RNH to proactively accept the transfer AND an option to cancel the transfer”. Discussion on each suggestion: The term [“Transfer Confirmation”] must be used in place of “Standardized Form of Authorization (FOA).” * WG agrees. [The [Transfer Confirmation] must include the Gaining Registrar’s IANA ID]: Discussion: * Match language in Recommendation 4; name might not mean anything. The IANA ID is the only unique identifier that exists in the system. * Staff suggest changing to ““IANA ID(s) of Gaining Registrar(s) and link to ICANN-maintained webpage listing accredited Registrars and corresponding IANA IDs. If available, the name of the Gaining Registrar(s) may also be included.”” * Might want to be careful on this one – by including a name it opens up the possibility of disagreement between the two fields. Should identify a clear benefit because code will have to change. * The issue is that a poll message is issued from the registry to the registrar – as long as we define it as coming from the IANA registry there should be no confusion. * This is added information to help the RNH. * With respect to resellers, sub-resellers, etc, this is why anchoring it with what’s in the IANA registry is our only option. such is the “standard” that our system offers to us to work with. * Re: “IANA ID(s) of Gaining Registrar(s) and link to ICANN-maintained webpage listing accredited Registrars and corresponding IANA IDs. If available, the name of the Gaining Registrar(s) may also be included.” Do we need to specify that this is the name of Gaining Registrar(s) as included in the IANA database? * Make sure we correct things that have been problems, but also to suggest things that will improve security – which IANA ID will do. Just don’t require people to use it. * If we have it let’s use it. * Having it could be very helpful to registrars and registrants. * The IANA ID is already being passed around – don’t think there would be contention with “MUST”. * Going back to Recommendation 4.3 – The ID is maintained by ICANN through IANA. The requirement is for the ID and a link to the page of IDs with names. The names can come from there as well. Losing registrar has a look-up to the IANA database/registry. * See: IANA IDs https://www.iana.org/assignments/registrar-ids/registrar-ids.xhtml * Should be careful to say it comes from the “registry available at IANA”. It’s not IANA’s registry or a registry maintained by IANA. * WG agrees: Use the exact same text as in Recommendation 4.3. So same in both places. [The [Transfer Confirmation] must include both an opportunity for the RNH to proactively accept the transfer AND an option to cancel the transfer] * This would be a change from the status quo. * Make mandatory for accept AND option to cancel. * WG agrees: Stay with status quo – ACK is optional. [The [Transfer Confirmation] must be provided in English and the language of the registration agreement and may also be provided in other languages] * See 3.3 The FOA shall be communicated in English, and any dispute arising out of a transfer request, shall be conducted in the English language. Registrars may choose to communicate with the Transfer Contact in additional languages. However, the Registrar choosing to exercise such option is responsible for the accuracy and completeness of the translation into such additional non-English version of the FOA. Further, such non-English communications must follow the processes and procedures set forth in this policy. This includes but is not limited to the requirement that no Registrar shall add any additional information to the FOA used to obtain the consent of the Transfer Contact in the case of a transfer request. * WG agrees with the suggested text. Issues for the next meeting: * Format of the Losing FOA; * Should we include in the recommendation that this deadline should be expressed in hours in addition to number of days "3.5 Failure by the Registrar of Record to respond within five (5) calendar days to a notification from the Registry regarding a transfer request will result in a default "approval" of the transfer." * Do we need a recommendation that provides specific details about how, when and by whom the pending transfer status is set and removed? 7. AOB

1 0

**ON IN 2 MINUTES** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 24 January 2023
by Julie Bisland Jan. 24, 2023

Jan. 24, 2023

**ON IN 2 MINUTES** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 24 January 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <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 <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/IYw-DQ * For other places see: https://tinyurl.com/4twuefvb [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/4twuefvb__;!!PtGJab4!77Phrkp…> ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments 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): Rename your line by adding 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * 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