Subject: PINT MIB Outline

From: Dan Romascanu <[email-masked]>
Date: Thu, 4 Mar 1999 09:54:43 +0200

Please look at the proposal below, concerning the outline of the PINT MIB.
Murali Krishnaswamy and myself would like to receive your feedbacks before
we develop this into a full Internet-Draft.

A few notes:

1.	We propose to build the configuration table as an extension of the
Application MIB - RFC 2287 using the augments construct. The applications
table in this MIB contains:

sysApplInstallPkgTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SysApplInstallPkgEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The table listing the software application packages
           installed on a host computer. In order to appear in
           this table, it may be necessary for the application
           to be installed using some type of software
           installation mechanism or Client registry so that its
           existence can be detected by the agent implementation."

       ::= { sysApplInstalled 1 }

   sysApplInstallPkgEntry OBJECT-TYPE
       SYNTAX      SysApplInstallPkgEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The logical row describing an installed application
           package."
       INDEX    { sysApplInstallPkgIndex }
       ::= { sysApplInstallPkgTable 1 }

   SysApplInstallPkgEntry ::= SEQUENCE {
       sysApplInstallPkgIndex               Unsigned32,
       sysApplInstallPkgManufacturer        Utf8String,
       sysApplInstallPkgProductName         Utf8String,
       sysApplInstallPkgVersion             Utf8String,
       sysApplInstallPkgSerialNumber        Utf8String,
       sysApplInstallPkgDate                DateAndTime,
       sysApplInstallPkgLocation            LongUtf8String
   }

This needs to be AUGMENTed with 

      pintApplInstallPkgDescription	DisplayString
      
Server location and contact might be retrieved from the standard MIB-II
sysLocation and sysContact objects. There is no need to replicate this
information in the PINT MIB. However, the PINT administrator may be a
different person than the sysadmin with global responsibilities, thus a
pintSysContact object is defined.

2.	We chose to monitor the gateway connections from the PINT server.
While the agent runs in the PINT servers, the connections to the gateways
might need to be monitored in order to understand what goes on. We placed
them in a separate MIB group, and by using MODULE-COMPLIANCE clauses, agents
that cannot implement this stuff will not be mandated to do it.

3.	There is no traps definition in this preliminary proposal. Note that
thresholding on counters is always possible by using a standard mechanism
defined by the Remote Monitoring MIB, that can be referenced here. Some
events that may be defined by using this mechanisms:
*	continuous login/authentication failure or refusal from a particular
client or user
*	nuisance call - repeated calls (within a specified period) to a
number originating from the same user
		 
4.	The client performance and user performance tables may be rather
resource demanding for an agent implementation. In some MIBs, like the
Remote Monitoring (RMON) MIBs, control mechanisms were built in order to
activate those statistics on demand. Also, a sorting ('topN') mechanism can
de designed, so that a sorted view of clients or users is presented for the
high level debugging. We did not include such mechanisms right now, we first
want to hear whether you think they might be necessary.

5.	We built a time-distribution trying to cover both short-lived, as
well as longer sessions (1-10 secs, 10 secs - 1 min., 1-15 min., 15 mins-24
hours, longer). Please feel free to propose some more educated figures.

6.	PintServerClientAddress is defined as a DisplayString. It may
include an IpAddress and/or name, but we prefered to minimize the number of
indices at this stage, and keep a human-readable format at the same time. 

7.	At this stage we defined pintServerUserIdName as the UserId. We
might want to discuss later how this maps to SessionId, of whether we need
to support the whole unique session identification (userId, clientId,
timestamp).

Here is the proposed MIB structure:

PintServiceType	::= TEXTUAL-CONVENTION
	SYNTAX 	INTEGER {
		r2c(1),
		r2f(2),
		r2fb(3),
		r2hc(4)
		}

pintServerConfig         OBJECT IDENTIFIER ::= { pintObjects 1 }
pintServerMonitor	OBJECT IDENTIFIER ::=  {pintObjects 2 }

pintReleaseNumber OBJECT-TYPE
       SYNTAX      DisplayString
       ::= { pintServerConfig 1 }

pintSysContact           OBJECT-TYPE
      SYNTAX        DisplayString 
      ::= { pintServerConfig 2 }

pintApplInstallPkgTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF PintApplInstallPkgEntry
       ::= { pintServerConfig 3 }

   pintApplInstallPkgEntry OBJECT-TYPE
       SYNTAX      PintApplInstallPkgEntry
       AUGMETS { sysApplInstallPkgIndex }
       ::= { pintApplInstallPkgTable 1 }

   PintApplInstallPkgEntry ::= SEQUENCE {
       pintApplInstallPkgDescription	DisplayString
   }

