[Gnso-igo-ingo-crp] CONSENSUS CALL on the WG's Recommendations and Remaining Options

George Kirikos icann at leap.com
Wed Jun 6 14:43:31 UTC 2018


Hi folks,

It's unclear to me whether a response to this email is required, given
many folks have already made their positions known on the various
recommendations, and that already-provided feedback cannot simply be
ignored. From my understanding of the working group guidelines, and
looking at past PDPs, the consensus level designations were made at
the *start* of the Consensus Call, accompanied by a draft final
report. Then folks who disagreed (if any) would speak up, e.g. see

(1) IRTP-D: https://forum.icann.org/lists/gnso-irtpd/msg00516.html

"Based on the discussion during the last calls, the assumption is that
there is consensus among the Group for all recommendations as they
currently stand, meaning we anticipate only minor non-substaitve edits
from here on out. If you do not agree with this statement and/or plan
to submit a minority statement, please indicate this on the list or,
at the latest, during our next meeting, Monday 15 September."

(2) Privacy & Proxy PDP:
https://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/2015-November/002196.html

"As noted in the WG Work Plan, circulation of this updated document opens the
period for the WG¹s consensus call. Following this, in accordance with the
GNSO's WG Guidelines, the WG co-chairs will make a final evaluation of the
consensus support levels and, if necessary, assign specific designations of
such to each individual WG recommendation. Any minority statements must
therefore also be submitted by that time. As noted in the WG Work Plan, the
co-chairs plan to close the consensus call period by Monday 7 December 2015.
Unless determined otherwise as a result of this consensus period, the
recommendations are currently marked as Full Consensus of the WG."

https://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/2015-December/002243.html

"This is just a reminder that the consensus call for the Final Report of our
work will close at 23:59 UTC on Monday 7 December 2015. As such, please
email this list with your statement of support, or if there are objections
to any of the final recommendations, your specific objection (and a minority
statement if any), as soon as possible before that deadline.

FYI and as noted previously, the WG chairs are responsible for designating
consensus levels for each final recommendation. Since many of the
recommendations have not changed from the preliminary recommendations that
were published for public comment back in May, and as those few that have
seen changes were modified based on WG discussion and agreement on the
nature of the changes, the current designation in both the original and
updated Final Report is one of Full Consensus.

As such, if no objections are received before the deadline, the presumption
will be that the WG consensus remains that of support for the final
recommendations."

By contrast, we've not yet seen the Draft Final Report for this PDP.
Nor have there been initial designations of consensus levels
specified. So, as I pointed out during our last call, while this has
been labelled a "Consensus Call", I disagree with that terminology. To
me, it appears to be another "pre-consensus" call for feedback, and
the actual "Consensus Call" begins when the Chair makes the initial
designations accompanied with a Draft Final Report.

That being said, even if feedback is not required, it doesn't mean
that continued feedback is not desirable to help refresh memories. My
continuing feedback on the recommendations to date should be no
surprise, but let me provide it again for the record.

1] Recommendation #1: I generally agree with the current draft text.
However, let me be more precise. To the extent that recommendation #4
makes changes to how a UDRP/URS decision is treated by registrars due
to the procedural "quirk of process" we've identified, then those
"changes" are permitted. i.e. some folks might perceive
Recommendations #1 and #4 to be in conflict, depending on the meaning
of "no changes". The "changes" that are made aren't being made to the
3-prong test, etc., but instead to how any decision should be dealt
with in the event that the scenario which leads to the quirk of
process is realized.

2] Recommendation #2: The modified text doesn't reflect my prior
suggestion on how this recommendation should have been made more
precise. See: https://mm.icann.org/pipermail/gnso-igo-ingo-crp/2018-May/001206.html

I would phrase the relevant sentence as follows:

"An IGO may consider this to be an option where it does not have
registered trademark rights or service mark rights in its name or
acronym (as applicable) but believes it has certain unregistered
trademark or service marks rights for which it might adduce….."

