RE: [Entmib] #355: OSI State to Something New Spectrum

["Romascanu, Dan (Dan)" <[e-mail]>]

Makes sense to me. I do not see major flaws in the current document. I do have my personal reservations on the granularity of some of the objects, and my personal opinions on the usefulness of another one or two the way that they are defined. So may have other. However, this work is useful, Sharon did a good job as editor, and this document is IMO at the appropriate level of quality to deserve a try on the standards track.

Regards,

Dan



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On 
> Behalf Of Margaret Wasserman
> Sent: 03 May, 2004 2:36 PM
> To: Sharon Chisholm
> Cc: [e-mail]
> Subject: RE: [Entmib] #355: OSI State to Something New Spectrum
> 
> 
> 
> Sharon corrected my understanding of issue #355 (see below).  But, my 
> conclusion is much the same.
> 
> At this point we have had multiple WG Last Calls on this document 
> and, according to our charter, we are quite overdue to send it to the 
> IESG...  So, I think that it should require consensus of the group to 
> make any major changes to the document at this point.  Do others 
> agree with that position?
> 
> Given that we are split on this particular issue, I do not believe 
> that we have consensus to make these changes so we should not make 
> them.  Does that make sense?
> 
> Margaret
> 
> >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:[e-mail]]
> >Sent: Saturday, May 01, 2004 11:28 AM
> >To: Randy Presuhn; [e-mail]
> >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" <[e-mail]>
> >>>   To: "Randy Presuhn" <[e-mail]>;
> >>>  <[e-mail]>
> >>>   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
> >>[e-mail]
> >>https://www1.ietf.org/mailman/listinfo/entmib
> >
> >
> >_______________________________________________
> >Entmib mailing list
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/entmib
> >
> >_______________________________________________
> >Entmib mailing list
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/entmib
> 
> 
> _______________________________________________
> Entmib mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/entmib
> 

_______________________________________________
Entmib mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/entmib