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

Best regards,

Emily, Julie, Berry, and Caitlin 

Action Items:

1. WG members are encouraged to review the overview of proposed response to Charter Question h2 (see page 13 and 14 here [docs.google.com]) and provide comments and/or suggestions.

2. WG members are encouraged to review the overview of proposed responses to EPDP Phase 1, Recommendation 27 “Wave 1” Report items (see document here [docs.google.com]) and add comments in the column “Additional Notes/Discussion”.

3. Staff to suggest a definition along the lines of Designated Agent as referenced in the COR.  Could say, “Working Group understands the Designated Representative to mean an individual or entity that the Registered Name Holder explicitly authorizes to obtain the TAC on their behalf.”

4. In the next 2 weeks -- Circle back to the Registrar SG (Sarah Wyld) and Registry SG (Jim Galvin and Rick Wilhelm) and also CPH TechOps (Jothan Frakes, although this would have to be coordinated with the Registrar SG) on the syntax for how to exchange and store the TAC.  See Discussion of Outstanding Items on TAC summary document here [docs.google.com].

Notes:

Transfer Policy Review Phase 1 - Meeting #43

Tuesday, 19 April 2022 at 16:00 UTC

Proposed Agenda

1. Roll Call & SOI updates

2. Welcome & Chair updates

• Small Team on Denial of Transfers/NACK: Cleaning up the draft recommendations.  Likely will finish up this week and then will report to the WG.
• In the phase of not detailed discussions, but focusing on what we’ve discussed and finalizing draft recommendations. 
• Poll on travel to ICANN74 looks great – lots of attendance in person (more than a dozen) at least for now.
• Note that the locks recommendations are available now for WG members to review.  Draft recommendations are now available on post-registration and post-transfer locks here [docs.google.com] (see pages 5 and 6).
• .  We’ll come back to these in a few weeks.

3. Overview of proposed response to Charter Question h2 (see page 13 and 14 here [docs.google.com])

Question: h2) Should additional guidance around cases subject to a UDRP decision be provided to ensure consistent treatment by all registrars? If so, is this something that should be considered by the RPMs PDP Working Group’s review of the UDRP, or should it be conducted within a Transfer Policy PDP?

The Working Group reviewed the World Intellectual Property Organization’s (WIPO) detailed comment in response to the Transfer Policy Status Report and has noted two concerns involving a UDRP proceeding vis-à-vis the Transfer Policy. Specifically, WIPO has noted issues related to: (i) the locking of a domain name subject to a UDRP proceeding (in order to prevent an inter-registrar during the pendency of the proceeding), and (ii) the implementation of a UDRP Panel’s order to transfer a domain name to a complainant. 

Some key points (see detail in the document at the link above):

• Group had a charter question that relates to UDRP locking and WIPO concerns.
• UDRP rule about locking a domain name – related to Transfer Policy on denial of transfer for a pending UDRP proceeding.  The small team is considering this draft recommendation.  Noted a wording change to “notified by the Provider”.
• In response to WIPO’s related concern that “the ambiguity associated with ‘locking’ a domain name has resulted in many improper domain name transfers,” the Working Group notes that the definition of Locking is part of the UDRP Rules, and, accordingly, appears out of scope for this Working Group to address.
• In the event a registrar mistakenly or purposefully effects an inter-registrar transfer during the pendency of a UDRP proceeding, this would be a clear violation of the Transfer Policy and should be referred to ICANN org Compliance for review.
• The Working Group also discussed WIPO’s noted concern regarding the reported refusal of some registrars to effect a UDRP Panel’s decision to transfer a disputed domain name(s) to the Complainant.
• The Working Group noted that a registrar refusal to implement a UDRP Panel’s decision to cancel or transfer the disputed domain name to the Complainant, absent official documentation of a court proceeding, would be a violation of the UDRP, and, accordingly, should be referred to ICANN org Compliance for review. The Working Group noted that it will refer this reported issue of UDRP decision implementation to the RPMs Phase 2 Working Group, as the Working Group believed the specific implementation around UDRP decisions to be out of scope for the Transfer Policy.

