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, 19 April 2022 at 16:00 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin 

Action Items:

1. WG members to provide language to justify the 30-day post-creation and post-transfer locks in the Working document [docs.google.com].

2. REMINDER from 05 April meeting: WG members to review suggested new language from Sarah Wyld in the bulk use cases Working document [docs.google.com] and possible suggested text (in recommendations 3, 8, and 9?) that the TAC has to be unique using the phrase “randomly generated value”.

Notes:

Transfer Policy Review Phase 1 - Meeting #42

Tuesday, 12 April 2022

Proposed Agenda

1. Roll Call & SOI updates

2. Welcome & Chair updates

• Small Team on Denial of Transfer/NACKing: Meeting this week and will have draft language for the WG to review.
• Single TAC for multiple domains: in Bulk Use Cases Working Document Sarah Wyld has suggested language for the WG review and comment.
• Reminder that as work is winding down the big tactical discussions are shortly behind us.  We’ll be finalizing draft recommendations and closing up anything that is still open.  Do think we have addressed the charter questions.  Goal is to have the Initial Report in good shape in June.

ACTION ITEM: REMINDER from 05 April meeting: WG members to review suggested new language from Sarah Wyld in the bulk use cases Working document [docs.google.com] and possible suggested text (in recommendations 3, 8, and 9?) that the TAC has to be unique using the phrase “randomly generated value”.

3. Post-creation and post-transfer locks – see: Working document [docs.google.com]

• Have some feedback from groups that 10 days may be too short.
• Asking some questions in a short poll – whether there should be a post-creation lock, period of time, and enforcement, and same for a post-transfer lock.  Not talking about a specific type of lock.  Just whether there is a window of time during which a transfer shouldn’t occur.
• Post-creation lock is a window of time after a domain is created that it cannot be transferred.  The other item that was brought up was payment, that also had a window of time associate with it.  See summary of the reasons suggested in the working document here on page 3: https://docs.google.com/document/d/1RGow_TYPSESvI9DFweF3T_g7vgufg6zCwEdSsUjBfqs/edit.

Poll Responses:

1. Should a transfer lock be required after a domain is registered?

• Yes – 88% responses
• No – 13% responses
• No answer – 0% responses

Discussion:

• Strong support for a lock.
• Note that today this is an optional lock; some registrars do it and some don’t.  Some registries do it.
• This is what we expected.

2. What should be the period of the post-creation lock?

• 10 days – 50% responses
• 30 days – 39% responses
• 60 days – 11% responses
• Other period/don’t know – 0% responses

Discussion:

• Some thought 60 days was too long.  Seems also that 10 days could be too short for some.
• Some suggest that the period should be left to the registrar with a minimum requirement of 10 days.
• Standardizing the period could be helpful.
• Could there be exceptions to allow 10 days?
• Could be a lot of value to aligning the time with the post-transfer lock period.  Maybe we need to not decide until we decide what the fast-undo period would be, to make them aligned.
• If the lock period is longer we should consider guardrails.
• Question: Can we come back to Phase 1 recommendations in Phase 2?  Answer: There will be a separate Final Report for Phases 1 and 2, so these are separate efforts.  The idea when we drafted the charter was when the Phase 1 work is completed getting this out to market as fast as possible means that the IRT can start up the work on the Phase 1 recommendations.  If Phase 2 required a change to a Phase1 recommendation this could be done because the recommendations won’t be implemented overnight, but the intention was that Phase 1 would be implemented while Phase 2 work is ongoing.
• By and large there seems to be a high-degree of agreement that there should be a period of time post-creation doesn’t occur and some agreement on a 10- or 30-day period.  Best if we have agreement before going into public comment on the Initial Report.  If we have both options in the Initial Report we need strong rationale for each.
• Key here is what the WG will take to public comment – better if we can take a limited set, with one time period being best if we can agree.
• Question:  Can we get justification from people who support 10 days and those who support 30 days?
• There are different business registrar business models. Many of the reseller registrars take a pre-payment, so there are certain players that have surety of payment as part of their business model.  Others have payment in real time and it’s not until a billing cycle occurs you wouldn’t see fraudulent payments.  60 days allows time for that to occur, but 30 days may not.  This also is tethered to fast undo.
• If we agree on 30 days, we need to justify it.

3. Should a transfer lock be required after a domain is transferred to a new registrar?

• Yes – 94% responses
• No – 6% responses
• No answer – 0% responses

Discussion:

• Need a transfer lock because of the potential for domain theft.
• Need to be thinking about the registrant and certainty of title/transfer of title.  This about the period of time for lock plus undo.  Need to find a sweet spot.  Perhaps rather than discuss the lock period, talk about the lock plus undo period.  Should be a fixed number of days and not per registrar or registry.
• A flipper could wait the 30 days (post-transfer lock) before selling? You aren’t initiated a transfer in order to participate in the marketplace.  Waiting period could affect when funds are released from escrow.
• Would think we would want to balance protection for the average registrar and risks of abuse.
• Most change of registrars would correspond with a change of registrant.  When the customer changes ownership, that is the change of registrant lock.
• As above, if we agree on 30 days when have to justify it.
• Poll shows support for a post-transfer lock.

4. What should be the period of the post-transfer lock?

• 10 days – 22% responses
• 30 days – 72% responses
• 60 days – 6% responses
• Other period/don’t know – 0% responses

Discussion:

• Could there be a 3a question?  Do people want continuity between a post-creation and post-transfer lock?
• Seems to be support for continuity.
• Poll results suggest that some people switched from 10 to 30 days.  Seems that most feel 60 days is too long.
• Question: Should there be no exceptions?  Such if the registrar and registrant agree to a shorter period? Answer: That would not be allowed.
• Reminder: We are talking about edge cases.
• Wondering if 30 days could be a general rule with the possibility of exceptions?
• We are again leaning towards 30 days.  We haven’t yet gotten to any agreement on carve-outs.  Could be a question in the Initial Report for public comment.
• Seems logical that fast undo would fall within the lock period.
• What if there is no quick-undo process?  Maybe we shouldn’t assume that we can agree on such a process.
• We brought the fast-undo process discussion forward to see if we could agree on it and to consider it in the context of locks.

5. How should the lock requirements be implemented?

• Requirement in the Transfer Policy for a registrar lock – 80% responses
• Requirement in the Registry Agreement for a registry lock – 13% responses
• Other/don’t know – 7% responses

Discussion:

• Question: Registrars are bound through the RAA for consensus policies, and registries too, right?  Why put a requirement in Registry Agreement.  Answer: Just focus on whether it’s a registrar or registry lock.  Ignore the part about the agreement.
• Registrar locks can be removed, whereas that’s not possible with a registry lock.
• Don’t think that registries have enough information to properly support this.  You are overloading registry-specific rules with the need or purpose of registrars.  Concerned about how this would be implemented.
• Right now, for example, if a registry finds that there is a name being abused the registry may turn on various EPP statuses to prevent transfer, and may also take it out of the zone. Using those same locks for inter-registrar transfer would be overloading those mechanisms.
• Instead of talking about a specific status, talk about a window in time.
• Leaning toward registrar use and enforcement.
• If there is a policy that states the period of time, could the registrar disallow these locks or set something shorter?
• Big question is whether to go with 10 or 30 days.  Do we have support for one or the other?  Seems we have a good indication that some people want 30, but we need that to be documented with a solid rationale.

ACTION ITEM: WG members to provide language to justify the 30-day post-creation and post-transfer locks in the Working document [docs.google.com].

4. AOB 

• Next call: Tuesday 19 April 2022 at 16:00 UTC.