- GNSO-TPR - lists.icann.org

ICANN75 Policy Outcomes Report is now available for Download
by Terri Agnew Oct. 20, 2022

Oct. 20, 2022

Dear all, As announced in the ICANN Community Digest, the ICANN75 Policy Outcomes Report is now available for download: https://go.icann.org/outcomes75 [go.icann.org]<https://urldefense.com/v3/__https:/go.icann.org/outcomes75__;!!PtGJab4!5_do…> Happy reading! Kindest regards, Terri

1 0

**Updated with Thursdays** October, November & December 2022 calls | Transfer Policy Review PDP WG
by Julie Bisland Oct. 18, 2022

Oct. 18, 2022

**We are sending in advance to get dates on everyone’s calendar. Thursday calls have been added below: Dear all, The calls for October (remaining weeks), November and December 2022 for the Transfer Policy Review PDP WG are listed below. The calls take place at 16:00 UTC for 90 minutes. The first 2 .ics attachments are recurring orders – one for Oct and the second for Nov/Dec, please be sure to download them as “recurring” vs. a one-time event to ensure all the dates show up on your calendar. In addition, there are 5 new .ics attachments for the 5 Thursday calls just added. * Tuesday, 25 October 2022 (invite has been sent) * Tuesday, 08 November 2022 * Thursday, 10 November 2022 * Tuesday, 15 November 2022 * Thursday, 17 November 2022 * Tuesday, 22 November 2022 * Tuesday, 29 November 2022 * Thursday, 01 December 2022 * Tuesday, 06 December 2022 * Thursday, 08 December 2022 * Tuesday, 13 December 2022 * Thursday, 15 December 2022 (conflicts with GNSO Council SPS) * Tuesday, 20 December 20222 Future invitations will be sent out closer to the date of the call. Thank you. With kind regards, Terri

1 0

Transfer Policy Review PDP WG
by ICANN Policy Calendar Oct. 18, 2022

Oct. 18, 2022

Meeting: Transfer Policy Review PDP WG Date/Time: Thursday, 15 December 2022 at 16:00 UTC for 90 minutes Join the Zoom Webinar: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 Passcode: @TP/^*4wg# * 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…>. 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> * Wiki agenda page: https://community.icann.org/x/cYIFDQ * Time conversion link: https://tinyurl.com/33ke8na4 ONLY for Members & Alternates: * Please join via the above Zoom Webinar link and staff will promote you to Panelist * Alternate replacements will be posted to the Alternate Log-Transfer Policy Review PDP wiki page<https://community.icann.org/x/V4aUCQ>. * Members and alternates replacing members, please select Everyone when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates (not replacing a member): Please rename your line in Zoom by adding THREE Zs “zzz” before your name, and in parentheses, (your affiliation - alternate), after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. For Audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6

1 0

Transfer Policy Review PDP WG
by ICANN Policy Calendar Oct. 18, 2022

Oct. 18, 2022

Meeting: Transfer Policy Review PDP WG Date/Time: Thursday, 08 December 2022 at 16:00 UTC for 90 minutes Join the Zoom Webinar: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 Passcode: @TP/^*4wg# * 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…>. 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> * Wiki agenda page: https://community.icann.org/x/b4IFDQ * Time conversion link: https://tinyurl.com/3htvzzad ONLY for Members & Alternates: * Please join via the above Zoom Webinar link and staff will promote you to Panelist * Alternate replacements will be posted to the Alternate Log-Transfer Policy Review PDP wiki page<https://community.icann.org/x/V4aUCQ>. * Members and alternates replacing members, please select Everyone when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates (not replacing a member): Please rename your line in Zoom by adding THREE Zs “zzz” before your name, and in parentheses, (your affiliation - alternate), after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. For Audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6

1 0

Transfer Policy Review PDP WG
by ICANN Policy Calendar Oct. 18, 2022

Oct. 18, 2022

Meeting: Transfer Policy Review PDP WG Date/Time: Thursday, 01 December 2022 at 16:00 UTC for 90 minutes Join the Zoom Webinar: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 Passcode: @TP/^*4wg# * 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…>. 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> * Wiki agenda page: https://community.icann.org/x/bYIFDQ * Time conversion link: https://tinyurl.com/2p9fx9c4 ONLY for Members & Alternates: * Please join via the above Zoom Webinar link and staff will promote you to Panelist * Alternate replacements will be posted to the Alternate Log-Transfer Policy Review PDP wiki page<https://community.icann.org/x/V4aUCQ>. * Members and alternates replacing members, please select Everyone when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates (not replacing a member): Please rename your line in Zoom by adding THREE Zs “zzz” before your name, and in parentheses, (your affiliation - alternate), after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. For Audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 25 October 2022
by Julie Bisland Oct. 18, 2022

Oct. 18, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 25 October 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/EwVpD * For other places see: https://tinyurl.com/3j5dsa3f 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

Transfer Policy Review PDP WG
by ICANN Policy Calendar Oct. 18, 2022

Oct. 18, 2022

Meeting: Transfer Policy Review PDP WG Date/Time: Thursday, 17 November 2022 at 16:00 UTC for 90 minutes Join the Zoom Webinar: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 Passcode: @TP/^*4wg# * 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…>. 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> * Wiki agenda page: https://community.icann.org/x/aoIFDQ * Time conversion link: https://tinyurl.com/4j68zdtk ONLY for Members & Alternates: * Please join via the above Zoom Webinar link and staff will promote you to Panelist * Alternate replacements will be posted to the Alternate Log-Transfer Policy Review PDP wiki page<https://community.icann.org/x/V4aUCQ>. * Members and alternates replacing members, please select Everyone when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates (not replacing a member): Please rename your line in Zoom by adding THREE Zs “zzz” before your name, and in parentheses, (your affiliation - alternate), after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. For Audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6

1 0

Transfer Policy Review PDP WG
by ICANN Policy Calendar Oct. 18, 2022

Oct. 18, 2022

Meeting: Transfer Policy Review PDP WG Date/Time: Thursday, 10 November 2022 at 16:00 UTC for 90 minutes Join the Zoom Webinar: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 Passcode: @TP/^*4wg# * 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…>. 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> * Wiki agenda page: https://community.icann.org/x/aIIFDQ * Time conversion link: https://tinyurl.com/2tp9uacu ONLY for Members & Alternates: * Please join via the above Zoom Webinar link and staff will promote you to Panelist * Alternate replacements will be posted to the Alternate Log-Transfer Policy Review PDP wiki page<https://community.icann.org/x/V4aUCQ>. * Members and alternates replacing members, please select Everyone when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates (not replacing a member): Please rename your line in Zoom by adding THREE Zs “zzz” before your name, and in parentheses, (your affiliation - alternate), after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. For Audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 18 October 2022
by Julie Bisland Oct. 18, 2022

Oct. 18, 2022

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

Notes and action items - TPR WG Meeting #62 - 18 October 2022 at 16:00 UTC
by Julie Hedlund Oct. 18, 2022

