Notes/ Action Items
ACTION ITEMS/HOMEWORK: Re: Charter Question G1 and G2 on TDRP for consideration and discussion at the next meeting: WG members to review Sections 3.1 and 3.2.1 of the Transfer Dispute Resolution policy in preparation for discussion of Charter Question G2 – see: https://www.icann.org/resources/pages/tdrp-2016-06-01-en. Notes: - Roll Call & SOI updates
2. Welcome and Chair Updates - Remind everyone to please fill out the poll before the end of this week with their availability for meetings in August. See: https://forms.gle/c7d1Aduo5YLct4ST7.
- Project Work Plan: We are working towards having substantial output by ICANN77. Have meetings scheduled for June and July. No open action items.
3. Review Draft Preliminary Recommendations on TEAC – see attached slides. 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: - Registrars located in regions outside of the Americas and Europe, because of significant time zone differences?
- Small and medium-sized registrars, which may not have a sufficiently large team to have 24x7 staff coverage with the necessary competency?
- 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? Draft Preliminary Recommendation #G2-1: Section I.A.4.6.3 of the Transfer Policy states, “Messages sent via the TEAC communication channel must generate a non-automated response by a human representative of the Gaining Registrar. The person or team responding must be capable and authorized to investigate and address urgent transfer issues. Responses are required within 4 hours of the initial request, although final resolution of the incident may take longer.” The working group recommends that the policy must be revised to update the required timeframe for initial response from 4 hours to 24 hours. Rationale in Brief: 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: - Early indication that this seems acceptable. Good to get confirmation.
- No opposition and several support in the chat; we can go with this.
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: - The timeframe for initial contact to the TEAC following the alleged unauthorized loss of a domain.
- The timeframe for final resolution of an issue raised through the TEAC channel.
Draft Preliminary Recommendation #G2-2: Section I.A.4.6.2 of the Transfer Policy states in part, “. . . 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 working group recommends that the Transfer Policy must be updated to state that the initial communication to a TEAC is expected to occur no more than [30 days] following the alleged unauthorized loss of a domain. If the initial communication to the TEAC occurs more that [30 days] following the alleged unauthorized loss of a domain, the registrar contacting the TEAC must provide a detailed written explanation to the TEAC justifying why this is an emergency situation that must be addressed through the TEAC and providing information about why earlier contact to the TEAC was not possible. Rationale in Brief: Defines “a reasonable period of time” while allowing flexibility for exceptional circumstances that may still constitute an emergency. The 30-day period corresponds to the 30-day post transfer lock period. Draft Preliminary Recommendation #G2-3: Once a registrar has provided an initial non-automated response to a TEAC communication as described in Section I.A.4.6.3 of the Transfer Policy, that registrar must provide additional, substantive updates by email to the registrar who initiated the TEAC communication. These updates must be sent every [48 hours] [72 hours] until work to resolve the issue is complete and must include specific actions taken to work towards resolution. Rationale in Brief: Introduces additional transparency and accountability without providing strict deadlines that may not be appropriate or feasible to meet, even when both registrars are working diligently towards resolution of the issue. Discussion: Recommendation #G2-2: - 30 days aligns with the 30-day lock.
- Make as many dates as consistent as possible – tether it to other lock periods – say the same as the post transfer lock, rather than 30 days.
- Appreciate alignment with locks, but there are times when they are discovered after 30 days that are still legitimate: maybe say “discovery” of the unauthorized loss of a domain.
- Current suggested recommendation allows it to go longer than 30 days.
- Would not recommend “discovery” as a term.
- Today it doesn’t specify any time period.
Recommendation #G2-3: - 72 hours covers weekends.
- Days is fine as well.
- We used both hours and days in the Phase 1A recommendations, we will update to be consistent.
- We will go with 72 hours/3-day window.
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? Draft Preliminary Recommendation #G1-4: Section I.A.4.6.2 states in part that “The TEAC point of contact may be designated as a telephone number or some other real-time communication channel and will be recorded in, and protected by, the ICANN registrar portal.” The working group recommends that the registrar must provide an email address for the TEAC point of contact and may additionally provide a telephone number or other real-time communication channel. Draft Preliminary Recommendation #G1-5: The working group recommends that initial communication to the TEAC described in Section I.A.4.6.2 of the Transfer Policy must either be in the form of email or be accompanied by an email communication to the TEAC. This email “starts the clock” for the 24-hours response timeframe specified in Preliminary Recommendation #G2-1. The registrar receiving the TEAC communication must respond by email within 24 hours. The registry and ICANN org must be copied on both the initial email to the TEAC and the initial response by the TEAC. Rationale in Brief: 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: - Question: Feel like we talked about how the registry would know who to copy – is there an email address? Answer: Good question – thoughts?
- Maybe the just contact the registry transfer contact?
- Not an issue in the preliminary, but we should define how to get that information.
- Should we specify “registry transfer contact”?
- Not aware this question was in doubt – but not sure that there is a registry contact; check to see if there is a contact in NSp – just do what the registrar is doing now; the registries already offer support; not sure there needs to be another contact.
- Should there be a specific email for this to go to? Does that make sense for the registry?
- Should make sure there is a clear place for this information to be accessed. What is that process?
- Agreement with the suggested recommendation.
- Rec could be that there is revisit of the current contacts in NSp/wherever that is specific to the TEAC situations.
4. Consider outstanding questions on TEAC f1) Is additional data needed to support evaluation of the effectiveness of the TEAC mechanism? If so, what data is needed? Some support has been expressed for the idea that more data is needed to evaluate the effectiveness of the TEAC mechanism. Some working group members indicated that registrars should be required to track and report on specific data points related to the TEAC going forward. Types of information the BC, RySG, and NCSG identified as potentially useful: - Number of times TEAC channel is used
- Modes of contact to TEAC, and whether these are satisfactory
- Steps taken before contacting TEAC
- Quality of initial response by TEAC
- Whether the timeframe for response is satisfactory
- Circumstances prompting use of TEAC
- Number of cases where there are problems associated with use of the TEAC, including abuse of the channel
- Circumstances of issues experienced with the TEAC
- Type of resolution of case raised through TEAC
- Level of satisfaction with final resolution
In addition the WG charter identifies the following metrics that could be used to measure whether policy goals are achieved: - Number of TEAC requests responded to within the required timeframe vs. number of TEAC requests NOT responded to within the required timeframe
- Number of TEAC requests resulting in a “transfer undo”
To Discuss: - The working group appears to be converging on recommendation that initial contact and response via the TEAC includes an email “paper trail.”
- At this time, the working group is not recommending a centralized system of record. Such a system would potentially be able to provide aggregated data about number of contacts, timeframe for response, etc.
- An email paper trail is a source of information, but turning that information into data requires manual work.
- Some data points might be fairly easy to collect and aggregate, for example number of times TEAC channel is used, amount of time it takes for a registrar to respond when the TEAC channel is used, and number of times registries undo a transfer as a result of a registrar missing the TEAC SLA.
- Other data points require recording narrative responses and analyzing the fact patterns of cases.
- What are the cost/benefit tradeoffs of recommending that these metrics are collected and analyzed?
- Who will be responsible for the data collection/analysis?
- Are there alternatives that the group wants to consider beyond requirements for data collection/reporting?
Discussion: - Important question: Who is responsible for tracking and coordinating that information?
- Do we miss something on the closure side – we don’t say what happens when it’s resolved – is that necessary? We don’t know the outcome unless someone supplies that information.
- If ICANN is being copied then it is a central repository, but then there would be resources require to gather and track the data.
- Like the idea of ICANN being the collector and reporter. Some identifying information probably shouldn’t be collected.
- Does anyone need to track this in real time, or just when there is a question that requires a review – to analyze it at a certain point in time; could be accommodated more easily.
- Emily, staff: If the WG is going to trend to a recommendation that ICANN needs to monitor all activity and track – should be clear what is expected to be tracked (different from what Compliance tracks, which would be complaints), what purpose tracking would serve, how would it inform future policy development? One of the advantages of a centralized system is dates and numbers.
- Just the emails that we recommend ICANN get copied on for TEAC would provide a simple data output.
- Seems simple, but it still would require resources.
- Berry, staff: Hesitant about where this is going. Very few TDRPs, but don’t know the volume of transfer disputes, some percentage of which involve TEAC. Trying to track TEAC traffic would not be easy – it would be unstructured data, so there is a quality issue. Processing any decentralized and unstructured data is burdensome.
- Don’t know how often the TEAC gets used today. How do you know about follow-up emails and match them up? What will you use them for? Is there a trigger, or just a backward look?
- The limited data obtainable from the TEAC procedure would not be helpful – would be nice to have the data the next time we make policy.
- Berry, staff: If the WG were going to produce a recommendation on metrics, then yes, I think Org would want to consider leveraging NSp to do such a thing.
- Don’t think the WG is recommending a centralized repository of data. Doesn’t seem to be enough support to recommend anything specific.
- Emily, staff: If the WG has no recommendation relating to metrics, coming back to the recommendation of copying ICANN org on TEAC emails: what is the purpose for ICANN org to collect these data so we can consider any GDRP considerations.
- It was that third-party look, to avoid the “he said, she said” scenario.
- Berry, staff: If there is no enforcement purpose, just to increase the legitimacy of the issue, it could set the expectation that ICANN org could get involved in a dispute when it couldn’t. So can’t the Registrar just file a complaint with Compliance for no response? What does the CC of Org on the email solve?
- Having the copy could allow ICANN to provide a paper trail.
- What is ICANN org supposed to do with this data? If we want something useful it should be a centralized database, no email copies.
- Holida, staff: From a practical perspective when ICANN has been copied in the past it has created confusion --- made the registrar think incorrectly that they didn’t have to respond because ICANN was involved. We already have a system for tracking complaints.
- Think the registry should be cc’d, not ICANN.
- Disagree: Some ticketing systems ignore a cc. Also, registry might be copied on something in which they might not need to be involved.
- Berry, staff: The difference though is a purpose of processing data for an actual complaint vs. bulk processing waiting for one to become a complaint.
- The debate is whether it is needed or not – maybe not a MUST to send to the registry, but a COULD or SHOULD.
- Sounds like everyone is moving away from copying ICANN but maybe the registry.
- Hard to prove the negative that the registrar didn’t respond. Could look at a copy of the original request to the gaining registrar, but we don’t know if it was responded to. So the registry does their own outreach to the gaining registrar – like a do-over.
- Emily, staff: Curious from the registries perspective: Is there a RySG position on being copied on the TEAC emails?
- Rick Wilhelm, RySG: If the registry is copied on the original request to the gaining registrar that’s okay, but we still don’t know if the gaining registrar responded, so we still have to do our own confirmation.
- We don’t having anything in the recommendations to provide a timeline for the registry. Do we need that?
- Would consider a recommendation do the extra step of validating.
- Rick Wilhelm, RySG: The registries have a requirement to undo a transfer within 5 days if no response – so there already is a timeline and registries also already do due diligence before reverting.
- Should there be a recommendation of what the registry should do? Do we need that?
- Rick Wilhelm, RySG: Registries would prefer that there not be anything more prescriptive than what already exists.
- WG is in agreement to remove this sentence from F5: “The registry and ICANN org must be copied on both the initial email to the TEAC and the initial response by the TEAC.” Also, that no change is needed on F6/F7. (See below.)
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: - Registry Operators do not have access to the designated TEACs for each Registrar, making validation of an undo request nearly impossible.
- 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.
- 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.
- 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.” Policy staff is investigating the history of this issue and any other relevant information to be shared for the working group’s consideration.
5. Charter Question G1 and G2 on TDRP – Moved to next meeting: Section 3.1 and 3.2.1 of the Transfer Dispute Resolution policy in preparation for discussion of Charter Question G2:https://www.icann.org/resources/pages/tdrp-2016-06-01-en.
6. AOB
|