2023-11-07 Transfer Policy Review PDP WG Call

Notes/ Action Items

 ACTION ITEMS/HOMEWORK:

1.  WG to review the Working Document “Changes to Bulk Transfer Recs following 3,10, 21 Oct 2023 Call” at https://docs.google.com/document/d/1_T41SQAH3duIPS9qhYE71iM5CAxpA3KUpgy55DK3Y3k/edit?usp=sharing to confirm that the revisions based on the 21 October discussion are accurately reflected.
2. WG members to review the Swimlane to make sure it is accurate (see attached).
3. IANA ID (slide 24) – Staff to reference the text in the report but WG members should note if Implementation Guidance is needed.
4. a) With respect to syntax requirement (slide 30) – not sure registries can verify.  Rick Wilhelm to check. b) Staff to review the discussions.
5. WG members to review the following materials before the next call if you have not already done so:

• The recording from the 17 January WG meeting [icann.zoom.us], where Berry presented the swim lane diagram
• an updated swim lane diagram (attached), which shows how the recommendations interrelate (attached)
• a slide deck (attached – starting at slide 44).

Notes:

1. Welcome and Chair updates

• Chair updates: Short recap from ICANN78 – we made some good progress, closing out our work on our ICANN bulk transfer discussions. The group agreed to some minor nits in the bulk transfer recommendations. We will have an action item for the WG to review the highlighted changes from ICANN78 to ensure staff captured those correctly. Staff went ahead and made updates to the working document and highlighted those so that it's clear to see what changed since the last time that we reviewed the recommendations.
• So when we circulate the action items for today's call, it's just a reminder to make sure that what staff changed in the recommendations is what the Working Group had in mind, and things were captured correctly. But we'll make sure to circulate that in the action item.

ACTION ITEM: WG to review the Working Document “Changes to Bulk Transfer Recs following 3,10, 21 Oct 2023 Call” at https://docs.google.com/document/d/1_T41SQAH3duIPS9qhYE71iM5CAxpA3KUpgy55DK3Y3k/edit?usp=sharing to confirm that the revisions based on the 21 October discussion are accurately reflected.

1. Recap of work to date: where are we now?

• Group 1(a) recommendations
• Swimlane Overview -- see attached document:

ACTION ITEM: WG members to review the Swimlane to make sure it is accurate (see attached).

Where we landed after the public comment -- see attached slides:

• Overview of FOA recommendations – start at slide 23

ACTON ITEM: IANA ID (slide 24) – Staff to reference the text in the report but WG members should note if Implementation Guidance is needed.

• Overview of Auth Codes/TAC recommendations – start at slide 28

ACTION ITEMS: 1) With respect to syntax requirement (slide 30) – not sure registries can verify.  Rick Wilhelm to check. 2) Staff to review the discussions.

• Overview of Wave 1 recommendations – start at slide 35
• Overview of NACK-ing recommendations – start at slide 37

• Note that slide 43 has a list of resources including an updated Initial Report following the public comment review at: https://drive.google.com/file/d/10arRg9YLpNQCJbSbsWETs3FBeqTthRSl/view?usp=sharing. WG members are encouraged to review the documents.

• Group 1(b) deliberations refresher – start at slide 44
• Change of Registrant

• Question: So a change of registrant could be initiated and the notification is sent to the existing registrant. In 24 hours, regardless of what they do, that change is going to take into effect, not giving people enough time really to respond and say my account with my registrar has been compromised. Is there some other process where there protections against this?
• The problem is that we have so many different business models, and if you want to protect the account of a registrant we first must acknowledge that there is a large portion of the registrars who have no control over registered accounts.  When you start messing with this change of registrant language you are delving into a technical minefield which hits on huge operational issues. So we decided maybe we should send notifications. Tone the policy down. So this is sort of a very tricky policy that we are going to deliberate on.
• I think it is very important to keep in mind that this does create operational issues, and we really don't want to put a barrier to updating registration data, especially if that is inaccurate personal data. We want people to be able to update that as easily as possible. So I I'm definitely still in support of the text on screen, with a notification rather than a confirmation process. To the question of whether 24 h is long enough I think I want to compare that to the previous or the current core process that's live right now, which is to process it within one day. And so I think we're not actually changing that we're just making it more specific -- 24 hours. I think that that is enough notification, because, if the change is unexpected to the registrant, that generally means that there's a problem somewhere else, like maybe their account was compromised, and that's what needs to be addressed. There should be other processes in place to handle account security.
• Question: What is the general approach we will take to developing CoR recommendations?  Answer: Staff will formulate a plan to share with the WG for input.
• Suggestion to look back on the original recommendations on CoR to get some history/context.
• Meeting on the 14^th and then taking the 21^st off.  Will send calendar notifications leading up to ICANN79.

ACTION ITEM: WG members to review the following materials before the next call if you have not already done so:

• The recording from the 17 January WG meeting [icann.zoom.us], where Berry presented the swim lane diagram
• an updated swim lane diagram (attached), which shows how the recommendations interrelate (attached)
• a slide deck (attached – starting at slide 44).