From exim@www1.ietf.org Wed Oct 1 17:35:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05828 for ; Wed, 1 Oct 2003 17:35:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ocg-0005eL-Qq for entmib-archive@odin.ietf.org; Wed, 01 Oct 2003 17:35:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91LZ2Ug021716 for entmib-archive@odin.ietf.org; Wed, 1 Oct 2003 17:35:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ocg-0005e9-36; Wed, 01 Oct 2003 17:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ocP-0005dZ-U9 for entmib@optimus.ietf.org; Wed, 01 Oct 2003 17:34:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05795 for ; Wed, 1 Oct 2003 17:34:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ocJ-0005op-00 for entmib@ietf.org; Wed, 01 Oct 2003 17:34:39 -0400 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ocC-0005o4-00 for entmib@ietf.org; Wed, 01 Oct 2003 17:34:33 -0400 Received: from shannon.research.telcordia.com (shannon-83.research.telcordia.com [128.96.83.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id h91LXres026277 for ; Wed, 1 Oct 2003 17:33:53 -0400 (EDT) Received: from kaj-100.research.telcordia.com (kaj-100.cc.telcordia.com [128.96.71.110]) by shannon.research.telcordia.com (8.9.3/8.9.3) with ESMTP id RAA24583 for ; Wed, 1 Oct 2003 17:33:53 -0400 (EDT) Message-Id: <4.3.2.7.2.20031001171034.01610dd8@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Oct 2003 17:33:47 -0400 To: entmib@ietf.org From: Kaj Tesink Subject: RE: [Entmib] entity mib support for tcif In-Reply-To: References: <93401232EABAAB4EA430E13ECC701CCF2A0D3E@yorktown.pedestalnetworks.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_32504879==_.ALT" X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , --=====================_32504879==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed folks, i consulted with some interested parties directly. my impression is that we could do the following: 1) to support the Manufacture Date we'll need a new object entPhysicalMfgDate that augments the entPhysicalTable 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. 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. any preferences out there? kaj At 03:29 PM 9/7/2003 -0700, David T. Perkins wrote: [snip] >And responding to Faye's question.... >If a well know prefix is used, this does not create any additional >work for vendors. That is, they already have to "create an OID registry" >to support object entPhysicalVendorType. And for management platforms >that want to use CLEI codes, a standard prefix (and encoding rules) >allows them to "extract" a CLEI code from the value of >entPhysicalVendorType, and all other management platforms to be >blissfully unaware of CLEI codes. > >On Sun, 7 Sep 2003, Faye Ly wrote: > > Just playing the devil's advocate! On the other hand, CLEI code is a > > fixed string and although it is more elegant to maintain an OID registry > > per vendor but this might grow for a NMS that manages multiple vendors. > > A fixed string as an augmented table to the physical entity table is > > more straightforward to support. > > > > -faye > > > > -----Original Message----- > > From: C. M. Heard [mailto:heard@pobox.com] > > Sent: Sunday, September 07, 2003 12:59 AM > > To: entmib@ietf.org; Kaj Tesink; Giamboi, Anthony; Lam, Hing-Kam (Kam); > > Faye Ly; Juergen Schoenwaelder; Margaret Wasserman; David T. Perkins; > > Wijnen, Bert (Bert); atommib@research.telcordia.com > > Subject: Re: [Entmib] entity mib support for tcif > > > > On Sat, 6 Sep 2003, David T. Perkins wrote: > > > I believe that adding a CLEI code (common langauge equipment > > > identifier code) is completely redundant with the object > > > entPhysicalVendorType and should not be added. > > > A CLEI code is a globally unique value that is purchased > > > from Telcordia. It costs approximately $100 to get the > > > document from Telcordia that defines CLEI codes, and > > > it costs per assigned code. > > > > > > 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. > > > > I think this is a VERY GOOD idea. > > > > In previous off-line discussions entPhysicalModelName was suggested > > as one place where a CLEI code might live. While there is nothing > > wrong with putting a CLEI code there (especially if it's on a bar > > code on the label), there would be no guarantee that any particular > > manufacturer did this, nor is there a sure-fire way for a management > > application to tell if what's there is actually a CLEI code, if it > > happens to be 10 octets long. But entPhysicalVendorType contains an > > OID, which is self-describing. Very elegant. > > > > I wish there were as neat a solution for entPhysicalMfgDate :-( > > > > Mike > > >Regards, >/david t. perkins At 10:44 AM 9/5/2003 -0700, C. M. Heard wrote: >>>>> On Fri, 5 Sep 2003, Juergen Schoenwaelder wrote: JS> On Thu, Sep 04, 2003 at 07:29:23PM -0400, Kaj Tesink wrote: JS> JS> > new objects: JS> > JS> > entPhysicalCLIECode OBJECT-TYPE This should say entPhysicalCLEICode yup, sorry about the typo JS> > SYNTAX SnmpAdminString (SIZE (0..10)) JS> > MAX-ACCESS read-write JS> > STATUS current JS> > DESCRIPTION JS> > "The CLIE Code for the physical entity. If a CLIE Code JS> > is unknown or non-existent, the entPhysicalCLIECode will JS> > be set to a zero-length string instead." JS> > ::= { entPhysicalEntry xx } JS> > REFERENCE "TCIF-02-004, Guideline for data elements JS> > included in the Management Information Base, JS> > Telecommunications Industry Forum (TCIF), 09/11/2002. JS> > ANSI T1.213-2001, Coded identification of equipment entities JS> > of the North American telecommunications system for JS> > information exchange, ANSI. JS> > ANSI T1.213a-2001, Supplement to T1.213-2001, JS> > Coded identification of equipment entities of the North JS> > American telecommunications system for information exchange, JS> > to correct the representation of the Basic Code in JS> > Figure B.1, ANSI." JS> JS> Can someone translate that into something I can understand? JS> JS> Explaining entPhysicalCLIECode with "The CLIE Code for the physical JS> entity." is not really helpful for those poor souls who have no clue JS> what a CLIE code is (and the reference does not look like it is easy JS> to find the answer somewhere on the web). Would it help to modify the definition like so: entPhysicalCLEICode OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..10)) MAX-ACCESS read-write STATUS current DESCRIPTION "The CLEI (Common Language Equipment Identifier) Code for the physical entity. If the CLEI Code is unknown, or if no CLEI code exists, then this object will contain a zero-length string." REFERENCE [ ... as above ... ] ::= { entPhysicalEntry xx } yup and perhaps to have something in the narrative section of the defining document (whatever it turns out to be) that more completely defines the nature and usage of a CLEI code? >>>>> On Thu, 4 Sep 2003, Margaret Wasserman wrote: MW> I am trying to understand your request... I think I can answer some of these questions. Kaj, please step in and correct me if I get anything wrong. MW> Why has the TCIF defined objects that must occur in a MIB, MW> without a defining a MIB that includes them? The TCIF documents are requirements documents: they mandate what information must be present but don't mandate a specific method for getting it there. If the information isn't provided by a standard MIB module then a proprietary MIB module can be used to satisfy the requirement. This is a common approach in the telecom industry. right on MW> Why do you think that it would make sense to add these objects MW> to the Entity MIB? Are you expecting each sub-component in a MW> system to have separate CLIE codes and manufacturing information? MW> Or would there be one set for the entire box? There is a separate CLEI code and manufacturing date for each Field Replaceble Unit or FRU. A line card ("circuit pack" in telecom-speak) would be an example of an FRU. right. CLEIs are not necessarily box-related. this is one reason why the entity mib seems a reasonable place to put this info. MW> Why do you think that it would be better to include these MW> objects in the Entity MIB than it would be to publish a MW> separate MIB module that includes these objects? I think there is some distaste for artifically fragmenting MIB modules into "base" and "supplemental" parts just to get around the problem that the presence of new objects inhibits advancement on the standards track. This is especially the case when there would be only a small number of object (two, in this case) in the supplemental MIB module. A supplemental MIB module seems like overkill in that case. yup, that was the logic That said, it is certainly feasible to define a supplemental MIB module with one conceptual table whose row object AUGMENTS entPhysicalEntry and contains just the two objects entPhysicalCLEICode and entPhysicalMfgDate. It's even possible to do this in a proprietary MIB module or in a MIB module sponsored by a telecom industry consortium, although I think that there would probably be greater regard for a MIB module that is on the IETF standards track. we looked at these alternatives; esp. the CLEI is widely used now, so enterprise-specific approaches are not the preferred path forward. as mike points out above, the tcif is not into mib specifications; they look at organizations like the ietf as the most appropriate place for that. kaj Hope that helps, Mike ============================================================= ========================================================= entity mib wg, attached is a discussion on accommodating some TCIF information elements in an appropriate MIB module. the entity mib would be a good candidate, but we understand that the timing may be problematic since it's going to draft right now. we're talking about 6 data elements (see TCIF-02-004, 09/11/2002). most can probably be mapped to existing objects, but not all. so it appears that we have several options: a) extend the entity mib with the 'missing' objects (see attached strawman) b) write a 'supplemental' mib module for the 'missing' objects c) find another suitable mib module while a) seems most desirable the current state of the entity mib may make it problematic(?). (b) seems somewhat overkill. (c) seems suboptimal. the new objects would only be required for systems that support management access to this information. any comments? particulars attached, pl copy Cc list above, kaj, tony, ============================================================ TCIF Required MIB objects: - CLEI Code Suggested to use: new object Reference: TCIF-02-004, 09/11/2002 Reference: ANSI T1.213-2001 and T1.213a-2001, T1M1.3 - Unique Serial Identification (USI) Suggested to use: entPhysicalSerialNum - Software Version Suggested to use: entPhysicalSoftwareRev - Manufacture Date Suggested to use: new object TCIF Optional MIB objects: - Manufacturer Identification Suggested to use: entPhysicalMfgName - Manufacturer Product Identification Suggested to use: entPhysicalModelName ============================================================= new objects: entPhysicalCLIECode OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..10)) MAX-ACCESS read-write STATUS current DESCRIPTION "The CLIE Code for the physical entity. If a CLIE Code is unknown or non-existent, the entPhysicalCLIECode will be set to a zero-length string instead." ::= { entPhysicalEntry xx } REFERENCE "TCIF-02-004, Guideline for data elements included in the Management Information Base, Telecommunications Industry Forum (TCIF), 09/11/2002. ANSI T1.213-2001, Coded identification of equipment entities of the North American telecommunications system for information exchange, ANSI. ANSI T1.213a-2001, Supplement to T1.213-2001, Coded identification of equipment entities of the North American telecommunications system for information exchange, to correct the representation of the Basic Code in Figure B.1, ANSI." entPhysicalMfgDate OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The manufacturing date for the physical entity." ::= { entPhysicalEntry xx } _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Kaj Tesink Telcordia Technologies. Inc. 331 Newman Springs Road Red Bank, NJ 07701 Email: kaj@research.telcordia.com Tel: (732) 758-5254 Fax: (732) 758-4177 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ --=====================_32504879==_.ALT Content-Type: text/html; charset="us-ascii" folks, i consulted with some interested parties directly.
my impression is that we could do the following:

1) to support the Manufacture Date we'll need a new object
   entPhysicalMfgDate that augments the entPhysicalTable

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.

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.

any preferences out there?


kaj




At 03:29 PM 9/7/2003 -0700, David T. Perkins wrote:
[snip]



And responding to Faye's question....
If a well know prefix is used, this does not create any additional
work for vendors. That is, they already have to "create an OID registry"
to support object entPhysicalVendorType. And for management platforms
that want to use CLEI codes, a standard prefix (and encoding rules)
allows them to "extract" a CLEI code from the value of
entPhysicalVendorType, and all other management platforms to be
blissfully unaware of CLEI codes. 

On Sun, 7 Sep 2003, Faye Ly wrote:
> Just playing the devil's advocate!  On the other hand, CLEI code is a
> fixed string and although it is more elegant to maintain an OID registry
> per vendor but this might grow for a NMS that manages multiple vendors.
> A fixed string as an augmented table to the physical entity table is
> more straightforward to support.
>
> -faye
>
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: Sunday, September 07, 2003 12:59 AM
> To: entmib@ietf.org; Kaj Tesink; Giamboi, Anthony; Lam, Hing-Kam (Kam);
> Faye Ly; Juergen Schoenwaelder; Margaret Wasserman; David T. Perkins;
> Wijnen, Bert (Bert); atommib@research.telcordia.com
> Subject: Re: [Entmib] entity mib support for tcif
>
> On Sat, 6 Sep 2003, David T. Perkins wrote:
> > I believe that adding a CLEI code (common langauge equipment
> > identifier code) is completely redundant with the object
> > entPhysicalVendorType and should not be added.
> > A CLEI code is a globally unique value that is purchased
> > from Telcordia. It costs approximately $100 to get the
> > document from Telcordia that defines CLEI codes, and
> > it costs per assigned code.
> >
> > 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.
>
> I think this is a VERY GOOD idea.
>
> In previous off-line discussions entPhysicalModelName was suggested
> as one place where a CLEI code might live.  While there is nothing
> wrong with putting a CLEI code there (especially if it's on a bar
> code on the label), there would be no guarantee that any particular
> manufacturer did this, nor is there a sure-fire way for a management
> application to tell if what's there is actually a CLEI code, if it
> happens to be 10 octets long.  But entPhysicalVendorType contains an
> OID, which is self-describing.  Very elegant.
>
> I wish there were as neat a solution for entPhysicalMfgDate :-(
>
> Mike
>
Regards,
/david t. perkins


At 10:44 AM 9/5/2003 -0700, C. M. Heard wrote:
>>>>> On Fri, 5 Sep 2003, Juergen Schoenwaelder wrote:
JS> On Thu, Sep 04, 2003 at 07:29:23PM -0400, Kaj Tesink wrote:
JS>
JS> > new objects:
JS> >
JS> > entPhysicalCLIECode OBJECT-TYPE
This should say entPhysicalCLEICode
yup, sorry about the typo

JS> > SYNTAX SnmpAdminString (SIZE (0..10))
JS> > MAX-ACCESS read-write
JS> > STATUS current
JS> > DESCRIPTION
JS> > "The CLIE Code for the physical entity. If a CLIE Code
JS> > is unknown or non-existent, the entPhysicalCLIECode will
JS> > be set to a zero-length string instead."
JS> > ::= { entPhysicalEntry xx }
JS> > REFERENCE "TCIF-02-004, Guideline for data elements
JS> > included in the Management Information Base,
JS> > Telecommunications Industry Forum (TCIF), 09/11/2002.
JS> > ANSI T1.213-2001, Coded identification of equipment entities
JS> > of the North American telecommunications system for
JS> > information exchange, ANSI.
JS> > ANSI T1.213a-2001, Supplement to T1.213-2001,
JS> > Coded identification of equipment entities of the North
JS> > American telecommunications system for information exchange,
JS> > to correct the representation of the Basic Code in
JS> > Figure B.1, ANSI."
JS>
JS> Can someone translate that into something I can understand?
JS>
JS> Explaining entPhysicalCLIECode with "The CLIE Code for the physical
JS> entity." is not really helpful for those poor souls who have no clue
JS> what a CLIE code is (and the reference does not look like it is easy
JS> to find the answer somewhere on the web).

Would it help to modify the definition like so:

entPhysicalCLEICode OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..10))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The CLEI (Common Language Equipment Identifier)
Code for the physical entity. If the CLEI Code
is unknown, or if no CLEI code exists, then this
object will contain a zero-length string."
REFERENCE
[ ... as above ... ]
::= { entPhysicalEntry xx }
yup

and perhaps to have something in the narrative section of the
defining document (whatever it turns out to be) that more completely
defines the nature and usage of a CLEI code?
>>>>> On Thu, 4 Sep 2003, Margaret Wasserman wrote:
MW> I am trying to understand your request...
I think I can answer some of these questions. Kaj, please step in
and correct me if I get anything wrong.
MW> Why has the TCIF defined objects that must occur in a MIB,
MW> without a defining a MIB that includes them?
The TCIF documents are requirements documents: they mandate what
information must be present but don't mandate a specific method for
getting it there. If the information isn't provided by a standard
MIB module then a proprietary MIB module can be used to satisfy the
requirement. This is a common approach in the telecom industry.
right on

MW> Why do you think that it would make sense to add these objects
MW> to the Entity MIB? Are you expecting each sub-component in a
MW> system to have separate CLIE codes and manufacturing information?
MW> Or would there be one set for the entire box?
There is a separate CLEI code and manufacturing date for each Field
Replaceble Unit or FRU. A line card ("circuit pack" in
telecom-speak) would be an example of an FRU.


right. CLEIs are not necessarily box-related.
this is one reason why the entity mib seems a reasonable
place to put this info.

MW> Why do you think that it would be better to include these
MW> objects in the Entity MIB than it would be to publish a
MW> separate MIB module that includes these objects?
I think there is some distaste for artifically fragmenting MIB
modules into "base" and "supplemental" parts just to get around the
problem that the presence of new objects inhibits advancement on the
standards track. This is especially the case when there would be
only a small number of object (two, in this case) in the
supplemental MIB module. A supplemental MIB module seems like
overkill in that case.

yup, that was the logic

That said, it is certainly feasible to define a supplemental MIB
module with one conceptual table whose row object AUGMENTS
entPhysicalEntry and contains just the two objects
entPhysicalCLEICode and entPhysicalMfgDate. It's even possible to
do this in a proprietary MIB module or in a MIB module sponsored by
a telecom industry consortium, although I think that there would
probably be greater regard for a MIB module that is on the IETF
standards track.

we looked at these alternatives; esp. the CLEI is widely used
now, so enterprise-specific approaches are not the preferred path forward.
as mike points out above, the tcif is not into mib specifications; they look
at organizations like the ietf as the most appropriate place for that.
kaj


Hope that helps,
Mike





=============================================================

=========================================================
entity mib wg,
attached is a discussion on accommodating
some TCIF information elements in an appropriate
MIB module.
the entity mib would be a good candidate, but
we understand that the timing may be problematic
since it's going to draft right now.
we're talking about 6 data elements (see
TCIF-02-004, 09/11/2002). most can probably be mapped to existing
objects, but not all.
so it appears that we have several options:
a) extend the entity mib with the 'missing' objects (see attached strawman)
b) write a 'supplemental' mib module for the 'missing' objects
c) find another suitable mib module
while a) seems most desirable the current state of the entity mib may make
it problematic(?). (b) seems somewhat overkill.
(c) seems suboptimal.
the new objects would only be required for systems that support management
access to this information.
any comments? particulars attached,
pl copy Cc list above,
kaj, tony,
============================================================

TCIF Required MIB objects:
- CLEI Code
Suggested to use: new object
Reference: TCIF-02-004, 09/11/2002
Reference: ANSI T1.213-2001 and T1.213a-2001, T1M1.3
- Unique Serial Identification (USI)
Suggested to use: entPhysicalSerialNum
- Software Version
Suggested to use: entPhysicalSoftwareRev
- Manufacture Date
Suggested to use: new object
TCIF Optional MIB objects:
- Manufacturer Identification
Suggested to use: entPhysicalMfgName
- Manufacturer Product Identification
Suggested to use: entPhysicalModelName
=============================================================
new objects:
entPhysicalCLIECode OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..10))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The CLIE Code for the physical entity. If a CLIE Code
is unknown or non-existent, the entPhysicalCLIECode will
be set to a zero-length string instead."
::= { entPhysicalEntry xx }
REFERENCE "TCIF-02-004, Guideline for data elements
included in the Management Information Base,
Telecommunications Industry Forum (TCIF), 09/11/2002.
ANSI T1.213-2001, Coded identification of equipment entities
of the North American telecommunications system for
information exchange, ANSI.
ANSI T1.213a-2001, Supplement to T1.213-2001,
Coded identification of equipment entities of the North
American telecommunications system for information exchange,
to correct the representation of the Basic Code in
Figure B.1, ANSI."
entPhysicalMfgDate OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The manufacturing date for the physical entity."
::= { entPhysicalEntry xx }








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

