Comments on "New gTLD Applicant Guidebook Version 3 Module 5"
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/>