[GNSO-TPR] Notes and action items - TPR WG Meeting #78 - 24 January 2023 at 16:00 UTC

Tue Jan 24 17:56:29 UTC 2023

Dear TPR WG members,

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

The next meeting will be on Tuesday, 31 January 2023 at 16:00 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin

ACTION ITEMS/HOMEWORK:

Ongoing Actions:

  1.  Small Team on Recommendation 13 TTL: Provide revised rationale.
  2.  Small Team on threat vectors: Provide language.

Actions from Meeting on 24 January:

1. Re: Recordkeeping: Staff will draft a standalone recommendation with 15 months to insert into the next redline.

2. Re: Recommendation 17: WG members to take the language and suggested revisions back to their groups and provide to the WG at least informal feedback whether the proposed change is supported or not.  See attached redline and screenshot.

3. Re: Recommendations 16 & 17: Staff to suggest language to include in Recommendations 16 and 17 re: 30-day restriction replacing existing restrictions (such as 60-day locks).

Notes:

Transfer Policy Review - Meeting #78

Proposed Agenda

24 January 2023

1. Roll Call & SOI updates

2. Welcome and Chair Updates

  *   Need rationale from the small team on Rec 13 TTL in the next week.  No update provided at this time.
  *   Need a write up from the small team on threat vectors in the next week.  No update provided at this time.

3. Input received on 21 December redline (recommendations 10-22): https://docs.google.com/document/d/1Zoh8D2GuulpIDbyqwYsfRCSJkiGpa19k02eiEE-tWnE/edit

  *   No comments received.
  *   Given no comments, we think that means that WG members are comfortable with it so that there won’t be any surprises later.

4. Proposed language from ICANN Contractual Compliance on record keeping: https://mm.icann.org/pipermail/gnso-tpr/2023-January/000740.html

“Registrar shall retain all records pertaining to the provision of the TAC to a Registered Name Holder, as well as all notifications sent per the requirements under this Transfer Policy. At a minimum, the records retained in accordance with this section shall document the date/time, means and contact(s) to whom the TAC and notifications are sent. Registrar shall maintain these records for the shorter of two (2) years or the longest period permitted by applicable law, and during such period, shall provide such records to ICANN upon reasonable notice.”

  *   Drafted in accordance with the current RAA and doesn’t prevent the Registrars from setting their own records retention policies.

Discussion:

  *   Question: Was the gTLD Registration Data policy (not yet finished the IRT) considered? I think it spoke to retention periods.  Answer: This was considered, but this is open for discussion.  Drafted Reg. Data policy suggests 15 months – consider aligning.
  *   Does there need to be anything said about data processing agreements?
  *   Seems that the text makes sense.
  *   Confirming that staff will draft a standalone recommendation with 15 months to insert into the next redline.

ACTION ITEM: Re: Recordkeeping: Staff will draft a standalone recommendation with 15 months to insert into the next redline.

5. Continued discussion on proposed redline from Small Group on Exemption for Recommendation 17 (see attached)

Discussion:

  *   Suggestions from Sarah Wyld (see attached screen shot): Changes to help clarify: “Registrar will remove the registrar lock…” and change to “fewer than 30 days” (from “less than 30 days”), add “at the Registrar’s discretion” to replace “for the purpose of an inter-registrar transfer”.
  *   Small team: Suggest not removing “for the purpose of an inter-registrar transfer”.  I think also we should keep “at the Registrar’s discretion” as well as “ClientTransferProhibited”.
  *   At least one WG member is against the change.  Disabling ability to prevent registrar-hopping.  Also, dependencies on dispute discussions in future.
  *   Note that the report uses the term “restriction” rather than “lock”.
  *   Think it is a good point to ask why this was introduced since registrar-hopping is an important consideration and it isn’t currently tracked.  Will also be interdependent with possible rollbacks in the next phase.  If we define this now, will we be able to come back to it?
  *   If we decide something later that breaks something we’ve already said we’ll have to revisit it.
  *   No decision from the WG at this time – doesn’t seem like there is strong support at this time.  Would be good to have a Stakeholder Group discussion on this and at least informal support or not.
  *   Note that this exception would apply only post transfer.

ACTION ITEM: Recommendation 17: WG members to take the language and suggested revisions back to their groups and provide to the WG at least informal feedback whether the proposed change is supported or not.  See attached redline and screenshot.

Additional Issues:

  *   Question: If we create a 30-day restriction should we explicitly say that any existing 60-day restrictions would go away?  Answer: Important to document – should we put language in the policy or otherwise to make this clear?
  *   As staff understands it in today’s world most of the requirements are set, are set by varying contracted parties outside of the RA/RAA, so we need to be precise in the policy itself.
  *   Need to specify in order to enforce.
  *   Question: Where to put the language? Should be in the body of the recommendation.

ACTION ITEM: Recommendations 16 & 17: Staff to suggest language to include in Recommendations 16 and 17 re: 30-day restriction replacing existing restrictions (such as 60-day locks).

6. Possible minor modifications to Losing FOA (see bracketed text below)

