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

we had that yesterday in our hood.

in Zoom room now

hello all

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

Is jeff cutting out or is it my phone?

He sounds okay to me, Anne

sound ok for me

sounds fine Jeff

gremlins @Jeff

it is better to use ICANN accredited, to distinguish between Registry accredited

noted @Maxim

honestly I don't think the language in the sentence is unclear at all

Can you remind us of the rationale, Jeff?

not the intent at all!!

Yes - Jeff - it's a language problem. It IS unclear

Move the comma: Registries must use only ICANN accredited registrars in registering domain names, and may not discriminate among such accredited registrars unless an exemption to the Registry Code of Conduct is granted

+1 Susan

I like the public comment aspect

The problem is the very broad nature of "unless an exemption is granted"

yep public comment bit is fine

Agreed with public comment

so does @Susan have it right with the comma move?

Would need to know that Code of Conduct will not change, however

why does it matter if the code of conduct changes Anne, for these purposes? this is talking about having to have an exemption to it, for a particular circumstance

I think referring back to Code of Conduct process should be adequate. As Jeff said, there would need to be a process to undertake changes to the code of conduct

There are registrars who are accredited for ccTLDs but not ICANN accredited

but if brands do their own registrations they aren't really acting as a registrar, i.e. they aren't selling names to third parties so they aren't a source of discrimination

the code of conduct is in the RA

ICANN accredited registrars is covered in the text

The remaining issue is the new gTLD which fails to attract support from incumbent Registrars, and should be allowed to self Register names up dot a threshold of time or numbers. Otherwise incumbents can effectively resist the new entrants. No.

But other than Brands?

@Kathy - I am thinking about small new geo names.

E.g. non EN scriopts

OK, tx!

@Kathy - Code of Conduct exemption is a only a part of Spec 13 terms

Beijing Communique here: https://gac.icann.org/contentMigrated/icann46-beijing-communique

Illegible font on screen: Please revert to #18.

Document now being shared: https://www.icann.org/en/system/files/files/resolutions-new-gtld-annex-2-05feb14-en.pdf

Switzerland: Implementation Guidance xx (rationale 2) : GAC Advice on categories of applications should remain possible,where emerging issues and/or unexpected concerns arise regarding a category of applications.

agree with Paul

@Jeff - thank you for all of that factual background and answering the additional questions.

How can the dollar be a geographic term? Looks like at least 22 countries use it. https://www.google.com/search?q=how+many+countries+use+dollars&rlz=1C1CHBD_enUS848US848&oq=how+many+countries+use+dollars&aqs=chrome..69i57j0l7.7551j1j7&sourceid=chrome&ie=UTF-8

@ Paul: $ is not necessarily geographic,. But I

.USD is geographic. There are 200+ currency codes, only a few of which are ‘plural-country’.

I think there is a need to affirm this NGPC framework implementation in some logical way because they highlight public interest and safety concerns.

+1 Justine

How do we rationalise that with the conclusion we've already reached not to create more categories?

they were investigating where gala tickets went ;)

I like the word Justine used..."Framework".....we would be affirming the general framework

@Donna - when such? Additional categories will arise on the evidence of the applications.

+1 Jim

Yes @Jim...

No, we would be affirming the implementation

+1 @ Jim.

+1 Jim

can I come back?

The thought of categories was actually shot down very early in the process leading to AGB 2012. My personal view is that if there had been different rules for different categories

If we affirm implementation of this framework in some logical way then we can try and streamline the process of dealing with strings that might fall under this framework.

It seems like a subjective application of predictability.

..we might not have had some of the problems we have today

So do I @Jeff

I agree with Jeff on that

+1 Jeff

It will save time following the view of Jeff here, in my view

Who will the category that a string fits into?

It does not seem to me that we have any public comment on this topic.

I agree with Jeff, we may as well lt applicants know that this is going to be an issue for them - and we know it will be

sorry, who will determine the category that string fits into.

This is what happened in 2012, so it needs to be replicated mostly as is unless we agree to change.

I think that's a reasonable approach from Jim, but I'm still concerned about who makes the determination.

Donna, if we repeat 2012, GAC.

@Donna - predictability is key for ALL interested parties, not only the applicant. It. Is already inevitably subjective to a degree.

not it is sufficiently complicated ;]

thanks Jim

*no it is

its not conclucive - right -- applicant beware

So, do we leave it to the GAC again to call out certain strings??

Gg, yes unless we suggest someone else does it.

Religious category created issues and would be helpful for future applicants

.COVID

any list we develop will not be definitive.

We need to provide some predictability beyond "beware."

GAC list was not supposed by GAC to be definitive either, but ICANN simply followed them to the letter.

+1 Gg

I don't think Chrysler thought they would have an issue applying for .RAM for trucks and having it challenged on religious basis

Focus on decriptions and rationale for safeguards, and use examples from this list.

Based on this framework

And explain the process that follows if an applied-for string gets called out for treatment under this framework

We know from the 2012-round that the GAC is able to delay the process considerably if we do not listen to their advice.

@Annebeth, correct, so it makes further sense to try and affirm this somehow

The applicant reviewers would decide if the safeguards must apply.

We can also specify that getting categorised implies the same refund as getting GAC EW.

