Subject: RE: Ethernet Chipsets Registration

From: Lynn Kubinec <[email-masked]>
Date: Fri, 10 Jul 1998 09:50:21 -0500

Hi,

Just in case there's not enough agreement here :-)  I'll agree that
the list needs to be excised from the MIB file.  I've also always 
questioned the utility of the object itself.  It seems to me to be, 
as John said, very much on par with sysDescr and sysObjectID, etc.  
I wouldn't argue with deprecating the object right out of the MIB.

Lynn

At 06:05 PM 7/9/98 -0700, you wrote:
>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: [email-masked] (Geoff Thompson)
Date: Mon, 13 Jul 1998 19:59:12 -0700

I too have mixed feelings about this one.  I'm not too fond of the approach
taken here becuase keeping the list up to date is a major problem.

The reason for having an object like this is very clear and compelling.  If
everyone has a compliant device and the standard is sufficiently
comprehensive to fully characterize its network behavior then the object is
not needed.

If someone has a bad implementation that you need to search out or if the
network is behaving badly and the cause can be isolated to a particular
implementation of set of implementations that may be causing whatever then
it is tremendiously valuable.

IEEE 802 has what I consider a somewhat better way of doing this.  See IEEE
Std 802.1F clause 7.1.1.2 and also A.5

Geoff

>>  > meeting in Chicago, and take a decision by then. 
|=========================================|
| Geoffrey O. Thompson                    |
| Chair IEEE 802.3                        |
| Bay Networks, Inc.                      |
| 4401 Great America Parkway              |
| P. O. Box 58185                         |
| Santa Clara, CA 95052-8185  USA         |
| Phone: +1 408 495 1339                  |
| Fax:   +1 408 988 5525                  |
| E-Mail: [email-masked]  |
|=========================================|

---

From: "Dan romascanu DVP-TA" <[email-masked]>
Date: Wed, 15 Jul 98 10:03:48 +0300

Geoff,

Thanks for the pointer to the IEEE document. What is described there is 
indeed a more complete structure, composed of four objects, defining 
manufacturerOUI, manufacturerName, manufacturerProductName and 
manufacturerProductVersion. That's probably all somebody would need to 
identify the chipset.

>From what I heard until now, I think we have basically four options to 
proceed with this:

1. Continue with the present method - I think there is almost consensus 
that this is not a good idea, then we would have to overturn the 
recomendation of the IESG review.

2. Go along the IETF / IANA method - that means spliting the documents, 
finding a registrar, all I described in my original proposal.

3. Build a solution based on the 802.1F/A.5 model - pointed to us by 
Geoff. That would avoid the need of a registrar, but would mean 
introducing something new, somehow extra-burdening the agents.

4. Drop the whole stuff. Maybe this is not as useful as it looks, or 
maybe people do not use it anyway?

More opinions, please.

Dan

--------------------------------------------------------------------------
------
Dan Romascanu,
Systems Architecture Group Manager,
LANNET Ltd.,
Voice: 972-3-645-8414, e-mail: [email-masked]
--------------------------------------------------------------------------
------
> The reason for having an object like this is very clear and compelling. 

> If

---

From: [email-masked] (Geoff Thompson)
Date: Wed, 15 Jul 1998 09:45:04 -0700

Dan-

Thanks for the note.

No great surprise, I am in favor of option 3. I think option 4 is a bad
idea. We may not use it often now but think in terms of the Y2K bug.  This
will provide a mechanism that will allow us to come back in later if a
particular implementation(s) have a problem.  I do like that the idea does
not require a registrar. That is always a pain and would be more so in the
future as the number of implementations grows.  The fact that it is based
on an IEEE Standard might give 802 the opportunity to provide normative
support for your requirement.

Geoff

---

From: [email-masked] (Geoff Thompson)
Date: Wed, 15 Jul 1998 11:22:22 -0700

Steve-

Actually the ResourceTypeID does not go with the chip, it goes with the
product.  If you look in 802.3u clause 30 you will see that the combination
of the Mac and Mau or Repeater and Mau are bound to the ResourceTypeId.
There is special provision in 802.3 management for removable maus (AUI etc)
where the configuration cn be changed by the user.

See 802.3u clause 30.1.2 and Figure 30-3

Geoff

At 10:18 AM 7/15/98 -0700, [email-masked] wrote:
>Dan et al.
>
>it's worse than that he's dead Jim!
>
>What do we mean by a chipset?
>
>Interoperability issues may be caused by a MAC (or switch), the physical
>layer devices used, or perhaps only by a particular combination of the
>two.
>
>	If we think manufacturerOUI, manufacturerName,
>manufacturerProductName and 
>manufacturerProductVersion are useful per etherlike I/F, then similar
>objects should be in the MAU MIB.  I don't see them in RFC2239 or clause
>30 of 802.3u.
>
>Steve
>

---

From: Lynn Kubinec <[email-masked]>
Date: Wed, 15 Jul 1998 13:27:50 -0500

Howdy,

At 10:27 AM 7/15/98 -0700, you wrote:
>
>I think this is, increasingly, a local matter for product vendors: I
>would assert that the large majority of Ethernet chips shipped today are
>designed/made by the same company that is manufacturing the device/board
>to which they are glued. If you accept that assertion

Can't accept the assertion...we sell a bunch of chips, we have as
yet to manufacture the board :-)

>, solutions 1 and 2
>become irrelevant and the information proposed in solution 3 can already
>be obtained from the device/board through other MIBs (e.g. entity MIB):

Ouch, the entity MIB?  The etherLike MIB applies to a NIC card in a
PC or Workstation, yes?  The Entity MIB is overkill....

>this should be sufficient for a customer and vendor to trace any
>problem. Solution 4 seems fine to me.
>
>One other alternative, let's call it 2a, if people really want an object
>for chipsets, would be to deprecate just the list of "well known OIDs"
>and make chip or box vendors allocate one from their own enterprise tree
>(general-purpose chip vendors could publish the OID to use with their
>data sheets if they want to). 

I'm not sure this would work nicely, although I can't see why we wouldn't
play along should the overwhelming consensus select this method.

>Please don't set up a new registry anyhow.

I'm less worried about this....

Lynn

>
>Andrew
>
>****************************************************************
>Andrew Smith                              tel: +1 (408) 863-2821
>Extreme Networks                          fax: +1 (408) 342-0990
>10460 Bandley Drive               http://www.extremenetworks.com
>Cupertino CA 95014               em:  [email-masked]
>****************************************************************
>
>
>From: Dan romascanu DVP-TA [mailto:[email-masked]]
>Sent: Wednesday, July 15, 1998 12:04 AM
>To: [email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: RE: Ethernet Chipsets Registration
>
>
>Geoff,
>
>> IEEE 802 has what I consider a somewhat better way of doing this.  See
>
>IEEE