ICANN ICANN Email List Archives

[gnso-vi-feb10]


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

RE: [gnso-vi-feb10] Law, Policing and Punishment aka compliance proposal, aka WIP draft collection

  • To: Volker Greimann <vgreimann@xxxxxxxxxxxxxxx>, "Gnso-vi-feb10@xxxxxxxxx" <Gnso-vi-feb10@xxxxxxxxx>
  • Subject: RE: [gnso-vi-feb10] Law, Policing and Punishment aka compliance proposal, aka WIP draft collection
  • From: Milton L Mueller <mueller@xxxxxxx>
  • Date: Wed, 23 Jun 2010 09:21:44 -0400

Huh? Of course compliance is essential. But (and I don't mean to sound 
contrarian) what matters to me is what people are being forced to comply with. 
Give me rules that protect consumers while facilitating open entry and business 
model innovation - then talk about how to make people comply with those rules. 
First things first.
--MM

> -----Original Message-----
> From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-
> feb10@xxxxxxxxx] On Behalf Of Volker Greimann
> Sent: Tuesday, June 22, 2010 4:01 PM
> To: Gnso-vi-feb10@xxxxxxxxx
> Subject: [gnso-vi-feb10] Law, Policing and Punishment aka compliance
> proposal, aka WIP draft collection
> 
> 
> Maybe we can try to approach the issue another way, by focussing on the
> one issue most of us can agree upon: Compliance.
> 
> Most of us can from what I see from discussions over the previous days
> with everyone I had the opportunity to steal a little time from, we so
> far agree that he most important issue is compliance and enforcement. We
> need a strong and well defined body of law (contract), a competent
> police force (compliance control team) and a tiered penalty system. Once
> we can agree on terms of such a system ownership or control percentages
> will become irrelevant. For many proponents, the topic of compliance
> seems to be the driving motive behind their desire to implement control
> limits even though many of the harms are entirely unrelated to VI and CO
> and can just as likely occur in scenarios of 0 % CO/VI.
> 
> I will only list the basic premise we all add to and therefore clearly
> mark the following as:
> 
> 
> WORK IN PROGRESS
> 
> 
> THE LAW:
> 
> To draw up the law, a codex of rules that applies to every contracted
> partner, from registry to RSP we first need to clearly define the harms
> we intend to prevent and the behavior patterns we believe to be
> undesirable. Extrapolating from these, our lawyer team-members, myself
> included, can adapt the contractual body to combat the harms more
> effectively than any ownership limitation could.
> 
> Pilfering shamelessly from the "back-room proposal", a separate contract
> of RSPs will have to be put in place clearly defining the roles and
> obligations of such service providers, as all parties need to be
> contractually bound by ICANN to allow policing.
> 
> Rather than focussing on separation percentages, let us focus in the
> text of the law on what we want to achieve/prevent and cast that into a
> text of rules. The contracts will of course require an inclusion option
> to allow revision after a reasonable time of review to either reduce or
> increase requirements.
> 
> As not all registries are created equally, we may want to considered a
> tiered system of application requirements, based on market power of the
> created or owning entity, as well as the designated purpose of the TLDS.
> For example, a SRSU TLD will need less stringent initial requirements
> than other x-owned entities.
> 
> 
> POLICE FORCE:
> 
>  From our meetings I have gathered that many believe that establishing
> an effective police force is the biggest problem. ICANN enforcement
> today is underfunded and understaffed. So we need to make sure that we
> hold Rod to his words given in this weeks introductory speech. Whatever
> we design, ICANN must put in place (and finance). The funds are there,
> but we will need to convince the board that they will have to dip into
> the sacred fund to put a compliance enforcement team worthy of its name
> in place. I agree with pessimists that will claim such a suggestion is
> impossible to get, but hearing various comments from the board and
> having the strong impression that ICANN staff can be persuaded that the
> exchange of cash for success of the program is possible, we need to
> hammer staff in the coming days with the unified demand of this WG: set
> aside some of the money currently sitting in the bank for a strong and
> competent enforcement team. This is heavy-duty lobbying, but united we
> can, nay, must do it.
> 
> As we all think that enforcement is lacking this needs to be done in
> either case, no matter what proposal you favor.
> 
> 
> PENALTIES:
> 
> As placeholder for further discussion, I am basing the penalty system on
> criminal justice systems:
> 
> Tier 0: Notice and warning: Small fine for minor violation
> 
> Tier 1: Fiscal penalty: Minor violations not fixed after notice period
> carrying a pecuniary penalty substantial enough to discourage active
> intent by nullifying all ill-gotten gains.
> 
> Tier 2: Doing Time: Repeated minor violations or more substantial
> violations reducing the available contingent for registrations to a
> percentage of the average over the past 12 months
> 
> Tier 3: Hard time: Temporary suspension of registration activity,
> possibility of cancellation of contract for RSP, prohibition of carrying
> TLD for registrar in case of severe breach of contract.
> 
> Tier 4: Death penalty: Permanent Suspension of entity from service,
> redelegation of all TLDs under management/deaccreditation for active
> intentional misconduct, repeated major breach of contract.
> 
> Other penalties may include but are not limited to obligatory audits,
> higher fees and more.
> 
> I invite everyone to review these ideas, and consider what to improve,
> change, adapt or reject (and why). I welcome all constructive criticism
> unless you are only interested in protecting your own market share by
> disallowing competition.
> 
> 
> --
> 
> Fur Ruckfragen stehen wir Ihnen gerne zur Verfugung.
> 
> Mit freundlichen Grusen,
> 
> Volker A. Greimann
> - Rechtsabteilung -
> 
> Key-Systems GmbH        Prager Ring 4-12                            Web:
> 66482 Zweibrucken                           www.key-systems.net
> <http://www.key-systems.net/>
> Tel.: +49 (0) 6332 - 79 18 50               www.domaindiscount24.com
> <http://www.domaindiscount24.com/>
> Fax.: +49 (0) 6332 - 79 18 51               www.ISPproxy.net
> <http://www.ispproxy.net/>
> Email: vgreimann@xxxxxxxxxxxxxxx <mailto:vgreimann@xxxxxxxxxxxxxxx>
> www.RRPproxy.net <http://www.rrpproxy.net/>
> 
> Geschaftsfuhrer: Alexander Siffrin
> Handelsregister Nr..: HR B 1861 - Zweibruecken
> Umsatzsteuer ID.: DE211006534
> 
> Der Inhalt dieser Nachricht ist vertraulich und nur fur den angegebenen
> Empfanger bestimmt. Jede Form der Kenntnisnahme, Veroffentlichung oder
> Weitergabe durch Dritte ist unzulassig. Sollte diese Nachricht nicht fur
> Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder
> telefonisch in Verbindung zu setzen.
> 
> --
> 
> Should you have any further questions, please do not hesitate to contact
> us.
> 
> Best regards,
> 
> Volker A. Greimann
> - legal department -
> 
> Key-Systems GmbH
> Prager Ring 4-12
> DE-66482 Zweibruecken
> Tel.: +49 (0) 6332 - 79 18 85
> Fax.: +49 (0) 6332 - 79 18 61
> Email: jpfeiffer@xxxxxxxxxxxxxxx
> 
> Web: www.key-systems.net / www.RRPproxy.net
> www.domaindiscount24.com / www.BrandShelter.com
> 
> Follow us on Twitter or join our fan community on Facebook and stay
> updated:
> www.key-systems.net/facebook
> www.twitter.com/key_systems
> 
> CEO: Alexander Siffrin
> Registration No.: HR B 1861 - Zweibruecken
> V.A.T. ID.: DE211006534
> 
> This e-mail and its attachments is intended only for the person to whom
> it is addressed. Furthermore it is not permitted to publish any content
> of this email. You must not use, disclose, copy, print or rely on this
> e-mail. If an addressing or transmission error has misdirected this e-
> mail, kindly notify the author by replying to this e-mail or contacting
> us by telephone.
> 
> 
> 
> 
> 
> 
> 
> 





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

Privacy Policy | Terms of Service | Cookies Policy