Subject: RE: Chip Set Registrations

From: Andrew Smith <[email-masked]>
Date: Mon, 16 Nov 1998 15:24:14 -0800

I agree with John's proposal i.e. no central administration required of this
object. It is up to manufacturers of both the chips and the products that
use them to make management platforms aware of the reverse mappings from
enterprise-id/OIDs to text strings describing the component if they think it
worthwhile. I am not convinced of the continued value of the object anyway -
I think that the only useful semantics are the human-readable DESCRIPTION
string itself and it is not a requirement that the OIDs used by 2 products
using the same chip be the same. And we still have the bug that the object
really needs dividing up into MAC/PHY/PMD parts, similar to 802.3.

Whatever, we do need to get a new Ether-like MIB into last call ASAP and
preferably before Orlando IETF.

Andrew

> -----Original Message-----
> From: Dan romascanu DVP-TA [mailto:[email-masked]]
> Sent: Sunday, November 15, 1998 6:08 AM
> To: [email-masked]; [email-masked]
> Subject: Re: Chip Set Registrations
> 
> 
> John,
> 
> Speaking as a contributor, I have some reservations concerning your 
> proposal. The main question is with the way we can uniquely 
> identify the 
> vendors in the future. It might be that we need to enforce 
> the rule that 
> the OID should be hardly connected with the enterprise 
> subtree MIB and/or 
> with the OUI MAC prefix.
> 
> Speaking as a WG chair, I would point that it's only the 
> Ethernet-like 
> Interfaces Draft needs to obbey to the Nov. 17 deadline. In 
> conclusion, I 
> would sugest that you issue the new I-D, with:
> - the object kept
> - the list taken out
> - some explanatory text.
> 
> Let us compile and discuss the method in the coming two 
> weeks, and maybe 
> reach a conclusion concerning the informational document by 
> the Orlando 
> meeting. No formal meeting is planned in Orlando, I remind 
> you, but I do 
> not think holding a meeting is mandatory. In fact we already 
> discussed 
> this problem in the previous two IETF sessions. Maybe now we 
> can the few 
> of us who care about this matter focus and solve it on the list.
> 
> Best Regards,
> 
> Dan
> 
> --------------------------------------------------------------
> ------------
> ------
> Dan Romascanu,
> Systems Architecture Group Manager,
> LANNET (Lucent Israel),
> Voice: 972-3-645-8414, e-mail: [email-masked]
> --------------------------------------------------------------
> ------------
> ------
> > I would like to propose the following compromise solution to the
> > chipset object dilemma:
> > 
> >   - keep the object current (since the minutes from Chicago seem to
> >     indicate that some people thought it was useful)
> > 
> >   - move the chipset OIDs to a separate, informational document
> > 
> >   - recommend that vendors assign OIDs to any future chipsets under
> >     their own enterprise tree.
> > 
> > The minutes for Chicago indicate that the last suggestion was
> > introduced and rejected.  If I were there, I would have argued that
> > this object is being used to unambiguously identify a specific piece
> > of hardware.  The precedents we have for this in other MIBs include:
> > 
> >   - sysObjectID - used to identify a system.  Assigned by 
> vendor under 
> >     enterprise tree
> > 
> >   - entPhysicalVendorType - used to identify a physical 
> component in a 
> >     system.  Assigned by vendor under enterprise tree
> > 
> > I guess I am having trouble seeing how identifying these hardware
> > components using a vendor-assigned OID is considered acceptable, but
> > identifying a hardware component that happens to be an Ethernet MAC
> > chip using a vendor-assigned OID is considered an
> > interoperability
> > problem.
> > 
> > Aditional comments in favor of this proposal:
> > 
> >   - I guess I can see how this object could be seen as useful under
> >     some circumstances, but I don't think it is useful 
> enough to incur 
> >     the overhead of central administration.
> > 
> >   - If we were going to use central administration, why did 
> we make it 
> >     an OID in the first place?  OIDs are mainly useful in order to
> >     allow vendors to add their own values unilaterally.  
> This suggests 
> >     that the original authors of RFC 1284 had vendor 
> assignment under
> >     the enterprise tree in mind.  This conclusion is 
> supported by the
> >     comment in the MIB (which has been there since RFC 1284).
> > 
> > NOTE:  We need to resolve this by Tuesday, November 17 in order to
> > meet the internet-draft deadline for the Orlando IETF.  Please let
> > your opinions be known
> > IMMEDIATELY!!!!
> > 
> > Thanks,
> > John
> > 
>

---

From: John Flick <[email-masked]>
Date: Mon, 16 Nov 1998 15:46:57 -0800 (PST)

Andrew Smith writes:
 > using the same chip be the same.

Andrew and I are in complete agreement here.  The design here should
be driven from the expected use model.  If this object is expected to
simply be queried by a network administrator to determine which MAC
chip is responsible for some anomalous behaviour, we only need to be
able to map from OID => chip set.  The reverse mapping does not
necessarily need to be unique.  If we cannot agree to a use model, 
maybe deprecating the object is the correct answer.

 > And we still have the bug that the object

The existing object is of questionable use to begin with.  I don't
think I want to split it into three objects of questionable use.

 > preferably before Orlando IETF.

Again, Andrew and I are in complete agreement.  I am in the process of 
cleaning up the document to submit to the internet-drafts editor.  I
plan to send it Tuesday evening (California time).

John