Discussion:

• Question: What happens if somehow the UDRP policy changes?  Does that open up the Transfer Policy?  Answer: If there was a PDP making changes, we should note that dependency.  Should reference the UDRP policy to allow flexibility for changes in that policy (rather than stating the UDRP policy within the Transfer Policy).
• Question: Does the Transfer Policy override other locks, such as Change of Registrant, that are in play during a UDRP dispute?  Answer: Don’t know if the Transfer Policy should get into this question. Change of Registrar lock wouldn’t apply.  Could be a government order or other outlying cases, but those would be very limited and didn’t prevent transfer in the case of UDRP.
• If there was a post-creation lock in place when the transfer was to occur then the only way to transfer was a inter-registrar push, then the registrant would have to wait that X number of days during the post-creation lock.
• This was the original use case for the concern raised by WIPO.  Given the registration monitoring solutions a brand owner could be notified within 5-10 days, WIPO’s concern in those instances of a newly created domain name and the 60 day create lock applied, the complainant would have to wait that 60 days.
• If we reduce that time to 30 days for that lock then it would reduce that wait.
• It’s possible that perhaps the UDRP review/RPMs Phase 2 could address it.

ACTION ITEM: WG members are encouraged to review the Overview of proposed response to Charter Question h2 (see page 13 and 14 here [docs.google.com]) and provide comments and/or suggestions.

4. Overview of proposed responses to EPDP Phase 1, Recommendation 27 “Wave 1” Report items (see document here [docs.google.com]) 

Estimated Impact: High 

Key Points: This policy is substantively affected by the new Registration Data Policy requirements. Some areas identified have been addressed by the EPDP Phase 1 recommendations. It is also noted that the GNSO has work in progress to review the Transfer Policy.

Support staff team has gathered everything in the above-referenced document – Wave 1 Analysis Key Points, Potential WG Response, Additional Notes/Discussion.

Summary:

1. Administrative Contact removed from the Transfer Policy.
2. Transfer Contact needs to be updated.  Transfer Policy instead uses Registered Name Holder.
3. Administrative Contact: WG is not recommending any use of the term Administrative Contact.
4. Transfer Emergency Action Contact (TEAC) communication and responses – deferred to Phase 1 of the PDP.
5. Issue: not feasible for a Gaining Registrar to send an FOA to the registrant contact data associated with an existing registration; WG recommending eliminating the requirement that the Gaining Registrar send a Gaining Form of Authorization. 
6. Defer discussion to Phase 1(b) of the PDP.
7. Defer discussion to Phase 1(b) of the PDP.
8. Working Group may wish to consider replacing current references to Whois to RDDS throughout the Transfer Policy for any references to Whois that remain. (Please see response to Key Item 9 below for more detail.)
9. In its draft recommendations, the Working Group is recommending eliminating the requirement that the Gaining Registrar send a Gaining Form of Authorization. The Working Group may wish to explicitly recommend the terminology changes from EPDP Phase 1, Recommendation #24.
10. The Working Group has methodically worked through its charter questions, which has enabled it to review previously identified and longstanding issues in the Transfer Policy by proposing slight adjustments to specific transfer issues and/or proposing new methods.  
11. Defer discussion to Phase 1(b) of the PDP.

Discussion:

• Re: #10: Comments received in reference to the registrar survey about starting over.  When compiling charter questions we allowed for the WG to look at the CPH TechOps proposal, but WG could concentrate on the policy language.
• The losing FOA matter as written in the TechOps letter was identifying a workaround to address the sweeping redaction response to the GDPR consequences.  THAT tempspec letter was official.  If there's an official response needed from TechOps we are glad to engage.
• Make sure the language here parallels the language in the draft recommendations on Losing FOA.
• Instead of saying the “Working Group is recommending eliminating the requirement that the Gaining Registrar send a Gaining Form of Authorization” could say “replacing the requirement” or other suggested text.

