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-pcrt-Initial-Report-Recommendations_Rec%2017_20220829.docx?version=1&modificationDate=1661773117000&api=v2> and Public Comment Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1yTeU5FTqfXt59_JqAewSs0SvNzoObgmZRWDtYYjxxtY/edit__;!!PtGJab4!6xPK9tu2Xv77St2mvd6BvA1GSy4b1CcZI6Tnlm6UcVxaG8A2kVTnjtYqzLSYGNgKxhnlZKYH1FdUrqZ1w-agk4CVNxDFeZPhGGw$>) * 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+Tool?preview=/201949311/212107985/gnso-TPR-P1A-pcrt-Initial-Report-Recommendations_Rec%2018_20220829.docx> and Public Comment Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1IwufJ7Os2cAqYZqD7wMcSg2pbtT6o2EBsAGQDwM5tt8/edit__;!!PtGJab4!-nISIddQI1mDpTj7PoZiBrFnP7d7con3eClqvn9UBEO_S2gt_wldyM24r2vYcIP0uy0rVTJyO-a-mj8U1jgw_pqhEZrvYT2ynNF1$>) 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+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$>) 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.