Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be Tuesday, 12 July at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: WG members are encouraged to provide additional inputs in the working document at: https://docs.google.com/document/d/1gu4sXGvyJeWJIfvaK_I7GKA6lAdfKFPQKaN4UMgz... (table on page 8) prior to the next meeting on 12 July. Notes: Transfer Policy Review Phase 1(b) - Meeting #52 Proposed Agenda 12 July 2022 1. Roll Call & SOI updates SOI Update from Catherine Merdinger: https://community.icann.org/display/gnsosoi/Catherine+Merdinger+SOI 2. Welcome and Chair Updates * Reminder that the Phase 1(a) Initial Report is out for public comment. Closes on 02 August. * Reminder that we will take a few weeks off at the end of August – 6 more sessions before the break. During the break would be a good time to review the public comments. 3. WG Analysis of Key Elements of CoR See: https://docs.google.com/document/d/1gu4sXGvyJeWJIfvaK_I7GKA6lAdfKFPQKaN4UMgz..., table on page 8 For reference, here is the Transfer Policy: https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en Overview: * In Phase 1(a) we found that this was a helpful exercise to look at the high-level elements and the functions that they serve. Make sure everyone understands them and think about whether or not they make sense. We’ve heard that people want to make changes but drilling down on the elements will help us to focus the discussion. * CoR policy is pretty compact. Think with this table we’ll hit on all of the topics of the policy. The first element is key – to confirm that the domain name is eligible for CoR. Policy Elements: Confirm the domain name is eligible for Change of Registrant (Section II.C.1.1). WG Notes: * Thinking through the reasons we might not allow CoR, section 2.1 still seems reasonable. 2.2 may need to change. 2.3 also reasonable. * Wonder if there should be something in here where the name is in violation of the registrar’s policies as a reason why the registrar could hold up a CoR. It’s not really a dispute and wouldn’t be a court order. * I like 3; we might put a placeholder that we might need to expand these reasons. * Could consider carrying over language from Phase 1(a). Obtain confirmation of the Change of Registrant request from the New Registrant, or a Designated Agent of the New Registrant, and provide certain required notifications (Section II.C.1.2). WG Notes: * This section is confusing and doesn’t add much. * Would it make sense if it as a notification instead of a confirmation? * Don’t think we need a confirmation at this stage – maybe a notification. Something that allows a person to quickly flag it’s a problem or to undo it. Replace confirmation with notification. * A point from a prior call: CoR in combination with change of registrar, why having these intertwined muddles the policy. CoR looks to the registry like a change of registrar but usually isn’t. These are two very different situations. * Seems like there is good support for changing confirmation to notification – any objections? (none) Inform the Prior Registrant or its Designated Agent that if its final goal is to transfer the domain name to a different registrar, the Prior Registrant is advised to request the inter-registrar transfer before the Change of Registrant to avoid triggering the 60-day lock (Section II.C.1.3) WG Notes: * This is the next stage, that there are two parts to this – warn them that this has an impact if there also is a change of registrar. * There are a couple of ways today to avoid a 60-day lock. * Does a 60-day lock make sense? Is 60 days the right number? Is there a way to opt out? * Not sure why we went with 60 days, maybe just mirroring other lock time periods. Maybe say that the registrar must remove the lock if requested (instead of MAY). * Maybe we drop to 30 days to mirror what we decided in Phase 1(a). * From the IRTP-C Final Report: “The 60-day lock is used to “contain” the changes of Registrants within a single Registrar in order to facilitate recovery of domains that have been hijacked.” * Don’t think we need it, but if we have it, it should follow the timing of the registrar transfer. * At least all registrar should have the same policy. * Maybe leave it for the registrar to decide and remove it from the policy. * Sounds like there is support for removing the lock. * Should the policy state that there should not be a lock? * Maybe we fix this by considering how to address this in the transfer reversal process. * Could keep it but reduce it to 30 days. If we remove it that is a security vulnerability. We should not compromise security. * Need a rationale for keeping it. Could be helpful to have numbers to support both arguments. Maybe from ICANN Compliance? * You can opt out of the lock currently, if the registrar offers that option. Not all registrar offer this. * Suggest including in the policy the ability to remove the lock – it’s not currently there or unclear. * Three proposals: 1) remove the lock; 2) keep but shorten the timeframe; 3) keeping it but allowing a registrant to get the lock removed. Obtain confirmation of the Change of Registrant request from the Prior Registrant, or the Designated Agent of the Prior Registrant (Section II.C.1.4). WG Notes: * Similar to the confirmation of the new registrant, this is the confirmation of the Prior Registrant. Big question is whether you need a confirmation or is a notification sufficient. * Doesn’t really serve a purpose to prevent domain name hijacking. * Changing from confirmation to notification is a suggestion. * Maybe have the option for a fast undo. * Wonder if there are good examples of a secure method of communication that is more secure than the current practice? * Could be notification only with an option to dispute. * Needs to be a balance of level of security. * Could we at least simplify the language in the policy? * In Phase 1(a) we talked about the importance of the TAC for security. Is there something that we can have that the notification between the prior and new registrant is secure? * We do need to be mindful of the difference between notification and confirmation. There is ambiguity in the definition of “secure” in this context/language. Not sure if “secure” is the right way to word this. * Sorry, the formatting of that is terrible, but secure mechanism is discussed in the implementation notes and was designed to provide some flexibility for implementation. * Do we need something more that the change request is valid? Just need the appropriate level of security. * Can we do something better here? Probably not at the cost of flexibility. * Good point... Sarah brings up the difference between changing data WITHIN a particular account (at a registrar) and moving a registration ACROSS accounts (at a registrar). Maybe the policy needs to accommodate these two very different actions. * We should look at what other companies do for account management accuracy. * Going back to an earlier point: changing account information irrespective of industry. Under GDPR data subjects have certain rights to accuracy, but that doesn’t preclude security. If you are doing industry practices in a secure manner that would not violate GDPR. Having an out-of-bound authentication as a security policy shouldn’t violate GDPR. * Think that the push here was to remove the confirmation and changing it to notification. Process the Change of Registrant within one (1) day of obtaining the confirmations (Section II.C.1.5). WG Notes: * If we change confirmations to notifications how does that affect this part of the policy? Does it still apply? No longer than 1 day from notification of both parties? * The key to this is to make sure the process continues and is completed. But when does the 1-day period start? * Because there is no confirmation don’t think there is a place for this 1-day timeframe. * The key is that they wanted to get the updates done at the registrar within a reasonable time. * If this CoR is on the registry level there is no way to verify that. * The 1 day was meant to be at the registrar level. * Section 1.5 was the mechanism to force the change to happen. * 1.5 needs to be updated that when those notification are sent (if we change from confirmation) that happens within 1 day. * If we are moving to notification from confirmation we don’t need 1.5. Notify the Prior Registrant and New Registrant before or within one day of the completion of the Change of Registrant (Section II.C.1.6). This notification includes informing the Prior Registrant and New Registrant of the 60-day inter-registrar transfer lock or informing the Prior Registrant that it previously opted out of the 60-day inter-registrar transfer lock (Section II.C.1.6.4). WG Notes: * Seems to be okay when talking about notifications (versus confirmations). Seems to still be appropriate. * Should add in the dispute process, which we need to create. Impose a 60-day inter-registrar transfer lock, unless the Registered Name Holder had previously opted out (Section II.C.2). WG Notes: * Do we remove it, shorten it, have a way to opt out? Think about these questions for the next call, also in the context of moving to notifications instead of confirmations. * Any additional inputs will be welcome in the working doc between then and next week's call. 4. AOB: Next meeting, Tuesday, 12 July at 16:00 UTC.