[GNSO-TPR] Notes and action items - TPR WG Meeting #41 - 05 April 2022

Tue Apr 5 17:35:16 UTC 2022

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

Best regards,

Emily, Julie, Berry, and Caitlin

Action Items:

  1.  Take to the list, starting with suggested new language from Sarah Wyld in the bulk use cases Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1mqPITDShqiVQ4rH6x-FlvePmL_c05CtyWGgkpj9-77I/edit__;!!PtGJab4!rEDR13o3d-aTSLeZNJgupVDk8jNA1kK9UYqUzMGMTJRewCzadpr68mFXJvImeFamXnGYmmSV4A$> and possible suggested text (in recommendations 3, 8, and 9?) that the TAC has to be unique using the phrase “randomly generated value”.
  2.  Leadership and staff to research the issue of whether changes to the extension of the expiration date after a transfer are in scope.
Notes:

Transfer Policy Review Phase 1 - Meeting #41
Tuesday, 05 April 2022
Proposed Agenda

1. Roll Call & SOI updates

2. Welcome & Chair updates

a. Zack Muscovitch, update from the BC: Transfer Policy Locks -- short summary on three different kinds of locks.  See email<https://mm.icann.org/pipermail/gnso-tpr/2022-April/000395.html> and below:

Post-Creation Lock
Ten days is too short. Leave it at 60 days if possible. Maybe 30 days is a happy medium, but 60 days is still preferable. The longer the better from a trademark enforcement perspective as it prevents having to redo a UDRP or demand letter, and also assists with preventing registrar hopping when a registrar is asked to take enforcement proceedings against an infringing or unlawfully used domain name.  There may be an issue in shortening the period from a registrar’s perspective, in that a registrar customer may take advantage of promotional / loss-leader type pricing for the initial year and then the customer moves away to another registrar.

Change of Registrant Lock
The default rule should be a transfer lock following a change of registrant. However, a registrar should be required in a transparent manner, to enable a registrant, upon request to opt-out of the transfer lock or to reduce the transfer lock, rather then leave it to each registrar to decide whether they will generally permit opt-outs. Nevertheless, each registrar should retain discretion as to whether to permit a transfer even if the registrant has ostensibly opted out, for security reasons. A transfer lock should not prevent registrants and businesses from effecting bona fide transfers when necessary or desirable. There should be a fact-based rationale for the determination of the length of the default transfer lock, whether it is 60 or 30 days, for example. A BC member is looking to see whether Domain Abuse Activity Reporting data can provide any insight into the appropriate length for transfer locks.

Change of Registrar Lock
This lock does not appear to be of significant concern as it would usually coincide with a change of registrant lock. However, a registrant should not be prevented from transferring a domain name from one registrar to another, even after a recent registrar change, unless there is another type of lock at play.

Questions/Discussion:

  *   Question: Post-creation lock – why is 10 days too short?   Answer: When a brand-protection company contacts a registrant about an abuse domain name, the registrant could say that the name just got transferred.  Longer post-creation lock there is a longer period to deal with abuse issues with the registrant.
  *   Question: Moving from registrar to another: gaining registrar wouldn’t know it was a transfer. Answer: If there is a change of registrant there should be a lock by default, but a change of registrar without a change of registrant shouldn’t have a lock.
  *   Question: post-creation lock or change to registrant – what is the EPP status?  Answer: We weren’t considering the technical term.  Just no ability to move it.
  *   Comment: Standardizing across the board should make it easier for registrants.
  *   Comment from BC: Agree with standardization as long as it is a longer period.
  *   Comment: When we do a change of registrar it could also be a change of registrant, so that would argue for the same lock period.
b. Schedule leading up to ICANN74 and production of Initial Report (see attached PDF):

  *   Several more sessions before we can wrap up our discussions.
  *   This week bulk use and fast undo.
  *   Small Team on NACK meeting on 06 April.
  *   Next week is locking.
  *   Re-evaluate TAC discussions.
  *   Then swimlane and draft recommendations for WG review.
  *   Goal is to get the report out right around ICANN74.
