ICANN ICANN Email List Archives

[gnso-irtp-b-jun09]


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

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

  • To: "Michele Neylon :: Blacknight" <michele@xxxxxxxxxxxxx>, "Mike O'Connor" <mike@xxxxxxxxxx>
  • Subject: RE: [gnso-irtp-b-jun09] Approaches discussed on Tuesday's call
  • From: "Erdman, Kevin R." <Kevin.Erdman@xxxxxxxxxx>
  • Date: Mon, 8 Feb 2010 15:01:58 -0500

Michele, yes, Registrants can informally contact ICANN and get things
resolved.  I am not sure how well known this avenue is, or whether many
Registrants use it.  Also, it could become administratively challenging to
ICANN legal if a formal process is not implemented and transfer problems
increase (to0 many complaints to ICANN legal?  Perhaps staff may inquire?).
I brought up this aspect because this discussion started in reference to Part
D, where Part D includes the following issues:

"16. Whether dispute options for registrants should be developed and
implemented as part of the policy (registrants currently depend on registrars
to initiate a dispute on their behalf). (CR
14.0)
19. Whether requirements or best practices should be put into place for
registrars to make information on transfer dispute resolution options
available to registrants. (CR 16.0)"

I agree that opening the TDRP to Registrants opens a big can of worms.
However, if direct Registrant participation is not desired then I suggest
that something be added to provide more incentives and/or penalties to
Registrars in addressing Registrant concerns.  It is my opinion that the
reason some Registrants work around the TDRP is because of a perceived or
actual lack of responsiveness by some Registrars on how "urgent" is urgent.

When a business person has a problem with ownership/use of a domain, they
typically will either turn to IT or legal, and often IT will then punt to
legal.  The lawyer is going to look at the urgency of the situation and the
demand for a quick fix to the problem and TDRP will not make the list.  TDRP
is unsuitable for the Registrant's lawyer because the lawyer currently has no
basis for getting the Registrar to act with the urgency the lawyer's client
desires.

My other reaction to the negative view about Registrant participation is:
who is the domain registration system for except for the Registrants?
Registrants drive the needs and pay the fees (directly or indirectly) so
their difficulties need to be addressed.  Land owners have demanded direct
access to legal process to resolve land ownership issues, why shouldn't
Registrants have similar access?
_____________________________________________________________________________
___________________________
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: Michele Neylon :: Blacknight [mailto:michele@xxxxxxxxxxxxx] 
Sent: Monday, February 08, 2010 9:42 AM
To: Mike O'Connor
Cc: Steele, Barbara; James M. Bladel; Erdman, Kevin R.; IRTP B Mailing List
Subject: Re: [gnso-irtp-b-jun09] Approaches discussed on Tuesday's call


On 8 Feb 2010, at 14:34, Mike O'Connor wrote:

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

Can't registrants lodge complaints directly with ICANN already? ie. when
they've already tried to contact the registrar and got nowhere .. 


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

Mr Michele Neylon
Blacknight Solutions
Hosting & Colocation, Brand Protection
http://www.blacknight.com/
http://blog.blacknight.com/
http://mneylon.tel
Intl. +353 (0) 59  9183072
US: 213-233-1612 
UK: 0844 484 9361
Locall: 1850 929 929
Direct Dial: +353 (0)59 9183090
Fax. +353 (0) 1 4811 763
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845


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




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

Privacy Policy | Terms of Service | Cookies Policy