Subject: Chip Set Registrations

From: John Flick <[email-masked]>
Date: Fri, 13 Nov 1998 17:16:59 -0800 (PST)

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: "Dan romascanu DVP-TA" <[email-masked]>
Date: Sun, 15 Nov 98 16:07:33 +0200

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