Subject: Re: Protocol Action: The Interfaces Group MIB to Proposed Standard

From: "Ted Brunner 503.627.1317" <[email-masked]>
Date: Mon, 17 Nov 1997 10:41:08 -0800

I would like to clarify something I typed last week,
just so there is no mistake.

> To actually hit that date requires some preliminary work.
> Somewhere in the middle of march we will need to assemble
> a list of implementors.  Every object must have 2 implementors.

What I mean is I want to identify and write down the names
of implementors so that list can be submitted along with our
request for promotion of the MIB.  I do _not_ want to get
people and machines in the same room for any sort of testing.

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

---

From: Gary Hanson <[email-masked]>
Date: Mon, 17 Nov 1997 12:44:52 -0800 (PST)

> > a list of implementors.  Every object must have 2 implementors.

Ted,

I think it would be worthwhile to ensure that there are at
least 2 independent implementations of ALL unconditionally
mandatory objects.  Right at the moment, I do not think
that this is the case, based on the most recent table of
independent IF-MIB implementations vs. objects that you
have sent on this list.

If this hurdle is not reached, and the WG requests that the
IF-MIB be advanced to draft, it would be equivalent to asking
the IESG to endorse incomplete implementations, which I don't
think is a good official position for either the WG or the
IESG to take.

> people and machines in the same room for any sort of testing.

By the way, Mike O'Dell and the rest of the IESG have produced
an excellent draft document (draft-iesg-odell-mibtest-00.txt)
that defines the IESG's expectations about "MIB Interoperability
Testing" as part of advancing SNMP MIB specs from proposed to
draft.

There has been a little debate about the extent to which the
IESG can prescribe the actual logistics of this testing, but
the draft certainly makes the intent pretty clear.  I would
recommend that people put their .02 in on it, since it is
itself intended for standards track.

> 503.627.1317			Beaverton OR 97005	

Regards,
Gary

 ______
| ///  |       TM   Gary Hanson                [email-masked]
|   ADC|Kentrox     14375 NW Science Park Dr.  503-641-3321 (FAX)
|______|            Portland, Oregon  97229    800-733-5511 x6333

---

From: "Ted Brunner 503.627.1317" <[email-masked]>
Date: Wed, 19 Nov 1997 11:22:24 -0800

Gary-

> independent IF-MIB implementations vs. objects that you

You are absolutely right.  We do not yet have the required
implementation level.  We need it.  One key reason why
our draft (son of 1573) is still at proposed standard
is that applying the promotion rules (rfc 2026)
allows no "wiggle room" on the implementation requirement.
We should expect the IESG to apply the rules of 2026 as written.

As I mentioned in a previous message, looking over the
implementation matrix made me start to worry.
There are objects with spotty implementation records
(eg. ifTableLastChange, ifRecvAddrTable, ifStackLastChange,
ifCounterDiscontinuity).  But I think these aren't
that hard to implement.

I am more concerned about 64bit counters.
They are difficult.  I know of no shipping implementations.
I don't see anything on the horizon that changes this picture
very quickly (in less than 6 months.)
Not to be overly shrill and alarmist here, but it may turn out that we
aren't progressing this MIB further until we do see a change.

Let's try to get a better picture.
Here are some questions I don't know the answer to:

Are there any media specific mibs which require 64bit counters?
For what sorts of interfaces?  Are these interfaces selling?

Are there limitations on the manager station side?
Are 64bit counters supported on SNM, OpenView, WinSNMP,
and other ones?

Is there any perceived customer pull for 64bit?
Are there any shipping products where 64bit is really necessary
and the agent avoids it?

---

From: Sandra Durham <[email-masked]>
Date: Wed, 19 Nov 1997 12:13:11 -0800 (PST)

> ifCounterDiscontinuity).  But I think these aren't

Could you re-advise on the timeline we are working with
here again?  We have 6 months to get two independent complete
ifmib implementations in order to progress, yes?  

FWIW - we've been hit for all the missing objects in cisco's
implementation, so we plan on implementing everything
"real soon now". I'm reasonably sure we can have a full
implementation of all mib objects by 6 months.

