Comments on "New gTLD Applicant Guidebook Version 3 Module 5"

[Patrick Mevzek <contact@xxxxxxxxxxxx>]

Following the ICANN announcement at
http://www.icann.org/en/topics/new-gtlds/comments-3-en.htm
please find below my comments related to the Module 5 of
the New gTLD Applicant Guidebook Version 3
http://www.icann.org/en/topics/new-gtlds/draft-transition-clean-04oct09-en.pdf


* 5.1
"All applicants that have successfully completed the
evaluation process--including, if necessary, the dispute
resolution and string contention processes--are required to
enter into a registry agreement with ICANN in order to
proceed to delegation."

In order not to create another case like .POST, I would suggest that
a delay restriction should be added so that registry operators are
required to sign their final contract with ICANN in some timeframes,
otherwise their whole proposal will be considered moot.

This would ensure that, after having dealt with a proposal and
studied a lot based on the procedure outlined in the guidebook, ICANN
does not need again lot of discussions to finalize the contract with
its registry operator, based on the fact that this future contract is
available for review to all parties before even applying for a new
gTLD.
In light of this, a delay of 6 months would surely be the maximum.

If the contract can not be signed by that time, the proposal should
finally be rejected, and if there was a contention or auction, the second
winner should then be awarded the possibility to sign the final
contract, if it still complies with all requirements.

Doing so would make sure that the "community" and/or end-users are
not frustrated to see that some TLD does not go forward.


And the same idea should be applied for the testing procedures (they
should not last more than x months)


A specific page on ICANN website should deal with the final life of
all proposals, listing each TLD/Registry operator being in phase of
"signing the contract", "doing the final technical tests", "IANA
delegation" etc...
alongside with dates of when each event happened.

================================================================

"Registry Agreement & Specifications"

* 1.2 Technical Feasibility of String.

In order not to pursue the confusion that Internet is the web
(see also my other comment archived at
http://forum.icann.org/lists/privacy-proxy-study/msg00007.html)
this point should be rewritten to say that 
" ...  certain top-level domain strings may encounter difficulty 
in acceptance by various existing or future Internet services"

There is no need here to concentrate on webhosters or web
applications. Same problems can exist for email systems for example.



* Specification 4
 Thick/Thin registries & Whois vs IRIS

I think that the current situation of still living with whois and not
pushing for IRIS on one side, and on the other side saying that even
with a thick registry, registrars are still required to have a
whois with contact information, is a very bad situation.

This new round of gTLD should be the ideal occasion to:
- mandate the use of IRIS and completely forbid whois over tcp port
43 as known today, both at registry and registrar level
- and in the case of thick registry, mandate all information to be
available through the registry IRIS server, without any information
to be available on the registrar IRIS server
(which would lessen risks of confusion with data not being the same
at 2 separate points and simplify data escrow).

Using of IRIS is also a huge advantage on the competition side of
things, as it allows far more services to be built on top of it than
whois.


For privacy protection reasons if thick registries are mandated, each
registry operator should have a public webpage on a designated
address (such as www.nic.$TLD/privacy or anything else to the extent
that it could be the same for all TLD operators) which would display:
- the registry country and laws into effect to its operation, related
to customer data privacy, as links to the government webpages or
similar showing the laws
- the way the registry uses the personal data, besides access through 
its IRIS server


* Specification 6

The registry operator should be mandated to follow all RFCs related
to EPP, and in the event it needs some extensions, it should be
required to publicly release all documentation related to its EPP
extensions. To the extent possible it should follow IETF guidelines
in writing drafts and participating in IETF efforts related to EPP
and other protocols associated with its operations
(DNS,DNSSEC,IDNs,IRIS,etc.)


================================================================

"Community Registry Restrictions Dispute Resolution Procedure" 



I would suggest that complainants be required to disclose if they
participated in any way in the ICANN new gTLD program, either by
providing comments, submitting an application, raising concerns, etc.
It should also disclose its relation, if any, with any other registry
operator currently operating or wishing to operate a new gTLD.

This would help to make sure that contentions at earlier stages are
not forwarded later at a stage where the registry runs, and
complaints come through the RRDRP

The complainant should also disclose its ties with the community for
which it fills a complaint, and also disclose if it owns domain names
in the registry for which the complaint is lodged, as well as if it
tried to register domain names but was turned down and for which
reasons.


I would also suggest that all complaints, at least after their
resolution, are published publicly somewhere, on ICANN website or the
RRDRP provider, with all possible details.



================================================================

"Trademark Post-Delegation Dispute Resolution Procedure"



I do not find this procedure clear at all. It seems to mix, without
enough details, problem with the gTLD string itself possibly
infringing some trademarks, and problems with abusive registrations
under the gTLD zone.

For the first problem, I would suggest that trademarks holder have
time, before the registry starts operating, to lodge complaints with
ICANN through designated procedure (Module 3) to show that some registry
proposal should not go forward as is.
Giving trademark holders a perpetual right to fight against some
registry far after it started seems to be without merit and at least
completely unbalanced.

As for the second problem I think it would be hard to identify such
large scale bad behavior from the registry, except if it is so
blatant that it should have been caught at the application step well
before the start of the registry.
I would suggest that such cases should be "consequences" of UDRP in
the sense that if some gTLDs seem to have some high amounts of
complaints, then some further review of the registry operations
should be attempted.

With these two points in mind, a new specific procedure would not be
needed.

However if this procedure do exist, I would give the same comments as
for the previous procedure, related to details that complainants
should be required to disclose, and publicly available data for
complaints that have been decided.

Also, since the level of similarities between th RRDRP and the PDDRP
is so high, I would advise, if the PDDRP can not be dropped, that
attempts are made to merge both for cost and efficiency reasons.

-- 
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/>