Management Information Base for the PINT Services Architecture
Extracted elements (21)
Gateway connection statistics are placed in a separate MIB group with MODULE-COMPLIANCE clauses so that agents unable to implement gateway monitoring are not mandated to do so, allowing partial conformance.
No SNMP traps are defined in this MIB; instead, thresholding on counters is delegated to the Remote Monitoring (RMON) MIB standard mechanism. Example events include repeated authentication failures and nuisance calls from the same user.
PintServerClientAddress is defined as an SnmpAdminString (human-readable) rather than an IpAddress to minimize the number of indices and maintain a human-readable format simultaneously.
pintServerUserIdName is defined as the UserId and must be unique across multiple PINT servers and gateways. Uniqueness can be achieved by appending clientId to the UserId string; the SessionId can then be a combination of this new UserId and a timestamp.
The configuration table augments the Application MIB (RFC 2287) sysApplInstallPkgEntry using the AUGMENTS construct rather than replicating sysLocation/sysContact, to avoid information duplication. A separate pintSysContact is still defined because the PINT administrator may differ from the system administrator.
This MIB is compliant to SMIv2. A SMIv1-conformant MIB can be produced by translation, but Counter64 objects cannot be translated and must be omitted; machine-readable SMIv2 information is converted to textual descriptions without changing MIB semantics.
All extensions to the values listed in the PINT MIB must be done through Standards Action processes as defined in RFC 2434.
Conformant implementations MUST implement both the pintMibConfigGroup and pintMibMonitorGroup as specified in the MODULE-COMPLIANCE statement pintMibCompliance.
It is recommended that implementers use the SNMPv3 User-based Security Model (RFC 2574) and View-based Access Control Model (RFC 2575) to provide a secure management environment for the PINT MIB.
pintServerConfig contains pintReleaseNumber (read-only PINT protocol version string), pintSysContact (read-write administrator contact), pintApplInstallPkgTable (augments sysApplInstallPkgEntry with a description), and pintRegisteredGatewayTable (name and description of registered gateways).
The MIB is rooted at pintMib (mib-2 93) and is organized into pintServerConfig (1), pintServerMonitor (2), and pintMibConformance (3) subtrees. The OID assignment places the PINT MIB under mib-2.
The PINT MIB defines four PINT service types via the PintServiceType textual convention: r2C (Request-to-Talk), r2F (Request-to-Fax), r2FB (Request-to-Fax-Back), and r2HC (Request-to-Hear-Content). These are the fundamental service categories monitored by the MIB.
The PintPerfStatPeriod textual convention defines four statistics collection periods: last30sec (1), last15min (2), last24Hr (3), and sinceReboot (4). Counters indexed with sinceReboot can be affected by rollover at 2**32-1.
The pintServerClientStatsTable is indexed by pintServerClientAddress (SnmpAdminString), PintServiceType, and PintPerfStatPeriod. It tracks per-client counters: calls received, successful, disconnected, disconnected due to client auth failure, and egress facility problems.
The pintServerGatewayStatsTable is indexed by pintRegisteredGatewayName, PintServiceType, and PintPerfStatPeriod. It tracks per-gateway counters: calls received, successful calls, and disconnected calls.
The pintServerGlobalStatsTable is indexed by PintServiceType and PintPerfStatPeriod and tracks per-service global counters: calls received, successful calls, disconnected calls, disconnections due to client/user auth failure, server problems, and gateway problems.
The pintServerUserIdStatsTable is indexed by pintServerUserIdName (SnmpAdminString, SIZE 0..64), PintServiceType, and PintPerfStatPeriod. It tracks per-user counters: calls received, successful, disconnected, disconnected due to user auth failure, and egress facility problems.
The PINT MIB is assigned the OID mib-2 93 (pintMib ::= { mib-2 93 }). Extensions to MIB values require Standards Action per RFC 2434.
Objects such as pintServerUserIdName may contain business-sensitive customer identification data. GET access should be controlled and SNMP values should be encrypted in transit; SNMPv1 alone provides no such protection even over a secured network.
SNMPv1 provides no access control beyond community strings; it is the operator's responsibility to configure the SNMP entity to grant GET/SET access only to principals with legitimate rights. SNMPv3 with USM and VACM is the recommended mitigation.
The pintSysContact object has MAX-ACCESS read-write; SET operations without proper protection in a non-secure environment can negatively affect network operations. All other objects are read-only, and there are no read-create objects.