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/1e8iG6FmRD0M5VlMUrmIedPw3burqfxLXQrkubxDJ3oQ/edit?usp=sharing__;!!PtGJab4!-MBrP5qp2XONoJwbo2m7MEPm-BAXozIdc6qJiedJrq9QuMZ1Gk5qR15mKHyvtNpCJ7EnsTBXWoKBsuOCjGOlhcxhmw00lg6xWg$> (feedback document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1d7KwQH6poIxrafFYc5_1e1jQiiCA4WHqdNuRrx2IfWY/edit?usp=sharing__;!!PtGJab4!-MBrP5qp2XONoJwbo2m7MEPm-BAXozIdc6qJiedJrq9QuMZ1Gk5qR15mKHyvtNpCJ7EnsTBXWoKBsuOCjGOlhcxhmw0IQ4agMw$>) * 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/1d7KwQH6poIxrafFYc5_1e1jQiiCA4WHqdNuRrx2IfWY/edit?usp=sharing__;!!PtGJab4!-MBrP5qp2XONoJwbo2m7MEPm-BAXozIdc6qJiedJrq9QuMZ1Gk5qR15mKHyvtNpCJ7EnsTBXWoKBsuOCjGOlhcxhmw0IQ4agMw$>) * 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+Tool?preview=/201949311/212107986/gnso-TPR-P1A-pcrt-Initial-Report-Recommendations_Rec%2019_20220829.docx> and Public Comment Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1trkihdcP80GAJL0a9PFn1L1bER464bvTyzk_IDSCgA4/edit__;!!PtGJab4!-nISIddQI1mDpTj7PoZiBrFnP7d7con3eClqvn9UBEO_S2gt_wldyM24r2vYcIP0uy0rVTJyO-a-mj8U1jgw_pqhEZrvYfDm8dpu$>) 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-m...) 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.