• printers
• servers
• users
• e-mail addresses
• root web directories
• user web directories
• serial numbers
• MAC addresses
• IP addresses

In general, we will use the word namespace to refer to some sort of, possibly not very well defined, database associated with these identifying lists.

It should be obvious that the larger and more sophisticated a computing environment becomes the more important it is to manage namespaces effectively.  It is also very important to achieve the step of identifying that managing namespaces is an important issue.  If you do not think this is the case, hopefully this webpage will help you modify your opinion.

Namespace Policies.  Namespaces needed some sort of overarching policies to help guide their development and implementation.  The following outline surveys what may be seen as the major policy issues.

• Naming Policy
  • What names are permitted?
  • What names are not permitted?
  • How are names selected?
  • How are collisions resolved?

Limoncelli states that when selecting names there are four methods

• Formulaic:  Names should follow a strict formula.
  • all desktops might be labeled pc???? where each question mark is a single digit number
  • login names might be strictly first initial, followed by middle initial if applicable, followed by first six letters of the last name, followed by 3 digits to guarantee uniqueness
• Theme:  Names follow a theme.
  • server named after planets in solar system
  • printers named after Greek muses
• Functional: Names have functions.
  • names reflect specific purpose such as admin, guest, secretary
  • server names reflect use such as dns1, FacultyWeb
  • directory names reflect data they store such as /finance, /admissions
• No Method:  There is no system.
  • everyone picks what they want, first come first served

Different approaches have their advantages in different situations.  Functional names can be very helpful when used as aliases for servers or machines that perform particular functions.  By the same token, you don't want to use these as actual names for the machines for a number of reasons including what happens when you need to replace a machine.

Names can also help reflect locations so that network administrators can more easily locate and identify something that is acting up.  This may also help users connect to particular printers that are local to their current computer usage.

Now we need to discuss

• Protection Policy
  • What kind of security/protection does the namespace require?
  • What/who are you trying to protect the namespace from?
  • Do the names in the namespace need to be protected or just their attributes?
  • Who can add, change or delete entire records?
  • Can the owner of a record change certain fields within the record?

It is almost certain that everyone should be restricted from reading a namespace of login names associated with their passwords.  On the other hand, you are likely to want people to be able to figure out or find the e-mail addresses of other people within the organization.  When people publish to a corporate web they need to be able to find/identify the directory to which they should publish, though publication rights need to be password restricted.  This collection of possibilities goes on and on and must be well thought out before setting up the namespace.

In general, sys admins are going to want to highly restrict permission to make modifications to namespaces.  Users are going to be able to need to modify their passwords, but they shouldn't be allowed to modify their usernames or machine names.  These restrictions can be implemented in a number of ways from making use to passwords and code logic to making use of a database's own internal security measures.

Another major issue that requires careful policy level decision making is the

• Longevity Policy
  • When are entries in this namespace removed?

Some entries need to expire after certain dates or after a certain amount of inactivity.  For example, after students graduate their usernames and privileges are likely to be removed from most servers.  Subcontractors will also be in similar situations.  On the other hand, IP addresses can be quite scarce and are likely to change whenever a particular type of renewal of use isn't performed.

Now we continue with issues related to the

• Scope Policy
  • Where is the namespace to be used?
  • How global or local is a particular namespace?
    • How widely (wide) is it used?
    • How many services (thick) use it?

Do you want each user to have a different username and password for each server in your site?  Do you want server names to be duplicated at different locations in your firm around the world?  Maybe you want to use a mail alias for all of your e-mail servers, but there are a large number of e-mail servers in your organization?  How can this be resolved?  Maybe you have a Terry Knight working in three locations within your organization?

One also needs to determine how consistent the attributes for an entity in a namespace will be.  Maybe someone needs particular privileges on a particular server but not on another.  You want a user to be able to check their e-mail on the e-mail server, but you don't want them publishing webs on this server.  You need to design so that particular attributes can be set for particular entities as necessary.  Obviously, this can easily get complicated.

Finally we need to consider the

• Reuse Policy
  • How soon can a name be reused after it has been deleted or expired?

Usually a name can be reused quite rapidly.  But, for things like e-mail addresses you need to make certain you have taken care of forwarding.  Obviously, no one likes to receive e-mail or phone calls for other people that had the same namespace identifier.

Change and Centralization.  It is totally important to have well defined and known procedures for making additions, changes and deletions to namespaces.  These also need to be well documented.  Turnover and changes in job functions for sys admins are inevitable.

It is also almost always the case that it is better to have a single host, with intelligent backups, maintain your namespaces.  Then these namespaces can be pushed or accessed by other hosts by simple systematic processes.  Sometimes, firms even have one huge database that drives everything in terms of namespaces.  Obviously, the underlying processing needs to be exceedingly fast and effective.

Automating the processes for development, modification and updating namespaces as much as is reasonable is very important.  The automation should also adjust to the permission levels of the person interacting with the system.  Sys admins should be able to use the namespace related automation to a much greater degree than the normal user.  But this should also assist the customers to do as many of the updates as they realistically should for themselves.