Dear TPR Working Group,

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

The next meeting will be Tuesday, 21 September at 16:00 UTC.

Best regards,

Emily, Caitlin, Berry, and Julie

--

Action Items (carried over from the meeting on 07 September):

ACTION ITEM: Homework: WG members should look at reasons for denial in the current policy and comment on whether or not we need to update those reason.  Add lines or comments to the Transfer Steps and Notifications Chart:  Transfer Steps and Notifications chart [docs.google.com]

ACTION ITEM: Leadership and staff to clean up the document based on comments and determine where steps can be combined.

See the updated Work Plan and Action Items here: https://docs.google.com/spreadsheets/d/1FunWaz3gNZl8mPi5pNKti2GsfPC_9_DTt8uRQq4Oe5Q/edit?usp=sharing [docs.google.com]

Notes:

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

Proposed Agenda

1. Roll Call & SOI Updates (5 minutes)

2. Welcome & Chair updates (5 minutes)

• Updates from WG members: None.
• ICANN Contractual Compliance:
  • Not much problem with compliance., but a template for registrars to follow would be helpful – could provide clear examples, even in cases where the activity is not mandatory.
  • Question: Did ICANN Compliance “approve” NOT required to have a fixed language in English in the notifications?  Answer: Regarding the language of the notification – we look for the evidence that the registrant was informed about the instruction, reviewing the records and emails.  Compliance is accepted in languages other than English.  But the WG might consider developing a template in English that could be translated to other languages.  Question: Is Compliance okay that the WG is suggesting no requiring specific language, but making it optional but with examples.  Answer: Could provide an optional template as an example but not making it mandatory.

3. Continued Discussion of Losing FOA

a. Updated Polling Questions

(Q1) Should the losing registrar notify the registrant when the TAC is requested? – 15 responses

• Yes, This notification should be required in policy -- 53%
• It should be up to the registrar if and how they do this -- 40%
• No, I do not support this type of notification -- 7%
• Not sure/needs further discussion --0 %

(Q2) What, if anything, should be required in this communication? – 15 responses

• The notification should contain all of the elements listed in the Working Document -- 33%
• The notification should include only some of the elements listed in the Working Document -- 47%
• The notification should include a different set of elements, which have not yet been discussed -- 7%
• I do not support this type of notification -- 0%
• Not sure/needs further discussion -- 13%

Discussion:

• If we answer Q1 should be optional, then the elements in Q2 should be optional.
• Question (from ICANN Compliance): Should there be a requirement not to include irrelevant information (such as advertising)?  Answer: This is very interesting.  Are there comparable requirements where we aren’t allowed to advertise other products or include irrelevant information.  ICANN Compliance: There are a lot of examples of registrants not understanding the communication.  For example, renewal notices can contain other information. If we are creating a template, if we are requiring it then it is easier to control the content, but not such much if it’s not mandatory.
• In the current FOA the text is written.
• WG members should consider then question (as to excluding/including content) when considering the design of the template for notification.
• Should we consider requiring the option for the domain owner to be able to opt out of this notification.
• Question: Are we talking about the domain owner or the contact?  As a safety precaution it would be good to have it with a minimal requirement for certain content/elements.
• If the email address for the account holder is different from the domain owner there could be an option for the registrar to send to both.
• Yes -- I think we should have *required* point to include, and then a template version which is optional for them to use, or they can word it themselves.
• I think it only makes sense to tell the account holder that a TAC was requested… it’s like a password change request you know.
• Question: When might the TAC be emailed somewhere else?  Is there an option to send it not to the domain owner?  Answer: There are a couple of scenarios – there is the idea of contacting the account holder, who could be managing domains for other people.  Then there is the domain owner.  Could be provided to the account holder and the registrant, and these could be different.
• Question: But would we allow emailing the TAC to the account holder instead of the RNH? or did we decide that the TAC is only ever emailed to the RNH? Should we decide that?
• The TAC should not be sent by email. The policy should state in a “secure way”, hence not email.  So then we would define how they track that they provided the TAC?
• Question: Is it a different person or identity other than the registrant who is involved in receiving the TAC?  It matters to whom the notification is provided and also how it is provided.  Whoever is asking for the TAC may not be the right person.
• Policy could say that if you can confirm that the account holder and domain owner are the same then you don’t have to send to notifications, but probably makes more sense just to send to both.
• Maybe the policy should say that the domain owner MUST be aware. Either they get the TAC themself, or, if someone else got it we notify the domain owner.
• The important thing is that the mechanism used for the notification has to be able to be recorded, as well as the recipient(s).
• Sending the notification regardless is a security measure because at least the domain owner is notified that something will happen.
• On changing addresses in the control panel – such a change is likely to drive a notification, or it should.  Today, a change of email address is a big enough change that it stops the transfer from occurring. 
• If one does not opt out of 60-day lock for changing email, then yes, it delays a transfer.
• Everything we are saying about this is dependent on a change to the policy process, that the TAC would not always exist.  If we decide not to change the policy we should come back to this.
• It seems clear that there are multiple roles involved, some of which may be the same entity and some not.  Suggest staff to take an action item to apply the roles and put some definitions around them (domain name owner, account holder, other).  We will probably check with ICANN Legal re: consensus policy, re: can such a policy be developed around non-contractual roles?
• There is an existing requirement about the losing FOA that is part of the Transfer Policy.  Looking ahead we will need consensus to undue the existing requirement.
• Putting requirements on an account holder may be outside of the scope of the policy.
• Let’s not talk about when the TAC is provided yet, but when is the TAC requested.  Then, when the TAC is provided should there be a notification.
• Bulk transfer also will have a different path (to be discussed later).
• These questions are about whether there should be a notification prior to receiving the TAC.  There also is an up-to-5-day window after the TAC is requested and when it is provided.
• If we are thinking about who receives the notice that the TAC has been provided, do we have to figure out who can receive the TAC.
• What we are asking here is whether a request for the TAC should generate a notification, “Someone has requested a TAC to be issued for your domain…”
• Seems like we just have one notification, but figure out where the 5-day window resides.
• If we look at steps 2 and 3, no TAC has been provided.  The 5-day window seems to come after step 2.
• The TAC has to be sent in a secure manner – should we qualify what that manner might be?  We are trying to leave aside the mechanism to ensure future flexibility.  It will depend on the registrar model and their customers.
• Re: To whom we are providing the TAC – in the current policy the registrant and admin contact can request a TAC – if they aren’t the same the registrant trumps the admin contact.  Maybe we should keep that requirement?
• Owner can be changed in the transfer process, yes. So I do think they should be notified.
• We should allow flexibility for whom to notify.  Also, the notification mechanism should be up to the registrar.  For example, the registrar may not have an email contact.
• NOTE: Seems that people agree that the line two Request to prepare domain for transfer notification is optional and it would go to the domain owner.

The following questions relate to lines 4 and 5 in the transfer document (Fulfill request to prepare domain for transfer

(Q3) Should the losing registrar notify the registrant when the TAC is provided? – 20 responses.

• Yes, This notification should be required in policy -- 80%
• It should be up to the registrar if and how they do this -- 10%
• No, I do not support this type of notification -- 10%
• Not sure/needs further discussion -- 0%

(Q4) What should be included in the notification of TAC provision? --20 responses

• Include a link to notify registrar if TAC was not requested by registrant -- 65% 
• Include no links (the message serves as a notification only) -- 10%
• I do not support any notification of TAC provision --10 %
• Not sure/needs further discussion -- 15%

Discussion:

• What we are talking about is 1 notification that may be to multiple people – “Here is your TAC” and the main question is whether it should be required to notify the registrant when the TAC is provided.
• If we go down the route of differentiating between “request TAC” and “TAC provided” as two separate occurrences, we should be clear that in cases where those things occur simultaneously, that a single notification is required.
• If steps 2-5 are fairly instantaneous that should probably be 1 notification.
• Could permit but not require more than 1 notification.  But make it a requirement to notify the registrant when the TAC is provided.
• We can think about what exactly might be the content of the notification – or minimum requirement.
• NOTE: Optional notification that the TAC was requested; mandatory notification to the registrant when TAC is provided/request fulfilled.

(Q5) Should the losing registrar send a separate notification to the registrant when a transfer is pending? – 17 responses

• Yes, This notification should be required in policy -- 47%
• It should be up to the registrar if and how they do this -- 35%
• No, I do not support this type of notification -- 12%
• Not sure/needs further discussion -- 6%

(Q6) What should be included in the notification of pending transfer? – 17 responses

• Include a link to deny transfer (status quo - Losing FOA) -- 18%
• Include a link to deny the transfer and a link to approve the transfer -- 47%
• Include no links (the message serves as a notification only) -- 0%
• I do not support any notification of pending transfer -- 18%
• Not sure/needs further discussion -- 18%

Discussion:

• When this is sent: This is very similar to the current losing FOA process; sent after the TAC has been obtained by the domain owner, and the domain has been unlocked, but before the TAC is provided to the gaining Registrar (at which point the domain is transferred).
• It doesn’t make sense to have various periods and various requirements.  Could have 3 notifications for the same thing – should just be 1 with the option to issue more.
• There are a couple of themes coming out of these steps, so could look at overarching principles: 1) notify someone of significant changes happening to their account/domain name.  We are walking through a series of potential steps, and the issue we keep coming back to is the timing – is it dependent or independent.  The policy has to allow for some of the dependent discrete steps depending on the registrar.  Need to extract the timing restraints.
• Think that the goal should be to require a single notice/email somewhere in this path (TAC provided, transfer pending), that gives the registrant the ability to terminate the potential transfer.  But not necessarily a separate notice for each step, unless the RR separates out each step.

(Q7) Should the losing registrar send a separate notification to the registrant when a transfer is complete? – 15 responses

• Yes, This notification should be required in policy --60 %
• It should be up to the registrar if and how they do this -- 33%
• No, I do not support this type of notification -- 0%
• Not sure/needs further discussion -- 7%

(Q8) What, if anything, should be required in this communication? – 15 responses

• The notification should contain all of the elements listed in the Working Document -- 20%
• The notification should include only some of the elements listed in the Working Document -- 67%
• The notification should include a different set of elements, which have not yet been discussed -- 0%
• I do not support this type of notification -- 7%
• Not sure/needs further discussion -- 7%

Discussion:

• The principle is that there are moments in time that a registrant should be notified, but the timing is a separate question.
• if the ownership info changes during the transfer, only the losing Rr can send to the pre-transfer owner. So I chose yes, required
• These notifications should be sent to the registered name holder, aka owner of the domain.
• Most important info is IANA ID or name of new registrar.
• NOTE: Seems to be agreement that this communication to the registrant of the completed transfer should be required, with some agreement on only some elements included.

(Q9) Should any of the above notifications be combined?

(Q10) If yes, which notifications?

Discussion:

• We’ve talked through the last two poll questions.

b. Further discussion of Transfer Steps & Notifications [docs.google.com] (see above)

4. Introduction of Gaining FOA Working Document Overview and Charter Questions

Overview (see above document)

Discussion:

• Postpone to the next meeting.

5. AOB -- Next meeting: Tuesday, 21 September 2021 @ 16.00 UTC