As per Relevance of the word standard, we have this rfc below:
Network Working Group SNMPv2 Working
Request for Comments: 1908 J.
Obsoletes: 1452 SNMP Research, Inc
Category: Standards Track K.
Cisco Systems, Inc
M.
Dover Beach Consulting, Inc
S.
International Network
January 1996
Coexistence between Version 1 and Version 2 of
Internet-standard Network Management
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Table of
1. Introduction ................................................ 2
2. Management Information ...................................... 2
2.1 Object Definitions ......................................... 3
2.2 Trap Definitions ........................................... 5
2.3 Compliance Statements ...................................... 5
2.4 Capabilities Statements .................................... 6
3 Protocol Operations .......................................... 6
3.1 Proxy Agent Behavior ....................................... 6
3.1.1 SNMPv2 -> SNMPv1 ......................................... 7
3.1.2 SNMPv1 -> SNMPv2 ......................................... 7
3.2 Bi-lingual Manager Behavior ................................ 8
4. Security Considerations ..................................... 8
5. Editor's Address ............................................ 8
6. Acknowledgements ............................................ 8
7. References .................................................. 9
SNMPv2 Working Group Standards Track [Page 1]
RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996
1.
The purpose of this document is to describe coexistence
version 2 of the Internet-standard Network Management Framework [1-
6], termed the SNMP version 2 framework (SNMPv2), and the
Internet-standard Network Management Framework (SNMPv1),
consists of these three documents
STD 16, RFC 1155 [7] which defines the Structure of
Information (SMI), the mechanisms used for describing and
objects for the purpose of management
STD 16, RFC 1212 [8] which defines a more concise
mechanism, which is wholly consistent with the SMI
STD 15, RFC 1157 [9] which defines the Simple Network
Protocol (SNMP), the protocol used for network access to
objects
2. Management
The SNMPv2 approach towards describing collections of managed
is nearly a proper superset of the approach defined in the Internet
standard Network Management Framework. For example, both
use ASN.1 [10] as the basis for a formal descriptive notation
Indeed, one might note that the SNMPv2 approach largely codifies
existing practice for defining MIB modules, based on
experience with the current framework
The SNMPv2 documents which deal with information modules are
Structure of Management Information for SNMPv2 [1], which
concise notations for describing information modules,
objects and notifications
Textual Conventions for SNMPv2 [2], which defines a
notation for describing textual conventions, and also defines
initial conventions; and
Conformance Statements for SNMPv2 [3], which defines
notation for describing compliance and capabilities statements
The following sections consider the three areas: MIB modules
compliance statements, and capabilities statements
MIB modules defined using the current framework may continue to
used with the SNMPv2 protocol. However, for the MIB modules
conform to the SNMPv2 framework, the following changes are required
SNMPv2 Working Group Standards Track [Page 2]
RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996
2.1. Object
In general, conversion of a MIB module does not require
deprecation of the objects contained therein. Only if the
of an object truly changes should deprecation be performed
(1) The IMPORTS statement must reference SNMPv2-SMI, instead
RFC1155-SMI and RFC-1212.
(2) The MODULE-IDENTITY macro must be invoked immediately after
IMPORTs statement
(3) For any descriptor which contains the hyphen character, the
character is removed
(4) For any label for a named-number enumeration which contains
hyphen character, the hyphen character is removed
(5) For any object with an integer-valued SYNTAX clause, in which
corresponding INTEGER does not have a range restriction (i.e.,
INTEGER has neither a defined set of named-number enumerations
an assignment of lower- and upper-bounds on its value), the
must have the value of its SYNTAX clause changed to Integer32.
(6) For any object with a SYNTAX clause value of an enumerated INTEGER
the hyphen character is removed from any named-number labels
contain the hyphen character
(7) For any object with a SYNTAX clause value of Counter, the
must have the value of its SYNTAX clause changed to Counter32.
(8) For any object with a SYNTAX clause value of Gauge, the object
have the value of its SYNTAX clause changed to Gauge32.
(9) For all objects, the ACCESS clause must be replaced by a MAX-
clause. The value of the MAX-ACCESS clause is the same as that
the ACCESS clause unless some other value makes "protocol sense"
the maximal level of access for the object. In particular,
types for which instances can be explicitly created by a
set operation, will have a MAX-ACCESS clause of "read-create".
the value of the ACCESS clause is "write-only", then the value
the MAX-ACCESS clause is "read-write", and the DESCRIPTION
notes that reading this object will result implementation-
results
(10) For all objects, if the value of the STATUS clause is "mandatory",
the value must be replaced with "current".
SNMPv2 Working Group Standards Track [Page 3]
RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996
(11) For all objects, if the value of the STATUS clause is "optional",
the value must be replaced with "obsolete".
(12) For any object not containing a DESCRIPTION clause, the object
have a DESCRIPTION clause defined
(13) For any object corresponding to a conceptual row which does
have an INDEX clause, the object must have either an INDEX
or an AUGMENTS clause defined
(14) For any object with an INDEX clause that references an object
a syntax of NetworkAddress, the value of the STATUS clause of
objects is changed to "obsolete".
(15) For any object containing a DEFVAL clause with an OBJECT
value which is expressed as a collection of sub-identifiers,
the value to reference a single ASN.1 identifier
Other changes are desirable, but not necessary
(1) Creation and deletion of conceptual rows is inconsistent using
current framework. The SNMPv2 framework corrects this. As such
if the MIB module undergoes review early in its lifetime, and
contains conceptual tables which allow creation and deletion
conceptual rows, then it may be worthwhile to deprecate the
relating to those tables and replace them with objects
using the new approach
(2) For any object with a string-valued SYNTAX clause, in which
corresponding OCTET STRING does not have a size restriction (i.e.,
the OCTET STRING has no assignment of lower- and upper-bounds
its length), one might consider defining the bounds for the size
the object
(3) For all textual conventions informally defined in the MIB module
one might consider redefining those conventions using the TEXTUAL
CONVENTION macro. Such a change would not necessitate
objects previously defined using an informal textual convention
(4) For any object which represents a measurement in some kind
units, one might consider adding a UNITS clause to the
of that object
(5) For any conceptual row which is an extension of another
row, i.e., for which subordinate columnar objects both exist
are identified via the same semantics as the other conceptual row
one might consider using an AUGMENTS clause in place of the
clause for the object corresponding to the conceptual row which
SNMPv2 Working Group Standards Track [Page 4]
RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996
an extension
Finally, when encountering common errors in SNMPv1 MIB modules
(1) For any non-columnar object that is instanced as if it
immediately subordinate to a conceptual row, the value of
STATUS clause of that object is changed to "obsolete".
(2) For any conceptual row object that is not contained
subordinate to a conceptual table, the value of the STATUS
of that object (and all subordinate objects) is changed
"obsolete".
2.2. Trap
If a MIB module is changed to conform to the SNMPv2 framework,
each occurrence of the TRAP-TYPE macro must be changed to
corresponding invocation of the NOTIFICATION-TYPE macro
(1) The IMPORTS statement must not reference RFC-1215.
(2) The ENTERPRISES clause must be removed
(3) The VARIABLES clause must be renamed to the OBJECTS clause
(4) The STATUS clause must be added
(5) The value of an invocation of the NOTIFICATION-TYPE macro is
OBJECT IDENTIFIER, not an INTEGER, and must be changed accordingly
Specifically, if the value of the ENTERPRISE clause is not 'snmp
then the value of the invocation is the value of the
clause extended with two sub-identifiers, the first of which
the value 0, and the second has the value of the invocation of
TRAP-TYPE
2.3. Compliance
For those information modules which are "standard", a
invocation of the MODULE-COMPLIANCE macro must be included within
information module (or in a companion information module), and
commentary text in the information module which relates to
must be removed. Typically this editing can occur when
information module undergoes review
SNMPv2 Working Group Standards Track [Page 5]
RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996
2.4. Capabilities
In the current framework, the informational document [11] uses
MODULE-CONFORMANCE macro to describe an agent's capabilities
respect to one or more MIB modules. Converting such a
for use with the SNMPv2 framework requires these changes
(1) Use the macro name AGENT-CAPABILITIES instead of MODULE
CONFORMANCE
(2) The STATUS clause must be added
(3) For all occurrences of the CREATION-REQUIRES clause, note
slight change in semantics, and omit this clause if appropriate
In order to ease the coexistence between SNMPv1 and SNMPv2,
groups defined in an SNMPv1 MIB module may be referenced by
INCLUDES clause of an invocation of the AGENT-CAPABILITIES macro
upon encountering a reference to an OBJECT IDENTIFIER subtree
in an SNMPv1 MIB module, all leaf objects which are subordinate
the subtree and have a STATUS clause value of mandatory are deemed
be INCLUDEd. (Note that this method is ambiguous when
revisions of a SNMPv1 MIB have different sets of mandatory
under the same subtree; in such cases, the only solution is
rewrite the MIB using the SNMPv2 SMI in order to define the
groups unambiguously.)
3. Protocol
The SNMPv2 documents which deal with protocol operations are
Protocol Operations for SNMPv2 [4], which defines the syntax
semantics of the operations conveyed by the protocol; and
Transport Mappings for SNMPv2 [5], which defines how the
operations are carried over different transport services
The following section considers two areas: the proxy
between a SNMPv2 entity and a SNMPv1 agent; and, the behavior
"bi-lingual" protocol entities acting in a manager role
3.1. Proxy Agent
To achieve coexistence at the protocol-level, a proxy mechanism
be used. A SNMPv2 entity acting in an agent role may be
and configured to act in the role of a proxy agent
SNMPv2 Working Group Standards Track [Page 6]
RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996
3.1.1. SNMPv2 -> SNMPv
When converting requests from a SNMPv2 entity acting in a
role into requests sent to a SNMPv1 entity acting in an agent role
(1) If a GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU
received, then it is passed unaltered by the proxy agent
(2) If a GetBulkRequest-PDU is received, the proxy agent sets the non
repeaters and max-repetitions fields to zero, and sets the tag
the PDU to GetNextRequest-PDU
3.1.2. SNMPv1 -> SNMPv
When converting responses received from a SNMPv1 entity acting in
agent role into responses sent to a SNMPv2 entity acting in a
role
(1) If a GetResponse-PDU is received, then it is passed unaltered
the proxy agent. Note that even though a SNMPv2 entity will
generate a Response-PDU with a error-status field having a value
`noSuchName', `badValue', or `readOnly', the proxy agent must
change this field. This allows the SNMPv2 entity acting in
manager role to interpret the response correctly
If a GetResponse-PDU is received with an error-status field
a value of `tooBig', the proxy agent will remove the contents
the variable-bindings field before propagating the response.
that even though a SNMPv2 entity will never generate a `tooBig'
response to a GetBulkRequest-PDU, the proxy agent must
such a response
(2) If a Trap-PDU is received, then it is mapped into a SNMPv2-Trap
PDU. This is done by prepending onto the variable-bindings
two new bindings: sysUpTime.0 [6], which takes its value from
timestamp field of the Trap-PDU; and, snmpTrapOID.0 [6], which
calculated thusly: if the value of generic-trap field
`enterpriseSpecific', then the value used is the concatenation
the enterprise field from the Trap-PDU with two additional sub
identifiers, `0', and the value of the specific-trap field
otherwise, the value of the corresponding trap defined in [6]
used. (For example, if the value of the generic-trap field
`coldStart', then the coldStart trap [6] is used.) Then, one
binding is appended onto the variable-bindings field
snmpTrapEnterprise.0 [6], which takes its value from the
field of the Trap-PDU. The destinations for the SNMPv2-Trap-
are determined in an implementation-dependent fashion by the
agent
SNMPv2 Working Group Standards Track [Page 7]
RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996
3.2. Bi-lingual Manager
To achieve coexistence at the protocol-level, a protocol
acting in a manager role might support both SNMPv1 and SNMPv2.
a management application needs to contact a protocol entity acting
an agent role, the entity acting in a manager role consults a
database to select the correct management protocol to use
In order to provide transparency to management applications,
entity acting in a manager role must map operations as if it
acting as a proxy agent
4. Security
Security issues are not discussed in this memo
5. Editor's
Keith
Cisco Systems, Inc
170 West Tasman
San Jose, CA 95134-1706
Phone: +1 408 526 5260
EMail: kzm@cisco.
6.
This document is the result of significant work by the four
contributors
Jeffrey D. Case (SNMP Research, case@snmp.com
Keith McCloghrie (Cisco Systems, kzm@cisco.com
Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us
Steven Waldbusser (International Network Services, stevew@uni.ins.com
In addition, the contributions of the SNMPv2 Working Group
acknowledged. In particular, a special thanks is extended for
contributions of
Alexander I. Alten (Novell
Dave Arneson (Cabletron
Uri Blumenthal (IBM
Doug Book (Chipcom
Kim Curran (Bell-Northern Research
Jim Galvin (Trusted Information Systems
Maria Greene (Ascom Timeplex
SNMPv2 Working Group Standards Track [Page 8]
RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996
Iain Hanson (Digital
Dave Harrington (Cabletron
Nguyen Hien (IBM
Jeff Johnson (Cisco Systems
Michael Kornegay (Object Quest
Deirdre Kostick (AT&T Bell Labs
David Levi (SNMP Research
Daniel Mahoney (Cabletron
Bob Natale (ACE*COMM
Brian O'Keefe (Hewlett Packard
Andrew Pearson (SNMP Research
Dave Perkins (Peer Networks
Randy Presuhn (Peer Networks
Aleksey Romanov (Quality Quorum
Shawn Routhier (Epilogue
Jon Saperia (BGS Systems
Bob Stewart (Cisco Systems, bstewart@cisco.com),
Kaj Tesink (Bellcore
Glenn Waters (Bell-Northern Research
Bert Wijnen (IBM
7.
[1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
S. Waldbusser, "Structure of Management Information for Version 2
of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996.
[2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
S. Waldbusser, "Textual Conventions for Version 2 of the
Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
S. Waldbusser, "Conformance Statements for Version 2 of the
Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
[4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
S. Waldbusser, "Protocol Operations for Version 2 of the
Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
S. Waldbusser, "Transport Mappings for Version 2 of the
Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
[6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
S. Waldbusser, "Management Information Base for Version 2 of
Simple Network Management Protocol (SNMPv2)", RFC 1907,
January 1996.
SNMPv2 Working Group Standards Track [Page 9]
RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996
[7] Rose, M., and K. McCloghrie, "Structure and Identification
Management Information for TCP/IP-based internets", STD 16,
1155, May 1990.
[8] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16,
RFC 1212, March 1991.
[9] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Management Protocol", STD 15, RFC 1157, SNMP Research,
Systems International, MIT Laboratory for Computer Science,
1990.
[10] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization.
Standard 8824, (December, 1987).
[11] McCloghrie, K., and M. Rose, "A Convention for Describing SNMP
based Agents", RFC 1303, Hughes LAN Systems, Dover
Consulting, Inc., February 1992.
SNMPv2 Working Group Standards Track [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
