Re: #322 - Textual Convention Names (Prefix)
"David T. Perkins" <[email protected]> Mon, 29 Mar 2004 09:01:57 -0800
| Newsgroups | gmane.ietf.entmib |
|---|---|
| Message-ID | <[email protected]> |
HI, 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: >hi > ><co-editor> >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? ></co-editor> > ><Sharon> >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> > >Sharon Chisholm >Portfolio Integration >Nortel Networks >Ottawa, Canada Regards, /david t. perkins