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

38:37
Definitions document here: https://docs.google.com/document/d/1CYOruGqewTsu5ejL_zoom0ol6VA1xMLX2FXW2VAy4eI/edit

41:56
sorry for the delay, I had some problems with password

43:16
Jeff, you sound okay to me

43:19
I hear you ok Jeff

45:08
Brands

47:48
@A.A-S. I have just said that the status quo has to be changed for non AGB geo-names.

48:58
What closed generic policy Kathy?

49:08
For me, status quo is AGB 2012. However, I am sure that is different for the different issues.

49:34
And haven't you been arguing throughout that closed generics were always prohibited? So, it's good to see you now accept that is not correct

50:00
Hello all , sorry for being late

50:20
+ 1 Greg

50:34
@Susan, disagree and will leave it at that.

50:37
I don't agree with Kathy that the negotiations over the contracts for .brand registries was "policy." That said, do we need to reach this issue in order to approve this document today?

51:03
The note is that was far more than "implementation" between AGB and delegrations.

52:42
I disagree that we have to get through this document without providing examples. Definitional documents are extremely important.

54:08
It's important in part because we are reviewing "can't live with" language.

55:58
Sorry I'm late folks. What did I miss?

56:12
It was an IG

57:22
@Donna - we solved Closed Generics, Auctions, and the SPIRT with 100% agreement. :)

01:00:10
Agree with Anne. "hopefully" isn't explicit enough.

01:00:25
+1 Anne - that makes sense

01:03:18
@Jeff - for auctions would it be "no agreement for changes to the status quo" (unless we get agreement)?

01:04:33
+1 Justine

01:04:38
@Jeff - I withdraw the question. I see the default back to status quo is the the No Agreement section

01:04:54
Thanks Jeff

01:05:26
Production document here: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQLuQuo/edit?usp=sharing

01:07:29
I'd prefer should.

01:07:44
I prefer should

01:07:49
I still it should be a must

01:07:51
I also prefer “should” especially given the definitions

01:09:58
I think the recommendation and IG work well together

01:10:08
for this example

01:10:58
Can I have some time to revisit the rationale for this IG please?

01:12:47
What does it mean?

01:14:41
So, it means that the application comments collected are not part of the overall communications plan and will be handled elsehwhere?

01:14:53
Should it be: the impaction of comments made on applications collected through ....

01:15:22
Yes

01:16:36
Thanks Donna and Justine

01:16:58
Steve :)

01:17:34
Kudos to Julie, Steve and Emily for their invisible contributions

01:18:02
FYI, we are in the section on Systems

01:20:14
Empty answer is equal to another empty

01:20:32
Agree

01:20:41
@autofill : insofar as these provisions are designed to facilitate multiple portfolio applications I would be opposed, until the PDP has agreed LIMITS on the number of applications from the same entity.

01:20:47
lots of TLDs do not have anything added

01:21:21
@Cristopher, then we see lots of entities, not necessary affiliated in the begining

01:21:31
but merged later

01:21:53
it is not a bog deal to create another organization/company

01:22:00
*big

01:22:16
I have the same basic proposal

01:22:48
please don’t make it painful to add text to the application.

01:22:48
@Anne - but what does that have to do with auto-fill??

01:23:07
all RSEP go through the public process

01:23:37
is out task to make life of an applicant as complex as possible?

01:24:13
“curse you subpro!”

01:24:27
hand up

01:24:27
We are really talking about data entry convenience here, right? If so, I think we can just agree with Anne and move on.

01:25:38
we do not need to make life worse just because we think it is too simple

01:25:58
@Paul - we could, but really why do we have to make this so complicated for applicanyts because 2 people think this?

01:26:09
Autofill is different from copy & paste right?

01:26:45
isn't copy & paste a hardware function? Or, am I really stupid? (please be kind)

01:27:18
it is software level, until you install a robot behind the keyboard or API

01:28:08
if PIC is empty - then it is autofilled by definition

01:29:04
WHY !?!

01:29:21
why are we trying to police applicant submissions

01:29:23
new hand

01:30:09
It's a good question Elaine.

01:30:19
Thanks Maxim. So, I don't get it. How is it helpful to force manually typing something in?

01:30:28
@Elaine - it started out as a simple process improvement……

01:30:36
more labour = more paid hours, it helps economy

01:30:44
@Elaine - quite. Because some people think you shouldn't apply for more than one TLD and so they want hurdles

01:31:09
but adds lots of mistakes to the text, so the panelists have more things to do the same time

01:32:09
lack of autofill is highly unlikely to act as a deterrent to any applicant

01:32:11
So, if we are talking about banning block & copy (rather than just making pull-down-auto-fill unavailable for that section, I don't see how that makes sense.

01:32:30
copy and paste should not be forbidden

01:32:39
+1 Paul/Maxim

01:33:08
Right. So do we really NEED this autofill improvement at all?

01:33:09
Mandatory PICs

01:33:32
Good point, Maxim. If not Voluntary PICs, empty

01:33:37
I don't believe we do Justine

01:35:17
then reference to formerly called voluntary is not quite right

01:36:35
I didn't understand @Maxim

01:36:36
is adding random articles a, the counts as making a text ‘different’? if so - then we will have this

01:37:12
at $185k no one was ‘not’ thinking about what they put in the form

01:37:24
system was horrible - we had to use PDF (not editable) to use as a source from where text was copied bit by bit

01:37:25
I think we are there...

01:37:34
+1 Elaine

01:37:48
nobody needs live typing when the text is prepared in advance

01:38:38
agreed

01:38:52
even if paste function if forbidden it will be walked around by type bots emulating persons

01:40:04
fine,thanks

01:40:54
This autofill improvement really only helps applicants who intend to submit many applications, which seems to be to be favouring those kinds of applicants. So I sitll don't understand why we need this. Oh well ..

01:41:21
NOTE TO STAFF: RE Question 23, we also need a better definition of "additional services", ie "other than basic pre-approved services"

01:41:55
Thanks Anne. noted

01:46:19
OK

01:47:44
Who added this text?

01:49:10
+1 Jeff. This text would make applicants the funders of ICANN operations not just the funders of the new applicant program...

01:50:05
what on earth have the costs of the EPDP got to do with new gTLDs?

01:50:33
why is historical costs included ? they are now written off .

01:50:55
EPDP is cost of business , it is due to GDPR

01:52:09
Agree Jeff - ongoing operating fees cover BAU

01:52:11
this is wrong terminology .

01:52:30
No it wasn't.

01:52:41
after application - it is a Registry and ICANN invoices those

01:52:50
The reserve funds were used for IANA Transition.

01:52:57
No - funds were withdrawn for other reasons!

01:53:02
+1Donna

01:53:20
There is still excess funds from 2012 sitting in a separate ICANN account.

01:53:58
+1 Donna

01:54:06
everyone else is saying in chat so taken my hand down - auction proceeds were plundered for IANA transition. EPDP is due to change in legislation and nothing to do with the new gTLD program.

01:55:10
The EPDP and the CCWG on Auction Proceeds is being funding through the fees being collected by ICANN from contracted parties

01:56:30
ongoing

01:59:35
Angélique texts: ICANN benefits enormously from the value of unaccounted voluntary contributions of time. E.g. this PDP: These distinctions among different categories of costs are quite fungible.

02:01:20
the fee floor will need to be readjusted in the start of each round

02:01:52
Donna proposed a new IG

02:02:22
Agree - good addition from Donna

02:02:29
+1

02:02:30
@ Phil, I don't agree with your statement.

02:02:41
@Donna, +1

02:02:58
At some juncture we should have a discussion about how the costs of Application Support will be financed.

02:06:23
no

02:06:39
objection

02:06:55
Thanks

02:07:04
Must OK

02:07:12
yes I ll be put more on chat

02:08:24
bye all

02:09:09
Monday at....the appointed time

02:09:14
Tuesday 02 June at 03:00 UTC

02:09:14
Tuesday, 02 June at 0300 UTC

02:09:25
Bye All

02:09:26
Lots of good progress today team, thanks everyone! Bye for now...