ICANN ICANN Email List Archives

[gnso-irtp-b-jun09]


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

[gnso-irtp-b-jun09] Proposed Changes to ETRP based on last week's call

  • To: "IRTP B Mailing List" <Gnso-irtp-b-jun09@xxxxxxxxx>
  • Subject: [gnso-irtp-b-jun09] Proposed Changes to ETRP based on last week's call
  • From: "James M. Bladel" <jbladel@xxxxxxxxxxx>
  • Date: Mon, 03 May 2010 10:33:33 -0700

Team:


Please see the items below, which summarize our discussions on ETRP last
week.  Based upon these, I propose only one change (Item 3.5)  to the
ETRP draft recommendation.  Please let me know if these are accurate
reflections of our conclusions, or if you'd like further discussions on
Tuesday.

Next steps:  If Marika can edit the document,  I think this
recommendation is complete for inclusion in the Interim Report.  Of
course, we should anticipate (even expect) numerous Public Comments on
this subject.


Thanks--

J.



**********************
Item 3.1:  What is the incentive for the PTRr to cooperate with the
registrant and initiate the ETRP?

The group discussed the notion that uncooperative receiving registrars
are the barrier to recovering hijacked names in the existing
environment.  PTRr would have incentive to cooperate due to their desire
to assist the hijack victim, differentiate themselves from competitors
who do not cooperate, and build consumer confidence in the industry. 
These reasons mirror the incentives for registrars in deciding to offer
any optional service.

The group discussed that the PTRr cannot be -required- to offer this
service, or even to invoke it for a given circumstance.  The PTRr must
be free to exercise discretion in declining to invoke ETRP in cases
where they do not feel the evidence for hijacking is sufficient, or feel
that exercising the ETRP would involve them in a dispute between two
legitimate claims.


Conclusions:  ETRP is an optional service which does not depend upon
cooperation or action on the part of the registrar receiving the
hijacked name.  Note this discussion in the report, but no change to the
draft recommendation.


**********************
Item  3.2.1:  What are the consequences of making the 60-day transfer
lock mandatory (rather than optional)?  How will this effect the
secondary market, and similar concerns?


Topic was introduced by stating that Domain Security vs. Domain
Portability was a tradeoff, and there was no way to increase security
without having some inconveniencing effect on Portability.  From there,
the group discussed the implications of this recommendation, and Barbara
Steele offered to compile a list of registry operators who already
implement some restrictions on transfer requests within 60 days of a
previous transfer.  Mikey O'Connor proposed that auction service
providers or domain investors could reduce or eliminate this issue by
maintaining accounts at multiple registrars for transfer purposes. 
Michael Collins, Mikey O'Connor, Matt Serlin and others then discussed
the related issue of 60-day lock for change of registrant information.

Conclusions:  The proposal will have a negative impact in domain name
portability, which could impact the secondary market (domain investors,
auction services, etc.)  Whether this increased burden sufficiently
offsets the decrease in attempted sales of hijacked names is a question
open to comment by the secondary market.  No changes to the draft
recommendation.


********************** 
Item 3.4.2:  How can (or should) ICANN monitor or audit the requirement
to collect valid ID from the purported Hijack victim?


The group discussion on this topic focused on the due diligence of the
PTRr before initiating a ETRP.  Paul Diaz pointed out that the fact that
the PTRr is willing to accept the risk of initiating ETRP should be
sufficient. David Giza discussed how ICANN Compliance might audit these
records if the policy required the PTRr to collect and/or retain ID
verification.  Kevin Erdman proposed the idea that ID verification is
done on the front-end (at time of registration?) versus dealing with
problems later on.

Conclusion:  We have a choice to be either (a) very prescriptive in what
constitutes an ID check, or (b) simply require that the PTRr conduct its
own due diligence in verifying the claim of hijack, and maintain records
of this for release to ICANN if requested.  No changes to draft (yet).


**********************
Item 3.5:  The specification of a price cap for a Registrar service is
unprecedented in Consensus Policy, and should be modified.


James proposed that the ETRP price not be spelled out in the policy, or
tied to other services (such as IRTP), but rather that the ETRP price is
disclosed by the PTRr, for example in their registration agreement.
Those speaking on the call were generally supportive of this idea.

Conclusion:  Modify Item 3.5 to read:  "The PTRr may, at their
discretion, charge the Registrant a fee for this service.  If Registrar
operates a website for domain registration or renewal, it should state,
both at the time of registration and in a clear place on its website,
any fee charged for the recovery of a domain name via ETRP.  (Last
sentence borrowed from language in the EDDP, section 3.7.5.6)


**********************
Overall:  How can we ensure that this process will not be abused or
gamed?

Group discussed having some volunteers attempt to "break" this procedure
by uncovering vulnerabilities and proposing remedies.  Kevin Erdman
volunteered.

Conclusion:  No change to the draft.  Awaiting any thoughts or
recommendations by Kevin.  Should also leave this issue on the table for
Public Comment.







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

Privacy Policy | Terms of Service | Cookies Policy