RFC 3415
View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) 🦋
Okay bestie, this is RFC 3415 💖 It's a Standards Track doc from the Network Working Group, filed under STD 62 ✨ It came out in December 2002, written by B. Wijnen (Lucent Technologies), R. Presuhn (BMC Software, Inc.), and K. McCloghrie (Cisco Systems, Inc.) 👑 It also obsoletes RFC 2575 🙈 so this is the glow-up of the older version.
Status of This Memo ✨
This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🌸 For the standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💅
Copyright Notice 🎀
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract 🌈
So this doc describes the View-based Access Control Model (VACM) for use in the Simple Network Management Protocol (SNMP) architecture 🦋 It defines the Elements of Procedure for controlling access to management information. It also includes a Management Information Base (MIB) for remotely managing the configuration parameters for the View-based Access Control Model 🧚 And yep, it obsoletes RFC 2575 💀
Table of Contents 📖
1. Introduction ................................................. 2
1.2. Access Control ............................................. 3
1.3. Local Configuration Datastore .............................. 3
2. Elements of the Model ........................................ 4
2.1. Groups ..................................................... 4
2.2. securityLevel .............................................. 4
2.3. Contexts ................................................... 4
2.4. MIB Views and View Families ................................ 5
2.4.1. View Subtree ............................................. 5
2.4.2. ViewTreeFamily ........................................... 6
2.5. Access Policy .............................................. 6
3. Elements of Procedure ........................................ 7
3.1. Overview of isAccessAllowed Process ....................... 8
3.2. Processing the isAccessAllowed Service Request ............. 9
4. Definitions .................................................. 11
5. Intellectual Property ........................................ 28
6. Acknowledgements ............................................. 28
7. Security Considerations ...................................... 30
7.1. Recommended Practices ...................................... 30
7.2. Defining Groups ............................................ 30
7.3. Conformance ................................................ 31
7.4. Access to the SNMP-VIEW-BASED-ACM-MIB ...................... 31
8. References ................................................... 31
A. Installation ................................................. 33
B. Change Log ................................................... 36
Editors' Addresses ............................................... 38
Full Copyright Statement ......................................... 391. Introduction ✨
Okay so the Architecture for describing Internet Management Frameworks [RFC3411] explains that an SNMP engine is made up of these four bits 🧚
1) a Dispatcher
2) a Message Processing Subsystem,
3) a Security Subsystem, and
4) an Access Control Subsystem.Applications use the services of these subsystems 💅
It's super important to get the SNMP architecture and its terminology down, so you can see where the View-based Access Control Model fits in and how it works with the other subsystems 🫶 The reader is expected to have read and understood the description and terminology of the SNMP architecture, as defined in [RFC3411] 📚
The Access Control Subsystem of an SNMP engine is in charge of checking whether a specific type of access (read, write, notify) to a particular object (instance) is allowed 🔥
So this doc defines one specific model of the Access Control Subsystem, called the View-based Access Control Model. It's not necessarily the only Access Control Model out there 🌸
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 💜
1.2. Access Control 🔐
Access Control happens (either implicitly or explicitly) in an SNMP entity whenever it processes SNMP retrieval or modification request messages from an SNMP entity 👑 For example, a Command Responder application applies Access Control when it processes requests it received from a Command Generator application. These requests contain Read Class and Write Class PDUs as defined in [RFC3411] ✨
Access Control also happens in an SNMP entity when an SNMP notification message gets generated (by a Notification Originator application). These notification messages contain Notification Class PDUs as defined in [RFC3411] 🎀
The View-based Access Control Model defines a set of services that an application (such as a Command Responder or a Notification Originator application) can use to check access rights. The application is the one responsible for making the right service calls for access checking 🫶
1.3. Local Configuration Datastore 🗂️
To implement the model in this document, an SNMP entity needs to keep information about access rights and policies 🦋 This information is part of the SNMP engine's Local Configuration Datastore (LCD). See [RFC3411] for the definition of LCD 📖
So an SNMP entity's LCD can be configured remotely, portions of the LCD need to be accessible as managed objects. This doc includes a MIB module, the View-based Access Control Model Configuration MIB, which defines these managed object types 🌈
2. Elements of the Model 💖
This section has the definitions that make the access control service of the View-based Access Control Model work 🧚
2.1. Groups 👯
A group is a set of zero or more <securityModel, securityName> tuples on whose behalf SNMP management objects can be accessed. A group defines the access rights given to all securityNames that belong to that group. The combination of a securityModel and a securityName maps to at most one group. A group is identified by a groupName ✨
The Access Control module assumes that the securityName has already been authenticated as needed, and it doesn't do any further authentication of its own 🔐
The View-based Access Control Model uses the securityModel and the securityName as inputs to the Access Control module when it's called to check for access rights. It works out the groupName from securityModel and securityName 💅
2.2. securityLevel 🛡️
Members of a group can have different access rights for different levels of security, i.e., noAuthNoPriv, authNoPriv, and authPriv 🌸 The securityLevel tells you which level of security will be assumed when checking for access rights. For a definition of securityLevel, see the SNMP Architecture document [RFC3411] 📚
The View-based Access Control Model requires that the securityLevel is passed as input to the Access Control module when it's called to check for access rights 🔥
2.3. Contexts 🗺️
An SNMP context is a collection of management information that an SNMP entity can access. An item of management information may exist in more than one context, and an SNMP entity may have access to many contexts 🦋 For details on how management information is named, check the SNMP Architecture document [RFC3411] 🫶
The View-based Access Control Model defines a vacmContextTable that lists the locally available contexts by contextName 📋
2.4. MIB Views and View Families 🪟
For security reasons, it's often valuable to restrict the access rights of some groups to only a subset of the management information in the management domain 🔒 To make that possible, access to a context goes through a "MIB view", which details a specific set of managed object types (and optionally, the specific instances of object types) within that context ✨ For example, for a given context there will typically be one MIB view that gives access to all management information in that context, and often there'll be other MIB views that each contain some subset of the information. So the access a group gets can be limited in the way you want, by specifying its rights in terms of the particular (subset) MIB view it can access within each appropriate context 💜
Managed object types (and their instances) are identified through the tree-like naming structure of ISO's OBJECT IDENTIFIERs [ISO-ASN.1, RFC2578], so it makes sense to define a MIB view as the combination of a set of "view subtrees", where each view subtree is a subtree within the managed object naming tree 🌳 A simple MIB view (e.g., all managed objects within the Internet Network Management Framework) can be a single view subtree, while more complicated MIB views (e.g., all information relevant to a particular network interface) can be the union of multiple view subtrees 🧚
Any set of managed objects can be described by the union of some number of view subtrees, but situations can come up that would need a really large number of them 😭 This could happen, for example, when you specify all columns in one conceptual row of a MIB table, because they would show up in separate subtrees, one per column, each with a very similar format. Since the formats are similar, the required set of subtrees can easily be grouped into one structure. This structure is named a family of view subtrees after the set of subtrees it conceptually represents. A family of view subtrees can either be included in or excluded from a MIB view 👑
2.4.1. View Subtree 🌿
A view subtree is the set of all MIB object instances that share a common ASN.1 OBJECT IDENTIFIER prefix in their names 💖 A view subtree is identified by the OBJECT IDENTIFIER value that's the longest OBJECT IDENTIFIER prefix common to all (potential) MIB object instances in that subtree 🦋
2.4.2. ViewTreeFamily ✨
okay so a family of view subtrees is basically a pair 💜 It's an OBJECT IDENTIFIER value (that's the family name) plus a bit string (that's the family mask). The mask tells you which sub-identifiers of the family name actually matter for defining the family. Bestie, the mask is doing the heavy lifting here 💅
So when is a managed object instance part of a ViewTreeFamily? Both of these have to be true, no exceptions 🫶
- the OBJECT IDENTIFIER name of the instance has at least as many sub-identifiers as the family name does, and
- each sub-identifier in the instance's OBJECT IDENTIFIER name matches the matching sub-identifier of the family name wherever the matching bit in the family mask is non-zero 🔥
If the family mask is all ones, the family is literally the same thing as the single view subtree named by the family name. Iconic, no notes 🦋
Now the shorter-mask situation 🙈 If the configured family mask is too short for that test, it gets implicitly extended with ones. So a family with a zero-length mask always works out to one single view subtree ✨
2.5. Access Policy
okay now we're talking about what a group is actually allowed to do 👑 The View-based Access Control Model decides the access rights of a group, and a group is just zero or more securityNames that all share the same access rights. For a given context (that's the contextName), a group (groupName) gets access using a particular securityModel and securityLevel, and its rights come from three views: a read-view, a write-view, and a notify-view 🌸
- The read-view is the set of object instances the group is allowed to touch when reading. Reading happens when a retrieval operation is being processed (so when handling Read Class PDUs) 📖
- The write-view is the set of object instances the group is allowed to write to. Writing happens when a write operation is being processed (so when handling Write Class PDUs) ✍️
- The notify-view is the set of object instances the group is allowed to send in a notification, like when sending a notification (so when sending Notification Class PDUs) 🔔
3. Elements of Procedure
this section is the step-by-step of how an Access Control module that uses the View-based Access Control Model checks access when an application asks for it 🎀 Those apps could be a Command Responder or a Notification Originator, for example. The abstract service primitive looks like this:
statusInformation = -- success or errorIndication
isAccessAllowed(
securityModel -- Security Model in use
securityName -- principal who wants access
securityLevel -- Level of Security
viewType -- read, write, or notify view
contextName -- context containing variableName
variableName -- OID for the managed object
)Here are the abstract data elements, and yes, the statusInformation ones are the important drama 💀
statusInformation - one of the following:
accessAllowed - a MIB view was found and access is granted.
notInView - a MIB view was found but access is denied.
The variableName is not in the configured
MIB view for the specified viewType (e.g., in
the relevant entry in the vacmAccessTable).
noSuchView - no MIB view found because no view has been
configured for specified viewType (e.g., in
the relevant entry in the vacmAccessTable).
noSuchContext - no MIB view found because of no entry in the
vacmContextTable for specified contextName.
noGroupName - no MIB view found because no entry has been
configured in the vacmSecurityToGroupTable
for the specified combination of
securityModel and securityName.
noAccessEntry - no MIB view found because no entry has been
configured in the vacmAccessTable for the
specified combination of contextName,
groupName (from vacmSecurityToGroupTable),
securityModel and securityLevel.
otherError - failure, an undefined error occurred.
securityModel - Security Model under which access is requested.
securityName - the principal on whose behalf access is requested.
securityLevel - Level of Security under which access is requested.
viewType - view to be checked (read, write or notify).
contextName - context in which access is requested.
variableName - object instance to which access is requested.3.1. Overview of isAccessAllowed Process
this picture is the big-brain map of how the View-based Access Control Model decides access 🧠🦋
+--------------------------------------------------------------------+
| |
| +-> securityModel -+ |
| | (a) | |
| who -+ +-> groupName ----+ |
| (1) | | (x) | |
| +-> securityName --+ | |
| (b) | |
| | |
| where -> contextName ---------------------+ |
| (2) (e) | |
| | |
| | |
| +-> securityModel -------------------+ |
| | (a) | |
| how -+ +-> viewName -+ |
| (3) | | (y) | |
| +-> securityLevel -------------------+ | |
| (c) | +-> yes/no |
| | | decision |
| why ---> viewType (read/write/notify) ----+ | (z) |
| (4) (d) | |
| | |
| what --> object-type ------+ | |
| (5) (m) | | |
| +-> variableName (OID) ------+ |
| | (f) |
| which -> object-instance --+ |
| (6) (n) |
| |
+--------------------------------------------------------------------+How the isAccessAllowed decision gets made, step by step 🌈
- First, the inputs to the isAccessAllowed service are:
(a) securityModel -- Security Model in use (b) securityName -- principal who wants to access (c) securityLevel -- Level of Security (d) viewType -- read, write, or notify view (e) contextName -- context containing variableName (f) variableName -- OID for the managed object -- this is made up of:
- object-type (m)
- object-instance (n)
- The partial "who" (1), which is the securityModel (a) and the securityName (b), gets used as the indices (a,b) into the vacmSecurityToGroupTable. That finds one single entry that produces a group, called groupName (x) 👯
- The "where" (2), which is the contextName (e), plus the "who" in the form of the groupName (x) from the step before, plus the "how" (3), which is the securityModel (a) and securityLevel (c), are all used as indices (e,x,a,c) into the vacmAccessTable. That finds one single entry holding three MIB views 🎯
- The "why" (4), which is the viewType (d), picks the right MIB view, called viewName (y), out of the vacmAccessEntry we just found. This viewName (y) is an index into the vacmViewTreeFamilyTable, and it selects the entries that define which variableNames are included in or excluded from that MIB view 💖
- Last step! The "what" (5) type of management data and the "which" (6) particular instance, represented by the variableName (f), gets checked to see if it's in the MIB view or not. That gives you the yes/no decision (z) 🎉
3.2. Processing the isAccessAllowed Service Request
this section is the procedure an Access Control module follows every single time it gets an isAccessAllowed request 🫶
- First, the vacmContextTable gets checked for info about the SNMP context named by the contextName. If that context isn't in the table, an errorIndication (noSuchContext) goes back to the calling module 🙅♀️
- Next, the vacmSecurityToGroupTable gets checked to map the securityModel and securityName to a groupName. If that combination isn't in the table, an errorIndication (noGroupName) goes back to the calling module 💀
- Then the vacmAccessTable gets checked for info about the groupName, contextName, securityModel and securityLevel. If that combination is missing, an errorIndication (noAccessEntry) goes back to the calling module 😭
- Now pick the view based on the viewType:
a) If the viewType is "read", then the read view is used for checking access rights.
b) If the viewType is "write", then the write view is used for checking access rights.
c) If the viewType is "notify", then the notify view is used for checking access rights.
If the view to be used is the empty view (zero length viewName), then an errorIndication (noSuchView) goes back to the calling module 🙈
- Almost there, bestie 🌷
a) If there is no view configured for the specified viewType, then an errorIndication (noSuchView) goes back to the calling module.
b) If the specified variableName (object instance) is not in the MIB view (see DESCRIPTION clause for vacmViewTreeFamilyTable in section 4), then an errorIndication (notInView) goes back to the calling module.
Otherwise,
c) The specified variableName is in the MIB view. A statusInformation of success (accessAllowed) goes back to the calling module. Access granted, periodt 👑✨
4. Definitions
the MIB module itself is up next, so here's where it begins 🧚
SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGINvacmAccessTable OBJECT-TYPE SYNTAX SEQUENCE OF VacmAccessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of access rights for groups.
Each entry in this table is indexed by a groupName, a contextPrefix, a securityModel, and a securityLevel. " ::= { vacmMIBObjects 4 }
vacmAccessEntry OBJECT-TYPE SYNTAX VacmAccessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table defines the access rights for a group, in a particular context, for a particular securityModel and securityLevel. " INDEX { vacmGroupName, vacmAccessContextPrefix, vacmAccessSecurityModel, vacmAccessSecurityLevel } ::= { vacmAccessTable 1 }
VacmAccessEntry ::= SEQUENCE { vacmAccessContextPrefix SnmpAdminString, vacmAccessSecurityModel SnmpSecurityModel, vacmAccessSecurityLevel SnmpSecurityLevel, vacmAccessContextMatch INTEGER, vacmAccessReadViewName SnmpAdminString, vacmAccessWriteViewName SnmpAdminString, vacmAccessNotifyViewName SnmpAdminString, vacmAccessStorageType StorageType, vacmAccessStatus RowStatus }
vacmAccessContextPrefix OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "In order to gain access rights to an SNMP context, the contextName of the context must be prefixed by this value, as determined by the value of the vacmAccessContextMatch column.
The empty contextPrefix (zero length) represents the default context prefix. " ::= { vacmAccessEntry 1 }
vacmAccessSecurityModel OBJECT-TYPE SYNTAX SnmpSecurityModel(0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The securityModel to which this entry applies. A value of 'any' (0) indicates that this entry applies to all securityModels. " ::= { vacmAccessEntry 2 }
vacmAccessSecurityLevel OBJECT-TYPE SYNTAX SnmpSecurityLevel MAX-ACCESS not-accessible STATUS current DESCRIPTION "The minimum level of security required in order to gain access rights in this entry. " ::= { vacmAccessEntry 3 }
vacmAccessContextMatch OBJECT-TYPE SYNTAX INTEGER { exact(1), prefix(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "If the value of this object is exact(1), then all instances of the contextName must exactly match the contextPrefix in order for this entry to apply.
If the value of this object is prefix(2), then all contextName instances that begin with a prefix matching the contextPrefix value apply. " DEFVAL { exact } ::= { vacmAccessEntry 4 }
okay bestie, this part is where the access rules get real 💅 the vacmAccessTable is basically a bouncer's guest list 🎀 Each row is keyed by a groupName, a contextPrefix, a securityModel, and a securityLevel. When more than one row matches, the table has a whole tiebreak system (exact matches win, then the specific security model, then the longest prefix, then the highest securityLevel) 🦋 and noAuthNoPriv is the one case where all groups are basically equal 🙈
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:
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.
"
::= { vacmMIBObjects 4 }
vacmAccessEntry OBJECT-TYPE
SYNTAX VacmAccessEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An access right configured in the Local Configuration
Datastore (LCD) authorizing access to an SNMP context.
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.
"
INDEX { vacmGroupName,
vacmAccessContextPrefix,
vacmAccessSecurityModel,
vacmAccessSecurityLevel
}
::= { vacmAccessTable 1 }
VacmAccessEntry ::= SEQUENCE
{
vacmAccessContextPrefix SnmpAdminString,
vacmAccessSecurityModel SnmpSecurityModel,
vacmAccessSecurityLevel SnmpSecurityLevel,
vacmAccessContextMatch INTEGER,
vacmAccessReadViewName SnmpAdminString,
vacmAccessWriteViewName SnmpAdminString,
vacmAccessNotifyViewName SnmpAdminString,
vacmAccessStorageType StorageType,
vacmAccessStatus RowStatus
}
vacmAccessContextPrefix OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "In order to gain the access rights allowed by this
conceptual row, a contextName must match exactly
(if the value of vacmAccessContextMatch is 'exact')
or partially (if the value of vacmAccessContextMatch
is 'prefix') to the value of the instance of this
object.
"
::= { vacmAccessEntry 1 }
vacmAccessSecurityModel OBJECT-TYPE
SYNTAX SnmpSecurityModel
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "In order to gain the access rights allowed by this
conceptual row, this securityModel must be in use.
"
::= { vacmAccessEntry 2 }
vacmAccessSecurityLevel OBJECT-TYPE
SYNTAX SnmpSecurityLevel
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The minimum level of security required in order to
gain the access rights allowed by this conceptual
row. A securityLevel of noAuthNoPriv is less than
authNoPriv which in turn is less than authPriv.
If multiple entries are equally indexed except for
this vacmAccessSecurityLevel index, then the entry
which has the highest value for
vacmAccessSecurityLevel is selected.
"
::= { vacmAccessEntry 3 }
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
DESCRIPTION "If the value of this object is exact(1), then all
rows where the contextName exactly matches
vacmAccessContextPrefix are selected.
If the value of this object is prefix(2), then all
rows where the contextName whose starting octets
exactly match vacmAccessContextPrefix are selected.
This allows for a simple form of wildcarding.
"
DEFVAL { exact }
::= { vacmAccessEntry 4 }
vacmAccessReadViewName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The value of an instance of this object identifies
the MIB view of the SNMP context to which this
conceptual row authorizes read access.
The identified MIB view is that one for which the
vacmViewTreeFamilyViewName has the same value as the
instance of this object; 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.
"
DEFVAL { ''H } -- the empty string
::= { vacmAccessEntry 5 }
vacmAccessWriteViewName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The value of an instance of this object identifies
the MIB view of the SNMP context to which this
conceptual row authorizes write access.
The identified MIB view is that one for which the
vacmViewTreeFamilyViewName has the same value as the
instance of this object; 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.
"
DEFVAL { ''H } -- the empty string
::= { vacmAccessEntry 6 }
vacmAccessNotifyViewName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "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.
The identified MIB view is that one for which the
vacmViewTreeFamilyViewName has the same value as the
instance of this object; 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.
"
DEFVAL { ''H } -- the empty string
::= { vacmAccessEntry 7 }
vacmAccessStorageType 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 }
::= { vacmAccessEntry 8 }
vacmAccessStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row.
The RowStatus TC [RFC2579] 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.
"
::= { vacmAccessEntry 9 }
-- 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.
vacmMIBViews OBJECT IDENTIFIER ::= { vacmMIBObjects 5 }
vacmViewSpinLock OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION "An advisory lock used to allow cooperating SNMP
Command Generator applications to coordinate their
use of the Set operation in creating or modifying
views.
When creating a new view or altering an existing
view, it is important to understand the potential
interactions with other uses of the view. The
vacmViewSpinLock should be retrieved. The name of
the view to be created should be determined to be
unique by the SNMP Command Generator application by
consulting the vacmViewTreeFamilyTable. Finally,
the named view may be created (Set), 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, and 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.
"
::= { vacmMIBViews 1 }okay so the view families table is literally where the magic happens 🦋 every MIB view is built from two piles of subtrees, the included ones and the excluded ones, and they all live right here ✨
vacmViewTreeFamilyTable OBJECT-TYPE
SYNTAX SEQUENCE OF VacmViewTreeFamilyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "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.
"
::= { vacmMIBViews 2 }the matching rules are so iconic 💅 an object's OID gets checked against every active row, and the row with the most sub-identifiers wins 👑 if there's a tie, the lexicographically greatest type decides, no cap 🙈
vacmViewTreeFamilyEntry OBJECT-TYPE
SYNTAX VacmViewTreeFamilyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "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.
"
INDEX { vacmViewTreeFamilyViewName,
vacmViewTreeFamilySubtree
}
::= { vacmViewTreeFamilyTable 1 }
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
DESCRIPTION "The human readable name for a family of view subtrees.
"
::= { vacmViewTreeFamilyEntry 1 }
vacmViewTreeFamilySubtree OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The MIB subtree which when combined with the
corresponding instance of vacmViewTreeFamilyMask
defines a family of view subtrees.
"
::= { vacmViewTreeFamilyEntry 2 }ok the mask is where it gets seriously fun 🌈 each bit lines up with a sub-identifier, and a '0' means wild card while a '1' means exact match, so a family can cover a whole bunch of subtrees at once 🦋
vacmViewTreeFamilyMask 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 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 }the rest of the columns are pretty chill 🍓 type says whether a family is included or excluded, storage and status are the usual vibes, and the status column doesn't decide whether the other columns can be changed 🧚
vacmViewTreeFamilyType OBJECT-TYPE
SYNTAX INTEGER { included(1), excluded(2) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION "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
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 }
::= { vacmViewTreeFamilyEntry 5 }
vacmViewTreeFamilyStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row.
The RowStatus TC [RFC2579] 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.
"
::= { vacmViewTreeFamilyEntry 6 }now the conformance bit 🎀 this is the part that says what an engine has to support to count as compliant, and a bunch of the write access stuff is marked as optional for the vibes to stay chill 💜
-- Conformance information *******************************************
vacmMIBCompliances OBJECT IDENTIFIER ::= { vacmMIBConformance 1 }
vacmMIBGroups OBJECT IDENTIFIER ::= { vacmMIBConformance 2 }
-- Compliance statements *********************************************
vacmMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for SNMP engines which
implement the SNMP View-based Access Control Model
configuration MIB.
"
MODULE -- this module
MANDATORY-GROUPS { vacmBasicGroup }
OBJECT vacmAccessContextMatch
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmAccessReadViewName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmAccessWriteViewName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmAccessNotifyViewName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmAccessStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmAccessStatus
MIN-ACCESS read-only
DESCRIPTION "Create/delete/modify access to the
vacmAccessTable is not required.
"
OBJECT vacmViewTreeFamilyMask
WRITE-SYNTAX OCTET STRING (SIZE (0))
MIN-ACCESS read-only
DESCRIPTION "Support for configuration via SNMP of subtree
families using wild-cards is not required.
"
OBJECT vacmViewTreeFamilyType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmViewTreeFamilyStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmViewTreeFamilyStatus
MIN-ACCESS read-only
DESCRIPTION "Create/delete/modify access to the
vacmViewTreeFamilyTable is not required.
"
::= { vacmMIBCompliances 1 }
-- Units of conformance **********************************************next up: the units of conformance 🌸✨
vacmBasicGroup OBJECT-GROUP
OBJECTS {
vacmContextName,
vacmGroupName,
vacmSecurityToGroupStorageType,
vacmSecurityToGroupStatus,
vacmAccessContextMatch,
vacmAccessReadViewName,
vacmAccessWriteViewName,
vacmAccessNotifyViewName,
vacmAccessStorageType,
vacmAccessStatus,
vacmViewSpinLock,
vacmViewTreeFamilyMask,
vacmViewTreeFamilyType,
vacmViewTreeFamilyStorageType,
vacmViewTreeFamilyStatus
}
STATUS current
DESCRIPTION "A collection of objects providing for remote
configuration of an SNMP engine which implements
the SNMP View-based Access Control Model.
"
::= { vacmMIBGroups 1 }
END5. Intellectual Property ✨
okay so the IETF is basically saying "we're not picking sides here" 💅 They don't take a position on whether any intellectual property or other rights could be claimed over the tech in this document, or whether any license under those rights is available. They also don't say they've gone looking for any of those rights, so no promises either way 🫶
If you want the IETF's procedures for rights in standards-track and standards-related docs, check out BCP-11 📚 Copies of claimed rights that were made available for publication, plus any licence assurances, or the outcome of an attempt to get a general license or permission for implementers or users of this spec to use those proprietary rights, can all be obtained from the IETF Secretariat 💌
The IETF also invites anyone who's interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to practise this standard 🦋 Send that info to the IETF Executive Director, bestie!
6. Acknowledgements 🌸
this document is the result of the SNMPv3 Working Group's hard work, and we need to give some serious shoutouts to these legends 👑
- Harald Tveit Alvestrand (Maxware)
- Dave Battle (SNMP Research, Inc.)
- Alan Beard (Disney Worldwide Services)
- Paul Berrevoets (SWI Systemware/Halcyon Inc.)
- Martin Bjorklund (Ericsson)
- Uri Blumenthal (IBM T.J. Watson Research Center)
- Jeff Case (SNMP Research, Inc.)
- John Curran (BBN)
- Mike Daniele (Compaq Computer Corporation)
- T. Max Devlin (Eltrax Systems)
- John Flick (Hewlett Packard)
- Rob Frye (MCI)
- Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.)
- David Harrington (Cabletron Systems Inc.)
- Lauren Heintz (BMC Software, Inc.)
- N.C. Hien (IBM T.J. Watson Research Center)
- Michael Kirkham (InterWorking Labs, Inc.)
- Dave Levi (SNMP Research, Inc.)
- Louis A Mamakos (UUNET Technologies Inc.)
- Joe Marzot (Nortel Networks)
- Paul Meyer (Secure Computing Corporation)
- Keith McCloghrie (Cisco Systems)
- Bob Moore (IBM)
- Russ Mundy (TIS Labs at Network Associates)
- Bob Natale (ACE*COMM Corporation)
- Mike O'Dell (UUNET Technologies Inc.)
- Dave Perkins (DeskTalk)
- Peter Polkinghorne (Brunel University)
- Randy Presuhn (BMC Software, Inc.)
- David Reeder (TIS Labs at Network Associates)
- David Reid (SNMP Research, Inc.)
- Aleksey Romanov (Quality Quorum)
- Shawn Routhier (Epilogue)
- Juergen Schoenwaelder (TU Braunschweig)
- Bob Stewart (Cisco Systems)
- Mike Thatcher (Independent Consultant)
- Bert Wijnen (IBM T.J. Watson Research Center)
the design is based on recommendations from the IETF Security and Administrative Framework Evolution for SNMP Advisory Team ✨ The members of that Advisory Team were:
- David Harrington (Cabletron Systems Inc.)
- Jeff Johnson (Cisco Systems)
- David Levi (SNMP Research Inc.)
- John Linn (Openvision)
- Russ Mundy (Trusted Information Systems) chair
- Shawn Routhier (Epilogue)
- Glenn Waters (Nortel)
- Bert Wijnen (IBM T. J. Watson Research Center)
as the Advisory Team and the SNMPv3 Working Group Charter recommended, the design pulls in as much as is practical from earlier RFCs and drafts 🧚 So big thanks are due to the authors of the earlier designs known as SNMPv2u and SNMPv2*:
- Jeff Case (SNMP Research, Inc.)
- David Harrington (Cabletron Systems Inc.)
- David Levi (SNMP Research, Inc.)
- Keith McCloghrie (Cisco Systems)
- Brian O'Keefe (Hewlett Packard)
- Marshall T. Rose (Dover Beach Consulting)
- Jon Saperia (BGS Systems Inc.)
- Steve Waldbusser (International Network Services)
- Glenn W. Waters (Bell-Northern Research Ltd.)
7. Security Considerations 🔒
7.1. Recommended Practices
okay, security is where it gets dramatic 😭 This doc is meant for use in the SNMP architecture. The View-based Access Control Model checks access rights to management information based on these things:
- contextName, which represents a set of management information at the managed system where the Access Control module is running.
- groupName, which represents a set of zero or more securityNames. The combination of a securityModel and a securityName is mapped into a group in the View-based Access Control Model.
- securityModel under which access is requested.
- securityLevel under which access is requested.
- operation performed on the management information.
- MIB views for read, write or notify access.
when the User-based Access Control module gets called to check access rights, it's assumed that the calling module already took care of the authentication and privacy stuff for the securityLevel being passed in 🫶
and this part is so important 🚨 when you're creating or deleting entries in the vacmViewTreeFamilyTable, you need to do it in the sequence recommended in the DESCRIPTION clause of that table's definition. If you don't, unwanted access might get granted while the entries are being changed 💀
7.2. Defining Groups
the groupNames are used to give access to a group of zero or more securityNames 🎀 In the View-Based Access Control Model, a groupName counts as existing if it's listed in the vacmSecurityToGroupTable.
by mapping a securityModel and securityName combo into a groupName, an SNMP Command Generator application can add or delete securityNames to and from a group, as long as it has proper access 💅
also, realise that grouping <securityModel, securityName> tuples in the vacmSecurityToGroupTable does NOT take securityLevel into account 🙈 So the security admin has to use the securityLevel index in the vacmAccessTable to keep noAuthNoPriv separate from authPriv and/or authNoPriv access. that's the whole vibe ✨
7.3. Conformance
for an implementation of the View-based Access Control Model to be conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB according to the vacmMIBCompliance. It also SHOULD implement the initial configuration described in Appendix A 🌈
7.4. Access to the SNMP-VIEW-BASED-ACM-MIB
the objects in this MIB control access to all the MIB data that's reachable through the SNMP engine, and in lots of environments they can be considered sensitive 😭 It's really important to tightly control (both read and write) access to these MIB objects, using appropriately configured Access Control models, like the View-based Access Control Model specified in this document 🔥
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[SNMP3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
"Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", STD 62, RFC 3412,
December 2002.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.8.2. Informative References
[ISO-ASN.1] Information processing systems - Open Systems
Interconnection - Specification of Abstract Syntax
Notation One (ASN.1), International Organization for
Standardization. International Standard 8824, (December,
1987).Appendix A - Installation ✨
A.1. Installation Parameters
Okay so, before an authoritative SNMP engine can vibe with this View-based Access Control Model, it SHOULD be configured with a few initial parameters. 🛠️✨ For the View-based Access Control Model, these are:
1) A security configuration 🔐
The security configuration decides whether any initial configuration happens at all, and if it does, how. You pick exactly one of these three:
initial-minimum-security-configurationinitial-semi-security-configurationinitial-no-access-configuration
If you pick initial-no-access-configuration, there's no initial configuration, so the steps below don't matter 🙈
2) A default context 🎀
You need one entry in the vacmContextTable with a contextName of "" (the empty string), which represents the default context. Fun fact: this table gets created automatically if a default context exists.
vacmContextName ""3) An initial group 🧚
You need one entry in the vacmSecurityToGroupTable that lets the group "initial" get access.
vacmSecurityModel 3 (USM)
vacmSecurityName "initial"
vacmGroupName "initial"
vacmSecurityToGroupStorageType anyValidStorageType
vacmSecurityToGroupStatus active4) Initial access rights 🔑
You need three entries in the vacmAccessTable, like this:
- read-notify access for securityModel USM and securityLevel
"noAuthNoPriv", on behalf of securityNames that belong to the group"initial", to the<restricted>MIB view in the default context with contextName"". - read-write-notify access for securityModel USM and securityLevel
"authNoPriv", on behalf of securityNames that belong to the group"initial", to the<internet>MIB view in the default context with contextName"". - If privacy is supported, read-write-notify access for securityModel USM and securityLevel
"authPriv", on behalf of securityNames that belong to the group"initial", to the<internet>MIB view in the default context with contextName"".
Here's how that turns into actual vacmAccessTable entries.
One entry is for unauthenticated access (noAuthNoPriv):
vacmGroupName "initial"
vacmAccessContextPrefix ""
vacmAccessSecurityModel 3 (USM)
vacmAccessSecurityLevel noAuthNoPriv
vacmAccessContextMatch exact
vacmAccessReadViewName "restricted"
vacmAccessWriteViewName ""
vacmAccessNotifyViewName "restricted"
vacmAccessStorageType anyValidStorageType
vacmAccessStatus activeAnd one entry is for authenticated access (authNoPriv), with optional privacy (authPriv):
vacmGroupName "initial"
vacmAccessContextPrefix ""
vacmAccessSecurityModel 3 (USM)
vacmAccessSecurityLevel authNoPriv
vacmAccessContextMatch exact
vacmAccessReadViewName "internet"
vacmAccessWriteViewName "internet"
vacmAccessNotifyViewName "internet"
vacmAccessStorageType anyValidStorageType
vacmAccessStatus active5) Two MIB views 🦋
The second view depends on which security configuration you picked. 👀
- First up is the
<internet>view, for authenticated access. The<internet>MIB view is this subtree:"internet"(subtree 1.3.6.1). - Next is the
<restricted>view, for unauthenticated access. It's set up according to your security configuration:- For
initial-no-access-configuration, there's no default initial configuration, so no MIB views are prescribed. - For
initial-semi-secure-configuration, the<restricted>MIB view is the union of these subtrees: - For
initial-minimum-secure-configuration, the<restricted>MIB view is this subtree:"internet"(subtree 1.3.6.1).
- For
All of this translates into the following "internet" entry in the vacmViewTreeFamilyTable:
minimum-secure semi-secure
---------------- ---------------
vacmViewTreeFamilyViewName "internet" "internet"
vacmViewTreeFamilySubtree 1.3.6.1 1.3.6.1
vacmViewTreeFamilyMask "" ""
vacmViewTreeFamilyType 1 (included) 1 (included)
vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
vacmViewTreeFamilyStatus active activeOn top of that, it also translates into the following "restricted" entries in the vacmViewTreeFamilyTable:
minimum-secure semi-secure
---------------- ---------------
vacmViewTreeFamilyViewName "restricted" "restricted"
vacmViewTreeFamilySubtree 1.3.6.1 1.3.6.1.2.1.1
vacmViewTreeFamilyMask "" ""
vacmViewTreeFamilyType 1 (included) 1 (included)
vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
vacmViewTreeFamilyStatus active active
vacmViewTreeFamilyViewName "restricted"
vacmViewTreeFamilySubtree 1.3.6.1.2.1.11
vacmViewTreeFamilyMask ""
vacmViewTreeFamilyType 1 (included)
vacmViewTreeFamilyStorageType anyValidStorageType
vacmViewTreeFamilyStatus active
vacmViewTreeFamilyViewName "restricted"
vacmViewTreeFamilySubtree 1.3.6.1.6.3.10.2.1
vacmViewTreeFamilyMask ""
vacmViewTreeFamilyType 1 (included)
vacmViewTreeFamilyStorageType anyValidStorageType
vacmViewTreeFamilyStatus active
vacmViewTreeFamilyViewName "restricted"
vacmViewTreeFamilySubtree 1.3.6.1.6.3.11.2.1
vacmViewTreeFamilyMask ""
vacmViewTreeFamilyType 1 (included)
vacmViewTreeFamilyStorageType anyValidStorageType
vacmViewTreeFamilyStatus active
vacmViewTreeFamilyViewName "restricted"
vacmViewTreeFamilySubtree 1.3.6.1.6.3.15.1.1
vacmViewTreeFamilyMask ""
vacmViewTreeFamilyType 1 (included)
vacmViewTreeFamilyStorageType anyValidStorageType
vacmViewTreeFamilyStatus activeB. Change Log 📝
Here's what changed since RFC 2575:
- Removed reference from abstract as per RFC-Editor guidelines
- Updated references
And here's what changed since RFC 2275:
- Added text to vacmSecurityToGroupStatus DESCRIPTION clause to clarify under which conditions an entry in the vacmSecurityToGroupTable can be made active.
- Added REVISION clauses to MODULE-IDENTITY
- Clarified text in vacmAccessTable DESCRIPTION clause.
- Added a DEFVAL clause to vacmAccessContextMatch object.
- Added missing columns in Appendix A and re-arranged for clarity.
- Fixed oids in appendix A.
- Use the PDU Class terminology instead of RFC1905 PDU types.
- Added section 7.4 about access control to the MIB.
- Fixed references to new/revised documents
- Fix Editor contact information.
- fixed spelling errors
- removed one vacmAccesEntry from sample in appendix A.
- made some more clarifications.
- updated acknowledgement section.
Editors' Addresses 💌
Bert Wijnen
Lucent Technologies
Schagen 33
3461 GL Linschoten
Netherlands
Phone: +31-348-480-685
EMail: bwijnen@lucent.comRandy Presuhn
BMC Software, Inc.
2141 North First Street
San Jose, CA 95131
USA
Phone: +1 408-546-1006
EMail: randy_presuhn@bmc.comKeith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Phone: +1-408-526-5260
EMail: kzm@cisco.comFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
📦 where this page comes from
- ietf: rfc3415 2002-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms