Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be in one week on Tuesday, 29 November 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 22 November: 1. Recommendation 14, b) Proposed edit: Staff to revise the rationale to explain why the WG agreed not to make this change, and to revise the text to also include the Registry Agreement (RA) in addition to the text in the rationale of calling out the RAA. 2. Recommendation 16, c) Concern – period should be possible to override and Recommendation 17, b) Concern - period should be possible to override: Staff to call for a Small Team to develop language on an override with guardrails, both on post-create and post-transfer. Also Volunteers during the meeting are Zak, Owen, and Keiron. Notes: Transfer Policy Review - Meeting #68 Proposed Agenda 21 November 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates * Reminders on timelines: Wednesday, 30 November comments on Recommendation 2 are due, as well as any updates to the first 9 recommendations. WG members are urged to review. * Note that there is no meeting this Thursday due to the US holiday. 3. Terminology Updates: Whois – Recommendation 14 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> and Public Comment Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1VOwh3d7bieJI1...>) [No comments received on Recommendation 15] a) Proposed edit Include an Implementation Note clarifying that “‘Registration Data’ in case of a domain with an active P/P service means the underlying customer, not the publicly-displayed P/P data.” Potential next step: WG to consider whether this implementation note should be added. Discussion: * Be careful not to overlap; maybe just include in the Implementation note. * Definition from draft Reg Data Policy out for PC: "Registration Data" means the data element values collected from a natural or legal person or generated by Registrar or Registry Operator, in either case in connection with a Registered Name in accordance with Section 6 of this Policy. * Suggest not adding an implementation note. * WG agrees not to add an implementation note. b) Proposed edit Replace "Registration Data" with "RDDS Data" in paragraphs (i) and (ii) for clarity, consistency, and legality, as the term "Registration Data" would be viewed as much broader under GDPR and would include, e.g., REGISTRANT's credit card data obtained and processed by the REGISTRAR as part of the domain name "Registration" and renewal processes. Potential next step: WG to consider whether this edit is appropriate. Discussion: * WG agrees that no change is needed, although staff could take an action item to include the justification in the rationale of the Final Report. * WG agrees to revise the text to also include the Registry Agreement (RA) in addition to the text in the rationale of calling out the RAA. ACTION ITEM: Recommendation 14, b) Proposed edit: Staff to revise the rationale to explain why the WG agreed not to make this change, and to revise the text to also include the Registry Agreement (RA) in addition to the text in the rationale of calling out the RAA. 4. Transfer Restriction After Initial Registration – Recommendation 16 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> and Public Comment Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1lPqhvP6ekFafg...>) a) Concern – period should be longer and b) Concern – period should be shorter: Discussion: * WG discussed both longer and shorter time periods and 30 days was the compromise. * WG agrees to keep the time period at 30 days. c) Concern - period should be possible to override It should always be up to a registrar and its customer - the registrant - to agree to override any default restriction in appropriate circumstances. The RrSG proposes that registrars should be able to override a transfer lock period, as part of the “fast undo” transfer-reversal process (which will be discussed in a later phase of this PDP WG) or in the event that the registration violates the registrar’s Terms of Service, Acceptable Use Policy, etc. Discussion: * Should be a high bar to override and noting that we should maintain the consistency of application. * Comments seem to support a potential override between a registrar and customer, but there are security reasons to have locks. So if a registrar looks at the circumstances they should be able to override the locks if there are no security concerns. * Is it still not a possibility that there is a violation of AUP or TOS to be able to transfer the name? Any override disrupts the primary principle for why we wanted to make this consistent. If the WG agrees to an override it should provide consistent guidance of when it can happen and when it can’t. Need that clarity for Compliance, as to what can trigger an override. We have tried to be consistent in the time periods in all of these cases. * We are consolidating policies, and when we bring these together we need some kind of unity/conformity. * Should separate this from the fast-undo override. * Don’t hear any guardrails on the override. Registrars can just decide to remove the lock whenever they want – opening it up for abuse. * Revisit the reason for the lock – if the issue is fraud prevention then the registrar could take that risk. Could say as a guardrail that there couldn’t be a blanket override – it must be per domain name. * Need to be clear what we mean by abusing the lock. If the registrar has a an agreement to release it, it should be able to. * We should go back to the rationale for the original recommendation – consistency, transparency, user experience, security – see below. Thought we discussed the reasons to make the lock mandatory. * We agreed the lock was important for the reasons below and never got to a good reason for an override. * Maybe it should be optional from the registrar’s point of view, but for the registrant and a gaining registrar, this is a mitigation against high jacking. If you make it optional then you take that aspect out of the security profile. If you take it away the transfer confirmation (Losing FOA) is more important, but it still doesn’t replace the security of the 30-day lock. * If registrars agree to allow lock override you are agreeing to allow customers to transfer away. * Don’t think the security rationale addresses why you couldn’t have an override if the registrar and registrant agree on a case-by-case basis. * Case by case, creates ambiguity for compliance to enforce. * Override doesn’t mitigate hijacking of the account at the RoR. * If you make it optional and up to the registrar, then there’s no point in putting it into the policy, and we just go back to what we had before. * Could create a small team to develop override language with guardrails. * But full WG would need to come to consensus on this language and could require another public comment period. * We’ll move forward on the 30-day lock recommendation if no agreement. ACTION ITEM: Recommendation 16, c) Concern – period should be possible to override and Recommendation 17, b) Concern - period should be possible to override: Staff to call for a Small Team to develop language on an override with guardrails, both on post-create and post-transfer. Also Volunteers during the meeting are Zak, Owen, and Keiron. Rationale: The working group believes that a single requirement across the industry will result in a better experience for registrants. The working group recommends that 30 days is the appropriate period for this requirement because: * It provides a window of opportunity to identify issues associated with credit card payments, including unauthorized use of a credit card. This may assist with addressing criminal activity and deterring fraud. * It provides a window of opportunity for a complainant to file a Uniform Domain Name Dispute Resolution Policy (UDRP) proceeding without the domain being transferred to a new registrar. Once the proceeding is underway, the domain will be locked in relation to the dispute. * For registrants who legitimately want to transfer a domain shortly after registration, the working group believes that 30 days is a reasonable period of time to wait. d) Concern - period should be eliminated and 3) Concerns – other Discussion: * We discussed these issues, don’t think any of them warrant changes. * Registries are not going to enforce. * Preference between registration date and creation date? Internal consistency is reasonable. Make sure we are consistent with what we use. c) Proposed edit: ICANN org suggests the WG to review the means through which these mandatory restrictions must be implemented, preferably using the standard EPP status codes. EPP status codes, in addition to restricting transform-commands (e.g., clientTransferProhibited restricts transfer requests), are also a signaling mechanism that is shown in RDDS. Potential next step: If the WG supports this change, org suggests the following Strawman revision “The Registrar MUST restrict the RNH from transferring a domain name to a new Registrar within 30 days of the initial registration date by setting the appropriate EPP status(es) in the Registry system.” Discussion: * Think the WG covered this and we purposing left it generic. * Given where we are with these types of restrictions, we need to be careful about those that only involve the Registrar or Record, as not sure those would need to be managed by the EPP codes. * WG agrees to not make the change. 5. Transfer Restriction After Inter-Registrar transfer – Recommendation 17 (Public Comment Review Tool<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> and Public Comment Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1yTeU5FTqfXt59...>) * Almost identical comments as those that were received on Recommendation 16 due to similarities. * Except for the comment about a registrant dispute mechanism. * WG should review the comments in detail in preparation for the next call, keeping a frame of reference with the Change of Registrant (CoR) discussions. * Specifically to these questions, the small team on overrides should look at 16 and 17, so not sure we need to discuss them. * This the WG has covered a) and b), also c), and then the WG has previously discussed d) and e). * WG agrees to stay with the original language, except in the case of override, see above for the small team. 6. AOB