Identification is not a primary CM element

Although it is generally accepted that Configuration Identification is a basic element of Configuration Management (CM), I don't agree that is should be. Why not?

The core of CM is control of configurations. To know what configurations we are controlling, we need to identify them. To avoid confusing one configuration for another, we need to uniquely identify them. Equal configurations should not be identified differently. As you see, CM is interested in unique identification, but how the identification looks like is not relevant, as long is it is a uniquely. Of course we need naming conventions, but how it looks like depends on the requirements for humans, automation or (CM) tools.
As such configuration identification is a secondary requirement for CM, not a primary element. The identification process does not even need to be part of the CM discipline, in which case CM is a user of identifiers, just like most other people in a project, but with a different purpose than other people.

Identification and naming conventions
An important implication is that when using a version control tool or a CM tool - I assume you understand the difference, but for now that's irrelevant - the unique identification may be left to the tool. This often results in unreadable object identifiers (e.g. 23987sg2b.38h830okdh34.8827481) but this is sufficient for CM. Even if you do CM by hand, you may just keep a list of sequential numbers.

In practice it is more convenient to have human-readable identifiers such as file names or document titles (or document identifiers) and/or to have identifiers that ease automation (scripting). Also it is often practical to put semantic (meta-)information in the identifier, such as a file type or a component identification. Because identification is not primary requirement for CM, the definition of naming conventions does not have to be a primary responsibility of CM people. You may document it in the configuration management plan (CMP), you may assist in the definition of a naming convention, your may be involved in auditing the compliance to the naming convention and if you are responsible for automation/scripting you may have their own naming requirements, but ultimately you shouldn't really care (as long as identification is unique).

Identification of everything?
Another reason for not considering identification as a basic element of CM is that not every identification should be the responsibility of CM. In principle, only the configurations that are under configuration control need to be identified for CM - note the different between "for CM" and "by CM". Some identifiers are an attribute value without identifying a configuration. Attribute values are for example enumerated values that are used on forms or documents, database identifiers (e.g. PRCR numbers) or just names (e.g. person names, product family names). In practice the distinction between an attribute value and a configuration is not always clear.

So what?
The reason that this is important is that CM is often held responsible for naming conventions and for identification. Commercial names are the responsibility of Marketing or Product Management. Identification of a certain technology used in the product is the responsibility of Engineering. Identification of production lots is a responsibility of Logistics. Not everything that has to do with identification should be considered a CM responsibility. In fact, CM is not really interested in identification as long as configurations can be controlled properly.