[GNSO-TPR] Notes and action items - TPR WG Meeting #48 - 24 May 2022 at 16:00 UTC

Tue May 24 17:36:54 UTC 2022

Dear TPR WG members,

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

Leadership along with the WG will consider whether to cancel the next meeting on Tuesday, 31 May 2022 at 16:00 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin

Action Items

  1.  WG members to review the draft questions and text on recommendation 13.1 for public comment and provide comments/suggestions if any.  See: https://docs.google.com/document/d/1-iMcSboPsoTCHYye_u0uVmaVgNiOP7FKYXkO3FWhY2c/edit.
  2.  Staff to send to the WG list the latest version of the draft Initial Report (that which was sent after the WG meeting on 17 May) – COMPLETE; SEE ATTACHED.
  3.  Leadership along with the WG will consider whether to cancel the next meeting on Tuesday, 31 May 2022 at 16:00 UTC.
Notes:

Transfer Policy Review Phase 1(a) - Meeting #48
Proposed Agenda
24 May 2022

1. Roll Call & SOI updates

2. Welcome and Chair Updates

  *   Roger Carney, Chair -- Rec 13.1: Overview:
     *   With disagreement on where the TTL enforcement should be done the staff has been working on a question for the public comment period.  Link to Google Doc for Community Question regarding standard TTL: https://docs.google.com/document/d/1-iMcSboPsoTCHYye_u0uVmaVgNiOP7FKYXkO3FWhY2c/edit.
     *   Note that public comment is constructed with a survey with community questions by topic.  This was followed for the EPDP for registration data.
     *   Includes notes for the community, including what is a TTL and what are the WG proposals, and why the registry was originally proposed to enforce.  WG members also can respond in the public comment period.
     *   Google doc with the question is open for WG members to comment.  Note that we are trying to keep the question and proposals brief.
  *   Jim Galvin, RySG:
     *   For the record – did not realize that the WG was seeking a formal RySG group position.
     *   Would a position – other than informally that there is not support for this – result in a different action?
     *   Clarifying question: Does this mean that rec 13.1 will stay stated as is in the public comment?
  *   Roger Carney, Chair:
     *   There was no formal call for action, but we were expecting WG members to consult with their groups.
     *   Intent is to go to public comment with it as written and an official comment wouldn’t change that, but groups can comment in the public comment forum.
  *   Discussion:
     *   One proposal could be to put the TTL into the hash itself.
     *   Embedding the TTL into the TAC was discussed by the TechOps group.
     *   That could also be guidance for the IRT.
     *   We are looking for broad feedback in the public comment, but targeted feedback from the respective SGs and Cs.  After the public comment period closes the WG will review all the comments and evaluate whether changes are needed to the draft Initial Report that was posted for public comment.
     *   The next phase of the process is to get us closer to consensus.
     *   Jim Galvin, RySG: Statement for the record.  I believed I was following the process.  We all have an obligation to keep up with the work, but I missed the point at which 13.1 was closed.  RySG has objected to this recommendation from the beginning, so perhaps I missed a possibility to bring this back to the agenda.  I and my registry colleagues did not realize that this was closed and we should have made sure that this remained open.  We will work with the process going forward.
ACTION ITEM: WG members to review the draft questions and text on recommendation 13.1 for public comment and provide comments/suggestions if any.  See: https://docs.google.com/document/d/1-iMcSboPsoTCHYye_u0uVmaVgNiOP7FKYXkO3FWhY2c/edit.

ICANN74:

  *   See related sessions:
     *   GNSO Policy Update: Tuesday, 31 May at 18:00 UTC.
     *   Dedicated Transfer Review Update of Initial Report: Thursday, 2 June at 14:00 UTC.
3. Return to items flagged for further discussion during last week’s call (see here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1clAqB1wBeOf9ZC5RMMxKrrUTs3N2WyaVYTIyVy_ODs4/edit__;!!PtGJab4!-uPdCgOlvIc2D7WdjwrB25h_m-h2lThi7iJ9xVyDa_dRZeFlweIzaiDE8UpP6EiFmq8T2YaWUEFQ9GGinEd4aYQ6HZ0J7gf-T5yQ$>)

