Dear TPR WG members,

Please find below the notes from last week’s meeting. We apologize for the delay.

The next meeting will take place tomorrow: Tuesday, 29 October 2024 at 16:00 UTC.

Kind regards,

Julie and Christian on behalf of the TPR WG Support Team

2024-10-22 Transfer Policy Review PDP WG Call

Action Items:

1. ICANN Org to update recommendations based on discussions and present revised drafts.
2. WG Members to complete Assignment 3 (review of comments to Recs 25-28) and review the updated draft recommendations.

Documents:

• Link to Public Comment Review Tool (PCRT): https://docs.google.com/spreadsheets/d/1lyX27uECA5bNKRw-UOIH2bAaTRvec1YkX1EKjtHCsAQ/edit?usp=sharing [docs.google.com]
• Link to Rec Drafting Guide: https://docs.google.com/document/d/1YODFe-aZOi1AQ3c8f2-y8MXtcUU4PjzsByFzk-dpAD4/edit?usp=sharing [docs.google.com]

1. Welcome and Chair Updates

1. The Chair welcomed all attendees and provided brief updates.
2. He noted that we made great progress and we should keep up the momentum.

2. Review Draft Revisions to Recs 5-7, 9, and 11

Overview:                                                                                                                    

•  In the public comment review tool note that support staff has gone added information to the Working Group response column. After the comments there's a column where we can take notes on the Working Group's discussion and support staff has gone through to assist the Working Group with an attempt to capture what the Working Group agreed to on the call.
• Because this is a Google sheet, all Working Group members have the ability to comment and note if they if you think that either the conversation or agreements weren't captured correctly, or alternatively, if something needs to be added, or any sort of edits that you think are appropriate as a reminder. This is the tool that's going to be published, or rather is published on the Working Group site, and where public commenters can go and see in detail how their comments were treated, or how the Working Group responded to those. So in order for transparency, as well as out of respect to the folks who took time to submit, we are showing exactly how the Working Group responded in the Working Group response column.
• In particular, review the Notes Column where we captured the discussions from last week.  We aren’t going to go over those today, and what was agreed by the Working Group was captured in the notes distributed after the call. Please review the Notes Column to make sure we accurately captured the discussions.
• To review the Draft Revisions of the recommendations we discussed last week, the public comment review recommendation drafting guide is a tool that we're using. That's linked within that public comment review tool where the Working Group can work through edited text for each recommendation. So you'll see 3 boxes for each recommendation:

1. The 1^st box is the red box that shows the exact language from the Initial Report. You'll see that it's annotated with some comments, and that represents comments received from the public commenters. These are summarized. We expect that every Working Group member has already read through all those comments.
2. The 2^nd box is the yellow box labeled “Under Construction.”  The Working Group hasn't agreed to this language. This is merely a visual representation of comments that public commenters submitted, where we actually add the requested language into the recommendation, so that the Working Group can see what that would look like and have a discussion from there.
3. The 3^rd box is the green box at the bottom will be where the agreed to final report language is included, and that also gives a trial for the community to look and see. These are some of the changes the group considered, and this is ultimately what they agreed upon for the final report.

Recommendation 5 – definition of the TAC:

• The concern in the Initial Report language that commenters called out is that the definition uses the language “authorizes the transfer” when this code is presented, and several commenters noted that even if the TAC is obtained, the transfer might not be able to go through for a variety of reasons, and those are included in the transfer policy.
• The suggestion here in the second sentence is to adjust the language slightly to the TAC is required to be presented for a domain name and when presented authorizes an “eligible” transfer.
• A couple of Working Group members noted that that language made it a little bit more confusing. So the Working Group might want to include some examples of what that means. But if the group thinks that is self-explanatory, then we can leave the language as is.
• The Working Group agreed with the revised language: “eligible transfer.”

Recommendation 6 – SLA for TAC Provision:

• There was a comment to change the title to: “Required Timing for TAC Provision”.
• There was a comment to change calendar days to hours.
• The Working Group agreed with the revised title and language.

Recommendation 7:

• The Working Group agreed with the addition of a comma.

Recommendation 9.1 and 9.2 – TAC TTL:

9.1:

