A subtree manager is an application program that has assumed additional responsibilities. It supports any number of instances. It is not required to register any of them with CMIP services. It has requested and been granted ownership of a portion of the naming tree, which includes all instances contained within it.

All scoped indications that can include a member of the subtree owned by the subtree manager are passed to the subtree manager. It is responsible for managing scoping within its subtree and for creating all of the responses from its instances.

The subtree manager indicates to CMIP services that it has completed the responses from its supported instances. It cannot use the MIB variables &DN or &OC for any of its instances that are not registered. For information about MIB variables, see MIB variable format.

Once a subtree manager has registered itself, it establishes ownership of a subtree. At that point, no other application program can register objects within that subtree. Only the subtree manager can register additional objects within the subtree. For each leaf of the subtree that the subtree manager registers, it must first register all instances in that branch of the tree. An object cannot be registered unless its parent has been registered. Messages to an object within the subtree are assigned the local identifier of the subtree manager object. This is the local identifier that was explicitly requested.

A process that registers as a subtree manager can assume responsibility for one or more subtrees of the naming hierarchy. This capability allows the process to register only a small number of instances. A minimum of one instance is required. For each instance that it chooses not to register, the subtree manager must do the global-to-local name mapping and scoping functions that are provided by CMIP services for registered instances.

If many of the instances an application program represents are dynamic and changing frequently, it might be preferable for the application program to act as a subtree manager, instead of registering all of its instances. In that case, the overhead of registering the instances makes management too expensive to be practical.

Another example is when the application program chooses to control scoping itself. For example, if an agent application program is to receive scoped requests for a large number of objects, it might be better to receive a single scoped request. (A single scoped request is one that is not replicated by CMIP services.) A single scoped request might allow the request to be processed more efficiently internally.

Here we list one advantage and one disadvantage to registering as a subtree manager. The advantage is that a subtree manager can avoid registering some or all of its object instances and can control scoped operations. The disadvantage is that a subtree manager is required to assign names within the name space it owns. It must also ensure that the names are unique. It must perform all of the scoping function within its name space, a requirement that makes coding the application program more complicated.

When designing an application program, you must decide between writing additional code to provide these functions or registering all instances.