Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be on Thursday, 08 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. Recommendation 19: Sarah Wyld to send the proposed revised language and rationale to the WG list on behalf of the Small Team. 3. Recommendation 22: * a) Concern: Fees and b) Concern: Sanctions: Staff to ensure that the rationale reflects the WG’s discussion and agreement. * c) Proposed edit: WG agrees to a revision to the Implementation Guidance as proposed in the Potential next step. Notes: Transfer Policy Review - Meeting #71 Proposed Agenda 06 December 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates Summary of Process Updates from Staff sent to the list: Process updates * Rec 2 – Addition of Losing FOA * Rec xx – Registry Operator provides Gaining Rr’s IANA ID to Losing Rr in the notification of pending transfer request, to be included in Losing FOA and Notification of Transfer Completion Open Items * Rec 6 – RrSG reps may suggest further clarifications regarding the designated representative * Rec 11 – RySG reps may suggest further clarifications regarding when the TAC is considered “used” and is reset to null, relationship to TTL, and/or interaction with Ry Lock * Rec 13 – Small team is working on a proposal regarding TTL enforcement * Rec 16 & 17 – Small team is working on a proposal for exceptions to post-create and post-transfer restrictions on transfer * General – Small group is working on developing a list of threat vectors that the proposed security model is and is not intended to address Additional Updates: * Rec 11: * The TAC is used when the registry accepts it; if the registry denies the transfer request the TTL would live on and the TAC could still be used. The ACK/NACK is still valid. * Registries have some research on the reasons why a registry MAY and MUST deny a transfer. * The Gaining Registrar can validate a TAC with an INFO Command – but this does not constitute using it. * INFO command has been around for a long time to validate the TAC. Many registries have mechanisms in place to detect brute force attacks. RFC 9154 greatly reduces possibility of brute force attacks. * Rec 13: Probably need to meet one more time, at least. * Rec 16 & 17: Meeting one more time to see if they can agree on a proposal for the WG to consider. 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/1trkihdcP80GAJ...>) * Extensive discussion on the last call on the wording, “Evidence of fraud or violation of the Registrar’s domain use or anti-abuse policies.” * There was no strong agreement to change that wording. * Without agreement on changes or on what is in the Initial Report, we would stay with the status quo, which is “evidence of fraud”. * Could be helpful to establish a small team to re-evaluate the language over the next week. ACTION ITEM: Recommendation 19: Small team to re-evaluate the language in Rec 19 -- WG members are -- Owen Smigelski, Sarah Wyld, Keiron Tobin, Zak Muscovitch, and Volker Greiman. See below. 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/1VkFtTdlrwDmzu...>) a) Concerns We do wish to mention here that the "general objection to all transfer requests received by the Registrar, either temporarily or indefinitely." can be made even stronger by our proposal in section I (TIMELOCK ACCESS TO TAC GENERATOR, AKA "VACATION MODE" or "LOCKDOWN MODE") of our submission. Also, the "express objection to the transfer" will be ineffective if the Losing FOA is eliminated, and/or it's too late if the transfer has already completed before the registrant has the opportunity to learn of an unauthorized transfer. Thus, the Losing FOA must be retained (at least as an option!). For the time limits in I.A.3.7.5 and I.A.3.7.6, it makes more sense to us for the registry to enforce the times, rather than the registrar. Potential next step: WG to consider the extent to which these comments were addressed in deliberations on previous comments. Discussion: * WG members agreed that this was discussed and addressed; no further change are needed. b) Proposed Edit Fraud is one example of an abusive activity that registrars must prohibit in their Registration Agreement with Registrants. Edit language to further empower registrars to deny transfers for abusive behaviour, while also ensuring that the registrar has evidence of the abusive behaviour. Add new reason that registrars MUST deny a transfer (currently a MAY): “The Registrar of Record has credible evidence of fraud.” Potential next step: WG to consider whether this comment introduces new information that should be further considered. Discussion: * WG members agreed that this was discussed and addressed; agreed to keep the language as “MAY”. 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-pcrt...> and Public Comment Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1SlBZKawRXBNmk...>) a) Concern regarding I.A.3.8.1 and I.A.3.8.2 The RrSG notes that the notification of UDRP or URS procedure must come from the Provider and as such there may in some cases be a delay between the time of registration and the time of notification of the dispute. It is important that the timing of transfer denials be carefully considered to ensure that a registrant does not move between registrars in order to avoid the UDRP or URS and, should that occur, rollback of the transfer in these scenarios should be considered in the appropriate phase of this TPR WG. Rec 21: #4 Potential next step: WG to discuss if any additional adjustments need to be made to the recommendations with respect to this issue in the Phase I recommendations. Rollbacks will be considered in Phase II. Discussion: * WG members agreed that this was discussed and addressed; no further change are needed 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-pcrt...> and Public Comment Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1h8w7bjDYUHnfg...>) a) Concern: Fees (I.A.3.9.1) Transfer Policy Fee: We have heard there are cases of high transfer fees in some registrars. This is especially very restrictive for noncommercial users. Therefore, as the policy recommendations mentions the ground nonpayment as one of the denial of transfer, we expect to see the issue of high fees in terms of domain name transfer be fully discussed and addressed by the working group and requiring unreasonable fees be discouraged. A Registrar may not withhold a domain name transfer; however, we have seen some Registrars charge their customers significant fees for moving their domain names away. . .It is our view that Registrants should not be forced to pay "exit" fees when they are trying to move to a new Registrar that better suits their needs. We have reviewed such a third-party agreement (between a Registrar and Registrant), and the terms regarding exit fees were ambiguous at best, but without a clear policy to deal with this issue, it created an opportunity for the Registrar in question to use transfer out fees as a tool to deter their clients from leaving. If the goal of the transfer policy is to provide for enhanced domain name portability, resulting in greater consumer and business choice, then these fees fly in the face of this fundamental principle and should not be allowed. b) Concern: Sanctions We believe if you discuss the reasons that MAY deny a transfer, sanctions should be discussed as a reason. Ordinary noncommercial registrants who are not on special designated national list are subject to discrimination and on several instances transfer of domain names are not allowed by the registrar, the registrars just confiscate it. The working group decided not to discuss this issue or even dismiss it. We invite the working group to at least highlight the issue and if it believes it’s out of scope, express it. Rec 22: #5 Potential next step: If the WG continues to believe that these topics are out of scope, consider adding language in the Final Report in this regard providing additional rationale. Discussion: * WG did discuss fees and addressed that in the language. Registrar can charge a fee, but registrant doesn’t have to pay that. * We can add in the rationale that the WG discussed fees and agreed that it was out of scope. * The WG also agreed that sanctions also are out of scope. This also would duplicate the work in Work Stream 2. ACTION ITEM: Recommendation 22, a) Concern: Fees and b) Concern: Sanctions: Staff to ensure that the rationale reflects the WG’s discussion and agreement. c) Concern: Other With regard to transfer restrictions, we reiterate our concerns regarding the proposed restrictions as set out above, and we will have more comments on change of registrant restrictions when the issue is addressed in Phase 1(b). Rec 22: #7 Potential next step: WG to consider if this comment raises any new issues that need to be discussed. Discussion: * WG has no further comments. * WG agrees that no changes are necessary. c) Proposed Edit I.A.3.9.1: Current Guidance implies that these reasons only apply during the Auto-Renew Grace Period but they are intended to always apply. Recommend removal of “during the Auto-Renew Grace Period, provided that any auto-renewal costs borne by the Registrar are reversible for future period” so that the Guidance says: “Implementation Guidance: Registrars are prohibited from denying domain name transfer requests based on non- payment of fees for pending or future registration periods during the Auto-Renew Grace Period, provided that any auto-renewal costs borne by the Registrar are reversible for future period.” Potential next step: The original intention of the Implementation Guidance was to provide guidance specifically addressing questions that have come up surrounding the Auto-Renew Grace Period. Potential revision: “Implementation Guidance regarding the Auto-Renew Grace Period: Registrars are prohibited from denying domain name transfer requests based on non- payment of fees for pending or future registration periods during the Auto-Renew Grace Period, provided that any auto-renewal costs borne by the Registrar are reversible for future period.” Discussion: * Suggested edit is basically making the Implementation Note the same as the policy provision. * Suggestion from staff is to emphasize that the Implementation Guidance is specifically about the Auto-Renew Grace Period. ACTION ITEM: Recommendation 22, c) Proposed edit: WG agrees to a revision to the Implementation Guidance as proposed in the Potential next step. d) Proposed edit in I.A.3.9.2, the default behaviour from a security point of view should be to deny a transfer, unless you have affirmative consent (i.e. if there's no "ACK", then the transfer should be denied, even if there's no "NACK"). Potential next step: This suggestion is being discussed and considered in the context of discussions regarding the Losing FOA. e) Proposed edit "Silence" (i.e. no response) should be interpreted conservatively. So, in I.A.3.9.2, the default behaviour from a security point of view should be to deny a transfer, unless you have affirmative consent (i.e. if there's no "ACK", then the transfer should be denied, even if there's no "NACK"). That's how things once used to be, but then it got changed to where the transfer would automatically go through by default, if there was no response. This is the "UltraSecure" option mentioned above (section F. "THE BEST OF BOTH WORLDS" PROPOSAL TO RETAIN THE LOSING FOA ON AN OPT-IN BASIS BY REGISTRANTS) that registrants should be allowed to have the choice to opt-in to. Small point, but in I.A.3.9.5, we've never liked the term "reseller" (although it's a defined term in the RAA). Some in the public (and UDRP complainants in particular) might use the label to imply that a "reseller" must be registering domain names in order to resell them (rather than someone that simply has access to a registrar's advanced systems, to be able to access white-label platform for registration services, or a "pro" interface). That confusion over the meaning of "reseller" might negatively impact a registrant. So, it would be nice at some point to revisit the term "reseller", and perhaps replace it with "Value Added Integrator" or some other term that doesn't reference buying/selling domains themselves (as opposed to domain registration services). The "registration service provider" term is also fine. Potential next step: See deliberations on Losing FOA (recommendation 2). WG to consider whether to revisit the term “reseller” (see I.A.3.9.5). Discussion: * No need for a required NACK; don’t see evidence for this – of illicit transfers, * No need to define “reseller”. * Auto NACK is not the way to go – no justification for it. * WG agrees that there is no need for changes. AOB: Small Team for Recommendation 19: ACTION ITEM: Recommendation 19: Small team to re-evaluate the language in Rec 19 -- WG members are -- Owen Smigelski, Sarah Wyld, Keiron Tobin, Zak Muscovitch. 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: * Need to get the refined scope; probably not going to get the perfect language – need some way to reflect the work in the community on abuse. Stronger than evidence of fraud but not too strong. * Question: What are we trying to capture in an anti-abuse policy? Answer: “Evidence of fraud” is very narrow. But there are concerns are that the suggested revision is too broad: “or violation of the Registrar’s domain use or anti-abuse policies”. * Question: Why not put in exactly what we are trying to prevent/capture? Ex. Malware, phishing, etc? Answer: Concerns about content regulation and future-proofing. * As a reminder, there was another compromise proposal that was narrower than the Initial Report but broader than the status quo: “violation of registrar’s anti-abuse policies, or evidence of fraud”. * What about “DNS abuse”? ICANN has a definition for this. Could be the precise term we are looking for. * DNS security threats include five broad categories of harmful activity: * Botnets * Malware * Pharming * Phishing * Spam (as it is used to propagate other DNS security threats). * Can we just say “fraud” and “DNS abuse” – does this lower the bar? Having “evidence” is important. * Make it clear that “evidence” applies to “fraud” and “DNS abuse”. * Suggested wording “"Evidence of (a) fraud or (b) the domain presents an active DNS security threat as defined here: <link>”. * Small Team agrees with suggested language: "Evidence of (a) fraud or (b) the domain presents an active DNS security threat as defined here: <link>" ACTION ITEM: Recommendation 19: Sarah Wyld to send the proposed revised language and rationale to the WG list on behalf of the Small Team.