ICANN ICANN Email List Archives

[bc-gnso]


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

Re: [bc-gnso] pressing the BC recommendations for dot-brand TLDs

  • To: "Berry Cobb" <berrycobb@xxxxxxxxxxxxxxxxxxx>
  • Subject: Re: [bc-gnso] pressing the BC recommendations for dot-brand TLDs
  • From: "Mike O'Connor" <mike@xxxxxxxxxx>
  • Date: Fri, 28 Jan 2011 07:24:51 -0600

hi all,

as the joyously "ex" co-chair of the VI working group, i would like to heartily 
second everything Berry has said in this note.  

the bright-line definition is crucial for any workable proposal.  i think Kurt 
alluded to this problem during his "what does ICANN monitor?" comments to us in 
Washington DC.  

mikey


On Jan 27, 2011, at 6:11 PM, Berry Cobb wrote:

> Thank you Steve for updating the BC.  Adding to Steve’s points......
>  
> The reason ICANN Staff, experienced Registry Operators, & some other 
> stakeholders will not sign on for “carve outs” is because there is NO BRIGHT 
> LINE DEFINTION FOR A BRAND.  In the context of TLDs what is a BRAND?  Is it 
> because they are Fortune 1000 company?  Do they own Trademarks in the USA or 
> Europe?  Do they earn over $2 billion dollars a year in revenue?  Where do we 
> start to draw the line?  If some sort of bright line exists, then please 
> share.  If it exists then I doubt we would see the pushback experienced today 
> or during the VI WG.
>  
> In my opinion, if the BC and IPC ever expect any headway regarding the 
> “dot-brand” concept, then we MUST stop using “DOT-BRAND.”  Within my short 
> ICANN career, one thing I’ve noticed is that a BRAND is a loaded and charged 
> word among the community.  If the BC supports “carve outs,” then the case 
> must be presented very specifically and using BRAND is not the way forward.  
> Framing this concept should embrace the use of “Single Registrant” only.  
> Notice how Single User & Multiple User is omitted?  The main reason SRSU 
> gained support during VI is only because of the Single Registrant component 
> and it’s limitations in how domains were registered and used.  Anything 
> beyond SRSU was poking a stick at a tiger.  I remind everyone the reasoning 
> for SRSU & SRMU is only because BRAND could not be defined.
>  
> The following is how I view the possible scope of a “Single Registrant” TLD:
> ·         Any 2nd, 3rd, 4th,5th level domains registered are owned and 
> operated only the by the entity that owns the TLD
> ·         All WHOIS information for registered 2nd level domains reflect the 
> entity that owns the TLD
> ·         If the entity chooses to deploy content or allow use by others 
> external to them, the entity is still responsible or liable for that domain 
> and its content
> ·         The entity may register its own domains without equivalent access 
> to other Registrars (RAA concepts should still be used, but ZERO registration 
> fees to ICANN)
> ·         The entity may deploy and use its 2nd level domains how it sees fit 
> and the Reserve Names list no longer applies
> ·         The entity can ”warehouse” domains because it owns the domains
> ·         The entity is required to provide Zone File Access for monitoring 
> and compliance
> ·         I am sure there are other elements to define the boundary here….
> ·         Therefore, much of the Code of Conduct is meaningless to a “Single 
> Registrant” TLD
>  
> So, using the Cannon example from Steve below, the above “Single Registrant” 
> concepts can satisfy the “carve outs” defined by the BC.  If Cannon chose to 
> register 2nd level domains to their customers, partners & vendors, but it is 
> still designated as the Registrant, then the Single Registrant carve outs 
> still apply.  What about the Facebook use case?  The one batted around most 
> often is berrycobb.facebook.  If Facebook chooses to register and supply me a 
> domain and the defined “Registrant” remains as Facebook and Facebook is 
> willing to take on the risk for the content I deploy on berrycobb.facebook, 
> then I imagine the stakeholders listed above will probably not have much 
> issue with “Single Registrant carve outs.”  This is the essence to “Single 
> Registrant, Single User” concept.
>  
> Conversely, any hope for consensus in VI quickly broke down with a use case 
> for “Single Registrant Multiple Users.”  Using Facebook as an example 
> again…..if FB chose to allow me to register berrycobb.facebook, but instead I 
> am designated as the Registrant, Facebook now competes head to head with 
> other Registrars & Registries in the domain registration business.  This is 
> the crux of the debate.  Where does one draw the line as Facebook being a 
> social media “BRAND” vs. Facebook a social media “BRAND” that also chooses to 
> register domains and compete in the domain market.  If any exceptions or 
> carve outs are given to FB because they are designated a “BRAND”, then 
> wouldn’t other entities competing for the same registration dollar be at a 
> competitive disadvantage because they are bound by the full extent of the 
> Code of Conduct? 
>  
> Most will recall that I did not support the sections of the BC Position that 
> called for these SR exceptions, because it did not provide a bright line 
> solution for the community.  Rather, it called for nebulous, self-serving, 
> carve outs that only provided confusion.  I hope we do not repeat the same 
> mistake for future BC position statements.  I’m starting to believe that no 
> position is better than a half-baked one.
>  
> With all this said however, I CAN support a “Single Registrant” concept, just 
> not as we have it defined in our position today.  There is no doubt that 
> without some sort of designation for single registrant TLDs the Code of 
> Conduct will certainly interfere with operations and may in fact deter some 
> applications.  The challenge is that the “Single Registrant” type of TLD is 
> NOT defined in the Guidebook.  Until it is, then any exceptions will not make 
> the next AGB.  I am willing to join a team of BC members to develop a 
> specific proposal that not only benefits the BC, but benefits the entire 
> community by relieving confusion.
>  
> If we expect any momentum, the BC must come together and define a reasonable 
> solution that ICANN Staff and Community can embrace.  I am sure my fast-run 
> scope definition above has several holes.  So I welcome contributions to fill 
> them.  Gripes, complaints, & moans are also welcome if you feel I am way off 
> base.
>  
> Thank you, B
>  
>  
> Berry Cobb
> Infinity Portals LLC
> berrycobb@xxxxxxxxxxxxxxxxxxx
> http://infinityportals.com
> 720.839.5735
>  
> From: owner-bc-gnso@xxxxxxxxx [mailto:owner-bc-gnso@xxxxxxxxx] On Behalf Of 
> Steve DelBianco
> Sent: Thursday, January 27, 2011 12:11 PM
> To: 'bc - GNSO list'
> Subject: [bc-gnso] pressing the BC recommendations for dot-brand TLDs
>  
> To: BC Members
> Re:  ICANN Con call today regarding Registry Contracts
>  
> I joined a large con call today hosted by ICANN, to discuss new gTLD registy 
> agreement.  (see description at bottom of this note)
>  
> Berry Cobb and Jon Nevett were also on the call.
>  
> When we got to the Registry Code of Conduct, ICANN staff mentioned they had 
> received many comments on how this would or would not work for dot-brand 
> registries. 
>  
> At that point I brought up the BC concerns expressed in our Guidebook 
> comments filed 6-Dec in Cartagena.
>  
> I used the example of Canon, since they have said they may pursue a 
> dot-brand.  
> I said Canon might want to operate its own Registrar and restrict 
> registrations to its  own operating divisions, like copiers.canon  and 
> cameras.canon     
> And Canon might want to manage a big sub-domain of photographers using Canon 
> cameras, like [name].photos.canon
>  
> I said The Code of Conduct should not restrict dot-brands from using an owned 
> or closely affiliated registrar to register and manage names that it 
> controls.  (e.g., for divisions, product lines, locations, customers, 
> affiliates, etc. )
>  
> I gave  the BC recommendation to insert this clause into the Registry Code of 
> Conduct:
>  
> 4.  Nothing set forth in articles 1, 2, or 3 shall apply to a 
> single-registrant ('dot brand') Registry Operator acting with respect to user 
> data that is under its ownership and control, or with respect to conduct 
> reasonably necessary for the management, operations and purpose of the TLD.
>  
> An experienced registry operator on the call said our 'carve out' would allow 
> 'gaming' and abuse.  (they say that a lot).
>  
> ICANN Staff is very resistant to any 'carve-out' for dot-brands.  They oppose 
> any exception (or even a definition) for dot-brand.   
> Craig Schwartz said ICANN didn't want to get in the business of monitoring 
> Canon's copier business. ( I think that was the point of our recommendation — 
> we don't want ICANN getting involved in how a dot-brand allocates 
> registrations to entities it owns or controls)
>  
> Will discuss more on our Monday call, I hope.
>  
> --
> Steve DelBianco
> Executive Director
> NetChoice
> http://www.NetChoice.org and http://blog.netchoice.org
> +1.202.420.7482
>  
> Temporary Drafting Group Work Session on New gTLD Base Registry Agreement 
> Issues – To Be Held 27 January 2011
> by Craig Schwartz on January 14, 2011
> 
> The Temporary Drafting Group will hold a teleconference on 27 January 2011. 
> The issues open for drafting/discussion during the call will include:
> 
> Suggestions for additional language for Specification 9 (the Registry Code of 
> Conduct)
> Proposed modifications to conditions related to the termination of a registry 
> services agreement
> Suggestions for clarifications to provision requiring advance notice of 
> registry price increases
> Concepts for continued registry operations instrument to provide continuity 
> of services
> Results:
> 
> This is not a formal public consultation, but is intended to inform drafting 
> which might make up a later public consultation. Any results from the 
> Temporary Drafting Group will be included in documents that will be posted 
> for public comment. No results from the Group will necessarily be used in any 
> agreement drafts, but inputs from the Group will be considered by the ICANN 
> Staff in making recommendations relating to questions discussed or posed to 
> the Group.
> 
> Session:
> 
> This third Temporary Drafting Group session will be held via teleconference 
> on 27 January 2011 at 18.00 UTC (http://timeanddate.com/s/1xxz), and is 
> scheduled to last for 120 minutes.
> 
> Participation:
> 
> The Temporary Drafting Group was formed in early 2010 and announced in a 28 
> April 2010 blog post. If you would like to participate, please submit your 
> name to TDG-Legal@xxxxxxxxx, and we will provide you with information for the 
> call.
> 
>  
>  

- - - - - - - - -
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