From mailman-admin@ietf.org Sat May 1 11:29:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25870 for ; Sat, 1 May 2004 11:29:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJuTl-0001bc-76 for entmib-archive@lists.ietf.org; Sat, 01 May 2004 09:24:29 -0400 Date: Sat, 01 May 2004 09:24:29 -0400 Message-ID: <20040501132429.27207.10662.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: entmib-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, entmib-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for entmib-archive@lists.ietf.org: List Password // URL ---- -------- entmib@ietf.org CNIo https://www1.ietf.org/mailman/options/entmib/entmib-archive%40lists.ietf.org From entmib-admin@ietf.org Sat May 1 13:08:11 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02950 for ; Sat, 1 May 2004 13:08:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJxXw-0007MT-Mh; Sat, 01 May 2004 12:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJw9n-00009Z-QC for entmib@optimus.ietf.org; Sat, 01 May 2004 11:11:59 -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 LAA24301 for ; Sat, 1 May 2004 11:11:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJw9m-0000lk-W0 for entmib@ietf.org; Sat, 01 May 2004 11:11:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJw8r-0000YM-00 for entmib@ietf.org; Sat, 01 May 2004 11:11:02 -0400 Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx with esmtp (Exim 4.12) id 1BJw7v-0000L0-00 for entmib@ietf.org; Sat, 01 May 2004 11:10:03 -0400 Received: from [24.61.30.237] (account margaret HELO [10.0.0.64]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 68224; Sat, 01 May 2004 11:09:34 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <4.3.2.7.2.20040414182947.02953c90@128.96.81.11> References: <4.3.2.7.2.20040414182947.02953c90@128.96.81.11> Date: Sat, 1 May 2004 11:09:45 -0400 To: Kaj Tesink , entmib@ietf.org From: Margaret Wasserman Subject: RE: [Entmib] Re: Entity mib support for tcif Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Kaj, I'm sorry that I didn't answer this message sooner. I was on vacation in mid-April, and I'm only catching up now. 3. acceptance as work item since the original proposal i've seen several supporting comments but i leave this to the WG chair and AD to gauge The Entity MIB WG charter does not currently include this work, so we could not accept this document as a work item without a charter update. There are at least two concerns about updating the Entity MIB WG charter to include this item: 1) The WG has not been timely in completing our current work. 2) I was appointed to the IESG last July, and it is not considered a good idea for IESG members to run WGs. I stayed on as entmib WG chair because we were expected to complete our work within a few months (not that things have gone exactly as planned...). If the life of the WG will be extended by new work items, it will be necessary for Bert to identify and appoint a new chair. So, if you want to pursue this work in the IETF, you should talk to Bert Wijnen about the best way to do that. In the meantime, the only chartered work items for the entmib WG are completing the Entity State MIB and getting the Entity MIB promoted to Draft Standard. Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Sat May 1 13:09:32 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03124 for ; Sat, 1 May 2004 13:09:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJxbr-0000pB-0K; Sat, 01 May 2004 12:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJwOk-0004tv-4r for entmib@optimus.ietf.org; Sat, 01 May 2004 11:27:26 -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 LAA25403 for ; Sat, 1 May 2004 11:27:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJwOj-0003Ie-7A for entmib@ietf.org; Sat, 01 May 2004 11:27:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJwN5-0002la-00 for entmib@ietf.org; Sat, 01 May 2004 11:25:45 -0400 Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx with esmtp (Exim 4.12) id 1BJwL9-0002D7-00 for entmib@ietf.org; Sat, 01 May 2004 11:23:43 -0400 Received: from [24.61.30.237] (account margaret HELO [10.0.0.64]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 68227 for entmib@ietf.org; Sat, 01 May 2004 11:23:05 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <3549C09B853DD5119B540002A52CDD340ACD5D06@zcard0ka.ca.nortel.com> References: <3549C09B853DD5119B540002A52CDD340ACD5D06@zcard0ka.ca.nortel.com> Date: Sat, 1 May 2004 11:20:57 -0400 To: entmib@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 Subject: [Entmib] CONSENSUS CALL: #322 - Textual Convention Names (Prefix) 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: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Based on my reading of the mailing list, it seems like we have very rough consensus on two things related to issue #322: (1) The TCs should be placed in a separate MIB module (within the same I-D) to facilitate their re-use in other MIB modules, as appropriate. (2) The TCs are specific-enough to the state of logical and physical entities that it would make sense to use "Entity" (or perhaps "EntityState") as a prefix for these TCs. I know that there were some people that didn't agree with one or both of these positions, but it seems like most people would be willing to accept these two choices. Does anyone disagree that we seem to have rough consensus on these two positions? Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Sat May 1 13:09:52 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03193 for ; Sat, 1 May 2004 13:09:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJxbr-0000pJ-6X; Sat, 01 May 2004 12:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJwOp-0004vU-OT for entmib@optimus.ietf.org; Sat, 01 May 2004 11:27:31 -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 LAA25436 for ; Sat, 1 May 2004 11:27:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJwOo-0003Ji-RF for entmib@ietf.org; Sat, 01 May 2004 11:27:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJwNC-0002mp-00 for entmib@ietf.org; Sat, 01 May 2004 11:25:51 -0400 Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx with esmtp (Exim 4.12) id 1BJwLJ-0002D7-00 for entmib@ietf.org; Sat, 01 May 2004 11:23:53 -0400 Received: from [24.61.30.237] (account margaret HELO [10.0.0.64]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 68228; Sat, 01 May 2004 11:23:05 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <3549C09B853DD5119B540002A52CDD340ACD5D55@zcard0ka.ca.nortel.com> References: <3549C09B853DD5119B540002A52CDD340ACD5D55@zcard0ka.ca.nortel.com> Date: Sat, 1 May 2004 11:23:28 -0400 To: "Sharon Chisholm" , entmib@ietf.org From: Margaret Wasserman Subject: Re: [Entmib] entstate-335: Consensus Check Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , IMO, we would need consensus to add a new notification to the Enitity State MIB at this point, and I did not see consensus to add this notification. Does anyone disagree with the above consensus call? If not, Sharon please do not add the new notification and mark this issue as closed. Thanks, Margaret At 4:24 PM -0400 4/12/04, Sharon Chisholm wrote: >hi > > >There has been a proposal to add a new notification related to the stand by >state. There hasn't really been any opposition based on people feeling it is >a really bad idea or anything, but there has been a couple bits of >opposition against adding it more related to benefit, current stage in MIB >development, lack of proposal, etc. > >Is consensus not to add this new notification(s) at this time? > > >[Note there is a bit more in the 335 thread, but it's not really related] > >Sharon Chisholm >Portfolio Integration >Nortel Networks >Ottawa, Canada > >_______________________________________________ >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 From entmib-admin@ietf.org Sat May 1 13:10:06 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03259 for ; Sat, 1 May 2004 13:10:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJxcn-0001MI-GT; Sat, 01 May 2004 12:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJwQf-0005eD-CJ for entmib@optimus.ietf.org; Sat, 01 May 2004 11:29:25 -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 LAA25846 for ; Sat, 1 May 2004 11:29:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJwQe-0003pK-E8 for entmib@ietf.org; Sat, 01 May 2004 11:29:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJwQ0-0003bm-00 for entmib@ietf.org; Sat, 01 May 2004 11:28:45 -0400 Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx with esmtp (Exim 4.12) id 1BJwOy-0003Kx-00 for entmib@ietf.org; Sat, 01 May 2004 11:27:40 -0400 Received: from [24.61.30.237] (account margaret HELO [10.0.0.64]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 68232; Sat, 01 May 2004 11:27:12 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <005a01c412a8$145a89a0$7f1afea9@oemcomputer> References: <3549C09B853DD5119B540002A52CDD340A9D3071@zcard0ka.ca.nortel.com> <5.2.0.9.2.20040325115604.023269f8@127.0.0.1> <005a01c412a8$145a89a0$7f1afea9@oemcomputer> Date: Sat, 1 May 2004 11:27:31 -0400 To: "Randy Presuhn" , From: Margaret Wasserman Subject: Re: [Entmib] #355: OSI State to Something New Spectrum Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , 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" >> To: "Randy Presuhn" ; >> 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 From entmib-admin@ietf.org Sat May 1 13:10:33 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03342 for ; Sat, 1 May 2004 13:10:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJxdk-0002cG-CC; Sat, 01 May 2004 12:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJwX2-0007XU-Sg for entmib@optimus.ietf.org; Sat, 01 May 2004 11:36:00 -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 LAA26421 for ; Sat, 1 May 2004 11:35:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJwX1-0005FQ-Rb for entmib@ietf.org; Sat, 01 May 2004 11:35:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJwW1-00052C-00 for entmib@ietf.org; Sat, 01 May 2004 11:34:58 -0400 Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx with esmtp (Exim 4.12) id 1BJwV2-0004qL-00 for entmib@ietf.org; Sat, 01 May 2004 11:33:56 -0400 Received: from [24.61.30.237] (account margaret HELO [10.0.0.64]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 68233 for entmib@ietf.org; Sat, 01 May 2004 11:33:28 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: Date: Sat, 1 May 2004 11:32:49 -0400 To: entmib@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 Subject: [Entmib] Entity State MIB: Open Issues? 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: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , I have attempted to determine consensus on what appears (to me) to be the remaining open issues with the Entity State MIB. Are there other open issues that still require resolution? Or are there "closed" issues for which anyone in the group disagrees with the resolution that Sharon has proposed? I'd like to get all of the remaining issues (if any) on the table, so that we can get the final edits done and get this document submitted to the IESG ASAP. Thanks, Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Sat May 1 13:12:14 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03495 for ; Sat, 1 May 2004 13:12:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJxxo-0004FP-3m for entmib-archive@odin.ietf.org; Sat, 01 May 2004 13:07:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i41H7ivY016317 for entmib-archive@odin.ietf.org; Sat, 1 May 2004 13:07:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJxXw-0007MT-Mh; Sat, 01 May 2004 12:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJw9n-00009Z-QC for entmib@optimus.ietf.org; Sat, 01 May 2004 11:11:59 -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 LAA24301 for ; Sat, 1 May 2004 11:11:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJw9m-0000lk-W0 for entmib@ietf.org; Sat, 01 May 2004 11:11:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJw8r-0000YM-00 for entmib@ietf.org; Sat, 01 May 2004 11:11:02 -0400 Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx with esmtp (Exim 4.12) id 1BJw7v-0000L0-00 for entmib@ietf.org; Sat, 01 May 2004 11:10:03 -0400 Received: from [24.61.30.237] (account margaret HELO [10.0.0.64]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 68224; Sat, 01 May 2004 11:09:34 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <4.3.2.7.2.20040414182947.02953c90@128.96.81.11> References: <4.3.2.7.2.20040414182947.02953c90@128.96.81.11> Date: Sat, 1 May 2004 11:09:45 -0400 To: Kaj Tesink , entmib@ietf.org From: Margaret Wasserman Subject: RE: [Entmib] Re: Entity mib support for tcif Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Kaj, I'm sorry that I didn't answer this message sooner. I was on vacation in mid-April, and I'm only catching up now. 3. acceptance as work item since the original proposal i've seen several supporting comments but i leave this to the WG chair and AD to gauge The Entity MIB WG charter does not currently include this work, so we could not accept this document as a work item without a charter update. There are at least two concerns about updating the Entity MIB WG charter to include this item: 1) The WG has not been timely in completing our current work. 2) I was appointed to the IESG last July, and it is not considered a good idea for IESG members to run WGs. I stayed on as entmib WG chair because we were expected to complete our work within a few months (not that things have gone exactly as planned...). If the life of the WG will be extended by new work items, it will be necessary for Bert to identify and appoint a new chair. So, if you want to pursue this work in the IETF, you should talk to Bert Wijnen about the best way to do that. In the meantime, the only chartered work items for the entmib WG are completing the Entity State MIB and getting the Entity MIB promoted to Draft Standard. Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Sat May 1 13:12:39 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03534 for ; Sat, 1 May 2004 13:12:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJxz7-0005lt-4U for entmib-archive@odin.ietf.org; Sat, 01 May 2004 13:09:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i41H95gB022175 for entmib-archive@odin.ietf.org; Sat, 1 May 2004 13:09:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJxbr-0000pB-0K; Sat, 01 May 2004 12:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJwOk-0004tv-4r for entmib@optimus.ietf.org; Sat, 01 May 2004 11:27:26 -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 LAA25403 for ; Sat, 1 May 2004 11:27:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJwOj-0003Ie-7A for entmib@ietf.org; Sat, 01 May 2004 11:27:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJwN5-0002la-00 for entmib@ietf.org; Sat, 01 May 2004 11:25:45 -0400 Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx with esmtp (Exim 4.12) id 1BJwL9-0002D7-00 for entmib@ietf.org; Sat, 01 May 2004 11:23:43 -0400 Received: from [24.61.30.237] (account margaret HELO [10.0.0.64]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 68227 for entmib@ietf.org; Sat, 01 May 2004 11:23:05 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <3549C09B853DD5119B540002A52CDD340ACD5D06@zcard0ka.ca.nortel.com> References: <3549C09B853DD5119B540002A52CDD340ACD5D06@zcard0ka.ca.nortel.com> Date: Sat, 1 May 2004 11:20:57 -0400 To: entmib@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 Subject: [Entmib] CONSENSUS CALL: #322 - Textual Convention Names (Prefix) 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: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Based on my reading of the mailing list, it seems like we have very rough consensus on two things related to issue #322: (1) The TCs should be placed in a separate MIB module (within the same I-D) to facilitate their re-use in other MIB modules, as appropriate. (2) The TCs are specific-enough to the state of logical and physical entities that it would make sense to use "Entity" (or perhaps "EntityState") as a prefix for these TCs. I know that there were some people that didn't agree with one or both of these positions, but it seems like most people would be willing to accept these two choices. Does anyone disagree that we seem to have rough consensus on these two positions? Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Sat May 1 13:12:45 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03566 for ; Sat, 1 May 2004 13:12:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJxzQ-0006Oq-TP for entmib-archive@odin.ietf.org; Sat, 01 May 2004 13:09:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i41H9Oad024590 for entmib-archive@odin.ietf.org; Sat, 1 May 2004 13:09:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJxbr-0000pJ-6X; Sat, 01 May 2004 12:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJwOp-0004vU-OT for entmib@optimus.ietf.org; Sat, 01 May 2004 11:27:31 -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 LAA25436 for ; Sat, 1 May 2004 11:27:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJwOo-0003Ji-RF for entmib@ietf.org; Sat, 01 May 2004 11:27:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJwNC-0002mp-00 for entmib@ietf.org; Sat, 01 May 2004 11:25:51 -0400 Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx with esmtp (Exim 4.12) id 1BJwLJ-0002D7-00 for entmib@ietf.org; Sat, 01 May 2004 11:23:53 -0400 Received: from [24.61.30.237] (account margaret HELO [10.0.0.64]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 68228; Sat, 01 May 2004 11:23:05 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <3549C09B853DD5119B540002A52CDD340ACD5D55@zcard0ka.ca.nortel.com> References: <3549C09B853DD5119B540002A52CDD340ACD5D55@zcard0ka.ca.nortel.com> Date: Sat, 1 May 2004 11:23:28 -0400 To: "Sharon Chisholm" , entmib@ietf.org From: Margaret Wasserman Subject: Re: [Entmib] entstate-335: Consensus Check Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , IMO, we would need consensus to add a new notification to the Enitity State MIB at this point, and I did not see consensus to add this notification. Does anyone disagree with the above consensus call? If not, Sharon please do not add the new notification and mark this issue as closed. Thanks, Margaret At 4:24 PM -0400 4/12/04, Sharon Chisholm wrote: >hi > > >There has been a proposal to add a new notification related to the stand by >state. There hasn't really been any opposition based on people feeling it is >a really bad idea or anything, but there has been a couple bits of >opposition against adding it more related to benefit, current stage in MIB >development, lack of proposal, etc. > >Is consensus not to add this new notification(s) at this time? > > >[Note there is a bit more in the 335 thread, but it's not really related] > >Sharon Chisholm >Portfolio Integration >Nortel Networks >Ottawa, Canada > >_______________________________________________ >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 From exim@www1.ietf.org Sat May 1 13:13:39 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03627 for ; Sat, 1 May 2004 13:13:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJxzf-0006rW-5A for entmib-archive@odin.ietf.org; Sat, 01 May 2004 13:09:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i41H9dEj026352 for entmib-archive@odin.ietf.org; Sat, 1 May 2004 13:09:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJxcn-0001MI-GT; Sat, 01 May 2004 12:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJwQf-0005eD-CJ for entmib@optimus.ietf.org; Sat, 01 May 2004 11:29:25 -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 LAA25846 for ; Sat, 1 May 2004 11:29:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJwQe-0003pK-E8 for entmib@ietf.org; Sat, 01 May 2004 11:29:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJwQ0-0003bm-00 for entmib@ietf.org; Sat, 01 May 2004 11:28:45 -0400 Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx with esmtp (Exim 4.12) id 1BJwOy-0003Kx-00 for entmib@ietf.org; Sat, 01 May 2004 11:27:40 -0400 Received: from [24.61.30.237] (account margaret HELO [10.0.0.64]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 68232; Sat, 01 May 2004 11:27:12 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <005a01c412a8$145a89a0$7f1afea9@oemcomputer> References: <3549C09B853DD5119B540002A52CDD340A9D3071@zcard0ka.ca.nortel.com> <5.2.0.9.2.20040325115604.023269f8@127.0.0.1> <005a01c412a8$145a89a0$7f1afea9@oemcomputer> Date: Sat, 1 May 2004 11:27:31 -0400 To: "Randy Presuhn" , From: Margaret Wasserman Subject: Re: [Entmib] #355: OSI State to Something New Spectrum Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , 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" >> To: "Randy Presuhn" ; >> 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 From exim@www1.ietf.org Sat May 1 13:14:13 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03666 for ; Sat, 1 May 2004 13:14:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJy06-0007MH-G7 for entmib-archive@odin.ietf.org; Sat, 01 May 2004 13:10:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i41HA6Mn028275 for entmib-archive@odin.ietf.org; Sat, 1 May 2004 13:10:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJxdk-0002cG-CC; Sat, 01 May 2004 12:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJwX2-0007XU-Sg for entmib@optimus.ietf.org; Sat, 01 May 2004 11:36:00 -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 LAA26421 for ; Sat, 1 May 2004 11:35:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJwX1-0005FQ-Rb for entmib@ietf.org; Sat, 01 May 2004 11:35:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJwW1-00052C-00 for entmib@ietf.org; Sat, 01 May 2004 11:34:58 -0400 Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx with esmtp (Exim 4.12) id 1BJwV2-0004qL-00 for entmib@ietf.org; Sat, 01 May 2004 11:33:56 -0400 Received: from [24.61.30.237] (account margaret HELO [10.0.0.64]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 68233 for entmib@ietf.org; Sat, 01 May 2004 11:33:28 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: Date: Sat, 1 May 2004 11:32:49 -0400 To: entmib@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 Subject: [Entmib] Entity State MIB: Open Issues? 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: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , I have attempted to determine consensus on what appears (to me) to be the remaining open issues with the Entity State MIB. Are there other open issues that still require resolution? Or are there "closed" issues for which anyone in the group disagrees with the resolution that Sharon has proposed? I'd like to get all of the remaining issues (if any) on the table, so that we can get the final edits done and get this document submitted to the IESG ASAP. Thanks, Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Sun May 2 05:59:01 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07726 for ; Sun, 2 May 2004 05:59:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKDdi-0008U3-7E; Sun, 02 May 2004 05:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKDbu-0007oF-Ms for entmib@optimus.ietf.org; Sun, 02 May 2004 05:50:10 -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 FAA05278 for ; Sun, 2 May 2004 05:03:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKCsy-0003FW-5r for entmib@ietf.org; Sun, 02 May 2004 05:03:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKCs5-00032a-00 for entmib@ietf.org; Sun, 02 May 2004 05:02:50 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1BKCre-0002om-00 for entmib@ietf.org; Sun, 02 May 2004 05:02:22 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4291q904403 for ; Sun, 2 May 2004 05:01:52 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 2 May 2004 05:01:53 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD340B01E2F8@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] #355: OSI State to Something New Spectrum Date: Sun, 2 May 2004 05:01:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , 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" >> To: "Randy Presuhn" ; >> >> 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 From exim@www1.ietf.org Sun May 2 06:01:08 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07861 for ; Sun, 2 May 2004 06:01:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKDk2-0001tG-Tb for entmib-archive@odin.ietf.org; Sun, 02 May 2004 05:58:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i429wY6u007266 for entmib-archive@odin.ietf.org; Sun, 2 May 2004 05:58:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKDdi-0008U3-7E; Sun, 02 May 2004 05:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKDbu-0007oF-Ms for entmib@optimus.ietf.org; Sun, 02 May 2004 05:50:10 -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 FAA05278 for ; Sun, 2 May 2004 05:03:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKCsy-0003FW-5r for entmib@ietf.org; Sun, 02 May 2004 05:03:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKCs5-00032a-00 for entmib@ietf.org; Sun, 02 May 2004 05:02:50 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1BKCre-0002om-00 for entmib@ietf.org; Sun, 02 May 2004 05:02:22 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4291q904403 for ; Sun, 2 May 2004 05:01:52 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 2 May 2004 05:01:53 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD340B01E2F8@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] #355: OSI State to Something New Spectrum Date: Sun, 2 May 2004 05:01:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , 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" >> To: "Randy Presuhn" ; >> >> 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 From entmib-admin@ietf.org Mon May 3 07:57:18 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22566 for ; Mon, 3 May 2004 07:57:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKbwV-0001e2-0V; Mon, 03 May 2004 07:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKbsJ-0008RT-8v for entmib@optimus.ietf.org; Mon, 03 May 2004 07:44:43 -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 HAA22121 for ; Mon, 3 May 2004 07:44:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKbsI-0003eD-Iw for entmib@ietf.org; Mon, 03 May 2004 07:44:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKbpP-000387-00 for entmib@ietf.org; Mon, 03 May 2004 07:41:45 -0400 Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx with esmtp (Exim 4.12) id 1BKbmZ-0002Z4-00 for entmib@ietf.org; Mon, 03 May 2004 07:38:47 -0400 Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 68624; Mon, 03 May 2004 07:37:52 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: Date: Mon, 3 May 2004 07:35:45 -0400 To: "Sharon Chisholm" From: Margaret Wasserman Subject: RE: [Entmib] #355: OSI State to Something New Spectrum Cc: entmib@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , 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: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" >>> To: "Randy Presuhn" ; >>> >>> 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 From exim@www1.ietf.org Mon May 3 08:20:11 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23534 for ; Mon, 3 May 2004 08:20:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKc42-0004Ce-1C for entmib-archive@odin.ietf.org; Mon, 03 May 2004 07:56:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43BunW7016156 for entmib-archive@odin.ietf.org; Mon, 3 May 2004 07:56:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKbwV-0001e2-0V; Mon, 03 May 2004 07:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKbsJ-0008RT-8v for entmib@optimus.ietf.org; Mon, 03 May 2004 07:44:43 -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 HAA22121 for ; Mon, 3 May 2004 07:44:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKbsI-0003eD-Iw for entmib@ietf.org; Mon, 03 May 2004 07:44:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKbpP-000387-00 for entmib@ietf.org; Mon, 03 May 2004 07:41:45 -0400 Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx with esmtp (Exim 4.12) id 1BKbmZ-0002Z4-00 for entmib@ietf.org; Mon, 03 May 2004 07:38:47 -0400 Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 68624; Mon, 03 May 2004 07:37:52 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: Date: Mon, 3 May 2004 07:35:45 -0400 To: "Sharon Chisholm" From: Margaret Wasserman Subject: RE: [Entmib] #355: OSI State to Something New Spectrum Cc: entmib@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , 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: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" >>> To: "Randy Presuhn" ; >>> >>> 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 From entmib-admin@ietf.org Mon May 3 18:34:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09059 for ; Mon, 3 May 2004 18:34:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKlxn-0000aL-R7; Mon, 03 May 2004 18:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKlmA-0006Gf-OE for entmib@optimus.ietf.org; Mon, 03 May 2004 18:19:03 -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 SAA08155 for ; Mon, 3 May 2004 18:18:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKlm7-0004TD-OM for entmib@ietf.org; Mon, 03 May 2004 18:18:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKll7-0004LW-00 for entmib@ietf.org; Mon, 03 May 2004 18:17:59 -0400 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx with esmtp (Exim 4.12) id 1BKlkC-00047b-00 for entmib@ietf.org; Mon, 03 May 2004 18:17:00 -0400 Received: from shannon.research.telcordia.com (shannon [128.96.81.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id i43MGG8o022322; Mon, 3 May 2004 18:16:16 -0400 (EDT) Received: from kaj-100.research.telcordia.com (kaj-100.cc.telcordia.com [128.96.71.110]) by shannon.research.telcordia.com (8.9.3/8.9.3) with ESMTP id SAA09362; Mon, 3 May 2004 18:16:15 -0400 (EDT) Message-Id: <4.3.2.7.2.20040503134541.02568348@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 May 2004 14:06:45 -0400 To: "Wijnen, Bert (Bert)" , Margaret Wasserman From: Kaj Tesink Subject: RE: [Entmib] Re: Entity mib support for tcif Cc: entmib@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,DATE_IN_PAST_03_06, HTML_20_30,HTML_FONTCOLOR_BLUE,HTML_MESSAGE,MIME_HTML_ONLY, NO_OBLIGATION 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: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: ,
Margaret, thanks for your note.

