SNMP-VIEW-BASED-ACM-MIB Table View

The table of locally available contexts.
          
This table provides information to SNMP Command
          
Generator applications so that they can properly
configure the vacmAccessTable to control access to
all contexts at the SNMP entity.
          
This table may change dynamically if the SNMP entity
allows that contexts are added/deleted dynamically
(for instance when its configuration changes).  Such
changes would happen only if the management
instrumentation at that SNMP entity recognizes more
(or fewer) contexts.
          
The presence of entries in this table and of entries
in the vacmAccessTable are independent.  That is, a
context identified by an entry in this table is not
necessarily referenced by any entries in the
vacmAccessTable; and the context(s) referenced by an
entry in the vacmAccessTable does not necessarily
currently exist and thus need not be identified by an
entry in this table.
          
This table must be made accessible via the default
context so that Command Responder applications have
a standard way of retrieving the information.
          
This table is read-only.  It cannot be configured via
SNMP.

This table maps a combination of securityModel and
securityName into a groupName which is used to define
an access control policy for a group of principals.

The table of access rights for groups.
          
Each entry is indexed by a groupName, a contextPrefix,
a securityModel and a securityLevel.  To determine
whether access is allowed, one entry from this table
needs to be selected and the proper viewName from that
entry must be used for access control checking.
          
To select the proper entry, follow these steps:
          
1) the set of possible matches is formed by the
   intersection of the following sets of entries:
          
     the set of entries with identical vacmGroupName
     the union of these two sets:
      - the set with identical vacmAccessContextPrefix
      - the set of entries with vacmAccessContextMatch
        value of 'prefix' and matching
        vacmAccessContextPrefix
     intersected with the union of these two sets:
      - the set of entries with identical
        vacmSecurityModel
      - the set of entries with vacmSecurityModel
        value of 'any'
     intersected with the set of entries with
     vacmAccessSecurityLevel value less than or equal
     to the requested securityLevel
          
2) if this set has only one member, we're done
   otherwise, it comes down to deciding how to weight
   the preferences between ContextPrefixes,
   SecurityModels, and SecurityLevels as follows:
   a) if the subset of entries with securityModel
      matching the securityModel in the message is
      not empty, then discard the rest.
   b) if the subset of entries with
      vacmAccessContextPrefix matching the contextName
      in the message is not empty,
      then discard the rest
   c) discard all entries with ContextPrefixes shorter
      than the longest one remaining in the set
   d) select the entry with the highest securityLevel
          
Please note that for securityLevel noAuthNoPriv, all
groups are really equivalent since the assumption that
the securityName has been authenticated does not hold.

Locally held information about families of subtrees
within MIB views.
          
Each MIB view is defined by two sets of view subtrees:
  - the included view subtrees, and
  - the excluded view subtrees.
Every such view subtree, both the included and the
          
excluded ones, 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 vacmViewTreeFamilyType in the entry whose
value of vacmViewTreeFamilySubtree has the most
sub-identifiers.  If multiple entries match and have
the same number of sub-identifiers (when wildcarding
is specified with the value of vacmViewTreeFamilyMask),
then the lexicographically greatest instance of
vacmViewTreeFamilyType 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 vacmViewTreeFamilySubtree for the entry,
and each sub-identifier in the value of
vacmViewTreeFamilySubtree matches its corresponding
sub-identifier in X.  Two sub-identifiers match
either if the corresponding bit of the value of
vacmViewTreeFamilyMask for the entry is zero (the
'wild card' value), or if they are equal.
          
A 'family' of subtrees is the set of subtrees defined
by a particular combination of values of
vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask.
          
In the case where no 'wild card' is defined in the
vacmViewTreeFamilyMask, the family of subtrees reduces
to a single subtree.
          
When creating or changing MIB views, an SNMP Command
Generator application should utilize the
vacmViewSpinLock to try to avoid collisions.  See
DESCRIPTION clause of vacmViewSpinLock.
          
When creating MIB views, it is strongly advised that
first the 'excluded' vacmViewTreeFamilyEntries are
created and then the 'included' entries.
          
When deleting MIB views, it is strongly advised that
first the 'included' vacmViewTreeFamilyEntries are
          
deleted and then the 'excluded' entries.
          
If a create for an entry for instance-level access
control is received and the implementation does not
support instance-level granularity, then an
inconsistentName error must be returned.