This section describes a convention for the definition of MIB views and, using that convention, presents example configurations of MIB views for SNMPv2 contexts that refer to local object resources.
A MIB view is defined by a collection of view subtrees (see Section 2.6), and any MIB view may be represented in this way. Because MIB view definitions may, in certain cases, comprise a very large number of view subtrees, a convention for abbreviating MIB view definitions is desirable.
The convention adopted in [4] supports abbreviation of MIB view definitions in terms of families of view subtrees that are either included in or excluded from the definition of the relevant MIB view. By this convention, a table locally maintained by each SNMPv2 entity defines the MIB view associated with each SNMPv2 context that refers to local object resources. Each entry in the table represents a family of view subtrees that (according to the type of that entry) is either included in or excluded from the MIB view of some SNMPv2 context. Each table entry represents a subtree family as a pairing of an OBJECT IDENTIFIER value (called the family name) together with a bitstring value (called the family mask). The family mask indicates which sub-identifiers of the associated family name are significant to the definition of the represented subtree family. For each possible MIB object instance, that instance belongs to the view subtree family represented by a particular table entry if
The appearance of a MIB object instance in the MIB view for a particular SNMPv2 context is related to the membership of that instance in the subtree families associated with that SNMPv2 context in local table entries:
The subtree family represented by a table entry for which the associated family mask is all ones corresponds to the single view subtree identified by the family name for that entry. Because the convention of [4] provides for implicit extension of family mask values with ones, the subtree family represented by a table entry with a family mask of zero length always corresponds to a single view subtree.
Context Type Family Name Family Mask
lucy included internet ''H
Table 6: View Definition for Minimal Agent
Using this convention for abbreviating MIB view definitions, some of the most common definitions of MIB views may be conveniently expressed. For example, Table 6 illustrates the MIB view definitions required for a minimal SNMPv2 entity that having a single SNMPv2 context for which the associated MIB view embraces all instances of all MIB objects defined within the SNMPv2 Network Management Framework. The represented table has a single entry. The SNMPv2 context (lucy) for which that entry defines the MIB view is identified in the first column. The type of that entry (included) signifies that any MIB object instance belonging to the subtree family represented by that entry may appear in the MIB view for the SNMPv2 context lucy. The family name for that entry is internet, and the zero-length family mask value signifies that the relevant subtree family corresponds to the single view subtree rooted at that node.
Another example of MIB view definition (see Table 7) is that of a SNMPv2 entity having multiple SNMPv2 contexts with distinct MIB views. The MIB view associated with the SNMPv2 context lucy comprises all instances of all MIB objects defined within the SNMPv2 Network Management Framework, except those pertaining to the administration of SNMPv2 parties. In contrast, the MIB view attributed to the SNMPv2 context ricky contains only MIB object instances defined in the system group of the Internet-standard MIB together with those object instances by which SNMPv2 parties are administered.
Context Type Family Name Family Mask
lucy included internet ''H
lucy excluded snmpParties ''H
ricky included system ''H
ricky included snmpParties ''H
Table 7: View Definition for Multiple Contexts
A more complicated example of MIB view configuration illustrates the abbreviation of related collections of view subtrees by view subtree families (see Table 8). In this example, the MIB view associated with the SNMPv2 context lucy includes all object instances in the system group of the Internet-standard MIB together with some information related to the second network interface attached to the managed device. However, this interface-related information does not include the speed of the interface. The family mask value 'FFA0'H in the second table entry signifies that a MIB object instance belongs to the relevant subtree family if the initial prefix of its name places it within the ifEntry portion of the registration hierarchy and if the eleventh sub-identifier of its name is 2. The MIB object instance representing the speed of the second network interface belongs to the subtree families represented by both the second and third entries of the table, but that particular instance is excluded from the MIB view for the SNMPv2 context lucy because the lexicographically greater of the relevant family names appears in the table entry with type excluded.
The MIB view for the SNMPv2 context ricky is also defined in this example. The MIB view attributed to the SNMPv2 context ricky includes all object instances in the icmp group of the Internet-standard MIB, together with all information relevant to the fifth network interface attached to the managed device. In addition, the MIB view attributed to the SNMPv2 context ricky includes the number of octets received on the fourth attached network interface.
Context Type Family Name Family Mask
lucy included system ''H
lucy included { ifEntry 0 2 } 'FFA0'H
lucy excluded { ifSpeed 2 } ''H
ricky included icmp ''H
ricky included { ifEntry 0 5 } 'FFA0'H
ricky included { ifInOctets 4 } ''H
Table 8: More Elaborate View Definitions
While, as suggested by the examples above, a wide range of MIB view configurations are efficiently supported by the abbreviated representation of [4], prudent MIB design can sometimes further reduce the size and complexity of the most likely MIB view definitions. On one hand, it is critical that mechanisms for MIB view configuration impose no absolute constraints either upon the access policies of local administrations or upon the structure of MIB namespaces; on the other hand, where the most common access policies are known, the configuration costs of realizing those policies may be slightly reduced by assigning to distinct portions of the registration hierarchy those MIB objects for which local policies most frequently require distinct treatment.