Comments and suggestions related to IRTP Part B

[Patrick Mevzek <contact@xxxxxxxxxxxx>]

Following the ICANN announcement at
http://www.icann.org/en/announcements/announcement-14sep09-en.htm
please find below my comments on the 5 points raised in section 4 of
http://gnso.icann.org/issues/transfers/irtp-report-b-15may09.pdf

I'm writing these comments as an individual generic Internet user,
owner of some domain names for personal and business needs,
and a founder of a company working with ICANN registries, registrars,
and domain names providers.

I would urge readers of this email to also read my introduction on a
previous email archived at
http://forum.icann.org/lists/irtp-initial-report/msg00001.html
which in summary explains that I feel we lack many data points
before being able to create wide policies.

We should really refrain to try creating policies and putting a lot
of work and energies to try fixing things just because there was one
or two very problematic cases. Of course fraudulent transfers on the
size of panix.com or some others do create great risk and very bad
consequences, but this has to be put in perspective with the total
number of transfers happening. It has to be understood that whatever
policies and technical solutions are put in place, there always will
be a percentage of unavoidable problems. The aim is not to try
removing all of them (as this is impossible), but just lowering them
as much as possible. I'm still not absolutely sure that the current
level can be lowered again without introducing many more risks.


Issues:

1) "Whether a process for urgent return/resolution of a domain name
should be developed, as discussed within the SSAC hijacking report
(http://www.icann.org/announcements/hijacking-report-12jul05.pdf);
see also 
http://www.icann.org/correspondence/cole-to-tonkin-14mar05.htm)
(Issue #2); "



This point really question me as a single incident (the panix.com)
seem to be the basis to create new policies, which I do not find to
be a good idea, and even if I obviously regret this incident, and
that the SSAC report writes about other incidents.



The TDRP exists to handle dispute coming out of transfers. Before
implementing new policies to resolve those disputes, I would find it
a good idea to assess the TDRP effectiveness, in order to strenghten
it if possible or to remove it if it does not solve anything.
As I said in my previous email on January 29 (see archive link in
introduction), the current public data on transfers do not show a lot
of problems
(and BTW the link in my previous emails are unfortunately wrong they
should read
http://www.dotandco.net/ressources/icann_registries/index.en
and
http://www.dotandco.net/ressources/icann_registries/verisign_com_net/transfers_COM.en
to see for example data on .COM transfers which show there are less
than 10 disputes per month related to transfers where around 300000
transfers happen each month, this is a 0.0033% failure rate)


I'm specifically worried reading §4.2.3 of
http://gnso.icann.org/issues/transfers/irtp-report-b-15may09.pdf
which can be summarized as:
- there may be a need of a fast procedure
- because it takes time to come to the bottom of the problem, finding
proofs and assess the situation
- but at the end, the  decision made quickly earlier and before all
verifications may need to be reversed after fact
finding.

This is for me a red light: if there is a need to take time to find
the problem, then nothing should be decided at that point in a hurry,
other than blocking the current state of affairs (which would mean
in domain speak to enable some update/delete/transfer locks).


I do understand that most of the problem arise when there is a DNS
change after the transfer. So the problem does not seem to be with
the transfer but with the DNS change that could have also happened
without a transfer.
In that regard I would prefer to recommand something along the line
of : no domain updates possible for one week after a finished
transfer, so that it gives time to intervene if it happens that the
transfer by itself was fraudulous.

The locking delay should not be too long (hence I would suggest more
7 than 15 days) because such kind of situation do also happen when a
customer is desperate with its current sponsoring registrar not
responding to its needs or not available as he may wish for support
or other stuff, so that he may decide to do a transfer to a "better"
registrar where he will be able to do the DNS change he needs.

All state changes, such as renewal, transfers, or updates should be
handled as painting: you wait for the first layer to dry before
putting another one, meaning that there should be a delay after any
of this operation during which nothing else can happen, so that
everything can cool off.


I would also note that some ccTLDs registries (ex: .LU .EU .BE .SI)
enable a transfer+update in one operation, that is during the domain
name transfer new nameservers can be given and will be applied by the
registry as soon as the transfer finishes.

So in short I would be against putting time and energy into
developing a specific ad hoc process for urgent domain name transfer
undoing based on the fact that the number of problems seem too low,
that such process could be heavy to implement and could create even
more risks than what it attempts to solve. Hence, while I do not
negate that problem may appear, I think that such new policy
drawbacks would overrid its supposed benefits.

2) "Whether additional provisions on undoing inappropriate transfers
are needed, especially with regard to disputes between a Registrant and 
Admin Contact (AC).
The policy is clear that the Registrant can overrule the AC, but how
this is implemented is currently at the discretion of the registrar 
(Issue #7); "


As I already said in another forum
(see archive at
http://forum.icann.org/lists/irtp-initial-report/msg00001.html )
I think that many issues are outcomes of the ambivalence of the
registrant/admin contact and in my opinion they should be treated
equally during all the transfer process, which would simplify all
things a lot. And what would be even better is to take only one of
the two and left the other: the administrative contact would have
full power on transfers, accepting or rejecting them, and when done,
they could not be anymore overruled by the registrant.

If the two contacts are maintained as authoritative then both should
accept a transfer, not only one, and that alone would solve all
problems of current transfers accepted by the admin contact but then
later disputed by the registrant.


As for the previous point, creating a specific policy for undoing
transfers is more complicated and will create even more problems than
the simple changes in current policies as explained in previous
paragraphs.

3) "Whether special provisions are needed for a change of registrant
when it occurs near to the time of a change of registrar. The policy 
does not currently deal with change of registrant, which often figures 
in hijacking cases (Issue #9);"

In short I agree with §4.4.3 which is already something I wrote
above: any kind of changes such as transfers or contacts/registrant
change should be followed by a cooling off period where nothing else
could happen. So that would include transfer after registrant change
but also registrant change after transfer.

This could be easily implemented on the registry side just using the
EPP statuses (clientUpdateProhibited, clientTransferProhibited and so
on).

I would however prefer to see lower delays than 30 days. I think that
one week or up to 10 days would be better.

Again I would also point out that many ccTLDs allow transfer+contacts
update at the same time (as one single EPP command).


4) "Whether standards or best practices should be implemented
regarding use of Registrar Lock status (e.g., when it may/may not,
 should/should not be applied) (Issue #5); "


I would first would like that any discussion be put in line with the
current protocols as "Registrar-Lock" was used with RRP which is now
superseded by EPP for all gTLDs, and in EPP there are more that one
status available to the registrar, where changes are more
fine-grained such as : clientXProhibited where X can be Transfer,
Update, Renew, or Delete.

So I take from now on that we are here indeed speaking about the
clientTransferProhibited status value that at registrar may use to
deny any outgoing transfer on a domain name he sponsors.

I believe that registrars should be free to use these statuses in any
way they wish, or not all. This is specially true since registries are
starting to market services around their own set of available status,
such as Verisign proposal at
http://www.icann.org/registries/rsep/verisign-reglock-request-25jun09.pdf

So these statuses should be available to registrars, that can use
them related to their own business procedures, rules and customers
services.

Instead of trying to limit registrars use of this status, I think it
would be better to make sure that registrant and end customers have
the possibility to change this status online through their respective
registrars. For that, besides handling spontaneous incoming
complaints from users, ICANN should commission yearly review of
registrars using people acting as clients, unknown to the registrar
tested, and then they would be able to verify that each registrar let
its registrant change that status value per their wishes.

I would also like to point out that in EPP, each status value can be
associated with a message (in any language, as a language tag can be
provided alongside the message), explaining the reason of the status.
This message is optional and seems to be seldom used, but it could be
useful for registrars to provide it as it would give an explanation
for the basis that enabled this status value.

This would enable the registry and/or ICANN to immediately assess if
the statuses are used for valid purposes and in accordance with
relevant policies, if registrars are required to file the message
with a valid reason.


5) Whether, and if so, how to best clarify denial reason #7: A domain
name was already in "lock status" provided that the Registrar provides 
a readily accessible and reasonable means for the Registered Name 
Holder to remove the lock status 
(Recommendation from the IRTP Denials WG). "



As explained in my previous point:
- Registrar should be required to document why a domain is in
clientTransferProhibited status (which would then automatically
explain, without any explicit action, why a transfer request would
fail)
- yearly verification should be made to ensure that indeed end
clients are able to switch this lock on or off as they wish.
ICANN may maintain a webpage explaining, for each registrar, the
specific procedure to follow for end users wanting to change the
locking attribute.


I also agree that this issue (number 5) should be handled together
with the previous one (issue 4).
And the example given as footnote on page 24 seems reasonable to me
in order to assess how much having access to the locking procedure is
easy at each registrar.



And just for the record after having read some other comments already
published at
http://forum.icann.org/lists/irtp-b/
I strongly disagree with the fact that all registries must be thick and
that private data should be banned: thick registries and no private
data do not solve just by themselves any true problem and on the
contrary creates many privacy problems conflicting with national
laws.
But I think this has nothing to do with transfer issues.



Regards,

-- 
Patrick Mevzek
Dot and Co <http://www.dotandco.com/> <http://www.dotandco.net/>
<http://www.dotandco.net/ressources/icann_registrars/prices>
<http://icann-registrars-life.dotandco.net/>