ICANN/GNSO GNSO Email List Archives

[council]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [council] Discussion kick-off on BC/IPC strawman proposal as blogged by Fadi

  • To: Thomas Rickert <rickert@xxxxxxxxxxx>
  • Subject: Re: [council] Discussion kick-off on BC/IPC strawman proposal as blogged by Fadi
  • From: Maria Farrell <maria.farrell@xxxxxxxxx>
  • Date: Tue, 11 Dec 2012 14:35:19 +0000
  • Cc: Jonathan Robinson <jonathan.robinson@xxxxxxxxxxx>, Mason Cole <mcole@xxxxxxxxxx>, Volker Greimann <vgreimann@xxxxxxxxxxxxxxx>, council@xxxxxxxxxxxxxx
  • Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OJ9UvLpBNcQV0dvZCzwQB8e3//ZMXROpinaXcZijobo=; b=u+TH5o1VZBBsB8+CpkWB6UioDvn7dyPqngMSWFZ0fc7C6WtOSGedOYxQQFFaTWeYKs 0S3nksgfSB2I5Q4CIY2jG7dIIwOh8L6Ew53se0KRAZvEFpfEZZvfGyfYmx0y/jO6eaBq VG7VlF6AbqkC0hHK5EUjBx9+049QYEgDAaj8fW5NvWV71mI2BqH0/p8nXz2L7h/NF47W rypJBX+6fe7L7MW7bT57hCI/FDascRUM8vUNPDmS37/pg7V8qwFve24ynilqFE0+x8c0 q7jRIIFShkmd7lH4NKrIpPRF/SADfGwOqCNS3lZEZjzjsZVr5BeiIYKREHfL+GnC+Fjn oopw==
  • In-reply-to: <9CFAF749-82F9-4D08-874B-9BB6CA7E2794@anwaelte.de>
  • List-id: council@xxxxxxxxxxxxxx
  • References: <50B656D5.3070007@key-systems.net> <CAC7qwdDFQHq+wPN1MFrVT-71jRBpS71pmsBNeNgDV6KYa-iZbw@mail.gmail.com> <E3600E5D-CECE-4601-ACBC-6B0E2999A57C@5x5com.com> <02a101cdd15d$7f471120$7dd53360$@ipracon.com> <9CFAF749-82F9-4D08-874B-9BB6CA7E2794@anwaelte.de>
  • Sender: owner-council@xxxxxxxxxxxxxx

>>Can I ask we sort of formalize our work on the policy/implementation and
this subject in a subgroup that produces concrete >>proposals for the
Council?

This sounds like a sensible suggestion to me, Thomas.

All the best, Maria


On 7 December 2012 21:41, Thomas Rickert <rickert@xxxxxxxxxxx> wrote:

> All,
> this is a very good and healthy discussion. To me, the question is, how do
> we take this topic kicked off by Volker, which is partially congruent with
> the issue Jeff (and his colleagues) have been working on, forward.
>
> Does the Council wish to react to this specific instance? Do we wish to
> approach this more generally?
>
> With the new season that has been announced to have started at ICANN there
> might be an opportunity (I hope) to improve the way we work and interact
> inside ICANN. There are multiple dimensions to what Volker described
> (although there are other, comparable cases, too), namely the (lack of)
> interaction by the Council with the CEO, the Board, the GNSO and individual
> groups in the GNSO. There is no simple catch-all solution to all these
> areas and each of the aforementioned needs to be approached differently.
>
> However, what makes me worry is that the reason for the symptoms we see
> might be the fact that the GNSO is perceived to be ineffective. Thus, I
> would even go further than Jonathan and say that we need to put the GNSO
> and its Council in as ordered a state as possible. This is certainly easier
> said than done, but I guess if the Council works quicker and (I know I am
> repeating myself here) uses all the tools it has available, not only PDPs
> working towards Consensus Policies, to adequately respond to the tasks that
> are in its remit,
>
> - there will be less reason for individual groups to try to bypass the
> GNSO Council and
> - the CEO and Board and maybe even the GAC might be more immune against
> attempts to bypass the system.
>
> Can I ask we sort of formalize our work on the policy/implementation and
> this subject in a subgroup that produces concrete proposals for the Council?
>
> Thanks,
> Thomas
>
>
>
> Am 03.12.2012 um 14:52 schrieb Jonathan Robinson <
> jonathan.robinson@xxxxxxxxxxx>:
>
> Thanks Mason,****
>
> Your commitment to working on solutions and through them to improving
> reality and perceptions is appreciated, by me at least!****
>
> I do believe in your point, we as a Council need to put our own house (or
> should that be houses?) in as ordered a state as possible.****
> To me, this means working effectively with all on the Council and also
> outwardly towards and within our respective SGs.****
>
> Thanks.****
>
> Jonathan.****
>
>
>
> *From:* owner-council@xxxxxxxxxxxxxx [mailto:owner-council@xxxxxxxxxxxxxx]
>  *On Behalf Of *Mason Cole
> *Sent:* 30 November 2012 17:32
> *To:* Maria Farrell
> *Cc:* Volker Greimann; council@xxxxxxxxxxxxxx
> *Subject:* Re: [council] Discussion kick-off on BC/IPC strawman proposal
> as blogged by Fadi****
> ** **
> I agree with Volker's concerns too an find them to be well stated.****
> ** **
> Jeff's email regarding policy vs. implementation is on target as well.
>  Unfortunately, the community has looked for and found ways to outright
> circumvent the processes we all agreed to for establishing policy when
> those processes don't suit them.  Doing so robs us all of predictability,
> which I know is of little concern to some, but is very important to most.
>  The sooner we stop playing these games the better.****
> ** **
> In Toronto, we heard again accusations that the GNSO is broken, that it
> takes too long to develop policy, that confidence is lacking.  Speaking for
> myself, I don't believe that's correct, but the perception remains.  My
> belief is we have a duty to the council and to the community to address
> that head on and improve our performance.  We can, for example, improve the
> PDP timeline, not propose policy that has little chance to come into effect
> and thus waste our and staff's time, be respectful of the workload the
> council can actually carry, and set priorities.  Councilors and others have
> discussed these issues before and we have yet to see a good result, but,
> blame the optimist in me, we're all smart people and if we build some trust
> and work together, we can take people by surprise and make some changes for
> the better.  ****
> ** **
> Until we do, I'm concerned we will continue to see process freelancing
> like this, which may be a short-term gain for some but will continue to
> erode the GNSO model -- that would indeed be a disappointing outcome for
> the ICANN model we all seem to support.****
> ** **
> ** **
> On Nov 29, 2012, at 11:27 AM, Maria Farrell wrote:****
>
>
> ****
>
> Volker,
>
> Thank you very much. I share many of your concerns, particularly regarding
> this 'extra-judicial' process'; its secrecy and its imbalance.
>
> I would very much like to have clarity on what the role of the GNSO
> Council, and the GNSO more broadly, should now be.
>
> While I wish to be as constructive as possible regarding the substance of
> any new proposals formally presented to the GNSO, I do not wish for the
> GNSO to be asked to rubber-stamp the outcomes of a flawed process.
>
> I look forward to learning more about these proposals, including the
> publication of - at a minimum - who was involved in drawing them up, and
> what process was invoked to ensure transparency, participation and balance.
>
>
> All the best, Maria****
> On 28 November 2012 18:24, Volker Greimann <vgreimann@xxxxxxxxxxxxxxx>
> wrote:****
>
> Dear fellow councillors,
>
> frankly, I do not like most of what I am seeing regarding the latest
> BC/IPC demands. The new proposals re-open and significantly expand upon
> carefully developed and agreed upon compromise positions beyond their
> original scope and intent at the last minute and more significantly,
> outside the established policy making mechanisms. Such a precedent will
> only serve to open the floodgates for any community or stakeholder group to
> reopen any nominally closed and agreed process to push their agenda just a
> little beyond what the community had already agreed upon.
>
> We should consider the ramifications of the CEO getting involved in what
> easily could be viewed as policy making decisions and that to me should be
> the focus of the council now as we look to provide feedback to Fadi about
> his strawman and what implications it would have on future policy
> development.
>
> While I welcome the more hands-on and practical approach of our new CEO,
> it would be helpful to have more detailed information on how ICANN staff
> and Fadi arrived at the conclusion that most of these positions are
> implementation issues rather than policy. However, even if it were
> implementation rather than policy, this does not mean these suggestions
> should be implemented without proper process and especially if the majority
> of the community is in disagreement. Just because you can does not mean you
> should.
>
> These proposals need to be vetted by the community, namely the GNSO
> Council. To quote Steve Crocker from the Toronto public forum:
>
> "Three more items. The rights protection in new gTLDs. The Intellectual
> Property Constituency and business constituency reached consensus on
> further mechanisms for new gTLD rights protection and agreed to socialize
> these to the rest of the GNSO AND THE BOARD LOOKS FORWARD TO receiving
> input on these suggestions FROM the GNSO. So that is our plan, so to speak,
> WHICH IS WE WILL CONTINUE TO LISTEN AND WAIT FOR THIS TO COME UP"
>
> From what I have seen, the strawman proposal was developed by the IPC and
> the BC together with ICANN staff. Others made themselves available to
> discuss them, but it does not seem accuracte to say they actually developed
> the proposals. It is now our job as the GNSO council to weigh in and make
> our opinions on these proposals clear. To kick this process off, I will
> make the first move:
>
> -Blocking (aka "LPR"): While not directly included in the straw man, I
> understand this is still on the table. The paper on this proposal is well
> written and does an excellent job of totally blocking out the actual harms
> the implementation of this proposal would do. Its arguments only take into
> account other trademark holders that may apply in the sunrise period whose
> rights would naturally not be affected. No mention however is made of other
> legitimate potential registrants whose rights to a non-infringing
> registration after the sunrise phase would be completely eliminated. These
> include people with the same name as the mark, trademark holders not
> participating in the sunrise for whatever reason (newer trademark than
> permitted, lack of prior knowledge, etc) or companies without eligible
> trademarks. Frankly, only TM-holders that would otherwise participate in
> the Sunrise would think this is a good idea. There will likely be a lot of
> money to be made by implementing this demand but this is not good policy.
>
> -Claims 2: The extension of Trademark Claims is a service except for a
> very small part of the community for which there is no need and that will
> only serve to scare away otherwise legally eligible registrants, slow the
> registration process and drive up costs of registrations. As many of the
> new TLDs will initially have a very small market such restrictions will
> decrease the customer base even further.
> Furthermore, the description of the proposal as  "voluntary" seems to
> fundamentally misrepresent the nature of the proposal, since it will be
> anything but voluntary for registrants, registries and registrars. The only
> parties for whom the optional nature of this proposal applies are its sole
> beneficiaries.
> This proposal also does not take into account in any way how the technical
> systems of each individual registrar need to be adapted to set this system
> up. Having to implement a 60 day temporary system that will have light use
> (Regular claims) is simpler than a system that will have many more commands
> running through it and many more TLDs (as it will last for 1 year).
> Finally, the idea that registrars and registries will have to build these
> systems at their own cost and risk with no guarantee of compensation for
> their use as Rights Holders could opt out is not appropriate as it creates
> a definite financial burden for registries and registrars to alleviate a
> potential burden resulting from the presumed need for protection against
> infringing registrations.
>
> -Scope: This proposal is effectively a multiplier of the above issues,
> i.e. every problem resulting from the above proposals will be multiplied by
> up to 50 strings per TMCH entry. I also have come to understand that UDRP
> decisions are not always flawless or beyond reproach as many have been
> successfully overturned in court, so basing a blocking mechanisms on UDRP
> decisions seems like an overreach (again).
>
> -Notice: Of all the new demands put on the table by the IPC and the BC,
> the only one that I can support without issues is the Sunrise Notice
> Requirement. This is pure implementation, and makes sense both from a
> marketing as well as a RPM standpoint. The rest are mostly overreach to
> benefit a single interest group to the detriment of all others.
>
> Of course I understand the desire of users of the TMCH to protect their
> rights against infringements but the proposed measures must end exactly at
> the point where they begin to infringe upon the legitimate rights rights of
> others. Of course, there is nothing to prevent any registry from
> implementing any of these demands voluntarily, but as policy, I heartily
> disagree with both the process and format in which these proposals have
> been suggested and discussed as well - to a large degree - their content.
>
> Like I indicated above, this is a topic that needs to be discussed on our
> level and given the limited time on our schedules during the monthly
> council calls and the urgency of the matter, I would like to kick off the
> discussion with this paper.
>
> Best regards,
>
> Volker Greimann****
> ** **
> ** **
>
>
> ___________________________________________________________
> Thomas Rickert, Rechtsanwalt
> Schollmeyer &  Rickert Rechtsanwaltsgesellschaft m.b.H. (i.e. law firm)
> Geschäftsführer / CEO: Torsten Schollmeyer, Thomas Rickert
> HRB 9262, AG Bonn
>
> Büro / Office Bonn:
> Kaiserplatz 7-9, 53113 Bonn, Germany
> Phone: +49 (0)228 74 898 - 0
>
> Büro / Office Frankfurt a.M.:
> Savignystraße 43, 60325 Frankfurt, Germany
> Phone: +49 (0)69 714 021 - 56
>
> Zentralfax: +49 (0)228 74 898 - 66
>
> mailto: rickert@xxxxxxxxxxx
> skype-id: trickert
> web: www.anwaelte.de
>
>


<<< Chronological Index >>>    <<< Thread Index >>>