The value "read-write" indicates that read and write access make
"protocol sense", but create does not. The value "read-create"
indicates that read, write and create access make "protocol sense".
The value "not-accessible" indicates an auxiliary object (see Section
7.7). The value "accessible-for-notify" indicates an object which is
accessible only via a notification (e.g., snmpTrapOID [5]).
These values are ordered, from least to greatest: "not-accessible",
"accessible-for-notify", "read-only", "read-write", "read-create".
If any columnar object in a conceptual row has "read-create" as its
maximal level of access, then no other columnar object of the same
conceptual row may have a maximal access of "read-write". (Note that
"read-create" is a superset of "read-write".)
RFC2578 SMIv2 April 1999
7.4. Mapping of the STATUS clause
The STATUS clause, which must be present, indicates whether this
definition is current or historic.
The value "current" means that the definition is current and valid.
The value "obsolete" means the definition is obsolete and should not
be implemented and/or can be removed if previously implemented.
While the value "deprecated" also indicates an obsolete definition,
it permits new/continued implementation in order to foster
interoperability with older/existing implementations.
7.5. Mapping of the DESCRIPTION clause
The DESCRIPTION clause, which must be present, contains a textual
definition of that object which provides all semantic definitions
necessary for implementation, and should embody any information which
would otherwise be communicated in any ASN.1 commentary annotations
associated with the object.
7.6. Mapping of the REFERENCE clause
The REFERENCE clause, which need not be present, contains a textual
cross-reference to some other document, either another information
module which defines a related assignment, or some other document
which provides additional information relevant to this definition.
7.7. Mapping of the INDEX clause
The INDEX clause, which must be present if that object corresponds to
a conceptual row (unless an AUGMENTS clause is present instead), and
must be absent otherwise, defines instance identification information
for the columnar objects subordinate to that object.
The instance identification information in an INDEX clause must
specify object(s) such that value(s) of those object(s) will
unambiguously distinguish a conceptual row. The objects can be
columnar objects from the same and/or another conceptual table, but
must not be scalar objects. Multiple occurrences of the same object
in a single INDEX clause is strongly discouraged.
The syntax of the objects in the INDEX clause indicate how to form
the instance-identifier:
(1) integer-valued (i.e., having INTEGER as its underlying primitive
type): a single sub-identifier taking the integer value (this
works only for non-negative integers);
RFC2578 SMIv2 April 1999
(2) string-valued, fixed-length strings (or variable-length preceded by
the IMPLIED keyword): `n' sub-identifiers, where `n' is the length
of the string (each octet of the string is encoded in a separate
sub-identifier);
(3) string-valued, variable-length strings (not preceded by the IMPLIED
keyword): `n+1' sub-identifiers, where `n' is the length of the
string (the first sub-identifier is `n' itself, following this,
each octet of the string is encoded in a separate sub-identifier);
(4) object identifier-valued (when preceded by the IMPLIED keyword):
`n' sub-identifiers, where `n' is the number of sub-identifiers in
the value (each sub-identifier of the value is copied into a
separate sub-identifier);
(5) object identifier-valued (when not preceded by the IMPLIED
keyword): `n+1' sub-identifiers, where `n' is the number of sub-
identifiers in the value (the first sub-identifier is `n' itself,
following this, each sub-identifier in the value is copied);
(6) IpAddress-valued: 4 sub-identifiers, in the familiar a.b.c.d
notation.
Note that the IMPLIED keyword can only be present for an object
having a variable-length syntax (e.g., variable-length strings or
object identifier-valued objects), Further, the IMPLIED keyword can
only be associated with the last object in the INDEX clause.
Finally, the IMPLIED keyword may not be used on a variable-length
string object if that string might have a value of zero-length.
Since a single value of a Counter has (in general) no information
content (see section 7.1.6 and 7.1.10), objects defined using the
syntax, Counter32 or Counter64, must not be specified in an INDEX
clause. If an object defined using the BITS construct is used in an
INDEX clause, it is considered a variable-length string.
Instances identified by use of integer-valued objects should be
numbered starting from one (i.e., not from zero). The use of zero as
a value for an integer-valued index object should be avoided, except
in special cases.
Objects which are both specified in the INDEX clause of a conceptual
row and also columnar objects of the same conceptual row are termed
auxiliary objects. The MAX-ACCESS clause for auxiliary objects is
"not-accessible", except in the following circumstances:
RFC2578 SMIv2 April 1999
(1) within a MIB module originally written to conform to SMIv1, and
later converted to conform to SMIv2; or
(2) a conceptual row must contain at least one columnar object which is
not an auxiliary object. In the event that all of a conceptual
row's columnar objects are also specified in its INDEX clause, then
one of them must be accessible, i.e., have a MAX-ACCESS clause of
"read-only". (Note that this situation does not arise for a
conceptual row allowing create access, since such a row will have a
status column which will not be an auxiliary object.)
Note that objects specified in a conceptual row's INDEX clause need
not be columnar objects of that conceptual row. In this situation,
the DESCRIPTION clause of the conceptual row must include a textual
explanation of how the objects which are included in the INDEX clause
but not columnar objects of that conceptual row, are used in uniquely
identifying instances of the conceptual row's columnar objects.
7.8. Mapping of the AUGMENTS clause
The AUGMENTS clause, which must not be present unless the object
corresponds to a conceptual row, is an alternative to the INDEX
clause. Every object corresponding to a conceptual row has either an
INDEX clause or an AUGMENTS clause.
If an object corresponding to a conceptual row has an INDEX clause,
that row is termed a base conceptual row; alternatively, if the
object has an AUGMENTS clause, the row is said to be a conceptual row
augmentation, where the AUGMENTS clause names the object
corresponding to the base conceptual row which is augmented by this
conceptual row augmentation. (Thus, a conceptual row augmentation
cannot itself be augmented.) Instances of subordinate columnar
objects of a conceptual row augmentation are identified according to
the INDEX clause of the base conceptual row corresponding to the
object named in the AUGMENTS clause. Further, instances of
subordinate columnar objects of a conceptual row augmentation exist
according to the same semantics as instances of subordinate columnar
objects of the base conceptual row being augmented. As such, note
that creation of a base conceptual row implies the correspondent
creation of any conceptual row augmentations.
For example, a MIB designer might wish to define additional columns
in an "enterprise-specific" MIB which logically extend a conceptual
row in a "standard" MIB. The "standard" MIB definition of the
conceptual row would include the INDEX clause and the "enterprise-
specific" MIB would contain the definition of a conceptual row using
the AUGMENTS clause. On the other hand, it would be incorrect to use
the AUGMENTS clause for the relationship between RFC2233's ifTable
RFC2578 SMIv2 April 1999
and the many media-specific MIBs which extend it for specific media
(e.g., the dot3Table in RFC2358), since not all interfaces are of
the same media.
Note that a base conceptual row may be augmented by multiple
conceptual row augmentations.
7.8.1. Relation between INDEX and AUGMENTS clauses
When defining instance identification information for a conceptual
table:
(1) If there is a one-to-one correspondence between the conceptual rows
of this table and an existing table, then the AUGMENTS clause
should be used.
(2) Otherwise, if there is a sparse relationship between the conceptual
rows of this table and an existing table, then an INDEX clause
should be used which is identical to that in the existing table.
For example, the relationship between RFC2233's ifTable and a
media-specific MIB which extends the ifTable for a specific media
(e.g., the dot3Table in RFC2358), is a sparse relationship.
(3) Otherwise, if no existing objects have the required syntax and
semantics, then auxiliary objects should be defined within the
conceptual row for the new table, and those objects should be used
within the INDEX clause for the conceptual row.
7.9. Mapping of the DEFVAL clause
The DEFVAL clause, which need not be present, defines an acceptable
default value which may be used at the discretion of an agent when an
object instance is created. That is, the value is a "hint" to
implementors.
During conceptual row creation, if an instance of a columnar object
is not present as one of the operands in the correspondent management
protocol set operation, then the value of the DEFVAL clause, if
present, indicates an acceptable default value that an agent might
use (especially for a read-only object).
Note that with this definition of the DEFVAL clause, it is
appropriate to use it for any columnar object of a read-create table.
It is also permitted to use it for scalar objects dynamically created
by an agent, or for columnar objects of a read-write table
dynamically created by an agent.
RFC2578 SMIv2 April 1999
The value of the DEFVAL clause must, of course, correspond to the
SYNTAX clause for the object. If the value is an OBJECT IDENTIFIER,
then it must be expressed as a single ASN.1 identifier, and not as a
collection of sub-identifiers.
Note that if an operand to the management protocol set operation is
an instance of a read-only object, then the error `notWritable' [6]
will be returned. As such, the DEFVAL clause can be used to provide
an acceptable default value that an agent might use.
By way of example, consider the following possible DEFVAL clauses:
ObjectSyntax DEFVAL clause
---------------- ------------
Integer32 DEFVAL { 1 }
-- same for Gauge32, TimeTicks, Unsigned32
INTEGER DEFVAL { valid } -- enumerated value
OCTET STRING DEFVAL { 'ffffffffffff'H }
DisplayString DEFVAL { "SNMP agent" }
IpAddress DEFVAL { 'c0210415'H } -- 192.33.4.21
OBJECT IDENTIFIER DEFVAL { sysDescr }
BITS DEFVAL { { primary, secondary } }
-- enumerated values that are set
BITS DEFVAL { { } }
-- no enumerated values are set
A binary string used in a DEFVAL clause for an OCTET STRING must be
either an integral multiple of eight or zero bits in length;
similarly, a hexadecimal string must be an even number of hexadecimal
digits. The value of a character string used in a DEFVAL clause must
not contain tab characters or line terminator characters.
Object types with SYNTAX of Counter32 and Counter64 may not have
DEFVAL clauses, since they do not have defined initial values.
However, it is recommended that they be initialized to zero.
7.10. Mapping of the OBJECT-TYPE value
The value of an invocation of the OBJECT-TYPE macro is the name of
the object, which is an OBJECT IDENTIFIER, an administratively
assigned name.
When an OBJECT IDENTIFIER is assigned to an object:
(1) If the object corresponds to a conceptual table, then only a single
assignment, that for a conceptual row, is present immediately
beneath that object. The administratively assigned name for the
conceptual row object is derived by appending a sub-identifier of
RFC2578 SMIv2 April 1999
"1" to the administratively assigned name for the conceptual table.
(2) If the object corresponds to a conceptual row, then at least one
assignment, one for each column in the conceptual row, is present
beneath that object. The administratively assigned name for each
column is derived by appending a unique, positive sub-identifier to
the administratively assigned name for the conceptual row.
(3) Otherwise, no other OBJECT IDENTIFIERs which are subordinate to the
object may be assigned.
Note that the final sub-identifier of any administratively assigned
name for an object shall be positive. A zero-valued final sub-
identifier is reserved for future use.
7.11. Usage Example
Consider how one might define a conceptual table and its
subordinates. (This example uses the RowStatus textual convention
defined in [3].)
evalSlot OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The index number of the first unassigned entry in the
evaluation table, or the value of zero indicating that
all entries are assigned.
A management station should create new entries in the
evaluation table using this algorithm: first, issue a
management protocol retrieval operation to determine the
value of evalSlot; and, second, issue a management
protocol set operation to create an instance of the
evalStatus object setting its value to createAndGo(4) or
createAndWait(5). If this latter operation succeeds,
then the management station may continue modifying the
instances corresponding to the newly created conceptual
row, without fear of collision with other management
stations."
::= { eval 1 }
evalTable OBJECT-TYPE
SYNTAX SEQUENCE OF EvalEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
RFC2578 SMIv2 April 1999
"The (conceptual) evaluation table."
::= { eval 2 }
evalEntry OBJECT-TYPE
SYNTAX EvalEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) in the evaluation table."
INDEX { evalIndex }
::= { evalTable 1 }
EvalEntry ::=
SEQUENCE {
evalIndex Integer32,
evalString DisplayString,
evalValue Integer32,
evalStatus RowStatus
}
evalIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The auxiliary variable used for identifying instances of
the columnar objects in the evaluation table."
::= { evalEntry 1 }
evalString OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The string to evaluate."
::= { evalEntry 2 }
evalValue OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when evalString was last evaluated, or zero if
no such value is available."
DEFVAL { 0 }
::= { evalEntry 3 }
evalStatus OBJECT-TYPE
RFC2578 SMIv2 April 1999
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status column used for creating, modifying, and
deleting instances of the columnar objects in the
evaluation table."
DEFVAL { active }
::= { evalEntry 4 }
8. Mapping of the NOTIFICATION-TYPE macro
The NOTIFICATION-TYPE macro is used to define the information
contained within an unsolicited transmission of management
information (i.e., within either a SNMPv2-Trap-PDU or InformRequest-
PDU). It should be noted that the expansion of the NOTIFICATION-TYPE
macro is something which conceptually happens during implementation
and not during run-time.
8.1. Mapping of the OBJECTS clause
The OBJECTS clause, which need not be present, defines an ordered
sequence of MIB object types. One and only one object instance for
each occurrence of each object type must be present, and in the
specified order, in every instance of the notification. If the same
object type occurs multiple times in a notification's ordered
sequence, then an object instance is present for each of them. An
object type specified in this clause must not have an MAX-ACCESS
clause of "not-accessible". The notification's DESCRIPTION clause
must specify the information/meaning conveyed by each occurrence of
each object type in the sequence. The DESCRIPTION clause must also
specify which object instance is present for each object type in the
notification.
Note that an agent is allowed, at its own discretion, to append as
many additional objects as it considers useful to the end of the
notification (i.e., after the objects defined by the OBJECTS clause).
8.2. Mapping of the STATUS clause
The STATUS clause, which must be present, indicates whether this
definition is current or historic.
The value "current" means that the definition is current and valid.
The value "obsolete" means the definition is obsolete and should not
be implemented and/or can be removed if previously implemented.
While the value "deprecated" also indicates an obsolete definition,
it permits new/continued implementation in order to foster
RFC2578 SMIv2 April 1999
interoperability with older/existing implementations.
8.3. Mapping of the DESCRIPTION clause
The DESCRIPTION clause, which must be present, contains a textual
definition of the notification which provides all semantic
definitions necessary for implementation, and should embody any
information which would otherwise be communicated in any ASN.1
commentary annotations associated with the notification. In
particular, the DESCRIPTION clause should document which instances of
the objects mentioned in the OBJECTS clause should be contained
within notifications of this type.
8.4. Mapping of the REFERENCE clause
The REFERENCE clause, which need not be present, contains a textual
cross-reference to some other document, either another information
module which defines a related assignment, or some other document
which provides additional information relevant to this definition.
8.5. Mapping of the NOTIFICATION-TYPE value
The value of an invocation of the NOTIFICATION-TYPE macro is the name
of the notification, which is an OBJECT IDENTIFIER, an
administratively assigned name. In order to achieve compatibility
with SNMPv1 traps, both when converting SMIv1 information modules
to/from this SMI, and in the procedures employed by multi-lingual
systems and proxy forwarding applications, the next to last sub-
identifier in the name of any newly-defined notification must have
the value zero.
Sections 4.2.6 and 4.2.7 of [6] describe how the NOTIFICATION-TYPE
macro is used to generate a SNMPv2-Trap-PDU or InformRequest-PDU,
respectively.
8.6. Usage Example
Consider how a configuration change notification might be described:
entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 }
entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 }
entConfigChange NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"An entConfigChange trap is sent when the value of
entLastChangeTime changes. It can be utilized by an NMS to
trigger logical/physical entity table maintenance polls.
RFC2578 SMIv2 April 1999
An agent must not generate more than one entConfigChange
'trap-event' in a five second period, where a 'trap-event'
is the transmission of a single trap PDU to a list of
trap destinations. If additional configuration changes
occur within the five second 'throttling' period, then
these trap-events should be suppressed by the agent. An
NMS should periodically check the value of
entLastChangeTime to detect any missed entConfigChange
trap-events, e.g. due to throttling or transmission loss."
::= { entityMIBTrapPrefix 1 }
According to this invocation, the notification authoritatively
identified as
{ entityMIBTrapPrefix 1 }
is used to report a particular type of configuration change.
9. Refined Syntax
Some macros have clauses which allows syntax to be refined,
specifically: the SYNTAX clause of the OBJECT-TYPE macro, and the
SYNTAX/WRITE-SYNTAX clauses of the MODULE-COMPLIANCE and AGENT-
CAPABILITIES macros [2]. However, not all refinements of syntax are
appropriate. In particular, the object's primitive or application
type must not be changed.
Further, the following restrictions apply:
Restrictions to Refinement of
object syntax range enumeration size
----------------- ----- ----------- ----
INTEGER (1) (2) -
Integer32 (1) - -
Unsigned32 (1) - -
OCTET STRING - - (3)
OBJECT IDENTIFIER - - -
BITS - (2) -
IpAddress - - -
Counter32 - - -
Counter64 - - -
Gauge32 (1) - -
TimeTicks - - -
where:
RFC2578 SMIv2 April 1999
(1) the range of permitted values may be refined by raising the lower-
bounds, by reducing the upper-bounds, and/or by reducing the
alternative value/range choices;
(2) the enumeration of named-values may be refined by removing one or
more named-values (note that for BITS, a refinement may cause the
enumerations to no longer be contiguous); or,
(3) the size in octets of the value may be refined by raising the
lower-bounds, by reducing the upper-bounds, and/or by reducing the
alternative size choices.
No other types of refinements can be specified in the SYNTAX clause.
However, the DESCRIPTION clause is available to specify additional
restrictions which can not be expressed in the SYNTAX clause.
Further details on (and examples of) sub-typing are provided in
Appendix A.
10. Extending an Information Module
As experience is gained with an information module, it may be
desirable to revise that information module. However, changes are
not allowed if they have any potential to cause interoperability
problems "over the wire" between an implementation using an original
specification and an implementation using an updated
specification(s).
For any change, the invocation of the MODULE-IDENTITY macro must be
updated to include information about the revision: specifically,
updating the LAST-UPDATED clause, adding a pair of REVISION and
DESCRIPTION clauses (see section 5.5), and making any necessary
changes to existing clauses, including the ORGANIZATION and CONTACT-
INFO clauses.
Note that any definition contained in an information module is
available to be IMPORT-ed by any other information module, and is
referenced in an IMPORTS clause via the module name. Thus, a module
name should not be changed. Specifically, the module name (e.g.,
"FIZBIN-MIB" in the example of Section 5.7) should not be changed
when revising an information module (except to correct typographical
errors), and definitions should not be moved from one information
module to another.
Also note that obsolete definitions must not be removed from MIB
modules since their descriptors may still be referenced by other
information modules, and the OBJECT IDENTIFIERs used to name them
must never be re-assigned.
RFC2578 SMIv2 April 1999
10.1. Object Assignments
If any non-editorial change is made to any clause of a object
assignment, then the OBJECT IDENTIFIER value associated with that
object assignment must also be changed, along with its associated
descriptor.
10.2. Object Definitions
An object definition may be revised in any of the following ways:
(1) A SYNTAX clause containing an enumerated INTEGER may have new
enumerations added or existing labels changed. Similarly, named
bits may be added or existing labels changed for the BITS
construct.
(2) The value of a SYNTAX clause may be replaced by a textual
convention, providing the textual convention is defined to use the
same primitive ASN.1 type, has the same set of values, and has
identical semantics.
(3) A STATUS clause value of "current" may be revised as "deprecated"
or "obsolete". Similarly, a STATUS clause value of "deprecated"
may be revised as "obsolete". When making such a change, the
DESCRIPTION clause should be updated to explain the rationale.
(4) A DEFVAL clause may be added or updated.
(5) A REFERENCE clause may be added or updated.
(6) A UNITS clause may be added.
(7) A conceptual row may be augmented by adding new columnar objects at
the end of the row, and making the corresponding update to the
SEQUENCE definition.
(8) Clarifications and additional information may be included in the
DESCRIPTION clause.
(9) Entirely new objects may be defined, named with previously
unassigned OBJECT IDENTIFIER values.
Otherwise, if the semantics of any previously defined object are
changed (i.e., if a non-editorial change is made to any clause other
than those specifically allowed above), then the OBJECT IDENTIFIER
value associated with that object must also be changed.
RFC2578 SMIv2 April 1999
Note that changing the descriptor associated with an existing object
is considered a semantic change, as these strings may be used in an
IMPORTS statement.
10.3. Notification Definitions
A notification definition may be revised in any of the following
ways:
(1) A REFERENCE clause may be added or updated.
(2) A STATUS clause value of "current" may be revised as "deprecated"
or "obsolete". Similarly, a STATUS clause value of "deprecated"
may be revised as "obsolete". When making such a change, the
DESCRIPTION clause should be updated to explain the rationale.
(3) A DESCRIPTION clause may be clarified.
Otherwise, if the semantics of any previously defined notification
are changed (i.e., if a non-editorial change is made to any clause
other those specifically allowed above), then the OBJECT IDENTIFIER
value associated with that notification must also be changed.
Note that changing the descriptor associated with an existing
notification is considered a semantic change, as these strings may be
used in an IMPORTS statement.
RFC2578 SMIv2 April 1999
11. Appendix A: Detailed Sub-typing Rules
11.1. Syntax Rules
The syntax rules for sub-typing are given below. Note that while
this syntax is based on ASN.1, it includes some extensions beyond
what is allowed in ASN.1, and a number of ASN.1 constructs are not
allowed by this syntax.
<integerSubType>
::= <empty>
| "(" <range> ["|" <range>]... ")"
<octetStringSubType>
::= <empty>
| "(" "SIZE" "(" <range> ["|" <range>]... ")" ")"
<range>
::= <value>
| <value> ".." <value>
<value>
::= "-" <number>
| <number>
| <hexString>
| <binString>
where:
<empty> is the empty string
<number> is a non-negative integer
<hexString> is a hexadecimal string (e.g., '0F0F'H)
<binString> is a binary string (e.g, '1010'B)
<range> is further restricted as follows:
- any <value> used in a SIZE clause must be non-negative.
- when a pair of values is specified, the first value
must be less than the second value.
- when multiple ranges are specified, the ranges may
not overlap but may touch. For example, (1..4 | 4..9)
is invalid, and (1..4 | 5..9) is valid.
- the ranges must be a subset of the maximum range of the
base type.
RFC2578 SMIv2 April 1999
11.2. Examples
Some examples of legal sub-typing:
Integer32 (-20..100)
Integer32 (0..100 | 300..500)
Integer32 (300..500 | 0..100)
Integer32 (0 | 2 | 4 | 6 | 8 | 10)
OCTET STRING (SIZE(0..100))
OCTET STRING (SIZE(0..100 | 300..500))
OCTET STRING (SIZE(0 | 2 | 4 | 6 | 8 | 10))
SYNTAX TimeInterval (0..100)
SYNTAX DisplayString (SIZE(0..32))
(Note the last two examples above are not valid in a TEXTUAL
CONVENTION, see [3].)
Some examples of illegal sub-typing:
Integer32 (150..100) -- first greater than second
Integer32 (0..100 | 50..500) -- ranges overlap
Integer32 (0 | 2 | 0 ) -- value duplicated
Integer32 (MIN..-1 | 1..MAX) -- MIN and MAX not allowed
Integer32 (SIZE (0..34)) -- must not use SIZE
OCTET STRING (0..100) -- must use SIZE
OCTET STRING (SIZE(-10..100)) -- negative SIZE
12. Security Considerations
This document defines a language with which to write and read
descriptions of management information. The language itself has no
security impact on the Internet.
13. Editors' Addresses
Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Phone: +1 408 526 5260
EMail: kzm@cisco.com
RFC2578 SMIv2 April 1999
David Perkins
SNMPinfo
3763 Benton Street
Santa Clara, CA 95051
USA
Phone: +1 408 221-8702
EMail: dperkins@snmpinfo.com
Juergen Schoenwaelder
TU Braunschweig
Bueltenweg 74/75
38106 Braunschweig
Germany
Phone: +49 531 391-3283
EMail: schoenw@ibr.cs.tu-bs.de
14. References
[1] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization. International
Standard 8824, (December, 1987).
[2] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.
and S. Waldbusser, "Conformance Statements for SMIv2", STD 58,
RFC2580, April 1999.
[3] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.
and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
RFC2579, April 1999.
[4] Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax Notation
One (ASN.1), International Organization for Standardization.
International Standard 8825, (December, 1987).
[5] The 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)", RFC1907, January
1996.
[6] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and
S. Waldbusser, "Protocol Operations for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC1905, January 1996.
RFC2578 SMIv2 April 1999
15. Full Copyright Statement
Copyright (C) The Internet Society (1999). 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."
McCloghrie, et al. Standards Track [Page 43]