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

Notes and action items - TPR WG Meeting #31 - 11 Jan 2022
by Julie Hedlund 11 Jan '22

11 Jan '22

Dear TPR WG Members, Please find below the notes and action items from today’s call. The next TPR WG meeting will be on Tuesday, 18 January 2022 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: 1. TAC Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…> (beginning on p. 15) Recommendation #5: ACTION ITEM: Delete Recommendation #5. Recommendation #10: ACTION ITEM: Change the first sentence to: “The Working Group confirms that the Transfer Policy should continue to require Registrars to [set the TAC at the Registry] and….” Insert new text in brackets. Recommendation #11.1: ACTION ITEM: Revise the language to be more precise, as in “11. 1: A standard Time to Live (TTL) for the TAC be [14 calendar days from the time it is [set] at the Registry]…” Insert new text in brackets. 2. Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?…> (beginning on p. 14) Recommendation 13: ACTION ITEMS: 1. 13.2: Delete it. 2. 13.3: Add two new bullet points: -- Date and time that the TAC was generated and information about when the TAC will expire. -- If the TAC has not been provided via another method, this communication will include the TAC. Recommendation #14: ACTION ITEMS: 1. Use “Losing Registrar” instead (with footnote explaining that we mean the Registrar of Record at the time of the transfer request). 2. Use 24 hours as the timing. Transfer Policy Review Phase 1 - Meeting #31 Tuesday 11 January 2022 at 16:00 UTC 1. Roll Call & SOI Updates: No updates provided. 2. Welcome & Chair updates (5 minutes): No updates provided. 3. Second reading: TAC and FOA (45 minutes) TAC Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…> (beginning on p. 15) Recommendation #3: Removed “from time-to-time”. Recommendation #5: * Last week talked about removing recommendation #5. Assume that it is no longer valid and remove it. * ACTION ITEM: Delete Recommendation #5. Additional Candidate Recommendation xx: Keep as a placeholder for now. Recommendation #6: Continue with the new version. Recommendation #9: * A couple of edits to make it more clear that the TAC is only used once. * Revisit when we talk about bulk transfers. Recommendation #10: ACTION ITEM: Change the first sentence to: “The Working Group confirms that the Transfer Policy should continue to require Registrars to [set the TAC at the Registry] and….” Insert new text in brackets. Recommendation #11.1: * 11.1 is okay and keep the 14 calendar days – consider whether hours makes more sense. From when it is provisioned at the registry. But the registry isn’t actually doing it – it’s the registrar. The registry is only accepting the TAC. It is when the registry hashes and saves it to the record when the 14 days start. Could say, “set at the registry” and make the change in recommendation 10 as in 6.2. TTL starts when it is set at the registry. * ACTION ITEM: Revise the language to be more precise, as in “11. 1: A standard Time to Live (TTL) for the TAC be [14 calendar days from the time it is [set] at the Registry]…” Insert new text in brackets. Recommendation 11.2: * 11.2 there was a lot of discussion around the purpose. Leave it as is for now. * For 11.2, second bullet “After a period of less than 14 days by agreement by the Registrar of Record and the RNH?” Is it possible to specify what the agreement might be? * Not sure why we have 11.2. Think we are trying to codify what can happen today and we want to continue the ability to set the TAC to null. * Think we want to set out rules around resetting the TAC so that a registrar can't reset it so often it becomes impossible to transfer the domain. * That agreement could be part of your registration policy, indicating pre-determined reasons to reset a TAC. * Sections 3.7 and 3.8 of current policy set out why a transfer can be denied. Could be reasons to enable a reset of the TAC. Useful to review when we talk about NACKing. * If we leave it with just the first bullet, is that sufficient? Let’s keep both now and revisit in the NACK discussion. Think we need it in case of evidence of fraud. * Is the RNH and Registrar agreement a case where a circumstance arises and then it has to be agreed to at that time? It would need to be prior to being set to null. It should be that the RNH can ask for it at any time. Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?…> (beginning on p. 14) Recommendation 12: We are good with the current language with the footnote. Recommendation 13: * The Registrar of Record will have to maintain who that was at that point in time. * No objections to “10 minutes” for the timing. Recommendations 13.2 and 13.3: * Should we had a TTL? * We don’t say that the TAC is provided, but we assume it? * See 6.3: When the Registrar of Record provides the TAC to the RNH or their designated representative, the Registrar of Record MUST also provide information about when the TAC will expire.]. Makes sense then to also include this in 13.3. * Reseller could be the designated representative. * If it’s a combined communication, is it necessary to say when the TAC was provided? * It’s almost always available via control panel. * There are registrars that only use the Registry interface. How will this work for these? * If registrars use a registry interface for transfers the question pops up how do they send the FOA? As the registry does not trigger such a process.] * Do we care if the Registrar of Record is providing the TAC via control panel? Either way we have to send an email. * Maybe “control panel” isn’t the right terminology since it could be via other methods. * What if we just say that the Registrar of Record…has to include the TAC if it has not be provided by another method, in the Notification of TAC Provision. * Maybe delete the first sentence in 13.2: “[If the Registrar of Record provides the TAC viais provided in the control panel, this notification must be provided to the RNH using a separate method of communication other than the control panel.] * Consider for bullet 3 under 13.3, perhaps include a timeframe? * Should we get rid of 13.2? Not sure we need it. Seems to be generate agreement to delete it. * ACTION ITEMS: * In 13.2: Delete it. * In 13.3: Add two new bullet points: * Date and time that the TAC was generated and information about when the TAC will expire. * If the TAC has not been provided via another method, this communication will include the TAC. Recommendation #14: ACTION ITEMS: 1. Use “Losing Registrar” instead (with footnote explaining that we mean the Registrar of Record at the time of the transfer request. 2. Use 24 hours as the timing. Recommendation #14.1, 14.2, 14.3: * On 14.3, first bullet: Waiting to hear from the RySG on the feasibility of providing the IANA ID. * Not sure that the benefit of including the IANA ID or Rr name outweighs the work to do so. 4. AOB (5 minutes) * Next call: Tuesday 18 January 2021 at 16:00 UTC

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 11 January 2022
by Julie Bisland 11 Jan '22

