
39:20
Please review ICANN Expected Standards of Behavior here: https://www.icann.org/resources/pages/expected-standards-2016-06-28-en

39:27
Reminders:**Members: when using chat, please select Panelists and Attendees in order for everyone to see chat.**Alternates not replacing a member are not permitted to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing.

44:54
Do we have any metrics related to the current transfer policy, and do we have any targets for what sort of improvement in the metrics we’re aiming for? I’ll suggest a couple of metrics that occur to me, but others here are much closer to the actual facts than I am.

47:00
There are generically two sorts of errors that can occur when a transfer is requested. One is failure to complete a legitimate transfer. The other is the success of an illegitimate transfer. These are often called false negatives and false positives, respectively. (And in statistics literature, these are also called Type I and Type II errors.)

47:21
Hi Steve, the major source of metrics we will be drawing on is the Transfer Policy Status Report: https://www.icann.org/uploads/ckeditor/IRTPPSRRevised_GNSO_Final.pdf

48:16
Has there been any form of reporting on how many of each types of errors have been occurring? Has there been heartburn about these statistics, or have these not been a problem?

48:17
Although the Working Group may identify if additional data is needed to support its work.

49:11
The Final Issue Report points to the relevant metrics in the Status Report for each topic

49:20
Thanks Emily, that's helpful

49:39
A separate issue is the cost of transfers, where “cost” includes time delays, workload on the registrars, cost to the registrants, etc.

50:33
@Steve- while those are valid items to consider, that is outside of our current scope. Can we raise those concerns later rather than distracting from our current discussion?

51:04
It’s interesting in this environment that the cost issue and the errors are intertwined.

52:00
For false negatives, i.e. failure to complete a legitimate transfer, the result is a delay. The transfer can be attempted again, and presumably will eventually succeed.

52:46
So here’s the punchline: The 60 day delay is sort of like an imposed series of refused legitimate transfers.

01:05:46
I feel like saying "to identify the registrant" could be confusing to unfamiliar readers. But the key analogy is great.

01:06:04
(it doesn't identify who the registrant is; it sort of lets a person verify that they have authority or that they are the registrant bc only the registrant should be able to access it)

01:12:16
ok!

01:12:21
Thanks for this, Sarah. Helpful clarification.

01:12:32
Thank you Emily!

01:13:04
The link to the footnote 1 in the charter is missing (page 4), could someone put the link in the chat?

01:14:32
3 years next week! Yeppers

01:15:01
Reminder to all: Please select PANELISTS AND ATTENDEES so everyone can see your chat.

01:15:10
Sorry about that Sarah. Here is the link: https://mm.icann.org/pipermail/council/attachments/20200219/94112f0f/Rec27-Wave1-Updated-14feb20-0001.pdf

01:16:37
SO it will be good for this team to document what data we are relying on for this decision, yes

01:16:46
I definitely agree that complaints to ICANN Compliance is a helpful metric

01:16:54
If there is any data

01:17:12
ANd probably that transfer status report that Emily mentioned earlier has info we must consider

01:17:40
I would size this as small to medium

01:18:15
Thanks Sarah. A simple High, Medium, Low reaction will help.

01:18:26
Low will be fine

01:18:37
Low

01:18:48
I think for the future calls, staff will investigate using the zoom polling function.

01:18:55
Good idea Berry!

01:18:57
The metrics are needed to backup the discussion. ICAAN Compliance could be having some metrics

01:19:09
Daniel I agree, we should be able to justify any decision we make

01:19:11
Interesting point Kristian. I was not aware that the gaining FOA predated AuthInfo code

01:19:32
Richard +1

01:19:41
I would say it increases to medium if we discover that we lack data on which to base any decision

01:19:51
because then we need to get some data. but I do think it exists & is available to us

01:22:45
Definitely still required

01:23:50
I think because we have the TechOps proposal that's done a lot of the work for us! So we can scope this as Low because we have a good chunk of work done already

01:24:04
agreed

01:24:14
+1 Sarah

01:25:59
+1 Owen

01:26:04
+1 to keeping, but should review the implementation

01:26:16
agreed, that goes under "are updates necessary"

01:26:21
so maybe this should be Medium instead

01:26:33
naee

01:26:52
I think we do keep losing FOA (but rename) and then make some edits. It’s a good paper trail.

01:27:01
happy to rename it yes

01:28:02
That sounds reasonable to me

01:28:10
I think we already have this data, we just need to make sure to look at it

01:29:28
Yeah I do think so, the authcode is the most important part of the transfer approval. Maybe this goes under the next topic, though?

01:29:50
Absolutely!

01:33:40
@Sarah, some registrars make it had to get the authcode - and this hinders transfers

01:33:53
Daniel, we should make sure that's not possible moving forward

01:34:52
Yes, the authcode should be available with ease whenever there is need to transfer the domain.

01:35:10
There are many reasons as to why a domain may be transferred

01:38:04
As for opt-in, not using an optional "feature" very often doesn't mean it isn't an essential option...

01:38:39
but will be a good discussion point

01:39:56
Zak has his hand up

01:42:39
+1 Zak

01:45:54
I think the TechOps paper had a lot of input on this one also, right?

01:46:23
yes

01:49:22
+1 Roger

01:55:06
+1 Jim

01:55:13
+1 Ji,

01:55:29
+1 Jim

01:56:05
+1 Roger

01:57:09
curious why one of them is 60min instead of 90

01:57:17
thank you :D

01:57:37
ooh that sounds interesting! OK

01:58:30
I thought we were shooting 90 minutes

01:59:00
That is a very good idea

01:59:06
All standard calls will be 90 min. Just the one will be 60 to not collide with the policy webinar.

01:59:16
Thanks, all!

01:59:21
Thanks all