[GNSO-TPR] Notes and action items - TPR WG Meeting #53 - 12 July 2022 at 16:00 UTC
Mike Rodenbaugh
mike at rodenbaugh.com
Tue Jul 12 21:35:57 UTC 2022
I want to get clear on the effect of this proposed change. This 60-day
lock is optional now. We are talking about removing that optional lock
from the IRTP, and it seems we are getting to consensus to remove it. I
suppose that removing it from the Policy is not the same as prohibiting
registrars from imposing such a lock anyway via their TOS. So, are we also
talking about prohibiting registrars from imposing any such lock upon
Change of Registrant? Otherwise, I guess I do not see the point of
removing it from the Policy. Maybe I am just missing something here...
Thanks,
Mike
[image: Logo]
Mike Rodenbaugh
address:
548 Market Street, Box 55819
San Francisco, CA 94104
email:
mike at rodenbaugh.com
phone:
+1 (415) 738-8087
On Tue, Jul 12, 2022 at 12:06 PM Julie Hedlund <julie.hedlund at icann.org>
wrote:
> 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
> <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 flexibility 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
> <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
>
>
> _______________________________________________
> GNSO-TPR mailing list
> GNSO-TPR at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-tpr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20220712/b69e978b/attachment-0001.html>
More information about the GNSO-TPR
mailing list