doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc1065.txt b/doc/rfc/rfc1065.txt
new file mode 100644
index 0000000..cb99631
--- /dev/null
+++ b/doc/rfc/rfc1065.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group                                            M. Rose
+Request for Comments: 1065                                 K. McCloghrie
+                                                                     TWG
+                                                             August 1988
+
+
+
+         Structure and Identification of Management Information
+                       for TCP/IP-based internets
+
+                           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
+
+1.  Status of this Memo
+
+   This memo provides the common definitions for the structure and
+   identification of management information for TCP/IP-based internets.
+   In particular, together with its companion memos which describe the
+   initial management information base along with the initial network
+   management protocol, these documents provide a simple, workable
+
+
+
+Rose & McCloghrie                                               [Page 1]
+
+RFC 1065                          SMI                        August 1988
+
+
+   architecture and system for managing TCP/IP-based internets and in
+   particular, the Internet.
+
+   This memo specifies a draft standard for the Internet community.
+   TCP/IP implementations in the Internet which are network manageable
+   are expected to adopt and implement this specification.
+
+   Distribution of this memo is unlimited.
+
+2.  Introduction
+
+   This memo describes the common structures and identification scheme
+   for the definition of management information used in managing
+   TCP/IP-based internets.  Included are descriptions of an object
+   information model for network management along with a set of generic
+   types used to describe management information.  Formal descriptions
+   of the structure are given using Abstract Syntax Notation One (ASN.1)
+   [1].
+
+   This memo is largely concerned with organizational concerns and
+   administrative policy: it neither specifies the objects which are
+   managed, nor the protocols used to manage those objects.  These
+   concerns are addressed 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 based in part on the work of the Internet Engineering
+   Task Force, particularly the working note titled "Structure and
+   Identification of Management Information for the Internet" [4].  This
+   memo uses a skeletal structure derived from that note, but differs in
+   one very significant way:that note focuses entirely on the use of
+   OSI-style network management.  As such, it is not suitable for use in
+   the short-term for which a non-OSI protocol, the SNMP, has been
+   designated as the standard.
+
+   This memo attempts to achieve two goals: simplicity and
+   extensibility.  Both are motivated by a common concern: although the
+   management of TCP/IP-based internets has been a topic of study for
+   some time, the authors do not feel that the depth and breadth of such
+   understanding is complete.  More bluntly, we feel that previous
+   experiences, while giving the community insight, are hardly
+   conclusive.  By fostering a simple SMI, the minimal number of
+   constraints are imposed on future potential approaches; further, by
+   fostering an extensible SMI, the maximal number of potential
+   approaches are available for experimentation.
+
+   It is believed that this memo and its two companions comply with the
+   guidelines set forth in RFC 1052, "IAB Recommendations for the
+
+
+
+Rose & McCloghrie                                               [Page 2]
+
+RFC 1065                          SMI                        August 1988
+
+
+   Development of Internet Network Management Standards" [5].  In
+   particular, we feel that this memo, along with the memo describing
+   the initial management information base, provide a solid basis for
+   network management of the Internet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & McCloghrie                                               [Page 3]
+
+RFC 1065                          SMI                        August 1988
+
+
+3.  Structure and Identification of Management Information
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  Objects in the MIB are
+   defined using Abstract Syntax Notation One (ASN.1) [1].
+
+   Each type of object (termed an object type) has a name, a syntax, and
+   an encoding.  The name is represented uniquely as an OBJECT
+   IDENTIFIER.  An OBJECT IDENTIFIER is an administratively assigned
+   name.  The administrative policies used for assigning names are
+   discussed later in this memo.
+
+   The syntax for an object type defines the abstract data structure
+   corresponding to that object type.  For example, the structure of a
+   given object type might be an INTEGER or OCTET STRING.  Although in
+   general, we should permit any ASN.1 construct to be available for use
+   in defining the syntax of an object type, this memo purposely
+   restricts the ASN.1 constructs which may be used.  These restrictions
+   are made solely for the sake of simplicity.
+
+   The encoding of an object type is simply how instances of that object
+   type are represented using the object's type syntax.  Implicitly tied
+   to the notion of an object's syntax and encoding is how the object is
+   represented when being transmitted on the network.  This memo
+   specifies the use of the basic encoding rules of ASN.1 [6].
+
+   It is beyond the scope of this memo to define either the initial MIB
+   used for network management or the network management protocol.  As
+   mentioned earlier, these tasks are left to the companion memos.  This
+   memo attempts to minimize the restrictions placed upon its companions
+   so as to maximize generality.  However, in some cases, restrictions
+   have been made (e.g., the syntax which may be used when defining
+   object types in the MIB) in order to encourage a particular style of
+   management.  Future editions of this memo may remove these
+   restrictions.
+
+3.1.  Names
+
+   Names are used to identify managed objects.  This memo specifies
+   names which are hierarchical in nature.  The OBJECT IDENTIFIER
+   concept is used to model this notion.  An OBJECT IDENTIFIER can be
+   used for purposes other than naming managed object types; for
+   example, each international standard has an OBJECT IDENTIFIER
+   assigned to it for the purposes of identification.  In short, OBJECT
+   IDENTIFIERs are a means for identifying some object, regardless of
+   the semantics associated with the object (e.g., a network object, a
+   standards document, etc.)
+
+
+
+
+Rose & McCloghrie                                               [Page 4]
+
+RFC 1065                          SMI                        August 1988
+
+
+   An OBJECT IDENTIFIER is a sequence of integers which traverse a
+   global tree.  The tree consists of a root connected to a number of
+   labeled nodes via edges.  Each node may, in turn, have children of
+   its own which are labeled.  In this case, we may term the node a
+   subtree.  This process may continue to an arbitrary level of depth.
+   Central to the notion of the OBJECT IDENTIFIER is the understanding
+   that administrative control of the meanings assigned to the nodes may
+   be delegated as one traverses the tree.  A label is a pairing of a
+   brief textual description and an integer.
+
+   The root node itself is unlabeled, but has at least three children
+   directly under it:  one node is administered by the International
+   Standards Organization, with label iso(1); another is administrated
+   by the International Telegraph and Telephone Consultative Committee,
+   with label ccitt(2); and the third is jointly administered by the ISO
+   and the CCITT, 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 have been assigned to the U.S. National Bureau of
+   Standards.  One of these subtrees has been transferred by the NBS to
+   the U.S. Department of Defense, dod(6).
+
+   As of this writing, the DoD has not indicated how it will manage its
+   subtree of OBJECT IDENTIFIERs.  This memo assumes that DoD will
+   allocate a node to the Internet community, to be administered by the
+   Internet Activities Board (IAB) as follows:
+
+      internet    OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
+
+   That is, the Internet subtree of OBJECT IDENTIFIERs starts with the
+   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 use with a future memo that
+   discusses how the OSI Directory may be used in the Internet.
+
+
+
+Rose & McCloghrie                                               [Page 5]
+
+RFC 1065                          SMI                        August 1988
+
+
+3.1.2.  MGMT
+
+   The mgmt(2) subtree is used to identify objects which are defined in
+   IAB-approved documents.  Administration of the mgmt(2) subtree is
+   delegated by the IAB to the Assigned Numbers authority for the
+   Internet.  As RFCs which define new versions of the Internet-standard
+   Management Information Base are approved, they are assigned an OBJECT
+   IDENTIFIER by the Assigned Numbers authority for identifying the
+   objects defined by that memo.
+
+   For example, the RFC which 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.1
+
+   in 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 used to identify objects used in
+   Internet experiments.  Administration of the experimental(3) subtree
+   is delegated by the IAB to the Assigned Numbers authority of the
+   Internet.
+
+   For example, an experimenter might received number 17, and would have
+   available the OBJECT IDENTIFIER
+
+      { experimental 17 }
+
+   or
+
+      1.3.6.1.3.17
+
+   for use.
+
+   As a part of the assignment process, the Assigned Numbers authority
+   may make requirements as to how that subtree is used.
+
+
+
+
+
+Rose & McCloghrie                                               [Page 6]
+
+RFC 1065                          SMI                        August 1988
+
+
+3.1.4.  PRIVATE
+
+   The private(4) subtree is used to identify objects defined
+   unilaterally.  Administration of the private(4) subtree is delegated
+   by the IAB to the 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 permit
+   parties providing networking subsystems to register models of their
+   products.
+
+   Upon receiving a subtree, the enterprise may, for example, define new
+   MIB objects in this subtree.  In addition, it is strongly recommended
+   that the enterprise will also register its networking subsystems
+   under this subtree, in order to provide an unambiguous identification
+   mechanism for use in management protocols.  For example, if the
+   "Flintstones, Inc."  enterprise produced networking subsystems, then
+   they could request a node under the enterprises subtree from the
+   Assigned Numbers authority.  Such a node might be numbered:
+
+      1.3.6.1.4.1.42
+
+   The "Flintstones, Inc." enterprise might then register their "Fred
+   Router" under the name of:
+
+      1.3.6.1.4.1.42.1.1
+
+3.2.  Syntax
+
+   Syntax is used to define the structure corresponding 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
+
+
+
+Rose & McCloghrie                                               [Page 7]
+
+RFC 1065                          SMI                        August 1988
+
+
+   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 which
+
+
+
+Rose & McCloghrie                                               [Page 8]
+
+RFC 1065                          SMI                        August 1988
+
+
+   monotonically increases until it reaches a maximum value, when 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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & McCloghrie                                               [Page 9]
+
+RFC 1065                          SMI                        August 1988
+
+
+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 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 also facilitates simple table mappings for
+   user interfaces.
+
+4.2.  Object Types and Instances
+
+   An object type is a definition of a kind of managed object; it is
+
+
+
+Rose & McCloghrie                                              [Page 10]
+
+RFC 1065                          SMI                        August 1988
+
+
+   declarative in nature.  In contrast, an object instance is an
+   instantiation of an object type which 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; individual
+   entries in a particular routing table which 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.
+
+
+
+Rose & McCloghrie                                              [Page 11]
+
+RFC 1065                          SMI                        August 1988
+
+
+   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.
+
+
+
+
+Rose & McCloghrie                                              [Page 12]
+
+RFC 1065                          SMI                        August 1988
+
+
+   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
+
+
+
+Rose & McCloghrie                                              [Page 13]
+
+RFC 1065                          SMI                        August 1988
+
+
+      { 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
+
+   In order to facilitate the use of tools for processing the definition
+   of the MIB, the OBJECT-TYPE macro may be used.  This macro permits
+   the key aspects of an object type to be represented in a formal way.
+
+      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
+
+   Given the object types defined earlier, we might imagine the
+   following definitions being present in the MIB:
+
+                  atIndex OBJECT-TYPE
+
+
+
+Rose & McCloghrie                                              [Page 14]
+
+RFC 1065                          SMI                        August 1988
+
+
+                          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, relating, for
+   example, the OBJECT DESCRIPTOR atIndex to the OBJECT IDENTIFIER {
+   atEntry 1 }.  In addition, the syntax of this object is defined
+   (INTEGER) along with the access permitted (read-write) and status
+   (mandatory).  The sixth definition describes an ASN.1 type called
+   AtEntry.
+
+
+
+
+
+
+
+Rose & McCloghrie                                              [Page 15]
+
+RFC 1065                          SMI                        August 1988
+
+
+5.  Extensions to the MIB
+
+   Every Internet-standard MIB document obsoletes all previous such
+   documents.  The portion of a name, termed the tail, following the
+   OBJECT IDENTIFIER
+
+      { mgmt version-number }
+
+   used to name objects shall remain unchanged between versions.  New
+   versions may:
+
+      (1) declare old object types obsolete (if necessary), but not
+      delete their names;
+
+      (2) 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,
+
+      (3) define entirely new object types.
+
+   New versions may not:
+
+      (1) change the semantics of any previously defined object without
+      changing the name of that object.
+
+   These rules are important because they admit easier support for
+   multiple versions of the Internet-standard MIB.  In particular, the
+   semantics associated with the tail of a name remain constant
+   throughout different versions of the MIB.  Because multiple versions
+   of the MIB may thus coincide in "tail-space," implementations
+   supporting multiple versions of the MIB can be vastly simplified.
+
+   However, as a consequence, a management agent might return an
+   instance corresponding to a superset of the expected object type.
+   Following the principle of robustness, in this exceptional case, a
+   manager should ignore any additional information beyond the
+   definition of the expected object type.  However, the robustness
+   principle requires that one exercise care with respect to control
+   actions: if an instance does not 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 an operation.
+
+
+
+
+
+
+
+
+
+Rose & McCloghrie                                              [Page 16]
+
+RFC 1065                          SMI                        August 1988
+
+
+6.  Definitions
+
+           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
+
+
+
+
+Rose & McCloghrie                                              [Page 17]
+
+RFC 1065                          SMI                        August 1988
+
+
+               -- 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
+
+
+
+Rose & McCloghrie                                              [Page 18]
+
+RFC 1065                          SMI                        August 1988
+
+
+                  -- 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"
+
+                  END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & McCloghrie                                              [Page 19]
+
+RFC 1065                          SMI                        August 1988
+
+
+7.  Acknowledgements
+
+   This memo was influenced by three sets of contributors:
+
+   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 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
+
+
+
+
+
+
+
+
+
+
+
+Rose & McCloghrie                                              [Page 20]
+
+RFC 1065                          SMI                        August 1988
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & McCloghrie                                              [Page 21]
+
\ No newline at end of file