Re: #355: OSI State to Something New Spectrum

Hi -

I think Sharon has stated my position more accurately.

I think that what the ITU-T model actually requires has at times
been overestimated here, and that some of the divergence
unnecessarily complicates things.

However, if folks feel the added complications are needed for
SNMP-based management, I'm willing to go along with it,
especially since I don't need to implement it.  :-)

Randy

> From: "Sharon Chisholm" <[email protected]>
> To: <[email protected]>
> Sent: Sunday, May 02, 2004 2:01 AM
> Subject: RE: [Entmib] #355: OSI State to Something New Spectrum
>

> hi
>
> Actually, the issue was more/also whether there was consensus to change the
> current MIB a lot to diverge from the ITU-T model. We've diverged from it as
> has made sense to the working group, but there were a few requests for
> changes such as object renaming which in my personal view didn't make sense
> to do since they seemed non-value add changes. My take on consensus to
> diverge further is that we are somewhat split on the issue.
>
> Sharon
>
> -----Original Message-----
> From: Margaret Wasserman [mailto:[email protected]]
> Sent: Saturday, May 01, 2004 11:28 AM
> To: Randy Presuhn; [email protected]
> Subject: Re: [Entmib] #355: OSI State to Something New Spectrum
>
>
>
> 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
>
>
> _______________________________________________
> Entmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/entmib
>
> _______________________________________________
> Entmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/entmib