Dear TPR WG Members,

Please find below the notes and action items from today’s session at ICANN73.

The next TPR WG meeting will be on Tuesday, 22 March 2022 at 16:00 UTC.  Note that there will be no meeting next week on Tuesday, 15 March.

Best regards,

Emily, Julie, Berry, and Caitlin 

Action Items:

Continued deliberations on Denial of Transfers (NACKing) (60 minutes)  -- see: Working document [docs.google.com]

3.7.1: If we want to expand beyond “fraud” or clarify. WG members should suggest new language.

3.7.2: WG members to review and suggest language relating to clarify the dispute and requested by issue.

3.8.1: Staff to add the suggestion to remove “pending” and to change “informed of” to “notify”.

3.9.3: Add language to be more explicit on the order of applicability and reorder the list as MUST, MAY, MAY NOT.  WG members are requested to suggest edits to make it more clear.

3.9.3: Staff to research where the language of 3.9.5 was developed and the context/rationale.  In general staff to review the entire list (MAY, MUST, MAY/MUST NOT) as a package and see which might be combined/eliminated/changed.

Bulk Use Cases:

WG members to look at bulk transfer charter questions in the charter on bulk use of AuthInfo codes, specifically b5, b6, and b7.

Transfer Policy Review Phase 1 - Meeting #39

Tuesday 08 March 2022 at 14:30 UTC

 1. Roll Call & SOI updates (5 minutes)

2. Welcome & Chair updates (5 minutes)

• Just a couple of items left to talk about in Phase 1 before starting on drafting the recommendations.
• The WG is on schedule.
• RySG is looking at a couple of questions for us and will provide an update when ready.

3. Continued deliberations on Denial of Transfers (NACKing) (60 minutes)  -- see: Working document [docs.google.com]

Charter Question:

h1) Are the current reasons for denying or NACK-ing a transfer sufficiently clear? Should additional reasons be considered? For instance, ICANN Contractual Compliance has observed difficulties from registrars tying transfer denials involving domain names suspended for abusive activities to the denial instances contemplated by the Transfer Policy; or should any reasons be removed?

In considering this question, the WG may wish to consider:

• Should any or all of the reasons that registrars MAY NACK a transfer be changed to MUST NACK to promote consistency and reduce potential registrant confusion?Contractual Compliance has noted that many registrars and registrants remain confused by the terminology used in I.3.9.1, “Instances when the requested change of Registrar MAY NOT be denied include, but are not limited to: 3.9.1 Nonpayment for a pending or future registration period.” Does the Working Group have suggestions for clarifying this language, or does it believe it should remain as is?

Discussion of Comments (beginning on page 1):

3.7.1 Evidence of fraud.

• Does “fraud” need to be further defined to distinguish between “fraud” as it refers to the legitimacy of the transfer itself vs. “fraud” in related to the content of the website? It was noted that there is not currently evidence that this provision has been problematic to implement with the current language, so fraud may not need to be further defined.
• Agree we need more than just “fraud” because some abuse might not considered fraud.
• Abuse is an undefined concept at ICANN.  Why would we try to define it here?
• There are other types of abuse such as spam might not be fraud but might be abuse and still blocked.
• RAA could be too broad and provide too many reasons for denial of transfer.
• Broad terms like “abuse” and “fraud” could lead to too many reasons for denial.
• In theory the registration agreement can say the customer must send weekly messages to registrar by carrier pigeon. Does not violate RAA/Consensus policies, but then failure to send the pigeon message could lead to denial of transfer.
• But getting very specific doesn’t allow the policy to grow, but if “fraud” as currently referenced in the policy has not been a problem then leave it?  Or is there better language?  Maybe work on the scope of the words.

ACTION ITEM: If we want to expand beyond “fraud” or clarify. WG members should suggest new language.

3.7.2 Reasonable dispute over the identity of the Registered Name Holder or Administrative Contact.