Kaj Tesink
Telcordia Technologies. Inc.
331 Newman Springs Road
Red Bank, NJ 07701
Email: kaj@research.telcordia.com
Tel: (732) 758-5254
Fax: (732) 758-4177

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
--=====================_32504879==_.ALT-- _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Oct 1 18:24:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05827 for ; Wed, 1 Oct 2003 17:35:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ocg-0005e9-36; Wed, 01 Oct 2003 17:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ocP-0005dZ-U9 for entmib@optimus.ietf.org; Wed, 01 Oct 2003 17:34:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05795 for ; Wed, 1 Oct 2003 17:34:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ocJ-0005op-00 for entmib@ietf.org; Wed, 01 Oct 2003 17:34:39 -0400 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ocC-0005o4-00 for entmib@ietf.org; Wed, 01 Oct 2003 17:34:33 -0400 Received: from shannon.research.telcordia.com (shannon-83.research.telcordia.com [128.96.83.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id h91LXres026277 for ; Wed, 1 Oct 2003 17:33:53 -0400 (EDT) Received: from kaj-100.research.telcordia.com (kaj-100.cc.telcordia.com [128.96.71.110]) by shannon.research.telcordia.com (8.9.3/8.9.3) with ESMTP id RAA24583 for ; Wed, 1 Oct 2003 17:33:53 -0400 (EDT) Message-Id: <4.3.2.7.2.20031001171034.01610dd8@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Oct 2003 17:33:47 -0400 To: entmib@ietf.org From: Kaj Tesink Subject: RE: [Entmib] entity mib support for tcif In-Reply-To: References: <93401232EABAAB4EA430E13ECC701CCF2A0D3E@yorktown.pedestalnetworks.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_32504879==_.ALT" X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , --=====================_32504879==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed folks, i consulted with some interested parties directly. my impression is that we could do the following: 1) to support the Manufacture Date we'll need a new object entPhysicalMfgDate that augments the entPhysicalTable 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. 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. any preferences out there? kaj At 03:29 PM 9/7/2003 -0700, David T. Perkins wrote: [snip] >And responding to Faye's question.... >If a well know prefix is used, this does not create any additional >work for vendors. That is, they already have to "create an OID registry" >to support object entPhysicalVendorType. And for management platforms >that want to use CLEI codes, a standard prefix (and encoding rules) >allows them to "extract" a CLEI code from the value of >entPhysicalVendorType, and all other management platforms to be >blissfully unaware of CLEI codes. > >On Sun, 7 Sep 2003, Faye Ly wrote: > > Just playing the devil's advocate! On the other hand, CLEI code is a > > fixed string and although it is more elegant to maintain an OID registry > > per vendor but this might grow for a NMS that manages multiple vendors. > > A fixed string as an augmented table to the physical entity table is > > more straightforward to support. > > > > -faye > > > > -----Original Message----- > > From: C. M. Heard [mailto:heard@pobox.com] > > Sent: Sunday, September 07, 2003 12:59 AM > > To: entmib@ietf.org; Kaj Tesink; Giamboi, Anthony; Lam, Hing-Kam (Kam); > > Faye Ly; Juergen Schoenwaelder; Margaret Wasserman; David T. Perkins; > > Wijnen, Bert (Bert); atommib@research.telcordia.com > > Subject: Re: [Entmib] entity mib support for tcif > > > > On Sat, 6 Sep 2003, David T. Perkins wrote: > > > I believe that adding a CLEI code (common langauge equipment > > > identifier code) is completely redundant with the object > > > entPhysicalVendorType and should not be added. > > > A CLEI code is a globally unique value that is purchased > > > from Telcordia. It costs approximately $100 to get the > > > document from Telcordia that defines CLEI codes, and > > > it costs per assigned code. > > > > > > 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. > > > > I think this is a VERY GOOD idea. > > > > In previous off-line discussions entPhysicalModelName was suggested > > as one place where a CLEI code might live. While there is nothing > > wrong with putting a CLEI code there (especially if it's on a bar > > code on the label), there would be no guarantee that any particular > > manufacturer did this, nor is there a sure-fire way for a management > > application to tell if what's there is actually a CLEI code, if it > > happens to be 10 octets long. But entPhysicalVendorType contains an > > OID, which is self-describing. Very elegant. > > > > I wish there were as neat a solution for entPhysicalMfgDate :-( > > > > Mike > > >Regards, >/david t. perkins At 10:44 AM 9/5/2003 -0700, C. M. Heard wrote: >>>>> On Fri, 5 Sep 2003, Juergen Schoenwaelder wrote: JS> On Thu, Sep 04, 2003 at 07:29:23PM -0400, Kaj Tesink wrote: JS> JS> > new objects: JS> > JS> > entPhysicalCLIECode OBJECT-TYPE This should say entPhysicalCLEICode yup, sorry about the typo JS> > SYNTAX SnmpAdminString (SIZE (0..10)) JS> > MAX-ACCESS read-write JS> > STATUS current JS> > DESCRIPTION JS> > "The CLIE Code for the physical entity. If a CLIE Code JS> > is unknown or non-existent, the entPhysicalCLIECode will JS> > be set to a zero-length string instead." JS> > ::= { entPhysicalEntry xx } JS> > REFERENCE "TCIF-02-004, Guideline for data elements JS> > included in the Management Information Base, JS> > Telecommunications Industry Forum (TCIF), 09/11/2002. JS> > ANSI T1.213-2001, Coded identification of equipment entities JS> > of the North American telecommunications system for JS> > information exchange, ANSI. JS> > ANSI T1.213a-2001, Supplement to T1.213-2001, JS> > Coded identification of equipment entities of the North JS> > American telecommunications system for information exchange, JS> > to correct the representation of the Basic Code in JS> > Figure B.1, ANSI." JS> JS> Can someone translate that into something I can understand? JS> JS> Explaining entPhysicalCLIECode with "The CLIE Code for the physical JS> entity." is not really helpful for those poor souls who have no clue JS> what a CLIE code is (and the reference does not look like it is easy JS> to find the answer somewhere on the web). Would it help to modify the definition like so: entPhysicalCLEICode OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..10)) MAX-ACCESS read-write STATUS current DESCRIPTION "The CLEI (Common Language Equipment Identifier) Code for the physical entity. If the CLEI Code is unknown, or if no CLEI code exists, then this object will contain a zero-length string." REFERENCE [ ... as above ... ] ::= { entPhysicalEntry xx } yup and perhaps to have something in the narrative section of the defining document (whatever it turns out to be) that more completely defines the nature and usage of a CLEI code? >>>>> On Thu, 4 Sep 2003, Margaret Wasserman wrote: MW> I am trying to understand your request... I think I can answer some of these questions. Kaj, please step in and correct me if I get anything wrong. MW> Why has the TCIF defined objects that must occur in a MIB, MW> without a defining a MIB that includes them? The TCIF documents are requirements documents: they mandate what information must be present but don't mandate a specific method for getting it there. If the information isn't provided by a standard MIB module then a proprietary MIB module can be used to satisfy the requirement. This is a common approach in the telecom industry. right on MW> Why do you think that it would make sense to add these objects MW> to the Entity MIB? Are you expecting each sub-component in a MW> system to have separate CLIE codes and manufacturing information? MW> Or would there be one set for the entire box? There is a separate CLEI code and manufacturing date for each Field Replaceble Unit or FRU. A line card ("circuit pack" in telecom-speak) would be an example of an FRU. right. CLEIs are not necessarily box-related. this is one reason why the entity mib seems a reasonable place to put this info. MW> Why do you think that it would be better to include these MW> objects in the Entity MIB than it would be to publish a MW> separate MIB module that includes these objects? I think there is some distaste for artifically fragmenting MIB modules into "base" and "supplemental" parts just to get around the problem that the presence of new objects inhibits advancement on the standards track. This is especially the case when there would be only a small number of object (two, in this case) in the supplemental MIB module. A supplemental MIB module seems like overkill in that case. yup, that was the logic That said, it is certainly feasible to define a supplemental MIB module with one conceptual table whose row object AUGMENTS entPhysicalEntry and contains just the two objects entPhysicalCLEICode and entPhysicalMfgDate. It's even possible to do this in a proprietary MIB module or in a MIB module sponsored by a telecom industry consortium, although I think that there would probably be greater regard for a MIB module that is on the IETF standards track. we looked at these alternatives; esp. the CLEI is widely used now, so enterprise-specific approaches are not the preferred path forward. as mike points out above, the tcif is not into mib specifications; they look at organizations like the ietf as the most appropriate place for that. kaj Hope that helps, Mike ============================================================= ========================================================= entity mib wg, attached is a discussion on accommodating some TCIF information elements in an appropriate MIB module. the entity mib would be a good candidate, but we understand that the timing may be problematic since it's going to draft right now. we're talking about 6 data elements (see TCIF-02-004, 09/11/2002). most can probably be mapped to existing objects, but not all. so it appears that we have several options: a) extend the entity mib with the 'missing' objects (see attached strawman) b) write a 'supplemental' mib module for the 'missing' objects c) find another suitable mib module while a) seems most desirable the current state of the entity mib may make it problematic(?). (b) seems somewhat overkill. (c) seems suboptimal. the new objects would only be required for systems that support management access to this information. any comments? particulars attached, pl copy Cc list above, kaj, tony, ============================================================ TCIF Required MIB objects: - CLEI Code Suggested to use: new object Reference: TCIF-02-004, 09/11/2002 Reference: ANSI T1.213-2001 and T1.213a-2001, T1M1.3 - Unique Serial Identification (USI) Suggested to use: entPhysicalSerialNum - Software Version Suggested to use: entPhysicalSoftwareRev - Manufacture Date Suggested to use: new object TCIF Optional MIB objects: - Manufacturer Identification Suggested to use: entPhysicalMfgName - Manufacturer Product Identification Suggested to use: entPhysicalModelName ============================================================= new objects: entPhysicalCLIECode OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..10)) MAX-ACCESS read-write STATUS current DESCRIPTION "The CLIE Code for the physical entity. If a CLIE Code is unknown or non-existent, the entPhysicalCLIECode will be set to a zero-length string instead." ::= { entPhysicalEntry xx } REFERENCE "TCIF-02-004, Guideline for data elements included in the Management Information Base, Telecommunications Industry Forum (TCIF), 09/11/2002. ANSI T1.213-2001, Coded identification of equipment entities of the North American telecommunications system for information exchange, ANSI. ANSI T1.213a-2001, Supplement to T1.213-2001, Coded identification of equipment entities of the North American telecommunications system for information exchange, to correct the representation of the Basic Code in Figure B.1, ANSI." entPhysicalMfgDate OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The manufacturing date for the physical entity." ::= { entPhysicalEntry xx } _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Kaj Tesink Telcordia Technologies. Inc. 331 Newman Springs Road Red Bank, NJ 07701 Email: kaj@research.telcordia.com Tel: (732) 758-5254 Fax: (732) 758-4177 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ --=====================_32504879==_.ALT Content-Type: text/html; charset="us-ascii" folks, i consulted with some interested parties directly.
my impression is that we could do the following:

1) to support the Manufacture Date we'll need a new object
   entPhysicalMfgDate that augments the entPhysicalTable

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.

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.

any preferences out there?


kaj




At 03:29 PM 9/7/2003 -0700, David T. Perkins wrote:
[snip]



And responding to Faye's question....
If a well know prefix is used, this does not create any additional
work for vendors. That is, they already have to "create an OID registry"
to support object entPhysicalVendorType. And for management platforms
that want to use CLEI codes, a standard prefix (and encoding rules)
allows them to "extract" a CLEI code from the value of
entPhysicalVendorType, and all other management platforms to be
blissfully unaware of CLEI codes. 

On Sun, 7 Sep 2003, Faye Ly wrote:
> Just playing the devil's advocate!  On the other hand, CLEI code is a
> fixed string and although it is more elegant to maintain an OID registry
> per vendor but this might grow for a NMS that manages multiple vendors.
> A fixed string as an augmented table to the physical entity table is
> more straightforward to support.
>
> -faye
>
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: Sunday, September 07, 2003 12:59 AM
> To: entmib@ietf.org; Kaj Tesink; Giamboi, Anthony; Lam, Hing-Kam (Kam);
> Faye Ly; Juergen Schoenwaelder; Margaret Wasserman; David T. Perkins;
> Wijnen, Bert (Bert); atommib@research.telcordia.com
> Subject: Re: [Entmib] entity mib support for tcif
>
> On Sat, 6 Sep 2003, David T. Perkins wrote:
> > I believe that adding a CLEI code (common langauge equipment
> > identifier code) is completely redundant with the object
> > entPhysicalVendorType and should not be added.
> > A CLEI code is a globally unique value that is purchased
> > from Telcordia. It costs approximately $100 to get the
> > document from Telcordia that defines CLEI codes, and
> > it costs per assigned code.
> >
> > 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.
>
> I think this is a VERY GOOD idea.
>
> In previous off-line discussions entPhysicalModelName was suggested
> as one place where a CLEI code might live.  While there is nothing
> wrong with putting a CLEI code there (especially if it's on a bar
> code on the label), there would be no guarantee that any particular
> manufacturer did this, nor is there a sure-fire way for a management
> application to tell if what's there is actually a CLEI code, if it
> happens to be 10 octets long.  But entPhysicalVendorType contains an
> OID, which is self-describing.  Very elegant.
>
> I wish there were as neat a solution for entPhysicalMfgDate :-(
>
> Mike
>
Regards,
/david t. perkins


At 10:44 AM 9/5/2003 -0700, C. M. Heard wrote:
>>>>> On Fri, 5 Sep 2003, Juergen Schoenwaelder wrote:
JS> On Thu, Sep 04, 2003 at 07:29:23PM -0400, Kaj Tesink wrote:
JS>
JS> > new objects:
JS> >
JS> > entPhysicalCLIECode OBJECT-TYPE
This should say entPhysicalCLEICode
yup, sorry about the typo

JS> > SYNTAX SnmpAdminString (SIZE (0..10))
JS> > MAX-ACCESS read-write
JS> > STATUS current
JS> > DESCRIPTION
JS> > "The CLIE Code for the physical entity. If a CLIE Code
JS> > is unknown or non-existent, the entPhysicalCLIECode will
JS> > be set to a zero-length string instead."
JS> > ::= { entPhysicalEntry xx }
JS> > REFERENCE "TCIF-02-004, Guideline for data elements
JS> > included in the Management Information Base,
JS> > Telecommunications Industry Forum (TCIF), 09/11/2002.
JS> > ANSI T1.213-2001, Coded identification of equipment entities
JS> > of the North American telecommunications system for
JS> > information exchange, ANSI.
JS> > ANSI T1.213a-2001, Supplement to T1.213-2001,
JS> > Coded identification of equipment entities of the North
JS> > American telecommunications system for information exchange,
JS> > to correct the representation of the Basic Code in
JS> > Figure B.1, ANSI."
JS>
JS> Can someone translate that into something I can understand?
JS>
JS> Explaining entPhysicalCLIECode with "The CLIE Code for the physical
JS> entity." is not really helpful for those poor souls who have no clue
JS> what a CLIE code is (and the reference does not look like it is easy
JS> to find the answer somewhere on the web).

Would it help to modify the definition like so:

entPhysicalCLEICode OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..10))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The CLEI (Common Language Equipment Identifier)
Code for the physical entity. If the CLEI Code
is unknown, or if no CLEI code exists, then this
object will contain a zero-length string."
REFERENCE
[ ... as above ... ]
::= { entPhysicalEntry xx }
yup

