Subject: IF MIB advancement

From: "Ted Brunner 503.627.1317" <[email-masked]>
Date: Tue, 09 Jun 1998 16:05:43 -0700

Dave-

> In the surveys that have been done for implementation of the IF MIB,
> do you have a list of the interface types that have been implemented
> and the interpretation of what is included in the octet counts?
> (There were 137 different types of interfaces when I checked in
> april.)
> 
> I sent out a message a few weeks back on the IF MIB and RMON MIB WG
> mailing lists asking what was included in the octet counts for ethernet
> and token ring and got back different answers. 

No, I do not have a list of the interface types supported by each
of the responding implementations.  And I don't have
any implementation matrix with >137 rows.
I actually hadn't been planning on considering interface types
separately when pulling together our implementation experience.

Last time this working group successfully promoted a MIB to
draft standard, I don't recall such a level of detail
in reporting implementation experience. Admittedly
that was several years ago, and now a new promotion procedure
is in place (RFC 2026).  And perhaps I am relying too much
on past experience.  We (WG + IESG) must decide that point.

But I think that we will generally find situations in the
standardization process where a judgement call must be made.
No process document will cover all the cases.

I also think that the interface mib will challenge us to use our
judgement. It is my view that the interfaces mib is somewhat special
in that it lacks the modularity of many other mibs.
It has objects whose use is dependent on interface type,
the particulars of which is detailed by other mibs.
And that list is steadily expanding.
The interface mib has objects (you mentioned octet counts)
which must be used correctly in those other mibs.

I agree it will take continued monitoring to ensure this.

What I don't want to do is to set unrealistic hurdles for the
standardization of a mib which has "fingers" in other mibs.
I would like our process to be flexible enough to accomodate
mibs which are not strictly modular.

And I am afraid of the O(n) complexity of contacting all the
people involved.  (Just a lazy typist I guess ;^<  )

At the same time, as chair, I am obliged to exercise
due diligence with this MIB, so that the word interoperable
means something.

So I'm left to make a proposal, which is that we consider
such cases on an ad hoc basis.  If they look important,
we make a special effort to figure out whats going on.
Working group members discovering specific problems is the single best
way we have of ensuring the quality of the WG output.

I will also ask all implementors, when I pull in my next/final 
round of implmentation reports, if they had any special experiences
or problems with a specific interface type.

Other suggestions?

Ted Brunner			Video and Networking Division
				Tektronix
				MS 50-490
[email-masked]		14150 SW Karl Braun
503.627.1317			Beaverton OR 97005

---

From: David Perkins <[email-masked]>
Date: Tue, 9 Jun 98 16:24:53 pdt

Ted,

It looks like I was not clear in the message as to the suggestion that I
was making. You didn't include it. It is...

>So, I think that there is a little more work (which I think may be
>just instructions to interface MIB authors) that needs to be included
>when the IF MIB document is split.
What I meant by this is that the instructions for interface MIB authors
need to provide additional guidance. Currently, there is no guidance
to clarify what is meant by the description for ifInOctets, which is
  "The total number of octets received on the interface,
  including framing characters. <rest of description cut>"

Interface utilization is a key number that needs to be calculated.
Guidance needs to be specified in the IF MIB that interface MIB
authors need to include a formula for utilization calculation.

Also, to get new interface types, there needs to be a requirement
for minimum information that must be provide.

In all, I'm sugesting that when the document is split, that the IF
MIB have the current instructions to interface MIB writers extended
to cover the topics which are not covered, but need to be.

I agree with your observation that the IF MIB is a framework that
requires specific interface types to demonstrate interoperability.
An unending list of new interface types can be potentially created.
There is no need to wait until all of them have been created before
advancing the IF MIB.

I think that the only requirement for advancement of the IF MIB is that
example interface types of each "class" of interface supported by
the IF MIB are shown to interoperate. I think that the IF MIB supports
a small finite number of interface "classes". Examples of classes include
packet interfaces, fixed cell interfaces, character interfaces,
virtual interfaces, high speed interfaces, etc.

As to the 137 types of interfaces, I wish there were more than an
few words on each. This is documentation. (A separate document other
than the IF MIB.) Again, I don't see a need to show interoperation of
each 137 types. There only needs to be demonstrated implementation of
each class of interface to make sure that the model works.
 
On Tue, 09 Jun 1998 16:05:43 -0700  Ted Brunner 503.627.1317 wrote:
>Ted Brunner

Regards,
/[email-masked], David T. Perkins
Date: 06/09/98, Time: 16:24:53