Dear TPR WG members,

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

The next meeting will be on Tuesday, 16 May at 1600 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin

ACTION ITEMS/HOMEWORK:  None captured.

Notes:

Transfer Policy Review - Meeting #90

Proposed Agenda

09 May 2023

1. Roll Call & SOI updates

2. Welcome and Chair Updates

• Yesterday was the deadline of policy proposals for requirements related to informal resolution. There do not appear to be any new proposals in the document. Therefore we are going to focus back on the questions in the charter, beginning with TEAC.
• Steinar: CPWG/ALAC discussed the proposal for informal resolution and agreed it should be policy, but offered no specific language.
• We are trying something different this week -- a more structured approach, including a chair proposal for the path forward based on inputs to date. Perhaps we can take a few mins at the end of the call to collect feedback on the approach and whether folks are comfortable continuing this way for TEAC/TDPR questions.
• Project Work Plan:
  • There were no new policy proposals for requirements related to informal resolution, so we will focus back on the questions in the charter, beginning with TEAC.
  • Note that there are new meetings on the calendar for June and July.  We will send a poll to gauge availability for August.

3. New proposals for policy requirements - non-emergency informal resolution (if any are received) (link to working document [docs.google.com])

• No new proposals to discuss.

4. Status and next steps on Charter Questions F1-F7 (see TEAC working document [docs.google.com] and attached slides)

Question F1: f1) Is additional data needed to support evaluation of the effectiveness of the TEAC mechanism? If so, what data is needed?

Status:

In written input RySG, NCSG, and BC have stated that it would be helpful to have additional metrics from registrars to support  policymaking. In WG discussion, some support was expressed for requiring registrars to track and report on TEAC activity.

Possible Path	Recommendation to require registrars to track and report on specific data points related to the TEAC going  forward, leveraging lists from RySG, NCSG, and BC.
Rationale	Metrics will support understanding of how well the TEAC functions and any pain points, which will support future  data-driven policy making.
To Discuss	Specific metrics that would be required.

Discussion:

• Think the WG agrees that we need additional data and tracking, but need specifics.  Confirmed that this is a good idea.
• Talk about the things that would be most helpful to track at a high level.
• We may be creating pieces of these metrics as we go.
• Any thoughts from the WG on specific metrics to collect?  Not a lot of discussion about this yet.

Questions F2/F3:

f2) The time frame (4 hours) for registrars to respond to communications via the TEAC channel has been raised as a concern by  the Transfer Policy Review Scoping Team and in survey responses. Some have expressed that registries must, in practice, have 24x7  coverage by staff members with the appropriate competency to meet this requirement and the language skills to respond to  communications from around the world. Is there merit to concerns that the requirement disproportionately impacts certain registrars,  namely:

1. Registrars located in regions outside of the Americas and Europe, because of significant time zone differences?
2. Small and medium-sized registrars, which may not have a sufficiently large team to have 24x7 staff coverage with the necessary  competency?
3. Registrars in countries where English is not the primary language, who may, in practice, need to have English-speaking TEAC  contacts to respond to requests in English?

f3) To what extent should the 4-hour time frame be revisited in light of these concerns? Are there alternative means to address the  underlying concerns other than adjusting the time frame?

Status: In initial deliberations, some support was expressed for extending the timeframe for initial contact from 4 hours to 24 hours.  Early written input does not seem to contradict this path forward:

• RySG: “. . . as a practical matter, the 4-hour timeframe and the telephone-driven nature of the TEAC mechanism can lead to  suboptimal outcomes. . . Research of prior RySG comments on the IRTP Part B (March 2011) indicates (at that time) most  voicing an opinion within the RySG supported a timeframe of 24 hours.”
• RrSG: “While 4 hours may be too short, there should be a minimum response deadline (perhaps 48 hours) to ensure that  emergency transfer disputes are addressed in a timely manner.”
• NCSG: “The 4-hour time frame should be revisited to, at least, 24 hours.”
• BC: depending on the frequency and effectiveness of use, the four-hour time frame seems generally appropriate for  emergency situations, though it can perhaps be expanded somewhat to 12 or 24 hours.

Possible Path	Recommendation to extend the TEAC deadline to 24 hours.
Rationale	Reduce risk of gaming, reduce burden on registrars (especially smaller companies and those in time zones outside  of Europe and the Americas), while still providing a reasonable response timeframe. Currently RAA has a 24 hour  SLA for Rrs to provide a non-automated initial response to reports of illegal activity. This may be considered an  analogous situation.

Discussion:

• Heard a lot of support for the 24-hour window.