> very quickly (in less than 6 months.)

We've been hit very hard for these lately. I can guarantee you
they will be shipping in less than 6 months.

> For what sorts of interfaces?  Are these interfaces selling?

Highspeed interfaces are all over the show. Customers are
definitely looking for 64bit counters on ATM today. There
are alot of other interface types that need this support
asap as well.  Don't know the shipping details, but
there are OC3 and above interfaces, and gigabit ethernet, etc etc.

> Are 64bit counters supported on SNM, OpenView, WinSNMP,

I'm not sure, but i would imagine any v2 based NMS would
support the counter64 type.  Whether their ifmib usage
goes to ifXTable etc yet, i dunno.  

> Is there any perceived customer pull for 64bit?
Ho yeah.  I get hits for it daily.

> Are there any shipping products where 64bit is really necessary

errr...;-)  I would say any shipping ATM w/o 64bit is
agent avoidance.

Sandra Durham
cisco Systems

---

From: Bob Natale <[email-masked]>
Date: Wed, 19 Nov 1997 16:38:02 -0500

>At 12:13 PM 11/19/97 -0800, Sandra Durham wrote:

Hi Sandra,

<...>
>support the counter64 type.

Yes, ACE*COMM's WinSNMP engine (which is both SNMPv2c and
WinSNMP v2.0 compliant and which will ship with both NTv5
and OpenView/NNM for NT in the near future [and, FYI, is
licensed by Cisco too]) fully supports counter64.

>Whether their ifmib usage goes to ifXTable etc yet, i dunno.

While our engine is "blind" to specific MIB objects per
se (except for the required varbinds of SNMPv2c trap PDUs),
the management utilities in our WinSNMP User Kit can
also handle counter64 objects in any MIB...of course, I
would not characterize that product as an "NMS" in the same
category as an "OpenView", "NetView", "Spectrum", etc.

Cordially,

BobN
----- ISO 9001 Registered Hardware and Software Divsions ----
Bob Natale         | ACE*COMM              | 301-721-3000 [v]
Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f]
[email-masked]| Gaithersburg MD 20878 | www.acecomm.com
---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ----
------ NetPlus (r) "FCAPS" Telemanagement Applications ------

---

From: "Ted Brunner 503.627.1317" <[email-masked]>
Date: Wed, 19 Nov 1997 15:23:25 -0800

Sandra

> ifmib implementations in order to progress, yes?  

Basically Yes.

Six months is the minimum time a protocol or MIB stays at proposed standard
before it may be elevated to draft standard.  It can be more time.
We wanted to be at draft standard now, but since we couldn't be,
the next best is to go to draft as soon as possible.
Mid-May is the earliest.  Because it takes some time to
go through the IESG review, I proposed we start collecting our
supporting documents before that - I suggested 2 months
to track down the progress of a half-dozen vendors.

To succeed in our effort to promote
this MIB to draft we need (among other things) to have
"two independent interoperable implementations" as specified in rfc 2026.
Traditionally that has meant two implementations of each MIB object
which are sematically and syntactically correct.
The verification of that correctness has traditionally been
done by the vendor of the agent implementing the MIB.
Gary mentioned a new draft by Mike O'Dell proposing an explicit
interpretation of that requirement as we go forward.
It's proposal is much the same as what I described above.

The upshot is that it would be sufficient to show
two implementations of the complete MIB
that are shipping, or have completed internal quality testing.
I think that having several implementations
which between them do every object at least twice
is also sufficient.

---

From: "Ted Brunner 503.627.1317" <[email-masked]>
Date: Wed, 19 Nov 1997 15:35:01 -0800

Sandra-

>  I'm reasonably sure we can have a full

This is very good.  This is very good indeed.
This makes me feel much more like we will
be able to promote this MIB as written.

And I don't believe there is a requirement that the
MIB is shipping, so much that the vendor has build it
and verified that it works.  Internal quality testing
should be sufficient there.

Hmm...
Now I just have to identify implementation #2   ;^)