Re: [Entmib] #355: OSI State to Something New Spectrum
"Randy Presuhn" <randy_presuhn@mindspring.com> Tue, 04 May 2004 18:06 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16437 for <entmib-archive@lists.ietf.org>; Tue, 4 May 2004 14:06:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4B9-0006Xr-85; Tue, 04 May 2004 13:58:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL42H-0001uK-CK for entmib@optimus.ietf.org; Tue, 04 May 2004 13:48:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15543 for <entmib@ietf.org>; Tue, 4 May 2004 13:48:50 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL42F-0000MN-22 for entmib@ietf.org; Tue, 04 May 2004 13:48:51 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL41H-0000GB-00 for entmib@ietf.org; Tue, 04 May 2004 13:47:52 -0400
Received: from cardinal.mail.pas.earthlink.net ([207.217.121.226]) by ietf-mx with esmtp (Exim 4.12) id 1BL40k-0000Aa-00 for entmib@ietf.org; Tue, 04 May 2004 13:47:18 -0400
Received: from h-68-164-155-147.snvacaid.dynamic.covad.net ([68.164.155.147] helo=oemcomputer) by cardinal.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BL40j-0003Bn-00 for entmib@ietf.org; Tue, 04 May 2004 10:47:17 -0700
Message-ID: <005701c43200$6ce5ba00$7f1afea9@oemcomputer>
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: entmib@ietf.org
References: <3549C09B853DD5119B540002A52CDD340B01E2F8@zcard0ka.ca.nortel.com>
Subject: Re: [Entmib] #355: OSI State to Something New Spectrum
Date: Tue, 04 May 2004 10:51:27 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: entmib-admin@ietf.org
Errors-To: entmib-admin@ietf.org
X-BeenThere: entmib@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/entmib>, <mailto:entmib-request@ietf.org?subject=unsubscribe>
List-Id: IETF Entity MIB WG <entmib.ietf.org>
List-Post: <mailto:entmib@ietf.org>
List-Help: <mailto:entmib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/entmib>, <mailto:entmib-request@ietf.org?subject=subscribe>
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" <schishol@nortelnetworks.com> > To: <entmib@ietf.org> > 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:margaret@thingmagic.com] > Sent: Saturday, May 01, 2004 11:28 AM > To: Randy Presuhn; entmib@ietf.org > 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" <dperkins@dsperkins.com> > >> To: "Randy Presuhn" <randy_presuhn@mindspring.com>; > >> <entmib@ietf.org> > >> 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 > >Entmib@ietf.org > >https://www1.ietf.org/mailman/listinfo/entmib > > > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib > > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib
- [Entmib] #355: OSI State to Something New Spectrum Sharon Chisholm
- Re: [Entmib] #355: OSI State to Something New Spe… Randy Presuhn
- Re: [Entmib] #355: OSI State to Something New Spe… David T. Perkins
- Re: [Entmib] #355: OSI State to Something New Spe… Randy Presuhn
- Re: [Entmib] #355: OSI State to Something New Spe… Margaret Wasserman
- RE: [Entmib] #355: OSI State to Something New Spe… Sharon Chisholm
- RE: [Entmib] #355: OSI State to Something New Spe… Margaret Wasserman
- Re: [Entmib] #355: OSI State to Something New Spe… Randy Presuhn
- RE: [Entmib] #355: OSI State to Something New Spe… Romascanu, Dan (Dan)