- GNSO-TPR - lists.icann.org

Post Call | Transfer Policy Review PDP WG | Tuesday, 07 December 2021
by Julie Bisland Dec. 7, 2021

Dec. 7, 2021

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

Notes and action items - TPR WG Meeting #27 - 07 Dec 2021
by Julie Hedlund Dec. 7, 2021

Dec. 7, 2021

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, 14 December at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items Revisit TAC recommendations (60 minutes) – see: TAC Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…> (beginning on p. 15) Recommendation 1: Revise text to (new text in brackets): “The Working Group recommends that the Transfer Policy and all related policies use the term “Transfer Authorization Code (TAC)” in place of the currently-used term “AuthInfo Code”[ and related terms].” Recommendation 2: Revise the wording (new text in brackets) to ““A Transfer Authorization Code (TAC) is a token created by the Registrar of Record and provided upon request to the registrant or [their designated representative.] Change “registrant” to “Registered Name Holder” throughout. Recommendation 3: WG members to suggest alternate/revised language. Recommendation 4: Change “created” to “stored”. Recommendation 5: WG to review revised text as suggested: “The Working Group recommends that the Registry notify the Registrar of Record after the Gaining Registrar has made [3-5] failed attempts to present a valid TAC to the Registry for a domain name, and for each successive failed attempt as long as a TAC is present. The Registrar of Record must notify the registrant that the failed attempts have taken place, and may take additional action, for example resetting the TAC.” Recommendations 6-11: WG to review and comment. Transfer Policy Review Phase 1 - Meeting #27 Tuesday 07 December 2021 at 16:00 UTC 1. Roll Call & SOI Updates * No updates provided. 2. Welcome & Chair updates (5 minutes) * Owen Smigelski: Questions about registrar type in the survey. Provided responses grouped by type and size. See attached. There are several types and we had responses to the survey from several different types and sizes. Could not correlate between type and size. Did seems to be more support for having locks than not, but could not correlate that response by type or size. 3. Rationale for elimination of the Gaining FOA (15 minutes) – see: Gaining FOA Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hd…> (beginning on p. 16) * Have not seen comments on the final revisions. We will read it out to see if there are more comments. We will come back to it so we aren’t done yet. * In October the WG agreed that we would draft a summary of the discussion on the elimination of the Gaining FOA. * We provided some of the background for context. Discussion: * Question: Why do we say this? “The Working Group believes that the notifications detailed in recommendations [xxx-xxx] ensure that the Registered Name Holder receives the necessary information when a key change has been made to their account.” This is no longer true based on current discussion. Answer: We have updated the text to reflect the recent discussion in the Losing FOA document and we’ll update the language here to be consistent. 4. Revisit TAC recommendations (60 minutes) – see: TAC Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…> (beginning on p. 15) * We updated this to no longer be candidate recommendations since we’ve reviewed it several times – now these are draft recommendations. * Not every charter question ended up with a recommendation. Charter Question b1) Is AuthInfo Code still a secure method for inter-registrar transfers? What evidence was used by the Working Group to make this determination? Recommendations 1-5: Recommendation 1: * Big change was to eliminate the confusion over terminology. * As an editorial comment – in place of the currently used term also add “and related terms” to be more inclusive. Don’t want to lose the opportunity to cover everything appropriate. ACTION ITEM: Revise text to (new text in brackets): “The Working Group recommends that the Transfer Policy and all related policies use the term “Transfer Authorization Code (TAC)” in place of the currently-used term “AuthInfo Code”[ and related terms].” Recommendation 2: * Are we consistent in terminology throughout when referencing the registrant? Should we be using Registered Name Holder? * Registrant and admin are the only ones authorized. * Registrant is not necessarily the account holder. Good to show the ultimate decision maker as the registrant. * Suggest change to “registrant or [their] designated representative” – new text in brackets. Need to be mindful of how this policy will work with the transfer dispute policy. * Some registrars use a designated agent for a transfer, so “designated representative” is still accurate. * The Definition should not exclude other security mechanisms. * Avoid using the administrative contact language since that is going away. * Question: To be precise, the admin contact in RDDS is going away, but is it conceivable that via the account panel that the RNH will assign a non-RDDS admin contact? How does a RNH go about designating that person? Answer: Could be that their provider that allows a log in for the account that provides access to certain things – they could give that info to a representative, but we shouldn’t get too specific here. * The sole Point is to reach the registrant, so we do not need to define the various opportunities. So, “send to the registrant” is sufficient. * Change “registrant” to Registered Name Holder” throughout? ACTION ITEM: Revise the wording (new text in brackets) to ““A Transfer Authorization Code (TAC) is a token created by the Registrar of Record and provided upon request to the registrant or [their designated representative.] Change “registrant” to “Registered Name Holder” throughout. Recommendation 3: * Question re: “ICANN org may change these requirements from time to time in response to new or updated standards, but any changes to the requirements must go in effect with sufficient [notification and] time for registrarsregistries to implement the necessary updates.” Is it normal for ICANN Org to establish this type of requirement? * If this were a protocol issue those statements would be done in the IETF. This is a security requirement. IETF is a source we can go to for this. Could be a statement that it “should be based on applicable security standards” and add a reference. * The key here is that ICANN would be initiating it – should other parties be able to initiate? * In the last sentence, change “registrars and registries” to “contracted parties”. * See IETF language at: https://datatracker.ietf.org/doc/draft-ietf-regext-secure-authinfo-transfer/ ACTION ITEM: WG members to suggest alternate/revised language. Recommendation 4: * Suggest it should say “stored” or “set” rather than “created”. ACTION ITEM: Change “created” to “stored”. Recommendation 5: * May need to look at this recommendation again for bulk transfers. * Question: Are we failing to set a new TAC, or providing the wrong TAC? Answer: We need to revise the language to make it clearer. * Question: If we are setting the number of failed attempts as a trigger, can ICANN Org change it later? Or is that a policy change? * Question: Should we set a period of time? * If you want to detect brute-force attempts then we should make that clear. Brute force was one example, could also just be a system error. * Could change to: “The Working Group recommends that, if the Gaining Registrar presents an invalid TAC [$number] times, or [$number within $period] times, the Registry MUST notify the Registrar of Record of the invalid attempts.” * Comment: from a security perspective – from the principle of wanting to provide protection to the registrant in this case there may be a malefactor involved so we are trying to provide an extra layer of protection. If everything is working as it should then the only risk here is that the value has been mis-entered. We should put a number here; a small number of attempts. Something to think about is the transfer should not be allowed if you have entered X number of failed attempts. Maybe the registry disables the transfer and make them go to get another TAC. * One thing to keep in mind, in order for this system to work if the registry is going to be telling you something it should be required – “MUST” not “MAY”. As a security mechanism using “MUST” makes more sense. * Number of failed attempts could be between 3-5. * Recalling earlier discussions: there were originally two formations of this recommendation. It sounded like the recommendation to cancel the transfer was not selected because it would be a way to derail a transfer. * If after the failed attempts (3 or 5), a notification to the registrant is sufficient. I think changing it automatically isn’t a good idea, as it’s done its job. * Clarify that this is per domain (issue of bulk transfers). * From a security perspective if you aren’t going to disable the transfer then you could force a reset; if you don’t want to do that you should say that the registry after X number of attempts an any attempt that failed you MUST send a notification. * A notification is sufficient of the failed attempts. * Suggest, “registrar of record MUST notify the registrant and MAY take further action such as resetting the TAC.” If we do say the registrar MUST notify we should decide if we need to provide a template for that communication. * What is the process for changing the number of failed attempts? If we put a number here do we need policy to change it? Maybe suggest a number to the IRT that they can update. ACTION ITEM: WG to review revised text as suggested: “The Working Group recommends that the Registry notify the Registrar of Record after the Gaining Registrar has made [3-5] failed attempts to present a valid TAC to the Registry for a domain name, and for each successive failed attempt as long as a TAC is present. The Registrar of Record must notify the registrant that the failed attempts have taken place, and may take additional action, for example resetting the TAC.” 5. AOB (5 minutes) * Next call: Tuesday 14 December 2021 at 16:00 UTC

1 0

15 MINUTES | **REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 07 December 2021 at 16:00 UTC
by Devan Reed Dec. 7, 2021

Dec. 7, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 07 December 2021 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/fwiHCg * Check your time zone: https://tinyurl.com/2p83v35x [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/2p83v35x__;!!PtGJab4!pfyUo3b…> 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, Devan

1 0

**REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 07 December 2021 at 16:00 UTC
by Julie Bisland Dec. 6, 2021

Dec. 6, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 07 December 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/fwiHCg * Check your time zone: https://tinyurl.com/2p83v35x [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/2p83v35x__;!!PtGJab4!pfyUo3b…> 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, Devan

1 0

Proposed agenda for meeting #27 on Tuesday 7 December 2021 at 16:00 UTC
by Emily Barabas Dec. 6, 2021

Dec. 6, 2021

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 7 December 2021 at 16:00 UTC. In addition to reviewing the latest versions of the resources linked below in the agenda, please note that the Losing FOA recommendations have been updated based on feedback during last week’s call (see Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?…> beginning on p. 14). Please take a few minutes to review and provide any feedback you may have. Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #27 Proposed Agenda Tuesday 7 December 2021 at 16:00 UTC 1. Roll Call & SOI updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 1. Rationale for elimination of the Gaining FOA (15 minutes) * Gaining FOA Working Document<https://docs.google.com/document/d/1QOCzbLh7w4hdijpAsg6_lybddr0nlsFDcWjdz5e…> (beginning on p. 16) 2. Revisit TAC recommendations (15 minutes) * TAC Working Document<https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…> (beginning on p. 15) 3. AOB (5 minutes) * Next call: Tuesday 14 December 2021 at 16:00 UTC

1 1

RrSG survey re: domain locks
by Owen Smigelski Dec. 3, 2021

Dec. 3, 2021

Hi all, Attached is the document I shared during Tuesday’s meeting regarding RrSG member feedback regarding domain name locks at creation and transfer. As requested, I added a breakdown by registrar type and size. I was not able to find any correlation between either registrar size or type and the preferred lock period. Please let me know if you have any questions. Regards, Owen

1 0

TPR-P1 // 30 Nov 2021 Project Package
by Berry Cobb Dec. 2, 2021

Dec. 2, 2021

Dear WG, Please find a link below to project package for the TPR-P1 PDP (30 Nov 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. * A PCR has been submitted to Council to include the NACK policy topics from Phase 2 into Phase 1A. 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

Post Call | Transfer Policy Review PDP WG | Tuesday, 30 November 2021
by Devan Reed Nov. 30, 2021

Nov. 30, 2021

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 30 November 2021 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/fQiHCg> (attendance included) and the GNSO Master calendar<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, Devan

1 0

With ical attached | Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 07 December 2021 at 16:00 UTC
by Devan Reed Nov. 30, 2021

Nov. 30, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 07 December 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/fwiHCg * Check your time zone: https://tinyurl.com/2p83v35x [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/2p83v35x__;!!PtGJab4!pfyUo3b…> 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, Devan

1 0

Notes and action items - TPR WG Meeting #26 - 30 Nov 2021
by Julie Hedlund Nov. 30, 2021

Nov. 30, 2021

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, 07 December at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items 1. Losing FOA Candidate Recommendations – see: Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?…> (beginning on p. 14) and Transfer Steps and Notifications [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/17ADMRTYx…> Candidate Recommendation #12: ACTION ITEM: Staff to amend footnote 1 as follows: “The Working Group recommends notes that, in place of the Losing FOA, notifications are sent to the RNH [in relation to an inter-registrar transfer] when key changes take place with their account in relation to a transfer, as detailed in recommendations 13-15.” Candidate Recommendations #13 and #14: ACTION ITEM: Staff to determine whether footnotes 2 and 3 need to be duplicates or if they can be combined. Candidate Recommendation #14: ACTION ITEM: Replace with new text suggested with clarification. ACTION ITEM: Jim Galvin to take the question to the Registries Stakeholder Group as to the feasibility of providing the IANA ID and/or name of the Gaining Registrar. Leave in the requirement in the candidate recommendation until we get a response. 2. Rationale for Elimination of the Gaining FOA – see: Gaining FOA Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hd…> (beginning on p. 16) ACTION ITEM: WG members should review the rationale for eliminating the Gaining FOA in preparation for next week’s meeting. Transfer Policy Review Phase 1 - Meeting #26 Tuesday 30 November 2021 at 16:00 UTC 1. Roll Call & SOI Updates * No updates provided. 2. Welcome & Chair updates * Reminder we are pulling forward from Phase 2 the NACKing section (section H of the charter) into Phase 1a. * Owen Smigelski re: Registrar Stakeholder Group survey regarding domain creation/transfer locks; see results at: https://docs.google.com/document/d/1-64Z4RqJB2sxR2aFbjt-YakafsjIrYixonfbHcC…. * Got 21 responses out of about 100 members. * There was a wide selection of respondents and regions. * Survey results seem to represent a wide range of opinion. * Question: Did you provide context such as proposed changes that would improve security? Answer: No, just want lock you would prefer and length. There was a comments section where some respondents provided rationale. * Question: Any talk about the opt in/opt out feature? Answer: No, that wasn’t included. * Question: In terms of responses received, can you correlate responses from older registrars versus newer ones? Answer: Do know how each registrar responded, but not sure how much detail I can provide and still keep the data anonymous. * Re: this poll and the AT-Large poll – the background information/context is crucial. Think about putting together a webinar with thoughts and perspectives on this. * Project Plan (see attached document): * WP Meeting #25: Losing FOA; Gaining FOA TPR WG 11/30/21 * WP Meeting #27: Gaining FOA; Revisit TAC TPR WG 12/07/21 * WP Meeting #28: Second reading of FOA/TAC; 60 day lock TPR WG 12/14/21 * WP Meeting #29: 60 day lock; NACK TPR WG 12/21/21 * WP Meeting #30: NACK TPR WG 01/04/22 * WP Meeting #31: Review recommendations package - Phase 1A TPR WG 01/11/22 * WP Meeting #32: Start bulk discussion TPR WG 01/18/22 3. Losing FOA Candidate Recommendations – see: Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?…> (beginning on p. 14) and Transfer Steps and Notifications [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/17ADMRTYx…> Candidate Recommendation #12: * Question re: footnote 1: Why is this written as a recommendation? See “The Working Group recommends that, in place of the Losing FOA, notifications are sent to the RNH when key changes take place with their account in relation to a transfer, as detailed in recommendations 13-15.” * Useful to clarify “losing registrar” is the pre-transfer registrar? Should consistently use “losing registrar” since that is in the policy. * Confirm that several members raised concerns with recommendation #12 that the context needs to be provided, which is the intention of the footnote. * Concerned that “when key changes take place with their account in relation to a transfer” isn’t clear. Leave that out and add the text in brackets: “[in relation to an inter-registrar transfer]” * Not sure resellers can be compliant with this recommendation. * The footnote is only supposed to say that we have decided to remove Losing FOA and do notifications instead as detailed in recommendations #13-#15. The footnote is not a recommendation itself. * ACTION ITEM: Staff to amend footnote 1 as follows: “The Working Group recommends notes that, in place of the Losing FOA, notifications are sent to the RNH [in relation to an inter-registrar transfer] when key changes take place with their account in relation to a transfer, as detailed in recommendations 13-15.” Candidate Recommendation #13: * Re: “The Working Group recommends that the Registrar of Record MUST send a notification [specify method of sending?] to the RNH (as listed in the Registration Data at the time of the TAC request) without undue delay but no later than [10 minutesperiod of time] after the Registrar of Record provides the TAC.” 10-minute time period seems too short. * Possible alternative approach to recommendations 13 & 15 -- Notification of TAC provision is always required when TAC is provided immediately upon request. Notification of TAC request is always required when there is period of time between TAC request and TAC provision. Could provide a conditional statement – different notifications depending on whether instant transfer or asynchronous. * For the moment #13 seems fine, but we may want to come back to it when we discuss bulk transfers. * ACTION ITEM: Staff to determine whether footnotes 2 and 3 need to be duplicates or if they can be combined. Candidate Recommendation #14: * Question: There is one bit of ambiguity: We start out talking about the transfer request and then jump to notification of transfer completion – which is it? Answer: This is about completion of transfer. * Requiring the IANA ID is a new requirement; not sure it is feasible. But this seems like good information to have, so we should require it and figure out now to do it? It could be a lot of work, but maybe the benefit outweighs the impact. * Is it really that useful? Is this really a likely scenario? * It is quite valuable information to have – where the domain name is going. From a registrant perspective it seems like an obviously good thing to know. If you have the IANA ID you can then look up the contact information. We should make this more user friendly. * If we're making a change to what's in the poll response, maybe we should focus on getting the Registrar name rather than IANA ID? RNH will find Registrar name more useful. * Jim Galvin said that they will ask this question of registries to understand the work that might be involved. * Staff working on diagraming the process flow based on the candidate recommendations and also will look at RFC 5731 “Extensible Provisioning Protocol (EPP) Domain Name Mapping”. * ACTION ITEM: Replace with new text suggested with clarification. * ACTION ITEM: Jim Galvin to take the question to the Registries Stakeholder Group as to the feasibility of providing the IANA ID and/or name of the Gaining Registrar. Leave in the requirement in the candidate recommendation until we get a response. Candidate Recommendation #15: * No changes needed as revised. Candidate Recommendation #16: * The WG determined that this was no longer needed so it has been deleted. Re: Record Keeping: * Are there recommendations for each topic area? Or in general? * Don’t most businesses already keep data? Do we have to require it? * If we do make recommendation concerning logs and data retention we could start with requirements to keep records of transfers but as required in the EPDP policy. * It could help to spell out the requirements. There is already current wording that we can look at about keeping logs and best practices. * Do we create global recommendations for transfer policy, or more precise recommendations for each area (TAC, etc.). 4. Rationale for Elimination of the Gaining FOA – see: Gaining FOA Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hd…> (beginning on p. 16) * ACTION ITEM: WG members should review the rationale for eliminating the Gaining FOA in preparation for next week’s meeting. 5. AOB: Next call Tuesday 7 December 2021 at 16:00 UTC.

1 0