Bert, see attached message from Margaret.
the original thread is attached as well.

as you know on this issue there were three issues raised:
1. document title is too vague
2. opaque object is cumbersome to implement
3. acceptance as work item

on (1): seems resolvable to all satisfaction
on (2): there has been some back&forth on this one; Juergen
         and Dave P thought that a URN approach may work best;
         Dave P. will provide a strawman (due to him being sick
         last week this has been delayed).
on (3): Margaret refers to you given the state of the entmib WG.
         all I can add is that there have been a handful of
         expressions of support, and no objections (comments
         have focused on (1) and (2) instead).

your guidance on how to carry this forward is appreciated,

kaj



X-Sender: margaret@mail.thingmagic.com
Date: Sat, 1 May 2004 11:09:45 -0400
To: Kaj Tesink <kaj@research.telcordia.com>, entmib@ietf.org
From: Margaret Wasserman <margaret@thingmagic.com>
Subject: RE: [Entmib] Re: Entity mib support for tcif
X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper)
X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/)


Hi Kaj,

I'm sorry that I didn't answer this message sooner.  I was on vacation in mid-April, and I'm only catching up now.

3. acceptance as work item
since the original proposal i've seen several supporting comments
but i leave this to the WG chair and AD to gauge

The Entity MIB WG charter does not currently include this work, so we could not accept this document as a work item without a charter update.

