[GNSO-TPR] Notes and action items: TPR WG on 19 Dec at 1600 UTC

Tue Dec 19 17:22:44 UTC 2023

Dear TPR WG members,

Please find below the brief notes and action items from today’s meeting.

The next meeting will be in three weeks on Tuesday, 09 January 2024 at 1600 UTC.

Kind regards,

Christian, Caitlin, Berry and Julie

ACTION ITEMS/HOMEWORK: None captured.

Transfer Policy Review - Meeting #112

Proposed Agenda

19 December 2023

Notes:

1. Welcome and Chair updates

  *   This is our last call of the year – resuming on 09 January in two weeks, same time.
  *   Eight meetings before ICANN79; finish up COR and return to any outstanding items.
  *   Call for updates: None provided.

2. Discussion of Security Measures: COR + Registrar Transfers – See attached slides.

  *   Moving on from COR only to COR + TAC request.
  *   Wrap up COR only and COR + TAC request security measures following the break and before ICANN79.
  *   60-day lock seems to be causing frustration and doesn’t seem to provide increased security.

Discussion – option 1 (slide 3):

  *   Question: Doesn’t the registrar do a validation/security check. Answer: 5-day window was for registrars to do due diligence/security/validation check. Some TAC request may be almost instantaneously fulfilled; other may take longer because of check.
  *   Last bullet is an option for registrar to offer or not.
  *   Usually not what happens: usually registrant logs into their account – don’t usually get a TAC request via email.
  *   Thinks the intent was the above: TAC request comes in and then registrar notices it’s from a different email.
  *   The order is usually that the registrant requests a TAC but then notice that they need to update their info.
  *   Compliance has had lots of complaints when they need to request a TAC but can’t because they need to update their contact info.
  *   This is not specific because it is registrar-specific.
  *   This is one of several options.

Discussion – option 2 (slide 5):

  *   That 5-day window for the registrar allows a security check.  In the Group 1A discussions we covered this.
  *   This is combining two processes – updating contact info and requesting the TAC – that is not necessary and creates a dependency.
  *   If we look at the example, that is not how the TAC is requested (via email).  Agree not to combine processes and we already have an option for the registrar to validate.
  *   TAC request is coming in however.
  *   This could be a business decision by a registrar.  Like the email notification but don’t require approval from both the old and new registrant.
  *   The timing of the email change – business decision as to whether that requires validation/5-day wait.  Losing registrar’s responsibility.  Change of registrant does happen often around a change of contact.
  *   We need to factor in how some registrars are processing expired deletions.  Those may change contact info.
  *   Allowing an objection by the losing registrant is an opportunity for fraud. No need for the losing registrant to be involved.
  *   The above is an argument for this to be a registrar’s business decision.

Discussion – Option 3 (slide 7):

  *   Not seeing how this provides an added security benefit – same security as option 1, registrar to validate.
  *   This makes a lot of sense – should verify if you change contact info, but doesn’t add security.
  *   This can be used against registrants. Could keep a registrant from moving to a new registrar.

Discussion – Option 4 (slide 9):

  *   This option has been put up by different people.  Addresses Compliance issues.
  *   Like this option – opt out is good, that the registrar can remove the lock as long as there is agreement.
  *   For Compliance – is there a requirement for documentation?
  *   The extra lock doesn’t add security.
  *   Two things: The transfer lock after COR is causing problems so if the registrant can remove that might address those complaints, but would there be  more domain thefts?
  *   Have to consider whether this adds anything. Have discussed that COR doesn’t cause domain theft.
  *   Sounds like we are adding complexity without added security.  Can we get the data we requested from Compliance?
  *   This feels like a security measure but not sure it is and also adds cost and risk.

Discussion --- Option 5 (slide 11):

  *   Run into a whole bunch of operational issues.
  *   Seems difficult to enforce.
  *   Not sure the benefit outweighs the added complexity.

Discussion – Option 6 (slide 13)

  *   Any additional thoughts?
  *   Good support for an argument to separate these processes, such as not making the 5-day window being a dependency.  We aren’t solving the problem with these options, but we are creating more complexity.  Seems like there is some agreement to separate COR from TAC request.

3. Poll Question 2: COR Followed by a TAC Request

Of the Options discussed thus far, which can you support as a minimum requirement for Registrars when a TAC request follows a completed COR? Select your first, second, and third choices (if applicable)

Option 1: No special requirements are necessary. 58%

Option 2: There should be a waiting period before issuing the TAC, allowing time for objections. 58%

Option 3: Before issuing the TAC, changes to RNH/Account Holder information must be verified.* 42%

Option 4: Following a COR, impose a 30-day transfer lock, but allow Registrars to lift it, if agreed. 58%

Option 5: Registrars must offer registrants an opt-in option for added protection. 67%

Option 6: Other: _________ 83%

Option 7: None of the above 42% (not making a choice)

Discussion:

  *   Looks like other/no special requirements is the favored option.
  *   Don’t think we are looking for the exact answer today.
  *   Last week there was agreement if there is a change of registrant the notice goes to the losing registrant.
  *   Today it seems that there is agreement that COR is handled as a COR and a TAC request is handled separately.
  *   Need to get some recommendations out of this.

4. AOB

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20231219/fde403dd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Change of Registrant - TPR Group 1(b) II - Mtg #111.pdf
Type: application/pdf
Size: 1883885 bytes
Desc: Change of Registrant - TPR Group 1(b) II - Mtg #111.pdf
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20231219/fde403dd/ChangeofRegistrant-TPRGroup1bII-Mtg111-0001.pdf>