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

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.

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.

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.)

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

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?

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

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

Thanks Emily, that's helpful

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

@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?

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

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.

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

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

(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)

ok!

Thanks for this, Sarah. Helpful clarification.

Thank you Emily!

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

3 years next week! Yeppers

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

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

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

I definitely agree that complaints to ICANN Compliance is a helpful metric

If there is any data

ANd probably that transfer status report that Emily mentioned earlier has info we must consider

I would size this as small to medium

Thanks Sarah. A simple High, Medium, Low reaction will help.

Low will be fine

Low

I think for the future calls, staff will investigate using the zoom polling function.

Good idea Berry!

The metrics are needed to backup the discussion. ICAAN Compliance could be having some metrics

Daniel I agree, we should be able to justify any decision we make

Interesting point Kristian. I was not aware that the gaining FOA predated AuthInfo code

Richard +1

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

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

Definitely still required

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

agreed

+1 Sarah

+1 Owen

+1 to keeping, but should review the implementation

agreed, that goes under "are updates necessary"

so maybe this should be Medium instead

naee

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

happy to rename it yes

That sounds reasonable to me

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

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

Absolutely!

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

Daniel, we should make sure that's not possible moving forward

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

There are many reasons as to why a domain may be transferred

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

but will be a good discussion point

Zak has his hand up

+1 Zak

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

yes

+1 Roger

+1 Jim

+1 Ji,

+1 Jim

+1 Roger

curious why one of them is 60min instead of 90

thank you :D

ooh that sounds interesting! OK

I thought we were shooting 90 minutes

That is a very good idea

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

Thanks, all!

Thanks all