SNMP-VIEW-BASED-ACM-MIB(7)

📦

version 25.3.2.8 · 3 versions

25.3.2.8 · debian bookworm, ubuntu jammy, ubuntu noble (latest)
29.1.1 · alpine 3.24, arch rolling, nixos 26.05, nixpkgs unstable, ubuntu stonking
26.2.5.21 · fedora 43, fedora 44

, in debian bookworm, ubuntu jammy, ubuntu noble

💖 `SNMP-VIEW-BASED-ACM-MIB(7)` 💖

Manual name folded in near the top, bestie: SNMP-VIEW-BASED-ACM-MIB(7), section MIB. This is part 1 of 4, so we are not done yet — do not touch that dial.

🎀 NAME 🎀

SNMP-VIEW-BASED-ACM-MIB — the Erlang/OTP MIB module for the view-based access control model for SNMP. That’s the whole errand: SNMP access control, but make it Erlang/OTP. Slay.

✨ DESCRIPTION ✨

Okay so this DESCRIPTION is literally the MIB module definition, and it is giving full source-code main-character energy. Here is the whole definition block, no cap, verbatim:

SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-COMPLIANCE, OBJECT-GROUP       FROM SNMPv2-CONF
    MODULE-IDENTITY, OBJECT-TYPE,
    snmpModules                           FROM SNMPv2-SMI
    TestAndIncr,
    RowStatus, StorageType                FROM SNMPv2-TC
    SnmpAdminString,
    SnmpSecurityLevel,
    SnmpSecurityModel                     FROM SNMP-FRAMEWORK-MIB;

snmpVacmMIB       MODULE-IDENTITY
    LAST-UPDATED "9901200000Z"            -- 20 Jan 1999, midnight
    ORGANIZATION "SNMPv3 Working Group"
    CONTACT-INFO "WG-email:   snmpv3@tis.com
                  Subscribe:  majordomo@tis.com
                              In message body:  subscribe snmpv3

                  Chair:      Russ Mundy
                              Trusted Information Systems
                  postal:     3060 Washington Rd
                              Glenwood MD 21738
                              USA
                  email:      mundy@tis.com
                  phone:      +1-301-854-6889

                  Co-editor:  Bert Wijnen
                              IBM T.J. Watson Research
                  postal:     Schagen 33
                              3461 GL Linschoten
                              Netherlands
                  email:      wijnen@vnet.ibm.com
                  phone:      +31-348-432-794

                  Co-editor:  Randy Presuhn
                              BMC Software, Inc
                  postal:     965 Stewart Drive
                              Sunnyvale, CA 94086
                              USA
                  email:      randy_presuhn@bmc.com
                  phone:      +1-408-616-3100

                  Co-editor:  Keith McCloghrie
                              Cisco Systems, Inc.
                  postal:     170 West Tasman Drive
                              San Jose, CA  95134-1706
                              USA
                  email:      kzm@cisco.com
                  phone:      +1-408-526-5260
                 "
    DESCRIPTION  "The management information definitions for the
                  View-based Access Control Model for SNMP.
                 "
--  Revision history
    REVISION     "9901200000Z"            -- 20 Jan 1999, midnight
                                          -- RFC-Editor assigns RFCxxxx
    DESCRIPTION  "Clarifications, published as RFCxxxx"

    REVISION     "9711200000Z"            -- 20 Nov 1997, midnight
    DESCRIPTION  "Initial version, published as RFC2275"

    ::= { snmpModules 16 }

-- Administrative assignments ****************************************

vacmMIBObjects      OBJECT IDENTIFIER ::= { snmpVacmMIB 1 }
vacmMIBConformance  OBJECT IDENTIFIER ::= { snmpVacmMIB 2 }

-- Information about Local Contexts **********************************

vacmContextTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF VacmContextEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "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.
                "
    ::= { vacmMIBObjects 1 }

vacmContextEntry OBJECT-TYPE
    SYNTAX       VacmContextEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "Information about a particular context."
    INDEX       {
                  vacmContextName
                }
    ::= { vacmContextTable 1 }

