ICANN ICANN Email List Archives

[gnso-vi-feb10]


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

Re: [gnso-vi-feb10] request -- documenting BRU2 - minority opinion

  • To: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
  • Subject: Re: [gnso-vi-feb10] request -- documenting BRU2 - minority opinion
  • From: "Mike O'Connor" <mike@xxxxxxxxxx>
  • Date: Tue, 13 Jul 2010 09:56:20 -0500

hi all,

i've posted Keith's draft on the wiki -- here's the link;

        https://st.icann.org/vert-integration-pdp/index.cgi?bru2_proposal

let me know where i should insert what, and i'll add whatever parts of Kathy's 
stuff y'all agree to.

hint -- i'm going to build the poll by cutting and pasting from the wiki page, 
so it would be good to get that stuff inserted in the right place(s)...

thanks,

mikey


On Jul 13, 2010, at 8:37 AM, Neuman, Jeff wrote:

> All,
>  
> I do not think we should be including minority opinions in every single 
> document.  The fact is that the molecule (or list of atoms) from that group 
> is just another proposal.  Proposals do not have minority opinions.  Just 
> people who support and do not support the proposal.  If we do a minority 
> opinion for this proposal, then minority opinions will need to be included 
> for all the other proposals that came out.  The point was to represent the 
> different proposals.  In addition, Kathy has labeled this as a “strong 
> minority position”.  How can a position held by 1 person out of 10 be 
> classified as “strong”.  Granted it is a strongly held belief of 1 person, 
> but that does not mean a “strong minority position.”
>  
> Lets not overcomplicate this entire thing.  Lets lay out all the proposals, 
> indicate the level of support overall from the VI-WG in general.  
> 
> That is just my opinion, but of course I welcome minority opinions on my 
> opinion.
>  
> Jeffrey J. Neuman 
> Neustar, Inc. / Vice President, Law & Policy
> 
> The information contained in this e-mail message is intended only for the use 
> of the recipient(s) named above and may contain confidential and/or 
> privileged information. If you are not the intended recipient you have 
> received this e-mail message in error and any review, dissemination, 
> distribution, or copying of this message is strictly prohibited. If you have 
> received this communication in error, please notify us immediately and delete 
> the original message.
>  
>  
> From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-feb10@xxxxxxxxx] On 
> Behalf Of Kathy Kleiman
> Sent: Tuesday, July 13, 2010 8:32 AM
> To: Drazek, Keith; Mike O'Connor; Gnso-vi-feb10@xxxxxxxxx
> Subject: RE: [gnso-vi-feb10] request -- documenting BRU2 - minority opinion
>  
> Hi All,
> After yesterday’s call, I am not sure whether and in what form the Brussels 
> work will be going forward.  But in the interest of completeness, I wrote up 
> the minority voice (me) in the Brussels 2  group (BRU2). In particular, we 
> developed a long list of compliance, detection and monitoring requirements 
> (as part of the majority BRU2, I had thought. I see it in our notes, but not 
> in the write-up).
>  
> The minority opinion is attached, and it could be inserted after “6. 
> Compliance and Enforcement,” and before the Questions section.  Tx to Keith 
> for writing up the main position.
>  
> Best,
>  
> Kathy Kleiman
> Director of Policy
> .ORG The Public Interest Registry
> Direct: +1 703 889-5756  Mobile: +1 703 371-6846
>  
> Visit us online!
> Check out events & blogs at .ORG Buzz!
> Find us on Facebook | dotorg
> See the .ORG Buzz! Photo Gallery on Flickr
> See our video library on YouTube
>  
> CONFIDENTIALITY NOTE:
> Proprietary and confidential to .ORG, The Public Interest Registry.  If 
> received in error, please inform sender and then delete.
>  
>  
>  
> From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-feb10@xxxxxxxxx] On 
> Behalf Of Drazek, Keith
> Sent: Thursday, July 08, 2010 1:55 PM
> To: Mike O'Connor; Gnso-vi-feb10@xxxxxxxxx
> Subject: RE: [gnso-vi-feb10] request -- documenting the current state of 
> "Brussels proposals"
>  
> Mikey, per your request, here’s the recap from Brussels Option #2 (BRU2) and 
> responses to the questions you posed. Other members of the BRU2 sub-group 
> should review and edit as needed. I’m submitting this in my personal capacity 
> as note-taker for the group, not as an advocate. Questions/comments/edits 
> welcome. Thanks, Keith
>  
> 1. LIMITS DO NOT APPLY ACROSS TLDS
> A registry operator or registry services provider that does not distribute 
> its own TLD should not be restricted from acting as a registrar in other 
> TLDs. An existing registrar should not be prohibited from becoming a new TLD 
> registry just because it sells other TLDs. The potential harms of registry 
> sharing data with an affiliated reseller or friendly registrar can be 
> addressed via contract and ICANN compliance and enforcement mechanisms, 
> provided resources and commitment are present. The benefit of new entrants, 
> including existing registrars, outweighs the potential harms from 
> cross-ownership if no self-distribution is permitted.
>  
> 2. CONTROL/OWNERSHIP
> Cross-ownership up to 100% is permitted provided there is no distribution of 
> own TLD. An existing registrar should be permitted to become a new TLD 
> registry and own up to 100% provided they don't act as their own registrar. 
> Separation of functionality and no self-distribution make restrictions on 
> cross-ownership unnecessary provided ICANN enforces contracts.
>  
> 3. OWNERSHIP LIMITS
> No ownership limit if cross-owned entity doesn't distribute its own TLD. De 
> minimus limit (5%) if cross-owned entity distributes own TLD.
>     
> 4. EXCEPTIONS
> Exceptions should be allowed for single-registrant/single user, orphaned 
> TLDs, and possibly others TBD. A procedure should be established for 
> applicants to request exceptions based on business model and to ensure 
> ability to take TLD to market if no other registrars agree to offer and/or 
> market the TLD.
>  
> 5. REGISTRY SERVICE PROVIDERS
> Registry Service Providers should have the same restrictions as Registry 
> Operators.
>  
> 6. COMPLIANCE AND ENFORCEMENT
> We spent a significant portion of our time discussing compliance, audit, and 
> enforcement procedures. Our group felt that a "serious" structure would be 
> required, but would be capable of deterring bad actors with significant but 
> tiered penalties.
>  
> Questions:
>  
> What is the best way to prevent gaming in a cross-owned entity -- percentage 
> ownership caps, restrictions on control, both or something else?
>  
> ·         BRU2 maintains and strictly enforces functional separation of 
> registries and registrars and equal access requirements.
> ·         BRU2 prevents cross-owned entities from selling registrations in 
> their own TLD, except in SRSU and orphaned TLD cases.
> ·         BRU2 prohibits a registry from owning or controlling more than a de 
> minimus share (5%) of a registrar distributing its own TLD.
> ·         BRU2 allows 100% cross-ownership provided there is no 
> self-distribution.
> ·         BRU2 recognizes the need for an effective compliance and 
> enforcement regime, including severe penalties for violators.
>  
> Do the benefits of increased competition (registrars becoming registries or 
> back-end service providers) outweigh the potential risks of gaming from a 
> cross-owned entity, or vice-versa?
>  
> ·         BRU2 considers the benefits of increased competition, specifically 
> allowing registrars to become registries, as more valuable than the potential 
> risks of gaming from a cross-owned entity if that cross-owned entity was also 
> prohibited from self-distribution.
> ·         BRU2 recognizes the need for an effective compliance and 
> enforcement regime, including severe penalties for violators, and that such a 
> regime would adequately address the risks of gaming and data-sharing.
>  
> Common ownership
>  
> Should a registry be able to own a registrar, and vice versa, provided it 
> doesn't distribute its own TLD?
>  
> ·         Yes, BRU2 says 100% cross-ownership is allowable if 
> self-distribution is prohibited..
>  
> What is an acceptable level of cross-ownership (0 - 100%) if 
> self-distribution is permitted?
>  
> ·         BRU2 says de minimus (5%) is allowable when self-distribution is 
> permitted.
>  
> What is an acceptable level of cross-ownership (0 - 100%) if 
> self-distribution is prohibited?
>  
> ·         BRU2 says 100% cross-ownership is allowable if self-distribution is 
> prohibited.
>  
> Control 
>  
> Should a registry be able to control a registrar, and vice versa, provided it 
> doesn't distribute its own TLD?
>  
> ·         BRU2 says yes, 100% cross-ownership and control is allowed with no 
> self-distribution.
>  
> Absent an arbitrary restriction on percentage of cross-ownership, what 
> constitutes control?
>  
> ·         BRU2 did not address the definition of control.
>  
> What restrictions should be put in place to prevent control?  Do these vary 
> if self-distribution is prohibited?
>  
> ·         BRU2 did not address restrictions on control.
>  
> Enforcement and compliance
>  
> Is ICANN capable of enforcing contract compliance to prevent gaming in a 
> cross-owned entity?
>  
> ·         BRU2 assumes that ICANN is capable of enforcing contract 
> compliance, provided the rules and restrictions are clearly defined.
>  
> Scope
>  
> Should the scope of ICANN contracts be increased?
>  
> ·         BRU2 identified the need for expanded/enhanced contractual language 
> to prevent gaming and data-sharing.
>  
> Specifically, should Registry Service Providers be required to enter into 
> contracts with ICANN?
>  
> ·         BRU2 said cross-ownership and self-distribution restrictions should 
> be extended to Registry Service Providers, but did not recommend new 
> contracts with ICANN for those entities.
>  
> Should other entities (eg Resellers) also be required to enter into contracts 
> with ICANN?
>  
> ·         BRU2 did not consider or recommend reseller contracts with ICANN.
>  
> Exceptions to cross-ownership and self-distribution restrictions
>  
> Permitted for Single-Registrant, Single-User (SRSU) TLDs?
>  
> ·         BRU2 allows an exception for SRSU TLDs.
>  
> Permitted for "orphaned" TLDs that can't get registrar distribution?
>  
> ·         BRU2 allows an exception for orphaned TLDs.
>  
> Permitted for "community" TLDs?
>  
> ·         BRU did not address a specific exception for “community” TLDs.
>  
> Should there be numeric caps for any or all of these?
>  
> ·         BRU2 did not address specific numerical caps for exceptions.
>  
> Interim solution
>  
> Should the results of this first-phase VI-WG PDP be limited to the first 
> round of new TLDs only?
>  
> ·         BRU considers the first phase of the VI-WG PDP as applying only to 
> the first round of new TLDs.
>  
>  
>  
> From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-feb10@xxxxxxxxx] On 
> Behalf Of Mike O'Connor
> Sent: Thursday, July 01, 2010 10:08 PM
> To: Gnso-vi-feb10@xxxxxxxxx
> Subject: [gnso-vi-feb10] request -- documenting the current state of 
> "Brussels proposals"
>  
> hi all,
>  
> one of the requests that came out of our call today was for a summary of each 
> of the "Brussels proposals" that we developed during the Saturday meeting 
> (and then refined through lots of hallway conversation thereafter).  as i 
> mentioned on the call, those summaries will have to come from the groups 
> themselves, as Roberto and i were floating back and forth between the groups 
> and wouldn't be able to do a good job of preparing the summaries.
>  
> could each of the groups document the current state of their views and post 
> them to the list?  
>  
> another request -- could the RACK+ folks do the same?  it would be nice to 
> create another version of Kathy's matrix so that we can set all these side by 
> side.
>  
> to aid that process, here's a series of questions that i've lifted from 
> various places that you all can use to structure your summaries.  it's a 
> blend of atoms and questions and the goal is to get to principles that 
> perhaps we can rally around.  note the cool Capitalization so that it can be 
> used as the basis of a real document.  please try to structure your summary 
> around these if you can.
>  
> thanks,
>  
> mikey
>  
> - - - - - -
>  
> Questions:
>  
> What is the best way to prevent gaming in a cross-owned entity -- percentage 
> ownership caps, restrictions on control, both or something else?
>  
> Do the benefits of increased competition (registrars becoming registries or 
> back-end service providers) outweigh the potential risks of gaming from a 
> cross-owned entity, or vice-versa?
>  
> Common ownership
>  
> Should a registry be able to own a registrar, and vice versa, provided it 
> doesn't distribute its own TLD?
>  
> What is an acceptable level of cross-ownership (0 - 100%) if 
> self-distribution is permitted?
>  
> What is an acceptable level of cross-ownership (0 - 100%) if 
> self-distribution is prohibited?
>  
> Control 
>  
> Should a registry be able to control a registrar, and vice versa, provided it 
> doesn't distribute its own TLD?
>  
> Absent an arbitrary restriction on percentage of cross-ownership, what 
> constitutes control?
>  
> What restrictions should be put in place to prevent control?  Do these vary 
> if self-distribution is prohibited?
>  
> Enforcement and compliance
>  
> Is ICANN capable of enforcing contract compliance to prevent gaming in a 
> cross-owned entity?
>  
> If the answer is "no," what steps would ICANN need to take to overcome this 
> problem?
>  
> If the answer is "no," what steps would ICANN need to take to demonstrate an 
> ongoing commitment to fulfilling this role?
>  
> Scope
>  
> Should the scope of ICANN contracts be increased?
>  
> Specifically, should Registry Service Providers be required to enter into 
> contracts with ICANN?
>  
> Should other entities (eg Resellers) also be required to enter into contracts 
> with ICANN?
>  
> Exceptions to cross-ownership and self-distribution restrictions
>  
> Permitted for Single-Registrant, Single-User (SRSU) TLDs?
>  
> Permitted for "orphaned" TLDs that can't get registrar distribution?
>  
> Permitted for "community" TLDs?
>  
> Should there be numeric caps for any or all of these
>  
> Interim solution
>  
> Should the results of this first-phase VI-WG PDP be limited to the first 
> round of new TLDs only?
>  
> - - - - - - - - -
> phone    651-647-6109  
> fax                           866-280-2356  
> web        www.haven2.com
> handle   OConnorStP (ID for public places like Twitter, Facebook, Google, 
> etc.)
>  

- - - - - - - - -
phone   651-647-6109  
fax             866-280-2356  
web     http://www.haven2.com
handle  OConnorStP (ID for public places like Twitter, Facebook, Google, etc.)



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

Privacy Policy | Terms of Service | Cookies Policy