RE: entity mib support for tcif

At 10:41 AM 10/2/2003 +0200, Wijnen, Bert (Bert) 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.
> >
>I agree here. We should call it what it is. Either we support the idea
>that we need such an object or we don't. But hiding it in some
>obscurely named object does not seem to make sense to me.


that is fine with me too; that was my original proposal. but dave's proposal
allows for accommodating other things than CLEIs as well; see this snippet:

 > On Sat, 6 Sep 2003, David T. Perkins wrote:
[snip]
 > >
 > > If a vendor wants to use CLEI codes, it is a simple matter
 > > to construct the OID value for entPhysicalVendorType from
 > > any CLEI code.
 > >
 > > The only proposal that I would support is to define a standard
 > > OID prefix, and encoding of the suffix of the OID.
 > >
 > > For example, assume and OID value is assigned with descriptor
 > > "entPhysicalVendorTypeCLIE", and the encoding is a sub-identifer
 > > of the decimal value of per character in the CLIE code.
 >






> > > 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.
> >
>And I think that is what option 3)c. allows for. And that is what I had
>told Kaj when he asked me for possible solutions.

right

kaj



>Bert
> > /js


_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies. Inc.
331 Newman Springs Road
Red Bank, NJ 07701
Email: [email protected]
Tel: (732) 758-5254
Fax: (732) 758-4177

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/