There are at least two concerns about updating the Entity MIB WG charter to include this item:

1) The WG has not been timely in completing our current work.

2) I was appointed to the IESG last July, and it is not considered a good idea for IESG members to run WGs.  I stayed on as entmib WG chair because we were expected to complete our work within a few months (not that things have gone exactly as planned...). If the life of the WG will be extended by new work items, it will be necessary for Bert to identify and appoint a new chair.

So, if you want to pursue this work in the IETF, you should talk to Bert Wijnen about the best way to do that.  In the meantime, the only chartered work items for the entmib WG are completing the Entity State MIB and getting the Entity MIB promoted to Draft Standard.

Margaret



ORGINAL THREAD:
===========================================================

X-Sender: kaj@128.96.81.11
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 14 Apr 2004 19:01:31 -0400
To: entmib@ietf.org
From: Kaj Tesink <kaj@research.telcordia.com>
Subject: RE: [Entmib] Re: Entity mib support for tcif
X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
ietf-mx.ietf.org
X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,HTML_30_40,
HTML_FONTCOLOR_BLUE,HTML_MESSAGE,MIME_HTML_ONLY,NO_OBLIGATION
autolearn=no version=2.60
Sender: entmib-admin@ietf.org
X-BeenThere: entmib@ietf.org
X-Mailman-Version: 2.0.12
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>

