Subject: RE: deprecating dot3StatsEtherChipSets

From: "Kubinec, Lynn" <[email-masked]>
Date: Thu, 28 Jan 1999 08:49:03 -0600

Hi John,

This solution is fine with me.  In the discussion of why the object
has been deprecated, you note that its utility is questionable due
to the fact that the object identifies only the MAC, not the PHY,
etc.  Is it clear, then, in the last sentence:

   For chipsets not listed in [28], implementors should assign
   OBJECT IDENTIFIERS within that part of the registration tree
   delegated to individual enterprises.

that we are not suggesting that implementors come up
with an OID that identifies the MAC, PMD, PHY and driver, but
only that additional MAC devices be identified in this
manner?

If the rest of the group thinks so, then fine...my concern 
isn't overwhelming, I just want our resolution to be as final
as possible :-)

Thanks!

Lynn

> -----Original Message-----
> From: John Flick [mailto:[email-masked]]
> Sent: Wednesday, January 27, 1999 7:16 PM
> To: [email-masked]
> Subject: deprecating dot3StatsEtherChipSets
> 
> 
> After consulting with the chair, we came to the decision to go ahead
> and deprecate the dot3StatsEtherChipSets object.  I am in the process
> of updating the draft (would like to submit the new draft tomorrow,
> with the intent of forwarding it immediately to the IESG, along with
> the MAU MIB draft).  This entails making the following changes to the
> draft:
> 
> - change the STATUS field of dot3StatsEtherChipSets to
>   'deprecated'
> 
> - remove dot3StatsEtherChipSets from the etherStatsBaseGroup
>   OBJECT-GROUP
> 
> - Update the text of Section 3.4 to the following:
> 
>     3.4.  dot3StatsEtherChipSet
> 
>        This document defines an object called 
> dot3StatsEtherChipSet, which
>        is used to identify the MAC hardware used to communicate on an
>        interface.  Previous versions of this document 
> contained a number of
>        OID assignments for some existing Ethernet chipsets.  
> Maintaining
>        that list as part of this document has proven to be 
> problematic, so
>        the OID assignments contained in prevous versions of 
> this document
>        have now been moved to a separate document [28].
> 
>        The dot3StatsEtherChipSet object has now been deprecated.
>        Implementation feedback indicates that this object is much more
>        useful in theory than in practice.  The object's 
> utility in debugging
>        network problems in the field appears to be limited.  
> In those cases
>        where it may be useful, it is not sufficient, since it 
> identifies
>        only the MAC chip, and not the PHY, PMD, or driver.  The
>        administrative overhead involved in maintaining a 
> central registry of
>        chipset OIDs cannot be justified for an object whose 
> usefulness is
>        questionable at best.
> 
>        Implementations which continue to support this object 
> for the purpose
>        of backwards compatability may continue to use the 
> values defined in
>        [28].  For chipsets not listed in [28], implementors 
> should assign
>        OBJECT IDENTIFIERS within that part of the registration tree
>        delegated to individual enterprises.
> 
> - Add the following to the Change Log (Section A.1):
> 
>       (10)  The dot3StatsEtherChipSet object has been deprecated.
> 
>       (11)  The dot3ChipSets have been moved to a separate document.
> 
> Let me know if this sounds acceptable.  If so, I will submit the
> updated draft tomorrow (Thursday).
> 
> Thanks,
> John
>

---

From: John Flick <[email-masked]>
Date: Thu, 28 Jan 1999 14:56:51 -0800 (PST)

> only that additional MAC devices be identified in this

I believe the text in the DESCRIPTION of the chipset object says it
should identify the MAC chip, and we shouldn't try to change that.
However, I would expect that the MIB implementor would assign the OID
in whatever way makes sense in their implementation (e.g., if the MAC
and PHY are on the same chip, the chipset OID would obviously identify
both).  I think that it would be the MIB implementor, not the chip
vendor, that would assign the OID.  This could result in multiple
vendors assigning different OIDs to the same chip.  If both HP and
Cisco were using the same new TI chip set in their products, that chip
set would be given one OID by HP, and another by Cisco.

However, with the object deprecated, I would expect {0 0} and
noSuchObject to become popular chipset IDs :-)

John