VacmContextEntry ::= SEQUENCE
    {
        vacmContextName SnmpAdminString
    }

vacmContextName  OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "A human readable name identifying a particular
                 context at a particular SNMP entity.

                 The empty contextName (zero length) represents the
                 default context.
                "
    ::= { vacmContextEntry 1 }

-- Information about Groups ******************************************

vacmSecurityToGroupTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF VacmSecurityToGroupEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "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.
                "
    ::= { vacmMIBObjects 2 }

vacmSecurityToGroupEntry OBJECT-TYPE
    SYNTAX       VacmSecurityToGroupEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "An entry in this table maps the combination of a
                 securityModel and securityName into a groupName.
                "
    INDEX       {
                  vacmSecurityModel,
                  vacmSecurityName
                }
    ::= { vacmSecurityToGroupTable 1 }

VacmSecurityToGroupEntry ::= SEQUENCE
    {
        vacmSecurityModel               SnmpSecurityModel,
        vacmSecurityName                SnmpAdminString,
        vacmGroupName                   SnmpAdminString,
        vacmSecurityToGroupStorageType  StorageType,
        vacmSecurityToGroupStatus       RowStatus
    }

vacmSecurityModel OBJECT-TYPE
    SYNTAX       SnmpSecurityModel(1..2147483647)
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The Security Model, by which the vacmSecurityName
                 referenced by this entry is provided.

                 Note, this object may not take the 'any' (0) value.
                "
    ::= { vacmSecurityToGroupEntry 1 }

vacmSecurityName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The securityName for the principal, represented in a
                 Security Model independent format, which is mapped by
                 this entry to a groupName.
                "
    ::= { vacmSecurityToGroupEntry 2 }

vacmGroupName    OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The name of the group to which this entry (e.g., the
                 combination of securityModel and securityName)
                 belongs.

                 This groupName is used as index into the
                 vacmAccessTable to select an access control policy.
                 However, a value in this table does not imply that an
                 instance with the value exists in table vacmAccesTable.
                "
    ::= { vacmSecurityToGroupEntry 3 }

vacmSecurityToGroupStorageType OBJECT-TYPE
    SYNTAX       StorageType
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The storage type for this conceptual row.
                 Conceptual rows having the value 'permanent' need not
                 allow write-access to any columnar objects in the row.
                "
    DEFVAL      { nonVolatile }
    ::= { vacmSecurityToGroupEntry 4 }

vacmSecurityToGroupStatus OBJECT-TYPE
    SYNTAX       RowStatus
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The status of this conceptual row.

                 Until instances of all corresponding columns are
                 appropriately configured, the value of the
                 corresponding instance of the vacmSecurityToGroupStatus
                 column is 'notReady'.

                 In particular, a newly created row cannot be made
                 active until a value has been set for vacmGroupName.

                 The  RowStatus TC [RFC1903] requires that this
                 DESCRIPTION clause states under which circumstances
                 other objects in this row can be modified:

                 The value of this object has no effect on whether
                 other objects in this conceptual row can be modified.
                "
    ::= { vacmSecurityToGroupEntry 5 }

-- Information about Access Rights ***********************************

vacmAccessTable  OBJECT-TYPE
    SYNTAX       SEQUENCE OF VacmAccessEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "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:

okay so picking which row actually wins is like the ✨main character selection arc✨ of the whole table, and honestly it's giving algorithm. Here's how the winner gets picked:

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
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

heads up bestie 🫶 please note that for securityLevel noAuthNoPriv, all groups are really equivalent since the assumption that the securityName has been authenticated does not hold.

::= { vacmMIBObjects 4 }

🎀 `vacmAccessEntry`

vacmAccessEntry  OBJECT-TYPE
    SYNTAX       VacmAccessEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    INDEX        { vacmGroupName,
                   vacmAccessContextPrefix,
                   vacmAccessSecurityModel,
                   vacmAccessSecurityLevel
                 }
    ::= { vacmAccessTable 1 }

So this is an access right configured in the Local Configuration Datastore (LCD) authorizing access to an SNMP context. 💅

