DECnet phiv-mib Status Update
Jon Saperia <saperia@tcpjon.tay.dec.com> Tue, 15 June 1993 19:41 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15792; 15 Jun 93 15:41 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15788; 15 Jun 93 15:41 EDT
Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa19616; 15 Jun 93 15:41 EDT
Received: by inet-gw-2.pa.dec.com; id AA16263; Tue, 15 Jun 93 12:41:31 -0700
Received: by nsl.pa.dec.com; id AA15572; Tue, 15 Jun 93 12:00:22 -0700
Received: by nsl.pa.dec.com; id AA15568; Tue, 15 Jun 93 12:00:21 -0700
Received: by pobox1.pa.dec.com; id AA02734; Tue, 15 Jun 93 12:00:19 -0700
Received: by tcpjon.tay.dec.com (5.57/ULTRIX-fma-071891); id AA03435; Tue, 15 Jun 93 15:04:10 -0400
Message-Id: <9306151904.AA03435@tcpjon.tay.dec.com>
To: phiv-mib@pa.dec.com
Cc: saperia@tcpjon.tay.dec.com
Subject: DECnet phiv-mib Status Update
Date: Tue, 15 Jun 1993 15:04:10 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Jon Saperia <saperia@tcpjon.tay.dec.com>
X-Mts: smtp
A few weeks ago, I sent out an implementation survey to help determine the status of the groups in the DECNet Phase IV MIB. The following groups have been implemented either by a single vendor multiple times, or by multiple vendors, multiple times: phivSystem phivManagement (a single vendor implementation on several platforms) routing circuit ethernet adjacency line area Given this, I propose that the groups above remain mandatory. I also propose that we make the remaining groups below optional. This will leave them in the MIB while it is at Draft Status. I have spoken with Marshall, our area director, about this and this approach is OK. If the groups which are now optional do not have implementation activity, they must be removed before the document is moved to full standard status. The groups which will be moved from mandatory to optional in the draft I am working on as the version to be moved forward as the Draft Standard are: session end ddcmp control counters (this was implemented by a single vendor once) nonBroadcastLine With this as background I plan on preparing a new version of the MIB before the end of this month (per our plan). I sent out a list of potential changes a while ago, I have not had any messages which propose alternatives. Below are the proposals I made and what I plan to do with each (I have not included the obvious things like the typo fix or the fix to the adjacency table): > I will remove phivAdjExecListenTimer if there is a clear > consensus to do so. > I believe that we discussed this on the list previously. The new Adjacency table will not have an ExecListenTimer Object. > I will add phivCountersCountMcastBytesRecd only if there > is a clear consensus to do so AND somebody proposes > explicit wording. > I have not seen any support for this since I posted this note, so I will not add this object. > I will remove entire counters group unless > implementations have been done. If we have agreement to > keep the group, the we should make suggested changes to > descriptions for LINK and LINE - see discussion below (and > notes from John Shriver). Given the approach I outlined above for groups (and that the counters group has been implemented and is in a currently available commercial product), we will keep this group. I will obsolete both phivCountersCountDataBlocksSent and phivCountersCountDataBlocksRecd since their descriptions are identical to those of the phivCountersCountDataBlksRecd and phivCountersCountDataBlksSent objects. For reference purposes, please check the Counters table. Do we have a need/desire to recreate these objects with the change in their descriptions being instead of the word link for each, we use line? Thanks /jon ------------------------------------------ Jon Saperia, Digital Equipment Corporation Internet: saperia@tay.dec.com Voice/FAX 508-952-3171/3023
- DECnet phiv-mib Status Update Jon Saperia