Rather than use a timestamp an alternative approach is to define a conformance unit that requires the use of the NamespaceMetadata Type defined in Part 5, section 6.3.13. The intent is that this will be implemented by servers to provide information for clients that need to validate stored configuration data. This conformance unit can be used with any profile.

The NamespaceMetadata type defines metadata for each namespace in a server.
Servers that implement this conformance unit shall keep two fields updated, NamespaceUri and NamespacePublicationDate. These shall be required to contain data for each namespace in the server. When the namespace changes these fields shall be updated.

This conformance unit to be added to the CTT for server validation. At this time there is no corresponding conformance unit for clients.

Clients can read these values and compare it to stored configuration data to determine if its view of the namespace has changed.

Yes, we need a way to enable the Client to detect whether the persisted NodeIds in a Client are still valid.
(No matter how the NodeIds were collected, maybe by NodeSet import or by previous browsing of the Server).

To have an indication not only for the complete IM but for each separate Namespace is a good idea. This would for example reduce the time for a NodeId-refresh if only a few Nodes of the instance space have been changed.

Using a NamespacePublicationDate for detecting such changes would basically work, but compared to GUID or CRC there is a relatively high chance that the same NamespacePublicationDate is generated for different IMs.
Example: Some automated config-management process applies changes to several identical machines (but maybe with slightly different IMs). Server X in machine 1 and Server X in machine 2 might have the same identiy (even the same PublishingDate), but different IMs.
For this reason I would prefer using a GUID (or a CRC?), which is more safe in avoiding duplicates. Could such an GUID be added to the definition of NamespaceMetaData as optional property?

I prefer a CRC but CRCs are more expensive to generate.

A CRC would be better because a Guid will be different each time it is generated even if the namespace has not changed. A client cares about the contents of the namespace, not necessarily when it was generated or loaded into a server.

If a CRC is used we should think about which attributes should be included. For example, for all nodes the NodeId and BrowsePath should be included. For Variable nodes it should include ValueRank, ArrayDimensions (even if null), DataType, and possibly TypeDefinition.

If a system is smart enough it can also make sure it changes the GUID only then if the namespace has changed.
We have to consider 2 cases:
1: An external instance (tool/engineer) transfers a new IM to a server ... then it is up to the tool whether it generates a new GUID because it has changed relevant data
2: The server itself is the reason for the change (e.g. detection of a changes in the hardware-configuration)

In both cases it would be a very complex task to standardize how a CRC has to be built ... which attributes to include etc... and at the end we might come to the conclusion that the complete namespace including all atrributes and references should be included.
I would propose a GUID and give the advice that the generation of a new GUID should only happen when necessary.
Then a constraint device could argue that it does not have enough resources to do a extensive comparison in the background, and it might change the GUID even if the newly transferred namespace is actually the same.
Another device with frequently changing IM might decide to not persists some of its 'dynamic' NodeIds at all to avoid too many write cycles on the flash, it would generate a new GUID at every startup.

Devices which have a very large amount of nodes (where it actually matters that the GUID is only changed when absolutely necessary) usually also have enough resources to do a smarter handling of the GUID. They could also generate a CRC and convert it to a GUID, with the advantage that we don't have to specify how to generate the CRC.

Agreed that no spec changes are needed, just Conformance Units and Profiles for Clients and Servers that use this feature. David Lavine has agreed do work on CUs and Profiles for this with advice from Paul.

David has left Rockwell, so there is no volunteer to work on this.