Comments from the FID SU-PDP Project

[Yuri Demchenko <demch@xxxxxxxxx>]

Hello Everybody!

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)?

Generally NO, but this rule can be used conditionally depending on the
concerned user community.

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?

It would be reasonably to ask here also "If NO, what existing mechanisms
or practices should be changed?". So, my answer will be to this question.

ICANN should not play passive role in ISO3166 MA
(http://www.iso.org/iso/fr/prods-services/iso3166ma/04background-on-iso-3166/iso3166-ma-members.html), 

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?

Removal must be never imperative and should be based on the community
decision/consensus.

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?

It is not clear what tests are meant. However, the main criteria must be
existing user community consensus. There may be possible community
agreement to move to a new or another domain but this never should be
mandated, especially by international body.


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

This question may have quite definite answer from the user perspective.

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?

Accept this as existing situation and don't try to change, especially in
case of "UK" and "GB" with well operated and managed DN service and
registration business. If necessary, recommend ISO to make exceptional
reservation.

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.

------------


Yuri Demchenko,
FID SU-PDP project member