Internet Draft Andy Bierman
Cisco Systems, Inc.
31 May 2002
Conformance MIB
<draft-bierman-conf-mib-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. Please send comments to the
SMIng WG mailing list <sming@ops.ietf.org>.
1. Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
2. Abstract
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
Internet Draft Conformance MIB May 31, 2002
particular, it describes managed objects for identifying the conformance
level of all management information available from an SNMP agent.
3. Table of Contents
1 Copyright Notice ................................................ 1
2 Abstract ........................................................ 1
3 Table of Contents ............................................... 2
4 The SNMP Network Management Framework ........................... 2
5 Overview ........................................................ 3
5.1 MIB Structure ................................................. 4
5.2 Terms ......................................................... 5
6 Definitions ..................................................... 5
7 Appendix A: Conformance Information Usage Examples .............. 11
7.1 Full Conformance .............................................. 11
7.2 Full Conformance with some Optional Groups .................... 11
7.3 Previous Revision Conformance ................................. 11
7.4 Partial Conformance (I) ....................................... 12
7.5 Partial Conformance (II) ...................................... 12
7.6 Minimum Conformance ........................................... 13
7.7 Other Conformance ............................................. 13
8 Open Issues ..................................................... 13
9 Normative References ............................................ 14
10 Informative References ......................................... 15
11 Security Considerations ........................................ 17
12 Author's Address ............................................... 17
13 Full Copyright Statement ....................................... 18
4. The SNMP Network Management Framework
The SNMP Management Framework presently consists of five major
components:
o An overall architecture, described in RFC 2571 [RFC2571].
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in
RFC 1155 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215].
The second version, called SMIv2, is described in RFC 2578
[RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580].
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in RFC 1157 [RFC1157]. A second version of the SNMP
Expires December 1, 2002 [Page 2]
Internet Draft Conformance MIB May 31, 2002
message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC 1901 [RFC1901]
and RFC 1906 [RFC1906]. The third version of the message
protocol is called SNMPv3 and described in RFC 1906 [RFC1906],
RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in RFC 1157 [RFC1157]. A second set of protocol
operations and associated PDU formats is described in RFC 1905
[RFC1905].
o A set of fundamental applications described in RFC 2573
[RFC2573] and the view-based access control mechanism described
in RFC 2575 [RFC2575].
A more detailed introduction to the current SNMP Management Framework
can be found in RFC 2570 [RFC2570].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the mechanisms defined in the SMI.
This memo specifies a MIB module that is compliant to the SMIv2. A
MIB conforming to the SMIv1 can be produced through the appropriate
translations. The resulting translated MIB must be semantically
equivalent, except where objects or events are omitted because no
translation is possible (use of Counter64). Some machine readable
information in SMIv2 will be converted into textual descriptions in
SMIv1 during the translation process. However, this loss of machine
readable information is not considered to change the semantics of the
MIB.
5. Overview
There is a need for a standardized way of retrieving the conformance and
variance information associated with the managed objects support by a
particular agent.
Conformance Statements for SMIv2 [RFC2580] provides the MODULE-
COMPLIANCE macro, which allows the MIB writer to define different
conformance levels, in order to specify various subsets of the full
functionality defined in the MIB module, or allow for new versions of
the MIB module. Unfortunately, an NMS application developer cannot
easily determine the exact conformance level by any given agent
Expires December 1, 2002 [Page 3]
Internet Draft Conformance MIB May 31, 2002
implementation, even those that are following the standard correctly.
For example, it is not always easy to determine which version of a MIB
module is implemented, or if an agent implements the full semantics of
an object or the semantics refined by one of potentially several OBJECT
clauses (in different MODULE-COMPLIANCE macros).
The AGENT-CAPABILITIES macro allows an SNMP developer to determine
conformance information for specific objects for a particular release of
a particular product. Unfortunately, this information is not available
in any form from the agent. Instead, it is maintained as a text file by
the network administrator. The sysORTable [RFC1907] allows an agent to
advertise which AGENT-CAPABILITIES macros are supported, but this is
insufficient because these macros are stored in external files, and
since they are optional, agent developers are not required to provide
these files.
5.1. MIB Structure
The Conformance MIB contains a single group of conformance objects,
which contains a single scalar, called 'confLastUpdateTime', and a
single table, called the 'confTable'.
The 'confLastUpdateTime' allows an NMS application to determine if the
contents of the 'confTable' have changed over time. The 'confTable'
identifies conformance and variance information for a specified MIB sub-
tree. If multiple (overlapping) entries exist for a particular portion
of the MIB sub-tree, then the most specific entry (i.e. longest match)
has precedence. The following objects are contained in the 'confTable':
confModuleCompliance
An OID pointer to MODULE-COMPLIANCE macro pertaining to the set of
objects, as implemented by the agent.
confLevel
An enumerated integer describing the basic conformance level to the
specification for the set of objects, as implemented by the agent.
confVarSyntax
A string describing the semantic variation for a set of MIB objects
or a single MIB object. This usually consists of the SYNTAX clause
within the the VARIATION clause that would be present in an AGENT-
CAPABILITIES macro for the specified object, or the SYNTAX, WRITE-
SYNTAX and/or MIN-ACCESS clauses that would be present in the
OBJECT macro within a MODULE-COMPLIANCE macro.
Expires December 1, 2002 [Page 4]
Internet Draft Conformance MIB May 31, 2002
5.2. Terms
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 RFC 2119. [RFC2119]
6. Definitions
CONFORMANCE-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, mib-2
FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
TEXTUAL-CONVENTION, TimeStamp
FROM SNMPv2-TC;
conformanceMIB MODULE-IDENTITY
LAST-UPDATED "200205300000Z"
ORGANIZATION "IETF OPS-NM Area"
CONTACT-INFO
" Andy Bierman
Cisco Systems, Inc.
Tel: +1 408 527-3711
E-mail: abierman@cisco.com
Postal: 170 West Tasman Drive
San Jose, CA USA 95134
Send comments to <mibs@ops.ietf.org>"
DESCRIPTION
"Contains objects which describe the conformance
level for specific data objects."
REVISION "200205300000Z"
DESCRIPTION
"Initial version."
::= { mib-2 xxx } -- unassigned
confMibObjects OBJECT IDENTIFIER ::= { conformanceMIB 1 }
confMibNotifications OBJECT IDENTIFIER ::= { conformanceMIB 2 }
confMibConformance OBJECT IDENTIFIER ::= { conformanceMIB 3 }
confMibConformanceObjects OBJECT IDENTIFIER
::= { confMibObjects 1 }
Expires December 1, 2002 [Page 5]
Internet Draft Conformance MIB May 31, 2002
--
-- Textual Conventions
--
ConformanceLevel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An indication of the conformance level for a particular set
of MIB objects.
The value 'noConf' indicates that the agent does not
implement any of the required semantics for the associated
set of objects. Usually this means the object is not
implemented at all. However, it also indicates the special
case in which incorrect values are returned, e.g., counter
objects that always return zero, string objects that always
return a zero-length string (but should not), hard-wired
(potentially incorrect) enumerations or gauges.
The value 'otherConf' indicates that the implementation
complies with the semantics of the associated set of objects
in a manner that varies from the specification in some way.
The value 'minConf' indicates that the implementation
complies with the semantics of the associated set of objects
as refined by a GROUP clause or an OBJECT clause within a
MODULE-COMPLIANCE macro.
The value 'fullConf' indicates that the implementation
complies with the semantics of the associated set of objects
as defined by an indicated compliance statement for the set
of objects.
The value 'completeConf' indicates that the implementation
complies with the full semantics of the associated set of
objects as defined by the data definitions for the objects.
This may be greater than than the conformance level
indicated by the 'fullConf' enumeration if the indicated
compliance statement does not require full implementation of
the entire set of objects."
REFERENCE
"RFC 2580, section 5."
SYNTAX INTEGER {
noConf(1),
otherConf(2),
Expires December 1, 2002 [Page 6]
Internet Draft Conformance MIB May 31, 2002
minConf(3),
fullConf(4),
completeConf(5)
}
ConformanceString ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An administrative string identifying conformance
information.
An object of this type SHOULD follow the encoding rules for
an SnmpAdminString, except its length is limited to 1024
octets instead of 255 octets."
REFERENCE
"RFC 2571, section 5."
SYNTAX OCTET STRING (SIZE (0..1024)) -- SnmpAdminString
--
-- Conformance Group scalars
--
confLastUpdateTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when the agent last added, deleted,
or modified an entry in the confTable."
::= { confMibConformanceObjects 1 }
--
-- Conformance Table
--
confTable OBJECT-TYPE
SYNTAX SEQUENCE OF ConfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of entries describing the MIB conformance for this
agent."
::= { confMibConformanceObjects 2 }
Expires December 1, 2002 [Page 7]
Internet Draft Conformance MIB May 31, 2002
confEntry OBJECT-TYPE
SYNTAX ConfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A conceptual row in the confTable. Entries SHOULD be
created by the agent at system reinitialization time.
However, agents MAY create, delete, or modify entries in
this table to support dynamic loading and unloading of MIB
modules. It is possible that overlapping entries will exist
in this table, in which case the more specific entry (i.e.,
the one with the longest confSubTree INDEX) takes
precedence."
INDEX { confSubTree }
::= { confTable 1 }
ConfEntry ::= SEQUENCE {
confSubTree OBJECT IDENTIFIER,
confModuleCompliance OBJECT IDENTIFIER,
confLevel ConformanceLevel,
confVarSyntax ConformanceString }
confSubTree OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The root of the MIB sub-tree associated with this entry.
This object SHOULD identify an interior node to indicate
multiple MIB objects or a leaf node to indicate a single MIB
object."
::= { confEntry 1 }
confModuleCompliance OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Identifies the MODULE-COMPLIANCE macro name for the
associated set of MIB objects. If no appropriate value can
be determined, then the agent will return '0.0'."
REFERENCE
"RFC 2580, section 5.5."
::= { confEntry 2 }
Expires December 1, 2002 [Page 8]
Internet Draft Conformance MIB May 31, 2002
confLevel OBJECT-TYPE
SYNTAX ConformanceLevel
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the basic level of conformance for the associated
set of MIB objects.
If this object contains the value 'otherConf', then the
confVarSyntax object SHOULD be present for the associated
entry.
If this object contains the value 'fullConf', 'minConf', or
'noConf' then the confVarSyntax object MAY be present for
the associated entry.
If this object contains the value 'completeConf' then the
confVarSyntax object SHOULD NOT be present for the
associated entry."
REFERENCE
"RFC 2580, section 5."
::= { confEntry 3 }
confVarSyntax OBJECT-TYPE
SYNTAX ConformanceString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A textual representation of the syntactical variation
described by this variation structure.
If the associated confLevel object is equal to 'otherConf',
then this string SHOULD contain the the same value as the
SYNTAX clause within a VARIATION clause of an AGENT-
CAPABILITIES macro.
If the associated confLevel object is equal to 'minConf',
and this entry identifies a set of MIB objects, then this
string MAY identify the applicable GROUP clause(s)
associated with the entry.
For all entries in which the associated confLevel object is
equal to 'minConf', this string SHOULD contain the same
value as the SYNTAX, WRITE-SYNTAX, and/or MIN-ACCESS clauses
present within the OBJECT clause of a MODULE-COMPLIANCE
Expires December 1, 2002 [Page 9]
Internet Draft Conformance MIB May 31, 2002
macro. The actual keyword (e.g., 'SYNTAX') SHOULD precede
the quoted string value. Multiple clauses MAY be
concatenated within a single string, and SHOULD be separated
by whitespace. If this entry identifies multiple objects,
then the same clause(s) must apply to all objects.
The agent MAY return a zero-length string instead of a
noSuchInstance exception."
REFERENCE
"RFC 2580, sections 5.4.3 and 6.5.2."
::= { confEntry 4 }
--
-- Notification Section (none defined)
--
--
-- Conformance Section
--
confMibCompliances OBJECT IDENTIFIER ::= { confMibConformance 1 }
confMibGroups OBJECT IDENTIFIER ::= { confMibConformance 2 }
confMibCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Describes the requirements for conformance to the
Conformance MIB."
MODULE -- this module
MANDATORY-GROUPS { confMibConformanceGroup }
::= { confMibCompliances 1 }
-- Object Groups
confMibConformanceGroup OBJECT-GROUP
OBJECTS {
confLastUpdateTime,
confModuleCompliance,
confLevel,
confVarSyntax
}
STATUS current
DESCRIPTION
"A collection of objects used to describe the conformance
Expires December 1, 2002 [Page 10]
Internet Draft Conformance MIB May 31, 2002
level of the MIB objects supported by an agent."
::= { confMibGroups 1 }
END
7. Appendix A: Conformance Information Usage Examples
The Interfaces MIB [RFC2233][RFC2863] is used to demonstrate some
possible applications of the Conformance MIB.
7.1. Full Conformance
This example shows full conformance to the RFC 2863 version of the
Interfaces MIB. Note that the MODULE-COMPLIANCE allows many objects to
be omitted, as specified by the various GROUP macros. The enumeration
'fullConf' indicates that the full implementation of all mandatory
objects is supported, even if OBJECT clauses exist for some mandatory
objects.
- confTable entry for the entire IF-MIB:
- confSubTree INDEX == { ifMIB 1 }
- confModuleCompliance == { ifCompliance3 }
- confLevel == 'fullConf(4)'
- confVarSyntax == noSuchInstance (or empty string)
7.2. Full Conformance with some Optional Groups
This example shows full conformance to the RFC 2863 version of the
Interfaces MIB. In this example, the agent supports the groups required
for character-oriented interfaces with ifSpeed values not exceeding
20,000,000 bits/second.
- confTable entry for the entire IF-MIB:
- confSubTree INDEX == { ifMIB 1 }
- confModuleCompliance == { ifCompliance3 }
- confLevel == 'fullConf(4)'
- confVarSyntax == 'GROUP ifFixedLengthGroup'
7.3. Previous Revision Conformance
This example shows full conformance to the RFC 2233 version of the
Interfaces MIB. In this example, the agent supports all the mandatory
groups, and supports the group for high capacity packet based
interfaces.
Expires December 1, 2002 [Page 11]
Internet Draft Conformance MIB May 31, 2002
- confTable entry for the entire IF-MIB:
- confSubTree INDEX == { ifMIB 1 }
- confModuleCompliance == { ifCompliance2 }
- confLevel == 'fullConf(4)'
- confVarSyntax == 'GROUP ifHCPacketGroup'
7.4. Partial Conformance (I)
This example shows complete conformance to the RFC 2863 version of the
Interfaces MIB. In this example, the agent supports all the mandatory
groups and all the optional groups, however, the deprecated ifTestTable
is not implemented.
- confTable entry for the entire IF-MIB:
- confSubTree INDEX == { ifMIB 1 }
- confModuleCompliance == { ifCompliance3 }
- confLevel == 'completeConf(5)'
- confVarSyntax == noSuchInstance (or empty string)
- confTable entry for the ifTestTable:
- confSubTree INDEX == { ifMIBObjects 3 }
- confModuleCompliance == { ifCompliance3 }
- confLevel == 'noConf(1)'
- confVarSyntax == noSuchInstance (or empty string)
7.5. Partial Conformance (II)
This example shows full conformance to the RFC 2863 version of the
ifTable and ifXTable, except for the ifTable non-unicast packet
counters, which are not implemented at all.
- confTable entry for the ifTable:
- confSubTree INDEX == { interfaces 2 }
- confModuleCompliance == { ifCompliance3 }
- confLevel == 'fullConf(4)'
- confVarSyntax == noSuchInstance (or empty string)
- confTable entry for the ifXTable:
- confSubTree INDEX == { ifMIBObjects 1 }
- confModuleCompliance == { ifCompliance3 }
- confLevel == 'fullConf(4)'
- confVarSyntax == noSuchInstance (or empty string)
- confTable entry for the ifInNUcastPkts:
- confSubTree INDEX == { ifEntry 12 }
Expires December 1, 2002 [Page 12]
Internet Draft Conformance MIB May 31, 2002
- confModuleCompliance == { ifCompliance3 }
- confLevel == 'noConf(1)'
- confVarSyntax == noSuchInstance (or empty string)
- confTable entry for the ifOutNUcastPkts:
- confSubTree INDEX == { ifEntry 18 }
- confModuleCompliance == { ifCompliance3 }
- confLevel == 'noConf(1)'
- confVarSyntax == noSuchInstance (or empty string)
7.6. Minimum Conformance
This example shows minimum conformance to the RFC 2863 version of the
ifTable. In this example, the agent supports all the mandatory objects,
except the table is implemented as read-only.
- confTable entry for the ifTable:
- confSubTree INDEX == { interfaces 2 }
- confModuleCompliance == { ifCompliance3 }
- confLevel == 'minConf(3)'
- confVarSyntax == 'MIN-ACCESS read-only'
7.7. Other Conformance
This example shows full conformance to the RFC 2863 version of the
ifXTable, except the ifAlias object, which is implemented as a read-
write 32 octet string, instead of a read-write 64 octet string.
- confTable entry for the ifXTable:
- confSubTree INDEX == { ifMIBObjects 1 }
- confModuleCompliance == { ifCompliance3 }
- confLevel == 'fullConf(4)'
- confVarSyntax == noSuchInstance (or empty string)
- confTable entry for ifAlias:
- confSubTree INDEX == { ifXEntry 18 }
- confModuleCompliance == { ifCompliance3 }
- confLevel == 'otherConf(2)'
- confVarSyntax == 'SYNTAX DisplayString (SIZE(0..32))'
8. Open Issues
Conformance information for INDEX components
Should the confTable be modified to support entries for INDEX
components, which are not actually represented in MODULE-COMPLIANCE
Expires December 1, 2002 [Page 13]
Internet Draft Conformance MIB May 31, 2002
macros?
Default confTable behavior
Should the absence of a confEntry indicate any particular
semantics?
Missing conformance sections
MODULE-COMPLIANCE sections are not strictly mandatory, but this MIB
gets around this corner-case (and the missing conformance
information for INDEX components) by describing the conformance
information that would be present in an information module, even if
that information is not actually present. Are there any problems
with this approach?
9. Normative References
[RFC1905]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Protocol Operations for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research,
Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[RFC1906]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco
Systems, Inc., Dover Beach Consulting, Inc., International Network
Services, January 1996.
[RFC2026]
Bradner, S., "The Internet Standards Process -- Revision 3", RFC
2026, Harvard University, October, 1996.
[RFC2119]
S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels" RFC 2119, Harvard University, March 1997.
[RFC2571]
Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2571, Cabletron
Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, April
1999.
Expires December 1, 2002 [Page 14]
Internet Draft Conformance MIB May 31, 2002
[RFC2572]
Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, SNMP Research, Inc., Cabletron Systems,
Inc., BMC Software, Inc., IBM T. J. Watson Research, April 1999.
[RFC2573]
Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC
2573, SNMP Research, Inc., Secure Computing Corporation, Cisco
Systems, April 1999.
[RFC2574]
Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for
version 3 of the Simple Network Management Protocol (SNMPv3)", RFC
2574, IBM T. J. Watson Research, April 1999.
[RFC2575]
Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", RFC 2575, IBM T. J. Watson Research, BMC Software, Inc.,
Cisco Systems, Inc., April 1999.
[RFC2578]
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser, "Structure of Management Information Version 2
(SMIv2)", RFC 2578, STD 58, Cisco Systems, SNMPinfo, TU
Braunschweig, SNMP Research, First Virtual Holdings, International
Network Services, April 1999.
[RFC2579]
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD
58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First
Virtual Holdings, International Network Services, April 1999.
[RFC2580]
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580,
STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research,
First Virtual Holdings, International Network Services, April 1999.
10. Informative References
[RFC1155]
Rose, M., and K. McCloghrie, "Structure and Identification of
Expires December 1, 2002 [Page 15]
Internet Draft Conformance MIB May 31, 2002
Management Information for TCP/IP-based Internets", RFC 1155,
Performance Systems International, Hughes LAN Systems, May 1990.
[RFC1157]
Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
Management Protocol", RFC 1157, SNMP Research, Performance Systems
International, Performance Systems International, MIT Laboratory
for Computer Science, May 1990.
[RFC1212]
Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212,
Performance Systems International, Hughes LAN Systems, March 1991.
[RFC1215]
M. Rose, "A Convention for Defining Traps for use with the SNMP",
RFC 1215, Performance Systems International, March 1991.
[RFC1901]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901,
SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting,
Inc., International Network Services, January 1996.
[RFC1907]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Management Information Base for Version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC 1907, SNMP
Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[RFC2233]
McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB Using
SMIv2", RFC 2233, Cisco Systems, FTP Software, November, 1997.
[RFC2570]
Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to
Version 3 of the Internet-standard Network Management Framework",
RFC 2570, SNMP Research, Inc., TIS Labs at Network Associates,
Inc., Ericsson, Cisco Systems, April 1999.
[RFC2863]
McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB", RFC
2863, Cisco Systems, Argon Networks, June, 2000.
Expires December 1, 2002 [Page 16]
Internet Draft Conformance MIB May 31, 2002
11. Security Considerations
There are no managed objects defined in this MIB that have a MAX-ACCESS
clause of read-write and/or read-create.
There are no managed objects in this MIB that may contain sensitive
information.
SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPSec), even then, there is no
control as to who on the secure network is allowed to access and GET the
objects in this MIB.
It is recommended that the implementors consider the security features
as provided by the SNMPv3 framework. Specifically, the use of the User-
based Security Model RFC 2574 [RFC2574] and the View-based Access
Control Model RFC 2575 [RFC2575] is recommended.
It is then a customer/user responsibility to ensure that the SNMP entity
giving access to an instance of this MIB, is properly configured to give
access to the objects only to those principals (users) that have
legitimate rights to GET them.
12. Author's Address
Andy Bierman
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA USA 95134
Phone: +1 408-527-3711
Email: abierman@cisco.com
Expires December 1, 2002 [Page 17]
Internet Draft Conformance MIB May 31, 2002
13. Full 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.
Expires December 1, 2002 [Page 18]