Comments from the FID SU-PDP Project
I am submitting these comments on behalf of the FID SU-PDP Project, the project on developing .SU Policy Development Process initiated by the Fund on Internet Development (FID) currently acting as a .SU supervisor and administrator on agreement with the formal .SU AC/TC Russian Institute for Public Networks (RIPN).
This is also an opportunity to make ICANN and wider community aware about this project started in summer 2006 to investigate possible ways to resolve current, in some sense uncertain, situation with the .SU domain.
The Project made extensive study of available ICANN documents and practices and also consulted with many people currently and formerly actively involved in the ICANN activity.
Current discussion initiated by ICANN, although a bit unexpected for some interested parties, in fact is very useful and made a good job for collecting different opinions, interesting ideas and also revealing (sincere) community attitude.
Although posting our comments late, we had a possibility to read and analyse other posted comments and think how the problems risen in the ICANN discussion paper can be resolved in general and in relation to the .SU domain (and in the interests of the .SU user community which can be historical but doesn't have tendency to stop growing with further Internet development).
Being part of the professional Internet developers and users community, we understand the importance of common and clear rules to keep the Internet stability and consistency.
At the same time, we observe and recognise that the Internet brings a new reality that may need to change existing approaches and practices. The issue is what should be put as a priority?
For us as representing .SU user community that keeps its cultural, historical, scientific and currently also business identity, there is a clear priority of working in the interests of this community. I guess we will not much deviate from the recent ISOC campaign slogan "Internet is for everyone" (RFC3271) understanding it as "Internet is for people (or community)".
Below are our answers to the Guiding questions both in general and in relation to the .SU domain. We will be ready to discuss other possible issues in this forum or in the follow-on discussion.
1. Should IANA adhere to the ISO-3166 standard and remove top-level domains from the DNS root that become transitionally reserved (i.e. retired)?
All mentioned in the ICANN discussion paper cases are different as it is correctly explained in comments by Elisabeth Porteneuve by 12 Dec 2006 (http://forum.icann.org/lists/cctld-sunset-comments/msg00008.html - Thanks for this very interesting information!).
In particular, .SU is different from other cases in sense that it served some FSU countries for another 5 years after the SU dissolution, and it is active now and serves a community that has its clear identity.
2. If so, by what process should this be conducted?
ICANN should not play passive role in ISO3166 MA
see comments of Jan. 21, 2007 by Olivier Guillard (http://forum.icann.org/lists/cctld-sunset-comments/msg00060.html).
ICANN represents Internet user community which is already (and rather typically) not geographically bound.
In respect to the "SU" country code, there are enough reasons that ICANN can ask ISO3166 MA to make it exceptionally reserved. This case in fact is not much different from "UK"/"GB" or "EU" and will significantly simplify the situation.
Possible next step of migrating .SU existing domains and future registration to a new (community oriented) domain will exclusively depend on the current .SU user community consensus.
3. What implementation timeframes for removal should be specified?
As we can understand, there is no precedent for non-voluntary removal. There is no need to do it in any mentioned in the ICANN paper or discussed on the forum case.
Trying to do it forcefully will create many legal and human problems.
4. If removal is test-based, what specific milestones should signify removal from the root zone?
5. What pre-emptive right, if any, should existing operators have toward a new code that covers an area previously serviced (in whole, or in part) by another code?
If the community decides to move to another domain, their rights for moving their existing SLD domains must be guaranteed. But for this there are many examples from currently existing ccTLD practices how to organise the sunrise period.
6. In the event there is more than one code for a particular country available for its use (e.g. GB and UK), what policy should govern their status?
Another case with TP and TL, for simplicity should be treated the same way, and left as historical or legacy.
But for future possible situations, when country may change its name, this will THE moment when the ICANN representative in ISO3166 MA will play their role: adding a new country code should be conditional to migrating domain names to the new code.