• There was a comment to replace calendar days with hours. It was noted the since the Working Group agrees with this type of change they will be called out in future.
• The Working Group did not agree with the added text.

9.2:

• The Working Group discussed the added text (the registrar to set the TAC to null for security reasons without agreement of the RNH) and agreed that there were cases where this could be necessary.
• One member noted that allowing the TAC to be set to null was effectively a denial and that the registrar should have to provide an explanation to the RNH.  Another member suggested such an explanation might not be feasible in all cases.
• There was a suggestion that language could be added for the registrar to notify the RNH when the TAC is set to null.
• The Working Group agreed with the change to hours in 9.1 but not with the additional text.
• The Working Group agreed with the added text in 9.2 and will consider whether to add a notification.

Recommendation 11 _-_ Notification of TAC Issuance

• There were concerns that the timing of the notification (10 min.) is too short.
• In 11.1, there was a suggestion to add “(if different)” after “registration agreement” in “This notification MUST be provided in English and in the language of the registration agreement and MAY also be provided in other languages.” 
• Summary of comments:  On the footnote on how notification should be sent; from ICANN Org on an RFC re: secure communications not being sent via email; on notifications to privacy or proxy services also going to the underlying customer; and on the registrar confirming that the RNH meant to request a TAC.
• Suggested changes:

1. 11 -- Added “affiliated” before privacy or proxy service provider;
2. 11.1 -- Added “(if different)” after “registration agreement”;
3. 11.3 – No agreement to add a 24-hour requirement to allow the registrar to invalidate the TAC, but Working Group could clarify for commenters that registrar has 14 days to invalidate the TAC once it’s sent.

• Working Group members noted that the 24-hour language in 11.3 makes no sense and is confusing.  They agreed in last week’s discussion that no change is needed.
• 11 -- One Working Group member noted that privacy and proxy services are required to forward notifications to their customers so not sure why any change is needed.  Another thought the added language could be useful.  A representative from the registries wondered why the notification of TAC issuance would reference underlying customers but not other notifications, and deferred to registrars. The registrar reps   agreed if we were going to add the text it should be done for all notifications, but that it could cause definitional confusion and some registrars may not know who is the underlying customer.  Finally, another member noted that the RAA requires relaying this type of communication.  The group agrees that the text isn’t needed.
• The Working Group agreed that none of the suggested changes are necessary in 11, 11.1, or 11.3.

3. Discuss Recommendations 3, 12-24

Recommendation 13 – TAC as a one-time use

• New security enhancement for the transfer policy.
• Comments from some registrars suggesting to add language clarifying that testing the validity of the TAC should not violate one-time use.
• Staff suggested adding a parenthetical to the end of the recommendation which just points out that for the avoidance of doubt registrars may confirm the validity of the TAC prior to initiating the inter-register transfer. This confirmation or read-only verification of the TAC is exempt from the one-time use requirement.
• One registry rep noted that such verification is accounted for in RFC 9154. It doesn’t violate one-time use because the TAC showing up in an Info Command (such as for verification) is not considered use of the TAC.
• Another member suggested including the language for consistency.
• ACTION TO WORKING GROUP MEMBERS: Check the bracketed text to make sure it makes sense.

Recommendation 3 – Initial Transfer Restrictions:

• This recommendation was the subject of a lot of comments.
• Summary of comments:

1. This is no longer a necessary restriction since some of the concerns initially with credit card chargebacks and fraud can be resolved almost instantaneously in today's age.
2. Other commenters who oppose the restriction noted that there wasn't really evidence in the Working Group’s Initial Report as to why this restriction is warranted, and suggests that in the event the working group believes this should continue, or should remain, that there be more evidence or examples as to why the working group thinks this is necessary.
3. Some commenters understand the reasoning behind the restriction, but recommend shortening it from 30 days to 5 days.
4. The comment about days versus hours remains.
5. There were a couple of small nits with the language which were about prepositions.
6. There were comments about the initial registration date. There's a footnote there, that talks about that. This commenter notes rather than have the footnote, why not just put creation date and make it clear in the actual text.
7. And then there were some differing opinions about the next portion. So there was one commenter that noted that the second sentence of the recommendation should be moved to implementation guidance, whereas another commenter noted that the text in footnote 2 should be moved into the body of the recommendation and that footnotes are not authoritative.

• So again, some are in favor. Some are not. Some think it should be shortened. Some think that there needs to be more evidence. And then the actual construction of the recommendation in terms of what's a footnote and what's not, and what's implementation, guidance and what's not is kind of up for debate.
• Note what we did in the Yellow Box.
• One more caveat: When the group is looking at comments, it's important to consider new information rather than rehash debates. Some comments not are not new; it may be best to refer the commenters to the rationale.
• Working Group members did not take issue to the proposed “creation date” or hours revision, and discussed moving the footnote text into the recommendation itself.
• It was noted that other footnotes will also need to be looked at for inclusion in recommendation text to ensure they are normative and part of the recommendation(s).
• A Working Group member disagreed with the proposal to move the second sentence of the recommendation into Implementation Guidance, urging that for clarity the text should remain where it is and not for IRT interpretation.
• The Working Group members agreed to update to hours instead of calendar days, as well as the updates to “creation date”, and inclusion of the footnote in the recommendation text. The Working Group did not agree to proposal of moving text from the recommendation to implementation guidance.

Recommendation 14 – Maintenance of Records

• The Working Group received comments requesting clarity around record keeping, the “designated representative”, the types of records collected (specifically IP addresses), and concerns that pre-verifying the TAC conflicts with the TAC’s one-time use.
• Working Group members noted that the recommendation should need to specify what data registrars need to keep, just that they have to keep the records. There is no need to specify IP retention as a requirement.
• Some registrar customers use VPN, so IP addresses are not the only source of information to make legal decisions on. Still, there should be good record keeping.
• The Working Group reviewed section 1.2.2 of the ICANN Data Retention Specification, which includes IP addresses as part of the records. The recommendation text should make reference to this specification.
• The Working Group agreed to add “designated representative” and clarifying text around record keeping and the ICANN Data Retention Specification.

Recommendation 15 – Gaining Form of Authorization (FOA)

• The recommendation had one comment, supporting the elimination of the Gaining Registrar FOA, provided that the Losing Registrar FOA remains in place as a means to mitigate unauthorized transfers.
• The Working Group already recommends retaining the losing FOA obligations so this comment could be revisited if the Working Group decides to eliminate it.
• The Working Group had no further comments, suggesting the recommendation text remains fine as is.

Recommendation 16 – Registry Transmission of IANA ID to Losing Registrar

• Some registries use the IANA id in these transmissions, others do not.
• A comment had noted that the registries that use different Ids may need to implement an EPP extension to provide this information, which could require registries and registrars to work in the IETF to standardize the extension. The commenter was unclear if this recommendation requires providing the information via EPP, or if providing it offline would be an option.
• A Working Group member noted that this was intended to be via EPP, and it was known during discussions there was going to be an effect on registries who do not use IANA Ids.

• Another Working Group acknowledged that this is not a ccTLD environment and that registries use registrar IDs often. No change to this recommendation is needed. Registries working in the IANA world should be using the same registrar IDs.

• The Working Group agreed the recommendation text remains fine as is.

Recommendation 17 – Losing Form of Authorization (FOA)

• One comment suggested that the Losing FOA should be eliminated, as the additional security mechanisms (e.g. TAC and notifications make Losing FOA superfluous

• Other comments included moving recommendation text to the rationale, updating calendar days to hours, and adding “(if different)” regarding the language of the registration agreement
• The ‘In Construction’ draft text included textual updates suggested by commenters. Working Group members did not express concern about moving part of the recommendation text to the rationale, updating to hours, or adding “if different”
• There was a concern from one of the commenters that there should not be a mechanism within the Losing FOA to immediately approve a transfer. The registrant can contact its registrar if it wants to approve this transfer immediately, but it shouldn't be housed within this notification in case of fraud.
• The Working Group reviewed the proposed draft 17.5, and whether it should be added to address the commenter’s concern.
• One Working Group member noted that there is no requirement to send in approval. Most hijacking is done via compromise, so if an EPP key is being sent email why send the confirmation of transfer to same compromised email? If the purpose of this notice is to confirm, then it provides a bad actor the means to steal.
• ACTION TO WORKING GROUP MEMBERS: Think about this new 17.5 proposal and consider whether to include in the recommendation.

4. AOB