Re: [gnso-irtp-b-jun09] Approaches discussed on Tuesday's call

["Mike O'Connor" <mike@xxxxxxxxxx>]

yup -- we've had this conversation before.  maybe it was in the last round.  i 
agree that a direct launch of the TDRP by a registrant doesn't work.  but i 
think where we wound up is that there needs to be *some* mechanism where a 
registrant can break out of the grip of an unresponsive registrar and escalate 
the problem.  perhaps we could leave that topic on the table?

mikey


On Feb 8, 2010, at 8:13 AM, Steele, Barbara wrote:

> I completely agree with James on this.  The contractual relationship for
> domain registrations is between the Registrar and the Registrant.
> Registries do not have insight into what those contractual relationships are
> and in the case of thin registries, have no information on the registrants
> and other contacts for a domain name.  Allowing "registrants" to come
> directly to the registry via the TDRP could very well open up the door for
> an increase in hijackings.  
> 
> 
> -------------------------------------------------------
> Barbara Steele
> Compliance Officer / Director of Policy
> VeriSign Naming Services
> 
> 
> -----Original Message-----
> From: owner-gnso-irtp-b-jun09@xxxxxxxxx
> [mailto:owner-gnso-irtp-b-jun09@xxxxxxxxx] On Behalf Of James M. Bladel
> Sent: Thursday, February 04, 2010 11:47 PM
> To: Erdman,Kevin R.
> Cc: IRTP B Mailing List
> Subject: RE: [gnso-irtp-b-jun09] Approaches discussed on Tuesday's call
> 
> 
> Kevin:
> 
> You are correct that TDRP is currently defined as a Registry / Registrar
> service, and I'm of the opinion that it should remain so.  
> 
> Opening up TDRP to registrants would be much more than a modification,
> it would represent a complete re-invention of the mechanism, and could
> have significant unforeseen consequences. (Example:  Fraudulent "Urgent
> Return" could be a new breed of hijacking...)
> 
> Fixing the existing policy so that it is more effective in facilitating
> Urgent Returns will enpower registrars to better serve their customers,
> and ideally eliminate the need for direct intervention by ICANN and
> other TDRP workarounds....
> 
> 
> Thanks--
> 
> J.
> 
> -------- Original Message --------
> Subject: RE: [gnso-irtp-b-jun09] Approaches discussed on Tuesday's call
> From: "Erdman, Kevin R." <Kevin.Erdman@xxxxxxxxxx>
> Date: Wed, February 03, 2010 1:24 pm
> To: "Mike O'Connor" <mike@xxxxxxxxxx>, "IRTP B Mailing List"
> <Gnso-irtp-b-jun09@xxxxxxxxx>
> 
> 
> From a procedural aspect, the TDRP may only be invoked by a Registrar,
> while
> the UDRP may only be invoked by a party possessing trademark rights
> (usually
> the Registrant or its authorized agent).
> If we are looking for a way to allow a Registrant to get an "urgent
> return"
> then it would appear appropriate to Allow a Registrant to use the
> "urgent
> return" modification of the TDRP (one reason that a Registrant currently
> may
> opt for going direct to ICANN is because of the delay in getting the
> Registrar to act under the TDRP). Query whether allowing Registrant
> participation in the TDRP is a "tune up" or a new/separate process...
> ____________________________________________________________________________
> _
> ___________________________
> Kevin R Erdman  T: 317.237.1029 | F: 317.237.8521 | C: 317.289.3934
> Intellectual Property, Internet, and Information Attorney, Registered
> Patent
> Attorney
> BAKER & DANIELS LLP WWW.BAKERDANIELS.COM 300 N. MERIDIAN STREET, SUITE
> 2700 |
> INDIANAPOLIS, IN 46204
> 
> 
> -----Original Message-----
> From: owner-gnso-irtp-b-jun09@xxxxxxxxx
> [mailto:owner-gnso-irtp-b-jun09@xxxxxxxxx] On Behalf Of Mike O'Connor
> Sent: Wednesday, February 03, 2010 8:51 AM
> To: IRTP B Mailing List
> Subject: Re: [gnso-irtp-b-jun09] Approaches discussed on Tuesday's call
> 
> 
> great work! gives us plenty to eschew on. 
> 
> i agree with your notion that we should tune up the TDRP rather than
> starting
> up a new/separate process. 
> 
> mikey
> 
> 
> On Feb 3, 2010, at 12:48 AM, James M. Bladel wrote:
> 
>> 
>> Team:
>> 
>> 
>> There were some interesting ideas and proposals raised on today's call,
>> so rather than risk losing them to Transcript Purgatory, I thought I'd
>> make an attempt at summarizing them here. Please let me know if I've
>> missed something from our discussions, or mis-characterized any points.
>> 
>> J.
>> 
>> **************
>> 
>> 
>> 1. The TRDP is a relatively little used method for disputing / undoing
>> inter-registrar Transfers.
>> a. For Registrants, especially those who are victims of
>> "hijacking," the process is too slow, and potentially expensive.
>> b. For Registrants and Internet Users, the Harm of a name resolving
>> to a disputed site (or not resolving at all) persists while the TDRP
>> proceeding is ongoing.
>> c. For Registrars, the TDRP is seen as too slow, resource
>> expensive, and could yield unpredictable outcomes.
>> d. Larger Registrars have developed informal procedures to work
>> together to rapidly reverse transfers that were erroneous or fraudulent.
>> But still wish to preserve a formal policy to escalate matters to the
>> Registry in the event that registrars cannot agree on the remedy. 
>> e. Some registered name holders have eschewed the TDRP and
>> Registrar contact entirely, and prefer to work directly with ICANN to
>> resolve disputed transfers.
>> f. Verisign has adopted it's own procedure under its Supplemental
>> Rules to (augment? replace?) the TRDP. Other registries may have
>> equivalent procedures, or may seek to develop them.
>> 
>> 
>> 
>> 2. The charter of this group asks "Whether a process for the urgent
>> return/resolution of a domain name should be developed."
>> a. The consensus of Tuesday's participants is that this is the
>> case, and that the WG is chartered to develop policy recommendations for
>> this procedure. (Council confirmation pending).
>> b. The group acknowledge a Staff Note that the TDRP is a topic in
>> future IRTP working groups, specifically IRTP-D. If appropriate, the
>> group would like to fold these in to the work of IRTP-B (Council
>> confirmation pending).
>> 
>> 
>> 3. The group discussed two approaches to outlining recommendations for
>> a new procedure:
>> a. Modify or adjust the TDRP to make it more useful and relevant in
>> scenarios where "urgent" return is required, such as incidents of
>> hijacking.
>> b. Create a new policy, separate from TDRP, to be employed
>> exclusively in the event of hijacking, while leaving the existing TDRP
>> unchanged.
>> 
>> 
>> Editorial: 
>> 1. I support the first assertion (1), for all the exemplaries listed in
>> (1a) through (1c), and evidenced by the various alternative, ad hoc, and
>> work-around methods listed in (1d) through (1f).
>> 
>> 2. Following from this, I support the proposal that this IRTP Working
>> Group should set out to recommend a new policy procedure that deals with
>> the shortcomings of TDRP (2a), and that we should add any additional
>> TDRP topics found in IRTP-D and beyond. This support presumes approval
>> of the Council.
>> 
>> 3. Finally, I believe the TDRP provides a foundation of the new policy
>> / procedure, and could be more effective in this area (along with its
>> current purpose) with modifications (3a) to expedite the proceedings and
>> reduce or eliminate the harm (as per Tim's suggestion that pre-transfer
>> Namerserver / DNS records be restored). 
>> 
>> Conversely, I am concerned that developing a separate procedure (3b),
>> separate from TDRP will create confusion and establish new boundary
>> conditions: First, determining which situations warrant the "new
>> process" versus the existing TDRP (When is urgency never required? Is a
>> hijack by a former Registrant or AC still a hijack?) 
>> 
>> Also, consider that once we have extracted from TDRP those elements that
>> are useful versus hijacking, then what remains in TDRP starts to overlap
>> with other dispute mechanisms (UDRP). Which could generate even more
>> confusion about the differences between "Transfer Disputes" and more
>> generalized "Domain Name Disputes."
>> 
> 
> - - - - - - - - -
> phone 651-647-6109 
> fax 866-280-2356 
> web www.haven2.com
> handle OConnorStP (ID for public places like Twitter, Facebook, Google,
> etc.)
> 
> 
> 
> ----------------------------
> ATTENTION:
> 
> To ensure compliance with applicable Internal Revenue Service
> Regulations,
> we inform you that any tax advice contained in this electronic message
> was
> not intended or written to be used, and cannot be used, for the purpose
> of
> avoiding penalties under the Internal Revenue Code.
> 
> 
> This message and all its attachments are PRIVATE and may contain
> information that is CONFIDENTIAL and PRIVILEGED.
> 
> If you received this message in error, please notify the sender by reply
> 
> e-mail and delete the message immediately.
> 
> 

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