<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [gnso-irtp-b-jun09] For your review - draft IRTP Part B Initial Report
- To: "James M. Bladel" <jbladel@xxxxxxxxxxx>
- Subject: RE: [gnso-irtp-b-jun09] For your review - draft IRTP Part B Initial Report
- From: "Erdman, Kevin R." <Kevin.Erdman@xxxxxxxxxx>
- Date: Wed, 12 May 2010 18:39:07 -0400
James and all,
If we cannot go beyond 60 days, then the potential problem is that the
hijacker of the high traffic domain hacks in and changes the Registrant and
transfers the domain to another Registrar while keeping the DNS stuff the
same. The prior Registrant may not notice as the traffic continues to inure
to its benefit, then at day 65, the hijacker redirects the DNS for its own
purposes and the prior Registrant finds out it has no domain. The proposed
alternative window for the ETRP would provide the prior Registrant a
procedure to quickly recover the domain once the high volume traffic
diversion occurs.
I understand that currently, the vast number of cases would not need more
than 60 days. However, assuming the ETRP is well used, then every educated
hijacker will do as I propose above.
What is the time frame in the RAA for demarcating the end of the PTRa's
responsibility? Perhaps tracking this time period would be better for
counsel to consider rather than a limitless time frame, but one that would
still somewhat deter the use of the scenario above.
_____________________________________________________________________________
___________________________
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: James M. Bladel [mailto:jbladel@xxxxxxxxxxx]
Sent: Wednesday, May 12, 2010 4:27 PM
To: Erdman, Kevin R.
Cc: IRTP B Mailing List
Subject: RE: [gnso-irtp-b-jun09] For your review - draft IRTP Part B Initial
Report
Kevin et al:
I share Paul's concern, and there is precedent in the RAA for
demarcating the end of the PTRa's responsibility. For example, the RAA
describes the various registrar responsibility for names that it
-actively- manages, and the time period it is required to maintain
registrant data after deletion or transfer-away. So there are some
limits to how long the chain of previous registrars can be for any given
registration.
Also, keeping this window open for too long starts to cloud the issue of
who is ultimately (and contractually) obligated to the registrant: the
Registrar of Record, or one (or more) PTRa's? And is the registrant the
-current- registrant, or a previous name holder now claiming hijack?
Doesn't the legal community refer to this as "dead hand" or somesuch?
Finally, we should note that hijackers are typically not interested in
low-profile targets, but instead focus on high traffic / high value
names, the hijacking of which is noted in hours or days. So I think we
can safely limit the timeframe for any dispute, without diminishing the
value of the mechanism for the vast majority of cases.
The bottom line is that any recommended period longer than 60 days will
probably kill support for this idea at the council level, and all of our
good intentions will not budge the status quo.
Thanks--
J.
-------- Original Message --------
Subject: RE: [gnso-irtp-b-jun09] For your review - draft IRTP Part B
Initial Report
From: "Erdman, Kevin R." <Kevin.Erdman@xxxxxxxxxx>
Date: Wed, May 12, 2010 3:00 pm
To: "Diaz, Paul" <pdiaz@xxxxxxxxxxxxxxxxxxxx>, "Marika Konings"
<marika.konings@xxxxxxxxx>, <Gnso-irtp-b-jun09@xxxxxxxxx>
Paul and all:
I do not think that the PTRa’s responsibility ever ends. However,
the PTRa only needs to forward the ETRP package to the new Registrar for
which it can charge a fee. I think that the ICANN obligations are only
to send the ETRP packet to the new Registrar, the PTRa may set its own
document retention policies and require the Registrant to provide all
relevant information/documentation. Or I am misunderstanding the
obligations created on the PTRa?
Also note that in 3.1 I missed one “Token” which should be
“Title”.
_____________________________________________________________________________
___________________________
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
From: Diaz, Paul [mailto:pdiaz@xxxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, May 12, 2010 3:38 PM
To: Erdman, Kevin R.; Marika Konings; Gnso-irtp-b-jun09@xxxxxxxxx
Subject: RE: [gnso-irtp-b-jun09] For your review - draft IRTP Part B
Initial Report
Hi Kevin,
Just to be clear, you’re proposing that a domain name be locked (at
the Registrar-level) for 60 days after the initial transfer, and then
locked (at the Registry-level) for another 60-day period once the ETRP
is filed? What happens when the original/pre-transfer Registrant
discovers the hijack > 60 days after it occurred? I’m trying to
figure out where (or, more accurately, when) the PTRa’s responsibility
to get involved ends. Let me be clear: Network Solutions will continue
to go to great lengths to assist its customers. My concern lies with
proposing a mandatory policy (ETRP) that requires Registrars to follow
these processes even when the name in question has been out of the
PTRa’s management for many months.
From: owner-gnso-irtp-b-jun09@xxxxxxxxx
[mailto:owner-gnso-irtp-b-jun09@xxxxxxxxx] On Behalf Of Erdman, Kevin R.
Sent: Wednesday, May 12, 2010 1:48 PM
To: Marika Konings; Gnso-irtp-b-jun09@xxxxxxxxx
Subject: RE: [gnso-irtp-b-jun09] For your review - draft IRTP Part B
Initial Report
Dear All,
I believe this was discussed in the prior teleconference, but here is a
brief summary of the rational for using the ‘Registrant becoming aware
of the transfer’ language. If I were a hijacker and wanted to avoid
the ETRP, I would reset the Registrant info and transfer the domain but
not change any of the DNS settings (so the domain proprietor would have
no reason to check on the status of the domain registration). Then
after the 60 day period, the hijacker changes the DNS info and the prior
Registrant finds that its web site does not work. This ‘Registrant
becoming aware of the transfer’ language allows a Registrant to invoke
the ETRP in such a situation, but require that the prior Registrant
explain its situation. The veracity of the prior Registrant explanation
would not necessarily be examined, but could be a basis for reversing an
ETRP in a situation where a prior Registrant was abusing the process and
such explanation was discredited in a TDRP.
_____________________________________________________________________________
___________________________
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
From: owner-gnso-irtp-b-jun09@xxxxxxxxx
[mailto:owner-gnso-irtp-b-jun09@xxxxxxxxx] On Behalf Of Marika Konings
Sent: Wednesday, May 12, 2010 5:16 AM
To: Gnso-irtp-b-jun09@xxxxxxxxx
Subject: [gnso-irtp-b-jun09] For your review - draft IRTP Part B
Initial Report
Dear All,
Following the IRTP Part B WG meeting yesterday, please find attached
and posted on the wiki (https://st.icann.org/irtp-partb/) an updated
version of the draft Initial Report for your review. I have integrated
the proposed ETRP language, from the latest draft circulated by Kevin
yesterday, in Annex C. Please note some changes I made highlighted in
blue in Annex C, as well as some outstanding issues highlighted in
yellow. I also highlighted one addition that was made by Kevin that as
far as I recall was not discussed on yesterday’s meeting in relation
to the ‘Registrant becoming aware of the transfer’. It is not clear
to me what that actually means or how that could be enforced. Maybe
Kevin could provide some additional clarification? Annex C will need to
be further updated once the sub-team provides its definitions of
registrant. Also, there is still a placeholder in the report for a
recommendation for issue D, which is on Michele’s ‘to do’ list.
As agreed yesterday, you are strongly encouraged to review the draft
Initial Report and share your edits / comments with the mailing list at
the latest by 19 May so that a final review can take place at our
meeting on 25 May.
Thanks,
Marika
----------------------------ATTENTION: To ensure compliance with
applicable Internal Revenue Service Regulations,we inform you that any
tax advice contained in this electronic message wasnot intended or
written to be used, and cannot be used, for the purpose ofavoiding
penalties under the Internal Revenue Code. This message and all its
attachments are PRIVATE and may containinformation 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.
----------------------------ATTENTION:To ensure compliance with
applicable Internal Revenue Service Regulations,we inform you that any
tax advice contained in this electronic message wasnot intended or
written to be used, and cannot be used, for the purpose ofavoiding
penalties under the Internal Revenue Code.This message and all its
attachments are PRIVATE and may containinformation 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.
----------------------------
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
>>>
|