IANA | ccTLD News Memo #1

Dedicated to preserving the central coordinating functions of the global
Internet for the public good.

CCTLD News Memo #1 (23 October 1997)

There is a backlog of topics to discuss so this message will touch on several things that will be discussed more fully eparately in subsequent messages over the next several weeks.

1. Organization

It seems that it would be helpful to have a bit more organization among the country code TLD managers and operators to share information about problems and solutions, software and systems, and policies and procedures.

I hope this mailing list is a significant step in the right direction. However there may be other things that could be done. For example, it might be helpful to have a time during the annual INET conference for those of us that can attend to get together. However, meeting on a world wide basis may be too expensive, so regional groupings and meetings are also possible, and i encourage you to form regional groups, with mailing lists and meetings.

2. Policy and Procedures

The policies and procedures for the use of each contry code must be available for public inspection. Generally these are posted on web pages or made available for file transfer.

While we expect there will be variations in policies and procedures the from country to country due to local customs and cultural values, they must be documented and available to interested parties.

An additional factor has become very important since RFC 1591 was written: the desires of the government of the country. The IANA takes the desires of the government of the country very seriously, and will take them as a major consideration in any transition discussion.

On a few occasions, the parties involved have not been able to reach an agreement and the IANA has been required to resolve the matter. This is usually a long drawn out process, leaving at least one party unhappy, so it is far better when the parties can reach an agreement among themselves.

4. Shared Registries

In Great Britian (.UK) a system of "shared registration" has been developed (see http://www.nic.uk). This is a very interesting approach to allowing competition in the registration process and one that is likley to be adopted in other countries. The IANA encouragws country code managers to look into forming a management consortium including the interested parties and adopting a shared registry operation.

5. Naming Structure

The design of the naming structure under the country code is up to the manager of that country code. There may be reasons for an unusual or even unique structure to be developed in a particular country due to local customs. However, it may be useful to develop a model country code naming structure as a basis for local variations. This is a topic to be discussed further in future messages.

If there are criteria as to the type of organization that is appropriate to register under a particular branch of the country code, those criteria must be published (as part of the policies and procedures) and applied equally to all applicants.

Sometimes there are questions about what kind of names should be allowed (or outlawed). The experience is that if there is to be some set of allowed (or outlawed) names in a particular situation the best approach is to use an existing list maintained by another long-existing, reputable, organization. Just as we use the list of country codes determined by the ISO-3166 standard.

Another aspect of names is what characters to allow in names. In the early days, there were rules against names that started with a digit (such as 3COM). These rules have been discarded, at least for the COM domain, and such names work with no problems for the DNS system. Even names of all digits work fine. It is up to you to decide what names to allow or not, but it is important to be realistic about what efforts you have to make to consistently enforce the rules you make.

Thank you.

IANA