Dear TPR WG members,
Please find below the notes and action items from today’s meeting.
The next meeting will be at ICANN75 on Saturday, 17 September at 10:30-12:00 MYT (local time KL).
Best regards,
Emily, Julie, Berry, and Caitlin
ACTION ITEMS/HOMEWORK -- Preparation for ICANN75:
1. Staff to incorporate points raised in discussion during the meeting on 13 September on recommendation #2 for WG members to review.
2. WG members to review the proposed edits in the
Recommendation 2 Public Comment Working Document [docs.google.com] and also the
following documents:
Notes:
Proposed Agenda
13 September 2022
1. Roll Call & SOI updates
2. Welcome and Chair Updates
- Today’s discussion will be continued into ICANN75.
- Do have a pretty big topic here. We knew we would get some comments back on it. Nothing unexpected, but a lot of good comments to go through.
- Question: What are we discussing in Kuala Lumpur? Answer: There will be a quick overview of the status of the work followed by a working session.
3. Approach to Public Comment Review -- Begin Discussion of Comments on Elimination of the Losing FOA:
Overview:
- Discussion with staff and leadership on how best to support the review of public comments.
- Last week we began a discussion in the WG on Rec 19 and we’ll come back to that.
- But now we’ll focus on early recommendations and determined that it would be helpful to give the WG some discussion papers to call out proposals for changes to the recommendations and/or current policy.
- Staff to describe the working document for Recommendation 2 and welcome feedback.
Recommendation
2 Public Comment Working Document [docs.google.com]
- Top of document – recommendation text.
- Staff will avoid doing any synthesis of the comments so WG members should review and be familiar with comments, but staff will highlight key points or areas of agreements, proposals.
Key Principles for Public Comment Review:
- If suggested edits are minor and editorial in nature, focus on whether you can live with them.
- If suggested edits are substantive, focus on what new information or insights that have been provided by the commenter.
- If concerns, information, or perspectives have already been considered in the development of the recommendations, consider how the report can strengthen the rationale by showing how these have been
addressed and why the WG took the approach it did.
- Members are representing their groups, not their individual or employer positions/perspectives. Now is the time to make sure you are aligned.
- The goal is to make recommendations that achieve consensus support. If there isn’t consensus to change the policy, the existing policy remains in place.
Proposal for using these documents:
- Staff prepared documents ahead of time.
- Use last 15 minutes of the call for homework -- review comments and working documents, and then prep for the next week’s call, including coordination with their groups as necessary.
- After deliberations staff will collect key points and agreements, update the report with suggested edits to review over the mailing list.
- Alternative: more offline homework with WG expected to take time every week to review comments and provide written analysis for staff to synthesize. For the EPDP this required WG members to meet in
between meetings to do homework, but we aren’t sure that’s needed here.
Discussion on Process:
- Question: If a proposal is nearly the same as a recommendation or policy, do WG members have to go back to their groups for approval? Answer: Each group will have its own procedures, but we just want
to guard against a representative from advocating for a position that is at odds with their group. WG members should ask their groups how they want to address proposals discussed in reviewing the comments.
- Timing: Try to work through dependencies first, with consolidated elements of the comments; staff will capture the discussions and incorporate them into the working documents and set a time frame for
discussions/responses from groups.
- As we review the comments and as on last week’s call, there was momentum building to adjust the recommendation #19 to something that the WG can agree on taking into consideration the comments. This
isn’t the last chance to develop final recommendations – there will be time later for the full WG to consider the new revised recommendation and to reconfirm with their respective groups. Where there is agreement on a change to a recommendation we want to
determine where we have general agreement on the text.
- Hard to get input from our groups incrementally without seeing the impact on the full policy. WG members should have flexibility with their groups to bring forward proposals and suggest how the group
should approach them – WG members need to understand what their group wants to see in the final product. There will be time to review and discuss any draft final language with their groups.
- We can adjust the process as necessary as we go.
Summary of public comments – see:
Recommendation 2 Public Comment Working Document [docs.google.com]
- A number of people (registrants and BC) said that registrants need a way to NACK/deny the transfer before it takes place. For some of these the recommendation eliminates the ability of a registrant
to deny a transfer.
- Consider whether these concerns are new and whether they need to be address.
- Concern that if the losing FOA is eliminated some registrars may adopt security measures that would delay the provision of the TAC making the process slower.
- Another element is about the security of the TAC – that measures to increase the security of the TAC are not sufficient to replace the security of the FOA, and the recommendations don’t safeguard the
security of the TAC.
- References supporting the security of the consent model. Request for data from registrars.
Discussion points:
- Whether these concerns are new and how to address them – consider whether to revise the recommendations.
- Not sure we discussed all of these ideas and if we didn’t we should think about whether or how to address them.
- Encourage WG members to look at the responses to the charter questions in relation to this recommendation.
- Make sure we address the issue that the dispute resolution process is not the same as stopping a fraudulent transfer before it happens.
- Consider whether we need to be more direct even if it is in our current rationale.
- Should be able to document how the group consider the comment (see below as an example re: violation of RFC9154).
WG Comments:
- Not persuaded by these arguments, think we address them. But maybe we need a better rationale for the recommendations – to explain how the WG addressed with their recommendations the concerns being
raised.
- Note how the Losing FOA didn’t really go away, it is addressed by the TAC. Maybe ask the registrars for data.
- A NACK isn’t necessarily a negative thing. NACKing doesn’t happen often to begin with and not all is related to fraud.
- In terms of explaining the recommendations – we are making sure that fraudulent transfers don’t even get off the ground.
- Re: assertion that RFC9154 is being violated – disagree with the commenter. There is no RFC problem here.
- On the issue of affirmative response, the reality is the "affirmative response" is the fact that an RNH logged in to the registrar account. That's the first line of defense and the FOA doesn't fix that.
If someone gets into your account they change all those points of contact and the FOA serves no purpose. I hope that's clear enough. The point is the issue is still covered, the same as always.
- These concerns are interlinked and difficult to talk about them in isolation. For example, could increase the number of days before the TAC is revealed.
- Staff will need help from WG members to confirm if the rationale in the Final Report properly addresses the concerns raised in public comment – the rationale has to address these directly.
- Well of course it's vulnerable to theft once it's generated. That's always been true. If the RNH doesn't do their part to keep it safe, well, oh well. This proposed system works better because the TAC
doesn't exist until it's needed, which is different than history. That's a significant improvement, in my opinion.
- Those who have concerns about recommendation #2 should look at recommendation #3 – specifically 3.2 – elements of TAC provision, steps the RNH can take to NACK the transfer.
- Think that there is a misunderstanding about the security properties of the Losing FOA. The reality is that the first line of defense is that fact that you’ve logged into the registrar account. People
are misattributing security properties to the FOA.
- The losing FOA did provide something that we aren’t requiring today, particularly a 5-day window for an action. So that needs additional rationale.
- Should highlight that this is a huge advancement.
- If an account got hacked you’d never see a NACK anyway. You have ACKs that are fraudulent that you don’t see.
- So, yes the 5 day window to NACK has been removed from today's traditional transfer process. But isn't this what the TTL of the TAC is meant to compensate for?
- No it doesn't. They are solving different problems.
- There still can be a 5-day window to provide the TAC, it’s just not mandatory. Registrants can choose a registrar with that level of security if they wish, or not. That is the flexibility we built in.
- The TAC TTL is just providing some protection for the TAC, limiting the overall window of vulnerability when a domain is eligible for a transfer. the 5 days window is an extra step for a registrant
at a cost of the delay waiting for the transfer.
4. Planning for ICANN75 session: Saturday, 17 September at 10:30 MYT
- Staff will send the agenda shortly and WG members should review.
- WG will continue the discussion from today’s meeting, starting with recommendation #2.
ACTION ITEMS/HOMEWORK -- Preparation for ICANN75:
1. Staff to incorporate points raised in discussion during the meeting on 13 September on recommendation #2 for WG members to review.
2. WG members to review the proposed edits in the
Recommendation 2 Public Comment Working Document [docs.google.com] and also the
following documents:
6. AOB