LAPB MIB yet again

"Dean D. Throop" <throop@dg-rtp.dg.com> Tue, 09 June 1992 20:00 UTC

Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa10967; 9 Jun 92 16:00 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa29136; 9 Jun 92 16:00 EDT
Received: from dg-rtp.rtp.dg.com by NRI.Reston.VA.US id aa29106; 9 Jun 92 15:59 EDT
Received: from walrus.rtp.dg.com by dg-rtp.dg.com (5.4/dg-rtp-proto) id AA28858; Tue, 9 Jun 1992 15:14:42 -0400
Received: by walrus (5.4.1/140.2) id AA01479; Tue, 9 Jun 1992 15:12:20 -0400
Date: Tue, 09 Jun 1992 15:12:20 -0400
From: "Dean D. Throop" <throop@dg-rtp.dg.com>
Message-Id: <9206091912.AA01479@walrus>
To: x25mib@dg-rtp
Subject: LAPB MIB yet again

Well here's the status of the LAPB MIB.

We've put it out for review and the review period has elapsed.  
This means the working group is done with the draft.  

I've notified the SNMP area directory and he is planning on 
reviewing the MIB with the SNMP directorate at the July IETF 
meeting.  They need final draft around the end of June.  

I would like to say the LAPB MIB is done but I've noticed some 
additional things that really should be fixed.  Since we've got a 
couple of weeks I'm going to the change MIB and put out yet another 
draft.

The LAPB MIB defines a new type PositiveInteger with values 
(1..2147483647).  The MIB then going on to use PositiveInteger to 
define define T2 and T3 and defines what happens if the timer is 
zero.  While there aren't tools in common use today that check 
assignment of zero to a range of 1.., but there maybe someday in 
the future.  I believe we should just allow zero with
PositiveInteger and not bother to define what zero means in
all the places where zero may not make sense for a configuration
value.

Also we define:
	lapbAdmnN2RxmitCount    OBJECT-TYPE
		SYNTAX  INTEGER (1..255)

and
	lapbOperN2RxmitCount    OBJECT-TYPE
		SYNTAX  INTEGER (0..65535)

Again we should be consistant in the range.  I'd like to change
lapbAdmnN2RxmitCount to (0..65535)

The LAPB MIB defines ifInoctets to be:
_- ifInOctets: contains the number of information bytes
-- received from the peer LAPB.
while MIB-II defines ifInOctets to be
                      "The total number of octets received on the
                      interface, including framing characters."
I believe we should update the definition in the LAPB MIB to 
do what MIB-II states; the number of octets coming in from the peer.

Likewise the LAPB MIB states 
-- ifOutOctets: number of information octets sent to peer.
While MIB-II defines ifOutOctets to be
                      "The total number of octets transmitted out of the
                      interface, including framing characters."
I believe we should update the definition to the LAPB MIB to
do what MIB-II states.


Similarly:
 
-- ifInErrors: contains the number of received packets that
-- contained errors (such as out of sequence,
-- invalid control field, etc);
I believe this should be "The number of Invalid Frames received."
 
-- ifInUnknownProtos: contains the number of received packets
-- that were correct but were dropped due to unknown
-- destinations.
This should be "The number of frames that were dropped because
they contained a bad address or they were inappropriate
for the current LAPB state."

I also have received a number of typos to correct and I won't
bore you with those.

Unless I get objections, I'll make the changes and distribute
yet another MIB.  The status on this version will say completed by
the working group.

Dean Throop		throop@dg-rtp.dg.com