[GNSO-TPR] Notes and action items - TPR WG Meeting #53 - 12 July 2022 at 16:00 UTC

Tue Jul 12 19:06:20 UTC 2022

Dear TPR WG members,

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

The next meeting will be Tuesday, 19 July at 16:00 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin

Action Items:

  1.  WG members to go back to their representative groups to determine if there are any issues that need to be brought forward to the WG, but particularly the question of whether the 60-day lock for CoR should be removed, and replacing affirmation confirmation requirements with notification.  See Key Elements of CoR (table on page 8) at: https://docs.google.com/document/d/1gu4sXGvyJeWJIfvaK_I7GKA6lAdfKFPQKaN4UMgzmcE/edit.

  1.  WG members to review the 60-day lock Working Document at https://docs.google.com/document/d/1SFMDrDazU7iM-1_mvf05ZMQ-ZS2GVJ1mtIXZNcI7F1E/edit and provide comments/suggestions to the charter questions beginning on page 3.

Notes:

Transfer Policy Review Phase 1(b) - Meeting #53

Proposed Agenda

12 July 2022

1. Roll Call & SOI updates

  *   Jim Galvin – His employer Donuts has rebranded to Identity Digital.  Otherwise everything is the same.  See: https://community.icann.org/display/gnsosoi/James+M+Galvin+SOI.

2. Welcome and Chair Updates

  *   Public comment period for the Phase 1(a) Initial Report closes on 02 August.  Please get your comment in.
  *   Steiner Grotterod, At-Large: Some comments on why we set 14 days for the duration of the TAC Time to Live (TTL)?
     *   For security purposes, but don’t recall if we talked about other timeframes.
     *   14 days was originally suggested by TechOps and the WG thought it seemed like a reasonable number, but staff will check.  Also time to complete locks or other issues before transfer.  The CPH Tech Ops Group concluded “in regard to the TTL the group suggested a validity of no more than 14 days, presented as the total number of hours until TTL expiration. There was no resolution for a minimum TTL requirement, because registrars with different business models may have different requirements for how quickly a domain name gets unlocked and transferred. More work on any of these topics is needed.”
     *   General discussion was that in those cases where things needed to be resolved sufficient time was needed.
     *   That would be considered a maximum.  The TAC being active opens the name up for a transfer window, which makes it exposed, so we want to allow shorter than 14 days.
     *   See the deliberations on TTL on pages 8 and 9 here: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0AK00/edit

3. WG Analysis of Key Elements of CoR (continued from previous meeting) – see: working document at: https://docs.google.com/document/d/1gu4sXGvyJeWJIfvaK_I7GKA6lAdfKFPQKaN4UMgzmcE/edit  (table on page 8)

Impose a 60-day inter-registrar transfer lock, unless the Registered Name Holder had previously opted out (Section II.C.2).

WG Notes:

  *   The fact that the policy says there is a 60-day lock, how that is done isn’t something we have to determine here.  Maybe we consider to make it shorter, eliminate it, or allow it to be unlocked.
  *   Some favor removing the lock.  Registrars could have their own policies in place.  If we keep it, it should be changed to 30 days and make it standard so everyone does it, and/or a way to opt out of it – maybe the registrar makes an arrangement with the registrant.
  *   Think everyone agrees that 60 days is too long.

II.C.2 The Registrar must impose a 60-day inter-registrar transfer lock [footnote 4<https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en#foot4>] following a Change of Registrant, provided, however, that the Registrar may allow the Registered Name Holder to opt out of the 60-day inter-registrar transfer lock prior to any Change of Registrant request.

 Footnote 4<https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en#note4>: The Registrar may, but is not required to, impose restrictions on the removal of the lock described in Section II.C.2. For example, the Registrar will only remove the lock after five business days have passed, the lock removal must be authorized via the Prior Registrant's affirmative response to email, etc.

Notes: Inter-Registrar Transfer Lock following a Change of Registrant: Registrars are not required to apply a specific EPP status code for the 60-day inter-registrar transfer lock described in section II.C.2; however, if a registrar chooses to apply the clientTransferProhibited EPP status code, it must also lock the name in a way that prohibits the Registered Name Holder from removing the lock per section I.A.5.1.

  *   See staff document on 60-day lock: https://docs.google.com/document/d/1SFMDrDazU7iM-1_mvf05ZMQ-ZS2GVJ1mtIXZNcI7F1E/edit
  *   Policy Status Report and Issue Report have the most detail.

WG Notes:

  *   If it were changed to 30 days some WG members suggested that that would not be a significant improvement. Current policy seems to invite some confusion because some registrars don’t offer and opt out – the policy isn’t consistent.  Also the timing of the opt out is inconsistent.
  *   The policy isn’t very consumer-registrant friendly.
  *   Faced with a definitional challenge: the definition of Change of Registrant is difficult to nail down.  Unclear if the policy distinguishes between change of registrant data and change from one party to another.  The lock isn’t needed in the first instance.  Maybe try to organize the language.
  *   For historical reference, the IRTP-C WG mentioned an opt out, but left it open for registrars to determine to offer an opt out of the 60-day lock. Specifically, “If a registrar chooses to offer an option for registrants to opt out, the process to remove this restriction must use a generally accepted method of authentication.” This, of course, does not prevent this WG from establishing consistent opt out requirements, but we thought it would be helpful to provide some context as to why there is currently an inconsistency.  (Quotation is from p. 27 of the IRTP-C Final Report: https://gnso.icann.org/sites/default/files/filefield_34607/irtp-c-final-report-09oct12-en.pdf)
  *   Helpful if for the name component everyone sets the rules at the beginning.
  *   May be helpful to look at the IRTP-C use cases (see discussion below).

ACTION ITEM: WG members to go back to their representative groups to determine if there are any issues that need to be brought forward to the WG, but particularly the question of whether the 60-day lock for CoR should be removed, and replacing affirmation confirmation requirements with notification.  See Key Elements of CoR (table on page 8) at: https://docs.google.com/document/d/1gu4sXGvyJeWJIfvaK_I7GKA6lAdfKFPQKaN4UMgzmcE/edit.

4. Review applicability of use cases/case studies from IRTP-C – see: Annex G of the Final Report on pages  72 – 77, at:   https://gnso.icann.org/sites/default/files/filefield_34607/irtp-c-final-report-09oct12-en.pdf<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/filefield_34607/irtp-c-final-report-09oct12-en.pdf__;!!PtGJab4!5JMBGvC0g7vRK1evvSw1WuJp_vA67GLW5qoYSg81cGhM20dM2IKAPofgioO85MEO0rtFQUd2kmOmYbwIB3YE96Rzm9HyUCa3LQ$>

Case 1: Change Registrar: This falls under current IRTP policy. Mike wants to move his domain from one registrar to another. No other parties involved. Because the Registrant hasn’t changed, Registrant info must remain the same and the “waive lock” option is not needed or presented

Case 2: Change Registrar: Mary (a business owner) wants to buy a domain from Mike for use in her business. She and Mike are using the same registrar. Because she plans to use the name for a long (me, and wants to protect it from hijacking, she leaves the lock in place.

Case 3: Waive the Registrar Hopping Safeguard: Susan (a domain investor) wants waive the lock in anticipation of a future transaction

Case 4: Change Registrant AND Registrar: Ann (an individual) wants to buy a domain from Mike for use for her blog. She and Mike are NOT using the same registrar.  Because she plans to use the name for a long time, and wants to protect it from hijacking, she leaves the lock in place.

Case 5: Change Registrant and Registrar and Waive Safeguard: Susan (a domain investor) wants to buy a domain asset from Mike. She and Mike are NOT using the same registrar. Because she wants the ﬂexibility to sell the name, and has sophisticated antihijacking of her own, she waives the lock.

Case 6: Minor Change to Registrant Information: Nathalie (a recently married blogger) wants to update her Registrant information to her married name.  Because she has no plans to transfer her domain and wants to protect from hijacking, she declines the opportunity to waive the lock when it’s presented by her registrar.  Note: technically this is identical to Use Case 2.

Case 7: Minor change to Registrant information, waiving the post<change lock: Nele (an unhappy registrar customer) wants to make a minor change to her registrant information. She is willing to waive the safeguard in order to have the option to quickly transfer to a new registrar.

Discussion:

  *   Some cases don’t apply anymore because of GDPR.
  *   All comes back to what is a material change.  Should there be different policies for changing registrant information and changing registrant.
  *   How do you delineate each one of the scenarios.
  *   If change of registrant happens at the same registrar then there’s less of a security issue.  If outside the same registrar we have a 30-day lock anyway.
  *   How does a registrant air a grievance – should be able to initiate a transfer dispute.
  *   Once the transfer goes to another registrar there will be a lock put on it and because it is more difficult to undo.
  *   There are so many updates to a domain names on a day-to-day basis, these restrictions don’t make it easier for people to update their data.
  *   Relying on older anecdotal evidence on which to base a policy – there should be a basis to infringe on the right of a registrant to change ownership.  Is this something that we should make registrars track?
  *   Can probably re-use these use cases to document our thought processes.  Some don’t seem to fit though.
  *   See page 12 of the charter for proposed metrics: https://gnso.icann.org/sites/default/files/file/field-file-attach/draft-charter-pdp-transfer-policy-review-2-24mar21-en.pdf -- could put this into the policy recommendations.

60-day lock policy questions:

d4) Survey responses and data provided by ICANN’s Global Support Center indicate that registrants do not understand the 60-day lock and express frustration when it prevents them from completing an inter-registrar transfer. Does the 60-day lock meet the objective of reducing the incidence of domain hijacking? What data is available to help answer this question? Is the 60-day lock the most appropriate and efficient mechanism for reducing the incidence of hijacking? If not, what alternative mechanisms might be used to meet the same goals? Are there technical solutions, such as those using the control panel or two-factor authentication, or other alternatives that should be explored?

d5) Survey responses and data provided by ICANN’s Global Support Center and Contractual Compliance Department indicate that registrants have expressed significant frustration with their inability to remove the 60-day lock. If the 60-day lock is retained, to what extent should there be a process or options to remove the 60-day lock?

d6) Due to requirements under privacy law, certain previously public fields, such as registrant name and email may be redacted by the registrar. Is there data to support the idea that the lack of public access to this information has reduced the risk of hijacking and has therefore obviated the need for the 60-day lock when underlying registrant information is changed?

