Part of the sysadmin's art is the naming of computers and other non-human objects. (I would say "inanimate", but sysadmins know better.) Good naming is more difficult than non-sysadmins appreciate: a good name must be distinctive and pronounceable, must have no intrinsic meaning relevant to the context in which the names will be used, must not be too long or embarrassing to say, and so on. (If only parents took this much care over naming their children.)
Naming a series of objects is even more difficult: each name must individually meet these requirements, yet at the same time it is desirable for the names to be thematically related. A good naming scheme has a large number of thematically-related good names, leaving room for the series to grow.
In an attempt to help the naming task, here are some prepared collections of names suitable for naming computers. The name lists below give not just the raw names, but also (where required) some explanation of their relationship to the list's theme.
The name lists:
Contributions of similarly prepared lists would be welcome. Minimum size 20 names, please.
A simple way to obtain a list of related names is to search a word list for words sharing a particular prefix or suffix, such as "bu-" or "-ind". Some selection is required within the raw word list. The resulting names are very obviously grouped.
Author: A. Main. Date: October 2001. Abstract:
This memo examines practical problems in the use of the ICANN generic top-level domains, in particular that they fail to provide a stable namespace that is required by some protocols. The practical problems are traced to underlying problems in domain name allocation policy in those domains. Possible solutions to the problem are discussed, including the possibility of a new top-level domain to be managed in accordance with IANA assigned-numbers principles.
Available as plain text, RFC Editor nroff.
This is my response to a technical problem that has been caused by political decisions. I advocate technical fixes that completely subvert the faulty policies.
Unfortunately the IETF consensus was that this was the wrong thing to do. There was never a consensus on why it was the wrong thing: responses included "there is no a problem", "the problem isn't a problem in this context", "a technical fix is inappropriate", "the technical fix can be achieved within the current architecture", and "the problem is insoluble". I am not currently pursuing this issue, and I don't intend to raise similarly controversial issues in the IETF in the future.
Bob Frankston has proposed a similar idea, under the name "dotDNS". His essay goes into some depth concerning how the new TLD would be used.
Author: A. Main. Date: 2003-10-06. Abstract:
Many Internet protocols have as an essential element a mapping from a textual name to some resource. There is a technique, popular in some circles, of providing a default resource, which is returned in response to a lookup that does not match any known name, rather than returning an indication that there is no resource of that name. This technique is dangerous and is to be discouraged in all contexts. This memo discusses the issues.
Available as plain text, RFC Editor nroff.