<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [SPAM] [gnso-irtp-b-jun09] ETRP
- To: "Michael Collins" <mc@xxxxxxxxxxxxxxxxx>, "Marika Konings" <marika.konings@xxxxxxxxx>, <Gnso-irtp-b-jun09@xxxxxxxxx>
- Subject: RE: [SPAM] [gnso-irtp-b-jun09] ETRP
- From: "Diaz, Paul" <pdiaz@xxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 10 May 2010 11:47:20 -0400
Hi Michael,
Thanks for the thought and effort that went into your "Disputed ETRP"
proposal. I'm still thinking through the details, but would appreciate
clarification on a few points:
* In 5.2, you recommend allowing the party that wants to undo the
ETRP up to 14 days to file their petition. Why so long? This seems
inconsistent with all of the other timeframes associated with transfer
policies.
* In 5.4.1, are you using the term "registrant" in a general
sense, or as defined by ICANN (aka Registered Name Holder)? If the
former, then this could involve the Administrative Contact for the
domain? If so, are we rehashing to the Registrant trumps AC dilemma?
* In 5.9, you note that the TDRP allows a complainant up to 6
months to file their petition. You go on to note that "it is not
reasonable" for a name to remain with the PTRr for this entire period
when the domain name is in dispute. Setting aside for a moment using a
word like "reasonable," if the WG accepts your position do we also need
to recommend a change to the TDRP timeframe?
* In 5.10, doesn't the Registry Operator determine the outcome of
a TDRP? If so, that entity will know the outcome of the proceeding and
could unlock a contested domain name as appropriate. Do we need any of
the text after the first sentence (i.e. just confirm that the Registry
Operator locks the name - at the Registry level - when the TDRP is
filed)?
* In 5.11, why do you recommend a 30-day timeframe? Wouldn't the
interests of a registrant (using the term in the general sense, as an
Admin Contact could prevail in a TDRP) be better served by a much
shorter timeframe?
Best regards, P
________________________________
From: owner-gnso-irtp-b-jun09@xxxxxxxxx
[mailto:owner-gnso-irtp-b-jun09@xxxxxxxxx] On Behalf Of Michael Collins
Sent: Monday, May 10, 2010 10:48 AM
To: 'Marika Konings'; Gnso-irtp-b-jun09@xxxxxxxxx
Subject: RE: [SPAM] [gnso-irtp-b-jun09] ETRP
Marika and the group:
I edited the document to add a "Disputed ETRP". I understand now why the
sub-group didn't want to tackle this issue. There were more issues to
work through than I first realized. I tried to accomplish what I thought
we set as a goal for ETRP when we first began discussing it. Create a
means to quickly return a domain to a pre-transfer state after a
hijacking claim, allowing a dispute (TDRP), if any, to be heard while
the original registrant has use of the domain name.
I added a new section (5) and made a couple changes to existing text to
require registrant notification and locking ETRP domains to provide time
to hear a dispute. I copied as much language as I could from what was
already written. Please consider it a starting point for including a
dispute process.
Best regards,
Michael Collins
From: owner-gnso-irtp-b-jun09@xxxxxxxxx
[mailto:owner-gnso-irtp-b-jun09@xxxxxxxxx] On Behalf Of Marika Konings
Sent: Tuesday, May 04, 2010 5:17 AM
To: Gnso-irtp-b-jun09@xxxxxxxxx
Subject: [SPAM] [gnso-irtp-b-jun09] ETRP
Dear All,
Following the request of James, please find attached and posted on the
wiki (https://st..icann.org/irtp-partb/index.cgi?irtp_part_b
<https://st.icann.org/irtp-partb/index.cgi?irtp_part_b> ) an updated
version of the proposed Expedited Transfer Reverse Policy. This version
includes the modification proposed to item 3.5. In addition, I would
like to propose a small modification to avoid confusion by changing the
acronym from eTRP to ETRP as a small 'e' in Europe is associated with
electronic (eGovernment, eInclusion, etc.).
Could I ask those that suggested additional modifications (Michael,
Kevin) to provide language for inclusion? Once all edits have been
provided and reviewed by the WG, I'll incorporate it in the draft
Initial Report.
With best regards,
Marika
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|