[GNSO-TPR] Notes and action items: TPR WG on 30 Jan at 1600 UTC

Tue Jan 30 17:35:28 UTC 2024

Dear TPR WG members,

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

The next meeting will be Tuesday, 06 February 2024 at 1600 UTC.

Kind regards,

Christian, Caitlin, Berry and Julie

ACTION ITEMS/HOMEWORK: WG to complete the COR Reduction Rationale document at: https://docs.google.com/document/d/1DpDO2BYTl6TA7ApfPpG3Hpl13nrv4y4x9B3hImrx_Fc/edit?usp=sharing

Transfer Policy Review - Meeting #116

Proposed Agenda

30 January 2024

Notes:

1. Welcome and Chair updates

  *   Planning for ICANN79:
     *   Only 4 meetings leading up to ICANN79; need to complete COR recommendations.
     *   Two sessions – agendas TBD.
  *   WG Self-Assessment Survey: Link will be sent tomorrow for an interim survey.

2. Transfer Complaint metrics with ICANN Contractual Compliance -- ICANN Compliance (Holida Yanik): Sent attached report in response to WG request.

Discussion:

  *   Discrepancies may arise because one case may involve several domain names.  Also, cases may span both old and new (NSP) systems.
  *   As we consider this, how to correlated it to registrations – how many complaints involve multiple domain names?  Don’t have those numbers, but it is quite often.
  *   Just a picture of what is going on in the wider world – just a small fraction.  Good that most cases are closed without going to the registrar, but also reflects a lot of confusion.  Suggests that the WG’s plan to go with a simple approach for COR is the right approach.
  *   The numbers are small so need to look at the pain points.
  *   Found it very confusing to go through the report  -- such as the difference between unauthorized CORs and CORs denied.  It seems like there is a low percentage of complaints relative to registrations.  This supports the notion of moving to a notification process.
  *   ICANN Compliance: Not all registrants are aware of ICANN. Page 2 – unauthorized complaints; page 4 – inability to complete the COR (registrants).
  *   From the chat:
     *   These are just the Complaints that made it to ICANN, not the entire universe of Complaints, most of which would have been dealt with by the registrars themselves.
     *   Yes - so in our notice process we've discussed requiring the Rr to provide info about how to address complaints, sounds like that will indeed be useful.

3. COR Polls and Discussion: Elimination, Notifications, and Definitions – See attached slides.

  *   The reason for the poll questions is to help determine a recommendation.

Poll 1:
At this stage in the group's discussions, are you convinced that the Change of Registrant (COR) policy should be eliminated entirely?

  1.  YES, there should no longer be any COR policy anywhere – 50%
  2.  NO, there should remain a reduced COR policy somewhere  – 50%

Poll 2:
At this stage in the group's discussions, are you convinced there should be mandatory notifications sent to the Prior & New Registrant when specific contact fields are updated?

  1.  YES, notifications should be mandatory  – 60%
  2.  NO, notifications should be optional  – 40%

Discussion:

  *   There is a close split because there are only two choices – no option to opt out.
  *   Trying to be as clear as possible.
  *   Some agreement to have COR somewhere else – doesn’t include inter-registrar policy addressed elsewhere.
  *   Notifications should exist but dealt with elsewhere, outside of the Transfer Policy.
  *   Elimination completely but address elsewhere? What is the specific proposal?  There isn’t one – but there are requirements spread around elsewhere. But don’t think everything is covered, such as mandatory notifications.
  *   Not a strong recommendation that some other group needs to determine where these notifications are addressed; not sure what you would get.
  *   GNSO Council would have to make the decision of where that is addressed.
  *   Question: Is COR a Transfer Policy issue?
  *   If we are eliminating COR, first we are eliminating the 60- or 30-) day lock; looks like a complete gutting of protections.
  *   If we eliminate COR, could we keep the option for the registrar to put on a lock if it determines that a transfer is fraudulent.
  *   Not gutting protections, but policy isn’t doing what it was designed to do (for protecting registrants); also, it’s not a transfer, but a change of ownership.  Keep the bare minimum.
  *   Staff: If section 2 of Transfer Policy is removed and MUSTs turned to MAYs for notifications, this would no longer be a policy, but  perhaps an advisory.
  *   Maybe Section 2 is changed to an advisory section on notification.
  *   Don’t think removing entirely (no notifications) would be acceptable by the public.  Have to keep the notifications.  Against putting it back to Council to decide – no idea how long that would take.
  *   50/50 split is just the starting point – what would it take to get everyone to agree? A two-pronged approach to addressing disputes, including a registrant initiated transfer dispute resolution policy.
  *   Sounds like elimination of Section 2 is not supported by this group.
  *   Agree that we need a policy that allows a registrant to reverse a transfer.
  *   Need to work out the details of a notification system.
  *   If we stick with a reduced COR and registrars have their own policies, do we still need to define “material change”.  Could be confusing if registrars all define it differently.
  *   Potential middle path – having the option for the registrant opt out of a mandatory notification?
  *   Still see a big issue. What if the person opting out is doing it for fraudulent reasons?
  *   If we are going to require it we shouldn’t allow an opt out.
  *   Let’s assume if COR changes to notifications those should be mandatory.
  *   Think about what a notification would entail.
  *   Opt out could need to be confirmed/verified as valid.
  *   Not envisioning the notification as an email.  Could be something else.
  *   Keep a small modified Section 2 that is mandatory notifications. Still need to address definitions and the details of notifications.
  *   See slides 6 and 7 – notification definitions and triggers.

Poll 3:
For the purposes of a reduced COR/notification policy, what does the WG need to define?

  1.  Change of Registrant
  2.  Change of Control
  3.  Both
  4.  Neither

Discussion:

  *   Neither can be to leave it as is.
  *   Not sure definitions are irrelevant – just what triggers a notification – change of registrant data.
  *   Don’t need to complete the poll. Support for Change of Registrant data as the trigger for notification.  Might still need some clarification of what that would be.

ACTION ITEM: WG to complete the COR Reduction Rationale document at: https://docs.google.com/document/d/1DpDO2BYTl6TA7ApfPpG3Hpl13nrv4y4x9B3hImrx_Fc/edit?usp=sharing

4. AOB

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20240130/624b6b04/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Change of Registrant - TPR Group 1(b) II - Mtg #116.pdf
Type: application/pdf
Size: 1207604 bytes
Desc: Change of Registrant - TPR Group 1(b) II - Mtg #116.pdf
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20240130/624b6b04/ChangeofRegistrant-TPRGroup1bII-Mtg116-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Transfer Complaints Metrics_Sept 2020_Oct 2023.pdf
Type: application/pdf
Size: 102091 bytes
Desc: Transfer Complaints Metrics_Sept 2020_Oct 2023.pdf
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20240130/624b6b04/TransferComplaintsMetrics_Sept2020_Oct2023-0001.pdf>