Dear TPR WG Members, Please find below the notes and action items from today’s meeting. The next TPR WG meeting will be on Tuesday, 29 March 2022 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: None captured. Transfer Policy Review Phase 1 - Meeting #39 Tuesday 22 March 2022 at 1600 UTC 1. Roll Call & SOI updates (5 minutes) 2. Welcome & Chair updates (5 minutes) a. Update from Steinar Grøtterød, ALAC: Distributed results of discussion in the CPWG on locks. Based on that discussion we had a poll. There were around 40 responses. The results showed support for a 60-day period for locks as well as 30 days. Positive response to keeping the same policy for all locks. This input should be taken as informal. Questions/Comments: * Question: Noted that in the time period for the transfer locks there was equal support for 10 and 60 days, but for creation lock there was support for the 30-day period. Any explanation for that result? Answer: There was a concern about whether there was enough time for the UDRP with 10 days, so less support for that, but in general there was support for keeping the shorter period. * Question: Seems like the respondents didn’t understand the locks relating to the UDRP, would more information help? Also, isn’t a goal to standardize the time periods for the lock? * Question: Could you say what the policy was supposed to be that would be the same for all registry operators? Answer: We thought it would be more user friendly to have the same policy. That it should be the same number of days for creation and transfer locks. * There are more registries that would prefer not to have activities in this space. Need a discussion as to whether there should be a requirement on registry operators. This has not been decided in this WG. * Steinar: Would like to hear if 10 days is a real show stopper for the UDRP policy. * 60 days seems far too long and 10 days seems to have general support. * Question: Are we asking whether 10 days from creation enough time to file a UDRP? Answer: In post-create and post-transfer is 10 days enough time to complete a UDRP? * Once a UDRP is notified the name is locked until settled, so the creation or transfer lock no longer applies. * Don’t think the creation or transfer locks had anything to do with the UDRP. The lock for the UDRP on notification is separate. The length of a creation lock shouldn’t have any bearing on how long it takes to complete a UDRP. These locks should be mutually exclusive. * The brand protection services are pretty quick to file a UDRP. Once settled, the creation lock would still apply. * This seems a non-issue… very few UDRPs filed within first 30 days as there would rarely be any usage by then, plus time to prepare and file. * Once the creation lock expires, the UDRP lock still applies. If we are looking at 10 days, if a UDRP is filed in 12 days then the name might have been transferred, in which case some of the UDRP filing would have to be updated to reflect the transfer. This was also an issue that WIPO brought up. If a complaint is filed, but the domain is not locked in time, and transferred to a new Registrar, then the admin process has to reset as owner(RNH)/Registrar have changed. * Even if they were to change the registrar, another 10-day transfer lock would apply. * Question: If we were to standardize a post-creation or transfer lock, would this be a registry lock or a registrar lock? Answer: Roger’s assumption was that the lock was enforced at the registrar level. Registries would only be brought in if there was a court case. The post-creation and post-transfer would be the registrar handling the locking of the domain during that period. * Question: There this also an open question as to how registry lock is handled during the transfer process? When is a registry lock removed or put back on? * Think the registry lock is outside the transfer policy. * Question: While the registry lock service is out of scope, there still is an issue of when the registry lock is dealt with? Seems like that point is in scope for this WG. * If the registry lock doesn’t come off, then the losing registrar will deny the transfer to the gaining registrar. * Seems that it would be good to have a stated policy on this – even if the statement is that the policy does not address this. But think the registrars would want to know what are their obligations. * Don’t see why it needs to be treated differently than any other lock? If the domain owner who requested it in the first place asked for it to be removed, then it gets removed. if not, isn't the whole point of the lock to prevent a transfer? * In the swimlane it is the sponsoring registrar’s responsibility to address any locks, including registry locks. * Seems that we’ll need another swimlane review session. In relation to who does what and when, if we look at this in the swimlane in general the moment the TAC is provisioned (which is an automated step), if there are any locks that the sponsoring registrar determines would prevent the transfer they shouldn’t be provisioning the TAC, the losing/sponsor registrar should resolve any locks. If all the locks are not cured there is an out to kick it back to the losing registrar. * The registry still has to do that final check. * The locks that we are talking about are in terms of EPP statuses being set. There really is no such thing as a “registry lock”, but a set of EPP statuses. Should talk in terms of service statuses. * “5. Registry Lock: Registry Operator may offer the Registry Lock service, which is a registry service that allows an authorized representative from the sponsoring Registrar to request the activation or deactivation of any of the following EPP statuses: serverUpdateProhibited, serverDeleteProhibited and⁄or serverTransferProhibited.” * A registry will set these EPP statuses as part of a registry lock service in order to protect registrants. There is an interaction with these registry lock statuses with the transfers that we need to understand. A registry to create a lock service that a RNH could ask for a transfer, registrar handles the client statuses that they have to cure, but the registry statuses stay in place. The registry gets a transfer request, but how do they distinguish that from an attack? The registrar of record would get a notification and then would have to notify the RNH, cure the lock, get the name transferred, and then the registry would reinstitute the lock. * Maybe the Registry which offers the lock service could include in the lock removal process that the RNH should tell them the correct gaining registrar and the Registry only allows the transfer to that registrar. * Don’t think we should treat registry lock as any special. Could simplify it by looking just at the EPP status. * The window of vulnerability is the time period between when the registry lock status is removed until it is restored. That’s a vulnerability for the registrant, since the TAC is at risk of getting lost or stolen. b. Update From ICANN Org Compliance re: “3.9.3 Domain name in Registrar Lock Status, unless the Registered Name Holder is provided with the reasonable opportunity and ability to unlock the domain name prior to the Transfer Request.” * Compliance invokes 3.9.3 when the domain has an internal lock applied. Example is an internal lock for additional security. The registrant had to follow some steps to request for the lock to be disabled. Generally, the registrar can’t deny a transfer if an internal lock has been applied without giving an opportunity for the registrant to request that the internal lock is removed. Helpful if the policy could provide clarification on what is “reasonable.” 3. Begin discussion on bulk use cases (60 minutes) Related charter question: “b5) Should the ability for registrants to request AuthInfo Codes in bulk be streamlined and codified? If so, should additional security measures be considered?” See AuthInfo Codes Working Document<https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0A...>, page 9. * Theo Geurts: In the Netherlands, if you want to transfer your portfolio from one registrar to another, you provide the names to the gaining registrar, the registry contacts the losing registrar to get the necessary verifications, then the registry moves the database. Pretty easy and cost effective. Dutch registry charges 50 Euro for a database switch. Current bulk transfers are overly complex. * For a lot of TLDs it’s even easier as the transfer is instant. * Would like to see an additional security level and claw back because of the number of domains. * Think we should be aware that this already happens in the gTLD space. As long as there can be a transfer that doesn’t go against the transfer policy, those transfers can happen. * We are talking about large-scale transfers outside of BTAPPA. * Overall the bulk transfer process should be similar to the single-domain transfer. * Question: Have we talked about the contact information – how would that be handled for bulk transfers? Couldn’t find recommendations on contact information in the AuthInfo Code working document. * I don’t think that contact info is needed… because the gaining registrar literally has to know the registrant. * Think that the BTAPPA is a fast-track registry service. There is pre-approved boilerplate language, so we would have to make sure that our recommendations don’t interfere with things that already exist. Also, not clear in the charter question what “bulk” means, but it is defined in the BTAPPA process. * Think we are going to discuss what “bulk” is. * So areas that could be different are (1) how the TAC is obtained, (2) if the notice of TAC provision needs to be sent once or multiple times, (3) if multiple domains + TACs can be submitted in one order to the registry (does it matter?) (4) how is it verified that they should all go together, (5) does the contact info all have to be the same pre-transfer, (6) does the contact info all have to be the same post-transfer. * Need to think also about whether a year is added to the extension. * Need to separate this out from BTAPPA. 4. AOB (5 minutes) * Next call: ICANN73 session on Tuesday 29 March 2022 at 16:00 UTC