doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc1724.txt b/doc/rfc/rfc1724.txt
new file mode 100644
index 0000000..44231f4
--- /dev/null
+++ b/doc/rfc/rfc1724.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                         G. Malkin
+Request for Comments: 1724                               Xylogics, Inc.
+Obsoletes: 1389                                                F. Baker
+Category: Standards Track                                 Cisco Systems
+                                                          November 1994
+
+
+                      RIP Version 2 MIB Extension
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This memo defines a portion of the Management Information Base (MIB)
+   for use with network management protocols in TCP/IP-based internets.
+   In particular, it defines objects for managing RIP Version 2.
+
+Acknowledgements
+
+   The authors would like to thank the IETF ripv2 Working Group for
+   their help in improving the RIP-2 MIB extension.
+
+Table of Contents
+
+   1. The Network Management Framework ......................    2
+   2. Objects ...............................................    2
+   2.1 Format of Definitions ................................    3
+   3. Overview ..............................................    3
+   3.1 Textual Conventions ..................................    3
+   3.2 Structure of MIB .....................................    3
+   3.3 Modifications from RFC 1389 ..........................    3
+   4. Definitions ...........................................    5
+   4.1 Global Counters ......................................    6
+   4.2 RIP Interface Tables .................................    6
+   4.3 Peer Table ...........................................   12
+   5. References ............................................   17
+   6. Security Considerations ...............................   18
+   7. Authors' Addresses ....................................   18
+
+
+
+
+
+
+
+Malkin & Baker                                                  [Page 1]
+
+RFC 1724                  RIP-2 MIB Extension              November 1994
+
+
+1. The Network Management Framework
+
+   The Internet-standard Network Management Framework consists of three
+   components.  They are:
+
+      STD 16/RFC 1155 which defines the SMI, the mechanisms used for
+         describing and naming objects for the purpose of management.
+
+      STD 16/RFC 1212 defines a more concise description mechanism,
+         which is wholly consistent with the SMI.
+
+      RFC 1156 which defines MIB-I, the core set of managed objects for
+         the Internet suite of protocols.  STD 17/RFC 1213 defines MIB-
+         II, an evolution of MIB-I based on implementation experience
+         and new operational requirements.
+
+      STD 15/RFC 1157 which defines the SNMP, the protocol used for
+         network access to managed objects.
+
+   The Framework permits new objects to be defined for the purpose of
+   experimentation and evaluation.
+
+2. Objects
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  Objects in the MIB are
+   defined using the subset of Abstract Syntax Notation One (ASN.1) [7]
+   defined in the SMI.  In particular, each object has a name, a syntax,
+   and an encoding.  The name is an object identifier, an
+   administratively assigned name, which specifies an object type.  The
+   object type together with an object instance serves to uniquely
+   identify a specific instantiation of the object.  For human
+   convenience, we often use a textual string, termed the OBJECT
+   DESCRIPTOR, to also refer to the object type.
+
+   The syntax of an object type defines the abstract data structure
+   corresponding to that object type.  The ASN.1 language is used for
+   this purpose.  However, the SMI [3] purposely restricts the ASN.1
+   constructs which may be used.  These restrictions are explicitly made
+   for simplicity.
+
+   The encoding of an object type is simply how that object type is
+   represented using the object type's syntax.  Implicitly tied to the
+   notion of an object type's syntax and encoding is how the object type
+   is represented when being transmitted on the network.
+
+   The SMI specifies the use of the basic encoding rules of ASN.1 [8],
+   subject to the additional requirements imposed by the SNMP.
+
+
+
+Malkin & Baker                                                  [Page 2]
+
+RFC 1724                  RIP-2 MIB Extension              November 1994
+
+
+2.1 Format of Definitions
+
+   Section 4 contains the specification of all object types contained in
+   this MIB module.  The object types are defined using the conventions
+   defined in the SMI, as amended by the extensions specified in [9].
+
+3. Overview
+
+3.1 Textual Conventions
+
+   Several new data types are introduced as a textual convention in this
+   MIB document.  These textual conventions enhance the readability of
+   the specification and can ease comparison with other specifications
+   if appropriate.  It should be noted that the introduction of the
+   these textual conventions has no effect on either the syntax nor the
+   semantics of any managed objects.  The use of these is merely an
+   artifact of the explanatory method used.  Objects defined in terms of
+   one of these methods are always encoded by means of the rules that
+   define the primitive type.  Hence, no changes to the SMI or the SNMP
+   are necessary to accommodate these textual conventions which are
+   adopted merely for the convenience of readers and writers in pursuit
+   of the elusive goal of clear, concise, and unambiguous MIB documents.
+
+   The new data type is RouteTag. The RouteTag type represents the
+   contents of the Route Domain field in the packet header or route
+   entry.
+
+3.2 Structure of MIB
+
+   The RIP-2 MIB contains global counters, useful for detecting the
+   deleterious effects of RIP incompatibilities; two "interfaces"
+   tables, which contains interface-specific statistics and
+   configuration information; and an optional "peer" table, containing
+   information that may be helpful in debugging neighbor relationships.
+   Like the protocol itself, this MIB takes great care to preserve
+   compatibility with RIP-1 systems and controls for monitoring and
+   controlling system interactions.
+
+3.3 Modifications from RFC 1389
+
+   The RIP-2 MIB was originally published in RFC 1389.  It encoded the
+   concept of a Routing Domain, and did not address unnumbered
+   interfaces.
+
+   In the current version of the protocol, Route Domains are deprecated;
+   therefore, they are deprecated in the MIB as well.  This means that
+   the object rip2IfConfDomain is deprecated, and the object
+   rip2PeerDomain (which cannot be deprecated, being an instance object)
+
+
+
+Malkin & Baker                                                  [Page 3]
+
+RFC 1724                  RIP-2 MIB Extension              November 1994
+
+
+   must always be zero.
+
+   Unnumbered interfaces are supported in this version.  Since the IP
+   Address that the neighbor uses may be unknown to the system, a
+   pseudo-address is used to identify these interfaces.  The pseudo-
+   address is in the class A network 0.0.0.0, and the host number (the
+   least significant 24 bits of the address) are the ifIndex value of
+   the relevant IP Interface.  This is an additional new meaning of the
+   objects rip2IfStatAddress and rip2IfConfAddress, backward compatible
+   with the RFC 1389 usage.  The object rip2IfConfSrcAddress is added,
+   to permit the configuration of the source address on an unnumbered
+   interface, and the meaning of the object rip2PeerAddress is broadened
+   to remain relevant on unnumbered interfaces.
+
+   rip2IfConfSend is augmented with two values for the use of Demand RIP
+   under RIP-I and RIP-II rules.  This avoids the necessity of a Demand
+   RIP MIB.
+
+   MD5 Authentication is supported.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malkin & Baker                                                  [Page 4]
+
+RFC 1724                  RIP-2 MIB Extension              November 1994
+
+
+4. Definitions
+
+   RIPv2-MIB DEFINITIONS ::= BEGIN
+
+   IMPORTS
+       MODULE-IDENTITY, OBJECT-TYPE, Counter32,
+       TimeTicks, IpAddress                     FROM SNMPv2-SMI
+       TEXTUAL-CONVENTION, RowStatus            FROM SNMPv2-TC
+       MODULE-COMPLIANCE, OBJECT-GROUP          FROM SNMPv2-CONF
+       mib-2                                    FROM RFC1213-MIB;
+
+   --  This MIB module uses the extended OBJECT-TYPE macro as
+   --  defined in [9].
+
+   rip2  MODULE-IDENTITY
+           LAST-UPDATED "9407272253Z"      -- Wed Jul 27 22:53:04 PDT 1994
+           ORGANIZATION "IETF RIP-II Working Group"
+           CONTACT-INFO
+          "       Fred Baker
+          Postal: Cisco Systems
+                  519 Lado Drive
+                  Santa Barbara, California 93111
+          Tel:    +1 805 681 0115
+          E-Mail: fbaker@cisco.com
+
+          Postal: Gary Malkin
+                  Xylogics, Inc.
+                  53 Third Avenue
+                  Burlington, MA  01803
+
+          Phone:  (617) 272-8140
+          EMail:  gmalkin@Xylogics.COM"
+      DESCRIPTION
+         "The MIB module to describe the RIP2 Version 2 Protocol"
+     ::= { mib-2 23 }
+
+ --  RIP-2 Management Information Base
+
+ -- the RouteTag type represents the contents of the
+ -- Route Domain field in the packet header or route entry.
+ -- The use of the Route Domain is deprecated.
+
+ RouteTag ::= TEXTUAL-CONVENTION
+     STATUS      current
+     DESCRIPTION
+        "the RouteTag type represents the contents of the Route Domain
+        field in the packet header or route entry"
+    SYNTAX      OCTET STRING (SIZE (2))
+
+
+
+Malkin & Baker                                                  [Page 5]
+
+RFC 1724                  RIP-2 MIB Extension              November 1994
+
+
+--4.1 Global Counters
+
+--      The RIP-2 Globals Group.
+--      Implementation of this group is mandatory for systems
+--      which implement RIP-2.
+
+-- These counters are intended to facilitate debugging quickly
+-- changing routes or failing neighbors
+
+rip2Globals OBJECT IDENTIFIER ::= { rip2 1 }
+
+    rip2GlobalRouteChanges OBJECT-TYPE
+        SYNTAX   Counter32
+        MAX-ACCESS   read-only
+        STATUS   current
+        DESCRIPTION
+           "The number of route changes made to the IP Route
+           Database by RIP.  This does not include the refresh
+           of a route's age."
+       ::= { rip2Globals 1 }
+
+    rip2GlobalQueries OBJECT-TYPE
+        SYNTAX   Counter32
+        MAX-ACCESS   read-only
+        STATUS   current
+        DESCRIPTION
+           "The number of responses sent to RIP queries
+           from other systems."
+       ::= { rip2Globals 2 }
+
+--4.2 RIP Interface Tables
+
+--  RIP Interfaces Groups
+--  Implementation of these Groups is mandatory for systems
+--  which implement RIP-2.
+
+-- The RIP Interface Status Table.
+
+    rip2IfStatTable OBJECT-TYPE
+        SYNTAX   SEQUENCE OF Rip2IfStatEntry
+        MAX-ACCESS   not-accessible
+        STATUS   current
+        DESCRIPTION
+           "A list of subnets which require separate
+           status monitoring in RIP."
+       ::= { rip2 2 }
+
+   rip2IfStatEntry OBJECT-TYPE
+
+
+
+Malkin & Baker                                                  [Page 6]
+
+RFC 1724                  RIP-2 MIB Extension              November 1994
+
+
+       SYNTAX   Rip2IfStatEntry
+       MAX-ACCESS   not-accessible
+       STATUS   current
+       DESCRIPTION
+          "A Single Routing Domain in a single Subnet."
+      INDEX { rip2IfStatAddress }
+      ::= { rip2IfStatTable 1 }
+
+    Rip2IfStatEntry ::=
+        SEQUENCE {
+            rip2IfStatAddress
+                IpAddress,
+            rip2IfStatRcvBadPackets
+                Counter32,
+            rip2IfStatRcvBadRoutes
+                Counter32,
+            rip2IfStatSentUpdates
+                Counter32,
+            rip2IfStatStatus
+                RowStatus
+    }
+
+    rip2IfStatAddress OBJECT-TYPE
+        SYNTAX   IpAddress
+        MAX-ACCESS   read-only
+        STATUS   current
+        DESCRIPTION
+           "The IP Address of this system on the indicated
+           subnet. For unnumbered interfaces, the value 0.0.0.N,
+           where the least significant 24 bits (N) is the ifIndex
+           for the IP Interface in network byte order."
+       ::= { rip2IfStatEntry 1 }
+
+    rip2IfStatRcvBadPackets OBJECT-TYPE
+        SYNTAX   Counter32
+        MAX-ACCESS   read-only
+        STATUS   current
+        DESCRIPTION
+           "The number of RIP response packets received by
+           the RIP process which were subsequently discarded
+           for any reason (e.g. a version 0 packet, or an
+           unknown command type)."
+       ::= { rip2IfStatEntry 2 }
+
+    rip2IfStatRcvBadRoutes OBJECT-TYPE
+        SYNTAX   Counter32
+        MAX-ACCESS   read-only
+        STATUS   current
+
+
+
+Malkin & Baker                                                  [Page 7]
+
+RFC 1724                  RIP-2 MIB Extension              November 1994
+
+
+        DESCRIPTION
+           "The number of routes, in valid RIP packets,
+           which were ignored for any reason (e.g. unknown
+           address family, or invalid metric)."
+       ::= { rip2IfStatEntry 3 }
+
+    rip2IfStatSentUpdates OBJECT-TYPE
+        SYNTAX   Counter32
+        MAX-ACCESS   read-only
+        STATUS   current
+        DESCRIPTION
+           "The number of triggered RIP updates actually
+           sent on this interface.  This explicitly does
+           NOT include full updates sent containing new
+           information."
+       ::= { rip2IfStatEntry 4 }
+
+    rip2IfStatStatus OBJECT-TYPE
+        SYNTAX   RowStatus
+        MAX-ACCESS   read-create
+        STATUS   current
+        DESCRIPTION
+           "Writing invalid has the effect of deleting
+           this interface."
+       ::= { rip2IfStatEntry 5 }
+
+-- The RIP Interface Configuration Table.
+
+    rip2IfConfTable OBJECT-TYPE
+        SYNTAX   SEQUENCE OF Rip2IfConfEntry
+        MAX-ACCESS   not-accessible
+        STATUS   current
+        DESCRIPTION
+           "A list of subnets which require separate
+           configuration in RIP."
+       ::= { rip2 3 }
+
+   rip2IfConfEntry OBJECT-TYPE
+       SYNTAX   Rip2IfConfEntry
+       MAX-ACCESS   not-accessible
+       STATUS   current
+       DESCRIPTION
+          "A Single Routing Domain in a single Subnet."
+      INDEX { rip2IfConfAddress }
+      ::= { rip2IfConfTable 1 }
+
+    Rip2IfConfEntry ::=
+        SEQUENCE {
+
+
+
+Malkin & Baker                                                  [Page 8]
+
+RFC 1724                  RIP-2 MIB Extension              November 1994
+
+
+            rip2IfConfAddress
+                IpAddress,
+            rip2IfConfDomain
+                RouteTag,
+            rip2IfConfAuthType
+                INTEGER,
+            rip2IfConfAuthKey
+                OCTET STRING (SIZE(0..16)),
+            rip2IfConfSend
+                INTEGER,
+            rip2IfConfReceive
+                INTEGER,
+            rip2IfConfDefaultMetric
+                INTEGER,
+            rip2IfConfStatus
+                RowStatus,
+            rip2IfConfSrcAddress
+                IpAddress
+    }
+
+    rip2IfConfAddress OBJECT-TYPE
+        SYNTAX   IpAddress
+        MAX-ACCESS   read-only
+        STATUS   current
+        DESCRIPTION
+           "The IP Address of this system on the indicated
+           subnet.  For unnumbered interfaces, the value 0.0.0.N,
+           where the least significant 24 bits (N) is the ifIndex
+           for the IP Interface in network byte order."
+       ::= { rip2IfConfEntry 1 }
+
+    rip2IfConfDomain OBJECT-TYPE
+        SYNTAX   RouteTag
+        MAX-ACCESS   read-create
+        STATUS   obsolete
+        DESCRIPTION
+           "Value inserted into the Routing Domain field
+           of all RIP packets sent on this interface."
+       DEFVAL { '0000'h }
+       ::= { rip2IfConfEntry 2 }
+
+    rip2IfConfAuthType OBJECT-TYPE
+        SYNTAX   INTEGER {
+                    noAuthentication (1),
+                    simplePassword (2),
+                    md5 (3)
+                 }
+        MAX-ACCESS   read-create
+
+
+
+Malkin & Baker                                                  [Page 9]
+
+RFC 1724                  RIP-2 MIB Extension              November 1994
+
+
+        STATUS   current
+        DESCRIPTION
+           "The type of Authentication used on this
+           interface."
+       DEFVAL { noAuthentication }
+       ::= { rip2IfConfEntry 3 }
+
+    rip2IfConfAuthKey OBJECT-TYPE
+        SYNTAX   OCTET STRING (SIZE(0..16))
+        MAX-ACCESS   read-create
+        STATUS   current
+        DESCRIPTION
+           "The value to be used as the Authentication Key
+           whenever the corresponding instance of
+           rip2IfConfAuthType has a value other than
+           noAuthentication.  A modification of the corresponding
+           instance of rip2IfConfAuthType does not modify
+           the rip2IfConfAuthKey value.  If a string shorter
+           than 16 octets is supplied, it will be left-
+           justified and padded to 16 octets, on the right,
+           with nulls (0x00).
+
+           Reading this object always results in an  OCTET
+           STRING of length zero; authentication may not
+           be bypassed by reading the MIB object."
+       DEFVAL { ''h }
+       ::= { rip2IfConfEntry 4 }
+
+    rip2IfConfSend OBJECT-TYPE
+        SYNTAX   INTEGER {
+                    doNotSend (1),
+                    ripVersion1 (2),
+                    rip1Compatible (3),
+                    ripVersion2 (4),
+                    ripV1Demand (5),
+                    ripV2Demand (6)
+                 }
+        MAX-ACCESS   read-create
+        STATUS   current
+        DESCRIPTION
+           "What the router sends on this interface.
+           ripVersion1 implies sending RIP updates compliant
+           with  RFC  1058.   rip1Compatible implies
+           broadcasting RIP-2 updates using RFC 1058 route
+           subsumption rules.  ripVersion2 implies
+           multicasting RIP-2 updates.  ripV1Demand indicates
+           the use of Demand RIP on a WAN interface under RIP
+           Version 1 rules.  ripV2Demand indicates the use of
+
+
+
+Malkin & Baker                                                 [Page 10]
+
+RFC 1724                  RIP-2 MIB Extension              November 1994
+
+
+           Demand RIP on a WAN interface under Version 2 rules."
+       DEFVAL { rip1Compatible }
+       ::= { rip2IfConfEntry 5 }
+
+    rip2IfConfReceive OBJECT-TYPE
+        SYNTAX   INTEGER {
+                    rip1 (1),
+                    rip2 (2),
+                    rip1OrRip2 (3),
+                    doNotRecieve (4)
+                 }
+        MAX-ACCESS   read-create
+        STATUS   current
+        DESCRIPTION
+           "This indicates which version of RIP updates
+           are to be accepted.  Note that rip2 and
+           rip1OrRip2 implies reception of multicast
+           packets."
+       DEFVAL { rip1OrRip2 }
+       ::= { rip2IfConfEntry 6 }
+
+    rip2IfConfDefaultMetric OBJECT-TYPE
+        SYNTAX   INTEGER ( 0..15 )
+        MAX-ACCESS   read-create
+        STATUS   current
+        DESCRIPTION
+           "This variable indicates the metric that is to
+           be used for the default route entry in RIP updates
+           originated on this interface.  A value of zero
+           indicates that no default route should be
+           originated; in this case, a default route via
+           another router may be propagated."
+       ::= { rip2IfConfEntry 7 }
+
+    rip2IfConfStatus OBJECT-TYPE
+        SYNTAX   RowStatus
+        MAX-ACCESS   read-create
+        STATUS   current
+        DESCRIPTION
+           "Writing invalid has  the  effect  of  deleting
+           this interface."
+       ::= { rip2IfConfEntry 8 }
+
+    rip2IfConfSrcAddress OBJECT-TYPE
+        SYNTAX   IpAddress
+        MAX-ACCESS   read-create
+        STATUS   current
+        DESCRIPTION
+
+
+
+Malkin & Baker                                                 [Page 11]
+
+RFC 1724                  RIP-2 MIB Extension              November 1994
+
+
+           "The IP Address this system will use as a source
+            address on this interface.  If it is a numbered
+            interface, this MUST be the same value as
+            rip2IfConfAddress.  On unnumbered interfaces,
+            it must be the value of rip2IfConfAddress for
+            some interface on the system."
+       ::= { rip2IfConfEntry 9 }
+
+--4.3 Peer Table
+
+--  Peer Table
+
+--      The RIP Peer Group
+--      Implementation of this Group is Optional
+
+--      This group provides information about active peer
+--      relationships intended to assist in debugging.  An
+--      active peer is a router from which a valid RIP
+--      updated has been heard in the last 180 seconds.
+
+    rip2PeerTable OBJECT-TYPE
+        SYNTAX   SEQUENCE OF Rip2PeerEntry
+        MAX-ACCESS   not-accessible
+        STATUS   current
+        DESCRIPTION
+           "A list of RIP Peers."
+       ::= { rip2 4 }
+
+   rip2PeerEntry OBJECT-TYPE
+       SYNTAX   Rip2PeerEntry
+       MAX-ACCESS   not-accessible
+       STATUS   current
+       DESCRIPTION
+          "Information regarding a single routing peer."
+      INDEX { rip2PeerAddress, rip2PeerDomain }
+      ::= { rip2PeerTable 1 }
+
+    Rip2PeerEntry ::=
+        SEQUENCE {
+            rip2PeerAddress
+                IpAddress,
+            rip2PeerDomain
+                RouteTag,
+            rip2PeerLastUpdate
+                TimeTicks,
+            rip2PeerVersion
+                INTEGER,
+            rip2PeerRcvBadPackets
+
+
+
+Malkin & Baker                                                 [Page 12]
+
+RFC 1724                  RIP-2 MIB Extension              November 1994
+
+
+                Counter32,
+            rip2PeerRcvBadRoutes
+                Counter32
+            }
+
+    rip2PeerAddress OBJECT-TYPE
+        SYNTAX   IpAddress
+        MAX-ACCESS   read-only
+        STATUS   current
+        DESCRIPTION
+           "The IP Address that the peer is using as its source
+            address.  Note that on an unnumbered link, this may
+            not be a member of any subnet on the system."
+       ::= { rip2PeerEntry 1 }
+
+    rip2PeerDomain OBJECT-TYPE
+        SYNTAX   RouteTag
+        MAX-ACCESS   read-only
+        STATUS   current
+        DESCRIPTION
+           "The value in the Routing Domain field  in  RIP
+           packets received from the peer.  As domain suuport
+           is deprecated, this must be zero."
+       ::= { rip2PeerEntry 2 }
+
+    rip2PeerLastUpdate OBJECT-TYPE
+        SYNTAX   TimeTicks
+        MAX-ACCESS   read-only
+        STATUS   current
+        DESCRIPTION
+           "The value of sysUpTime when the most recent
+           RIP update was received from this system."
+       ::= { rip2PeerEntry 3 }
+
+    rip2PeerVersion OBJECT-TYPE
+        SYNTAX   INTEGER ( 0..255 )
+        MAX-ACCESS   read-only
+        STATUS   current
+        DESCRIPTION
+           "The RIP version number in the header of the
+           last RIP packet received."
+       ::= { rip2PeerEntry 4 }
+
+    rip2PeerRcvBadPackets OBJECT-TYPE
+        SYNTAX   Counter32
+        MAX-ACCESS   read-only
+        STATUS   current
+        DESCRIPTION
+
+
+
+Malkin & Baker                                                 [Page 13]
+
+RFC 1724                  RIP-2 MIB Extension              November 1994
+
+
+           "The number of RIP response packets from this
+           peer discarded as invalid."
+       ::= { rip2PeerEntry 5 }
+
+
+    rip2PeerRcvBadRoutes OBJECT-TYPE
+        SYNTAX   Counter32
+        MAX-ACCESS   read-only
+        STATUS   current
+        DESCRIPTION
+           "The number of routes from this peer that were
+           ignored because the entry format was invalid."
+       ::= { rip2PeerEntry 6 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malkin & Baker                                                 [Page 14]
+
+RFC 1724                  RIP-2 MIB Extension              November 1994
+
+
+-- conformance information
+
+rip2Conformance OBJECT IDENTIFIER ::= { rip2 5 }
+
+rip2Groups      OBJECT IDENTIFIER ::= { rip2Conformance 1 }
+rip2Compliances OBJECT IDENTIFIER ::= { rip2Conformance 2 }
+
+-- compliance statements
+rip2Compliance MODULE-COMPLIANCE
+    STATUS  current
+    DESCRIPTION
+       "The compliance statement "
+    MODULE  -- this module
+    MANDATORY-GROUPS {
+                 rip2GlobalGroup,
+                 rip2IfStatGroup,
+                 rip2IfConfGroup,
+                 rip2PeerGroup
+        }
+    GROUP       rip2GlobalGroup
+    DESCRIPTION
+       "This group defines global controls for RIP-II systems."
+    GROUP       rip2IfStatGroup
+    DESCRIPTION
+       "This group defines interface statistics for RIP-II systems."
+    GROUP       rip2IfConfGroup
+    DESCRIPTION
+       "This group defines interface configuration for RIP-II systems."
+    GROUP       rip2PeerGroup
+    DESCRIPTION
+       "This group defines peer information for RIP-II systems."
+    ::= { rip2Compliances 1 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malkin & Baker                                                 [Page 15]
+
+RFC 1724                  RIP-2 MIB Extension              November 1994
+
+
+-- units of conformance
+
+rip2GlobalGroup    OBJECT-GROUP
+    OBJECTS {
+                rip2GlobalRouteChanges,
+                rip2GlobalQueries
+    }
+    STATUS  current
+    DESCRIPTION
+       "This group defines global controls for RIP-II systems."
+    ::= { rip2Groups 1 }
+rip2IfStatGroup    OBJECT-GROUP
+    OBJECTS {
+            rip2IfStatAddress,
+            rip2IfStatRcvBadPackets,
+            rip2IfStatRcvBadRoutes,
+            rip2IfStatSentUpdates,
+            rip2IfStatStatus
+    }
+    STATUS  current
+    DESCRIPTION
+       "This group defines interface statistics for RIP-II systems."
+    ::= { rip2Groups 2 }
+rip2IfConfGroup    OBJECT-GROUP
+    OBJECTS {
+            rip2IfConfAddress,
+            rip2IfConfAuthType,
+            rip2IfConfAuthKey,
+            rip2IfConfSend,
+            rip2IfConfReceive,
+            rip2IfConfDefaultMetric,
+            rip2IfConfStatus,
+            rip2IfConfSrcAddress
+    }
+    STATUS  current
+    DESCRIPTION
+       "This group defines interface configuration for RIP-II systems."
+    ::= { rip2Groups 3 }
+rip2PeerGroup    OBJECT-GROUP
+    OBJECTS {
+            rip2PeerAddress,
+            rip2PeerDomain,
+            rip2PeerLastUpdate,
+            rip2PeerVersion,
+            rip2PeerRcvBadPackets,
+            rip2PeerRcvBadRoutes
+    }
+    STATUS  current
+
+
+
+Malkin & Baker                                                 [Page 16]
+
+RFC 1724                  RIP-2 MIB Extension              November 1994
+
+
+    DESCRIPTION
+       "This group defines peer information for RIP-II systems."
+    ::= { rip2Groups 4 }
+END
+
+5. References
+
+   [1] Cerf, V., "IAB Recommendations for the Development of Internet
+       Network Management Standards", RFC 1052, IAB, April 1988.
+
+   [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review
+       Group", RFC 1109, IAB, August 1989.
+
+   [3] Rose M., and K. McCloghrie, "Structure and Identification of
+       Management Information for TCP/IP-based internets", STD 16, RFC
+       1155, Performance Systems International, Hughes LAN Systems, May
+       1990.
+
+   [4] McCloghrie K., and M. Rose, "Management Information Base for
+       Network Management of TCP/IP-based internets", RFC 1156, Hughes
+       LAN Systems, Performance Systems International, May 1990.
+
+   [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
+       Network Management Protocol", STD 15, RFC 1157, SNMP Research,
+       Performance Systems International, Performance Systems
+       International, MIT Laboratory for Computer Science, May 1990.
+
+   [6] Rose, M., Editor, "Management Information Base for Network
+       Management of TCP/IP-based internets: MIB-II", RFC 1158,
+       Performance Systems International, May 1990.
+
+   [7] Information processing systems - Open Systems Interconnection -
+       Specification of Abstract Syntax Notation One (ASN.1),
+       International Organization for Standardization, International
+       Standard 8824, December 1987.
+
+   [8] 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.
+
+   [9] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
+       STD 16, RFC 1212, Performance Systems International, Hughes LAN
+       Systems, March 1991.
+
+  [10] Malkin, G., "RIP Version 2 - Carrying Additional Information",
+       RFC 1723, Xylogics, Inc., November 1994.
+
+
+
+
+Malkin & Baker                                                 [Page 17]
+
+RFC 1724                  RIP-2 MIB Extension              November 1994
+
+
+  [11] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1721,
+       Xylogics, Inc., November 1994.
+
+  [12] Malkin, G., "RIP Version 2 Protocol Applicability Statement", RFC
+       1722, Xylogics, Inc., November 1994.
+
+6.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+7.  Authors' Addresses
+
+   Gary Malkin
+   Xylogics, Inc.
+   53 Third Avenue
+   Burlington, MA  01803
+
+   Phone: (617) 272-8140
+   EMail: gmalkin@Xylogics.COM
+
+
+   Fred Baker
+   Cisco Systems
+   519 Lado Drive
+   Santa Barbara, California 93111
+
+   Phone: 805-681-0115
+   EMail: fred@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malkin & Baker                                                 [Page 18]
+