ACTION ITEM: WG members are encouraged to review the overview of proposed responses to EPDP Phase 1, Recommendation 27 “Wave 1” Report items (see document here [docs.google.com]) and add comments in the column “Additional Notes/Discussion”.

5. Discussion of Outstanding Items on TAC (see summary document here [docs.google.com])

• Many of these items don’t require action/feedback.
• Somewhat of a balancing act.

Item 1, Response to CQ b1, row 4: Comments from ICANN Org Compliance: if a definition is added to the Transfer Policy that eliminates any mention to the term “identify”, the language in Section I.A.5.6 of the Transfer Policy (“The "AuthInfo" codes must be used solely to identify a Registered Name Holder…”) should also be amended for consistency.

– staff suggestion, fairly simply solution. Add a sentence to Recommendation 2 stating that relevant policy language must be updated for consistency with the definition provided by the WG.

Item 2, Response to CQ b1, row 5: No action required.

Item 3, Recommendation 1, row 6: No action required.

Item 4, Recommendation 2, row 7: recommends defining the term “designated representative” within the policy (like “Designated Agent” is defined for Change of Registrant (COR) requests), so that it is clear that the representative is authorized to request and receive the TAC in order to complete an inter-registrar transfer.

• Support not defining it but I like including a confirmation that RNH supersedes Designated Rep.
• "When we say 'Designated Representative', we mean.
• ICANN Compliance: Include a definition for implementation of the policy.
• From a security principles point of view, focus on what we control – what is in registrar and registry systems.  Proposed principles around the TAC, but once the registrant has the TAC we have no control over that.  Take out “or the Designated Representative”.
• If we remove “Designated Representative” then we are removing terminology that reflects what is currently being done and reflected in contractual relationships.  Need to keep this in.
• Could say: “"Designated Representative" means an individual or entity that the Registered Name Holder explicitly authorizes to obtain the TAC on their behalf.”
• Question: Where to put this text?  Is there a definition section? Answer: Don’t think we have a definition section yet, but we can create one.

ACTION ITEM: Staff to suggest a definition along the lines of Designated Agent as referenced in the COR.  Could say, “Working Group understands the Designated Representative to mean an individual or entity that the Registered Name Holder explicitly authorizes to obtain the TAC on their behalf.” See Discussion of Outstanding Items on TAC summary document here [docs.google.com].

Item 5, Recommendation 2, row 8: RE: SME input on the sentence, “The TAC is required for a domain name to be transferred from one Registrar to another Registrar and when presented authorizes the transfer”: Who is this? The RNH/their representative, or the losing registrar? Response: The WG previously agreed that the language should not specifically address who presents the TAC. Does the WG want to revisit? Agreement to leave this as is.

Item 6, Recommendation 3, rows 9, 10, and 11:

Compliance input: Compliance notes that it is unclear who within the org would establish those requirements and how, as well as how the requirements (and any change to them) would be communicated to the contracted parties. For the avoidance of doubt, ICANN Contractual Compliance does not have the technical knowledge to establish those requirements or to determine whether they are appropriate or not. For ICANN Contractual Compliance to enforce these requirements, all requirements must be clearly enumerated and described within the policy itself.

SME input: Add “security requirements for data at rest” to the list of examples of requirements for composition of the TAC

WG members have an outstanding action item to suggest revisions to this recommendation

• Take the next couple of weeks to get feedback from Registrar and Registry WG and CPH Tech Ops.

ACTION ITEM: In the next 2 weeks -- Circle back to the Registrar SG (Sarah Wyld) and Registry SG (Jim Galvin and Rick Wilhelm) and also CPH TechOps (Jothan Frakes, although this would have to be coordinated with the Registrar SG) on the syntax for how to exchange and store the TAC.  See Discussion of Outstanding Items on TAC summary document here [docs.google.com].

6. AOB 

• Next call: Tuesday 26 April 2022 at 16:00 UTC