Preliminary Recommendation 2: The working group did not reach agreement to eliminate or substantially change the Obligations of the Registrar of Record described in Section I.A.3.1 - I.A.3.6 of the Transfer Policy. Therefore, the working group anticipates that these requirements will largely remain in place. The working group recommends the following minor modifications:

  *   The term [“Transfer Confirmation”] must be used in place of “Standardized Form of Authorization (FOA).”
  *   [The [Transfer Confirmation] must include the Gaining Registrar’s IANA ID]
  *   [The [Transfer Confirmation] must include both an opportunity for the RNH to proactively accept the transfer AND an option to cancel the transfer]
  *   [The [Transfer Confirmation] must be provided in English and the language of the registration agreement and may also be provided in other languages]

General Discussion:

  *   Question: Also include a name in addition to IANA ID?  (Many ccTLD registrars do not have an IANA ID)  Could potentially include language as in Rec 14 to provide flexibility.
  *   Concerns from Sarah re: “opportunity for the RNH to proactively accept the transfer AND an option to cancel the transfer”.

Discussion on each suggestion:

The term [“Transfer Confirmation”] must be used in place of “Standardized Form of Authorization (FOA).”

  *   WG agrees.

[The [Transfer Confirmation] must include the Gaining Registrar’s IANA ID]:

Discussion:

  *   Match language in Recommendation 4; name might not mean anything.  The IANA ID is the only unique identifier that exists in the system.
  *   Staff suggest changing to ““IANA ID(s) of Gaining Registrar(s) and link to ICANN-maintained webpage listing accredited Registrars and corresponding IANA IDs. If available, the name of the Gaining Registrar(s) may also be included.””
  *   Might want to be careful on this one – by including a name it opens up the possibility of disagreement between the two fields.  Should identify a clear benefit because code will have to change.
  *   The issue is that a poll message is issued from the registry to the registrar – as long as we define it as coming from the IANA registry there should be no confusion.
  *   This is added information to help the RNH.
  *   With respect to resellers, sub-resellers, etc, this is why anchoring it with what’s in the IANA registry is our only option.  such is the “standard” that our system offers to us to work with.
  *   Re: “IANA ID(s) of Gaining Registrar(s) and link to ICANN-maintained webpage listing accredited Registrars and corresponding IANA IDs. If available, the name of the Gaining Registrar(s) may also be included.” Do we need to specify that this is the name of Gaining Registrar(s) as included in the IANA database?
  *   Make sure we correct things that have been problems, but also to suggest things that will improve security – which IANA ID will do.  Just don’t require people to use it.
  *   If we have it let’s use it.
  *   Having it could be very helpful to registrars and registrants.
  *   The IANA ID is already being passed around – don’t think there would be contention with “MUST”.
  *   Going back to Recommendation 4.3 – The ID is maintained by ICANN through IANA.  The requirement is for the ID and a link to the page of IDs with names.  The names can come from there as well.  Losing registrar has a look-up to the IANA database/registry.
  *   See: IANA IDs https://www.iana.org/assignments/registrar-ids/registrar-ids.xhtml
  *   Should be careful to say it comes from the “registry available at IANA”. It’s not IANA’s registry or a registry maintained by IANA.
  *   WG agrees: Use the exact same text as in Recommendation 4.3.  So same in both places.

[The [Transfer Confirmation] must include both an opportunity for the RNH to proactively accept the transfer AND an option to cancel the transfer]

  *   This would be a change from the status quo.
  *   Make mandatory for accept AND option to cancel.
  *   WG agrees: Stay with status quo – ACK is optional.

[The [Transfer Confirmation] must be provided in English and the language of the registration agreement and may also be provided in other languages]

  *   See 3.3 The FOA shall be communicated in English, and any dispute arising out of a transfer request, shall be conducted in the English language. Registrars may choose to communicate with the Transfer Contact in additional languages. However, the Registrar choosing to exercise such option is responsible for the accuracy and completeness of the translation into such additional non-English version of the FOA. Further, such non-English communications must follow the processes and procedures set forth in this policy. This includes but is not limited to the requirement that no Registrar shall add any additional information to the FOA used to obtain the consent of the Transfer Contact in the case of a transfer request.
  *   WG agrees with the suggested text.

Issues for the next meeting:

  *   Format of the Losing FOA;

     *   Should we include in the recommendation that this deadline should be expressed in hours in addition to number of days "3.5 Failure by the Registrar of Record to respond within five (5) calendar days to a notification from the Registry regarding a transfer request will result in a default "approval" of the transfer."
     *   Do we need a recommendation that provides specific details about how, when and by whom the pending transfer status is set and removed?
7. AOB

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20230124/ea46be5e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rec17-idea.JPG
Type: image/jpeg
Size: 71482 bytes
Desc: rec17-idea.JPG
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20230124/ea46be5e/rec17-idea-0001.JPG>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DraftRevisionstoPreliminaryRecommendation16and17v2-0001.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 41172 bytes
Desc: DraftRevisionstoPreliminaryRecommendation16and17v2-0001.docx
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20230124/ea46be5e/DraftRevisionstoPreliminaryRecommendation16and17v2-0001-0001.docx>