At 03:34 PM 4/9/2004 -0700, Faye Ly wrote:
Hi,

Yes, we have a need for this MIB. Any chance of getting this done?


i think the following issues have been raised:
1. document title is too vague
2. opaque object is cumbersome to implement
3. acceptance as work item


1. document title is too vague:
current proposed title is:
Definitions of Supplemental Entity Managed Objects

the current contents of the MIB module is only two objects
- manufacturing date
- additional info (an opaque object with one currently identified
application)

i proposed this title to be
a) in line with similar documentation techniques in the past
b) to be compatible with possible extensions in the future

given the two current objects, and that one of them is opaque,
it is hard to be very specific. Dan suggested something like:
'Entity MIB Extensions for manufacturing date and physical module identification'

or perhaps:

Extensions to entPhysicalTable of the Entity MIB
(more precise but still not very illuminating)

I suggest we go with Dan's proposal.


2. opaque object is cumbersome to implement.
the suggested construct was based on neat suggestions by Dave
and was meant to accommodate several concerns and also
allow flexibility. but several comments pointed out that
this may be too cumbersome to implement. i attach the
original proposal which was an object dedicated to CLEI.
note that my original question was posed in the context of
extending the Entity MIB directly instead of creating a separate
document.
any strong feelings against going back to the original? Dave?


