2022-11-10 Transfer Policy Review PDP WG Call
The call for the Transfer Policy Review PDP Working Group will take place on Thursday, 10 November 2022 at 16:00 UTC for 90 minutes.
For other places see: https://tinyurl.com/2tp9uacu
PROPOSED AGENDA
Roll Call & SOI updates
Welcome and Chair Updates
Continue Discussion of Notification of TAC Provision – Recommendation 3 (see Public Comment Review Tool and Working Document [docs.google.com])
Continue Discussion of Notification of Transfer Completion – Recommendation 4 (Public Comment Review Tool and Working Document [docs.google.com]), including the question for community input on Recommendation 4 (Public Comment Review Tooland Working Document [docs.google.com])
Begin Discussion on Recommendation 5 (Public Comment Review Tool and Working Document [docs.google.com]) and Recommendation 6 (Public Comment Review Tooland Working Document [docs.google.com])
AOB
BACKGROUND DOCUMENTS
Public Comment Review Tools for Recommendations 3, 4, 5, and 6 as well as the question for community input on Recommendation 4.
Public Comment Working Documents for Recommendations 3 [docs.google.com], and 4 [docs.google.com], 5 [docs.google.com], and 6 [docs.google.com] as well as the question for community input [docs.google.com] on Recommendation 4.
PARTICIPATION
Apologies: Theo Geurts (RrSG), Catherine Merdinger (RrSG), James Galvin (RySG), Prudence Malinki (RrSG), Berry Cobb (staff)
Alternates: Jothan Frakes (RrSG), Jody Kolker (RrSG), Beth Bacon (RySG), Rich Brown (RrSG)
RECORDINGS
Chat Transcript (see Zoom recording, chat tab)
GNSO transcripts are located on the GNSO Calendar
Notes/ Action Items
ACTION ITEMS/HOMEWORK:
Jothan Frakes, Jim Galvin, Jody Kolker, and Rick Wilhelm have volunteered to compile a list of attack vectors and how the recommendations solve for them, or where they are out of scope.
Recommendation 2:
2. Staff to write up the recommendation to keep the Losing FOA functionality with flexibility on terminology and format.
Recommendation 3:
3. (f) Proposed edit -- Staff to provide revised draft language to change to mandatory (“MUST”).
4. (g) Proposed Edit -- Staff to revise the language in the Working Document to change to “notification of TAC issuance” and WG to review/comment.
Recommendation 4:
5. (c) Proposed Edit -- Staff to revise the recommendation text to include “For the purposes of sending the notification, the Registrar of Record should use contact information as it was in the registration data at the time of the transfer request.”
6. (d) Proposed Edit -- Staff to provide draft language for the WG to consider.
7. (e) Proposed Edit -- Staff to revise as suggested in the proposed next step but also to confirm that this and similar language is consistent.
Recommendation 5:
8. (b) Proposed Edit -- Staff to revise the language in the Working Document as suggested in the potential next step.
Recommendation 6:
9. (a) Concern -- Staff to revise the language in the Working Document as suggested in the potential next step.
10. (b) Concern -- Staff to revise the language in the Working Document as suggested in the potential next step.
11. (c) Proposed Edit -- Staff to revise the language in the Working Document as suggested in the potential next step.
12. (d) Proposed Edit -- Registrars to discuss.
Recommendation 7:
13. WG members to review prior to next Tuesday’s meeting: See the Working Document Tool at: https://docs.google.com/document/d/1796UeXK6GspA7cehLcSn5tWiCyuR7JU7hOfKHgCSVz4/edit.
Notes:
Roll Call & SOI updates
2. Welcome and Chair Updates
Reminder that we have 10 more bi-weekly meetings to the end of the year with the goal to complete our review of the public comments.
Still working on the proposal relating to the Losing FOA based on our discussion during the call on 08 November – should have that to you to consider at the next meeting.
3. Continue Discussion of Notification of TAC Provision – Recommendation 3 (see Public Comment Review Tool and Working Document [docs.google.com])
Discussion:
A lot of registrars are doing this, but does it need to be mandatory.
Do we know if we have problems with email? Seems like a real disruption to a user’s experience.
The WG needs to decide – it’s in the RFC: sending the TAC in email is not a good security practice. That is the reason why the language is in RFC9154.
It might be an overstep to say that everyone has to change their systems because many are likely not sending via email already.
The comment in the proposed edit (e) does quote directly from RFC9154 – but the group would not necessarily have to adopt the suggested revised language.
This is someone related to the mechanism currently known as the “Losing FOA” – if you lose control of your email and the TAC the registrant has a way of denying a transfer. These security mechanisms are interrelated/interdependent.
Policy can’t solve for accounts being compromised.
The WG is not agreed that this should be a mandatory requirement.
Discussion:
The purpose of the comment was because the Losing FOA is communicating in the primary language as a standard and this would make it mandatory (a “MUST”).
This is a comment from John Poole.
Seems to be an easy small change so changing to a “MUST” would make sense.
ACTION ITEM: Recommendation 3, (f) Proposed edit -- Staff to provide revised draft language to change to mandatory (“MUST”).
Discussion:
Seems to be addressed by previous/earlier recommendation (edit under (c)). See: “Implementation Note: For the purposes of sending the notification, the Registrar of Record should use contact information as it was in the registration data at the time of the TAC request.”
Should we use a different word than “provision” in the notification? “Provision” is the technical creating and there is a small delay between “provision” and “providing”.
Could be “Notification of TAC issuance”? WG agrees at least provisionally – make the change and review.
ACTION ITEM: Recommendation 3, (g) Proposed Edit -- Staff to revise the language in the Working Document to change to “notification of TAC issuance” and WG to review/comment.
Discussion:
Seems to make sense, but depends on the method of “issuance”.
Think we already have language that talks about consolidation so not sure if we have to add anything.
WG agrees not to modify the language of the recommendation because there is existing language elsewhere that envisions consolidation.
Discussion:
The WG did consider better security mechanisms.
The thinking at the time of the comment is to leave the security protocols to registrars, there is the option to provide implementation guidance to registrars so they have best practices that they can add to their baseline protocols. Even if the WG doesn’t mandate these things, they could be helpful for registrars to know them.
It may be out of scope for the policy, but worthwhile including as guidance.
4. Continue Discussion of Notification of Transfer Completion – Recommendation 4 (Public Comment Review Tooland Working Document [docs.google.com]), including the question for community input on Recommendation 4 (Public Comment Review Tooland Working Document [docs.google.com])
Discussion:
Already addressed in Recommendation #3 10-minute standard.
Discussion:
Already addressed in previous discussions.
Discussion:
Strawman doesn’t change the intent – it’s not optional, but need to provide rationale.
Don’t think the language needs to be stricken.
Could we take out the stricken language and instead add the first sentence of the Implementation Note to the recommendation.
ACTION ITEM: Recommendation 4, (c) Proposed Edit -- Staff to revise the recommendation text to include “For the purposes of sending the notification, the Registrar of Record should use contact information as it was in the registration data at the time of the transfer request.”
Discussion:
Seems reasonable, but need to see it in writing.
ACTION ITEM: Recommendation 4, (d) Proposed Edit -- Staff to provide draft language for the WG to consider.
Discussion:
WG agrees but staff should ensure that this and all similar language is consistent.
ACTION ITEM: Recommendation 4, (e) Proposed Edit -- Staff to revise as suggested in the proposed next step but also to confirm that this and similar language is consistent.
Note re: Additional Considerations (f) and (g) – save for Phase 2.
Discussion:
WG agrees, but registries should consider and provide input – confirm on the next call.
Registries did provide the following comment: “Registry Operators acknowledge the security benefit of notifying a RNH both of a completed transfer and of the identity of the Gaining Registrar. This notification provides a confirmation to the RNH that the desired action was completed as requested. Further, Registry Operators understand that in order to achieve this it will be incumbent of Registry Operators to provide this information to the Losing Registrar via EPP upon completion of the transfer as the Losing Registrar would not otherwise have access to this information.”
5. Begin Discussion on Recommendation 5 (Public Comment Review Tooland Working Document [docs.google.com]) and Recommendation 6 (Public Comment Review Tool and Working Document [docs.google.com])
Recommendation 5:
Discussion:
WG agrees with the proposed strawman revision.
ACTION ITEM: Recommendation 5, (b) Proposed Edit -- Staff to revise the language in the Working Document as suggested in the potential next step.
Recommendation 6:
Discussion:
The WG agrees with the suggested potential next step.
ACTION ITEM: Recommendation 6, (a) Concern -- Staff to revise the language in the Working Document as suggested in the potential next step.
Discussion:
WG agrees with the suggested potential next step.
ACTION ITEM: Recommendation 6, (b) Concern -- Staff to revise the language in the Working Document as suggested in the potential next step.
Discussion:
This makes it clear that the “Designated representative” is authorized to request the TAC.
WG agrees with the suggested potential next step.
ACTION ITEM: Recommendation 6, (c) Proposed Edit -- Staff to revise the language in the Working Document as suggested in the potential next step.
Discussion:
Suggestion is to make this a recommendation as opposed to just a footnote.
Concern is that we haven’t fully defined what “Designated representative” means. Has it been defined in other ICANN policies?
Staff notes that “Designated Agent” is defined elsewhere, but not “Designated Representative”. This is different from the “Designated Agent”.
From the Transfer Policy: "Designated Agent" means an individual or entity that the Prior Registrant or New Registrant explicitly authorizes to approve a Change of Registrant on its behalf.
We are acknowledging that in some cases “Designated Representatives” exist and they can obtain the TAC.
ACTION ITEM: Recommendation 6, (d) Proposed Edit -- Registrars to discuss.
Recommendation 7:
ACTION ITEM: Recommendation 7 -- WG members to review prior to next Tuesday’s meeting: See the Working Document Tool at https://docs.google.com/document/d/1796UeXK6GspA7cehLcSn5tWiCyuR7JU7hOfKHgCSVz4/edit.
6. AOB