Internet DRAFT - draft-ietf-snmpv2-data-filter-mib
draft-ietf-snmpv2-data-filter-mib
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 08:19:03 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 08 Aug 1995 22:00:00 GMT
ETag: "323a94-f0d2-3027de60"
Accept-Ranges: bytes
Content-Length: 61650
Connection: close
Content-Type: text/plain
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= <deviceX_rptr1>
dfContextType= local
dfContextLocalEntity= <repeater1>
dfContextLocalTime= currentTime
dfViewNextIndex= 0
datafilterIdentity= <deviceX_rptr1_readOnly>
datafilterContext= <deviceX_rptr1>
datafilterReadViewIndex <all>
datafilterWriteViewIndex <empty>
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= <deviceX_rptr2>
dfContextType= local
dfContextLocalEntity= <repeater2>
dfContextLocalTime= currentTime
dfViewNextIndex= <321>
datafilterIdentity= <deviceX_rptr2_config_and_monitor>
datafilterContext= <deviceX_rptr2>
datafilterReadViewIndex <all>
datafilterWriteViewIndex <rptr2_config_table_view>
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 <all>
datafilterWriteViewIndex <empty>
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]