Oct. 18, 2022

Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be on Tuesday 25 October at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: 1. ACTION ITEM: Staff to create a diagram comparing the timeline of the existing Losing FOA with the proposed notification of TAC request discussed during the meeting on 18 October. 2. ACTION ITEM: 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. Notes: Transfer Policy Review - Meeting #62 Proposed Agenda 18 October 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates * Doodle poll to pick another weekly time slot: choice was 16:00 UTC on Thursdays. We will start on 10 November. * Good conversation from last meeting. Seemed to be agreement that we need an explicit window to NACK. Proposal to make a mandatory notification of transfer requests at the time of request that goes to the registrant on record. Didn’t yet agree on a time window – need to get ideas on that. Moves us from recommendations 1 to recommendations 2 and 3. 3. Continue Discussion of Comments on Elimination of the Losing FOA – Recommendations 2 (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/1gyy9xfe0-ymW…>) Look at the working document bottom of page 3: Proposal: Make a notification of TAC (transfer) request mandatory. The registrant has the option to accept or reject the release of the TAC. If there is no response by x period of time (a period of less than 5 days), the Registrar may proceed to issue the TAC. Discussion: * If this were an email notice that might fit a NACK-like behavior. * Good point. It is something beyond the registrar’s portal – outside of that. We have avoided stipulating the method of communication. It just has to be separate, so a multi-factor concept. * Regarding format of notifications from the Initial Report: 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. * Clarify/reiteration from last week’s discussion – once the transfer is submitted it is done; so no NACK process. Instead, when you request a TAC you get a notification that you have requested a TAC and the registrant has the option to confirm (yes) or not (no). Notice has two parts – confirm or deny. * (For notification of TAC provision and notification of transfer completion, but presumably would also apply to this additional notification). * Provisioning a TAC does not initiate a transfer. * Because we are frontloading things are we also frontloading hurtles to those who want to transfer? Are we still getting them the TAC to allow them to do what they want to do. Getting the TAC to the RNH might be important, but are we adding that agility at the expense of being flexible to transfer. * If a registrar does not allow a registrant to leave, then they are violating the existing Transfer Policy. * What problem are we solving from a technical concern – being able to deny the transfer before it starts? Don’t see the problem from a systems point of view. Small group will get together during CPH meeting to compile a list of attack vectors and how our recommendations solve them, or not (and explain why not). * The registrant may not be the person making the request for the transfer. The problem we are solving isn’t a technical problem but a security issue to make sure the registrant agrees to the transfer occurring -- what was the Losing FOA. * The provisioning of the TAC does not initiate the transfer. Notification versus confirm/cancel are two different things. Doing this on the provisioning of the TAC is increasing the difficulty of transfer. Commenters want the chance to deny the transfer that is about to go through – but this proposal doesn’t do that. * In our current recommendations once the TAC is communicated the transfer can happen nearly simultaneous. In our new proposal when the NACK can happen doesn’t matter, just that we put the ability to deny before the TAC provision. This is the Losing FOA -- it requires the registrar to do something to allow the transfer to go through; just bringing back the same window that the registrars have. We are saying there has to be an explicit window for the registrants to deny it. * This is a compromise on what we proposed previously. This covers a lot of things, but not a technical fix. Giving the registrants what they want. This is our response to the feedback we got. * Think this is a worse situation as it still exposes us to complaints that we’ve removed the Losing FOA and removed a window that allows the transfer to be NACKed at the last minute. It requires registrars to change their code without any real benefit. Why not just put the Losing FOA back? * Does it make sense that we are adding the FOA into the 5-day window? Why not just leave the FOA? What’s the benefit? We are lengthening the transfer process by having two windows – one for the registrar and one for the registrant. Does it make sense to streamline into one 5-day window? * Going back to the principles of the public comment review: when we are going through the comments on the recommendations the goal is to get consensus on the final recommendation. If we can’t get consensus on change from the status quo then we go back to the status quo, which is the Losing FOA. There are also previous discussions on way to improve the Losing FOA that might be a way forward. * Might want to consider what rollback (Phase 2) might look like. Some of this might be disrupted. Don’t know if we can come back to address something from Phase 1. * A claw-back will help us but that is reactive, rather than proactive like the Losing FOA. * What we said at the end of the last call was bringing the Losing FOA back in its functionality. Does it stay at the end (as it was today) or move it out front to the 5-day window that the registrar have to provide the TAC. * What is the second 5-day window? We currently have that, but the recommendation is a single 5-day window and the proposal is to put the notification into the (now) single 5-day window. * If we combine the windows change it from “Losing FOA”. * In today’s world the registrars and registrants are used to two 5-day windows. We are proposing one 5-day window. If we don’t get consensus on changes then we will go back to two 5-day window. * It would help to get a “time line “ displayed indicating the alternatives, inc. when the RNH can NACK the transfer. * Registrars should look at proposed edits (b) and (c) as a possible middle path to no FOA or a proposed FOA. CPH Tech Ops may consider at its next meeting. * If we are keeping the functionality should it stay at the end, or do we go to one 5-day period and put the notification at the beginning? * The other question is whether the 5-day window is correct, or should it be shorter? * The original timeline reflected business days. * It was up to 5 days, but it could be less. Once they get the TAC it can be fairly immediate. * Question: What is wrong with the status quo? Answer: Those who are seeking to streamline are looking for better ways to serve their customers’ needs. * In my view, 5 days is OK. More critical (in time) is the (potential) 30 days transfer lock due to a material change of registrant data. ACTION ITEM: Staff to create a diagram comparing the timeline of the existing Losing FOA with the proposed notification of TAC request discussed during the meeting on 18 October. 4. Begin Discussion of Notification – Recommendations 3 and 4 (see Recommendation 3 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…> and 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…>) From the Working Document: Recommendation 3: The working group recommends that the Registrar of Record MUST send a “Notification of TAC Provision” to the RNH, as listed in the registration data at the time of the TAC request, without undue delay but no later than after the Registrar of Record provides the TAC. 3.1: This notification MUST be written in the language of the registration agreement and MAY also be provided in English or other languages. 3.2: The following elements MUST be included in the “Notification of TAC Provision”: * Domain name(s) * Date and time that the TAC was provided and information about when the TAC will expire * Instructions detailing how the RNH can take action if the request is invalid (how to invalidate the TAC) * If the TAC has not been provided via another method of communication, this communication will include the TAC Discussion: * These recommendations are tied to what we do with recommendations and whether we go back to retaining the Losing FOA. Do they make sense no matter what we do? Don’t think there’s any reason to change recommendation 3. * Think it’s useful to cover the comments on recommendation 3. Public Comments Suggested Edits on Privacy/Proxy Services (Proposed Edit (c)): * Use of the term “Registration Data” (“as listed in the Registration Data at the time of the TAC request”) could suggest that this applies to Privacy/Proxy service data. Add an Implementation Note clarifying that “Registration Data” in case of a domain with an active P/P service means the underlying customer data, not the publicly-displayed P/P data. * The recommendation refers to the registered name holder (RNH) obtaining the TAC, however for domain names that utilize Privacy/Proxy services, it is possible that the underlying customer may obtain the TAC rather than the RNH. According to Section 1.3 of the Specification on Privacy and Proxy Registrations of the 2013 RAA, a Proxy Service is considered the RNH and licenses use of the domain name to the customer. It is impractical for a Proxy Provider to obtain TACs on behalf of customers, and this recommendation should be updated to accommodate Privacy/Proxy service customers. * The term “RNH, as listed in the Registration Data at the time of the TAC request” is incorrect as it should simply be “the RNH at the time of the TAC request” to allow for registrants who use Privacy/Proxy service data. We suggest removal of “, as listed in the Registration Data” so that it reads “to the RNH at the time of the TAC request”. c.f. Recommendation 14. Potential next step: Strawman revision: Recommendation 3: The working group recommends that the Registrar of Record MUST send a “Notification of TAC Provision” to the RNH, as listed in the registration data at the time of the TAC request, without undue delay but no later than after the Registrar of Record provides the TAC. 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. In cases where a customer uses a Privacy/Proxy service, the Registrar of Record should send the notification directly to contact information associated with the underlying customer where it is possible to do so. Public Comment Proposed Edit (d): Include additional elements required to be included in the “Notification of TAC Provision” such as: * An element that explains that the TAC will enable the transfer of the domain name to another registrar. * The deadline by which the RNH must take action if the request is invalid so that the registrar has sufficient time to NACK the transfer, where applicable (note that, at the time the RNH receives the “Notification of TAC Provision”, the TAC may have already been provided and the transfer command sent to the registry operator). * Required actions registrars must take (and by when) upon receiving notification by the RNH of an invalid request. Public Comment Proposed Edit (e): 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. See further public comments and proposed edits in the working document. 5. AOB

1 0