Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients
Extracted elements (22)
All COPS protocol statistics counters are cumulative since agent restart and are explicitly not zeroed on new connections. This preserves historical failure data across reconnections, which is useful for diagnosing recurring issues with a specific server.
PDP-Redirect-learned servers always take priority over statically configured entries, regardless of the configured priority value. This reflects the COPS protocol's design intent that a server can delegate to a preferred peer.
The MIB scope is limited to the COPS client; server-side management is explicitly out of scope. Client-type-specific management (e.g., RSVP) is also excluded, keeping the MIB focused on the generic COPS client module only.
The MIB module is SMIv2-compliant. An SMIv1 translation is possible and must be semantically equivalent, except that Counter64 objects (none used here) cannot be translated; machine-readable SMIv2 annotations become textual descriptions in SMIv1.
Compliant implementations MUST support both copsDeviceStatusGroup and copsDeviceConfigGroup as mandatory conformance groups.
Write access to the six configuration objects (TcpPort, Priority, RowStatus, RetryAlgrm, RetryCount, RetryIntvl) is REQUIRED only if the device supports COPS server configuration; otherwise MIN-ACCESS read-only is acceptable.
CopsAuthType textual convention enumerates the supported security mechanisms: authNone(0), authOther(1), authIpSecAh(2), authIpSecEsp(3), authTls(4), and authCopsIntegrity(5). It is used both in the status table (current mode) and the config table (requested mode).
copsClientCapabilities is a BITS object advertising optional client capabilities: copsClientVersion1(0), copsClientAuthIpSecAh(1), copsClientAuthIpSecEsp(2), copsClientAuthTls(3), and copsClientAuthInteg(4). It is read-only and reflects what the local client implementation supports.
copsClientServerAccountingTime (TimeInterval, centiseconds) records the COPS Accounting timeout as specified by the server in Client-Accept. A value of zero means no accounting is to be performed.
copsClientServerConfigPriority (Integer32, read-create) controls the order in which configured COPS servers are attempted; higher numbers are tried first. Servers learned via PDP-Redirect always take precedence over any entry in this table regardless of priority.
copsClientServerConfigRetryAlgrm selects the reconnection algorithm: other(1), sequential(2) default, or roundRobin(3). The retry count and interval semantics differ per algorithm as described in the accompanying scalar objects.
copsClientServerConfigRetryCount (Unsigned32, default 1) and copsClientServerConfigRetryIntvl (TimeInterval, default 1000 centiseconds) parameterise the retry algorithm. For sequential mode, count is retries per server before moving on; for round-robin, count is unused and interval governs the inter-cycle wait.
copsClientServerConfigTable is a read-create configuration table indexed by (InetAddressType, InetAddress, Client-Type, CopsAuthType). Multiple entries for the same server and client-type with different auth types are allowed and tried in priority order.
copsClientServerCurrentTable is a read-only status table indexed by (InetAddressType, InetAddress, Client-Type). One entry exists per Client-Type served; an entry with Client-Type 0 represents the underlying TCP connection itself, consistent with the COPS specification.
copsClientServerKeepaliveTime (TimeInterval, centiseconds) records the COPS Keepalive timeout currently negotiated with the server via Client-Accept. A value of zero means no keepalive activity is expected.
CopsErrorCode textual convention mirrors COPS protocol error codes (RFC 2748 section 2.2.8), ranging from errorOther(0) through errorAuthenticationMissing(15). The code is recorded in copsClientLastError and is not zeroed on Client-Open operations.
CopsServerEntryType distinguishes copsServerStatic(1) entries configured by a manager from copsServerRedirect(2) entries learned via COPS PDP-Redirect. This type is exposed read-only in the status table.
Per-server error counters in copsClientServerCurrentEntry track distinct failure categories: unsupported client type, unsupported version, length mismatch, unknown opcode, unknown C-Num, bad C-Type, bad sends, wrong objects, wrong opcode, keepalive timeouts, auth failures, and missing auth. All are Counter32 and cumulative since agent restart.
The COPS-CLIENT-MIB module is registered under mib-2 89 (copsClientMIB ::= { mib-2 89 }), establishing its OID arc for all COPS client management objects.
Several MIB objects have MAX-ACCESS read-create. Allowing SNMP SET operations in a non-secure environment without proper protection can negatively affect network operations by permitting unauthorized modification of COPS server configuration.
SNMPv1 is not a secure environment; even over IPsec there is no per-principal access control. Implementers are recommended to use SNMPv3 with the User-based Security Model (USM) and View-based Access Control Model (VACM) to restrict GET/SET access to authorised principals.
CopsClientState defines six states for a COPS client connection: copsClientInvalid(1) default, copsClientTcpconnected(2) TCP up but COPS not open, copsClientAuthenticating(3) TCP up but authenticating, copsClientSecAccepted(4) authenticated, copsClientAccepted(5) server accepted client, copsClientTimingout(6) keepalive expired and tearing down.