RE: [gnso-irtp-b-jun09] 60day lock recommendation
- To: ITRP-B Mailing List Mailing List <Gnso-irtp-b-jun09@xxxxxxxxx>
- Subject: RE: [gnso-irtp-b-jun09] 60day lock recommendation
- From: "Sedo :: Simonetta Batteiger" <simonetta@xxxxxxxx>
- Date: Mon, 16 May 2011 22:16:08 +0200
I had another thought on this over the weekend (weird that I'm even thinking
about domain locks on a weekend)
The 60 day lock idea came up to prevent registrar hopping after a domain was
hijacked. So we're probably all on the same page that the locking
recommendation does not actually prevent the hijacking in the first place, it
would merely make it easier to resolve the issue once it has already happened.
I'm wondering if introducing a second consequence to the initial EAC filing
could "fix" the same issue.
Could be something like: EAC communication piece is logged through RADAR => an
email goes out to the registry prompting to place a registry lock on the name
until they hear from the registrars that either the issue got resolved OR the
issue goes to dispute => the registry prevents further "hopping" of the domain
Just an idea, I wanted to bring up. This may be a way to stop the registrar
hopping in case of hijacking without having an impact on transfer locks around
legitimate transfer requests.
[mailto:owner-gnso-irtp-b-jun09@xxxxxxxxx] On Behalf Of Sedo :: Simonetta
Sent: Friday, May 13, 2011 6:51 PM
To: ITRP-B Mailing List Mailing List
Subject: [gnso-irtp-b-jun09] 60day lock recommendation
I had a few more conversations with domain owners, some of our registrar
partners and other members of the Sedo team and want to bring this feedback to
your attention before we submit the final report on our work.
We had set up a poll to "assess the WG's view on the issue of the 60 day lock
following a transfer (please note that this relates to a transfer between
registrars, NOT a change of control)."
=> my question to this part is how do you tell these apart? How would a
registrar in practice know when a transfer happens with or without change of
The current IRTP policy does not distinguish the two, would we then have to
make recommendations on completely new language there? And isn't that getting
into the much larger debate on the lack of a policy for transfers WITH
ownership update at the same time? Which is part of what we do recommend to
look into in another part of our report. I'm wondering if we should merely
include a statement there stating that we recommend an issues report and one of
the issues that should be looked at are the locks around transfers. By the time
we would look at this we should then have some data from the EAC to judge how
relevant this specific piece is in relation to the prevention of hijacking and
in comparison to the number of legitimate domain transfers going through.
"The problem of domain transfer 'hopping' between registrars is a known issue,
and could be used to thwart anti-hijacking issues, as well as create other
enforcement / takedown problems."
=> I agree that it would help with this, but I want to make sure that our
report reflects a viewpoint that while it may help with a subset of all
hijacking cases it places additional hurdles on normal domain transfer
activities. Domain owners tell us they do not want to have additional obstacles
placed on their domain transfer activities. They specifically value the ability
to be able to get a name unlocked upon request and moved for legitimate reasons
and do not want to see this changed into a mandatory policy.
The 60-day post-transfer lock is currently optional (Reason for Denial #9 of
the IRTP) and we're polling if it should be mandatory.
=> It is my opinion that we would suggest a significant change to the current
IRTP policy by making this recommendation (as there currently is no such thing
as a mandatory lock). I would not feel comfortable submitting our report
including this recommendation without a commenting option for the community.
Finally looking at the doodle poll results I see that 25% of the respondents
wanted to leave the item untouched, can somebody tell me what "level of
support" does this translate to for this recommendation in our final report? If
we choose to keep the existing language suggestion there, I would like to
include a statement of opposition to this viewpoint.