Subject: Re: Last Call: The Interfaces Group MIB to Draft Standard

From: ted brunner <[email-masked]>
Date: Thu, 06 Jan 2000 23:25:21 -0800

It sounds to me like we have reached a consensus on this point,
and unless I hear some quick disagreement, I will conclude this topic.

So we shall respin the ifmib, with this change. 

Given that the IESG last call was on Dec.7 with the call for
comments to conclude on Dec.20,  I think we can say
that this is the last change.

Ted Brunner

[email-masked] wrote:

> That sounds like a reasonable argument to me.  I can certainly
> go along with making ifCounterDiscontinuityTime conditionally
> mandatory along the lines you proposed.  It sounds like a minor
> change to any fielded implementations to remove the object from
> those ifTable entries that don't include counters, and I would
> guess that no management station would crash upon encountering
> an entry that included it when it no longer should, since after
> all it WAS required under RFC 2233.
> 
> I also agree with you that it makes sense to NOT fiddle with the
> other unconditionally mandatory objects that are already in the
> ifGeneralInformationGroup.
> 
> Gary
> 
> On Sat, 25 Dec 1999, C. M. Heard/VVNET, Inc. wrote:
> 
> > On Fri, Dec 17 Gary Hanson wrote:
> >
> > > It seems to me that the same argument could be made about the
> > > ifPhysAddress, ifSpeed, and ifHighSpeed objects, all of which
> > > are mandatory objects at present, but which are certainly less
> > > than meaningful for a number of interface types.  Do you feel
> > > as strongly about those objects being pure dead weight as you
> > > do about the more recently defined ifCounterDiscontinuityTime
> > > object?
> >
> > No.
> >
> > > If so, do you feel we should make those objects non-mandatory
> > > now as well?  And, if not, why not?
> >
> > The conformance statements for a generic MIB module such as IF-MIB can
> > provide only a finite level of granularity.  The design provides for six
> > disinct types of interfaces:  bit-oriented, fixed-length, high capacity
> > fixed-length, packet, high capacity packet, very high capacity packet.  All
> > of the unconditionally mandatory objects except ifCounterDiscontinuityTime
> > -- i.e., all of the objects in the ifGeneralInformationGroup -- are at
> > least potentially applicable to every one of those interface types. Now if
> > we were to make some objects now in the ifGeneralInformationGroup optional,
> > that would have the effect of adding more categories of interfaces for
> > management stations to support.   That would arguably make life more
> > difficult for management stations.  So there is some positive benefit in
> > having the objects in the ifGeneralInformationGroup remain unconditionally
> > mandatory.  That is not true, however, for ifCounterDiscontinuityTime.
> > Making it conditionally mandatory does not require major revision of the
> > text, and given that the object is (according to the implementation reports)
> > not universally implemented, should not obsolete fielded implementations.
> > It won't cost us much, so let's get this right while we still can.
> >
> > Mike
> > --
> > C. M. Heard/VVNET, Inc.
> > [email-masked]
> >