Subject: RE: Ethernet Chipsets Registration

From: Andrew Smith <[email-masked]>
Date: Wed, 15 Jul 1998 10:27:07 -0700

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, 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):
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). Please don't set up a new registry anyhow.

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

-----Original Message-----
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,

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]
------------------------------------------------------------------------
--
------
> 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
> 
> 
> At 06:05 PM 7/9/98 -0700, [email-masked] 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]
>>>  >
>>> 
----------------------------------------------------------------------
>>> ----
>>>  > ------
>>>  > 
>>
> |=========================================|
> | 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: John Flick <[email-masked]>
Date: Wed, 15 Jul 1998 12:07:16 -0700 (PDT)

Andrew Smith writes:
 > to which they are glued.

This is probably true for high-end switches, I don't think it is
necessarily true in desktop switches, where many vendors use
off-the-shelf chips.  It is rarely true for Ethernet interfaces in end 
nodes.

 > If you accept that assertion, solutions 1 and 2

It seems unlikely that an end node like a PC or Unix box would be
implementing the Entity MIB.  However, some board level info should
probably be available thru ifDescr.  In particular, much of the info
found in ResourceTypeID should be able to be contained in ifDescr,
albeit as an unstructured string:

   ifDescr OBJECT-TYPE
       SYNTAX      DisplayString (SIZE (0..255))
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "A textual string containing information about the
               interface.  This string should include the name of the
               manufacturer, the product name and the version of the
               interface hardware/software."
       ::= { ifEntry 2 }

 > data sheets if they want to). Please don't set up a new registry anyhow.

I think 2a is what I was trying to say in my last message.  An OID is
just an authoritative name.  It really doesn't matter where it is
rooted.

John