@Justine, at least for those who want that it should be possible to apply for new gTLDs as soon as possible. Governments have a lot of considerations the rest of us don’t have

Gg, there is no application evaluation on safeguards.

So we would need to specify a new evaluation type.

It's in there Jeff, 10.

@Rubens, I like the idea of new evaluation for safeguards

Global Warming is not governmental in US or Brazil.

PAUL - you promise to be quiet????!!!!

@Anne - ha!

@Jeff - you want to adopt these PICS to prevent conflicting advice that is MORE restrictive than the 2012 implementation?

I think we know that the GAC did not call these out as an exhaustive list, although that is how they were treated. The GAC intended this to cover any strings in the category types. We can't rule out that there might be other types in future, but we already know that these types are a problem from the GAC perspective and would lead to this type of advice again. I think we have to try to address it contractually up front

+1 @ Susan

I am repeating -Affirm framework by focusing on decriptions and rationale for safeguards, and use examples from this list.Based on this framework Then explain the process that follows if an applied-for string gets called out for treatment under this framework, including a "safeguard evaluation".

@Susan, does that mean that if you have 3 strings in contention and only one of the applicants agrees to abide by certain safeguards, does that mean that is the only applicant that can prevail?

Self declare to a type seems like an interesting add to what is being discussed now...

@Martin, that is an interesting suggestion

what if you don't self-declare?

Can self-declaration be gamed?

Then you get called out

@Donna, that would be why it's better not to leave it to the applicant to decide

So long as applicants can't just say, "no, this doesn't apply to me," when it actually does.

Interesting idea Martin.

It's pretty easy to warn the applicants as suggested by Jim, Paul, et al. Jeff suggests we may want to make a specific policy recommendation affirming the existing PICS in order to "head off at the pass" some more restrictive PICs than these.

who is reviewing?

The applicants should have the information about the categories in advance

+1 Annebeth

I think PICs already cover self-identification. If you include the PICs from 2012 categories from start, you basically identified yourself as that.

worst thing is to be stuck in limbo

+1 Maxim

Exactly, Jeffr!

@Jeff - I think we need a strawman to work with to get to our destination. Can we get that and take it up on the next call?

Perhaps calling out the advisory on this issue (as opposed to a "warning"

give warning. point to contract, GAC advice and Board resolutions in AGB.

I agree on that

Yes, but more importantly, the GAC clearly does.

I believe CCT-RT mentioned something towards that.

I thought I have stated yes

+1 Jim

Paul’s talking again……..

LOL

Do we point to the contract or do we say these are the contractual provisions that will apply

:-)

both

Pointing to the contract means its optional and the GAC could negotiate with the Board more stringent provisions

Paul, you should be quiet ;-)

Jeff is suggesting it is safer to say: "The WG affirms the categories and affirms the specific PICs".

It's fair to the 2012 registries to include similar PICs down the road.

+1 Anne and Rubens

Noted @Rubens

Yes! There are strings that deserve extra protections. I work on 3 of them. Would be nice to get into communications with GAC BEFORE we apply - to factor in their input.

we cant anticipate what the GAC does in the AGB. (unless of course we aske for final GAC advice prior to AGB being published but I've given up on that dream)

@Alexander, I agree

@Jim - it is a great dream though.

Indeed @Alexander I think we're getting something towards that

Or are likely to apply

what contractual provisions?

I would be HAPPY about pre-apllication feedback by GAC!

Yes.

@Jeff - let's just write it down and wordsmith it then

Being able yo consult with GAC pre-application would save everybody a LOT of trouble.

Tx!

It would be tricky to get GAC input ahead of application - no way to protect confidentiality of your business plan prior to disclosing.

We can say "including but not limited to"

Please...

10 mins in the call left

And - the representatives from governments are changing from year to year

My business plans are public - already now. These are public-benefit, non-profits: owned, funded & governed by communities.

we haven't heard back from Council on that letter, correct?

discussion continues in Council

Annabeth: the reps might change but the issues should remain.

DNS Abuse is not something that will be exclusive of 2022+ TLDs. So I don't see why doing something specific in SubPro.

Except .con, the 2022+ TLD for everything deceptive.

@Alexander, I agree. But we should be aware, anyway

It's hard to make "real changes" to an application AFTER submission.

im sure the GAC does but we will find out soon enough

Too bad because I think this Auspicious group could solve DNS abuse once and for all. :-)

hahahahha

Always the optimist Paul

2100+ TLDs then.

Applicant Support (multipliers at auction) page 6 in 2.1 Auctions: Mechanisms of Last Resort & 2.2 Private Resolution of Contention Sets (Including Private Auction) -- time permitting

why are we starting on this with 7 minutes left? this isn't simple

+1 Jim.

thanks

Public procurement frequently uses weighted evaluation, it's not hard to factor a multiplier.

^^^^ agree

So, for clarity, auctions are the subject of the next call?

Subway contracts in São Paulo.

@Jeff - thanks!

Larger discussion as in ICANN68?

Good progress again today, thanks everyone... More next week of course see note from Julie in chat above... Bye for now...

Really great call today Jeff. Thank you.

Thanks, a good call!

We will give more time for feedback n Package 5 though

Thanks, all!

Bye!

Next meeting: Monday, 08 June at 1500 UTC

bye all

Thanks all

Bye all!

bye all