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

From: [email-masked]
Date: Wed, 15 Jul 1998 10:18:41 -0700

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

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