Link to the document we are currently viewing: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit

Yes thx

@Jeff, when would third party service providers be selected?

Such as DRP

CPE

Steve is at SPS

:)

But I can answer

SOIs for SPIRT have to be separately published at that site.

Global support didn't exist in 2012, but yes I believe the current ones are likely to fulfil the WG suggestion.

(Current SLAs)

Tha'ts because SOIs for SPIRT much be must be more detailed than regular ICANN SOIs.

@staff - I can't seem to get a hard copy of the document with all the mark-ups to print. Is there a trick to making that happen?

@Anne, if you download a WORD version, the markups should be there.

Thanks, Alan. @Anne, that would be my advice as well.

@Anne: Convert to Word or PDF and then print.

Oops, ditto :-)

Downloading as Word includes the markups, as PDF removes them

Good day All, sorry for being late.

PIRR recommendation 8.5.a,: "Consider customer service to be a critical function of the organization, and ensure that the Customer Service Center has the appropriate resources to support the ongoing and future activities of the New gTLD Program."

You could simply say you support it

or agree

I think it helps the document by referring to PIRR recommendations

agree @jim

Note that PIRR is somewhat biased towards show how cool ICANN Org is, so sometimes you might want to stay away to criticise the 2012 implementation.

sorry i joined late, is it possible to have the link to the document provided in chat please?

But in a number of times PIRR pointed to things that indeed should be supported by the WG.

https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit

Thanks Emily

Sure thing

@Rubens - Agree In not doing a wholesale endorsement but in that case it works.

Just a consistency of language issue: is there a difference between the generally agreed and wide agreement? I think it would be helpful, if there is no difference, that we maintain consistent language.

Donna, there isn’t a difference. We can adjust to make it consistent.

Does the group have a preference?

I like "wide agreement", but that's just me.

No preference, just so long as its consistent.

We may actually want to go back and do this streamlining at the end

On restating affirmation, not repeating is fine, and insert page number where the affirmation can be found.

as we are drafting the sections out of chronological order

good point

agree that streamling at the end makes sense

sorry my zoom dropped... back now

nightmarish to use

Basically, making ICANN Org follow UASG recommendations

+1 Rubens

+1 Rubens.

Have ICANN Org support UA & EAI

Changes by any authorised user.

i.e. payment receipt

Also user registration prior to any submission?

automated invoices - may be automated account

good practice

Usually when you get an automated response, you get that every time something happens with that application, every change

Most of the times upload wasn't allowed.

thanks for the clarification

agreed Rubens , especially financial info / documents

Jeff, what are the titles of the sections you just read off as numbers?

23 - Registry Services

@Jeff, are we sure the questions will keep the same #s?4

numbers?

The questions may have different numbers, so we should specificity these are AGB 2012 questions.

keep it simple and not allow auto fill at all ?

Could someone remind me where does PICs come in in the application system?

PICs were treated by the case-system, not by the application system.

This recommendation shows that we are "inviting" portfolio applicants. Do we?

I imagine this will change in the next round.

I would say non-auto fill for PICs.

@Justine, I agree

Alexander, this text was discussed many times in order to avoid that.

non-auto-fill for Question 18 and Question 23 and agree with Justine - no autofill for voluntary PICs.

Ok .....

do we need to create a new section for PICs ? . I agree Justine

Perhaps just add Voluntary PICs to this sentence.

23 asks for all proposed services - some may not be standard

Need to add 22?

I wouldn’t have any auto fill , because each application needs to be stand alone from an evaluation point of view

16?

If anyone ever wanted to spot implementation details being developed during the policy phase, here it is. :)

Paul - Our charter is all about us doing implementation

16. Describe the applicant's efforts to ensure that there are no known operational or rendering problems concerning the applied-for gTLD string. If such issues are known, describe steps that will be taken to mitigate these issues in software and other applications.

There is no sensible reason to not allow auto fill.

thanks Jeff . point(s) understood and accepted

16, for ASCII TLDs this answer is always the same.

It might change a bit in IDN TLDs.

On geo names, it seems the applicant country of incorporation would depend on what the authorizing authority agrees to approve.

What kind of genomes are you talking about here, Anne?

Auto-fill is a possibility, not an obligation. Every one that wants to taylor each question can do it.

Agree Rubens

yes it is the option to autofill

@Rubens, the encouragement is to tell the public as much as possible

Where are these numbers? 22.23 etc.

Question 16 made very little sense for ASCII TLDs.

except for that whole universal acceptance thing...

new hand

I also recall discussion (or at least concern) on the cost of implementing auto-fill for some fields and not others. Although personally I didn't think cost would be prohibitive.

Auto-fill can also be used for directors, for instance.

I would proffer that UA should not *just* be an IDN thing however

Jeff, thus my smiling face

Personally, I think this is a nonsense discussion.

As Rubens mentioned, it is optional to autofill. They can all be scrutinised through public comment.

we can agree to disagree

The desired outcome should be to minimise multiple applications from incumbent applicants

Christopher, this was ruled out during discussion of program goals.

my comment was not regarding autofill option, rather where UA is considered in the AGB

I don’t think autofill is going to be a driver for multiple applications.

We can hear you

yes

yes

I don't think the lack of autofill is going to be a disincentive for multiple applications either.

The cost of hiring someone in Upwork to retype repetitive things is in the vicinity of USD 1/hour or less.

+1 Donna, it's a no-brainer to me too.

cut and paste is pretty cheap :-)

@ Rubens That would tend to facilitate increased dominance by incumbent large Registries/Registrars. Not advisable.

I think "associated with systems access" already specifies to which agreements this applies to.

@ CW, it's not my role to discuss that anymore, since that discussion is done.

So that would exclude need for an acknowledgment (check box?) of mandatory PIC obligations during application phase, well ahead of contracting phase? Don't have my finger on if or where mandatory PICs appear in AGB.

Justine, there were no PICs, neither mandatory or voluntary, in AGB. They were created to address GAC Advice.

Next Guidebook will have to cover PICs

Yes, Rubens, I'm talking about subsequent procedures.

indeed @Anne

Thanks everyone - sorry I have to drop early. Until the next call...Anne

https://www.icann.org/en/system/files/files/cybersecurity-transparency-guidelines-03aug18-en.pdf

Application fees will be contested ...

28 Jan 2020 at 0300 UTC

Next call is 28 Jan at 3:00 UTC

jinx LOL

:)

Let's agree that we pay nothing and Alexander pays USD 10 Million.

Bye all

Hahaha

thx, bye all

Bye all

Bye!

Bye everyone!