Re: #355: OSI State to Something New Spectrum
Margaret Wasserman <[email protected]> Sat, 1 May 2004 11:27:31 -0400
| Newsgroups | gmane.ietf.entmib |
|---|---|
| Message-ID | <p06020433bcb971d07bd8@[10.0.0.64]> |
Hi Randy, I did not see strong support for making changes to the Entity State MIB to bring it more in line with the ITU model, so I do not think that we have consensus to make these changes. Unless you disagree with my assessment, Sharon should mark this issue as closed. Margaret At 12:30 PM -0800 3/25/04, Randy Presuhn wrote: >Hi - > >> From: "David T. Perkins" <[email protected]> >> To: "Randy Presuhn" <[email protected]>; <[email protected]> >> Sent: Thursday, March 25, 2004 12:04 PM >> Subject: Re: [Entmib] #355: OSI State to Something New Spectrum >... >> Randy - it gets back to a fundamental question, which is >> "Is the ITU model and the specification for it worthwhile?" >> In the 10+ years that I have asked this question, I have NEVER >> gotten an answer. NEVER! In my own extensive analysis >> (which included creating both state and alarm MIB modules >> that are MUCH closer to the ITU models and specs than the >> documents created in the IETF), it just isn't forth it. >> Now, if someone would volunteer to show me an implementation >> where the benefits surpass the costs, I'll create time to >> learn from them, and change my tune. But pointing me to >> documents and manuals just doesn't cut it. Is this clear? >... > >I think the difference here is in our understanding of "the ITU model". >It sounds like your understand it to mean *all* the stuff in X.731. >However, that's *not* how X.731 was meant to be used. It provides >a core (Administrative/Usage/Operational states) of rather wide >applicability, and a bunch of other knobs and dials that an object >definer can use when appropriate. I'm arguing to keep this thing >simple, i.e., not add anything (even from X.731) unless there is >a clear need for it. > >So, if one were defining an object class using X.731, and only >operational state was meaningful, then objects of that class simply >wouldn't have administrative or usage states. This maps well to >using the TCs in this MIB module. From my perspective, this alone >would be useful. When one has to do this in something >like the entity state table, it is not as nice. The workaround of adding >additional "not applicable" values to the enumerations is ugly, but it's >the kind of ugliness we're accustomed to in the SNMP world. > >Returning to your question: is having operational state worthwhile? >Absolutely, for the objects that need it. Is having administrative state >worthwhile? Same answer. This is how X.731 was designed to be >used. > >Randy > > > >_______________________________________________ >Entmib mailing list >[email protected] >https://www1.ietf.org/mailman/listinfo/entmib