Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be on Thursday, 15 December at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: 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 on TTL Enforcement: Send the proposal to the list with rationale. 3. Other - Additional Suggested Topics and Proposals – Item 7 from ICANN Org – see: gnso-TPR-P1A-pcrt-Initial-Report-Additional Topics and Proposals_20221213.docx<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> -- Request for ICANN Org Compliance to suggest specific language. 4. Other - Additional Input – see: gnso-TPR-P1A-pcrt-Initial-Report-General_20220829.docx<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> -- WG members to look at comments 12-23 and 24-33 to make sure there is something we haven’t already covered Notes: Transfer Policy Review - Meeting #73 Proposed Agenda 13 December 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates * Small Team Updates: * Recs 16 & 17 lock override: Met yesterday (12 Dec) – Developed a proposal that they can share to the full list. * Rec 13 TTL: Meeting today (13 Dec). 3. Review of additional mailing list feedback<https://mm.icann.org/pipermail/gnso-tpr/2022-December/date.html> on Small Team Proposal regarding Transfer Policy section I.A.3.7.1<https://mm.icann.org/pipermail/gnso-tpr/2022-December/000696.html> * Adding DNS Security Threat and definition to Evidence of Fraud. * Two new items on the mailing list in response: * Mike R.: Why this should be added to MUST not transfer. * Rick’s response to Mike (why it should stay as MAY). * Status: Intent is to go with this proposed language in the MAY category. Need to be able to give flexibility to registrars to have discretion. * Examples: Need to study a security threat (such a Microsoft or Facebook) – to transfer from one registrar to another. * Question: Why not just write in an exception for the above example, but keep it as a MUST? If that is the only exception. * There needs to be flexibility for various examples – not just the one exception. Leaving it broad is the better approach. * Hard to explain this clearly to those who think it should be MUST. Need a more compelling argument. * Most WG members agree to stay with the proposed language in the MAY category. 4. Phase 1A Initial Report Public comment review – review of items not specifically tied to a recommendation (please see Public Comment Review Documents in the bottom three rows of the table on the wiki page here<https://community.icann.org/display/TPRPDP/Phase+1A+-+Public+Comment+Review>): a. Other - Additional Suggested Topics and Proposals – Item 7 only from ICANN Org – see: gnso-TPR-P1A-pcrt-Initial-Report-Additional Topics and Proposals_20221213.docx<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> Summary: “ICANN org suggests that the policy recommendation include requirements related to the maintenance and provision to ICANN (upon reasonable notice) of records related to when/how/to whom the TAC was provided, regardless of the means the registrar chooses to use to provide the TAC.” Discussion: * Assume this goes along with transfer disputes; and when we talk about control panel access – if it was provided by the control panel the registrant still had to be notified. * Relates to the difficulty of proving who accessed the control panel. * Would be helpful to see specific language. Also would need a data processing agreement before registrars could provide personal data. * Assumed that if there's a requirement (e.g. provide TAC only to RNH) that the corresponding obligation to be able to prove we met that requirement is assumed? * This adds a new layer to previous discussions about record keeping. * Registrars need to see the benefit of logging. Registrars would need to look at costs vs. benefits and also the DPA. * ICANN Org Compliance: Registrars should be able to provide evidence [documentation? Records?] of compliance with TAC and notification provision requirements. ACTION ITEM: Request for ICANN Org Compliance to suggest specific language. b. Other - WG Process and Modalities – see: gnso-TPR-P1A-pcrt-Initial-Report-WG Process and Modalities_20220829.docx<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> Comments 1-10 – requests to extend the deadline (other elements are captured elsewhere). Discussion: * Leadership considered the request and extended the public comment period. Not sure there was a benefit for a longer extension. * Note comment 10 also touches on a couple of other items – concerns about registrants being underrepresented and lack of balance, which we’ll talk about below. Comments 11-14: Discussion: * Discussed participation and representation: We do report attendance and we are seeing diversity of viewpoints – between registrars as well as with non-registrars. * Attendance is also included in the monthly reports to Council. * The WG will go back to weekly meetings as of the beginning of the year. If a member cannot attend a call he or she should establish an alternate for that call. c. Other - Additional Input – see: gnso-TPR-P1A-pcrt-Initial-Report-General_20220829.docx<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> Comments 1, 2, 5, 6, and 11: Discussion: * Note: Many of the comments in this document are covered elsewhere and have already been dealt with (12-23, 25-33). * All raised concerns about the elimination of the Losing FOA. Discussed with Recommendation 2 and adding back in the ability to ACK or NACK. * WG agrees that these comments have been previously addressed. Comments 3 and 4: Discussion: * Don’t think we discussed this: “SSAC should also do a thorough review, in light of our own comments that highlighted the inconsistencies between their past advisories and the working group's recommendations.” * Leap of Faith provided a lot of good comments that the WG has reviewed. * Don’t know if we wanted to ask the SSAC to write a specific report. * SSAC did have the opportunity to comment (but didn’t). SSAC isn’t shy about contributing to community discussions. They have chosen not to in this case. Not sure why we would make a specific request of them; could look like we are delaying the process. Comments 7-10 (all related to security): Discussion: * A lot of the process the WG went through addressed these issues – specifically making changes to enhance security. Couldn’t find hard data on unauthorized transfers. Balance of looking through the security procedures and make sure they make sense. * Security in these comments is in a different context – we don’t know until we implement these recommendation the impact on security. * Re: Lack of data – we are confronted with the same situation that there is a lack of reporting so a lack of data. Consider a recommendation in implementation or contractual negotiations. Comment 24: Discussion: * Don’t think the comment it raising anything new, but provides some helpful points. * No further comments from the WG. ACTION ITEM: WG members to look at comments 12-23 and 24-33 to make sure there is something we haven’t already covered. 5. AOB: No meeting 22 December and last week in December; first meeting in January is Tuesday, 10 January.