Dear TPR WG Members,

Please find below the notes and action items from today’s call.

The next TPR WG meeting will be on Tuesday, 23 November at 16:00 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin 

Action Items

1. Losing FOA Candidate Recommendations – see: Losing FOA Working Document (beginning on p. 14)

Candidate Recommendation #12: Staff will add a reference/footnote.

Candidate Recommendation #13:

1) Staff to review the discussions to clarify the rationale for this recommendation to have two communications.

2) WG members to suggest wording for the method of sending and period of time (text in brackets).

Candidate Recommendation #14: WG members to suggest wording re: the method of sending and period of time (text in brackets).

Candidate Recommendation #15:

1) WG members to suggest wording re: the method of sending and period of time (text in brackets).

2) Staff to update the context to add text on when this makes sense to be used.

Candidate Recommendation #16: WG members to suggest wording re: the method of sending and period of time (text in brackets).

2. Rationale for Elimination of the Gaining FOA: WG members to review the document at Gaining FOA Working Document [docs.google.com] (beginning on p. 16) and provide suggestions and comments if any.

Transfer Policy Review Phase 1 - Meeting #23

Tuesday 16 November 2021 at 16:00 UTC

1. Roll Call & SOI Updates

• No updates provided.

2. Welcome & Chair updates

• Will return to the lock discussion in a few weeks.
• Note that since we are being so efficient, we are looking to do a Project Change Request to pull forward the NACKing discussion scheduled for Phase 2 so we can get a complete view of the transfer policy during Phase 1a.  That includes copying what we are doing now to review charter questions, develop recommendations, and incorporate into the Phase 1 report.  We will inform the Council that those discussions may include the TEAC – how it may change or be enhanced with respect to the NACKing of transfers, but any recommendations for changes will not be part of Phase 1, but will stay in Phase 2.
• Schedule NACKing after we get through with our discussions on bulk, etc.
• The RrSG is holding a poll on locking.
• At-Large CPWG also will hold a poll on locking.

3. Losing FOA Candidate Recommendations – see: Losing FOA Working Document (beginning on p. 14)

Candidate Recommendation #12: The Working Group recommends eliminating from the Transfer Policy the requirement that the Registrar of Record send a Losing Form of Authorization. This requirement is detailed in sections [xxxx] of the Transfer Policy.

• Wonder if there should be a footnote that there will still be a notification.
• It would really help to include the explanation/context so that people not familiar will know that there will still be a notification.
• Context: How this is structured – the candidate recommendations are preceded by a response to the charter questions, which does provide the context, including the rationale.  These recommendations won’t be presented in isolation.
• ACTION ITEM: Staff will add a reference/footnote.

Candidate Recommendation #13:

• What do we mean by “distinct” as in “If the Registrar of Record provides the TAC by email, the email containing the TAC and the message notifying the RNH of the TAC request must be two distinct communications.”  Could be “two separate communications”.
• Don’t see the value of sending two separate emails.  Would rather see a combination of this in one email.
• The important part is the notification to the registered name holder (RNH).  There is also the concept of the 5-day window at the beginning.
• Definitely agree we must ensure the RNH is notified; not sure it needs to be two separate messages. But we must have had some reason for it?
• Would like to include the name of the person who requested it.
• If we look at rows 4 and 5 in the charter, that is what we are doing here.  The question we haven’t answered is do we have to specify who the TAC is provided to?  If provided to the RNH then we don’t need separate methods.  If to someone other than the RNH we’ll need two messages.  The security element (secondary notification to RNH) is only needed if the TAC is provided in some method OTHER than by email to the RNH
• It can only go to the RNH.  It only makes sense to go there.
• When we are talking about how we supply the TAC, there could be other means.  We could send a notice that a TAC has been created and to look in your account,.
• If we look at the early deliberations, some support was expressed for making this two distinct communications for security reasons.
• Maybe we split this recommendation up: 1) notification to RNH that a TAC has been requested. 2) If the RNH is receiving the TAC via a communication then they know that the request happened (so no need for a separate communication).
• Our goal is to ensure that the RNH is aware of the request.
• We want to say if the TAC is being communicated to the RNH then we don’t need two communications, but if provided by a different mechanism then the RNH should receive a notification that the request has happened.
• It might be helpful to zoom out to look at the table at: https://docs.google.com/spreadsheets/d/17ADMRTYxN5sA-e3WoEI96KxlH5YRALBsxgwOmpsCC0g/edit?usp=sharing.
• Also note that the recommendations are in order of mandatory ones first then optional, rather than in order of the process steps.
• Registrar doesn’t know how the reseller is going to deliver the TAC.
• Maybe it will be clearer if we break this recommendation into two parts.
• Try to make the type of communication/notification as generic as possible.  Suggest wording.
• List doesn’t say specifically that the TAC has to be provided or how.
• Don’t we have recommendations relating to the TAC?  We have a set of recommendations that are specific to the TAC.  Notifications of the provision of the TAC are related to the Losing FOA, so that is why the reference is here.  We are likely to reorganized these when they are agreed to so all of the TAC recommendations are together.
• Envision a scenario where someone logs into a portal and updates the RNH email address and requests a TAC – could be fraud in the account.  So, if a RNH email is changed in a certain amount of time then a notification is sent to the previous RNH.
• Think the above scenario will come up as part of the change of registrant process.  Not sure that is a problem we need to solve for.
• We cannot stop this type of fraud with an ICANN policy.
• Concerned that we are relying on laws to provide security via some cumbersome and lengthy process, rather than looking at mechanisms that can enhance the security of the transfer.
• This relates to Change of Registrant (COR) so we’ll delay that part of the discussion.
• ACTION ITEMS: 1) Staff to review the discussions to clarify the rationale for this recommendation to have two communications.  2) WG members to suggest wording for method of sending and period of time (text in brackets).

Candidate Recommendation #14:

• On number 1 and the IANA ID – losing registrar always gets the IANA ID but not the name of the gaining registrar – if we want that then the registry will have to provide it.
• Does it matter that the IANA ID is provided with the name of the gaining registrar?
• Think adding IANA ID will overly complicate a communication intended for non-technical people.
• Agree that regular users will find IANA ID confusing and unhelpful, but also agree that we can't currently automagically get the actual registrar name.
• “Regular users” have a problem when there are resellers have initiated the transfers and the RNH sees the Registrar name (with/without IANA ID).
• We do not have info about resellers at the gaining registrar.
• Not sure that we need to set a requirement on that.
• Language seems flexible enough to allow for minimal notification.
• In most cases we see reporters do not know about registrars and file reports with compliance as changing reseller/service provider, but in fact it ends up with changing registrar.
• ACTION ITEM: WG members to suggest wording re: the method of sending and period of time (text in brackets).

Candidate Recommendation #15:

• This is one of the optional notifications.
• Add a number 4, the reason for the delay, if there is one?  If it is due to a delayed TAC response this would be a good idea.
• Do we need to add the rationale for why this is needed?  Maybe clarifying when this makes sense to be used in the context.
• ACTION ITEM: 1) WG members to suggest wording re: the method of sending and period of time (text in brackets). 2) Staff to update the context to add text on when this makes sense to be used.

Candidate Recommendation #16:

• This is the second optional notification – the pending notification.
• If this is optional, do we have to specify the period of time?
• ACTION ITEM: WG members to suggest wording re: the method of sending and period of time (text in brackets).

4. Rationale for Elimination of the Gaining FOA – see: Gaining FOA Working Document [docs.google.com] (beginning on p. 16)

ACTION ITEM: WG members to review the Rationale for Elimination of the Gaining FOA – see: Gaining FOA Working Document [docs.google.com] (beginning on p. 16) and provide suggestions and comments if any.

5. AOB

• Next call: Tuesday 23 November 2021 at 16:00 UTC