Dear TPR WG Members, Please find below the notes and action items from today’s call. The next TPR WG meeting will be on Tuesday, 01 February 2022 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: None. Transfer Policy Review Phase 1 - Meeting #33 Tuesday 25 January 2022 at 16:00 UTC 1. Roll Call & SOI updates (5 minutes): * No updates provided. 2. Welcome & Chair updates (5 minutes) * No updates provided. 3. Discussion of registrar-applied lock upon domain creation (75 minutes) See overview of inter-registrar transfer locks here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1q7xaJuxi50Q6T...> Previous discussions on this topic are captured in the parking lot working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1e4hwyxKTx2JFR...> 60-Day Creation Lock: * Went through a lot of the locks, even those for which we aren’t responsible. * Charter questions relate to the 60-day creation date and transfer locks. Should there be changes to the current 60-day lock in the policy. * Summary of previous discussions suggests that people were leaning towards some period of time in which transfers are prohibited. * Current policy has these as “MAY”. * Question is do we need to make the locks consistent and do they still serve a purpose? * The 60-day lock on creation – having a universal approach would help protect new people entering the market. * Get some clarification on charge back – is this a live issue, or a legacy? * 60-day lock is handy now if you have a fraudulent reseller. * 60-day lock is a problem for the registrants and isn’t consistently applied. Don’t see charge-backs as such a big problem. * The anti-fraud mechanisms today with credit cards are more robust than they used to be, so the risk has shifted to the credit card companies. The fraud situation has been ameliorated. * Even if the registrar is not incurring the charge, we would like to avoid the name transferring fraudulently. * Why not make this optional for the registrar? * The individual user should have the right to choose this option. * Standardization would help many parties. * There was a reference made to domain tasting and the lock as a mitigation. Not aware of domain tasting as a problem relating to a transfer. * Also observe that claw-backs are a separate process and independent of the lock. You should be able to claw back whether it’s locked or not.’ * At-Large submitted results of a survey and from that At-Large was not in favor of locks. Also inconsistent application is confusing for end users. * Felt that claw-back would be part of the transfer dispute discussions the WG is undertaking later. * Question: Is the current policy of a 60-day lock mandatory (MUST) or optional (MAY)? Answer: Current policy is “MAP” on the sponsoring registrar. May be able to deny a request. * It is NOT an ICANN requirement under the current Transfer policy. * The 60-day lock after creation is contractual (Registry Agreement) for SOME registries but not all. For example it is a contractual requirement in our Registry Agreement with ICANN, but it’s not a requirement across the board – some new gTLDs don’t have it in their RAs, but many follow that model. * This WG could recommend that the RAs could be revised to not include the mandate for a 60-day lock. Does the WG have any interest in making that recommendation. * From the TPR Parking Lot document, bottom of page 1: “Proposal for additional consideration: Include in policy a 60-day lock post creation and post transfer but with an opt out feature (for registrants? For registrar?) -- Should there be exceptions/constraints to the opt out?” * Lock after transfer and lock after creation should be handled differently. Creation lock should be made mandatory. For transfer 60 days is way too long. * How can this WG make a consistent policy across all registries when the original policy is written into the registry agreements? Problem is that it is not written into all agreements. We can make it consistent at least with post-creation lock. * If the only available option is to impose the 60-day post creation lock on all registries that don’t already have it in their agreements. * If the WG were to form consensus around a creation lock, the consensus policy adopted by the GNSO Council and the Board would supersede any provisions in the registry agreements. Where the provisions were lacking they would have to be included in amendments of the agreements. * Look at the pros and cons of the lock for security and consistency. * Can we find out which registry agreements have the locks and which don’t? * All ICANN contracted parties are required to meet requirements of consensus policies. * Haven’t heard a solid security reason for why there is a lock after creation. * Creation lock is less about security and more about consistency, while the transfer lock is more about security but also consistency. * Is 60-day lock the ultimate security (versus 30-days, etc.)? 60-day is more historical. * Caution to make sure we are looking at this holistically and its potential impact on other policies, such as the (Add Grace Period) AGP Limits Policy. * Seems like we should have a lock that is as long as the grace period, which is currently 5 days. * Should look for a correlation between ccTLDs and gTLDs as they are very different. * Sounds like the WG is leaning towards a shorter mandatory period. * If we lower the period of time but keep the mandatory lock we should provide a rational. * The lock after transfer could be just a “transferProhibited” lock, so other changes, e.g., updates, could still occur. * The WG should make sure its recommendations are as nailed down as possible. * For the Initial Report the WG could ask specific questions in a survey format to get quantitative and qualitative responses. * Instead of calling it a lock, could call it a non-transfer period. * Seems that we are leaning towards shortening the 60-days but keeping the requirement that a transfer not occur in the X-day (say 7 days) period and we need to provide the rationale. We should considering the period in calendar days or hours. * There is nothing that prevents any RDAP server from adding anything in response. Do you want to require the publication of a value, or you could just do it. 60-day Transfer Lock: * Could call it a transfer window availability. * There are more security issues here. * Registrar survey responses leaning towards a shorter lock (30 days). * If we have 7 days for the creation lock we could make it 7 days for the transfer, for consistency. * First question is what the length of time should be, but the second question is whether that period of time has to be the same for all? Or whether there are exceptions. * There is also the question of should we have a lock. * I wonder if 7 days is long enough for a dispute … maybe 30 makes more sense. * Like the ability to lift the lock upon request. * Need to have the flexibility to resolve the dispute. * What if the gaining registrar is not responsive and thus does not want to place a lock due to the dispute? * It's all connected. Dispute process, fast undo, lock timing, etc. and TEAC. * But disputes can take months. Could it have it long enough for the dispute to be filed. * Is 7 days enough to file a dispute? * In the case of suspicious behaviour (abuse), will clientHold be sufficient? I.e. clientTransferProhibited can be removed. Update to my idea: serverTransferProhibited is removed, replaced with clientTransferProhibited when abuse. * TDRP is also in scope for this PDP. * Need to make a distinction between a 7-day lock and a dispute lock. 4. AOB (5 minutes): * Next call: Tuesday 1 February 2022 at 16:00 UTC