Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be Tuesday, 13 September at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEM: WG members should be prepared to discuss the public comments on Recommendation #2<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> of the Phase 1A Initial Report. Notes: Transfer Policy Review - Meeting #58 Proposed Agenda 6 September 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates * Busy next few weeks with ICANN75 coming up. * Public comment period ended and all comments (34) have been assembled. Support and identification of a few items to discuss. We’ll be reviewing all comments and updating recommendations as appropriate. * Update from Steiner on the At-Large summary of the CPWG discussion on Change of Registrant policy. See attached. * Had a fruitful discussion last week on the CPWG call. * Based on that discussion, if we are going to change anything on the transfer lock the CPWG would like some statistics/data supporting removing that part of the policy. But we don’t have any statistics. If we will have transfer lock period it might be reduced to less than 60 days. Specifically: “Input to the discussion were mostly connected to the question whether the present 60-days transfer lock after a change of registrant data is preventing domain name hijacking. Further - the majority of the CPWG attendees requested data about the volume of hijacked domain names. These statistics - if available, may indicate if the transfer lock after a change of registrant is needed. The discussion also covered whether a transfer lock is needed for mitigation of domain name hijacking.” * Discussion: * Wonder if Compliance has some data? * Registrars have indicated that they don’t have data. * Without data we should remove it. * From staff re: question about data: Compliance has provided data related to complaints about the lock itself in Phase 1A, but not specific enough in terms of hijacking. As to data to “prove” that a lock is necessary or not, we don’t have that level of breakdown/tracking to speak to that issue. * Compliance tracks transfer complaints in general, but does not break down to “inter registrar" vs. “COR”. * The best you can get is the NACK statistics from the Open Data Initiative, but only limited years and not recent. Does show significant use of the NACK, but can’t correlate it to hijacking. * Not sure that we can get valuable data as to why there was a NACK in the first place. * Registrars offer different levels of security and registrant can pick the model that fits their needs/shop around to get what they are looking for. * I also remember most complaints about COR to Compliance were people annoyed by not being to unlock their domains. For hijacked domains, the hijack happened even with COR process (which hijackers were able to bypass). * It’s a very interesting perspective. As registrars can and do provide security that is superior to minimum requirements under the Transfer Policy. Accordingly, it may be that this is the answer; leave it to registrants to select a registrar with desirable security protocols to prevent unauthorized transfer. 3. Review public comments on proposed edits to Transfer Policy section I.A.3.7.1 -- See Public Comment Review Tool for Recommendation 19<https://community.icann.org/display/TPRPDP/Phase+1A+-+Public+Comment+Review+...> Overview of the Public Comment Review Tool (PCRT): * See the wiki page: https://community.icann.org/display/TPRPDP/Phase+1A+-+Public+Comment+Review+... * Full compilation of 34 comments. Summary: * Include both those responding to specific questions and from those who didn’t follow the format. * Responses to questions. * Series of comments suggesting new topics that are consolidated. * Process and modalities (such as extension of the public comment period). * Series of comment that express concern about security issues. * PCRT: * For each recommendation, breakdown: support, support with wording change, significant change required, recommendation should be deleted, no opinion. Grouped the comments by type. * Grouped by themes. Recommendation #19 PCRT<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> – Summary: * Expectation that WG members have reviewed these comments. * Support -- Ted Chang, RySG, ICANN Business Constituency (BC), ICANN Org, Samwel Kariuki, Philip Busca, Namecheap, RrSG, Newfold Digital, IPC * Support recommendation with wording change: * Tucows, GoDaddy, John Poole. * Significant change required: * Com Laude, ICA, Leap of Faith Financial Services Inc. * Recommendation should be deleted: NCSG. Discussion: * The evidence of fraud was discussed in the full WG and in the small group. * We expected to get comments on this. * Based on the comments, do we have a path forward on whether to change the recommendation? * Is there a possibility that fraud goes to a “MUST”? * There could be good reasons to leave fraud as a “MAY”-- could imagine that a registrar might allow a registrant to transfer away, so good to have the flexibility. * Maybe the losing registrar doesn’t want to deal with this registrant/domain name, so wants the flexibility to allow a transfer. * Does that mean that a losing registrar could allow a fraudulent registrant to transfer without the gaining registrar to know about the fraud? * How do you know that there is evidence of fraud? If you make it a “MUST” a registrar could be in breach without ever knowing it. Or something is illegal for one country but not in another. * Procedure element: The current language is limited to evidence of fraud in the “MAY” category. To put a change in policy forward to Council the WG will have to have consensus support for a change to the recommendation/policy. In this case the “MAY” is the current policy so there would need to be consensus for a change to “MUST”. * Suggest removing “domain use” from “Violation of the Registrar's domain use or anti-abuse policies or evidence of fraud.” * The above suggested change may not allow enough flexibility – to allow for things other than abuse or fraud. * Three scenarios: 1) keep the recommendation as “evidence of fraud”; 2) the recommended language; 3) “Violation of the Registrar's anti-abuse policies or evidence of fraud.” * Once we agree to language the change should go back to the groups and get approval. 4. Time permitting, Review public comments on other elements of Recommendations 18, 19, and 20 – See Public Comment Review Tools for Recommendations 18, 19, and 20<https://community.icann.org/display/TPRPDP/Phase+1A+-+Public+Comment+Review+...> Recommendation 18 (brief discussion), PCRT<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> – Summary: * Pretty good support. * Support as written: Ted Chang, Tucows, Com Laude, ICANN Business Constituency (BC), ICANN Org, GoDaddy, Samwel Kariuki, Philip Busca, NCSG, Namecheap, RrSG, Newfold Digital, IPC, ARTICLE 19, Leap of Faith Financial Services Inc., ICA Support with wording change: RySG and John Poole Discussion: * Registrars have a clear process for taking down domain names. Language we have now is good enough. * Not sure the gaining and Losing Registrar have the same data of abuse. 5. AOB: Next session: Tuesday 13 September at 16:00 UTC * Next topic will be the elimination of the FOA and security of the TAC. Current plan is to start on that topic on the 13 September meeting. Then continue on that topic at ICANN75. * In the meantime WG members should review Recommendation #2 and the comments, as well as how to reconcile them to find mutual agreeable updates to the recommendations. ACTION ITEM: WG members should be prepared to discuss the public comments on Recommendation #2<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> of the Phase 1A Initial Report.