The way it's currently drafted (as of 25 May 2018), it's suggesting
that an IGO can have other rights (i.e. other than trademark or
service mark rights) that can be recognized by the UDRP/URS
procedures. I believe that differs from the feedback we received
during the public comment period, namely that the UDRP/URS remain
procedures solely for trademark/service mark violations, i.e.
cybersquatting, and not open up to any claimed "rights". When our
first draft report was created and opened for public comments, we had
proposed that Article 6ter terms be automatically given standing (i.e.
meeting the first prong of the 3-prong test), i.e. that they were not
just "evidence" but "proof" of trademark/service mark rights, but got
pushback on that. By changing it to the language I propose above, we
weaken it to simply "evidence" of (but not proof of) those
trademark/service mark rights. But, my proposed language still
circumscribes it to be trademark or service mark rights (i.e. the
distinction is only between "registered" vs. "unregistered").

In contrast, the May 25, 2018 draft opens it up to a vague definition
of what rights can actually be enough to pass the first prong of the
UDRP/URS. Indeed, as currently written, it even says (first part of
the May 25 2018 draft language) that "An IGO may consider this to be
an option where it ***does not have rights in a trademark or service
mark***** ..... . In other words, it's proposing to expand the
UDRP/URS for IGOs to non-trademark and non-service mark rights, which
I believe is incorrect. We still want to keep it as trademark/service
mark rights, but simply allow for registered vs unregistered
scenarios.


3] Recommendation #3: I support. This PDP could have and should have
ended years ago, when this workaround for IGOs was
discovered/identified. See my email to the mailing list in December
2014 (that's not a typo; that's more than three and a half years ago):

https://mm.icann.org/pipermail/gnso-igo-ingo-crp/2014-December/000221.html
https://mm.icann.org/pipermail/gnso-igo-ingo-crp/2014-December/000220.html

4] Recommendation #4: As I noted in my public comments to the first
draft report, I oppose subsidies to any group, on principle. Every
group feels they are "special" in some way, and I've seen no objective
test that says that IGOs should be treated differently than any other
party to a UDRP/URS. Simply saying "in accordance with GAC advice" is
not a reason, let alone a good reason, that justifies recommendation
#4. If one simply obeys "GAC advice", that suggests PDPs aren't
empowered to make their own decisions, which is not correct. In a
multi-stakeholder model of internet governance, the GAC is simply one
stakeholder whose self-serving (IGOs are observers to the GAC, and
presumably had a hand in drafting this "GAC Advice") requests for
financial subsidies without good justification should be rejected.
IGOs don't receive subsidies when they use the courts. IGOs don't
receive subsidies when they use ADR like mediation or arbitration. Why
should the UDRP/URS be any different? IGOs are creatures created by
governments. Even governments pay court costs and legal fees just like
any other party to a dispute in offline courts (and face similar costs
for staff and lawyers, photocopies and internet). I've not seen any
good reason coming from the GAC other than "we want this" or the vague
"it's in the public interest". Claiming it's "in the public interest"
(without elaboration) can be used to justify many bad ideas, and this
is yet another example of that.

Some of these IGOs have enormous budgets (they're funded by
governments, and ultimately taxpayers), and are in much stronger
financial positions than nearly all respondents. If one was going to
be objective about who "needs" funding, it's those who are objectively
poorer --- and that's certainly not IGOs. Generally, it's the
respondents who are financially at a disadvantage, compared with the
IGOs.

Thus, my position is that no one is entitled to these subsidies,
simply because they want them. ICANN shouldn't be in the position of
"Santa Claus", handing out subsidies to "favoured" groups, those who
whine the loudest to ICANN. This is exactly why ICANN is facing a
budget crisis (despite huge revenues compared to just a few years
ago), because its expenses are out of control. Ultimately, directly
or indirectly, all the revenue of ICANN comes from registrants. ICANN
needs to start saying "No", and indeed should be severely cutting back
on wasteful and unjustified spending, reversing some of its past
mistakes (e.g. liberal travel subsidies, fellowship program, overpaid
staff, etc.).