Question F4: f4) Section I.A.4.6.2 of the Transfer Policy states that “Communications to a TEAC must be initiated in a timely manner, within a  reasonable period of time following the alleged unauthorized loss of a domain.” The Transfer Policy Review Scoping Team noted that this  timeframe should be more clearly defined. Is additional guidance needed to define a “reasonable period of time” after which registrars  should be expected to use a standard dispute resolution process?

Note:

The working group has considered two items related to this charter question:

1. The timeframe for initial contact to the TEAC following the alleged unauthorized loss of a domain.
2. The timeframe for final resolution of an issue raised through the TEAC channel.

f4, Item 1: The timeframe for initial contact to the TEAC following the alleged unauthorized loss of a domain.

Status: Comments from the RySG, RrSG, NCSG, and BC support providing more guidance around “a reasonable period of time.”  While some working group members have favored providing a precise deadline, others have noted that there may be circumstances  that require more flexibility. RrSG suggested that the timeframe should be aligned with when the registrar is made aware of the  unauthorized transfer. BC suggested the period could be 5 days from the alleged unauthorized loss of a domain.

Possible Path	Initial contact to a TEAC should generally occur no more than [x days] following the alleged unauthorized loss of a  domain. If the initial contact to the TEAC channel occurs more that [x days] following the alleged unauthorized loss  of a domain, the registrar must provide a detailed explanation of why this is an emergency situation that must be  addressed through the TEAC channel, including why earlier contact to the TEAC was not possible.
Rationale	The suggested approach puts additional definition around “a reasonable period of time,” while allowing flexibility for  exceptional circumstances that may still constitute an emergency.
To Discuss	Would 30 days be an appropriate time frame, corresponding to the post-transfer lock period?

Discussion:

• We had discussions around data occurrence versus data reporting – when is it a TEAC/emergency situation?
• Not sure how the above would be validated.  Better to look at an objective number.  30 days seems more reasonable.  Shouldn’t be gauging awareness.

f4, Item 2: The timeframe for final resolution of an issue raised through the TEAC channel

Status: Some working group members noted that it would be helpful to have defined timeframes, but others raised that each case  is different and some cases may take longer to resolve than others. Absent data about the types of cases and resolutions handled  through the TEAC channel, it is difficult to define requirements.

Possible Path	If an issue is raised through the TEAC channel, the registrar receiving the communication must provide updates  about the status of the resolution to the party who initiated the TEAC contact no less than every [x period of time],  including specific actions taken to work towards resolution.
Rationale	Introduces additional transparency and accountability without providing strict deadlines that may not be  appropriate or feasible to meet, depending on circumstances.
To Discuss	Time period for periodic updates.

Discussion:

• This is a complicated thing to write policy around.  Not sure how regular these updates need to be.
• Timeframe might vary.
• Goal is to keep the two parties engaged and working towards resolution.  Two or three days seems reasonable.

Question F5: f5) According to section I.A.4.6.2 of the Transfer Policy, the TEAC may be designated as a telephone number, and therefore some TEAC  communications may take place by phone. The Transfer Policy Review Scoping Team flagged this provision as a potential item for  further consideration. Do telephone communications provide a sufficient “paper trail” for registrars who may later wish to request a  transfer “undo” based on failure by a TEAC to respond? Such a request would require the registrar to provide evidence that a phone call  was made and not answered, or a call back was not received within 4 hours. Noting this requirement, should the option to  communicate by phone be eliminated? Is an authoritative “system of record” for TEAC communications warranted? If so, what  are the requirements for such a system?

Status: There are different views on this question:

• RySG supports “exploring integrating a TEAC-like function into the ICANN nSP”, but is “not prepared to recommend  that the option for phone communication be eliminated without understanding the proposed option(s) for replacement.”
• RrSG does not have a unified position and suggests that It “may be ideal to allow each registrar to choose which form of  contact they would prefer.”
• NCSG suggests that the use of telephone communication for TEAC may “raise concerns about the ability to provide a  sufficient "paper trail"” and suggests that email may be a suitable system of record.
• BC notes that “the telephone contact appears to remain an effective means of communications for the initial contact,  however there should perhaps be an additional logging mechanism via a written report to ICANN, for example, or even via  email correspondence which would have a paper trail.”

Possible Path	Require that registrars provide an email address for TEAC. First attempt to contact the TEAC must be by email,  but can be followed by other forms of communication (for example, phone). The TEAC must respond to that initial  email within 24 hours.
Rationale	Ensures that there is a paper trail associated with each initial TEAC contact without creating complex new  requirements for an system of record that may be seldom used.

Discussion:

• Hard to build requirements when we have very little data at this point.
• Don’t think the Registries role to gather evidence.
• The 24-hour might stretch this out a little.
• Being used so little, does it make sense to create a system of record?
• Could add in that ICANN could be pushing the TEACs when then send out contacts – if ICANN knows when contact updates go out it would be helpful if they could send them to the Registries.
• Good to keep the phone contact, but the email would be initiating it and moving it forward.  Solves a paper-trail/evidence issue.
• Seems to be support for the possible path.