and perhaps to have something in the narrative section of the
defining document (whatever it turns out to be) that more completely
defines the nature and usage of a CLEI code?
>>>>> On Thu, 4 Sep 2003, Margaret Wasserman wrote:
MW> I am trying to understand your request...
I think I can answer some of these questions. Kaj, please step in
and correct me if I get anything wrong.
MW> Why has the TCIF defined objects that must occur in a MIB,
MW> without a defining a MIB that includes them?
The TCIF documents are requirements documents: they mandate what
information must be present but don't mandate a specific method for
getting it there. If the information isn't provided by a standard
MIB module then a proprietary MIB module can be used to satisfy the
requirement. This is a common approach in the telecom industry.
right on

MW> Why do you think that it would make sense to add these objects
MW> to the Entity MIB? Are you expecting each sub-component in a
MW> system to have separate CLIE codes and manufacturing information?
MW> Or would there be one set for the entire box?
There is a separate CLEI code and manufacturing date for each Field
Replaceble Unit or FRU. A line card ("circuit pack" in
telecom-speak) would be an example of an FRU.


right. CLEIs are not necessarily box-related.
this is one reason why the entity mib seems a reasonable
place to put this info.

MW> Why do you think that it would be better to include these
MW> objects in the Entity MIB than it would be to publish a
MW> separate MIB module that includes these objects?
I think there is some distaste for artifically fragmenting MIB
modules into "base" and "supplemental" parts just to get around the
problem that the presence of new objects inhibits advancement on the
standards track. This is especially the case when there would be
only a small number of object (two, in this case) in the
supplemental MIB module. A supplemental MIB module seems like
overkill in that case.

yup, that was the logic

That said, it is certainly feasible to define a supplemental MIB
module with one conceptual table whose row object AUGMENTS
entPhysicalEntry and contains just the two objects
entPhysicalCLEICode and entPhysicalMfgDate. It's even possible to
do this in a proprietary MIB module or in a MIB module sponsored by
a telecom industry consortium, although I think that there would
probably be greater regard for a MIB module that is on the IETF
standards track.

we looked at these alternatives; esp. the CLEI is widely used
now, so enterprise-specific approaches are not the preferred path forward.
as mike points out above, the tcif is not into mib specifications; they look
at organizations like the ietf as the most appropriate place for that.
kaj


Hope that helps,
Mike





=============================================================

=========================================================
entity mib wg,
attached is a discussion on accommodating
some TCIF information elements in an appropriate
MIB module.
the entity mib would be a good candidate, but
we understand that the timing may be problematic
since it's going to draft right now.
we're talking about 6 data elements (see
TCIF-02-004, 09/11/2002). most can probably be mapped to existing
objects, but not all.
so it appears that we have several options:
a) extend the entity mib with the 'missing' objects (see attached strawman)
b) write a 'supplemental' mib module for the 'missing' objects
c) find another suitable mib module
while a) seems most desirable the current state of the entity mib may make
it problematic(?). (b) seems somewhat overkill.
(c) seems suboptimal.
the new objects would only be required for systems that support management
access to this information.
any comments? particulars attached,
pl copy Cc list above,
kaj, tony,
============================================================

TCIF Required MIB objects:
- CLEI Code
Suggested to use: new object
Reference: TCIF-02-004, 09/11/2002
Reference: ANSI T1.213-2001 and T1.213a-2001, T1M1.3
- Unique Serial Identification (USI)
Suggested to use: entPhysicalSerialNum
- Software Version
Suggested to use: entPhysicalSoftwareRev
- Manufacture Date
Suggested to use: new object
TCIF Optional MIB objects:
- Manufacturer Identification
Suggested to use: entPhysicalMfgName
- Manufacturer Product Identification
Suggested to use: entPhysicalModelName
=============================================================
new objects:
entPhysicalCLIECode OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..10))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The CLIE Code for the physical entity. If a CLIE Code
is unknown or non-existent, the entPhysicalCLIECode will
be set to a zero-length string instead."
::= { entPhysicalEntry xx }
REFERENCE "TCIF-02-004, Guideline for data elements
included in the Management Information Base,
Telecommunications Industry Forum (TCIF), 09/11/2002.
ANSI T1.213-2001, Coded identification of equipment entities
of the North American telecommunications system for
information exchange, ANSI.
ANSI T1.213a-2001, Supplement to T1.213-2001,
Coded identification of equipment entities of the North
American telecommunications system for information exchange,
to correct the representation of the Basic Code in
Figure B.1, ANSI."
entPhysicalMfgDate OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The manufacturing date for the physical entity."
::= { entPhysicalEntry xx }








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