And here's a fun lil detail: entries in this table can use an instance value for object vacmGroupName even if no entry in table vacmAccessSecurityToGroupTable has a corresponding value for object vacmGroupName. Like, it's allowed. No gatekeeping.

Also, the INDEX is these four, in this exact order, no cap:

vacmGroupName
vacmAccessContextPrefix
vacmAccessSecurityModel
vacmAccessSecurityLevel

And the row itself is this SEQUENCE 👇

VacmAccessEntry ::= SEQUENCE
    {
        vacmAccessContextPrefix    SnmpAdminString,
        vacmAccessSecurityModel    SnmpSecurityModel,
        vacmAccessSecurityLevel    SnmpSecurityLevel,
        vacmAccessContextMatch     INTEGER,
        vacmAccessReadViewName     SnmpAdminString,
        vacmAccessWriteViewName    SnmpAdminString,
        vacmAccessNotifyViewName   SnmpAdminString,
        vacmAccessStorageType      StorageType,
        vacmAccessStatus           RowStatus
    }

🦋 `vacmAccessContextPrefix`

vacmAccessContextPrefix OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    MAX-ACCESS   not-accessible
    STATUS       current
    ::= { vacmAccessEntry 1 }

So for a contextName to actually get the access rights this conceptual row is handing out, it's gotta match the value of the instance of this object — exactly if vacmAccessContextMatch is 'exact', or partially if vacmAccessContextMatch is 'prefix'. That's it, that's the vibe check 🔥

💜 `vacmAccessSecurityModel`

vacmAccessSecurityModel OBJECT-TYPE
    SYNTAX       SnmpSecurityModel
    MAX-ACCESS   not-accessible
    STATUS       current
    ::= { vacmAccessEntry 2 }

To get the access rights from this conceptual row, this securityModel must be in use. Non-negotiable bestie.

⭐ `vacmAccessSecurityLevel`

vacmAccessSecurityLevel OBJECT-TYPE
    SYNTAX       SnmpSecurityLevel
    MAX-ACCESS   not-accessible
    STATUS       current
    ::= { vacmAccessEntry 3 }

This one is the minimum level of security required in order to gain the access rights allowed by this conceptual row. And it's a whole hierarchy, iykyk:

noAuthNoPriv is less than authNoPriv which in turn is less than authPriv. Slay, ordered.

And the tiebreak tea ☕: if multiple entries are equally indexed except for this vacmAccessSecurityLevel index, then the entry which has the highest value for vacmAccessSecurityLevel is selected. Highest wins, periodt.

🌈 `vacmAccessContextMatch`

vacmAccessContextMatch OBJECT-TYPE
    SYNTAX       INTEGER
                 { exact (1), -- exact match of prefix and contextName
                   prefix (2) -- Only match to the prefix
                 }
    MAX-ACCESS   read-create
    STATUS       current
    DEFVAL       { exact }
    ::= { vacmAccessEntry 4 }

Okay so this is the wildcard switch and it's lowkey iconic ✨

if it's exact(1) — then all rows where the contextName exactly matches vacmAccessContextPrefix are selected. No wiggle room.
if it's prefix(2) — then all rows where the contextName whose starting octets exactly match vacmAccessContextPrefix are selected. Which, and I quote, allows for a simple form of wildcarding 🎀

Default value is exact — DEFVAL { exact }. So strict by default, as she should be 💅

🍓 `vacmAccessReadViewName`

vacmAccessReadViewName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    MAX-ACCESS   read-create
    STATUS       current
    DEFVAL       { ''H }   -- the empty string
    ::= { vacmAccessEntry 5 }

The value of an instance of this object identifies the MIB view of the SNMP context to which this conceptual row authorizes read access. 👑

So the identified MIB view is the one where vacmViewTreeFamilyViewName has the same value as the instance of this object. But — and this matters 😭 — if the value is the empty string, or if there is no active MIB view having this value of vacmViewTreeFamilyViewName, then no access is granted.

Default: DEFVAL { ''H } — the empty string. Which, per the above, means no access. Yes really 💀

🧚 `vacmAccessWriteViewName`

vacmAccessWriteViewName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    MAX-ACCESS   read-create
    STATUS       current
    DEFVAL       { ''H }   -- the empty string
    ::= { vacmAccessEntry 6 }

Same energy as the read one but for ✍️ writes: the value of an instance of this object identifies the MIB view of the SNMP context to which this conceptual row authorizes write access.

Again, the identified MIB view is the one where vacmViewTreeFamilyViewName has the same value as the instance of this object — and if the value is the empty string or if there is no active MIB view having this value of vacmViewTreeFamilyViewName, then no access is granted. Same rule, same consequences, no exceptions bestie.

Default: DEFVAL { ''H } — the empty string.

🔔 `vacmAccessNotifyViewName`

vacmAccessNotifyViewName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    MAX-ACCESS   read-create
    STATUS       current
    DEFVAL       { ''H }   -- the empty string
    ::= { vacmAccessEntry 7 }

Third one, notification flavor 🦋 the value of an instance of this object identifies the MIB view of the SNMP context to which this conceptual row authorizes access for notifications.

You already know the drill by now: identified MIB view = the one where vacmViewTreeFamilyViewName has the same value as the instance of this object. And if the value is the empty string or if there is no active MIB view having this value of vacmViewTreeFamilyViewName, then no access is granted. 😭

Default: DEFVAL { ''H } — the empty string.

🎀 `vacmAccessStorageType`

vacmAccessStorageType OBJECT-TYPE
    SYNTAX       StorageType
    MAX-ACCESS   read-create
    STATUS       current
    DEFVAL       { nonVolatile }
    ::= { vacmAccessEntry 8 }

It's the storage type for this conceptual row. Short and sweet ✨

Important caveat though: conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. So don't come for her if writes get refused on a permanent row, fr fr.

Default: DEFVAL { nonVolatile }.

💅 `vacmAccessStatus`

vacmAccessStatus OBJECT-TYPE
    SYNTAX       RowStatus
    MAX-ACCESS   read-create
    STATUS       current
    ::= { vacmAccessEntry 9 }

This is the status of this conceptual row. Standard stuff.

Now, the RowStatus TC [RFC1903] requires that this DESCRIPTION clause states under which circumstances other objects in this row can be modified — so here's the answer, and it's honestly so chill:

The value of this object has no effect on whether other objects in this conceptual row can be modified.

Yeah. None. Go off 👑

-- Information about MIB views ***************************************

-- Support for instance-level granularity is optional.
--
-- In some implementations, instance-level access control
-- granularity may come at a high performance cost.  Managers
-- should avoid requesting such configurations unnecessarily.

read this one bestie 🫶 support for instance-level granularity is optional. And in some implementations, instance-level access control granularity may come at a high performance cost — so managers should avoid requesting such configurations unnecessarily. Be considerate, she's doing her best 😭

vacmMIBViews OBJECT IDENTIFIER ::= { vacmMIBObjects 5 }

🌸 `vacmViewSpinLock`

vacmViewSpinLock OBJECT-TYPE
    SYNTAX       TestAndIncr
    MAX-ACCESS   read-write
    STATUS       current
    ::= { vacmMIBObjects 7 }

Wait — no, keep it exactly as given: the OID line for this one is ::= { vacmMIBObjects 7 } only if the source said so, so let's not invent. Here's the actual declaration:

vacmViewSpinLock OBJECT-TYPE
    SYNTAX       TestAndIncr
    MAX-ACCESS   read-write
    STATUS       current

And the description begins: an advisory lock used to allow cooperating SNMP Command Generator applications to coordinate their use of the Set operation in creating or modifying views. 🌈

(and that's where we're picking it up in the next part, bestie — the tea continues ✨)

Okay so bestie, when you're creating a new view or altering an existing one, you have to understand the potential interactions with other uses of the view. First, retrieve vacmViewSpinLock. Then your SNMP Command Generator application needs to figure out that the name of the view you want to create is unique — by consulting vacmViewTreeFamilyTable. Finally, you can create (Set) the named view, including the advisory lock. 💅

If another SNMP Command Generator application has altered the views in the meantime, then the spin lock's value will have changed, so this creation will fail — because it will specify the wrong value for the spin lock. 😭

Since this is an advisory lock, the use of this lock is not enforced. It's giving "suggestion, not security guard." 🫶

::= { vacmMIBViews 1 }

🦋 `vacmViewTreeFamilyTable` OBJECT-TYPE 🦋

SYNTAX       SEQUENCE OF VacmViewTreeFamilyEntry
MAX-ACCESS   not-accessible
STATUS       current

This table is the 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. No cap. 🔥

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 the 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. Like, order matters, bestie. 🧚

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. No exceptions.

::= { vacmMIBViews 2 }

🌸 `vacmViewTreeFamilyEntry` OBJECT-TYPE 🌸

SYNTAX       VacmViewTreeFamilyEntry
MAX-ACCESS   not-accessible
STATUS       current

This is information on a particular family of view subtrees included in or excluded from a particular SNMP 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 vacmViewTreeFamilyTable.

If no conceptual rows exist in this table for a given MIB view (viewName), that view may be thought of as consisting of the empty set of view subtrees. Empty set energy, but make it MIB. 💀

INDEX       { vacmViewTreeFamilyViewName,
              vacmViewTreeFamilySubtree
            }
::= { vacmViewTreeFamilyTable 1 }

💖 `VacmViewTreeFamilyEntry ::= SEQUENCE` 💖

VacmViewTreeFamilyEntry ::= SEQUENCE
    {
        vacmViewTreeFamilyViewName     SnmpAdminString,
        vacmViewTreeFamilySubtree      OBJECT IDENTIFIER,
        vacmViewTreeFamilyMask         OCTET STRING,
        vacmViewTreeFamilyType         INTEGER,
        vacmViewTreeFamilyStorageType  StorageType,
        vacmViewTreeFamilyStatus       RowStatus
    }

🎀 `vacmViewTreeFamilyViewName` OBJECT-TYPE 🎀

SYNTAX       SnmpAdminString (SIZE(1..32))
MAX-ACCESS   not-accessible
STATUS       current

The human readable name for a family of view subtrees. Literally what it says on the label.

::= { vacmViewTreeFamilyEntry 1 }

⭐ `vacmViewTreeFamilySubtree` OBJECT-TYPE ⭐

SYNTAX       OBJECT IDENTIFIER
MAX-ACCESS   not-accessible
STATUS       current

The MIB subtree which, when combined with the corresponding instance of vacmViewTreeFamilyMask, defines a family of view subtrees.

::= { vacmViewTreeFamilyEntry 2 }

🌈 `vacmViewTreeFamilyMask` OBJECT-TYPE 🌈

SYNTAX       OCTET STRING (SIZE (0..16))
MAX-ACCESS   read-create
STATUS       current

This is the bit mask which, in combination with the corresponding instance of vacmViewTreeFamilySubtree, defines a family of view subtrees.

Each bit of this bit mask corresponds to a sub-identifier of vacmViewTreeFamilySubtree, 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, for each sub-identifier of the value of vacmViewTreeFamilySubtree, either:

the i-th bit of vacmViewTreeFamilyMask is 0, or
the i-th sub-identifier of X is equal to the i-th sub-identifier of the value of vacmViewTreeFamilySubtree.

If the value of this bit mask is M bits long and there are more than M sub-identifiers in the corresponding instance of vacmViewTreeFamilySubtree, then the bit mask is extended with 1's to be the required length.

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 vacmViewTreeFamilySubtree.

Note that masks of length greater than zero length do not need to be supported. In this case this object is made read-only.

DEFVAL      { ''H }
::= { vacmViewTreeFamilyEntry 3 }

👑 `vacmViewTreeFamilyType` OBJECT-TYPE 👑

SYNTAX       INTEGER  { included(1), excluded(2) }
MAX-ACCESS   read-create
STATUS       current

Indicates whether the corresponding instances of vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask define a family of view subtrees which is included in or excluded from the MIB view.