3. acceptance as work item
since the original proposal i've seen several supporting comments
but i leave this to the WG chair and AD to gauge

kaj





---snip from initial posting-------------------------------------------------


=============================================================
new objects:

entPhysicalCLIECode OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..10))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The CLIE Code for the physical entity. If a CLIE Code
is unknown or non-existent, the entPhysicalCLIECode will
be set to a zero-length string instead."
::= { entPhysicalEntry xx }
REFERENCE "TCIF-02-004, Guideline for data elements
included in the Management Information Base,
Telecommunications Industry Forum (TCIF), 09/11/2002.
ANSI T1.213-2001, Coded identification of equipment entities
of the North American telecommunications system for
information exchange, ANSI.
ANSI T1.213a-2001, Supplement to T1.213-2001,
Coded identification of equipment entities of the North
American telecommunications system for information exchange,
to correct the representation of the Basic Code in
Figure B.1, ANSI."

entPhysicalMfgDate OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The manufacturing date for the physical entity."
::= { entPhysicalEntry xx }



-faye
-----Original Message-----
From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org] On Behalf Of Kaj Tesink
Sent: Friday, April 02, 2004 8:38 AM
To: Sharon Chisholm; entmib@ietf.org
Subject: [Entmib] Re: Entity mib support for tcif

hi Sharon,

At 12:56 PM 4/1/2004 -0500, Sharon Chisholm wrote:

hi

Where are we in this discussion? Have we decided whether the working group
wants to take this on?


i think that question is still pending;
we asked for input and expressions of interest well before the
last ietf meeting but there has not been much traffic on this
since that request. so let me repeat the request for input on this spec:

http://www.ietf.org/internet-drafts/draft-tesink-entity-supplmib-00.txt





This is a requirement I've heard bounced around a few times so I think this
is worth trying to address, but like Dan I have a few concerns with some
aspects of the proposed solution. As he has mentioned, the title is not
sufficiently descriptive. In addition, I think the data types might be too
opaque to be useful.


as per my comments based on Dan's note, there were
some good reasons for the high level title, but
i'd be open to other suggestions.

as for the opaque object, the history is that
the initial proposal based on an octet string
syntax invoked a discussion about flexibility
and some other aspects, and resulted in a proposal
by Dave for the current opaque construct, although
some other comments expressed reservations (i believe
by Juergen and Dan).
i'm willing to go with whatever the rough consensus
dictates.

kaj





Sharon
-----Original Message-----
From: Kaj Tesink [mailto:kaj@research.telcordia.com]
Sent: Wednesday, February 11, 2004 10:25 AM
To: entmib@ietf.org
Subject: RE: [Entmib] Re: Entity mib support for tcif



Hi Dan,

At 10:03 PM 2/10/2004 +0200, Romascanu, Dan (Dan) wrote:
>Kaj,
>
>I was among the ones who supported doing this work. I did not change my
>mind.
>
>Two comments:
>1. I would like the title of the document to be more explicit about
>what
>is really provided by this MIB. 'Supplemental' is really too generic a
>title - what about something like 'Entity MIB Extensions for manufacturing
>and physical modules identification'?



I see what you're trying to do. While this would more accurately reflect the
content, there is the issue of future compatibility. The problem with
adding
new objects to MIBs over time is that
a) either you add to the original spec; but this means there's a problem
with advancing the spec over time
b) or you define supplemental specs; the problem here is that you dont want
all sorts of miblets around; you want to minimize the number So, similar
as what we did for ATM, and attempted for DS1s, the tactic was to use this
generic title, so that additional functions could still be added for a
while. I agree its not perfect. I also thought that in previous
discussions
there were some thoughts about some additional functions(?).

>2. Some of the concerns expressed in the meeting (not by me) were
>related
>to the availability and the proprietary nature of the CLEI codes. Can you
>comment on these? Are the documents mentioned in the REFERENCE clause of
>the cleiCode object freely available?

You're right, some of that did come up before.
My understanding is the following:
- the references point to documents by different standards groups,
and i think are available for a small fee at www.atis.org
- CLEI codes are defined in those standards;
Telcordia is the registrar to obtain an actual code
In previous discussion it was pointed out that
while CLEIs are in wide use, there is no obligation to
use them; I've tried to reflect that in the draft
in two ways: (a) use an opaque object instead of a dedicated object as
proposed by Dave, and (b) language for the case that the whole thing (no
CLEI nor any other application of the object) is not supported.

Kaj







