Remove RFC texts.

21 files changed, 25 insertions, 28971 deletions

diff --git a/doc/rfc/Makefile.am b/doc/rfc/Makefile.am
index 755310cf..ed884f9e 100644
--- a/doc/rfc/Makefile.am
+++ b/doc/rfc/Makefile.am
@@ -18,23 +18,4 @@
 # along with GNU Radius; if not, write to the Free Software Foundation,
 # Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 
-EXTRA_DIST = \
- rfc1157.txt\
- rfc1448.txt\
- rfc1901.txt\
- rfc1905.txt\
- rfc2138.txt\
- rfc2433.txt\
- rfc2548.txt\
- rfc2618.txt\
- rfc2619.txt\
- rfc2620.txt\
- rfc2621.txt\
- rfc2759.txt\
- rfc2865.txt\
- rfc2866.txt\
- rfc2867.txt\
- rfc2868.txt\
- rfc2869.txt\
- rfc2882.txt\
- rfc3575.txt
+EXTRA_DIST = README
diff --git a/doc/rfc/README b/doc/rfc/README
new file mode 100644
index 00000000..a9269958
--- /dev/null
+++ b/doc/rfc/README
@@ -0,0 +1,24 @@
+This is a list of RFCs used when designing GNU Mailutils. To read any
+of them, visit http://tools.ietf.org/html/rfcNNNN, replacing NNNN with
+the actual RFC number.
+
+1157    A Simple Network Management Protocol (SNMP)
+1448    Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)
+1901    Introduction to Community-based SNMPv2
+1905    Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)
+2138    Remote Authentication Dial In User Service (RADIUS)
+2433    Microsoft PPP CHAP Extensions
+2548    Microsoft Vendor-specific RADIUS Attributes
+2618    RADIUS Authentication Client MIB
+2619    RADIUS Authentication Server MIB
+2620    RADIUS Accounting Client MIB
+2621    RADIUS Accounting Server MIB
+2759    Microsoft PPP CHAP Extensions, Version 2
+2865    Remote Authentication Dial In User Service (RADIUS)
+2866    RADIUS Accounting
+2867    RADIUS Accounting Modifications for Tunnel Protocol Support
+2868    RADIUS Attributes for Tunnel Protocol Support
+2869    RADIUS Extensions
+2882    Network Access Servers Requirements: Extended RADIUS Practices
+3575    IANA Considerations for RADIUS
+
diff --git a/doc/rfc/rfc1157.txt b/doc/rfc/rfc1157.txt
deleted file mode 100644
index 262e7eb5..00000000
--- a/doc/rfc/rfc1157.txt
+++ /dev/null
@@ -1,2019 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            J. Case
-Request for Comments:  1157                                SNMP Research
-Obsoletes:  RFC 1098                                            M. Fedor
-                                       Performance Systems International
-                                                          M. Schoffstall
-                                       Performance Systems International
-                                                                J. Davin
-                                     MIT Laboratory for Computer Science
-                                                                May 1990
-
-
-              A Simple Network Management Protocol (SNMP)
-
-                           Table of Contents
-
-   1. Status of this Memo ...................................    2
-   2. Introduction ..........................................    2
-   3. The SNMP Architecture .................................    5
-   3.1 Goals of the Architecture ............................    5
-   3.2 Elements of the Architecture .........................    5
-   3.2.1 Scope of Management Information ....................    6
-   3.2.2 Representation of Management Information ...........    6
-   3.2.3 Operations Supported on Management Information .....    7
-   3.2.4 Form and Meaning of Protocol Exchanges .............    8
-   3.2.5 Definition of Administrative Relationships .........    8
-   3.2.6 Form and Meaning of References to Managed Objects ..   12
-   3.2.6.1 Resolution of Ambiguous MIB References ...........   12
-   3.2.6.2 Resolution of References across MIB Versions......   12
-   3.2.6.3 Identification of Object Instances ...............   12
-   3.2.6.3.1 ifTable Object Type Names ......................   13
-   3.2.6.3.2 atTable Object Type Names ......................   13
-   3.2.6.3.3 ipAddrTable Object Type Names ..................   14
-   3.2.6.3.4 ipRoutingTable Object Type Names ...............   14
-   3.2.6.3.5 tcpConnTable Object Type Names .................   14
-   3.2.6.3.6 egpNeighTable Object Type Names ................   15
-   4. Protocol Specification ................................   16
-   4.1 Elements of Procedure ................................   17
-   4.1.1 Common Constructs ..................................   19
-   4.1.2 The GetRequest-PDU .................................   20
-   4.1.3 The GetNextRequest-PDU .............................   21
-   4.1.3.1 Example of Table Traversal .......................   23
-   4.1.4 The GetResponse-PDU ................................   24
-   4.1.5 The SetRequest-PDU .................................   25
-   4.1.6 The Trap-PDU .......................................   27
-   4.1.6.1 The coldStart Trap ...............................   28
-   4.1.6.2 The warmStart Trap ...............................   28
-   4.1.6.3 The linkDown Trap ................................   28
-   4.1.6.4 The linkUp Trap ..................................   28
-
-
-
-Case, Fedor, Schoffstall, & Davin                               [Page 1]
-
-RFC 1157                          SNMP                          May 1990
-
-
-   4.1.6.5 The authenticationFailure Trap ...................   28
-   4.1.6.6 The egpNeighborLoss Trap .........................   28
-   4.1.6.7 The enterpriseSpecific Trap ......................   29
-   5. Definitions ...........................................   30
-   6. Acknowledgements ......................................   33
-   7. References ............................................   34
-   8. Security Considerations................................   35
-   9. Authors' Addresses.....................................   35
-
-1.  Status of this Memo
-
-   This RFC is a re-release of RFC 1098, with a changed "Status of this
-   Memo" section plus a few minor typographical corrections.  This memo
-   defines a simple protocol by which management information for a
-   network element may be inspected or altered by logically remote
-   users.  In particular, together with its companion memos which
-   describe the structure of management information along with the
-   management information base, these documents provide a simple,
-   workable architecture and system for managing TCP/IP-based internets
-   and in particular the Internet.
-
-   The Internet Activities Board recommends that all IP and TCP
-   implementations be network manageable.  This implies implementation
-   of the Internet MIB (RFC-1156) and at least one of the two
-   recommended management protocols SNMP (RFC-1157) or CMOT (RFC-1095).
-   It should be noted that, at this time, SNMP is a full Internet
-   standard and CMOT is a draft standard.  See also the Host and Gateway
-   Requirements RFCs for more specific information on the applicability
-   of this standard.
-
-   Please refer to the latest edition of the "IAB Official Protocol
-   Standards" RFC for current information on the state and status of
-   standard Internet protocols.
-
-   Distribution of this memo is unlimited.
-
-2.  Introduction
-
-   As reported in RFC 1052, IAB Recommendations for the Development of
-   Internet Network Management Standards [1], a two-prong strategy for
-   network management of TCP/IP-based internets was undertaken.  In the
-   short-term, the Simple Network Management Protocol (SNMP) was to be
-   used to manage nodes in the Internet community.  In the long-term,
-   the use of the OSI network management framework was to be examined.
-   Two documents were produced to define the management information: RFC
-   1065, which defined the Structure of Management Information (SMI)
-   [2], and RFC 1066, which defined the Management Information Base
-   (MIB) [3].  Both of these documents were designed so as to be
-
-
-
-Case, Fedor, Schoffstall, & Davin                               [Page 2]
-
-RFC 1157                          SNMP                          May 1990
-
-
-   compatible with both the SNMP and the OSI network management
-   framework.
-
-   This strategy was quite successful in the short-term: Internet-based
-   network management technology was fielded, by both the research and
-   commercial communities, within a few months.  As a result of this,
-   portions of the Internet community became network manageable in a
-   timely fashion.
-
-   As reported in RFC 1109, Report of the Second Ad Hoc Network
-   Management Review Group [4], the requirements of the SNMP and the OSI
-   network management frameworks were more different than anticipated.
-   As such, the requirement for compatibility between the SMI/MIB and
-   both frameworks was suspended.  This action permitted the operational
-   network management framework, the SNMP, to respond to new operational
-   needs in the Internet community by producing documents defining new
-   MIB items.
-
-   The IAB has designated the SNMP, SMI, and the initial Internet MIB to
-   be full "Standard Protocols" with "Recommended" status.  By this
-   action, the IAB recommends that all IP and TCP implementations be
-   network manageable and that the implementations that are network
-   manageable are expected to adopt and implement the SMI, MIB, and
-   SNMP.
-
-   As such, the current network management framework for TCP/IP- based
-   internets consists of:  Structure and Identification of Management
-   Information for TCP/IP-based Internets, which describes how managed
-   objects contained in the MIB are defined as set forth in RFC 1155
-   [5]; Management Information Base for Network Management of TCP/IP-
-   based Internets, which describes the managed objects contained in the
-   MIB as set forth in RFC 1156 [6]; and, the Simple Network Management
-   Protocol, which defines the protocol used to manage these objects, as
-   set forth in this memo.
-
-   As reported in RFC 1052, IAB Recommendations for the Development of
-   Internet Network Management Standards [1], the Internet Activities
-   Board has directed the Internet Engineering Task Force (IETF) to
-   create two new working groups in the area of network management.  One
-   group was charged with the further specification and definition of
-   elements to be included in the Management Information Base (MIB).
-   The other was charged with defining the modifications to the Simple
-   Network Management Protocol (SNMP) to accommodate the short-term
-   needs of the network vendor and operations communities, and to align
-   with the output of the MIB working group.
-
-   The MIB working group produced two memos, one which defines a
-   Structure for Management Information (SMI) [2] for use by the managed
-
-
-
-Case, Fedor, Schoffstall, & Davin                               [Page 3]
-
-RFC 1157                          SNMP                          May 1990
-
-
-   objects contained in the MIB.  A second memo [3] defines the list of
-   managed objects.
-
-   The output of the SNMP Extensions working group is this memo, which
-   incorporates changes to the initial SNMP definition [7] required to
-   attain alignment with the output of the MIB working group.  The
-   changes should be minimal in order to be consistent with the IAB's
-   directive that the working groups be "extremely sensitive to the need
-   to keep the SNMP simple."  Although considerable care and debate has
-   gone into the changes to the SNMP which are reflected in this memo,
-   the resulting protocol is not backwardly-compatible with its
-   predecessor, the Simple Gateway Monitoring Protocol (SGMP) [8].
-   Although the syntax of the protocol has been altered, the original
-   philosophy, design decisions, and architecture remain intact.  In
-   order to avoid confusion, new UDP ports have been allocated for use
-   by the protocol described in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Case, Fedor, Schoffstall, & Davin                               [Page 4]
-
-RFC 1157                          SNMP                          May 1990
-
-
-3.  The SNMP Architecture
-
-   Implicit in the SNMP architectural model is a collection of network
-   management stations and network elements.  Network management
-   stations execute management applications which monitor and control
-   network elements.  Network elements are devices such as hosts,
-   gateways, terminal servers, and the like, which have management
-   agents responsible for performing the network management functions
-   requested by the network management stations.  The Simple Network
-   Management Protocol (SNMP) is used to communicate management
-   information between the network management stations and the agents in
-   the network elements.
-
-3.1.  Goals of the Architecture
-
-   The SNMP explicitly minimizes the number and complexity of management
-   functions realized by the management agent itself.  This goal is
-   attractive in at least four respects:
-
-      (1)  The development cost for management agent software
-           necessary to support the protocol is accordingly reduced.
-
-      (2)  The degree of management function that is remotely
-           supported is accordingly increased, thereby admitting
-           fullest use of internet resources in the management task.
-
-      (3)  The degree of management function that is remotely
-           supported is accordingly increased, thereby imposing the
-           fewest possible restrictions on the form and
-           sophistication of management tools.
-
-      (4)  Simplified sets of management functions are easily
-           understood and used by developers of network management
-           tools.
-
-   A second goal of the protocol is that the functional paradigm for
-   monitoring and control be sufficiently extensible to accommodate
-   additional, possibly unanticipated aspects of network operation and
-   management.
-
-   A third goal is that the architecture be, as much as possible,
-   independent of the architecture and mechanisms of particular hosts or
-   particular gateways.
-
-3.2.  Elements of the Architecture
-
-   The SNMP architecture articulates a solution to the network
-   management problem in terms of:
-
-
-
-Case, Fedor, Schoffstall, & Davin                               [Page 5]
-
-RFC 1157                          SNMP                          May 1990
-
-
-      (1)  the scope of the management information communicated by
-           the protocol,
-
-      (2)  the representation of the management information
-           communicated by the protocol,
-
-      (3)  operations on management information supported by the
-           protocol,
-
-      (4)  the form and meaning of exchanges among management
-           entities,
-
-      (5)  the definition of administrative relationships among
-           management entities, and
-
-      (6)  the form and meaning of references to management
-           information.
-
-3.2.1.  Scope of Management Information
-
-   The scope of the management information communicated by operation of
-   the SNMP is exactly that represented by instances of all non-
-   aggregate object types either defined in Internet-standard MIB or
-   defined elsewhere according to the conventions set forth in
-   Internet-standard SMI [5].
-
-   Support for aggregate object types in the MIB is neither required for
-   conformance with the SMI nor realized by the SNMP.
-
-3.2.2.  Representation of Management Information
-
-   Management information communicated by operation of the SNMP is
-   represented according to the subset of the ASN.1 language [9] that is
-   specified for the definition of non-aggregate types in the SMI.
-
-   The SGMP adopted the convention of using a well-defined subset of the
-   ASN.1 language [9].  The SNMP continues and extends this tradition by
-   utilizing a moderately more complex subset of ASN.1 for describing
-   managed objects and for describing the protocol data units used for
-   managing those objects.  In addition, the desire to ease eventual
-   transition to OSI-based network management protocols led to the
-   definition in the ASN.1 language of an Internet-standard Structure of
-   Management Information (SMI) [5] and Management Information Base
-   (MIB) [6].  The use of the ASN.1 language, was, in part, encouraged
-   by the successful use of ASN.1 in earlier efforts, in particular, the
-   SGMP.  The restrictions on the use of ASN.1 that are part of the SMI
-   contribute to the simplicity espoused and validated by experience
-   with the SGMP.
-
-
-
-Case, Fedor, Schoffstall, & Davin                               [Page 6]
-
-RFC 1157                          SNMP                          May 1990
-
-
-   Also for the sake of simplicity, the SNMP uses only a subset of the
-   basic encoding rules of ASN.1 [10].  Namely, all encodings use the
-   definite-length form.  Further, whenever permissible, non-constructor
-   encodings are used rather than constructor encodings.  This
-   restriction applies to all aspects of ASN.1 encoding, both for the
-   top-level protocol data units and the data objects they contain.
-
-3.2.3.  Operations Supported on Management Information
-
-   The SNMP models all management agent functions as alterations or
-   inspections of variables.  Thus, a protocol entity on a logically
-   remote host (possibly the network element itself) interacts with the
-   management agent resident on the network element in order to retrieve
-   (get) or alter (set) variables.  This strategy has at least two
-   positive consequences:
-
-      (1)  It has the effect of limiting the number of essential
-           management functions realized by the management agent to
-           two:  one operation to assign a value to a specified
-           configuration or other parameter and another to retrieve
-           such a value.
-
-      (2)  A second effect of this decision is to avoid introducing
-           into the protocol definition support for imperative
-           management commands:  the number of such commands is in
-           practice ever-increasing, and the semantics of such
-           commands are in general arbitrarily complex.
-
-   The strategy implicit in the SNMP is that the monitoring of network
-   state at any significant level of detail is accomplished primarily by
-   polling for appropriate information on the part of the monitoring
-   center(s).  A limited number of unsolicited messages (traps) guide
-   the timing and focus of the polling.  Limiting the number of
-   unsolicited messages is consistent with the goal of simplicity and
-   minimizing the amount of traffic generated by the network management
-   function.
-
-   The exclusion of imperative commands from the set of explicitly
-   supported management functions is unlikely to preclude any desirable
-   management agent operation.  Currently, most commands are requests
-   either to set the value of some parameter or to retrieve such a
-   value, and the function of the few imperative commands currently
-   supported is easily accommodated in an asynchronous mode by this
-   management model.  In this scheme, an imperative command might be
-   realized as the setting of a parameter value that subsequently
-   triggers the desired action.  For example, rather than implementing a
-   "reboot command," this action might be invoked by simply setting a
-   parameter indicating the number of seconds until system reboot.
-
-
-
-Case, Fedor, Schoffstall, & Davin                               [Page 7]
-
-RFC 1157                          SNMP                          May 1990
-
-
-3.2.4.  Form and Meaning of Protocol Exchanges
-
-   The communication of management information among management entities
-   is realized in the SNMP through the exchange of protocol messages.
-   The form and meaning of those messages is defined below in Section 4.
-
-   Consistent with the goal of minimizing complexity of the management
-   agent, the exchange of SNMP messages requires only an unreliable
-   datagram service, and every message is entirely and independently
-   represented by a single transport datagram.  While this document
-   specifies the exchange of messages via the UDP protocol [11], the
-   mechanisms of the SNMP are generally suitable for use with a wide
-   variety of transport services.
-
-3.2.5.  Definition of Administrative Relationships
-
-   The SNMP architecture admits a variety of administrative
-   relationships among entities that participate in the protocol.  The
-   entities residing at management stations and network elements which
-   communicate with one another using the SNMP are termed SNMP
-   application entities.  The peer processes which implement the SNMP,
-   and thus support the SNMP application entities, are termed protocol
-   entities.
-
-   A pairing of an SNMP agent with some arbitrary set of SNMP
-   application entities is called an SNMP community.  Each SNMP
-   community is named by a string of octets, that is called the
-   community name for said community.
-
-   An SNMP message originated by an SNMP application entity that in fact
-   belongs to the SNMP community named by the community component of
-   said message is called an authentic SNMP message.  The set of rules
-   by which an SNMP message is identified as an authentic SNMP message
-   for a particular SNMP community is called an authentication scheme.
-   An implementation of a function that identifies authentic SNMP
-   messages according to one or more authentication schemes is called an
-   authentication service.
-
-   Clearly, effective management of administrative relationships among
-   SNMP application entities requires authentication services that (by
-   the use of encryption or other techniques) are able to identify
-   authentic SNMP messages with a high degree of certainty.  Some SNMP
-   implementations may wish to support only a trivial authentication
-   service that identifies all SNMP messages as authentic SNMP messages.
-
-   For any network element, a subset of objects in the MIB that pertain
-   to that element is called a SNMP MIB view.  Note that the names of
-   the object types represented in a SNMP MIB view need not belong to a
-
-
-
-Case, Fedor, Schoffstall, & Davin                               [Page 8]
-
-RFC 1157                          SNMP                          May 1990
-
-
-   single sub-tree of the object type name space.
-
-   An element of the set { READ-ONLY, READ-WRITE } is called an SNMP
-   access mode.
-
-   A pairing of a SNMP access mode with a SNMP MIB view is called an
-   SNMP community profile.  A SNMP community profile represents
-   specified access privileges to variables in a specified MIB view. For
-   every variable in the MIB view in a given SNMP community profile,
-   access to that variable is represented by the profile according to
-   the following conventions:
-
-      (1)  if said variable is defined in the MIB with "Access:" of
-           "none," it is unavailable as an operand for any operator;
-
-      (2)  if said variable is defined in the MIB with "Access:" of
-           "read-write" or "write-only" and the access mode of the
-           given profile is READ-WRITE, that variable is available
-           as an operand for the get, set, and trap operations;
-
-      (3)  otherwise, the variable is available as an operand for
-           the get and trap operations.
-
-      (4)  In those cases where a "write-only" variable is an
-           operand used for the get or trap operations, the value
-           given for the variable is implementation-specific.
-
-   A pairing of a SNMP community with a SNMP community profile is called
-   a SNMP access policy. An access policy represents a specified
-   community profile afforded by the SNMP agent of a specified SNMP
-   community to other members of that community.  All administrative
-   relationships among SNMP application entities are architecturally
-   defined in terms of SNMP access policies.
-
-   For every SNMP access policy, if the network element on which the
-   SNMP agent for the specified SNMP community resides is not that to
-   which the MIB view for the specified profile pertains, then that
-   policy is called a SNMP proxy access policy. The SNMP agent
-   associated with a proxy access policy is called a SNMP proxy agent.
-   While careless definition of proxy access policies can result in
-   management loops, prudent definition of proxy policies is useful in
-   at least two ways:
-
-      (1)  It permits the monitoring and control of network elements
-           which are otherwise not addressable using the management
-           protocol and the transport protocol.  That is, a proxy
-           agent may provide a protocol conversion function allowing
-           a management station to apply a consistent management
-
-
-
-Case, Fedor, Schoffstall, & Davin                               [Page 9]
-
-RFC 1157                          SNMP                          May 1990
-
-
-           framework to all network elements, including devices such
-           as modems, multiplexors, and other devices which support
-           different management frameworks.
-
-      (2)  It potentially shields network elements from elaborate
-           access control policies.  For example, a proxy agent may
-           implement sophisticated access control whereby diverse
-           subsets of variables within the MIB are made accessible
-           to different management stations without increasing the
-           complexity of the network element.
-
-   By way of example, Figure 1 illustrates the relationship between
-   management stations, proxy agents, and management agents.  In this
-   example, the proxy agent is envisioned to be a normal Internet
-   Network Operations Center (INOC) of some administrative domain which
-   has a standard managerial relationship with a set of management
-   agents.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 10]
-
-RFC 1157                          SNMP                          May 1990
-
-
-   +------------------+       +----------------+      +----------------+
-   |  Region #1 INOC  |       |Region #2 INOC  |      |PC in Region #3 |
-   |                  |       |                |      |                |
-   |Domain=Region #1  |       |Domain=Region #2|      |Domain=Region #3|
-   |CPU=super-mini-1  |       |CPU=super-mini-1|      |CPU=Clone-1     |
-   |PCommunity=pub    |       |PCommunity=pub  |      |PCommunity=slate|
-   |                  |       |                |      |                |
-   +------------------+       +----------------+      +----------------+
-          /|\                      /|\                     /|\
-           |                        |                       |
-           |                        |                       |
-           |                       \|/                      |
-           |               +-----------------+              |
-           +-------------->| Region #3 INOC  |<-------------+
-                           |                 |
-                           |Domain=Region #3 |
-                           |CPU=super-mini-2 |
-                           |PCommunity=pub,  |
-                           |         slate   |
-                           |DCommunity=secret|
-           +-------------->|                 |<-------------+
-           |               +-----------------+              |
-           |                       /|\                      |
-           |                        |                       |
-           |                        |                       |
-          \|/                      \|/                     \|/
-   +-----------------+     +-----------------+       +-----------------+
-   |Domain=Region#3  |     |Domain=Region#3  |       |Domain=Region#3  |
-   |CPU=router-1     |     |CPU=mainframe-1  |       |CPU=modem-1      |
-   |DCommunity=secret|     |DCommunity=secret|       |DCommunity=secret|
-   +-----------------+     +-----------------+       +-----------------+
-
-
-   Domain:  the administrative domain of the element
-   PCommunity:  the name of a community utilizing a proxy agent
-   DCommunity:  the name of a direct community
-
-
-                                 Figure 1
-                 Example Network Management Configuration
-
-
-
-
-
-
-
-
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 11]
-
-RFC 1157                          SNMP                          May 1990
-
-
-3.2.6.  Form and Meaning of References to Managed Objects
-
-   The SMI requires that the definition of a conformant management
-   protocol address:
-
-      (1)  the resolution of ambiguous MIB references,
-
-      (2)  the resolution of MIB references in the presence multiple
-           MIB versions, and
-
-      (3)  the identification of particular instances of object
-           types defined in the MIB.
-
-3.2.6.1.  Resolution of Ambiguous MIB References
-
-   Because the scope of any SNMP operation is conceptually confined to
-   objects relevant to a single network element, and because all SNMP
-   references to MIB objects are (implicitly or explicitly) by unique
-   variable names, there is no possibility that any SNMP reference to
-   any object type defined in the MIB could resolve to multiple
-   instances of that type.
-
-3.2.6.2.  Resolution of References across MIB Versions
-
-   The object instance referred to by any SNMP operation is exactly that
-   specified as part of the operation request or (in the case of a get-
-   next operation) its immediate successor in the MIB as a whole.  In
-   particular, a reference to an object as part of some version of the
-   Internet-standard MIB does not resolve to any object that is not part
-   of said version of the Internet-standard MIB, except in the case that
-   the requested operation is get-next and the specified object name is
-   lexicographically last among the names of all objects presented as
-   part of said version of the Internet-Standard MIB.
-
-3.2.6.3.  Identification of Object Instances
-
-   The names for all object types in the MIB are defined explicitly
-   either in the Internet-standard MIB or in other documents which
-   conform to the naming conventions of the SMI.  The SMI requires that
-   conformant management protocols define mechanisms for identifying
-   individual instances of those object types for a particular network
-   element.
-
-   Each instance of any object type defined in the MIB is identified in
-   SNMP operations by a unique name called its "variable name." In
-   general, the name of an SNMP variable is an OBJECT IDENTIFIER of the
-   form x.y, where x is the name of a non-aggregate object type defined
-   in the MIB and y is an OBJECT IDENTIFIER fragment that, in a way
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 12]
-
-RFC 1157                          SNMP                          May 1990
-
-
-   specific to the named object type, identifies the desired instance.
-
-   This naming strategy admits the fullest exploitation of the semantics
-   of the GetNextRequest-PDU (see Section 4), because it assigns names
-   for related variables so as to be contiguous in the lexicographical
-   ordering of all variable names known in the MIB.
-
-   The type-specific naming of object instances is defined below for a
-   number of classes of object types.  Instances of an object type to
-   which none of the following naming conventions are applicable are
-   named by OBJECT IDENTIFIERs of the form x.0, where x is the name of
-   said object type in the MIB definition.
-
-   For example, suppose one wanted to identify an instance of the
-   variable sysDescr The object class for sysDescr is:
-
-             iso org dod internet mgmt mib system sysDescr
-              1   3   6     1      2    1    1       1
-
-   Hence, the object type, x, would be 1.3.6.1.2.1.1.1 to which is
-   appended an instance sub-identifier of 0.  That is, 1.3.6.1.2.1.1.1.0
-   identifies the one and only instance of sysDescr.
-
-3.2.6.3.1.  ifTable Object Type Names
-
-   The name of a subnet interface, s, is the OBJECT IDENTIFIER value of
-   the form i, where i has the value of that instance of the ifIndex
-   object type associated with s.
-
-   For each object type, t, for which the defined name, n, has a prefix
-   of ifEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
-   the form n.s, where s is the name of the subnet interface about which
-   i represents information.
-
-   For example, suppose one wanted to identify the instance of the
-   variable ifType associated with interface 2.  Accordingly, ifType.2
-   would identify the desired instance.
-
-3.2.6.3.2.  atTable Object Type Names
-
-   The name of an AT-cached network address, x, is an OBJECT IDENTIFIER
-   of the form 1.a.b.c.d, where a.b.c.d is the value (in the familiar
-   "dot" notation) of the atNetAddress object type associated with x.
-
-   The name of an address translation equivalence e is an OBJECT
-   IDENTIFIER value of the form s.w, such that s is the value of that
-   instance of the atIndex object type associated with e and such that w
-   is the name of the AT-cached network address associated with e.
-
-