Dear All, Please find below the notes and action items from today’s Transfer Policy Review Working Group. Our next meeting will be Tuesday, 1 June at 16:00 UTC. Best regards, Emily, Berry, and Caitlin Transfer Policy Review Phase 1 - Meeting #03 Proposed Agenda Tuesday 25 May 2021 at 16.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) * We will use a polling mechanism during this call to assist in determining initial feelings of the group, re: sizing of work, dependencies, etc. * Please note that while the poll will appear for everyone in the Zoom room, please do not respond unless you are an active member of the WG. * This poll is not meant as a scientific endeavor – we are using this to get a better temperature of the room regarding the complexity and duration of the topics before the group. It will assist the Staff Support Team in developing the project plan to ensure reasonable timelines, delivery dates, and milestones. 3. Briefly Revisit Topics from Meeting #03 Using Poll: Topic #01 (Gaining FOA), Topic #02 (Losing FOA), Topic #03 (FOA - Additional Security Measures), and Topic #04 (AuthInfo Code Management) (20 minutes) * With respect to Q1 (call hours), would like to get the group to think about how many hours of call hours are needed INSTEAD of calendar times (like six months). How long will it take for the group to deliberate the topic, form preliminary conclusions, and get the topic stabilized to move on to the next. * Our current cadence is 1.5 hours per week. If we say this is a medium topic, we are, in essence, saying it will take the group 5-7 weeks to come to preliminary conclusions on a topic. * Please also keep in mind that one meeting may have more than one topic. GAINING FOA * Level of Effort in terms of call hours? (S, M, L) * S -- 53% * M – 47% * L * Dependencies? (Is there any work that needs to be completed before discussion of this topic, is there work that needs to be done in parallel, or any future work that is dependent on this topic?) * Y – 35% * N – 65% * It may be best to look at auth-info codes first because the need for FOAs would be better reviewed after we look at the security of auth-info codes. * The Gaining and Losing FOA are very dependent on the process with auth-codes. * Changes to the Losing FOA are dependent on the auth-code, but do not believe the Gaining FOA is dependent on auth-codes. * Related Topics? * Y – 6% * N – 94% LOSING FOA * Level of Effort in terms of call hours? (S, M, L) * S – 62% * M – 46% * L – * Dependencies? (Is there any work that needs to be completed before this topic, in parallel, any future work that is dependent on this topic?) * Y – 62% * N – 38% * Related Topics? * Y – 8% * N – 92% FOA – ADDITIONAL SECURITY MEASURES * Level of Effort in terms of call hours? (S, M, L) * S – 33% * M – 60% * L – 7% * As this leans towards medium/high, will consider as part of building out the project plan, we will build in slack (extra time to consider complex topics). * Dependencies? (Is there any work that needs to be completed before this topic, in parallel, any future work that is dependent on this topic?) * Y – 40% * N – 60% * After last week, interpreting security more broadly. It may be beneficial to have a discussion re: DNSSEC vis-à-vis transfers. Should want to support secure transfers for a registrant. WG should discuss if this is or is not important as a relevant security feature to continue to include. * This topic is interesting but unsure if this is in scope. If DNSSEC is discussed, the WG should have some education on this topic so that everyone is on the same page – what is DNSSEC, can this be transferred, etc. * This could be a possible area where the group could lay down a few extra questions during the early input phase from SO/ACs. Agree that education would also be necessary for this group. If the group does determine that the topic warrants further investigation, it may not be in scope under the current charter, but project change requests do allow for changes in scope. Please note, though, project change requests are a last resort. * Related Topics? * Y – 20% * N – 80% AUTH INFO CODE MANAGEMENT * Level of Effort in terms of call hours? (S, M, L) * S – 6% * M – 50% * L – 44% * Dependencies? (Is there any work that needs to be completed before this topic, in parallel, any future work that is dependent on this topic?) * Y – 50% * N – 50% * Related Topics? * Y – 38% * N – 63% * One thing that is missing is how the registrant can actually find a way to get the auth-code. Losing registrar should submit the auth-code within five days, but there should be standardization around this. * In reading the tea leaves, it sounds like the group would like to start discuss auth code management in a general sense – registrar management, usability from a domain owner perspective. This would start to the topics on security (the previous topic), then the group would discuss the Gaining FOA and then, finally, the Losing FOA as a general cadence or approach. * Perhaps Losing FOA should be discussed before Gaining FOA – in the Tech Ops Paper, there were many items related to the Losing FOA. The Gaining FOA, on the other hand, does not have a use (and is no longer used); however probably not comfortably eliminating the Gaining FOA until we discuss the Losing FOA 4. Phase 1A Charter Topic #05 Discussion - Bulk Use of Auth-Info Codes (20 minutes) * Level of Effort in terms of call hours? (S, M, L) * S – 27% * M – 67% * L – 7% * Dependencies? (Is there any work that needs to be completed before this topic, in parallel, any future work that is dependent on this topic?) * Y – 53% * N – 47% * Important to cover auth-info code first. It’s important to understand how something is done once before understanding how this can be done in bulk. * Suspect FOA topic should be covered before this topic. * Related Topics? * Y – 33% * N – 67% * If the Team decides there is a relationship with DNSSEC, that will also impact this topic. 5. Phase 1A Charter Topic #06 - FOA - Wave 1, Recommendation 27 (20 minutes) * The Phase 1 EPDP Team noted the access to registration data is important for transfers but noted that the changes to the Transfer Policy would be handled in this group. This is mostly an inventory mechanism to make sure all of our bases were covered. * Level of Effort in terms of call hours? (S, M, L) * S – 23% * M – 62% * L – 15% * Dependencies? (Is there any work that needs to be completed before this topic, in parallel, any future work that is dependent on this topic?) * Y – 46% * N – 54% * Based on this shopping list, the group can review this list and do a sanity check – in other words, is anything missing from the Wave 1 report that the group needs to consider? * Support Staff is aware of the Phase 1 IRT’s work and will be there to ensure that the left hand and right hand are coordinated. The IRT is tasked, as a result of this Wave 1 Report, to do a terminology update. As part of implementing the Phase 1 recommendations, if there is a reference to legacy protocol of WHOIS, that needs to be converted to RDDS or registration data. Similarly, references to admin contact will be deleted. If terminology updates encroach upon policy making, they will be passed to this group. Where we stand now, there is no apparent disconnect b/w the IRT and this WG. However, Support Staff will continue to ensure coordination. * Related Topics? * Y – 15% * N – 85% 6. High-level Review of Phase 1B Charter Topics & Charter Questions (15 minutes and time permitting) * What is Change of Registrant (CoR) – Requirements that seek to prevent domain name hijacking by ensuring that certain changes to registrant information have been authorized. * What is required? Registrars must obtain confirmation from the Prior Registrant and New Registrant before a material change is made to: Prior Registrant name, Prior Registrant organization, Prior Registrant email address, and/or Administrative Contact email address, if no Prior Registrant email address. * Encourage everyone to review the associated metrics in the Final Issue Report * What elements of the CoR Policy need review? * "60-day inter-registrar transfer lock" prevents transfer to another registrar for sixty (60) days following a CoR. Registrants have difficulty with the 60-day lock, especially that they are not able to remove the lock once it is applied. * Designated Agent: an individual or entity that the Prior Registrant or New Registrant authorizes to approve a CoR. * Appear to be different interpretations of role and authority. * Compliance enforcement is being deferred in relation to CoR as it applies to removal or addition of privacy/proxy services, pending further work to clarify implementation of relevant IRTP-C provisions. * Charter<https://community.icann.org/display/TPRPDP/2.+WG+Charter> Questions (please refer to the Charter to review the full text of questions – some high-level notes are included below for reference): * First set of questions focuses on the policy overall – according to the Scoping Team Report, CoR does not achieve the stated goals – why? Are the stated goals still valid? How should the goals be achived? * Data gathered indicates that some registrants find the CoR policy burdensome – how can this be mitigated while still ensuring security for registrants? * Should there be a standalone policy for CoR instead of it being part of the Transfer Policy? * Is a 60-day lock appropriate to prevent hijacking or are there other alternatives that should be explored? * Review of Designated Agent – there seems to be differences in the understanding and authority of the Designated Agent * Changes/addition of P/P service – how should this be handled vis-à-vis CoR? * WG comments * P/P services fall into certain buckets – one is a service run by a registrar vs. an unaffiliated service where the registrar does not have access. Is that distinction included here? * The Charter questions do not go into that level of specificity, but the group can consider if new questions should be added to the WG’s scope. * Discriminators are – can you tell if a P/P service is being used or not? If you can tell, is it affiliated with the registrar or not? * One approach should be – do we actually need this policy? Then review all of the additional charter questions – should start higher level – is this policy even needed. * We are going over these questions so that the group can understand the topic and answer the polling questions from an educated perspective. * Please review the Issues Report and Charter Questions and consider what size effort this will be and if there are dependencies or related topics. 7. Next steps & closing (5 minutes) a. Next meeting 1 June 2021 @ 16:00 UTC b. Reminder to please review the Change of Registrant charter questions and consider what size effort this will be and if there are dependencies or related topics. We will begin the next meeting with polling questions on this topic.