d7) In its survey response, the Registrar Stakeholder Group indicated that the 60-day lock hinders corporate acquisitions, consolidations, and divestitures of large lists of domains to new legal entities. To what extent should this concern be taken into consideration in reviewing the60-day lock?

d8) If the policy is retained, are there areas of the existing policy that require clarification? For example, based on complaints received by ICANN Contractual Compliance, the following areas of the policy may be appropriate to review and clarify: [see examples]

Discussion:

  *   As noted in our charter, are there any reporting/tracking requirements that the WG wants to recommend?  Does the benefit of having the data outweigh the cost?
  *   We are saying there’s no specific data at this time to show that there is a problem.  What we have is anecdotal.
  *   Seems like the lock still provides security, but not clear that it’s needed.
  *   Our job is to go through the charter questions, answer them, and make any recommendations.
  *   Is a lock (of any duration) still important?
  *   Important that you are taking these issues back to the SGs/Cs and see if there are any issues that need to be brought forward, particularly on removing the lock and replacing affirmative confirmation with notification.  Encourage anyone who wants a lock of any duration to provide a rationale.
  *   Plan is for the WG to go into the 60-day working doc to make comments into each of these charter questions to get discussions going.  See 60-day lock working doc at https://docs.google.com/document/d/1SFMDrDazU7iM-1_mvf05ZMQ-ZS2GVJ1mtIXZNcI7F1E/edit.
  *   Pull the use case scenarios into our discussion doc.

ACTION ITEM: WG members to review the 60-day lock Working Document at https://docs.google.com/document/d/1SFMDrDazU7iM-1_mvf05ZMQ-ZS2GVJ1mtIXZNcI7F1E/edit and provide comments/suggestions to the charter questions beginning on page 3.

5. AOB -- Next session: Tuesday 19 July at 16:00 UTC

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20220712/3b5bd4b3/attachment-0001.html>