[GNSO-TPR] Notes and action items - TPR WG Meeting #81 - 21 February 2023 at 16:00 UTC
Julie Hedlund
julie.hedlund at icann.org
Tue Feb 21 17:37:07 UTC 2023
Dear TPR WG members,
Please find below the notes and action items from today’s meeting.
The next meeting will be on Tuesday, 28 February 2023 at 16:00 UTC.
Best regards,
Emily, Julie, Berry, and Caitlin
ACTION ITEMS/HOMEWORK:
Actions from Meeting on 14 February:
1. Re: Data from RADAR relating to TEAC -- Staff will check to see if there is any available data.
2. Re: The time frame (4 hours) for registrars to respond to communications via the TEAC channel – WG members should consider a provisional recommendation to change the time frame to 24 hours.
3. Re: 07 March meeting -- If WG members cannot attend the 07 March meeting please let the Secretariat staff know at gnso-secs at icann.org<mailto:gnso-secs at icann.org> so we can decide if we have enough attendance to hold the meeting.
Notes:
Transfer Policy Review - Meeting #81
Proposed Agenda
21 February 2023
1. Roll Call & SOI updates
2. Welcome and Chair Updates
1. Project Change Request, updated project plan, and charter revisions reflecting the new project plan were approved by Council on Thursday, 16 February. Minor revisions, not substantive.
2. Note that we shared ICANN org input on I.A.3.7.1 with the WG. Folks can socialize with their groups and think about it in the background. We will discuss when we return to Phase 1a topics.
3. Members should review the draft outreach letter on phase 2 topics to send to SO/AC/SG/Cs – WG members should share any questions/concerns to the mailing list by Monday, 27 February at the latest. As a reminder, we are not asking anyone to answer the questions at this time, we are just confirming that the letter is ok to send.
4. ICANN76: We have two sessions – first will be a working session on Saturday the 11th, probably on the TEAC; second session on Sunday the 12th will include perhaps more community input, such as on a possible fast undo. First Session is Saturday March 11 at 9:00 local time. Second Session is Sunday March 12 at 10:30 local time.
3. Continued Discussion of Transfer Emergency Action Contact (TEAC)
We will be using the following working document to support discussion on TEAC: https://docs.google.com/document/d/1ejqMnKrN5Pnqyne6G4jHj-DPTfFLVidmeSDpyPM06eA/edit?usp=sharing [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1ejqMnKrN5Pnqyne6G4jHj-DPTfFLVidmeSDpyPM06eA/edit?usp=sharing__;!!PtGJab4!5vDrmZY9kfemRqSR-GeEJAbCGm1_Ni5VjPK5twWVj2J5dQF_zg2QIBJePxEwiRXaEJ9lLBtnPH301lB8kz297bGsipnbV7H0Ag$>. As we move through deliberations on this topic, archived versions of the working document will be kept on the wiki here: https://community.icann.org/display/TPRPDP/Working+Documents
Summary of working document:
* Current applicable policy language -- I.A. 4.6 Transfer Emergency Action Contact
* Survey Inputs from the Policy Status Report at: See https://www.surveymonkey.com/results/SM-Q2J8JZRQV/
* Question 18: Do you think the Transfer Emergency Action Contact (“TEAC”) is an effective way to handle urgent inter-registrar transfer issues between registrars, or does the TEAC process require changes?” See above working document for responses.
* Additional Comments in Survey<https://www.surveymonkey.com/results/SM-Q2J8JZRQV/> Responses Related to TEAC/Transfer Reversal. See above working document for responses.
* Question 5: The transfer policy has evolved over the last six years. In your opinion, have the policy modifications improved, worsened, or had no effect on the process for transferring domains between registrars and/or registrants?
* Question 16: Should there be more standard reporting requirements across registrars as they relate to transfers? If so, what should these reporting requirements include?
* Question 19: In general, what issues are your customers having, if any, as they relate to transfers?
* Question 21: What do you think the ideal transfer process should look like from a policy and a technical perspective?
Discussion on Charter Questions:
f1) Is additional data needed to support evaluation of the effectiveness of the TEAC mechanism? If so, what data is needed?
* Primary source is survey data from the PSR.
Deliberations:
* Working group members noted that because TEAC communications may occur through a variety of channels, it is difficult to collect comprehensive data sets on the use and effectiveness of the TEAC across the industry.
* Survey responses and anecdotal information may point to pain points and opportunity areas.
* Question for further consideration: Could there be requirements going forward that would result in better data to support the next review of TEAC?
Discussion:
* May not be the best question to start with.
* Lack of data is often an issue. Data is what can be gleaned from the survey responses. Can we improve this to ensure there is ongoing data?
* Being able to document/log is important -- would that emergency contact be tracked by ICANN, others? How can we track data on an ongoing basis.
* Do we have any data from the RADAR days? Might be, but could be a problem because not all communications had to go via RADAR so could be incomplete.
ACTION ITEM: Re: Data from RADAR relating to TEAC -- Staff will check to see if there is any available data.
f2/f3) 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:
i. Registrars located in regions outside of the Americas and Europe, because of significant time zone differences?
ii. Small and medium-sized registrars, which may not have a sufficiently large team to have 24x7 staff coverage with the necessary competency?
iii. 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?
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?
RrSG comment<https://mm.icann.org/pipermail/comments-irtp-status-14nov18/attachments/20190115/ff65ffad/RrSGTechOpsresponsetoIRTPPolicyStatusReport2-0001.pdf> on the issue (input to Policy Status Report): There is significant concern with the 4-hour response time requirement…
Other input received via survey<https://www.surveymonkey.com/results/SM-Q2J8JZRQV/>:
* Response required within 4 hours of the initial request is an unreasonable policy, we suggest to extend the response hour to 12-24 hours.
* It needs to be changed on the 4 hours, it is too difficult.
* TEAC requires 4 hours response time is unfair and unreasonable for non-English speaking registrars that are in different time zones to those in the US and Europe.
Deliberations:
* From one perspective, the 4-hour time frame is very rigid. If the TEAC doesn’t respond within the time frame, this is a reason for the transfer to be undone.
* At the same time, some noted that this 4-hour requirement may be gamed by bad actors.
* From one perspective, there may be an opportunity to be more flexible with the requirement. Perhaps there is another penalty that is not as consequential as a transfer undo.
* It was suggested that the required timeframe be contingent on the urgency of the request.
* Some working group members pointed out that it may not make sense to have a rigid requirement for initial (often non-substantive) response and no requirements around a timeframe for meaningful resolution (see also f4).
Discussion:
* Might depend on the reversal process.
* Highly unlikely that we could agree on a quick undo process.
* Even not a quick undo, but I feel like we need to understand the overall reversal process before we can set timeframes for responses in emergency cases.
* Think this a question about which piece of the discussion comes first – consider what could improve the process now. ICANN76 session could be a gap analysis on the TEAC and what needs improvement/needs not being met and possible solutions. Also to get broader community input on fast undo. Might need to toggle between specific charter questions and the bigger picture.
* Do we need multiple paths? Do we need an emergency contact and also a regular contact?
* Focus on looking what’s there, does it need to change, does it leave a gap?
* Multiple WG members agree that 24 hours seems better (then we have to consider if it's business or real time).
* Sounds like 24 hours could be an improvement. WG members should consider.
ACTION ITEM: Re: The time frame (4 hours) for registrars to respond to communications via the TEAC channel – WG members should consider a provisional recommendation to change the time frame to 24 hours.
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 WG may want to discuss two possible issues:
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.
Relevant RrSG comment<https://mm.icann.org/pipermail/comments-irtp-status-14nov18/attachments/20190115/ff65ffad/RrSGTechOpsresponsetoIRTPPolicyStatusReport2-0001.pdf> on the issue (input to Policy Status Report):
* The TEAC is an effective way to make contact regarding an urgent transfer issue, but it does not go far enough, because it does not require that both registrars work together to investigate and reverse the disputed transfer if needed. The process should be revised to require the two registrars to come to a mutually acceptable resolution, potentially with the assistance of a neutral mediator.
Relevant survey<https://www.surveymonkey.com/results/SM-Q2J8JZRQV/> input - Policy Status Report:
* Yes, but registrars need to be required to respond to all inquiries and find resolution (whatever it may be) and not just an initial response within 4 hours. We would like to see TEAC be the start of a process requirement where both registrars work to come to a resolution.
* . . . What is needed is a deadline by which a TEAC response must give a final answer on whether the transfer will be reversed, not merely a deadline on when they have to send a generic useless response.
Deliberations:
Regarding time frame for first contact with the TEAC:
* From one perspective, if someone doesn’t notice for a long time that the domain has been transferred inappropriately, this may be an indication that the issue is not urgent and therefore the TEAC might not be the right channel for resolving the issue. This may point to a need to define a specific timeframe for first contact to the TEAC.
* From another perspective, resolution may still be needed urgently even if the RNH does not realize that there is an issue right away. There should not be a cutoff period for using the TEAC.
* Change “reasonable period of time following the alleged unauthorized loss of a domain” to reasonable timeframe from the time that the Rr finds out about the issue.
Regarding time frame for resolution:
* It was pointed out that some Registars respond quickly with a non-substantive response upon first contact but take a long time to resolve issues. There is no penalty for this currently.
* Suggestion: The negative impact of the transfer defines how urgent the issue is and the appropriate timeframe for final resolution.
Discussion:
* Hard to say what is a negative impact.
* Not clear what is a “reasonable” time.
* If the transfer has taken place in the distant past (say 6 months) but brought through the TEAC – should be a restriction period, say a week.
* Feels like the time to file a dispute should align with the lock period (30 days) though also I like an exception for if the RNH notices it some time later on (I think we saw that last week?). Right - is there a non-emergency path? what are the expectations there? Why don’t we define the process first and then see if we need emergency and not-emergency and when?
* A transfer can happen and the DNS could remain the same – so might not be noticed.
* How do we define urgency? Should there be a limit?
* IRTP came up with reasonable by balancing the variables – number of customers, time frame, etc. For example, if it’s past 30 days do you have to provide a justification to be able to use the TEAC. Should “reasonable” be more precisely defined?
* Using 30 days as a restriction seems reasonable, but someone could game the system by waiting until 31 days. Is there a way to have 30 days with an exception to go longer?
* What about the time frame for resolution – should it be 7 days? Is there a different time frame for urgent/non-urgent?
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?
Deliberations:
* Some working group members pointed out that that phone may have seemed like an efficient channel when TEAC requirements were first put into place, but the technology environment has evolved and that there may be a better framework to pursue going forward that will allow for a quick response and provide a paper trail.
* It was noted by one member that it would be better for ROs if the TEAC communication occurs via email, because there is a paper trail.
Discussion:
* Phone number is good, but email is better for documentation.
* Is email at each registrar enough, but should it be tracked centrally?
* When you centralize that might cause delays.
* I think we should make req's for what is tracked, but not that it be centralized somehow - there's so much work that would add (personal data considerations!).
* Keep the phone number but require documentation in email.
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:
i. Registry Operators do not have access to the designated TEACs for each Registrar, making validation of an undo request nearly impossible.
ii. 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.
iii. 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.
iv. 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?
Deliberations:
i. TEAC data is stale in some cases and not usable by the RO. ICANN should pass TEAC update changes to the Registries when providing notifications of other primary/authoritative contacts. This will ensure RO will get updates, but won’t address the issue of a TEAC not being updated by the Rr.
Discussion:
* Maybe instead of the registry validating it, there is a set of circumstances that have to be met and then the ry will return the domain without further validation, responsibility to ensure it's correct lies with the pre-transfer registrar.
* These are not consistently up-to-date.
* Like a chain of indemnifications that all goes back to the pre-transfer Registered Name Holder - they indemnify the registrar who indemnifies the registry …
* ICANN could publish the TEAC but doesn’t help if the registrar doesn’t keep it up-to-date.
* Thinking about where is the ultimate responsibility? The RNH should know where the name should be. Maybe the verification is done by the registrar who indemnifies the registry.
* The hard part is to determine which registrant – who has that decision?
* We're not necessarily talking about two registrants, but indeed we could be -- In which case I do think the pre-change registrant has authority.
* Maybe there are multiple paths.
* What check boxes do we need to go through to make sure that the registry doesn’t have to make a decision.
Other pain points/opportunities:
* Not everyone knows about the TEAC channel and when to use it. Is more/different/better information needed about the purpose and function of the TEAC?
* Should “emergency” be further defined and guidance provided about when the TEAC should be used (versus TDRP)?
Function/purpose of the TEAC:
* Working group members noted considered scenarios where the TEAC is used:
* Domain names that have been transferred but the transfer should not have occurred. Typically, there is a time sensitive element in these cases. There may be different reasons, including hijack, error, etc.
* Some cases involve malicious behavior, for example unauthorized access to the registrar account to steal the domain name, use of fake court orders, etc.
* Some working group members noted that when a domain is high value/high profile and/or financial, service delivery, and/or safety issue for the RHN or customers/end users, it is more important to have a fast mechanism to resolve an issue.
4. AOB: Two more calls before ICANN76 --- 28 February and 07 March
ACTION ITEM: If WG members cannot attend the 07 March meeting please let the Secretariat staff know at gnso-secs at icann.org<mailto:gnso-secs at icann.org> so we can decide if we have enough attendance to hold the meeting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20230221/f02148fc/attachment-0001.html>
More information about the GNSO-TPR
mailing list