Given a few folks in this PDP have called for this to be discussed
further between the ICANN Board and the GAC/IGOs, I would strongly
suggest that they establish an objective standard for financial
support, rather than simply leaving it wide open for backroom
discussions. There should also be specific quantitative limits (e.g.
number or dollar amount per year per IGO) to limit the scope of any
discussions. If subsidies made UDRP/URS decisions entirely free and
unlimited for complainants, one could see the potential for costs to
spiral out of control, and for abusive complaints to be filed.

If we are to be engaging in evidence-based policymaking (and that
should be the standard), then that is evidence we should not be
ignoring (i.e. the inability to show that the costs are too high).
Furthermore, we know from the Swaine report that IGOs have used the
UDRP numerous times, so that too is evidence that the fees haven't
been a barrier to the past usage of the UDRP (and the fees for the URS
are much lower). See:

https://mm.icann.org/pipermail/gnso-igo-ingo-crp/2017-November/000895.html

At a minimum (and this is reflected in the final sentence of the
current draft), registrants who are defending a UDRP/URS should
receive matching and identical subsidies, if any complainant received
a subsidy.

But, my strong preference is that no one should be getting any
subsidies. Indeed, when asked, the GAC didn't provide any feedback
that the current fees for UDRP/URS complaints were too high or
unreasonable.

5] Recommendation #5: I'm unchanged from my past position made public
on the mailing list at:

https://mm.icann.org/pipermail/gnso-igo-ingo-crp/2018-May/001142.html
https://mm.icann.org/pipermail/gnso-igo-ingo-crp/2018-May/001143.html

Briefly, I'm in favour of all of the options, except for Option #3. My
strong preference is for Option #1, as that completely solves the
"quirk of process" putting both sides in the exact same position as
they would have been without the UDRP/URS, allowing for the court
process to proceed naturally without interference by ICANN policy.

Option #2 (which I proposed) attempted to be a compromise between
Option #1 and Option #3, but seems to have not resonated or caused
backers of Option #3 to see it at as an attempt at compromise.

Option #4 (as originally proposed by Zak) is a sound option, because
it recognizes that there's an important underlying issue (access to
the courts for REGISTRANTS), one that's also in play for the
Yoyo.email "cause of action" issue in the UK, that might be best
solved holistically in the RPM PDP.

Both Option #5 and Option #6 attempted to reduce the number of cases
that actually experience this "quirk of process".

I support Option #5 (which I proposed) which makes this reduction
*after* the UDRP/URS is decided, by allowing for "in rem" cases (which
were unwittingly disadvantaged by the poor phrasing of the UDRP
language when it was drafted nearly 20 years) to be on an equal
footing as "in personam" cases in the eyes of registrars, when it
comes to locking the domain (that small technical fix can still be
pursued in the RPM PDP, though).

I support Option #6, which makes the reduction in cases encountering
the "quirk of process" differently, namely *before* the UDRP/URS
decision is even made, by introducing a non-binding mediation step.
Given the success at Nominet, this seemed like a no-brainer to me.

I oppose Option #3, as it doesn't actually solve the problem. It
compounds one problem (the quirk of process) with an even worse
solution (arbitration, which creates a whole host of new problems),
rather than doing what Option #1 properly does (solving the problem
entirely by setting aside the UDRP/URS decision and putting both
parties in the exact same position they would have been had the
UDRP/URS procedure not interfered with the underlying legal rights of
the registrant to have access to the courts for the underlying dispute
to be decided on the merits). I've written about this in depth before
(see past posts on this mailing list). Without reiterating every
point, I'd point out that it's a weak facsimile of the due process
protections of real courts and can be far more expensive than real
courts (since taxpayers pay the costs of judges in real courts,
whereas in arbitration those costs are paid by the parties).

As for the current wording of the options, I don't think the revisions
to Option #4 are "friendly". While adding the URS (which I suggested
before) is good, Option #4 wasn't just asking for a "consultation",
but an actual recommendation on how to move forward. The suggestion
that a charter change to the RPM PDP is required doesn't make sense,
given that the RPM PDP's scope is broad, and that the RPM Charter
already contemplated coordination with other PDPs. As previously noted
in April:

https://mm.icann.org/pipermail/gnso-igo-ingo-crp/2018-April/001112.html

in point #2, the RPM PDP charter already states:

""(b) Coordination with Other Parallel Efforts In the course of its
work, the Working Group should monitor the progress of and, where
appropriate, coordinate with, other ICANN groups that are working on
topics that may overlap with or ***otherwise provide useful input to
this PDP.***
....
In addition, the RPM PDP Working Group should also take into
consideration the work/outcome of the TMCH Independent Review, the CCT
Review, and ***any other relevant GNSO policy development***"

(emphasis added)

So, in other words, this PDP's "outcome" provides input for the RPM
PDP's work, and the RPM PDP, via its current charter, should take that
into consideration. Furthermore, the RPM PDP should have *already*
been monitoring and coordinating things (of course, there's
overlapping membership between the two PDPs).

Also, I think the language for Option #6 can be cleaned up a bit, as I
suggested previously. Namely (a) it doesn't mention the URS at
present, and (b) it could be made clearer that it's simply a
combination of mediation + Option #1.

I continue to have some reservations, as previously expressed by Paul
Tattersfield, in how the language of the final report will handle the
Swaine report. Since a draft final report was not part of the
documents that accompanied this pseudo-"consensus call" (or more
properly a "pre-consensus call"), I'll reserve my feedback until
later. For now, I'll just link to my past comments at:

https://mm.icann.org/pipermail/gnso-igo-ingo-crp/2018-May/001201.html

Sincerely,

George Kirikos
416-588-0269
http://www.leap.com/




On Fri, May 25, 2018 at 6:15 PM, Steve Chan <steve.chan at icann.org> wrote:
> Dear WG Members,
>
>
>
> Attached, please find the compilation of the Working Group’s recommendations
> and six (6) options related to Recommendation 5. This message is intended to
> kick of the consensus call process for the WG’s recommendations and
> remaining options under Recommendation 5. For those WG members who wish to
> participate in the consensus call, we ask that you respond on the email list
> to note your support or non-support for all recommendations (i.e.,
> recommendations 1-4) AND the six (6) remaining options under recommendation
> 5. Please provide your response on or before Friday, 8 June.
>
>
>
> Subsequently, the WG Chair will consider response to the consensus call and
> seek to designate final consensus levels on the recommendations and options,
> which will be published to the WG’s email list for WG consideration. WG
> members will then have the opportunity to object to the designations and the
> WG may choose to conduct another call on Thursday, 14 June to discuss; WG
> members will also have the opportunity to file minority statements if
> applicable, which will be incorporated into a Final Report for the Council
> by 17 June.
>
>
>
> Note, based on the discussion on the WG’s call held on Friday, 25 May, a
> handful of changes were made to the attached recommendations/options
> document, highlighted in yellow (e.g., Recommendation 2, Recommendation 4,
> Option 4). In addition, footnotes were added, linking to the original
> rationale and suggestions made by Zak Muscovitch (Option 4), George Kirikos
> (Option 5) and Paul Tattersfield (Option 6). The same was not done for the
> first three options as those had been discussed extensively before the
> additional three options were added and are included unchanged from the text
> presented in the October 2017 poll.
>
> If you have any questions, please let us know.
>
>
>
> Best,
>
> Steve & Mary
>
>
>
>
>
>
>
>
>
>
>
>
>
> Steven Chan
>
> Policy Director, GNSO Support
>
>
>
> ICANN
>
> 12025 Waterfront Drive, Suite 300
>
> Los Angeles, CA 90094-2536
>
> steve.chan at icann.org
>
> mobile: +1.310.339.4410
>
> office tel: +1.310.301.5800
>
> office fax: +1.310.823.8649
>
>
>
> Find out more about the GNSO by taking our interactive courses and visiting
> the GNSO Newcomer pages.
>
>
>
> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO
>
> Follow the GNSO on Facebook: https://www.facebook.com/icanngnso/
>
> http://gnso.icann.org/en/
>
>
>
>
> _______________________________________________
> Gnso-igo-ingo-crp mailing list
> Gnso-igo-ingo-crp at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-igo-ingo-crp


More information about the Gnso-igo-ingo-crp mailing list