Comments on LAPB SNMP MIB RFC

[Gilbert Glick <[e-mail]>]

Members of the X.25 MIB working group:

I would like to comment on the proposed SNMP MIB for LAPB; I am working
from the final draft dated July 30, 1992.  I've only started looking at
this recently, so some of my comments may have already been hashed out
in previous versions.

By way of background, I'm an X.25 jock consulting with Cisco Systems
for the past year.  They have asked me to evaluate the proposed SNMP MIBs
for X.25 layers 2 and 3 with an eye towards implementing them.  I have
some background in network management although little with SNMP MIBs.


1. On page 14, the name of the lapbAdmnN2RxmitCount element of SEQUENCE
   LapbAdmnEntry is misleading.  Although N2 is typically identified as
   the "retransmit counter" (indeed some protocol validation suites treat
   it as such), the official definition is along the lines of "maximum
   number of transmissions"; the CCITT text makes it clear that N2 is
   the total transmission count, not the retransmission count.  I'd
   suggest "lapbAdmnN2XmitCount".

   Similarly the description on page 17 would need to be modified.
   The 1984 CCITT description might be used:

	"2.4.8.2 Maximum number of attempts to complete a transmission N2
	    ...
	    The value of N2 shall indicate the maximum number of attempts
	 made by the DCE or DTE to complete the successful transmission of
	 a frame to the DTE or DCE, respectively."

   The same comment holds for element lapbOperN2RxmitCount on pages 20
   and 22-23.


2. On page 26, the comment for the n2Timeout element of OBJECT-TYPE
   lapbFlowChangeReason should not read "N2 Timer Expired"; I suggest
   "N2 Count Exceeded".


3. On page 27, the OBJECT-TYPE lapbFlowCurrentMode would be, IMHO, difficult
   to implement as the states are not intuitive.  It combines aspects of
   the protocol service (connected/disconnected) with those of the transmit
   state machine (waiting acknowledgement, remote station busy, etc.) and
   those of the receive state machine (reject sent, station busy, etc.)

   I would prefer to see three separate objects that would separately
   represent the state of the protocol, transmit and receive state
   machines.  Would you entertain something along the following lines?

	lapbServiceState OBJECT-TYPE
	    SYNTAX INTEGER {
		disconnected (1),
			-- initial state or DISC received
		linkSetup (2),
			-- SABM sent
		informationTransfer (3),
			-- data service available
		frameReject (4),
			-- FRMR sent in response to an invalid frame
		disconnecting (5),
			-- DISC sent
		xidFrameSent (6),
			-- SABM sent
	    }
	ACCESS	read-only
	STATUS	mandatory
	DESCRIPTION
	    "The current condition of the protocol service."
	::= { lapbFlowEntry *x* }

	lapbReceiveState OBJECT-TYPE
	    SYNTAX INTEGER {
		noInformationTransfer (1)
			-- data service is not available
		normal (2)
			-- able to receive data
		rejFrameSent (3)
			-- invalid N(S) received and REJ sent
		stationBusy (4)
			-- RNR sent, unable to receive data
	    }
	ACCESS	read-only
	STATUS	mandatory
	DESCRIPTION
	    "The current condition of the data receive service."
	::= { lapbFlowEntry *y* }

	lapbTransmitState OBJECT-TYPE
	    SYNTAX INTEGER {
		noInformationTransfer (1)
			-- data service is not available
		normal (2)
			-- able to send data
		polling (3)
			-- T1 expired and frame sent with Poll bit set
		remoteStationBusy (4)
			-- RNR received
	    }
	ACCESS	read-only
	STATUS	mandatory
	DESCRIPTION
	    "The current condition of the data transmit service."
	::= { lapbFlowEntry *z* }


   Note that some of the following data may also be useful, but I
   consider them to be incidental to the fundamental states:
	a) is the protocol service refusing to come up due to an invalid
	   configuration?
	b) does the receive state machine need to exit stationBusy
	   with a REJ frame?
	c) is the transmit state machine blocked because it has K
	   unacknowledged frames outstanding?
	d) is the transmit machine polling for an I-frame acknowledgement
	   or to check a remote RNR condition?

   I don't believe that this would change the objects lapbFlowStateChanges
   and lapbFlowChangeReason, as they simply apply to the protocol service
   state.


4. On page 29, the description of OBJECT-TYPE lapbFlowT1Timeouts is
   somewhat confusing.  I assume this counter would be incremented
   each time T1 expires.  This is not the same as the number of
   retransmissions, however.  If the description is what we want,
   the name could be modified to something like lapbFlowT1Rexmit.


Thank you for your time.

Gilbert Glick
Cisco Systems X.25 Engineering