RFC 1065
Structure and identification of management information for TCP/IP-based internets
RFC 1065: Structure and Identification of Management Information for TCP/IP-based internets 🎀
okay bestie, the title block is giving nostalgia 🌸. This is RFC 1065 from the Network Working Group, written by M. Rose and K. McCloghrie (both at TWG 💜) and dated August 1988 📅. Its status is draft standard, which Section 1 spells out 💅. The header doesn't list anything it obsoletes or updates, so there's nothing to cross-check there ✨.
Table of Contents 📚
1. Status of this Memo ............................................. 1
2. Introduction .................................................... 2
3. Structure and Identification of Management Information........... 4
3.1 Names .......................................................... 4
3.1.1 DIRECTORY .................................................... 5
3.1.2 MGMT ......................................................... 6
3.1.3 EXPERIMENTAL ................................................. 6
3.1.4 PRIVATE ...................................................... 7
3.2 Syntax ......................................................... 7
3.2.1 Primitive Types .............................................. 7
3.2.1.1 Guidelines for Enumerated INTEGERs ......................... 7
3.2.2 Constructor Types ............................................ 8
3.2.3 Defined Types ................................................ 8
3.2.3.1 NetworkAddress ............................................. 8
3.2.3.2 IpAddress .................................................. 8
3.2.3.3 Counter .................................................... 8
3.2.3.4 Gauge ...................................................... 9
3.2.3.5 TimeTicks .................................................. 9
3.2.3.6 Opaque ..................................................... 9
3.3 Encodings ...................................................... 9
4. Managed Objects ................................................. 10
4.1 Guidelines for Object Names .................................... 10
4.2 Object Types and Instances ..................................... 10
4.3 Macros for Managed Objects ..................................... 14
5. Extensions to the MIB ........................................... 16
6. Definitions ..................................................... 17
7. Acknowledgements ................................................ 20
8. References ...................................................... 211. Status of this Memo ✨
This memo is the shared foundation for how management information is structured and identified in TCP/IP-based internets 🧱. Its companion memos cover the initial management information base and the initial network management protocol, and together the three make a simple, workable system for managing TCP/IP-based internets, the Internet especially 🌐.
This memo is a draft standard for the Internet community. TCP/IP implementations on the Internet that are network manageable are expected to adopt and implement this specification 🫶.
Distribution of this memo is unlimited 🦋.
2. Introduction 💖
This memo covers the common structures and identification scheme for defining management information used when managing TCP/IP-based internets. It describes an object information model for network management, plus a set of generic types for describing management information 🧩. The formal descriptions are written in Abstract Syntax Notation One (ASN.1) [1].
Honestly, this memo is mostly about organizational stuff and admin policy 📋. It doesn't specify the objects being managed, and it doesn't specify the protocols used to manage them. Two companion memos take care of that: one describing the Management Information Base (MIB) [2], and one describing the Simple Network Management Protocol (SNMP) [3].
This memo is partly based on the work of the Internet Engineering Task Force, especially the working note titled "Structure and Identification of Management Information for the Internet" [4]. It borrows a skeletal structure from that note, but it differs in one very significant way: that note focuses entirely on OSI-style network management. That makes it unsuitable for the short term, when a non-OSI protocol, the SNMP, has been designated as the standard 🙈.
This memo has two goals: simplicity and extensibility ✨. Both come from the same concern. Management of TCP/IP-based internets has been studied for a while, but the authors don't feel their understanding is complete. More bluntly, previous experiences gave the community insight but aren't conclusive 🤷♀️. A simple SMI puts the fewest constraints on future approaches. An extensible SMI keeps the most potential approaches open for experimentation 🧪.
This memo and its two companions are believed to comply with the guidelines in RFC 1052, "IAB Recommendations for the Development of Internet Network Management Standards" [5]. Especially, this memo plus the memo on the initial management information base give a solid basis for network management of the Internet 💅.
3. Structure and Identification of Management Information 🎀
Managed objects are accessed through a virtual information store called the Management Information Base, or MIB. Objects in the MIB are defined using ASN.1 [1] 🧠.
Each type of object (an object type) has a name, a syntax, and an encoding 🏷️. The name is uniquely represented as an OBJECT IDENTIFIER, which is an administratively assigned name. The admin policies for assigning names get discussed later in this memo.
The syntax of an object type defines the abstract data structure for that object type. For example, the structure of an object type might be an INTEGER or an OCTET STRING. In general, we could allow any ASN.1 construct to define the syntax of an object type, but this memo purposely restricts which ASN.1 constructs can be used. These restrictions are made solely for the sake of simplicity 🫧.
The encoding of an object type is how instances of that type get represented using the object's type syntax. Tied closely to syntax and encoding is how the object is represented when it's transmitted on the network. This memo specifies the use of the basic encoding rules of ASN.1 [6] 📦.
Defining the initial MIB or the network management protocol is beyond the scope of this memo. Those jobs go to the companion memos. This memo tries to minimize the restrictions it places on its companions, to keep things as general as possible. Still, some restrictions exist (for example, the syntax you can use when defining object types in the MIB) to encourage a particular style of management 👑. Future editions of this memo may remove these restrictions.
3.1. Names 🏷️
Names identify managed objects, and this memo specifies names that are hierarchical in nature 🌳. The OBJECT IDENTIFIER concept models that idea. OBJECT IDENTIFIERs can do more than name managed object types. For instance, each international standard gets an OBJECT IDENTIFIER for identification. Basically, an OBJECT IDENTIFIER is a way to identify some object regardless of what it means, whether that's a network object, a standards document, or something else 💜.
An OBJECT IDENTIFIER is a sequence of integers that traverses a global tree. The tree has a root connected to a bunch of labeled nodes through edges. Each node can have labeled children of its own, and a node with children can be called a subtree. This can keep going to any depth. The key idea is that administrative control of the meanings assigned to nodes can be delegated as you move down the tree 🪜. A label is a brief textual description paired with an integer.
The root node itself is unlabeled, but it has at least three children directly under it. One node is administered by the International Standards Organization, labeled iso(1). Another is administered by the International Telegraph and Telephone Consultative Committee, labeled ccitt(2). The third is jointly administered by the ISO and the CCITT, labeled joint-iso-ccitt(3) 🌍.
Under the iso(1) node, the ISO has designated one subtree for use by other (inter)national organizations, org(3). Of the children nodes present, two were assigned to the U.S. National Bureau of Standards. One of those subtrees was transferred by the NBS to the U.S. Department of Defense, dod(6) 🇺🇸.
As of this writing, the DoD hasn't said how it'll manage its subtree of OBJECT IDENTIFIERs. This memo assumes the DoD will allocate a node to the Internet community, to be administered by the Internet Activities Board (IAB) like this:
internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }So the Internet subtree of OBJECT IDENTIFIERs starts with this prefix:
1.3.6.1.This memo, as an RFC approved by the IAB, now specifies the policy under which this subtree of OBJECT IDENTIFIERs is administered. Initially, four nodes are present ✨:
directory OBJECT IDENTIFIER ::= { internet 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }3.1.1. DIRECTORY 📂
The directory(1) subtree is reserved for a future memo that discusses how the OSI Directory may be used in the Internet 🔮.
3.1.2. MGMT 📊
The mgmt(2) subtree identifies objects defined in IAB-approved documents 🗂️. The IAB has delegated administration of the mgmt(2) subtree to the Assigned Numbers authority for the Internet. As RFCs defining new versions of the Internet-standard Management Information Base get approved, the Assigned Numbers authority gives each one an OBJECT IDENTIFIER for identifying the objects defined in that memo 🎫.
For example, the RFC that defines the initial Internet-standard MIB would be assigned management document number 1. That RFC would use the OBJECT IDENTIFIER:
{ mgmt 1 }or
1.3.6.1.2.1in defining the Internet-standard MIB.
Generating new versions of the Internet-standard MIB is a rigorous process 🧐. Section 5 of this memo describes the rules used when a new version is defined.
3.1.3. EXPERIMENTAL 🧪
The experimental(3) subtree identifies objects used in Internet experiments 🔬. The IAB has delegated administration of the experimental(3) subtree to the Assigned Numbers authority of the Internet.
For example, an experimenter might receive number 17, and would then have the OBJECT IDENTIFIER:
{ experimental 17 }or
1.3.6.1.3.17available for use 🌈.
As part of the assignment process, the Assigned Numbers authority may make requirements about how that subtree is used. Stay tuned for 3.1.4 PRIVATE 👀🧚
3.1.4. PRIVATE 🦋
okay so the private(4) subtree is for stuff that gets defined unilaterally 🫶 meaning one party just decides it, no committee needed. Administration of this subtree is delegated by the IAB to the Assigned Numbers authority for the Internet 👑. Right now it has at least one child:
enterprises OBJECT IDENTIFIER ::= { private 1 }The enterprises(1) subtree is used, among other things, to let networking folks register models of their products 💖
Once an enterprise receives a subtree, it MAY, for example, define new MIB objects in there ✨ It's also strongly RECOMMENDED that the enterprise registers its networking subsystems under this subtree too, so management protocols have an unambiguous way to identify them 🧚 Say the "Flintstones, Inc." enterprise makes networking subsystems. They could request a node under the enterprises subtree from the Assigned Numbers authority, and that node might be numbered:
1.3.6.1.4.1.42Then the "Flintstones, Inc." enterprise could register their "Fred Router" under the name of:
1.3.6.1.4.1.42.1.13.2. Syntax 💅
Syntax is used to define the structure that corresponds to object types. ASN.1 constructs are used to define this structure, although the full generality of ASN.1 is not permitted 🙈
The ASN.1 type ObjectSyntax defines the different syntaxes which MAY be used in defining an object type 🎀
3.2.1. Primitive Types 🌸
Only the ASN.1 primitive types INTEGER, OCTET STRING, OBJECT IDENTIFIER, and NULL are permitted. These are sometimes referred to as non-aggregate types 🍓
3.2.1.1. Guidelines for Enumerated INTEGERs 🙅♀️
If an enumerated INTEGER is listed as an object type, then a named-number having the value 0 SHALL NOT be present in the list of enumerations. Using this value is prohibited 🚫
3.2.2. Constructor Types 🧸
The ASN.1 constructor type SEQUENCE is permitted, providing that it is used to generate either lists or tables ✨
For lists, the syntax takes the form:
SEQUENCE { <type1>, ..., <typeN> }where each <type> resolves to one of the ASN.1 primitive types listed above. Further, these ASN.1 types are always present (the DEFAULT and OPTIONAL clauses do not appear in the SEQUENCE definition) 💀
For tables, the syntax takes the form:
SEQUENCE OF <entry>where <entry> resolves to a list constructor.
Lists and tables are sometimes referred to as aggregate types 🌈
3.2.3. Defined Types 🧁
In addition, new application-wide types MAY be defined, so long as they resolve into an IMPLICITly defined ASN.1 primitive type, list, table, or some other application-wide type. Initially, few application-wide types are defined. Future memos will no doubt define others once a consensus is reached 🫶
3.2.3.1. NetworkAddress 🌐
This CHOICE represents an address from one of possibly several protocol families. Currently, only one protocol family, the Internet family, is present in this CHOICE 🦋
3.2.3.2. IpAddress 🍑
This application-wide type represents a 32-bit internet address. It is represented as an OCTET STRING of length 4, in network byte-order 🔥
When this ASN.1 type is encoded using the ASN.1 basic encoding rules, only the primitive encoding form SHALL be used 🙌
3.2.3.3. Counter 🔢
This application-wide type represents a non-negative integer which monotonically increases until it reaches a maximum value. When it hits that maximum, it wraps around and starts increasing again from zero 🔄 This memo specifies a maximum value of 2^32-1 (4294967295 decimal) for counters.
3.2.3.4. Gauge 📈
This application-wide type represents a non-negative integer, which MAY increase or decrease, but which latches at a maximum value 💜 This memo specifies a maximum value of 2^32-1 (4294967295 decimal) for gauges.
3.2.3.5. TimeTicks ⏱️
This application-wide type represents a non-negative integer which counts the time in hundredths of a second since some epoch. When object types are defined in the MIB which use this ASN.1 type, the description of the object type identifies the reference epoch 🕰️
3.2.3.6. Opaque 🎁
This application-wide type supports the capability to pass arbitrary ASN.1 syntax. A value is encoded using the ASN.1 basic rules into a string of octets. That, in turn, is encoded as an OCTET STRING, which is effectively "double-wrapping" the original ASN.1 value 🪆
A conforming implementation need only be able to accept and recognize opaquely-encoded data. It need not be able to unwrap the data and then interpret its contents. ⚠️
Further note that by use of the ASN.1 EXTERNAL type, encodings other than ASN.1 MAY be used in opaquely-encoded data 🌟
3.3. Encodings 🎶
Once an instance of an object type has been identified, its value MAY be transmitted by applying the basic encoding rules of ASN.1 to the syntax for the object type 📨
4. Managed Objects 📦
Although it is not the purpose of this memo to define objects in the MIB, this memo specifies a format for other memos to use when they define these objects 🧩
An object type definition consists of five fields:
OBJECT:A textual name, termed the OBJECT DESCRIPTOR, for the object type, along with its corresponding OBJECT IDENTIFIER.Syntax:The abstract syntax for the object type. This MUST resolve to an instance of the ASN.1 type ObjectSyntax (defined below).Definition:A textual description of the semantics of the object type. Implementations SHOULD ensure that their instance of the object fulfills this definition, since this MIB is intended for use in multi-vendor environments. As such, it is vital that objects have consistent meaning across all machines 🤝Access:One of read-only, read-write, write-only, or not-accessible.Status:One of mandatory, optional, or obsolete.
Future memos MAY also specify other fields for the objects which they define 🍭
4.1. Guidelines for Object Names 🏷️
No object type in the Internet-Standard MIB SHALL use a sub-identifier of 0 in its name. This value is reserved for use with future extensions 🚧
Each OBJECT DESCRIPTOR corresponding to an object type in the internet-standard MIB SHALL be a unique, but mnemonic, printable string. This promotes a common language for humans to use when discussing the MIB, and it also makes simple table mappings for user interfaces easier 🗣️✨
4.2. Object Types and Instances 🧠
An object type is a definition of a kind of managed object, and it is declarative in nature. In contrast, an object instance is an instantiation of an object type that has been bound to a value. For example, the notion of an entry in a routing table might be defined in the MIB. Such a notion corresponds to an object type, and individual entries in a particular routing table that exist at some time are object instances of that object type 🛣️
A collection of object types is defined in the MIB. Each such subject type is uniquely named by its OBJECT IDENTIFIER and also has a textual name, which is its OBJECT DESCRIPTOR. The means whereby object instances are referenced is not defined in the MIB. Reference to object instances is achieved by a protocol-specific mechanism: it is the responsibility of each management protocol adhering to the SMI to define this mechanism 🔑
An object type MAY be defined in the MIB such that an instance of that object type represents an aggregation of information also represented by instances of some number of "subordinate" object types. For example, suppose the following object types are defined in the MIB:
OBJECT:
-------
atIndex { atEntry 1 }
Syntax:
INTEGER
Definition:
The interface number for the physical address.
Access:
read-write.
Status:
mandatory.
OBJECT:
-------
atPhysAddress { atEntry 2 }
Syntax:
OCTET STRING
Definition:
The media-dependent physical address.
Access:
read-write.
Status:
mandatory.
OBJECT:
-------
atNetAddress { atEntry 3 }
Syntax:
NetworkAddress
Definition:
The network address corresponding to the media-dependent physical
address.
Access:
read-write.
Status:
mandatory.Then, a fourth object type might also be defined in the MIB:
OBJECT:
-------
atEntry { atTable 1 }
Syntax:
AtEntry ::= SEQUENCE {
atIndex
INTEGER,
atPhysAddress
OCTET STRING,
atNetAddress
NetworkAddress
}
Definition:
An entry in the address translation table.
Access:
read-write.
Status:
mandatory.Each instance of this object type comprises information represented by instances of the former three object types. An object type defined in this way is called a list 📋
Similarly, tables can be formed by aggregations of a list type. For example, a fifth object type might also be defined in the MIB:
OBJECT:
------
atTable { at 1 }
Syntax:
SEQUENCE OF AtEntry
Definition:
The address translation table.
Access:
read-write.
Status:
mandatory.such that each instance of the atTable object comprises information represented by the set of atEntry object types that collectively constitute a given atTable object instance, that is, a given address translation table 🗂️
Consider how one might refer to a simple object within a table. Continuing with the previous example, one might name the object type:
{ atPhysAddress }and specify, using a protocol-specific mechanism, the object instance:
{ atNetAddress } = { internet "10.0.0.52" }This pairing of object type and object instance would refer to all instances of atPhysAddress which are part of any entry in some address translation table for which the associated atNetAddress value is { internet "10.0.0.52" } 🎯
To continue with this example, consider how one might refer to an aggregate object (list) within a table. Naming the object type:
{ atEntry }and specifying, using a protocol-specific mechanism, the object instance:
{ atNetAddress } = { internet "10.0.0.52" }refers to all instances of entries in the table for which the associated atNetAddress value is { internet "10.0.0.52" } 💖
Each management protocol MUST provide a mechanism for accessing simple (non-aggregate) object types. Each management protocol specifies whether or not it supports access to aggregate object types. Further, the protocol MUST specify which instances are "returned" when an object type/instance pairing refers to more than one instance of a type 🧐
To afford support for a variety of management protocols, all information by which instances of a given object type may be usefully distinguished, one from another, is represented by instances of object types defined in the MIB 🌷
4.3. Macros for Managed Objects 🎀
okay so the OBJECT-TYPE macro is giving tool-friendly energy 🛠️ It lets you show the key stuff about an object type in a formal way, so the tools can actually read your MIB definitions. it's basically "say it properly so the computer gets it" 💅
OBJECT-TYPE MACRO ::=
BEGIN
TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax)
"ACCESS" Access
"STATUS" Status
VALUE NOTATION ::= value (VALUE ObjectName)
Access ::= "read-only"
| "read-write"
| "write-only"
| "not-accessible"
Status ::= "mandatory"
| "optional"
| "obsolete"
ENDGiven the object types we already met, we could imagine these definitions showing up in the MIB 🧚
atIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
::= { atEntry 1 }
atPhysAddress OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-write
STATUS mandatory
::= { atEntry 2 }
atNetAddress OBJECT-TYPE
SYNTAX NetworkAddress
ACCESS read-write
STATUS mandatory
::= { atEntry 3 }
atEntry OBJECT-TYPE
SYNTAX AtEntry
ACCESS read-write
STATUS mandatory
::= { atTable 1 }
atTable OBJECT-TYPE
SYNTAX SEQUENCE OF AtEntry
ACCESS read-write
STATUS mandatory
::= { at 1 }
AtEntry ::= SEQUENCE {
atIndex
INTEGER,
atPhysAddress
OCTET STRING,
atNetAddress
NetworkAddress
}ok so the first five definitions are the object types 🌸 They tie the OBJECT DESCRIPTOR atIndex to the OBJECT IDENTIFIER { atEntry 1 }, and they also lock in the syntax (INTEGER), the access (read-write), and the status (mandatory). The sixth one defines an ASN.1 type called AtEntry, and honestly it's giving organized ✨
5. Extensions to the MIB 🦋
okay this part is about how the MIB is allowed to grow up over time, and the rules are lowkey strict 🔥 Every Internet-standard MIB document obsoletes all the previous ones, no cap. The tail of a name (the part that comes after the OBJECT IDENTIFIER below) SHALL remain unchanged between versions:
{ mgmt version-number }New versions MAY:
- declare old object types obsolete (if necessary), but not delete their names;
- augment the definition of an object type corresponding to a list by appending non-aggregate object types to the object types in the list; or,
- define entirely new object types.
New versions MUST NOT:
- change the semantics of any previously defined object without changing the name of that object.
these rules are SO important bc they make it way easier to support multiple versions of the Internet-standard MIB 💜 The meaning of a name's tail stays the same across every version, so multiple versions can coincide in "tail-space," and implementations that support several versions can get vastly simpler. iykyk 💅
BUT (and this is the tea 🍵) a management agent might return an instance that's a superset of the object type you expected. In that exceptional case, following the robustness principle, a manager SHOULD ignore any extra information beyond the definition of the expected object type. The robustness principle also means you have to be careful with control actions 🙈 If an instance doesn't have the same syntax as its expected object type, then those control actions MUST fail. In both the monitoring and control cases, the name of an object returned by an operation MUST be identical to the name requested by the operation. no shortcuts, bestie 🫶
6. Definitions 📜
here's the whole SMI module in one place, and it's the main event ✨
RFC1065-SMI DEFINITIONS ::= BEGIN
EXPORTS -- EVERYTHING
internet, directory, mgmt,
experimental, private, enterprises,
OBJECT-TYPE, ObjectName, ObjectSyntax, SimpleSyntax,
ApplicationSyntax, NetworkAddress, IpAddress,
Counter, Gauge, TimeTicks, Opaque;
-- the path to the root
internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
directory OBJECT IDENTIFIER ::= { internet 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }
enterprises OBJECT IDENTIFIER ::= { private 1 }
-- definition of object types
OBJECT-TYPE MACRO ::=
BEGIN
TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax)
"ACCESS" Access
"STATUS" Status
VALUE NOTATION ::= value (VALUE ObjectName)
Access ::= "read-only"
| "read-write"
| "write-only"
| "not-accessible"
Status ::= "mandatory"
| "optional"
| "obsolete"
END
-- names of objects in the MIB
ObjectName ::=
OBJECT IDENTIFIER
-- syntax of objects in the MIB
ObjectSyntax ::=
CHOICE {
simple
SimpleSyntax,
-- note that simple SEQUENCEs are not directly
-- mentioned here to keep things simple (i.e.,
-- prevent mis-use). However, application-wide
-- types which are IMPLICITly encoded simple
-- SEQUENCEs may appear in the following CHOICE
application-wide
ApplicationSyntax
}
SimpleSyntax ::=
CHOICE {
number
INTEGER,
string
OCTET STRING,
object
OBJECT IDENTIFIER,
empty
NULL
}
ApplicationSyntax ::=
CHOICE {
address
NetworkAddress,
counter
Counter,
gauge
Gauge,
ticks
TimeTicks,
arbitrary
Opaque
-- other application-wide types, as they are
-- defined, will be added here
}
-- application-wide types
NetworkAddress ::=
CHOICE {
internet
IpAddress
}
IpAddress ::=
[APPLICATION 0] -- in network-byte order
IMPLICIT OCTET STRING (SIZE (4))
Counter ::=
[APPLICATION 1]
IMPLICIT INTEGER (0..4294967295)
Gauge ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)
TimeTicks ::=
[APPLICATION 3]
IMPLICIT INTEGER
Opaque ::=
[APPLICATION 4] -- arbitrary ASN.1 value,
IMPLICIT OCTET STRING -- "double-wrapped"
END7. Acknowledgements 🫶
this memo was shaped by three groups of amazing people 💖
First, Lee Labarre of the MITRE Corporation, who wrote the NETMAN SMI [4] and laid out the basic roadmap for the SMI. main character energy 👑
Second, several people who gave really valuable comments on this memo before it first went out:
- James Davin, Proteon
- Mark S. Fedor, NYSERNet
- Craig Partridge, BBN Laboratories
- Martin Lee Schoffstall, Rensselaer Polytechnic Institute
- Wengyik Yeong, NYSERNet
Third, the IETF MIB working group 🌈
- Karl Auerbach, Epilogue Technology
- K. Ramesh Babu, Excelan
- Lawrence Besaw, Hewlett-Packard
- Jeffrey D. Case, University of Tennessee at Knoxville
- James R. Davin, Proteon
- Mark S. Fedor, NYSERNet
- Robb Foster, BBN
- Phill Gross, The MITRE Corporation
- Bent Torp Jensen, Convergent Technology
- Lee Labarre, The MITRE Corporation
- Dan Lynch, Advanced Computing Environments
- Keith McCloghrie, The Wollongong Group
- Dave Mackie, 3Com/Bridge
- Craig Partridge, BBN (chair)
- Jim Robertson, 3Com/Bridge
- Marshall T. Rose, The Wollongong Group
- Greg Satz, cisco
- Martin Lee Schoffstall, Rensselaer Polytechnic Institute
- Lou Steinberg, IBM
- Dean Throop, Data General
- Unni Warrier, Unisys
8. 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., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1066, TWG, August 1988.
[3] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple Network Management Protocol", RFC 1067, University of Tennessee at Knoxville, NYSERNet, Rensselaer Polytechnic, Proteon, August 1988.
[4] LaBarre, L., "Structure and Identification of Management Information for the Internet", Internet Engineering Task Force working note, Network Information Center, SRI International, Menlo Park, California, April 1988.
[5] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988.
[6] Information processing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Notation One (ASN.1)", International Organization for Standardization, International Standard 8825, December 1987.
📦 where this page comes from
- ietf: rfc1065 1988-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms