<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Greg,<br>
</p>
<p>The number of proponents surelydoes not matter, only their
affiliation does. If those eleven for Recs 14/15 were to all hail
from only one SG, and the opponents from various SGs, there would
be a majority opposition in the terms of the GNSO representation.
<br>
</p>
<p>Not saying it is so, just saying pure numbers need not
necessarily matter as much as you seem to indicate.<br>
</p>
Best,<br>
Volker<br>
<br>
<div class="moz-cite-prefix">Am 17.10.2018 um 22:02 schrieb Greg
Shatan:<br>
</div>
<blockquote type="cite"
cite="mid:CA+aOHUTL_pGYKwEseqw+s8COJejxDMt8QbdRWN=grczQXjzqJQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div>
<div dir="auto">Julie and all,</div>
<div dir="auto"><br>
</div>
<div dir="auto">I have a couple of issues regarding the
“ratings” for the proposed recommendations. Before that, I
have a concern with the methodology, on two levels.</div>
<div dir="auto"><br>
</div>
<div dir="auto">First, there is a great deal of continuing
confusion in our work about whether “support” or “opposition”
goes to the potential adoption of a recommendation or to the
publication of a recommendation.<b> </b></div>
<div dir="auto"><br>
</div>
<div dir="auto">This confusion extends to this document and to
the underlying transcripts, chats and emails it references.
Some participants were (sometimes) explicit about where they
stood on both prongs, stating support for publication while
remaining neutral on (or even opposing) the substance of a
recommendation. In other cases, support or opposition is
phrased only in connection with substance. More rarely, views
focused only on publication. </div>
<div dir="auto"><br>
</div>
<div dir="auto">Second, this document attempts to glean, from
the pro-active statements of participants in these underlying
materials, the level of “support” for each proposal
(presumably, for publication and not necessarily substance),
sometimes (but not always) including some gauging of the level
of opposition. This is a flawed method, due to both the
repeated ambiguity about what is being supported or opposed
and to the reliance only on “squeaky wheel” analysis of the
participants.</div>
<div dir="auto"><br>
</div>
<div dir="auto">In numerous cases where support or opposition is
stated, it is not clear whether this is directed toward
publication or adoption of the recommendation. This creates
an interpretation problem. Of course, those who support the
proposal can readily be counted as supporting publication.
But the opposite is not true — those stating opposition to
substance cannot be read as stating opposition to
publication. Indeed, in several cases, I supported
publication while opposing the underlying proposal. </div>
<div dir="auto"><br>
</div>
<div dir="auto">There is also the problem of focusing only those
who spoke up. While I was reasonably active in stating my
views, there were times where I supported a proposal, but I
said nothing. Also, sometimes I said nothing where I opposed
a proposal, because I had nothing new to add to the
oppositions already put forward. If I had known that the
interventions were going to be tallied and used to determine
levels of support and opposition, I would have approached this
entire exercise quite differently.</div>
<div dir="auto"><br>
</div>
<div dir="auto"><b>It needs to be made super clear and explicit
in this document and in our report whether, </b><u
style="font-weight:bold">in each instance</u><b>, we are
describing support or opposition to </b><i
style="font-weight:bold">publication of a proposed
recommendation</i><b> vs. support or opposition to the </b><b
style="font-style:italic">substance of the proposal. </b>Otherwise,
we are doomed to confusion.<br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">On to the specific Recommendations.</div>
<div dir="auto"><br>
</div>
<div dir="auto"><b>12.</b> Based on the recent discussion of
Recommendation #12 (“created in bad faith”) on the email list,
this should be rated “limited support” rather than “adequate
support,” and the parenthetical should be revised to reflect
the concerns raised in this discussion. There’s no need to
reiterate everything in that thread here.</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto"><b>14/15.</b> Recommendations 14/15 appear to be
incorrectly characterized as limited support, when it should be
adequate support. This may be based on a misunderstanding,
since the parenthetical says “proponent supports and most
oppose.” These two proposals together have <u
style="font-weight:bold">11 proponents</u>. Clearly it’s
wrong to characterize this as a lonely “proponent supports.”
While 5-6 participants in the chat and transcript oppose the
proposal in substance, none said outright that it should not be
published. Even if you decide that also mean they oppose
publication, there are still more proponents than detractors.
In addition, at least one participant (David McAuley) supported
publication. I will expressly support publication as well.</div>
<div dir="auto"><br>
</div>
<div dir="auto"><b>18/20.</b> I think the document gets it right
with regard to proposals 18-20. I’m shocked that anyone could
think otherwise. I’ll also note that “importance” in the eyes
of a proponent is clearly not a relevant yardstick.</div>
<div dir="auto"><br>
</div>
<div dir="auto"><b>33.</b> Support for #33 should be “limited”
(at best) and not “adequate” based on the chat and the email
thread indicated. There are several statements of strong
opposition that are undeniably directed toward the
intelligibility/publication of the proposal, because (among
other things) it is based on an incorrect premise (that MoUs are
not contracts). I would even say, after reviewing a number of
the underlying chats, transcripts and email threads, that there
was more express opposition to putting this proposal forward
than in virtually any other case.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Best regards,</div>
<div dir="auto"><br>
</div>
<div dir="auto">Greg</div>
<div dir="auto"><br>
</div>
<div dir="auto">P.S. Note that I am only concerned with the
overall level of support. I am not trying to tell any
particular individual what they think (sort of a “If I wanted
your opinion, I’d tell it to you” exercise). Nor am I trying to
“bell the cat” and use opinions written under other
circumstances to discredit anyone’s views. Those things would
be disruptive of our workflow, especially if done repeatedly and
over the objections of those individuals.</div>
<div dir="auto"><br>
</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr">On Wed, Oct 17, 2018 at 1:29 PM George Kirikos
<<a href="mailto:icann@leap.com" moz-do-not-send="true">icann@leap.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">David,<br>
<br>
But, you're not just asking "What do you think?" It says:<br>
<br>
"On behalf of Verisign, I am proposing that the WG put out
for Public<br>
Comment the issue of whether the URS should become an ICANN<br>
Consensus Policy. Verisign believes that it is the
appropriate time<br>
for this matter to be discussed in the Public Comment forum
on the<br>
WG’s Initial Report. Sub-team developed data indicates that
***** URS<br>
in practice has proven viable, efficacious, and
fit-for-purpose as a<br>
rapid remedy for clear-cut instances of protected mark
abuse.****** We<br>
believe that inviting public input will be valuable, indeed
essential,<br>
in<br>
informing the RPM PDP WG in its future work" (emphasis
added)<br>
<br>
i.e. it's essentally saying "It's working great", which
obviously<br>
frames the issue towards "acceptance." Even in my comments
on your<br>
proposal, see page 43 of the transcript of October 3, 2018:<br>
<br>
<a
href="https://gnso.icann.org/sites/default/files/file/field-file-attach/transcript-rpm-review-03oct18-en.pdf"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://gnso.icann.org/sites/default/files/file/field-file-attach/transcript-rpm-review-03oct18-en.pdf</a><br>
<br>
I said I don't support the proposal itself, but agree it can
be put<br>
out for public comment. Now it seems there's some "gaming"
going on,<br>
where important proposals are shoved into an annex on the
same issue,<br>
because some members of this PDP are withholding support for
even<br>
putting it out for public comment when they oppose a
proposal, lest<br>
the public comment come back favourable towards a proposal
they<br>
disagree with.<br>
<br>
Sincerely,<br>
<br>
George Kirikos<br>
416-588-0269<br>
<a href="http://www.leap.com/" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://www.leap.com/</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
On Wed, Oct 17, 2018 at 1:06 PM, McAuley, David <<a
href="mailto:dmcauley@verisign.com" target="_blank"
moz-do-not-send="true">dmcauley@verisign.com</a>>
wrote:<br>
> George, I don't agree and think that is a non-sequitur.<br>
><br>
> I don't understand why it would follow that I support
URS as consensus policy when I simply ask the public "what
do you think?"<br>
><br>
> It is an issue we will face, why not get input.<br>
><br>
> To those who might conceivably perceive it otherwise, I
say again, this is seeking public comment on the issue, not
seeking a decision on it. Enough said.<br>
><br>
> Best regards,<br>
> David<br>
><br>
> David McAuley<br>
> Sr International Policy & Business Development
Manager<br>
> Verisign Inc.<br>
> 703-948-4154<br>
><br>
> -----Original Message-----<br>
> From: GNSO-RPM-WG <<a
href="mailto:gnso-rpm-wg-bounces@icann.org"
target="_blank" moz-do-not-send="true">gnso-rpm-wg-bounces@icann.org</a>>
On Behalf Of George Kirikos<br>
> Sent: Wednesday, October 17, 2018 1:00 PM<br>
> To: <a href="mailto:gnso-rpm-wg@icann.org"
target="_blank" moz-do-not-send="true">gnso-rpm-wg@icann.org</a><br>
> Subject: [EXTERNAL] Re: [GNSO-RPM-WG] List of URS
Individual Proposals & Suggested Support Levels<br>
><br>
> David,<br>
><br>
> I don't think that's how it'll be perceived. i.e. if
you "support"<br>
> proposal #31, then you support the URS becoming a
consensus policy.<br>
> That's not "neutral". Furthermore, it doesn't address
*elimination* of the URS for new gTLDs.<br>
><br>
> I want to equally have the underlying issue put on the
table, via a proposal that is explicit and direct (i.e. #32
is explicit about removing the URS from the new gTLDs, and
*not* making it apply to legacy gTLDs like .com/net/org via
a consensus policy).<br>
><br>
> Sincerely,<br>
><br>
> George Kirikos<br>
> 416-588-0269<br>
> <a href="http://www.leap.com/" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://www.leap.com/</a><br>
><br>
><br>
><br>
> On Wed, Oct 17, 2018 at 12:46 PM, McAuley, David <<a
href="mailto:dmcauley@verisign.com" target="_blank"
moz-do-not-send="true">dmcauley@verisign.com</a>>
wrote:<br>
>> I want to reiterate (again) that my proposal re URS
and legacy gTLDS is NOT a proposal that legacy gTLDs be
subject to URSbut IS RATHER a proposal that we seek public
comment on this matter to inform us on this issue and it
will help inform Verisign on whose behalf I made the
proposal. It is simply a proposal seeking comment and is
definitely NOT a proposal seeking a substantive change.<br>
>><br>
>> Best regards all,<br>
>> David<br>
>><br>
>> David McAuley<br>
>> Sr International Policy & Business Development
Manager Verisign Inc.<br>
>> 703-948-4154<br>
>><br>
>> -----Original Message-----<br>
>> From: GNSO-RPM-WG <<a
href="mailto:gnso-rpm-wg-bounces@icann.org"
target="_blank" moz-do-not-send="true">gnso-rpm-wg-bounces@icann.org</a>>
On Behalf Of George<br>
>> Kirikos<br>
>> Sent: Wednesday, October 17, 2018 12:39 PM<br>
>> To: <a href="mailto:gnso-rpm-wg@icann.org"
target="_blank" moz-do-not-send="true">gnso-rpm-wg@icann.org</a><br>
>> Subject: [EXTERNAL] Re: [GNSO-RPM-WG] List of URS
Individual Proposals<br>
>> & Suggested Support Levels<br>
>><br>
>> Hi folks,<br>
>><br>
>> I disagree with some of the designated support
levels being "limited"<br>
>> as opposed to "adequate", i.e. some support levels
aren't fully capturing the support (e.g. folks not attending
calls, etc.). See comments below:<br>
>><br>
>> A] Proposal #7 -- Legal Contact in WHOIS -- there
was an "action item"<br>
>> about revising the proposal, but after the call I
reviewed comments,<br>
>> and decided that no further changes were needed
(that's why I've not<br>
>> already submitted any revisions to it)<br>
>><br>
>> B] Proposal #8 -- adjusting the response time by 3
years for each year a domain name has been registered; I
think more than just a few would support that, as it's
unreasonable to expect people to respond swiftly to a
complaint over a domain that has been registered for 10 or
20 years! Maybe those on the list who want to get public
comments on this should speak out, as registrants are
currently severely disadvantaged.<br>
>><br>
>> C] Proposals #18, #19, and #20 (dealing with the
"lack of cause of action" issue) -- I'm shocked this is
described as having only "limited" support, given these are
the single most important proposals I've made, tackling an
important problem, and mirror the debate we had in the IGO
PDP about this important "access to courts" issue. This PDP
can't simply ignore the fact that all registrants in the UK,
for example, can't appeal an adverse URS/UDRP ruling to the
UK courts at present (if that's the mutual jurisdiction, or
if they're elsewhere and the registrar is in the UK),
because of the way the UDRP has been implemented.<br>
>><br>
>> This was the problem also mentioned in the White
Paper back in 1999, as was noted in the emails at:<br>
>><br>
>> <a
href="https://mm.icann.org/pipermail/gnso-rpm-wg/2018-October/003444.html"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mm.icann.org/pipermail/gnso-rpm-wg/2018-October/003444.html</a><br>
>> <a
href="https://mm.icann.org/pipermail/gnso-rpm-wg/2018-October/003449.html"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mm.icann.org/pipermail/gnso-rpm-wg/2018-October/003449.html</a><br>
>><br>
>> which *wasn't* properly solved by Section 4(k) of
the UDRP, but which will be fixed by adopting URS Proposals
#18 or #19 (#20 wouldn't completely fix it, but would be an
improvement).<br>
>><br>
>> Furthermore, the transcript of the October 10th
call (when these were<br>
>> presented) demonstrates that Zak Muscovitch and the
ICA openly supported all my proposals presented on that date
to be put out for public comment:<br>
>><br>
>> <a
href="https://gnso.icann.org/en/meetings/transcript-rpm-review-10oct18-en.pd"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://gnso.icann.org/en/meetings/transcript-rpm-review-10oct18-en.pd</a><br>
>> f<br>
>><br>
>> "Zak Muscovitch for the record. First of all, thank
you George for<br>
>> making the proposal. I want to let the working
group know that all had<br>
>> of George's proposals are going to receive support
from me to be put<br>
>> into interim floor for discussion." (page 9)<br>
>><br>
>> so to suggest that only Michael K. supported #18 is
flat out wrong.<br>
>> I'm confident others who were in the IGO PDP in the
"consensus recommendation" (most, if not all, who are also
members of this PDP) also support that this be put out for
public comment. (i.e. #19 matches that PDP's recommendation,
although #18 is superior in my view, and #20 with expansion
to include US Jurisdiction was also mentioned by others as a
solution).<br>
>><br>
>> As for the "action item" to consolidate them into a
single proposal, that's not possible, given the nature of
the proposals (they're alternatives to each others).<br>
>><br>
>> D] Proposal #30 -- mediation - this too was
discussed in the IGO PDP and had some support there, but
most said "defer to the RPM PDP".<br>
>> Well, now we're in the RPM PDP and we're not going
to let the public weigh in on this fully (but shove it into
an appendix?). I don't think so.....I think there was
"adequate" support on this.<br>
>><br>
>> E] Proposal #32 -- elimination of URS for new
gTLDs, and *not*<br>
>> becoming a mandatory consensus policy -- this was
the *opposite* of<br>
>> David McAuley's Proposal #31, so you would think
that those who<br>
>> *opposed* his proposal (that the URS would become a
"consensus<br>
>> policy") are implicitly supporters of Proposal #32
(my proposal).<br>
>> Given all the attempts by ICANN Staff to inject the
URS into legacy TLDs (like .org, .travel, etc.), and the
opposition to that when it happened, the public deserves the
chance to make it clear that they want to reject the
expansion of the URS into .com/net/org. Putting Propsal #32
on an even field with Proposal #31 makes sense, and I think
the support level is not correct (it should be "adequate").<br>
>><br>
>> Sincerely,<br>
>><br>
>> George Kirikos<br>
>> 416-588-0269<br>
>> <a href="http://www.leap.com/" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://www.leap.com/</a><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On Wed, Oct 17, 2018 at 11:27 AM, Julie Hedlund
<<a href="mailto:julie.hedlund@icann.org" target="_blank"
moz-do-not-send="true">julie.hedlund@icann.org</a>>
wrote:<br>
>>> Dear RPM PDP Working Group members,<br>
>>><br>
>>><br>
>>><br>
>>> In preparation for the Working Group meetings
at ICANN63, session 1<br>
>>> and session 4, and in accordance with the
attached Procedures for URS<br>
>>> Policy and Operational Recommendations, staff
have reviewed the WG<br>
>>> deliberations as recorded in the meeting
transcripts and chat rooms,<br>
>>> and have produced the attached table with the
staff’s suggested<br>
>>> levels of support for the individual proposals.
The co-chairs believe<br>
>>> a good path forward is to allow all WG members
to review and, if they<br>
>>> wish, comment upon these preliminary
designations of support. For<br>
>>> those attending ICANN63, please bring your
comments to our first<br>
>>> face-to-face (F2F) session on Sunday, 21
October at<br>
>>> 15:15-16:45 local time. For those not attending
the F2F meeting,<br>
>>> please feel free to let us know your thoughts
online.<br>
>>><br>
>>><br>
>>><br>
>>> Staff took its guidance from the following
excerpt from Section 7 of<br>
>>> the procedures, as agreed to by the WG:<br>
>>><br>
>>><br>
>>><br>
>>> “Unless there is substantial material
opposition within the Working<br>
>>> Group, Sub Team recommendations will be
included in the Initial<br>
>>> Report for the purpose of soliciting public
comment thereon. To be<br>
>>> clear, Sub Team recommendations have a
rebuttable presumption,<br>
>>> subject to WG feedback, of enjoying an adequate
level of support to<br>
>>> be included in the Initial Report for the
purpose of soliciting<br>
>>> community input; Sub Team proposals, like those
from individuals,<br>
>>> will only become Final Report recommendations
if they achieve Full Consensus or Consensus.”<br>
>>><br>
>>><br>
>>><br>
>>> The Co-Chairs would like the WG to note the
following with respect to<br>
>>> these suggested levels of support:<br>
>>><br>
>>><br>
>>><br>
>>> These are preliminary and subject to review and
deliberation by the<br>
>>> WG at ICANN63; WG members are encouraged to
provide feedback on the<br>
>>> suggested levels of support and in particular
as to whether there are<br>
>>> any mischaracterizations; The levels of support
and determination<br>
>>> with respect to inclusion in the Initial Report
will be based on the<br>
>>> deliberations at ICANN63, with public comment
requested on all<br>
>>> proposals that garnered adequate support; The
Initial Report will<br>
>>> note for the record individual proposals that
failed to achieve<br>
>>> adequate support; The WG will have the
opportunity to review the<br>
>>> proposals as they appear in the draft Initial
Report and propose<br>
>>> revisions before the Initial Report is
published for public comment.<br>
>>><br>
>>><br>
>>><br>
>>> Finally, if WG members have revised proposals
they should submit them<br>
>>> to the WG list no later than 23:59 UTC on
Friday, 19 October so that<br>
>>> they may be discussed at the sessions at
ICANN63.<br>
>>><br>
>>><br>
>>><br>
>>> Best regards,<br>
>>><br>
>>> Mary, Julie, Ariel & Berry<br>
>>><br>
>>> On behalf of the RPM PDP Working Group
Co-Chairs<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> GNSO-RPM-WG mailing list<br>
>>> <a href="mailto:GNSO-RPM-WG@icann.org"
target="_blank" moz-do-not-send="true">GNSO-RPM-WG@icann.org</a><br>
>>> <a
href="https://mm.icann.org/mailman/listinfo/gnso-rpm-wg"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/listinfo/gnso-rpm-wg</a><br>
>> _______________________________________________<br>
>> GNSO-RPM-WG mailing list<br>
>> <a href="mailto:GNSO-RPM-WG@icann.org"
target="_blank" moz-do-not-send="true">GNSO-RPM-WG@icann.org</a><br>
>> <a
href="https://mm.icann.org/mailman/listinfo/gnso-rpm-wg"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/listinfo/gnso-rpm-wg</a><br>
> _______________________________________________<br>
> GNSO-RPM-WG mailing list<br>
> <a href="mailto:GNSO-RPM-WG@icann.org" target="_blank"
moz-do-not-send="true">GNSO-RPM-WG@icann.org</a><br>
> <a
href="https://mm.icann.org/mailman/listinfo/gnso-rpm-wg"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/listinfo/gnso-rpm-wg</a><br>
_______________________________________________<br>
GNSO-RPM-WG mailing list<br>
<a href="mailto:GNSO-RPM-WG@icann.org" target="_blank"
moz-do-not-send="true">GNSO-RPM-WG@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rpm-wg"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/listinfo/gnso-rpm-wg</a></blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
GNSO-RPM-WG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:GNSO-RPM-WG@icann.org">GNSO-RPM-WG@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rpm-wg">https://mm.icann.org/mailman/listinfo/gnso-rpm-wg</a></pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
Volker A. Greimann<br>
General Counsel and Policy Manager<br>
<strong style="border-bottom: 3px solid #5C46B5">KEY-SYSTEMS GMBH</strong><br>
<br>
T: +49 6894 9396901<br>
M: +49 6894 9396851<br>
F: +49 6894 9396851<br>
W: <a class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a><br>
<br>
Key-Systems GmbH is a company registered at the local court of
Saarbruecken, Germany with the registration no. HR B 18835<br>
CEO: Alexander Siffrin<br>
<br>
Part of the CentralNic Group PLC (LON: CNIC) a company registered
in England and Wales with company number 8576358.</div>
</body>
</html>