DECnet MIB question (4)

Debasis Dalapati <> Fri, 21 August 1992 16:00 UTC

Received: from by IETF.NRI.Reston.VA.US id aa03359; 21 Aug 92 12:00 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03354; 21 Aug 92 12:00 EDT
Received: from by NRI.Reston.VA.US id aa09617; 21 Aug 92 12:01 EDT
Received: by; id AA16153; Fri, 21 Aug 92 09:00:55 -0700
Received: by; id AA19559; Fri, 21 Aug 92 08:30:17 -0700
Received: by; id AA19555; Fri, 21 Aug 92 08:30:16 -0700
Received: by; id AA14155; Fri, 21 Aug 92 08:30:15 -0700
Received: by bagate.BELL-ATL.COM (/\==/\ Smail3.1.25.1 #25.29)id <m0mLaxp-0000gBC@bagate.BELL-ATL.COM>; Fri, 21 Aug 92 11:31 EDT
Received: by (4.1/SMI-4.1)id AA10603; Fri, 21 Aug 92 11:30:08 EDT
Date: Fri, 21 Aug 92 11:30:08 EDT
From: Debasis Dalapati <>
Message-Id: <>
Subject: DECnet MIB question (4)


Could anybody help me in understanding "DECnet style locking counters".
It is mentioned in the description of counters group in RFC1289, page 45.

These counters are maintained on interface basis. Is there any means/necessity
of zeroing out these counters? Also, is there any means/necessity for zeroing
out the counters in phivDDCMPLineCountEntry objects? 

If an interface is used by other protocol stacks along with DECnet, in what
manner should these counters be maintained/reported? Does "locking counters"
have anything to do with this issue, in the sense that an interface may be
shared by multiple stacks but it could be managed through the management 
instrumentation of only DECnet protocol stack?

Do you see the Phase IV MIB changing in future to separate interface specific
management information from itself?