Internet Draft Data Filter MIB for SNMPv2 Aug 1995 Data Filter MIB for Version 2 of the Simple Network Management Protocol (SNMPv2) 1 Aug 1995 draft-ietf-snmpv2-data-filter-mib-00.txt David Harrington Cabletron Systems, Inc. dbh@ctron.com Sandeep Asija Cabletron Systems, Inc. asija@ctron.com Daniel O. Mahoney II Cabletron Systems, Inc. dmahoney@ctron.com David Arneson Cabletron Systems, Inc. arneson@ctron.com Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This document describes and defines a portion of the Management Information Base (MIB) for use with the Simple Network Management Protocol version 2. In particular, it defines objects for delimiting managed information in data access requests. Expires January 1996 [Page 1] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 1. Introduction A management system contains: several (potentially many) nodes, each with a processing entity, termed an agent, which has access to management instrumentation; at least one management station; and, a management protocol, used to convey management information between the agents and management stations. Operations of the protocol are carried out under an administrative framework which defines authentication, authorization, access control, and privacy policies. Management stations execute management applications which monitor and control managed elements. Managed elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information. Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1], termed the Structure of Management Information (SMI) [2]. The model described here is largely derived from the work of the SNMPv2 Working Group, as published in RFC1445 and RFC1447, and subsequent internet drafts. The administrative model described in those RFCs and drafts was determined to be inappropriate for some users, especially the required security framework. Those aspects of the model which allowed better specification of subsets of managed data at an agent, namely contexts and MIBviews, were found generally acceptable. It is the purpose of this document, the Data Filter MIB for SNMPv2, to define how data filters can be applied to realize effective specification and access control for managed data in a variety of configurations and environments in a model which can be used with a variety of security frameworks, commonly referred to as admin models. It is the purpose of this document to define the properties associated with SNMPv2 contexts, SNMPv2 MIBviews, and their inter-relationships, and to define managed objects which correspond to those properties, and to do so without dependence on a specific security or admin model. 1.1 Acknowledgments The bulk of this document was taken directly from the draft of the SNMPv2 Working Group published draft, draft-ietf-snmpv2-party-ds-02.txt, authored by Jeffrey D. Case, James Galvin, Keith McCloghrie, Marshall T. Rose, and Steven Waldbusser. The authors also wish to acknowledge the contributions of the SNMPv2 Working Group in general. Harrington [Page 2] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 1.2. A Note on Terminology For the purpose of exposition, the original Internet-standard Network Management Framework, as described in RFCs 1155, 1157, and 1212, is termed the SNMP version 1 framework (SNMPv1). The current framework is termed the SNMP version 2 framework (SNMPv2). 2. Overview - A management domain typically contains a large amount of management information. Each individual item of management information is an instance of a managed object type. The definition of a related set of managed object types is contained in a Management Information Base (MIB) module. Many such MIB modules are defined. For each managed object type it describes, a MIB module defines not only the semantics and syntax of that managed object type, but also the method of identifying an individual instance so that multiple instances of the same managed object type can be distinguished. 2.1. Contexts Typically, there are many instances of each managed object type within a management domain. For simplicity, the method for identifying instances specified by the MIB module does not allow each instance to be distinguished amongst the set of all instances within the management domain; rather, it allows each instance to be identified only within some scope or "context", where there are multiple such contexts within the management domain. Often, a context is a physical device, or perhaps, a logical device, although a context can also encompass multiple devices, or a subset of a single device, or even a subset of multiple devices. Thus, in order to identify an individual item of management information within the management domain, its context must be identified in addition to its object type and its instance. Note that this requires each context to have a globally-unique identification within the management domain. Note also that the same item of management information can exist in multiple contexts. For example, the managed object type, ifDescr, is defined as the description of a network interface. To identify the description of device-X's first network interface, three pieces of information are needed: logical device-X (the context), ifDescr (the managed object type), and "1" (the instance). Harrington [Page 3] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 Management information often changes over time. Thus, when naming a specific value of a managed object instance, an indication of time is needed. In most situations, it is the value at the current time which is of interest to the network manager. There are, however, situations where times other than the current time are of interest. For example, where the value of a device parameter after the device's next reboot is to be different to its current value. To accommodate this, each context has an associated notion of time, called its temporal domain. This allows, for example, one context to refer to the current values of a device's parameters, and a different context to refer to the values that the same parameters for the same device will have after the device's next restart. 2.2. Authorization: Read/Write Access to Information For security reasons, it is often valuable to be able to restrict the operations allowed on the management information within a particular context. For example, one management application might be prohibited from write-access to a particular context, while another might be allowed to perform any type of operation. Data filter structures contain two view indexes. One identifies what data is accessible for reading, the other identifies what data is accessible for writing. If the index is empty(0), no data is accessible for that operation type. If the index is all(1), then any object in the context is accessible for that operation, if the definition of the object allows the operation. The intersection of context and readViewIndex and writeViewIndex describe four possible access modes for each context: 1) not accessible: readView=empty(0), writeView=empty(0) no object in the context can be read or written, regardless of the access type specified in the object definition. 2) read-only: readView=internet(1), writeView=empty(0) any object in the context can be read, if the access-type specified in the object definition allows the operation. No object in the context can be written, regardless of the access type specified in the object definition. 3) write-only: readView=empty(0), writeView=internet(1) any object in the context can be written, if the access-type of the object definition allows the operation. No object can be read, regardless of the access-type specified in the object definition. 4) read-write: readView=internet(1), writeView=internet(1) any object in the context can be read and/or written, if the access-type specified in the object definition allows the operation. ViewIndexes empty(0) and all(1) are special well-known MIBviews, which are not necessarily implemented as entries in a viewTable. If only views empty(0) and all(1) are supported, no viewTable is required. Harrington [Page 4] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 2.3. Authorization: Limiting Access via MIB Views It is often valuable to be able to restrict the access rights of some management applications to only a subset of the management information in the management domain. To provide this capability, access to a context may be limited to a "MIB view" which details a specific set of managed object types (and optionally, the specific instances of object types) within that context. So, by providing access rights to a management application in terms of the particular (subset) MIB view it can access for that context, the management application is restricted in the desired manner. Since managed object types (and their instances) are identified via the tree-like naming structure of ISO's OBJECT IDENTIFIERs [1, 2], it is convenient to define a MIB view as the combination of a set of "view subtrees", where each view subtree is a sub-tree within the managed object naming tree. Thus, a simple MIB view (e.g., all managed objects within the Internet Network Management Framework) can be defined as a single view sub-tree, while more complicated MIB views (e.g., all information relevant to a particular network interface) can be represented by the union of multiple view sub-trees. While any set of managed objects can be described by the union of some number of view subtrees, situations can arise that would require a very large number of view subtrees. This could happen, for example, when specifying all columns in one conceptual row of a MIB table because they would appear in separate subtrees, one per column, each with a very similar format. Because the formats are similar, the required set of subtrees can easily be aggregated into one structure. This structure is named a family of view subtrees after the set of subtrees that it conceptually represents. A family of view subtrees can either be included or excluded from a MIB view. The well-known views empty(0) and all(1) may be implemented as entries or as virtual entries according to the needs of the implementation, but the MIB views represented by empty(0) and all(1) must always correspond to the empty set of views, and the complete set of views, and that representation may not be modified. Views other than empty(0) and all(1) must have view indexes in the range 2..2147483647, and must have corresponding viewEntries kept in the Local DataFilter Datastore. 2.4 An SNMPv2 Entity's Local DataFilter Datastore An SNMPv2 entity is an SNMPv2 protocol implementation used by an SNMPv2 agent and/or by one or more management applications. The local contexts, views, and datafilters at an SNMPv2 entity are those which operate locally, and are those for which the SNMPv2 entity acts as a SNMPv2 agent in responding to requests. Harrington [Page 5] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 Each SNMPv2 entity needs to retain its own set of information about contexts, datafilters, and (in agents) views. This set of information is called the SNMPv2 entity's Local DataFilter Datastore (LDD) because it is locally- stored information. Note that the LDD contains information on both local and/or remote contexts and datafilters, and may optionally include local and/or remote views. The LDD may be part of a Local Configuration Datastore, which also contains additional structures to support a security model. In order to allow an SNMPv2 entity's LDD to be configured, the LDD needs to be accessible as managed objects. The MIB module contained in this document, the SNMPv2 DataFilter MIB, defines these managed object types. 2.5 Maintenance DataFilter The internalContext is local to any SNMPv2 entity acting in an agent role, and has these characteristics: contextIdentity 0.0 contextType local (to agent) Note that internalContext has a StorageType of "readOnly" [4], in that it always exists and cannot be modified. Further, internalContext MUST NOT be accessible to entities outside of an SNMPv2 entity itself. Thus, even though conceptually represented in the LDD, internalContext is not visible through the SNMPv2 DataFilter MIB. It should be noted that the use of a fixed context-identity (internalContext) is contrary to the architectural principles of the administrative framework: in SNMPv2, management information is always uniquely identified by a combination of context local-entity, context local-time, object type, and object instance. However, in the interests of both simplicity and the reuse of infrastructure, maintenance functions are provided "outside" of the administrative infrastructure available to applications which make use of an SNMPv2 entity. It must be emphasized that a management communication using internalContext belongs to a logically different protocol than SNMP, just as the ICMP is logically a different protocol from the IP. Thus, use of internalContext, except for the purpose of performing maintenance functions, is prohibited. internalContext is reserved for maintenance function usage by all admin models. The functions available are admin-model dependent. Some admin models may specify a well-known restricted view within the internalContext context via a predefined MIBview, and thus may require that a viewTable. 3. Elements of the Model This section provides a more formal description of the model. Harrington [Page 6] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 3.1 SNMPv2 Context An SNMPv2 context is a collection of management information accessible by an SNMPv2 entity. For a SNMPv2 context which is realized by an SNMPv2 entity, that SNMPv2 entity uses locally-defined mechanisms to access the management information identified by the SNMPv2 context. Each SNMPv2 context has a set of attributes which include the following: contextIdentity - the value which uniquely identifies the SNMPv2 context. contextType - a value which indicates that this context is of type local which is realized by the local SNMPv2 entity, or of type remote which is realized by some other SNMPv2 entity. contextLocalEntity - the value which identifies the local entity (e.g., a logical device local to the SNMPv2 entity which realizes the context) whose management information is contained in the SNMPv2 context. contextLocalTime - the temporal context of the management information contained in the SNMPv2 context. An SNMPv2 entity's LDD includes information on all local contexts and on any remote contexts which are known locally. 3.2. View Subtree A view subtree is the set of all MIB object instances which have a common ASN.1 OBJECT IDENTIFIER prefix to their names. A view subtree is identified by the OBJECT IDENTIFIER value which is the longest OBJECT IDENTIFIER prefix common to all (potential) MIB object instances in that subtree. When the OBJECT IDENTIFIER prefix identifying a view subtree is longer than the OBJECT IDENTIFIER of an object type defined according to the SMI [2], then the use of such a view subtree for access control has granularity at the object instance level. Such granularity is considered beyond the scope of an SNMPv2 agent. However, access control information is also used in determining which SNMPv2 entities operating on behalf of management applications should receive trap notifications (Section 4.2.6 of [3]). As such, agent implementors might wish to provide instance-level granularity in order to allow SNMPv2 entity operating on behalf of management applications to use fine-grain configuration of trap notifications. Harrington [Page 7] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 3.3. View Subtree Families A family of view subtrees is 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 family's definition. For each possible managed object instance, that instance belongs to a particular view subtree family if both of the following conditions are true: o the OBJECT IDENTIFIER name of the managed object instance contains at least as many sub-identifiers as does the family name, and o each sub-identifier in the the OBJECT IDENTIFIER name of the managed object instance matches the corresponding sub-identifier of the family name whenever the corresponding bit of the associated family mask is non-zero. When the configured value of the family mask is all ones, the view subtree family is identical to the single view subtree identified by the family name. When the configured value of the family mask is shorter than required to perform the above test, its value is implicitly extended with ones. Consequently, a view subtree family having a family mask of zero length always corresponds to a single view subtree. 3.4. MIB View A MIB view is a subset of the set of all instances of all object types defined according to the SMI [2] within an SNMPv2 context, subject to the following constraints: o It is possible to specify a MIB view which contains the full set of all object instances within an SNMPv2 context. o Each object instance within a MIB view is uniquely named by an ASN.1 OBJECT IDENTIFIER value. As such, identically named instances of a particular object type must be contained within different SNMPv2 contexts. That is, a particular object instance name resolves within a particular SNMPv2 context to at most one object instance. A MIB view is defined as a collection of view subtree families, where each view subtree family has a type. The type determines whether the view subtree family is included in, or excluded from, the MIB view. A managed object instance is contained/not contained within the MIB view according to the view subtree families to which the instance belongs: Harrington [Page 8] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 o If a managed object instance belongs to none of the relevant subtree families, then that instance is not in the MIB view. o If a managed object instance belongs to exactly one of the relevant subtree families, then that instance is included in, or excluded from, the relevant MIB view according to the type of that subtree family. o If a managed object instance belongs to more than one of the relevant subtree families, then that instance is included in, or excluded from, the relevant MIB view according to the type of a particular one of the subtree families to which it belongs. The particular subtree family is the one for which, first, the associated family name comprises the greatest number of sub- identifiers, and, second, the associated family name is lexicographically greatest. 3.5. Data Filters A data filter defines a subset of managed information represented by an SNMPv2 agent. The subset is delimited by the context in which the objects are realized, the view subtrees which include or exclude particular subtree families of managed information within the context, and the read/write access modes of the specified subsets. A DataFilter has attributes which include the following: datafilterIdentity - the value which uniquely identifies the data filter datafilterContext - the context in which the management information is realized datafilterReadViewIndex - the read MIB view - the subset of management information within the local datafilterContext for which read-access will be permitted to authorized entities datafilterWriteViewIndex - the write MIB view - the subset of management information within the local datafilterContext for which write-access will be permitted to authorized entities 4. Definitions SNMPv2-DATAFILTER-MIB DEFINITIONS ::= BEGIN Harrington [Page 9] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, OBJECT-TYPE, snmpModules, zeroDotZero FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, StorageType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; datafilterMIB MODULE-IDENTITY LAST-UPDATED "9503190000Z" ORGANIZATION "IETF SNMPv2 Working Group" CONTACT-INFO " David Harrington Postal: Cabletron Systems Inc. ATTN: David Harrington Engineering - Durham P.O. Box 5005 Rochester NH 03866-5005 USA Phone: +1 603 337 7357 Email: dbh@ctron.com" DESCRIPTION "The MIB module describing SNMPv2 data filters." REVISION "9508010000Z" DESCRIPTION "The initial revision of the MIB module from which this is derived was published as RFC 1447." ::= { snmpModules xxxx } -- textual conventions Context ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Denotes a SNMPv2 context identifier. Note that agents may impose implementation limitations on the length of OIDs used to identify Contexts. As such, management stations creating new contexts should be aware that using an excessively long OID may result in the agent refusing to perform the set operation and instead returning the appropriate error response, e.g., noCreation." SYNTAX OBJECT IDENTIFIER -- administrative assignments datafilterAdmin OBJECT IDENTIFIER ::= { datafilterMIB 1 } Harrington [Page 10] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 -- definitions of temporal domains temporalDomains OBJECT IDENTIFIER ::= { datafilterAdmin 2 } currentTime OBJECT-IDENTITY STATUS current DESCRIPTION "The temporal domain which refers to management information at the current time." ::= { temporalDomains 1 } restartTime OBJECT-IDENTITY STATUS current DESCRIPTION "The temporal domain which refers to management information upon the next re-initialization of the managed device." ::= { temporalDomains 2 } cacheTime OBJECT-IDENTITY STATUS current DESCRIPTION "The prefix for temporal domains which refer to management information that is cached. In particular, the temporal domain: { cacheTime N } and guaranteed to be at most N seconds old." ::= { temporalDomains 3 } -- object assignments datafilterMIBObjects OBJECT IDENTIFIER ::= { datafilterMIB 2 } -- SNMPv2 data filter information -- SNMPv2 datafilter contexts datafilterContexts OBJECT IDENTIFIER ::= { datafilterMIBObjects 2 } dfContextTable OBJECT-TYPE SYNTAX SEQUENCE OF DfContextEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SNMPv2 Context database." ::= { datafilterContexts 1 } Harrington [Page 11] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 dfContextEntry OBJECT-TYPE SYNTAX DfContextEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally held information about a particular SNMPv2 context." INDEX { IMPLIED dfContextIdentity } ::= { dfContextTable 1 } DfContextEntry ::= SEQUENCE { dfContextIdentity Context, dfContextType INTEGER, dfContextLocalEntity OCTET STRING, dfContextLocalTime OBJECT IDENTIFIER, dfContextStorageType StorageType, dfContextStatus RowStatus } dfContextIdentity OBJECT-TYPE SYNTAX Context MAX-ACCESS not-accessible STATUS current DESCRIPTION "A context identifier uniquely identifying a particular SNMPv2 context. This object is prohibited from taking the value { 0 x } for any value of x." ::= { dfContextEntry 1 } dfContextType OBJECT-TYPE SYNTAX INTEGER { local(1), remote(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of context. local(1) - this conceptual row refers to a SNMPv2 context containing MIB views of a locally accessible entity; the value of the corresponding instances of the dfContextLocalEntity and dfContextLocalTime objects provide further information on the local entity and its temporal domain. remote(2) - this conceptual row refers to a SNMPv2 context which is realized by a remote SNMPv2 entity." DEFVAL { local } ::= { dfContextEntry 2 } Harrington [Page 12] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 dfContextLocalEntity OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "If the value of the corresponding instance of the dfContextType is local(1), then the value of an instance of this object uniquely identifies the local entity (e.g., a logical device managed by the same agent) whose management information is represented by the SNMPv2 context. The empty string indicates that the context represents the SNMPv2 entity's own local management information; otherwise, a non-empty string indicates that the context represents management information of some other local entity, e.g., 'Repeater1'. If the value of the corresponding instance of the dfContextType is remote(2), then the value of an instance of this object identifies an entity which is local to the SNMPv2 entity which realizes this SNMPv2 context, and whose management information is represented by the SNMPv2 context." DEFVAL { ''H } -- the empty string ::= { dfContextEntry 3 } dfContextLocalTime OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "If the value of the corresponding instance of the dfContextType is local(1) or remote(2), then the value of an instance of this object identifies the temporal context of the management information represented by this SNMPv2 context." DEFVAL { currentTime } ::= { dfContextEntry 4 } dfContextStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the dfContextTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { dfContextEntry 5 } Harrington [Page 13] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 dfContextStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row in the dfContextTable. A context is not qualified for activation until instances of all corresponding columns have consistent values. For those columnar objects which permit write-access, their value in an existing conceptual row can be changed irrespective of the value of dfContextStatus for that row." ::= { dfContextEntry 6 } -- MIB views datafilterViews OBJECT IDENTIFIER ::= { datafilterMIBObjects 4 } dfViewNextIndex OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "A currently unassigned value of dfViewIndex. The value 0 indicates that no unassigned values are available. In order to cause a non-zero value of this object to be assigned for use as the dfViewIndex of a future MIB view, it must be successfully modified by a set operation. When modified by a set operation, the new value supplied must precisely match the value presently held by the object. If not, the management protocol set operation fails with an error of `inconsistentValue'. Immediately after the completion of a successful set operation, the agent must modify the value of this object. The algorithm for modifying the value is implementation- dependent, and may use a subset of values within 2..2147483647. However, the agent must guarantee that the new value is not assigned to any in-use value of dfViewIndex, e.g., is not pointed to by any other MIB object. A management station creates a new MIB view using this algorithm: - issue a management protocol retrieval operation to obtain the value of dfViewNextIndex; if the retrieved value is zero, a new MIB view cannot be created at this time; if only the empty(0) and all(1) views are supported, the agent should return zero. Harrington [Page 14] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 - issue a management protocol set operation for dfViewNextIndex, supplying the same value as obtained in the previous step; - if the set operation succeeds, use the supplied value as the dfViewIndex of the new MIB view; - issue a management protocol set operation to create an instance of the dfViewStatus object setting its value to `createAndGo' or `createAndWait' (as specified in the description of the RowStatus textual convention)." ::= { datafilterViews 2 } dfViewTable OBJECT-TYPE SYNTAX SEQUENCE OF DfViewEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally held information about the subtrees of MIB views known to this SNMPv2 entity. Note that a MIB view which has no subtrees defined for it has no entries in this table. Each SNMPv2 context which is locally accessible has zero or more MIB views. Each MIB view is defined by two collections of view subtrees: the included view subtrees, and the excluded view subtrees. Every such subtree, both included and excluded, is defined in this table. To determine if a particular object instance is in a particular MIB view, compare the object instance's OBJECT IDENTIFIER with each of the MIB view's active entries in this table. If none match, then the object instance is not in the MIB view. If one or more match, then the object instance is included in, or excluded from, the MIB view according to the value of dfViewType in the entry whose value of dfViewSubtree has the most sub-identifiers. If multiple entries match and have the same number of sub-identifiers, then the lexicographically greatest instance of dfViewType determines the inclusion or exclusion. An object instance's OBJECT IDENTIFIER X matches an active entry in this table when the number of sub-identifiers in X is at least as many as in the value of dfViewSubtree for the entry, and each sub-identifier in the value of dfViewSubtree matches its corresponding sub-identifier in X. Two sub identifiers match either if the corresponding bit of dfViewMask is zero (the 'wild card' value), or if they are equal. Due to this 'wild card' capability, we introduce the term, a 'family' of view subtrees, to refer to the set of subtrees defined by a particular combination of values of dfViewSubtree Harrington [Page 15] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 and dfViewMask. In the case where no 'wild card' is defined in dfViewMask, the family of view subtrees reduces to a single view subtree." ::= { datafilterViews 1 } dfViewEntry OBJECT-TYPE SYNTAX DfViewEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on a particular family of view subtrees included in or excluded from a particular SNMPv2 context's MIB view. Implementations must not restrict the number of families of view subtrees for a given MIB view, except as dictated by resource constraints on the overall number of entries in the dfViewTable." INDEX { dfViewIndex, IMPLIED dfViewSubtree } ::= { dfViewTable 1 } DfViewEntry ::= SEQUENCE { dfViewIndex INTEGER, dfViewSubtree OBJECT IDENTIFIER, dfViewMask OCTET STRING, dfViewType INTEGER, dfViewStorageType StorageType, dfViewStatus RowStatus } dfViewIndex OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary unique value for each MIB view. The value for each MIB view must remain constant at least from one re initialization of the entity's network management system to the next re-initialization. The value 0 is reserved for 'none'. The value 1 is reserved for 'all'. The specific value is meaningful only within a given SNMPv2 entity, i.e., it is not meaningful to any other SNMPv2 entity except to uniquely identify the view within the set of all views known to this agent." ::= { dfViewEntry 1 } Harrington [Page 16] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 dfViewSubtree OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "A MIB subtree." ::= { dfViewEntry 2 } dfViewMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "The bit mask which, in combination with the corresponding instance of dfViewSubtree, defines a family of view subtrees. Each bit of this bit mask corresponds to a sub-identifier of dfViewSubtree, with the most significant bit of the i-th octet of this octet string value (extended if necessary, see below) corresponding to the (8*i - 7)-th sub-identifier, and the least significant bit of the i-th octet of this octet string corresponding to the (8*i)-th sub-identifier, where i is in the range 1 through 16. Each bit of this bit mask specifies whether or not the corresponding sub-identifiers must match when determining if an OBJECT IDENTIFIER is in this family of view subtrees; a '1' indicates that an exact match must occur; a '0' indicates 'wild card', i.e., any sub-identifier value matches. Thus, the OBJECT IDENTIFIER X of an object instance is contained in a family of view subtrees if the following criteria are met: for each sub-identifier of the value of dfViewSubtree, either: the i-th bit of dfViewMask is 0, or the i-th sub-identifier of X is equal to the i-th sub-identifier of the value of dfViewSubtree. If the value of this bit mask is M bits long and there are more than M sub-identifiers in the corresponding instance of dfViewSubtree, then the bit mask is extended with 1's to be the required length. Harrington [Page 17] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 Note that when the value of this object is the zero-length string, this extension rule results in a mask of all-1's being used (i.e., no 'wild card'), and the family of view subtrees is the one view subtree uniquely identified by the corresponding instance of dfViewSubtree." DEFVAL { ''H } ::= { dfViewEntry 3 } dfViewType OBJECT-TYPE SYNTAX INTEGER { included(1), excluded(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The status of a particular family of view subtrees within the particular SNMPv2 context's MIB view. The value 'included(1)' indicates that the corresponding instances of dfViewSubtree and dfViewMask define a family of view subtrees included in the MIB view. The value 'excluded(2)' indicates that the corresponding instances of dfViewSubtree and dfViewMask define a family of view subtrees excluded from the MIB view." DEFVAL { included } ::= { dfViewEntry 4 } dfViewStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the dfViewTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { dfViewEntry 5 } dfViewStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row in the dfViewTable. For those columnar objects which permit write-access, their value in an existing conceptual row can be changed irrespective of the value of dfViewStatus for that row." ::= { dfViewEntry 6 } -- SNMPv2 data filter Harrington [Page 18] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 snmpDataFilter OBJECT IDENTIFIER ::= { datafilterMIBObjects 3 } datafilterTable OBJECT-TYPE SYNTAX SEQUENCE OF DatafilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SNMPv2 data filter database." ::= { snmpDataFilter 1 } datafilterEntry OBJECT-TYPE SYNTAX DatafilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally held information about a particular SNMPv2 data filter." INDEX { IMPLIED datafilterIdentity } ::= { datafilterTable 1 } DatafilterEntry ::= SEQUENCE { datafilterIdentity OBJECT IDENTIFIER, datafilterContext Context, datafilterReadViewIndex INTEGER, datafilterWriteViewIndex INTEGER, datafilterStorageType StorageType, datafilterStatus RowStatus } datafilterIdentity OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "A datafilter identifier uniquely identifying a particular SNMPv2 datafilter. This object is prohibited from taking the value { 0 x } for any value of x." ::= { datafilterEntry 1 } datafilterContext OBJECT-TYPE SYNTAX Context MAX-ACCESS read-create STATUS current DESCRIPTION "A context identifier uniquely identifying a particular SNMPv2 context." ::= { datafilterEntry 2 } Harrington [Page 19] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 datafilterReadViewIndex OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "If, for the SNMPv2 context identified by the corresponding instance of datafilterContext, the value of contextType is local(1), then the value of an instance of this object identifies the MIB view of the SNMPv2 context to which this conceptual row authorizes read access. The identified MIB view is that for which dfViewIndex has the same value as the instance of this object; if the value is zero or there are no active view subtrees for that value, then the identified MIB view is the empty set of view subtrees. If the value is 1, then the identified MIB view is 'all'. (Note that read access includes access via retrieval requests as well as transmission of information via notification requests.) If, for the SNMPv2 context identified by the corresponding instance of datafilterContext, the value of contextType is not local(1), , this object is ignored and can take any value at the agent's discretion, e.g., zero." DEFVAL { 0 } ::= { datafilterEntry 3 } datafilterWriteViewIndex OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "If, for the SNMPv2 context identified by the corresponding instance of datafilterContext, the value of contextType is local(1), then the value of an instance of this object identifies the MIB view of the SNMPv2 context to which this conceptual row authorizes write access. The identified MIB view is that for which dfViewIndex has the same value as the instance of this object; if the value is zero or there are no active view subtrees for that value, then the identified MIB view is the empty set of view subtrees. If the value is 1, then the identified MIB view is 'all'. If, for the SNMPv2 context identified by the corresponding instance of datafilterContext, the value of contextType is not local(1), , this object is ignored and can take any value at the agent's discretion, e.g., zero." DEFVAL { 0 } ::= { datafilterEntry 4 } Harrington [Page 20] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 datafilterStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the datafilterTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { datafilterEntry 5 } datafilterStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row in the datafilterTable. For those columnar objects which permit write-access, their value in an existing conceptual row can be changed irrespective of the value of datafilterStatus for that row. A conceptual row in this table is not qualified for activation until the context it references is active. A conceptual row in this table is immediately made notInService whenever the status of the context it references is made notInService. A conceptual row in this table is immediately destroyed whenever the context it references is destroyed." ::= { datafilterEntry 6 } -- conformance information datafilterMIBConformance OBJECT IDENTIFIER ::= { datafilterMIB 3 } datafilterMIBCompliances OBJECT IDENTIFIER ::= { datafilterMIBConformance 1 } datafilterMIBGroups OBJECT IDENTIFIER ::= { datafilterMIBConformance 2 } -- compliance statements datafilterCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement the datafilter MIB, but do not support any MIBviews other than empty(0) and all(1)" MODULE -- this module MANDATORY-GROUPS { datafilterMIBGroup } ::= { datafilterMIBCompliances 1 } Harrington [Page 21] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 fullViewCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement the datafilter MIB, including support for MIBviews other than empty(0) and all(1)" MODULE -- this module MANDATORY-GROUPS { datafilterMIBGroup, datafilterMIBviewGroup } ::= { datafilterMIBCompliances 2 } -- conformance groups datafilterMIBGroup OBJECT-GROUP OBJECTS { dfContextType, dfContextLocalEntity, dfContextLocalTime, dfContextStorageType, dfContextStatus, dfViewNextIndex, datafilterContext, datafilterReadViewIndex, datafilterWriteViewIndex, datafilterStorageType, datafilterStatus } STATUS current DESCRIPTION "The collection of objects allowing the description and configuration of SNMPv2 datafilters. Note that objects which support full views are not included in this conformance group." ::= { datafilterMIBGroups 1 } datafilterMIBviewGroup OBJECT-GROUP OBJECTS { dfViewMask, dfViewType, dfViewStorageType, dfViewStatus } STATUS current DESCRIPTION "The collection of objects needed for the support of views other than empty(0) and all(1)." ::= { datafilterMIBGroups 2 } END 5. Usage Examples 5.1 Minimal Local DataFilter Configuration This section presents an example configuration for a datafilter that uses only the default well-known views to allow read-access and no write-access to all objects in the deviceX_rptr1 context. Since custom views are not supported, dfViewNextIndex always returns zero. Harrington [Page 22] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 dfContextIdentity= dfContextType= local dfContextLocalEntity= dfContextLocalTime= currentTime dfViewNextIndex= 0 datafilterIdentity= datafilterContext= datafilterReadViewIndex datafilterWriteViewIndex 5.2 Customized Views This section presents an example configuration for a datafilter that uses custom views to allow read-access to all objects in the deviceX_rptr2 context, and limiting write-access to the subset defined by the rptr2_config_table_view family of views. Since the viewTable is supported, dfViewNextIndex shows the next available view index for use by managers creating a new view family. dfContextIdentity= dfContextType= local dfContextLocalEntity= dfContextLocalTime= currentTime dfViewNextIndex= <321> datafilterIdentity= datafilterContext= datafilterReadViewIndex datafilterWriteViewIndex 5.3. MIB View Configurations This section provides example configurations of MIB views illustrating both simple view subtrees, and more complicated uses of included and excluded families of view subtrees. A minimal SNMPv2 entity that only requires the ability to deny or allow access to a single MIB view containing all instances of all MIB objects defined within the SNMPv2 Network Management Framework need not implement a MIB view at all. The empty(0) and all(1) indexes provide that capability with no viewTable support. View Index Type Family Name Family Mask 5 included snmpV2 ''H Table 1: View Definition for Simple Agent Harrington [Page 23] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 Table 1 illustrates the definition of a MIB view required for a simple SNMPv2 entity that has a single MIB view containing all instances of all MIB objects defined within the SNMPv2 Network Management Subtree. The first column identifies the View Index by which this view is referenced by local access policies. Note that the value of View Index has only local significance. The type (included) signifies that any MIB object instance belonging to the view subtree family is contained within the MIB view. The family name is snmpV2, 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 2) is that of a SNMPv2 entity having multiple distinct MIB views. The MIB view associated with View Index 7 comprises all instances of all MIB objects defined within the SNMPv2 Network Management Framework, except those pertaining to the administration of SNMPv2 contexts. In contrast, the MIB view associated with View Index 8 contains only MIB object instances defined in the system group of the Internet-standard MIB together with those object instances by which SNMPv2 contexts are administered. View Index Type Family Name Family Mask 7 included internet ''H 7 excluded datafilterContexts ''H 8 included system ''H 8 included datafilterContexts ''H Table 2: Definition of Multiple Views A more complicated example of MIB view configuration illustrates the use of view subtree families (see Table 3). In this example, the MIB view associated with the View Index 42 includes all object instances in the system group of the Internet-standard MIB together with 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 View Index 42 because the lexicographically greater of the relevant family names appears in the table entry with type excluded. Harrington [Page 24] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 The MIB view for View Index 49 is also defined in this example, to include 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 for View Index 49 includes the number of octets received on the fourth attached network interface. View Index Type Family Name Family Mask 42 included system ''H 42 included { ifEntry 0 2 } 'FFA0'H 42 excluded { ifSpeed 2 } ''H 49 included icmp ''H 49 included { ifEntry 0 5 } 'FFA0'H 49 included { ifInOctets 4 } ''H Table 3: More Elaborate View Definitions While, as suggested by the examples above, a wide range of MIB view configurations are efficiently supported by the use of view subtree families, 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. Notwithstanding the above, instance level granularity is optional (see section 3.2). 6. Initial Configurations dfContextIdentity "" dfContextType local dfContextLocalEntity "" dfContextLocalTime currentTime dfViewNextIndex <0 | 2..2147483647> datafilterIdentity "" datafilterContext "" datafilterReadViewIndex datafilterWriteViewIndex A security or admin model may define an alternate initial configuration to satisfy security or other considerations. Harrington [Page 25] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 7. References [1] Information processing systems - Open Systems Interconnection Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, May 1995. [3] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, August 1995, draft-mahoney-SNMPv2-proto-03.txt. [4] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, | May 1995. 8. Security Considerations In order to participate in the administrative model set forth in this memo, SNMPv2 implementations must support local, non-volatile storage of the LDD. 9. Authors' Addresses Daniel O. Mahoney II Cabletron Systems, Inc. ATTN: Dan Mahoney Engineering - Durham P.O. Box 5005 Rochester NH 03866-5005 US Phone: +1 603 337 7355 Email: dmahoney@ctron.com Sandeep Asija Cabletron Systems, Inc. ATTN: Sandeep Asija Engineering - Durham P.O. Box 5005 Rochester NH 03866-5005 US Harrington [Page 26] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 Phone: +1 603 337 7185 Email: asija@ctron.com David Harrington Cabletron Systems, Inc. ATTN: David Harrington Engineering - Durham P.O. Box 5005 Rochester NH 03866-5005 US Phone: +1 603 337 7357 Email: dbh@ctron.com David Arneson Cabletron Systems, Inc. ATTN: David Arneson Engineering - Merrimack P.O. Box 5005 Rochester NH 03866-5005 US Phone: +1 603 337 5238 Email: arneson@ctron.com Harrington [Page 27] Internet Draft Data Filter MIB for SNMPv2 Aug 1995 Table of Contents 1 Introduction .................................................... 2 1.1 Acknowledgments .............................................. 2 1.2 A Note on Terminology ......................................... 3 2 Overview ........................................................ 3 2.1 Contexts ...................................................... 3 2.2 Authorization: Read/Write Access to Information ............... 4 2.3 Authorization: Limiting Access via MIB Views .................. 5 2.4 An SNMPv2 Entity's Local DataFilter Datastore ................. 5 2.5 Maintenance DataFilter ........................................ 6 3 Elements of the Model ........................................... 6 3.1 SNMPv2 Context ................................................ 7 3.2 View Subtree .................................................. 7 3.3 View Subtree Families ......................................... 8 3.4 MIB View ...................................................... 8 3.5 Data Filters .................................................. 9 4 Definitions ..................................................... 9 5 Usage Examples .................................................. 22 5.1 Minimal Local DataFilter Configuration ........................ 22 5.2 Customized Views .............................................. 23 5.3 MIB View Configurations ....................................... 23 6 Initial Configurations .......................................... 25 7 References ...................................................... 26 8 Security Considerations ......................................... 26 9 Authors' Addresses .............................................. 26 Expires January 1996 [Page 28]