Re: entity mib support for tcif

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.
 
> 3) from a documentation perspective we have the following options:
>    a) fold into the existing document; this may jeopardize the entmib
>        going to Draft
>    b) create a supplemental entmib
>    c) create a supplemental entmib that will be folded into the
>       main document once the specs reach the same standainzation status
> 
> all options work for me although on reflection
> i have a slight pref for 2a) over 2b) based on distaste of object 
> proliferation.

I have always raised my voice that not all portions of a MIB module
have to have the same status. We have one precedence - that high
capacity extensions for RMON. If the WG decides that it is crucial
that this MIB goes to Draft, then we should investigate with Bert
whether we can do something to handle this without creating additional
modules or even merging modules, which means putting burden on the
users of these modules.

/js