[GNSO-TPR] Notes and action items - TPR WG Meeting #56 - 02 August 2022 at 16:00 UTC

Tue Aug 2 17:46:57 UTC 2022

Dear TPR WG members,

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

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

Best regards,

Emily, Julie, Berry, and Caitlin

Action Items:

HOMEWORK/ACTION ITEMS: REMINDER – For those WG members who have not already done so, please find attached the analysis matrix to complete either individually or in a small group of your choosing.  As you work through the sheet, please feel free to refer to the Google Doc version [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1eB3cowSoEp4ERoqQmlc3hc5dpV4g5NzP/edit*gid=1995275920__;Iw!!PtGJab4!_s7mq3YcSbwZEHJfMOC2cQcVIYTklknBx3fegflsWnMzQGipncjp4RF7ZyTPslHxqTcnDBLQa1Gn7D2tAOqIt5pjVxvP0eGtnw$>, which includes example text in italics.  Please fill in the full sheet, from your own perspective, and send to emily.barabas at icann.org<mailto:emily.barabas at icann.org> no later than Monday, 08 August 2022. This will allow us to discuss any new aggregate responses on our next call scheduled for Tuesday, 09 August.

Notes:

Transfer Policy Review Phase 1(b) - Meeting #56

Proposed Agenda

02 August 2022

1. Roll Call & SOI updates

2. Welcome and Chair Updates

  *   There were a couple of requests for extension of the public comment period, which was due to close today.  It has been extended two weeks until 16 August.
  *   No meetings on the 16th, 23rd, and 30th of August.

3. Review Responses: CoR Triggers and Actions Matrix – see: https://docs.google.com/spreadsheets/d/1eB3cowSoEp4ERoqQmlc3hc5dpV4g5NzP/edit?usp=sharing&ouid=103865008760080873867&rtpof=true&sd=true

Overview of the consolidated spreadsheet:

  *   There is a column focused on triggers (column A) and a series of actions.
  *   Received 6 responses: 5 from registrars and 1 from Zak in his personal capacity.
  *   Last set of tabs are complete responses we received.  All of these are not on behalf of a particular SG.  Useful to look at to see distinct patterns and what might be appropriate for future action.
  *   Get a high-level overview from the respondents.
  *   Deeper dive into some of the actions, without immediately focusing on solutions.
  *   There are some big definitional questions, around change of control for example. Hope these definitions will be teased out.
  *   Other tab is responses by trigger – so starting in the first column with the respondent’s name.
  *   First sheet is all responses related to an update to a registrant’s name that is not a typographical error, for example.
  *   When we are going through some of the responses, this is the first round – these are not to the level of constituency or stakeholder group.  At this point it’s important to focus on whether the existing requirements are fit for purpose and the rationale around why or why not.  This will translate into the rationale for the Initial Report.

Input from Sarah Wyld (summary):

  *   Answers speak for themselves.  Column B: If the action is legitimate – we have to assume that the registrar doesn’t know because the action occurs automatically.
  *   On the the question of whether current policies are fit for purpose, we really had to think about what the purpose is – preventing theft of the domain name or allowing the registrant to transfer the domain name.  For most of these triggers, the problem is not the change but that someone else is able to make the change fraudulently – change of or lack of control.  Not sure the policy is fit for purpose.

Input from Catherine Merdinger (summary):

  *   Felt that the designated agent process eliminates a lot of the contacts with registrants.
  *   If the method of contact hasn’t changed then there is no issue for the designated agent even if other things change in the account. Where it might matter when someone owns the domain name but doesn’t have access to the email – but that is a support/admin issue.  Only care how I am going to reach you.  Don’t think there is a way to design a policy to mitigate any of these changes.

Input from Erik Rokobauer (summary):

  *   High-level: agreeing with most people’s comments.
  *   When are we ready to get some recommendations developed.
  *   Biggest confusion was columns G/H – what does it mean when it is close proximity to or part of change of control?
  *   At our registry we have a support function where people can call and verify – this can be nuanced by registrar.  It comes down to what the registrar is doing to verify requests or account for changes.

Input from Zak Muskovitch (summary):

  *   We are looking at this is for security – minimum standards for transfers.  But must all registrar be treated the same?  Some registrars have their own security protocols. If some registrars are using mechanisms to verify transfers, then why shouldn’t they be able to follow their own models with respect to transfers (say without having locks)?
  *   These are evolving thoughts and not representative of the BC.

Discussion:

  *   We (At-Large) found it difficult to respond to the questions in the matrix due to more registrar focused questioned (no problem with that).
  *   Question Re: Trigger from the Transfer Policy: II.A.1.1.4 Administrative Contact email address, if there is no Prior Registrant email address – this doesn’t seem to make sense with how things are done today.  Where does this come from? How could we not have a Prior Registrant email address?  Answer: Sarah -- Looked at it as though it could happen – didn’t ask why it could happen.  Theo – Back in 2014 discussed that there might be data missing from old data – if there was this unlikely scenario we could rely on the Admin Contact.  But now this will no longer be feasible.  Maybe there was some evidence of this originally.
  *   Re: Column B – if an action was found to be illegitimate did the resulting action mitigate it?  What are the available mechanisms after that?  Don’t think there is a specific dispute mechanism.  Does it go to a court of law?  Columns B, C, and D are there to tease out whether the resulting action is fit for purpose.
  *   In the design of the policy, change of control was a key factor.  If the fit for purpose was about mitigating hijacking do these actions accomplish that?
  *   It’s all about balance – does the process help more than it hinders?
  *   The security enhancements in Phase 1A help to address some of these problems.
  *   Columns E/F and G/H because if the original intent was to mitigate domain hijacking, is the name change alone to move into Columns G/H, for example?  Not sure a name change is even a theft.  If there is a name theft, there probably is a move to another registrar, where Phase 1A security will apply.
  *   In Phase 1A there were two entities – gaining and losing registrar.  In CoR there is one entity, the registrant, and actions happening in the same registrar.  Not sure why we are spending time on things that are not a problem outside of that registrar.
  *   Thought experiment re: what problem we are trying to solve: depends on your perspective.  For a registry, change of control is change of registrar, as in Phase 1A.  If it is within a registrar the registry doesn’t care what the registrar does. Moving from one account holder to another account holder is a change of control.  Inside of the same account it’s not.  Just because an account is changed it’s not necessarily a change of ownership.  Even a change in registrar is not necessarily a change in ownership.
  *   What we are concerned about is change of control.
  *   Change of control - between registrars you "sign" a new contract.  Even with a registrar, if you create a new account (or whatever the model is at the registrar) there must be a point of "signing a contract”, which from the point of view of a registrar is change of control.  it's not about data element comparison.
  *   We should ask whether the solutions in the policy actually worked.
  *   Would change of registrant exist in its current form today if we had some of the security requirements in Phase 1A?
  *   We do need to develop the rationale for any changes to the current policy.
  *   "inter" by definition means between, so changing the registrant within one registrar is not an inter-registrar transfer.
  *   If you think about the primary method of communication with the registered name holder – such as email – that may well be a material change that has some required mitigating action.
  *   Re: Catherine’s input, the way you contact someone is the most important thing – the anchor contact method.
  *   Would like to see that any material change should trigger notification and no other action; if there is any lock it should be a consistent time – such as 30 days.
  *   Before we can get to recommendations we still have to provide a rationale for why the current policy isn’t fit for purpose.
  *   We need to look at what is actually happening today, particularly with locks.
  *   Most registrar will place a lock but some will NACK, not necessarily visible.
  *   Question: When the CoR is invoked, there have been several mentions of the confusion that it causes. Where is this confusion happening and why? Answer: Many registrants don’t realize that they have to opt out of the lock and then are frustrated when they are locked from transferring. Question is how much you explain.  Ultimately it because a customer support issue.
  *   Right - and we don’t want to hinder offering additional security features on top of the mandatory policy requirements.
  *   Yes, that is correct I believe. but if those services prevent unauthorized transfers more effectively than without them, why would such registrars need to abide by locks which result at registrars without such additional mechanism? Just a question I have been pondering.
  *   Registrars want to offer value-added security services, but these are not the default.
  *   Next week start getting into the specifics.  There are a lot of patterns here.

4. AOB -- Next session: Tuesday 9 August at 16:00 UTC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20220802/2e930651/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TPR_P1B_CoR_Analysis_v0.1_Homework.xlsx
Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Size: 75379 bytes
Desc: TPR_P1B_CoR_Analysis_v0.1_Homework.xlsx
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20220802/2e930651/TPR_P1B_CoR_Analysis_v0.1_Homework-0001.xlsx>