DECnet phiv-mib Status Update

Jon Saperia <> Tue, 15 June 1993 19:41 UTC

Received: from 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 by CNRI.Reston.VA.US id aa19616; 15 Jun 93 15:41 EDT
Received: by; id AA16263; Tue, 15 Jun 93 12:41:31 -0700
Received: by; id AA15572; Tue, 15 Jun 93 12:00:22 -0700
Received: by; id AA15568; Tue, 15 Jun 93 12:00:21 -0700
Received: by; id AA02734; Tue, 15 Jun 93 12:00:19 -0700
Received: by (5.57/ULTRIX-fma-071891); id AA03435; Tue, 15 Jun 93 15:04:10 -0400
Message-Id: <>
Subject: DECnet phiv-mib Status Update
Date: Tue, 15 Jun 93 15:04:10 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Jon Saperia <>
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: 

   phivManagement (a single vendor implementation on several platforms)

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

   counters (this was implemented by a single vendor once)
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?


	Jon Saperia, Digital Equipment Corporation			
	Voice/FAX  508-952-3171/3023