doc: Add RFC documents

1 files changed, 1515 insertions, 0 deletions

diff --git a/doc/rfc/rfc2940.txt b/doc/rfc/rfc2940.txt
new file mode 100644
index 0000000..4e310da
--- /dev/null
+++ b/doc/rfc/rfc2940.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group                                            A. Smith
+Request for Comments: 2940                                     Consultant
+Category: Standards Track                                      D. Partain
+                                                                 Ericsson
+                                                              J. Seligson
+                                                          Nortel Networks
+                                                             October 2000
+
+
+  Definitions of Managed Objects for Common Open Policy Service (COPS)
+                            Protocol Clients
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+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 a client of the Common
+   Open Policy Service (COPS) protocol.
+
+   This memo includes a MIB module in a manner that is compliant to the
+   SMIv2 [V2SMI].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith                       Standards Track                     [Page 1]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+1.  The SNMP Management Framework
+
+   The SNMP Management Framework presently consists of five major
+   components:
+
+      o  An overall architecture, described in an Architecture for
+         Describing SNMP Management Frameworks [ARCH].
+
+      o  Mechanisms for describing and naming objects and events for the
+         purpose of management.  The first version of this Structure of
+         Management Information (SMI) is called SMIv1 and described in
+         STD 16, RFC 1155 [V1SMI], STD 16, RFC 1212 [V1CONCISE] and RFC
+         1215 [V1TRAPS].  The second version, called SMIv2, is described
+         in STD 58, RFC 2578 [V2SMI], STD 58, RFC 2579 [V2TC] and STD
+         58, RFC 2580 [V2CONFORM].
+
+      o  Message protocols for transferring management information.  The
+         first version of the SNMP message protocol is called SNMPv1 and
+         described in STD 15, RFC 1157 [V1PROTO].  A second version of
+         the SNMP message protocol, which is not an Internet standards
+         track protocol, is called SNMPv2c and described in RFC 1901
+         [V2COMMUNITY] and RFC 1906 [V2TRANS].  The third version of the
+         message protocol is called SNMPv3 and described in RFC1906
+         [V2TRANS], Message Processing and Dispatching [V3MPC] and
+         User-based Security Model [V3USM].
+
+      o  Protocol operations for accessing management information.  The
+         first set of protocol operations and associated PDU formats is
+         described in STD 15, RFC 1157 [V1PROTO].  A second set of
+         protocol operations and associated PDU formats is described in
+         RFC 1905 [V2PROTO].
+
+      o  A set of fundamental applications described in SNMPv3
+         Applications [V3APPS] and the view-based access control
+         mechanism described in View-based Access Control Model
+         [V3VACM].
+
+   A more detailed introduction to the current SNMP Management Framework
+   can be found in RFC 2570 [V3INTRO].
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  Objects in the MIB are
+   defined using the mechanisms defined in the SMI.
+
+   This memo specifies a MIB module that is compliant to the SMIv2.  A
+   MIB conforming to the SMIv1 can be produced through the appropriate
+   translations.  The resulting translated MIB must be semantically
+   equivalent, except where objects or events are omitted because no
+
+
+
+Smith                       Standards Track                     [Page 2]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+   translation is possible (use of Counter64).  Some machine readable
+   information in SMIv2 will be converted into textual descriptions in
+   SMIv1 during the translation process.  However, this loss of machine
+   readable information is not considered to change the semantics of the
+   MIB.
+
+2.  Overview
+
+   The COPS protocol [COPS] is a client-server protocol intended for the
+   communication of policy requests and decisions between a Policy
+   Enforcement Point (PEP) and a Policy Decision Point (PDP).  The PEP
+   acts as a COPS client in this scenario.  The model for policy out-
+   sourcing, of which the COPS protocol provides one part, is described
+   in [FRAMEWORK].
+
+2.1.  Scope
+
+   This MIB is intended to provide management of the important features
+   of a COPS protocol client module. It does not provide management for
+   a COPS server - this is outside the scope of the current memo.  It
+   provides for monitoring of status and protocol statistics, as well as
+   for configuration of the client, in particular for telling it where
+   to locate its servers.  Other mechanisms for achieving this function
+   without SNMP configuration might include use of the Service Location
+   Protocol [SRVLOC] although this is outside the scope of this memo and
+   are not specified by the COPS protocol itself.
+
+   This MIB also does not provide management of specific COPS client-
+   types e.g., for use with the RSVP protocol [RSVP][COPSRSVP].
+
+3.  Structure of COPS Client MIB
+
+   Objects in this MIB are arranged into groups.  Each group is
+   organized as a set of related objects. The overall structure is
+   described below.
+
+3.1.  copsClientCapabilitiesGroup
+
+   This group contains objects that represent COPS protocol capabilities
+   implemented by this COPS client.
+
+3.2.  copsClientStatusGroup
+
+   This group contains objects that indicate the current status of
+   connection(s) to COPS servers, including per-server protocol
+   statistics.  It maintains last-known statistics for all of the
+   servers with which the client has ever been connected since agent
+   restart.
+
+
+
+Smith                       Standards Track                     [Page 3]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+3.3.  copsConfigGroup
+
+   This group contains objects that allow for configuration of COPS
+   server addresses and the order to which connections should be
+   attempted.  It contains a table of per-server objects as well as
+   scalars for configuration of the retry algorithm to be used by a
+   client to obtain a connection to an appropriate server.
+
+3.4.  Textual Conventions
+
+   The datatypes CopsClientState, CopsServerEntryType, CopsErrorCode,
+   CopsTcpPort and CopsAuthType are used as textual conventions in this
+   document.  These textual conventions have NO effect on either the
+   syntax nor the semantics of any managed object.  Objects defined
+   using these conventions are always encoded by means of the rules that
+   define their 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.
+
+3.5.  Relationship to Other MIBs
+
+3.5.1.  Relationship to the 'system' group
+
+   This MIB contains definitions for a single COPS protocol client
+   represented by a single SNMP agent and instance of the MIB-2 system
+   group [MIB2].  It does not address the case of multiple co-located
+   COPS protocol clients.
+
+4.  Definitions for COPS Client MIB
+
+COPS-CLIENT-MIB DEFINITIONS ::= BEGIN
+
+-- -------------------------------------------------------------
+-- -------------------------------------------------------------
+
+IMPORTS
+    MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32,
+    Unsigned32, mib-2
+        FROM SNMPv2-SMI
+    TimeStamp, TimeInterval, RowStatus, TEXTUAL-CONVENTION
+        FROM SNMPv2-TC
+    MODULE-COMPLIANCE, OBJECT-GROUP
+        FROM SNMPv2-CONF
+    InetAddressType, InetAddress
+        FROM INET-ADDRESS-MIB;
+
+
+--    REFERENCE
+
+
+
+Smith                       Standards Track                     [Page 4]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+--        "The COPS (Common Open Policy Service) Protocol RFC 2748
+
+copsClientMIB MODULE-IDENTITY
+    LAST-UPDATED "200009280000Z"
+    ORGANIZATION "IETF RSVP Admission Policy Working Group"
+    CONTACT-INFO
+        "       Andrew Smith (WG co-chair)
+         Phone: +1 408 579 2821
+         Email: ah_smith@pacbell.net
+
+                Mark Stevens (WG co-chair)
+         Phone: +1 978 287 9102
+         Email: markstevens@lucent.com
+
+         Editor: Andrew Smith
+         Phone: +1 408 579 2821
+         Email: ah_smith@pacbell.net
+
+         Editor: David Partain
+         Phone: +46 13 28 41 44
+         Email: David.Partain@ericsson.com
+
+         Editor: John Seligson
+         Phone: +1 408 495 2992
+         Email: jseligso@nortelnetworks.com"
+
+    DESCRIPTION
+        "The COPS Client MIB module"
+
+    REVISION    "200009280000Z"
+    DESCRIPTION "This version published as RFC 2940"
+
+    ::= { mib-2 89 }
+
+copsClientMIBObjects OBJECT IDENTIFIER ::= { copsClientMIB 1 }
+
+-- -------------------------------------------------------------
+-- Textual Conventions
+-- -------------------------------------------------------------
+
+CopsClientState ::= TEXTUAL-CONVENTION
+    STATUS      current
+    DESCRIPTION
+        "A value indicating the state of a COPS client."
+    SYNTAX      INTEGER {
+            copsClientInvalid(1),      -- default state.
+            copsClientTcpconnected(2), -- TCP connection up but COPS
+                                       -- not yet open.
+
+
+
+Smith                       Standards Track                     [Page 5]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+            copsClientAuthenticating(3), -- TCP connection up but still
+                                         -- authenticating.
+            copsClientSecAccepted(4),  -- connection authenticated.
+            copsClientAccepted(5),     -- COPS server accepted client.
+            copsClientTimingout(6)     -- Keepalive timer has expired,
+                                       -- client is in process of
+                                       -- tearing down connection.
+    }
+
+CopsServerEntryType ::= TEXTUAL-CONVENTION
+    STATUS      current
+    DESCRIPTION
+        "A value indicating how a COPS server entry came into existence."
+    SYNTAX      INTEGER {
+            copsServerStatic(1),        -- configured by manager
+            copsServerRedirect(2)       -- notified by COPS server
+    }
+
+CopsErrorCode ::= TEXTUAL-CONVENTION
+    STATUS      current
+    DESCRIPTION
+        "A value describing a COPS protocol error. Codes are identical
+         to those used by the COPS protocol itself."
+    SYNTAX      INTEGER {
+            errorOther(0),             -- none of the below
+            errorBadHandle(1),
+            errorInvalidHandleReference(2),
+            errorBadMessageFormat(3),
+            errorUnableToProcess(4),
+            errorMandatoryClientSiMissing(5),
+            errorUnsupportedClientType(6),
+            errorMandatoryCopsObjectMissing(7),
+            errorClientFailure(8),
+            errorCommunicationFailure(9),
+            errorUnspecified(10),        -- client-type specific subcode
+            errorShuttingDown(11),
+            errorRedirectToPreferredServer(12),
+            errorUnknownCopsObject(13),
+            errorAuthenticationFailure(14),
+            errorAuthenticationMissing(15)
+    }
+--  REFERENCE
+--      "RFC 2748 section 2.2.8"
+
+CopsTcpPort ::= TEXTUAL-CONVENTION
+    STATUS      current
+    DESCRIPTION
+        "A value indicating a TCP protocol port number."
+
+
+
+Smith                       Standards Track                     [Page 6]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+    SYNTAX      INTEGER (0..65535)
+
+CopsAuthType ::= TEXTUAL-CONVENTION
+    STATUS      current
+    DESCRIPTION
+        "A value indicating a type of security authentication mechanism."
+    SYNTAX      INTEGER {
+        authNone(0),
+        authOther(1),
+        authIpSecAh(2),
+        authIpSecEsp(3),
+        authTls(4),
+        authCopsIntegrity(5)
+    }
+
+-- -------------------------------------------------------------
+
+copsClientCapabilitiesGroup OBJECT IDENTIFIER
+                            ::= { copsClientMIBObjects 1 }
+
+-- -------------------------------------------------------------
+--
+-- Capabilities of the COPS client to connect to a COPS server:
+--
+copsClientCapabilities OBJECT-TYPE
+    SYNTAX      BITS {
+        copsClientVersion1(0),     -- supports version1 of COPS protocol
+        copsClientAuthIpSecAh(1) , -- supports IP-SEC Authentication
+        copsClientAuthIpSecEsp(2), -- supports IP-SEC Encryption
+        copsClientAuthTls(3),      -- supports Transport-Layer Security
+        copsClientAuthInteg(4)     -- supports COPS Integrity
+    }
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "A list of the optional capabilities that this COPS client
+        supports."
+    ::= { copsClientCapabilitiesGroup 1 }
+
+-- -------------------------------------------------------------
+
+copsClientStatusGroup OBJECT IDENTIFIER ::= { copsClientMIBObjects 2 }
+
+-- -------------------------------------------------------------
+--
+-- Current status of COPS server connections, all read-only.
+--
+
+
+
+
+Smith                       Standards Track                     [Page 7]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+copsClientServerCurrentTable OBJECT-TYPE
+    SYNTAX      SEQUENCE OF CopsClientServerCurrentEntry
+    MAX-ACCESS  not-accessible
+    STATUS      current
+    DESCRIPTION
+        "A table of information regarding COPS servers as seen from the
+        point of view of a COPS client. This table contains entries
+        for both statically-configured and dynamically-learned servers
+        (from a PDP Redirect operation). One entry exists in this table
+        for each COPS Client-Type served by the COPS server. In addition,
+        an entry will exist with copsClientServerClientType 0 (zero)
+        representing information about the underlying connection itself:
+        this is consistent with the COPS specification which reserves
+        this value for this purpose."
+
+    ::= { copsClientStatusGroup 1 }
+
+copsClientServerCurrentEntry OBJECT-TYPE
+    SYNTAX      CopsClientServerCurrentEntry
+    MAX-ACCESS  not-accessible
+    STATUS      current
+    DESCRIPTION
+        "A set of information regarding a single COPS server serving
+        a single COPS Client-Type from the point of view of a COPS
+        client."
+    INDEX { copsClientServerAddressType, copsClientServerAddress,
+            copsClientServerClientType }
+    ::= { copsClientServerCurrentTable 1 }
+
+CopsClientServerCurrentEntry ::=
+    SEQUENCE {
+        copsClientServerAddressType         InetAddressType,
+        copsClientServerAddress             InetAddress,
+        copsClientServerClientType          INTEGER,
+        copsClientServerTcpPort             CopsTcpPort,
+        copsClientServerType                CopsServerEntryType,
+        copsClientServerAuthType            CopsAuthType,
+        copsClientServerLastConnAttempt     TimeStamp,
+        copsClientState                     CopsClientState,
+        copsClientServerKeepaliveTime       TimeInterval,
+        copsClientServerAccountingTime      TimeInterval,
+        copsClientInPkts                    Counter32,
+        copsClientOutPkts                   Counter32,
+        copsClientInErrs                    Counter32,
+        copsClientLastError                 CopsErrorCode,
+        copsClientTcpConnectAttempts        Counter32,
+        copsClientTcpConnectFailures        Counter32,
+        copsClientOpenAttempts              Counter32,
+
+
+
+Smith                       Standards Track                     [Page 8]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+        copsClientOpenFailures              Counter32,
+        copsClientErrUnsupportClienttype    Counter32,
+        copsClientErrUnsupportedVersion     Counter32,
+        copsClientErrLengthMismatch         Counter32,
+        copsClientErrUnknownOpcode          Counter32,
+        copsClientErrUnknownCnum            Counter32,
+        copsClientErrBadCtype               Counter32,
+        copsClientErrBadSends               Counter32,
+        copsClientErrWrongObjects           Counter32,
+        copsClientErrWrongOpcode            Counter32,
+        copsClientKaTimedoutClients         Counter32,
+        copsClientErrAuthFailures           Counter32,
+        copsClientErrAuthMissing            Counter32
+    }
+
+copsClientServerAddressType OBJECT-TYPE
+    SYNTAX      InetAddressType
+    MAX-ACCESS  not-accessible
+    STATUS      current
+    DESCRIPTION
+        "The type of address in copsClientServerAddress."
+    ::= { copsClientServerCurrentEntry 1 }
+
+copsClientServerAddress OBJECT-TYPE
+    SYNTAX      InetAddress
+    MAX-ACCESS  not-accessible
+    STATUS      current
+    DESCRIPTION
+        "The IPv4, IPv6 or DNS address of a COPS Server. Note that,
+        since this is an index to the table, the DNS name must be
+        short enough to fit into the maximum length of indices allowed
+        by the management protocol in use."
+    REFERENCE
+        "RFC 2748 section 2.3"
+    ::= { copsClientServerCurrentEntry 2 }
+
+copsClientServerClientType OBJECT-TYPE
+    SYNTAX      INTEGER (0..65535)
+    MAX-ACCESS  not-accessible
+    STATUS      current
+    DESCRIPTION
+        "The COPS protocol Client-Type for which this entry
+        applies. Multiple Client-Types can be served by a single
+        COPS server. The value 0 (zero) indicates that this
+        entry contains information about the underlying connection
+        itself."
+    REFERENCE
+        "RFC 2748 section 6, IANA"
+
+
+
+Smith                       Standards Track                     [Page 9]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+    ::= { copsClientServerCurrentEntry 3 }
+
+copsClientServerTcpPort OBJECT-TYPE
+    SYNTAX      CopsTcpPort
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "The TCP port number on the COPS server to which the
+        client should connect/is connected."
+    ::= { copsClientServerCurrentEntry 4 }
+
+copsClientServerType OBJECT-TYPE
+    SYNTAX      CopsServerEntryType
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "Indicator of the source of this COPS server information.
+        COPS servers may be configured by network management
+        into copsClientServerConfigTable and appear in this entry
+        with type copsServerStatic(1). Alternatively, the may be
+        notified from another COPS server by means of the COPS
+        PDP-Redirect mechanism and appear as copsServerRedirect(2)."
+    ::= { copsClientServerCurrentEntry 5 }
+
+copsClientServerAuthType OBJECT-TYPE
+    SYNTAX      CopsAuthType
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "Indicator of the current security mode in use between
+        client and this COPS server."
+    ::= { copsClientServerCurrentEntry 6 }
+
+copsClientServerLastConnAttempt OBJECT-TYPE
+    SYNTAX      TimeStamp
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "Timestamp of the last time that this client attempted to
+        connect to this COPS server."
+    ::= { copsClientServerCurrentEntry 7 }
+
+copsClientState  OBJECT-TYPE
+    SYNTAX      CopsClientState
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "The state of the connection and COPS protocol with respect
+
+
+
+Smith                       Standards Track                    [Page 10]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+        to this COPS server."
+    ::= { copsClientServerCurrentEntry 8 }
+
+copsClientServerKeepaliveTime OBJECT-TYPE
+    SYNTAX      TimeInterval
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "The value of the COPS protocol Keepalive timeout, in
+        centiseconds, currently in use by this client, as
+        specified by this COPS server in the Client-Accept operation.
+        A value of zero indicates no keepalive activity is expected."
+    REFERENCE
+        "RFC 2748 section 3.7, 4.4"
+    ::= { copsClientServerCurrentEntry 9 }
+
+copsClientServerAccountingTime   OBJECT-TYPE
+    SYNTAX      TimeInterval
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "The value of the COPS protocol Accounting timeout, in
+        centiseconds, currently in use by this client, as specified
+        by the COPS server in the Client-Accept operation. A value
+        of zero indicates no accounting activity is to be performed."
+    REFERENCE
+        "RFC 2748 section 3.7"
+    ::= { copsClientServerCurrentEntry 10 }
+
+copsClientInPkts OBJECT-TYPE
+    SYNTAX      Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "A count of the total number of COPS messages that this client
+        has received from this COPS server marked for this Client-Type.
+        This value is cumulative since agent restart and is not zeroed
+        on new connections."
+    ::= { copsClientServerCurrentEntry 11 }
+
+copsClientOutPkts OBJECT-TYPE
+    SYNTAX      Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "A count of the total number of COPS messages that this client
+        has sent to this COPS server marked for this Client-Type. This
+        value is cumulative since agent restart and is not zeroed on new
+
+
+
+Smith                       Standards Track                    [Page 11]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+        connections."
+    ::= { copsClientServerCurrentEntry 12 }
+
+copsClientInErrs OBJECT-TYPE
+    SYNTAX      Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "A count of the total number of COPS messages that this client
+        has received from this COPS server marked for this Client-Type
+        that contained errors in syntax. This value is cumulative since
+        agent restart and is not zeroed on new connections."
+    ::= { copsClientServerCurrentEntry 13 }
+
+copsClientLastError OBJECT-TYPE
+    SYNTAX      CopsErrorCode
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "The code contained in the last COPS protocol Error Object
+        received by this client from this COPS server marked for this
+        Client-Type. This value is not zeroed on COPS Client-Open
+        operations."
+    REFERENCE
+        "RFC 2748 section 2.2.8"
+    ::= { copsClientServerCurrentEntry 14 }
+
+copsClientTcpConnectAttempts OBJECT-TYPE
+    SYNTAX     Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "A count of the number of times that this COPS client has tried
+        (successfully or otherwise) to open an TCP connection to a COPS
+        server. This value is cumulative  since agent restart and is not
+        zeroed on new connections. This value is not incremented for
+        entries representing a non-zero Client-Type."
+    ::= { copsClientServerCurrentEntry 15 }
+
+copsClientTcpConnectFailures OBJECT-TYPE
+    SYNTAX     Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "A count of the number of times that this COPS client has failed
+        to open an TCP connection to a COPS server. This value is
+        cumulative since agent restart and is not zeroed on new
+        connections. This value is not incremented for
+
+
+
+Smith                       Standards Track                    [Page 12]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+        entries representing a non-zero Client-Type."
+    ::= { copsClientServerCurrentEntry 16 }
+
+copsClientOpenAttempts OBJECT-TYPE
+    SYNTAX     Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "A count of the number of times that this COPS client has tried
+        to perform a COPS Client-Open to a COPS server for this
+        Client-Type. This value is cumulative since agent restart and is
+        not zeroed on new connections."
+    ::= { copsClientServerCurrentEntry 17 }
+
+copsClientOpenFailures OBJECT-TYPE
+    SYNTAX     Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "A count of the number of times that this COPS client has failed
+        to perform a COPS Client-Open to a COPS server for this
+        Client-Type. This value is cumulative since agent restart and is
+        not zeroed on new connections."
+    ::= { copsClientServerCurrentEntry 18 }
+
+copsClientErrUnsupportClienttype OBJECT-TYPE
+    SYNTAX     Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "A count of the total number of COPS messages that this client
+        has received from COPS servers that referred to Client-Types
+        that are unsupported by this client. This value is cumulative
+        since agent restart and is not zeroed on new connections. This
+        value is not incremented for entries representing a non-zero
+        Client-Type."
+    ::= { copsClientServerCurrentEntry 19 }
+
+copsClientErrUnsupportedVersion OBJECT-TYPE
+    SYNTAX     Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "A count of the total number of COPS messages that this client
+        has received from COPS servers marked for this Client-Type that
+        had a COPS protocol Version number that is unsupported by this
+        client. This value is cumulative since agent restart and is not
+        zeroed on new connections."
+
+
+
+Smith                       Standards Track                    [Page 13]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+    ::= { copsClientServerCurrentEntry 20 }
+
+copsClientErrLengthMismatch OBJECT-TYPE
+    SYNTAX     Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "A count of the total number of COPS messages that this client
+        has received from COPS servers marked for this Client-Type that
+        had a COPS protocol Message Length that did not match the actual
+        received message. This value is cumulative since agent restart
+        and is not zeroed on new connections."
+    ::= { copsClientServerCurrentEntry 21 }
+
+copsClientErrUnknownOpcode OBJECT-TYPE
+    SYNTAX     Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "A count of the total number of COPS messages that this client
+        has received from COPS servers marked for this Client-Type that
+        had a COPS protocol Op Code that was unrecognised by this
+        client. This value is cumulative since agent restart and is not
+        zeroed on new connections."
+    ::= { copsClientServerCurrentEntry 22 }
+
+copsClientErrUnknownCnum OBJECT-TYPE
+    SYNTAX     Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "A count of the total number of COPS messages that this client
+        has received from COPS servers marked for this Client-Type that
+        contained a COPS protocol object C-Num that was unrecognised by
+        this client. This value is cumulative since agent restart and is
+        not zeroed on new connections."
+    ::= { copsClientServerCurrentEntry 23 }
+
+copsClientErrBadCtype OBJECT-TYPE
+    SYNTAX     Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "A count of the total number of COPS messages that this client
+        has received from COPS servers marked for this Client-Type that
+        contained a COPS protocol object C-Type that was not defined for
+        the C-Nums known by this client. This value is cumulative since
+        agent restart and is not zeroed on new connections."
+
+
+
+Smith                       Standards Track                    [Page 14]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+    ::= { copsClientServerCurrentEntry 24 }
+
+copsClientErrBadSends OBJECT-TYPE
+    SYNTAX     Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "A count of the total number of COPS messages that this client
+        attempted to send to COPS servers marked for this Client-Type
+        that resulted in a transmit error. This value is cumulative
+        since agent restart and is not zeroed on new connections."
+    ::= { copsClientServerCurrentEntry 25 }
+
+copsClientErrWrongObjects OBJECT-TYPE
+    SYNTAX     Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "A count of the total number of COPS messages that this client
+        has received from COPS servers marked for this Client-Type that
+        did not contain a permitted set of COPS protocol objects. This
+        value is cumulative since agent restart and is not zeroed on new
+        connections."
+    ::= { copsClientServerCurrentEntry 26 }
+
+copsClientErrWrongOpcode OBJECT-TYPE
+    SYNTAX     Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "A count of the total number of COPS messages that this client
+        has received from COPS servers marked for this Client-Type that
+        had a COPS protocol Op Code that should not have been sent to a
+        COPS client e.g. Open-Requests. This value is cumulative since
+        agent restart and is not zeroed on new connections."
+    ::= { copsClientServerCurrentEntry 27 }
+
+copsClientKaTimedoutClients OBJECT-TYPE
+    SYNTAX     Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "A count of the total number of times that this client has
+        been shut down for this Client-Type by COPS servers that had
+        detected a COPS protocol Keepalive timeout. This value is
+        cumulative since agent restart and is not zeroed on new
+        connections."
+    ::= { copsClientServerCurrentEntry 28 }
+
+
+
+Smith                       Standards Track                    [Page 15]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+copsClientErrAuthFailures OBJECT-TYPE
+    SYNTAX     Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "A count of the total number of times that this client has
+        received a COPS message marked for this Client-Type which
+        could not be authenticated using the authentication mechanism
+        used by this client."
+    ::= { copsClientServerCurrentEntry 29 }
+
+copsClientErrAuthMissing OBJECT-TYPE
+    SYNTAX     Counter32
+    MAX-ACCESS  read-only
+    STATUS      current
+    DESCRIPTION
+        "A count of the total number of times that this client has
+        received a COPS message marked for this Client-Type which did not
+        contain authentication information."
+    ::= { copsClientServerCurrentEntry 30 }
+
+
+-- -------------------------------------------------------------
+
+copsClientConfigGroup OBJECT IDENTIFIER ::= { copsClientMIBObjects 3 }
+
+-- -------------------------------------------------------------
+
+copsClientServerConfigTable OBJECT-TYPE
+     SYNTAX      SEQUENCE OF CopsClientServerConfigEntry
+    MAX-ACCESS  not-accessible
+    STATUS      current
+    DESCRIPTION
+        "Table of possible COPS servers to try to connect to in order
+        of copsClientServerConfigPriority. There may be multiple
+        entries in this table for the same server and client-type which
+        specify different security mechanisms: these mechanisms will
+        be attempted by the client in the priority order given. Note
+        that a server learned by means of PDPRedirect always takes
+        priority over any of these configured entries."
+    ::= { copsClientConfigGroup 1 }
+
+copsClientServerConfigEntry OBJECT-TYPE
+    SYNTAX      CopsClientServerConfigEntry
+    MAX-ACCESS  not-accessible
+    STATUS      current
+    DESCRIPTION
+        "A set of configuration information regarding a single
+
+
+
+Smith                       Standards Track                    [Page 16]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+        COPS server from the point of view of a COPS client."
+    INDEX { copsClientServerConfigAddrType,
+            copsClientServerConfigAddress,
+            copsClientServerConfigClientType,
+            copsClientServerConfigAuthType }
+    ::= { copsClientServerConfigTable 1 }
+
+CopsClientServerConfigEntry ::=
+    SEQUENCE {
+        copsClientServerConfigAddrType      InetAddressType,
+        copsClientServerConfigAddress       InetAddress,
+        copsClientServerConfigClientType    INTEGER,
+        copsClientServerConfigAuthType      CopsAuthType,
+        copsClientServerConfigTcpPort       CopsTcpPort,
+        copsClientServerConfigPriority      Integer32,
+        copsClientServerConfigRowStatus     RowStatus
+    }
+
+copsClientServerConfigAddrType OBJECT-TYPE
+    SYNTAX      InetAddressType
+    MAX-ACCESS  not-accessible
+    STATUS      current
+    DESCRIPTION
+        "The type of address in copsClientServerConfigAddress."
+    ::= { copsClientServerConfigEntry 1 }
+
+copsClientServerConfigAddress OBJECT-TYPE
+    SYNTAX      InetAddress
+    MAX-ACCESS  not-accessible
+    STATUS      current
+    DESCRIPTION
+        "The IPv4, IPv6 or DNS address of a COPS Server. Note that,
+        since this is an index to the table, the DNS name must be
+        short enough to fit into the maximum length of indices allowed
+        by the management protocol in use."
+    REFERENCE
+        "RFC 2748 section 2.3"
+    ::= { copsClientServerConfigEntry 2 }
+
+copsClientServerConfigClientType OBJECT-TYPE
+    SYNTAX      INTEGER (0..65535)
+    MAX-ACCESS  not-accessible
+    STATUS      current
+    DESCRIPTION
+        "The COPS protocol Client-Type for which this entry
+        applies and for which this COPS server is capable
+        of serving. Multiple Client-Types can be served by a
+        single COPS server."
+
+
+
+Smith                       Standards Track                    [Page 17]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+    REFERENCE
+        "RFC 2748 section 6, IANA"
+    ::= { copsClientServerConfigEntry 3 }
+
+copsClientServerConfigAuthType OBJECT-TYPE
+    SYNTAX      CopsAuthType
+    MAX-ACCESS  not-accessible
+    STATUS      current
+    DESCRIPTION
+        "The type of authentication mechanism for this COPS client
+        to request when negotiating security at the start of a
+        connection to a COPS server."
+    REFERENCE
+        "RFC 2748 section 4."
+    ::= { copsClientServerConfigEntry 4 }
+
+
+copsClientServerConfigTcpPort OBJECT-TYPE
+    SYNTAX      CopsTcpPort
+    MAX-ACCESS  read-create
+    STATUS      current
+    DESCRIPTION
+        "The TCP port number on the COPS server to which the
+        client should connect."
+    ::= { copsClientServerConfigEntry 5 }
+
+copsClientServerConfigPriority OBJECT-TYPE
+    SYNTAX      Integer32
+    MAX-ACCESS  read-create
+    STATUS      current
+    DESCRIPTION
+        "The priority of this entry relative to other entries.
+        COPS client will attempt to contact COPS servers for the
+        appropriate Client-Type. Higher numbers are tried first. The
+        order to be used amongst server entries with the same priority
+        is undefined. COPS servers that are notified to the client using
+        the COPS protocol PDP-Redirect mechanism are always used in
+        preference to any entries in this table."
+    ::= { copsClientServerConfigEntry 6 }
+
+copsClientServerConfigRowStatus OBJECT-TYPE
+    SYNTAX      RowStatus
+    MAX-ACCESS  read-create
+    STATUS      current
+    DESCRIPTION
+        "State of this entry in the table."
+    ::= { copsClientServerConfigEntry 7 }
+
+
+
+
+Smith                       Standards Track                    [Page 18]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+copsClientServerConfigRetryAlgrm OBJECT-TYPE
+    SYNTAX      INTEGER {
+                    other(1),
+                    sequential(2),
+                    roundRobin(3)
+                }
+    MAX-ACCESS  read-write
+    STATUS      current
+    DESCRIPTION
+        "The algorithm by which the client should retry when it
+         fails to connect to a COPS server."
+    DEFVAL { sequential }
+    ::= { copsClientConfigGroup 2 }
+
+copsClientServerConfigRetryCount OBJECT-TYPE
+    SYNTAX      Unsigned32
+    MAX-ACCESS  read-write
+    STATUS      current
+    DESCRIPTION
+        "A retry count for use by the retry algorithm.  Each retry
+         algorithm needs to specify how it uses this value.
+
+         For the 'sequential(2)' algorithm, this value is the
+         number of times the client should retry to connect
+         to one COPS server before moving on to another.
+         For the 'roundRobin(3)' algorithm, this value is not used."
+    DEFVAL { 1 }
+    ::= { copsClientConfigGroup 3 }
+
+copsClientServerConfigRetryIntvl OBJECT-TYPE
+    SYNTAX      TimeInterval
+    UNITS       "centi-seconds"
+    MAX-ACCESS  read-write
+    STATUS      current
+    DESCRIPTION
+        "A retry interval for use by the retry algorithm.  Each retry
+         algorithm needs to specify how it uses this value.
+
+         For the 'sequential(2)' algorithm, this value is the time to
+         wait between retries of a connection to the same COPS server.
+
+         For the 'roundRobin(3)' algorithm, the client always attempts
+         to connect to each Server in turn, until one succeeds or they
+         all fail; if they all fail, then the client waits for the value
+         of this interval before restarting the algorithm."
+    DEFVAL { 1000 }
+    ::= { copsClientConfigGroup 4 }
+
+
+
+
+Smith                       Standards Track                    [Page 19]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+-- -------------------------------------------------------------
+-- Conformance Information
+-- -------------------------------------------------------------
+
+copsClientConformance OBJECT IDENTIFIER ::= { copsClientMIB 2 }
+
+copsClientGroups OBJECT IDENTIFIER ::= { copsClientConformance 1 }
+copsClientCompliances OBJECT IDENTIFIER ::= { copsClientConformance 2 }
+
+-- -------------------------------------------------------------
+-- units of conformance
+-- -------------------------------------------------------------
+
+copsDeviceStatusGroup OBJECT-GROUP
+    OBJECTS {
+        copsClientCapabilities,
+        copsClientServerTcpPort, copsClientServerType,
+        copsClientServerAuthType, copsClientServerLastConnAttempt,
+        copsClientState, copsClientServerKeepaliveTime,
+        copsClientServerAccountingTime, copsClientInPkts,
+        copsClientOutPkts, copsClientInErrs, copsClientLastError,
+        copsClientTcpConnectAttempts, copsClientTcpConnectFailures,
+        copsClientOpenAttempts, copsClientOpenFailures,
+        copsClientErrUnsupportClienttype,
+        copsClientErrUnsupportedVersion, copsClientErrLengthMismatch,
+        copsClientErrUnknownOpcode, copsClientErrUnknownCnum,
+        copsClientErrBadCtype, copsClientErrBadSends,
+        copsClientErrWrongObjects, copsClientErrWrongOpcode,
+        copsClientKaTimedoutClients, copsClientErrAuthFailures,
+        copsClientErrAuthMissing
+    }
+    STATUS      current
+    DESCRIPTION
+        "A collection of objects for monitoring the status of
+        connections to COPS servers and statistics for a COPS client."
+    ::= { copsClientGroups 1 }
+
+copsDeviceConfigGroup OBJECT-GROUP
+    OBJECTS {
+        copsClientServerConfigTcpPort, copsClientServerConfigPriority,
+        copsClientServerConfigRowStatus,
+        copsClientServerConfigRetryAlgrm,
+        copsClientServerConfigRetryCount,
+        copsClientServerConfigRetryIntvl
+    }
+    STATUS      current
+    DESCRIPTION
+        "A collection of objects for configuring COPS server
+
+
+
+Smith                       Standards Track                    [Page 20]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+        information."
+    ::= { copsClientGroups 2 }
+
+-- -------------------------------------------------------------
+-- compliance statements
+-- -------------------------------------------------------------
+
+copsClientCompliance MODULE-COMPLIANCE
+    STATUS  current
+    DESCRIPTION
+        "The compliance statement for device support of
+        management of the COPS client."
+
+    MODULE
+        MANDATORY-GROUPS {
+            copsDeviceStatusGroup, copsDeviceConfigGroup
+        }
+
+        OBJECT      copsClientServerConfigTcpPort
+        MIN-ACCESS  read-only
+        DESCRIPTION
+            "Write access is required only if the device supports the
+            configuration of COPS server information."
+
+        OBJECT      copsClientServerConfigPriority
+        MIN-ACCESS  read-only
+        DESCRIPTION
+            "Write access is required only if the device supports the
+            configuration of COPS server information."
+
+        OBJECT      copsClientServerConfigRowStatus
+        MIN-ACCESS  read-only
+        DESCRIPTION
+            "Write access is required only if the device supports the
+            configuration of COPS server information."
+
+        OBJECT      copsClientServerConfigRetryAlgrm
+        MIN-ACCESS  read-only
+        DESCRIPTION
+            "Write access is required only if the device supports the
+            configuration of COPS server information."
+
+        OBJECT      copsClientServerConfigRetryCount
+        MIN-ACCESS  read-only
+        DESCRIPTION
+            "Write access is required only if the device supports the
+            configuration of COPS server information."
+
+
+
+
+Smith                       Standards Track                    [Page 21]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+        OBJECT      copsClientServerConfigRetryIntvl
+        MIN-ACCESS  read-only
+        DESCRIPTION
+            "Write access is required only if the device supports the
+            configuration of COPS server information."
+
+       ::= { copsClientCompliances 1 }
+
+END
+
+5.  Acknowledgments
+
+   This document describes instrumentation for the client side of the
+   COPS protocol which was defined by the RSVP Admission Policy (rap)
+   Working Group, now known as the Resource Allocation Protocol (rap)
+   Working Group.
+
+6.  Security Considerations
+
+   There are a number of management objects defined in this MIB that
+   have a MAX-ACCESS clause of read-create.  Such objects may be
+   considered sensitive or vulnerable in some network environments.  The
+   support for SET operations in a non-secure environment without proper
+   protection can have a negative effect on network operations.
+
+   SNMPv1 by itself is not a secure environment.  Even if the network
+   itself is secure (for example by using IPSec), even then, there is no
+   control as to who on the secure network is allowed to access and
+   GET/SET (read/change/create/delete) the objects in this MIB.
+
+   It is recommended that the implementers consider the security
+   features as provided by the SNMPv3 framework.  Specifically, the use
+   of the User-based Security Model [USM] and the View-based Access
+   Control Model [VACM] is recommended.
+
+   It is then a customer/user responsibility to ensure that the SNMP
+   entity giving access to an instance of this MIB, is properly
+   configured to give access to the objects only to those principals
+   (users) that have legitimate rights to indeed GET or SET
+   (change/create/delete) them.
+
+
+
+
+
+
+
+
+
+
+
+Smith                       Standards Track                    [Page 22]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+7.  References
+
+   [ARCH]        Harrington, D., Presuhn, R. and B. Wijnen, "An
+                 Architecture for Describing SNMP Management
+                 Frameworks", RFC 2571, April 1999.
+
+   [V1PROTO]     Case, J., Fedor, M., Schoffstall, M. and J. Davin,
+                 "Simple Network Management Protocol", STD 15, RFC 1157,
+                 May 1990.
+
+   [V1SMI]       Rose, M. and K. McCloghrie, "Structure and
+                 Identification of Management Information for TCP/IP-
+                 based Internets", STD 16, RFC 1155, May 1990.
+
+   [V1CONCISE]   Rose, M. and K. McCloghrie, "Concise MIB Definitions",
+                 STD 16, RFC 1212, March 1991.
+
+   [V1TRAPS]     Rose, M., "A Convention for Defining Traps for use with
+                 the SNMP", RFC 1215, March 1991.
+
+   [V2SMI]       McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
+                 J., Rose, M. and S. Waldbusser, "Structure of
+                 Management Information Version 2 (SMIv2)", STD 58, RFC
+                 2578, April 1999.
+
+   [V2TC]        McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
+                 J., Rose, M. and S. Waldbusser, "Textual Conventions
+                 for SMIv2", STD 58, RFC 2579, April 1999.
+
+   [V2CONFORM]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
+                 J., Rose, M. and S. Waldbusser, "Conformance Statements
+                 for SMIv2", STD 58, RFC 2580, April 1999.
+
+   [V2COMMUNITY] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+                 "Introduction to Community-based SNMPv2", RFC 1901,
+                 January 1996.
+
+   [V2TRANS]     Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+                 "Transport Mappings for Version 2 of the Simple Network
+                 Management Protocol (SNMPv2)", RFC 1906, January 1996.
+
+   [V2PROTO]     Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+                 "Protocol Operations for Version 2 of the Simple
+                 Network Management Protocol (SNMPv2)", RFC 1905,
+                 January 1996.
+
+
+
+
+
+
+Smith                       Standards Track                    [Page 23]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+   [V3INTRO]     Case, J., Mundy, R., Partain, D. and B. Stewart,
+                 "Introduction to Version 3 of the Internet-standard
+                 Network Management Framework", RFC 2570, April 1999.
+
+   [V3MPC]       Case, J., Harrington D., Presuhn R. and B. Wijnen,
+                 "Message Processing and Dispatching for the Simple
+                 Network Management Protocol (SNMP)", RFC 2572, April
+                 1999.
+
+   [V3USM]       Blumenthal, U. and B. Wijnen, "The User-Based Security
+                 Model (USM) for Version 3 of the Simple Network
+                 Management Protocol (SNMPv3)", RFC 2574, April 1999.
+
+   [V3APPS]      Levi, D., Meyer, P. and B. Stewart, "SNMP
+                 Applications", RFC 2573, April 1999.
+
+   [V3VACM]      Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
+                 Access Control Model for the Simple Network Management
+                 Protocol (SNMP)", RFC 2575, April 1999.
+
+   [MIB2]        McCloghrie K. and M. Rose, "Management Information Base
+                 for Network Management of TCP/IP-based internets", STD
+                 17, RFC 1213, March 1991.
+
+   [FRAMEWORK]   Yavatkar, R., Pendarakis, D. and Guerin, R., "A
+                 Framework for Policy-based Admission Control", RFC
+                 2753, January 2000.
+
+   [COPS]        Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.
+                 and A. Sastry, "The COPS (Common Open Policy Service)
+                 Protocol", RFC 2748, January 2000.
+
+   [RSVP]        Braden, R. ed., Zhang, L., Berson, S., Herzog, S. and
+                 S.  Jamin, "Resource ReSerVation Protocol (RSVP)
+                 Version 1 - Functional Specification", RFC 2205,
+                 September 1997.
+
+   [COPSRSVP]    Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.
+                 and A. Sastry, "COPS Usage for RSVP", RFC 2749, January
+                 2000.
+
+   [SRVLOC]      Guttman, E., Perkins, C., Veizades, J. and M. Day,
+                 "Service Location Protocol, Version 2", RFC 2608, June
+                 1999.
+
+   [ADDRESSMIB]  Daniele, M., Haberman, B., Routhier, S. and J.
+                 Schoenwaelder, "Textual Conventions for Internet
+                 Network Addresses", RFC 2851, June 2000.
+
+
+
+Smith                       Standards Track                    [Page 24]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+   [PROCESS]     Bradner, S., "The Internet Standards Process --
+                 Revision 3", BCP 9, RFC 2026, October 1996.
+
+8.  Authors' Addresses
+
+   Andrew Smith
+
+   Fax:  +1 415 345 1827
+   Email: ah_smith@pacbell.net
+
+
+   David Partain
+   Ericsson Radio Systems
+   Research and Innovation
+   P.O. Box 1248
+   SE-581 12 Linkoping
+   Sweden
+
+   Phone: +46 13 28 41 44
+   EMail: David.Partain@ericsson.com
+
+
+   John Seligson
+   Nortel Networks, Inc.
+   4401 Great America Parkway
+   Santa Clara, CA 95054
+   USA
+
+   Phone: +1 408 495 2992
+   EMail: jseligso@nortelnetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith                       Standards Track                    [Page 25]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+9.  Notices
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith                       Standards Track                    [Page 26]
+
+RFC 2940                    COPS Client MIB                 October 2000
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith                       Standards Track                    [Page 27]
+