• Potential edits: “reasonable concern [over the identity of the Registered Name Holder], that the transfer was not requested by the RNH, [or that the transfer request is otherwise not valid].”
• Say something like if the transfer was done against the will of the RNH (or intent).
• We should word it as "Reasonable concern that the transfer…"
• Look at this language and suggest revisions.

ACTION ITEM: WG members to review and suggest language relating to clarify the dispute and requested by issue.

3.7.3 Edits are acceptable.

3.7.4 and 3.7.5 Support for moving to MUST.

3.8.1 – 3.8.4 – Support to keep in this section.

3.8.1 A pending UDRP proceeding that the Registrar has been informed of.

• Remove “pending”.  Want to make sure there is an active UDRP in process, a potential dispute is not a reason to block.
• Some prefer the original language.

ACTION ITEM: Staff to add the suggestion to remove “pending” and to change “informed of” to “notify”.

Poll to aid in discussion (continued from meeting #38):

NOTE: Some of the provisions below are only displayed in part due to character limits in the polling tool. In such cases, the text ends with “. . .”

Reasons that the Registrar of Record MAY NOT deny a transfer request (Cont.)

3.9.2 No response from the Registered Name Holder or Administrative Contact.

• Leave as MAY NOT and keep language as-is – 35%
• Leave as a MAY NOT but make edits – 29%
• Remove from list – 24%
• Other/don’t know – 12%

Discussion:

• There is no requirement for a direct response from the RNH.
• Prior to the acknowledgement – think we can remove it from the list.  Don’t think it’s needed, but might keep it if revised.  No response is required so it is redundant?
• Think we could keep it but at least remove the Administrative Contact.  WG members review to see how we can make it more clear.

3.9.3 Domain name in Registrar Lock Status, unless the Registered Name Holder is provided with the reasonable opportunity and ability to unlock the domain name prior to the Transfer Request.

• Leave as MAY NOT and keep language as-is – 50%
• Leave as a MAY NOT but make edits – 22%
• Remove from list – 11%
• Other/don’t know – 17%

Discussion:

• We can still have the ability to block abusive domain names.
• Should try to use standardized terms.  Use “ClientTransferProhibited” – use the EPP status.
• ICANN has kept it flexible rather than requiring a specific EPP status – could interfere with some business models.
• Do need to find a common understanding.
• Do we want the lock to be specific or flexible?
• What is our goal with this item.  If the RNH can unlock the domain but didn't, then it's OK to deny the transfer because the domain is locked. If the RNH has no way to unlock the domain, then the lock can't prevent the transfer.
• From an ICANN perspective the ClientTransferProhibited prevents the transfer, but from a gaining registrar's perspective it can also mean that it will be retried as they would expect the Registered Nameholder to be able to remove the lock at the losing registrar.
• Thought the concern was, if the Registrar locks for abuse that lock should prevent the transfer, regardless of what the RNH wants to do.
• We have to make these clear as to why you can do this or not – what type of lock are we talking about?  We should be clear.
• Make it clear that if there is a lock for abuse then it is not eligible for transfer.  These don’t apply.
• 3.18.1 Registrar shall maintain an abuse contact to receive reports of abuse involving Registered Names sponsored by Registrar, including reports of Illegal Activity. Registrar shall publish an email address to receive such reports on the home page of Registrar's website (or in another standardized place that may be designated by ICANN from time to time). Registrar shall take reasonable and prompt steps to investigate and respond appropriately to any reports of abuse.
• If one supersedes the other we should make that explicit.  Don’t think any of these MAY NOT items supersedes a MAY or MUST.
• This still is applicable but maybe we need to change the language.  Change the order – MUST, MAY, MAY NOT.  The prior sections override.
• Could we ask ICANN Compliance for an example of this item, or where there’s been a disagreement on how to apply them.
• ICANN Compliance: Example – registrant comes to Compliance and says they can’t unlock a domain name and registrant is not responding.  Registrant does not have access to the account.  From Compliance failed access to the account is out of scope for transfer policy.  Respond that the registrar has provided the unlocking via the account.  Educate the registrant and registrar.
• [Additional Candidate Recommendation xx: If a Gaining Registrar requests a transfer and an inter-registrar transfer lock is in place, the transfer must not proceed.]

ACTON ITEM: Add language to be more explicit on the order of applicability and reorder the list as MUST, MAY, MAY NOT.  WG members are requested to suggest edits to make it more clear.

3.9.4 Domain name registration period time constraints, other than during the first 60 days of initial registration, during the first 60 days after a registrar transfer, or during the 60-day lock following a COR pursuant to Section II.C.2.

• Leave as MAY NOT and keep language as-is – 47%
• Leave as a MAY NOT but make edits – 42%
• Remove from list – 0%
• Other/don’t know – 11%

Discussion:

• Is there an example of this?  ICANN Compliance: 2 years after renewal – don’t fall into the allowed non-transfer period.
• Has anybody tried to deny?  Think this is a catch-all situation – the only time constraints are those that we have explicitly enumerated.
• So this is saying that except for the no-transfer times we already agreed on, the Rr can't deny a transfer due to what time it is?
• Poll shows strong support for leaving it on the list but with edits.
• Based on where we sit today this item seems like a catch all for the inconsistencies that exist in the market today.  The WG seems to be coalescing that there is going to be a standard create lock of X duration and a post-transfer lock of X duration, and if assume that core doesn’t change except duration and all will be MUST, wonder if this item will need to be necessary.
• If we agree on the timelines maybe we revisit this.
• Picked 2nd option, I think that will let us adjust the time period and also maybe consider including that expired domains can be transferred.  Not sure if that goes here or if it is a new one? 
• Do we need to specify if we agree on the timeframes where we can deny.  If not in those then you can’t deny.  Or do we need to be explicit?
• It might not be intuitive that you can’t deny a transfer during expiry, so I feel like it should be mentioned.
• Maybe add as an implementation note?
• Think about adding a footnote to this but keeping it.

3.9.5 General payment defaults between Registrar and business partners / affiliates in cases where the Registered Name Holder for the domain in question has paid for the registration.

• Leave as MAY NOT and keep language as-is – 59%
• Leave as a MAY NOT but make edits – 35%
• Remove from list – 0%
• Other/don’t know – 6%

Discussion:

• Poll shows strong support for keeping this with edits.
• Need clarification on this scenario. 
• Maybe use the language that is in the RAA.  This wording here is old and predate reseller.
• In practice, some registrar may advise not to transfer (but not deny) before 45 days after renewal so that they do not lose renewal period.
• Steinar posted to the list about registrars charging for the transfer – what if RNH cannot pay? Should a registrar be able to block a transfer even if the registration is paid for?
• Maybe an open question here is whether this should be even more general.
• From the policy: .10 The Registrar of Record has other mechanisms available to collect payment from the Registered Name Holder that are independent from the Transfer process. Hence, in the event of a dispute over payment, the Registrar of Record must not employ transfer processes as a mechanism to secure payment for services from a Registered Name Holder. Exceptions to this requirement are as follows: (i) In the case of non-payment for previous registration period(s) if the transfer is requested after the expiration date, or (ii) In the case of non-payment of the current registration period, if transfer is requested before the expiration date.
• Charging a fee is no explicitly prohibited.
• Think this should be changed to MUST NOT deny.
• But registrar cannot block for failure to pay the transfer fee.
• MUST NOT seems more appropriate, but ask staff to research where this language came from/context/rationale.
• What we may be seeing is an artifact from years ago before there was a transfer policy.
• Staff next step will be to review these as a package including reordering.

ACTION ITEM: Staff to research where the language of 3.9.5 was developed and the context/rationale.  In general staff to review the entire list (MAY, MUST, MAY/MUST NOT) as a package and see which might be combined/eliminated/changed.

4. Begin discussion on bulk use cases:

ACTION ITEM: WG members to look at bulk transfer charter questions in the charter on bulk use of AuthInfo codes, specifically b5, b6, and b7.

5. AOB (5 minutes) 

• Next call: 22 March 2022 1600 UTC.  Note that there will be no meeting next week on Tuesday, 15 March.