draft-ietf-snmpv2-tc-ds-01.txt   draft-ietf-snmpv2-tc-ds-02.txt 
Textual Conventions Textual Conventions
for Version 2 of the for Version 2 of the
Simple Network Management Protocol (SNMPv2) Simple Network Management Protocol (SNMPv2)
19 March 1995 | 31 May 1995 |
draft-ietf-snmpv2-tc-ds-01.txt | draft-ietf-snmpv2-tc-ds-02.txt |
Jeffrey D. Case Jeffrey D. Case
SNMP Research, Inc. SNMP Research, Inc.
case@snmp.com case@snmp.com
Keith McCloghrie Keith McCloghrie
Cisco Systems, Inc. Cisco Systems, Inc.
kzm@cisco.com kzm@cisco.com
Marshall T. Rose Marshall T. Rose
skipping to change at page 3, line 43 skipping to change at page 3, line 43
initial set of textual conventions available to all MIB modules. initial set of textual conventions available to all MIB modules.
Objects defined using a textual convention are always encoded by means Objects defined using a textual convention are always encoded by means
of the rules that define their primitive type. However, textual of the rules that define their primitive type. However, textual
conventions often have special semantics associated with them. As such, conventions often have special semantics associated with them. As such,
an ASN.1 macro, TEXTUAL-CONVENTION, is used to concisely convey the an ASN.1 macro, TEXTUAL-CONVENTION, is used to concisely convey the
syntax and semantics of a textual convention. syntax and semantics of a textual convention.
For all textual conventions defined in an information module, the name For all textual conventions defined in an information module, the name
shall be unique and mnemonic, and shall not exceed 64 characters in shall be unique and mnemonic, and shall not exceed 64 characters in
length. All names used for the textual conventions defined in all length. (However, names longer than 32 characters are not recommended.) +
"standard" information modules shall be unique. All names used for the textual conventions defined in all "standard"
information modules shall be unique.
1.1. A Note on Terminology 1.1. A Note on Terminology
For the purpose of exposition, the original Internet-standard Network For the purpose of exposition, the original Internet-standard Network
Management Framework, as described in RFCs 1155, 1157, and 1212, is Management Framework, as described in RFCs 1155, 1157, and 1212, is
termed the SNMP version 1 framework (SNMPv1). The current framework is termed the SNMP version 1 framework (SNMPv1). The current framework is
termed the SNMP version 2 framework (SNMPv2). termed the SNMP version 2 framework (SNMPv2).
1.2. Change Log 2. Definitions -
For the 19 March version: +
- The changes adopted by the SNMPv2 Working Group. +
For the 1 November version:
- recast RFC 1443 into an Internet-Draft,
- fixed typos,
- added a summary of NVT ASCII to description of DisplayString,
- clarified the description of InstancePointer,
- fixed an error in the RowStatus state table, and another in its
notes,
- added a clarification on the use of DISPLAY-HINTS for particular
types of syntax,
2. Definitions
SNMPv2-TC DEFINITIONS ::= BEGIN SNMPv2-TC DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
ObjectSyntax, Integer32, TimeTicks ObjectSyntax, TimeTicks |
FROM SNMPv2-SMI; FROM SNMPv2-SMI;
-- definition of textual conventions -- definition of textual conventions
TEXTUAL-CONVENTION MACRO ::= TEXTUAL-CONVENTION MACRO ::=
BEGIN BEGIN
TYPE NOTATION ::= TYPE NOTATION ::=
DisplayPart DisplayPart
"STATUS" Status "STATUS" Status
"DESCRIPTION" Text "DESCRIPTION" Text
ReferPart ReferPart
"SYNTAX" Syntax | "SYNTAX" Syntax
VALUE NOTATION ::= VALUE NOTATION ::=
value(VALUE Syntax) value(VALUE Syntax)
DisplayPart ::= DisplayPart ::=
"DISPLAY-HINT" Text "DISPLAY-HINT" Text
| empty | empty
Status ::= Status ::=
"current" "current"
| "deprecated" | "deprecated"
| "obsolete" | "obsolete"
ReferPart ::= ReferPart ::=
"REFERENCE" Text "REFERENCE" Text
| empty | empty
-- uses the NVT ASCII character set -- uses the NVT ASCII character set
Text ::= """" string """" Text ::= """" string """"
Syntax ::= + Syntax ::=
type(ObjectSyntax) + type(ObjectSyntax)
| "BITS" "{" Kibbles "}" + | "BITS" "{" Kibbles "}"
Kibbles ::= + Kibbles ::=
Kibble + Kibble
| Kibbles "," Kibble + | Kibbles "," Kibble
Kibble ::= + Kibble ::=
identifier "(" nonNegativeNumber ")" + identifier "(" nonNegativeNumber ")"
END END
DisplayString ::= TEXTUAL-CONVENTION DisplayString ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a" DISPLAY-HINT "255a"
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Represents textual information taken from the NVT ASCII "Represents textual information taken from the NVT ASCII
character set, as defined in pages 4, 10-11 of RFC 854. character set, as defined in pages 4, 10-11 of RFC 854.
skipping to change at page 9, line 24 skipping to change at page 9, line 24
fails with an error of `inconsistentValue'. Otherwise, if fails with an error of `inconsistentValue'. Otherwise, if
the current value is the maximum value of 2^31-1 (2147483647 the current value is the maximum value of 2^31-1 (2147483647
decimal), then the value held by the instance is wrapped to decimal), then the value held by the instance is wrapped to
zero; otherwise, the value held by the instance is zero; otherwise, the value held by the instance is
incremented by one. (Note that regardless of whether the incremented by one. (Note that regardless of whether the
management protocol set operation succeeds, the variable- management protocol set operation succeeds, the variable-
binding in the request and response PDUs are identical.) binding in the request and response PDUs are identical.)
The value of the ACCESS clause for objects having this The value of the ACCESS clause for objects having this
syntax is either `read-write' or `read-create'. When an syntax is either `read-write' or `read-create'. When an
instance of a columnar object having this syntax is created, | instance of a columnar object having this syntax is created,
any value may be supplied via the management protocol. | any value may be supplied via the management protocol.
When the network management portion of the system is re- | When the network management portion of the system is re-
initialized, the value of every object instance having this | initialized, the value of every object instance having this
syntax must either be incremented from its value prior to | syntax must either be incremented from its value prior to
the re-initialization, or (if the value prior to the re- | the re-initialization, or (if the value prior to the re-
initialization is unknown) be set to a pseudo-randomly | initialization is unknown) be set to a pseudo-randomly
generated value." | generated value."
SYNTAX INTEGER (0..2147483647) SYNTAX INTEGER (0..2147483647)
AutonomousType ::= TEXTUAL-CONVENTION AutonomousType ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Represents an independently extensible type identification "Represents an independently extensible type identification
value. It may, for example, indicate a particular sub-tree value. It may, for example, indicate a particular sub-tree
with further MIB definitions, or define a particular type of with further MIB definitions, or define a particular type of
protocol or hardware." protocol or hardware."
SYNTAX OBJECT IDENTIFIER SYNTAX OBJECT IDENTIFIER
InstancePointer ::= TEXTUAL-CONVENTION InstancePointer ::= TEXTUAL-CONVENTION
STATUS obsolete | STATUS obsolete
DESCRIPTION DESCRIPTION
"A pointer to either a specific instance of a MIB object or "A pointer to either a specific instance of a MIB object or
a conceptual row of a MIB table in the managed device. In a conceptual row of a MIB table in the managed device. In
the latter case, by convention, it is the name of the the latter case, by convention, it is the name of the
particular instance of the first accessible columnar object | particular instance of the first accessible columnar object
in the conceptual row. | in the conceptual row.
The two uses of this textual convention are replaced by | The two uses of this textual convention are replaced by
VariablePointer and RowPointer, respectively." | VariablePointer and RowPointer, respectively."
SYNTAX OBJECT IDENTIFIER SYNTAX OBJECT IDENTIFIER
VariablePointer ::= TEXTUAL-CONVENTION + VariablePointer ::= TEXTUAL-CONVENTION
STATUS current + STATUS current
DESCRIPTION + DESCRIPTION
"A pointer to a specific object instance. For example, + "A pointer to a specific object instance. For example,
sysContact.0 or ifInOctets.3." + sysContact.0 or ifInOctets.3."
SYNTAX OBJECT IDENTIFIER + SYNTAX OBJECT IDENTIFIER
RowPointer ::= TEXTUAL-CONVENTION + RowPointer ::= TEXTUAL-CONVENTION
STATUS current + STATUS current
DESCRIPTION + DESCRIPTION
"Represents a pointer to a conceptual row. The value is the + "Represents a pointer to a conceptual row. The value is the
name of the instance of the first accessible columnar object + name of the instance of the first accessible columnar object
in the conceptual row. + in the conceptual row.
For example, ifIndex.3 would point to the 3rd row in the + For example, ifIndex.3 would point to the 3rd row in the
ifTable (note that if ifIndex were not-accessible, then + ifTable (note that if ifIndex were not-accessible, then
ifDescr.3 would be used instead)." + ifDescr.3 would be used instead)."
SYNTAX OBJECT IDENTIFIER + SYNTAX OBJECT IDENTIFIER
RowStatus ::= TEXTUAL-CONVENTION RowStatus ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The RowStatus textual convention is used to manage the "The RowStatus textual convention is used to manage the
creation and deletion of conceptual rows, and is used as the creation and deletion of conceptual rows, and is used as the
value of the SYNTAX clause for the status column of a value of the SYNTAX clause for the status column of a
conceptual row (as described in Section 7.7.1 of [2].) conceptual row (as described in Section 7.7.1 of [2].)
The status column has six defined values: The status column has six defined values:
skipping to change at page 12, line 31 skipping to change at page 12, line 31
such a specification is made, affected columns may be such a specification is made, affected columns may be
changed by an SNMP set PDU if the RowStatus would not changed by an SNMP set PDU if the RowStatus would not
be equal to `active' either immediately before or after be equal to `active' either immediately before or after
processing the PDU. In other words, if the PDU also processing the PDU. In other words, if the PDU also
contained a varbind that would change the RowStatus contained a varbind that would change the RowStatus
value, the column in question may be changed if the value, the column in question may be changed if the
RowStatus was not equal to `active' as the PDU was RowStatus was not equal to `active' as the PDU was
received, or if the varbind sets the status to a value received, or if the varbind sets the status to a value
other than 'active'. other than 'active'.
Also note that whenever any elements of a row exist, the + Also note that whenever any elements of a row exist, the
RowStatus column must also exist. + RowStatus column must also exist.
To summarize the effect of having a conceptual row with a To summarize the effect of having a conceptual row with a
status column having a SYNTAX clause value of RowStatus, status column having a SYNTAX clause value of RowStatus,
consider the following state diagram: consider the following state diagram:
STATE STATE
+--------------+-----------+-------------+------------- +--------------+-----------+-------------+-------------
| A | B | C | D | A | B | C | D
| |status col.|status column| | |status col.|status column|
|status column | is | is |status column |status column | is | is |status column
ACTION |does not exist| notReady | notInService| is active ACTION |does not exist| notReady | notInService| is active
skipping to change at page 13, line 44 skipping to change at page 13, line 45
| | or | | or | | or | | or
| | | | | | | |
| |see 3 ->C| ->C|wrongValue | |see 3 ->C| ->C|wrongValue
--------------+--------------+-----------+-------------+------------- --------------+--------------+-----------+-------------+-------------
set status |noError |noError |noError |noError set status |noError |noError |noError |noError
column to | | | | column to | | | |
destroy | ->A| ->A| ->A| ->A destroy | ->A| ->A| ->A| ->A
--------------+--------------+-----------+-------------+------------- --------------+--------------+-----------+-------------+-------------
set any other |see 4 |noError |noError |see 5 set any other |see 4 |noError |noError |see 5
column to some| | | | column to some| | | |
value | ->A| see 1| ->C| ->D value | | see 1| ->C| ->D |
--------------+--------------+-----------+-------------+------------- --------------+--------------+-----------+-------------+-------------
(1) goto B or C, depending on information available to the (1) goto B or C, depending on information available to the
agent. agent.
(2) if other variable bindings included in the same PDU, (2) if other variable bindings included in the same PDU,
provide values for all columns which are missing but provide values for all columns which are missing but
required, then return noError and goto D. required, then return noError and goto D.
(3) if other variable bindings included in the same PDU, (3) if other variable bindings included in the same PDU,
provide values for all columns which are missing but provide values for all columns which are missing but
required, then return noError and goto C. required, then return noError and goto C.
(4) at the discretion of the agent, the return value may be | (4) at the discretion of the agent, the return value may be
either: | either:
inconsistentName: because the agent does not choose to + inconsistentName: because the agent does not choose to
create such an instance when the corresponding + create such an instance when the corresponding
RowStatus instance does not exist, or + RowStatus instance does not exist, or
inconsistentValue: if the supplied value is + inconsistentValue: if the supplied value is
inconsistent with the state of some other MIB object's + inconsistent with the state of some other MIB object's
value, or + value, or
noError: because the agent chooses to create the + noError: because the agent chooses to create the
instance. + instance.
If noError is returned, then the instance of the status + If noError is returned, then the instance of the status |
column must also be created. + column must also be created, and the new state is B or C, |
depending on the information available to the agent. If |
inconsistentName or inconsistentValue is returned, the row |
remains in state A. |
(5) depending on the MIB definition for the column/table, (5) depending on the MIB definition for the column/table,
either noError or inconsistentValue may be returned. either noError or inconsistentValue may be returned.
NOTE: Other processing of the set request may result in a NOTE: Other processing of the set request may result in a
response other than noError being returned, e.g., response other than noError being returned, e.g.,
wrongValue, noCreation, etc. wrongValue, noCreation, etc.
Conceptual Row Creation Conceptual Row Creation
skipping to change at page 20, line 42 skipping to change at page 20, line 42
If the management station is prevented from setting the If the management station is prevented from setting the
status column to `active' (e.g., due to management station status column to `active' (e.g., due to management station
or network failure) the conceptual row will be left in the or network failure) the conceptual row will be left in the
`notInService' or `notReady' state, consuming resources `notInService' or `notReady' state, consuming resources
indefinitely. The agent must detect conceptual rows that indefinitely. The agent must detect conceptual rows that
have been in either state for an abnormally long period of have been in either state for an abnormally long period of
time and remove them. This period of time should be long time and remove them. This period of time should be long
enough to allow for human response time (including `think enough to allow for human response time (including `think
time') between the creation of the conceptual row and the time') between the creation of the conceptual row and the
setting of the status to `active'. It is suggested that setting of the status to `active'. It is suggested that
this period be approximately 5 minutes in length. this period be approximately 5 minutes in length. This +
removal action applies not only to newly-created rows, but +
also to previously active rows which are set to, and left +
in, the notInService state for a prolonged period. +
Conceptual Row Suspension Conceptual Row Suspension
When a conceptual row is `active', the management station When a conceptual row is `active', the management station
may issue a management protocol set operation which sets the may issue a management protocol set operation which sets the
instance of the status column to `notInService'. If the instance of the status column to `notInService'. If the
agent is unwilling to do so, the set operation fails with an agent is unwilling to do so, the set operation fails with an
error of `wrongValue'. Otherwise, the conceptual row is error of `wrongValue'. Otherwise, the conceptual row is
taken out of service, and a `noError' response is returned. taken out of service, and a `noError' response is returned.
It is the responsibility of the the DESCRIPTION clause of It is the responsibility of the the DESCRIPTION clause of
the status column to indicate under what circumstances the the status column to indicate under what circumstances the
skipping to change at page 23, line 34 skipping to change at page 24, line 5
For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be
displayed as: displayed as:
1992-5-26,13:30:15.0,-4:0 1992-5-26,13:30:15.0,-4:0
Note that if only local time is known, then timezone Note that if only local time is known, then timezone
information (fields 8-10) is not present." information (fields 8-10) is not present."
SYNTAX OCTET STRING (SIZE (8 | 11)) SYNTAX OCTET STRING (SIZE (8 | 11))
StorageType ::= TEXTUAL-CONVENTION +
STATUS current +
DESCRIPTION +
"Describes the memory realization of a conceptual row. A +
row which is volatile(2) is lost upon reboot. A row which +
is either nonVolatile(3), permanent(4) or readOnly(5), is +
backed up by stable storage. A row which is permanent(4) +
can be changed but not deleted. A row which is readOnly(5) +
cannot be changed nor deleted. +
If the value of an object with this syntax is either +
permanent(4) or readOnly(5), it cannot be modified. +
Conversely, if the value is either other(1), volatile(2) or +
nonVolatile(3), it cannot be modified to be permanent(4) or +
readOnly(5). +
Every usage of this textual convention is required to +
specify the columnar objects which a permanent(4) row must +
at a minimum allow to be writable." +
SYNTAX INTEGER { +
other(1), -- eh? +
volatile(2), -- e.g., in RAM +
nonVolatile(3), -- e.g., in NVRAM +
permanent(4), -- e.g., partially in ROM +
readOnly(5) -- e.g., completely in ROM +
} +
END END
3. Mapping of the TEXTUAL-CONVENTION macro 3. Mapping of the TEXTUAL-CONVENTION macro
The TEXTUAL-CONVENTION macro is used to convey the syntax and semantics The TEXTUAL-CONVENTION macro is used to convey the syntax and semantics
associated with a textual convention. It should be noted that the associated with a textual convention. It should be noted that the
expansion of the TEXTUAL-CONVENTION macro is something which expansion of the TEXTUAL-CONVENTION macro is something which
conceptually happens during implementation and not during run-time. conceptually happens during implementation and not during run-time.
For all descriptors appearing in an information module, the descriptor For all descriptors appearing in an information module, the descriptor
shall be unique and mnemonic, and shall not exceed 64 characters in shall be unique and mnemonic, and shall not exceed 64 characters in
length. Further, the hyphen is not allowed as a character in the name length. (However, descriptors longer than 32 characters are not +
of any textual convention. recommended.) +
Further, the hyphen is not allowed as a character in the name of any
textual convention.
3.1. Mapping of the DISPLAY-HINT clause 3.1. Mapping of the DISPLAY-HINT clause
The DISPLAY-HINT clause, which need not be present, gives a hint as to The DISPLAY-HINT clause, which need not be present, gives a hint as to
how the value of an instance of an object with the syntax defined using how the value of an instance of an object with the syntax defined using
this textual convention might be displayed. The DISPLAY-HINT clause may this textual convention might be displayed. The DISPLAY-HINT clause may
be present if and only if the syntax has an underlying primitive type of be present if and only if the syntax has an underlying primitive type of
INTEGER or OCTET STRING. (Note, however, that the semantics defined for INTEGER or OCTET STRING. (Note, however, that the semantics defined for
a particular syntax can cause the use of DISPLAY-HINT for that syntax to a particular syntax can cause the use of DISPLAY-HINT for that syntax to
make no sense, e.g., for Counter32 [2].) make no sense, e.g., for Counter32 [2].)
When the syntax has an underlying primitive type of INTEGER, the hint | When the syntax has an underlying primitive type of INTEGER, the hint
consists of an integer-format specification, containing two parts. The | consists of an integer-format specification, containing two parts. The
first part is a single character suggesting a display format, either: | first part is a single character suggesting a display format, either: |
The second part is always omitted for 'x', 'o' and 'b', and need not be | 'x' for hexadecimal, or 'd' for decimal, or 'o' for octal, or 'b' for |
present for 'd'. If present, the second part starts with a hyphen and | binary. |
is followed by a decimal number, which defines the implied decimal point | The second part is always omitted for 'x', 'o' and 'b', and need not be
when rendering the value. For example: | present for 'd'. If present, the second part starts with a hyphen and
is followed by a decimal number, which defines the implied decimal point
when rendering the value. For example:
Hundredths ::= TEXTUAL-CONVENTION | Hundredths ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d-2" | DISPLAY-HINT "d-2"
... | ...
SYNTAX INTEGER (0..10000) | SYNTAX INTEGER (0..10000)
suggests that a Hundredths value of 1234 be rendered as "12.34" | suggests that a Hundredths value of 1234 be rendered as "12.34"
When the syntax has an underlying primitive type of OCTET STRING, the When the syntax has an underlying primitive type of OCTET STRING, the
hint consists of one or more octet-format specifications. Each hint consists of one or more octet-format specifications. Each
specification consists of five parts, with each part using and removing specification consists of five parts, with each part using and removing
zero or more of the next octets from the value and producing the next zero or more of the next octets from the value and producing the next
zero or more characters to be displayed. The octets within the value zero or more characters to be displayed. The octets within the value
are processed in order of significance, most significant first. are processed in order of significance, most significant first.
The five parts of a octet-format specification are: The five parts of a octet-format specification are:
(1) the (optional) repeat indicator; if present, this part is a `*', (1) the (optional) repeat indicator; if present, this part is a `*',
and indicates that the current octet of the value is to be used as and indicates that the current octet of the value is to be used as
the repeat count. The repeat count is an unsigned integer (which the repeat count. The repeat count is an unsigned integer (which
skipping to change at page 26, line 4 skipping to change at page 27, line 10
than a decimal digit and a `*'. than a decimal digit and a `*'.
Output of a display separator character or a repeat terminator character Output of a display separator character or a repeat terminator character
is suppressed if it would occur as the last character of the display. is suppressed if it would occur as the last character of the display.
If the octets of the value are exhausted before all the octet-format If the octets of the value are exhausted before all the octet-format
specification have been used, then the excess specifications are specification have been used, then the excess specifications are
ignored. If additional octets remain in the value after interpreting ignored. If additional octets remain in the value after interpreting
all the octet-format specifications, then the last octet-format all the octet-format specifications, then the last octet-format
specification is re-interpreted to process the additional octets, until specification is re-interpreted to process the additional octets, until
no octets remain in the value. no octets remain in the value.
3.2. Mapping of the STATUS clause 3.2. Mapping of the STATUS clause
The STATUS clause, which must be present, indicates whether this The STATUS clause, which must be present, indicates whether this
definition is current or historic. definition is current or historic.
The values "current", and "obsolete" are self-explanatory. The The values "current", and "obsolete" are self-explanatory. The |
"deprecated" value indicates that the textual convention is obsolete, "deprecated" value indicates that the definition is obsolete, but that |
but that an implementor may wish to support that object to foster an implementor may wish to support the use of this textual convention to |
interoperability with older implementations. foster interoperability with older implementations. |
3.3. Mapping of the DESCRIPTION clause 3.3. Mapping of the DESCRIPTION clause
The DESCRIPTION clause, which must be present, contains a textual The DESCRIPTION clause, which must be present, contains a textual
definition of the textual convention, which provides all semantic definition of the textual convention, which provides all semantic
definitions necessary for implementation, and should embody any definitions necessary for implementation, and should embody any
information which would otherwise be communicated in any ASN.1 information which would otherwise be communicated in any ASN.1
commentary annotations associated with the object. commentary annotations associated with the object.
Note that, in order to conform to the ASN.1 syntax, the entire value of Note that, in order to conform to the ASN.1 syntax, the entire value of
skipping to change at page 26, line 39 skipping to change at page 27, line 44
3.4. Mapping of the REFERENCE clause 3.4. Mapping of the REFERENCE clause
The REFERENCE clause, which need not be present, contains a textual The REFERENCE clause, which need not be present, contains a textual
cross-reference to a related item defined in some other published work. cross-reference to a related item defined in some other published work.
3.5. Mapping of the SYNTAX clause 3.5. Mapping of the SYNTAX clause
The SYNTAX clause, which must be present, defines abstract data The SYNTAX clause, which must be present, defines abstract data
structure corresponding to the textual convention. The data structure structure corresponding to the textual convention. The data structure
must be one of the alternatives defined in the ObjectSyntax CHOICE [2] | must be one of the alternatives defined in the ObjectSyntax CHOICE or |
or the KIBBLE BITS construct. | the BITS construct (see section 7.1 in [2]). |
Full ASN.1 sub-typing is allowed, as appropriate to the underingly ASN.1
type, primarily as an aid to implementors in understanding the meaning
of the textual convention. Of course, sub-typing is not allowed for
textual conventions derived from either the Counter32 or Counter64
types, but is allowed for textual conventions derived from the Gauge32
type.
4. Acknowledgements 4. Acknowledgements
The authors wish to acknowledge the contributions of the SNMPv2 Working The authors wish to acknowledge the contributions of the SNMPv2 Working
Group in general. In particular, the following individuals Group in general. In particular, the following individuals
Dave Arneson (Cabletron), Dave Arneson (Cabletron),
Uri Blumenthal (IBM), Uri Blumenthal (IBM),
Doug Book (Chipcom), Doug Book (Chipcom),
Maria Greene (Ascom Timeplex), Maria Greene (Ascom Timeplex),
skipping to change at page 28, line 37 skipping to change at page 28, line 37
[1] Information processing systems - Open Systems Interconnection - [1] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1), Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization. International International Organization for Standardization. International
Standard 8824, (December, 1987). Standard 8824, (December, 1987).
[2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure [2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure
of Management Information for Version 2 of the Simple Network of Management Information for Version 2 of the Simple Network
Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc.,
Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon
University, November 1994. University, May 1995. |
6. Security Considerations 6. Security Considerations
Security issues are not discussed in this memo. Security issues are not discussed in this memo.
7. Authors' Addresses 7. Authors' Addresses
Jeffrey D. Case Jeffrey D. Case
SNMP Research, Inc. SNMP Research, Inc.
3001 Kimberlin Heights Rd. 3001 Kimberlin Heights Rd.
skipping to change at page 30, line 9 skipping to change at page 30, line 9
Pittsburgh, PA 15213 Pittsburgh, PA 15213
US US
Phone: +1 412 268 6628 Phone: +1 412 268 6628
Email: waldbusser@cmu.edu Email: waldbusser@cmu.edu
Table of Contents Table of Contents
1 Introduction .................................................... 3 1 Introduction .................................................... 3
1.1 A Note on Terminology ......................................... 4 1.1 A Note on Terminology ......................................... 4
1.2 Change Log .................................................... 4
2 Definitions ..................................................... 5 2 Definitions ..................................................... 5
3 Mapping of the TEXTUAL-CONVENTION macro ......................... 24 3 Mapping of the TEXTUAL-CONVENTION macro ......................... 25
3.1 Mapping of the DISPLAY-HINT clause ............................ 24 3.1 Mapping of the DISPLAY-HINT clause ............................ 25
3.2 Mapping of the STATUS clause .................................. 26 3.2 Mapping of the STATUS clause .................................. 27
3.3 Mapping of the DESCRIPTION clause ............................. 26 3.3 Mapping of the DESCRIPTION clause ............................. 27
3.4 Mapping of the REFERENCE clause ............................... 26 3.4 Mapping of the REFERENCE clause ............................... 27
3.5 Mapping of the SYNTAX clause .................................. 26 3.5 Mapping of the SYNTAX clause .................................. 27
4 Acknowledgements ................................................ 28 4 Acknowledgements ................................................ 28
5 References ...................................................... 28 5 References ...................................................... 28
6 Security Considerations ......................................... 29 6 Security Considerations ......................................... 29
7 Authors' Addresses .............................................. 29 7 Authors' Addresses .............................................. 29
 End of changes. 36 change blocks. 
119 lines changed or deleted 126 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/