Subject: RE: Ethernet Chipsets Registration

From: [email-masked]
Date: Thu, 9 Jul 1998 18:05:15 -0700

John et al:

I apologize for not participating in this one until so late in the
process.

I would like to know why we need this object at all (despite 12 of ours
appearing at the top of the list).  Why do other hosts care what chipset
they are talking to?  As long as we have done our jobs right in other
areas mechanisms such as autonegotiation and other MIBs (e.g. RFC2239)
should convey the capabilities of each host (on each port).

Steve

> -----Original Message-----
> From:	John Flick [SMTP:[email-masked]]
> Sent:	Thursday, July 09, 1998 12:05 PM
> To:	Dan romascanu DVP-TA
> Cc:	[email-masked]; [email-masked];
> [email-masked]
> Subject:	Ethernet Chipsets Registration
> 
> Dan,
> 
> I kind of have mixed feelings about this one.  I agree that the
> monumental list of OIDs should be separated out from the Ethernet-like
> 
> Interfaces MIB.  I guess I am less convinced that we need an
> IANA-maintained OID list.  It was probably a mistake to enlarge the
> list in RFC 2358 in the first place.
> 
> The ChipSet object is used to uniquely identify the chipset being used
> 
> on a particular Ethernet interface.  There is no reason why this
> cannot be managed by individual vendors.  I believe you made the
> comment that this would affect interperability.  I guess I don't see
> why it would be any less interoperable than sysObjectID.  All that is
> really needed is for the mapping from OID to chipset to be unique (in
> fact, the mapping the other direction does not even need to be
> unique).  As long as a vendor publishes the mapping from OID to
> chipset that they are using in their implementation, we are fine.
> There really shouldn't be any problem if system vendor A and router
> vendor B are both using the same chipset, but assign differend OIDs to
> 
> that chipset under their proprietary MIBs, as long as they both
> publish the assignment.
> 
> The flip side, however, is that this has not been happening.  Vendors
> have not been publishing OID assignments.  I have encountered many
> implementations that just return 0.0 for the ChipSet object.  We also
> have the problem of the appearance of priviledge for the chips that
> have historical assignments in 2358 and before.
> 
> It would I think be best if we had some way to encourage vendors to
> actually implement the ChipSet object and release their OID assigments
> 
> to chipsets without incurring the overhead of IANA having to manage
> the name space, and having to find a volunteer willing to be the
> designated expert.  (Isn't that why this was an OID to begin with?).
> 
> John
> 
> Dan romascanu DVP-TA writes:
>  > Hub-MIBers,
>  > 
>  > During the review of the Etehrnet-like Interfaces MIB (now RFC
> 2358), 
>  > Harald and Bert raised the issue of the chipset lists, which is
> part of 
>  > this document. The hardware chipsets list, covering now 50% or more
> of 
>  > the MIB text itself, needs to be detached in their opinion from the
> core 
>  > of the management MIB objects. This would allow the registration of
> new 
>  > chipsets to happen in parallel, without influencing the evolution
> of the 
>  > MIB, and without requiring this WG to be active forever, just to
> update 
>  > this list.
>  > 
>  > There are some precedents on managing such lists, with the
> assistance of 
>  > IANA. One such example is RFC 2278 - IANA Charset Registration 
>  > Procedures. The following needs to be done by the WG in order to 
>  > establish a new procedure. 
>  > 
>  > a. issue a Informational RFC of ours, similar to RFC 2278 
>  > b. find a competent and community-dedicated person, who would
> volunteer 
>  > to act as a designated expert (registrar), and manage this list.
>  > c. break out the OIDs list from the Ethernet-like MIB and
> (optional) 
>  > issue a informational RFC including the latest updated list.That
> list 
>  > could go through periodical revisions.
>  > 
>  > I would like to put on the table of the WG the proposal of
> implementing 
>  > such a procedure starting with the next iteration of the
> Ethernet-like 
>  > interfaces MIB, which we are chartered to do for 1 Gigabit
> Ethernet. If 
>  > approved, this would mean that the next Ethernet-like MIB will not 
>  > include the hardware chipsets list, and we will issue the
> informational 
>  > RFC(s) in parallel with the next version of RFC 2358. Please study
> this, 
>  > and comment. I would like to include this item on the agenda of the
> WG 
>  > meeting in Chicago, and take a decision by then. 
>  > 
>  > Dan
>  > 
>  >
> ----------------------------------------------------------------------
> ----
>  > ------
>  > Dan Romascanu,
>  > Systems Architecture Group Manager,
>  > LANNET Ltd.,
>  > Voice: 972-3-645-8414, e-mail: [email-masked]
>  >
> ----------------------------------------------------------------------
> ----
>  > ------
>  >

---

From: John Flick <[email-masked]>
Date: Fri, 10 Jul 1998 13:42:11 -0700 (PDT)

> should convey the capabilities of each host (on each port).

The main reason for this object is so that network administrators or
management apps could take into account any known anomalies or errata
for specific Ethernet chips when trying to diagnose a network
problem.  When this MIB was first written, there were some pretty
significant differences in instrumentation on the various chips that
made it difficult/impossible to implement some of the counters in this 
MIB correctly.  Though the instrumentation is probably alot better
now, there are still quite frequently errata.  And I have had to deal
with relatively new silicon (one of the new additions to the list)
just this year that didn't provide adequate instrumentation to
implement some of the counters in the Ethernet MIB.

It would be interesting to hear if there are any applications or
network administrators out there that are actually using the ChipSet
object.

John