[GNSO-RPM-WG] List of URS Individual Proposals & Suggested Support Levels

Wed Oct 17 22:35:42 UTC 2018

George #23 doesn’t seem very sensible and I’m somewhat surprised it is
deemed to have adequate support.

As I have already pointed out the TM holder is a 3rd party looking to
intervene in a private contract. What you are proposing is that one of the
parties to the contract that is causing the problem should be rewarded
proportionately to level of bad behaviour, which would have the effect of
working in direct opposition to the intenttions of RAA 3.18.

On Wed, Oct 17, 2018 at 10:19 PM George Kirikos <icann at leap.com> wrote:

> Well said, Michael. It's worth noting I have experience helping to
> form consensus across all constituencies, to find excellent solutions.
> e.g. in the IGO PDP, we had a broad consensus across multiple
> constituencies:
>
>
> https://docs.google.com/spreadsheets/d/e/2PACX-1vQgB2sY5AgaBZUHsHJJPLIsAwTFj-0i3FsammN5q-iD1QCQ_EMBC8LTzZ30TGvrf6Fw_mUvlnHa9DV9/pubhtml
>
> and where there was opposition, it was outweighed by other support
> from the opposers' own constituencies. Or, witness the huge consensus
> against the SiteFinder proposal (sorry guys from VeriSign), where I
> helped to mobilize consensus against it.
>
> It's early in the process, and some are trying to extinguish proposals
> that might win the support of the public, by not letting the public
> even get exposed to the ideas. That's wrong, in my view. Folks need to
> set aside their personal interests, and think of what's best across
> all constituencies and stakeholders. I'm not even in the UK, and I'm
> helping solve a serious problem for their registrants (via #18, #19,
> and #20). I'm not a registrar or registry, and the cost-recovery
> proposal I submitted won't impact me, but makes sense as being in the
> interest of all stakeholders globally (i.e. underlying economic
> fairness). It doesn't have to "I win, you lose"  --- there's "win-win"
> too.
>
> Sincerely,
>
> George Kirikos
> 416-588-0269
> http://www.leap.com/
>
>
>
>
> On Wed, Oct 17, 2018 at 5:07 PM, Michael Karanicolas
> <mkaranicolas at gmail.com> wrote:
> > Hi all,
> >
> > I disagree with Greg’s reasoning regarding levels of support, as I
> > think the focus on pure numbers is misleading. Just because a
> > particular industry can afford to brigade the group with a dozen
> > people, all of whom are essentially paid to say the same thing, does
> > not indicate that a particular proposal has a lot of support – nor
> > would that reasoning reflect well on the “multistakeholder model”
> > we’re supposed to be implementing.
> >
> > I think a much more telling indicator is the breadth of support,
> > particularly across constituencies. Here’s it’s worth noting that
> > several of George’s proposals (ALAC) have attracted support from the
> > ICA (BC) and from people in leadership positions in both the NCUC and
> > NPOC.
> >
> > That, in my mind, reflects a broader base of support, and ultimately a
> > greater likelihood that these proposals will attract consensus, than a
> > proposal which attracts vehement support from the IPC but no support
> > from outside that narrow constituency.
> >
> > Best,
> >
> > Michael
> >
> > On Wed, Oct 17, 2018 at 4:02 PM Greg Shatan <gregshatanipc at gmail.com>
> wrote:
> >>
> >> Julie and all,
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> It needs to be made super clear and explicit in this document and in
> our report whether, in each instance, we are describing support or
> opposition to publication of a proposed recommendation vs. support or
> opposition to the substance of the proposal.  Otherwise, we are doomed to
> confusion.
> >>
> >> On to the specific Recommendations.
> >>
> >> 12.  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.
> >>
> >> 14/15.  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 11 proponents.  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.
> >>
> >> 18/20.  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.
> >>
> >> 33.  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.
> >>
> >> Best regards,
> >>
> >> Greg
> >>
> >> 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.
> >>
> >>
> >> On Wed, Oct 17, 2018 at 1:29 PM George Kirikos <icann at leap.com> wrote:
> >>>
> >>> David,
> >>>
> >>> But, you're not just asking "What do you think?" It says:
> >>>
> >>> "On behalf of Verisign, I am proposing that the WG put out for Public
> >>> Comment the issue of whether the URS should become an ICANN
> >>> Consensus Policy. Verisign believes that it is the appropriate time
> >>> for this matter to be discussed in the Public Comment forum on the
> >>> WG’s Initial Report. Sub-team developed data indicates that ***** URS
> >>> in practice has proven viable, efficacious, and fit-for-purpose as a
> >>> rapid remedy for clear-cut instances of protected mark abuse.****** We
> >>> believe that inviting public input will be valuable, indeed essential,
> >>> in
> >>> informing the RPM PDP WG in its future work" (emphasis added)
> >>>
> >>> i.e. it's essentally saying "It's working great", which obviously
> >>> frames the issue towards "acceptance." Even in my comments on your
> >>> proposal, see page 43 of the transcript of October 3, 2018:
> >>>
> >>>
> https://gnso.icann.org/sites/default/files/file/field-file-attach/transcript-rpm-review-03oct18-en.pdf
> >>>
> >>> I said I don't support the proposal itself, but agree it can be put
> >>> out for public comment. Now it seems there's some "gaming" going on,
> >>> where important proposals are shoved into an annex on the same issue,
> >>> because some members of this PDP are withholding support for even
> >>> putting it out for public comment when they oppose a proposal, lest
> >>> the public comment come back favourable towards a proposal they
> >>> disagree with.
> >>>
> >>> Sincerely,
> >>>
> >>> George Kirikos
> >>> 416-588-0269
> >>> http://www.leap.com/
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, Oct 17, 2018 at 1:06 PM, McAuley, David <dmcauley at verisign.com>
> wrote:
> >>> > George, I don't agree and think that is a non-sequitur.
> >>> >
> >>> > 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?"
> >>> >
> >>> > It is an issue we will face, why not get input.
> >>> >
> >>> > 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.
> >>> >
> >>> > Best regards,
> >>> > David
> >>> >
> >>> > David McAuley
> >>> > Sr International Policy & Business Development Manager
> >>> > Verisign Inc.
> >>> > 703-948-4154
> >>> >
> >>> > -----Original Message-----
> >>> > From: GNSO-RPM-WG <gnso-rpm-wg-bounces at icann.org> On Behalf Of
> George Kirikos
> >>> > Sent: Wednesday, October 17, 2018 1:00 PM
> >>> > To: gnso-rpm-wg at icann.org
> >>> > Subject: [EXTERNAL] Re: [GNSO-RPM-WG] List of URS Individual
> Proposals & Suggested Support Levels
> >>> >
> >>> > David,
> >>> >
> >>> > I don't think that's how it'll be perceived. i.e. if you "support"
> >>> > proposal #31, then you support the URS becoming a consensus policy.
> >>> > That's not "neutral". Furthermore, it doesn't address *elimination*
> of the URS for new gTLDs.
> >>> >
> >>> > 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).
> >>> >
> >>> > Sincerely,
> >>> >
> >>> > George Kirikos
> >>> > 416-588-0269
> >>> > http://www.leap.com/
> >>> >
> >>> >
> >>> >
> >>> > On Wed, Oct 17, 2018 at 12:46 PM, McAuley, David <
> dmcauley at verisign.com> wrote:
> >>> >> 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.
> >>> >>
> >>> >> Best regards all,
> >>> >> David
> >>> >>
> >>> >> David McAuley
> >>> >> Sr International Policy & Business Development Manager Verisign Inc.
> >>> >> 703-948-4154
> >>> >>
> >>> >> -----Original Message-----
> >>> >> From: GNSO-RPM-WG <gnso-rpm-wg-bounces at icann.org> On Behalf Of
> George
> >>> >> Kirikos
> >>> >> Sent: Wednesday, October 17, 2018 12:39 PM
> >>> >> To: gnso-rpm-wg at icann.org
> >>> >> Subject: [EXTERNAL] Re: [GNSO-RPM-WG] List of URS Individual
> Proposals
> >>> >> & Suggested Support Levels
> >>> >>
> >>> >> Hi folks,
> >>> >>
> >>> >> I disagree with some of the designated support levels being
> "limited"
> >>> >> 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:
> >>> >>
> >>> >> A] Proposal #7 -- Legal Contact in WHOIS -- there was an "action
> item"
> >>> >> about revising the proposal, but after the call I reviewed comments,
> >>> >> and decided that no further changes were needed (that's why I've not
> >>> >> already submitted any revisions to it)
> >>> >>
> >>> >> 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.
> >>> >>
> >>> >> 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.
> >>> >>
> >>> >> This was the problem also mentioned in the White Paper back in
> 1999, as was noted in the emails at:
> >>> >>
> >>> >> https://mm.icann.org/pipermail/gnso-rpm-wg/2018-October/003444.html
> >>> >> https://mm.icann.org/pipermail/gnso-rpm-wg/2018-October/003449.html
> >>> >>
> >>> >> 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).
> >>> >>
> >>> >> Furthermore, the transcript of the October 10th call (when these
> were
> >>> >> presented) demonstrates that Zak Muscovitch and the ICA openly
> supported all my proposals presented on that date to be put out for public
> comment:
> >>> >>
> >>> >>
> https://gnso.icann.org/en/meetings/transcript-rpm-review-10oct18-en.pd
> >>> >> f
> >>> >>
> >>> >> "Zak Muscovitch for the record. First of all, thank you George for
> >>> >> making the proposal. I want to let the working group know that all
> had
> >>> >> of George's proposals are going to receive support from me to be put
> >>> >> into interim floor for discussion." (page 9)
> >>> >>
> >>> >> so to suggest that only Michael K. supported #18 is flat out wrong.
> >>> >> 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).
> >>> >>
> >>> >> 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).
> >>> >>
> >>> >> 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".
> >>> >> 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.
> >>> >>
> >>> >> E] Proposal #32 -- elimination of URS for new gTLDs, and *not*
> >>> >> becoming a mandatory consensus policy -- this was the *opposite* of
> >>> >> David McAuley's Proposal #31, so you would think that those who
> >>> >> *opposed* his proposal (that the URS would become a "consensus
> >>> >> policy") are implicitly supporters of Proposal #32 (my proposal).
> >>> >> 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").
> >>> >>
> >>> >> Sincerely,
> >>> >>
> >>> >> George Kirikos
> >>> >> 416-588-0269
> >>> >> http://www.leap.com/
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Wed, Oct 17, 2018 at 11:27 AM, Julie Hedlund <
> julie.hedlund at icann.org> wrote:
> >>> >>> Dear RPM PDP Working Group members,
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> In preparation for the Working Group meetings at ICANN63, session 1
> >>> >>> and session 4, and in accordance with the attached Procedures for
> URS
> >>> >>> Policy and Operational Recommendations, staff have reviewed the WG
> >>> >>> deliberations as recorded in the meeting transcripts and chat
> rooms,
> >>> >>> and have produced the attached table with the staff’s suggested
> >>> >>> levels of support for the individual proposals. The co-chairs
> believe
> >>> >>> a good path forward is to allow all WG members to review and, if
> they
> >>> >>> wish, comment upon these preliminary designations of support.  For
> >>> >>> those attending ICANN63, please bring your comments to our first
> >>> >>> face-to-face (F2F) session on Sunday, 21 October at
> >>> >>> 15:15-16:45 local time. For those not attending the F2F meeting,
> >>> >>> please feel free to let us know  your thoughts online.
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> Staff took its guidance from the following excerpt from Section 7
> of
> >>> >>> the procedures, as agreed to by the WG:
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> “Unless there is substantial material opposition within the Working
> >>> >>> Group, Sub Team recommendations will be included in the Initial
> >>> >>> Report for the purpose of soliciting public comment thereon. To be
> >>> >>> clear, Sub Team recommendations have a rebuttable presumption,
> >>> >>> subject to WG feedback, of enjoying an adequate level of support to
> >>> >>> be included in the Initial Report for the purpose of soliciting
> >>> >>> community input; Sub Team proposals, like those from individuals,
> >>> >>> will only become Final Report recommendations if they achieve Full
> Consensus or Consensus.”
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> The Co-Chairs would like the WG to note the following with respect
> to
> >>> >>> these suggested levels of support:
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> These are preliminary and subject to review and deliberation by the
> >>> >>> WG at ICANN63; WG members are encouraged to provide feedback on the
> >>> >>> suggested levels of support and in particular as to whether there
> are
> >>> >>> any mischaracterizations; The levels of support and determination
> >>> >>> with respect to inclusion in the Initial Report will be based on
> the
> >>> >>> deliberations at ICANN63, with public comment requested on all
> >>> >>> proposals that garnered adequate support; The Initial Report will
> >>> >>> note for the record individual proposals that failed to achieve
> >>> >>> adequate support; The WG will have the opportunity to review the
> >>> >>> proposals as they appear in the draft Initial Report and propose
> >>> >>> revisions before the Initial Report is published for public
> comment.
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> Finally, if WG members have revised proposals they should submit
> them
> >>> >>> to the WG list no later than 23:59 UTC on Friday, 19 October so
> that
> >>> >>> they may be discussed at the sessions at ICANN63.
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> Best regards,
> >>> >>>
> >>> >>> Mary, Julie, Ariel & Berry
> >>> >>>
> >>> >>> On behalf of the RPM PDP Working Group Co-Chairs
> >>> >>>
> >>> >>>
> >>> >>> _______________________________________________
> >>> >>> GNSO-RPM-WG mailing list
> >>> >>> GNSO-RPM-WG at icann.org
> >>> >>> https://mm.icann.org/mailman/listinfo/gnso-rpm-wg
> >>> >> _______________________________________________
> >>> >> GNSO-RPM-WG mailing list
> >>> >> GNSO-RPM-WG at icann.org
> >>> >> https://mm.icann.org/mailman/listinfo/gnso-rpm-wg
> >>> > _______________________________________________
> >>> > GNSO-RPM-WG mailing list
> >>> > GNSO-RPM-WG at icann.org
> >>> > https://mm.icann.org/mailman/listinfo/gnso-rpm-wg
> >>> _______________________________________________
> >>> GNSO-RPM-WG mailing list
> >>> GNSO-RPM-WG at icann.org
> >>> https://mm.icann.org/mailman/listinfo/gnso-rpm-wg
> >>
> >> _______________________________________________
> >> GNSO-RPM-WG mailing list
> >> GNSO-RPM-WG at icann.org
> >> https://mm.icann.org/mailman/listinfo/gnso-rpm-wg
> > _______________________________________________
> > GNSO-RPM-WG mailing list
> > GNSO-RPM-WG at icann.org
> > https://mm.icann.org/mailman/listinfo/gnso-rpm-wg
> _______________________________________________
> GNSO-RPM-WG mailing list
> GNSO-RPM-WG at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rpm-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rpm-wg/attachments/20181017/af580ec9/attachment-0001.html>