Dear TPR Working Group,

Please find below the notes and action items from today’s TPR meeting on Tuesday, 17 August 2021 at 16:00 UTC.

The next meeting will be Tuesday, 24 August at 16:00 UTC.

Best regards,

Emily, Caitlin, Berry, and Julie

Action Items

ACTION ITEM: In preparation for the next meeting on 24 August WG members to provide suggested language for changes to the current losing FOA policy in the working document along with those provided on page 3 at: https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy-raY/edit?usp=sharing.

Notes:

Transfer Policy Review Phase 1 - Meeting #13 – Tuesday, 17 August at 16:00 UTC

Proposed Agenda

1. Roll Call & SOI Updates (5 minutes)

2. Welcome & Chair updates (5 minutes

3. Continued discussion of Losing FOA (75 minutes)

Losing FOA working document [docs.google.com]

At-Large Consolidated Policy Working Group (CPWG) comments – Steinar Grotterod on Outcomes of CPWG discussions: (Link to the Losing FOA working document: https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy-raY/edit )

Held discussions and polls.
Outcome is that CPWG agreed to keep the losing FOA as mandatory.
What the CPWG is: Policy members from the At-Large community. Report every week to the ALAC and bring questions back to the CPWG. Helps to avoid making personal decisions on behalf of At-Large.

Discussion:

Great that ALAC is having these discussions and we hope that the other groups are doing the same thing.
Question: Why is the losing FOA important to preserve as a mandate for At-Large? Answer: It helps protect the registrant. When the losing FOA is sent, if the registrant hasn’t initiated the transfer when the registrant gets the losing FOA notification it can stop the transfer. So it provides added security.
Agree that the losing registrar should be required to notify the domain owner about the transfer. But I don't think the losing FOA should be required for approval/denial.
Question re: losing FOA being generated by the incumbent registrar. Need to document a distinction: If the TAC is provided to the registrant and the TAC is the authorization is allowed to take place. Then for the FOA to be an extra layer of security then it needs to go somewhere other than to the entity (registrant for example) who got the TAC. Otherwise it is not an additional layer of security.
We should use the losing FOA to notify the registrant. But not to approve/deny the transfer (that's the TAC).
TAC will be given to account holder. Loosing FOA will be sent to registrant e-mail. If we keep that practice sometimes it will be different entities and sometimes it will be the same entity.
Question: If the losing FOA is maintained, what if it is just a notification but doesn’t slow down the transfer? Answer: That is good, but not if we have to wait 5 days.
The losing registrar should send it as a notification of a transfer and build in a transfer reversal process. Require it but not the 5-day delay.
Depends on how much security you need. Depends on how big is the security problem.
At-Large CPWG will not necessarily vote against improvement of the losing FOA, just that there should be a message to the registrant and the losing FOA is one way to do that.
In thinking this through, there are some circumstances of a frictionless transfer – where the registrant has opted into a fast transfer. So in those circumstances it is an opt out of the usual notifications. If there were a deliberate process for the registrant to opt out of notifications what would the At-Large think about that.?
Maybe don’t call it a FOA, but just a notification. Is important for the losing registrar to send it. Retain the FOA if we are changing it to a notification.
We should rename it and change it to just a notification.
In the At-Large CPWG we are in favor for there to be a way for the registrant to be able to stop the transfer.
There has to be some reverse process, and boundaries around it to make sure people are not abusing it.
For rewriting the losing FOA, we should make required elements, but not actual required form/content. The current version is unwieldy.
In building a reversal process need to determine what to do if a renewal is involved.
Right now the compliance for the mandate is very strict. Should be guidelines.
WG members should put suggested language in the working document.

Draft Straw Poll Questions - Losing FOA:

1. Does the Losing FOA serve a security function? -- 20 Responses

Yes, and it is important that the Losing FOA continues to serve this function --20 %
Yes, but this function can be served through other measures -- 55%
No, it does not serve this function --15 %
Not sure/Needs further discussion -- 10%

Discussion:

Several ccTLDs do not have this form of authorization. We haven’t looked at their experiences. Not sure if this provides security.
At lot of the large ccTLD operators do not use the FOA.
This seems to be a weak form of security. Better if the registrar has a control panel with two-factor authentication.
Hard to compare ccTLDs and gTLDs. There are some differences.
There are several options. There is a notice before the transfer happens, there is a notice after a transfer might occur. There is a version of the losing FOA that includes a link or means to decline the transfer. Then a version of that to approve the transfer. Took the question to refer to the latter of the two options. We should be explicit about what we are agreeing.
Note that the transfer isn’t one thing, it has multiple factors in it.
The FOA was meant to ack or nack a transfer, it was not a security feature and as a security feature it is rather weak

2. Does the Losing FOA serve a notification function? -- 21 Responses

Yes, and it is important that the Losing FOA continues to serve this function --62 %
Yes, but this function can be served through other measures -- 38%
No, it does not serve this function -- 0%
Not sure/Needs further discussion -- 0%

Discussion:

Maybe the language in the RAA needs to be changed.
Seems like everyone agrees.

3. Does the Losing FOA serve a “paper trail” function? -- 20 Responses

Yes, and it is important that the Losing FOA continues to serve this function -- 35%
Yes, but this function can be served through other measures -- 45%
No, it does not serve this function -- 15%
Not sure/Needs further discussion -- 5%

Discussion:

Not sure it provides a paper trail. A positive or negative response is not necessary for the transfer to occur.
Yes, need to keep records. So not exactly full email, but copy of template and log about sending the FOA
Shouldn’t be too restrictive as to the type of communication. Should allow registrars to implement as they see fit.
Registrant should be able to choose their notification method.
In terms of record keeping don’t see how it is useful to show that the registrant acknowledged a transfer on day X.
The new notification email should not require action on the registrant's part (it's just a notification).
When we say “record keeping” what level are we talking about?
When we are talking about the losing FOA there are options in the marketplace where a registrant deliberately opts into a pre-authorization of a transfer. There could be legitimate reasons to not have these types of transfer notifications. Should allow frictionless transfers without requiring notification.
ICANN Org (Compliance): FOAs currently are only a notification and the losing the FOA only goes to the account holder. The registrant does not have the option to deny a transfer. The FOA is only a notification.

4. Does the Losing FOA serve another function not listed in previous questions? -- 21 Responses

Yes -- 5%
No -- 67%
Not sure/Needs further discussion -- 29%

Discussion:

Have had experiences in the last year where we’ve needed someone to forward the FOA email. There are some legitimate scenarios where the FOA helps to ensure that a transfer is done reliably.
Seems to be general agreement that the FOA is not needed in other circumstances.

5. Should the Losing FOA continue to be required? -- 23 Responses

It should be required as-is -- 4%
It should be required but updated/changed -- 57%
It should be eliminated as a requirement, but other measures are needed to serve certain functions -- 30%
It should be eliminated as a requirement with no additional measures to replace it -- 4%
Not sure/Needs further discussion -- 4%

Discussion:

Think we are leaning to yes, but it needs to be updated and modified.

6. If you no longer support the Losing FOA as a requirement, would you support it as an optional resource for the Losing Registrar, i.e., “Losing Registrar MAY confirm the intent of the Registered Name Holder…”? -- 19 Responses

Yes -- 47%
No -- 26%
Not sure/Needs further discussion -- 26%

Discussion:

Really interesting idea. Could see a situation where a registrar wants to have additional security. Should be allowed with some parameters/boundaries, so it doesn’t become prohibitive.
If we make the losing FOA possible we should add the requirement that it should be as easy to acknowledge or deny a transfer.

Summary:

Agree that it needs to be updated.
Needs flexibility to grow.
If we see losing FOA as optional, then the TAC will be mandatory.
We could provide required points and an optional template (which covers those required points).
We should split these up: The registrar transfer notification is required, and the losing FOA is optional.
Need a few people to write down thoughts on changes to the losing FOA – such as name change, options versus mandatory, etc. Bring these suggestion to the next call for discussion.
Add to what Sarah has provided in page 3 of the document at: https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy-raY/edit?usp=sharing
Question: Can the losing FOA be used for bulk transfers?
Seems like instead of it being an FOA, it could be a notification as when you change your email.
Seems like each domain name should have its own unique transfer notification – but we could leave it up to registrars to design the system to allow bulk transfers.
Think bulk transfer is permitted now, we can leave it as it is now.

5. AOB (5 minutes)

- Next meeting: 24 August 2021 @ 16.00 UTC