Questions F6/7: f6/f7) The Transfer Policy Review Scoping Team indicated that there are several factors that make a Registry Operator’s obligation to  “undo” a transfer under Section 6.4 of the Transfer Policy challenging:

1. Registry Operators do not have access to the designated TEACs for each Registrar, making validation of an undo request nearly  impossible.
2. There is no way for Registry Operators to independently verify that a Registrar did not respond within the required time frame or  at all since Registry Operators are not a party to, or copied on, communications between the Registrar TEACs.
3. Transfer “undo” requests associated with the failure of a TEAC to respond are unilateral so there is no validation required prior to  a Registry Operator taking action. This has, on occasion, led to a “he said”, “she said” scenario.
4. Follow on to f6 iii., if the policy were to be updated to allow for some level of validation by the Registry Operator prior to taking  action, the requirement to “undo” a transfer within 5 calendar days of receiving an TEAC undo request leaves little to no time to  attempt to validate the request prior to taking the action.

To what extent are changes to the policy needed to address these concerns? Are there other pain points for Registry Operators that need  to be considered in the review of the policy in this regard?

Issue i Status:

• RySG suggests “that ICANN Org include the Rr TEAC in the list of Rr contacts that it regularly supplies to the ROs.”

Possible Path	Recommendation that ICANN Org include the registrar TEAC in the list of registrar contacts that it regularly  supplies to the ROs.
Rationale	Helps to ensure that registries are aware of updates to TEAC information.

Discussion:

• What is the issue behind the RySG suggestion:
  • Registrars are required to keep their TEAC updated in the NsP and also the portal with the RO.
  • ICANN doesn’t include the TEAC when they send updates to the RO.
  • Ask that ICANN includes the TEAC update along with the primary Registrar contacts.
  • Questions: Do registries have access to the NsP? Answer: The primary way we access the TEAC is in our own systems – pretty sure we don’t have access to the registrar’s TEAC in the portal.
  • Question: It seems like a logistics and operational – rather than policy – issue.  Could registries go directly to GDS?  Answer: Yes, we have tried to do this but it was decided that because of GDPR this information could no longer be distributed.

Issue ii, iii, iv Status:

• RySG early input reiterated concerns stated in the charter question. In working group discussion, RySG members have held  that the process should work in such a way that the RO doesn’t need to make a decision or conduct any verification.  Registries should also not be liable in cases where they undo a transfer because a TEAC did not respond in time.
• RrSG early input noted that “some Registrars suggest that the registry should be required to contact both registrars  before taking action that could impact the domain in determining whether there is noncompliance.” Further, “Transfer undoes  should only occur for TEAC noncompliance when a registry can conclude that the TEAC obligations of the gaining  registrar were noncompliant, not in a scenario where evidence from the two registrars is conflicting. The group may  benefit from considering requiring the creation of a communication path to pass these TEAC requests back and forth  and ensure that the registry and ICANN also have visibility into them.”
• NCSG suggested that “one possible solution could be to require Registrar TEACs to copy Registry Operators on all TEAC  communications” and noted that an authoritative system is an alternative.
• BC notes that in the “. . . absence of much data concerning dissatisfaction with a very infrequently used procedure, would  seem to mitigate in favour little change to the current approach.”

Question for Input: According to Transfer Policy Section I.A.6.4, “The Registry Operator shall undo a transfer if, after a transfer has  occurred, the Registry Operator receives one of the notices as set forth below. . .6.4.4 Documentation provided by  the Registrar of Record prior to transfer that the Gaining Registrar has not responded to a message via the TEAC  within the timeframe specified in Section I.A.4.6.” Would a requirement that first contact occurs by email sufficiently  mitigate registry concerns about “he said, she said” scenarios?

Discussion:

• No suggested path forward as there are diverging positions.
• Good step to go from phone to email, and having RO cc’d on TEAC email – also could be helpful if there was a suggested template for the email to ensure it contains key information.  Think about it going to a specific inbox (i.e., teac@godaddy.com).
• The specific inbox probably can’t be policy, but could be guidance.
• Question: What evidence would the RO need to do a rollback? Answer: It is very situationally dependent. Registries have concerns about liability – really look hard before doing a rollback.
• Looking at current practices there is a lot of concern about liability.
• Extending the timeframe from 4 to 24 hours will help a lot, and having an email paper trail.  Could mitigate the issues.

Next Steps:

• Is this approach useful?
• Seems like there is general support for this approach.
• Question: Can staff start drafting answers to charter questions?  Answer: Yes, and drafting some preliminary recommendations.

5. AOB