a. Discussion of Recommendation 19 email thread (please see here<https://mm.icann.org/pipermail/gnso-tpr/2022-May/000449.html>) (Mike R.)

Proposed revision:
“Evidence of fraud or [material] violation of the Registration Agreement. Implementation Guidance: The intent of “violation of the Registration Agreement” is not to allow the blocking of transfers due to minor violations, but to allow action in case of substantive contravention of the Registration Agreement.”

Discussion:

  *   Mike provided an email, see above, with the concern that a nefarious registrar could have a clause that could deny and transfer.
  *   Mike had suggested language with a materiality assessment.
  *   Sarah had suggested similar language and staff put that out for WG review, particularly by Mike. Since Mike is not on this call staff will follow up with Mike to ask for his comments and if he has alternate language.
  *   Language is still too broad – could be anything that could be a violation. Think we need to be more specific.
  *   Note that this is a “MAY” deny.
  *   Note also that there is a separate option to deny for non-payment: I.A.3.9.1: Implementation Guidance: Registrars are prohibited from denying domain name transfer requests based on non-payment of fees for pending or future registration periods during the Auto-Renew Grace Period, provided that any auto-renewal costs borne by the Registrar are reversible for future period.
  *   More specificity would help ICANN Compliance, such as “violation of registrar's domain use or anti-abuse policies” would be helpful.
  *   There is a very narrow use case.
  *   Leave the alternate language for now.
b. Recommendation 12 (Mike R.): “Five calendar days, or 120 hours as stated in the report, is too long to wait for a TAC. While most registrars give this to you instantly or within minutes, we wouldn’t want to wait five days if the matter was urgent and a registrar had that kind of time latitude.  We’d strongly prefer a 1-2 calendar day maximum.”’

Preliminary Recommendation 12: “The working group confirms that the Transfer Policy MUST continue to require Registrars to set the TAC at the Registry and provide the TAC to the RNH or their designated representative within five calendar days of a request, although the working group recommends that the policy state the requirement as 120 hours rather than 5 calendar days to reduce any risk of confusion. The working group further recommends that the policy MUST make clear that 120 hours is the maximum and not the standard period in which the TAC is to be provided.”

Discussion:

  *   In current policy there are two 5-day windows, so actually 10 days.  So the suggestion in Rec 12 cuts that time in half.
  *   Worth talking about whether a smaller time period is acceptable, and what are the pros and cons of leaving it at 5 or making it shorter.
  *   Swimlane can be helpful here – particularly the moment when the RNH requests the TAC that there are a large number of transfer that have no issues keeping the transfer from happening in a number of minutes.  Conversely, there are cases where various issues must be cured before the TAC is provisioned to the RNH.  These 120 hours, are they the appropriate time to cure those issues.
  *   Note that this is “up to” the 120 hours.  It should be done as quickly as possible if not simultaneously.
  *   WG seems to have coalesced around 5 days – not hearing support for changing to less than 120 hours.
  *   Leave it as is and go to comment with this.  IPC can comment in the public forum.
4. Begin review of items flagged in Proposed Revisions from Working Group members [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1s9xumJ1XBPdTb7kQmc5sAC2AkszvfAF0freMvnx6G18/edit__;!!PtGJab4!-uPdCgOlvIc2D7WdjwrB25h_m-h2lThi7iJ9xVyDa_dRZeFlweIzaiDE8UpP6EiFmq8T2YaWUEFQ9GGinEd4aYQ6HZ0J7rDcNJzw$> document (if any)

  *   Nothing else is flagged.
  *   Probably can cancel next week’s call.
  *   Updated version of the Initial Report was sent out after last week’s call incorporated changes agreed to on the call relating to RFCs and suggestions from Jim.
  *   Staff will send last week’s version of the Initial Report along with the notes from this call. Didn’t hear any agreement to change the language from what was sent after last week’s call.
  *   Leadership to consider with the WG whether to cancel next week’s meeting.
  *   Plan is to talk about Phase 1(b) on Change of Registrant during ICANN74. WG should start reviewing those charter questions.
ACTION ITEM: Staff to send to the WG list the latest version of the draft Initial Report (that which was sent after the WG meeting on 17 May) – COMPLETE; SEE ATTACHED.

5. AOB

  *   Next call: Tuesday 31 May 2022 at 16:00 UTC
ACTION ITEM: Leadership along with the WG will consider whether to cancel the next meeting on Tuesday, 31 May 2022 at 16:00 UTC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20220524/accf39df/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TPR Initial Report Draft - 17 May 2022.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 217408 bytes
Desc: TPR Initial Report Draft - 17 May 2022.docx
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20220524/accf39df/TPRInitialReportDraft-17May2022-0001.docx>