Re: entity mib support for tcif

HI,

On the comment by Juergen, I would probably respond the same way
without first hearing the reason. See below....
At 10:04 AM 10/2/2003 +0200, Juergen Schoenwaelder wrote:
>On Wed, Oct 01, 2003 at 05:33:47PM -0400, Kaj Tesink wrote:
>
>> 2) a) to support the CLEI we have the option of using
>>    entPhysicalVendorType with the elegant method pointed out by Dave;
>>    the only drawback is that this use theoretically may clash with
>>    other uses people may have had in mind.
>> 
>>    b) alternatively, we can define a new entPhysicalVendorType2
>>    and still apply Dvae's method.
>
>If a new object is supposed to hold a CLEI, then this object should
>be named accordingly and use a suitable type. Adding an opaque
>entPhysicalVendorType2 just to avoid calling it a CLEI object is
>IMHO something that just an standards organization can come up with.
CLEI codes are a proprietary and industry segment specific way to
identify physical components and systems. (The Telcordia guys will
argue this point, pointing out that they have been successful in
bringing this identification system through the standards process,
and are close to getting this identification scheme standardized.
Telcordia is the "registrar" for CLEI codes, and has a monopoly
on this business. The costs and procedures for obtaining CLEI
code is proprietary and discriminatory. Likewise, the procedure
and costs for obtaining and distributing a listing of assignements
is proprietary and discriminatory.)

Also of concern is that there may be other industry segments that
have or want to have their own identification system. Favoring
one versus another when there is an unbiased one does not seem
fair.

Now, there is already an identification system via object
entPhysicalVendorType in the entity MIB. Using the mapping
that I've proposed, in the ideal case no new object is needed.
However, a vendor may have already fielded a product using
vendor specific OID values to identify components. Thus, following
a pragmatic approach, a new object is proposed to be added
to specify another identification. That is why another object.
Now, as to why not define the object to hold just a CLEI code,
that is the important issue. And it goes back to the standards
process and having the proper level of abstraction in MIB design
to define an object that can be used for other identification
schemes, and not just for a CLEI code.

Hope this background adds understanding and support for adding
a new object that is not CLEI code specific.

Regards,
/david t. perkins