RFC 1443
Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)
Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2) 🎀
Okay bestie, this is RFC 1443, published in April 1993 by the Network Working Group 💖 It's all about textual conventions for SNMPv2, the second version of the Simple Network Management Protocol ✨
The squad behind it is four authors. J. Case is from SNMP Research, Inc., K. McCloghrie is from Hughes LAN Systems, M. Rose is from Dover Beach Consulting, Inc., and S. Waldbusser is from Carnegie Mellon University 👑 It's a IAB standards track protocol. The header doesn't list any RFC that it obsoletes or updates, so there's no drama there 🙈
Status of this Memo 💅
This RFC specifies an IAB standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of "IAB Official Protocol Standards." And distribution of this memo is unlimited 🌈
Table of Contents 📚
1 Introduction .......................................... 2
1.1 A Note on Terminology ............................... 3
2 Definitions ........................................... 4
3 Mapping of the TEXTUAL-CONVENTION macro ............... 22
3.1 Mapping of the DISPLAY-HINT clause .................. 22
3.2 Mapping of the STATUS clause ........................ 24
3.3 Mapping of the DESCRIPTION clause ................... 24
3.4 Mapping of the REFERENCE clause ..................... 24
3.5 Mapping of the SYNTAX clause ........................ 24
4 Acknowledgements ...................................... 26
5 References ............................................ 30
6 Security Considerations ............................... 31
7 Authors' Addresses .................................... 311. Introduction ✨
Okay so a network management system has a few main pieces 🧚 There are several (potentially many) nodes, and each one has a processing entity called an agent, which has access to management instrumentation. There's also at least one management station, plus a management protocol that carries management information between the agents and the management stations. Everything runs under an administrative framework that defines both authentication and authorization policies 🔐
Network management stations run management applications that monitor and control network elements. Network elements are devices like hosts, routers, terminal servers, etc., and they get monitored and controlled through access to their management information 💜
Management information is viewed as a collection of managed objects that live in a virtual information store called the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1], which is called the Structure of Management Information (SMI) [2] 📖
When you're designing a MIB module, it's often super useful to define new types that are similar to the ones in the SMI. Compared to an SMI type, each of these new types has a different name, a similar syntax, and a more precise semantics. They're called textual conventions, and they're used for the convenience of the humans reading the MIB module 🍓 The purpose of this document is to define the initial set of textual conventions available to all MIB modules 🎀
Objects defined using a textual convention are always encoded by the rules that define their primitive type. Textual conventions often have special semantics attached, though, so an ASN.1 macro called TEXTUAL-CONVENTION is used to concisely convey the syntax and semantics of a textual convention 🦋
For all textual conventions defined in an information module, the name shall be unique and mnemonic, and shall not exceed 64 characters in length. All names used for the textual conventions defined in all "standard" information modules shall be unique 💅
1.1. A Note on Terminology 🌸
For the purpose of exposition, the original Internet-standard Network 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 2 framework (SNMPv2) ✨
2. Definitions 🎀
Here's the ASN.1 module, copy-paste ready 💻
SNMPv2-TC DEFINITIONS ::= BEGIN
IMPORTS
ObjectSyntax, Integer32, TimeTicks
FROM SNMPv2-SMI;
-- definition of textual conventions
TEXTUAL-CONVENTION MACRO ::=
BEGIN
TYPE NOTATION ::=
DisplayPart
"STATUS" Status
"DESCRIPTION" Text
ReferPart
"SYNTAX" type(Syntax)
VALUE NOTATION ::=
value(VALUE Syntax)
DisplayPart ::=
"DISPLAY-HINT" Text
| empty
Status ::=
"current"
| "deprecated"
| "obsolete"
ReferPart ::=
"REFERENCE" Text
| empty
-- uses the NVT ASCII character set
Text ::= """" string """"
END
DisplayString ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS current
DESCRIPTION
"Represents textual information taken from the NVT
ASCII character set, as defined in pages 4, 10-11
of RFC 854. Any object defined using this syntax
may not exceed 255 characters in length."
SYNTAX OCTET STRING (SIZE (0..255))
PhysAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1x:"
STATUS current
DESCRIPTION
"Represents media- or physical-level addresses."
SYNTAX OCTET STRING
MacAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1x:"
STATUS current
DESCRIPTION
"Represents an 802 MAC address represented in the
'canonical' order defined by IEEE 802.1a, i.e., as
if it were transmitted least significant bit
first, even though 802.5 (in contrast to other
802.x protocols) requires MAC addresses to be
transmitted most significant bit first."
SYNTAX OCTET STRING (SIZE (6))
TruthValue ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents a boolean value."
SYNTAX INTEGER { true(1), false(2) }
TestAndIncr ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents integer-valued information used for
atomic operations. When the management protocol
is used to specify that an object instance having
this syntax is to be modified, the new value
supplied via the management protocol must
precisely match the value presently held by the
instance. If not, the management protocol set
operation fails with an error of
'inconsistentValue'. Otherwise, if the current
value is the maximum value of 2^31-1 (2147483647
decimal), then the value held by the instance is
wrapped to zero; otherwise, the value held by the
instance is incremented by one. (Note that
regardless of whether the management protocol set
operation succeeds, the variable-binding in the
request and response PDUs are identical.)
The value of the ACCESS clause for objects having
this syntax is either 'read-write' or 'read-
create'. When an instance of a columnar object
having this syntax is created, any value may be
supplied via the management protocol."
SYNTAX INTEGER (0..2147483647)
AutonomousType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents an independently extensible type
identification value. It may, for example,
indicate a particular sub-tree with further MIB
definitions, or define a particular type of
protocol or hardware."
SYNTAX OBJECT IDENTIFIER
InstancePointer ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A pointer to a specific instance of a conceptual
row of a MIB table in the managed device. By
convention, it is the name of the particular
instance of the first columnar object in the
conceptual row."
SYNTAX OBJECT IDENTIFIER
RowStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The RowStatus textual convention is used to
manage the creation and deletion of conceptual
rows, and is used as the value of the SYNTAX
clause for the status column of a conceptual row
(as described in Section 7.7.1 of [2].)
The status column has six defined values:
- 'active', which indicates that the
conceptual row is available for use by the
managed device;
- 'notInService', which indicates that the
conceptual row exists in the agent, but is
unavailable for use by the managed device
(see NOTE below);
- 'notReady', which indicates that the
conceptual row exists in the agent, but is
missing information necessary in order to be
available for use by the managed device;
- 'createAndGo', which is supplied by a
management station wishing to create a new
instance of a conceptual row and to have it
available for use by the managed device;createAndWait🧁 is what a management station sends when it wants to create a new instance of a conceptual row but doesn't want the managed device to start using it yet; and,destroy💥 is what a management station sends when it wants to delete all of the instances tied to an existing conceptual row.
Okay bestie, here's the tea ☕: five of the six values (everything except notReady) MAY be specified in a management protocol set operation 🎀. But when you retrieve a row, you only ever get back notReady, notInService, or active. 💅 So when you check on an existing conceptual row, it's giving one of three vibes:
- it's
active✨, which means the managed device can use it (the status column has the valueactive); - it's
notInService🛠️, which means the device can't use it yet, but the agent has enough info to make that happen (the status column has the valuenotInService); or, - it's
notReady😭, which means the device can't use it because the agent doesn't have enough info (the status column has the valuenotReady).
NOTE WELL 🚨 This textual convention MAY be used for a MIB table, no matter whether that table's conceptual rows can be changed while they're active, or whether they MUST be taken out of service before they can be modified. It's the DESCRIPTION clause of the status column that gets to say whether the status column MUST be notInService before some other column in the same conceptual row can be modified. 📣
To sum up what happens when a conceptual row has a status column with a SYNTAX clause value of RowStatus, peep this state diagram 👀:
STATE
+--------------+-----------+-------------+-------------
| A | B | C | D
| |status col.|status column|
|status column | is | is |status column
ACTION |does not exist| notReady | notInService| is active
--------------+--------------+-----------+-------------+-------------
set status |noError ->D|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndGo |inconsistent- | | |
| Value| | |
--------------+--------------+-----------+-------------+-------------
set status |noError see 1|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndWait |wrongValue | | |
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError
column to | Value| entValue| |
active | | | |
| | or | |
| | | |
| |see 2 ->D| ->D| ->D
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError ->C
column to | Value| entValue| |
notInService | | | |
| | or | | or
| | | |
| |see 3 ->C| ->C|wrongValue
--------------+--------------+-----------+-------------+-------------
set status |noError |noError |noError |noError
column to | | | |
destroy | ->A| ->A| ->A| ->A
--------------+--------------+-----------+-------------+-------------
set any other |see 4 |noError |noError |noError
column to some| | | |
value | ->A| see 1| ->C| ->D
--------------+--------------+-----------+-------------+-------------(1) Goto B or C, depending on what info the agent has available 🧠.
(2) If other variable bindings came along in the same PDU, provide values for all the columns that are missing but required, then return noError and goto D 💖.
(3) If other variable bindings came along in the same PDU, provide values for all the columns that are missing but required, then return noError and goto C 💖.
(4) At the agent's discretion, either noError or inconsistentValue MAY be returned 🎲.
NOTE: Other processing of the set request MAY result in a response other than noError being returned, e.g., wrongValue, noCreation, etc. 🙈
Conceptual Row Creation ✨
Making a conceptual row from scratch is a whole glow-up with four interactions 💜: picking an instance-identifier that isn't in use, creating the conceptual row, initializing any objects the agent doesn't supply a default for, and finally making the conceptual row available for the managed device to use. 🦋
Interaction 1: Selecting an Instance-Identifier 🔍
The algorithm for picking an instance-identifier is different for every conceptual row 💅. Sometimes the instance-identifier actually means something, like the destination address of a route, so the management station picks it based on that meaning 🗺️.
In other cases, the instance-identifier just tells conceptual rows apart, so a management station that doesn't know much about the conceptual row might look at the instances that already exist to find one that's unused. (This approach MAY be used, but it's often highly sub-optimal 😬; however, it's also a questionable practice for a naive management station to attempt conceptual row creation 🙃.)
Alternately, the MIB module that defines the conceptual row might provide one or more objects that help figure out an unused instance-identifier 🧚. For example, if the conceptual row is indexed by an integer-value, then an object with an integer-valued SYNTAX clause might be defined for exactly that purpose, so a management station can issue a management protocol retrieval operation. To avoid unnecessary collisions between competing management stations, 'adjacent' retrievals of this object SHOULD be different 🤝.
Finally, the management station could pick a pseudo-random number to use as the index 🎲. If that index is already in use and an inconsistentValue comes back in response to the management protocol set operation, the management station SHOULD simply pick a new pseudo-random number and retry the operation 🔁.
A MIB designer SHOULD choose between the two latter algorithms based on the size of the table (and therefore how efficient each algorithm is) 📊. For tables where a large number of entries is expected, it is RECOMMENDED that a MIB object be defined that returns an acceptable index for creation 🏆. For tables with small numbers of entries, it is RECOMMENDED that the latter pseudo-random index mechanism be used 🌸.
Interaction 2: Creating the Conceptual Row 🎀
Once an unused instance-identifier has been selected, the management station decides whether it wants to create and activate the conceptual row in one transaction, or in a negotiated set of interactions 🤔.
Interaction 2a: Creating and Activating the Conceptual Row 🚀
Okay, so the management station MUST first figure out the column requirements. In other words, it MUST determine those columns for which it MUST or MUST NOT provide values 📋. Depending on how complicated the table is and how much the management station knows about the agent's capabilities, it can figure this out locally 🧩. Alternately, the management station issues a management protocol get operation to examine all the columns in the conceptual row it wants to create 👀. When that happens, each column can have one of three outcomes:
- a value comes back 🎁, which means some other management station already created this conceptual row. We go back to interaction 1 🔁.
- the exception
noSuchInstanceis returned 🫶, which means the agent implements the object-type for this column, and this column in at least one conceptual row would be accessible in the MIB view used by the retrieval if that row existed. For columns the agent gives read-create access to,noSuchInstancetells the management station it should supply a value for this column when the conceptual row is to be created. 🧚 - the exception
noSuchObjectis returned 💀, which means the agent does not implement the object-type for this column, or there is no conceptual row where this column would be accessible in the MIB view used by the retrieval. So the management station can not issue any management protocol set operations to create an instance of this column. Bestie, that's a hard no 🙅♀️
Once the column requirements are figured out, a management protocol set operation gets issued ✨ and this operation also sets the new instance of the status column to createAndGo. Main character energy 👑
When the agent processes the set operation, it checks that it has enough info to make the conceptual row available for use by the managed device 🔍 The info comes from two places: the set operation that creates the row, and implementation-specific defaults the agent supplies 🎀 (and yes, an agent must provide implementation-specific defaults for at least the objects it implements as read-only, no skipping!). If there's enough info, the row gets created, the agent sends back a noError response, the status column flips to active, and that's it, no more back-and-forth 💅 (interactions 3 and 4 get skipped, iykyk). If there's not enough info, the row does NOT get created 😭 and the set operation fails with inconsistentValue. At that point the management station can issue a retrieval to find out whether it just forgot to specify a value for a required column, or whether the selected instance of the status column already existed 🧐 If it already existed, we go back to interaction 1. If it forgot a required column, the management station can re-send the set operation with the extra info, or start interaction 2 again using createAndWait to negotiate the row creation 🦋
NOTE WELL 🚨 No matter how the column requirements were figured out, the management station might decide a column is necessary when the agent actually won't allow that columnar instance to be created or written. 💀 When that happens, the set operation fails with an error likenoCreationornotWritable. Then the management station decides if it still needs to set a value for that particular columnar instance. If not, it re-sends the set operation without setting a value for that instance. If it does need it, the management station aborts the row creation algorithm 🥀
Interaction 2b: Negotiating the Creation of the Conceptual Row
The management station sends a management protocol set operation that sets the desired instance of the status column to createAndWait 🌸 If the agent isn't willing to process a request like this, the set operation fails with a wrongValue error. (So an agent like this has to be ready to accept one single set operation, the interaction 2a one from above, containing all of the columns in its column requirements 🫠) Otherwise, the conceptual row gets created ✨ the agent returns noError, and the status column is immediately set to either notInService or notReady, depending on whether the agent has enough info to make the row usable by the managed device. Enough info means notInService; not enough means notReady. Either way, we move on to interaction 3 🏃♀️💨
Interaction 3: Initializing non-defaulted Objects
The management station needs to figure out the column requirements now 📋 It sends a management protocol get operation to look at all the columns in the created conceptual row. For each column, there are three possible outcomes:
- a value is returned 💖 meaning the agent implements the object-type for this column and had enough info to provide a value. For columns the agent gives read-create access to, a returned value tells the management station that it may send additional management protocol set operations, if it wants, to change the value of this column.
- the exception
noSuchInstanceis returned 🙈 meaning the agent implements the object-type for this column, and this column in at least one conceptual row would be accessible in the MIB view used by the retrieval if it existed. BUT the agent doesn't have enough info to give a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For columns the agent gives read-create access to,noSuchInstancetells the management station that it must send additional management protocol set operations to provide a value for this column. - the exception
noSuchObjectis returned 💀 meaning the agent does not implement the object-type for this column, or there's no conceptual row where this column would be accessible in the MIB view used by the retrieval. So the management station can not issue any management protocol set operations to create an instance of this column. Rip 🥲
If the status column's value is notReady, then the management station must first deal with all the noSuchInstance columns, if there are any 🧹 Once that's done, the status column becomes notInService, and we move on to interaction 4 🌈
Interaction 4: Making the Conceptual Row Available
Once the management station is happy with the values in the columns of the conceptual row 🥰 it sends a management protocol set operation to set the status column to active. If the agent has enough info to make the conceptual row available for use by the managed device, the set operation succeeds (the agent returns noError) ✅ Otherwise, the set operation fails with an error of inconsistentValue. 🙅♀️
NOTE WELL 👀 A conceptual row whose status column isnotInServiceornotReadyis unavailable to the managed device 🫣 So it's totally possible for the managed device to create its own instances between the set operation that sets the status column tocreateAndWaitand the set operation that sets it toactive. 🫢 If that happens, when the set operation setting the status column toactiveis issued, the values held in the agent win out over the ones the managed device was using. Iconic, honestly 💅🔥
If the management station is prevented from
setting the status column to 'active' (e.g., due
to management station or network failure) the
conceptual row will be left in the 'notInService'
or 'notReady' state, consuming resources
indefinitely. The agent must detect conceptual
rows that have been in either state for an
abnormally long period of time and remove them.
This period of time should be long enough to allow
for human response time (including 'think time')
between the creation of the conceptual row and the
setting of the status to 'active'. It is
suggested that this period be approximately 5
minutes in length.
Conceptual Row Suspension
When a conceptual row is 'active', the management
station may issue a management protocol set
operation which sets the instance of the status
column to 'notInService'. If the agent is
unwilling to do so, the set operation fails with
an error of 'wrongValue'. Otherwise, the
conceptual row is taken out of service, and a
'noError' response is returned. It is the
responsibility of the the DESCRIPTION clause of
the status column to indicate under what
circumstances the status column should be taken
out of service (e.g., in order for the value of
some other column of the same conceptual row to be
modified).
Conceptual Row Deletion
For deletion of conceptual rows, a management
protocol set operation is issued which sets the
instance of the status column to 'destroy'. This
request may be made regardless of the current
value of the status column (e.g., it is possible
to delete conceptual rows which are either
'notReady', 'notInService' or 'active'.) If the
operation succeeds, then all instances associated
with the conceptual row are immediately removed."
SYNTAX INTEGER {
-- the following two values are states:
-- these values may be read or written
active(1),
notInService(2),
-- the following value is a state:
-- this value may be read, but not written
notReady(3),
-- the following three values are
-- actions: these values may be written,
-- but are never read
createAndGo(4),
createAndWait(5),
destroy(6)
}
TimeStamp ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The value of MIB-II's sysUpTime object at which a
specific occurrence happened. The specific
occurrence must be defined in the description of
any object defined using this type."
SYNTAX TimeTicks
TimeInterval ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A period of time, measured in units of 0.01
seconds."
SYNTAX INTEGER (0..2147483647)
DateAndTime ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2d-1d-1d,1d:1d:1d.1d,1a1d:1d"
STATUS current
DESCRIPTION
"A date-time specification.
field octets contents range
----- ------ -------- -----
1 1-2 year 0..65536
2 3 month 1..12
3 4 day 1..31
4 5 hour 0..23
5 6 minutes 0..59
6 7 seconds 0..60
(use 60 for leap-second)
7 8 deci-seconds 0..9
8 9 direction from UTC '+' / '-'
9 10 hours from UTC 0..11
10 11 minutes from UTC 0..59
For example, Tuesday May 26, 1992 at 1:30:15 PM
EDT would be displayed as:
1992-5-26,13:30:15.0,-4:0
Note that if only local time is known, then
timezone information (fields 8-10) is not
present."
SYNTAX OCTET STRING (SIZE (8 | 11))
END3. Mapping of the TEXTUAL-CONVENTION macro ✨
okay so the TEXTUAL-CONVENTION macro is basically how we spell out the syntax and meaning of a textual convention 💅 the expansion of that macro is something that happens while you're implementing it, not while things are running. so it's a build-time thing, not a run-time thing 🧚
also, every descriptor in an information module has to be unique and mnemonic, and it can't go past 64 characters in length 😭 and the hyphen? totally banned from the name of any textual convention 🙅♀️ no hyphens allowed, bestie
3.1. Mapping of the DISPLAY-HINT clause 🎀
the DISPLAY-HINT clause is optional (it doesn't have to be there) and it's basically a little tip about how a value of an object might be displayed 👀 it can only show up when the syntax has an underlying primitive type of INTEGER or OCTET STRING.
when the underlying type is INTEGER, the hint is just one character: 'x' for hexadecimal, 'd' for decimal, 'o' for octal, or 'b' for binary 🦋
when the underlying type is OCTET STRING, the hint is one or more octet-format specifications. each spec has five parts, and each part uses up and removes zero or more of the next octets from the value, then produces the next zero or more characters to display. the octets get processed in order of significance, most significant first. so it's giving very orderly 💜
the five parts of an octet-format spec are:
- (1) the (optional) repeat indicator. if it's there, it's a
*, and the current octet of the value is used as the repeat count. the repeat count is an unsigned integer (which may be zero) and it says how many times the rest of this octet-format spec gets applied in a row. if there's no repeat indicator, the repeat count is one. - (2) the octet length: one or more decimal digits saying how many octets of the value this spec uses and formats. the octet length can be zero. if fewer octets than that are left in the value, then only the lesser number gets used ✨
- (3) the display format, which is
'x'for hexadecimal,'d'for decimal,'o'for octal, or'a'for ascii. if the octet length is greater than one and the display format is a numeric one, then network-byte ordering (big-endian encoding) is used when interpreting the octets 🌸 - (4) the (optional) display separator character. if it's present, it's a single character that gets displayed after each application of the spec. BUT it doesn't get displayed if it would be immediately followed by the display of the repeat terminator character for this spec. this can be any character except a decimal digit and a
*🍓 - (5) the (optional) repeat terminator character. this can only be present if the display separator character is present and the spec begins with a repeat indicator. if it's there, it's a single character that gets displayed after all the zero or more repeated applications (as given by the repeat count) of the spec. this can be any character except a decimal digit and a
*🫶
the output of a display separator or a repeat terminator gets suppressed if it would show up as the very last character of the display. no dangling separators, periodt 💅
if the octets run out before all the octet-format specs have been used, then the leftover specs get ignored. and if there are still octets left in the value after all the specs have been interpreted, then the last octet-format spec gets re-interpreted to process the extra octets, until no octets remain in the value 🔁 it's a whole loop, bestie
3.2. Mapping of the STATUS clause 🌈
the STATUS clause has to be present, and it tells you whether this definition is current or historic 🎀
"current" and "obsolete" are honestly self-explanatory, no notes 💖 the "deprecated" value means the textual convention is obsolete, but an implementor might still want to support it so they can keep things interoperating with older implementations 🧚♀️
3.3. Mapping of the DESCRIPTION clause 🍓
the DESCRIPTION clause has to be present. it's the textual definition of the textual convention, and it gives all the semantic definitions you need to implement it. it also should carry any info that would otherwise get communicated in ASN.1 commentary annotations on the object 📝
heads up: to stay ASN.1 legal, the entire value of this clause has to be wrapped in double quotation marks, which means the text itself can't contain any double quotation marks 🙈 the value can be multi-line though, so you're not totally stuck
3.4. Mapping of the REFERENCE clause 🦋
the REFERENCE clause doesn't have to be present. it's a textual cross-reference to a related item defined in some other published work, like a little pointer to another doc 📚✨
3.5. Mapping of the SYNTAX clause 💜
The SYNTAX clause is required, so it must be present. It defines the abstract data structure that matches the textual convention ✨. That structure must be one of the alternatives in the ObjectSyntax CHOICE [2] 🎀.
Full ASN.1 sub-typing is allowed 🦋, as long as it fits the underlying ASN.1 type. It's mostly there to help implementors understand what the textual convention means 🧚. Sub-typing is not allowed for textual conventions derived from Counter32 or Counter64 🙅, but it is allowed for textual conventions derived from Gauge32 ✅.
4. Acknowledgements 🎀
okay, the credits 🎬 PhysAddress (and textual conventions) came from RFC 1213 🌸.
MacAddress came from RFCs 1230 and 1231 🦋.
TruthValue came from RFC 1253 🍓.
AutonomousType and InstancePointer came from RFC 1316 🧚.
RowStatus came from RFC 1271 💜.
A special thanks to Bancroft Scott of Open Systems Solutions, Inc., for helping define the TEXTUAL-CONVENTIONS macro 🫶.
Finally, the comments of the SNMP version 2 working group are gratefully acknowledged 👑:
- Beth Adams, Network Management Forum
- Steve Alexander, INTERACTIVE Systems Corporation
- David Arneson, Cabletron Systems
- Toshiya Asaba
- Fred Baker, ACC
- Jim Barnes, Xylogics, Inc.
- Brian Bataille
- Andy Bierman, SynOptics Communications, Inc.
- Uri Blumenthal, IBM Corporation
- Fred Bohle, Interlink
- Jack Brown
- Theodore Brunner, Bellcore
- Stephen F. Bush, GE Information Services
- Jeffrey D. Case, University of Tennessee, Knoxville
- John Chang, IBM Corporation
- Szusin Chen, Sun Microsystems
- Robert Ching
- Chris Chiotasso, Ungermann-Bass
- Bobby A. Clay, NASA/Boeing
- John Cooke, Chipcom
- Tracy Cox, Bellcore
- Juan Cruz, Datability, Inc.
- David Cullerot, Cabletron Systems
- Cathy Cunningham, Microcom
- James R. (Chuck) Davin, Bellcore
- Michael Davis, Clearpoint
- Mike Davison, FiberCom
- Cynthia DellaTorre, MITRE
- Taso N. Devetzis, Bellcore
- Manual Diaz, DAVID Systems, Inc.
- Jon Dreyer, Sun Microsystems
- David Engel, Optical Data Systems
- Mike Erlinger, Lexcel
- Roger Fajman, NIH
- Daniel Fauvarque, Sun Microsystems
- Karen Frisa, CMU
- Shari Galitzer, MITRE
- Shawn Gallagher, Digital Equipment Corporation
- Richard Graveman, Bellcore
- Maria Greene, Xyplex, Inc.
- Michel Guittet, Apple
- Robert Gutierrez, NASA
- Bill Hagerty, Cabletron Systems
- Gary W. Haney, Martin Marietta Energy Systems
- Patrick Hanil, Nokia Telecommunications
- Matt Hecht, SNMP Research, Inc.
- Edward A. Heiner, Jr., Synernetics Inc.
- Susan E. Hicks, Martin Marietta Energy Systems
- Geral Holzhauer, Apple
- John Hopprich, DAVID Systems, Inc.
- Jeff Hughes, Hewlett-Packard
- Robin Iddon, Axon Networks, Inc.
- David Itusak
- Kevin M. Jackson, Concord Communications, Inc.
- Ole J. Jacobsen, Interop Company
- Ronald Jacoby, Silicon Graphics, Inc.
- Satish Joshi, SynOptics Communications, Inc.
- Frank Kastenholz, FTP Software
- Mark Kepke, Hewlett-Packard
- Ken Key, SNMP Research, Inc.
- Zbiginew Kielczewski, Eicon
- Jongyeoi Kim
- Andrew Knutsen, The Santa Cruz Operation
- Michael L. Kornegay, VisiSoft
- Deirdre C. Kostik, Bellcore
- Cheryl Krupczak, Georgia Tech
- Mark S. Lewis, Telebit
- David Lin
- David Lindemulder, AT&T/NCR
- Ben Lisowski, Sprint
- David Liu, Bell-Northern Research
- John Lunny, The Wollongong Group
- Robert C. Lushbaugh Martin, Marietta Energy Systems
- Michael Luufer, BBN
- Carl Madison, Star-Tek, Inc.
- Keith McCloghrie, Hughes LAN Systems
- Evan McGinnis, 3Com Corporation
- Bill McKenzie, IBM Corporation
- Donna McMaster, SynOptics Communications, Inc.
- John Medicke, IBM Corporation
- Doug Miller, Telebit
- Dave Minnich, FiberCom
- Mohammad Mirhakkak, MITRE
- Rohit Mital, Protools
- George Mouradian, AT&T Bell Labs
- Patrick Mullaney, Cabletron Systems
- Dan Myers, 3Com Corporation
- Rina Nathaniel, Rad Network Devices Ltd.
- Hien V. Nguyen, Sprint
- Mo Nikain
- Tom Nisbet
- William B. Norton, MERIT
- Steve Onishi, Wellfleet Communications, Inc.
- David T. Perkins, SynOptics Communications, Inc.
- Carl Powell, BBN
- Ilan Raab, SynOptics Communications, Inc.
- Richard Ramons, AT&T
- Venkat D. Rangan, Metric Network Systems, Inc.
- Louise Reingold, Sprint
- Sam Roberts, Farallon Computing, Inc.
- Kary Robertson, Concord Communications, Inc.
- Dan Romascanu, Lannet Data Communications Ltd.
- Marshall T. Rose, Dover Beach Consulting, Inc.
- Shawn A. Routhier, Epilogue Technology Corporation
- Chris Rozman
- Asaf Rubissa, Fibronics
- Jon Saperia, Digital Equipment Corporation
- Michael Sapich
- Mike Scanlon, Interlan
- Sam Schaen, MITRE
- John Seligson, Ultra Network Technologies
- Paul A. Serice, Corporation for Open Systems
- Chris Shaw, Banyan Systems
- Timon Sloane
- Robert Snyder, Cisco Systems
- Joo Young Song
- Roy Spitier, Sprint
- Einar Stefferud, Network Management Associates
- John Stephens, Cayman Systems, Inc.
- Robert L. Stewart, Xyplex, Inc. (chair)
- Kaj Tesink, Bellcore
- Dean Throop, Data General
- Ahmet Tuncay, France Telecom-CNET
- Maurice Turcotte, Racal Datacom
- Warren Vik, INTERACTIVE Systems Corporation
- Yannis Viniotis
- Steven L. Waldbusser, Carnegie Mellon Universitty
- Timothy M. Walden, ACC
- Alice Wang, Sun Microsystems
- James Watt, Newbridge
- Luanne Waul, Timeplex
- Donald E. Westlake III, Digital Equipment Corporation
- Gerry White
- Bert Wijnen, IBM Corporation
- Peter Wilson, 3Com Corporation
- Steven Wong, Digital Equipment Corporation
- Randy Worzella, IBM Corporation
- Daniel Woycke, MITRE
- Honda Wu
- Jeff Yarnell, Protools
- Chris Young, Cabletron
- Kiho Yum, 3Com Corporation
5. 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] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.
6. Security Considerations 🔥
Heads up, this one's short and serious: security issues are not discussed in this memo. 🙈
7. Authors' Addresses 💌
Jeffrey D. Case
SNMP Research, Inc.
3001 Kimberlin Heights Rd.
Knoxville, TN 37920-9716
US
Phone: +1 615 573 1434
Email: case@snmp.com
Keith McCloghrie
Hughes LAN Systems
1225 Charleston Road
Mountain View, CA 94043
US
Phone: +1 415 966 7934
Email: kzm@hls.com
Marshall T. Rose
Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA 94043-2186
US
Phone: +1 415 968 1052
Email: mrose@dbc.mtview.ca.us
Steven Waldbusser
Carnegie Mellon University
4910 Forbes Ave
Pittsburgh, PA 15213
US
Phone: +1 412 268 6628
Email: waldbusser@cmu.edu📦 where this page comes from
- ietf: rfc1443 1993-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms