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

Notes and action items - TPR WG Meeting #66 - 15 November 2022 at 16:00 UTC
by Julie Hedlund Nov. 15, 2022

Nov. 15, 2022

Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be on Thursday, 17 November at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: 1. Jothan Frakes, Jim Galvin, Jody Kolker, and Rick Wilhelm have volunteered to compile a list of attack vectors and how the recommendations solve for them, or where they are out of scope. Recommendation 6: 1. Staff to redline the language and include it as a sub-bullet in Recommendation 6. WG members to review with other redlines by Wednesday, 30 November. Recommendation 2: 1. WG members to review and comment on Strawman Revision of Recommendation 2 on the Losing FOA [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1e8iG6FmRD0M5…> on the list by Wednesday, 30 November. Recommendation 7: 1. (c) Proposed edit -- WG agrees with the potential next step of changing the language from “should” to “MUST”. Staff to incorporate. WG members should review and comment. Recommendation 8 1. (a) Proposed Edit -- WG agrees with the potential next step strawman revision. Staff to incorporate. 2. (b) Proposed Edit – WG agrees with the potential next step strawman revision. Staff to incorporate. Recommendation 9: 1. (b) Proposed edit -- WG agrees with the suggested language in the Potential next step. Staff to incorporate. Notes: Transfer Policy Review - Meeting #66 Proposed Agenda 15 November 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates Recommendation 6: Potential next step: Strawman revision: "Designated representative" means an individual or entity that the Registered Name Holder explicitly authorizes to request and obtain the TAC on their behalf.” Discussion: * Re: the recent discussion on “Designated Representative” perhaps suggest instead “Authorized Representative”? Or another term. * Maybe just don’t define “Designated Representative”? * From ICANN org Compliance: Suggestion is to be more clear about the Designated Representative’s authority. Issue of resellers including language of authorizing and denying transfers. Compliance has been able to obtain remediation in these cases, based on definitions in the policy – the more clear the policy is on definitions and authority for transfers, the better can Compliance enforce the policy. Recommends that the definition should be included in the text of the policy. * Some disagree to change the language to include in the policy – RNH should have to abide by the terms agreed to with the reseller with respect to authorizing or denying transfers. * Some agree that the authorization should be clear in the policy. * Keep “Designated Agent” separate. Compliance spoke of “Designated Agent” in the COR as an analogy only. “Designated Agent” is a separate concept/use case. * There was some agreement on the last call to adjust the meaning of the Designated Representative to include “request and obtain”. Also to pull out from the footnote into the policy but as a sub-bullet in Recommendation 6. * Redline of changes to recommendations thus far from discussion of public comments will be out soon – allow two weeks to review, by Wednesday, 30 November. ACTION ITEM: Recommendation 6 -- Staff to redline the language and include it as a sub-bullet in Recommendation 6. WG members to review with other redlines by Wednesday, 30 November. 3. Review of Strawman Revision of Recommendation 2 on the Losing FOA [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1e8iG6FmRD0M5…> * WG agreement in previous discussions to preserve the functionality of the Losing FOA and consider where best to put it. * Keep the 5-day provisioning window flexible. That’s what this strawman is doing. * WG has two weeks to review this strawman text. ACTION ITEM: Recommendation 2 -- WG members to review and comment on Strawman Revision of Recommendation 2 on the Losing FOA [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1e8iG6FmRD0M5…> on the list by Wednesday, 30 November. 4. Continue Discussion of TAC Composition – Recommendation 7 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcr…> and Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1796UeXK6GspA…>) Re: a) Concerns -- Discussion: * RFC9154 is only a guidance/principle – NIS2 will cover a lot of this with high requirements on how you set up security as a European company, including auditing capability; so we don’t have to do all of that. * Important to recognize that we aren’t using everything in RFC9154. * We have left the choice of mechanism for communication up to registrars, not specifying it in the policy. * RFC9154 doesn’t include auditing – but that’s not part of any technical specifications, not a limitation; we can add auditing provisions to the recommendations if we wish. * Reasonable for registrars to think back about what is the minimum from a security standard that we should have – which elements are mandatory and which are optional? Some of these security elements can be left up to the business model. * From a technical point of view you can’t just start eliminating characters – have an algorithm that has been reviewed and accepted – can’t just change it. Re: b) Proposed edit -- Discussion: * After review of Tech Ops discussion, WG doesn’t recommend any changes. Re: c) Proposed edit – Discussion: Potential next step: Strawman revision from ICANN org comment: “The working group recommends that the minimum requirements for the composition of a TAC MUST be as specified in RFC 9154, including all successor standards, modifications or additions thereto relating to Secure Authorization Information for Transfer. The requirement in section 4.1 of RFC 9154 regarding the minimum bits of entropy (i.e., 128 bits) should be a MUST in the policy until a future RFC approved as “Internet Standards” (as opposed to Informational or Experimental standards) through the applicable IETF processes updates the security recommendation.” * Hinges on the meaning of the word “should”. * Using “MUST” means it’s something you have to do; “should” is something you are urged to do, but don’t have to do it. ACTION ITEM: Recommendation 7, (c) Proposed edit -- WG agrees with the potential next step of changing the language from “should” to “MUST”. Staff to incorporate. WG members should review and comment. Re: d) Proposed edit – Discussion: * Think about whether the current language is sufficiently clear. * Seems like we don’t want to include this in our policy – the IETF is taking care of it. * WG members agree that no further clarification is necessary. 5. Discussion of Verification of TAC Composition – Recommendation 8 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcr…> and Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1gUoQQ-YpnjOO…>) Re: a) Proposed edit – Discussion: Potential next step: Strawman revision: “The working group recommends that the Registry verifies at the time that the TAC is stored in the Registry system that the TAC meets the syntax requirements specified in Preliminary Recommendation 7.” * WG agrees with the suggested change. ACTION ITEM: Recommendation 8, (a) Proposed Edit -- WG agrees with the potential next step strawman revision. Staff to incorporate. Re: b) Proposed edit – Discussion: Potential next step: Strawman revision, based on staff understanding of the WG’s intent: “The working group recommends that the Registry MUST verifyies at the time that the TAC is stored in the Registry system that the TAC meets the requirements specified in Preliminary Recommendation 7.” * WG agrees with the suggested change. ACTION ITEM: Recommendation 8, (b) Proposed Edit – WG agrees with the potential next step strawman revision. Staff to incorporate. 6. Discussion of TAC Generation, Storage, and Provision – Recommendation 9 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcr…> and Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1dbJ8gV6afl9o…>) Re: a) Concerns – Discussion: Potential next step: WG to consider the suggestion that Gaining Registrars should log failed requests and share with targets, as well as suggestion about enhanced security measures. * The TAC itself is one-time use; from a registry point of view if we get a TAC that matches what is stored, it can’t be used again. Also, rather than counting failed, the TAC has a TTL, which should address that. So, we already have security measures that address this; no need to log failed attempts. * Could be a registry choice to keep note of failures and investigate as part of a particular business model. No need to make it mandatory. * Registrars and registries already log a lot. * WG agrees that no changes are necessary to the policy language. Re: b) Proposed edit – Discussion: Potential next step: Strawman revision: 9.2: When the Registrar of Record sets the TAC at the Registry, the Registry MUST store the TAC securely, at least according to the minimum standard set forth in RFC 9154 (or its successors). ACTION ITEM: Recommendation 9, (b) Proposed edit -- WG agrees with the suggested language in the Potential next step. Staff to incorporate.

1 0

**AT THE TOP OF THE HOUR** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 15 November 2022
by Julie Bisland Nov. 15, 2022

Nov. 15, 2022

**AT THE TOP OF THE HOUR** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 15 November 2022 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/8QnVD * For other places see: https://tinyurl.com/5at6pk3p [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/5at6pk3p__;!!PtGJab4!66TFBWU…> 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. * 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 THREE 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

REMINDER | Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 15 November 2022
by Devan Reed Nov. 14, 2022

Nov. 14, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 15 November 2022 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/8QnVD * For other places see: https://tinyurl.com/5at6pk3p [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/5at6pk3p__;!!PtGJab4!66TFBWU…> 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. * 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 THREE 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 #66 on Tuesday 15 November 2022 at 16:00 UTC
by Emily Barabas Nov. 11, 2022

Nov. 11, 2022

Dear Working Group members, Please find below the proposed agenda for the next meeting scheduled to take place on Tuesday 15 November 2022 at 16:00 UTC. Prior to the call, please review the documents linked in the agenda below. Kind regards, Julie, Berry, Caitlin, and Emily Transfer Policy Review - Meeting #66 Proposed Agenda 15 November 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates 3. Review of Strawman Revision of Recommendation 2 on the Losing FOA<https://docs.google.com/document/d/1e8iG6FmRD0M5VlMUrmIedPw3burqfxLXQrkubxD…> 4. Continue Discussion of TAC Composition – Recommendation 7 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcr…> and Working Document<https://docs.google.com/document/d/1796UeXK6GspA7cehLcSn5tWiCyuR7JU7hOfKHgC…>) 5. Discussion of Verification of TAC Composition – Recommendation 8 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcr…> and Working Document<https://docs.google.com/document/d/1gUoQQ-YpnjOO_3X0R_vt6CRB9VUfEijf4Ap2LgR…>) 6. Discussion of TAC Generation, Storage, and Provision – Recommendation 9 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcr…> and Working Document<https://docs.google.com/document/d/1dbJ8gV6afl9oHxXW9dMvIX66nacy2IzzXz9VFpR…>) 7. Discussion of Verification of TAC Validity – Recommendation 10 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcr…> and Working Document<https://docs.google.com/document/d/1wmeFmn1zUDuA5-I-qKZsgddAYfDMx8oV0GC_Eix…>) 8. AOB

1 0

Notes and action items - TPR WG Meeting #66 - 10 November 2022 at 16:00 UTC
by Julie Hedlund Nov. 10, 2022

Nov. 10, 2022

Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be on Tuesday, 15 November (note new schedule of twice-weekly meetings) at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: 1. Jothan Frakes, Jim Galvin, Jody Kolker, and Rick Wilhelm have volunteered to compile a list of attack vectors and how the recommendations solve for them, or where they are out of scope. Recommendation 2: 1. Staff to write up the recommendation to keep the Losing FOA functionality with flexibility on terminology and format. Recommendation 3: 1. (f) Proposed edit -- Staff to provide revised draft language to change to mandatory (“MUST”). 2. (g) Proposed Edit -- Staff to revise the language in the Working Document to change to “notification of TAC issuance” and WG to review/comment. Recommendation 4: 1. (c) Proposed Edit -- Staff to revise the recommendation text to include “For the purposes of sending the notification, the Registrar of Record should use contact information as it was in the registration data at the time of the transfer request.” 2. (d) Proposed Edit -- Staff to provide draft language for the WG to consider. 3. (e) Proposed Edit -- Staff to revise as suggested in the proposed next step but also to confirm that this and similar language is consistent. Recommendation 5: 1. (b) Proposed Edit -- Staff to revise the language in the Working Document as suggested in the potential next step. Recommendation 6: 1. (a) Concern -- Staff to revise the language in the Working Document as suggested in the potential next step. 2. (b) Concern -- Staff to revise the language in the Working Document as suggested in the potential next step. 3. (c) Proposed Edit -- Staff to revise the language in the Working Document as suggested in the potential next step. 4. (d) Proposed Edit -- Registrars to discuss. Recommendation 7: 1. WG members to review prior to next Tuesday’s meeting: See the Working Document Tool at: https://docs.google.com/document/d/1796UeXK6GspA7cehLcSn5tWiCyuR7JU7hOfKHgC…. Notes: Transfer Policy Review - Meeting #65 Proposed Agenda 10 November 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates * Reminder that we have 10 more bi-weekly meetings to the end of the year with the goal to complete our review of the public comments. * Still working on the proposal relating to the Losing FOA based on our discussion during the call on 08 November – should have that to you to consider at the next meeting. 3. Continue Discussion of Notification of TAC Provision – Recommendation 3 (see Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcr…> and Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1SaEV9vjiSZON…>) e) Proposed edit ICANN org understands that notifications tend to be in the form of an email, and in general emails typically are not secure methods of communication. RFC9154 in subsection 7 of section 4.3, notes "The registrar's interface for communicating the authorization information with the registrant MUST be over an authenticated and encrypted channel." Thus, ICANN org suggests the WG consider updating the language in recommendation 3.2 to note "If the TAC has not been provided via another method of communication, this communication will include a secure mechanism (e.g. a link using HTTPS that requires authentication) to provide the TAC." This suggested language change complies with RFC9154. Potential next step: Strawman revision: If the TAC has not been provided via another method of communication, this communication will include a secure mechanism (e.g. a link using HTTPS that requires authentication) to provide the TAC. Discussion: * A lot of registrars are doing this, but does it need to be mandatory. * Do we know if we have problems with email? Seems like a real disruption to a user’s experience. * The WG needs to decide – it’s in the RFC: sending the TAC in email is not a good security practice. That is the reason why the language is in RFC9154. * It might be an overstep to say that everyone has to change their systems because many are likely not sending via email already. * The comment in the proposed edit (e) does quote directly from RFC9154 – but the group would not necessarily have to adopt the suggested revised language. * This is someone related to the mechanism currently known as the “Losing FOA” – if you lose control of your email and the TAC the registrant has a way of denying a transfer. These security mechanisms are interrelated/interdependent. * Policy can’t solve for accounts being compromised. * The WG is not agreed that this should be a mandatory requirement. f) Proposed edit Require that the notification be sent in English in addition to the language of the registration agreement. Potential next step: WG to consider if the notification should be sent in English in addition to the language of the registration agreement. Note that the FOA is currently communicated in English. Discussion: * The purpose of the comment was because the Losing FOA is communicating in the primary language as a standard and this would make it mandatory (a “MUST”). * This is a comment from John Poole. * Seems to be an easy small change so changing to a “MUST” would make sense. ACTION ITEM: Recommendation 3, (f) Proposed edit -- Staff to provide revised draft language to change to mandatory (“MUST”). g) Proposed edit The Registries note an ambiguity between Recommendations 3 and 12 that we believe should be clarified. Recommendation 3 states that the Registrar of Record is required to notify an RNH of the provision of a TAC within 10 minutes of its request. However, Recommendation 12 states that the TAC itself must be provided within at most 5 days. The use of “provision” and “provide” are ambiguous. Perhaps Recommendation 3 is intended to notify an RNH of the “request” for a TAC as opposed to its provision? Other resolutions are possible and our suggestion does not indicate a preferred choice. Rec 3: #13 Potential next step: The wording of the recommendation appears to be causing confusion. See suggested edit under c), which attempts to make clear that the notification is sent after the TAC is provided. Discussion: * Seems to be addressed by previous/earlier recommendation (edit under (c)). See: “Implementation Note: For the purposes of sending the notification, the Registrar of Record should use contact information as it was in the registration data at the time of the TAC request.” * Should we use a different word than “provision” in the notification? “Provision” is the technical creating and there is a small delay between “provision” and “providing”. * Could be “Notification of TAC issuance”? WG agrees at least provisionally – make the change and review. ACTION ITEM: Recommendation 3, (g) Proposed Edit -- Staff to revise the language in the Working Document to change to “notification of TAC issuance” and WG to review/comment. h) Additional Consideration Corresponding PCRT comment(s) If i paid to transfer 25 domains at one time, i think there should be only one notification for those 25 domains, but not separately as it is currently for each domain. Rec 3: #9 Potential Next Step: In recommendation 4.2 the WG has provided for optional consolidation of notifications of transfer completion, where possible. The WG previously discussed the possibility of special processes for bulk use cases, but did not come to any agreement on recommendations. Is further discussion needed about any other opportunities to consolidate notices? Discussion: * Seems to make sense, but depends on the method of “issuance”. * Think we already have language that talks about consolidation so not sure if we have to add anything. * WG agrees not to modify the language of the recommendation because there is existing language elsewhere that envisions consolidation. i) Additional Consideration We recognize that some registrars have employed security protocols which provide additional and voluntary security for registrants while not unnecessarily impeding the portability of domain names. Where appropriate, such best practices deserve consideration for inclusion in Transfer Policy itself so that they become requirements of registrars. Rec 3: #10 Potential Next Step: This comment may require additional clarification about the type of security protocols envisioned in the comment. The WG has previously discussed that account security, for example, falls outside of the picket fence. Discussion: * The WG did consider better security mechanisms. * The thinking at the time of the comment is to leave the security protocols to registrars, there is the option to provide implementation guidance to registrars so they have best practices that they can add to their baseline protocols. Even if the WG doesn’t mandate these things, they could be helpful for registrars to know them. * It may be out of scope for the policy, but worthwhile including as guidance. 4. Continue Discussion of Notification of Transfer Completion – Recommendation 4 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcr…> and Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1RDMBC4fdaltB…>), including the question for community input on Recommendation 4 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcr…> and Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1tQTbM2dxdmVJ…>) a) Concern Corresponding PCRT comment(s) Notice should be sent without delay (rec #3 already mentioned a 10 minute standard). Rec 4: #9 Potential next step: Is it appropriate to revisit SLA for notice? What are the pros/cons and feasibility of shortening the SLA from 24 hours to 10 minutes? Discussion: * Already addressed in Recommendation #3 10-minute standard. b) Concern Corresponding PCRT comment(s) Notices should be sent to all contacts (including the tech contact) not just the RNH. Rec 4: #9, Rec 15: #4 Potential next step: This suggestion was discussed by the WG’s review of comments on the Notification of TAC provision and similar points raised in that discussion appear to apply here. Discussion: * Already addressed in previous discussions. c) Proposed edit If the intent of the WG is to have the notification sent once the transfer has been completed, reword the recommendation to make clear that the notification of transfer is sent only once the notification is successfully completed and that the recipient is the RNH as it was reflected the Registration Data at the time of the transfer request. Potential next step: Strawman revision: Recommendation 4: The working group recommends that the Losing Registrar MUST send a “Notification of Transfer Completion” to the RNH, as listed in the Registration Data at the time of the transfer request, without undue delay but no later than 24 hours after the transfer is completed. Implementation Note: For the purposes of sending the notification, the Registrar of Record should use contact information as it was in the registration data at the time of the transfer request. [In cases where a customer uses a Privacy/Proxy service and the contact information associated with the underlying customer is known to the Registrar of Record, the Registrar of Record may send the notification directly to the underlying customer.] Discussion: * Strawman doesn’t change the intent – it’s not optional, but need to provide rationale. * Don’t think the language needs to be stricken. * Could we take out the stricken language and instead add the first sentence of the Implementation Note to the recommendation. ACTION ITEM: Recommendation 4, (c) Proposed Edit -- Staff to revise the recommendation text to include “For the purposes of sending the notification, the Registrar of Record should use contact information as it was in the registration data at the time of the transfer request.” d) Proposed edit Similar to input on 3.2, require additional elements to be included as part of the “Notification of Transfer Completion”, such as the timing by when the RNH is required to take action if they believe the transfer is invalid. Potential next step: WG to consider whether it is appropriate to include these additional elements. Discussion: * Seems reasonable, but need to see it in writing. ACTION ITEM: Recommendation 4, (d) Proposed Edit -- Staff to provide draft language for the WG to consider. e) Proposed edit Require that the notification be sent in English in addition to the language of the registration agreement. Potential next step: A similar comment was discussed under review of input on the Notification of TAC Request and conclusions of that discussion likely apply here as well. Discussion: * WG agrees but staff should ensure that this and all similar language is consistent. ACTION ITEM: Recommendation 4, (e) Proposed Edit -- Staff to revise as suggested in the proposed next step but also to confirm that this and similar language is consistent. Note re: Additional Considerations (f) and (g) – save for Phase 2. Potential next step: WG to consider the merits of these points to determine if the recommendation should be revised. WG discussion and agreement: As relayed from TechOps discussions at the 2022 CP Summit: * Participants in the TechOps discussions acknowledged benefits of the RO providing the Gaining Registrar’s IANA ID to the Registrar of Record via poll message. * To the extent that the Losing FOA is retained, the Gaining Registrar’s IANA ID can be included in the Losing FOA, as well as in the Notification of Transfer Completion: * Gaining Rr submits TAC to RO. * RO verifies validity of request/TAC. * RO sets pending status. * RO sends poll message to Losing Rr, to include Gaining Rr’s IANA ID. Discussion: * WG agrees, but registries should consider and provide input – confirm on the next call. * Registries did provide the following comment: “Registry Operators acknowledge the security benefit of notifying a RNH both of a completed transfer and of the identity of the Gaining Registrar. This notification provides a confirmation to the RNH that the desired action was completed as requested. Further, Registry Operators understand that in order to achieve this it will be incumbent of Registry Operators to provide this information to the Losing Registrar via EPP upon completion of the transfer as the Losing Registrar would not otherwise have access to this information.” 5. Begin Discussion on Recommendation 5 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcr…> and Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1ssvbicQ7pkZi…>) and Recommendation 6 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcr…> and Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1wr84v8XbEfe0…>) Recommendation 5: a) Concern Corresponding PCRT comment(s) The TAC is a high-value target that should be eliminated. It should be replaced with the PTID. Rec 5: #5 Potential next step: See deliberations on this proposal under discussion of Recommendation 1. WG discussion and agreement: b) Proposed edit Corresponding PCRT comment(s) ICANN org acknowledges that this update should be made across all platforms including ICANN.org webpages, and suggests the WG consider including an implementation note that clarifies that updates include publications and webpages in accordance with the suggested terminology change. Rec 5: #3 Potential next step: WG to consider if there is any downside to adding an Implementation Note, and if not, add suggested language. Strawman revision: Implementation Note: ICANN publications and webpages should also be updated to reflect the recommended terminology change. WG discussion and agreement: Discussion: * WG agrees with the proposed strawman revision. ACTION ITEM: Recommendation 5, (b) Proposed Edit -- Staff to revise the language in the Working Document as suggested in the potential next step. Recommendation 6: a) Concern ICANN org acknowledges the concerns raised by the WG that adding language that the RNH’s authority supersedes that of the representative may conflict with agreements between the RNH and a third-party to which the RNH has given authority. Yet, ICANN org would like to point out that it is not uncommon for resellers or web-developers (example of these third-parties) to include general clauses in their agreements granting blanket authority to the reseller or web-developer to manage the domain name (which may be used by the third party to attempt to hinder or process an inter-registrar transfer where there is a dispute). Org would also like to note that “in the event of dispute” it is not within ICANN’s remit to determine how and to which extent an agreement a RNH may enter with a third party may suffice to diminish the protection and authority the Transfer Policy intends to afford to RNHs. Org’s recommendation is consistent with the current Transfer Policy which indicates that the RNH and the Administrative Contact “are the only parties that have the authority to approve or deny a transfer request to the Gaining Registrar. In the event of a dispute, the Registered Name Holder's authority supersedes that of the Administrative Contact. “ This is regardless of whether or not the RNH and the Administrative Contact may have a separate agreement. Potential next step: WG to consider whether, in light of the above points, the recommendations should include the suggested language that the RNH’s authority supersedes that of the representative in the event of a dispute. Discussion: * The WG agrees with the suggested potential next step. ACTION ITEM: Recommendation 6, (a) Concern -- Staff to revise the language in the Working Document as suggested in the potential next step. b) Concern The TAC is a high-value target that should be eliminated. It should be replaced with the PTID. Conceivably the TAC can be generated by the registry, not just the registrar. Generation of the TAC on request (as opposed to always existing, like the current AuthInfo code) is a slight improvement, it is overstated as a huge improvement, because the existence of a domain name transfer lock blocks the persistent (always existing) AuthInfo code. Potential next step: See also deliberations on this proposal under discussion of Recommendation 1. Discussion: * WG agrees with the suggested potential next step. ACTION ITEM: Recommendation 6, (b) Concern -- Staff to revise the language in the Working Document as suggested in the potential next step. c) Proposed edit The WG may want to consider including the term “to request” in addition to obtaining the TAC. Specifically, an individual or entity that the Registered Name Holder explicitly authorizes to request and obtain the TAC on their behalf. This is to avert instances where a representative may obtain the TAC that the RNH never intended to request for a transfer the RNH never wanted. Potential next step: Strawman revision: “ "Designated representative" means an individual or entity that the Registered Name Holder explicitly authorizes to request and obtain the TAC on their behalf.” Discussion: * This makes it clear that the “Designated representative” is authorized to request the TAC. * WG agrees with the suggested potential next step. ACTION ITEM: Recommendation 6, (c) Proposed Edit -- Staff to revise the language in the Working Document as suggested in the potential next step. d) Proposed edit Org would also like to note that based on our experience in implementing other recommendations, it is a good idea to have important definitions embedded in the policy recommendations themselves (as opposed to in a footnote) as it will allow ICANN Compliance the ability to easily enforce the requirements when included and clearly described within the text of the policy language. Potential next step: Make the definition of the designated representative a standalone recommendation: Recommendation xx: "Designated representative" means an individual or entity that the Registered Name Holder explicitly authorizes to obtain the TAC on their behalf. Discussion: * Suggestion is to make this a recommendation as opposed to just a footnote. * Concern is that we haven’t fully defined what “Designated representative” means. Has it been defined in other ICANN policies? * Staff notes that “Designated Agent” is defined elsewhere, but not “Designated Representative”. This is different from the “Designated Agent”. * From the Transfer Policy: "Designated Agent" means an individual or entity that the Prior Registrant or New Registrant explicitly authorizes to approve a Change of Registrant on its behalf. * We are acknowledging that in some cases “Designated Representatives” exist and they can obtain the TAC. ACTION ITEM: Recommendation 6, (d) Proposed Edit -- Registrars to discuss. Recommendation 7: ACTION ITEM: Recommendation 7 -- WG members to review prior to next Tuesday’s meeting: See the Working Document Tool at https://docs.google.com/document/d/1796UeXK6GspA7cehLcSn5tWiCyuR7JU7hOfKHgC…. 6. AOB

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 15 November 2022
by Julie Bisland Nov. 10, 2022

Nov. 10, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 15 November 2022 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/8QnVD * For other places see: https://tinyurl.com/5at6pk3p 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. * 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 THREE 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 | Thursday, 10 November 2022
by Julie Bisland Nov. 10, 2022

Nov. 10, 2022

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

**AT THE TOP OF THE HOUR** Meeting Invitation | Transfer Policy Review PDP WG call | Thursday, 10 November 2022
by Julie Bisland Nov. 10, 2022

Nov. 10, 2022

**AT THE TOP OF THE HOUR** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Thursday, 10 November 2022 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/aIIFDQ * For other places see: https://tinyurl.com/2tp9uacu [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/2tp9uacu__;!!PtGJab4!_6W0hxO…> 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. * 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 THREE 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

**REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Thursday, 10 November 2022
by Julie Bisland Nov. 9, 2022

Nov. 9, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Thursday, 10 November 2022 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/aIIFDQ * For other places see: https://tinyurl.com/2tp9uacu [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/2tp9uacu__;!!PtGJab4!_6W0hxO…> 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. * 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 THREE 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

Proposed agenda for meeting #65 on Thursday 10 November at 16:00 UTC
by Emily Barabas Nov. 9, 2022

Nov. 9, 2022

1 0