11 Jan '22

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 11 January 2022 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/a4HOCg> (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

**On in 13 minutes** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 11 January 2022 at 16:00 UTC
by Julie Bisland 11 Jan '22

11 Jan '22

**On in 13 minutes** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 11 January 2022 at 16:00 UTC for 90 minutes. Zoom Room 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/a4HOCg * Check your time zone: https://tinyurl.com/4crnxp8v [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/4crnxp8v__;!!PtGJab4!uFNSMBa…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking 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): 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

**REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 11 January 2022 at 16:00 UTC
by Julie Bisland 10 Jan '22

10 Jan '22

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 11 January 2022 at 16:00 UTC for 90 minutes. Zoom Room 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/a4HOCg * Check your time zone: https://tinyurl.com/4crnxp8v [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/4crnxp8v__;!!PtGJab4!uFNSMBa…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking 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): 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

Proposed agenda for meeting #31 on Tuesday 11 January 2021 at 16:00 UTC
by Emily Barabas 07 Jan '22

07 Jan '22

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 11 January 2021 at 16:00 UTC. Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #31 Proposed Agenda 1. Roll Call & SOI updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 1. Second reading: TAC and FOA (45 minutes) * TAC Working Document<https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…> (beginning on p. 15) * Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?…> (beginning on p. 14) * Gaining FOA Working Document<https://docs.google.com/document/d/1QOCzbLh7w4hdijpAsg6_lybddr0nlsFDcWjdz5e…> (beginning on p. 16) 2. 60-day post domain registration lock and post domain transfer lock (30 minutes) * See Parking Lot<https://docs.google.com/document/d/1e4hwyxKTx2JFROQ0qpqm_KREHIuZqIugRlzl_gY…> document for high-level notes from previous WG discussions on this topic 3. AOB (5 minutes) * Next call: Tuesday 18 January 2021 at 16:00 UTC

1 0

TPR-P1 // 31 Dec 2021 Project Package
by Berry Cobb 06 Jan '22

06 Jan '22

Dear WG, Please find a link below to project package for the TPR-P1 PDP (30 Dec 2021). This package is a snap-shot at the close of each month and developed by the leadership team to report on the working group’s activities and status of the project. It is also distributed to the GNSO Council to keep them informed as managers of the PDP. The package is deposited on the wiki so that we can track access statistics. Link: https://community.icann.org/x/MQDQCQ 1. Page 01 – Summary dashboard 2. Page 02 – Project Sitrep – an extract from the Council’s Project List 3. Page 03,4 – Group roster 4. Page 05 – Work and activity metrics 5. Page 06,7 – Group attendance for plenary meetings 6. Page 08 – Project Plan, Gantt chart 7. Page 09 – Work plan & Action items for the period Key points: * The WG is proceeding according to plan against the charter topics/questions. Please let us know if you have questions. Thank you. B Berry Cobb Policy Development - Portfolio Manager Internet Corporation for Assigned Names and Numbers (ICANN) berry.cobb(a)icann.org

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 11 January 2022 at 16:00 UTC
by Julie Bisland 04 Jan '22

04 Jan '22

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 11 January 2022 at 16:00 UTC for 90 minutes. Zoom Room 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/a4HOCg * Check your time zone: https://tinyurl.com/4crnxp8v ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking 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): 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

Post Call | Transfer Policy Review PDP WG | Tuesday, 04 January 2022
by Julie Bisland 04 Jan '22

04 Jan '22

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 04 January 2022 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/aYHOCg> (attendance included) and the GNSO Master calendar<https://gnso.icann.org/en/group-activities/calendar/2022>. 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

Notes and action items - TPR WG Meeting #30 - 04 Jan 2022
by Julie Hedlund 04 Jan '22

04 Jan '22

Dear TPR WG Members, Please find below the notes and action items from today’s call. The next TPR WG meeting will be on Tuesday, 11 January 2022 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items -- See: TAC Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…> Recommendation 3: ACTION ITEM: WG to suggest/comment on the current language and suggest changes if any. Beth Bacon volunteered also to consult with the RySG. WG members to review the RFC at: https://datatracker.ietf.org/doc/rfc9154/ Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer. Recommendation 5: ACTION ITEM: WG members to review the recommendation and ask whether it helps to answer any of the charter questions or address a security issue. Recommendations 6 and 7: ACTION ITEM: WG members to provide suggestions for requirements for the one-way hash and Beth Bacon to use that information to consult with the RySG. WG members to review and comment on the suggested new wording combining recommendations 6 and 7. Recommendation 9: ACTION ITEM: Revise the recommendation to say that “The Working Group recommends that the TAC [MUST be used no more than once per domain name].” New text in brackets. Recommendation 11: ACTION ITEM: WG members to review 11.2 and consider whether to comment or suggest changes, and revisit at the next meeting. Transfer Policy Review Phase 1 - Meeting #30 Tuesday 04 January 2022 at 16:00 UTC 1. Roll Call & SOI Updates: * Kristian Ormen: Updating SOI to reflect changing jobs to ccNSO from the Registrar Stakeholder Group. Not sure when his replacement will join the TPR PDP WG 2. Welcome & Chair updates (5 minutes): No updates provided. 3. Second reading: TAC and FOA (45 minutes) TAC Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…> (beginning on p. 15) Recommendation 3: * Still looking for suggestions for revised language. * Should we be looking for a standard? Problem when all of the TLDs switch to backends. Then have to update to new requirements set by the registry. Any TLD can set any requirement if there is no standard. Better if there is a standard for all TLDs. * Could at least set bounds – but need to get wording that is consistent across all TLDs but allows flexibility. Don’t need to get more specific, or maybe the IRT can work out the details. * Re: wording about ICANN changing the requirements and concerns if the requirement is a policy, then there needs to be a policy making process, or at least involving the contracted parties. * Would like to go back to the registries to see if there is a technical reason to allow some flexibility. Beth Bacon volunteered to take this question back to the RySG. * Challenge to find some balance – a consensus policy recommendation can only be changed through a PDP. Not sure that was the intent for a purely technical requirement. Should be more prescriptive to make it easier for the IRT, but also to word it so that ICANN can make the changes. * Not sure we need “from time to time”. Reads more smoothy without it. Action is to delete it. (DONE) * Add “in collaboration with the Registrar and Registry Stakeholder Groups” for both mentions of ICANN Org. But might be helpful to better understand what “collaboration” means in this context and include then in the recommendation. The community would in any case be involved in setting the standards through the IRT. Would there be an IRT to update the standard too? * Would it not be better for changes to the standards happen via the IETF? Need to take a look at the RFCs relating to the TAC. Don’t know if any standards on the TAC at this time. Not sure the IETF is the best place. This there is a secure AuthInfo Code standard already out there. Need to check. * See the draft RFC at: https://datatracker.ietf.org/doc/rfc9154/ Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer – Seems to have a lot of what we are discussing. Maybe the contracted parties should review it. Recommendation 3: ACTION ITEM: WG to suggest/comment on the current language and suggest changes if any. Beth Bacon volunteered also to consult with the RySG. WG members to review the RFC at: https://datatracker.ietf.org/doc/rfc9154/ Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer. Recommendation 5: * These notifications need to be subject to standard EPP poll messages. * In general, don’t see how the notification is of any value. Think the recommendation in 5.2 will be exploited. Would be better if the registry also informs ICANN compliance. * Looking at 5.1 the notification sounds good on paper – any attacker could easily figure out how to stymie the notifications via DDoS. * Maybe need to make the investigation requirement more clear in 5.2. * Step back and look at the purpose of these requirements – operational goals. Think about if we were to remove this recommendation, would there be a gap in the goals of this PDP and the transfer policy? Consider whether this needs to stay in. * This seems to be more of an operational/user experience concept. Does it help answer the charter question? Does it address something that nothing else is resolving? Recommendation 5: ACTION ITEM: WG members to review the recommendation and ask whether it helps to answer any of the charter questions or address a security issue. [Additional Candidate Recommendation xx: If a Gaining Registrar requests a transfer and an inter-registrar transfer lock is in place, the transfer must not proceed.] * Question: Is this a requirement, or just a statement? Answer: The discussion around this was that when this occurs there could be different locks for different reasons and it’s up to the registrar of record (losing registrar) to resolve those issues. * There is an educational purpose – for the registrants to understand the different types of locks. * Is this useful – does it serve a purpose? * Is this overly broad? Could be used to block transfers. * This might be another case when we take a step back and ask what we are trying to achieve with a recommendation on this item. * Seems that we should park this one and see if we address it in another way. * We will come back to this on the 60-day lock discussion. Recommendations 6 and 7: * Discussion with leadership about whether to condense 6 and 7 in a logical manner. See revised suggested combination text. * Question: We set requirements around the TAC, but not on the one-way hash? Answer: That is true. Don’t know if we need to do so. * Maybe need to set some minimum level for the hash. * Could Beth Bacon go back to the registries to see if they have any comment on whether we need to set parameters for the hash. * If there are standards for the one-way hash it would be helpful if they could be included in the document. If Kristian or Theo could provide it. * 6.2 appears to be addressed by RFC9154. ACTION ITEM: WG members to provide suggestions for requirements for the one-way hash and Beth Bacon to use that information to consult with the RySG. WG members to review and comment on the suggested new wording combining recommendations 6 and 7. Recommendation 8: * Make sure the language is consistent with current ICANN policy, without referring to specifics. Do we need to point to the Temp Spec? Not sure if this recommendation is necessary. Recommendation 9: * Why do we have “may” instead of “MUST”? Change to “MUST” to be consistent with the rest of the recommendation? * Trying to say that you don’t want the same TAC for multiple domain names. * Could say “MUST be used no more than once”. * Could be problematic if the TAC is already used. Could cause operational issues. Don’t think it means the uniqueness, but per that domain – one time use only. * Maybe add “per domain name transfer”? Look at language we used elsewhere. * Prefer a requirement that the TAC needs to be randomly generated – think that goes back to recommendation 3 and the syntax of the TAC as well as the RFC. But perhaps that isn’t enough? * Seems we are saying that the registrar of record generates the TAC – check to make sure that is clear and also with reference to the uniqueness. * Definition of designated representative would be helpful. Some registrars or resellers may add provisions in the registration agreement forcing the RNH to agree that the account holder or the reseller may be a designated representative. Bearing in mind the fact that many registrants do not carefully read the registration agreements/Terms of Service before signing, this may lead to more unauthorized transfer complaints. ACTION ITEM: Revise the recommendation to say that “The Working Group recommends that the TAC [MUST be used no more than once per domain name].” New text in brackets. Recommendation 11: * Staff have suggested alternative language and added a footnote. * Drop “retain the ability”? Sounds like they MAY set the tac to null in those cases, rather than MAY be able to do so. * Think what we were trying to do was to allow a registrar and registrant to agree on automatic nulling. * RFC 9154 has information about TTL – that there is no current definition; flexibility on proprietary registrar criteria. * We used 120 hours for sending the TAC to the RNH, should we convert this to hours? Sound like 14 days is agreeable. Recommendation 11: ACTION ITEM: WG members to review 11.2 and consider whether to comment or suggest changes, and revisit at the next meeting. 4. AOB (5 minutes): Next call: Tuesday 11 January 2021 at 16:00 UTC

1 0

**On in 13 minutes** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 04 January 2022 at 16:00 UTC
by Julie Bisland 04 Jan '22

04 Jan '22

**On in 13 minutes** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 04 January 2022 at 16:00 UTC for 90 minutes. Zoom Room 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/aYHOCg * Check your time zone: https://tinyurl.com/sb3srr8b [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/sb3srr8b__;!!PtGJab4!qEXiv7a…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above and staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking 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): 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