Subject: Re: Ethernet Chipsets Registration (it's worse than that he's...........................)

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

I note we still have heard very little from people actually using the
object...if we deprecate it, we don't really hurt current solutions...

Additionally...

At 10:18 AM 7/15/98 -0700, you wrote:
>Dan et al.
>
>it's worse than that he's dead Jim!

:-)  

>
>What do we mean by a chipset?

Yes, what do we mean...

>
>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.

This is painfully true...i.e., it's caused me pain :-)  So...

>
>	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.

If we end up doing the MAC registration, then I think physical layer
chip registration is a necessity.  

If we don't get both, then I'm not sure it's worth the effort...I'm
still leaning toward option 4. 

Lynn
 
>
>Steve
>
>> -----Original Message-----
>> From:	Dan romascanu DVP-TA [SMTP:[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] 
>> > |
>> > |=========================================|
>> > 
>> > 
>
>