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

["James M. Bladel" <jbladel@xxxxxxxxxxx>]

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