>Thanks and Regards,
>
>Dan
>
>
>
> > -----Original Message-----
> > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On Behalf
> > Of Kaj Tesink
> > Sent: 10 February, 2004 6:48 PM
> > To: entmib@ietf.org
> > Subject: Fwd: [Entmib] Re: Entity mib support for tcif
> >
> >
> > all,
> >
> > the draft i sent to the list last week is now available at
> > http://www.ietf.org/internet-drafts/draft-tesink-entity-supplm
> > ib-00.txt
> >
> > pl note that the file name was changed (my error).
> > in order to move this forward the WG would need
> > to accept this as a formal work item.
> >
> > so we'd appreciate comments on
> > a) whether there is support/objection to do this work
> > b) any technical comments
> > while the minneapolis meeting already indicated some tentative
> > support, restating this or any new/additional views would be helpful
> >
> > kaj
> >
> >
> >
> >
> > >X-Sender: kaj@128.96.81.11
> > >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
> > >Date: Thu, 05 Feb 2004 15:06:54 -0500
> > >To: entmib@ietf.org
> > >From: Kaj Tesink <kaj@research.telcordia.com>
> > >
> > >
> > >all,
> > >
> > >attached is the supplemental entity miblet
> > >discussed a while ago, supporting
> > >- manufacturing date
> > >- additional entity info
> > >the latter uses the method proposed by dave
> > >to convey information such as CLEIs.
> > >i do recall that there were some different
> > >views on whether to use an opaque encoding
> > >method versus using a dedicated object, but
> > >please read it over and provide any comments.
> > >
> > >kaj
> >



_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies. Inc.
331 Newman Springs Road
Red Bank, NJ 07701
Email: kaj@research.telcordia.com
Tel: (732) 758-5254
Fax: (732) 758-4177

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Mon May 3 18:46:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09481 for ; Mon, 3 May 2004 18:46:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKm0z-0001uT-F4 for entmib-archive@odin.ietf.org; Mon, 03 May 2004 18:34:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43MYLxE007342 for entmib-archive@odin.ietf.org; Mon, 3 May 2004 18:34:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKlxn-0000aL-R7; Mon, 03 May 2004 18:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKlmA-0006Gf-OE for entmib@optimus.ietf.org; Mon, 03 May 2004 18:19:03 -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 SAA08155 for ; Mon, 3 May 2004 18:18:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKlm7-0004TD-OM for entmib@ietf.org; Mon, 03 May 2004 18:18:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKll7-0004LW-00 for entmib@ietf.org; Mon, 03 May 2004 18:17:59 -0400 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx with esmtp (Exim 4.12) id 1BKlkC-00047b-00 for entmib@ietf.org; Mon, 03 May 2004 18:17:00 -0400 Received: from shannon.research.telcordia.com (shannon [128.96.81.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id i43MGG8o022322; Mon, 3 May 2004 18:16:16 -0400 (EDT) Received: from kaj-100.research.telcordia.com (kaj-100.cc.telcordia.com [128.96.71.110]) by shannon.research.telcordia.com (8.9.3/8.9.3) with ESMTP id SAA09362; Mon, 3 May 2004 18:16:15 -0400 (EDT) Message-Id: <4.3.2.7.2.20040503134541.02568348@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 May 2004 14:06:45 -0400 To: "Wijnen, Bert (Bert)" , Margaret Wasserman From: Kaj Tesink Subject: RE: [Entmib] Re: Entity mib support for tcif Cc: entmib@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,DATE_IN_PAST_03_06, HTML_20_30,HTML_FONTCOLOR_BLUE,HTML_MESSAGE,MIME_HTML_ONLY, NO_OBLIGATION 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: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: ,
Margaret, thanks for your note.

Bert, see attached message from Margaret.
the original thread is attached as well.

as you know on this issue there were three issues raised:
1. document title is too vague
2. opaque object is cumbersome to implement
3. acceptance as work item

on (1): seems resolvable to all satisfaction
on (2): there has been some back&forth on this one; Juergen
         and Dave P thought that a URN approach may work best;
         Dave P. will provide a strawman (due to him being sick
         last week this has been delayed).
on (3): Margaret refers to you given the state of the entmib WG.
         all I can add is that there have been a handful of
         expressions of support, and no objections (comments
         have focused on (1) and (2) instead).

your guidance on how to carry this forward is appreciated,

kaj



X-Sender: margaret@mail.thingmagic.com
Date: Sat, 1 May 2004 11:09:45 -0400
To: Kaj Tesink <kaj@research.telcordia.com>, entmib@ietf.org
From: Margaret Wasserman <margaret@thingmagic.com>
Subject: RE: [Entmib] Re: Entity mib support for tcif
X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper)
X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/)


Hi Kaj,

I'm sorry that I didn't answer this message sooner.  I was on vacation in mid-April, and I'm only catching up now.

3. acceptance as work item
since the original proposal i've seen several supporting comments
but i leave this to the WG chair and AD to gauge

The Entity MIB WG charter does not currently include this work, so we could not accept this document as a work item without a charter update.

There are at least two concerns about updating the Entity MIB WG charter to include this item:

1) The WG has not been timely in completing our current work.

2) I was appointed to the IESG last July, and it is not considered a good idea for IESG members to run WGs.  I stayed on as entmib WG chair because we were expected to complete our work within a few months (not that things have gone exactly as planned...). If the life of the WG will be extended by new work items, it will be necessary for Bert to identify and appoint a new chair.

So, if you want to pursue this work in the IETF, you should talk to Bert Wijnen about the best way to do that.  In the meantime, the only chartered work items for the entmib WG are completing the Entity State MIB and getting the Entity MIB promoted to Draft Standard.

Margaret



ORGINAL THREAD:
===========================================================

X-Sender: kaj@128.96.81.11
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 14 Apr 2004 19:01:31 -0400
To: entmib@ietf.org
From: Kaj Tesink <kaj@research.telcordia.com>
Subject: RE: [Entmib] Re: Entity mib support for tcif
X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
ietf-mx.ietf.org
X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,HTML_30_40,
HTML_FONTCOLOR_BLUE,HTML_MESSAGE,MIME_HTML_ONLY,NO_OBLIGATION
autolearn=no version=2.60
Sender: entmib-admin@ietf.org
X-BeenThere: entmib@ietf.org
X-Mailman-Version: 2.0.12
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>

At 03:34 PM 4/9/2004 -0700, Faye Ly wrote:
Hi,

Yes, we have a need for this MIB. Any chance of getting this done?


i think the following issues have been raised:
1. document title is too vague
2. opaque object is cumbersome to implement
3. acceptance as work item


1. document title is too vague:
current proposed title is:
Definitions of Supplemental Entity Managed Objects

the current contents of the MIB module is only two objects
- manufacturing date
- additional info (an opaque object with one currently identified
application)

i proposed this title to be
a) in line with similar documentation techniques in the past
b) to be compatible with possible extensions in the future

given the two current objects, and that one of them is opaque,
it is hard to be very specific. Dan suggested something like:
'Entity MIB Extensions for manufacturing date and physical module identification'

or perhaps:

