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

From: "Hanson,Gary" <[email-masked]>
Date: Mon, 20 Dec 1999 12:40:17 -0800 (PST)

Hi Ken,

Thanks for clarifying your opinion.  I still think we need to get
more opinions in on this issue before leaping to action.  See my
comments below....

Gary

On Mon, 20 Dec 1999, Chapman, Ken wrote:

> > [...]
> > It seems to me that trying to make this object non-mandatory
> > at this point is really a gratuitous change with an arguably
> > small reward, basically a striving for perfection in this MIB
> > that is quite probably unrealizable.
> 
> Yes, the reward is arguably small.
> However, I don't necessarily agree that this means that it is a
> gratuitous change.  I think this is the essence of this debate
> and is a matter of opinion.

Hmmm, yes I agree that the reward is small, and that the essence
of the debate is whether this is a gratuitous change or not.  And
yes, I agree that this is likely to be a matter of opinion.

I'd like to hear the editor's opinion, and also any opinion from
anyone who is actually opposed to this substantive change for any
technical, philosophical, or logistical reason.  Other than the
point that the reward is small, and the obvious point that it
would delay publication of the next IF-MIB version, I am not sure
if there are any other disadvantages that haven't been pointed out.

> I disagree that striving for perfection is unrealizable.
> It is obtaining prefection that is quite probably unrealizable.

Oh, I think you missed my point.  The striving is easy, but the
obtaining is hard.  So, we are (I believe) in complete agreement on
this point.

> > 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?
> 
> Yes, indeed.

> > If so, do you feel we should make those objects non-mandatory
> > now as well?  And, if not, why not?
> 
> Yes, indeed; as a matter of principle.  ;^)

Note that the IF-MIB already contains DESCRIPTION statements for
the ifSpeed and ifHighSpeed objects saying that "For a sub-layer
that has no concept of bandwidth, this object should be zero."

Similarly, the IF-MIB already contains a DESCRIPTION statement for
the ifPhysAddress object saying that "For interfaces which do not
have such an address (e.g., a serial line), this object should
contain an octet string of zero length."

If we were to make these objects non-mandatory, how might we
propose placing them in OBJECT-GROUP(s) to obtain the desired
semantic stipulations?

Would we create one OBJECT-GROUP containing the ifSpeed and
ifHighSpeed objects, and make it mandatory for sub-layers that
have a concept of bandwidth?  If so, would we need to be more
specific about what it means to "have a concept of bandwidth"
so that implementors really know whether or not the object is
mandatory for any given sub-layer?  Would we have to enumerate
the ifType values (or some other criteria) for which there is a
concept of bandwidth?  In so doing, would we potentially render
some fielded implementations non-compliant?  Would that be wise?

Would we create another OBJECT-GROUP containing the ifPhysAddress
object, and make it mandatory for interfaces that have an address
at their protocol sub-layer?  If so, would we again need to be
more specific about the what this means, enumerating the ifType
values (or some other criteria), and would fielded implementations
be rendered non-compliant, and would that be wise, etc.?

Also, are there any other objects in the ifGeneralInformationGroup
that you feel should be made non-mandatory besides ifPhysAddress,
ifSpeed, and ifHighSpeed?

For example, what about ifName?  It, too, like ifPhysAddress,
suggests that "If there is no local name, or this object is
otherwise not applicable, then this object contains a zero-length
string."  Do we need to split this object that is anticipated to not
always be applicable out into its own non-mandatory OBJECT-GROUP?

I would suspect that the if-mib WG members may have different ideas
on whether all of these cases need to be fixed, on how to fix them,
and on the precise details of the wording changes involved in the
fixes, in order to ensure that it would not become significantly
harder for fielded implementations to comply with an IF-MIB that
has been semantically improved in this way.

Any other opinions out there?

---

From: ted brunner <[email-masked]>
Date: Thu, 23 Dec 1999 12:33:05 -0800

Speaking as your working group chair, more opinions weighed in would
be helpful in establishing a rough concensus.  I have heard three
voices, two for change, one against.  At this point I'm not sure
how people feel it is a significant enough improvement to warrent
a respin of the draft.

So vote (early and often?)

ted

-- 

Ted Brunner		VideoTele.com
			Tektronix
			MS 50-475
[email-masked]	14150 SW Karl Braun
503.627.1317		Beaverton OR 97005

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Sat, 25 Dec 1999 11:38:44 -0800 (PST)

> do about the more recently defined ifCounterDiscontinuityTime

No.

> 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]

---

From: [email-masked]
Date: Wed, 29 Dec 1999 11:46:33 -0800 (PST)

Mike,

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