3. Continue discussion on bulk use cases – see: Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1mqPITDShqiVQ4rH6x-FlvePmL_c05CtyWGgkpj9-77I/edit__;!!PtGJab4!rEDR13o3d-aTSLeZNJgupVDk8jNA1kK9UYqUzMGMTJRewCzadpr68mFXJvImeFamXnGYmmSV4A$>

  *   Last talked about whether the registrar could assign the same TAC to a bulk transfer, as an option or a registrar/registrant agreement.
  *   BTAPPA is not viable.
  *   Plus BTAPPA is not available with every gTLD. Need a solution that works across all gTLDs.
  *   With any transfer today the expiration date is extended by one year.  If there is no consensus to change it, it will stay that way.
  *   As much as possible any bulk action should mirror a single transfer.
  *   Not sure if changing the expiration date in in scope for this group.  We will check.
  *   Expiration date can be reduced, not sure which registrars have extensions.
  *   What about the ICANN transfer/transaction fee? Also to be “removed”? Not sure this is in scope.
  *   Extending the expiration for a year gives some incentive to the gaining registrar.
  *   Could include a question on this in the Initial Report.
  *   On the TAC, the requirement is always that the TAC is unique to the domain.
  *   This could mean that it needs to be the same TAC for each domain.  Not sure that the registry cares; whatever the registrar sets the registry takes.
  *   Are we recommending that the TAC is different for each domain in the transfer?  That each TAC and domain is a unique combination – the domain name could be the unique aspect.  But if this is the case, then we didn’t need to change the policy – they would all be unique by default.
  *   For bulk, you could have multiple domains but each one would have its own TAC.
  *   So maybe the question is if we want to make an exception to the requirement and allow one TAC per multiple domains?
  *   If the TAC is not null, it would be unique in the registry generally.
  *   In multi-domain transfers, for usability sake if the TTL on the TAC is sufficiently short you might be able to use the same TAC for multiple domains.
  *   What’s important if – currently the TAC is defined as unique in the domain name in the registrar.  If we are trying to make security better and more efficient, you need to add some rationale for why we are changing the security positioning in the policy and you should have some suggestions (maybe not policy) for solutions – such as short TTLs for multiple domains if you have one TAC for multiple, and addition identity checks for the registrant – such as two-factor authentication.
  *   Current recommendations don’t say anything about uniqueness, but it is in the policy:
See Auth-Info Codes Working Document<https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0AK00/edit?usp=sharing>: “Recommendation 9: The Working Group recommends that the TAC MUST be used no more than once per domain name. The Registry Operator MUST clear the TAC as part of completing the transfer request.”

  *   This is about uniqueness per domain name; and it needs to be one-time use because a registrar should have a single source of TACs and you don’t want replay attacks.
  *   The original intent was the one-time use.  Once the registry accepts the TAC it can’t be used again.
  *   We should make it clear that registrars should not restrict the number of domain names that can be transferred out.  But today’s policy doesn’t state this.  Say that registrants can do multi-domains at a single request.
  *   Critical phrase is “randomly generated value” for each domain name.  Don’t have to keep track because only used once, and you don’t have replay attacks, and doesn’t have to be stored.  See: https://datatracker.ietf.org/doc/html/rfc9154#section-4.1.
  *   Could probably provide examples of good practice if we leave this as an optional registrar decision re: multiple domains to be transferred with a single TAC.
  *   Is it the thought that registrars would expose this on the account manager interface, or only on customer service? That might dictate how you want this to work.
  *   There is a minimum requirement of one TAC per domain name; if you want to change this then there needs to be an exemption/carve out.
  *   Suggested new recommendation (from Sarah Wyld): “The Working Group recommends that the registrar MAY allow the use of the same TAC for multiple domains, provided the following requirements are met:
     *   the domains must all be owned by the same registrant (what actually do we mean by this, is it every contact element or only the email?)
     *   the domains are all being transferred to the same gaining registrar, etc.”
  *   So maybe we're just requiring that the RNH can decide to set the same TAC on multiple domains, with corresponding security requirements, and that's as far as it needs to go.
  *   I like the concept, and would suggest it should be included in the rationale about how the security profile is changed, as further support for being careful about multiple-domain transfers.
  *   Uniqueness depends on who is to check – if registrars are creating a “randomly generated value” then that check is taken care of; registries should not be keeping track about uniqueness.
  *   To say it another way, multi-domain is only seen at the registrar, not the registry; the protocol doesn't support it any other way.
ACTION ITEM: Take to the list, starting with suggested new language from Sarah Wyld in the bulk use cases Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1mqPITDShqiVQ4rH6x-FlvePmL_c05CtyWGgkpj9-77I/edit__;!!PtGJab4!rEDR13o3d-aTSLeZNJgupVDk8jNA1kK9UYqUzMGMTJRewCzadpr68mFXJvImeFamXnGYmmSV4A$>and possible suggested text (in recommendations 3, 8, and 9?) that the TAC has to be unique using the phrase “randomly generated value”.

ACTION ITEM: Leadership and staff to research the issue of whether changes to the extension of the expiration date after a transfer are in scope.

4. Fast Undo Procedure

  *   We intent in bringing this forward is to solidify the time window around post-create and post-transfer to make sure that time makes sense.  Today there is no quick reversal.
  *   WG members should review the homework, if they have not already done so.
  *   When IRTP-B was done in 2011, The difference between Rr and Ry was crisp.   There was little or no Vertical Integration.  Since then, there is tremendous vertical integration within Registry/Registrar worlds and blurrier lines.  We keep treating things as if there are still in place those crisp boundaries, and the reality is that it is different, and clawback/rollback and ERTP could behave differently where gaining or losing Registrar are vertically integrated with the Registry.
  *   If a clawback was to happen it should have a time-scale or stamp.
  *   Wonder how often the undo function is being used now in Verisign?  Maybe we could reach out to Verisign?
5. AOB

     *   Next call: Tuesday 12 April 2022 at 16:00 UTC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20220405/0c642356/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Project_Workplan_5 April 2022.pdf
Type: application/pdf
Size: 85203 bytes
Desc: Project_Workplan_5 April 2022.pdf
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20220405/0c642356/Project_Workplan_5April2022-0001.pdf>