Re: [Entmib] #322 - Textual Convention Names (Prefix)

"David T. Perkins" <> Mon, 29 March 2004 17:06 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA12522 for <>; Mon, 29 Mar 2004 12:06:29 -0500 (EST)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.20) id 1B80D3-0007CR-Kk; Mon, 29 Mar 2004 12:06:01 -0500
Received: from ([] by with esmtp (Exim 4.20) id 1B80CX-00078Q-RI for; Mon, 29 Mar 2004 12:05:30 -0500
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA12487 for <>; Mon, 29 Mar 2004 12:05:26 -0500 (EST)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 1B80CW-0001jf-00 for; Mon, 29 Mar 2004 12:05:28 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B80BZ-0001bV-00 for; Mon, 29 Mar 2004 12:04:30 -0500
Received: from ([]) by ietf-mx with esmtp (Exim 4.12) id 1B80Ad-0001Tq-00 for; Mon, 29 Mar 2004 12:03:31 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id i2TH3Cb07618; Mon, 29 Mar 2004 09:03:12 -0800
Message-Id: <>
X-Sender: dperkins@
X-Mailer: QUALCOMM Windows Eudora Version
Date: Mon, 29 Mar 2004 09:01:57 -0800
To: Sharon Chisholm <>,
From: "David T. Perkins" <>
Subject: Re: [Entmib] #322 - Textual Convention Names (Prefix)
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: IETF Entity MIB WG <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>


X.731 defines a "generic" state module and defines attributes that
describe that state module. This was done so that "any" appropriate
object class (in SNMP, a table) that supported the state model
could support the attributes defined in X.731. Because there is
such a wide range of resources including both hardware to software,
the model in X.731 is quite general and not all of it is applicable
to each resource type. With OSI's GDMO specification format, it is
suppose to be easy to specify for an object class the specific
support and behavior of generic attributes. (And, the theory is
that it this approach eases writing management applications.)

With SNMP, "reusing" attributes is not done the same way as that
in GDMO. The definition of an SNMP MIB generally follows the approach of 
specifying the core set of attributes, getting operational experience,
and then extending it if needed.

So, addressing your proposal, it is not clear to me that a generic
model and attributes is useful. Perhaps if you could provide several
examples, it might help. Note that there are several ways to accomplish
the goal of application of a generic model, such as
to specify in an informational RFC a "design pattern" that can be
used by future MIB designers tailored for each application. This
is the approach used in most existing MIB modules. (However, the
design pattern is specified in the first usage of it instead
of a separate RFC.)

At 10:27 AM 3/29/2004 -0500, Sharon Chisholm wrote:
>I'm not sure if consensus is fully formed yet, but I wanted to test a view
>that it seems to be leaning  in the direction of creating a separate MIB
>within this ID to house to textual conventions who's prefix we have not yet
>determined? Is that were people are or is more discussion required?
>I think the term 'Entity' is too limiting if we agree we are going for a
>more generic set of TCs. It occurs to be that we use the term 'resource' in
>the Alarm MIB when we introduced the concept of a 'ResourceId' as well as
>within the description clauses of the TCs in this MIB. Would a prefix of
>'ResourceState' work?
>Sharon Chisholm
>Portfolio Integration
>Nortel Networks
>Ottawa, Canada

/david t. perkins 

Entmib mailing list