DEFVAL      { included }
::= { vacmViewTreeFamilyEntry 4 }

🍓 `vacmViewTreeFamilyStorageType` OBJECT-TYPE 🍓

SYNTAX       StorageType
MAX-ACCESS   read-create
STATUS       current

The storage type for this conceptual row.

Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row.

DEFVAL      { nonVolatile }
::= { vacmViewTreeFamilyEntry 5 }

💜 `vacmViewTreeFamilyStatus` OBJECT-TYPE 💜

SYNTAX       RowStatus
MAX-ACCESS   read-create
STATUS       current

The status of this conceptual row.

The RowStatus TC [RFC1903] requires that this DESCRIPTION clause states under which circumstances other objects in this row can be modified:

...and the very last line of that whole DESCRIPTION clause — the one closing out vacmViewTreeFamilyStatus — is honestly a mood all by itself, bestie:

"The value of this object has no effect on whether other objects in this conceptual row can be modified."

Which is MIB-speak for "girl, this column minds its own business, it's not the row's bodyguard." And then, of course, the row wraps up with its sixth and final column:

           ::= { vacmViewTreeFamilyEntry 6 }

That's 6 bestie, the last index in the entry. Row complete. Table complete. We ate. 💅

🎀 Conformance information 🎀

Okay so now we're out of the tables and into the conformance zone, which is where the MIB declares "these are the rules, these are the objects, this is the whole assignment." Two little OID assignments kick it off:

       vacmMIBCompliances  OBJECT IDENTIFIER ::= { vacmMIBConformance 1 }
       vacmMIBGroups       OBJECT IDENTIFIER ::= { vacmMIBConformance 2 }

So vacmMIBCompliances gets branch 1 and vacmMIBGroups gets branch 2. Cute, tidy, sorted. ✨

📋 Compliance statements 📋

`vacmMIBCompliance`

This is a MODULE-COMPLIANCE object, and its STATUS is current — as in, it's live, it's real, it's the standard, no cap.

Its DESCRIPTION says this is the compliance statement for SNMP engines which implement the SNMP View-based Access Control Model configuration MIB. That's the whole flex: if your engine implements this MIB, this is the compliance statement it lives by.

It applies to MODULE -- this module (yep, this very one), and there's exactly one mandatory group to satisfy:

               MANDATORY-GROUPS { vacmBasicGroup }

🚨 Mandatory means mandatory, bestie. vacmBasicGroup is not a suggestion, not a nice-to-have, it's the price of admission.

Then comes the run of OBJECT clauses — each one relaxing or clarifying what an implementation actually needs to support. Here they all are, in order, with nothing skipped:

vacmAccessContextMatch — MIN-ACCESS read-only. DESCRIPTION: "Write access is not required." So read is enough, that's the floor. 🫶
vacmAccessReadViewName — MIN-ACCESS read-only. Again: write access not required.
vacmAccessWriteViewName — MIN-ACCESS read-only. Same energy, "Write access is not required."
vacmAccessNotifyViewName — MIN-ACCESS read-only. Yes bestie, also just read.
vacmAccessStorageType — MIN-ACCESS read-only. Read it and weep (you don't have to write it).
vacmAccessStatus — MIN-ACCESS read-only. This one's DESCRIPTION is a touch different: create/delete/modify access to the vacmAccessTable is not required. So you're off the hook for the whole create/delete/modify situation on that table. 🙈
vacmViewTreeFamilyMask — MIN-ACCESS read-only, and here's the spicy one: it also comes with a WRITE-SYNTAX of OCTET STRING (SIZE (0)). Its DESCRIPTION: support for configuration via SNMP of subtree families using wild-cards is not required. Translation? Wild-card config over SNMP is optional, queen. If you don't do wildcards, you're still compliant. 🦋
vacmViewTreeFamilyType — MIN-ACCESS read-only. "Write access is not required." (the classic).
vacmViewTreeFamilyStorageType — MIN-ACCESS read-only. Also the classic. Write access? Not required.
vacmViewTreeFamilyStatus — MIN-ACCESS read-only. Its DESCRIPTION mirrors the access-table one: create/delete/modify access to the vacmViewTreeFamilyTable is not required.

And then the compliance object closes out with:

           ::= { vacmMIBCompliances 1 }

Branch 1 of vacmMIBCompliances, locked in. 🔒

👑 Units of conformance 👑

`vacmBasicGroup`

The one group to rule them all — an OBJECT-GROUP with STATUS current. Its OBJECTS clause lists fifteen objects, and we're listing every single one because we don't do "etc." here:

                     vacmContextName,
                     vacmGroupName,
                     vacmSecurityToGroupStorageType,
                     vacmSecurityToGroupStatus,
                     vacmAccessContextMatch,
                     vacmAccessReadViewName,
                     vacmAccessWriteViewName,
                     vacmAccessNotifyViewName,
                     vacmAccessStorageType,
                     vacmAccessStatus,
                     vacmViewSpinLock,
                     vacmViewTreeFamilyMask,
                     vacmViewTreeFamilyType,
                     vacmViewTreeFamilyStorageType,
                     vacmViewTreeFamilyStatus

Count 'em — vaccmContextName and friends, all fifteen, exactly as written. Don't let anyone tell you otherwise. 💀

Its DESCRIPTION is the summary of the whole assignment:

"A collection of objects providing for remote configuration of an SNMP engine which implements the SNMP View-based Access Control Model."

Remote configuration of an SNMP engine that implements VACM — that's the group, that's the vibe, that's the whole point. ✨

And finally:

           ::= { vacmMIBGroups 1 }

Branch 1 of vacmMIBGroups. Then the module signs off the way every MIB must:

END

END. periodt. 🎀

And that's the whole page, bestie! 🫶 This one came from Erlang/OTP — the SNMP section, manpage section 7, filed under SNMP-VIEW-BASED-ACM-MIB(7). Go forth and configure your views, your groups, and your access entries responsibly. 💜🌈⭐

📦 where this page comes from

debian bookworm: erlang-manpages 1:25.2.3+dfsg-1+deb12u1 · Apache-2.0
debian bookworm: erlang-manpages 1:25.2.3+dfsg-1+deb12u4 · Apache-2.0
ubuntu jammy: erlang-manpages 1:24.2.1+dfsg-1 · Apache-2.0
ubuntu jammy: erlang-manpages 1:24.2.1+dfsg-1ubuntu0.8 · Apache-2.0
ubuntu noble: erlang-manpages 1:25.3.2.8+dfsg-1ubuntu4 · Apache-2.0
ubuntu noble: erlang-manpages 1:25.3.2.8+dfsg-1ubuntu4.8 · Apache-2.0
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on 2026-11-06: a language model's rewrite of the original, under its terms

SNMP-VIEW-BASED-ACM-MIB(7)

💖 SNMP-VIEW-BASED-ACM-MIB(7) 💖

🎀 NAME 🎀

✨ DESCRIPTION ✨

🎀 vacmAccessEntry

🦋 vacmAccessContextPrefix

💜 vacmAccessSecurityModel

⭐ vacmAccessSecurityLevel

🌈 vacmAccessContextMatch

🍓 vacmAccessReadViewName

🧚 vacmAccessWriteViewName

🔔 vacmAccessNotifyViewName

🎀 vacmAccessStorageType

💅 vacmAccessStatus

🌸 vacmViewSpinLock

🦋 vacmViewTreeFamilyTable OBJECT-TYPE 🦋

🌸 vacmViewTreeFamilyEntry OBJECT-TYPE 🌸

💖 VacmViewTreeFamilyEntry ::= SEQUENCE 💖

🎀 vacmViewTreeFamilyViewName OBJECT-TYPE 🎀

⭐ vacmViewTreeFamilySubtree OBJECT-TYPE ⭐

🌈 vacmViewTreeFamilyMask OBJECT-TYPE 🌈

👑 vacmViewTreeFamilyType OBJECT-TYPE 👑

🍓 vacmViewTreeFamilyStorageType OBJECT-TYPE 🍓

💜 vacmViewTreeFamilyStatus OBJECT-TYPE 💜