[GNSO-TPR] Notes and action items - TPR WG Meeting #74 - 20 December 2022 at 16:00 UTC

Tue Dec 20 18:02:59 UTC 2022

Dear TPR WG members,

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

The next meeting will be on Tuesday, 10 January 2023 at 16:00 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin

ACTION ITEMS/HOMEWORK:

  1.  Jothan Frakes, Jim Galvin, Jody Kolker, and Rick Wilhelm have volunteered to compile a list of attack vectors and how the recommendations solve for them, or where they are out of scope.
  2.  Staff to circulate the redlines and give the WG until 16 January for review and comment.
  3.  Small Team on Exemption for Recommendation 16 and 17: to provide language and rationale for discussion at the meeting on 10 January.
  4.  Small Team on Rec 13 TTL:
     *   Staff to incorporate the suggested text in the redline but without including hours at this point.
     *   Small team will work on the rationale text for discussion at the meeting on 10 January 2023.

Notes:

Transfer Policy Review - Meeting #74

Proposed Agenda

20 December 2022

1. Roll Call & SOI updates

2. Welcome and Chair Updates

  *   Question: When will the complete review of the Initial report phase 1a be distributed to the WG?
  *   Answer: Have circulated redlines through 13, and remaining redlines should come out 21 December – but not final version.  Staff will fill in rationales as a next step, including elements from small teams.  Suggest 09 January for comments on the remaining redlines.
  *   Seems like a quick turnaround; would prefer a week later.
  *   16 Jan is a holiday in the US.
  *   The new revisions are not very extensive.

ACTION ITEM: Staff to circulate the redlines and give the WG until 16 January for review and comment.

3. Small Group on Exemption for Recommendation 16 and 17 (proposal<https://mm.icann.org/pipermail/gnso-tpr/2022-December/000714.html>)

“Our proposal is to add the option for registrars to opt out of the lock for “Established Customers”. This should reduce the chance of domains transferring to multiple registrars as part of hijacking, while allowing existing registrants to better manage their domains. A draft definition for “Established Customer” is: ‘An established customer is a registrant who has previously received continuing services from a registrar for a period of more than 30 days and has an established relationship with the registrar. This typically refers to a customer who has a history of regular interactions with the registrar and has demonstrated a willingness to continue receiving services from the registrar in the future.’  See: https://mm.icann.org/pipermail/gnso-tpr/2022-December/000714.html

Discussion:

  *   Could change to “registrar/reseller” or “reseller” in parentheses, but the obligations of the RAA apply to reseller.
  *   Can this definition of “established” customer also be used for preventing a transfer lock after material change of Registrant? Perhaps.
  *   ALAC would like all processes to be equal, which would change with this policy.
  *   There are already policies that allow opt outs.
  *   ALAC would like to have time to present to the group.
  *   Consider/think ahead to locks on COR – post transfer restriction leveraged for possible changes in COR.
  *   When thinking about Rec 19 and evidence of fraud – would we similarly require evidence of this “Established Customer”?  How could Compliance know that?
  *   What is the next step for this proposal?  Can this be incorporated into the Recommendations 16 and 17 – also timing.
  *   Helpful to have specific language and a rationale from the small team.  Particularly the impact on the consistency across the industry and security elements.
  *   Challenge for Compliance to gather evidence on the “Established Customer”.

ACTION ITEM: Small Team on Exemption for Recommendation 16 and 17 (proposal<https://mm.icann.org/pipermail/gnso-tpr/2022-December/000714.html>): to provide language and rationale for discussion at the meeting on 10 January.

4. Small Group on TTL Enforcement (proposal at the bottom of Recommendation 13 Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1Wq4dHcIFR5XogoutSh0klkCyhZFUlS1z7cl2ilv9c9I/edit?usp=sharing__;!!PtGJab4!-ptXDR2_gOTcob8LhzS2jYvL-Dk8dVPoj9oCLCGX7P1xJLAwe1M1V3EQiJqIg7cuoqV-2gs5V_WCeulnOS1KLX_hzm0sRax1lQ$>)

Strawman Revision: Tentative Draft Language proposed by the Small Team – agreed by the RySG and under review by the RrSG:

13.1 A standard Time to Live (TTL) for tThe TAC MUST be valid for 14 calendar days from the time it is set at the Registry, enforced by the Registryies.
13.2 The Registrar of Record MAY set the TAC to NULL: After a period of less than 14 days prior to the end of the 14th calendar day by agreement of the Registrar of Record and the RNH.

Discussion:

  *   Removed “maximum” and settled on “14 calendar days” although registrars may suggest also including hours, but others objected.  We don’t use hours elsewhere.  No objections from the registrars on the change, except the suggestion to include hours.
  *   Probably shouldn’t say “calendar”, just “days”.  Trying to move away from calendars.
  *   Think hours could fit here – in the scope of the rationale.
  *   The statement at the end of 13.2 was not intended to unreasonably limit the ability of the Sponsoring Registrar to null the TAC.  Might think about rather than specifying reasons in 13.2, might reference other sections in the policy where we specify reasons why the registrar may reject the transfer.
  *   To remove the term “calendar” we have agreement from the RySG and the RrSG.  But RySG would like to take the suggestion to go to hours under advisement.  Would prefer not to include hours as that raises the compliance obligation.
  *   If we move to “days” from “calendar days” does that create opportunity for confusion?
  *   WG previously discussed including both “calendar days” and “hours”.
  *   “Calendar days” is more precise than “days”.  Don’t have to go to 336 hours.
  *   This is the only deadline where the registries have obligations and with a level of specificity great than obligations for registrars.
  *   Rec 12 specifies hours so adding hours to Rec 13 would make it consistent.
  *   Where does the small team stand on the language and rationale – particular comments around registry obligations?
  *   Would be helpful to reference in 13.2 another section on reasons why a registrar could reject a transfer/registrar of record refuses to send a TAC.
  *   Think we are covered elsewhere for the above references.

ACTION ITEMS:

  1.  Staff to incorporate the suggested text in the redline but without including hours at this point.
  2.  Small team will work on the rationale text for discussion at the meeting on 10 January 2023.

5. AOB: No meeting 22 December and last week in December; first meeting in January is Tuesday, 10 January.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20221220/fd4ddcfd/attachment-0001.html>