pintServerGlobalPerf  	OBJECT IDENTIFIER ::= {pintServerMonitor 1 }
pintServerClientPerf		OBJECT IDENTIFIER ::= {pintServerMonitor 2 }
pintServerUserIdPerf		OBJECT IDENTIFIER ::= {pintServerMonitor 3 }

pintServerGlobalStatsTable	OBJECT-TYPE
SYNTAX      SEQUENCE OF PintServerGlobalStatsEntry
::= { pintServerGlobalPerf 1 }

pintServerGlobalStatsEntry OBJECT-TYPE
       SYNTAX      PintServerGlobalStatsEntry
       INDEX {pintServerGlobalStatsIndex}
       ::= { pintServerGlobalStatsTable 1 }

PintServerGlobalStatsEntry	::=  SEQUENCE {
pintServerGlobalStatsIndex
PintServiceType,
pintServerGlobalCallsReceived 				Counter32,
pintServerGlobalSuccessfulCalls				Counter32,
pintServerGlobalDisconnectedCalls 				Counter32,
pintServerGlobalDisconnectedEgressFacilityRefuseCalls 	Counter32,
pintServerGlobalDisconnectedRemoteEndProblemCalls 	Counter32,
pintServerGlobalCallsInProgress 				Counter32,
pintServerGlobalCallsLessThen10seconds 			Counter32,
pintServerGlobalCalls10secondsToOneMinute 		Counter32,
pintServerGlobalCallsOneTo15Minutes 	    		Counter32,
pintServerGlobalCalls15MinutesTo24Hours 		Counter32,
pintServerGlobalCallsLongerThen24Hours	 		Counter32,
pintServerGlobalRequestsReceived				Counter32
}

pintServerClientStatsTable	OBJECT-TYPE
SYNTAX      SEQUENCE OF PintServerClientStatsEntry
::= { pintServerClientPerf 1 }

pintServerClientStatsEntry OBJECT-TYPE
       SYNTAX      PintServerClientStatsEntry
       INDEX {pintServerClientStatsIndex, pintServerClientAddress}
       ::= { pintServerClientStatsTable 1 }

PintServerClientStatsEntry	::=  SEQUENCE {
pintServerClientStatsIndex
PintServiceType,
pintServerClientAddress					DisplayString,
pintServerClientCallsReceived 				Counter32,
pintServerClientSuccessfulCalls				Counter32,
pintServerClientDisconnectedCalls 				Counter32,
pintServerClientDisconnectedEgressFacilityRefuseCalls 	Counter32,
pintServerClientDisconnectedRemoteEndProblemCalls 	Counter32,
pintServerClientCallsInProgress 				Counter32,
pintServerClientCallsLessThen10seconds 			Counter32,
pintServerClientCalls10secondsToOneMinute 		Counter32,
pintServerClientCallsOneTo15Minutes 	    		Counter32,
pintServerClientCalls15MinutesTo24Hours 			Counter32,
pintServerClientCallsLongerThen24Hours	 		Counter32,
pintServerClientRequestsReceived				Counter32
}

pintServerUserIdStatsTable	OBJECT-TYPE
SYNTAX      SEQUENCE OF PintServerUserIdStatsEntry
::= { pintServerUserIdPerf 1 }

pintServerUserIdStatsEntry OBJECT-TYPE
       SYNTAX      PintServerUserIdStatsEntry
       INDEX {pintServerUserIdStatsIndex, pintServerUserIdName}
       ::= { pintServerUserIdStatsTable 1 }

PintServerUserIdStatsEntry	::=  SEQUENCE {
pintServerUserIdStatsIndex
PintServiceType,
pintServerUserIdName					UserIdName,
pintServerUserIdCallsReceived 				Counter32,
pintServerUserIdSuccessfulCalls				Counter32,
pintServerUserIdDisconnectedCalls 				Counter32,
pintServerUserIdDisconnectedEgressFacilityRefuseCalls 	Counter32,
pintServerUserIdDisconnectedRemoteEndProblemCalls 	Counter32,
pintServerUserIdCallsInProgress 				Counter32,
pintServerUserIdCallsLessThen10seconds 			Counter32,
pintServerUserIdCalls10secondsToOneMinute 		Counter32,
pintServerUserIdOneTo15Minutes 	    			Counter32,
pintServerUserId15MinutesTo24Hours 			Counter32,
pintServerUserIdLongerThen24Hours	 		Counter32,
pintServerUserIdRequestsReceived				Counter32
}

Waiting for your comments,

Regards,

Dan

---------
This message came from the IETF PINT Working Group Mailing List.