RFC 1155
Structure and identification of management information for TCP/IP-based internets
RFC 1155: Structure and Identification of Management Information for TCP/IP-based Internets ✨
okay bestie, let's start with the title block 🎀 This is RFC 1155, and it's called Structure and Identification of Management Information for TCP/IP-based Internets. It came from the Network Working Group, and the authors are M. Rose of Performance Systems International and K. McCloghrie of Hughes LAN Systems. It's dated May 1990. It obsoletes RFC 1065, so this one is its replacement 🦋
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 ...................................................... 21
9. Security Considerations.......................................... 21
10. Authors' Addresses.............................................. 221. Status of this Memo 🌸
okay so this RFC is a re-release of RFC 1065. The main change is the "Status of this Memo" section, plus a few tiny typo fixes. The technical content is exactly the same as RFC 1065, so nothing new is hiding in here 💅
This memo gives the shared definitions for how management information is structured and identified in TCP/IP-based internets. The vibe is that it works together with its companion memos, one describing the management information base and one describing the network management protocol. Together they give you a simple, workable setup for managing TCP/IP-based internets, and specifically the Internet itself ✨
This memo is a Standard Protocol for the Internet community. Its status is "Recommended". TCP/IP implementations on the Internet that are network manageable are expected to adopt and implement this spec 🎀
The Internet Activities Board recommends that every IP and TCP implementation be network manageable. That means implementing the Internet MIB (RFC-1156) and at least one of the two recommended management protocols, SNMP (RFC-1157) or CMOT (RFC-1095). It's worth noting that SNMP is currently a full Internet standard, while CMOT is a draft standard. For more specific info on where this standard applies, check out the Host and Gateway Requirements RFCs 🧚
For the current state and status of standard Internet protocols, go look at the latest edition of the "IAB Official Protocol Standards" RFC 🦋
Distribution of this memo is unlimited 🌈
2. Introduction 🦋
this memo describes the shared structures and identification scheme for defining management information used when managing TCP/IP-based internets. It covers an object information model for network management, plus a set of generic types for describing management information. The formal descriptions of the structure are written in Abstract Syntax Notation One (ASN.1) [1] 💜
Real talk: this memo is mostly about organizational stuff and administrative policy. It does not specify which objects get managed, and it doesn't specify the protocols used to manage them. Those things are handled by two companion memos: one describing the Management Information Base (MIB) [2], and the other describing the Simple Network Management Protocol (SNMP) [3] 🫶
This memo is partly built on the work of the Internet Engineering Task Force, especially the working note titled "Structure and Identification of Management Information for the Internet" [4]. This memo borrows a skeletal structure from that note, but it's different in one really big way: that note focuses entirely on OSI-style network management, so it isn't suitable for use with SNMP 💀
This memo has two goals: simplicity and extensibility. Both come from the same worry. Managing TCP/IP-based internets has been studied for a while, but the authors don't feel that understanding is complete, and honestly, past experience is interesting but not conclusive 🙈 By keeping the SMI simple, you put the fewest constraints on future approaches. By keeping it extensible, you leave the most possible approaches open for experimentation 🌸
It's believed that this memo and its two companions follow the guidelines from RFC 1052, "IAB Recommendations for the Development of Internet Network Management Standards" [5], and RFC 1109, "Report of the Second Ad Hoc Network Management Review Group" [6]. The authors feel that this memo, together with the memo describing the management information base, gives the Internet a solid foundation for network management 👑
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 Abstract Syntax Notation One (ASN.1) [1] ✨
Every type of object (called 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 come later in this memo 🎀
The syntax of an object type defines the abstract data structure for that object type. For example, an object type's structure might be an INTEGER or an OCTET STRING. In general, you could allow any ASN.1 construct to define an object type's syntax, but this memo purposely limits which ASN.1 constructs can be used. Those limits exist only 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 an object's syntax and encoding is how the object gets represented when it's sent over the network. This memo specifies the use of the basic encoding rules of ASN.1 [7] 🦋
The MIB used for network management and the network management protocol are both outside this memo's scope. As mentioned earlier, companion memos handle those. This memo tries to keep restrictions on its companions as light as possible, so they stay as general as possible. Still, some restrictions do exist (for example, on the syntax you can use when defining object types in the MIB) to encourage a particular style of management. Future editions of this memo might remove these restrictions 🌈
3.1. Names 🎀
names are used to identify managed objects. This memo specifies names that are hierarchical in nature, and the OBJECT IDENTIFIER concept is used to model that. An OBJECT IDENTIFIER can also be used for purposes other than naming managed object types. For example, each international standard has an OBJECT IDENTIFIER assigned to it for identification. In short, OBJECT IDENTIFIERs are a way to identify some object, no matter what it means (a network object, a standards document, and so on) 🧚
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 its own labeled children, and then that node counts as a subtree. This can keep going to any depth. The key idea is that administrative control over what the nodes mean can be delegated as you go down the tree. A label is a pairing of a short text description and 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 Organization for Standardization, labeled iso(1). Another is administered by the International Telegraph and Telephone Consultative Committee, labeled ccitt(0). The third is jointly administered by the ISO and the CCITT, labeled joint-iso-ccitt(2) ✨
Under the iso(1) node, the ISO has set aside one subtree for use by other (inter)national organizations, org(3). Of the children present, two have been assigned to the U.S. National Institutes of Standards and Technology. The NIST has transferred one of those subtrees to the U.S. Department of Defense, dod(6) 🌸
As of writing, the DoD hasn't said how it will manage its subtree of OBJECT IDENTIFIERs. This memo assumes the DoD will allocate a node to the Internet community, 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 a standard approved by the IAB, now specifies the policy for administering this subtree of OBJECT IDENTIFIERs. Four nodes are present to start with:
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 might be used on the Internet 🔥
3.1.2. Mgmt 🦋
okay so the mgmt(2) subtree is where you find objects defined in IAB-approved documents 🌸 The IAB delegates admin of this subtree to the Internet Assigned Numbers Authority for the Internet 💅 Whenever RFCs that define new versions of the Internet-standard Management Information Base get approved, the Internet Assigned Numbers Authority gives them an OBJECT IDENTIFIER to identify the objects defined in that memo ✨
For example, the RFC that defines the initial Internet standard MIB would be assigned management document number 1 🧚 This RFC would use the OBJECT IDENTIFIER
{ mgmt 1 }or
1.3.6.1.2.1in defining the Internet-standard MIB.
The generation of 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 is for identifying objects used in Internet experiments 🔬 The IAB delegates admin of this subtree to the Internet Assigned Numbers Authority of the Internet.
For example, an experimenter might receive number 17 and would have this OBJECT IDENTIFIER available for use:
{ experimental 17 }or
1.3.6.1.3.17As part of the assignment process, the Internet Assigned Numbers Authority MAY make requirements as to how that subtree is used 👀
3.1.4. Private 🌈
the private(4) subtree is for identifying objects defined unilaterally 💜 The IAB delegates admin of this subtree to the Internet Assigned Numbers Authority for the Internet. Initially, this subtree has at least one child:
enterprises OBJECT IDENTIFIER ::= { private 1 }the enterprises(1) subtree is used, among other things, to let parties providing networking subsystems register models of their products 🍓
Upon receiving a subtree, the enterprise MAY, for example, define new MIB objects in this subtree ✨ On top of that, it is strongly RECOMMENDED that the enterprise will also register its networking subsystems under this subtree, so there's an unambiguous identification mechanism for use in management protocols 🫶
For example, if the "Flintstones, Inc." enterprise produced networking subsystems, they could request a node under the enterprises subtree from the Internet Assigned Numbers Authority. Such a node might be numbered:
1.3.6.1.4.1.42The "Flintstones, Inc." enterprise might then 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, though 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. Use of 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 that monotonically increases until it reaches a maximum value. Then 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. This, in turn, is encoded as an OCTET STRING, in effect "double-wrapping" the original ASN.1 value 🌯
Note that a conforming implementation only needs to be able to accept and recognize opaquely-encoded data. It doesn't need 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 to be used by other memos which 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 typeObjectSyntax(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 ofread-only,read-write,write-only, ornot-accessible.Status:One ofmandatory,optional, orobsolete.
Future memos MAY also specify other fields for the objects which they define 💅
4.1. Guidelines for Object Names 🌸
Each object type in the Internet-Standard MIB SHALL NOT 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 also facilitates simple table mappings for user interfaces ✨
4.2. Object Types and Instances ✨
okay bestie, let's talk about object types vs instances 💅 An object type is basically a definition of a kind of managed object. It's declarative, so think of it as a blueprint 📐 An object instance is what happens when you take that blueprint and bind it to an actual value 🎀 For example, "an entry in a routing table" could be defined in the MIB. That's the object type. The individual entries sitting in a particular routing table at some point in time? Those are object instances of that type 🦋
A whole collection of object types gets defined in the MIB 🌸 Each one is uniquely named by its OBJECT IDENTIFIER, and it also has a textual name called its OBJECT DESCRIPTOR 🏷️ The MIB doesn't define how you reference object instances, though. That part is a protocol-specific mechanism, and it's each management protocol's job (for anything following the SMI) to define it 🫶
Here's the fun bit. An object type can be defined so that an instance of it represents an aggregation of info that's also represented by instances of some number of "subordinate" object types 🧚 Say the MIB has these three object types:
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 bundles up the info represented by instances of those first three object types 🎁 An object type defined this way is called a list 💜
Tables work the same way, just one level up. Tables can be formed by aggregating 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.so that each instance of the atTable object holds the info represented by the set of atEntry object types that together make up a given atTable object instance, meaning a given address translation table 📖
Now let's see how you'd refer to a simple object inside a table 👀 Continuing the example, you could name the object type
{ atPhysAddress }and then use a protocol-specific mechanism to specify the object instance
{ atNetAddress } = { internet "10.0.0.52" }That pairing refers to all instances of atPhysAddress that are part of any entry in some address translation table where the associated atNetAddress value is { internet "10.0.0.52" } 😭✨
And for an aggregate object (a list) inside a table, you name the object type
{ atEntry }and specify the object instance
{ atNetAddress } = { internet "10.0.0.52" }using that same protocol-specific mechanism. This refers to all instances of entries in the table where the associated atNetAddress value is { internet "10.0.0.52" } 🍓
Some extra rules for the group chat 📝 Each management protocol has to provide a mechanism for accessing simple (non-aggregate) object types. Each management protocol specifies whether or not it supports access to aggregate object types. And the protocol has to specify which instances are "returned" when an object type/instance pairing refers to more than one instance of a type 💅
Last but not least, to support a bunch of different management protocols, all the info that lets you tell instances of a given object type apart from one another is represented by instances of object types defined in the MIB 🌟
4.3. Macros for Managed Objects 🎀
So the tools that process MIB definitions can read them, there's an OBJECT-TYPE macro 🛠️ It lets you write the key aspects of an object type in a formal way, and it looks like this:
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"
ENDNow, using the object types we already met, here's what the MIB definitions might look like 👑
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
}The first five definitions describe object types. For example, they connect the OBJECT DESCRIPTOR atIndex with the OBJECT IDENTIFIER { atEntry 1 } 🔗 They also pin down the syntax of that object (INTEGER), the access permitted (read-write), and the status (mandatory) 🙌 The sixth definition describes an ASN.1 type called AtEntry 🧁
5. Extensions to the MIB 🦋
Every Internet-standard MIB document obsoletes all previous such documents 🚫 The part of a name that comes after the OBJECT IDENTIFIER
{ mgmt version-number }is called the tail. It's used to name objects, and the tail shall remain unchanged between versions 🔒 New versions may do three things:
- 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.
But new versions may not change the semantics of any previously defined object without changing the name of that object 🙅♀️
Why does this matter? Because it makes supporting multiple versions of the Internet-standard MIB way easier 💖 In particular, the semantics tied to the tail of a name stay constant across different versions of the MIB. Since multiple versions can coincide in "tail-space," implementations that support several versions can be vastly simplified 🧠
There's a catch, though 👀 A management agent might return an instance that corresponds to a superset of the expected object type. In that exceptional case, and following the principle of robustness, a manager should ignore any additional information beyond the definition of the expected object type 🤓 The robustness principle also requires care 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 the control cases, the name of an object returned by an operation must be identical to the name requested by an operation 🫶✨
6. Definitions ✨
okay so this part is the actual ASN.1 module, RFC1155-SMI, and it's giving blueprint 💅 It's the whole skeleton the MIB is built on: the root of the tree, the macro for describing objects, and the core types. Here it is, copied exactly 🎀
RFC1155-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 (0..4294967295)
Opaque ::=
[APPLICATION 4] -- arbitrary ASN.1 value,
IMPLICIT OCTET STRING -- "double-wrapped"
END7. Acknowledgements 🫶
bestie, this part is all the people who helped make this memo happen, and they deserve the flowers 🌸
This memo was influenced by three sets of contributors to earlier drafts:
First, Lee Labarre of the MITRE Corporation, who as author of the NETMAN SMI [4], presented the basic roadmap for the SMI.
Second, several individuals who provided valuable comments on this memo prior to its initial distribution:
- James R. 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
the whole working group is iconic, no notes 🌈👑
8. References 📚
ok the references are the homework list, so here they are exactly as written 🧚
[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 1156, Performance Systems International and Hughes LAN Systems, May 1990.
[3] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple Network Management Protocol", RFC 1157, University of Tennessee at Knoxville, Performance Systems International, Performance Systems International, and the MIT Laboratory for Computer Science, May 1990.
[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] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, IAB, August 1989.
[7] 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.
Security Considerations 💀
okay the security part is short but I'm not gonna skip it 😭 the whole thing says: Security issues are not discussed in this memo. that's it. no cap, that's the full text, and it's the kind of line you read twice 🙈
Authors' Addresses 🎀
here are the people behind the memo, with their contact details copied exactly 💖
Marshall T. Rose
PSI, Inc.
PSI California Office
P.O. Box 391776
Mountain View, CA 94039
Phone: (415) 961-3380
EMail: mrose@PSI.COM
Keith McCloghrie
The Wollongong Group
1129 San Antonio Road
Palo Alto, CA 04303
Phone: (415) 962-7160
EMail: sytek!kzm@HPLABS.HP.COMand that's the whole RFC, bestie 🦋✨ we did it, we read the entire thing, we are so smart 💅
📦 where this page comes from
- ietf: rfc1155 1990-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms