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

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

49:53
Paul McGrady leads that Small Team

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

59:32
there should be safeguards for Geo tlds

01:00:11
is not having a domain discouraging? I think so

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

01:01:24
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.

01:01:36
short response

01:01:44
Agree completely with Griffin.

01:01:58
That's even lower

01:02:01
Sorry, can't hear Jason.

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

01:02:17
much better

01:02:24
compliance reads language as is, not intentions of the WG

01:03:15
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

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

01:04:10
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

01:04:25
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

01:04:36
(This is what small team was working on)

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

01:07:51
"... REASONABLE use". It's in the Rec.

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

01:08:12
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

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

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

01:08:47
No one would claim reserving police for the city police is anything other than reasonable.

01:08:49
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.”?

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

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

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

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

01:10:28
Which is generally hugely favorable to CPs

01:10:49
also price regulation is outside of the picket fence and non enforceable

01:11:13
But enforcing against circumvention of the RPMs through discriminatory practices is within the picket fence

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

01:11:50
and formal violations are enforced the way they see fit

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

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

01:12:21
ALP does not work yet

01:12:46
we do not know if it will

01:13:12
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)

01:13:13
as Jason said, threading the needle

01:13:27
We discussed this ad naseum before in reaching consensus on rec 2

01:13:27
Ariel's wording above seems OK to me.

01:13:49
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.”?

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

01:13:55
Repeating here for your reference

01:14:13
it was thought to be the way, but it did not work

01:14:59
+1 Ariel. Picket fence asked and answered

01:15:19
But is it reflected in the bullet point?

01:15:25
(new bullet point?)

01:15:57
seems like agreement on revision - how to proceed?

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

01:16:13
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”

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

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

01:17:43
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....

01:18:20
email I sent last night---

01:20:06
Not able to copy and paste...grrrr

01:20:16
We will display them on the screen

01:20:49
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

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

01:22:56
Agree with how Paul has responded to the clarifying questions

01:23:29
@Phil - correct.

01:24:11
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

01:25:38
panel can not replace arbitration

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

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

01:28:14
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).

01:28:15
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"

01:28:46
enforcement is about prohibition of violation of the contract, not about not following the ideas

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

01:29:16
it is literally the language of a contract following

01:29:56
@Paul, circumvention itself is not defined, so can not be enforced

01:30:16
Apologies, I have to drop off the call now.

01:30:39
good point about ephemeral nature of sunrise

01:30:54
there are sunrise drps

01:30:55
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?

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

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

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

01:33:45
Full stop

01:33:49
STI was an an IRT

01:33:56
STI was not an IRT

01:34:37
+1 Paul

01:34:37
disagree Paul -

01:34:53
STI like EPDP

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

01:35:32
I think you meant to tag Paul, not me, Rebecca?

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

01:36:48
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

01:36:53
*may need some

01:37:47
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

01:37:57
Thanks Phil!

01:38:09
the language is too vague

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

01:38:53
Especially with the further implementation guidance we are craftig

01:38:55
there is no agreement on that

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

01:39:11
Agree w/ Griffin. There's a large degree of agmt here.

01:39:14
I mean… it already went out as a WG recommendation....

01:39:33
So clearly we already determined that it had sufficient "consensus”

01:39:46
not the current language

01:40:03
The current language as in the add’l guidance?

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

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

01:42:05
hand up

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

01:43:06
hand up again

01:44:45
ALPs were handled poorly last time

01:45:07
I think so, it is directly related to RPMs

01:45:28
it is part of RPMs

01:48:19
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

01:49:01
thanks, Susan

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

01:51:50
@ 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

01:53:10
other than you wanted the proposal sent to the WG for discussion

01:53:19
@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?

01:54:36
Some of us did understand the EPDP Phase 1 report

01:54:40
Miraculously

01:55:53
nice suggestion

01:59:53
Nope

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

02:01:08
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.

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

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

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

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

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

02:05:09
@Kathy: The language was circulate to the WG

02:05:15
Pretty sure we did discuss the language about redaction

02:05:22
Hand up

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

02:06:26
Context language isn't binding, is it?

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

02:06:56
@Paul: It’s not binding. It’s just context.

02:06:59
This really should not be controversial…

02:07:15
It is not language that we adopted or even reviewed

02:07:20
It’s not even guidance to the IRT

02:07:28
it is not implementation guidance

02:07:34
It was not even part of the table that was circulated.

02:07:38
Recommendations are binding (at least I hope they are)...

02:07:49
@Kathy: It was part of the table

02:08:14
I have a hard stop at 2:30

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

02:09:16
No it was shown in the margin on the day the WG discussed it

02:09:28
Ariel put it in

02:09:36
I'm also pretty sure Kathy has mentioned this before.

02:09:59
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

02:10:05
Maybe I missed it if so

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

02:11:35
yes

02:11:45
good suggestion.

02:11:50
I guess I don’t object it just seems silly

02:12:25
thanks all

02:12:30
Thank you Phil, and staff, and all

02:12:40
Thanks for chairing yet again Phil,

02:12:49
thanks Phil, bye all

02:12:52
Bye all