Subject: RE: [Entmib] entity mib support for tcif

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 2 Oct 2003 10:41:57 +0200

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

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

Bert
> /js

_______________________________________________
Entmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/entmib

---

From: Kaj Tesink <[email-masked]>
Date: Thu, 02 Oct 2003 09:59:23 -0400

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

>told Kaj when he asked me for possible solutions.

right

kaj

> > /js

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

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Oct 2003 16:48:19 +0200

> allows for accommodating other things than CLEIs as well; see this snippet:

While it is true that you can encode almost everything which is small
enough into an OID value, I doubt that this is a really practical and
useful approach.

Even though I understand Dave's concerns, I think that we should make
practical decisions. If CLEI codes play a significant role, then why 
not put something into the MIB that supports this market? It should
be possible to spell out clearly in the description clause of the object
under which conditions this object applies and that ENTITY-MIB
compliance does not require to implement this object or to buy any official
CLEI codes. In fact, it might be possible to turn this object into an
opaque string object which holds an arbitrary identification code which
in some environments might happen to be the CLEI code. With my limited 
knowledge about CLEI codes, I think a string type is more appropriate 
than an OID type.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Oct 2003 16:48:19 +0200

/js