Extensions to entPhysicalTable of the Entity MIB
(more precise but still not very illuminating)

I suggest we go with Dan's proposal.


2. opaque object is cumbersome to implement.
the suggested construct was based on neat suggestions by Dave
and was meant to accommodate several concerns and also
allow flexibility. but several comments pointed out that
this may be too cumbersome to implement. i attach the
original proposal which was an object dedicated to CLEI.
note that my original question was posed in the context of
extending the Entity MIB directly instead of creating a separate
document.
any strong feelings against going back to the original? Dave?


3. acceptance as work item
since the original proposal i've seen several supporting comments
but i leave this to the WG chair and AD to gauge

kaj





---snip from initial posting-------------------------------------------------


=============================================================
new objects:

entPhysicalCLIECode OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..10))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The CLIE Code for the physical entity. If a CLIE Code
is unknown or non-existent, the entPhysicalCLIECode will
be set to a zero-length string instead."
::= { entPhysicalEntry xx }
REFERENCE "TCIF-02-004, Guideline for data elements
included in the Management Information Base,
Telecommunications Industry Forum (TCIF), 09/11/2002.
ANSI T1.213-2001, Coded identification of equipment entities
of the North American telecommunications system for
information exchange, ANSI.
ANSI T1.213a-2001, Supplement to T1.213-2001,
Coded identification of equipment entities of the North
American telecommunications system for information exchange,
to correct the representation of the Basic Code in
Figure B.1, ANSI."

entPhysicalMfgDate OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The manufacturing date for the physical entity."
::= { entPhysicalEntry xx }



-faye
-----Original Message-----
From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org] On Behalf Of Kaj Tesink
Sent: Friday, April 02, 2004 8:38 AM
To: Sharon Chisholm; entmib@ietf.org
Subject: [Entmib] Re: Entity mib support for tcif

hi Sharon,

At 12:56 PM 4/1/2004 -0500, Sharon Chisholm wrote:

hi

Where are we in this discussion? Have we decided whether the working group
wants to take this on?


i think that question is still pending;
we asked for input and expressions of interest well before the
last ietf meeting but there has not been much traffic on this
since that request. so let me repeat the request for input on this spec:

http://www.ietf.org/internet-drafts/draft-tesink-entity-supplmib-00.txt





This is a requirement I've heard bounced around a few times so I think this
is worth trying to address, but like Dan I have a few concerns with some
aspects of the proposed solution. As he has mentioned, the title is not
sufficiently descriptive. In addition, I think the data types might be too
opaque to be useful.


as per my comments based on Dan's note, there were
some good reasons for the high level title, but
i'd be open to other suggestions.

as for the opaque object, the history is that
the initial proposal based on an octet string
syntax invoked a discussion about flexibility
and some other aspects, and resulted in a proposal
by Dave for the current opaque construct, although
some other comments expressed reservations (i believe
by Juergen and Dan).
i'm willing to go with whatever the rough consensus
dictates.

kaj





Sharon
-----Original Message-----
From: Kaj Tesink [mailto:kaj@research.telcordia.com]
Sent: Wednesday, February 11, 2004 10:25 AM
To: entmib@ietf.org
Subject: RE: [Entmib] Re: Entity mib support for tcif



Hi Dan,

At 10:03 PM 2/10/2004 +0200, Romascanu, Dan (Dan) wrote:
>Kaj,
>
>I was among the ones who supported doing this work. I did not change my
>mind.
>
>Two comments:
>1. I would like the title of the document to be more explicit about
>what
>is really provided by this MIB. 'Supplemental' is really too generic a
>title - what about something like 'Entity MIB Extensions for manufacturing
>and physical modules identification'?



I see what you're trying to do. While this would more accurately reflect the
content, there is the issue of future compatibility. The problem with
adding
new objects to MIBs over time is that
a) either you add to the original spec; but this means there's a problem
with advancing the spec over time
b) or you define supplemental specs; the problem here is that you dont want
all sorts of miblets around; you want to minimize the number So, similar
as what we did for ATM, and attempted for DS1s, the tactic was to use this
generic title, so that additional functions could still be added for a
while. I agree its not perfect. I also thought that in previous
discussions
there were some thoughts about some additional functions(?).

>2. Some of the concerns expressed in the meeting (not by me) were
>related
>to the availability and the proprietary nature of the CLEI codes. Can you
>comment on these? Are the documents mentioned in the REFERENCE clause of
>the cleiCode object freely available?

You're right, some of that did come up before.
My understanding is the following:
- the references point to documents by different standards groups,
and i think are available for a small fee at www.atis.org
- CLEI codes are defined in those standards;
Telcordia is the registrar to obtain an actual code
In previous discussion it was pointed out that
while CLEIs are in wide use, there is no obligation to
use them; I've tried to reflect that in the draft
in two ways: (a) use an opaque object instead of a dedicated object as
proposed by Dave, and (b) language for the case that the whole thing (no
CLEI nor any other application of the object) is not supported.

Kaj







>Thanks and Regards,
>
>Dan
>
>
>
> > -----Original Message-----
> > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On Behalf
> > Of Kaj Tesink
> > Sent: 10 February, 2004 6:48 PM
> > To: entmib@ietf.org
> > Subject: Fwd: [Entmib] Re: Entity mib support for tcif
> >
> >
> > all,
> >
> > the draft i sent to the list last week is now available at
> > http://www.ietf.org/internet-drafts/draft-tesink-entity-supplm
> > ib-00.txt
> >
> > pl note that the file name was changed (my error).
> > in order to move this forward the WG would need
> > to accept this as a formal work item.
> >
> > so we'd appreciate comments on
> > a) whether there is support/objection to do this work
> > b) any technical comments
> > while the minneapolis meeting already indicated some tentative
> > support, restating this or any new/additional views would be helpful
> >
> > kaj
> >
> >
> >
> >
> > >X-Sender: kaj@128.96.81.11
> > >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
> > >Date: Thu, 05 Feb 2004 15:06:54 -0500
> > >To: entmib@ietf.org
> > >From: Kaj Tesink <kaj@research.telcordia.com>
> > >
> > >
> > >all,
> > >
> > >attached is the supplemental entity miblet
> > >discussed a while ago, supporting
> > >- manufacturing date
> > >- additional entity info
> > >the latter uses the method proposed by dave
> > >to convey information such as CLEIs.
> > >i do recall that there were some different
> > >views on whether to use an opaque encoding
> > >method versus using a dedicated object, but
> > >please read it over and provide any comments.
> > >
> > >kaj
> >



