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

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

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