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

Suggested language from Small Team 2: http://mm.icann.org/pipermail/gnso-rpm-wg/2020-September/004503.html

Paul McGrady leads that Small Team

Document Ariel is displaying: https://docs.google.com/document/d/12w5W2bQcviAqLwoDVB0vVK0n7SKj3fzP48NQyEW-1Q4/edit?usp=sharing

there should be safeguards for Geo tlds

is not having a domain discouraging? I think so

While this implementation language is helpful I agree with Maxim that Rec #2 is still largely vague

Maxim is raising the same old non-problem. No ICANN Compliance Department employee is going to issue a breach notice if someone saves a second level for the Police Department.

short response

Agree completely with Griffin.

That's even lower

Sorry, can't hear Jason.

@Maxim and all, please note that the text of the two bullet points in the Implementation Guidance is just examples.

much better

compliance reads language as is, not intentions of the WG

Further to my point, as was noted earlier, this is a high-level policy recommendation; the IRT will be tasked with implementing this recommendation and our guidance should be sufficient to allow the IRT to craft an appropriately tailored RA amendment and (hopefully a challenge mechanism with appropriate safeguards built in so as to not inhibit legitimate registry activities

@Maxim - correct. They won't think that saving a second level TLD for the police department is a circumvention.

ALP did not work, we do not know if it will next time, QLP is only 100 where an average capital {most geos last time) have hundreds of streets, monuments and pubic services

I agree (I think) with Jason insofar as implementing this recommendation may necessitate a third party challenge mechanism akin to the PDDRP or pICDRP so aggrieved TM owners can challenge a registry activity and there can be a ruling as to whether the activity is legitimate or not

(This is what small team was working on)

also I remind all of us, attempt to win over city authorities will lead to local law regulation and huge scandal in GAC

"... REASONABLE use". It's in the Rec.

QLP and ALP are nothing to do with this Maxim. You know perfectly well the type of behaviour we are trying to address

Perhaps we can just add a third bullet that says - registry activities that have a bona fide legitimate basis or rationale are explicitly not intended to be inhibited by this provision

to bullet point 1 -- adding: "without countervailing rationale and/or reasonable activity registries, including handling of dictionary terms.

Again, we all need to keep in mind that we are not crafting the actual contract language, that is the job of the IRT

No one would claim reserving police for the city police is anything other than reasonable.

As a staff suggestion for your consideration — perhaps we can include something to this effect: “The Working Group notes that this recommendation is not intended to preclude or restrict Registry operator’s legitimate business practice and pricing practice that are compliant with ICANN policies and procedures.”?

Agree with Marie - I think the rec on its face already provides the necessary circumscription (is that the right word)

to bullet point 1 (slightly revised)-- adding: "without countervailing rationale and/or reasonable activity by registries, including handling of dictionary terms.

With the word “reasonable” … but if others strongly feel we need to make the clarification more explicit, I can live with that

ICANN compliance just reads the contract and enforces the way they see fit, it is non negotiable

Which is generally hugely favorable to CPs

also price regulation is outside of the picket fence and non enforceable

But enforcing against circumvention of the RPMs through discriminatory practices is within the picket fence

@Griffin , I am not so sure - what we hear from compliance is demands not sugessions

and formal violations are enforced the way they see fit

And when was the last time of any severe penalty against a registry operating in good faith

Some of the vagueness could be cabined by reference to things that are ok, not just what's not ok. E.g., ALPs generally

ALP does not work yet

we do not know if it will

we can just say that this rec is not intended to inhibit legitimate registry activities that are specifically permitted by ICANN (this would cover all legitimate registry activities like the ones Maxim raises)

as Jason said, threading the needle

We discussed this ad naseum before in reaching consensus on rec 2

Ariel's wording above seems OK to me.

perhaps we can include something to this effect: “The Working Group notes that this recommendation is not intended to preclude or restrict Registry operator’s legitimate business practice that are compliant with ICANN policies and procedures.”?

Maxim, that's why my thought would be to suggest that it is a legitimate option

Repeating here for your reference

it was thought to be the way, but it did not work

+1 Ariel. Picket fence asked and answered

But is it reflected in the bullet point?

(new bullet point?)

seems like agreement on revision - how to proceed?

How would it be reflected in a bullet point? It is just summary discussion...

I think the pricing bullet point is mentioned in accordance with this sentence “While some Working Group members expressed concerns about the interplay of Registry pricing with RPMs obligations”

I think we discuss proposed amendment/addition to the bullet points on list - agree with Phil

Suggested language from Small Team 2: http://mm.icann.org/pipermail/gnso-rpm-wg/2020-September/004503.html

I don’t think adding “intentionally” in the rec helps us bc it doesn’t really address Maxim’s concern, bc reserving a name intentionally as part of an ALP or something is still intentional....

email I sent last night---

Not able to copy and paste...grrrr

We will display them on the screen

Personally, I support this language as a compromise but actually would suggest it explicitly instruct the IRT to develop a third-party challenge mechanism to address this activity, akin to the PDDRP or PICDRP in relation to the specific conduct that can be challenged via those mechanisms

link to Philip's email if that is easier to see https://mm.icann.org/pipermail/gnso-rpm-wg/2020-September/004506.html

Agree with how Paul has responded to the clarifying questions

@Phil - correct.

I think ICANN compliance would need to have a role, in a similar way it does in a PICDRP for instance; an independent panel would actually perform the substantive review and ICANN compliance would implement a panel finding, for example

panel can not replace arbitration

I am opposed to this suggestion (even if it is better than the previous one)

didn't an IRT create the URS, PDDRP, PICDRP, to name a few?

1. Clause could include a clause to include a challenge mechanism. 2. IRTs do this sort of thing all the time (e.g. the AGB and all of the challenge mechanisms with it).

Why isn't a complaint to ICANN compliance sufficient here? I agree with David that it's especially problematic to move from "vague standard applied by single decisionmaker" to "vague standard applied by various possible decisionmakers"

enforcement is about prohibition of violation of the contract, not about not following the ideas

@Rebecca - because in response to the complaints over the years on sunrise circumvention, ICANN has consistently said they could do nothing about it.

it is literally the language of a contract following

@Paul, circumvention itself is not defined, so can not be enforced

Apologies, I have to drop off the call now.

good point about ephemeral nature of sunrise

there are sunrise drps

Marie, the "could do nothing about it" doesn't mean "pick someone else"--if Rec 2 is "start doing something about it" then why isn't ICANN compliance the appropriate place?

if parties come to ICANN compliance asking for something not contrary to the contract, it should lead nowhere

UDRP actually 'started' at US Dept of Commerce in their white paper if I recall correctly

If we specifically instruct the IRT to create a challenge mechanism then they have the ability to do that

Full stop

STI was an an IRT

STI was not an IRT

+1 Paul

disagree Paul -

STI like EPDP

@Kathy - your view. You and I were both on the STI and it was not run anything like a PDP.

I think you meant to tag Paul, not me, Rebecca?

@Phil - can we have clarity? What is the decision? Is this moving forward or not? Thanks!

It seems to me there is general agreement on the Rec but we may not some clarification in terms of implementation guidance, which is what we are working on

*may need some

And frankly I am a bit puzzled about the apparent opposition to a challenge mechanism if there is general agreement about the rec - to me it is no different than the PICDRP or PDDRP as challenge mechanisms that are implicit and helpful in Spec 7 and Spec 11 of the RA

Thanks Phil!

the language is too vague

Too vague for what? I don’t think it’s too vague for a policy recommendation

Especially with the further implementation guidance we are craftig

there is no agreement on that

see: http://mm.icann.org/pipermail/gnso-rpm-wg/2020-September/004505.html

Agree w/ Griffin. There's a large degree of agmt here.

I mean… it already went out as a WG recommendation....

So clearly we already determined that it had sufficient "consensus”

not the current language

The current language as in the add’l guidance?

I didn't mean that everyone agrees (which would be miraculos on most any issue we discuss), rather that most agree.

@Paul T. - apologies if you already states this (I stepped away). What was the support level from the small group on this?

hand up

@Paul T. - Also, has Staff opined on whether or not this proposal is implementable?

hand up again

ALPs were handled poorly last time

I think so, it is directly related to RPMs

it is part of RPMs

TMCH RPMs Requirements document that is incorporated by reference into the AGB and the RA (http://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirements-14may14-en.pdf). 4.5 deals with Launch Programs, specifically 4.5.2:Registry Operator MAY, prior to the start date of its Sunrise Period, apply to ICANN for approval to conduct a registration program not otherwise permitted by these TMCH Requirements. Such a registration program application could, for example, provide for authorization to implement programs set forth in Registry Operator’s application for the TLD, which, if set forth in reasonable detail in the application for the TLD, will carry a presumption of being approved, unless ICANN reasonably determines that such requested registration program could contribute to consumer confusion or the infringement of intellectual property rights. If Registry Operator seeks ICANN’s approval of a program under this Section 4.5.2, and such requested registration program is substantially similar to a

thanks, Susan

https://docs.google.com/document/d/1huKNcgg3VAk95oybb-7u9papLZ4kEMUHNQNElMPWMFY/edit#

@ Paul M just seen your message I think your email server is having problems sometimes they get queued for 10 hours or more... Daivd & Susan supported and ID didn't hear from Scott or You

other than you wanted the proposal sent to the WG for discussion

@Ariel, is that new language highlighted just for the purposes of this call or is it identified for anyone who wants to review this after the call?

Some of us did understand the EPDP Phase 1 report

Miraculously

nice suggestion

Nope

Yes, the WG would have seen the contextual language and deliberations on URS Question 1 — as that is the origin for this recommendation.

And some of the language is incorporated from the EPDP Wave 1 analysis table, which was sent several weeks ago to the WG to review and discuss.

Unfortunately, I need to drop for a meeting with my first grader's teacher. The joys of distance learning.

The recommendation language has appeared in the public comment analysis summary as agreement by the WG

Purpose 6-PA5 text was included in the public comment analysis doc as a side comment since August

The language was circulated prior to the first discussion of the EPDP Wave 1 analysis table — by Ariel

Sorry but I really cannot understand Kathy’s concern or objection to that language…

@Kathy: The language was circulate to the WG

Pretty sure we did discuss the language about redaction

Hand up

It’s also literally some context…. Not even sure why we’re really discussing it now

Context language isn't binding, is it?

@Griffin: That’s right. It is included as context only. GNSO Council asked the WG to

@Paul: It’s not binding. It’s just context.

This really should not be controversial…

It is not language that we adopted or even reviewed

It’s not even guidance to the IRT

it is not implementation guidance

It was not even part of the table that was circulated.

Recommendations are binding (at least I hope they are)...

@Kathy: It was part of the table

I have a hard stop at 2:30

@Julie - it was referenced in the table, but not shown - you circulated it separately (many weeks later) - which I appreciate

No it was shown in the margin on the day the WG discussed it

Ariel put it in

I'm also pretty sure Kathy has mentioned this before.

Kathy do you have some particular substantive concern with the paragraph? I don’t really see what would be objectionable about its inclusion as context to this rec

Maybe I missed it if so

@All: Note that the context is just that — it is not binding and not Implementation Guidance.

yes

good suggestion.

I guess I don’t object it just seems silly

thanks all

Thank you Phil, and staff, and all

Thanks for chairing yet again Phil,

thanks Phil, bye all

Bye all