_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies. Inc.
331 Newman Springs Road
Red Bank, NJ 07701
Email: kaj@research.telcordia.com
Tel: (732) 758-5254
Fax: (732) 758-4177

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Tue May 4 14:06:05 2004 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 ; 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 ; 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" To: References: <3549C09B853DD5119B540002A52CDD340B01E2F8@zcard0ka.ca.nortel.com> Subject: Re: [Entmib] #355: OSI State to Something New Spectrum Date: Tue, 4 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: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-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" > To: > 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" > >> To: "Randy Presuhn" ; > >> > >> 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 From exim@www1.ietf.org Tue May 4 14:14:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17012 for ; Tue, 4 May 2004 14:14:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4IU-0000Nr-3r for entmib-archive@odin.ietf.org; Tue, 04 May 2004 14:05:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44I5cMC001475 for entmib-archive@odin.ietf.org; Tue, 4 May 2004 14:05:38 -0400 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 ; 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" To: References: <3549C09B853DD5119B540002A52CDD340B01E2F8@zcard0ka.ca.nortel.com> Subject: Re: [Entmib] #355: OSI State to Something New Spectrum Date: Tue, 4 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: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-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" > To: > 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" > >> To: "Randy Presuhn" ; > >> > >> 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 From entmib-admin@ietf.org Thu May 13 10:28:07 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15640 for ; Thu, 13 May 2004 10:28:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOH70-0001vp-E8; Thu, 13 May 2004 10:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOGzf-0007ja-HB for entmib@optimus.ietf.org; Thu, 13 May 2004 10:15:27 -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 KAA14773 for ; Thu, 13 May 2004 10:15:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOGzd-0003dZ-84 for entmib@ietf.org; Thu, 13 May 2004 10:15:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOGyL-000360-00 for entmib@ietf.org; Thu, 13 May 2004 10:14:06 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1BOGxc-0002Z2-00 for entmib@ietf.org; Thu, 13 May 2004 10:13:20 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i4DE89rw010891 for ; Thu, 13 May 2004 09:08:09 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i4DE86rw010812 for ; Thu, 13 May 2004 09:08:07 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Entmib] #355: OSI State to Something New Spectrum Date: Thu, 13 May 2004 17:13:15 +0300 Message-ID: Thread-Topic: [Entmib] #355: OSI State to Something New Spectrum Thread-Index: AcQxBbgJN8cPiKTmTYmZ0IBW4VaU8wH7iWmA From: "Romascanu, Dan (Dan)" To: "Margaret Wasserman" , "Sharon Chisholm" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable 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: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On=20 > Behalf Of Margaret Wasserman > Sent: 03 May, 2004 2:36 PM > To: Sharon Chisholm > Cc: entmib@ietf.org > Subject: RE: [Entmib] #355: OSI State to Something New Spectrum >=20 >=20 >=20 > Sharon corrected my understanding of issue #355 (see below). But, my=20 > conclusion is much the same. >=20 > At this point we have had multiple WG Last Calls on this document=20 > and, according to our charter, we are quite overdue to send it to the=20 > IESG... So, I think that it should require consensus of the group to=20 > make any major changes to the document at this point. Do others=20 > agree with that position? >=20 > Given that we are split on this particular issue, I do not believe=20 > that we have consensus to make these changes so we should not make=20 > them. Does that make sense? >=20 > Margaret >=20 > >hi > > > >Actually, the issue was more/also whether there was=20 > consensus to change the > >current MIB a lot to diverge from the ITU-T model. We've=20 > diverged from it as > >has made sense to the working group, but there were a few=20 > requests for > >changes such as object renaming which in my personal view=20 > didn't make sense > >to do since they seemed non-value add changes. My take on=20 > 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" > >>> To: "Randy Presuhn" ; > >>> > >>> 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=20 > is "Is the > >>> ITU model and the specification for it worthwhile?" In=20 > the 10+ years > >>> that I have asked this question, I have NEVER gotten an answer. > >>> NEVER! In my own extensive analysis (which included=20 > creating both > >>> state and alarm MIB modules that are MUCH closer to the=20 > 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=20 > 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=20 > well to using > >>the TCs in this MIB module. From my perspective, this=20 > 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=20 > 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 >=20 >=20 > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib >=20 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu May 13 10:34:43 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16142 for ; Thu, 13 May 2004 10:34:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOHBU-00035F-Le for entmib-archive@odin.ietf.org; Thu, 13 May 2004 10:27:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DEReMo011854 for entmib-archive@odin.ietf.org; Thu, 13 May 2004 10:27:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOH70-0001vp-E8; Thu, 13 May 2004 10:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOGzf-0007ja-HB for entmib@optimus.ietf.org; Thu, 13 May 2004 10:15:27 -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 KAA14773 for ; Thu, 13 May 2004 10:15:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOGzd-0003dZ-84 for entmib@ietf.org; Thu, 13 May 2004 10:15:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOGyL-000360-00 for entmib@ietf.org; Thu, 13 May 2004 10:14:06 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1BOGxc-0002Z2-00 for entmib@ietf.org; Thu, 13 May 2004 10:13:20 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i4DE89rw010891 for ; Thu, 13 May 2004 09:08:09 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i4DE86rw010812 for ; Thu, 13 May 2004 09:08:07 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Entmib] #355: OSI State to Something New Spectrum Date: Thu, 13 May 2004 17:13:15 +0300 Message-ID: Thread-Topic: [Entmib] #355: OSI State to Something New Spectrum Thread-Index: AcQxBbgJN8cPiKTmTYmZ0IBW4VaU8wH7iWmA From: "Romascanu, Dan (Dan)" To: "Margaret Wasserman" , "Sharon Chisholm" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable 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: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On=20 > Behalf Of Margaret Wasserman > Sent: 03 May, 2004 2:36 PM > To: Sharon Chisholm > Cc: entmib@ietf.org > Subject: RE: [Entmib] #355: OSI State to Something New Spectrum >=20 >=20 >=20 > Sharon corrected my understanding of issue #355 (see below). But, my=20 > conclusion is much the same. >=20 > At this point we have had multiple WG Last Calls on this document=20 > and, according to our charter, we are quite overdue to send it to the=20 > IESG... So, I think that it should require consensus of the group to=20 > make any major changes to the document at this point. Do others=20 > agree with that position? >=20 > Given that we are split on this particular issue, I do not believe=20 > that we have consensus to make these changes so we should not make=20 > them. Does that make sense? >=20 > Margaret >=20 > >hi > > > >Actually, the issue was more/also whether there was=20 > consensus to change the > >current MIB a lot to diverge from the ITU-T model. We've=20 > diverged from it as > >has made sense to the working group, but there were a few=20 > requests for > >changes such as object renaming which in my personal view=20 > didn't make sense > >to do since they seemed non-value add changes. My take on=20 > 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" > >>> To: "Randy Presuhn" ; > >>> > >>> 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=20 > is "Is the > >>> ITU model and the specification for it worthwhile?" In=20 > the 10+ years > >>> that I have asked this question, I have NEVER gotten an answer. > >>> NEVER! In my own extensive analysis (which included=20 > creating both > >>> state and alarm MIB modules that are MUCH closer to the=20 > 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=20 > 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=20 > well to using > >>the TCs in this MIB module. From my perspective, this=20 > 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=20 > 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 >=20 >=20 > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib >=20 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib