- GNSO-TPR - lists.icann.org

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 06 December 2022
by Julie Bisland Dec. 1, 2022

Dec. 1, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 06 December 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/9wnVD * For other places see: https://tinyurl.com/2ysbxuu7 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, 01 December 2022
by Julie Bisland Dec. 1, 2022

Dec. 1, 2022

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Thursday, 01 December 2022 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/bYIFDQ> (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 #70 - 01 December 2022 at 16:00 UTC
by Julie Hedlund Dec. 1, 2022

Dec. 1, 2022

Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be on Tuesday, 06 December at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: Ongoing Action Items: 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. Action Items from 01 December: 1. Recommendation 13: Question to the Community -- Small Team on TTL Enforcement: Send the proposal to the list with rationale. 2. Transfer Process: Staff to provide an updated flow chart of the entire transfer process to reflect the recent agreement from the WG, when all aspects of the process has been agreed to by the WG. 3. Recommendations 2-9: Staff to release revised redline based on WG agreement. Notes: Transfer Policy Review - Meeting #70 Proposed Agenda 01 December 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates * Small Team on TTL: * AOB from Sarah Wyld: Request a recap of the entire transfer process to view the flow – staff to create a flow chart? Have lost track of what messages happen and when, so good to have a wholistic review. Take an action item to staff. * Small Team on Recommendation 13 on the TTL for the TAC and where the enforcement takes place: Specifically, “13.1: A standard Time to Live (TTL) for the TAC MUST be 14 calendar days from the time it is set at the Registry, enforced by the Registries.” Question to the community: Who is best positioned to manage the standard 14-day TTL – the Registry or the Registrar, and why? Are there specific implications if the TTL is managed by the Losing Registrar? 13.2: The Registrar of Record MAY set the TAC to null after a period of less than 14 days by agreement by the Registrar of Record and the RNH. * Compromise is to do a one-word edit to 13.1 to replace “Registries” with “Registrars” and add “A maximum TTL for the TAC MUST be 21 calendar days from the time it is set at the Registry, enforced by the Registry.” * Discussion: * Think this is making it a lot more complicated to have two solutions to one problem. Could be a lot of places for ambiguity. * This is a compromise because of how long it would take for some registrars to provide the take to RNHs. Downside is that we are changing the TTL to 21 days. * Registrars do feel strongly that this should be enforced by the registries. * Concern that the Losing Registrar could be in breach. * Additionally, the 'cooling period' of TAC existing but not necessarily usable (notice to RnH) that is allegedly replacing the RnH's agency to halt an unintended transfer based upon their notice that the current NACK provides - is also a factor at the front of the 14 days. * The 5-day period starts when it's set and issued, so if there's a delay from request to set/issue that delay is not coming out of the 14-day TTL period. * The 5-day period for the request of the TAC starts when the TAC is requested, not when it's set. * This is not straightforward – there are a lot of pieces involved. ACTION ITEM: Small Team on TTL Enforcement/Recommendation 13: Send the proposal to the list with rationale. ACTION ITEM: Staff to provide an updated flow chart of the entire transfer process to reflect the recent agreement from the WG, when all aspects of the process has been agreed to by the WG. 3. Review of Feedback on Recommendation 2 Strawman Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1e8iG6FmRD0M5…> (feedback document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1d7KwQH6poIxr…>) * Jim Galvin, RySG: IANA ID to the losing registrar. Discussion text had some language, but that was redlined out. Pull detail into the recommendation add: “Preliminary Recommendation xx: The Registry Operator MUST provide the Gaining Registrar’s IANA ID in the notification of a pending transfer request to the Losing Registrar, which will enable the Losing Registrar to provide this information in the [Losing FOA and] Notification of Transfer Completion.” * From Sarah Wyld (see Recommendation 2 Strawman at the link above): * What the process would look like: * 1. RNH unlocks domain and requests TAC from the Registrar of Record (Losing Rr) * 2. Losing Rr sends a TAC ACK email to the RNH saying “Someone requested a TAC; if this wasn’t you, click <NACKlink>. If it was you, you can either do nothing and we’ll provide you the TAC in 5 days or you can click <ACKlink> and we’ll give you the TAC right now” * a. If RNH clicks <NACKlink>, the TAC is never set at the Ry, and other things might happen (e.g. account password reset, etc) * b. If RNH clicks <ACKlink>, the Losing Rr provisions the TAC at the Ry and issues it to the RNH (Rec 3 Notification of TAC Issuance) * c. If no response, Losing Rr waits 5 days and then provisions the TAC at the Ry and issues it to the RNH (Rec 3 Notification of TAC Issuance) * 3. When the RNH receives the TAC, they provide it to the gaining Rr and the transfer is completed (Rec 4 “Notification of Transfer Completion” etc) * Doesn’t solve the problem of the TAC going out in the wild once it’s provisioned. Strawman added the IANA ID, but this doesn’t provide that. Strawman solves both issues. * See other comments, including from ALAC and BC, in the Recommendation 2 strawman document. * TechOps suggests as few changes as possible from the original design. * Might need to be a time for adjustment via the IRT. * There is a re-education aspect as well. * Note that if the WG doesn’t come to agreement, the current policy (Losing FOA) stands. * The agency piece of this is to give the registrant more power, but the difference is the timing – we don’t agree on the timing. * People need to be as concise as possible with their proposals. * Seems that there is general agreement from the WG to go with the strawman proposal. Not full consensus – most agree and some do not. 4. Review of Feedback on Revisions to Recommendations 3-9 (see pages 18-24 attached) (feedback document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1d7KwQH6poIxr…>) * Recommendation 8: Comments from Sarah Wyld – editorial issue. WG accepts the changes – will be incorporated into the next redline. * Comments from RySG: Incorporate into the next redline. ACTION ITEM: Recommendations 2-9: Staff to release revised redline based on WG agreement. 5. Revised Reasons that a Registrar of Record MAY Deny a Transfer – Recommendation 19 (Public Comment Review Tool<https://community.icann.org/display/TPRPDP/Phase+1A+-+Public+Comment+Review…> and Public Comment Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1trkihdcP80GA…>) c) Proposed edits: I.A.3.7.1 Potential next step: Consider whether “violation of registrar’s anti-abuse policies, or evidence of fraud” in the MAY category is an appropriate compromise. In brief, the alternatives presented in the comments: In the MAY category: * Evidence of fraud (status quo) * Violation of the Registrar's domain use or anti-abuse policies or evidence of fraud. OR Evidence of fraud, or violation of the Registrar’s domain use or anti-abuse policies. * Evidence of fraud, illegal activity, phishing, distribution of malware, or to comply with the law. In the MUST category: * The Registrar has knowledge of credible evidence of the domain currently being used for malware, phishing, pharming, or command & control botnets. Additional proposal: Move “Evidence of fraud” to the MUST category and include “violation of the Registrar’s domain use or anti-abuse policies” in the MAY category. WG discussion and agreement: * WG members generally agreed that this item should remain in the MAY category for the reasons summarized above. * Additional proposal from Sarah Wyld (29 Nov): “Evidence of fraud or the domain presents an active or continuing threat.” * The WG recalled that upcoming discussions on potential contract amendments (https://www.icann.org/en/system/files/correspondence/heineman-demetriou-to-…) may interact with discussion of potential edits to I.A.3.7.1. Discussion: * Lots of discussion on the last call. * Seems like there isn’t agreement of adding something beyond evidence of fraud. * What about adding “security” into Sarah’s proposal? Like - Evidence of fraud or the domain presents an active or continuing security threat? * What is a “security threat”? Do like “anti-abuse policies”. * It’s in our contracts that we have to obey the law: RAA 3.7.2 "Registrar shall abide by applicable laws and governmental regulations.” * We’ll never get agreement on exact text but if we can make it better we should try. * Can’t prevent registrars from complying with the law. Could see you blocking because of OFAC, but we also can’t try to interpret local laws. * Registrars will comply with local law regardless of policy. * Think everyone thinks that evidence of fraud is not enough, but don’t agree how defining something beyond that. If we can’t get to agreement it will stay evidence of fraud. * Still seems like keeping it in the “MAY” category makes sense.

1 0

**AT THE TOP OF THE HOUR** Meeting Invitation | Transfer Policy Review PDP WG call | Thursday, 01 December 2022
by Julie Bisland Dec. 1, 2022

Dec. 1, 2022

**AT THE TOP OF THE HOUR** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Thursday, 01 December 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/bYIFDQ * For other places see: https://tinyurl.com/2p9fx9c4 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/2p9fx9c4__;!!PtGJab4!8nzE2yy…> 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

Input Due 30 November: Draft Revisions to Recommendations 2-9
by Emily Barabas Dec. 1, 2022

Dec. 1, 2022

Dear working group members, As discussed on yesterday’s call, staff had an action item to provide a redline revision of the Initial Report reflecting agreed updates to Recommendations 3-9 (see pages 18-24), as well as a strawman draft of the new Recommendation 2 and response to Charter Question A7. The redline is attached. The Recommendation 2 strawman is available here<https://docs.google.com/document/d/1e8iG6FmRD0M5VlMUrmIedPw3burqfxLXQrkubxD…>. Please carefully review these documents in coordination with the groups you represent. If you feel that there are items that need to be revised, please enter them here<https://docs.google.com/document/d/1d7KwQH6poIxrafFYc5_1e1jQiiCA4WHqdNuRrx2…>. For each item, please include: * Report version (the date listed in the header of the document) and applicable line numbers ( these are listed along the left margin of the document). * Name and group you represent: If multiple WG members represent a group, input should be in coordination with these other members. * Rationale: please provide a clear explanation for why you are proposing the revision. * Specific proposed revision: Provide the language you would like to see added/removed/edited. The deadline for submitting input is 30 November 2022. After the deadline, the working group will discuss the items submitted in the input document. Following review of those items, the text will be considered stable. Please do not hesitate to reach out with any questions about the review process. Kind regards, Caitlin, Julie, Berry, and Emily Emily Barabas Policy Development Support Senior Manager Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

8 14

At-Large input to Strawman Revision - Phase 1A - Recommendation 2
by Steinar Grøtterød Dec. 1, 2022

Dec. 1, 2022

Dear Team, At-Large discussed the Strawman Revision - Phase 1A - Recommendation 2 at the At-Large Consolidated Policy Working Group (CPWG) meeting on Nov 30, 2022. The CPWG members attending the call agreed to recommend the Strawman proposal. However, there were CPWG members that proposed a system where the RNH must positively acknowledge the transfer to proceed when receiving the “Losing FOA” (in the Strawman version). Our understanding is that - with the Strawman recommendation for Rec. 2, no response from the RNH will result in the transfer starts after 5 days. We are sorry for not making the Nov 30, 2022, deadline. Hopefully, our comment will still be of value. Regards, Steinar Grøtterød At-Large

1 0

REMINDER | Meeting Invitation | Transfer Policy Review PDP WG call | Thursday, 01 December 2022
by Devan Reed Nov. 30, 2022

Nov. 30, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Thursday, 01 December 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/bYIFDQ * For other places see: https://tinyurl.com/2p9fx9c4 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/2p9fx9c4__;!!PtGJab4!8nzE2yy…> 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

DEADLINE TODAY: Input on Draft Revisions to Recommendations 2-9
by Emily Barabas Nov. 30, 2022

Nov. 30, 2022

Dear all, Today, Wednesday 30 November, is the deadline for input on the following: * redline revision of the Initial Report reflecting agreed updates to Recommendations 3-9. * strawman draft of the new Recommendation 2 and response to Charter Question A7. Please see details below. Kind regards, Caitlin, Julie, Berry, and Emily From: Emily Barabas <emily.barabas(a)icann.org> Date: Wednesday, 16 November 2022 at 18:18 To: "gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> Subject: Input Due 30 November: Draft Revisions to Recommendations 2-9 Dear working group members, As discussed on yesterday’s call, staff had an action item to provide a redline revision of the Initial Report reflecting agreed updates to Recommendations 3-9 (see pages 18-24), as well as a strawman draft of the new Recommendation 2 and response to Charter Question A7. The redline is attached. The Recommendation 2 strawman is available here<https://docs.google.com/document/d/1e8iG6FmRD0M5VlMUrmIedPw3burqfxLXQrkubxD…>. Please carefully review these documents in coordination with the groups you represent. If you feel that there are items that need to be revised, please enter them here<https://docs.google.com/document/d/1d7KwQH6poIxrafFYc5_1e1jQiiCA4WHqdNuRrx2…>. For each item, please include: * Report version (the date listed in the header of the document) and applicable line numbers ( these are listed along the left margin of the document). * Name and group you represent: If multiple WG members represent a group, input should be in coordination with these other members. * Rationale: please provide a clear explanation for why you are proposing the revision. * Specific proposed revision: Provide the language you would like to see added/removed/edited. The deadline for submitting input is 30 November 2022. After the deadline, the working group will discuss the items submitted in the input document. Following review of those items, the text will be considered stable. Please do not hesitate to reach out with any questions about the review process. Kind regards, Caitlin, Julie, Berry, and Emily Emily Barabas Policy Development Support Senior Manager Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0

Proposed agenda for meeting #70 on Thursday 1 December 2022 at 16:00 UTC
by Emily Barabas Nov. 29, 2022

Nov. 29, 2022

Dear Working Group members, Please find below the proposed agenda for the next meeting scheduled to take place on Thursday 1 December 2022 at 16:00 UTC. Prior to the call, please review the documents linked in the agenda below. Kind regards, Emily, Julie, Berry, and Caitlin ________________________________________________________________________________________________ Transfer Policy Review - Meeting #70 Proposed Agenda 1 December 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates 1. Review of Feedback on Recommendation 2 Strawman Document<https://docs.google.com/document/d/1e8iG6FmRD0M5VlMUrmIedPw3burqfxLXQrkubxD…> (feedback document<https://docs.google.com/document/d/1d7KwQH6poIxrafFYc5_1e1jQiiCA4WHqdNuRrx2…>) 2. Review of Feedback on Revisions to Recommendations 3-9 (see pages 18-24 attached) (feedback document<https://docs.google.com/document/d/1d7KwQH6poIxrafFYc5_1e1jQiiCA4WHqdNuRrx2…>) 3. Revised Reasons that a Registrar of Record MAY Deny a Transfer – Recommendation 19 (Public Comment Review Tool<https://community.icann.org/display/TPRPDP/Phase+1A+-+Public+Comment+Review…> and Public Comment Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1trkihdcP80GA…>) 4. New Reasons that a Registrar a Record MUST Deny a Transfer – Recommendation 20 (Public Comment Review Tool<https://community.icann.org/display/TPRPDP/Phase+1A+-+Public+Comment+Review…> and Public Comment Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1VkFtTdlrwDmz…>) 5. Revised Reasons that a Registrar of Record MUST Deny a Transfer – Recommendation 21 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcr…> and Public Comment Working Document<https://docs.google.com/document/d/1SlBZKawRXBNmk4zHy9E_4wePW-q0z24sbwxFK_N…>) 6. Revised Reasons that a Registrar of Record MUST NOT Deny a Transfer – Recommendation 22 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcr…> and Public Comment Working Document<https://docs.google.com/document/d/1h8w7bjDYUHnfg8zJGZskF21KcumgE12KvZZDeBt…>) 7. AOB

1 0

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

Nov. 29, 2022

Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be on Thursday, 01 December at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: Ongoing Action Items: 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. 2. Recommendation 13: Question to the community – Small Team to consider whether to 1) maintain the recommendation as is – that the registries enforces; 2) add language to the current recommendation; 3) change it to the Registrars to manage the TTL; or 4) not to specify who enforces it. Volunteers are: Jim Galvin, Rick Wilhelm, Jody Kolker, and John Woodworth. Action Items from 29 November: 1. Recommendation 15 -- Staff to update the rationale for Recommendations 3 and 4 to reflect the further consideration of the WG, and also update the Working Document for Recommendation 15. 2. Recommendation 18, a) Proposed Edit – Staff will split the two sentences and revise the language of the first sentence to add “upon request” as relating to the phrase “the potential Gaining Registrar with the reason for denial”. 3. Recommendation 19, c) Proposed edits: I.A.3.7.1: WG members to review with their groups and suggest language to accommodate the public comments. Notes: Transfer Policy Review - Meeting #69 Proposed Agenda 29 November 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates * Reminder of deadlines of 30 November: * Strawman proposal for Recommendation 2; * Redlines for Recommendations 3-9. * Two Small Teams meeting this week and next. * Small Team on threat vectors to provide their write up this week. * Comments on Creation Date and Initial Registration Date – include a footnote clarifying that when we say Initial Registration Date we mean Creation Date. * Zak – raised strawman on Recommendation 2 with the BC – helpful to drop any comments provided on the list and can provide any further explanation on the call on Thursday. 3. Recommendation 15 * There was a comment put forward with respect to Recommendation 15. * Comments suggested that notification should go to the Tech contact and not just the RNH. WG agreed that it could be useful for the notification to be sent to other contacts, but that it should be left to the registrar with no additional mandates. Could see some registrars choosing to send to tech contacts, but that others might not have a need. * Consider slightly amending the rationale. We could say “draft registration data policy” and a footnote that it is under consideration but likely to become policy. Maybe we state that due to the draft consensus policy it won’t be required to collect this data so we shouldn’t rely on it. Note that the recommendations have been adopted, but not policy until the policy effective date. * Do we put language into the notifications or leave it to the registrar? Not sure there is agreement, but we can update the rationale. * Confirm that if we adjust the recommendation text it would be under recommendations 3 and 4? Intent is not to add anything except in the rationale to show that we discussed it and that the WG agreed it should be at the registrars’ discretion. This would be for the rationale for 3 and 4 with a pointer at Recommendation 15 in the Working Document. ACTION ITEM: Recommendation 15 -- Staff to update the rationale for Recommendations 3 and 4 to reflect the further consideration of the WG, and also update the Working Document for Recommendation 15. 4. Transfer Restriction After Inter-Registrar Transfer – Recommendation 17 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcr…> and Public Comment Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1yTeU5FTqfXt5…>) * Much of the comments are a repeat of comments for Recommendation 16 and have already been discussed by the WG. * ALAC discussion: Locks should be the same for all for consistency and there shouldn’t be any opt out. There is a Small Team looking at possible reasons for override. * Could be legal reasons to allow an override. * Once a registrant moves out of a registrar the ability of the Losing Registrar to help that registrant is restrict. * Consider how many times the domain has been transferred. * Is it technically possible to have the “release date/time” been displayed in the WHOIS/RDAP output? * ccTLDs don’t have the 30-day lock because they aren’t afraid to get involved in disputes. * European - in general, do not add another year to the lifecycle when transferred. * All gTLD do currently, absent bulk transfer, add 1 year. * Current policy does have 60 days, so we are just making a rationale for 30 days – don’t hear an argument for changing that recommendation. * Current 60-day lock is optional – to be consistent we are recommendation that the 30-day locks should be mandatory. * WG agrees with not changing Recommendations 16 and 17. 5. Format of Transfer Policy Section 1.A.3.7 – Recommendation 18 (Public Comment Review Tool<https://community.icann.org/display/TPRPDP/Phase+1A+-+Public+Comment+Review…> and Public Comment Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1IwufJ7Os2cAq…>) a) Proposed Edit: Add a sentence that recommends updating Section I.A.3.7 of the policy to make it clear that Registrars can not directly provide the reason for the denial to the potential Gaining Registrar. Potential next step: Strawman redline “Upon denying a transfer request for any of the following reasons, the Registrar of Record must provide the Registered Name Holder and the potential Gaining Registrar with the reason for denial to the Registered Name Holder and the Registry, and the Registry will pass the reason for the denial to the potential Gaining Registrar. . .” Discussion: * Not sure how the Registry would be able to pass the reason back to the potential Gaining Registrar. * Not clear how we would do this on an operational level in the EPP. * Current policy states that it goes to the RNH and to the Gaining Registrar. * The Registry comment is that we can’t pass on the reason for denial. There is not a mechanism to do that – no systemic way to do this. * Technical detail – the Registrar of Record doesn’t know the Gaining Registrar. There is no link to the Gaining Registrar. * The act of telling the Gaining Registrar is simply not possible. Would have to take the recommendation back to the RySG. This would be a substantive change to the policy. * So the pass-thru requirement would create a variety of ad-hoc solutions to provide the reason for denial. * Registrars only receive an ID of the gaining registrar, which only maps to the id of the gaining registrar in the registry system which the losing registrar does not have the mapping of the ID to the gaining registrar. * I'm confused because notifying the gaining Rr is the current policy obligation. But also it does not seem possible in an automated manner. So now i'm considering if just removing it would cause problems. * No way to do this even if the RNH provides the contact information for the Gaining Registrar. * Maybe we should discuss what would be the problem with removing the requirement to notify. * I thought also on this 18.a that we added the words ", upon request." because this was something that would be difficult to make consistent. * Providing the reason the transfer was denied, upon request, to the registrant or registry does make sense. The way this is worded currently it seems to create a burden of doing this EVERY TIME. * The RNH is the real one who needs to know why the transfer failed, let's just tell them. Upon request is also reasonable, but I would rather it be the default to notify the RNH of the reason. * Maybe we admit that this is not an automatic reply to the Gaining Registrar – the Gaining Registrar has to ask. * All the WG recommended was two split the two sentences into two recommendations. * Don’t think there is anything the WG needs to do. This isn’t a requirement in the current policy. * I think adding "upon request" for the gaining registrar should be added, and probably "always" for contacting the RNH. * Adding “upon request” doesn’t add anything to what the current policy says, since there is no obligation. * Support for splitting the two concepts and adding the language “upon request”. ACTION ITEM: Recommendation 18, a) Proposed Edit – Staff will split the two sentences and revise the language of the first sentence to add “upon request” as relating to the phrase “the potential Gaining Registrar with the reason for denial”. b) Additional Consideration: We suggest that the portion of the Transfer Policy which specifically includes restrictions on transfers, if any, be reproduced in a separate companion document that is in an easily understandable format for average registrants, along with commentary and guidance provided by ICANN. Rec 18: #4 Potential Next Step: WG to consider whether an Implementation Note is appropriate. Discussion: * Not sure an Implementation Note is appropriate. * Have to be very careful not to introduce ambiguity. Would need to make sure this doesn’t introduce anything new – maybe do it just as a pointer. * This is something that ICANN does anyway. There is already a resource page that could be updated. * Do we provide language saying that existing resources should be updated to reflect the new policy. Not sure we need to say it; should be standard procedure. Also could be discussed in the IRT. A policy recommendation may not be necessary. * WG agrees that no changes are necessary. 6. Revised Reasons that a Registrar of Record MAY Deny a Transfer – Recommendation 19 (Public Comment Review Tool<https://community.icann.org/display/TPRPDP/Phase+1A+-+Public+Comment+Review…> and Public Comment Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1trkihdcP80GA…>) a) Concern: We don’t believe that recommending reasons that registrars MAY deny a transfer request is within the scope of this group. ICANN contractual has to use the usual legal tools to interpret compliance rules. These recommendations can be abused and be interpreted broadly. Rec 19: #8 Potential next step: In previous discussions, WG members expressed that the “MAY” category gives flexibility for Registrars to deny a transfer in specific circumstances but does not require them to do so where a denial is unwarranted. From this perspective, the “MAY” category continues to be appropriate. WG to consider if any additional language should be added to the Report to give additional context. WG discussion and agreement: The Working Group considered that the “MAY” category already exists within the policy so considering the items in this category is within scope for the WG. Absent a compelling reason to eliminate this category, it should remain in the policy. The WG noted that there may be undesirable consequences if all items in the MAY category became MUST. For example, if a registrar is based in a jurisdiction where certain speech is considered fraud, they would be required to prevent the registrant from transferring the domain to a registrar in a jurisdiction where that speech is permitted. Therefore it is better to provide some level of discretion to registrars in specific types of cases. Specifically on NCSG concerns that the WG should address the issue of sanctions, one WG member noted that It is up to the registry and registrar to comply with the law. When sanctions are applicable, contracted parties need to comply. That is why it is outside the scope of ICANN policy development. Discussion: * The WG has already considered this; no need to discuss it further. c) Proposed edits: I.A.3.7.1 Potential next step: Consider whether “violation of registrar’s anti-abuse policies, or evidence of fraud” in the MAY category is an appropriate compromise. In brief, the alternatives presented in the comments: In the MAY category: * Evidence of fraud (status quo) * Violation of the Registrar's domain use or anti-abuse policies or evidence of fraud. OR Evidence of fraud, or violation of the Registrar’s domain use or anti-abuse policies. * Evidence of fraud, illegal activity, phishing, distribution of malware, or to comply with the law. In the MUST category: * The Registrar has knowledge of credible evidence of the domain currently being used for malware, phishing, pharming, or command & control botnets. Additional proposal: Move “Evidence of fraud” to the MUST category and include “violation of the Registrar’s domain use or anti-abuse policies” in the MAY category. Discussion: * Suggest tying to the upcoming contract updates. * Abuse negotiations are currently still in the formation stage, and not yet officially started. * Seems like it fits better in the “MAY” category. Logic still makes sense to keep this as a “MAY”. * not specifically tying but sort of being aware of it as we write our language here * Change to something like "“Evidence of fraud or the domain presents an active or continuing threat”. * We have to consider that the Registrar may use different reputation block lists, hence a NACK due to “credible evidence” may be not understand by the RNH or the Gaining Registrar. * Wouldn’t want something to become a must to interfere with contract negotiations on DNS abuse. * WG agrees to keep it as “MAY”. * Is there a path to expand beyond evidence of fraud? Tie to updates to the contract under discussion? * Suggestion: ““Evidence of fraud or the domain presents an active or continuing threat”. * Reluctant to allow anything based on possible future policies. * Like the compromise language: “include “violation of the Registrar’s domain use or anti-abuse policies” in the MAY category.” * “Evidence of fraud or violation of the Registrar’s domain use or anti-abuse policies.” is the language in the Initial Report. ACTION ITEM: Recommendation 19, c) Proposed edits: I.A.3.7.1: WG members to review with their groups and suggest language to accommodate the public comments.

1 0