« A couple more: kudos, and mixed kudos/gripe | Main | Poor choices in automatic / registration-based naming »

June 26, 2009

Principles

If I could sum up one lesson that I'd like for anyone who reads these pages to take away it would be this:

The act of naming is personal, but with communal aftereffects.

Another way of thinking of this, if you don't mind a foray into religious studies (and if you do, skip to the next paragraph, it's okay), is that naming is perhaps the most sacred act an individual may perform, being an act of participation in a divinity and community of language. But bear in mind that religions, by definition, aren't mystical - the very term "religion" defines a community of belief and a shared language for discussing those beliefs - so naming participates in both a very personal act of recognizing and externalizing your perceptions, and a very social act because the name becomes available for others to use, interpret, and acknowledge.

While it may be perfectly fine for me to name my child "Beeblebrox", because that's what I always think of him as, the name will be used by other people, too. That's one reason why despite the fact that a parent may always have a nickname for a child, they still give the child a respectable name (unless the parent in question is Frank Zappa, of course). That's just a metaphor for CNAME and PTR, BTW. And may well have nothing to do with what's actually in /etc/hostname, either - the PTR is for external recognition, CNAME for alternate use. Oh, and you're not Frank Zappa. He could get away with it. You can't.

Names, once given, convey information, and do so beyond the local context. Just because I call a server "skynyrd" because (personal reason) it had one incident where it crashed unexpectedly doesn't mean I shouldn't name it so that (public, community-oriented reason) it may be recognized for what it is beyond my network, in this case a database and Web server. In the case of an IP dynamically assigned to residential cable users via DHCP, don't assume that just because your whois SWIP for that netblock has a memo or note to that effect, that the PTRs don't need to - why not keep the name itself as the locus of such information? You're more likely to change the PTRs than you are to remember to change the note in a whois record, once those IPs are reallocated as statically assigned commercial DSL. In other words:

Maximize the information associated with a name, and keep it closest to the individual unit to which it is associated.

Think of the concept of identification. In its most basic of definitions, identification is where one thing is the same as another - in this case, a name refers to an object, so the name may be used in place of the object - they are the same thing for the purposes of the particular context. In slightly more scary contexts, you might be traveling and have someone demand to see your identification, in other words, the papers that certify your name and enable strangers to confirm that the name (and perhaps picture, fingerprints, and other biometrics) matches the body.

When naming servers (or dialup ranges, or NAT pools, etc.) think of the context in which the names will be evaluated - it will be a stranger, probably not thrilled to be evaluating your host(s) at all, probably considering them somewhat of a threat, and so forth. Worst case, it will be a stranger's leave-behind rules for evaluating the same, and there will be all the personality of an automatic teller machine involved. When naming, put your best, most formal foot forward, and don't crack jokes in line at the bomb screening.

Names are detachable containers of information; don't assume the local context and assumptions and codes will survive translation to a new context.

Finally, names differentiate one object from another. If I call one name server itchy and another scratchy, I can tell the difference between the two. If I name every last one of my end user PTRs tm.net.my, or beamcablesystem.in, the names fail the differentiation test. Put another way, there is an inherent distrust in empty, generic labels - think of "Agent Smith" from the Matrix movies - he was not real, he was merely an expression or avatar of the Matrix, and could appear as one or many, and the more he was, the more threatening. Generic name, multiple copies translates as a threat, or at least diminishes trust.

Names should be unique and informative, not generic, if their referents are to provide important services you want strangers to trust.

Okay, that's enough for now, time to go get some hot dogs and a little beach time.

Posted by schampeo at June 26, 2009 11:56 AM