Kaj Tesink
Telcordia Technologies. Inc.
331 Newman Springs Road
Red Bank, NJ 07701
Email: kaj@research.telcordia.com
Tel: (732) 758-5254
Fax: (732) 758-4177

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
--=====================_32504879==_.ALT-- _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Thu Oct 2 04:06:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07008 for ; Thu, 2 Oct 2003 04:06:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yTK-0006DY-9p; Thu, 02 Oct 2003 04:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ySR-0006Co-AJ for entmib@optimus.ietf.org; Thu, 02 Oct 2003 04:05:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06995 for ; Thu, 2 Oct 2003 04:04:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ySO-0004Tx-00 for entmib@ietf.org; Thu, 02 Oct 2003 04:05:04 -0400 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1A4ySN-0004Td-00 for entmib@ietf.org; Thu, 02 Oct 2003 04:05:04 -0400 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id D4A02568E8; Thu, 2 Oct 2003 10:04:33 +0200 (CEST) Received: from james (unknown [212.201.46.151]) by merkur.iu-bremen.de (Postfix) with ESMTP id 30D9156893; Thu, 2 Oct 2003 10:04:33 +0200 (CEST) Received: by james (Postfix, from userid 1000) id 4876281D0; Thu, 2 Oct 2003 10:04:32 +0200 (CEST) Date: Thu, 2 Oct 2003 10:04:32 +0200 From: Juergen Schoenwaelder To: Kaj Tesink Cc: entmib@ietf.org Subject: Re: [Entmib] entity mib support for tcif Message-ID: <20031002080432.GB717@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Kaj Tesink , entmib@ietf.org References: <93401232EABAAB4EA430E13ECC701CCF2A0D3E@yorktown.pedestalnetworks.com> <4.3.2.7.2.20031001171034.01610dd8@128.96.81.11> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20031001171034.01610dd8@128.96.81.11> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , 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 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu Oct 2 04:06:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07023 for ; Thu, 2 Oct 2003 04:06:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yTM-0006Dx-F3 for entmib-archive@odin.ietf.org; Thu, 02 Oct 2003 04:06:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92864oV023911 for entmib-archive@odin.ietf.org; Thu, 2 Oct 2003 04:06:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yTK-0006DY-9p; Thu, 02 Oct 2003 04:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ySR-0006Co-AJ for entmib@optimus.ietf.org; Thu, 02 Oct 2003 04:05:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06995 for ; Thu, 2 Oct 2003 04:04:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ySO-0004Tx-00 for entmib@ietf.org; Thu, 02 Oct 2003 04:05:04 -0400 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1A4ySN-0004Td-00 for entmib@ietf.org; Thu, 02 Oct 2003 04:05:04 -0400 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id D4A02568E8; Thu, 2 Oct 2003 10:04:33 +0200 (CEST) Received: from james (unknown [212.201.46.151]) by merkur.iu-bremen.de (Postfix) with ESMTP id 30D9156893; Thu, 2 Oct 2003 10:04:33 +0200 (CEST) Received: by james (Postfix, from userid 1000) id 4876281D0; Thu, 2 Oct 2003 10:04:32 +0200 (CEST) Date: Thu, 2 Oct 2003 10:04:32 +0200 From: Juergen Schoenwaelder To: Kaj Tesink Cc: entmib@ietf.org Subject: Re: [Entmib] entity mib support for tcif Message-ID: <20031002080432.GB717@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Kaj Tesink , entmib@ietf.org References: <93401232EABAAB4EA430E13ECC701CCF2A0D3E@yorktown.pedestalnetworks.com> <4.3.2.7.2.20031001171034.01610dd8@128.96.81.11> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20031001171034.01610dd8@128.96.81.11> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , 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 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Thu Oct 2 04:43:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07950 for ; Thu, 2 Oct 2003 04:43:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4z38-000851-78; Thu, 02 Oct 2003 04:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4z2l-00080y-Eh for entmib@optimus.ietf.org; Thu, 02 Oct 2003 04:42:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07922 for ; Thu, 2 Oct 2003 04:42:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4z2h-0004pr-00 for entmib@ietf.org; Thu, 02 Oct 2003 04:42:35 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A4z2g-0004pY-00 for entmib@ietf.org; Thu, 02 Oct 2003 04:42:34 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h928g0Y19904 for ; Thu, 2 Oct 2003 03:42:00 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 2 Oct 2003 10:41:59 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC3D5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'j.schoenwaelder@iu-bremen.de'" , Kaj Tesink Cc: entmib@ietf.org Subject: RE: [Entmib] entity mib support for tcif Date: Thu, 2 Oct 2003 10:41:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , > > 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 Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu Oct 2 04:43:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07952 for ; Thu, 2 Oct 2003 04:43:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4z3A-00085Q-FD for entmib-archive@odin.ietf.org; Thu, 02 Oct 2003 04:43:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h928h3Q1031079 for entmib-archive@odin.ietf.org; Thu, 2 Oct 2003 04:43:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4z38-000851-78; Thu, 02 Oct 2003 04:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4z2l-00080y-Eh for entmib@optimus.ietf.org; Thu, 02 Oct 2003 04:42:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07922 for ; Thu, 2 Oct 2003 04:42:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4z2h-0004pr-00 for entmib@ietf.org; Thu, 02 Oct 2003 04:42:35 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A4z2g-0004pY-00 for entmib@ietf.org; Thu, 02 Oct 2003 04:42:34 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h928g0Y19904 for ; Thu, 2 Oct 2003 03:42:00 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 2 Oct 2003 10:41:59 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC3D5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'j.schoenwaelder@iu-bremen.de'" , Kaj Tesink Cc: entmib@ietf.org Subject: RE: [Entmib] entity mib support for tcif Date: Thu, 2 Oct 2003 10:41:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , > > 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 Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Thu Oct 2 10:01:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19714 for ; Thu, 2 Oct 2003 10:01:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A540r-0000Tl-2f; Thu, 02 Oct 2003 10:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5402-0000Rg-NH for entmib@optimus.ietf.org; Thu, 02 Oct 2003 10:00:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19630 for ; Thu, 2 Oct 2003 10:00:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5400-0000w9-00 for entmib@ietf.org; Thu, 02 Oct 2003 10:00:08 -0400 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx with esmtp (Exim 4.12) id 1A53zz-0000vO-00 for entmib@ietf.org; Thu, 02 Oct 2003 10:00:07 -0400 Received: from shannon.research.telcordia.com (shannon [128.96.81.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id h92DxTes027174 for ; Thu, 2 Oct 2003 09:59:29 -0400 (EDT) Received: from kaj-100.research.telcordia.com (kaj-100.cc.telcordia.com [128.96.71.110]) by shannon.research.telcordia.com (8.9.3/8.9.3) with ESMTP id JAA20371 for ; Thu, 2 Oct 2003 09:59:29 -0400 (EDT) Message-Id: <4.3.2.7.2.20031002095136.02202e70@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Oct 2003 09:59:23 -0400 To: entmib@ietf.org From: Kaj Tesink Subject: RE: [Entmib] entity mib support for tcif In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155028EC3D5@nl0006exch001u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , 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: kaj@research.telcordia.com Tel: (732) 758-5254 Fax: (732) 758-4177 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu Oct 2 10:01:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19744 for ; Thu, 2 Oct 2003 10:01:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A540r-0000UU-PX for entmib-archive@odin.ietf.org; Thu, 02 Oct 2003 10:01:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92E11NG001869 for entmib-archive@odin.ietf.org; Thu, 2 Oct 2003 10:01:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A540r-0000Tl-2f; Thu, 02 Oct 2003 10:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5402-0000Rg-NH for entmib@optimus.ietf.org; Thu, 02 Oct 2003 10:00:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19630 for ; Thu, 2 Oct 2003 10:00:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5400-0000w9-00 for entmib@ietf.org; Thu, 02 Oct 2003 10:00:08 -0400 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx with esmtp (Exim 4.12) id 1A53zz-0000vO-00 for entmib@ietf.org; Thu, 02 Oct 2003 10:00:07 -0400 Received: from shannon.research.telcordia.com (shannon [128.96.81.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id h92DxTes027174 for ; Thu, 2 Oct 2003 09:59:29 -0400 (EDT) Received: from kaj-100.research.telcordia.com (kaj-100.cc.telcordia.com [128.96.71.110]) by shannon.research.telcordia.com (8.9.3/8.9.3) with ESMTP id JAA20371 for ; Thu, 2 Oct 2003 09:59:29 -0400 (EDT) Message-Id: <4.3.2.7.2.20031002095136.02202e70@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Oct 2003 09:59:23 -0400 To: entmib@ietf.org From: Kaj Tesink Subject: RE: [Entmib] entity mib support for tcif In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155028EC3D5@nl0006exch001u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , 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: kaj@research.telcordia.com Tel: (732) 758-5254 Fax: (732) 758-4177 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Thu Oct 2 10:50:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23073 for ; Thu, 2 Oct 2003 10:50:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54mH-0003UT-Aq; Thu, 02 Oct 2003 10:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54lJ-0003Lb-Oz for entmib@optimus.ietf.org; Thu, 02 Oct 2003 10:49:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22781 for ; Thu, 2 Oct 2003 10:48:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54lG-0001SQ-00 for entmib@ietf.org; Thu, 02 Oct 2003 10:48:59 -0400 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1A54lG-0001Rx-00 for entmib@ietf.org; Thu, 02 Oct 2003 10:48:58 -0400 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 53AA9569EC; Thu, 2 Oct 2003 16:48:24 +0200 (CEST) Received: from james (unknown [212.201.46.151]) by merkur.iu-bremen.de (Postfix) with ESMTP id 463B456108; Thu, 2 Oct 2003 16:48:22 +0200 (CEST) Received: by james (Postfix, from userid 1000) id A9FEA81CF; Thu, 2 Oct 2003 16:48:19 +0200 (CEST) Date: Thu, 2 Oct 2003 16:48:19 +0200 From: Juergen Schoenwaelder To: Kaj Tesink Cc: entmib@ietf.org Subject: Re: [Entmib] entity mib support for tcif Message-ID: <20031002144819.GA1013@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Kaj Tesink , entmib@ietf.org References: <7D5D48D2CAA3D84C813F5B154F43B155028EC3D5@nl0006exch001u.nl.lucent.com> <4.3.2.7.2.20031002095136.02202e70@128.96.81.11> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20031002095136.02202e70@128.96.81.11> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , On Thu, Oct 02, 2003 at 09:59:23AM -0400, Kaj Tesink wrote: > > >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: 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 P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu Oct 2 10:50:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23085 for ; Thu, 2 Oct 2003 10:50:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54mI-0003V0-7R for entmib-archive@odin.ietf.org; Thu, 02 Oct 2003 10:50:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Eo1OV013429 for entmib-archive@odin.ietf.org; Thu, 2 Oct 2003 10:50:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54mH-0003UT-Aq; Thu, 02 Oct 2003 10:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54lJ-0003Lb-Oz for entmib@optimus.ietf.org; Thu, 02 Oct 2003 10:49:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22781 for ; Thu, 2 Oct 2003 10:48:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54lG-0001SQ-00 for entmib@ietf.org; Thu, 02 Oct 2003 10:48:59 -0400 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1A54lG-0001Rx-00 for entmib@ietf.org; Thu, 02 Oct 2003 10:48:58 -0400 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 53AA9569EC; Thu, 2 Oct 2003 16:48:24 +0200 (CEST) Received: from james (unknown [212.201.46.151]) by merkur.iu-bremen.de (Postfix) with ESMTP id 463B456108; Thu, 2 Oct 2003 16:48:22 +0200 (CEST) Received: by james (Postfix, from userid 1000) id A9FEA81CF; Thu, 2 Oct 2003 16:48:19 +0200 (CEST) Date: Thu, 2 Oct 2003 16:48:19 +0200 From: Juergen Schoenwaelder To: Kaj Tesink Cc: entmib@ietf.org Subject: Re: [Entmib] entity mib support for tcif Message-ID: <20031002144819.GA1013@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Kaj Tesink , entmib@ietf.org References: <7D5D48D2CAA3D84C813F5B154F43B155028EC3D5@nl0006exch001u.nl.lucent.com> <4.3.2.7.2.20031002095136.02202e70@128.96.81.11> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20031002095136.02202e70@128.96.81.11> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , On Thu, Oct 02, 2003 at 09:59:23AM -0400, Kaj Tesink wrote: > > >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: 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 P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Thu Oct 2 11:20:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25867 for ; Thu, 2 Oct 2003 11:20:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55FJ-0005mZ-K7; Thu, 02 Oct 2003 11:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55Er-0005lK-6h for entmib@optimus.ietf.org; Thu, 02 Oct 2003 11:19:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25734 for ; Thu, 2 Oct 2003 11:19:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A55Eq-00024U-00 for entmib@ietf.org; Thu, 02 Oct 2003 11:19:32 -0400 Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx with esmtp (Exim 4.12) id 1A55Eo-00024R-00 for entmib@ietf.org; Thu, 02 Oct 2003 11:19:31 -0400 Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by smtpout1.bayarea.net (8.12.8/8.12.8) with ESMTP id h92FPgYV028901; Thu, 2 Oct 2003 08:25:42 -0700 Received: from dperkins-nb2.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h92FJPL05809; Thu, 2 Oct 2003 08:19:25 -0700 Message-Id: <5.2.0.9.2.20031002075620.02e59c60@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 02 Oct 2003 08:19:12 -0700 To: j.schoenwaelder@iu-bremen.de, Kaj Tesink From: "David T. Perkins" Subject: Re: [Entmib] entity mib support for tcif Cc: entmib@ietf.org In-Reply-To: <20031002080432.GB717@iu-bremen.de> References: <4.3.2.7.2.20031001171034.01610dd8@128.96.81.11> <93401232EABAAB4EA430E13ECC701CCF2A0D3E@yorktown.pedestalnetworks.com> <4.3.2.7.2.20031001171034.01610dd8@128.96.81.11> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , 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 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu Oct 2 11:20:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25883 for ; Thu, 2 Oct 2003 11:20:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55FL-0005mq-14 for entmib-archive@odin.ietf.org; Thu, 02 Oct 2003 11:20:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92FK2Pu022240 for entmib-archive@odin.ietf.org; Thu, 2 Oct 2003 11:20:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55FJ-0005mZ-K7; Thu, 02 Oct 2003 11:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55Er-0005lK-6h for entmib@optimus.ietf.org; Thu, 02 Oct 2003 11:19:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25734 for ; Thu, 2 Oct 2003 11:19:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A55Eq-00024U-00 for entmib@ietf.org; Thu, 02 Oct 2003 11:19:32 -0400 Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx with esmtp (Exim 4.12) id 1A55Eo-00024R-00 for entmib@ietf.org; Thu, 02 Oct 2003 11:19:31 -0400 Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by smtpout1.bayarea.net (8.12.8/8.12.8) with ESMTP id h92FPgYV028901; Thu, 2 Oct 2003 08:25:42 -0700 Received: from dperkins-nb2.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h92FJPL05809; Thu, 2 Oct 2003 08:19:25 -0700 Message-Id: <5.2.0.9.2.20031002075620.02e59c60@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 02 Oct 2003 08:19:12 -0700 To: j.schoenwaelder@iu-bremen.de, Kaj Tesink From: "David T. Perkins" Subject: Re: [Entmib] entity mib support for tcif Cc: entmib@ietf.org In-Reply-To: <20031002080432.GB717@iu-bremen.de> References: <4.3.2.7.2.20031001171034.01610dd8@128.96.81.11> <93401232EABAAB4EA430E13ECC701CCF2A0D3E@yorktown.pedestalnetworks.com> <4.3.2.7.2.20031001171034.01610dd8@128.96.81.11> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , 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 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu Oct 2 13:26:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14699 for ; Thu, 2 Oct 2003 13:26:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57DF-0005Gx-VB for entmib-archive@odin.ietf.org; Thu, 02 Oct 2003 13:26:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92HQ1w6020253 for entmib-archive@odin.ietf.org; Thu, 2 Oct 2003 13:26:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57DF-0005GV-LZ; Thu, 02 Oct 2003 13:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57Cg-0005Ft-Px for entmib@optimus.ietf.org; Thu, 02 Oct 2003 13:25:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14643 for ; Thu, 2 Oct 2003 13:25:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A57Ce-0003n0-00 for entmib@ietf.org; Thu, 02 Oct 2003 13:25:24 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A57Cc-0003ml-00 for entmib@ietf.org; Thu, 02 Oct 2003 13:25:23 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h92HOeJs024776; Thu, 2 Oct 2003 10:24:40 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn3-351.cisco.com [10.21.65.95]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMT27244; Thu, 2 Oct 2003 10:24:39 -0700 (PDT) Message-Id: <4.3.2.7.2.20031002101643.027ea170@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Oct 2003 10:20:12 -0700 To: Kaj Tesink From: Andy Bierman Subject: RE: [Entmib] entity mib support for tcif Cc: entmib@ietf.org In-Reply-To: <4.3.2.7.2.20031001171034.01610dd8@128.96.81.11> References: <93401232EABAAB4EA430E13ECC701CCF2A0D3E@yorktown.pedestalnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , At 02:33 PM 10/1/2003, Kaj Tesink wrote: >folks, i consulted with some interested parties directly. >my impression is that we could do the following: > >1) to support the Manufacture Date we'll need a new object > entPhysicalMfgDate that augments the entPhysicalTable > >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. > >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 I prefer (3b). There are lots of MIB modules that import something from ENTITY-MIB (usually entPhysicalIndex) and none of these RFCs can advance to DS until the Entity MIB advances. I think it will take a long time to get the supplemental objects published, and then it will take at least a year to get another implementation report together. >all options work for me although on reflection >i have a slight pref for 2a) over 2b) based on distaste of object proliferation. > >any preferences out there? > > >kaj Andy >At 03:29 PM 9/7/2003 -0700, David T. Perkins wrote: >[snip] > > > >>And responding to Faye's question.... >>If a well know prefix is used, this does not create any additional >>work for vendors. That is, they already have to "create an OID registry" >>to support object entPhysicalVendorType. And for management platforms >>that want to use CLEI codes, a standard prefix (and encoding rules) >>allows them to "extract" a CLEI code from the value of >>entPhysicalVendorType, and all other management platforms to be >>blissfully unaware of CLEI codes. >> >>On Sun, 7 Sep 2003, Faye Ly wrote: >>> Just playing the devil's advocate! On the other hand, CLEI code is a >>> fixed string and although it is more elegant to maintain an OID registry >>> per vendor but this might grow for a NMS that manages multiple vendors. >>> A fixed string as an augmented table to the physical entity table is >>> more straightforward to support. >>> >>> -faye >>> >>> -----Original Message----- >>> From: C. M. Heard [mailto:heard@pobox.com] >>> Sent: Sunday, September 07, 2003 12:59 AM >>> To: entmib@ietf.org; Kaj Tesink; Giamboi, Anthony; Lam, Hing-Kam (Kam); >>> Faye Ly; Juergen Schoenwaelder; Margaret Wasserman; David T. Perkins; >>> Wijnen, Bert (Bert); atommib@research.telcordia.com >>> Subject: Re: [Entmib] entity mib support for tcif >>> >>> On Sat, 6 Sep 2003, David T. Perkins wrote: >>> > I believe that adding a CLEI code (common langauge equipment >>> > identifier code) is completely redundant with the object >>> > entPhysicalVendorType and should not be added. >>> > A CLEI code is a globally unique value that is purchased >>> > from Telcordia. It costs approximately $100 to get the >>> > document from Telcordia that defines CLEI codes, and >>> > it costs per assigned code. >>> > >>> > 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. >>> >>> I think this is a VERY GOOD idea. >>> >>> In previous off-line discussions entPhysicalModelName was suggested >>> as one place where a CLEI code might live. While there is nothing >>> wrong with putting a CLEI code there (especially if it's on a bar >>> code on the label), there would be no guarantee that any particular >>> manufacturer did this, nor is there a sure-fire way for a management >>> application to tell if what's there is actually a CLEI code, if it >>> happens to be 10 octets long. But entPhysicalVendorType contains an >>> OID, which is self-describing. Very elegant. >>> >>> I wish there were as neat a solution for entPhysicalMfgDate :-( >>> >>> Mike >>> >>Regards, >>/david t. perkins > > >At 10:44 AM 9/5/2003 -0700, C. M. Heard wrote: >>>>>> On Fri, 5 Sep 2003, Juergen Schoenwaelder wrote: >JS> On Thu, Sep 04, 2003 at 07:29:23PM -0400, Kaj Tesink wrote: >JS> >JS> > new objects: >JS> > >JS> > entPhysicalCLIECode OBJECT-TYPE >This should say entPhysicalCLEICode >yup, sorry about the typo > >JS> > SYNTAX SnmpAdminString (SIZE (0..10)) >JS> > MAX-ACCESS read-write >JS> > STATUS current >JS> > DESCRIPTION >JS> > "The CLIE Code for the physical entity. If a CLIE Code >JS> > is unknown or non-existent, the entPhysicalCLIECode will >JS> > be set to a zero-length string instead." >JS> > ::= { entPhysicalEntry xx } >JS> > REFERENCE "TCIF-02-004, Guideline for data elements >JS> > included in the Management Information Base, >JS> > Telecommunications Industry Forum (TCIF), 09/11/2002. >JS> > ANSI T1.213-2001, Coded identification of equipment entities >JS> > of the North American telecommunications system for >JS> > information exchange, ANSI. >JS> > ANSI T1.213a-2001, Supplement to T1.213-2001, >JS> > Coded identification of equipment entities of the North >JS> > American telecommunications system for information exchange, >JS> > to correct the representation of the Basic Code in >JS> > Figure B.1, ANSI." >JS> >JS> Can someone translate that into something I can understand? >JS> >JS> Explaining entPhysicalCLIECode with "The CLIE Code for the physical >JS> entity." is not really helpful for those poor souls who have no clue >JS> what a CLIE code is (and the reference does not look like it is easy >JS> to find the answer somewhere on the web). > >Would it help to modify the definition like so: > >entPhysicalCLEICode OBJECT-TYPE >SYNTAX SnmpAdminString (SIZE (0..10)) >MAX-ACCESS read-write >STATUS current >DESCRIPTION >"The CLEI (Common Language Equipment Identifier) >Code for the physical entity. If the CLEI Code >is unknown, or if no CLEI code exists, then this >object will contain a zero-length string." >REFERENCE >[ ... as above ... ] >::= { entPhysicalEntry xx } >yup > >and perhaps to have something in the narrative section of the >defining document (whatever it turns out to be) that more completely >defines the nature and usage of a CLEI code? >>>>>> On Thu, 4 Sep 2003, Margaret Wasserman wrote: >MW> I am trying to understand your request... >I think I can answer some of these questions. Kaj, please step in >and correct me if I get anything wrong. >MW> Why has the TCIF defined objects that must occur in a MIB, >MW> without a defining a MIB that includes them? >The TCIF documents are requirements documents: they mandate what >information must be present but don't mandate a specific method for >getting it there. If the information isn't provided by a standard >MIB module then a proprietary MIB module can be used to satisfy the >requirement. This is a common approach in the telecom industry. >right on > >MW> Why do you think that it would make sense to add these objects >MW> to the Entity MIB? Are you expecting each sub-component in a >MW> system to have separate CLIE codes and manufacturing information? >MW> Or would there be one set for the entire box? >There is a separate CLEI code and manufacturing date for each Field >Replaceble Unit or FRU. A line card ("circuit pack" in >telecom-speak) would be an example of an FRU. > > >right. CLEIs are not necessarily box-related. >this is one reason why the entity mib seems a reasonable >place to put this info. > >MW> Why do you think that it would be better to include these >MW> objects in the Entity MIB than it would be to publish a >MW> separate MIB module that includes these objects? >I think there is some distaste for artifically fragmenting MIB >modules into "base" and "supplemental" parts just to get around the >problem that the presence of new objects inhibits advancement on the >standards track. This is especially the case when there would be >only a small number of object (two, in this case) in the >supplemental MIB module. A supplemental MIB module seems like >overkill in that case. > >yup, that was the logic > >That said, it is certainly feasible to define a supplemental MIB >module with one conceptual table whose row object AUGMENTS >entPhysicalEntry and contains just the two objects >entPhysicalCLEICode and entPhysicalMfgDate. It's even possible to >do this in a proprietary MIB module or in a MIB module sponsored by >a telecom industry consortium, although I think that there would >probably be greater regard for a MIB module that is on the IETF >standards track. > >we looked at these alternatives; esp. the CLEI is widely used >now, so enterprise-specific approaches are not the preferred path forward. >as mike points out above, the tcif is not into mib specifications; they look >at organizations like the ietf as the most appropriate place for that. >kaj > > >Hope that helps, >Mike > > > > > >============================================================= > >========================================================= >entity mib wg, >attached is a discussion on accommodating >some TCIF information elements in an appropriate >MIB module. >the entity mib would be a good candidate, but >we understand that the timing may be problematic >since it's going to draft right now. >we're talking about 6 data elements (see >TCIF-02-004, 09/11/2002). most can probably be mapped to existing >objects, but not all. >so it appears that we have several options: >a) extend the entity mib with the 'missing' objects (see attached strawman) >b) write a 'supplemental' mib module for the 'missing' objects >c) find another suitable mib module >while a) seems most desirable the current state of the entity mib may make >it problematic(?). (b) seems somewhat overkill. >(c) seems suboptimal. >the new objects would only be required for systems that support management >access to this information. >any comments? particulars attached, >pl copy Cc list above, >kaj, tony, >============================================================ > >TCIF Required MIB objects: >- CLEI Code >Suggested to use: new object >Reference: TCIF-02-004, 09/11/2002 >Reference: ANSI T1.213-2001 and T1.213a-2001, T1M1.3 >- Unique Serial Identification (USI) >Suggested to use: entPhysicalSerialNum >- Software Version >Suggested to use: entPhysicalSoftwareRev >- Manufacture Date >Suggested to use: new object >TCIF Optional MIB objects: >- Manufacturer Identification >Suggested to use: entPhysicalMfgName >- Manufacturer Product Identification >Suggested to use: entPhysicalModelName >============================================================= >new objects: >entPhysicalCLIECode OBJECT-TYPE >SYNTAX SnmpAdminString (SIZE (0..10)) >MAX-ACCESS read-write >STATUS current >DESCRIPTION >"The CLIE Code for the physical entity. If a CLIE Code >is unknown or non-existent, the entPhysicalCLIECode will >be set to a zero-length string instead." >::= { entPhysicalEntry xx } >REFERENCE "TCIF-02-004, Guideline for data elements >included in the Management Information Base, >Telecommunications Industry Forum (TCIF), 09/11/2002. >ANSI T1.213-2001, Coded identification of equipment entities >of the North American telecommunications system for >information exchange, ANSI. >ANSI T1.213a-2001, Supplement to T1.213-2001, >Coded identification of equipment entities of the North >American telecommunications system for information exchange, >to correct the representation of the Basic Code in >Figure B.1, ANSI." >entPhysicalMfgDate OBJECT-TYPE >SYNTAX DateAndTime >MAX-ACCESS read-only >STATUS current >DESCRIPTION >"The manufacturing date for the physical entity." >::= { entPhysicalEntry xx } > > > > > > > > >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > >Kaj Tesink >Telcordia Technologies. Inc. >331 Newman Springs Road >Red Bank, NJ 07701 >Email: kaj@research.telcordia.com >Tel: (732) 758-5254 >Fax: (732) 758-4177 > >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Thu Oct 2 14:14:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14697 for ; Thu, 2 Oct 2003 13:26:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57DF-0005GV-LZ; Thu, 02 Oct 2003 13:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57Cg-0005Ft-Px for entmib@optimus.ietf.org; Thu, 02 Oct 2003 13:25:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14643 for ; Thu, 2 Oct 2003 13:25:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A57Ce-0003n0-00 for entmib@ietf.org; Thu, 02 Oct 2003 13:25:24 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A57Cc-0003ml-00 for entmib@ietf.org; Thu, 02 Oct 2003 13:25:23 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h92HOeJs024776; Thu, 2 Oct 2003 10:24:40 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn3-351.cisco.com [10.21.65.95]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMT27244; Thu, 2 Oct 2003 10:24:39 -0700 (PDT) Message-Id: <4.3.2.7.2.20031002101643.027ea170@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Oct 2003 10:20:12 -0700 To: Kaj Tesink From: Andy Bierman Subject: RE: [Entmib] entity mib support for tcif Cc: entmib@ietf.org In-Reply-To: <4.3.2.7.2.20031001171034.01610dd8@128.96.81.11> References: <93401232EABAAB4EA430E13ECC701CCF2A0D3E@yorktown.pedestalnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , At 02:33 PM 10/1/2003, Kaj Tesink wrote: >folks, i consulted with some interested parties directly. >my impression is that we could do the following: > >1) to support the Manufacture Date we'll need a new object > entPhysicalMfgDate that augments the entPhysicalTable > >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. > >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 I prefer (3b). There are lots of MIB modules that import something from ENTITY-MIB (usually entPhysicalIndex) and none of these RFCs can advance to DS until the Entity MIB advances. I think it will take a long time to get the supplemental objects published, and then it will take at least a year to get another implementation report together. >all options work for me although on reflection >i have a slight pref for 2a) over 2b) based on distaste of object proliferation. > >any preferences out there? > > >kaj Andy >At 03:29 PM 9/7/2003 -0700, David T. Perkins wrote: >[snip] > > > >>And responding to Faye's question.... >>If a well know prefix is used, this does not create any additional >>work for vendors. That is, they already have to "create an OID registry" >>to support object entPhysicalVendorType. And for management platforms >>that want to use CLEI codes, a standard prefix (and encoding rules) >>allows them to "extract" a CLEI code from the value of >>entPhysicalVendorType, and all other management platforms to be >>blissfully unaware of CLEI codes. >> >>On Sun, 7 Sep 2003, Faye Ly wrote: >>> Just playing the devil's advocate! On the other hand, CLEI code is a >>> fixed string and although it is more elegant to maintain an OID registry >>> per vendor but this might grow for a NMS that manages multiple vendors. >>> A fixed string as an augmented table to the physical entity table is >>> more straightforward to support. >>> >>> -faye >>> >>> -----Original Message----- >>> From: C. M. Heard [mailto:heard@pobox.com] >>> Sent: Sunday, September 07, 2003 12:59 AM >>> To: entmib@ietf.org; Kaj Tesink; Giamboi, Anthony; Lam, Hing-Kam (Kam); >>> Faye Ly; Juergen Schoenwaelder; Margaret Wasserman; David T. Perkins; >>> Wijnen, Bert (Bert); atommib@research.telcordia.com >>> Subject: Re: [Entmib] entity mib support for tcif >>> >>> On Sat, 6 Sep 2003, David T. Perkins wrote: >>> > I believe that adding a CLEI code (common langauge equipment >>> > identifier code) is completely redundant with the object >>> > entPhysicalVendorType and should not be added. >>> > A CLEI code is a globally unique value that is purchased >>> > from Telcordia. It costs approximately $100 to get the >>> > document from Telcordia that defines CLEI codes, and >>> > it costs per assigned code. >>> > >>> > 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. >>> >>> I think this is a VERY GOOD idea. >>> >>> In previous off-line discussions entPhysicalModelName was suggested >>> as one place where a CLEI code might live. While there is nothing >>> wrong with putting a CLEI code there (especially if it's on a bar >>> code on the label), there would be no guarantee that any particular >>> manufacturer did this, nor is there a sure-fire way for a management >>> application to tell if what's there is actually a CLEI code, if it >>> happens to be 10 octets long. But entPhysicalVendorType contains an >>> OID, which is self-describing. Very elegant. >>> >>> I wish there were as neat a solution for entPhysicalMfgDate :-( >>> >>> Mike >>> >>Regards, >>/david t. perkins > > >At 10:44 AM 9/5/2003 -0700, C. M. Heard wrote: >>>>>> On Fri, 5 Sep 2003, Juergen Schoenwaelder wrote: >JS> On Thu, Sep 04, 2003 at 07:29:23PM -0400, Kaj Tesink wrote: >JS> >JS> > new objects: >JS> > >JS> > entPhysicalCLIECode OBJECT-TYPE >This should say entPhysicalCLEICode >yup, sorry about the typo > >JS> > SYNTAX SnmpAdminString (SIZE (0..10)) >JS> > MAX-ACCESS read-write >JS> > STATUS current >JS> > DESCRIPTION >JS> > "The CLIE Code for the physical entity. If a CLIE Code >JS> > is unknown or non-existent, the entPhysicalCLIECode will >JS> > be set to a zero-length string instead." >JS> > ::= { entPhysicalEntry xx } >JS> > REFERENCE "TCIF-02-004, Guideline for data elements >JS> > included in the Management Information Base, >JS> > Telecommunications Industry Forum (TCIF), 09/11/2002. >JS> > ANSI T1.213-2001, Coded identification of equipment entities >JS> > of the North American telecommunications system for >JS> > information exchange, ANSI. >JS> > ANSI T1.213a-2001, Supplement to T1.213-2001, >JS> > Coded identification of equipment entities of the North >JS> > American telecommunications system for information exchange, >JS> > to correct the representation of the Basic Code in >JS> > Figure B.1, ANSI." >JS> >JS> Can someone translate that into something I can understand? >JS> >JS> Explaining entPhysicalCLIECode with "The CLIE Code for the physical >JS> entity." is not really helpful for those poor souls who have no clue >JS> what a CLIE code is (and the reference does not look like it is easy >JS> to find the answer somewhere on the web). > >Would it help to modify the definition like so: > >entPhysicalCLEICode OBJECT-TYPE >SYNTAX SnmpAdminString (SIZE (0..10)) >MAX-ACCESS read-write >STATUS current >DESCRIPTION >"The CLEI (Common Language Equipment Identifier) >Code for the physical entity. If the CLEI Code >is unknown, or if no CLEI code exists, then this >object will contain a zero-length string." >REFERENCE >[ ... as above ... ] >::= { entPhysicalEntry xx } >yup > >and perhaps to have something in the narrative section of the >defining document (whatever it turns out to be) that more completely >defines the nature and usage of a CLEI code? >>>>>> On Thu, 4 Sep 2003, Margaret Wasserman wrote: >MW> I am trying to understand your request... >I think I can answer some of these questions. Kaj, please step in >and correct me if I get anything wrong. >MW> Why has the TCIF defined objects that must occur in a MIB, >MW> without a defining a MIB that includes them? >The TCIF documents are requirements documents: they mandate what >information must be present but don't mandate a specific method for >getting it there. If the information isn't provided by a standard >MIB module then a proprietary MIB module can be used to satisfy the >requirement. This is a common approach in the telecom industry. >right on > >MW> Why do you think that it would make sense to add these objects >MW> to the Entity MIB? Are you expecting each sub-component in a >MW> system to have separate CLIE codes and manufacturing information? >MW> Or would there be one set for the entire box? >There is a separate CLEI code and manufacturing date for each Field >Replaceble Unit or FRU. A line card ("circuit pack" in >telecom-speak) would be an example of an FRU. > > >right. CLEIs are not necessarily box-related. >this is one reason why the entity mib seems a reasonable >place to put this info. > >MW> Why do you think that it would be better to include these >MW> objects in the Entity MIB than it would be to publish a >MW> separate MIB module that includes these objects? >I think there is some distaste for artifically fragmenting MIB >modules into "base" and "supplemental" parts just to get around the >problem that the presence of new objects inhibits advancement on the >standards track. This is especially the case when there would be >only a small number of object (two, in this case) in the >supplemental MIB module. A supplemental MIB module seems like >overkill in that case. > >yup, that was the logic > >That said, it is certainly feasible to define a supplemental MIB >module with one conceptual table whose row object AUGMENTS >entPhysicalEntry and contains just the two objects >entPhysicalCLEICode and entPhysicalMfgDate. It's even possible to >do this in a proprietary MIB module or in a MIB module sponsored by >a telecom industry consortium, although I think that there would >probably be greater regard for a MIB module that is on the IETF >standards track. > >we looked at these alternatives; esp. the CLEI is widely used >now, so enterprise-specific approaches are not the preferred path forward. >as mike points out above, the tcif is not into mib specifications; they look >at organizations like the ietf as the most appropriate place for that. >kaj > > >Hope that helps, >Mike > > > > > >============================================================= > >========================================================= >entity mib wg, >attached is a discussion on accommodating >some TCIF information elements in an appropriate >MIB module. >the entity mib would be a good candidate, but >we understand that the timing may be problematic >since it's going to draft right now. >we're talking about 6 data elements (see >TCIF-02-004, 09/11/2002). most can probably be mapped to existing >objects, but not all. >so it appears that we have several options: >a) extend the entity mib with the 'missing' objects (see attached strawman) >b) write a 'supplemental' mib module for the 'missing' objects >c) find another suitable mib module >while a) seems most desirable the current state of the entity mib may make >it problematic(?). (b) seems somewhat overkill. >(c) seems suboptimal. >the new objects would only be required for systems that support management >access to this information. >any comments? particulars attached, >pl copy Cc list above, >kaj, tony, >============================================================ > >TCIF Required MIB objects: >- CLEI Code >Suggested to use: new object >Reference: TCIF-02-004, 09/11/2002 >Reference: ANSI T1.213-2001 and T1.213a-2001, T1M1.3 >- Unique Serial Identification (USI) >Suggested to use: entPhysicalSerialNum >- Software Version >Suggested to use: entPhysicalSoftwareRev >- Manufacture Date >Suggested to use: new object >TCIF Optional MIB objects: >- Manufacturer Identification >Suggested to use: entPhysicalMfgName >- Manufacturer Product Identification >Suggested to use: entPhysicalModelName >============================================================= >new objects: >entPhysicalCLIECode OBJECT-TYPE >SYNTAX SnmpAdminString (SIZE (0..10)) >MAX-ACCESS read-write >STATUS current >DESCRIPTION >"The CLIE Code for the physical entity. If a CLIE Code >is unknown or non-existent, the entPhysicalCLIECode will >be set to a zero-length string instead." >::= { entPhysicalEntry xx } >REFERENCE "TCIF-02-004, Guideline for data elements >included in the Management Information Base, >Telecommunications Industry Forum (TCIF), 09/11/2002. >ANSI T1.213-2001, Coded identification of equipment entities >of the North American telecommunications system for >information exchange, ANSI. >ANSI T1.213a-2001, Supplement to T1.213-2001, >Coded identification of equipment entities of the North >American telecommunications system for information exchange, >to correct the representation of the Basic Code in >Figure B.1, ANSI." >entPhysicalMfgDate OBJECT-TYPE >SYNTAX DateAndTime >MAX-ACCESS read-only >STATUS current >DESCRIPTION >"The manufacturing date for the physical entity." >::= { entPhysicalEntry xx } > > > > > > > > >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > >Kaj Tesink >Telcordia Technologies. Inc. >331 Newman Springs Road >Red Bank, NJ 07701 >Email: kaj@research.telcordia.com >Tel: (732) 758-5254 >Fax: (732) 758-4177 > >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Sun Oct 5 09:17:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15058 for ; Sun, 5 Oct 2003 09:17:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A68kv-000159-0f; Sun, 05 Oct 2003 09:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A68kO-00014p-Bt for entmib@optimus.ietf.org; Sun, 05 Oct 2003 09:16:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15043 for ; Sun, 5 Oct 2003 09:16:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A68kM-0001sr-00 for entmib@ietf.org; Sun, 05 Oct 2003 09:16:26 -0400 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1A68kM-0001sT-00 for entmib@ietf.org; Sun, 05 Oct 2003 09:16:26 -0400 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 28A6856B42; Sun, 5 Oct 2003 15:15:54 +0200 (CEST) Received: from james (unknown [212.201.46.151]) by merkur.iu-bremen.de (Postfix) with ESMTP id 0149D56B36; Sun, 5 Oct 2003 15:15:51 +0200 (CEST) Received: by james (Postfix, from userid 1000) id 1319E81D0; Sun, 5 Oct 2003 15:15:51 +0200 (CEST) Date: Sun, 5 Oct 2003 15:15:51 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: Kaj Tesink , entmib@ietf.org Subject: Re: [Entmib] entity mib support for tcif Message-ID: <20031005131551.GC870@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , Kaj Tesink , entmib@ietf.org References: <93401232EABAAB4EA430E13ECC701CCF2A0D3E@yorktown.pedestalnetworks.com> <4.3.2.7.2.20031002101643.027ea170@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20031002101643.027ea170@fedex.cisco.com> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , On Thu, Oct 02, 2003 at 10:20:12AM -0700, Andy Bierman wrote: > > I prefer (3b). There are lots of MIB modules that > import something from ENTITY-MIB (usually entPhysicalIndex) > and none of these RFCs can advance to DS until the > Entity MIB advances. I think it will take a long > time to get the supplemental objects published, > and then it will take at least a year to get another > implementation report together. Which module do you have in mind? $ cd /usr/local/share/mibs/ietf $ grep ENTITY-MIB * ENTITY-MIB:ENTITY-MIB DEFINITIONS ::= BEGIN ENTITY-SENSOR-MIB: FROM ENTITY-MIB ENTITY-SENSOR-MIB: MODULE ENTITY-MIB PTOPO-MIB: FROM ENTITY-MIB Am I missing something? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Sun Oct 5 09:17:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15080 for ; Sun, 5 Oct 2003 09:17:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A68kw-00015c-AD for entmib-archive@odin.ietf.org; Sun, 05 Oct 2003 09:17:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h95DH2pX004174 for entmib-archive@odin.ietf.org; Sun, 5 Oct 2003 09:17:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A68kv-000159-0f; Sun, 05 Oct 2003 09:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A68kO-00014p-Bt for entmib@optimus.ietf.org; Sun, 05 Oct 2003 09:16:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15043 for ; Sun, 5 Oct 2003 09:16:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A68kM-0001sr-00 for entmib@ietf.org; Sun, 05 Oct 2003 09:16:26 -0400 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1A68kM-0001sT-00 for entmib@ietf.org; Sun, 05 Oct 2003 09:16:26 -0400 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 28A6856B42; Sun, 5 Oct 2003 15:15:54 +0200 (CEST) Received: from james (unknown [212.201.46.151]) by merkur.iu-bremen.de (Postfix) with ESMTP id 0149D56B36; Sun, 5 Oct 2003 15:15:51 +0200 (CEST) Received: by james (Postfix, from userid 1000) id 1319E81D0; Sun, 5 Oct 2003 15:15:51 +0200 (CEST) Date: Sun, 5 Oct 2003 15:15:51 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: Kaj Tesink , entmib@ietf.org Subject: Re: [Entmib] entity mib support for tcif Message-ID: <20031005131551.GC870@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , Kaj Tesink , entmib@ietf.org References: <93401232EABAAB4EA430E13ECC701CCF2A0D3E@yorktown.pedestalnetworks.com> <4.3.2.7.2.20031002101643.027ea170@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20031002101643.027ea170@fedex.cisco.com> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , On Thu, Oct 02, 2003 at 10:20:12AM -0700, Andy Bierman wrote: > > I prefer (3b). There are lots of MIB modules that > import something from ENTITY-MIB (usually entPhysicalIndex) > and none of these RFCs can advance to DS until the > Entity MIB advances. I think it will take a long > time to get the supplemental objects published, > and then it will take at least a year to get another > implementation report together. Which module do you have in mind? $ cd /usr/local/share/mibs/ietf $ grep ENTITY-MIB * ENTITY-MIB:ENTITY-MIB DEFINITIONS ::= BEGIN ENTITY-SENSOR-MIB: FROM ENTITY-MIB ENTITY-SENSOR-MIB: MODULE ENTITY-MIB PTOPO-MIB: FROM ENTITY-MIB Am I missing something? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Oct 8 15:08:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03628 for ; Wed, 8 Oct 2003 15:08:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JfF-0002zJ-8S; Wed, 08 Oct 2003 15:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6g6t-0001rV-4j for entmib@optimus.ietf.org; Mon, 06 Oct 2003 20:53:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00233 for ; Mon, 6 Oct 2003 20:53:45 -0400 (EDT) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6g6q-0006Q3-00 for entmib@ietf.org; Mon, 06 Oct 2003 20:53:52 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A6g6q-0006Q0-00 for entmib@ietf.org; Mon, 06 Oct 2003 20:53:52 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h970rq602411 for ; Tue, 7 Oct 2003 03:53:52 +0300 (EET DST) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 7 Oct 2003 03:53:51 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 6 Oct 2003 17:53:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Oct 2003 20:53:49 -0400 Message-ID: Thread-Topic: Meeting in Minneapolis? Thread-Index: AcOMbXgo8zBpM6CNSn+ZHBW4qwhg2Q== To: X-OriginalArrivalTime: 07 Oct 2003 00:53:50.0894 (UTC) FILETIME=[792ECCE0:01C38C6D] Content-Transfer-Encoding: quoted-printable Subject: [Entmib] Meeting in Minneapolis? Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I think that we should meet in Minneapolis to discuss the following=20 topics: - TCIF Proposal -- Do we want to take on this new work? - Entity State MIB -- Status/Open Issues - Entity MIB -- Status of move to DS Is there anything else that we need to talk about? If not, I think that this would probably fit in one hour. What do=20 other folks think? Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Oct 8 15:08:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03642 for ; Wed, 8 Oct 2003 15:08:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JfG-00030A-Ez for entmib-archive@odin.ietf.org; Wed, 08 Oct 2003 15:08:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98J82pP011513 for entmib-archive@odin.ietf.org; Wed, 8 Oct 2003 15:08:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JfF-0002zJ-8S; Wed, 08 Oct 2003 15:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6g6t-0001rV-4j for entmib@optimus.ietf.org; Mon, 06 Oct 2003 20:53:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00233 for ; Mon, 6 Oct 2003 20:53:45 -0400 (EDT) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6g6q-0006Q3-00 for entmib@ietf.org; Mon, 06 Oct 2003 20:53:52 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A6g6q-0006Q0-00 for entmib@ietf.org; Mon, 06 Oct 2003 20:53:52 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h970rq602411 for ; Tue, 7 Oct 2003 03:53:52 +0300 (EET DST) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 7 Oct 2003 03:53:51 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 6 Oct 2003 17:53:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Oct 2003 20:53:49 -0400 Message-ID: Thread-Topic: Meeting in Minneapolis? Thread-Index: AcOMbXgo8zBpM6CNSn+ZHBW4qwhg2Q== To: X-OriginalArrivalTime: 07 Oct 2003 00:53:50.0894 (UTC) FILETIME=[792ECCE0:01C38C6D] Content-Transfer-Encoding: quoted-printable Subject: [Entmib] Meeting in Minneapolis? Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I think that we should meet in Minneapolis to discuss the following=20 topics: - TCIF Proposal -- Do we want to take on this new work? - Entity State MIB -- Status/Open Issues - Entity MIB -- Status of move to DS Is there anything else that we need to talk about? If not, I think that this would probably fit in one hour. What do=20 other folks think? Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib