[bc-gnso] RE: Revised Draft BC Position on Establishing Standard Contract for UDRP Providers

[Marilyn Cade]

I am in agreement with Sarah and Mike. and, yes, Mike, thanks for that reminder! I still have the transcripts from part of that session! I recall one graduate student who told us that IPR shouldn't exist on the Internet! 



From: michael at palage.com
To: sarah.b.deutsch at verizon.com; philip.sheppard at aim.be; pcorwin at butera-andrews.com; bc-gnso at icann.org
Subject: RE: [bc-gnso] RE: Revised Draft BC Position on Establishing Standard Contract for UDRP Providers
Date: Wed, 20 Oct 2010 09:28:32 -0400



















Sarah,

 

I share your concerns.   In fact this type of rigid “contract”
language is what stalled individual ccTLD participation within the ICANN
process for so long. It was only after ICANN adopted an accountability
framework document that more participation/recognition occurred.

 

I think Phil’s concerns can be address without the hard
coded “contract” language. Having dealt with IGOs over the past
several years I can tell you that getting them to sign “contracts” can
be a complicated process. Therefore making WIPO sign a UDRP provider contract
is likely to run into some complications that would likely draw the
support/empathy of the GAC. Do we really want to pick that fight? 

 

Having dealt with WIPO during the past 11 years ago (remember that
first UDRP meeting at Georgetown Sarah/Marilyn – seems almost like
yesterday) I think as a trustee of this process WIPO would be in agreement about
ensuring some  uniformity of the rules. So let’s figure how to make
them part of the solution, instead of making them part of the problem.

 

Just my two cents.

 

Best regards,

 

Michael 

 





From:
owner-bc-gnso at icann.org [mailto:owner-bc-gnso at icann.org] On Behalf Of Deutsch,
Sarah B

Sent: Wednesday, October 20, 2010 8:50 AM

To: 'Philip Sheppard'; 'Phil Corwin'; bc-gnso at icann.org

Subject: RE: [bc-gnso] RE: Revised Draft BC Position on Establishing
Standard Contract for UDRP Providers





 

My concern is that by includng the words "contract" this
will be misread by ICANN as a green light to go forward with regulation having
nothing to do with these parties' qualifications even if the idea of
an "other mechanism" is also included as an option.  

 

The following language addresses my concern but keeps the same
meaning Phil originally intended:

 

The
Business Constituency (BC) cannot support approval of this or any other UDRP
accreditation application at this time on the grounds that no new UDRP
providers should be accredited until ICANN implements with
all accredited providers a standard mechanism for establishing
uniform rules and procedures and flexible means of delineating and enforcing
arbitration provider responsibilities.



 





In the rest of the document, I'd recommend replacing
"contact" with "standard mechanism."  







Thanks,







Sarah







Sarah
B. Deutsch 

Vice President & Associate General Counsel 

Verizon Communications 

Phone: 703-351-3044 

Fax: 703-351-3670 



 



 







From: Philip Sheppard [mailto:philip.sheppard at aim.be]


Sent: Wednesday, October 20, 2010 3:29 AM

To: 'Phil Corwin'; Deutsch, Sarah B; bc-gnso at icann.org

Subject: RE: [bc-gnso] RE: Revised Draft BC Position on Establishing
Standard Contract for UDRP Providers



I
share Sarah's concern but agree with Phil that our current language is
flexible:





 





The
Business Constituency (BC) cannot support approval of this or any other UDRP
accreditation application at this time on the grounds that no new UDRP
providers should be accredited until ICANN implements a standard contract
with all accredited providers or
develops some other mechanism for establishing uniform rules
and procedures and flexible means of delineating and enforcing arbitration
provider responsibilities. (emphasis added)



Philip

 



 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/bc-gnso/attachments/20101020/b8cc267b/attachment.html>