From mailman-admin@ietf.org Sun Feb 1 09:17:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14418 for ; Sun, 1 Feb 2004 09:17:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnIPH-0001k2-8u for entmib-archive@lists.ietf.org; Sun, 01 Feb 2004 09:17:03 -0500 Date: Sun, 01 Feb 2004 09:17:03 -0500 Message-ID: <20040201141703.1364.12344.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 Mon Feb 2 17:22:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18098 for ; Mon, 2 Feb 2004 17:22:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmSA-0006MB-2c; Mon, 02 Feb 2004 17:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmS6-0006Kz-9p for entmib@optimus.ietf.org; Mon, 02 Feb 2004 17:21:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18075 for ; Mon, 2 Feb 2004 17:21:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnmS4-0005Iz-00 for entmib@ietf.org; Mon, 02 Feb 2004 17:21:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnmRD-0005DA-00 for entmib@ietf.org; Mon, 02 Feb 2004 17:21:03 -0500 Received: from smtp.exodus.net ([66.35.230.236]) by ietf-mx with esmtp (Exim 4.12) id 1AnmQi-00055U-00; Mon, 02 Feb 2004 17:20:34 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp.exodus.net (8.12.8/8.12.8) with ESMTP id i12Nwtw3017189; Mon, 2 Feb 2004 15:59:01 -0800 Received: from ala-mrwtemp.thingmagic.com (unverified [66.228.91.169]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id ; Mon, 2 Feb 2004 14:19:47 -0800 Message-Id: <5.1.0.14.2.20040202171225.04dcbe18@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Feb 2004 17:15:10 -0500 To: iesg-secretary@ietf.org From: Margaret Wasserman Cc: Bert Wijnen , David Kessens , entmib@ietf.org Mime-Version: 1.0 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] Publication Request: Entity MIB to Draft Standard 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 would like to request, on behalf of the Entity MIB WG that draft-ietf-entmib-v3-04.txt be published as a Draft Standard. The latest version of this document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-entmib-v3-04.txt Our implementation report can be found at: http://www.psg.com/~mrw/EntMIB-Impl-Report-Sep03.html Please let me know if you need further information to process this request. Thanks, Margaret Wasserman Entity MIB (entmib) WG Chair _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Mon Feb 2 17:23:27 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18170 for ; Mon, 2 Feb 2004 17:23:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmT6-0006QA-IE; Mon, 02 Feb 2004 17:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmS9-0006Lw-Mp for entmib@optimus.ietf.org; Mon, 02 Feb 2004 17:22:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18092 for ; Mon, 2 Feb 2004 17:21:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnmS7-0005JU-00 for entmib@ietf.org; Mon, 02 Feb 2004 17:21:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnmRG-0005Dn-00 for entmib@ietf.org; Mon, 02 Feb 2004 17:21:06 -0500 Received: from smtp.exodus.net ([66.35.230.236]) by ietf-mx with esmtp (Exim 4.12) id 1AnmQq-00056l-00; Mon, 02 Feb 2004 17:20:40 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp.exodus.net (8.12.8/8.12.8) with ESMTP id i12NxGw3017232; Mon, 2 Feb 2004 15:59:16 -0800 Received: from ala-mrwtemp.thingmagic.com (unverified [66.228.91.169]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id ; Mon, 2 Feb 2004 14:19:49 -0800 Message-Id: <5.1.0.14.2.20040202171512.04dd7700@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Feb 2004 17:16:50 -0500 To: entmib@ietf.org From: Margaret Wasserman Subject: Re: [Entmib] WG Last Call: Entity State MIB Cc: Entmib@ietf.org In-Reply-To: <5.1.0.14.2.20040123165643.045a9d70@ms101.mail1.com> Mime-Version: 1.0 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 All, Please respond to this last call with either positive or negative feedback on whether the Entity State MIB is ready for publication at PS. If you have reviewed this document and believe that it is ready for publication, please say so. Thanks, Margaret At 05:00 PM 1/23/2004 -0500, Margaret Wasserman wrote: >Hi All, > >This is a two week WG Last Call for submitting the Entity State >MIB to the IESG for publication as a Proposed Standard. The latest >version of this document can be found at: > >http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-02.txt > >This WG Last Call will end on Friday, February 6th at 5pm EST. > >Please review the document and forward substantive comments to >the mailing list. Editorial comments can be sent directly >to the authors. > >Thanks, >Margaret > > > >_______________________________________________ >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 Feb 2 17:23:27 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18172 for ; Mon, 2 Feb 2004 17:23:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmT7-0006RO-6v for entmib-archive@odin.ietf.org; Mon, 02 Feb 2004 17:23:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12MN0Xr024729 for entmib-archive@odin.ietf.org; Mon, 2 Feb 2004 17:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmT6-0006QA-IE; Mon, 02 Feb 2004 17:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmS9-0006Lw-Mp for entmib@optimus.ietf.org; Mon, 02 Feb 2004 17:22:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18092 for ; Mon, 2 Feb 2004 17:21:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnmS7-0005JU-00 for entmib@ietf.org; Mon, 02 Feb 2004 17:21:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnmRG-0005Dn-00 for entmib@ietf.org; Mon, 02 Feb 2004 17:21:06 -0500 Received: from smtp.exodus.net ([66.35.230.236]) by ietf-mx with esmtp (Exim 4.12) id 1AnmQq-00056l-00; Mon, 02 Feb 2004 17:20:40 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp.exodus.net (8.12.8/8.12.8) with ESMTP id i12NxGw3017232; Mon, 2 Feb 2004 15:59:16 -0800 Received: from ala-mrwtemp.thingmagic.com (unverified [66.228.91.169]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id ; Mon, 2 Feb 2004 14:19:49 -0800 Message-Id: <5.1.0.14.2.20040202171512.04dd7700@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Feb 2004 17:16:50 -0500 To: entmib@ietf.org From: Margaret Wasserman Subject: Re: [Entmib] WG Last Call: Entity State MIB Cc: Entmib@ietf.org In-Reply-To: <5.1.0.14.2.20040123165643.045a9d70@ms101.mail1.com> Mime-Version: 1.0 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 All, Please respond to this last call with either positive or negative feedback on whether the Entity State MIB is ready for publication at PS. If you have reviewed this document and believe that it is ready for publication, please say so. Thanks, Margaret At 05:00 PM 1/23/2004 -0500, Margaret Wasserman wrote: >Hi All, > >This is a two week WG Last Call for submitting the Entity State >MIB to the IESG for publication as a Proposed Standard. The latest >version of this document can be found at: > >http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-02.txt > >This WG Last Call will end on Friday, February 6th at 5pm EST. > >Please review the document and forward substantive comments to >the mailing list. Editorial comments can be sent directly >to the authors. > >Thanks, >Margaret > > > >_______________________________________________ >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 Feb 2 17:23:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18200 for ; Mon, 2 Feb 2004 17:23:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmT7-0006S4-Pw; Mon, 02 Feb 2004 17:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmS9-0006Lf-2k for entmib@optimus.ietf.org; Mon, 02 Feb 2004 17:22:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18089 for ; Mon, 2 Feb 2004 17:21:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnmS6-0005JP-00 for entmib@ietf.org; Mon, 02 Feb 2004 17:21:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnmRF-0005Dg-00 for entmib@ietf.org; Mon, 02 Feb 2004 17:21:06 -0500 Received: from smtp.exodus.net ([66.35.230.236]) by ietf-mx with esmtp (Exim 4.12) id 1AnmQq-00056l-00; Mon, 02 Feb 2004 17:20:40 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp.exodus.net (8.12.8/8.12.8) with ESMTP id i12NxGw3017232; Mon, 2 Feb 2004 15:59:16 -0800 Received: from ala-mrwtemp.thingmagic.com (unverified [66.228.91.169]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id ; Mon, 2 Feb 2004 14:19:49 -0800 Message-Id: <5.1.0.14.2.20040202171512.04dd7700@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Feb 2004 17:16:50 -0500 To: entmib@ietf.org From: Margaret Wasserman Subject: Re: [Entmib] WG Last Call: Entity State MIB Cc: Entmib@ietf.org In-Reply-To: <5.1.0.14.2.20040123165643.045a9d70@ms101.mail1.com> Mime-Version: 1.0 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 All, Please respond to this last call with either positive or negative feedback on whether the Entity State MIB is ready for publication at PS. If you have reviewed this document and believe that it is ready for publication, please say so. Thanks, Margaret At 05:00 PM 1/23/2004 -0500, Margaret Wasserman wrote: >Hi All, > >This is a two week WG Last Call for submitting the Entity State >MIB to the IESG for publication as a Proposed Standard. The latest >version of this document can be found at: > >http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-02.txt > >This WG Last Call will end on Friday, February 6th at 5pm EST. > >Please review the document and forward substantive comments to >the mailing list. Editorial comments can be sent directly >to the authors. > >Thanks, >Margaret > > > >_______________________________________________ >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 Feb 2 17:23:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18205 for ; Mon, 2 Feb 2004 17:23:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmT8-0006TD-5T for entmib-archive@odin.ietf.org; Mon, 02 Feb 2004 17:23:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12MN1ms024838 for entmib-archive@odin.ietf.org; Mon, 2 Feb 2004 17:23:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmT7-0006S4-Pw; Mon, 02 Feb 2004 17:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmS9-0006Lf-2k for entmib@optimus.ietf.org; Mon, 02 Feb 2004 17:22:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18089 for ; Mon, 2 Feb 2004 17:21:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnmS6-0005JP-00 for entmib@ietf.org; Mon, 02 Feb 2004 17:21:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnmRF-0005Dg-00 for entmib@ietf.org; Mon, 02 Feb 2004 17:21:06 -0500 Received: from smtp.exodus.net ([66.35.230.236]) by ietf-mx with esmtp (Exim 4.12) id 1AnmQq-00056l-00; Mon, 02 Feb 2004 17:20:40 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp.exodus.net (8.12.8/8.12.8) with ESMTP id i12NxGw3017232; Mon, 2 Feb 2004 15:59:16 -0800 Received: from ala-mrwtemp.thingmagic.com (unverified [66.228.91.169]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id ; Mon, 2 Feb 2004 14:19:49 -0800 Message-Id: <5.1.0.14.2.20040202171512.04dd7700@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Feb 2004 17:16:50 -0500 To: entmib@ietf.org From: Margaret Wasserman Subject: Re: [Entmib] WG Last Call: Entity State MIB Cc: Entmib@ietf.org In-Reply-To: <5.1.0.14.2.20040123165643.045a9d70@ms101.mail1.com> Mime-Version: 1.0 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 All, Please respond to this last call with either positive or negative feedback on whether the Entity State MIB is ready for publication at PS. If you have reviewed this document and believe that it is ready for publication, please say so. Thanks, Margaret At 05:00 PM 1/23/2004 -0500, Margaret Wasserman wrote: >Hi All, > >This is a two week WG Last Call for submitting the Entity State >MIB to the IESG for publication as a Proposed Standard. The latest >version of this document can be found at: > >http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-02.txt > >This WG Last Call will end on Friday, February 6th at 5pm EST. > >Please review the document and forward substantive comments to >the mailing list. Editorial comments can be sent directly >to the authors. > >Thanks, >Margaret > > > >_______________________________________________ >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 Tue Feb 3 12:09: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 MAA18759 for ; Tue, 3 Feb 2004 12:09:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao42m-0000tN-Lk; Tue, 03 Feb 2004 12:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao42Q-0000sp-Vj for entmib@optimus.ietf.org; Tue, 03 Feb 2004 12:08:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18751 for ; Tue, 3 Feb 2004 12:08:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao42P-00016S-00 for entmib@ietf.org; Tue, 03 Feb 2004 12:08:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao41Z-000108-00 for entmib@ietf.org; Tue, 03 Feb 2004 12:07:45 -0500 Received: from smtp.exodus.net ([66.35.230.237] helo=smtp02-w.exodus.net) by ietf-mx with esmtp (Exim 4.12) id 1Ao41C-0000te-00 for entmib@ietf.org; Tue, 03 Feb 2004 12:07:22 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp02-w.exodus.net (8.12.8/8.12.8) with ESMTP id i13EGdEv000795 for ; Tue, 3 Feb 2004 08:16:39 -0600 Received: from ala-mrwtemp.thingmagic.com (unverified [66.228.91.169]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id for ; Tue, 3 Feb 2004 09:06:51 -0800 Message-Id: <5.1.0.14.2.20040203115830.03bdd5d0@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Feb 2004 12:05:12 -0500 To: entmib@ietf.org From: Margaret Wasserman Mime-Version: 1.0 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] Meeting in Korea? 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 All, Do you think that we should schedule an Entity MIB meeting in Korea? The Entity MIB and our Entity MIB implementation reports are now in the hands of the IESG. The Entity State MIB is in a second WG Last Call, and we don't yet have any negative review comments. If we receive Last Call comments, I hope that we can resolve them and send this document to the IESG before Korea. So, I don't think that we will have any work to do at the next IETF meeting. What do others think? At this point, I personally think that the WG should finish up these two work items (Entity MIB to DS and Entity State MIB to PS), declare victory, and shut down. What do others think about that plan? Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Tue Feb 3 12:56:49 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 MAA18761 for ; Tue, 3 Feb 2004 12:09:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao42m-0000tk-TQ for entmib-archive@odin.ietf.org; Tue, 03 Feb 2004 12:09:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13H905m003440 for entmib-archive@odin.ietf.org; Tue, 3 Feb 2004 12:09:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao42m-0000tN-Lk; Tue, 03 Feb 2004 12:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao42Q-0000sp-Vj for entmib@optimus.ietf.org; Tue, 03 Feb 2004 12:08:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18751 for ; Tue, 3 Feb 2004 12:08:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao42P-00016S-00 for entmib@ietf.org; Tue, 03 Feb 2004 12:08:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao41Z-000108-00 for entmib@ietf.org; Tue, 03 Feb 2004 12:07:45 -0500 Received: from smtp.exodus.net ([66.35.230.237] helo=smtp02-w.exodus.net) by ietf-mx with esmtp (Exim 4.12) id 1Ao41C-0000te-00 for entmib@ietf.org; Tue, 03 Feb 2004 12:07:22 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp02-w.exodus.net (8.12.8/8.12.8) with ESMTP id i13EGdEv000795 for ; Tue, 3 Feb 2004 08:16:39 -0600 Received: from ala-mrwtemp.thingmagic.com (unverified [66.228.91.169]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id for ; Tue, 3 Feb 2004 09:06:51 -0800 Message-Id: <5.1.0.14.2.20040203115830.03bdd5d0@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Feb 2004 12:05:12 -0500 To: entmib@ietf.org From: Margaret Wasserman Mime-Version: 1.0 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] Meeting in Korea? 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 All, Do you think that we should schedule an Entity MIB meeting in Korea? The Entity MIB and our Entity MIB implementation reports are now in the hands of the IESG. The Entity State MIB is in a second WG Last Call, and we don't yet have any negative review comments. If we receive Last Call comments, I hope that we can resolve them and send this document to the IESG before Korea. So, I don't think that we will have any work to do at the next IETF meeting. What do others think? At this point, I personally think that the WG should finish up these two work items (Entity MIB to DS and Entity State MIB to PS), declare victory, and shut down. What do others think about that plan? Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Feb 4 09:15: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 JAA06651 for ; Wed, 4 Feb 2004 09:15:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoNo2-0007p7-C7 for entmib-archive@odin.ietf.org; Wed, 04 Feb 2004 09:15:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14EF62s030062 for entmib-archive@odin.ietf.org; Wed, 4 Feb 2004 09:15:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoNny-0007oZ-Jf; Wed, 04 Feb 2004 09:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoNnD-0007n1-Ea for entmib@optimus.ietf.org; Wed, 04 Feb 2004 09:14:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06523 for ; Wed, 4 Feb 2004 09:14:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoNnB-0000Xl-00 for entmib@ietf.org; Wed, 04 Feb 2004 09:14:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoNmJ-0000Ps-00 for entmib@ietf.org; Wed, 04 Feb 2004 09:13:19 -0500 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoNlJ-0000DN-00 for entmib@ietf.org; Wed, 04 Feb 2004 09:12:17 -0500 Received: from shannon.research.telcordia.com (shannon-83.research.telcordia.com [128.96.83.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id i14EBkai028335 for ; Wed, 4 Feb 2004 09:11:46 -0500 (EST) 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 JAA06390 for ; Wed, 4 Feb 2004 09:11:46 -0500 (EST) Message-Id: <4.3.2.7.2.20040204090420.02f9f198@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Feb 2004 09:11:42 -0500 To: entmib@ietf.org From: Kaj Tesink Subject: Re: [Entmib] Meeting in Korea? In-Reply-To: <5.1.0.14.2.20040203115830.03bdd5d0@ms101.mail1.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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=0.0 required=5.0 tests=none 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: , At 12:05 PM 2/3/2004 -0500, Margaret Wasserman wrote: >Hi All, > >Do you think that we should schedule an Entity MIB meeting >in Korea? > >The Entity MIB and our Entity MIB implementation reports >are now in the hands of the IESG. > >The Entity State MIB is in a second WG Last Call, and we >don't yet have any negative review comments. If we >receive Last Call comments, I hope that we can resolve >them and send this document to the IESG before Korea. > >So, I don't think that we will have any work to do at >the next IETF meeting. What do others think? as you recall i still owe the list a draft I-D with the supplemental objects we discussed before. apologies for the delay; i'll post asap. i personally dont think that those few objects merit the scheduling of a meeting given previous discussion on the topic. as far as closing down the wg i'd appreciate some delay to accommodate this supplemental work. kaj >At this point, I personally think that the WG should >finish up these two work items (Entity MIB to DS and >Entity State MIB to PS), declare victory, and shut down. >What do others think about that plan? > >Margaret > > >_______________________________________________ >Entmib mailing list >Entmib@ietf.org >https://www1.ietf.org/mailman/listinfo/entmib _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ 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 Wed Feb 4 10:06:59 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 JAA06653 for ; Wed, 4 Feb 2004 09:15:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoNny-0007oZ-Jf; Wed, 04 Feb 2004 09:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoNnD-0007n1-Ea for entmib@optimus.ietf.org; Wed, 04 Feb 2004 09:14:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06523 for ; Wed, 4 Feb 2004 09:14:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoNnB-0000Xl-00 for entmib@ietf.org; Wed, 04 Feb 2004 09:14:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoNmJ-0000Ps-00 for entmib@ietf.org; Wed, 04 Feb 2004 09:13:19 -0500 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoNlJ-0000DN-00 for entmib@ietf.org; Wed, 04 Feb 2004 09:12:17 -0500 Received: from shannon.research.telcordia.com (shannon-83.research.telcordia.com [128.96.83.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id i14EBkai028335 for ; Wed, 4 Feb 2004 09:11:46 -0500 (EST) 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 JAA06390 for ; Wed, 4 Feb 2004 09:11:46 -0500 (EST) Message-Id: <4.3.2.7.2.20040204090420.02f9f198@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Feb 2004 09:11:42 -0500 To: entmib@ietf.org From: Kaj Tesink Subject: Re: [Entmib] Meeting in Korea? In-Reply-To: <5.1.0.14.2.20040203115830.03bdd5d0@ms101.mail1.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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=0.0 required=5.0 tests=none 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: , At 12:05 PM 2/3/2004 -0500, Margaret Wasserman wrote: >Hi All, > >Do you think that we should schedule an Entity MIB meeting >in Korea? > >The Entity MIB and our Entity MIB implementation reports >are now in the hands of the IESG. > >The Entity State MIB is in a second WG Last Call, and we >don't yet have any negative review comments. If we >receive Last Call comments, I hope that we can resolve >them and send this document to the IESG before Korea. > >So, I don't think that we will have any work to do at >the next IETF meeting. What do others think? as you recall i still owe the list a draft I-D with the supplemental objects we discussed before. apologies for the delay; i'll post asap. i personally dont think that those few objects merit the scheduling of a meeting given previous discussion on the topic. as far as closing down the wg i'd appreciate some delay to accommodate this supplemental work. kaj >At this point, I personally think that the WG should >finish up these two work items (Entity MIB to DS and >Entity State MIB to PS), declare victory, and shut down. >What do others think about that plan? > >Margaret > > >_______________________________________________ >Entmib mailing list >Entmib@ietf.org >https://www1.ietf.org/mailman/listinfo/entmib _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ 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 Thu Feb 5 15:22:30 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 PAA04163 for ; Thu, 5 Feb 2004 15:22:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoq0f-00050e-01; Thu, 05 Feb 2004 15:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoq00-0004hc-I5 for entmib@optimus.ietf.org; Thu, 05 Feb 2004 15:21:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03966 for ; Thu, 5 Feb 2004 15:21:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aopzz-00023M-00 for entmib@ietf.org; Thu, 05 Feb 2004 15:21:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aopz5-0001x9-00 for entmib@ietf.org; Thu, 05 Feb 2004 15:20:25 -0500 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aopyk-0001qs-00 for entmib@ietf.org; Thu, 05 Feb 2004 15:20:02 -0500 Received: from shannon.research.telcordia.com (shannon-83.research.telcordia.com [128.96.83.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id i15KJRai022030 for ; Thu, 5 Feb 2004 15:19:27 -0500 (EST) 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 PAA17861 for ; Thu, 5 Feb 2004 15:19:26 -0500 (EST) Message-Id: <4.3.2.7.2.20040205145753.016bbca8@128.96.81.11> 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 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_1978861402==_" 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=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Entmib] Re: Entity mib support for tcif 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: , --=====================_1978861402==_ Content-Type: text/plain; charset="us-ascii"; format=flowed 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 --=====================_1978861402==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-entity-supplmib-00.txt" Entity MIB Working Group Kaj Tesink INTERNET DRAFT Telcordia Technologies February 1, 2004 Definitions of Supplemental Entity Managed Objects Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it describes additional objects that supplement those defined in the Definitions of Managed Objects for the Entity MIB document [RFCzzzz]. Expires 08/01/2004 Entity Supplemental Objects [Page 1] Internet Draft 02/01/2004 Table of Contents 1 Conventions ............................................... 3 2 The Internet-Standard Management Framework ................ 3 3 Overview .................................................. 3 3.1 entSupplPhysicalManufacturingDate ....................... 3 3.2 entSupplPhysicalInfo .................................... 3 4 Object Definitions ........................................ 5 5 Intellectual Property ..................................... 9 6 Acknowledgments ........................................... 10 7 Security Considerations ................................... 11 8 References ................................................ 12 8.1 Normative References .................................... 12 8.2 Informative References .................................. 12 9 Author's Address .......................................... 12 Full Copyright Statement ................................... 13 Expires 08/01/2004 Entity Supplemental Objects [Page 2] Internet Draft 02/01/2004 1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL", when they appear in this document, are to be interpreted as described in RFC 2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Overview The objects defined in this memo are used in conjunction with objects defined in the Entity MIB [RFCzzzz]. The MIB module defined in this memo is a sparse augmentation of the entPhysicalTable of the ENTITY- MIB -- i.e., it is REQUIRED that an agent implementing objects defined in this memo also implement the relevant ENTITY-MIB objects. The purpose of the augmentation of the entPhysicalTable is to define a managed object for the manufacturing date of a managed entity, and a managed object to support additional information related to the managed entity. 3.1. entSupplPhysicalManufacturingDate This object contains the date of manufacturing of the managed entity. If the manufacturing date is unknown or not supported the object is not instantiated. 3.2. entSupplPhysicalInfo This object provides additional information about the managed entity. For example, this object may be used to encode a CLEI (Common Language Equipment Identifier) Code [T1.213][T1.213a] for the managed physical entity by setting the prefix to the OID cleiCode, and by embedding the 10 octet CLEI code as the 10 subsequent components of Expires 08/01/2004 Entity Supplemental Objects [Page 3] Internet Draft 02/01/2004 the suffix, i.e., cleiCode.A.B.C.D.E.F.G.H.I.J. If no additional information is known or supported about the managed entity the object is not instantiated. Expires 08/01/2004 Entity Supplemental Objects [Page 4] Internet Draft 02/01/2004 4. Object Definitions ENTSUPPL-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, transmission FROM SNMPv2-SMI DateAndTime FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF entPhysicalIndex FROM ENTITY-MIB; entitySupplMIB MODULE-IDENTITY LAST-UPDATED "200402010000Z" -- February 1, 2004 ORGANIZATION "IETF Entity MIB Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/entmib-charter.html Mailing Lists: General Discussion: entmib@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/entmib Chair: Margaret Wasserman Postal: Tel: E-mail: margaret@thingmagic.com Author: Kaj Tesink Postal: 331 Newman Springs Road Red Bank, NJ 07701 USA Tel: +1 732-758-5254 E-mail: kaj@research.telcordia.com" Expires 08/01/2004 Entity Supplemental Objects [Page 5] Internet Draft 02/01/2004 DESCRIPTION "The objects in this MIB module are used in conjunction with objects in the ENTITY-MIB to manage entities Copyright (C) The Internet Society (2004). This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." -- RFC Ed.: replace yyyy with actual RFC number & remove this notice REVISION "200402010000Z " -- February 1, 2004 DESCRIPTION "Initial version, published as RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this notice ::= { transmission XXX } -- RFC Ed.: replace XXX with IANA-assigned number & remove this notice Expires 08/01/2004 Entity Supplemental Objects [Page 6] Internet Draft 02/01/2004 -- The main sections of the module entitySupplObjects OBJECT IDENTIFIER ::= { entitySupplMIB 1 } entitySupplConformance OBJECT IDENTIFIER ::= { entitySupplMIB 2 } -- These objects provide extensions to the entPhysicalTable. entSupplPhysicalTable OBJECT-TYPE SYNTAX SEQUENCE OF EntSupplPhysicalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table for supplementary objects to the entPhysicalTable." ::= { entitySupplObjects 1 } entSupplPhysicalEntry OBJECT-TYPE SYNTAX EntSupplPhysicalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the entSupplPhysicalTable. For each instance of this object there MUST be a corresponding instance of entPhysicalEntry." INDEX { entPhysicalIndex } ::= { entSupplPhysicalTable 1 } EntSupplPhysicalEntry ::= SEQUENCE { entSupplPhysicalManufacturingDate DateAndTime, entSupplPhysicalInfo OCTET STRING } entSupplPhysicalManufacturingDate OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The manufacturing date for the physical entity." ::= { entSupplPhysicalEntry 1 } entSupplPhysicalInfo OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write Expires 08/01/2004 Entity Supplemental Objects [Page 7] Internet Draft 02/01/2004 STATUS current DESCRIPTION "This object contains additional information about the entity. The encoding of this object is prefix.suffix where prefix represents an OID that identifies the use of the suffix, and suffix is encoded as defined for that prefix." ::= { entSupplPhysicalEntry 2 } cleiCode OBJECT-IDENTITY STATUS current DESCRIPTION "Object identity for CLEI (Common Language Equipment Identifier) Code." REFERENCE "TCIF-02-004, Guideline for data elements included in the Management Information Base, Telecommunications Industry Forum (TCIF), 09/11/2002. ANSI T1.213, Coded identification of equipment entities of the North American telecommunications system for information exchange, ANSI. ANSI T1.213a, Supplement to T1.213, 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." ::= { entitySupplObjects 2 } -- -- Conformance Statements -- entitySupplGroups OBJECT IDENTIFIER ::= { entitySupplConformance 1 } entitySupplCompliances OBJECT IDENTIFIER ::= { entitySupplConformance 2 } -- Object Groups entitySupplPhysicalGroup OBJECT-GROUP OBJECTS { Expires 08/01/2004 Entity Supplemental Objects [Page 8] Internet Draft 02/01/2004 entSupplPhysicalManufacturingDate, entSupplPhysicalInfo } STATUS current DESCRIPTION "A collection of supplemental objects for to support physical entity features." ::= { entitySupplGroups 1 } -- Compliance Statements entitySupplCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that support this module. Compliance with the entity3Compliance statement of the ENTITY-MIB is prerequisite." MODULE -- this module MANDATORY-GROUPS { entitySupplPhysicalGroup } OBJECT entSupplPhysicalInfo MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { entitySupplCompliances 1 } END 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. Expires 08/01/2004 Entity Supplemental Objects [Page 9] Internet Draft 02/01/2004 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 6. Acknowledgments This document is a product of the Entity MIB Working Group. Expires 08/01/2004 Entity Supplemental Objects [Page 10] Internet Draft 02/01/2004 7. Security Considerations entSupplPhysicalInfo defined in this MIB module has a MAX-ACCESS clause of read-write; erroreous or unauthorized Writing of this object will result in the provision of misleading information to network management systems. The user of this MIB module must therefore be aware that support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The readable objects in this MIB module (i.e., those with MAX-ACCESS other than not-accessible) may be considered sensitive in some environments since, collectively, they provide information about the managed entities and can reveal some aspects of their configuration. In such environments it is important to control even GET and NOTIFY access to these objects and possibly even to encrypt their values when sending them over the network via SNMP. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Expires 08/01/2004 Entity Supplemental Objects [Page 11] Internet Draft 02/01/2004 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFCzzzz] Bierman, A., McCloghrie, K., "Entity MIB (Version 3)", RFCzzzz. 8.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [T1.213] ANSI T1.213, Coded identification of equipment entities of the North American telecommunications system for information exchange, ANSI. [T1.213a] ANSI T1.213a, Supplement to T1.213, 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." 9. Author's Address Kaj Tesink 331 Newman Springs Road Red Bank, NJ 07701 USA Phone: +1 732 758-5254 EMail: kaj@research.telcordia.com Expires 08/01/2004 Entity Supplemental Objects [Page 12] Internet Draft 02/01/2004 Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires 08/01/2004 Entity Supplemental Objects [Page 13] Internet Draft 02/01/2004 ************************************************************ * NOTES TO RFC Editor (to be removed prior to publication) * * * * 1.) The normative references [RFCzzzz] * * must be updated to point to the appropriate * * RFC when the corresponding Internet Draft is published, * * and all occurrences of the reference tags must be * * changed. * * * * 2.) Please replace all occurrences of "yyyy" in the * * DESCRIPTION clause of the MODULE-IDENTITY invocation * * in Section 4 with the RFC number assigned to this * * specification and remove the accompanying notes. * * * * 3.) Please replace "XXX" in the MODULE-IDENTITY value * * with an IANA-assigned value under the 'transmission' * * subtree and remove the accompanying note. * * * ************************************************************ Expires 08/01/2004 Entity Supplemental Objects [Page 14] --=====================_1978861402==_ Content-Type: text/plain; charset="us-ascii"; format=flowed _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ 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 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ --=====================_1978861402==_-- _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu Feb 5 15:22:35 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 PAA04180 for ; Thu, 5 Feb 2004 15:22:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoq0f-00052u-P2 for entmib-archive@odin.ietf.org; Thu, 05 Feb 2004 15:22:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15KM1Zg019390 for entmib-archive@odin.ietf.org; Thu, 5 Feb 2004 15:22:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoq0f-00050e-01; Thu, 05 Feb 2004 15:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoq00-0004hc-I5 for entmib@optimus.ietf.org; Thu, 05 Feb 2004 15:21:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03966 for ; Thu, 5 Feb 2004 15:21:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aopzz-00023M-00 for entmib@ietf.org; Thu, 05 Feb 2004 15:21:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aopz5-0001x9-00 for entmib@ietf.org; Thu, 05 Feb 2004 15:20:25 -0500 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aopyk-0001qs-00 for entmib@ietf.org; Thu, 05 Feb 2004 15:20:02 -0500 Received: from shannon.research.telcordia.com (shannon-83.research.telcordia.com [128.96.83.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id i15KJRai022030 for ; Thu, 5 Feb 2004 15:19:27 -0500 (EST) 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 PAA17861 for ; Thu, 5 Feb 2004 15:19:26 -0500 (EST) Message-Id: <4.3.2.7.2.20040205145753.016bbca8@128.96.81.11> 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 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_1978861402==_" 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=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Entmib] Re: Entity mib support for tcif 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: , --=====================_1978861402==_ Content-Type: text/plain; charset="us-ascii"; format=flowed 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 --=====================_1978861402==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-entity-supplmib-00.txt" Entity MIB Working Group Kaj Tesink INTERNET DRAFT Telcordia Technologies February 1, 2004 Definitions of Supplemental Entity Managed Objects Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it describes additional objects that supplement those defined in the Definitions of Managed Objects for the Entity MIB document [RFCzzzz]. Expires 08/01/2004 Entity Supplemental Objects [Page 1] Internet Draft 02/01/2004 Table of Contents 1 Conventions ............................................... 3 2 The Internet-Standard Management Framework ................ 3 3 Overview .................................................. 3 3.1 entSupplPhysicalManufacturingDate ....................... 3 3.2 entSupplPhysicalInfo .................................... 3 4 Object Definitions ........................................ 5 5 Intellectual Property ..................................... 9 6 Acknowledgments ........................................... 10 7 Security Considerations ................................... 11 8 References ................................................ 12 8.1 Normative References .................................... 12 8.2 Informative References .................................. 12 9 Author's Address .......................................... 12 Full Copyright Statement ................................... 13 Expires 08/01/2004 Entity Supplemental Objects [Page 2] Internet Draft 02/01/2004 1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL", when they appear in this document, are to be interpreted as described in RFC 2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Overview The objects defined in this memo are used in conjunction with objects defined in the Entity MIB [RFCzzzz]. The MIB module defined in this memo is a sparse augmentation of the entPhysicalTable of the ENTITY- MIB -- i.e., it is REQUIRED that an agent implementing objects defined in this memo also implement the relevant ENTITY-MIB objects. The purpose of the augmentation of the entPhysicalTable is to define a managed object for the manufacturing date of a managed entity, and a managed object to support additional information related to the managed entity. 3.1. entSupplPhysicalManufacturingDate This object contains the date of manufacturing of the managed entity. If the manufacturing date is unknown or not supported the object is not instantiated. 3.2. entSupplPhysicalInfo This object provides additional information about the managed entity. For example, this object may be used to encode a CLEI (Common Language Equipment Identifier) Code [T1.213][T1.213a] for the managed physical entity by setting the prefix to the OID cleiCode, and by embedding the 10 octet CLEI code as the 10 subsequent components of Expires 08/01/2004 Entity Supplemental Objects [Page 3] Internet Draft 02/01/2004 the suffix, i.e., cleiCode.A.B.C.D.E.F.G.H.I.J. If no additional information is known or supported about the managed entity the object is not instantiated. Expires 08/01/2004 Entity Supplemental Objects [Page 4] Internet Draft 02/01/2004 4. Object Definitions ENTSUPPL-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, transmission FROM SNMPv2-SMI DateAndTime FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF entPhysicalIndex FROM ENTITY-MIB; entitySupplMIB MODULE-IDENTITY LAST-UPDATED "200402010000Z" -- February 1, 2004 ORGANIZATION "IETF Entity MIB Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/entmib-charter.html Mailing Lists: General Discussion: entmib@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/entmib Chair: Margaret Wasserman Postal: Tel: E-mail: margaret@thingmagic.com Author: Kaj Tesink Postal: 331 Newman Springs Road Red Bank, NJ 07701 USA Tel: +1 732-758-5254 E-mail: kaj@research.telcordia.com" Expires 08/01/2004 Entity Supplemental Objects [Page 5] Internet Draft 02/01/2004 DESCRIPTION "The objects in this MIB module are used in conjunction with objects in the ENTITY-MIB to manage entities Copyright (C) The Internet Society (2004). This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." -- RFC Ed.: replace yyyy with actual RFC number & remove this notice REVISION "200402010000Z " -- February 1, 2004 DESCRIPTION "Initial version, published as RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this notice ::= { transmission XXX } -- RFC Ed.: replace XXX with IANA-assigned number & remove this notice Expires 08/01/2004 Entity Supplemental Objects [Page 6] Internet Draft 02/01/2004 -- The main sections of the module entitySupplObjects OBJECT IDENTIFIER ::= { entitySupplMIB 1 } entitySupplConformance OBJECT IDENTIFIER ::= { entitySupplMIB 2 } -- These objects provide extensions to the entPhysicalTable. entSupplPhysicalTable OBJECT-TYPE SYNTAX SEQUENCE OF EntSupplPhysicalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table for supplementary objects to the entPhysicalTable." ::= { entitySupplObjects 1 } entSupplPhysicalEntry OBJECT-TYPE SYNTAX EntSupplPhysicalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the entSupplPhysicalTable. For each instance of this object there MUST be a corresponding instance of entPhysicalEntry." INDEX { entPhysicalIndex } ::= { entSupplPhysicalTable 1 } EntSupplPhysicalEntry ::= SEQUENCE { entSupplPhysicalManufacturingDate DateAndTime, entSupplPhysicalInfo OCTET STRING } entSupplPhysicalManufacturingDate OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The manufacturing date for the physical entity." ::= { entSupplPhysicalEntry 1 } entSupplPhysicalInfo OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write Expires 08/01/2004 Entity Supplemental Objects [Page 7] Internet Draft 02/01/2004 STATUS current DESCRIPTION "This object contains additional information about the entity. The encoding of this object is prefix.suffix where prefix represents an OID that identifies the use of the suffix, and suffix is encoded as defined for that prefix." ::= { entSupplPhysicalEntry 2 } cleiCode OBJECT-IDENTITY STATUS current DESCRIPTION "Object identity for CLEI (Common Language Equipment Identifier) Code." REFERENCE "TCIF-02-004, Guideline for data elements included in the Management Information Base, Telecommunications Industry Forum (TCIF), 09/11/2002. ANSI T1.213, Coded identification of equipment entities of the North American telecommunications system for information exchange, ANSI. ANSI T1.213a, Supplement to T1.213, 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." ::= { entitySupplObjects 2 } -- -- Conformance Statements -- entitySupplGroups OBJECT IDENTIFIER ::= { entitySupplConformance 1 } entitySupplCompliances OBJECT IDENTIFIER ::= { entitySupplConformance 2 } -- Object Groups entitySupplPhysicalGroup OBJECT-GROUP OBJECTS { Expires 08/01/2004 Entity Supplemental Objects [Page 8] Internet Draft 02/01/2004 entSupplPhysicalManufacturingDate, entSupplPhysicalInfo } STATUS current DESCRIPTION "A collection of supplemental objects for to support physical entity features." ::= { entitySupplGroups 1 } -- Compliance Statements entitySupplCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that support this module. Compliance with the entity3Compliance statement of the ENTITY-MIB is prerequisite." MODULE -- this module MANDATORY-GROUPS { entitySupplPhysicalGroup } OBJECT entSupplPhysicalInfo MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { entitySupplCompliances 1 } END 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. Expires 08/01/2004 Entity Supplemental Objects [Page 9] Internet Draft 02/01/2004 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 6. Acknowledgments This document is a product of the Entity MIB Working Group. Expires 08/01/2004 Entity Supplemental Objects [Page 10] Internet Draft 02/01/2004 7. Security Considerations entSupplPhysicalInfo defined in this MIB module has a MAX-ACCESS clause of read-write; erroreous or unauthorized Writing of this object will result in the provision of misleading information to network management systems. The user of this MIB module must therefore be aware that support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The readable objects in this MIB module (i.e., those with MAX-ACCESS other than not-accessible) may be considered sensitive in some environments since, collectively, they provide information about the managed entities and can reveal some aspects of their configuration. In such environments it is important to control even GET and NOTIFY access to these objects and possibly even to encrypt their values when sending them over the network via SNMP. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Expires 08/01/2004 Entity Supplemental Objects [Page 11] Internet Draft 02/01/2004 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFCzzzz] Bierman, A., McCloghrie, K., "Entity MIB (Version 3)", RFCzzzz. 8.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [T1.213] ANSI T1.213, Coded identification of equipment entities of the North American telecommunications system for information exchange, ANSI. [T1.213a] ANSI T1.213a, Supplement to T1.213, 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." 9. Author's Address Kaj Tesink 331 Newman Springs Road Red Bank, NJ 07701 USA Phone: +1 732 758-5254 EMail: kaj@research.telcordia.com Expires 08/01/2004 Entity Supplemental Objects [Page 12] Internet Draft 02/01/2004 Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires 08/01/2004 Entity Supplemental Objects [Page 13] Internet Draft 02/01/2004 ************************************************************ * NOTES TO RFC Editor (to be removed prior to publication) * * * * 1.) The normative references [RFCzzzz] * * must be updated to point to the appropriate * * RFC when the corresponding Internet Draft is published, * * and all occurrences of the reference tags must be * * changed. * * * * 2.) Please replace all occurrences of "yyyy" in the * * DESCRIPTION clause of the MODULE-IDENTITY invocation * * in Section 4 with the RFC number assigned to this * * specification and remove the accompanying notes. * * * * 3.) Please replace "XXX" in the MODULE-IDENTITY value * * with an IANA-assigned value under the 'transmission' * * subtree and remove the accompanying note. * * * ************************************************************ Expires 08/01/2004 Entity Supplemental Objects [Page 14] --=====================_1978861402==_ Content-Type: text/plain; charset="us-ascii"; format=flowed _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ 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 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ --=====================_1978861402==_-- _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Thu Feb 5 16:17:30 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 QAA09341 for ; Thu, 5 Feb 2004 16:17:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoqrs-0000XV-Rv; Thu, 05 Feb 2004 16:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoqr5-0000Sg-7O for entmib@optimus.ietf.org; Thu, 05 Feb 2004 16:16:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09229 for ; Thu, 5 Feb 2004 16:16:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoqr3-0001rU-00 for entmib@ietf.org; Thu, 05 Feb 2004 16:16:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoqqA-0001fM-00 for entmib@ietf.org; Thu, 05 Feb 2004 16:15:15 -0500 Received: from smtp.exodus.net ([66.35.230.237] helo=smtp02-w.exodus.net) by ietf-mx with esmtp (Exim 4.12) id 1Aoqop-0001Gn-00 for entmib@ietf.org; Thu, 05 Feb 2004 16:13:51 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp02-w.exodus.net (8.12.8/8.12.8) with ESMTP id i15IN3Ev013598 for ; Thu, 5 Feb 2004 12:23:03 -0600 Received: from ala-mrwtemp.thingmagic.com (unverified [66.228.91.169]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id for ; Thu, 5 Feb 2004 13:13:21 -0800 Message-Id: <5.1.0.14.2.20040205160724.03d1d870@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 05 Feb 2004 16:11:40 -0500 To: entmib@ietf.org From: Margaret Wasserman Subject: REMINDER: [Entmib] WG Last Call: Entity State MIB Mime-Version: 1.0 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 All, Just a reminder that we are currently in WG Last Call for the Entity State MIB. Please review this document before Friday and send your feedback (positive or negative) to the list. Given that this is a second WG Last Call for this document, that several people reviewed it during the previous WG Last Call, and that Sharon did a great job of maintaining an issue list and documenting the resolution of each issue, I am planning to interpret silence as agreement to send this document to the IESG. So, if you have any objection to submitting this document for publication as a Proposed Standard, please make that clear by Friday. Thanks, Margaret >Date: Fri, 23 Jan 2004 17:00:59 -0500 >To: Entmib@ietf.org >From: Margaret Wasserman > >Hi All, > >This is a two week WG Last Call for submitting the Entity State >MIB to the IESG for publication as a Proposed Standard. The latest >version of this document can be found at: > >http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-02.txt > >This WG Last Call will end on Friday, February 6th at 5pm EST. > >Please review the document and forward substantive comments to >the mailing list. Editorial comments can be sent directly >to the authors. > >Thanks, >Margaret > > > >_______________________________________________ >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 Thu Feb 5 17:07:25 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 QAA09343 for ; Thu, 5 Feb 2004 16:17:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoqrt-0000Xz-7Z for entmib-archive@odin.ietf.org; Thu, 05 Feb 2004 16:17:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15LH1f8002091 for entmib-archive@odin.ietf.org; Thu, 5 Feb 2004 16:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoqrs-0000XV-Rv; Thu, 05 Feb 2004 16:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoqr5-0000Sg-7O for entmib@optimus.ietf.org; Thu, 05 Feb 2004 16:16:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09229 for ; Thu, 5 Feb 2004 16:16:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoqr3-0001rU-00 for entmib@ietf.org; Thu, 05 Feb 2004 16:16:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoqqA-0001fM-00 for entmib@ietf.org; Thu, 05 Feb 2004 16:15:15 -0500 Received: from smtp.exodus.net ([66.35.230.237] helo=smtp02-w.exodus.net) by ietf-mx with esmtp (Exim 4.12) id 1Aoqop-0001Gn-00 for entmib@ietf.org; Thu, 05 Feb 2004 16:13:51 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp02-w.exodus.net (8.12.8/8.12.8) with ESMTP id i15IN3Ev013598 for ; Thu, 5 Feb 2004 12:23:03 -0600 Received: from ala-mrwtemp.thingmagic.com (unverified [66.228.91.169]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id for ; Thu, 5 Feb 2004 13:13:21 -0800 Message-Id: <5.1.0.14.2.20040205160724.03d1d870@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 05 Feb 2004 16:11:40 -0500 To: entmib@ietf.org From: Margaret Wasserman Subject: REMINDER: [Entmib] WG Last Call: Entity State MIB Mime-Version: 1.0 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 All, Just a reminder that we are currently in WG Last Call for the Entity State MIB. Please review this document before Friday and send your feedback (positive or negative) to the list. Given that this is a second WG Last Call for this document, that several people reviewed it during the previous WG Last Call, and that Sharon did a great job of maintaining an issue list and documenting the resolution of each issue, I am planning to interpret silence as agreement to send this document to the IESG. So, if you have any objection to submitting this document for publication as a Proposed Standard, please make that clear by Friday. Thanks, Margaret >Date: Fri, 23 Jan 2004 17:00:59 -0500 >To: Entmib@ietf.org >From: Margaret Wasserman > >Hi All, > >This is a two week WG Last Call for submitting the Entity State >MIB to the IESG for publication as a Proposed Standard. The latest >version of this document can be found at: > >http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-02.txt > >This WG Last Call will end on Friday, February 6th at 5pm EST. > >Please review the document and forward substantive comments to >the mailing list. Editorial comments can be sent directly >to the authors. > >Thanks, >Margaret > > > >_______________________________________________ >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 Fri Feb 6 05:09:30 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 FAA18718 for ; Fri, 6 Feb 2004 05:09:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2uz-0005kg-GX; Fri, 06 Feb 2004 05:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2ub-0005hn-4y for entmib@optimus.ietf.org; Fri, 06 Feb 2004 05:08:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18711 for ; Fri, 6 Feb 2004 05:08:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2uX-0000mK-00 for entmib@ietf.org; Fri, 06 Feb 2004 05:08:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap2tb-0000kJ-00 for entmib@ietf.org; Fri, 06 Feb 2004 05:07:36 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2sp-0000iH-00 for entmib@ietf.org; Fri, 06 Feb 2004 05:06:47 -0500 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 i16A39fi015046 for ; Fri, 6 Feb 2004 05:03:10 -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 i16A35fi014975 for ; Fri, 6 Feb 2004 05:03:06 -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: REMINDER: [Entmib] WG Last Call: Entity State MIB Date: Fri, 6 Feb 2004 12:06:43 +0200 Message-ID: Thread-Topic: REMINDER: [Entmib] WG Last Call: Entity State MIB Thread-Index: AcPsLcknIZ31QA8LQl+ufOWcNPLv6AAavR3g From: "Romascanu, Dan (Dan)" To: "Margaret Wasserman" , 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 I have no objections to submitting this document for publication as a = Proposed Standard.=20 Thanks to Sharon for the effort in pushing this ahead. Regards, Dan > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On=20 > Behalf Of Margaret Wasserman > Sent: 05 February, 2004 11:12 PM > To: entmib@ietf.org > Subject: REMINDER: [Entmib] WG Last Call: Entity State MIB >=20 >=20 >=20 > Hi All, >=20 > Just a reminder that we are currently in WG Last Call for the > Entity State MIB. Please review this document before Friday > and send your feedback (positive or negative) to the list. >=20 > Given that this is a second WG Last Call for this document, that > several people reviewed it during the previous WG Last Call, and > that Sharon did a great job of maintaining an issue list and > documenting the resolution of each issue, I am planning to interpret > silence as agreement to send this document to the IESG. >=20 > So, if you have any objection to submitting this document for > publication as a Proposed Standard, please make that clear > by Friday. >=20 > Thanks, > Margaret >=20 >=20 > >Date: Fri, 23 Jan 2004 17:00:59 -0500 > >To: Entmib@ietf.org > >From: Margaret Wasserman > > > >Hi All, > > > >This is a two week WG Last Call for submitting the Entity State > >MIB to the IESG for publication as a Proposed Standard. The latest > >version of this document can be found at: > > > >http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-02.txt > > > >This WG Last Call will end on Friday, February 6th at 5pm EST. > > > >Please review the document and forward substantive comments to > >the mailing list. Editorial comments can be sent directly > >to the authors. > > > >Thanks, > >Margaret > > > > > > > >_______________________________________________ > >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 Fri Feb 6 05:09:31 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 FAA18734 for ; Fri, 6 Feb 2004 05:09:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2v1-0005lk-T8 for entmib-archive@odin.ietf.org; Fri, 06 Feb 2004 05:09:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16A93WP022136 for entmib-archive@odin.ietf.org; Fri, 6 Feb 2004 05:09:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2uz-0005kg-GX; Fri, 06 Feb 2004 05:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap2ub-0005hn-4y for entmib@optimus.ietf.org; Fri, 06 Feb 2004 05:08:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18711 for ; Fri, 6 Feb 2004 05:08:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2uX-0000mK-00 for entmib@ietf.org; Fri, 06 Feb 2004 05:08:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap2tb-0000kJ-00 for entmib@ietf.org; Fri, 06 Feb 2004 05:07:36 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1Ap2sp-0000iH-00 for entmib@ietf.org; Fri, 06 Feb 2004 05:06:47 -0500 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 i16A39fi015046 for ; Fri, 6 Feb 2004 05:03:10 -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 i16A35fi014975 for ; Fri, 6 Feb 2004 05:03:06 -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: REMINDER: [Entmib] WG Last Call: Entity State MIB Date: Fri, 6 Feb 2004 12:06:43 +0200 Message-ID: Thread-Topic: REMINDER: [Entmib] WG Last Call: Entity State MIB Thread-Index: AcPsLcknIZ31QA8LQl+ufOWcNPLv6AAavR3g From: "Romascanu, Dan (Dan)" To: "Margaret Wasserman" , 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 I have no objections to submitting this document for publication as a = Proposed Standard.=20 Thanks to Sharon for the effort in pushing this ahead. Regards, Dan > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On=20 > Behalf Of Margaret Wasserman > Sent: 05 February, 2004 11:12 PM > To: entmib@ietf.org > Subject: REMINDER: [Entmib] WG Last Call: Entity State MIB >=20 >=20 >=20 > Hi All, >=20 > Just a reminder that we are currently in WG Last Call for the > Entity State MIB. Please review this document before Friday > and send your feedback (positive or negative) to the list. >=20 > Given that this is a second WG Last Call for this document, that > several people reviewed it during the previous WG Last Call, and > that Sharon did a great job of maintaining an issue list and > documenting the resolution of each issue, I am planning to interpret > silence as agreement to send this document to the IESG. >=20 > So, if you have any objection to submitting this document for > publication as a Proposed Standard, please make that clear > by Friday. >=20 > Thanks, > Margaret >=20 >=20 > >Date: Fri, 23 Jan 2004 17:00:59 -0500 > >To: Entmib@ietf.org > >From: Margaret Wasserman > > > >Hi All, > > > >This is a two week WG Last Call for submitting the Entity State > >MIB to the IESG for publication as a Proposed Standard. The latest > >version of this document can be found at: > > > >http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-02.txt > > > >This WG Last Call will end on Friday, February 6th at 5pm EST. > > > >Please review the document and forward substantive comments to > >the mailing list. Editorial comments can be sent directly > >to the authors. > > > >Thanks, > >Margaret > > > > > > > >_______________________________________________ > >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 entmib-admin@ietf.org Fri Feb 6 06:33: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 GAA21275 for ; Fri, 6 Feb 2004 06:33:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap4EH-0004BV-J5; Fri, 06 Feb 2004 06:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap4Dy-00049B-My for entmib@optimus.ietf.org; Fri, 06 Feb 2004 06:32:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21266 for ; Fri, 6 Feb 2004 06:32:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap4Du-0005IB-00 for entmib@ietf.org; Fri, 06 Feb 2004 06:32:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap4Cz-0005Fr-00 for entmib@ietf.org; Fri, 06 Feb 2004 06:31:42 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Ap4Ch-0005D3-00 for entmib@ietf.org; Fri, 06 Feb 2004 06:31:23 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i16BUkn15727 for ; Fri, 6 Feb 2004 05:30:47 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 6 Feb 2004 12:30:45 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC525@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Margaret Wasserman'" , entmib@ietf.org Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB Date: Fri, 6 Feb 2004 12:30:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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: , > Given that this is a second WG Last Call for this document, that > several people reviewed it during the previous WG Last Call, and > that Sharon did a great job of maintaining an issue list and > documenting the resolution of each issue, I am planning to interpret > silence as agreement to send this document to the IESG. > I do not want to step on the toes of our WG chair, but yet... I would actually appreciate if the people who spoke up (a while ago) that the MIB was too complex, that they do state if they are now OK with this version! PLEASE PARTICIPATE and express your opinion. Bert > So, if you have any objection to submitting this document for > publication as a Proposed Standard, please make that clear > by Friday. > > Thanks, > Margaret > > > >Date: Fri, 23 Jan 2004 17:00:59 -0500 > >To: Entmib@ietf.org > >From: Margaret Wasserman > > > >Hi All, > > > >This is a two week WG Last Call for submitting the Entity State > >MIB to the IESG for publication as a Proposed Standard. The latest > >version of this document can be found at: > > > >http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-02.txt > > > >This WG Last Call will end on Friday, February 6th at 5pm EST. > > > >Please review the document and forward substantive comments to > >the mailing list. Editorial comments can be sent directly > >to the authors. > > > >Thanks, > >Margaret > > > > > > > >_______________________________________________ > >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 Fri Feb 6 06:33: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 GAA21277 for ; Fri, 6 Feb 2004 06:33:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap4EI-0004Bo-9q for entmib-archive@odin.ietf.org; Fri, 06 Feb 2004 06:33:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16BX2Q1016101 for entmib-archive@odin.ietf.org; Fri, 6 Feb 2004 06:33:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap4EH-0004BV-J5; Fri, 06 Feb 2004 06:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap4Dy-00049B-My for entmib@optimus.ietf.org; Fri, 06 Feb 2004 06:32:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21266 for ; Fri, 6 Feb 2004 06:32:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap4Du-0005IB-00 for entmib@ietf.org; Fri, 06 Feb 2004 06:32:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap4Cz-0005Fr-00 for entmib@ietf.org; Fri, 06 Feb 2004 06:31:42 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Ap4Ch-0005D3-00 for entmib@ietf.org; Fri, 06 Feb 2004 06:31:23 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i16BUkn15727 for ; Fri, 6 Feb 2004 05:30:47 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 6 Feb 2004 12:30:45 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC525@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Margaret Wasserman'" , entmib@ietf.org Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB Date: Fri, 6 Feb 2004 12:30:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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: , > Given that this is a second WG Last Call for this document, that > several people reviewed it during the previous WG Last Call, and > that Sharon did a great job of maintaining an issue list and > documenting the resolution of each issue, I am planning to interpret > silence as agreement to send this document to the IESG. > I do not want to step on the toes of our WG chair, but yet... I would actually appreciate if the people who spoke up (a while ago) that the MIB was too complex, that they do state if they are now OK with this version! PLEASE PARTICIPATE and express your opinion. Bert > So, if you have any objection to submitting this document for > publication as a Proposed Standard, please make that clear > by Friday. > > Thanks, > Margaret > > > >Date: Fri, 23 Jan 2004 17:00:59 -0500 > >To: Entmib@ietf.org > >From: Margaret Wasserman > > > >Hi All, > > > >This is a two week WG Last Call for submitting the Entity State > >MIB to the IESG for publication as a Proposed Standard. The latest > >version of this document can be found at: > > > >http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-02.txt > > > >This WG Last Call will end on Friday, February 6th at 5pm EST. > > > >Please review the document and forward substantive comments to > >the mailing list. Editorial comments can be sent directly > >to the authors. > > > >Thanks, > >Margaret > > > > > > > >_______________________________________________ > >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 Fri Feb 6 11:32:29 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 LAA03417 for ; Fri, 6 Feb 2004 11:32:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap8td-0008CH-Qg; Fri, 06 Feb 2004 11:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap8tc-0008Bo-Bu for entmib@optimus.ietf.org; Fri, 06 Feb 2004 11:32:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03410 for ; Fri, 6 Feb 2004 11:31:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap8tb-0000gp-00 for entmib@ietf.org; Fri, 06 Feb 2004 11:31:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap8sj-0000dD-00 for entmib@ietf.org; Fri, 06 Feb 2004 11:31:06 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Ap8sN-0000YP-00 for entmib@ietf.org; Fri, 06 Feb 2004 11:30:43 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i16GUA9T013509; Fri, 6 Feb 2004 08:30:10 -0800 (PST) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn3-390.cisco.com [10.21.65.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQR60579; Fri, 6 Feb 2004 08:30:09 -0800 (PST) Message-Id: <4.3.2.7.2.20040206080627.02cd69f0@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Feb 2004 08:27:19 -0800 To: "Wijnen, Bert (Bert)" From: Andy Bierman Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB Cc: "'Margaret Wasserman'" , entmib@ietf.org In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155028EC525@nl0006exch001u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: , At 03:30 AM 2/6/2004, Wijnen, Bert (Bert) wrote: >> Given that this is a second WG Last Call for this document, that >> several people reviewed it during the previous WG Last Call, and >> that Sharon did a great job of maintaining an issue list and >> documenting the resolution of each issue, I am planning to interpret >> silence as agreement to send this document to the IESG. >> >I do not want to step on the toes of our WG chair, but yet... >I would actually appreciate if the people who spoke up (a while ago) >that the MIB was too complex, that they do state if they are now >OK with this version! > >PLEASE PARTICIPATE and express your opinion. okay, okay... I do not approve of, or object to, the Entity State MIB going forward. My concerns are regarding the intent of the MIB -- the actual problem being addressed. So I looked to the Entmib WG charter page for guidance. This is all it says about the Entity State MIB: Done Publish state/status extensions as a WG I-D Mar 04 Submit Entity State MIB to the IESG for Proposed Standard Not a word about the problem being addressed. I thought we set out to add an 'operStatus' object for physical entities -- a simple ( green, yellow, red ) status indicator. Applications would still need to know how to use other MIBs to diagnose or correct a fault. IMO, there's not much value in a generic indicator beyond this, so it's best to keep it simple. From the draft: "Objects are defined to capture administrative, operational and usage states. In addition there are further state objects defined to provide additional information for these three basic states." The document clearly attempts to provide more functionality than a simple 'operStatus' object. The authors have done a fine job defining and documenting this functionality. In order to discuss how well a MIB addresses its intended function, we have to agree on the intended function. >Bert Andy >> So, if you have any objection to submitting this document for >> publication as a Proposed Standard, please make that clear >> by Friday. >> >> Thanks, >> Margaret >> >> >> >Date: Fri, 23 Jan 2004 17:00:59 -0500 >> >To: Entmib@ietf.org >> >From: Margaret Wasserman >> > >> >Hi All, >> > >> >This is a two week WG Last Call for submitting the Entity State >> >MIB to the IESG for publication as a Proposed Standard. The latest >> >version of this document can be found at: >> > >> >http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-02.txt >> > >> >This WG Last Call will end on Friday, February 6th at 5pm EST. >> > >> >Please review the document and forward substantive comments to >> >the mailing list. Editorial comments can be sent directly >> >to the authors. >> > >> >Thanks, >> >Margaret >> > >> > >> > >> >_______________________________________________ >> >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 Fri Feb 6 12:22:17 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 LAA03419 for ; Fri, 6 Feb 2004 11:32:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap8te-0008Ch-8l for entmib-archive@odin.ietf.org; Fri, 06 Feb 2004 11:32:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16GW286031523 for entmib-archive@odin.ietf.org; Fri, 6 Feb 2004 11:32:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap8td-0008CH-Qg; Fri, 06 Feb 2004 11:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap8tc-0008Bo-Bu for entmib@optimus.ietf.org; Fri, 06 Feb 2004 11:32:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03410 for ; Fri, 6 Feb 2004 11:31:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap8tb-0000gp-00 for entmib@ietf.org; Fri, 06 Feb 2004 11:31:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap8sj-0000dD-00 for entmib@ietf.org; Fri, 06 Feb 2004 11:31:06 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Ap8sN-0000YP-00 for entmib@ietf.org; Fri, 06 Feb 2004 11:30:43 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i16GUA9T013509; Fri, 6 Feb 2004 08:30:10 -0800 (PST) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn3-390.cisco.com [10.21.65.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQR60579; Fri, 6 Feb 2004 08:30:09 -0800 (PST) Message-Id: <4.3.2.7.2.20040206080627.02cd69f0@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Feb 2004 08:27:19 -0800 To: "Wijnen, Bert (Bert)" From: Andy Bierman Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB Cc: "'Margaret Wasserman'" , entmib@ietf.org In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155028EC525@nl0006exch001u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: , At 03:30 AM 2/6/2004, Wijnen, Bert (Bert) wrote: >> Given that this is a second WG Last Call for this document, that >> several people reviewed it during the previous WG Last Call, and >> that Sharon did a great job of maintaining an issue list and >> documenting the resolution of each issue, I am planning to interpret >> silence as agreement to send this document to the IESG. >> >I do not want to step on the toes of our WG chair, but yet... >I would actually appreciate if the people who spoke up (a while ago) >that the MIB was too complex, that they do state if they are now >OK with this version! > >PLEASE PARTICIPATE and express your opinion. okay, okay... I do not approve of, or object to, the Entity State MIB going forward. My concerns are regarding the intent of the MIB -- the actual problem being addressed. So I looked to the Entmib WG charter page for guidance. This is all it says about the Entity State MIB: Done Publish state/status extensions as a WG I-D Mar 04 Submit Entity State MIB to the IESG for Proposed Standard Not a word about the problem being addressed. I thought we set out to add an 'operStatus' object for physical entities -- a simple ( green, yellow, red ) status indicator. Applications would still need to know how to use other MIBs to diagnose or correct a fault. IMO, there's not much value in a generic indicator beyond this, so it's best to keep it simple. From the draft: "Objects are defined to capture administrative, operational and usage states. In addition there are further state objects defined to provide additional information for these three basic states." The document clearly attempts to provide more functionality than a simple 'operStatus' object. The authors have done a fine job defining and documenting this functionality. In order to discuss how well a MIB addresses its intended function, we have to agree on the intended function. >Bert Andy >> So, if you have any objection to submitting this document for >> publication as a Proposed Standard, please make that clear >> by Friday. >> >> Thanks, >> Margaret >> >> >> >Date: Fri, 23 Jan 2004 17:00:59 -0500 >> >To: Entmib@ietf.org >> >From: Margaret Wasserman >> > >> >Hi All, >> > >> >This is a two week WG Last Call for submitting the Entity State >> >MIB to the IESG for publication as a Proposed Standard. The latest >> >version of this document can be found at: >> > >> >http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-02.txt >> > >> >This WG Last Call will end on Friday, February 6th at 5pm EST. >> > >> >Please review the document and forward substantive comments to >> >the mailing list. Editorial comments can be sent directly >> >to the authors. >> > >> >Thanks, >> >Margaret >> > >> > >> > >> >_______________________________________________ >> >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 Fri Feb 6 12:31: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 MAA06327 for ; Fri, 6 Feb 2004 12:31:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9oj-00050V-SH for entmib-archive@odin.ietf.org; Fri, 06 Feb 2004 12:31:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16HV1xv019234 for entmib-archive@odin.ietf.org; Fri, 6 Feb 2004 12:31:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9oi-0004zR-Sr; Fri, 06 Feb 2004 12:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9oZ-0004yi-9R for entmib@optimus.ietf.org; Fri, 06 Feb 2004 12:30:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06306 for ; Fri, 6 Feb 2004 12:30:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap9oX-0005IA-00 for entmib@ietf.org; Fri, 06 Feb 2004 12:30:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap9nd-0005FP-00 for entmib@ietf.org; Fri, 06 Feb 2004 12:29:54 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Ap9mk-000592-00 for entmib@ietf.org; Fri, 06 Feb 2004 12:28:58 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 06 Feb 2004 09:35:04 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i16HSPGv005857; Fri, 6 Feb 2004 09:28:26 -0800 (PST) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn3-390.cisco.com [10.21.65.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQR66189; Fri, 6 Feb 2004 09:28:24 -0800 (PST) Message-Id: <4.3.2.7.2.20040206092242.02d30e90@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Feb 2004 09:25:34 -0800 To: "Wijnen, Bert (Bert)" From: Andy Bierman Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB Cc: "'Margaret Wasserman'" , entmib@ietf.org In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155028EC525@nl0006exch001u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: , At 03:30 AM 2/6/2004, Wijnen, Bert (Bert) wrote: >> Given that this is a second WG Last Call for this document, that >> several people reviewed it during the previous WG Last Call, and >> that Sharon did a great job of maintaining an issue list and >> documenting the resolution of each issue, I am planning to interpret >> silence as agreement to send this document to the IESG. >> >I do not want to step on the toes of our WG chair, but yet... >I would actually appreciate if the people who spoke up (a while ago) >that the MIB was too complex, that they do state if they are now >OK with this version! > >PLEASE PARTICIPATE and express your opinion. comment on the MIB itself... the TCs should be named with a prefix. E.g., OperState -> EntityOperState. This applies to all the TCs in the draft. Andy _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 6 13:17:17 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 MAA06325 for ; Fri, 6 Feb 2004 12:31:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9oi-0004zR-Sr; Fri, 06 Feb 2004 12:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap9oZ-0004yi-9R for entmib@optimus.ietf.org; Fri, 06 Feb 2004 12:30:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06306 for ; Fri, 6 Feb 2004 12:30:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap9oX-0005IA-00 for entmib@ietf.org; Fri, 06 Feb 2004 12:30:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap9nd-0005FP-00 for entmib@ietf.org; Fri, 06 Feb 2004 12:29:54 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Ap9mk-000592-00 for entmib@ietf.org; Fri, 06 Feb 2004 12:28:58 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 06 Feb 2004 09:35:04 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i16HSPGv005857; Fri, 6 Feb 2004 09:28:26 -0800 (PST) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn3-390.cisco.com [10.21.65.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQR66189; Fri, 6 Feb 2004 09:28:24 -0800 (PST) Message-Id: <4.3.2.7.2.20040206092242.02d30e90@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Feb 2004 09:25:34 -0800 To: "Wijnen, Bert (Bert)" From: Andy Bierman Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB Cc: "'Margaret Wasserman'" , entmib@ietf.org In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155028EC525@nl0006exch001u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: , At 03:30 AM 2/6/2004, Wijnen, Bert (Bert) wrote: >> Given that this is a second WG Last Call for this document, that >> several people reviewed it during the previous WG Last Call, and >> that Sharon did a great job of maintaining an issue list and >> documenting the resolution of each issue, I am planning to interpret >> silence as agreement to send this document to the IESG. >> >I do not want to step on the toes of our WG chair, but yet... >I would actually appreciate if the people who spoke up (a while ago) >that the MIB was too complex, that they do state if they are now >OK with this version! > >PLEASE PARTICIPATE and express your opinion. comment on the MIB itself... the TCs should be named with a prefix. E.g., OperState -> EntityOperState. This applies to all the TCs in the draft. Andy _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 6 14:31: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 OAA11302 for ; Fri, 6 Feb 2004 14:31:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBgq-0005f7-Bl; Fri, 06 Feb 2004 14:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBfu-0005Yu-9p for entmib@optimus.ietf.org; Fri, 06 Feb 2004 14:30:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11221 for ; Fri, 6 Feb 2004 14:29:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApBfr-0005a2-00 for entmib@ietf.org; Fri, 06 Feb 2004 14:29:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApBf0-0005Wp-00 for entmib@ietf.org; Fri, 06 Feb 2004 14:29:06 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ApBeb-0005Sr-00 for entmib@ietf.org; Fri, 06 Feb 2004 14:28:41 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i16JS9V16023 for ; Fri, 6 Feb 2004 14:28:09 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNHZ8JG>; Fri, 6 Feb 2004 14:28:09 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A1792C7@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB Date: Fri, 6 Feb 2004 14:28:09 -0500 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 I don't understand where the impression that we were only planning on adding a single object that gave operational status came from. My early presentations on this topic outlined a large number of state objects that could be defined and from that we whittled down to what we thought was a reasonable set. Some people wanted more and some people wanted less. Sharon -----Original Message----- From: Andy Bierman [mailto:abierman@cisco.com] Sent: Friday, February 06, 2004 11:27 AM To: Wijnen, Bert (Bert) Cc: 'Margaret Wasserman'; entmib@ietf.org Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB At 03:30 AM 2/6/2004, Wijnen, Bert (Bert) wrote: >> Given that this is a second WG Last Call for this document, that >> several people reviewed it during the previous WG Last Call, and that >> Sharon did a great job of maintaining an issue list and documenting >> the resolution of each issue, I am planning to interpret silence as >> agreement to send this document to the IESG. >> >I do not want to step on the toes of our WG chair, but yet... I would >actually appreciate if the people who spoke up (a while ago) that the >MIB was too complex, that they do state if they are now OK with this >version! > >PLEASE PARTICIPATE and express your opinion. okay, okay... I do not approve of, or object to, the Entity State MIB going forward. My concerns are regarding the intent of the MIB -- the actual problem being addressed. So I looked to the Entmib WG charter page for guidance. This is all it says about the Entity State MIB: Done Publish state/status extensions as a WG I-D Mar 04 Submit Entity State MIB to the IESG for Proposed Standard Not a word about the problem being addressed. I thought we set out to add an 'operStatus' object for physical entities -- a simple ( green, yellow, red ) status indicator. Applications would still need to know how to use other MIBs to diagnose or correct a fault. IMO, there's not much value in a generic indicator beyond this, so it's best to keep it simple. From the draft: "Objects are defined to capture administrative, operational and usage states. In addition there are further state objects defined to provide additional information for these three basic states." The document clearly attempts to provide more functionality than a simple 'operStatus' object. The authors have done a fine job defining and documenting this functionality. In order to discuss how well a MIB addresses its intended function, we have to agree on the intended function. >Bert Andy >> So, if you have any objection to submitting this document for >> publication as a Proposed Standard, please make that clear by Friday. >> >> Thanks, >> Margaret >> >> >> >Date: Fri, 23 Jan 2004 17:00:59 -0500 >> >To: Entmib@ietf.org >> >From: Margaret Wasserman >> > >> >Hi All, >> > >> >This is a two week WG Last Call for submitting the Entity State MIB >> >to the IESG for publication as a Proposed Standard. The latest >> >version of this document can be found at: >> > >> >http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-02.txt >> > >> >This WG Last Call will end on Friday, February 6th at 5pm EST. >> > >> >Please review the document and forward substantive comments to >> >the mailing list. Editorial comments can be sent directly >> >to the authors. >> > >> >Thanks, >> >Margaret >> > >> > >> > >> >_______________________________________________ >> >Entmib mailing list >> >Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib >> >> >> _______________________________________________ >> Entmib mailing list >> Entmib@ietf.org >> https://www1.ietf.org/mailman/listinfo/entmib >> > >_______________________________________________ >Entmib mailing list >Entmib@ietf.org >https://www1.ietf.org/mailman/listinfo/entmib _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 6 14:31:29 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 OAA11319 for ; Fri, 6 Feb 2004 14:31:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBgr-0005g3-E7 for entmib-archive@odin.ietf.org; Fri, 06 Feb 2004 14:31:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16JV1SU021823 for entmib-archive@odin.ietf.org; Fri, 6 Feb 2004 14:31:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBgq-0005f7-Bl; Fri, 06 Feb 2004 14:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBfu-0005Yu-9p for entmib@optimus.ietf.org; Fri, 06 Feb 2004 14:30:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11221 for ; Fri, 6 Feb 2004 14:29:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApBfr-0005a2-00 for entmib@ietf.org; Fri, 06 Feb 2004 14:29:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApBf0-0005Wp-00 for entmib@ietf.org; Fri, 06 Feb 2004 14:29:06 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ApBeb-0005Sr-00 for entmib@ietf.org; Fri, 06 Feb 2004 14:28:41 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i16JS9V16023 for ; Fri, 6 Feb 2004 14:28:09 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNHZ8JG>; Fri, 6 Feb 2004 14:28:09 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A1792C7@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB Date: Fri, 6 Feb 2004 14:28:09 -0500 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 I don't understand where the impression that we were only planning on adding a single object that gave operational status came from. My early presentations on this topic outlined a large number of state objects that could be defined and from that we whittled down to what we thought was a reasonable set. Some people wanted more and some people wanted less. Sharon -----Original Message----- From: Andy Bierman [mailto:abierman@cisco.com] Sent: Friday, February 06, 2004 11:27 AM To: Wijnen, Bert (Bert) Cc: 'Margaret Wasserman'; entmib@ietf.org Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB At 03:30 AM 2/6/2004, Wijnen, Bert (Bert) wrote: >> Given that this is a second WG Last Call for this document, that >> several people reviewed it during the previous WG Last Call, and that >> Sharon did a great job of maintaining an issue list and documenting >> the resolution of each issue, I am planning to interpret silence as >> agreement to send this document to the IESG. >> >I do not want to step on the toes of our WG chair, but yet... I would >actually appreciate if the people who spoke up (a while ago) that the >MIB was too complex, that they do state if they are now OK with this >version! > >PLEASE PARTICIPATE and express your opinion. okay, okay... I do not approve of, or object to, the Entity State MIB going forward. My concerns are regarding the intent of the MIB -- the actual problem being addressed. So I looked to the Entmib WG charter page for guidance. This is all it says about the Entity State MIB: Done Publish state/status extensions as a WG I-D Mar 04 Submit Entity State MIB to the IESG for Proposed Standard Not a word about the problem being addressed. I thought we set out to add an 'operStatus' object for physical entities -- a simple ( green, yellow, red ) status indicator. Applications would still need to know how to use other MIBs to diagnose or correct a fault. IMO, there's not much value in a generic indicator beyond this, so it's best to keep it simple. From the draft: "Objects are defined to capture administrative, operational and usage states. In addition there are further state objects defined to provide additional information for these three basic states." The document clearly attempts to provide more functionality than a simple 'operStatus' object. The authors have done a fine job defining and documenting this functionality. In order to discuss how well a MIB addresses its intended function, we have to agree on the intended function. >Bert Andy >> So, if you have any objection to submitting this document for >> publication as a Proposed Standard, please make that clear by Friday. >> >> Thanks, >> Margaret >> >> >> >Date: Fri, 23 Jan 2004 17:00:59 -0500 >> >To: Entmib@ietf.org >> >From: Margaret Wasserman >> > >> >Hi All, >> > >> >This is a two week WG Last Call for submitting the Entity State MIB >> >to the IESG for publication as a Proposed Standard. The latest >> >version of this document can be found at: >> > >> >http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-02.txt >> > >> >This WG Last Call will end on Friday, February 6th at 5pm EST. >> > >> >Please review the document and forward substantive comments to >> >the mailing list. Editorial comments can be sent directly >> >to the authors. >> > >> >Thanks, >> >Margaret >> > >> > >> > >> >_______________________________________________ >> >Entmib mailing list >> >Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib >> >> >> _______________________________________________ >> Entmib mailing list >> Entmib@ietf.org >> https://www1.ietf.org/mailman/listinfo/entmib >> > >_______________________________________________ >Entmib mailing list >Entmib@ietf.org >https://www1.ietf.org/mailman/listinfo/entmib _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 6 14:36:29 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 OAA11428 for ; Fri, 6 Feb 2004 14:36:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBlh-0005oh-IR; Fri, 06 Feb 2004 14:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBlc-0005oM-4w for entmib@optimus.ietf.org; Fri, 06 Feb 2004 14:35:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11413 for ; Fri, 6 Feb 2004 14:35:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApBlZ-0005w4-00 for entmib@ietf.org; Fri, 06 Feb 2004 14:35:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApBkj-0005sx-00 for entmib@ietf.org; Fri, 06 Feb 2004 14:35:02 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ApBkI-0005om-00 for entmib@ietf.org; Fri, 06 Feb 2004 14:34:34 -0500 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 i16JY3i10010 for ; Fri, 6 Feb 2004 14:34:03 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNHZ83J>; Fri, 6 Feb 2004 14:34:03 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A1792D6@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB Date: Fri, 6 Feb 2004 14:34:02 -0500 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 I've created issue 322 to track this. The intention in creating the textual conventions was that they could be used in other MIBs that wanted to define state/status objects. Prefixing them with Entity makes this less obvious. Sharon -----Original Message----- From: Andy Bierman [mailto:abierman@cisco.com] Sent: Friday, February 06, 2004 12:26 PM To: Wijnen, Bert (Bert) Cc: 'Margaret Wasserman'; entmib@ietf.org Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB At 03:30 AM 2/6/2004, Wijnen, Bert (Bert) wrote: >> Given that this is a second WG Last Call for this document, that >> several people reviewed it during the previous WG Last Call, and that >> Sharon did a great job of maintaining an issue list and documenting >> the resolution of each issue, I am planning to interpret silence as >> agreement to send this document to the IESG. >> >I do not want to step on the toes of our WG chair, but yet... I would >actually appreciate if the people who spoke up (a while ago) that the >MIB was too complex, that they do state if they are now OK with this >version! > >PLEASE PARTICIPATE and express your opinion. comment on the MIB itself... the TCs should be named with a prefix. E.g., OperState -> EntityOperState. This applies to all the TCs in the draft. Andy _______________________________________________ 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 Fri Feb 6 14:36:29 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 OAA11430 for ; Fri, 6 Feb 2004 14:36:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBli-0005pZ-Ab for entmib-archive@odin.ietf.org; Fri, 06 Feb 2004 14:36:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16Ja12B022374 for entmib-archive@odin.ietf.org; Fri, 6 Feb 2004 14:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBlh-0005oh-IR; Fri, 06 Feb 2004 14:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBlc-0005oM-4w for entmib@optimus.ietf.org; Fri, 06 Feb 2004 14:35:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11413 for ; Fri, 6 Feb 2004 14:35:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApBlZ-0005w4-00 for entmib@ietf.org; Fri, 06 Feb 2004 14:35:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApBkj-0005sx-00 for entmib@ietf.org; Fri, 06 Feb 2004 14:35:02 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ApBkI-0005om-00 for entmib@ietf.org; Fri, 06 Feb 2004 14:34:34 -0500 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 i16JY3i10010 for ; Fri, 6 Feb 2004 14:34:03 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNHZ83J>; Fri, 6 Feb 2004 14:34:03 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A1792D6@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB Date: Fri, 6 Feb 2004 14:34:02 -0500 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 I've created issue 322 to track this. The intention in creating the textual conventions was that they could be used in other MIBs that wanted to define state/status objects. Prefixing them with Entity makes this less obvious. Sharon -----Original Message----- From: Andy Bierman [mailto:abierman@cisco.com] Sent: Friday, February 06, 2004 12:26 PM To: Wijnen, Bert (Bert) Cc: 'Margaret Wasserman'; entmib@ietf.org Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB At 03:30 AM 2/6/2004, Wijnen, Bert (Bert) wrote: >> Given that this is a second WG Last Call for this document, that >> several people reviewed it during the previous WG Last Call, and that >> Sharon did a great job of maintaining an issue list and documenting >> the resolution of each issue, I am planning to interpret silence as >> agreement to send this document to the IESG. >> >I do not want to step on the toes of our WG chair, but yet... I would >actually appreciate if the people who spoke up (a while ago) that the >MIB was too complex, that they do state if they are now OK with this >version! > >PLEASE PARTICIPATE and express your opinion. comment on the MIB itself... the TCs should be named with a prefix. E.g., OperState -> EntityOperState. This applies to all the TCs in the draft. Andy _______________________________________________ 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 Feb 7 08:15:32 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 IAA02644 for ; Sat, 7 Feb 2004 08:15:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApSIZ-0004xY-5N; Sat, 07 Feb 2004 08:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApSI2-0004tG-P2 for entmib@optimus.ietf.org; Sat, 07 Feb 2004 08:14:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02633 for ; Sat, 7 Feb 2004 08:14:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApSI1-0003kk-00 for entmib@ietf.org; Sat, 07 Feb 2004 08:14:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApSH5-0003hE-00 for entmib@ietf.org; Sat, 07 Feb 2004 08:13:31 -0500 Received: from smtp.exodus.net ([66.35.230.237] helo=smtp02-w.exodus.net) by ietf-mx with esmtp (Exim 4.12) id 1ApSGp-0003do-00 for entmib@ietf.org; Sat, 07 Feb 2004 08:13:15 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp02-w.exodus.net (8.12.8/8.12.8) with ESMTP id i17AMMEv003046 for ; Sat, 7 Feb 2004 04:22:22 -0600 Received: from ala-mrwtemp.thingmagic.com (unverified [24.61.30.237]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id ; Sat, 7 Feb 2004 05:12:43 -0800 Message-Id: <5.1.0.14.2.20040207080446.041f1288@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 07 Feb 2004 08:06:48 -0500 To: "Sharon Chisholm" From: Margaret Wasserman Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB Cc: entmib@ietf.org In-Reply-To: <3549C09B853DD5119B540002A52CDD340A1792D6@zcard0ka.ca.norte l.com> Mime-Version: 1.0 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 All, Could others please express their opinions on this issue? Who believes that these TCs should use a prefix (e.g. EntityOperStatus) and why? Who think that they should not include a prefix, and why? Since we are not planning to meet in Seoul, it is important to close this issue on the mailing list. Thanks, Margaret At 02:34 PM 2/6/2004 -0500, Sharon Chisholm wrote: >Hi > >I've created issue 322 to track this. > >The intention in creating the textual conventions was that they could be >used in other MIBs that wanted to define state/status objects. Prefixing >them with Entity makes this less obvious. > >Sharon > >-----Original Message----- >From: Andy Bierman [mailto:abierman@cisco.com] >Sent: Friday, February 06, 2004 12:26 PM >To: Wijnen, Bert (Bert) >Cc: 'Margaret Wasserman'; entmib@ietf.org >Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB > > >At 03:30 AM 2/6/2004, Wijnen, Bert (Bert) wrote: > >> Given that this is a second WG Last Call for this document, that > >> several people reviewed it during the previous WG Last Call, and that > >> Sharon did a great job of maintaining an issue list and documenting > >> the resolution of each issue, I am planning to interpret silence as > >> agreement to send this document to the IESG. > >> > >I do not want to step on the toes of our WG chair, but yet... I would > >actually appreciate if the people who spoke up (a while ago) that the > >MIB was too complex, that they do state if they are now OK with this > >version! > > > >PLEASE PARTICIPATE and express your opinion. > >comment on the MIB itself... > >the TCs should be named with a prefix. E.g., >OperState -> EntityOperState. This applies to >all the TCs in the draft. > >Andy > > >_______________________________________________ >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 Sat Feb 7 08:15:32 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 IAA02648 for ; Sat, 7 Feb 2004 08:15:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApSIZ-0004xw-Ff for entmib-archive@odin.ietf.org; Sat, 07 Feb 2004 08:15:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i17DF3RM019078 for entmib-archive@odin.ietf.org; Sat, 7 Feb 2004 08:15:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApSIZ-0004xY-5N; Sat, 07 Feb 2004 08:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApSI2-0004tG-P2 for entmib@optimus.ietf.org; Sat, 07 Feb 2004 08:14:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02633 for ; Sat, 7 Feb 2004 08:14:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApSI1-0003kk-00 for entmib@ietf.org; Sat, 07 Feb 2004 08:14:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApSH5-0003hE-00 for entmib@ietf.org; Sat, 07 Feb 2004 08:13:31 -0500 Received: from smtp.exodus.net ([66.35.230.237] helo=smtp02-w.exodus.net) by ietf-mx with esmtp (Exim 4.12) id 1ApSGp-0003do-00 for entmib@ietf.org; Sat, 07 Feb 2004 08:13:15 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp02-w.exodus.net (8.12.8/8.12.8) with ESMTP id i17AMMEv003046 for ; Sat, 7 Feb 2004 04:22:22 -0600 Received: from ala-mrwtemp.thingmagic.com (unverified [24.61.30.237]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id ; Sat, 7 Feb 2004 05:12:43 -0800 Message-Id: <5.1.0.14.2.20040207080446.041f1288@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 07 Feb 2004 08:06:48 -0500 To: "Sharon Chisholm" From: Margaret Wasserman Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB Cc: entmib@ietf.org In-Reply-To: <3549C09B853DD5119B540002A52CDD340A1792D6@zcard0ka.ca.norte l.com> Mime-Version: 1.0 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 All, Could others please express their opinions on this issue? Who believes that these TCs should use a prefix (e.g. EntityOperStatus) and why? Who think that they should not include a prefix, and why? Since we are not planning to meet in Seoul, it is important to close this issue on the mailing list. Thanks, Margaret At 02:34 PM 2/6/2004 -0500, Sharon Chisholm wrote: >Hi > >I've created issue 322 to track this. > >The intention in creating the textual conventions was that they could be >used in other MIBs that wanted to define state/status objects. Prefixing >them with Entity makes this less obvious. > >Sharon > >-----Original Message----- >From: Andy Bierman [mailto:abierman@cisco.com] >Sent: Friday, February 06, 2004 12:26 PM >To: Wijnen, Bert (Bert) >Cc: 'Margaret Wasserman'; entmib@ietf.org >Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB > > >At 03:30 AM 2/6/2004, Wijnen, Bert (Bert) wrote: > >> Given that this is a second WG Last Call for this document, that > >> several people reviewed it during the previous WG Last Call, and that > >> Sharon did a great job of maintaining an issue list and documenting > >> the resolution of each issue, I am planning to interpret silence as > >> agreement to send this document to the IESG. > >> > >I do not want to step on the toes of our WG chair, but yet... I would > >actually appreciate if the people who spoke up (a while ago) that the > >MIB was too complex, that they do state if they are now OK with this > >version! > > > >PLEASE PARTICIPATE and express your opinion. > >comment on the MIB itself... > >the TCs should be named with a prefix. E.g., >OperState -> EntityOperState. This applies to >all the TCs in the draft. > >Andy > > >_______________________________________________ >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 Sat Feb 7 09:15:32 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 JAA04488 for ; Sat, 7 Feb 2004 09:15:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApTEd-0000mB-S3 for entmib-archive@odin.ietf.org; Sat, 07 Feb 2004 09:15:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i17EF3VG002967 for entmib-archive@odin.ietf.org; Sat, 7 Feb 2004 09:15:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApTEd-0000le-Gd; Sat, 07 Feb 2004 09:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApTEG-0000ku-Ip for entmib@optimus.ietf.org; Sat, 07 Feb 2004 09:14:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04456 for ; Sat, 7 Feb 2004 09:14:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApTEF-0000q2-00 for entmib@ietf.org; Sat, 07 Feb 2004 09:14:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApTDN-0000l8-00 for entmib@ietf.org; Sat, 07 Feb 2004 09:13:45 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ApTCe-0000cC-00 for entmib@ietf.org; Sat, 07 Feb 2004 09:13:00 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i17ECQo14707 for ; Sat, 7 Feb 2004 08:12:26 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 7 Feb 2004 15:12:25 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC562@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Margaret Wasserman'" , Sharon Chisholm Cc: entmib@ietf.org Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB Date: Sat, 7 Feb 2004 15:12:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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: , Speaking as technical contributor In general, when a TC is clearly generic, then using the most intuitive and generic name makes sense. In most cases, such a TC would be better specified in a generic/independent document (or at least a separate MIB module). As soon as a TC is specific to some technology or to some WG, then prefixing it with the wg or technology-specific acronym is the way to go. Bert > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: zaterdag 7 februari 2004 14:07 > To: Sharon Chisholm > Cc: entmib@ietf.org > Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB > > > > Hi All, > > Could others please express their opinions on this issue? Who > believes that these TCs should use a prefix (e.g. EntityOperStatus) > and why? Who think that they should not include a prefix, and why? > > Since we are not planning to meet in Seoul, it is important to > close this issue on the mailing list. > > Thanks, > Margaret > > At 02:34 PM 2/6/2004 -0500, Sharon Chisholm wrote: > >Hi > > > >I've created issue 322 to track this. > > > >The intention in creating the textual conventions was that > they could be > >used in other MIBs that wanted to define state/status > objects. Prefixing > >them with Entity makes this less obvious. > > > >Sharon > > > >-----Original Message----- > >From: Andy Bierman [mailto:abierman@cisco.com] > >Sent: Friday, February 06, 2004 12:26 PM > >To: Wijnen, Bert (Bert) > >Cc: 'Margaret Wasserman'; entmib@ietf.org > >Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB > > > > > >At 03:30 AM 2/6/2004, Wijnen, Bert (Bert) wrote: > > >> Given that this is a second WG Last Call for this document, that > > >> several people reviewed it during the previous WG Last > Call, and that > > >> Sharon did a great job of maintaining an issue list and > documenting > > >> the resolution of each issue, I am planning to interpret > silence as > > >> agreement to send this document to the IESG. > > >> > > >I do not want to step on the toes of our WG chair, but > yet... I would > > >actually appreciate if the people who spoke up (a while > ago) that the > > >MIB was too complex, that they do state if they are now OK > with this > > >version! > > > > > >PLEASE PARTICIPATE and express your opinion. > > > >comment on the MIB itself... > > > >the TCs should be named with a prefix. E.g., > >OperState -> EntityOperState. This applies to > >all the TCs in the draft. > > > >Andy > > > > > >_______________________________________________ > >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 Sat Feb 7 09:55:30 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 JAA05274 for ; Sat, 7 Feb 2004 09:55:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApTrK-00037I-Mf; Sat, 07 Feb 2004 09:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApTqr-00036Y-QZ for entmib@optimus.ietf.org; Sat, 07 Feb 2004 09:54:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05260 for ; Sat, 7 Feb 2004 09:54:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApTqp-0003XA-00 for entmib@ietf.org; Sat, 07 Feb 2004 09:54:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApTpw-0003Tx-00 for entmib@ietf.org; Sat, 07 Feb 2004 09:53:36 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ApTpM-0003Q2-00 for entmib@ietf.org; Sat, 07 Feb 2004 09:53:00 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 07 Feb 2004 06:59:56 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i17EqR9T021169; Sat, 7 Feb 2004 06:52:27 -0800 (PST) Received: from cisco.com (sjc-vpn2-436.cisco.com [10.21.113.180]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQS42802; Sat, 7 Feb 2004 06:52:26 -0800 (PST) Message-ID: <4024FBAA.8040600@cisco.com> Date: Sat, 07 Feb 2004 06:52:26 -0800 From: Subrahmanya Hegde Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman CC: Sharon Chisholm , entmib@ietf.org Subject: Re: REMINDER: [Entmib] WG Last Call: Entity State MIB References: <5.1.0.14.2.20040207080446.041f1288@ms101.mail1.com> In-Reply-To: <5.1.0.14.2.20040207080446.041f1288@ms101.mail1.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit 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: 7bit Hi Following comments were sent on 1/11/2004: But it is not taken care in the latest draft. Hoping some one is carrying as part of Editorial fix ****** a Minor Suggestion: Instead of having these OID definitions: -- Notifications entStateTraps OBJECT IDENTIFIER ::= { entityStateMIB 2 } entStateTrapPrefix OBJECT IDENTIFIER ::= { entStateTraps 0 } We can have entStateNotifs OBJECT IDENTIFIER ::= { entityStateMIB 0 } and use 'entStateNotifs' in the corresponding NOTIFICATION-TYPE Reason we would like to avoid name 'Traps' is: Latest RFCs refer them as Notifications Also, above OID tree structure will be inline with mib review guidelines document: draft-ietf-ops-mib-review-guidelines-02.txt **** 1/11/2004 comment ends 2. Regarding TC Names: I would like to see TC with prefix (for example: EntityOperStatus, EntityUsage state etc) Reason(s) are : * It is obivious it is related to Entities * I don't think having a Generic TC 'OperState' automatically means it can be used outside the context of Entity. Reason being other MIBs might need more than what is defined in this TC or most of them may not be applicable in some cases TC name from 'review guideline draft says" ** - Names of TCs that are specific to the MIB module and names of SEQUENCE types that are used in conceptual table definitions should start with a prefix Xxx that is the same as xxx but with the initial letter changed to upper case. OPT-IF-MIB uses the prefix OptIf on the names of TCs and SEQUENCE types. *** 3. As per the MIB convention : We should define a OID under 'entStateObjects' and use that in the xxxTable. For example: entStateObjects OBJECT IDENTIFIER ::= { entityStateMIB 1} add: entityState OBJECT IDENTIFIER ::= { entStateObjects 1} use this 'entityState'(or whatever else makes sense) for entStateTable in the mib 4. entStateConformance must be under { entityStateMIB 2} 3. I think OID definition for 'entityStateGroups' is missing it should be entStateGroups OBJECT IDENTIFIER ::= { entStateConformance 2} Thanks Subra Margaret Wasserman wrote: > > Hi All, > > Could others please express their opinions on this issue? Who > believes that these TCs should use a prefix (e.g. EntityOperStatus) > and why? Who think that they should not include a prefix, and why? > > Since we are not planning to meet in Seoul, it is important to > close this issue on the mailing list. > > Thanks, > Margaret > > At 02:34 PM 2/6/2004 -0500, Sharon Chisholm wrote: > >> Hi >> >> I've created issue 322 to track this. >> >> The intention in creating the textual conventions was that they could be >> used in other MIBs that wanted to define state/status objects. Prefixing >> them with Entity makes this less obvious. >> >> Sharon >> >> -----Original Message----- >> From: Andy Bierman [mailto:abierman@cisco.com] >> Sent: Friday, February 06, 2004 12:26 PM >> To: Wijnen, Bert (Bert) >> Cc: 'Margaret Wasserman'; entmib@ietf.org >> Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB >> >> >> At 03:30 AM 2/6/2004, Wijnen, Bert (Bert) wrote: >> >> Given that this is a second WG Last Call for this document, that >> >> several people reviewed it during the previous WG Last Call, and that >> >> Sharon did a great job of maintaining an issue list and documenting >> >> the resolution of each issue, I am planning to interpret silence as >> >> agreement to send this document to the IESG. >> >> >> >I do not want to step on the toes of our WG chair, but yet... I would >> >actually appreciate if the people who spoke up (a while ago) that the >> >MIB was too complex, that they do state if they are now OK with this >> >version! >> > >> >PLEASE PARTICIPATE and express your opinion. >> >> comment on the MIB itself... >> >> the TCs should be named with a prefix. E.g., >> OperState -> EntityOperState. This applies to >> all the TCs in the draft. >> >> Andy >> >> >> _______________________________________________ >> 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 Sat Feb 7 09:55:30 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 JAA05276 for ; Sat, 7 Feb 2004 09:55:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApTrL-00037o-4C for entmib-archive@odin.ietf.org; Sat, 07 Feb 2004 09:55:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i17Et3Ko012000 for entmib-archive@odin.ietf.org; Sat, 7 Feb 2004 09:55:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApTrK-00037I-Mf; Sat, 07 Feb 2004 09:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApTqr-00036Y-QZ for entmib@optimus.ietf.org; Sat, 07 Feb 2004 09:54:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05260 for ; Sat, 7 Feb 2004 09:54:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApTqp-0003XA-00 for entmib@ietf.org; Sat, 07 Feb 2004 09:54:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApTpw-0003Tx-00 for entmib@ietf.org; Sat, 07 Feb 2004 09:53:36 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ApTpM-0003Q2-00 for entmib@ietf.org; Sat, 07 Feb 2004 09:53:00 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 07 Feb 2004 06:59:56 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i17EqR9T021169; Sat, 7 Feb 2004 06:52:27 -0800 (PST) Received: from cisco.com (sjc-vpn2-436.cisco.com [10.21.113.180]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQS42802; Sat, 7 Feb 2004 06:52:26 -0800 (PST) Message-ID: <4024FBAA.8040600@cisco.com> Date: Sat, 07 Feb 2004 06:52:26 -0800 From: Subrahmanya Hegde Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman CC: Sharon Chisholm , entmib@ietf.org Subject: Re: REMINDER: [Entmib] WG Last Call: Entity State MIB References: <5.1.0.14.2.20040207080446.041f1288@ms101.mail1.com> In-Reply-To: <5.1.0.14.2.20040207080446.041f1288@ms101.mail1.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit 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: 7bit Hi Following comments were sent on 1/11/2004: But it is not taken care in the latest draft. Hoping some one is carrying as part of Editorial fix ****** a Minor Suggestion: Instead of having these OID definitions: -- Notifications entStateTraps OBJECT IDENTIFIER ::= { entityStateMIB 2 } entStateTrapPrefix OBJECT IDENTIFIER ::= { entStateTraps 0 } We can have entStateNotifs OBJECT IDENTIFIER ::= { entityStateMIB 0 } and use 'entStateNotifs' in the corresponding NOTIFICATION-TYPE Reason we would like to avoid name 'Traps' is: Latest RFCs refer them as Notifications Also, above OID tree structure will be inline with mib review guidelines document: draft-ietf-ops-mib-review-guidelines-02.txt **** 1/11/2004 comment ends 2. Regarding TC Names: I would like to see TC with prefix (for example: EntityOperStatus, EntityUsage state etc) Reason(s) are : * It is obivious it is related to Entities * I don't think having a Generic TC 'OperState' automatically means it can be used outside the context of Entity. Reason being other MIBs might need more than what is defined in this TC or most of them may not be applicable in some cases TC name from 'review guideline draft says" ** - Names of TCs that are specific to the MIB module and names of SEQUENCE types that are used in conceptual table definitions should start with a prefix Xxx that is the same as xxx but with the initial letter changed to upper case. OPT-IF-MIB uses the prefix OptIf on the names of TCs and SEQUENCE types. *** 3. As per the MIB convention : We should define a OID under 'entStateObjects' and use that in the xxxTable. For example: entStateObjects OBJECT IDENTIFIER ::= { entityStateMIB 1} add: entityState OBJECT IDENTIFIER ::= { entStateObjects 1} use this 'entityState'(or whatever else makes sense) for entStateTable in the mib 4. entStateConformance must be under { entityStateMIB 2} 3. I think OID definition for 'entityStateGroups' is missing it should be entStateGroups OBJECT IDENTIFIER ::= { entStateConformance 2} Thanks Subra Margaret Wasserman wrote: > > Hi All, > > Could others please express their opinions on this issue? Who > believes that these TCs should use a prefix (e.g. EntityOperStatus) > and why? Who think that they should not include a prefix, and why? > > Since we are not planning to meet in Seoul, it is important to > close this issue on the mailing list. > > Thanks, > Margaret > > At 02:34 PM 2/6/2004 -0500, Sharon Chisholm wrote: > >> Hi >> >> I've created issue 322 to track this. >> >> The intention in creating the textual conventions was that they could be >> used in other MIBs that wanted to define state/status objects. Prefixing >> them with Entity makes this less obvious. >> >> Sharon >> >> -----Original Message----- >> From: Andy Bierman [mailto:abierman@cisco.com] >> Sent: Friday, February 06, 2004 12:26 PM >> To: Wijnen, Bert (Bert) >> Cc: 'Margaret Wasserman'; entmib@ietf.org >> Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB >> >> >> At 03:30 AM 2/6/2004, Wijnen, Bert (Bert) wrote: >> >> Given that this is a second WG Last Call for this document, that >> >> several people reviewed it during the previous WG Last Call, and that >> >> Sharon did a great job of maintaining an issue list and documenting >> >> the resolution of each issue, I am planning to interpret silence as >> >> agreement to send this document to the IESG. >> >> >> >I do not want to step on the toes of our WG chair, but yet... I would >> >actually appreciate if the people who spoke up (a while ago) that the >> >MIB was too complex, that they do state if they are now OK with this >> >version! >> > >> >PLEASE PARTICIPATE and express your opinion. >> >> comment on the MIB itself... >> >> the TCs should be named with a prefix. E.g., >> OperState -> EntityOperState. This applies to >> all the TCs in the draft. >> >> Andy >> >> >> _______________________________________________ >> 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 Sat Feb 7 10:02: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 JAA04483 for ; Sat, 7 Feb 2004 09:15:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApTEd-0000le-Gd; Sat, 07 Feb 2004 09:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApTEG-0000ku-Ip for entmib@optimus.ietf.org; Sat, 07 Feb 2004 09:14:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04456 for ; Sat, 7 Feb 2004 09:14:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApTEF-0000q2-00 for entmib@ietf.org; Sat, 07 Feb 2004 09:14:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApTDN-0000l8-00 for entmib@ietf.org; Sat, 07 Feb 2004 09:13:45 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ApTCe-0000cC-00 for entmib@ietf.org; Sat, 07 Feb 2004 09:13:00 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i17ECQo14707 for ; Sat, 7 Feb 2004 08:12:26 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 7 Feb 2004 15:12:25 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC562@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Margaret Wasserman'" , Sharon Chisholm Cc: entmib@ietf.org Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB Date: Sat, 7 Feb 2004 15:12:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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: , Speaking as technical contributor In general, when a TC is clearly generic, then using the most intuitive and generic name makes sense. In most cases, such a TC would be better specified in a generic/independent document (or at least a separate MIB module). As soon as a TC is specific to some technology or to some WG, then prefixing it with the wg or technology-specific acronym is the way to go. Bert > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: zaterdag 7 februari 2004 14:07 > To: Sharon Chisholm > Cc: entmib@ietf.org > Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB > > > > Hi All, > > Could others please express their opinions on this issue? Who > believes that these TCs should use a prefix (e.g. EntityOperStatus) > and why? Who think that they should not include a prefix, and why? > > Since we are not planning to meet in Seoul, it is important to > close this issue on the mailing list. > > Thanks, > Margaret > > At 02:34 PM 2/6/2004 -0500, Sharon Chisholm wrote: > >Hi > > > >I've created issue 322 to track this. > > > >The intention in creating the textual conventions was that > they could be > >used in other MIBs that wanted to define state/status > objects. Prefixing > >them with Entity makes this less obvious. > > > >Sharon > > > >-----Original Message----- > >From: Andy Bierman [mailto:abierman@cisco.com] > >Sent: Friday, February 06, 2004 12:26 PM > >To: Wijnen, Bert (Bert) > >Cc: 'Margaret Wasserman'; entmib@ietf.org > >Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB > > > > > >At 03:30 AM 2/6/2004, Wijnen, Bert (Bert) wrote: > > >> Given that this is a second WG Last Call for this document, that > > >> several people reviewed it during the previous WG Last > Call, and that > > >> Sharon did a great job of maintaining an issue list and > documenting > > >> the resolution of each issue, I am planning to interpret > silence as > > >> agreement to send this document to the IESG. > > >> > > >I do not want to step on the toes of our WG chair, but > yet... I would > > >actually appreciate if the people who spoke up (a while > ago) that the > > >MIB was too complex, that they do state if they are now OK > with this > > >version! > > > > > >PLEASE PARTICIPATE and express your opinion. > > > >comment on the MIB itself... > > > >the TCs should be named with a prefix. E.g., > >OperState -> EntityOperState. This applies to > >all the TCs in the draft. > > > >Andy > > > > > >_______________________________________________ > >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 Sat Feb 7 11:22:31 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 LAA08002 for ; Sat, 7 Feb 2004 11:22:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApVDU-0006S8-2o; Sat, 07 Feb 2004 11:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApVD5-0006Rw-G8 for entmib@optimus.ietf.org; Sat, 07 Feb 2004 11:21:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07994 for ; Sat, 7 Feb 2004 11:21:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApVD4-0001A0-00 for entmib@ietf.org; Sat, 07 Feb 2004 11:21:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApVC8-00016i-00 for entmib@ietf.org; Sat, 07 Feb 2004 11:20:36 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ApVBv-00013I-00 for entmib@ietf.org; Sat, 07 Feb 2004 11:20:24 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i17GJoA09581 for ; Sat, 7 Feb 2004 10:19:50 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 7 Feb 2004 17:19:48 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC564@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Subrahmanya Hegde'" , Margaret Wasserman Cc: Sharon Chisholm , entmib@ietf.org Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB Date: Sat, 7 Feb 2004 17:19:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" 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: , > Following comments were sent on 1/11/2004: But it is not > taken care in the latest draft. > Hoping some one is carrying as part of Editorial fix > ****** > a Minor Suggestion: > > Instead of having these OID definitions: > > -- Notifications > > entStateTraps OBJECT IDENTIFIER ::= { entityStateMIB 2 } > entStateTrapPrefix OBJECT IDENTIFIER ::= { entStateTraps 0 } > > > We can have > entStateNotifs OBJECT IDENTIFIER ::= { entityStateMIB 0 } > > and use 'entStateNotifs' in the corresponding NOTIFICATION-TYPE > > Reason we would like to avoid name 'Traps' is: Latest RFCs refer them > as Notifications > > Also, above OID tree structure will be inline with mib review > guidelines document: draft-ietf-ops-mib-review-guidelines-02.txt > I agree with that ... and I would even say: entStateNotifications OBJECT IDENTIFIER ::= { entityStateMIB 0 } Why make the descriptor more cryptic than needed? Bert _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Sat Feb 7 11:22:31 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 LAA08009 for ; Sat, 7 Feb 2004 11:22:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApVDX-0006Sh-0h for entmib-archive@odin.ietf.org; Sat, 07 Feb 2004 11:22:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i17GM2eM024827 for entmib-archive@odin.ietf.org; Sat, 7 Feb 2004 11:22:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApVDU-0006S8-2o; Sat, 07 Feb 2004 11:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApVD5-0006Rw-G8 for entmib@optimus.ietf.org; Sat, 07 Feb 2004 11:21:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07994 for ; Sat, 7 Feb 2004 11:21:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApVD4-0001A0-00 for entmib@ietf.org; Sat, 07 Feb 2004 11:21:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApVC8-00016i-00 for entmib@ietf.org; Sat, 07 Feb 2004 11:20:36 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ApVBv-00013I-00 for entmib@ietf.org; Sat, 07 Feb 2004 11:20:24 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i17GJoA09581 for ; Sat, 7 Feb 2004 10:19:50 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 7 Feb 2004 17:19:48 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC564@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Subrahmanya Hegde'" , Margaret Wasserman Cc: Sharon Chisholm , entmib@ietf.org Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB Date: Sat, 7 Feb 2004 17:19:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" 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: , > Following comments were sent on 1/11/2004: But it is not > taken care in the latest draft. > Hoping some one is carrying as part of Editorial fix > ****** > a Minor Suggestion: > > Instead of having these OID definitions: > > -- Notifications > > entStateTraps OBJECT IDENTIFIER ::= { entityStateMIB 2 } > entStateTrapPrefix OBJECT IDENTIFIER ::= { entStateTraps 0 } > > > We can have > entStateNotifs OBJECT IDENTIFIER ::= { entityStateMIB 0 } > > and use 'entStateNotifs' in the corresponding NOTIFICATION-TYPE > > Reason we would like to avoid name 'Traps' is: Latest RFCs refer them > as Notifications > > Also, above OID tree structure will be inline with mib review > guidelines document: draft-ietf-ops-mib-review-guidelines-02.txt > I agree with that ... and I would even say: entStateNotifications OBJECT IDENTIFIER ::= { entityStateMIB 0 } Why make the descriptor more cryptic than needed? Bert _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Sat Feb 7 12:19: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 MAA09071 for ; Sat, 7 Feb 2004 12:19:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApW6e-0002kU-VZ; Sat, 07 Feb 2004 12:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApW6G-0002jw-6M for entmib@optimus.ietf.org; Sat, 07 Feb 2004 12:18:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09051 for ; Sat, 7 Feb 2004 12:18:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApW6E-00053T-00 for entmib@ietf.org; Sat, 07 Feb 2004 12:18:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApW5G-0004zN-00 for entmib@ietf.org; Sat, 07 Feb 2004 12:17:35 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ApW4K-0004sh-00 for entmib@ietf.org; Sat, 07 Feb 2004 12:16:36 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 Feb 2004 09:22:54 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i17HG3Gv029378; Sat, 7 Feb 2004 09:16:04 -0800 (PST) Received: from cisco.com (sjc-vpn2-436.cisco.com [10.21.113.180]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQS45042; Sat, 7 Feb 2004 09:16:03 -0800 (PST) Message-ID: <40251D53.8010406@cisco.com> Date: Sat, 07 Feb 2004 09:16:03 -0800 From: Subrahmanya Hegde Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: Margaret Wasserman , Sharon Chisholm , entmib@ietf.org Subject: Re: REMINDER: [Entmib] WG Last Call: Entity State MIB References: <7D5D48D2CAA3D84C813F5B154F43B155028EC564@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155028EC564@nl0006exch001u.nl.lucent.com> Content-Type: multipart/alternative; boundary="------------050806010806010604000203" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, HTML_TITLE_EMPTY 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: , This is a multi-part message in MIME format. --------------050806010806010604000203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Agree with you SUbra Wijnen, Bert (Bert) wrote: >>Following comments were sent on 1/11/2004: But it is not >>taken care in the latest draft. >>Hoping some one is carrying as part of Editorial fix >>****** >>a Minor Suggestion: >> >>Instead of having these OID definitions: >> >>-- Notifications >> >> entStateTraps OBJECT IDENTIFIER ::= { entityStateMIB 2 } >> entStateTrapPrefix OBJECT IDENTIFIER ::= { entStateTraps 0 } >> >> >>We can have >>entStateNotifs OBJECT IDENTIFIER ::= { entityStateMIB 0 } >> >>and use 'entStateNotifs' in the corresponding NOTIFICATION-TYPE >> >>Reason we would like to avoid name 'Traps' is: Latest RFCs refer them >>as Notifications >> >>Also, above OID tree structure will be inline with mib review >>guidelines document: draft-ietf-ops-mib-review-guidelines-02.txt >> >> >> > >I agree with that ... and I would even say: > > entStateNotifications OBJECT IDENTIFIER ::= { entityStateMIB 0 } > >Why make the descriptor more cryptic than needed? > >Bert > >_______________________________________________ >Entmib mailing list >Entmib@ietf.org >https://www1.ietf.org/mailman/listinfo/entmib > > > --------------050806010806010604000203 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Agree with you

SUbra

Wijnen, Bert (Bert) wrote:
Following comments were sent on 1/11/2004: But it is not 
taken care in the latest draft.
Hoping some one is carrying as part of Editorial fix
******
a Minor Suggestion:

Instead of having these OID definitions:

-- Notifications

  entStateTraps      OBJECT IDENTIFIER ::= { entityStateMIB 2 }
  entStateTrapPrefix OBJECT IDENTIFIER ::= { entStateTraps 0 }


We can have
entStateNotifs OBJECT IDENTIFIER ::= { entityStateMIB 0 }

and use 'entStateNotifs' in the corresponding NOTIFICATION-TYPE

Reason we would like to avoid name 'Traps' is: Latest RFCs refer them
as Notifications

Also, above OID tree structure will be inline with mib review 
guidelines document: draft-ietf-ops-mib-review-guidelines-02.txt

    

I agree with that ... and I would even say:

  entStateNotifications OBJECT IDENTIFIER ::= { entityStateMIB 0 }

Why make the descriptor more cryptic than needed?

Bert

_______________________________________________
Entmib mailing list
Entmib@ietf.org
https://www1.ietf.org/mailman/listinfo/entmib
--------------050806010806010604000203-- _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Sat Feb 7 12:19:53 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 MAA09093 for ; Sat, 7 Feb 2004 12:19:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApW6f-0002l1-AM for entmib-archive@odin.ietf.org; Sat, 07 Feb 2004 12:19:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i17HJ1Tg010582 for entmib-archive@odin.ietf.org; Sat, 7 Feb 2004 12:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApW6e-0002kU-VZ; Sat, 07 Feb 2004 12:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApW6G-0002jw-6M for entmib@optimus.ietf.org; Sat, 07 Feb 2004 12:18:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09051 for ; Sat, 7 Feb 2004 12:18:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApW6E-00053T-00 for entmib@ietf.org; Sat, 07 Feb 2004 12:18:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApW5G-0004zN-00 for entmib@ietf.org; Sat, 07 Feb 2004 12:17:35 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ApW4K-0004sh-00 for entmib@ietf.org; Sat, 07 Feb 2004 12:16:36 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 Feb 2004 09:22:54 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i17HG3Gv029378; Sat, 7 Feb 2004 09:16:04 -0800 (PST) Received: from cisco.com (sjc-vpn2-436.cisco.com [10.21.113.180]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQS45042; Sat, 7 Feb 2004 09:16:03 -0800 (PST) Message-ID: <40251D53.8010406@cisco.com> Date: Sat, 07 Feb 2004 09:16:03 -0800 From: Subrahmanya Hegde Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: Margaret Wasserman , Sharon Chisholm , entmib@ietf.org Subject: Re: REMINDER: [Entmib] WG Last Call: Entity State MIB References: <7D5D48D2CAA3D84C813F5B154F43B155028EC564@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155028EC564@nl0006exch001u.nl.lucent.com> Content-Type: multipart/alternative; boundary="------------050806010806010604000203" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, HTML_TITLE_EMPTY 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: , This is a multi-part message in MIME format. --------------050806010806010604000203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Agree with you SUbra Wijnen, Bert (Bert) wrote: >>Following comments were sent on 1/11/2004: But it is not >>taken care in the latest draft. >>Hoping some one is carrying as part of Editorial fix >>****** >>a Minor Suggestion: >> >>Instead of having these OID definitions: >> >>-- Notifications >> >> entStateTraps OBJECT IDENTIFIER ::= { entityStateMIB 2 } >> entStateTrapPrefix OBJECT IDENTIFIER ::= { entStateTraps 0 } >> >> >>We can have >>entStateNotifs OBJECT IDENTIFIER ::= { entityStateMIB 0 } >> >>and use 'entStateNotifs' in the corresponding NOTIFICATION-TYPE >> >>Reason we would like to avoid name 'Traps' is: Latest RFCs refer them >>as Notifications >> >>Also, above OID tree structure will be inline with mib review >>guidelines document: draft-ietf-ops-mib-review-guidelines-02.txt >> >> >> > >I agree with that ... and I would even say: > > entStateNotifications OBJECT IDENTIFIER ::= { entityStateMIB 0 } > >Why make the descriptor more cryptic than needed? > >Bert > >_______________________________________________ >Entmib mailing list >Entmib@ietf.org >https://www1.ietf.org/mailman/listinfo/entmib > > > --------------050806010806010604000203 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Agree with you

SUbra

Wijnen, Bert (Bert) wrote:
Following comments were sent on 1/11/2004: But it is not 
taken care in the latest draft.
Hoping some one is carrying as part of Editorial fix
******
a Minor Suggestion:

Instead of having these OID definitions:

-- Notifications

  entStateTraps      OBJECT IDENTIFIER ::= { entityStateMIB 2 }
  entStateTrapPrefix OBJECT IDENTIFIER ::= { entStateTraps 0 }


We can have
entStateNotifs OBJECT IDENTIFIER ::= { entityStateMIB 0 }

and use 'entStateNotifs' in the corresponding NOTIFICATION-TYPE

Reason we would like to avoid name 'Traps' is: Latest RFCs refer them
as Notifications

Also, above OID tree structure will be inline with mib review 
guidelines document: draft-ietf-ops-mib-review-guidelines-02.txt

    

I agree with that ... and I would even say:

  entStateNotifications OBJECT IDENTIFIER ::= { entityStateMIB 0 }

Why make the descriptor more cryptic than needed?

Bert

_______________________________________________
Entmib mailing list
Entmib@ietf.org
https://www1.ietf.org/mailman/listinfo/entmib
--------------050806010806010604000203-- _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Sun Feb 8 18:02: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 SAA05625 for ; Sun, 8 Feb 2004 18:02:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apxw9-0002hS-B5; Sun, 08 Feb 2004 18:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apxvj-0002LI-Uu for entmib@optimus.ietf.org; Sun, 08 Feb 2004 18:01:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05619 for ; Sun, 8 Feb 2004 18:01:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apxvh-00021r-00 for entmib@ietf.org; Sun, 08 Feb 2004 18:01:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Apxuj-0001yD-00 for entmib@ietf.org; Sun, 08 Feb 2004 18:00:34 -0500 Received: from smtp.exodus.net ([66.35.230.236]) by ietf-mx with esmtp (Exim 4.12) id 1ApxuI-0001uj-00 for entmib@ietf.org; Sun, 08 Feb 2004 18:00:06 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp.exodus.net (8.12.8/8.12.8) with ESMTP id i190cVw3029271 for ; Sun, 8 Feb 2004 16:38:31 -0800 Received: from ala-mrwtemp.thingmagic.com (unverified [24.61.30.237]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id ; Sun, 8 Feb 2004 14:59:36 -0800 Message-Id: <5.1.0.14.2.20040207080722.041c73f0@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 08 Feb 2004 17:56:10 -0500 To: "Sharon Chisholm" From: Margaret Wasserman Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB Cc: entmib@ietf.org In-Reply-To: <3549C09B853DD5119B540002A52CDD340A1792C7@zcard0ka.ca.norte l.com> Mime-Version: 1.0 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: , We originally considered doing the state/status extensions as part of the Entity MIB, and those first discussion did mention a single object. However, by November 2002 we had a much more complex model and agreed that it would be better to do this as a separate MIB. We agreed to accept the Entity State MIB as a WG document before March 2003, and at that time it was at least as complex as it is now. We've been working on this MIB for over a year, and I believe that it should take WG consensus to make a major change to it now. Do others agree? In Minneapolis, the complexity of this MIB was raised as an issue. There was a general sense of the room that the MIB was too complex, but many people who were involved in earlier discussions, including the editor, weren't present. When the discussion was brought to the mailing list, I did not see clear consensus that we need to reduce the complexity of the MIB. Sharon did try to address concerns about the complexity of this MIB in the latest version by simplifying and streamlining the description. So, where do we stand on this issue? Are there others who have read the current MIB and strongly believe that it needs to be simplified? Or not? Margaret At 02:28 PM 2/6/2004 -0500, Sharon Chisholm wrote: >Hi > >I don't understand where the impression that we were only planning on adding >a single object that gave operational status came from. My early >presentations on this topic outlined a large number of state objects that >could be defined and from that we whittled down to what we thought was a >reasonable set. Some people wanted more and some people wanted less. > >Sharon > >-----Original Message----- >From: Andy Bierman [mailto:abierman@cisco.com] >Sent: Friday, February 06, 2004 11:27 AM >To: Wijnen, Bert (Bert) >Cc: 'Margaret Wasserman'; entmib@ietf.org >Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB > > >At 03:30 AM 2/6/2004, Wijnen, Bert (Bert) wrote: > >> Given that this is a second WG Last Call for this document, that > >> several people reviewed it during the previous WG Last Call, and that > >> Sharon did a great job of maintaining an issue list and documenting > >> the resolution of each issue, I am planning to interpret silence as > >> agreement to send this document to the IESG. > >> > >I do not want to step on the toes of our WG chair, but yet... I would > >actually appreciate if the people who spoke up (a while ago) that the > >MIB was too complex, that they do state if they are now OK with this > >version! > > > >PLEASE PARTICIPATE and express your opinion. > >okay, okay... > >I do not approve of, or object to, the Entity State MIB >going forward. > >My concerns are regarding the intent of the MIB -- the >actual problem being addressed. So I looked to the >Entmib WG charter page for guidance. This is all it >says about the Entity State MIB: > > Done Publish state/status extensions as a WG I-D > > Mar 04 Submit Entity State MIB to the IESG for Proposed Standard > >Not a word about the problem being addressed. > >I thought we set out to add an 'operStatus' object for >physical entities -- a simple ( green, yellow, red ) >status indicator. Applications would still need to >know how to use other MIBs to diagnose or correct a fault. >IMO, there's not much value in a generic indicator beyond >this, so it's best to keep it simple. > > From the draft: > > "Objects are defined to capture administrative, operational and usage > states. In addition there are further state objects defined to > provide additional information for these three basic states." > >The document clearly attempts to provide more functionality than a simple >'operStatus' object. The authors have done a fine job defining and >documenting this functionality. > >In order to discuss how well a MIB addresses its intended function, we have >to agree on the intended function. > > > >Bert > >Andy > > > >> So, if you have any objection to submitting this document for > >> publication as a Proposed Standard, please make that clear by Friday. > >> > >> Thanks, > >> Margaret > >> > >> > >> >Date: Fri, 23 Jan 2004 17:00:59 -0500 > >> >To: Entmib@ietf.org > >> >From: Margaret Wasserman > >> > > >> >Hi All, > >> > > >> >This is a two week WG Last Call for submitting the Entity State MIB > >> >to the IESG for publication as a Proposed Standard. The latest > >> >version of this document can be found at: > >> > > >> >http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-02.txt > >> > > >> >This WG Last Call will end on Friday, February 6th at 5pm EST. > >> > > >> >Please review the document and forward substantive comments to > >> >the mailing list. Editorial comments can be sent directly > >> >to the authors. > >> > > >> >Thanks, > >> >Margaret > >> > > >> > > >> > > >> >_______________________________________________ > >> >Entmib mailing list > >> >Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib > >> > >> > >> _______________________________________________ > >> Entmib mailing list > >> Entmib@ietf.org > >> https://www1.ietf.org/mailman/listinfo/entmib > >> > > > >_______________________________________________ > >Entmib mailing list > >Entmib@ietf.org > >https://www1.ietf.org/mailman/listinfo/entmib > > >_______________________________________________ >Entmib mailing list >Entmib@ietf.org >https://www1.ietf.org/mailman/listinfo/entmib > >_______________________________________________ >Entmib 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 Feb 8 18:02: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 SAA05628 for ; Sun, 8 Feb 2004 18:02:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApxwA-0002iL-0O for entmib-archive@odin.ietf.org; Sun, 08 Feb 2004 18:02:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18N21ig010425 for entmib-archive@odin.ietf.org; Sun, 8 Feb 2004 18:02:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apxw9-0002hS-B5; Sun, 08 Feb 2004 18:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apxvj-0002LI-Uu for entmib@optimus.ietf.org; Sun, 08 Feb 2004 18:01:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05619 for ; Sun, 8 Feb 2004 18:01:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apxvh-00021r-00 for entmib@ietf.org; Sun, 08 Feb 2004 18:01:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Apxuj-0001yD-00 for entmib@ietf.org; Sun, 08 Feb 2004 18:00:34 -0500 Received: from smtp.exodus.net ([66.35.230.236]) by ietf-mx with esmtp (Exim 4.12) id 1ApxuI-0001uj-00 for entmib@ietf.org; Sun, 08 Feb 2004 18:00:06 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp.exodus.net (8.12.8/8.12.8) with ESMTP id i190cVw3029271 for ; Sun, 8 Feb 2004 16:38:31 -0800 Received: from ala-mrwtemp.thingmagic.com (unverified [24.61.30.237]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id ; Sun, 8 Feb 2004 14:59:36 -0800 Message-Id: <5.1.0.14.2.20040207080722.041c73f0@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 08 Feb 2004 17:56:10 -0500 To: "Sharon Chisholm" From: Margaret Wasserman Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB Cc: entmib@ietf.org In-Reply-To: <3549C09B853DD5119B540002A52CDD340A1792C7@zcard0ka.ca.norte l.com> Mime-Version: 1.0 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: , We originally considered doing the state/status extensions as part of the Entity MIB, and those first discussion did mention a single object. However, by November 2002 we had a much more complex model and agreed that it would be better to do this as a separate MIB. We agreed to accept the Entity State MIB as a WG document before March 2003, and at that time it was at least as complex as it is now. We've been working on this MIB for over a year, and I believe that it should take WG consensus to make a major change to it now. Do others agree? In Minneapolis, the complexity of this MIB was raised as an issue. There was a general sense of the room that the MIB was too complex, but many people who were involved in earlier discussions, including the editor, weren't present. When the discussion was brought to the mailing list, I did not see clear consensus that we need to reduce the complexity of the MIB. Sharon did try to address concerns about the complexity of this MIB in the latest version by simplifying and streamlining the description. So, where do we stand on this issue? Are there others who have read the current MIB and strongly believe that it needs to be simplified? Or not? Margaret At 02:28 PM 2/6/2004 -0500, Sharon Chisholm wrote: >Hi > >I don't understand where the impression that we were only planning on adding >a single object that gave operational status came from. My early >presentations on this topic outlined a large number of state objects that >could be defined and from that we whittled down to what we thought was a >reasonable set. Some people wanted more and some people wanted less. > >Sharon > >-----Original Message----- >From: Andy Bierman [mailto:abierman@cisco.com] >Sent: Friday, February 06, 2004 11:27 AM >To: Wijnen, Bert (Bert) >Cc: 'Margaret Wasserman'; entmib@ietf.org >Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB > > >At 03:30 AM 2/6/2004, Wijnen, Bert (Bert) wrote: > >> Given that this is a second WG Last Call for this document, that > >> several people reviewed it during the previous WG Last Call, and that > >> Sharon did a great job of maintaining an issue list and documenting > >> the resolution of each issue, I am planning to interpret silence as > >> agreement to send this document to the IESG. > >> > >I do not want to step on the toes of our WG chair, but yet... I would > >actually appreciate if the people who spoke up (a while ago) that the > >MIB was too complex, that they do state if they are now OK with this > >version! > > > >PLEASE PARTICIPATE and express your opinion. > >okay, okay... > >I do not approve of, or object to, the Entity State MIB >going forward. > >My concerns are regarding the intent of the MIB -- the >actual problem being addressed. So I looked to the >Entmib WG charter page for guidance. This is all it >says about the Entity State MIB: > > Done Publish state/status extensions as a WG I-D > > Mar 04 Submit Entity State MIB to the IESG for Proposed Standard > >Not a word about the problem being addressed. > >I thought we set out to add an 'operStatus' object for >physical entities -- a simple ( green, yellow, red ) >status indicator. Applications would still need to >know how to use other MIBs to diagnose or correct a fault. >IMO, there's not much value in a generic indicator beyond >this, so it's best to keep it simple. > > From the draft: > > "Objects are defined to capture administrative, operational and usage > states. In addition there are further state objects defined to > provide additional information for these three basic states." > >The document clearly attempts to provide more functionality than a simple >'operStatus' object. The authors have done a fine job defining and >documenting this functionality. > >In order to discuss how well a MIB addresses its intended function, we have >to agree on the intended function. > > > >Bert > >Andy > > > >> So, if you have any objection to submitting this document for > >> publication as a Proposed Standard, please make that clear by Friday. > >> > >> Thanks, > >> Margaret > >> > >> > >> >Date: Fri, 23 Jan 2004 17:00:59 -0500 > >> >To: Entmib@ietf.org > >> >From: Margaret Wasserman > >> > > >> >Hi All, > >> > > >> >This is a two week WG Last Call for submitting the Entity State MIB > >> >to the IESG for publication as a Proposed Standard. The latest > >> >version of this document can be found at: > >> > > >> >http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-02.txt > >> > > >> >This WG Last Call will end on Friday, February 6th at 5pm EST. > >> > > >> >Please review the document and forward substantive comments to > >> >the mailing list. Editorial comments can be sent directly > >> >to the authors. > >> > > >> >Thanks, > >> >Margaret > >> > > >> > > >> > > >> >_______________________________________________ > >> >Entmib mailing list > >> >Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib > >> > >> > >> _______________________________________________ > >> Entmib mailing list > >> Entmib@ietf.org > >> https://www1.ietf.org/mailman/listinfo/entmib > >> > > > >_______________________________________________ > >Entmib mailing list > >Entmib@ietf.org > >https://www1.ietf.org/mailman/listinfo/entmib > > >_______________________________________________ >Entmib mailing list >Entmib@ietf.org >https://www1.ietf.org/mailman/listinfo/entmib > >_______________________________________________ >Entmib 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 Sun Feb 8 23:13: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 XAA16358 for ; Sun, 8 Feb 2004 23:13:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq2n5-0000bK-6w; Sun, 08 Feb 2004 23:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq2mp-0000b9-PF for entmib@optimus.ietf.org; Sun, 08 Feb 2004 23:12:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16352 for ; Sun, 8 Feb 2004 23:12:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq2mn-0003vb-00 for entmib@ietf.org; Sun, 08 Feb 2004 23:12:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq2ls-0003sK-00 for entmib@ietf.org; Sun, 08 Feb 2004 23:11:45 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aq2lf-0003oo-00 for entmib@ietf.org; Sun, 08 Feb 2004 23:11:31 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Feb 2004 20:18:07 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i194AxGv000776; Sun, 8 Feb 2004 20:11:00 -0800 (PST) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn3-390.cisco.com [10.21.65.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQS80620; Sun, 8 Feb 2004 20:10:59 -0800 (PST) Message-Id: <4.3.2.7.2.20040208195621.02444ab8@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 08 Feb 2004 20:07:59 -0800 To: Margaret Wasserman From: Andy Bierman Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB Cc: "Sharon Chisholm" , entmib@ietf.org In-Reply-To: <5.1.0.14.2.20040207080722.041c73f0@ms101.mail1.com> References: <3549C09B853DD5119B540002A52CDD340A1792C7@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: , At 02:56 PM 2/8/2004, Margaret Wasserman wrote: >We originally considered doing the state/status extensions as >part of the Entity MIB, and those first discussion did mention >a single object. However, by November 2002 we had a much more >complex model and agreed that it would be better to do this as >a separate MIB. > >We agreed to accept the Entity State MIB as a WG document before >March 2003, and at that time it was at least as complex as it is >now. We've been working on this MIB for over a year, and I >believe that it should take WG consensus to make a major >change to it now. Do others agree? > >In Minneapolis, the complexity of this MIB was raised as an issue. >There was a general sense of the room that the MIB was too >complex, but many people who were involved in earlier discussions, >including the editor, weren't present. When the discussion was >brought to the mailing list, I did not see clear consensus that >we need to reduce the complexity of the MIB. I don't disagree with you about the WG consensus. I'm not objecting to the MIB going forward. But I wouldn't be surprised if application developers end up writing a complex function to convert an entStateEntry to a simple LED-type enum for the entity. >Sharon did try to address concerns about the complexity of this >MIB in the latest version by simplifying and streamlining the >description. > >So, where do we stand on this issue? I'd say it's closed. The WG doesn't think a simple operStatus type of object is sufficient. >Are there others who have read the current MIB and strongly >believe that it needs to be simplified? Or not? I didn't ask for the MIB to be simplified. >Margaret Andy >At 02:28 PM 2/6/2004 -0500, Sharon Chisholm wrote: >>Hi >> >>I don't understand where the impression that we were only planning on adding >>a single object that gave operational status came from. My early >>presentations on this topic outlined a large number of state objects that >>could be defined and from that we whittled down to what we thought was a >>reasonable set. Some people wanted more and some people wanted less. >> >>Sharon >> >>-----Original Message----- >>From: Andy Bierman [mailto:abierman@cisco.com] >>Sent: Friday, February 06, 2004 11:27 AM >>To: Wijnen, Bert (Bert) >>Cc: 'Margaret Wasserman'; entmib@ietf.org >>Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB >> >> >>At 03:30 AM 2/6/2004, Wijnen, Bert (Bert) wrote: >>>> Given that this is a second WG Last Call for this document, that >>>> several people reviewed it during the previous WG Last Call, and that >>>> Sharon did a great job of maintaining an issue list and documenting >>>> the resolution of each issue, I am planning to interpret silence as >>>> agreement to send this document to the IESG. >>>> >>>I do not want to step on the toes of our WG chair, but yet... I would >>>actually appreciate if the people who spoke up (a while ago) that the >>>MIB was too complex, that they do state if they are now OK with this >>>version! >>> >>>PLEASE PARTICIPATE and express your opinion. >> >>okay, okay... >> >>I do not approve of, or object to, the Entity State MIB >>going forward. >> >>My concerns are regarding the intent of the MIB -- the >>actual problem being addressed. So I looked to the >>Entmib WG charter page for guidance. This is all it >>says about the Entity State MIB: >> >> Done Publish state/status extensions as a WG I-D >> >> Mar 04 Submit Entity State MIB to the IESG for Proposed Standard >> >>Not a word about the problem being addressed. >> >>I thought we set out to add an 'operStatus' object for >>physical entities -- a simple ( green, yellow, red ) >>status indicator. Applications would still need to >>know how to use other MIBs to diagnose or correct a fault. >>IMO, there's not much value in a generic indicator beyond >>this, so it's best to keep it simple. >> >> From the draft: >> >> "Objects are defined to capture administrative, operational and usage >> states. In addition there are further state objects defined to >> provide additional information for these three basic states." >> >>The document clearly attempts to provide more functionality than a simple >>'operStatus' object. The authors have done a fine job defining and >>documenting this functionality. >> >>In order to discuss how well a MIB addresses its intended function, we have >>to agree on the intended function. >> >> >>>Bert >> >>Andy >> >> >>>> So, if you have any objection to submitting this document for >>>> publication as a Proposed Standard, please make that clear by Friday. >>>> >>>> Thanks, >>>> Margaret >>>> >>>> >>>> >Date: Fri, 23 Jan 2004 17:00:59 -0500 >>>> >To: Entmib@ietf.org >>>> >From: Margaret Wasserman >>>> > >>>> >Hi All, >>>> > >>>> >This is a two week WG Last Call for submitting the Entity State MIB >>>> >to the IESG for publication as a Proposed Standard. The latest >>>> >version of this document can be found at: >>>> > >>>> >http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-02.txt >>>> > >>>> >This WG Last Call will end on Friday, February 6th at 5pm EST. >>>> > >>>> >Please review the document and forward substantive comments to >>>> >the mailing list. Editorial comments can be sent directly >>>> >to the authors. >>>> > >>>> >Thanks, >>>> >Margaret >>>> > >>>> > >>>> > >>>> >_______________________________________________ >>>> >Entmib mailing list >>>> >Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib >>>> >>>> >>>> _______________________________________________ >>>> Entmib mailing list >>>> Entmib@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/entmib >>>> >>> >>>_______________________________________________ >>>Entmib mailing list >>>Entmib@ietf.org >>>https://www1.ietf.org/mailman/listinfo/entmib >> >> >>_______________________________________________ >>Entmib mailing list >>Entmib@ietf.org >>https://www1.ietf.org/mailman/listinfo/entmib >> >>_______________________________________________ >>Entmib 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 Feb 8 23:13:29 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 XAA16368 for ; Sun, 8 Feb 2004 23:13:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq2n6-0000bV-Aw for entmib-archive@odin.ietf.org; Sun, 08 Feb 2004 23:13:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i194D0px002321 for entmib-archive@odin.ietf.org; Sun, 8 Feb 2004 23:13:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq2n5-0000bK-6w; Sun, 08 Feb 2004 23:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq2mp-0000b9-PF for entmib@optimus.ietf.org; Sun, 08 Feb 2004 23:12:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16352 for ; Sun, 8 Feb 2004 23:12:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq2mn-0003vb-00 for entmib@ietf.org; Sun, 08 Feb 2004 23:12:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq2ls-0003sK-00 for entmib@ietf.org; Sun, 08 Feb 2004 23:11:45 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aq2lf-0003oo-00 for entmib@ietf.org; Sun, 08 Feb 2004 23:11:31 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Feb 2004 20:18:07 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i194AxGv000776; Sun, 8 Feb 2004 20:11:00 -0800 (PST) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn3-390.cisco.com [10.21.65.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQS80620; Sun, 8 Feb 2004 20:10:59 -0800 (PST) Message-Id: <4.3.2.7.2.20040208195621.02444ab8@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 08 Feb 2004 20:07:59 -0800 To: Margaret Wasserman From: Andy Bierman Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB Cc: "Sharon Chisholm" , entmib@ietf.org In-Reply-To: <5.1.0.14.2.20040207080722.041c73f0@ms101.mail1.com> References: <3549C09B853DD5119B540002A52CDD340A1792C7@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: , At 02:56 PM 2/8/2004, Margaret Wasserman wrote: >We originally considered doing the state/status extensions as >part of the Entity MIB, and those first discussion did mention >a single object. However, by November 2002 we had a much more >complex model and agreed that it would be better to do this as >a separate MIB. > >We agreed to accept the Entity State MIB as a WG document before >March 2003, and at that time it was at least as complex as it is >now. We've been working on this MIB for over a year, and I >believe that it should take WG consensus to make a major >change to it now. Do others agree? > >In Minneapolis, the complexity of this MIB was raised as an issue. >There was a general sense of the room that the MIB was too >complex, but many people who were involved in earlier discussions, >including the editor, weren't present. When the discussion was >brought to the mailing list, I did not see clear consensus that >we need to reduce the complexity of the MIB. I don't disagree with you about the WG consensus. I'm not objecting to the MIB going forward. But I wouldn't be surprised if application developers end up writing a complex function to convert an entStateEntry to a simple LED-type enum for the entity. >Sharon did try to address concerns about the complexity of this >MIB in the latest version by simplifying and streamlining the >description. > >So, where do we stand on this issue? I'd say it's closed. The WG doesn't think a simple operStatus type of object is sufficient. >Are there others who have read the current MIB and strongly >believe that it needs to be simplified? Or not? I didn't ask for the MIB to be simplified. >Margaret Andy >At 02:28 PM 2/6/2004 -0500, Sharon Chisholm wrote: >>Hi >> >>I don't understand where the impression that we were only planning on adding >>a single object that gave operational status came from. My early >>presentations on this topic outlined a large number of state objects that >>could be defined and from that we whittled down to what we thought was a >>reasonable set. Some people wanted more and some people wanted less. >> >>Sharon >> >>-----Original Message----- >>From: Andy Bierman [mailto:abierman@cisco.com] >>Sent: Friday, February 06, 2004 11:27 AM >>To: Wijnen, Bert (Bert) >>Cc: 'Margaret Wasserman'; entmib@ietf.org >>Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB >> >> >>At 03:30 AM 2/6/2004, Wijnen, Bert (Bert) wrote: >>>> Given that this is a second WG Last Call for this document, that >>>> several people reviewed it during the previous WG Last Call, and that >>>> Sharon did a great job of maintaining an issue list and documenting >>>> the resolution of each issue, I am planning to interpret silence as >>>> agreement to send this document to the IESG. >>>> >>>I do not want to step on the toes of our WG chair, but yet... I would >>>actually appreciate if the people who spoke up (a while ago) that the >>>MIB was too complex, that they do state if they are now OK with this >>>version! >>> >>>PLEASE PARTICIPATE and express your opinion. >> >>okay, okay... >> >>I do not approve of, or object to, the Entity State MIB >>going forward. >> >>My concerns are regarding the intent of the MIB -- the >>actual problem being addressed. So I looked to the >>Entmib WG charter page for guidance. This is all it >>says about the Entity State MIB: >> >> Done Publish state/status extensions as a WG I-D >> >> Mar 04 Submit Entity State MIB to the IESG for Proposed Standard >> >>Not a word about the problem being addressed. >> >>I thought we set out to add an 'operStatus' object for >>physical entities -- a simple ( green, yellow, red ) >>status indicator. Applications would still need to >>know how to use other MIBs to diagnose or correct a fault. >>IMO, there's not much value in a generic indicator beyond >>this, so it's best to keep it simple. >> >> From the draft: >> >> "Objects are defined to capture administrative, operational and usage >> states. In addition there are further state objects defined to >> provide additional information for these three basic states." >> >>The document clearly attempts to provide more functionality than a simple >>'operStatus' object. The authors have done a fine job defining and >>documenting this functionality. >> >>In order to discuss how well a MIB addresses its intended function, we have >>to agree on the intended function. >> >> >>>Bert >> >>Andy >> >> >>>> So, if you have any objection to submitting this document for >>>> publication as a Proposed Standard, please make that clear by Friday. >>>> >>>> Thanks, >>>> Margaret >>>> >>>> >>>> >Date: Fri, 23 Jan 2004 17:00:59 -0500 >>>> >To: Entmib@ietf.org >>>> >From: Margaret Wasserman >>>> > >>>> >Hi All, >>>> > >>>> >This is a two week WG Last Call for submitting the Entity State MIB >>>> >to the IESG for publication as a Proposed Standard. The latest >>>> >version of this document can be found at: >>>> > >>>> >http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-02.txt >>>> > >>>> >This WG Last Call will end on Friday, February 6th at 5pm EST. >>>> > >>>> >Please review the document and forward substantive comments to >>>> >the mailing list. Editorial comments can be sent directly >>>> >to the authors. >>>> > >>>> >Thanks, >>>> >Margaret >>>> > >>>> > >>>> > >>>> >_______________________________________________ >>>> >Entmib mailing list >>>> >Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib >>>> >>>> >>>> _______________________________________________ >>>> Entmib mailing list >>>> Entmib@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/entmib >>>> >>> >>>_______________________________________________ >>>Entmib mailing list >>>Entmib@ietf.org >>>https://www1.ietf.org/mailman/listinfo/entmib >> >> >>_______________________________________________ >>Entmib mailing list >>Entmib@ietf.org >>https://www1.ietf.org/mailman/listinfo/entmib >> >>_______________________________________________ >>Entmib 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 Feb 9 08:22:29 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 IAA17706 for ; Mon, 9 Feb 2004 08:22:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqBMO-00067g-AV; Mon, 09 Feb 2004 08:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqBLW-00062f-Ux for entmib@optimus.ietf.org; Mon, 09 Feb 2004 08:21:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17656 for ; Mon, 9 Feb 2004 08:21:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqBLV-0004bP-00 for entmib@ietf.org; Mon, 09 Feb 2004 08:21:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqBKY-0004Wu-00 for entmib@ietf.org; Mon, 09 Feb 2004 08:20:07 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqBK8-0004SH-00 for entmib@ietf.org; Mon, 09 Feb 2004 08:19:40 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 2A5D88503A; Mon, 9 Feb 2004 14:19:09 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.54]) by merkur.iu-bremen.de (Postfix) with ESMTP id 534CB84BC0; Mon, 9 Feb 2004 14:19:08 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 480238838; Mon, 9 Feb 2004 14:19:08 +0100 (CET) Date: Mon, 9 Feb 2004 14:19:08 +0100 From: Juergen Schoenwaelder To: Margaret Wasserman Cc: entmib@ietf.org Subject: Re: REMINDER: [Entmib] WG Last Call: Entity State MIB Message-ID: <20040209131908.GA1174@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Margaret Wasserman , entmib@ietf.org References: <5.1.0.14.2.20040205160724.03d1d870@ms101.mail1.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20040205160724.03d1d870@ms101.mail1.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by AMaViS 0.3.12pre8 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=none 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: , On Thu, Feb 05, 2004 at 04:11:40PM -0500, Margaret Wasserman wrote: > Just a reminder that we are currently in WG Last Call for the > Entity State MIB. Please review this document before Friday > and send your feedback (positive or negative) to the list. I could not get email out during the weekend. Anyway, here is what I wrote down on this subject... I have reviewed and I like the approach, as I have already said before. Below are some review comments to take into account. Most are just editorial while some might require some further discussion/thinking. 1) Change the end of the abstract from provide information about the state of the entity. to the following: provide information about the state of physical entities. Rationale: This MIB is specific to physical entities and since the ENTITY-MIB also has the concept of logical entities, I think it is better to more precise. 2) Description of StandByStatus, change "... but is will be immediately ..." to the following: "... but will be immediately ..." 3) Description of entStateLastChanged, change DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed, or zero." to the following: DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed, or '0000000000000000'H." 4) Description of entStateAdmin. I believe the following two sentences are kind of a contradiction: [...] This object can not be administratively set to 'notSupported'. For entities that do not support administrative state, changing the value of this object to something other than 'notSupported' is not permitted. A value of 'inconsistentValue' will be returned in either case. With the text in the second paragraph of the description clause, I think this can be fixed by just removing a sentence without loosing anything: [...] This object can not be administratively set to 'notSupported'. A value of 'inconsistentValue' will be returned in either case. 5) Several description clauses refer to "entities within its containment hierarchy" followed by a sentence which limits this to the entities "having a value of entPhysicalContainedIn that refers to this entity". This somehow excludes transitive containment. Is this by intention or accident? I mean, if I have C contained in B contained in A, then A still provides indirect service to C. 6) AlarmStatus TC: I do not really understand the alarmOutStanding bit. It seems like this is set whenever one of critical, major, minor, warning and indeterminate is set. But if this is true, I think the bit is not really terrible useful. Perhaps the bit has some other meaning. If so, please clarify. 7) The MIB did not compile because you once use entStateNotificationGroup and once you use entStateNotificationsGroup (see the plural s). Pick one. 8) I was surprised to read the entStateUsage description which says the UsageState is strictly bound to the containment relationship between entities. In general, the containment hierarchy is made up of containers and leafs. The entStateUsage description basically says that the UsageState is only interesting for containers since leafs are always busy. I found this interesting since the other objects do not make this distinction and some of them seem to particularly useful for leafs (e.g. interfaces). Perhaps it makes sense to define for each entState* column how it applies to containers and how it applies to leafs. For example, what does it mean to lock/unlock a container? (I believe entStateAdmin is more defined for leafs rather than containers.) 9) I am wondering why both notifications contain the entStateAlarm value, especially entStateOperEnabled notification. This surely is not wrong, but I am wondering what the rationale for including the entStateAlarm is (and for excluding other objects). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Mon Feb 9 08:22:29 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 IAA17719 for ; Mon, 9 Feb 2004 08:22:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqBMP-000683-42 for entmib-archive@odin.ietf.org; Mon, 09 Feb 2004 08:22:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19DM1kQ023547 for entmib-archive@odin.ietf.org; Mon, 9 Feb 2004 08:22:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqBMO-00067g-AV; Mon, 09 Feb 2004 08:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqBLW-00062f-Ux for entmib@optimus.ietf.org; Mon, 09 Feb 2004 08:21:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17656 for ; Mon, 9 Feb 2004 08:21:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqBLV-0004bP-00 for entmib@ietf.org; Mon, 09 Feb 2004 08:21:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqBKY-0004Wu-00 for entmib@ietf.org; Mon, 09 Feb 2004 08:20:07 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqBK8-0004SH-00 for entmib@ietf.org; Mon, 09 Feb 2004 08:19:40 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 2A5D88503A; Mon, 9 Feb 2004 14:19:09 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.54]) by merkur.iu-bremen.de (Postfix) with ESMTP id 534CB84BC0; Mon, 9 Feb 2004 14:19:08 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 480238838; Mon, 9 Feb 2004 14:19:08 +0100 (CET) Date: Mon, 9 Feb 2004 14:19:08 +0100 From: Juergen Schoenwaelder To: Margaret Wasserman Cc: entmib@ietf.org Subject: Re: REMINDER: [Entmib] WG Last Call: Entity State MIB Message-ID: <20040209131908.GA1174@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Margaret Wasserman , entmib@ietf.org References: <5.1.0.14.2.20040205160724.03d1d870@ms101.mail1.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20040205160724.03d1d870@ms101.mail1.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by AMaViS 0.3.12pre8 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=none 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: , On Thu, Feb 05, 2004 at 04:11:40PM -0500, Margaret Wasserman wrote: > Just a reminder that we are currently in WG Last Call for the > Entity State MIB. Please review this document before Friday > and send your feedback (positive or negative) to the list. I could not get email out during the weekend. Anyway, here is what I wrote down on this subject... I have reviewed and I like the approach, as I have already said before. Below are some review comments to take into account. Most are just editorial while some might require some further discussion/thinking. 1) Change the end of the abstract from provide information about the state of the entity. to the following: provide information about the state of physical entities. Rationale: This MIB is specific to physical entities and since the ENTITY-MIB also has the concept of logical entities, I think it is better to more precise. 2) Description of StandByStatus, change "... but is will be immediately ..." to the following: "... but will be immediately ..." 3) Description of entStateLastChanged, change DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed, or zero." to the following: DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed, or '0000000000000000'H." 4) Description of entStateAdmin. I believe the following two sentences are kind of a contradiction: [...] This object can not be administratively set to 'notSupported'. For entities that do not support administrative state, changing the value of this object to something other than 'notSupported' is not permitted. A value of 'inconsistentValue' will be returned in either case. With the text in the second paragraph of the description clause, I think this can be fixed by just removing a sentence without loosing anything: [...] This object can not be administratively set to 'notSupported'. A value of 'inconsistentValue' will be returned in either case. 5) Several description clauses refer to "entities within its containment hierarchy" followed by a sentence which limits this to the entities "having a value of entPhysicalContainedIn that refers to this entity". This somehow excludes transitive containment. Is this by intention or accident? I mean, if I have C contained in B contained in A, then A still provides indirect service to C. 6) AlarmStatus TC: I do not really understand the alarmOutStanding bit. It seems like this is set whenever one of critical, major, minor, warning and indeterminate is set. But if this is true, I think the bit is not really terrible useful. Perhaps the bit has some other meaning. If so, please clarify. 7) The MIB did not compile because you once use entStateNotificationGroup and once you use entStateNotificationsGroup (see the plural s). Pick one. 8) I was surprised to read the entStateUsage description which says the UsageState is strictly bound to the containment relationship between entities. In general, the containment hierarchy is made up of containers and leafs. The entStateUsage description basically says that the UsageState is only interesting for containers since leafs are always busy. I found this interesting since the other objects do not make this distinction and some of them seem to particularly useful for leafs (e.g. interfaces). Perhaps it makes sense to define for each entState* column how it applies to containers and how it applies to leafs. For example, what does it mean to lock/unlock a container? (I believe entStateAdmin is more defined for leafs rather than containers.) 9) I am wondering why both notifications contain the entStateAlarm value, especially entStateOperEnabled notification. This surely is not wrong, but I am wondering what the rationale for including the entStateAlarm is (and for excluding other objects). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Tue Feb 10 11:52:29 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 LAA27072 for ; Tue, 10 Feb 2004 11:52:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqb7B-0005r4-4R; Tue, 10 Feb 2004 11:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqb77-0005qU-30 for entmib@optimus.ietf.org; Tue, 10 Feb 2004 11:51:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27043 for ; Tue, 10 Feb 2004 11:51:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqb75-0004AE-00 for entmib@ietf.org; Tue, 10 Feb 2004 11:51:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqb6A-00043X-00 for entmib@ietf.org; Tue, 10 Feb 2004 11:51:00 -0500 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqb5K-0003qx-00 for entmib@ietf.org; Tue, 10 Feb 2004 11:50:06 -0500 Received: from shannon.research.telcordia.com (shannon-83.research.telcordia.com [128.96.83.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id i1AGnZai028903 for ; Tue, 10 Feb 2004 11:49:35 -0500 (EST) 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 LAA29854 for ; Tue, 10 Feb 2004 11:49:35 -0500 (EST) Message-Id: <4.3.2.7.2.20040210113836.01745038@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Feb 2004 11:48:28 -0500 To: entmib@ietf.org From: Kaj Tesink Subject: Fwd: [Entmib] Re: Entity mib support for tcif Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_-1896715443==_" 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=0.0 required=5.0 tests=none 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: , --=====================_-1896715443==_ Content-Type: text/plain; charset="us-ascii"; format=flowed all, the draft i sent to the list last week is now available at http://www.ietf.org/internet-drafts/draft-tesink-entity-supplmib-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 > > >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 --=====================_-1896715443==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-entity-supplmib-001.txt" Entity MIB Working Group Kaj Tesink INTERNET DRAFT Telcordia Technologies February 1, 2004 Definitions of Supplemental Entity Managed Objects Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it describes additional objects that supplement those defined in the Definitions of Managed Objects for the Entity MIB document [RFCzzzz]. Expires 08/01/2004 Entity Supplemental Objects [Page 1] Internet Draft 02/01/2004 Table of Contents 1 Conventions ............................................... 3 2 The Internet-Standard Management Framework ................ 3 3 Overview .................................................. 3 3.1 entSupplPhysicalManufacturingDate ....................... 3 3.2 entSupplPhysicalInfo .................................... 3 4 Object Definitions ........................................ 5 5 Intellectual Property ..................................... 9 6 Acknowledgments ........................................... 10 7 Security Considerations ................................... 11 8 References ................................................ 12 8.1 Normative References .................................... 12 8.2 Informative References .................................. 12 9 Author's Address .......................................... 12 Full Copyright Statement ................................... 13 Expires 08/01/2004 Entity Supplemental Objects [Page 2] Internet Draft 02/01/2004 1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL", when they appear in this document, are to be interpreted as described in RFC 2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Overview The objects defined in this memo are used in conjunction with objects defined in the Entity MIB [RFCzzzz]. The MIB module defined in this memo is a sparse augmentation of the entPhysicalTable of the ENTITY- MIB -- i.e., it is REQUIRED that an agent implementing objects defined in this memo also implement the relevant ENTITY-MIB objects. The purpose of the augmentation of the entPhysicalTable is to define a managed object for the manufacturing date of a managed entity, and a managed object to support additional information related to the managed entity. 3.1. entSupplPhysicalManufacturingDate This object contains the date of manufacturing of the managed entity. If the manufacturing date is unknown or not supported the object is not instantiated. 3.2. entSupplPhysicalInfo This object provides additional information about the managed entity. For example, this object may be used to encode a CLEI (Common Language Equipment Identifier) Code [T1.213][T1.213a] for the managed physical entity by setting the prefix to the OID cleiCode, and by embedding the 10 octet CLEI code as the 10 subsequent components of Expires 08/01/2004 Entity Supplemental Objects [Page 3] Internet Draft 02/01/2004 the suffix, i.e., cleiCode.A.B.C.D.E.F.G.H.I.J. If no additional information is known or supported about the managed entity the object is not instantiated. Expires 08/01/2004 Entity Supplemental Objects [Page 4] Internet Draft 02/01/2004 4. Object Definitions ENTSUPPL-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, transmission FROM SNMPv2-SMI DateAndTime FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF entPhysicalIndex FROM ENTITY-MIB; entitySupplMIB MODULE-IDENTITY LAST-UPDATED "200402010000Z" -- February 1, 2004 ORGANIZATION "IETF Entity MIB Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/entmib-charter.html Mailing Lists: General Discussion: entmib@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/entmib Chair: Margaret Wasserman Postal: Tel: E-mail: margaret@thingmagic.com Author: Kaj Tesink Postal: 331 Newman Springs Road Red Bank, NJ 07701 USA Tel: +1 732-758-5254 E-mail: kaj@research.telcordia.com" Expires 08/01/2004 Entity Supplemental Objects [Page 5] Internet Draft 02/01/2004 DESCRIPTION "The objects in this MIB module are used in conjunction with objects in the ENTITY-MIB to manage entities Copyright (C) The Internet Society (2004). This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." -- RFC Ed.: replace yyyy with actual RFC number & remove this notice REVISION "200402010000Z " -- February 1, 2004 DESCRIPTION "Initial version, published as RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this notice ::= { transmission XXX } -- RFC Ed.: replace XXX with IANA-assigned number & remove this notice Expires 08/01/2004 Entity Supplemental Objects [Page 6] Internet Draft 02/01/2004 -- The main sections of the module entitySupplObjects OBJECT IDENTIFIER ::= { entitySupplMIB 1 } entitySupplConformance OBJECT IDENTIFIER ::= { entitySupplMIB 2 } -- These objects provide extensions to the entPhysicalTable. entSupplPhysicalTable OBJECT-TYPE SYNTAX SEQUENCE OF EntSupplPhysicalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table for supplementary objects to the entPhysicalTable." ::= { entitySupplObjects 1 } entSupplPhysicalEntry OBJECT-TYPE SYNTAX EntSupplPhysicalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the entSupplPhysicalTable. For each instance of this object there MUST be a corresponding instance of entPhysicalEntry." INDEX { entPhysicalIndex } ::= { entSupplPhysicalTable 1 } EntSupplPhysicalEntry ::= SEQUENCE { entSupplPhysicalManufacturingDate DateAndTime, entSupplPhysicalInfo OCTET STRING } entSupplPhysicalManufacturingDate OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The manufacturing date for the physical entity." ::= { entSupplPhysicalEntry 1 } entSupplPhysicalInfo OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write Expires 08/01/2004 Entity Supplemental Objects [Page 7] Internet Draft 02/01/2004 STATUS current DESCRIPTION "This object contains additional information about the entity. The encoding of this object is prefix.suffix where prefix represents an OID that identifies the use of the suffix, and suffix is encoded as defined for that prefix." ::= { entSupplPhysicalEntry 2 } cleiCode OBJECT-IDENTITY STATUS current DESCRIPTION "Object identity for CLEI (Common Language Equipment Identifier) Code." REFERENCE "TCIF-02-004, Guideline for data elements included in the Management Information Base, Telecommunications Industry Forum (TCIF), 09/11/2002. ANSI T1.213, Coded identification of equipment entities of the North American telecommunications system for information exchange, ANSI. ANSI T1.213a, Supplement to T1.213, 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." ::= { entitySupplObjects 2 } -- -- Conformance Statements -- entitySupplGroups OBJECT IDENTIFIER ::= { entitySupplConformance 1 } entitySupplCompliances OBJECT IDENTIFIER ::= { entitySupplConformance 2 } -- Object Groups entitySupplPhysicalGroup OBJECT-GROUP OBJECTS { Expires 08/01/2004 Entity Supplemental Objects [Page 8] Internet Draft 02/01/2004 entSupplPhysicalManufacturingDate, entSupplPhysicalInfo } STATUS current DESCRIPTION "A collection of supplemental objects for to support physical entity features." ::= { entitySupplGroups 1 } -- Compliance Statements entitySupplCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that support this module. Compliance with the entity3Compliance statement of the ENTITY-MIB is prerequisite." MODULE -- this module MANDATORY-GROUPS { entitySupplPhysicalGroup } OBJECT entSupplPhysicalInfo MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { entitySupplCompliances 1 } END 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. Expires 08/01/2004 Entity Supplemental Objects [Page 9] Internet Draft 02/01/2004 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 6. Acknowledgments This document is a product of the Entity MIB Working Group. Expires 08/01/2004 Entity Supplemental Objects [Page 10] Internet Draft 02/01/2004 7. Security Considerations entSupplPhysicalInfo defined in this MIB module has a MAX-ACCESS clause of read-write; erroreous or unauthorized Writing of this object will result in the provision of misleading information to network management systems. The user of this MIB module must therefore be aware that support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The readable objects in this MIB module (i.e., those with MAX-ACCESS other than not-accessible) may be considered sensitive in some environments since, collectively, they provide information about the managed entities and can reveal some aspects of their configuration. In such environments it is important to control even GET and NOTIFY access to these objects and possibly even to encrypt their values when sending them over the network via SNMP. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Expires 08/01/2004 Entity Supplemental Objects [Page 11] Internet Draft 02/01/2004 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFCzzzz] Bierman, A., McCloghrie, K., "Entity MIB (Version 3)", RFCzzzz. 8.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [T1.213] ANSI T1.213, Coded identification of equipment entities of the North American telecommunications system for information exchange, ANSI. [T1.213a] ANSI T1.213a, Supplement to T1.213, 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." 9. Author's Address Kaj Tesink 331 Newman Springs Road Red Bank, NJ 07701 USA Phone: +1 732 758-5254 EMail: kaj@research.telcordia.com Expires 08/01/2004 Entity Supplemental Objects [Page 12] Internet Draft 02/01/2004 Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires 08/01/2004 Entity Supplemental Objects [Page 13] Internet Draft 02/01/2004 ************************************************************ * NOTES TO RFC Editor (to be removed prior to publication) * * * * 1.) The normative references [RFCzzzz] * * must be updated to point to the appropriate * * RFC when the corresponding Internet Draft is published, * * and all occurrences of the reference tags must be * * changed. * * * * 2.) Please replace all occurrences of "yyyy" in the * * DESCRIPTION clause of the MODULE-IDENTITY invocation * * in Section 4 with the RFC number assigned to this * * specification and remove the accompanying notes. * * * * 3.) Please replace "XXX" in the MODULE-IDENTITY value * * with an IANA-assigned value under the 'transmission' * * subtree and remove the accompanying note. * * * ************************************************************ Expires 08/01/2004 Entity Supplemental Objects [Page 14] --=====================_-1896715443==_ Content-Type: text/plain; charset="us-ascii"; format=flowed _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ 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 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ --=====================_-1896715443==_-- _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Tue Feb 10 11:52:36 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 LAA27090 for ; Tue, 10 Feb 2004 11:52:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqb7B-0005rJ-LB for entmib-archive@odin.ietf.org; Tue, 10 Feb 2004 11:52:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AGq1e3022517 for entmib-archive@odin.ietf.org; Tue, 10 Feb 2004 11:52:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqb7B-0005r4-4R; Tue, 10 Feb 2004 11:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqb77-0005qU-30 for entmib@optimus.ietf.org; Tue, 10 Feb 2004 11:51:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27043 for ; Tue, 10 Feb 2004 11:51:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqb75-0004AE-00 for entmib@ietf.org; Tue, 10 Feb 2004 11:51:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqb6A-00043X-00 for entmib@ietf.org; Tue, 10 Feb 2004 11:51:00 -0500 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqb5K-0003qx-00 for entmib@ietf.org; Tue, 10 Feb 2004 11:50:06 -0500 Received: from shannon.research.telcordia.com (shannon-83.research.telcordia.com [128.96.83.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id i1AGnZai028903 for ; Tue, 10 Feb 2004 11:49:35 -0500 (EST) 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 LAA29854 for ; Tue, 10 Feb 2004 11:49:35 -0500 (EST) Message-Id: <4.3.2.7.2.20040210113836.01745038@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Feb 2004 11:48:28 -0500 To: entmib@ietf.org From: Kaj Tesink Subject: Fwd: [Entmib] Re: Entity mib support for tcif Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_-1896715443==_" 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=0.0 required=5.0 tests=none 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: , --=====================_-1896715443==_ Content-Type: text/plain; charset="us-ascii"; format=flowed all, the draft i sent to the list last week is now available at http://www.ietf.org/internet-drafts/draft-tesink-entity-supplmib-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 > > >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 --=====================_-1896715443==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-entity-supplmib-001.txt" Entity MIB Working Group Kaj Tesink INTERNET DRAFT Telcordia Technologies February 1, 2004 Definitions of Supplemental Entity Managed Objects Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it describes additional objects that supplement those defined in the Definitions of Managed Objects for the Entity MIB document [RFCzzzz]. Expires 08/01/2004 Entity Supplemental Objects [Page 1] Internet Draft 02/01/2004 Table of Contents 1 Conventions ............................................... 3 2 The Internet-Standard Management Framework ................ 3 3 Overview .................................................. 3 3.1 entSupplPhysicalManufacturingDate ....................... 3 3.2 entSupplPhysicalInfo .................................... 3 4 Object Definitions ........................................ 5 5 Intellectual Property ..................................... 9 6 Acknowledgments ........................................... 10 7 Security Considerations ................................... 11 8 References ................................................ 12 8.1 Normative References .................................... 12 8.2 Informative References .................................. 12 9 Author's Address .......................................... 12 Full Copyright Statement ................................... 13 Expires 08/01/2004 Entity Supplemental Objects [Page 2] Internet Draft 02/01/2004 1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL", when they appear in this document, are to be interpreted as described in RFC 2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Overview The objects defined in this memo are used in conjunction with objects defined in the Entity MIB [RFCzzzz]. The MIB module defined in this memo is a sparse augmentation of the entPhysicalTable of the ENTITY- MIB -- i.e., it is REQUIRED that an agent implementing objects defined in this memo also implement the relevant ENTITY-MIB objects. The purpose of the augmentation of the entPhysicalTable is to define a managed object for the manufacturing date of a managed entity, and a managed object to support additional information related to the managed entity. 3.1. entSupplPhysicalManufacturingDate This object contains the date of manufacturing of the managed entity. If the manufacturing date is unknown or not supported the object is not instantiated. 3.2. entSupplPhysicalInfo This object provides additional information about the managed entity. For example, this object may be used to encode a CLEI (Common Language Equipment Identifier) Code [T1.213][T1.213a] for the managed physical entity by setting the prefix to the OID cleiCode, and by embedding the 10 octet CLEI code as the 10 subsequent components of Expires 08/01/2004 Entity Supplemental Objects [Page 3] Internet Draft 02/01/2004 the suffix, i.e., cleiCode.A.B.C.D.E.F.G.H.I.J. If no additional information is known or supported about the managed entity the object is not instantiated. Expires 08/01/2004 Entity Supplemental Objects [Page 4] Internet Draft 02/01/2004 4. Object Definitions ENTSUPPL-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, transmission FROM SNMPv2-SMI DateAndTime FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF entPhysicalIndex FROM ENTITY-MIB; entitySupplMIB MODULE-IDENTITY LAST-UPDATED "200402010000Z" -- February 1, 2004 ORGANIZATION "IETF Entity MIB Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/entmib-charter.html Mailing Lists: General Discussion: entmib@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/entmib Chair: Margaret Wasserman Postal: Tel: E-mail: margaret@thingmagic.com Author: Kaj Tesink Postal: 331 Newman Springs Road Red Bank, NJ 07701 USA Tel: +1 732-758-5254 E-mail: kaj@research.telcordia.com" Expires 08/01/2004 Entity Supplemental Objects [Page 5] Internet Draft 02/01/2004 DESCRIPTION "The objects in this MIB module are used in conjunction with objects in the ENTITY-MIB to manage entities Copyright (C) The Internet Society (2004). This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." -- RFC Ed.: replace yyyy with actual RFC number & remove this notice REVISION "200402010000Z " -- February 1, 2004 DESCRIPTION "Initial version, published as RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this notice ::= { transmission XXX } -- RFC Ed.: replace XXX with IANA-assigned number & remove this notice Expires 08/01/2004 Entity Supplemental Objects [Page 6] Internet Draft 02/01/2004 -- The main sections of the module entitySupplObjects OBJECT IDENTIFIER ::= { entitySupplMIB 1 } entitySupplConformance OBJECT IDENTIFIER ::= { entitySupplMIB 2 } -- These objects provide extensions to the entPhysicalTable. entSupplPhysicalTable OBJECT-TYPE SYNTAX SEQUENCE OF EntSupplPhysicalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table for supplementary objects to the entPhysicalTable." ::= { entitySupplObjects 1 } entSupplPhysicalEntry OBJECT-TYPE SYNTAX EntSupplPhysicalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the entSupplPhysicalTable. For each instance of this object there MUST be a corresponding instance of entPhysicalEntry." INDEX { entPhysicalIndex } ::= { entSupplPhysicalTable 1 } EntSupplPhysicalEntry ::= SEQUENCE { entSupplPhysicalManufacturingDate DateAndTime, entSupplPhysicalInfo OCTET STRING } entSupplPhysicalManufacturingDate OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The manufacturing date for the physical entity." ::= { entSupplPhysicalEntry 1 } entSupplPhysicalInfo OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write Expires 08/01/2004 Entity Supplemental Objects [Page 7] Internet Draft 02/01/2004 STATUS current DESCRIPTION "This object contains additional information about the entity. The encoding of this object is prefix.suffix where prefix represents an OID that identifies the use of the suffix, and suffix is encoded as defined for that prefix." ::= { entSupplPhysicalEntry 2 } cleiCode OBJECT-IDENTITY STATUS current DESCRIPTION "Object identity for CLEI (Common Language Equipment Identifier) Code." REFERENCE "TCIF-02-004, Guideline for data elements included in the Management Information Base, Telecommunications Industry Forum (TCIF), 09/11/2002. ANSI T1.213, Coded identification of equipment entities of the North American telecommunications system for information exchange, ANSI. ANSI T1.213a, Supplement to T1.213, 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." ::= { entitySupplObjects 2 } -- -- Conformance Statements -- entitySupplGroups OBJECT IDENTIFIER ::= { entitySupplConformance 1 } entitySupplCompliances OBJECT IDENTIFIER ::= { entitySupplConformance 2 } -- Object Groups entitySupplPhysicalGroup OBJECT-GROUP OBJECTS { Expires 08/01/2004 Entity Supplemental Objects [Page 8] Internet Draft 02/01/2004 entSupplPhysicalManufacturingDate, entSupplPhysicalInfo } STATUS current DESCRIPTION "A collection of supplemental objects for to support physical entity features." ::= { entitySupplGroups 1 } -- Compliance Statements entitySupplCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that support this module. Compliance with the entity3Compliance statement of the ENTITY-MIB is prerequisite." MODULE -- this module MANDATORY-GROUPS { entitySupplPhysicalGroup } OBJECT entSupplPhysicalInfo MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { entitySupplCompliances 1 } END 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. Expires 08/01/2004 Entity Supplemental Objects [Page 9] Internet Draft 02/01/2004 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 6. Acknowledgments This document is a product of the Entity MIB Working Group. Expires 08/01/2004 Entity Supplemental Objects [Page 10] Internet Draft 02/01/2004 7. Security Considerations entSupplPhysicalInfo defined in this MIB module has a MAX-ACCESS clause of read-write; erroreous or unauthorized Writing of this object will result in the provision of misleading information to network management systems. The user of this MIB module must therefore be aware that support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The readable objects in this MIB module (i.e., those with MAX-ACCESS other than not-accessible) may be considered sensitive in some environments since, collectively, they provide information about the managed entities and can reveal some aspects of their configuration. In such environments it is important to control even GET and NOTIFY access to these objects and possibly even to encrypt their values when sending them over the network via SNMP. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Expires 08/01/2004 Entity Supplemental Objects [Page 11] Internet Draft 02/01/2004 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFCzzzz] Bierman, A., McCloghrie, K., "Entity MIB (Version 3)", RFCzzzz. 8.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [T1.213] ANSI T1.213, Coded identification of equipment entities of the North American telecommunications system for information exchange, ANSI. [T1.213a] ANSI T1.213a, Supplement to T1.213, 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." 9. Author's Address Kaj Tesink 331 Newman Springs Road Red Bank, NJ 07701 USA Phone: +1 732 758-5254 EMail: kaj@research.telcordia.com Expires 08/01/2004 Entity Supplemental Objects [Page 12] Internet Draft 02/01/2004 Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires 08/01/2004 Entity Supplemental Objects [Page 13] Internet Draft 02/01/2004 ************************************************************ * NOTES TO RFC Editor (to be removed prior to publication) * * * * 1.) The normative references [RFCzzzz] * * must be updated to point to the appropriate * * RFC when the corresponding Internet Draft is published, * * and all occurrences of the reference tags must be * * changed. * * * * 2.) Please replace all occurrences of "yyyy" in the * * DESCRIPTION clause of the MODULE-IDENTITY invocation * * in Section 4 with the RFC number assigned to this * * specification and remove the accompanying notes. * * * * 3.) Please replace "XXX" in the MODULE-IDENTITY value * * with an IANA-assigned value under the 'transmission' * * subtree and remove the accompanying note. * * * ************************************************************ Expires 08/01/2004 Entity Supplemental Objects [Page 14] --=====================_-1896715443==_ Content-Type: text/plain; charset="us-ascii"; format=flowed _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ 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 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ --=====================_-1896715443==_-- _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Tue Feb 10 15:06:29 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 PAA06573 for ; Tue, 10 Feb 2004 15:06:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqe8v-0002b7-MZ; Tue, 10 Feb 2004 15:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqe8B-0002Bx-DY for entmib@optimus.ietf.org; Tue, 10 Feb 2004 15:05:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06401 for ; Tue, 10 Feb 2004 15:05:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqe88-0001td-00 for entmib@ietf.org; Tue, 10 Feb 2004 15:05:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqe7J-0001nU-00 for entmib@ietf.org; Tue, 10 Feb 2004 15:04:22 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1Aqe6p-0001gU-00 for entmib@ietf.org; Tue, 10 Feb 2004 15:03:51 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1AK2uvU010918 for ; Tue, 10 Feb 2004 15:02:56 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1AK2svU010879 for ; Tue, 10 Feb 2004 15:02:55 -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] Re: Entity mib support for tcif Date: Tue, 10 Feb 2004 22:03:44 +0200 Message-ID: Thread-Topic: [Entmib] Re: Entity mib support for tcif Thread-Index: AcPv95EnEUnJZLjNSaK806xXZxW+UgAGNiUw From: "Romascanu, Dan (Dan)" To: "Kaj Tesink" , 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 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'? 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? Thanks and Regards, Dan > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On=20 > Behalf Of Kaj Tesink > Sent: 10 February, 2004 6:48 PM > To: entmib@ietf.org > Subject: Fwd: [Entmib] Re: Entity mib support for tcif >=20 >=20 > all, >=20 > 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 >=20 > 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. >=20 > 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 >=20 > kaj >=20 >=20 >=20 >=20 > >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 > > > > > >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 >=20 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Tue Feb 10 15:06:33 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 PAA06596 for ; Tue, 10 Feb 2004 15:06:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqe8v-0002bN-UW for entmib-archive@odin.ietf.org; Tue, 10 Feb 2004 15:06:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AK61aj009997 for entmib-archive@odin.ietf.org; Tue, 10 Feb 2004 15:06:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqe8v-0002b7-MZ; Tue, 10 Feb 2004 15:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqe8B-0002Bx-DY for entmib@optimus.ietf.org; Tue, 10 Feb 2004 15:05:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06401 for ; Tue, 10 Feb 2004 15:05:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqe88-0001td-00 for entmib@ietf.org; Tue, 10 Feb 2004 15:05:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqe7J-0001nU-00 for entmib@ietf.org; Tue, 10 Feb 2004 15:04:22 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1Aqe6p-0001gU-00 for entmib@ietf.org; Tue, 10 Feb 2004 15:03:51 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1AK2uvU010918 for ; Tue, 10 Feb 2004 15:02:56 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1AK2svU010879 for ; Tue, 10 Feb 2004 15:02:55 -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] Re: Entity mib support for tcif Date: Tue, 10 Feb 2004 22:03:44 +0200 Message-ID: Thread-Topic: [Entmib] Re: Entity mib support for tcif Thread-Index: AcPv95EnEUnJZLjNSaK806xXZxW+UgAGNiUw From: "Romascanu, Dan (Dan)" To: "Kaj Tesink" , 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 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'? 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? Thanks and Regards, Dan > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On=20 > Behalf Of Kaj Tesink > Sent: 10 February, 2004 6:48 PM > To: entmib@ietf.org > Subject: Fwd: [Entmib] Re: Entity mib support for tcif >=20 >=20 > all, >=20 > 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 >=20 > 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. >=20 > 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 >=20 > kaj >=20 >=20 >=20 >=20 > >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 > > > > > >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 >=20 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Feb 11 10:28:27 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 KAA05195 for ; Wed, 11 Feb 2004 10:28:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwHP-0008Ah-VG; Wed, 11 Feb 2004 10:27:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwH8-00089t-MT for entmib@optimus.ietf.org; Wed, 11 Feb 2004 10:27:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05170 for ; Wed, 11 Feb 2004 10:27:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqwH6-0007Q7-00 for entmib@ietf.org; Wed, 11 Feb 2004 10:27:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqwG8-0007Kk-00 for entmib@ietf.org; Wed, 11 Feb 2004 10:26:41 -0500 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqwFT-0007BM-00 for entmib@ietf.org; Wed, 11 Feb 2004 10:25:59 -0500 Received: from shannon.research.telcordia.com (shannon-83.research.telcordia.com [128.96.83.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id i1BFPOai001798 for ; Wed, 11 Feb 2004 10:25:24 -0500 (EST) 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 KAA21279 for ; Wed, 11 Feb 2004 10:25:23 -0500 (EST) Message-Id: <4.3.2.7.2.20040211095054.01745848@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Feb 2004 10:25:19 -0500 To: From: Kaj Tesink Subject: RE: [Entmib] Re: Entity mib support for tcif In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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=0.6 required=5.0 tests=AWL,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: , 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 > > > > > > > > >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 Wed Feb 11 10:28:31 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 KAA05212 for ; Wed, 11 Feb 2004 10:28:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwHQ-0008Ay-DO for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 10:28:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BFS0fC031427 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 10:28:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwHP-0008Ah-VG; Wed, 11 Feb 2004 10:27:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwH8-00089t-MT for entmib@optimus.ietf.org; Wed, 11 Feb 2004 10:27:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05170 for ; Wed, 11 Feb 2004 10:27:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqwH6-0007Q7-00 for entmib@ietf.org; Wed, 11 Feb 2004 10:27:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqwG8-0007Kk-00 for entmib@ietf.org; Wed, 11 Feb 2004 10:26:41 -0500 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqwFT-0007BM-00 for entmib@ietf.org; Wed, 11 Feb 2004 10:25:59 -0500 Received: from shannon.research.telcordia.com (shannon-83.research.telcordia.com [128.96.83.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id i1BFPOai001798 for ; Wed, 11 Feb 2004 10:25:24 -0500 (EST) 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 KAA21279 for ; Wed, 11 Feb 2004 10:25:23 -0500 (EST) Message-Id: <4.3.2.7.2.20040211095054.01745848@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Feb 2004 10:25:19 -0500 To: From: Kaj Tesink Subject: RE: [Entmib] Re: Entity mib support for tcif In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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=0.6 required=5.0 tests=AWL,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: , 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 > > > > > > > > >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 Wed Feb 11 13:12:27 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 NAA12070 for ; Wed, 11 Feb 2004 13:12:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqyq8-00061y-6S; Wed, 11 Feb 2004 13:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqypy-00061f-AC for entmib@optimus.ietf.org; Wed, 11 Feb 2004 13:11:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12062 for ; Wed, 11 Feb 2004 13:11:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqypw-0001s3-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:11:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqyp0-0001n3-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:10:50 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AqyoI-0001c9-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:10:07 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1BI9Zr10111 for ; Wed, 11 Feb 2004 13:09:35 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7GAQ>; Wed, 11 Feb 2004 13:09:35 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2439B3@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 13:09:33 -0500 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 Subject: [Entmib] Summary of Issues from Entity State MIB WG Last Call 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 For those of you not regularly visiting http://rt.psg.org (ietf, ietf), here is the current list of open issues on the Entity State MIB. Most of these have been discussed on the list already. I'll start posting proposed resolutions to these to the list with the goal of closing them by the end of the week so that I can make the ID deadline of Monday 9am. A big thanks to everyone who took the time to review the document. 311 DateAndTimeOrZero 325 OID Organization 327 More Editorial Issues 328 Containment Hierach and entPhysicalContainedin 329 Usage State Scope 330 Notification Varbinds 306 entStateTrap rename/oid to entStateNotifs 307 'notSupported' is semantically wrong 308 Shutting Down Admin State 309 Operational State Names and Concepts 310 Alarm State Issues 312 Locked Admin State 322 Textual Convention Names (Prefix) 326 Too many state objects Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Feb 11 13:12:27 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 NAA12073 for ; Wed, 11 Feb 2004 13:12:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqyq8-00062L-ER for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 13:12:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BIC0WV023193 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 13:12:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqyq8-00061y-6S; Wed, 11 Feb 2004 13:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqypy-00061f-AC for entmib@optimus.ietf.org; Wed, 11 Feb 2004 13:11:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12062 for ; Wed, 11 Feb 2004 13:11:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqypw-0001s3-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:11:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqyp0-0001n3-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:10:50 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AqyoI-0001c9-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:10:07 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1BI9Zr10111 for ; Wed, 11 Feb 2004 13:09:35 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7GAQ>; Wed, 11 Feb 2004 13:09:35 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2439B3@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 13:09:33 -0500 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 Subject: [Entmib] Summary of Issues from Entity State MIB WG Last Call 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 For those of you not regularly visiting http://rt.psg.org (ietf, ietf), here is the current list of open issues on the Entity State MIB. Most of these have been discussed on the list already. I'll start posting proposed resolutions to these to the list with the goal of closing them by the end of the week so that I can make the ID deadline of Monday 9am. A big thanks to everyone who took the time to review the document. 311 DateAndTimeOrZero 325 OID Organization 327 More Editorial Issues 328 Containment Hierach and entPhysicalContainedin 329 Usage State Scope 330 Notification Varbinds 306 entStateTrap rename/oid to entStateNotifs 307 'notSupported' is semantically wrong 308 Shutting Down Admin State 309 Operational State Names and Concepts 310 Alarm State Issues 312 Locked Admin State 322 Textual Convention Names (Prefix) 326 Too many state objects Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Feb 11 13:16: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 NAA12169 for ; Wed, 11 Feb 2004 13:16:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqyu1-00069e-Bj; Wed, 11 Feb 2004 13:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqyto-00069E-PU for entmib@optimus.ietf.org; Wed, 11 Feb 2004 13:15:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12154 for ; Wed, 11 Feb 2004 13:15:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqytm-0002Dg-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:15:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqysq-00028b-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:14:49 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AqysF-0001yJ-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:14:11 -0500 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 i1BIDe305605 for ; Wed, 11 Feb 2004 13:13:40 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7G1Z>; Wed, 11 Feb 2004 13:13:40 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2439C1@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] Summary of Issues from Entity State MIB WG Last Call Date: Wed, 11 Feb 2004 13:13:39 -0500 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 Maybe if I got the URL right, more people would use the site ;-) http://rt.psg.com Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, February 11, 2004 1:10 PM To: entmib@ietf.org Subject: [Entmib] Summary of Issues from Entity State MIB WG Last Call Hi For those of you not regularly visiting http://rt.psg.org (ietf, ietf), here is the current list of open issues on the Entity State MIB. Most of these have been discussed on the list already. I'll start posting proposed resolutions to these to the list with the goal of closing them by the end of the week so that I can make the ID deadline of Monday 9am. A big thanks to everyone who took the time to review the document. 311 DateAndTimeOrZero 325 OID Organization 327 More Editorial Issues 328 Containment Hierach and entPhysicalContainedin 329 Usage State Scope 330 Notification Varbinds 306 entStateTrap rename/oid to entStateNotifs 307 'notSupported' is semantically wrong 308 Shutting Down Admin State 309 Operational State Names and Concepts 310 Alarm State Issues 312 Locked Admin State 322 Textual Convention Names (Prefix) 326 Too many state objects 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 Wed Feb 11 13:16: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 NAA12171 for ; Wed, 11 Feb 2004 13:16:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqyu2-0006BI-3u for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 13:16:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BIG1kq023671 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 13:16:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqyu1-00069e-Bj; Wed, 11 Feb 2004 13:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqyto-00069E-PU for entmib@optimus.ietf.org; Wed, 11 Feb 2004 13:15:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12154 for ; Wed, 11 Feb 2004 13:15:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqytm-0002Dg-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:15:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqysq-00028b-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:14:49 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AqysF-0001yJ-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:14:11 -0500 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 i1BIDe305605 for ; Wed, 11 Feb 2004 13:13:40 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7G1Z>; Wed, 11 Feb 2004 13:13:40 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2439C1@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] Summary of Issues from Entity State MIB WG Last Call Date: Wed, 11 Feb 2004 13:13:39 -0500 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 Maybe if I got the URL right, more people would use the site ;-) http://rt.psg.com Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, February 11, 2004 1:10 PM To: entmib@ietf.org Subject: [Entmib] Summary of Issues from Entity State MIB WG Last Call Hi For those of you not regularly visiting http://rt.psg.org (ietf, ietf), here is the current list of open issues on the Entity State MIB. Most of these have been discussed on the list already. I'll start posting proposed resolutions to these to the list with the goal of closing them by the end of the week so that I can make the ID deadline of Monday 9am. A big thanks to everyone who took the time to review the document. 311 DateAndTimeOrZero 325 OID Organization 327 More Editorial Issues 328 Containment Hierach and entPhysicalContainedin 329 Usage State Scope 330 Notification Varbinds 306 entStateTrap rename/oid to entStateNotifs 307 'notSupported' is semantically wrong 308 Shutting Down Admin State 309 Operational State Names and Concepts 310 Alarm State Issues 312 Locked Admin State 322 Textual Convention Names (Prefix) 326 Too many state objects 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 Wed Feb 11 13:45:31 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 NAA13242 for ; Wed, 11 Feb 2004 13:45:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzM6-0007sh-Ha; Wed, 11 Feb 2004 13:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzLt-0007rx-6e for entmib@optimus.ietf.org; Wed, 11 Feb 2004 13:44:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13216 for ; Wed, 11 Feb 2004 13:44:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzLq-0005BI-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:44:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzKr-00054a-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:43:46 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AqzJv-0004tY-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:42:47 -0500 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 i1BIgG310576 for ; Wed, 11 Feb 2004 13:42:16 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7HAG>; Wed, 11 Feb 2004 13:42:16 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243A21@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 13:42:08 -0500 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 Subject: [Entmib] FW: [psg.com #306] AutoReply: entStateTrap rename/oid to entState Notifs 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: , The following is the proposed resolution to entstate-306. The issue will be considered closed pending the proposed edit being done. Replace " entStateTraps OBJECT IDENTIFIER ::= { entityStateMIB 2 } entStateTrapPrefix OBJECT IDENTIFIER ::= { entStateTraps 0 }" With "entStateNotifications OBJECT IDENTIFIER ::= { entityStateMIB 0 }" and update the definition of entStateOperEnabled and entStateOperDisabled to use the new name. Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Monday, January 12, 2004 6:29 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #306] AutoReply: entStateTrap rename/oid to entStateNotifs ------------------------------------------------------------------------- Subrahmanya Hegde [subrah@cisco.com] " a Minor Suggestion: Instead of having these OID definitions: -- Notifications entStateTraps OBJECT IDENTIFIER ::= { entityStateMIB 2 } entStateTrapPrefix OBJECT IDENTIFIER ::= { entStateTraps 0 } We can have entStateNotifs OBJECT IDENTIFIER ::= { entityStateMIB 0 } and use 'entStateNotifs' in the corresponding NOTIFICATION-TYPE Reason we would like to avoid name 'Traps' is: Latest RFCs refer them as Notifications" Randy Presuhn [randy_presuhn@mindspring.com] "This would also bring it into better alignment with the MIB review guidelines." _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Feb 11 13:53: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 NAA13631 for ; Wed, 11 Feb 2004 13:53:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzTo-0000BE-2k; Wed, 11 Feb 2004 13:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzTf-0000At-Fz for entmib@optimus.ietf.org; Wed, 11 Feb 2004 13:52:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13620 for ; Wed, 11 Feb 2004 13:52:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzTd-0005v6-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:52:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzSj-0005pt-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:51:53 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AqzSB-0005ip-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:51:19 -0500 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 i1BIolf11830 for ; Wed, 11 Feb 2004 13:50:47 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7H2M>; Wed, 11 Feb 2004 13:50:47 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243A3F@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 13:50:46 -0500 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 Subject: [Entmib] FW: [psg.com #307] AutoReply: 'notSupported' is semantically wron g 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: , The following is the proposed resolution to entstate-307. The issue will be considered closed pending the proposed edit being done. Replace the enumeration 'notSupported' with 'notReportable' in each of the TCs and any references within the text. For each of the (TC, object definition) pairs, move the following sort of text from the object definition to the textual convention: "A value of 'notApplicable' means that this resource is unable to report [this] state." Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, January 13, 2004 2:50 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #307] AutoReply: 'notSupported' is semantically wrong ------------------------------------------------------------------------- Keith McCloghrie [kzm@cisco.com] " > 'notSupported' is semantically wrong, because a compliant implementation > obviously supports the MIB, but it can return 'notSupported' for > every object in the MIB. Presumably, the intended semantics is that > the agent would return the right value if only it knew the right value; > i.e., 'unknown' is the desired semantics. Also, why is each definition > of 'notSupported' defined in an object's DESCRIPTION, not in the TC's > DESCRIPTION ?" _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Feb 11 13:53: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 NAA13633 for ; Wed, 11 Feb 2004 13:53:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzTo-0000Bg-7k for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 13:53:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BIr0bU000702 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 13:53:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzTo-0000BE-2k; Wed, 11 Feb 2004 13:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzTf-0000At-Fz for entmib@optimus.ietf.org; Wed, 11 Feb 2004 13:52:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13620 for ; Wed, 11 Feb 2004 13:52:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzTd-0005v6-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:52:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzSj-0005pt-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:51:53 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AqzSB-0005ip-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:51:19 -0500 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 i1BIolf11830 for ; Wed, 11 Feb 2004 13:50:47 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7H2M>; Wed, 11 Feb 2004 13:50:47 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243A3F@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 13:50:46 -0500 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 Subject: [Entmib] FW: [psg.com #307] AutoReply: 'notSupported' is semantically wron g 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: , The following is the proposed resolution to entstate-307. The issue will be considered closed pending the proposed edit being done. Replace the enumeration 'notSupported' with 'notReportable' in each of the TCs and any references within the text. For each of the (TC, object definition) pairs, move the following sort of text from the object definition to the textual convention: "A value of 'notApplicable' means that this resource is unable to report [this] state." Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, January 13, 2004 2:50 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #307] AutoReply: 'notSupported' is semantically wrong ------------------------------------------------------------------------- Keith McCloghrie [kzm@cisco.com] " > 'notSupported' is semantically wrong, because a compliant implementation > obviously supports the MIB, but it can return 'notSupported' for > every object in the MIB. Presumably, the intended semantics is that > the agent would return the right value if only it knew the right value; > i.e., 'unknown' is the desired semantics. Also, why is each definition > of 'notSupported' defined in an object's DESCRIPTION, not in the TC's > DESCRIPTION ?" _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Feb 11 13:56:30 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 NAA13785 for ; Wed, 11 Feb 2004 13:56:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzWj-0000e0-Iv; Wed, 11 Feb 2004 13:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzWZ-0000di-Re for entmib@optimus.ietf.org; Wed, 11 Feb 2004 13:55:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13750 for ; Wed, 11 Feb 2004 13:55:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzWX-0006CW-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:55:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzVb-00066j-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:54:52 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AqzUo-0005wB-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:54:02 -0500 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 i1BIrVf12293 for ; Wed, 11 Feb 2004 13:53:31 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7HLM>; Wed, 11 Feb 2004 13:53:31 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243A4B@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 13:53:25 -0500 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 Subject: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is semantically wron g 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 That last bit should read ""A value of 'notReportable' means that this resource is unable to report [this] state." Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, February 11, 2004 1:51 PM To: 'entmib@ietf.org' Subject: FW: [psg.com #307] AutoReply: 'notSupported' is semantically wrong The following is the proposed resolution to entstate-307. The issue will be considered closed pending the proposed edit being done. Replace the enumeration 'notSupported' with 'notReportable' in each of the TCs and any references within the text. For each of the (TC, object definition) pairs, move the following sort of text from the object definition to the textual convention: "A value of 'notApplicable' means that this resource is unable to report [this] state." Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, January 13, 2004 2:50 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #307] AutoReply: 'notSupported' is semantically wrong ------------------------------------------------------------------------- Keith McCloghrie [kzm@cisco.com] " > 'notSupported' is semantically wrong, because a compliant implementation > obviously supports the MIB, but it can return 'notSupported' for > every object in the MIB. Presumably, the intended semantics is that > the agent would return the right value if only it knew the right value; > i.e., 'unknown' is the desired semantics. Also, why is each definition > of 'notSupported' defined in an object's DESCRIPTION, not in the TC's > DESCRIPTION ?" _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Feb 11 13:56:30 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 NAA13787 for ; Wed, 11 Feb 2004 13:56:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzWk-0000ev-9q for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 13:56:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BIu1gO002487 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 13:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzWj-0000e0-Iv; Wed, 11 Feb 2004 13:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzWZ-0000di-Re for entmib@optimus.ietf.org; Wed, 11 Feb 2004 13:55:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13750 for ; Wed, 11 Feb 2004 13:55:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzWX-0006CW-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:55:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzVb-00066j-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:54:52 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AqzUo-0005wB-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:54:02 -0500 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 i1BIrVf12293 for ; Wed, 11 Feb 2004 13:53:31 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7HLM>; Wed, 11 Feb 2004 13:53:31 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243A4B@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 13:53:25 -0500 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 Subject: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is semantically wron g 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 That last bit should read ""A value of 'notReportable' means that this resource is unable to report [this] state." Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, February 11, 2004 1:51 PM To: 'entmib@ietf.org' Subject: FW: [psg.com #307] AutoReply: 'notSupported' is semantically wrong The following is the proposed resolution to entstate-307. The issue will be considered closed pending the proposed edit being done. Replace the enumeration 'notSupported' with 'notReportable' in each of the TCs and any references within the text. For each of the (TC, object definition) pairs, move the following sort of text from the object definition to the textual convention: "A value of 'notApplicable' means that this resource is unable to report [this] state." Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, January 13, 2004 2:50 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #307] AutoReply: 'notSupported' is semantically wrong ------------------------------------------------------------------------- Keith McCloghrie [kzm@cisco.com] " > 'notSupported' is semantically wrong, because a compliant implementation > obviously supports the MIB, but it can return 'notSupported' for > every object in the MIB. Presumably, the intended semantics is that > the agent would return the right value if only it knew the right value; > i.e., 'unknown' is the desired semantics. Also, why is each definition > of 'notSupported' defined in an object's DESCRIPTION, not in the TC's > DESCRIPTION ?" _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Feb 11 14:03: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 OAA14262 for ; Wed, 11 Feb 2004 14:03:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzdY-0001tv-BE; Wed, 11 Feb 2004 14:03:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzcW-0001TC-P7 for entmib@optimus.ietf.org; Wed, 11 Feb 2004 14:02:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14174 for ; Wed, 11 Feb 2004 14:01:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzcU-0006w5-00 for entmib@ietf.org; Wed, 11 Feb 2004 14:01:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzbV-0006oT-00 for entmib@ietf.org; Wed, 11 Feb 2004 14:00:57 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AqzaQ-0006aH-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:59:50 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1BIxJr18318 for ; Wed, 11 Feb 2004 13:59:19 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7HRD>; Wed, 11 Feb 2004 13:59:19 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243A61@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 13:59:09 -0500 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 Subject: [Entmib] FW: [psg.com #308] AutoReply: Shutting Down Admin State 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: , The following is the proposed resolution to entstate-308. The issue will be considered closed with no changes made to the document. The following explanations were provided and no questions were raised. " 1. Is shutting down really more an operational state? The state refers more to whether your administrative model allows systems to be shut down gracefully or not. The idea being that if it does, you would still have the options to bring it down less gracefully. We have allowed in the description of the object for systems that don't support this value for the state. 2. Would 'noNewUsage' be a better term. Well, except that the idea is that once all the existing 'users' are gone, the system will shut down. The term 'noNewUsage' does not really reflect that." Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, January 13, 2004 2:55 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #308] AutoReply: Shutting Down Admin State ------------------------------------------------------------------------- Keith McCloghrie [kzm@cisco.com] " the term 'shuttingDown' suggests that the action of shutting down is > in progress, which of course is an operational condition, not an admin > state. A term more reflective of what the AdminState DESCRIPTION appears > to define would be 'noNewUsage'. In any case, this concept of 'usage' > is almost always a higher-level usage (e.g., a new ATM connection on an > ATM interface, a new Unix login on a cpu module, etc.) and thus don't > belong at the physical layer (i.e., don't apply to > entPhysicalIndex). " _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Feb 11 14:03:40 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 OAA14279 for ; Wed, 11 Feb 2004 14:03:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqzda-0001uX-Rr for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 14:03:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BJ36qU007339 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 14:03:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzdY-0001tv-BE; Wed, 11 Feb 2004 14:03:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzcW-0001TC-P7 for entmib@optimus.ietf.org; Wed, 11 Feb 2004 14:02:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14174 for ; Wed, 11 Feb 2004 14:01:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzcU-0006w5-00 for entmib@ietf.org; Wed, 11 Feb 2004 14:01:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzbV-0006oT-00 for entmib@ietf.org; Wed, 11 Feb 2004 14:00:57 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AqzaQ-0006aH-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:59:50 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1BIxJr18318 for ; Wed, 11 Feb 2004 13:59:19 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7HRD>; Wed, 11 Feb 2004 13:59:19 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243A61@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 13:59:09 -0500 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 Subject: [Entmib] FW: [psg.com #308] AutoReply: Shutting Down Admin State 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: , The following is the proposed resolution to entstate-308. The issue will be considered closed with no changes made to the document. The following explanations were provided and no questions were raised. " 1. Is shutting down really more an operational state? The state refers more to whether your administrative model allows systems to be shut down gracefully or not. The idea being that if it does, you would still have the options to bring it down less gracefully. We have allowed in the description of the object for systems that don't support this value for the state. 2. Would 'noNewUsage' be a better term. Well, except that the idea is that once all the existing 'users' are gone, the system will shut down. The term 'noNewUsage' does not really reflect that." Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, January 13, 2004 2:55 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #308] AutoReply: Shutting Down Admin State ------------------------------------------------------------------------- Keith McCloghrie [kzm@cisco.com] " the term 'shuttingDown' suggests that the action of shutting down is > in progress, which of course is an operational condition, not an admin > state. A term more reflective of what the AdminState DESCRIPTION appears > to define would be 'noNewUsage'. In any case, this concept of 'usage' > is almost always a higher-level usage (e.g., a new ATM connection on an > ATM interface, a new Unix login on a cpu module, etc.) and thus don't > belong at the physical layer (i.e., don't apply to > entPhysicalIndex). " _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Feb 11 14:21:30 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 OAA15707 for ; Wed, 11 Feb 2004 14:21:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqzuw-00041C-Cn; Wed, 11 Feb 2004 14:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqzu9-0003ze-Va for entmib@optimus.ietf.org; Wed, 11 Feb 2004 14:20:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15587 for ; Wed, 11 Feb 2004 14:20:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqzu7-0001bg-00 for entmib@ietf.org; Wed, 11 Feb 2004 14:20:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqzsx-0001Td-00 for entmib@ietf.org; Wed, 11 Feb 2004 14:19:00 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Aqzs8-0001Gi-00 for entmib@ietf.org; Wed, 11 Feb 2004 14:18:08 -0500 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 i1BJHbf25280 for ; Wed, 11 Feb 2004 14:17:37 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH72CG>; Wed, 11 Feb 2004 14:17:37 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243A9E@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 14:17:28 -0500 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 Subject: [Entmib] FW: [psg.com #309] AutoReply: Operational State Names and Concept s 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: , The following is the proposed resolution to entstate-309. The issue will be considered closed pending the proposed edit being done. Add the following text to entStateOper "Note that some implementations may not be able to accurately report entStateOper while the entStateAdmin object has a value other than 'unlocked'. In these cases, this object MUST have a value of 'notReportable'." Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, January 13, 2004 2:57 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #309] AutoReply: Operational State Names and Concepts ------------------------------------------------------------------------- Keith McCloghrie [kzm@cisco.com] "'enabled' and 'disabled' to me imply that an admin state, i.e., if > I saw an operState of 'disabled', or a entStateOperDisabled notification, > I'd look for the knob by which I could issue the enable command to enable > it again. > for most things, I believe you have to turn them on to see if they work; > if they don't work, you can turn them off again, and label them "inoperable", > but what that means is that they were inoperable the last time they were > turned on, and it doesn't necessarily mean they are still inoperable, e.g., > if something was inoperable the last time it was turned on and has just > been repaired, but not yet turned on again, is it still inoperable ?? > That is, neither 'disabled' nor 'inoperable' is the right term for > operState. " _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Feb 11 14:21:30 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 OAA15709 for ; Wed, 11 Feb 2004 14:21:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqzuw-00041a-Rd for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 14:21:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BJL2Vu015458 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 14:21:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqzuw-00041C-Cn; Wed, 11 Feb 2004 14:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqzu9-0003ze-Va for entmib@optimus.ietf.org; Wed, 11 Feb 2004 14:20:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15587 for ; Wed, 11 Feb 2004 14:20:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqzu7-0001bg-00 for entmib@ietf.org; Wed, 11 Feb 2004 14:20:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqzsx-0001Td-00 for entmib@ietf.org; Wed, 11 Feb 2004 14:19:00 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Aqzs8-0001Gi-00 for entmib@ietf.org; Wed, 11 Feb 2004 14:18:08 -0500 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 i1BJHbf25280 for ; Wed, 11 Feb 2004 14:17:37 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH72CG>; Wed, 11 Feb 2004 14:17:37 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243A9E@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 14:17:28 -0500 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 Subject: [Entmib] FW: [psg.com #309] AutoReply: Operational State Names and Concept s 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: , The following is the proposed resolution to entstate-309. The issue will be considered closed pending the proposed edit being done. Add the following text to entStateOper "Note that some implementations may not be able to accurately report entStateOper while the entStateAdmin object has a value other than 'unlocked'. In these cases, this object MUST have a value of 'notReportable'." Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, January 13, 2004 2:57 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #309] AutoReply: Operational State Names and Concepts ------------------------------------------------------------------------- Keith McCloghrie [kzm@cisco.com] "'enabled' and 'disabled' to me imply that an admin state, i.e., if > I saw an operState of 'disabled', or a entStateOperDisabled notification, > I'd look for the knob by which I could issue the enable command to enable > it again. > for most things, I believe you have to turn them on to see if they work; > if they don't work, you can turn them off again, and label them "inoperable", > but what that means is that they were inoperable the last time they were > turned on, and it doesn't necessarily mean they are still inoperable, e.g., > if something was inoperable the last time it was turned on and has just > been repaired, but not yet turned on again, is it still inoperable ?? > That is, neither 'disabled' nor 'inoperable' is the right term for > operState. " _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Feb 11 14:33:15 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 NAA13244 for ; Wed, 11 Feb 2004 13:45:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzM7-0007tI-0p for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 13:45:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BIj29J030316 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 13:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzM6-0007sh-Ha; Wed, 11 Feb 2004 13:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzLt-0007rx-6e for entmib@optimus.ietf.org; Wed, 11 Feb 2004 13:44:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13216 for ; Wed, 11 Feb 2004 13:44:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzLq-0005BI-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:44:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzKr-00054a-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:43:46 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AqzJv-0004tY-00 for entmib@ietf.org; Wed, 11 Feb 2004 13:42:47 -0500 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 i1BIgG310576 for ; Wed, 11 Feb 2004 13:42:16 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7HAG>; Wed, 11 Feb 2004 13:42:16 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243A21@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 13:42:08 -0500 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 Subject: [Entmib] FW: [psg.com #306] AutoReply: entStateTrap rename/oid to entState Notifs 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: , The following is the proposed resolution to entstate-306. The issue will be considered closed pending the proposed edit being done. Replace " entStateTraps OBJECT IDENTIFIER ::= { entityStateMIB 2 } entStateTrapPrefix OBJECT IDENTIFIER ::= { entStateTraps 0 }" With "entStateNotifications OBJECT IDENTIFIER ::= { entityStateMIB 0 }" and update the definition of entStateOperEnabled and entStateOperDisabled to use the new name. Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Monday, January 12, 2004 6:29 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #306] AutoReply: entStateTrap rename/oid to entStateNotifs ------------------------------------------------------------------------- Subrahmanya Hegde [subrah@cisco.com] " a Minor Suggestion: Instead of having these OID definitions: -- Notifications entStateTraps OBJECT IDENTIFIER ::= { entityStateMIB 2 } entStateTrapPrefix OBJECT IDENTIFIER ::= { entStateTraps 0 } We can have entStateNotifs OBJECT IDENTIFIER ::= { entityStateMIB 0 } and use 'entStateNotifs' in the corresponding NOTIFICATION-TYPE Reason we would like to avoid name 'Traps' is: Latest RFCs refer them as Notifications" Randy Presuhn [randy_presuhn@mindspring.com] "This would also bring it into better alignment with the MIB review guidelines." _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Feb 11 14:47:29 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 OAA17105 for ; Wed, 11 Feb 2004 14:47:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0K4-0006uQ-Vt; Wed, 11 Feb 2004 14:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0K4-0006uF-3n for entmib@optimus.ietf.org; Wed, 11 Feb 2004 14:47:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17090 for ; Wed, 11 Feb 2004 14:46:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0K1-0004aA-00 for entmib@ietf.org; Wed, 11 Feb 2004 14:46:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar0J3-0004U9-00 for entmib@ietf.org; Wed, 11 Feb 2004 14:45:58 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0IP-0004KF-00 for entmib@ietf.org; Wed, 11 Feb 2004 14:45:17 -0500 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 i1BJiku29357 for ; Wed, 11 Feb 2004 14:44:46 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7253>; Wed, 11 Feb 2004 14:44:46 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243B00@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 14:44:38 -0500 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 Subject: [Entmib] FW: [psg.com #310] AutoReply: Alarm State 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: , The following is the proposed resolution to entstate-310. The issue will be considered closed pending the proposed edit being done. In the description of AlarmStatus replace " When the value of under repair is set, the resource is currently being repaired." With " When the value of under repair is set, the resource is currently being repaired, which depending on the implementation, may make the other values in this bit string unreliable." And replace " When the value of 'alarmOutstanding' is set, one or more alarms is active against the resource. The fault may or may not be disabling. " With " When the value of 'alarmOutstanding' is set, one or more alarms is active against the resource. The fault may or may not be disabling. This bit provides a high-level summary that can be used to determine whether or not to examine the rest of the values." An explanation on the difference between raw and computed state, as defined in section 2.1 was previously provided in relation to the severity of alarms issue. No change appears to be necessary on that particular issue. Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, January 13, 2004 2:58 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #310] AutoReply: Alarm State Issues ------------------------------------------------------------------------- Keith McCloghrie [kzm@cisco.com] "> 'underRepair' is an operState, not an AlarmState. > > from what perspective are the alarms classified as critical/major/minor/etc. > e.g., does a particular fault have the same alarm status in 'coldStandby' > as it does in 'hotStandby' or in 'providingService' ?? (hint: the answer > is no!!). " Juergen Schoenwaelder [j.schoenwaelder@iu-bremen.de] "6) AlarmStatus TC: I do not really understand the alarmOutStanding bit. It seems like this is set whenever one of critical, major, minor, warning and indeterminate is set. But if this is true, I think the bit is not really terrible useful. Perhaps the bit has some other meaning. If so, please clarify." _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Feb 11 14:47:29 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 OAA17107 for ; Wed, 11 Feb 2004 14:47:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0K5-0006ux-K4 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 14:47:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BJl1OM026574 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 14:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0K4-0006uQ-Vt; Wed, 11 Feb 2004 14:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0K4-0006uF-3n for entmib@optimus.ietf.org; Wed, 11 Feb 2004 14:47:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17090 for ; Wed, 11 Feb 2004 14:46:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0K1-0004aA-00 for entmib@ietf.org; Wed, 11 Feb 2004 14:46:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar0J3-0004U9-00 for entmib@ietf.org; Wed, 11 Feb 2004 14:45:58 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0IP-0004KF-00 for entmib@ietf.org; Wed, 11 Feb 2004 14:45:17 -0500 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 i1BJiku29357 for ; Wed, 11 Feb 2004 14:44:46 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7253>; Wed, 11 Feb 2004 14:44:46 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243B00@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 14:44:38 -0500 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 Subject: [Entmib] FW: [psg.com #310] AutoReply: Alarm State 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: , The following is the proposed resolution to entstate-310. The issue will be considered closed pending the proposed edit being done. In the description of AlarmStatus replace " When the value of under repair is set, the resource is currently being repaired." With " When the value of under repair is set, the resource is currently being repaired, which depending on the implementation, may make the other values in this bit string unreliable." And replace " When the value of 'alarmOutstanding' is set, one or more alarms is active against the resource. The fault may or may not be disabling. " With " When the value of 'alarmOutstanding' is set, one or more alarms is active against the resource. The fault may or may not be disabling. This bit provides a high-level summary that can be used to determine whether or not to examine the rest of the values." An explanation on the difference between raw and computed state, as defined in section 2.1 was previously provided in relation to the severity of alarms issue. No change appears to be necessary on that particular issue. Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, January 13, 2004 2:58 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #310] AutoReply: Alarm State Issues ------------------------------------------------------------------------- Keith McCloghrie [kzm@cisco.com] "> 'underRepair' is an operState, not an AlarmState. > > from what perspective are the alarms classified as critical/major/minor/etc. > e.g., does a particular fault have the same alarm status in 'coldStandby' > as it does in 'hotStandby' or in 'providingService' ?? (hint: the answer > is no!!). " Juergen Schoenwaelder [j.schoenwaelder@iu-bremen.de] "6) AlarmStatus TC: I do not really understand the alarmOutStanding bit. It seems like this is set whenever one of critical, major, minor, warning and indeterminate is set. But if this is true, I think the bit is not really terrible useful. Perhaps the bit has some other meaning. If so, please clarify." _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Feb 11 15:30:31 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 PAA20340 for ; Wed, 11 Feb 2004 15:30:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0zi-0002IV-Ge; Wed, 11 Feb 2004 15:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0zf-0002Hs-9k for entmib@optimus.ietf.org; Wed, 11 Feb 2004 15:29:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20278 for ; Wed, 11 Feb 2004 15:29:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0ze-0000zl-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:29:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar0yd-0000tj-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:28:55 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0xc-0000i2-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:27:52 -0500 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 i1BKRHu16421 for ; Wed, 11 Feb 2004 15:27:17 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7KD2>; Wed, 11 Feb 2004 15:27:17 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243BC6@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 15:27:12 -0500 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 Subject: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? 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: , The following is the proposed resolution to entstate-311. The issue will be considered closed pending the proposed edit being done. Replace 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed, or zero."' With 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed. If there has been no change since the last re-initialization of the local system, this object contains the date and time of that initialization."' Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, January 13, 2004 3:00 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #311] AutoReply: DateAndTimeOrZero ? ------------------------------------------------------------------------- Keith McCloghrie [kzm@cisco.com] should the MIB define DateAndTimeOrZero ? What does zero mean ? _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Feb 11 15:30:32 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 PAA20360 for ; Wed, 11 Feb 2004 15:30:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0zj-0002In-6V for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 15:30:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BKU3Qr008842 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 15:30:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0zi-0002IV-Ge; Wed, 11 Feb 2004 15:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0zf-0002Hs-9k for entmib@optimus.ietf.org; Wed, 11 Feb 2004 15:29:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20278 for ; Wed, 11 Feb 2004 15:29:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0ze-0000zl-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:29:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar0yd-0000tj-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:28:55 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0xc-0000i2-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:27:52 -0500 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 i1BKRHu16421 for ; Wed, 11 Feb 2004 15:27:17 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7KD2>; Wed, 11 Feb 2004 15:27:17 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243BC6@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 15:27:12 -0500 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 Subject: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? 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: , The following is the proposed resolution to entstate-311. The issue will be considered closed pending the proposed edit being done. Replace 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed, or zero."' With 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed. If there has been no change since the last re-initialization of the local system, this object contains the date and time of that initialization."' Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, January 13, 2004 3:00 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #311] AutoReply: DateAndTimeOrZero ? ------------------------------------------------------------------------- Keith McCloghrie [kzm@cisco.com] should the MIB define DateAndTimeOrZero ? What does zero mean ? _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Feb 11 15:41:30 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 PAA21176 for ; Wed, 11 Feb 2004 15:41:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1AM-0003ZO-0I; Wed, 11 Feb 2004 15:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1AJ-0003Yr-Ey for entmib@optimus.ietf.org; Wed, 11 Feb 2004 15:40:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21137 for ; Wed, 11 Feb 2004 15:40:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1AI-0002TR-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:40:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar19W-0002Mx-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:40:11 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1Ar18o-0002Az-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:39:26 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1BKcqr13044 for ; Wed, 11 Feb 2004 15:38:53 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7KR8>; Wed, 11 Feb 2004 15:38:53 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243BFB@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 15:38:52 -0500 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 Subject: [Entmib] FW: [psg.com #312] AutoReply: Locked Admin State 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: , The following is the proposed resolution to entstate-312. The issue will be considered closed with no changes made to the document. I had proposed that logical locks were more useful and supportable from a software perspective than physical ones. There was no response. I propose keeping the definition as is. Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, January 13, 2004 3:03 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #312] AutoReply: Locked Admin State ------------------------------------------------------------------------- Keith McCloghrie [kzm@cisco.com] "> the entities to which this MIB applies are physical entities, and thus > it seems natural to apply the term 'locked' in a physcial sense, rather > than a logical sense, i.e., 'locked' is not the right term to use for > administratively disabling a device, because if a device had a physical > lock, then its adminState should not be 'locked' if/when its physical lock > could be unlocked, and vice versa." _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Feb 11 15:41:33 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 PAA21193 for ; Wed, 11 Feb 2004 15:41:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1AM-0003Zp-5r for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 15:41:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BKf2jY013732 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 15:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1AM-0003ZO-0I; Wed, 11 Feb 2004 15:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1AJ-0003Yr-Ey for entmib@optimus.ietf.org; Wed, 11 Feb 2004 15:40:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21137 for ; Wed, 11 Feb 2004 15:40:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1AI-0002TR-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:40:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar19W-0002Mx-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:40:11 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1Ar18o-0002Az-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:39:26 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1BKcqr13044 for ; Wed, 11 Feb 2004 15:38:53 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7KR8>; Wed, 11 Feb 2004 15:38:53 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243BFB@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 15:38:52 -0500 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 Subject: [Entmib] FW: [psg.com #312] AutoReply: Locked Admin State 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: , The following is the proposed resolution to entstate-312. The issue will be considered closed with no changes made to the document. I had proposed that logical locks were more useful and supportable from a software perspective than physical ones. There was no response. I propose keeping the definition as is. Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, January 13, 2004 3:03 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #312] AutoReply: Locked Admin State ------------------------------------------------------------------------- Keith McCloghrie [kzm@cisco.com] "> the entities to which this MIB applies are physical entities, and thus > it seems natural to apply the term 'locked' in a physcial sense, rather > than a logical sense, i.e., 'locked' is not the right term to use for > administratively disabling a device, because if a device had a physical > lock, then its adminState should not be 'locked' if/when its physical lock > could be unlocked, and vice versa." _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Feb 11 15:46:33 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 PAA21453 for ; Wed, 11 Feb 2004 15:46:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1FC-0003jF-4X; Wed, 11 Feb 2004 15:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1F2-0003iw-SU for entmib@optimus.ietf.org; Wed, 11 Feb 2004 15:45:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21347 for ; Wed, 11 Feb 2004 15:45:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1F1-0002xl-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:45:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1E1-0002rt-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:44:50 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1D3-0002hc-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:43:49 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1BKhHr13502 for ; Wed, 11 Feb 2004 15:43:17 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7KVL>; Wed, 11 Feb 2004 15:43:17 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243C0A@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 15:43:09 -0500 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 Subject: [Entmib] FW: [psg.com #322] AutoReply: 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: , The following is the proposed resolution to entstate-322. The issue will be considered closed with no changes made to the document. There were various bits of discussion on the list on when it is appropriate to use a MIB specific prefix on a textual convention and when it does not. As the intention on these textual conventions is for general use it would seem that a prefix is not appropriate. The proposal is to keep the names as is. Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Friday, February 06, 2004 2:33 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #322] AutoReply: Textual Convention Names (Prefix) ------------------------------------------------------------------------- Andy Bierman [abierman@cisco.com] the TCs should be named with a prefix. E.g., OperState -> EntityOperState. This applies to all the TCs in the draft. _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Feb 11 15:56:35 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 PAA23102 for ; Wed, 11 Feb 2004 15:56:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Ow-0004tE-5k; Wed, 11 Feb 2004 15:56:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Oi-0004sL-5m for entmib@optimus.ietf.org; Wed, 11 Feb 2004 15:55:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23056 for ; Wed, 11 Feb 2004 15:55:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1Og-0004Bm-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:55:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1Ni-00044u-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:54:51 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar1Mq-0003sK-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:53:56 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 Feb 2004 13:01:42 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1BKrKuC015705; Wed, 11 Feb 2004 12:53:23 -0800 (PST) Received: from cisco.com (dhcp-171-71-252-227.cisco.com [171.71.252.227]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQV63434; Wed, 11 Feb 2004 12:53:20 -0800 (PST) Message-ID: <402A9640.6050008@cisco.com> Date: Wed, 11 Feb 2004 12:53:20 -0800 From: Subrahmanya Hegde Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sharon Chisholm CC: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? References: <3549C09B853DD5119B540002A52CDD340A243BC6@zcard0ka.ca.nortel.com> In-Reply-To: <3549C09B853DD5119B540002A52CDD340A243BC6@zcard0ka.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: 7bit 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: 7bit 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed. If there has been no change since the last re-initialization of the local system, this object contains the date and time of that initialization."' >> may be good to rephrase it as : contains the date and time during initialization 'that' does not seem to fit well Subra Sharon Chisholm wrote: >The following is the proposed resolution to entstate-311. The issue will be >considered closed pending the proposed edit being done. > >Replace > >'entStateLastChanged OBJECT-TYPE > SYNTAX DateAndTime > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of this object is the date and > time when state/status of the entity > last changed, or zero."' > >With > >'entStateLastChanged OBJECT-TYPE > SYNTAX DateAndTime > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of this object is the date and > time when state/status of the entity > last changed. If there has been no change since > the last re-initialization of the local system, > this object contains the date and time of > that initialization."' > >Sharon > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 3:00 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #311] AutoReply: DateAndTimeOrZero ? > > > >------------------------------------------------------------------------- >Keith McCloghrie [kzm@cisco.com] > >should the MIB define DateAndTimeOrZero ? What does zero mean ? > >_______________________________________________ >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 Wed Feb 11 15:56:37 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 PAA23119 for ; Wed, 11 Feb 2004 15:56:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Ox-0004tr-EY for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 15:56:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BKu6f3018811 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 15:56:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Ow-0004tE-5k; Wed, 11 Feb 2004 15:56:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Oi-0004sL-5m for entmib@optimus.ietf.org; Wed, 11 Feb 2004 15:55:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23056 for ; Wed, 11 Feb 2004 15:55:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1Og-0004Bm-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:55:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1Ni-00044u-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:54:51 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar1Mq-0003sK-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:53:56 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 Feb 2004 13:01:42 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1BKrKuC015705; Wed, 11 Feb 2004 12:53:23 -0800 (PST) Received: from cisco.com (dhcp-171-71-252-227.cisco.com [171.71.252.227]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQV63434; Wed, 11 Feb 2004 12:53:20 -0800 (PST) Message-ID: <402A9640.6050008@cisco.com> Date: Wed, 11 Feb 2004 12:53:20 -0800 From: Subrahmanya Hegde Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sharon Chisholm CC: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? References: <3549C09B853DD5119B540002A52CDD340A243BC6@zcard0ka.ca.nortel.com> In-Reply-To: <3549C09B853DD5119B540002A52CDD340A243BC6@zcard0ka.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: 7bit 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: 7bit 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed. If there has been no change since the last re-initialization of the local system, this object contains the date and time of that initialization."' >> may be good to rephrase it as : contains the date and time during initialization 'that' does not seem to fit well Subra Sharon Chisholm wrote: >The following is the proposed resolution to entstate-311. The issue will be >considered closed pending the proposed edit being done. > >Replace > >'entStateLastChanged OBJECT-TYPE > SYNTAX DateAndTime > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of this object is the date and > time when state/status of the entity > last changed, or zero."' > >With > >'entStateLastChanged OBJECT-TYPE > SYNTAX DateAndTime > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of this object is the date and > time when state/status of the entity > last changed. If there has been no change since > the last re-initialization of the local system, > this object contains the date and time of > that initialization."' > >Sharon > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 3:00 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #311] AutoReply: DateAndTimeOrZero ? > > > >------------------------------------------------------------------------- >Keith McCloghrie [kzm@cisco.com] > >should the MIB define DateAndTimeOrZero ? What does zero mean ? > >_______________________________________________ >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 Wed Feb 11 15:57:30 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 PAA23178 for ; Wed, 11 Feb 2004 15:57:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Pq-0004wQ-57; Wed, 11 Feb 2004 15:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Oo-0004sb-BU for entmib@optimus.ietf.org; Wed, 11 Feb 2004 15:55:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23069 for ; Wed, 11 Feb 2004 15:55:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1Om-0004Ci-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:55:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1Nv-00046g-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:55:04 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1NA-0003sQ-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:54:17 -0500 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 i1BKrhu20832 for ; Wed, 11 Feb 2004 15:53:44 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7K98>; Wed, 11 Feb 2004 15:53:44 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243C29@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 15:53:40 -0500 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 Subject: [Entmib] FW: [psg.com #325] AutoReply: 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: , The following is the proposed resolution to entstate-325. The issue will be considered closed with no changes made to the document, other than those already identified with issue #306. The MIB review guidelines (August 2003) show the following xxxMIB | +-- xxxNotifications(0) +-- xxxObjects(1) +-- xxxConformance(2) | +-- xxxCompliances(1) +-- xxxGroups(2) The MIB currently defines, after we make the change identified in problem #306 entStateMIB | +-- entStateNotifications(0) +-- entStateObjects(1) +-- entStateConformance(2) | +-- entStateCompliances(1) +-- entStateroups(2) This is without making any further changes related to these specific comments. Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Wednesday, February 11, 2004 12:38 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #325] AutoReply: ------------------------------------------------------------------------- Subrahmanya Hegde [subrah@cisco.com]: "As per the MIB convention : We should define a OID under 'entStateObjects' and use that in the xxxTable. For example: entStateObjects OBJECT IDENTIFIER ::= { entityStateMIB 1} add: entityState OBJECT IDENTIFIER ::= { entStateObjects 1} use this 'entityState'(or whatever else makes sense) for entStateTable in the mib 4. entStateConformance must be under { entityStateMIB 2} 3. I think OID definition for 'entityStateGroups' is missing it should be entStateGroups OBJECT IDENTIFIER ::= { entStateConformance 2} " _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Feb 11 16:01:35 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 QAA23402 for ; Wed, 11 Feb 2004 16:01:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Tm-0005M2-SS for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 16:01:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BL16RH020579 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 16:01:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Tm-0005Lj-3m; Wed, 11 Feb 2004 16:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Th-0005KQ-Bl for entmib@optimus.ietf.org; Wed, 11 Feb 2004 16:01:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23381 for ; Wed, 11 Feb 2004 16:00:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1Tf-0004pq-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:00:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1Sr-0004jQ-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:00:10 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1SP-0004b1-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:59:42 -0500 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 i1BKx8u21718 for ; Wed, 11 Feb 2004 15:59:09 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7LC9>; Wed, 11 Feb 2004 15:59:09 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243C34@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 15:59:08 -0500 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 Subject: [Entmib] FW: [psg.com #326] AutoReply: Too many state objects 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: , The following is the proposed resolution to entstate-326. The issue will be considered closed with no changes made to the document. There was discussion of this issue on the mailing list after which it was agreed the issue could be closed. Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Wednesday, February 11, 2004 12:45 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #326] AutoReply: Too many state objects ------------------------------------------------------------------------- Andy Bierman [abierman@cisco.com] "My concerns are regarding the intent of the MIB -- the actual problem being addressed. So I looked to the Entmib WG charter page for guidance. This is all it says about the Entity State MIB: Done Publish state/status extensions as a WG I-D Mar 04 Submit Entity State MIB to the IESG for Proposed Standard Not a word about the problem being addressed. I thought we set out to add an 'operStatus' object for physical entities -- a simple ( green, yellow, red ) status indicator. Applications would still need to know how to use other MIBs to diagnose or correct a fault. IMO, there's not much value in a generic indicator beyond this, so it's best to keep it simple. From the draft: "Objects are defined to capture administrative, operational and usage states. In addition there are further state objects defined to provide additional information for these three basic states." The document clearly attempts to provide more functionality than a simple 'operStatus' object. The authors have done a fine job defining and documenting this functionality. In order to discuss how well a MIB addresses its intended function, we have to agree on the intended function. " _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Feb 11 16:01:35 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 QAA23401 for ; Wed, 11 Feb 2004 16:01:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Tm-0005Lj-3m; Wed, 11 Feb 2004 16:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Th-0005KQ-Bl for entmib@optimus.ietf.org; Wed, 11 Feb 2004 16:01:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23381 for ; Wed, 11 Feb 2004 16:00:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1Tf-0004pq-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:00:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1Sr-0004jQ-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:00:10 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1SP-0004b1-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:59:42 -0500 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 i1BKx8u21718 for ; Wed, 11 Feb 2004 15:59:09 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7LC9>; Wed, 11 Feb 2004 15:59:09 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243C34@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 15:59:08 -0500 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 Subject: [Entmib] FW: [psg.com #326] AutoReply: Too many state objects 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: , The following is the proposed resolution to entstate-326. The issue will be considered closed with no changes made to the document. There was discussion of this issue on the mailing list after which it was agreed the issue could be closed. Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Wednesday, February 11, 2004 12:45 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #326] AutoReply: Too many state objects ------------------------------------------------------------------------- Andy Bierman [abierman@cisco.com] "My concerns are regarding the intent of the MIB -- the actual problem being addressed. So I looked to the Entmib WG charter page for guidance. This is all it says about the Entity State MIB: Done Publish state/status extensions as a WG I-D Mar 04 Submit Entity State MIB to the IESG for Proposed Standard Not a word about the problem being addressed. I thought we set out to add an 'operStatus' object for physical entities -- a simple ( green, yellow, red ) status indicator. Applications would still need to know how to use other MIBs to diagnose or correct a fault. IMO, there's not much value in a generic indicator beyond this, so it's best to keep it simple. From the draft: "Objects are defined to capture administrative, operational and usage states. In addition there are further state objects defined to provide additional information for these three basic states." The document clearly attempts to provide more functionality than a simple 'operStatus' object. The authors have done a fine job defining and documenting this functionality. In order to discuss how well a MIB addresses its intended function, we have to agree on the intended function. " _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Feb 11 16:26:30 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 QAA26952 for ; Wed, 11 Feb 2004 16:26:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1ru-0008JX-Ap; Wed, 11 Feb 2004 16:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1ro-0008J4-Kv for entmib@optimus.ietf.org; Wed, 11 Feb 2004 16:25:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26864 for ; Wed, 11 Feb 2004 16:25:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1rm-0001mq-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:25:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1qs-0001ar-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:24:59 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1pV-00019l-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:23:33 -0500 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 i1BLN0O26180 for ; Wed, 11 Feb 2004 16:23:00 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7LYB>; Wed, 11 Feb 2004 16:23:00 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243C7D@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? Date: Wed, 11 Feb 2004 16:22:59 -0500 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 The term "during" by its nature implies a span of time, rather than single value. If we replaced "that" with "local system" would that work for you? Sharon -----Original Message----- From: Subrahmanya Hegde [mailto:subrah@cisco.com] Sent: Wednesday, February 11, 2004 3:53 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed. If there has been no change since the last re-initialization of the local system, this object contains the date and time of that initialization."' >> may be good to rephrase it as : contains the date and time during initialization 'that' does not seem to fit well Subra Sharon Chisholm wrote: >The following is the proposed resolution to entstate-311. The issue >will be considered closed pending the proposed edit being done. > >Replace > >'entStateLastChanged OBJECT-TYPE > SYNTAX DateAndTime > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of this object is the date and > time when state/status of the entity > last changed, or zero."' > >With > >'entStateLastChanged OBJECT-TYPE > SYNTAX DateAndTime > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of this object is the date and > time when state/status of the entity > last changed. If there has been no change since > the last re-initialization of the local system, > this object contains the date and time of > that initialization."' > >Sharon > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 3:00 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #311] AutoReply: DateAndTimeOrZero ? > > > >----------------------------------------------------------------------- >-- >Keith McCloghrie [kzm@cisco.com] > >should the MIB define DateAndTimeOrZero ? What does zero mean ? > >_______________________________________________ >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 Wed Feb 11 16:26:31 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 QAA26969 for ; Wed, 11 Feb 2004 16:26:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1ru-0008Ji-R0 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 16:26:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BLQ2Ct031970 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 16:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1ru-0008JX-Ap; Wed, 11 Feb 2004 16:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1ro-0008J4-Kv for entmib@optimus.ietf.org; Wed, 11 Feb 2004 16:25:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26864 for ; Wed, 11 Feb 2004 16:25:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1rm-0001mq-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:25:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1qs-0001ar-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:24:59 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1pV-00019l-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:23:33 -0500 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 i1BLN0O26180 for ; Wed, 11 Feb 2004 16:23:00 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7LYB>; Wed, 11 Feb 2004 16:23:00 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243C7D@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? Date: Wed, 11 Feb 2004 16:22:59 -0500 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 The term "during" by its nature implies a span of time, rather than single value. If we replaced "that" with "local system" would that work for you? Sharon -----Original Message----- From: Subrahmanya Hegde [mailto:subrah@cisco.com] Sent: Wednesday, February 11, 2004 3:53 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed. If there has been no change since the last re-initialization of the local system, this object contains the date and time of that initialization."' >> may be good to rephrase it as : contains the date and time during initialization 'that' does not seem to fit well Subra Sharon Chisholm wrote: >The following is the proposed resolution to entstate-311. The issue >will be considered closed pending the proposed edit being done. > >Replace > >'entStateLastChanged OBJECT-TYPE > SYNTAX DateAndTime > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of this object is the date and > time when state/status of the entity > last changed, or zero."' > >With > >'entStateLastChanged OBJECT-TYPE > SYNTAX DateAndTime > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of this object is the date and > time when state/status of the entity > last changed. If there has been no change since > the last re-initialization of the local system, > this object contains the date and time of > that initialization."' > >Sharon > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 3:00 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #311] AutoReply: DateAndTimeOrZero ? > > > >----------------------------------------------------------------------- >-- >Keith McCloghrie [kzm@cisco.com] > >should the MIB define DateAndTimeOrZero ? What does zero mean ? > >_______________________________________________ >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 Wed Feb 11 16:36:33 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 PAA21454 for ; Wed, 11 Feb 2004 15:46:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1FE-0003kA-Me for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 15:46:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BKk4pq014378 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 15:46:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1FC-0003jF-4X; Wed, 11 Feb 2004 15:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1F2-0003iw-SU for entmib@optimus.ietf.org; Wed, 11 Feb 2004 15:45:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21347 for ; Wed, 11 Feb 2004 15:45:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1F1-0002xl-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:45:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1E1-0002rt-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:44:50 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1D3-0002hc-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:43:49 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1BKhHr13502 for ; Wed, 11 Feb 2004 15:43:17 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7KVL>; Wed, 11 Feb 2004 15:43:17 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243C0A@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 15:43:09 -0500 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 Subject: [Entmib] FW: [psg.com #322] AutoReply: 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: , The following is the proposed resolution to entstate-322. The issue will be considered closed with no changes made to the document. There were various bits of discussion on the list on when it is appropriate to use a MIB specific prefix on a textual convention and when it does not. As the intention on these textual conventions is for general use it would seem that a prefix is not appropriate. The proposal is to keep the names as is. Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Friday, February 06, 2004 2:33 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #322] AutoReply: Textual Convention Names (Prefix) ------------------------------------------------------------------------- Andy Bierman [abierman@cisco.com] the TCs should be named with a prefix. E.g., OperState -> EntityOperState. This applies to all the TCs in the draft. _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Feb 11 16:37:30 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 QAA28400 for ; Wed, 11 Feb 2004 16:37:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar22X-0000yZ-S4; Wed, 11 Feb 2004 16:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar21m-0000xR-CQ for entmib@optimus.ietf.org; Wed, 11 Feb 2004 16:36:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28242 for ; Wed, 11 Feb 2004 16:36:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar21k-0003LZ-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:36:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar20n-0003AW-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:35:14 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1zu-0002w2-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:34:18 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 11 Feb 2004 13:34:46 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i1BLXxlP011502; Wed, 11 Feb 2004 13:33:59 -0800 (PST) Received: from cisco.com (dhcp-171-71-252-227.cisco.com [171.71.252.227]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQV68819; Wed, 11 Feb 2004 13:33:58 -0800 (PST) Message-ID: <402A9FC6.2070500@cisco.com> Date: Wed, 11 Feb 2004 13:33:58 -0800 From: Subrahmanya Hegde Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sharon Chisholm CC: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? References: <3549C09B853DD5119B540002A52CDD340A243C7D@zcard0ka.ca.nortel.com> In-Reply-To: <3549C09B853DD5119B540002A52CDD340A243C7D@zcard0ka.ca.nortel.com> Content-Type: multipart/alternative; boundary="------------030506020801040001000600" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY 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: , This is a multi-part message in MIME format. --------------030506020801040001000600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sounds great Subra Sharon Chisholm wrote: >Hi > >The term "during" by its nature implies a span of time, rather than single >value. If we replaced "that" with "local system" would that work for you? > >Sharon > >-----Original Message----- >From: Subrahmanya Hegde [mailto:subrah@cisco.com] >Sent: Wednesday, February 11, 2004 3:53 PM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Cc: entmib@ietf.org >Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? > > >'entStateLastChanged OBJECT-TYPE > SYNTAX DateAndTime > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of this object is the date and > time when state/status of the entity > last changed. If there has been no change since > the last re-initialization of the local system, > > this object contains the date and time of > that initialization."' > > > >>>may be good to rephrase it as : >>> >>> > contains the date and time during initialization > >'that' does not seem to fit well > >Subra > > > > > >Sharon Chisholm wrote: > > > >>The following is the proposed resolution to entstate-311. The issue >>will be considered closed pending the proposed edit being done. >> >>Replace >> >>'entStateLastChanged OBJECT-TYPE >> SYNTAX DateAndTime >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The value of this object is the date and >> time when state/status of the entity >> last changed, or zero."' >> >>With >> >>'entStateLastChanged OBJECT-TYPE >> SYNTAX DateAndTime >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The value of this object is the date and >> time when state/status of the entity >> last changed. If there has been no change since >> the last re-initialization of the local system, >> this object contains the date and time of >> that initialization."' >> >>Sharon >> >>-----Original Message----- >>From: entity-state [mailto:rt+entity-state@rt.psg.com] >>Sent: Tuesday, January 13, 2004 3:00 AM >>To: Chisholm, Sharon [CAR:0S00:EXCH] >>Subject: [psg.com #311] AutoReply: DateAndTimeOrZero ? >> >> >> >>----------------------------------------------------------------------- >>-- >>Keith McCloghrie [kzm@cisco.com] >> >>should the MIB define DateAndTimeOrZero ? What does zero mean ? >> >>_______________________________________________ >>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 > > > --------------030506020801040001000600 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sounds great

Subra


Sharon Chisholm wrote:
Hi

The term "during" by its nature implies a span of time, rather than single
value. If we replaced "that" with "local system" would that work for you? 

Sharon

-----Original Message-----
From: Subrahmanya Hegde [mailto:subrah@cisco.com] 
Sent: Wednesday, February 11, 2004 3:53 PM
To: Chisholm, Sharon [CAR:0S00:EXCH]
Cc: entmib@ietf.org
Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ?


'entStateLastChanged OBJECT-TYPE
  SYNTAX DateAndTime
  MAX-ACCESS read-only
  STATUS current
  DESCRIPTION 
    "The value of this object is the date and
    time when state/status of the entity
    last changed. If there has been no change since
    the last re-initialization of the local system, 

    this object contains the date and time of 
    that initialization."'

  
may be good to rephrase it as :
      
   contains the date and time during initialization

'that' does not seem to fit well

Subra

 



Sharon Chisholm wrote:

  
The following is the proposed resolution to entstate-311. The issue 
will be considered closed pending the proposed edit being done.

Replace

'entStateLastChanged OBJECT-TYPE
 SYNTAX DateAndTime
 MAX-ACCESS read-only
 STATUS current
 DESCRIPTION 
   "The value of this object is the date and
   time when state/status of the entity
   last changed, or zero."'

With

'entStateLastChanged OBJECT-TYPE
 SYNTAX DateAndTime
 MAX-ACCESS read-only
 STATUS current
 DESCRIPTION 
   "The value of this object is the date and
   time when state/status of the entity
   last changed. If there has been no change since
   the last re-initialization of the local system, 
   this object contains the date and time of 
   that initialization."'

Sharon        

-----Original Message-----
From: entity-state [mailto:rt+entity-state@rt.psg.com]
Sent: Tuesday, January 13, 2004 3:00 AM
To: Chisholm, Sharon [CAR:0S00:EXCH]
Subject: [psg.com #311] AutoReply: DateAndTimeOrZero ?

<clip>

-----------------------------------------------------------------------
--
Keith McCloghrie [kzm@cisco.com]

should the MIB define DateAndTimeOrZero ?  What does zero mean ?

_______________________________________________
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
--------------030506020801040001000600-- _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Feb 11 16:37:31 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 QAA28417 for ; Wed, 11 Feb 2004 16:37:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar22Y-0000yw-59 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 16:37:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BLb2Xk003761 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 16:37:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar22X-0000yZ-S4; Wed, 11 Feb 2004 16:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar21m-0000xR-CQ for entmib@optimus.ietf.org; Wed, 11 Feb 2004 16:36:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28242 for ; Wed, 11 Feb 2004 16:36:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar21k-0003LZ-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:36:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar20n-0003AW-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:35:14 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1zu-0002w2-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:34:18 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 11 Feb 2004 13:34:46 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i1BLXxlP011502; Wed, 11 Feb 2004 13:33:59 -0800 (PST) Received: from cisco.com (dhcp-171-71-252-227.cisco.com [171.71.252.227]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQV68819; Wed, 11 Feb 2004 13:33:58 -0800 (PST) Message-ID: <402A9FC6.2070500@cisco.com> Date: Wed, 11 Feb 2004 13:33:58 -0800 From: Subrahmanya Hegde Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sharon Chisholm CC: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? References: <3549C09B853DD5119B540002A52CDD340A243C7D@zcard0ka.ca.nortel.com> In-Reply-To: <3549C09B853DD5119B540002A52CDD340A243C7D@zcard0ka.ca.nortel.com> Content-Type: multipart/alternative; boundary="------------030506020801040001000600" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY 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: , This is a multi-part message in MIME format. --------------030506020801040001000600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sounds great Subra Sharon Chisholm wrote: >Hi > >The term "during" by its nature implies a span of time, rather than single >value. If we replaced "that" with "local system" would that work for you? > >Sharon > >-----Original Message----- >From: Subrahmanya Hegde [mailto:subrah@cisco.com] >Sent: Wednesday, February 11, 2004 3:53 PM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Cc: entmib@ietf.org >Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? > > >'entStateLastChanged OBJECT-TYPE > SYNTAX DateAndTime > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of this object is the date and > time when state/status of the entity > last changed. If there has been no change since > the last re-initialization of the local system, > > this object contains the date and time of > that initialization."' > > > >>>may be good to rephrase it as : >>> >>> > contains the date and time during initialization > >'that' does not seem to fit well > >Subra > > > > > >Sharon Chisholm wrote: > > > >>The following is the proposed resolution to entstate-311. The issue >>will be considered closed pending the proposed edit being done. >> >>Replace >> >>'entStateLastChanged OBJECT-TYPE >> SYNTAX DateAndTime >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The value of this object is the date and >> time when state/status of the entity >> last changed, or zero."' >> >>With >> >>'entStateLastChanged OBJECT-TYPE >> SYNTAX DateAndTime >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The value of this object is the date and >> time when state/status of the entity >> last changed. If there has been no change since >> the last re-initialization of the local system, >> this object contains the date and time of >> that initialization."' >> >>Sharon >> >>-----Original Message----- >>From: entity-state [mailto:rt+entity-state@rt.psg.com] >>Sent: Tuesday, January 13, 2004 3:00 AM >>To: Chisholm, Sharon [CAR:0S00:EXCH] >>Subject: [psg.com #311] AutoReply: DateAndTimeOrZero ? >> >> >> >>----------------------------------------------------------------------- >>-- >>Keith McCloghrie [kzm@cisco.com] >> >>should the MIB define DateAndTimeOrZero ? What does zero mean ? >> >>_______________________________________________ >>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 > > > --------------030506020801040001000600 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sounds great

Subra


Sharon Chisholm wrote:
Hi

The term "during" by its nature implies a span of time, rather than single
value. If we replaced "that" with "local system" would that work for you? 

Sharon

-----Original Message-----
From: Subrahmanya Hegde [mailto:subrah@cisco.com] 
Sent: Wednesday, February 11, 2004 3:53 PM
To: Chisholm, Sharon [CAR:0S00:EXCH]
Cc: entmib@ietf.org
Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ?


'entStateLastChanged OBJECT-TYPE
  SYNTAX DateAndTime
  MAX-ACCESS read-only
  STATUS current
  DESCRIPTION 
    "The value of this object is the date and
    time when state/status of the entity
    last changed. If there has been no change since
    the last re-initialization of the local system, 

    this object contains the date and time of 
    that initialization."'

  
may be good to rephrase it as :
      
   contains the date and time during initialization

'that' does not seem to fit well

Subra

 



Sharon Chisholm wrote:

  
The following is the proposed resolution to entstate-311. The issue 
will be considered closed pending the proposed edit being done.

Replace

'entStateLastChanged OBJECT-TYPE
 SYNTAX DateAndTime
 MAX-ACCESS read-only
 STATUS current
 DESCRIPTION 
   "The value of this object is the date and
   time when state/status of the entity
   last changed, or zero."'

With

'entStateLastChanged OBJECT-TYPE
 SYNTAX DateAndTime
 MAX-ACCESS read-only
 STATUS current
 DESCRIPTION 
   "The value of this object is the date and
   time when state/status of the entity
   last changed. If there has been no change since
   the last re-initialization of the local system, 
   this object contains the date and time of 
   that initialization."'

Sharon        

-----Original Message-----
From: entity-state [mailto:rt+entity-state@rt.psg.com]
Sent: Tuesday, January 13, 2004 3:00 AM
To: Chisholm, Sharon [CAR:0S00:EXCH]
Subject: [psg.com #311] AutoReply: DateAndTimeOrZero ?

<clip>

-----------------------------------------------------------------------
--
Keith McCloghrie [kzm@cisco.com]

should the MIB define DateAndTimeOrZero ?  What does zero mean ?

_______________________________________________
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
--------------030506020801040001000600-- _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Feb 11 16:39: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 QAA28612 for ; Wed, 11 Feb 2004 16:39:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar24S-0001NU-Hf; Wed, 11 Feb 2004 16:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar24G-0001Io-7E for entmib@optimus.ietf.org; Wed, 11 Feb 2004 16:38:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28570 for ; Wed, 11 Feb 2004 16:38:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar24E-0003n4-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:38:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar23J-0003eR-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:37:50 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Ar22V-0003NI-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:36:59 -0500 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 i1BLaPO02013 for ; Wed, 11 Feb 2004 16:36:26 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7MA2>; Wed, 11 Feb 2004 16:36:26 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243CB6@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? Date: Wed, 11 Feb 2004 16:36:25 -0500 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: , The following is the proposed resolution to entstate-311. The issue will be considered closed pending the proposed edit being done. Replace 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed, or zero."' With 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed. If there has been no change since the last re-initialization of the local system, this object contains the date and time of local system initialization."' Sharon -----Original Message----- From: Subrahmanya Hegde [mailto:subrah@cisco.com] Sent: Wednesday, February 11, 2004 4:34 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? Sounds great Subra Sharon Chisholm wrote: Hi The term "during" by its nature implies a span of time, rather than single value. If we replaced "that" with "local system" would that work for you? Sharon -----Original Message----- From: Subrahmanya Hegde [mailto:subrah@cisco.com ] Sent: Wednesday, February 11, 2004 3:53 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed. If there has been no change since the last re-initialization of the local system, this object contains the date and time of that initialization."' may be good to rephrase it as : contains the date and time during initialization 'that' does not seem to fit well Subra Sharon Chisholm wrote: The following is the proposed resolution to entstate-311. The issue will be considered closed pending the proposed edit being done. Replace 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed, or zero."' With 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed. If there has been no change since the last re-initialization of the local system, this object contains the date and time of that initialization."' Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com ] Sent: Tuesday, January 13, 2004 3:00 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #311] AutoReply: DateAndTimeOrZero ? ----------------------------------------------------------------------- -- Keith McCloghrie [kzm@cisco.com ] should the MIB define DateAndTimeOrZero ? What does zero mean ? _______________________________________________ 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 Wed Feb 11 16:43:15 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 PAA23179 for ; Wed, 11 Feb 2004 15:57:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Pq-0004wu-A0 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 15:57:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BKv2Ys019007 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 15:57:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Pq-0004wQ-57; Wed, 11 Feb 2004 15:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Oo-0004sb-BU for entmib@optimus.ietf.org; Wed, 11 Feb 2004 15:55:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23069 for ; Wed, 11 Feb 2004 15:55:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1Om-0004Ci-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:55:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1Nv-00046g-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:55:04 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1NA-0003sQ-00 for entmib@ietf.org; Wed, 11 Feb 2004 15:54:17 -0500 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 i1BKrhu20832 for ; Wed, 11 Feb 2004 15:53:44 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7K98>; Wed, 11 Feb 2004 15:53:44 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243C29@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 11 Feb 2004 15:53:40 -0500 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 Subject: [Entmib] FW: [psg.com #325] AutoReply: 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: , The following is the proposed resolution to entstate-325. The issue will be considered closed with no changes made to the document, other than those already identified with issue #306. The MIB review guidelines (August 2003) show the following xxxMIB | +-- xxxNotifications(0) +-- xxxObjects(1) +-- xxxConformance(2) | +-- xxxCompliances(1) +-- xxxGroups(2) The MIB currently defines, after we make the change identified in problem #306 entStateMIB | +-- entStateNotifications(0) +-- entStateObjects(1) +-- entStateConformance(2) | +-- entStateCompliances(1) +-- entStateroups(2) This is without making any further changes related to these specific comments. Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Wednesday, February 11, 2004 12:38 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #325] AutoReply: ------------------------------------------------------------------------- Subrahmanya Hegde [subrah@cisco.com]: "As per the MIB convention : We should define a OID under 'entStateObjects' and use that in the xxxTable. For example: entStateObjects OBJECT IDENTIFIER ::= { entityStateMIB 1} add: entityState OBJECT IDENTIFIER ::= { entStateObjects 1} use this 'entityState'(or whatever else makes sense) for entStateTable in the mib 4. entStateConformance must be under { entityStateMIB 2} 3. I think OID definition for 'entityStateGroups' is missing it should be entStateGroups OBJECT IDENTIFIER ::= { entStateConformance 2} " _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Feb 11 17:28:15 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 QAA28614 for ; Wed, 11 Feb 2004 16:39:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar24S-0001O3-Qn for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 16:39:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BLd0lu005310 for entmib-archive@odin.ietf.org; Wed, 11 Feb 2004 16:39:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar24S-0001NU-Hf; Wed, 11 Feb 2004 16:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar24G-0001Io-7E for entmib@optimus.ietf.org; Wed, 11 Feb 2004 16:38:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28570 for ; Wed, 11 Feb 2004 16:38:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar24E-0003n4-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:38:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar23J-0003eR-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:37:50 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Ar22V-0003NI-00 for entmib@ietf.org; Wed, 11 Feb 2004 16:36:59 -0500 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 i1BLaPO02013 for ; Wed, 11 Feb 2004 16:36:26 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH7MA2>; Wed, 11 Feb 2004 16:36:26 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A243CB6@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? Date: Wed, 11 Feb 2004 16:36:25 -0500 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: , The following is the proposed resolution to entstate-311. The issue will be considered closed pending the proposed edit being done. Replace 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed, or zero."' With 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed. If there has been no change since the last re-initialization of the local system, this object contains the date and time of local system initialization."' Sharon -----Original Message----- From: Subrahmanya Hegde [mailto:subrah@cisco.com] Sent: Wednesday, February 11, 2004 4:34 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? Sounds great Subra Sharon Chisholm wrote: Hi The term "during" by its nature implies a span of time, rather than single value. If we replaced "that" with "local system" would that work for you? Sharon -----Original Message----- From: Subrahmanya Hegde [mailto:subrah@cisco.com ] Sent: Wednesday, February 11, 2004 3:53 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed. If there has been no change since the last re-initialization of the local system, this object contains the date and time of that initialization."' may be good to rephrase it as : contains the date and time during initialization 'that' does not seem to fit well Subra Sharon Chisholm wrote: The following is the proposed resolution to entstate-311. The issue will be considered closed pending the proposed edit being done. Replace 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed, or zero."' With 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed. If there has been no change since the last re-initialization of the local system, this object contains the date and time of that initialization."' Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com ] Sent: Tuesday, January 13, 2004 3:00 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #311] AutoReply: DateAndTimeOrZero ? ----------------------------------------------------------------------- -- Keith McCloghrie [kzm@cisco.com ] should the MIB define DateAndTimeOrZero ? What does zero mean ? _______________________________________________ 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 Feb 12 13:34:30 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 NAA06042 for ; Thu, 12 Feb 2004 13:34:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLez-0006GR-H2; Thu, 12 Feb 2004 13:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLeO-0006F2-2j for entmib@optimus.ietf.org; Thu, 12 Feb 2004 13:33:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06021 for ; Thu, 12 Feb 2004 13:33:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArLeK-0003u4-00 for entmib@ietf.org; Thu, 12 Feb 2004 13:33:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArLdR-0003pV-00 for entmib@ietf.org; Thu, 12 Feb 2004 13:32:26 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArLcw-0003jx-00 for entmib@ietf.org; Thu, 12 Feb 2004 13:31:54 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1CIVOD25106 for ; Thu, 12 Feb 2004 13:31:24 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH75AB>; Thu, 12 Feb 2004 13:31:25 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A244318@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Thu, 12 Feb 2004 13:31:23 -0500 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 Subject: [Entmib] FW: [psg.com #327] AutoReply: More Editorial 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: , The following is the proposed resolution to entstate-327. The issue will be considered closed pending the proposed edit being done. 1) Change the end of the abstract from "provide information about the state of the entity." to the following: "provide information about the state of physical entities." 2) In the description to StandbyStatus replace " providing service, but is will be immediately able to" With " providing service, but it will be immediately able to" 3) Note that the resolution to issue #311 covers this 4) In the description of entStateAdmin replace "The administrative state for this entity. A value of 'notSupported' means that this entity is unable to report administrative state. This object can not be administratively set to 'notSupported'. For entities that do not support administrative state, changing the value of this object to something other than 'notSupported' is not permitted. A value of 'inconsistentValue' will be returned in either case." With "The administrative state for this entity. A value of 'notSupported' means that this entity is unable to report administrative state. This object can not be manually set to 'notSupported'. For entities that do not support administrative state, changing the value of this object to something other than 'notSupported' is not permitted. A value of 'inconsistentValue' will be returned in either case." 7) Replace " entStateNotificationGroup NOTIFICATION-GROUP" With " entStateNotificationsGroup NOTIFICATION-GROUP " Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Wednesday, February 11, 2004 12:53 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #327] AutoReply: More Editorial Issues ------------------------------------------------------------------------- Juergen Schoenwaelder [j.schoenwaelder@iu-bremen.de] "1) Change the end of the abstract from provide information about the state of the entity. to the following: provide information about the state of physical entities. Rationale: This MIB is specific to physical entities and since the ENTITY-MIB also has the concept of logical entities, I think it is better to more precise. 2) Description of StandByStatus, change "... but is will be immediately ..." to the following: "... but will be immediately ..." 3) Description of entStateLastChanged, change DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed, or zero." to the following: DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed, or '0000000000000000'H." 4) Description of entStateAdmin. I believe the following two sentences are kind of a contradiction: [...] This object can not be administratively set to 'notSupported'. For entities that do not support administrative state, changing the value of this object to something other than 'notSupported' is not permitted. A value of 'inconsistentValue' will be returned in either case. With the text in the second paragraph of the description clause, I think this can be fixed by just removing a sentence without loosing anything: [...] This object can not be administratively set to 'notSupported'. A value of 'inconsistentValue' will be returned in either case. 7) The MIB did not compile because you once use entStateNotificationGroup and once you use entStateNotificationsGroup (see the plural s). Pick one. _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu Feb 12 13:48:29 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 NAA06706 for ; Thu, 12 Feb 2004 13:48:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLsX-00085S-0w for entmib-archive@odin.ietf.org; Thu, 12 Feb 2004 13:48:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CIm1rJ031070 for entmib-archive@odin.ietf.org; Thu, 12 Feb 2004 13:48:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLsW-000851-Lo; Thu, 12 Feb 2004 13:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLrv-0007yo-I3 for entmib@optimus.ietf.org; Thu, 12 Feb 2004 13:47:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06596 for ; Thu, 12 Feb 2004 13:47:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArLrr-00056e-00 for entmib@ietf.org; Thu, 12 Feb 2004 13:47:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArLqx-00050H-00 for entmib@ietf.org; Thu, 12 Feb 2004 13:46:23 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArLpq-0004ql-00 for entmib@ietf.org; Thu, 12 Feb 2004 13:45:14 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1CIiiD26661 for ; Thu, 12 Feb 2004 13:44:44 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH75NG>; Thu, 12 Feb 2004 13:44:44 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A244352@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Thu, 12 Feb 2004 13:44:44 -0500 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 Subject: [Entmib] FW: [psg.com #328] AutoReply: Containment Hierach and entPhysical Containedin 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: , The following is the proposed resolution to entstate-328. The issue will be considered closed pending the proposed edit being done. In the various object definitions replace phrases like "as defined by a value of entPhysicalContainedIn that references this entity" With one like "as defined by the entPhysicalContainedIn object." Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Wednesday, February 11, 2004 12:56 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #328] AutoReply: Containment Hierach and entPhysicalContainedin ------------------------------------------------------------------------- Juergen Schoenwaelder [j.schoenwaelder@iu-bremen.de] "5) Several description clauses refer to "entities within its containment hierarchy" followed by a sentence which limits this to the entities "having a value of entPhysicalContainedIn that refers to this entity". This somehow excludes transitive containment. Is this by intention or accident? I mean, if I have C contained in B contained in A, then A still provides indirect service to C." _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Thu Feb 12 13:48:30 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 NAA06707 for ; Thu, 12 Feb 2004 13:48:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLsW-000851-Lo; Thu, 12 Feb 2004 13:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLrv-0007yo-I3 for entmib@optimus.ietf.org; Thu, 12 Feb 2004 13:47:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06596 for ; Thu, 12 Feb 2004 13:47:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArLrr-00056e-00 for entmib@ietf.org; Thu, 12 Feb 2004 13:47:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArLqx-00050H-00 for entmib@ietf.org; Thu, 12 Feb 2004 13:46:23 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArLpq-0004ql-00 for entmib@ietf.org; Thu, 12 Feb 2004 13:45:14 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1CIiiD26661 for ; Thu, 12 Feb 2004 13:44:44 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH75NG>; Thu, 12 Feb 2004 13:44:44 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A244352@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Thu, 12 Feb 2004 13:44:44 -0500 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 Subject: [Entmib] FW: [psg.com #328] AutoReply: Containment Hierach and entPhysical Containedin 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: , The following is the proposed resolution to entstate-328. The issue will be considered closed pending the proposed edit being done. In the various object definitions replace phrases like "as defined by a value of entPhysicalContainedIn that references this entity" With one like "as defined by the entPhysicalContainedIn object." Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Wednesday, February 11, 2004 12:56 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #328] AutoReply: Containment Hierach and entPhysicalContainedin ------------------------------------------------------------------------- Juergen Schoenwaelder [j.schoenwaelder@iu-bremen.de] "5) Several description clauses refer to "entities within its containment hierarchy" followed by a sentence which limits this to the entities "having a value of entPhysicalContainedIn that refers to this entity". This somehow excludes transitive containment. Is this by intention or accident? I mean, if I have C contained in B contained in A, then A still provides indirect service to C." _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu Feb 12 14:23:24 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 NAA06044 for ; Thu, 12 Feb 2004 13:34:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLez-0006Go-UQ for entmib-archive@odin.ietf.org; Thu, 12 Feb 2004 13:34:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CIY1bu024090 for entmib-archive@odin.ietf.org; Thu, 12 Feb 2004 13:34:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLez-0006GR-H2; Thu, 12 Feb 2004 13:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArLeO-0006F2-2j for entmib@optimus.ietf.org; Thu, 12 Feb 2004 13:33:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06021 for ; Thu, 12 Feb 2004 13:33:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArLeK-0003u4-00 for entmib@ietf.org; Thu, 12 Feb 2004 13:33:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArLdR-0003pV-00 for entmib@ietf.org; Thu, 12 Feb 2004 13:32:26 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArLcw-0003jx-00 for entmib@ietf.org; Thu, 12 Feb 2004 13:31:54 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1CIVOD25106 for ; Thu, 12 Feb 2004 13:31:24 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH75AB>; Thu, 12 Feb 2004 13:31:25 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A244318@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Thu, 12 Feb 2004 13:31:23 -0500 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 Subject: [Entmib] FW: [psg.com #327] AutoReply: More Editorial 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: , The following is the proposed resolution to entstate-327. The issue will be considered closed pending the proposed edit being done. 1) Change the end of the abstract from "provide information about the state of the entity." to the following: "provide information about the state of physical entities." 2) In the description to StandbyStatus replace " providing service, but is will be immediately able to" With " providing service, but it will be immediately able to" 3) Note that the resolution to issue #311 covers this 4) In the description of entStateAdmin replace "The administrative state for this entity. A value of 'notSupported' means that this entity is unable to report administrative state. This object can not be administratively set to 'notSupported'. For entities that do not support administrative state, changing the value of this object to something other than 'notSupported' is not permitted. A value of 'inconsistentValue' will be returned in either case." With "The administrative state for this entity. A value of 'notSupported' means that this entity is unable to report administrative state. This object can not be manually set to 'notSupported'. For entities that do not support administrative state, changing the value of this object to something other than 'notSupported' is not permitted. A value of 'inconsistentValue' will be returned in either case." 7) Replace " entStateNotificationGroup NOTIFICATION-GROUP" With " entStateNotificationsGroup NOTIFICATION-GROUP " Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Wednesday, February 11, 2004 12:53 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #327] AutoReply: More Editorial Issues ------------------------------------------------------------------------- Juergen Schoenwaelder [j.schoenwaelder@iu-bremen.de] "1) Change the end of the abstract from provide information about the state of the entity. to the following: provide information about the state of physical entities. Rationale: This MIB is specific to physical entities and since the ENTITY-MIB also has the concept of logical entities, I think it is better to more precise. 2) Description of StandByStatus, change "... but is will be immediately ..." to the following: "... but will be immediately ..." 3) Description of entStateLastChanged, change DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed, or zero." to the following: DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed, or '0000000000000000'H." 4) Description of entStateAdmin. I believe the following two sentences are kind of a contradiction: [...] This object can not be administratively set to 'notSupported'. For entities that do not support administrative state, changing the value of this object to something other than 'notSupported' is not permitted. A value of 'inconsistentValue' will be returned in either case. With the text in the second paragraph of the description clause, I think this can be fixed by just removing a sentence without loosing anything: [...] This object can not be administratively set to 'notSupported'. A value of 'inconsistentValue' will be returned in either case. 7) The MIB did not compile because you once use entStateNotificationGroup and once you use entStateNotificationsGroup (see the plural s). Pick one. _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Thu Feb 12 14:49:29 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 OAA09733 for ; Thu, 12 Feb 2004 14:49:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArMpZ-0005n2-GY; Thu, 12 Feb 2004 14:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArMp1-0005kA-BX for entmib@optimus.ietf.org; Thu, 12 Feb 2004 14:48:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09681 for ; Thu, 12 Feb 2004 14:48:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArMow-0003c1-00 for entmib@ietf.org; Thu, 12 Feb 2004 14:48:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArMo0-0003XW-00 for entmib@ietf.org; Thu, 12 Feb 2004 14:47:25 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArMnq-0003Sp-00 for entmib@ietf.org; Thu, 12 Feb 2004 14:47:14 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1CJkjD11178 for ; Thu, 12 Feb 2004 14:46:45 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH77HW>; Thu, 12 Feb 2004 14:46:45 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A24445E@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Thu, 12 Feb 2004 14:46:42 -0500 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 Subject: [Entmib] FW: [psg.com #329] AutoReply: Usage State Scope 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: , The following is the proposed resolution to entstate-329. The issue will be considered closed with no changes made to the document. Well, this is the one object that most directly relates to its child component. Our definition only talks about child components in terms of physical entities. So, the ability of a port to 'contain' an logical interface isn't reported by this status. I might be convinced to change the definition but I think this concepts starts getting harder to describe and understand when we start mixing physical containment and logical to physical mappings. I worry that talking about leafs and containers might confuse people. The current definition speaks in terms of whether something else can be contained in it. This is more consistent with the rest of the discussion. Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Wednesday, February 11, 2004 12:59 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #329] AutoReply: Usage State Scope ------------------------------------------------------------------------- Juergen Schoenwaelder [j.schoenwaelder@iu-bremen.de] "I was surprised to read the entStateUsage description which says the UsageState is strictly bound to the containment relationship between entities. In general, the containment hierarchy is made up of containers and leafs. The entStateUsage description basically says that the UsageState is only interesting for containers since leafs are always busy. I found this interesting since the other objects do not make this distinction and some of them seem to particularly useful for leafs (e.g. interfaces). Perhaps it makes sense to define for each entState* column how it applies to containers and how it applies to leafs. For example, what does it mean to lock/unlock a container? (I believe entStateAdmin is more defined for leafs rather than containers.)" _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Thu Feb 12 15:01:29 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 PAA10164 for ; Thu, 12 Feb 2004 15:01:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArN1B-0002HN-Lb; Thu, 12 Feb 2004 15:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArN0f-0001px-8L for entmib@optimus.ietf.org; Thu, 12 Feb 2004 15:00:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10101 for ; Thu, 12 Feb 2004 15:00:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArN0a-0004if-00 for entmib@ietf.org; Thu, 12 Feb 2004 15:00:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArMzb-0004cD-00 for entmib@ietf.org; Thu, 12 Feb 2004 14:59:23 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ArMym-0004TJ-00 for entmib@ietf.org; Thu, 12 Feb 2004 14:58:32 -0500 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 i1CJw3D28305 for ; Thu, 12 Feb 2004 14:58:03 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH77RG>; Thu, 12 Feb 2004 14:58:04 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A24448B@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Thu, 12 Feb 2004 14:57:58 -0500 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 Subject: [Entmib] FW: [psg.com #330] AutoReply: Notification Varbinds 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: , The following is the proposed resolution to entstate-330. The issue will be considered closed with no changes made to the document. The notifications tell when the operational state for the given entPhysicalIndex has changed. The notification contains the two varbinds entStateAdmin and entStateAlarm. entPhysicalIndex can be extracted from one of those varbinds. The missing information is then the usage state, which is not that interesting from a fault management perspective and the standyby state which is usually going to be 'providingService'. I think we get the usefulness of admin status. The alarm status tells you how many outstanding problems have been reported against this entity. This is interesting from a fault management perspective. Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Wednesday, February 11, 2004 1:01 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #330] AutoReply: Notification Varbinds ------------------------------------------------------------------------- Juergen Schoenwaelder [j.schoenwaelder@iu-bremen.de] "I am wondering why both notifications contain the entStateAlarm value, especially entStateOperEnabled notification. This surely is not wrong, but I am wondering what the rationale for including the entStateAlarm is (and for excluding other objects)." _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu Feb 12 15:01:29 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 PAA10168 for ; Thu, 12 Feb 2004 15:01:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArN1C-0002IA-0Y for entmib-archive@odin.ietf.org; Thu, 12 Feb 2004 15:01:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CK11GC008790 for entmib-archive@odin.ietf.org; Thu, 12 Feb 2004 15:01:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArN1B-0002HN-Lb; Thu, 12 Feb 2004 15:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArN0f-0001px-8L for entmib@optimus.ietf.org; Thu, 12 Feb 2004 15:00:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10101 for ; Thu, 12 Feb 2004 15:00:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArN0a-0004if-00 for entmib@ietf.org; Thu, 12 Feb 2004 15:00:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArMzb-0004cD-00 for entmib@ietf.org; Thu, 12 Feb 2004 14:59:23 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ArMym-0004TJ-00 for entmib@ietf.org; Thu, 12 Feb 2004 14:58:32 -0500 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 i1CJw3D28305 for ; Thu, 12 Feb 2004 14:58:03 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH77RG>; Thu, 12 Feb 2004 14:58:04 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A24448B@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Thu, 12 Feb 2004 14:57:58 -0500 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 Subject: [Entmib] FW: [psg.com #330] AutoReply: Notification Varbinds 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: , The following is the proposed resolution to entstate-330. The issue will be considered closed with no changes made to the document. The notifications tell when the operational state for the given entPhysicalIndex has changed. The notification contains the two varbinds entStateAdmin and entStateAlarm. entPhysicalIndex can be extracted from one of those varbinds. The missing information is then the usage state, which is not that interesting from a fault management perspective and the standyby state which is usually going to be 'providingService'. I think we get the usefulness of admin status. The alarm status tells you how many outstanding problems have been reported against this entity. This is interesting from a fault management perspective. Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Wednesday, February 11, 2004 1:01 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #330] AutoReply: Notification Varbinds ------------------------------------------------------------------------- Juergen Schoenwaelder [j.schoenwaelder@iu-bremen.de] "I am wondering why both notifications contain the entStateAlarm value, especially entStateOperEnabled notification. This surely is not wrong, but I am wondering what the rationale for including the entStateAlarm is (and for excluding other objects)." _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu Feb 12 15:38:25 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 OAA09736 for ; Thu, 12 Feb 2004 14:49:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArMpZ-0005nF-N6 for entmib-archive@odin.ietf.org; Thu, 12 Feb 2004 14:49:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CJn1KH022268 for entmib-archive@odin.ietf.org; Thu, 12 Feb 2004 14:49:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArMpZ-0005n2-GY; Thu, 12 Feb 2004 14:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArMp1-0005kA-BX for entmib@optimus.ietf.org; Thu, 12 Feb 2004 14:48:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09681 for ; Thu, 12 Feb 2004 14:48:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArMow-0003c1-00 for entmib@ietf.org; Thu, 12 Feb 2004 14:48:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArMo0-0003XW-00 for entmib@ietf.org; Thu, 12 Feb 2004 14:47:25 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArMnq-0003Sp-00 for entmib@ietf.org; Thu, 12 Feb 2004 14:47:14 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1CJkjD11178 for ; Thu, 12 Feb 2004 14:46:45 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH77HW>; Thu, 12 Feb 2004 14:46:45 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A24445E@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Thu, 12 Feb 2004 14:46:42 -0500 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 Subject: [Entmib] FW: [psg.com #329] AutoReply: Usage State Scope 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: , The following is the proposed resolution to entstate-329. The issue will be considered closed with no changes made to the document. Well, this is the one object that most directly relates to its child component. Our definition only talks about child components in terms of physical entities. So, the ability of a port to 'contain' an logical interface isn't reported by this status. I might be convinced to change the definition but I think this concepts starts getting harder to describe and understand when we start mixing physical containment and logical to physical mappings. I worry that talking about leafs and containers might confuse people. The current definition speaks in terms of whether something else can be contained in it. This is more consistent with the rest of the discussion. Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Wednesday, February 11, 2004 12:59 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #329] AutoReply: Usage State Scope ------------------------------------------------------------------------- Juergen Schoenwaelder [j.schoenwaelder@iu-bremen.de] "I was surprised to read the entStateUsage description which says the UsageState is strictly bound to the containment relationship between entities. In general, the containment hierarchy is made up of containers and leafs. The entStateUsage description basically says that the UsageState is only interesting for containers since leafs are always busy. I found this interesting since the other objects do not make this distinction and some of them seem to particularly useful for leafs (e.g. interfaces). Perhaps it makes sense to define for each entState* column how it applies to containers and how it applies to leafs. For example, what does it mean to lock/unlock a container? (I believe entStateAdmin is more defined for leafs rather than containers.)" _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Thu Feb 12 15:55:33 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 PAA14786 for ; Thu, 12 Feb 2004 15:55:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNrT-0004PI-Vq; Thu, 12 Feb 2004 15:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNqu-0004Mr-RD for entmib@optimus.ietf.org; Thu, 12 Feb 2004 15:54:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14674 for ; Thu, 12 Feb 2004 15:54:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNqr-0002pD-00 for entmib@ietf.org; Thu, 12 Feb 2004 15:54:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNpt-0002iW-00 for entmib@ietf.org; Thu, 12 Feb 2004 15:53:26 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNp2-0002bP-00 for entmib@ietf.org; Thu, 12 Feb 2004 15:52:32 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1CKqR304895; Thu, 12 Feb 2004 12:52:27 -0800 Message-Id: <5.2.0.9.2.20040212123438.01ef1df0@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Feb 2004 12:51:15 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Subject: Re: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is semantically wrong In-Reply-To: <3549C09B853DD5119B540002A52CDD340A243A4B@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, For me, the term "notReportable" is worse than "notSupported". The terms "notSupported", "unknown" and "unavailable" are used in MIB modules indicate an appropriate value cannot be obtained by the access or instrumentation code. Mods: section 3.1, pp 3 section 3.4 TC AdminState TC OperState TC UsageState TC AlarmStatus TC StandbyStatus Object entStateAdmin Object entStateOper Object entStateUsage Object entStateAlarm Object entStateStandby At 01:53 PM 2/11/2004 -0500, Sharon Chisholm wrote: >Hi > >That last bit should read > >""A value >of 'notReportable' means that this resource is unable to report [this] >state." > >Sharon > >-----Original Message----- >From: Chisholm, Sharon [CAR:0S00:EXCH] >Sent: Wednesday, February 11, 2004 1:51 PM >To: 'entmib@ietf.org' >Subject: FW: [psg.com #307] AutoReply: 'notSupported' is semantically wrong > > >The following is the proposed resolution to entstate-307. The issue will be >considered closed pending the proposed edit being done. > >Replace the enumeration 'notSupported' with 'notReportable' in each of the >TCs and any references within the text. > >For each of the (TC, object definition) pairs, move the following sort of >text from the object definition to the textual convention: > >"A value >of 'notApplicable' means that this resource is unable to report [this] >state." > >Sharon > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 2:50 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #307] AutoReply: 'notSupported' is semantically wrong > > > >------------------------------------------------------------------------- >Keith McCloghrie [kzm@cisco.com] > >" >> 'notSupported' is semantically wrong, because a compliant >implementation >> obviously supports the MIB, but it can return 'notSupported' for >> every object in the MIB. Presumably, the intended semantics is that >> the agent would return the right value if only it knew the right >value; >> i.e., 'unknown' is the desired semantics. Also, why is each >definition >> of 'notSupported' defined in an object's DESCRIPTION, not in the >TC's >> DESCRIPTION ?" /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu Feb 12 15:55:35 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 PAA14803 for ; Thu, 12 Feb 2004 15:55:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNrV-0004Pm-1T for entmib-archive@odin.ietf.org; Thu, 12 Feb 2004 15:55:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CKt4sf016956 for entmib-archive@odin.ietf.org; Thu, 12 Feb 2004 15:55:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNrT-0004PI-Vq; Thu, 12 Feb 2004 15:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNqu-0004Mr-RD for entmib@optimus.ietf.org; Thu, 12 Feb 2004 15:54:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14674 for ; Thu, 12 Feb 2004 15:54:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNqr-0002pD-00 for entmib@ietf.org; Thu, 12 Feb 2004 15:54:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNpt-0002iW-00 for entmib@ietf.org; Thu, 12 Feb 2004 15:53:26 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNp2-0002bP-00 for entmib@ietf.org; Thu, 12 Feb 2004 15:52:32 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1CKqR304895; Thu, 12 Feb 2004 12:52:27 -0800 Message-Id: <5.2.0.9.2.20040212123438.01ef1df0@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Feb 2004 12:51:15 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Subject: Re: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is semantically wrong In-Reply-To: <3549C09B853DD5119B540002A52CDD340A243A4B@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, For me, the term "notReportable" is worse than "notSupported". The terms "notSupported", "unknown" and "unavailable" are used in MIB modules indicate an appropriate value cannot be obtained by the access or instrumentation code. Mods: section 3.1, pp 3 section 3.4 TC AdminState TC OperState TC UsageState TC AlarmStatus TC StandbyStatus Object entStateAdmin Object entStateOper Object entStateUsage Object entStateAlarm Object entStateStandby At 01:53 PM 2/11/2004 -0500, Sharon Chisholm wrote: >Hi > >That last bit should read > >""A value >of 'notReportable' means that this resource is unable to report [this] >state." > >Sharon > >-----Original Message----- >From: Chisholm, Sharon [CAR:0S00:EXCH] >Sent: Wednesday, February 11, 2004 1:51 PM >To: 'entmib@ietf.org' >Subject: FW: [psg.com #307] AutoReply: 'notSupported' is semantically wrong > > >The following is the proposed resolution to entstate-307. The issue will be >considered closed pending the proposed edit being done. > >Replace the enumeration 'notSupported' with 'notReportable' in each of the >TCs and any references within the text. > >For each of the (TC, object definition) pairs, move the following sort of >text from the object definition to the textual convention: > >"A value >of 'notApplicable' means that this resource is unable to report [this] >state." > >Sharon > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 2:50 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #307] AutoReply: 'notSupported' is semantically wrong > > > >------------------------------------------------------------------------- >Keith McCloghrie [kzm@cisco.com] > >" >> 'notSupported' is semantically wrong, because a compliant >implementation >> obviously supports the MIB, but it can return 'notSupported' for >> every object in the MIB. Presumably, the intended semantics is that >> the agent would return the right value if only it knew the right >value; >> i.e., 'unknown' is the desired semantics. Also, why is each >definition >> of 'notSupported' defined in an object's DESCRIPTION, not in the >TC's >> DESCRIPTION ?" /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Thu Feb 12 16:02:31 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 QAA15401 for ; Thu, 12 Feb 2004 16:02:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNyE-0005Il-7V; Thu, 12 Feb 2004 16:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNxf-0005Hv-In for entmib@optimus.ietf.org; Thu, 12 Feb 2004 16:01:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15332 for ; Thu, 12 Feb 2004 16:01:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNxc-0003ip-00 for entmib@ietf.org; Thu, 12 Feb 2004 16:01:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNwe-0003bc-00 for entmib@ietf.org; Thu, 12 Feb 2004 16:00:24 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ArNvj-0003Ny-00 for entmib@ietf.org; Thu, 12 Feb 2004 15:59:27 -0500 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 i1CKww728991 for ; Thu, 12 Feb 2004 15:58:58 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH79F9>; Thu, 12 Feb 2004 15:58:58 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A67BA@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is sema ntically wrong Date: Thu, 12 Feb 2004 15:58:56 -0500 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 Well, if we are to pick from the three, I think "unavailable" aligns best with resolving this issue. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Thursday, February 12, 2004 3:51 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Re: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is semantically wrong HI, For me, the term "notReportable" is worse than "notSupported". The terms "notSupported", "unknown" and "unavailable" are used in MIB modules indicate an appropriate value cannot be obtained by the access or instrumentation code. Mods: section 3.1, pp 3 section 3.4 TC AdminState TC OperState TC UsageState TC AlarmStatus TC StandbyStatus Object entStateAdmin Object entStateOper Object entStateUsage Object entStateAlarm Object entStateStandby At 01:53 PM 2/11/2004 -0500, Sharon Chisholm wrote: >Hi > >That last bit should read > >""A value >of 'notReportable' means that this resource is unable to report [this] >state." > >Sharon > >-----Original Message----- >From: Chisholm, Sharon [CAR:0S00:EXCH] >Sent: Wednesday, February 11, 2004 1:51 PM >To: 'entmib@ietf.org' >Subject: FW: [psg.com #307] AutoReply: 'notSupported' is semantically wrong > > >The following is the proposed resolution to entstate-307. The issue >will be considered closed pending the proposed edit being done. > >Replace the enumeration 'notSupported' with 'notReportable' in each of >the TCs and any references within the text. > >For each of the (TC, object definition) pairs, move the following sort >of text from the object definition to the textual convention: > >"A value >of 'notApplicable' means that this resource is unable to report [this] >state." > >Sharon > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 2:50 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #307] AutoReply: 'notSupported' is semantically wrong > > > >----------------------------------------------------------------------- >-- >Keith McCloghrie [kzm@cisco.com] > >" >> 'notSupported' is semantically wrong, because a compliant >implementation >> obviously supports the MIB, but it can return 'notSupported' for >> every object in the MIB. Presumably, the intended semantics is that >> the agent would return the right value if only it knew the right >value; >> i.e., 'unknown' is the desired semantics. Also, why is each >definition >> of 'notSupported' defined in an object's DESCRIPTION, not in the >TC's >> DESCRIPTION ?" /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu Feb 12 16:02:31 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 QAA15402 for ; Thu, 12 Feb 2004 16:02:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNyE-0005JP-Ml for entmib-archive@odin.ietf.org; Thu, 12 Feb 2004 16:02:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CL22eL020397 for entmib-archive@odin.ietf.org; Thu, 12 Feb 2004 16:02:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNyE-0005Il-7V; Thu, 12 Feb 2004 16:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNxf-0005Hv-In for entmib@optimus.ietf.org; Thu, 12 Feb 2004 16:01:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15332 for ; Thu, 12 Feb 2004 16:01:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNxc-0003ip-00 for entmib@ietf.org; Thu, 12 Feb 2004 16:01:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNwe-0003bc-00 for entmib@ietf.org; Thu, 12 Feb 2004 16:00:24 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ArNvj-0003Ny-00 for entmib@ietf.org; Thu, 12 Feb 2004 15:59:27 -0500 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 i1CKww728991 for ; Thu, 12 Feb 2004 15:58:58 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH79F9>; Thu, 12 Feb 2004 15:58:58 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A67BA@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is sema ntically wrong Date: Thu, 12 Feb 2004 15:58:56 -0500 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 Well, if we are to pick from the three, I think "unavailable" aligns best with resolving this issue. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Thursday, February 12, 2004 3:51 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Re: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is semantically wrong HI, For me, the term "notReportable" is worse than "notSupported". The terms "notSupported", "unknown" and "unavailable" are used in MIB modules indicate an appropriate value cannot be obtained by the access or instrumentation code. Mods: section 3.1, pp 3 section 3.4 TC AdminState TC OperState TC UsageState TC AlarmStatus TC StandbyStatus Object entStateAdmin Object entStateOper Object entStateUsage Object entStateAlarm Object entStateStandby At 01:53 PM 2/11/2004 -0500, Sharon Chisholm wrote: >Hi > >That last bit should read > >""A value >of 'notReportable' means that this resource is unable to report [this] >state." > >Sharon > >-----Original Message----- >From: Chisholm, Sharon [CAR:0S00:EXCH] >Sent: Wednesday, February 11, 2004 1:51 PM >To: 'entmib@ietf.org' >Subject: FW: [psg.com #307] AutoReply: 'notSupported' is semantically wrong > > >The following is the proposed resolution to entstate-307. The issue >will be considered closed pending the proposed edit being done. > >Replace the enumeration 'notSupported' with 'notReportable' in each of >the TCs and any references within the text. > >For each of the (TC, object definition) pairs, move the following sort >of text from the object definition to the textual convention: > >"A value >of 'notApplicable' means that this resource is unable to report [this] >state." > >Sharon > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 2:50 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #307] AutoReply: 'notSupported' is semantically wrong > > > >----------------------------------------------------------------------- >-- >Keith McCloghrie [kzm@cisco.com] > >" >> 'notSupported' is semantically wrong, because a compliant >implementation >> obviously supports the MIB, but it can return 'notSupported' for >> every object in the MIB. Presumably, the intended semantics is that >> the agent would return the right value if only it knew the right >value; >> i.e., 'unknown' is the desired semantics. Also, why is each >definition >> of 'notSupported' defined in an object's DESCRIPTION, not in the >TC's >> DESCRIPTION ?" /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Thu Feb 12 16:53:29 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 QAA18214 for ; Thu, 12 Feb 2004 16:53:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOlZ-0002BB-2B; Thu, 12 Feb 2004 16:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOl2-00029p-Q5 for entmib@optimus.ietf.org; Thu, 12 Feb 2004 16:52:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18188 for ; Thu, 12 Feb 2004 16:52:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArOky-00015D-00 for entmib@ietf.org; Thu, 12 Feb 2004 16:52:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArOk1-00010L-00 for entmib@ietf.org; Thu, 12 Feb 2004 16:51:26 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArOjE-0000w3-00 for entmib@ietf.org; Thu, 12 Feb 2004 16:50:36 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1CLoV326007; Thu, 12 Feb 2004 13:50:31 -0800 Message-Id: <5.2.0.9.2.20040212125300.01f879c0@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Feb 2004 13:50:02 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Subject: Re: [Entmib] FW: [psg.com #308] AutoReply: Shutting Down Admin State In-Reply-To: <3549C09B853DD5119B540002A52CDD340A243A61@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 also find several problems with the current definition of the value "shuttingDown" for AdminState. First, the definition of usageState was radically changed in the current draft of the document. From the DESCRIPTION clause of object entStateUsage (with comments in "<...>"): " Note that in the context of a physical entity, this object refers to an entity's ability to service more physical entities in a containment hierarchy. A value of 'idle' means this entity is able to contain other entities but that no other entity is currently contained within this entity, as would have been demonstrated by a value of entPhysicalContainedIn that referenced this entity. A value of 'active' means that at least one entity is contained within this entity and therefore has a value of entPhysicalContainedIn that references this entity, but that it could handle more. A value of 'busy' means that the entity is unable to handle any additional entities being contained in it, as demonstrated by having a value of entPhysicalContainedIn that refers to this entity. Some entities will exhibit only a subset of the usage state values. Entities that are unable to ever service any entities within a containment hierarchy will always have a usage state of 'busy'. Some entities will only ever be able to support one entity within its containment hierarchy and will therefore only exhibit values of 'idle' and 'busy'." Given the above, I don't know how to apply the value of "shuttingDown". But first, let's look at the values. Secondly, the X.731 document models the admin characteristic as with a 3 state diagram. The states are "unlocked", "shutting down", and "locked". The "shutting down" state is meant to represent a graceful shutdown of an "object". The event "shutdown" is a state transition from "unlocked" to "shutting down". Another transition occurs from state "shutting down" to "lock" when event "the last user quits" occurs. Now, if I were to model this in SNMP's SMI, I would have an "action/state" object with values: locked - a state and action unlocked - a state and action shutDown - an action (a write only value) (on a SET with no error, a read would return either value "locked" or "shuttingDown") shuttingDown - a state (a read only value) However, given the change of definition of the meaning of usage state, I'm a little confused as to how to "update" the TC (and object type) definitions. In general, I'm not sure that there is a need for a "graceful" and "force" administrative shutdown action values. If "graceful" shutdown is added, then I suggest that the value of "shuttingDown" be return until the value of "operState" is no longer "enabled". This removes the confusing "user" terminology. (See section 3.1.13 of RFC 2863) Thirdly, object IF-MIB::ifAdminStatus has a value of "testing". I don't know it maps to values for AdminState. This was not covered in the document. Finally, neither the IF MIB document nor X.731 describe the relationship between the admin values and admin (and oper) values of "contained" objects. And thus, this document does not cover this topic. It can be one of: 1) there is no relationship 2) the relationship is implementation defined 3) there is no relationship between admin values, but there is a weak relationship between oper values (more on this in message about #309 (oper state values)) At 01:59 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-308. The issue will be >considered closed with no changes made to the document. > >The following explanations were provided and no questions were raised. > >" >1. Is shutting down really more an operational state? > >The state refers more to whether your administrative model allows >systems to be shut down gracefully or not. The idea being that if it >does, you would still have the options to bring it down less >gracefully. We have allowed in the description of the object for >systems that don't support this value for the state. > >2. Would 'noNewUsage' be a better term. > >Well, except that the idea is that once all the existing 'users' are >gone, the system will shut down. The term 'noNewUsage' does not really >reflect that." > >Sharon > > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 2:55 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #308] AutoReply: Shutting Down Admin State > > >------------------------------------------------------------------------- >Keith McCloghrie [kzm@cisco.com] > >" > >the term 'shuttingDown' suggests that the action of shutting down is >> in progress, which of course is an operational condition, not an >admin >> state. A term more reflective of what the AdminState DESCRIPTION >appears >> to define would be 'noNewUsage'. In any case, this concept >of 'usage' >> is almost always a higher-level usage (e.g., a new ATM connection >on an >> ATM interface, a new Unix login on a cpu module, etc.) and thus >don't >> belong at the physical layer (i.e., don't apply to >> entPhysicalIndex). >" Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Thu Feb 12 17:15:30 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 RAA19334 for ; Thu, 12 Feb 2004 17:15:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArP6s-00045s-JC; Thu, 12 Feb 2004 17:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArP6N-0003ut-OM for entmib@optimus.ietf.org; Thu, 12 Feb 2004 17:14:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19297 for ; Thu, 12 Feb 2004 17:14:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArP6J-0003Gn-00 for entmib@ietf.org; Thu, 12 Feb 2004 17:14:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArP5Q-0003CA-00 for entmib@ietf.org; Thu, 12 Feb 2004 17:13:33 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArP4s-00037E-00 for entmib@ietf.org; Thu, 12 Feb 2004 17:12:58 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1CMCs332011; Thu, 12 Feb 2004 14:12:55 -0800 Message-Id: <5.2.0.9.2.20040212135324.01f84a50@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Feb 2004 14:12:49 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Subject: Re: [Entmib] FW: [psg.com #309] AutoReply: Operational State Names and Concepts In-Reply-To: <3549C09B853DD5119B540002A52CDD340A243A9E@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, First, implementing this object to match the semantics of X.731 will be difficult (if not impossible) if the hardware was not designed this way. And for some hardware (such as a power supplys) it may not be economically feasible to implement. (On a power supply, it may "disabled" by disconnecting the input power. If so, you cannot determine if it is working (that is, delivering output power within it's rated range) unless you supply input power. You could fake the oper state value by saving the last value of oper state when admin state was "unlocked" and returning it while the admin state is "locked".) Because of this issue, I believe that a new value needs to be added, such as "disabledDue2Admin". Also, the other values for object IF-MIB::ifOperStatus should be added. These values are: testing(3), -- in some test mode unknown(4), -- status can not be determined -- for some reason. dormant(5), notPresent(6), -- some component is missing lowerLayerDown(7) -- down due to state of -- lower-layer interface(s) But "lowerLayerDown" which be renamed to "containedNotEnabled". Secondly, I would name the terms "up" and "down" instead of "enabled" and "disabled", since enabled/disabled seem to be admin status and not operational state! Thirdly, the relationship between values of contained entities needs to be defined. (Object IF-MIB::ifOperStatus supports this.) At 02:17 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-309. The issue will be >considered closed pending the proposed edit being done. > >Add the following text to entStateOper > >"Note that some implementations may not be able to accurately report >entStateOper while the entStateAdmin object has a value other than >'unlocked'. In these cases, this object MUST have a value of >'notReportable'." > >Sharon > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 2:57 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #309] AutoReply: Operational State Names and Concepts > > >------------------------------------------------------------------------- >Keith McCloghrie [kzm@cisco.com] > >"'enabled' and 'disabled' to me imply that an admin state, i.e., if >> I saw an operState of 'disabled', or a entStateOperDisabled >notification, >> I'd look for the knob by which I could issue the enable command to >enable >> it again. > >> for most things, I believe you have to turn them on to see if they >work; >> if they don't work, you can turn them off again, and label >them "inoperable", >> but what that means is that they were inoperable the last time they >were >> turned on, and it doesn't necessarily mean they are still >inoperable, e.g., >> if something was inoperable the last time it was turned on and has >just >> been repaired, but not yet turned on again, is it still >inoperable ?? >> That is, neither 'disabled' nor 'inoperable' is the right term for >> operState. > >" Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu Feb 12 17:15:30 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 RAA19337 for ; Thu, 12 Feb 2004 17:15:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArP6t-00046K-0Z for entmib-archive@odin.ietf.org; Thu, 12 Feb 2004 17:15:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CMF2oQ015752 for entmib-archive@odin.ietf.org; Thu, 12 Feb 2004 17:15:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArP6s-00045s-JC; Thu, 12 Feb 2004 17:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArP6N-0003ut-OM for entmib@optimus.ietf.org; Thu, 12 Feb 2004 17:14:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19297 for ; Thu, 12 Feb 2004 17:14:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArP6J-0003Gn-00 for entmib@ietf.org; Thu, 12 Feb 2004 17:14:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArP5Q-0003CA-00 for entmib@ietf.org; Thu, 12 Feb 2004 17:13:33 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArP4s-00037E-00 for entmib@ietf.org; Thu, 12 Feb 2004 17:12:58 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1CMCs332011; Thu, 12 Feb 2004 14:12:55 -0800 Message-Id: <5.2.0.9.2.20040212135324.01f84a50@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Feb 2004 14:12:49 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Subject: Re: [Entmib] FW: [psg.com #309] AutoReply: Operational State Names and Concepts In-Reply-To: <3549C09B853DD5119B540002A52CDD340A243A9E@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, First, implementing this object to match the semantics of X.731 will be difficult (if not impossible) if the hardware was not designed this way. And for some hardware (such as a power supplys) it may not be economically feasible to implement. (On a power supply, it may "disabled" by disconnecting the input power. If so, you cannot determine if it is working (that is, delivering output power within it's rated range) unless you supply input power. You could fake the oper state value by saving the last value of oper state when admin state was "unlocked" and returning it while the admin state is "locked".) Because of this issue, I believe that a new value needs to be added, such as "disabledDue2Admin". Also, the other values for object IF-MIB::ifOperStatus should be added. These values are: testing(3), -- in some test mode unknown(4), -- status can not be determined -- for some reason. dormant(5), notPresent(6), -- some component is missing lowerLayerDown(7) -- down due to state of -- lower-layer interface(s) But "lowerLayerDown" which be renamed to "containedNotEnabled". Secondly, I would name the terms "up" and "down" instead of "enabled" and "disabled", since enabled/disabled seem to be admin status and not operational state! Thirdly, the relationship between values of contained entities needs to be defined. (Object IF-MIB::ifOperStatus supports this.) At 02:17 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-309. The issue will be >considered closed pending the proposed edit being done. > >Add the following text to entStateOper > >"Note that some implementations may not be able to accurately report >entStateOper while the entStateAdmin object has a value other than >'unlocked'. In these cases, this object MUST have a value of >'notReportable'." > >Sharon > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 2:57 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #309] AutoReply: Operational State Names and Concepts > > >------------------------------------------------------------------------- >Keith McCloghrie [kzm@cisco.com] > >"'enabled' and 'disabled' to me imply that an admin state, i.e., if >> I saw an operState of 'disabled', or a entStateOperDisabled >notification, >> I'd look for the knob by which I could issue the enable command to >enable >> it again. > >> for most things, I believe you have to turn them on to see if they >work; >> if they don't work, you can turn them off again, and label >them "inoperable", >> but what that means is that they were inoperable the last time they >were >> turned on, and it doesn't necessarily mean they are still >inoperable, e.g., >> if something was inoperable the last time it was turned on and has >just >> been repaired, but not yet turned on again, is it still >inoperable ?? >> That is, neither 'disabled' nor 'inoperable' is the right term for >> operState. > >" Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu Feb 12 17:43:25 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 QAA18218 for ; Thu, 12 Feb 2004 16:53:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOlZ-0002Bl-NK for entmib-archive@odin.ietf.org; Thu, 12 Feb 2004 16:53:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CLr1Qu008406 for entmib-archive@odin.ietf.org; Thu, 12 Feb 2004 16:53:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOlZ-0002BB-2B; Thu, 12 Feb 2004 16:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOl2-00029p-Q5 for entmib@optimus.ietf.org; Thu, 12 Feb 2004 16:52:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18188 for ; Thu, 12 Feb 2004 16:52:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArOky-00015D-00 for entmib@ietf.org; Thu, 12 Feb 2004 16:52:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArOk1-00010L-00 for entmib@ietf.org; Thu, 12 Feb 2004 16:51:26 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArOjE-0000w3-00 for entmib@ietf.org; Thu, 12 Feb 2004 16:50:36 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1CLoV326007; Thu, 12 Feb 2004 13:50:31 -0800 Message-Id: <5.2.0.9.2.20040212125300.01f879c0@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Feb 2004 13:50:02 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Subject: Re: [Entmib] FW: [psg.com #308] AutoReply: Shutting Down Admin State In-Reply-To: <3549C09B853DD5119B540002A52CDD340A243A61@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 also find several problems with the current definition of the value "shuttingDown" for AdminState. First, the definition of usageState was radically changed in the current draft of the document. From the DESCRIPTION clause of object entStateUsage (with comments in "<...>"): " Note that in the context of a physical entity, this object refers to an entity's ability to service more physical entities in a containment hierarchy. A value of 'idle' means this entity is able to contain other entities but that no other entity is currently contained within this entity, as would have been demonstrated by a value of entPhysicalContainedIn that referenced this entity. A value of 'active' means that at least one entity is contained within this entity and therefore has a value of entPhysicalContainedIn that references this entity, but that it could handle more. A value of 'busy' means that the entity is unable to handle any additional entities being contained in it, as demonstrated by having a value of entPhysicalContainedIn that refers to this entity. Some entities will exhibit only a subset of the usage state values. Entities that are unable to ever service any entities within a containment hierarchy will always have a usage state of 'busy'. Some entities will only ever be able to support one entity within its containment hierarchy and will therefore only exhibit values of 'idle' and 'busy'." Given the above, I don't know how to apply the value of "shuttingDown". But first, let's look at the values. Secondly, the X.731 document models the admin characteristic as with a 3 state diagram. The states are "unlocked", "shutting down", and "locked". The "shutting down" state is meant to represent a graceful shutdown of an "object". The event "shutdown" is a state transition from "unlocked" to "shutting down". Another transition occurs from state "shutting down" to "lock" when event "the last user quits" occurs. Now, if I were to model this in SNMP's SMI, I would have an "action/state" object with values: locked - a state and action unlocked - a state and action shutDown - an action (a write only value) (on a SET with no error, a read would return either value "locked" or "shuttingDown") shuttingDown - a state (a read only value) However, given the change of definition of the meaning of usage state, I'm a little confused as to how to "update" the TC (and object type) definitions. In general, I'm not sure that there is a need for a "graceful" and "force" administrative shutdown action values. If "graceful" shutdown is added, then I suggest that the value of "shuttingDown" be return until the value of "operState" is no longer "enabled". This removes the confusing "user" terminology. (See section 3.1.13 of RFC 2863) Thirdly, object IF-MIB::ifAdminStatus has a value of "testing". I don't know it maps to values for AdminState. This was not covered in the document. Finally, neither the IF MIB document nor X.731 describe the relationship between the admin values and admin (and oper) values of "contained" objects. And thus, this document does not cover this topic. It can be one of: 1) there is no relationship 2) the relationship is implementation defined 3) there is no relationship between admin values, but there is a weak relationship between oper values (more on this in message about #309 (oper state values)) At 01:59 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-308. The issue will be >considered closed with no changes made to the document. > >The following explanations were provided and no questions were raised. > >" >1. Is shutting down really more an operational state? > >The state refers more to whether your administrative model allows >systems to be shut down gracefully or not. The idea being that if it >does, you would still have the options to bring it down less >gracefully. We have allowed in the description of the object for >systems that don't support this value for the state. > >2. Would 'noNewUsage' be a better term. > >Well, except that the idea is that once all the existing 'users' are >gone, the system will shut down. The term 'noNewUsage' does not really >reflect that." > >Sharon > > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 2:55 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #308] AutoReply: Shutting Down Admin State > > >------------------------------------------------------------------------- >Keith McCloghrie [kzm@cisco.com] > >" > >the term 'shuttingDown' suggests that the action of shutting down is >> in progress, which of course is an operational condition, not an >admin >> state. A term more reflective of what the AdminState DESCRIPTION >appears >> to define would be 'noNewUsage'. In any case, this concept >of 'usage' >> is almost always a higher-level usage (e.g., a new ATM connection >on an >> ATM interface, a new Unix login on a cpu module, etc.) and thus >don't >> belong at the physical layer (i.e., don't apply to >> entPhysicalIndex). >" Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 00:53:26 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 AAA10019 for ; Fri, 13 Feb 2004 00:53:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWG5-0002CT-5l; Fri, 13 Feb 2004 00:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWFq-0002CF-Ls for entmib@optimus.ietf.org; Fri, 13 Feb 2004 00:52:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10015 for ; Fri, 13 Feb 2004 00:52:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArWFk-0001cZ-00 for entmib@ietf.org; Fri, 13 Feb 2004 00:52:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArWEv-0001Yf-00 for entmib@ietf.org; Fri, 13 Feb 2004 00:51:50 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArWEP-0001Tl-00 for entmib@ietf.org; Fri, 13 Feb 2004 00:51:17 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D5p8325663; Thu, 12 Feb 2004 21:51:08 -0800 Message-Id: <5.2.0.9.2.20040212173353.01f989f8@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Feb 2004 21:50:30 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Subject: Re: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues In-Reply-To: <3549C09B853DD5119B540002A52CDD340A243B00@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, The Alarm Status (not state) brings up the unsettled definition of what is "an alarm" and what is "clearing an alarm". The definition of an alarm MUST be specified for the TC and object to be useful. Or another term must be used (and, of course, that term must be well defined). I suggest that the term "alarm" be replaced by "fault". And the following be used for the TC and object definitions: FaultStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The fault status, which is a bit string. When all the bits are zero, then no faults are present. The bit 'unavailable(0)' indicates that the fault status is unknown. When set, all bits other than 'underRepair(1)' must be zero. The 'underRepair(1)' indicates that the an item is under repair. The following bits are one when one or more faults of the perceived severity exist. The value is zero for a bit when there is no existing fault of the perceived severity. The bits and faults are: 'critical(2)' 'major(3)' 'minor(4)' 'warning(5)' 'indeterminate(6)' (the perceived severity cannot be determined) The entity may continue to operate while a fault condition exists." SYNTAX BITS { unavailable(0), underRepair(1), critical(2), major(3), minor(4), -- The following are not defined in X.733 warning(6), indeterminate(7) } entStateFault OBJECT-TYPE SYNTAX FaultStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The fault status for this entity. It does not include the faults raised on entities within its containment hierarchy. These are entities that specify this entity as the value for object entPhysicalContainedIn directly and indirectly." ::= { entStateEntry 5 } At 02:44 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-310. The issue will be >considered closed pending the proposed edit being done. > >In the description of AlarmStatus replace > >" When the > value of under repair is set, the resource is currently > being repaired." > >With > >" When the > value of under repair is set, the resource is currently > being repaired, which depending on the implementation, > may make the other values in this bit string unreliable." > > >And replace > >" > When the value of 'alarmOutstanding' is set, one or more > alarms is active against the resource. The fault may or may > not be disabling. " > >With > >" > When the value of 'alarmOutstanding' is set, one or more > alarms is active against the resource. The fault may or may > not be disabling. This bit provides a high-level summary that > can be used to determine whether or not to examine the rest of > the values." > > >An explanation on the difference between raw and computed state, as defined >in section 2.1 was previously provided in relation to the severity of alarms >issue. No change appears to be necessary on that particular issue. > >Sharon > > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 2:58 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #310] AutoReply: Alarm State Issues > > > >------------------------------------------------------------------------- >Keith McCloghrie [kzm@cisco.com] > >"> 'underRepair' is an operState, not an AlarmState. >> >> from what perspective are the alarms classified as >critical/major/minor/etc. >> e.g., does a particular fault have the same alarm status >in 'coldStandby' >> as it does in 'hotStandby' or in 'providingService' ?? (hint: the >answer >> is no!!). >" > > > >Juergen Schoenwaelder [j.schoenwaelder@iu-bremen.de] > >"6) AlarmStatus TC: I do not really understand the alarmOutStanding >bit. It seems like this is set whenever one of critical, major, >minor, warning and indeterminate is set. But if this is true, I >think the bit is not really terrible useful. > >Perhaps the bit has some other meaning. If so, please clarify." Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 00:53:27 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 AAA10022 for ; Fri, 13 Feb 2004 00:53:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWG5-0002Cq-J1 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 00:53:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D5r1we008468 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 00:53:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWG5-0002CT-5l; Fri, 13 Feb 2004 00:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWFq-0002CF-Ls for entmib@optimus.ietf.org; Fri, 13 Feb 2004 00:52:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10015 for ; Fri, 13 Feb 2004 00:52:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArWFk-0001cZ-00 for entmib@ietf.org; Fri, 13 Feb 2004 00:52:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArWEv-0001Yf-00 for entmib@ietf.org; Fri, 13 Feb 2004 00:51:50 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArWEP-0001Tl-00 for entmib@ietf.org; Fri, 13 Feb 2004 00:51:17 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D5p8325663; Thu, 12 Feb 2004 21:51:08 -0800 Message-Id: <5.2.0.9.2.20040212173353.01f989f8@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Feb 2004 21:50:30 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Subject: Re: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues In-Reply-To: <3549C09B853DD5119B540002A52CDD340A243B00@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, The Alarm Status (not state) brings up the unsettled definition of what is "an alarm" and what is "clearing an alarm". The definition of an alarm MUST be specified for the TC and object to be useful. Or another term must be used (and, of course, that term must be well defined). I suggest that the term "alarm" be replaced by "fault". And the following be used for the TC and object definitions: FaultStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The fault status, which is a bit string. When all the bits are zero, then no faults are present. The bit 'unavailable(0)' indicates that the fault status is unknown. When set, all bits other than 'underRepair(1)' must be zero. The 'underRepair(1)' indicates that the an item is under repair. The following bits are one when one or more faults of the perceived severity exist. The value is zero for a bit when there is no existing fault of the perceived severity. The bits and faults are: 'critical(2)' 'major(3)' 'minor(4)' 'warning(5)' 'indeterminate(6)' (the perceived severity cannot be determined) The entity may continue to operate while a fault condition exists." SYNTAX BITS { unavailable(0), underRepair(1), critical(2), major(3), minor(4), -- The following are not defined in X.733 warning(6), indeterminate(7) } entStateFault OBJECT-TYPE SYNTAX FaultStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The fault status for this entity. It does not include the faults raised on entities within its containment hierarchy. These are entities that specify this entity as the value for object entPhysicalContainedIn directly and indirectly." ::= { entStateEntry 5 } At 02:44 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-310. The issue will be >considered closed pending the proposed edit being done. > >In the description of AlarmStatus replace > >" When the > value of under repair is set, the resource is currently > being repaired." > >With > >" When the > value of under repair is set, the resource is currently > being repaired, which depending on the implementation, > may make the other values in this bit string unreliable." > > >And replace > >" > When the value of 'alarmOutstanding' is set, one or more > alarms is active against the resource. The fault may or may > not be disabling. " > >With > >" > When the value of 'alarmOutstanding' is set, one or more > alarms is active against the resource. The fault may or may > not be disabling. This bit provides a high-level summary that > can be used to determine whether or not to examine the rest of > the values." > > >An explanation on the difference between raw and computed state, as defined >in section 2.1 was previously provided in relation to the severity of alarms >issue. No change appears to be necessary on that particular issue. > >Sharon > > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 2:58 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #310] AutoReply: Alarm State Issues > > > >------------------------------------------------------------------------- >Keith McCloghrie [kzm@cisco.com] > >"> 'underRepair' is an operState, not an AlarmState. >> >> from what perspective are the alarms classified as >critical/major/minor/etc. >> e.g., does a particular fault have the same alarm status >in 'coldStandby' >> as it does in 'hotStandby' or in 'providingService' ?? (hint: the >answer >> is no!!). >" > > > >Juergen Schoenwaelder [j.schoenwaelder@iu-bremen.de] > >"6) AlarmStatus TC: I do not really understand the alarmOutStanding >bit. It seems like this is set whenever one of critical, major, >minor, warning and indeterminate is set. But if this is true, I >think the bit is not really terrible useful. > >Perhaps the bit has some other meaning. If so, please clarify." Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 02:02:30 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 CAA14530 for ; Fri, 13 Feb 2004 02:02:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXKu-0007ac-IK for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 02:02:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D72426029152 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 02:02:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXKs-0007Zd-6k; Fri, 13 Feb 2004 02:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXKh-0007WH-9z for entmib@optimus.ietf.org; Fri, 13 Feb 2004 02:01:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13724 for ; Fri, 13 Feb 2004 02:01:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXKa-0007MV-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:01:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArXJm-0007I4-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:00:55 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXJD-0007Bz-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:00:19 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D70E307178; Thu, 12 Feb 2004 23:00:14 -0800 Message-Id: <5.2.0.9.2.20040212222405.01faae60@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Feb 2004 22:47:50 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Subject: RE: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? In-Reply-To: <3549C09B853DD5119B540002A52CDD340A243CB6@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, On this object, the description needs a little more detail. Maybe it's obvious, but the description should be clear that the value is updated whenever the value of any of the objects entStateAdmin, entStateOper, entStateUsage, entStateAlarm, or entStateStandby change in the row. Also, the description needs to describe the value after hot insert or hot removal. At 04:36 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-311. The issue >will be considered closed pending the proposed edit being done. > >Replace > >'entStateLastChanged OBJECT-TYPE >SYNTAX DateAndTime >MAX-ACCESS read-only >STATUS current >DESCRIPTION > "The value of this object is the date and > time when state/status of the entity > last changed, or zero."' > >With > >'entStateLastChanged OBJECT-TYPE >SYNTAX DateAndTime >MAX-ACCESS read-only >STATUS current >DESCRIPTION > "The value of this object is the date and > time when state/status of the entity > last changed. If there has been no change since > the last re-initialization of the local system, > this object contains the date and time of > local system initialization."' > >Sharon > > > >-----Original Message----- >From: Subrahmanya Hegde [mailto:subrah@cisco.com] >Sent: Wednesday, February 11, 2004 4:34 PM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Cc: entmib@ietf.org >Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? > > >Sounds great > >Subra > > >Sharon Chisholm wrote: > > >Hi > > > >The term "during" by its nature implies a span of time, rather than single > >value. If we replaced "that" with "local system" would that work for you? > > > >Sharon > > > >-----Original Message----- > >From: Subrahmanya Hegde [mailto:subrah@cisco.com ] > > >Sent: Wednesday, February 11, 2004 3:53 PM > >To: Chisholm, Sharon [CAR:0S00:EXCH] > >Cc: entmib@ietf.org > >Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? > > > > > >'entStateLastChanged OBJECT-TYPE > > SYNTAX DateAndTime > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The value of this object is the date and > > time when state/status of the entity > > last changed. If there has been no change since > > the last re-initialization of the local system, > > > > this object contains the date and time of > > that initialization."' > > > > > >may be good to rephrase it as : > > > > contains the date and time during initialization > > > >'that' does not seem to fit well > > > >Subra > > > > > > > > > > > >Sharon Chisholm wrote: > > > > > >The following is the proposed resolution to entstate-311. The issue > >will be considered closed pending the proposed edit being done. > > > >Replace > > > >'entStateLastChanged OBJECT-TYPE > > SYNTAX DateAndTime > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The value of this object is the date and > > time when state/status of the entity > > last changed, or zero."' > > > >With > > > >'entStateLastChanged OBJECT-TYPE > > SYNTAX DateAndTime > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The value of this object is the date and > > time when state/status of the entity > > last changed. If there has been no change since > > the last re-initialization of the local system, > > this object contains the date and time of > > that initialization."' > > > >Sharon > > > >-----Original Message----- > >From: entity-state [mailto:rt+entity-state@rt.psg.com > ] > >Sent: Tuesday, January 13, 2004 3:00 AM > >To: Chisholm, Sharon [CAR:0S00:EXCH] > >Subject: [psg.com #311] AutoReply: DateAndTimeOrZero ? > > > > > > > >----------------------------------------------------------------------- > >-- > >Keith McCloghrie [kzm@cisco.com ] > > > >should the MIB define DateAndTimeOrZero ? What does zero mean ? /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 02:02:30 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 CAA14525 for ; Fri, 13 Feb 2004 02:02:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXKs-0007Zd-6k; Fri, 13 Feb 2004 02:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXKh-0007WH-9z for entmib@optimus.ietf.org; Fri, 13 Feb 2004 02:01:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13724 for ; Fri, 13 Feb 2004 02:01:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXKa-0007MV-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:01:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArXJm-0007I4-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:00:55 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXJD-0007Bz-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:00:19 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D70E307178; Thu, 12 Feb 2004 23:00:14 -0800 Message-Id: <5.2.0.9.2.20040212222405.01faae60@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Feb 2004 22:47:50 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Subject: RE: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? In-Reply-To: <3549C09B853DD5119B540002A52CDD340A243CB6@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, On this object, the description needs a little more detail. Maybe it's obvious, but the description should be clear that the value is updated whenever the value of any of the objects entStateAdmin, entStateOper, entStateUsage, entStateAlarm, or entStateStandby change in the row. Also, the description needs to describe the value after hot insert or hot removal. At 04:36 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-311. The issue >will be considered closed pending the proposed edit being done. > >Replace > >'entStateLastChanged OBJECT-TYPE >SYNTAX DateAndTime >MAX-ACCESS read-only >STATUS current >DESCRIPTION > "The value of this object is the date and > time when state/status of the entity > last changed, or zero."' > >With > >'entStateLastChanged OBJECT-TYPE >SYNTAX DateAndTime >MAX-ACCESS read-only >STATUS current >DESCRIPTION > "The value of this object is the date and > time when state/status of the entity > last changed. If there has been no change since > the last re-initialization of the local system, > this object contains the date and time of > local system initialization."' > >Sharon > > > >-----Original Message----- >From: Subrahmanya Hegde [mailto:subrah@cisco.com] >Sent: Wednesday, February 11, 2004 4:34 PM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Cc: entmib@ietf.org >Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? > > >Sounds great > >Subra > > >Sharon Chisholm wrote: > > >Hi > > > >The term "during" by its nature implies a span of time, rather than single > >value. If we replaced "that" with "local system" would that work for you? > > > >Sharon > > > >-----Original Message----- > >From: Subrahmanya Hegde [mailto:subrah@cisco.com ] > > >Sent: Wednesday, February 11, 2004 3:53 PM > >To: Chisholm, Sharon [CAR:0S00:EXCH] > >Cc: entmib@ietf.org > >Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? > > > > > >'entStateLastChanged OBJECT-TYPE > > SYNTAX DateAndTime > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The value of this object is the date and > > time when state/status of the entity > > last changed. If there has been no change since > > the last re-initialization of the local system, > > > > this object contains the date and time of > > that initialization."' > > > > > >may be good to rephrase it as : > > > > contains the date and time during initialization > > > >'that' does not seem to fit well > > > >Subra > > > > > > > > > > > >Sharon Chisholm wrote: > > > > > >The following is the proposed resolution to entstate-311. The issue > >will be considered closed pending the proposed edit being done. > > > >Replace > > > >'entStateLastChanged OBJECT-TYPE > > SYNTAX DateAndTime > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The value of this object is the date and > > time when state/status of the entity > > last changed, or zero."' > > > >With > > > >'entStateLastChanged OBJECT-TYPE > > SYNTAX DateAndTime > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The value of this object is the date and > > time when state/status of the entity > > last changed. If there has been no change since > > the last re-initialization of the local system, > > this object contains the date and time of > > that initialization."' > > > >Sharon > > > >-----Original Message----- > >From: entity-state [mailto:rt+entity-state@rt.psg.com > ] > >Sent: Tuesday, January 13, 2004 3:00 AM > >To: Chisholm, Sharon [CAR:0S00:EXCH] > >Subject: [psg.com #311] AutoReply: DateAndTimeOrZero ? > > > > > > > >----------------------------------------------------------------------- > >-- > >Keith McCloghrie [kzm@cisco.com ] > > > >should the MIB define DateAndTimeOrZero ? What does zero mean ? /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 02:08:29 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 CAA21427 for ; Fri, 13 Feb 2004 02:08:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXQf-0001XC-T7; Fri, 13 Feb 2004 02:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXQS-0001RH-HX for entmib@optimus.ietf.org; Fri, 13 Feb 2004 02:07:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20488 for ; Fri, 13 Feb 2004 02:07:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXQL-000030-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:07:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArXPK-0007lJ-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:06:39 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXOM-0007eu-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:05:38 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D75b308347; Thu, 12 Feb 2004 23:05:37 -0800 Message-Id: <5.2.0.9.2.20040212230124.01f905b0@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Feb 2004 23:05:30 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Subject: Re: [Entmib] FW: [psg.com #322] AutoReply: Textual Convention Names (Prefix) In-Reply-To: <3549C09B853DD5119B540002A52CDD340A243C0A@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, If the TCs are truly "generic", then they shouldn't be identified with a specific MIB module. However, I'm not at all convinced that they are generic. In fact, I really don't believe that thye are appropriate for both physical and logical entities. So, I support changing the descriptors(what is called "names" below) for the TCs. At 03:43 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-322. The issue will be >considered closed with no changes made to the document. > >There were various bits of discussion on the list on when it is appropriate >to use a MIB specific prefix on a textual convention and when it does not. >As the intention on these textual conventions is for general use it would >seem that a prefix is not appropriate. The proposal is to keep the names as >is. > >Sharon >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Friday, February 06, 2004 2:33 PM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #322] AutoReply: Textual Convention Names (Prefix) > > > >------------------------------------------------------------------------- >Andy Bierman [abierman@cisco.com] > >the TCs should be named with a prefix. E.g., >OperState -> EntityOperState. This applies to >all the TCs in the draft. /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 02:08:31 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 CAA21481 for ; Fri, 13 Feb 2004 02:08:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXQi-0001ZH-V2 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 02:08:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D784t0005963 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 02:08:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXQf-0001XC-T7; Fri, 13 Feb 2004 02:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXQS-0001RH-HX for entmib@optimus.ietf.org; Fri, 13 Feb 2004 02:07:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20488 for ; Fri, 13 Feb 2004 02:07:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXQL-000030-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:07:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArXPK-0007lJ-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:06:39 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXOM-0007eu-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:05:38 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D75b308347; Thu, 12 Feb 2004 23:05:37 -0800 Message-Id: <5.2.0.9.2.20040212230124.01f905b0@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Feb 2004 23:05:30 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Subject: Re: [Entmib] FW: [psg.com #322] AutoReply: Textual Convention Names (Prefix) In-Reply-To: <3549C09B853DD5119B540002A52CDD340A243C0A@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, If the TCs are truly "generic", then they shouldn't be identified with a specific MIB module. However, I'm not at all convinced that they are generic. In fact, I really don't believe that thye are appropriate for both physical and logical entities. So, I support changing the descriptors(what is called "names" below) for the TCs. At 03:43 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-322. The issue will be >considered closed with no changes made to the document. > >There were various bits of discussion on the list on when it is appropriate >to use a MIB specific prefix on a textual convention and when it does not. >As the intention on these textual conventions is for general use it would >seem that a prefix is not appropriate. The proposal is to keep the names as >is. > >Sharon >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Friday, February 06, 2004 2:33 PM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #322] AutoReply: Textual Convention Names (Prefix) > > > >------------------------------------------------------------------------- >Andy Bierman [abierman@cisco.com] > >the TCs should be named with a prefix. E.g., >OperState -> EntityOperState. This applies to >all the TCs in the draft. /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 02:20:33 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 CAA25266 for ; Fri, 13 Feb 2004 02:20:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXcI-0005n6-0M; Fri, 13 Feb 2004 02:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXc5-0005jA-47 for entmib@optimus.ietf.org; Fri, 13 Feb 2004 02:19:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25203 for ; Fri, 13 Feb 2004 02:19:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXbx-0001HO-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:19:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArXb1-0001DN-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:18:44 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXaJ-000197-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:17:59 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D7Hu310766; Thu, 12 Feb 2004 23:17:56 -0800 Message-Id: <5.2.0.9.2.20040212231230.01fafc50@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Feb 2004 23:17:49 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Subject: Re: [Entmib] FW: [psg.com #328] AutoReply: Containment Hierach and entPhysical Containedin In-Reply-To: <3549C09B853DD5119B540002A52CDD340A244352@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, This is a real problem. I suggest that a paragraph be added to the document that describes "containment hierarchy" (and provides an example). And then all of the uses in the DESCRIPTION clauses just say "containment hierarchy" and drop all mention of object entPhysicalContainedIn." If this approach is not desired, then use a phrase like "....on entities within its containment hierarchy. These are entities that specify this entity as the value for object entPhysicalContainedIn directly and indirectly." At 01:44 PM 2/12/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-328. The issue >will be considered closed pending the proposed edit being done. > >In the various object definitions replace phrases like > >"as defined by a value of > entPhysicalContainedIn that references this entity" > >With one like > >"as defined by the entPhysicalContainedIn object." > >Sharon > >-----Original Message----- >From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] >Sent: Wednesday, February 11, 2004 12:56 PM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #328] AutoReply: Containment Hierach and >entPhysicalContainedin > > >------------------------------------------------------------------------- >Juergen Schoenwaelder [j.schoenwaelder@iu-bremen.de] > >"5) Several description clauses refer to "entities within its > containment hierarchy" followed by a sentence which limits this to > the entities "having a value of entPhysicalContainedIn that refers > to this entity". This somehow excludes transitive containment. Is > this by intention or accident? I mean, if I have C contained in B > contained in A, then A still provides indirect service to C." Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 02:20: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 CAA25277 for ; Fri, 13 Feb 2004 02:20:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXcO-0005oj-4a for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 02:20:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D7K7EW022282 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 02:20:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXcI-0005n6-0M; Fri, 13 Feb 2004 02:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXc5-0005jA-47 for entmib@optimus.ietf.org; Fri, 13 Feb 2004 02:19:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25203 for ; Fri, 13 Feb 2004 02:19:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXbx-0001HO-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:19:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArXb1-0001DN-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:18:44 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXaJ-000197-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:17:59 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D7Hu310766; Thu, 12 Feb 2004 23:17:56 -0800 Message-Id: <5.2.0.9.2.20040212231230.01fafc50@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Feb 2004 23:17:49 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Subject: Re: [Entmib] FW: [psg.com #328] AutoReply: Containment Hierach and entPhysical Containedin In-Reply-To: <3549C09B853DD5119B540002A52CDD340A244352@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, This is a real problem. I suggest that a paragraph be added to the document that describes "containment hierarchy" (and provides an example). And then all of the uses in the DESCRIPTION clauses just say "containment hierarchy" and drop all mention of object entPhysicalContainedIn." If this approach is not desired, then use a phrase like "....on entities within its containment hierarchy. These are entities that specify this entity as the value for object entPhysicalContainedIn directly and indirectly." At 01:44 PM 2/12/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-328. The issue >will be considered closed pending the proposed edit being done. > >In the various object definitions replace phrases like > >"as defined by a value of > entPhysicalContainedIn that references this entity" > >With one like > >"as defined by the entPhysicalContainedIn object." > >Sharon > >-----Original Message----- >From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] >Sent: Wednesday, February 11, 2004 12:56 PM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #328] AutoReply: Containment Hierach and >entPhysicalContainedin > > >------------------------------------------------------------------------- >Juergen Schoenwaelder [j.schoenwaelder@iu-bremen.de] > >"5) Several description clauses refer to "entities within its > containment hierarchy" followed by a sentence which limits this to > the entities "having a value of entPhysicalContainedIn that refers > to this entity". This somehow excludes transitive containment. Is > this by intention or accident? I mean, if I have C contained in B > contained in A, then A still provides indirect service to C." Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 02:23: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 CAA25527 for ; Fri, 13 Feb 2004 02:23:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXfB-0006Tu-TR; Fri, 13 Feb 2004 02:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXez-0006RO-GN for entmib@optimus.ietf.org; Fri, 13 Feb 2004 02:22:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25464 for ; Fri, 13 Feb 2004 02:22:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXes-0001U7-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:22:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArXdv-0001Pz-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:21:44 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXdZ-0001M1-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:21:21 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D7LG311373; Thu, 12 Feb 2004 23:21:16 -0800 Message-Id: <5.2.0.9.2.20040212231949.01f905b0@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Feb 2004 23:21:10 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Subject: Re: [Entmib] FW: [psg.com #329] AutoReply: Usage State Scope In-Reply-To: <3549C09B853DD5119B540002A52CDD340A24445E@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 don't see a use for the usage state. As currently defined, it's value is easily computed. At 02:46 PM 2/12/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-329. The issue will be >considered closed with no changes made to the document. > >Well, this is the one object that most directly relates to its child >component. Our definition only talks about child components in terms of >physical entities. So, the ability of a port to 'contain' an logical >interface isn't reported by this status. I might be convinced to change the >definition but I think this concepts starts getting harder to describe and >understand when we start mixing physical containment and logical to physical >mappings. > >I worry that talking about leafs and containers might confuse people. The >current definition speaks in terms of whether something else can be >contained in it. This is more consistent with the rest of the discussion. > >Sharon >-----Original Message----- >From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] >Sent: Wednesday, February 11, 2004 12:59 PM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #329] AutoReply: Usage State Scope > > > >------------------------------------------------------------------------- >Juergen Schoenwaelder [j.schoenwaelder@iu-bremen.de] > >"I was surprised to read the entStateUsage description which says > the UsageState is strictly bound to the containment relationship > between entities. > > In general, the containment hierarchy is made up of containers and > leafs. The entStateUsage description basically says that the > UsageState is only interesting for containers since leafs are > always busy. I found this interesting since the other objects do > not make this distinction and some of them seem to particularly > useful for leafs (e.g. interfaces). Perhaps it makes sense to > define for each entState* column how it applies to containers and > how it applies to leafs. For example, what does it mean to > lock/unlock a container? (I believe entStateAdmin is more defined > for leafs rather than containers.)" Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 02:23: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 CAA25528 for ; Fri, 13 Feb 2004 02:23:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXfC-0006UT-Du for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 02:23:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D7N29f024925 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 02:23:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXfB-0006Tu-TR; Fri, 13 Feb 2004 02:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXez-0006RO-GN for entmib@optimus.ietf.org; Fri, 13 Feb 2004 02:22:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25464 for ; Fri, 13 Feb 2004 02:22:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXes-0001U7-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:22:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArXdv-0001Pz-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:21:44 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXdZ-0001M1-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:21:21 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D7LG311373; Thu, 12 Feb 2004 23:21:16 -0800 Message-Id: <5.2.0.9.2.20040212231949.01f905b0@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Feb 2004 23:21:10 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Subject: Re: [Entmib] FW: [psg.com #329] AutoReply: Usage State Scope In-Reply-To: <3549C09B853DD5119B540002A52CDD340A24445E@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 don't see a use for the usage state. As currently defined, it's value is easily computed. At 02:46 PM 2/12/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-329. The issue will be >considered closed with no changes made to the document. > >Well, this is the one object that most directly relates to its child >component. Our definition only talks about child components in terms of >physical entities. So, the ability of a port to 'contain' an logical >interface isn't reported by this status. I might be convinced to change the >definition but I think this concepts starts getting harder to describe and >understand when we start mixing physical containment and logical to physical >mappings. > >I worry that talking about leafs and containers might confuse people. The >current definition speaks in terms of whether something else can be >contained in it. This is more consistent with the rest of the discussion. > >Sharon >-----Original Message----- >From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] >Sent: Wednesday, February 11, 2004 12:59 PM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #329] AutoReply: Usage State Scope > > > >------------------------------------------------------------------------- >Juergen Schoenwaelder [j.schoenwaelder@iu-bremen.de] > >"I was surprised to read the entStateUsage description which says > the UsageState is strictly bound to the containment relationship > between entities. > > In general, the containment hierarchy is made up of containers and > leafs. The entStateUsage description basically says that the > UsageState is only interesting for containers since leafs are > always busy. I found this interesting since the other objects do > not make this distinction and some of them seem to particularly > useful for leafs (e.g. interfaces). Perhaps it makes sense to > define for each entState* column how it applies to containers and > how it applies to leafs. For example, what does it mean to > lock/unlock a container? (I believe entStateAdmin is more defined > for leafs rather than containers.)" Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 02:50:27 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 CAA26993 for ; Fri, 13 Feb 2004 02:50:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArY5J-0001dI-3L; Fri, 13 Feb 2004 02:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArY57-0001cI-4k for entmib@optimus.ietf.org; Fri, 13 Feb 2004 02:49:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26974 for ; Fri, 13 Feb 2004 02:49:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArY4z-0003ng-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:49:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArY41-0003jg-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:48:42 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArY3S-0003g7-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:48:06 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D7m4315429; Thu, 12 Feb 2004 23:48:04 -0800 Message-Id: <5.2.0.9.2.20040212232346.01faae60@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Feb 2004 23:41:02 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" In-Reply-To: <3549C09B853DD5119B540002A52CDD340A24445E@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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] Standby 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, "Standby status" items should be renamed to "standby state" to be consistent with the other naming of other items in the MIB module. (Items are "state" when value is an enumerated int, and "status" when the value is a bit string.) There is one important value missing from the enums for standby. It is the one that means that the service output is combined with other entities. This is commonly found with power supplies where the output is "summed". Section 2.2 is incorrect. It implies that by reading the value of entStandbyStatus for all entities, then entities can be classified as redundant (or protected). This is not true. Say that there are two entities that are identical and provide a "protected" service. At any time, only one is providing service, and the other is standing by protecting the other. A "protection switch" causes the roles to change (that is the one providing service will switch to standing by, and the one standing by will start to providing service). In general, this MIB module does not provide enough information to determine 1) which entities are protected, 2) the relationship between the entities that are protected and the entities providing protection. Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 02:50: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 CAA27010 for ; Fri, 13 Feb 2004 02:50:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArY5K-0001dX-95; Fri, 13 Feb 2004 02:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArY57-0001cN-Nb for entmib@optimus.ietf.org; Fri, 13 Feb 2004 02:49:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26977 for ; Fri, 13 Feb 2004 02:49:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArY50-0003nl-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:49:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArY42-0003jo-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:48:42 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArY3S-0003g8-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:48:06 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D7m5315434; Thu, 12 Feb 2004 23:48:05 -0800 Message-Id: <5.2.0.9.2.20040212234153.01f7f570@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Feb 2004 23:47:55 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" In-Reply-To: <3549C09B853DD5119B540002A52CDD340A24445E@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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] Relationship with Alarm MIB 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, The entity state MIB document should have proceeded the Alarm MIB document. Thus, section 3.2 is backwards. Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 02:50:30 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 CAA27028 for ; Fri, 13 Feb 2004 02:50:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArY5L-0001es-UZ for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 02:50:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D7o3WI006297 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 02:50:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArY5J-0001dI-3L; Fri, 13 Feb 2004 02:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArY57-0001cI-4k for entmib@optimus.ietf.org; Fri, 13 Feb 2004 02:49:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26974 for ; Fri, 13 Feb 2004 02:49:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArY4z-0003ng-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:49:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArY41-0003jg-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:48:42 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArY3S-0003g7-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:48:06 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D7m4315429; Thu, 12 Feb 2004 23:48:04 -0800 Message-Id: <5.2.0.9.2.20040212232346.01faae60@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Feb 2004 23:41:02 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" In-Reply-To: <3549C09B853DD5119B540002A52CDD340A24445E@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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] Standby 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, "Standby status" items should be renamed to "standby state" to be consistent with the other naming of other items in the MIB module. (Items are "state" when value is an enumerated int, and "status" when the value is a bit string.) There is one important value missing from the enums for standby. It is the one that means that the service output is combined with other entities. This is commonly found with power supplies where the output is "summed". Section 2.2 is incorrect. It implies that by reading the value of entStandbyStatus for all entities, then entities can be classified as redundant (or protected). This is not true. Say that there are two entities that are identical and provide a "protected" service. At any time, only one is providing service, and the other is standing by protecting the other. A "protection switch" causes the roles to change (that is the one providing service will switch to standing by, and the one standing by will start to providing service). In general, this MIB module does not provide enough information to determine 1) which entities are protected, 2) the relationship between the entities that are protected and the entities providing protection. Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 02:50:30 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 CAA27027 for ; Fri, 13 Feb 2004 02:50:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArY5L-0001et-VD for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 02:50:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D7o3j5006319 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 02:50:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArY5K-0001dX-95; Fri, 13 Feb 2004 02:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArY57-0001cN-Nb for entmib@optimus.ietf.org; Fri, 13 Feb 2004 02:49:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26977 for ; Fri, 13 Feb 2004 02:49:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArY50-0003nl-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:49:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArY42-0003jo-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:48:42 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArY3S-0003g8-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:48:06 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D7m5315434; Thu, 12 Feb 2004 23:48:05 -0800 Message-Id: <5.2.0.9.2.20040212234153.01f7f570@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Feb 2004 23:47:55 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" In-Reply-To: <3549C09B853DD5119B540002A52CDD340A24445E@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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] Relationship with Alarm MIB 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, The entity state MIB document should have proceeded the Alarm MIB document. Thus, section 3.2 is backwards. Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 03:27: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 DAA28067 for ; Fri, 13 Feb 2004 03:27:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYf9-0004Vs-3L for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 03:27:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D8R27N017329 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 03:27:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYf8-0004VB-IL; Fri, 13 Feb 2004 03:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYex-0004UK-BE for entmib@optimus.ietf.org; Fri, 13 Feb 2004 03:26:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28021 for ; Fri, 13 Feb 2004 03:26:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYep-0006vH-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:26:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArYdv-0006qe-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:25:48 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYd5-0006lx-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:24:55 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D8Or321788; Fri, 13 Feb 2004 00:24:53 -0800 Message-Id: <5.2.0.9.2.20040213001626.01f9c4f0@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Feb 2004 00:22:33 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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] Ent state Notifications 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, So, if an interface goes from down to up, with both a linkUp and a entStateOperEnabled notification be generated? Note the term "trap" needs to be replaced with "notification" in the DESCRIPTION clause. Why no notifications when the value of entStateStandby changes from/to providingService. /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 03:27:27 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 DAA28059 for ; Fri, 13 Feb 2004 03:27:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYf8-0004V3-69; Fri, 13 Feb 2004 03:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYew-0004Tn-Mm for entmib@optimus.ietf.org; Fri, 13 Feb 2004 03:26:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28018 for ; Fri, 13 Feb 2004 03:26:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYeo-0006vC-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:26:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArYdt-0006qM-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:25:46 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYd4-0006lv-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:24:54 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D8Oq321785; Fri, 13 Feb 2004 00:24:52 -0800 Message-Id: <5.2.0.9.2.20040213000700.01faae60@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Feb 2004 00:11:15 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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] Index for table entStateTable 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, The SMI requires that the DESCRIPTION for the row of a table describe the index item is that item is not a column in the table. And the DESCRIPTION clause for entStateEntry does not provide the needed info. In general, why is there a "sparse relationship". When should state be provided and when should it not? /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 03:27:29 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 DAA28064 for ; Fri, 13 Feb 2004 03:27:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYf9-0004Vt-3m for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 03:27:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D8R2tQ017320 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 03:27:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYf8-0004V3-69; Fri, 13 Feb 2004 03:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYew-0004Tn-Mm for entmib@optimus.ietf.org; Fri, 13 Feb 2004 03:26:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28018 for ; Fri, 13 Feb 2004 03:26:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYeo-0006vC-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:26:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArYdt-0006qM-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:25:46 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYd4-0006lv-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:24:54 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D8Oq321785; Fri, 13 Feb 2004 00:24:52 -0800 Message-Id: <5.2.0.9.2.20040213000700.01faae60@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Feb 2004 00:11:15 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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] Index for table entStateTable 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, The SMI requires that the DESCRIPTION for the row of a table describe the index item is that item is not a column in the table. And the DESCRIPTION clause for entStateEntry does not provide the needed info. In general, why is there a "sparse relationship". When should state be provided and when should it not? /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 04:13:31 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 DAA28070 for ; Fri, 13 Feb 2004 03:27:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYf9-0004WU-MO; Fri, 13 Feb 2004 03:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYf1-0004Ug-Bj for entmib@optimus.ietf.org; Fri, 13 Feb 2004 03:26:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28035 for ; Fri, 13 Feb 2004 03:26:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYet-0006vs-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:26:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArYdy-0006rH-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:25:51 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYdM-0006mU-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:25:12 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D8PB321839; Fri, 13 Feb 2004 00:25:11 -0800 Message-Id: <5.2.0.9.2.20040213002255.01f81cd0@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Feb 2004 00:25:05 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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] Examples in entity State MIB document 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, The document seems to be missing a table that says how the values are applied to each class of entity. Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 04:13:32 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 DAA28076 for ; Fri, 13 Feb 2004 03:27:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYfA-0004Ws-3U for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 03:27:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D8R3jF017396 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 03:27:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYf9-0004WU-MO; Fri, 13 Feb 2004 03:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYf1-0004Ug-Bj for entmib@optimus.ietf.org; Fri, 13 Feb 2004 03:26:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28035 for ; Fri, 13 Feb 2004 03:26:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYet-0006vs-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:26:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArYdy-0006rH-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:25:51 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYdM-0006mU-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:25:12 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D8PB321839; Fri, 13 Feb 2004 00:25:11 -0800 Message-Id: <5.2.0.9.2.20040213002255.01f81cd0@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Feb 2004 00:25:05 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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] Examples in entity State MIB document 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, The document seems to be missing a table that says how the values are applied to each class of entity. Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 04:13:32 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 DAA28060 for ; Fri, 13 Feb 2004 03:27:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYf8-0004VB-IL; Fri, 13 Feb 2004 03:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYex-0004UK-BE for entmib@optimus.ietf.org; Fri, 13 Feb 2004 03:26:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28021 for ; Fri, 13 Feb 2004 03:26:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYep-0006vH-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:26:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArYdv-0006qe-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:25:48 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYd5-0006lx-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:24:55 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D8Or321788; Fri, 13 Feb 2004 00:24:53 -0800 Message-Id: <5.2.0.9.2.20040213001626.01f9c4f0@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Feb 2004 00:22:33 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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] Ent state Notifications 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, So, if an interface goes from down to up, with both a linkUp and a entStateOperEnabled notification be generated? Note the term "trap" needs to be replaced with "notification" in the DESCRIPTION clause. Why no notifications when the value of entStateStandby changes from/to providingService. /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 04:13:33 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 DAA28063 for ; Fri, 13 Feb 2004 03:27:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYf9-0004Vr-2d; Fri, 13 Feb 2004 03:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYez-0004US-Gd for entmib@optimus.ietf.org; Fri, 13 Feb 2004 03:26:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28029 for ; Fri, 13 Feb 2004 03:26:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYer-0006va-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:26:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArYdw-0006qo-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:25:48 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYd5-0006m5-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:24:55 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D8Op321779; Fri, 13 Feb 2004 00:24:52 -0800 Message-Id: <5.2.0.9.2.20040212234957.01f7f570@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Feb 2004 00:04:29 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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] More on Standby 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, Here is a replacement for TC StandbyStatus: StandbyState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION " Represents the possible values of standby state. The value 'notAvailable(1)' means that no information is available on the standby state for the entity. The value 'hotStandby(2)' means the entity is not providing service, and will be immediately able to start providing service for the entity being backed up without the need for initialization activity, and will contain the same information as the entity being backed up. The value 'coldStandy(3)' means the entity is not providing service, and will be able to start providing service for an entity (possibly one from a set) being backed up, and will require some initialization activity. The value 'providingService(4)' means the entity is providing service. The value 'providingSharedService(5)' means the entity is providing service that is summed with the service provided by other entities." REFERENCE "ITU Recommendation X.731, 'Information Technology - Open Systems Interconnection - System Management: State Management Function', 1992" SYNTAX INTEGER { notAvailable(1), hotStandby(2), coldStandby(3), providingService(4), providingSharedService(5) } And a replacement for entStateStandby: entStateStandby OBJECT-TYPE SYNTAX StandbyStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The standby state for this entity. A value of 'notAvailable' means that this entity is unable to determine standby state. Some entities will exhibit only a subset of the remaining standby state values. If this entity cannot operate in a standby role, then the value with always be 'providingService'." ::= { entStateEntry 6 } >Date: Thu, 12 Feb 2004 23:41:02 -0800 >To: "Sharon Chisholm" , entmib@ietf.org >From: "David T. Perkins" >Subject: Standby > >HI, > >"Standby status" items should be renamed to "standby state" to be >consistent with the other naming of other items in the MIB module. >(Items are "state" when value is an enumerated int, and "status" >when the value is a bit string.) > >There is one important value missing from the enums for standby. >It is the one that means that the service output is combined >with other entities. This is commonly found with power supplies >where the output is "summed". > >Section 2.2 is incorrect. It implies that by reading the value >of entStandbyStatus for all entities, then entities can be classified >as redundant (or protected). This is not true. Say that there >are two entities that are identical and provide a "protected" >service. At any time, only one is providing service, and the >other is standing by protecting the other. A "protection switch" >causes the roles to change (that is the one providing service >will switch to standing by, and the one standing by will start >to providing service). > >In general, this MIB module does not provide enough information >to determine 1) which entities are protected, 2) the relationship >between the entities that are protected and the entities providing >protection. > >Regards, >/david t. perkins /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 04:13:33 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 DAA28065 for ; Fri, 13 Feb 2004 03:27:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYf9-0004WJ-CC for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 03:27:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D8R3tC017359 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 03:27:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYf9-0004Vr-2d; Fri, 13 Feb 2004 03:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYez-0004US-Gd for entmib@optimus.ietf.org; Fri, 13 Feb 2004 03:26:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28029 for ; Fri, 13 Feb 2004 03:26:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYer-0006va-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:26:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArYdw-0006qo-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:25:48 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYd5-0006m5-00 for entmib@ietf.org; Fri, 13 Feb 2004 03:24:55 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D8Op321779; Fri, 13 Feb 2004 00:24:52 -0800 Message-Id: <5.2.0.9.2.20040212234957.01f7f570@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Feb 2004 00:04:29 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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] More on Standby 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, Here is a replacement for TC StandbyStatus: StandbyState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION " Represents the possible values of standby state. The value 'notAvailable(1)' means that no information is available on the standby state for the entity. The value 'hotStandby(2)' means the entity is not providing service, and will be immediately able to start providing service for the entity being backed up without the need for initialization activity, and will contain the same information as the entity being backed up. The value 'coldStandy(3)' means the entity is not providing service, and will be able to start providing service for an entity (possibly one from a set) being backed up, and will require some initialization activity. The value 'providingService(4)' means the entity is providing service. The value 'providingSharedService(5)' means the entity is providing service that is summed with the service provided by other entities." REFERENCE "ITU Recommendation X.731, 'Information Technology - Open Systems Interconnection - System Management: State Management Function', 1992" SYNTAX INTEGER { notAvailable(1), hotStandby(2), coldStandby(3), providingService(4), providingSharedService(5) } And a replacement for entStateStandby: entStateStandby OBJECT-TYPE SYNTAX StandbyStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The standby state for this entity. A value of 'notAvailable' means that this entity is unable to determine standby state. Some entities will exhibit only a subset of the remaining standby state values. If this entity cannot operate in a standby role, then the value with always be 'providingService'." ::= { entStateEntry 6 } >Date: Thu, 12 Feb 2004 23:41:02 -0800 >To: "Sharon Chisholm" , entmib@ietf.org >From: "David T. Perkins" >Subject: Standby > >HI, > >"Standby status" items should be renamed to "standby state" to be >consistent with the other naming of other items in the MIB module. >(Items are "state" when value is an enumerated int, and "status" >when the value is a bit string.) > >There is one important value missing from the enums for standby. >It is the one that means that the service output is combined >with other entities. This is commonly found with power supplies >where the output is "summed". > >Section 2.2 is incorrect. It implies that by reading the value >of entStandbyStatus for all entities, then entities can be classified >as redundant (or protected). This is not true. Say that there >are two entities that are identical and provide a "protected" >service. At any time, only one is providing service, and the >other is standing by protecting the other. A "protection switch" >causes the roles to change (that is the one providing service >will switch to standing by, and the one standing by will start >to providing service). > >In general, this MIB module does not provide enough information >to determine 1) which entities are protected, 2) the relationship >between the entities that are protected and the entities providing >protection. > >Regards, >/david t. perkins /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 09:51:30 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 JAA11405 for ; Fri, 13 Feb 2004 09:51:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Areej-0001st-V0; Fri, 13 Feb 2004 09:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aree2-0001oB-IH for entmib@optimus.ietf.org; Fri, 13 Feb 2004 09:50:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11377 for ; Fri, 13 Feb 2004 09:50:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aree0-0006VR-00 for entmib@ietf.org; Fri, 13 Feb 2004 09:50:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arecx-0006Pt-00 for entmib@ietf.org; Fri, 13 Feb 2004 09:49:12 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1Arecf-0006K8-00 for entmib@ietf.org; Fri, 13 Feb 2004 09:48:53 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1DEmLS13104 for ; Fri, 13 Feb 2004 09:48:21 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8HAA>; Fri, 13 Feb 2004 09:48:22 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A6BB1@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 13 Feb 2004 09:48:19 -0500 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 Subject: [Entmib] RE: Examples in entity State MIB document 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 The document used to have a table like this but it was decided that this made the MIB more difficult to understand and would cause it to be out of date each time a new class of entity was added. Plus, you can't really make sweeping statements that 'fans ever do this' or 'power supplies never do that'. It was decided that instead, we would ensure that the objects and textual conventions were well enough defined so that this could easily be determined by the implementer. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 3:25 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Examples in entity State MIB document HI, The document seems to be missing a table that says how the values are applied to each class of entity. Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 09:51:30 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 JAA11419 for ; Fri, 13 Feb 2004 09:51:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Areel-0001ti-DM for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 09:51:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DEp3wu007272 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 09:51:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Areej-0001st-V0; Fri, 13 Feb 2004 09:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aree2-0001oB-IH for entmib@optimus.ietf.org; Fri, 13 Feb 2004 09:50:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11377 for ; Fri, 13 Feb 2004 09:50:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aree0-0006VR-00 for entmib@ietf.org; Fri, 13 Feb 2004 09:50:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arecx-0006Pt-00 for entmib@ietf.org; Fri, 13 Feb 2004 09:49:12 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1Arecf-0006K8-00 for entmib@ietf.org; Fri, 13 Feb 2004 09:48:53 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1DEmLS13104 for ; Fri, 13 Feb 2004 09:48:21 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8HAA>; Fri, 13 Feb 2004 09:48:22 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A6BB1@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 13 Feb 2004 09:48:19 -0500 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 Subject: [Entmib] RE: Examples in entity State MIB document 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 The document used to have a table like this but it was decided that this made the MIB more difficult to understand and would cause it to be out of date each time a new class of entity was added. Plus, you can't really make sweeping statements that 'fans ever do this' or 'power supplies never do that'. It was decided that instead, we would ensure that the objects and textual conventions were well enough defined so that this could easily be determined by the implementer. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 3:25 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Examples in entity State MIB document HI, The document seems to be missing a table that says how the values are applied to each class of entity. Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 11:49:29 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 LAA19579 for ; Fri, 13 Feb 2004 11:49:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgUv-0003gh-Hc; Fri, 13 Feb 2004 11:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgTz-0003X4-KP for entmib@optimus.ietf.org; Fri, 13 Feb 2004 11:48:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19457 for ; Fri, 13 Feb 2004 11:48:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgTy-0002c0-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:48:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgT7-0002SM-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:47:09 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArgRV-0001xo-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:45:29 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 04B2E855B9; Fri, 13 Feb 2004 17:44:58 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.54]) by merkur.iu-bremen.de (Postfix) with ESMTP id 49ECB85570; Fri, 13 Feb 2004 17:44:57 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 377345ED11; Fri, 13 Feb 2004 14:33:44 +0100 (CET) Date: Fri, 13 Feb 2004 14:33:44 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #327] AutoReply: More Editorial Issues Message-ID: <20040213133344.GD5970@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , entmib@ietf.org References: <3549C09B853DD5119B540002A52CDD340A244318@zcard0ka.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3549C09B853DD5119B540002A52CDD340A244318@zcard0ka.ca.nortel.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,DATE_IN_PAST_03_06 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: , On Thu, Feb 12, 2004 at 01:31:23PM -0500, Sharon Chisholm wrote: > With > > "The administrative state for this entity. A value > of 'notSupported' means that this entity is unable > to report administrative state. This object can not > be manually set to 'notSupported'. For > entities that do not support administrative state, > changing the value of this object to something other > than 'notSupported' is not permitted. A value of > 'inconsistentValue' will be returned in either case." I still find the text confusing from a stylistic point of view. What about this: "The administrative state for this entity. A value of 'notSupported' means that this entity is unable to report administrative state. Setting this object to 'notSupported' will result in an 'inconsistentValue' error. For entities that do not support administrative state, all set operations will result in an 'inconsistentValue' error." /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 11:49:29 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 LAA19581 for ; Fri, 13 Feb 2004 11:49:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgUv-0003gy-OU; Fri, 13 Feb 2004 11:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgU0-0003Xa-C7 for entmib@optimus.ietf.org; Fri, 13 Feb 2004 11:48:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19463 for ; Fri, 13 Feb 2004 11:48:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgTz-0002c5-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:48:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgT8-0002SY-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:47:10 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArgRV-0001xp-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:45:29 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 084FC855BA; Fri, 13 Feb 2004 17:44:58 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.54]) by merkur.iu-bremen.de (Postfix) with ESMTP id 4AC2C8559C; Fri, 13 Feb 2004 17:44:57 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 4CA955ED10; Fri, 13 Feb 2004 14:23:17 +0100 (CET) Date: Fri, 13 Feb 2004 14:23:17 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #330] AutoReply: Notification Varbinds Message-ID: <20040213132317.GC5970@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , entmib@ietf.org References: <3549C09B853DD5119B540002A52CDD340A24448B@zcard0ka.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3549C09B853DD5119B540002A52CDD340A24448B@zcard0ka.ca.nortel.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,DATE_IN_PAST_03_06 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: , On Thu, Feb 12, 2004 at 02:57:58PM -0500, Sharon Chisholm wrote: > The alarm status tells you how many outstanding problems have been > reported against this entity. This is interesting from a fault > management perspective. Let me ask again: Why is the alarm status important in the entStateOperEnabled notification? Do you expect that entities transition in the enabled operational state while alarms are pending? Is that spelled out somewhere? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 11:49:29 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 LAA19586 for ; Fri, 13 Feb 2004 11:49:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgUw-0003hl-5E; Fri, 13 Feb 2004 11:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgU1-0003Xf-68 for entmib@optimus.ietf.org; Fri, 13 Feb 2004 11:48:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19475 for ; Fri, 13 Feb 2004 11:48:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgTz-0002cA-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:48:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgT8-0002Sc-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:47:11 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArgRV-0001xt-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:45:29 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 00252855B0; Fri, 13 Feb 2004 17:44:59 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.54]) by merkur.iu-bremen.de (Postfix) with ESMTP id 486708556E; Fri, 13 Feb 2004 17:44:58 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 5E1CA5ED12; Fri, 13 Feb 2004 14:35:18 +0100 (CET) Date: Fri, 13 Feb 2004 14:35:18 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #328] AutoReply: Containment Hierach and entPhysical Containedin Message-ID: <20040213133518.GE5970@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , entmib@ietf.org References: <3549C09B853DD5119B540002A52CDD340A244352@zcard0ka.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3549C09B853DD5119B540002A52CDD340A244352@zcard0ka.ca.nortel.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,DATE_IN_PAST_03_06 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: , On Thu, Feb 12, 2004 at 01:44:44PM -0500, Sharon Chisholm wrote: > The following is the proposed resolution to entstate-328. The issue > will be considered closed pending the proposed edit being done. > > In the various object definitions replace phrases like > > "as defined by a value of > entPhysicalContainedIn that references this entity" > > With one like > > "as defined by the entPhysicalContainedIn object." So this is not generally transitive? I like Dave Perkin's suggestion on this issue. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 11:49:30 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 LAA19593 for ; Fri, 13 Feb 2004 11:49:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgUv-0003hV-TD for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 11:49:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DGn1Qg014194 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 11:49:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgUv-0003gh-Hc; Fri, 13 Feb 2004 11:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgTz-0003X4-KP for entmib@optimus.ietf.org; Fri, 13 Feb 2004 11:48:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19457 for ; Fri, 13 Feb 2004 11:48:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgTy-0002c0-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:48:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgT7-0002SM-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:47:09 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArgRV-0001xo-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:45:29 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 04B2E855B9; Fri, 13 Feb 2004 17:44:58 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.54]) by merkur.iu-bremen.de (Postfix) with ESMTP id 49ECB85570; Fri, 13 Feb 2004 17:44:57 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 377345ED11; Fri, 13 Feb 2004 14:33:44 +0100 (CET) Date: Fri, 13 Feb 2004 14:33:44 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #327] AutoReply: More Editorial Issues Message-ID: <20040213133344.GD5970@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , entmib@ietf.org References: <3549C09B853DD5119B540002A52CDD340A244318@zcard0ka.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3549C09B853DD5119B540002A52CDD340A244318@zcard0ka.ca.nortel.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,DATE_IN_PAST_03_06 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: , On Thu, Feb 12, 2004 at 01:31:23PM -0500, Sharon Chisholm wrote: > With > > "The administrative state for this entity. A value > of 'notSupported' means that this entity is unable > to report administrative state. This object can not > be manually set to 'notSupported'. For > entities that do not support administrative state, > changing the value of this object to something other > than 'notSupported' is not permitted. A value of > 'inconsistentValue' will be returned in either case." I still find the text confusing from a stylistic point of view. What about this: "The administrative state for this entity. A value of 'notSupported' means that this entity is unable to report administrative state. Setting this object to 'notSupported' will result in an 'inconsistentValue' error. For entities that do not support administrative state, all set operations will result in an 'inconsistentValue' error." /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 11:49:30 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 LAA19589 for ; Fri, 13 Feb 2004 11:49:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgUw-0003hh-2O for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 11:49:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DGn11I014218 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 11:49:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgUv-0003gy-OU; Fri, 13 Feb 2004 11:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgU0-0003Xa-C7 for entmib@optimus.ietf.org; Fri, 13 Feb 2004 11:48:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19463 for ; Fri, 13 Feb 2004 11:48:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgTz-0002c5-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:48:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgT8-0002SY-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:47:10 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArgRV-0001xp-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:45:29 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 084FC855BA; Fri, 13 Feb 2004 17:44:58 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.54]) by merkur.iu-bremen.de (Postfix) with ESMTP id 4AC2C8559C; Fri, 13 Feb 2004 17:44:57 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 4CA955ED10; Fri, 13 Feb 2004 14:23:17 +0100 (CET) Date: Fri, 13 Feb 2004 14:23:17 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #330] AutoReply: Notification Varbinds Message-ID: <20040213132317.GC5970@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , entmib@ietf.org References: <3549C09B853DD5119B540002A52CDD340A24448B@zcard0ka.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3549C09B853DD5119B540002A52CDD340A24448B@zcard0ka.ca.nortel.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,DATE_IN_PAST_03_06 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: , On Thu, Feb 12, 2004 at 02:57:58PM -0500, Sharon Chisholm wrote: > The alarm status tells you how many outstanding problems have been > reported against this entity. This is interesting from a fault > management perspective. Let me ask again: Why is the alarm status important in the entStateOperEnabled notification? Do you expect that entities transition in the enabled operational state while alarms are pending? Is that spelled out somewhere? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 11:51:29 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 LAA19765 for ; Fri, 13 Feb 2004 11:51:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgWs-0004G6-GH for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 11:51:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DGp28P016358 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 11:51:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgWr-0004FW-TZ; Fri, 13 Feb 2004 11:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgW4-0004CK-93 for entmib@optimus.ietf.org; Fri, 13 Feb 2004 11:50:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19696 for ; Fri, 13 Feb 2004 11:50:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgW3-0002pD-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:50:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgVJ-0002jg-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:49:25 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArgUh-0002eE-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:48:47 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id E0029855C1; Fri, 13 Feb 2004 17:48:16 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.54]) by merkur.iu-bremen.de (Postfix) with ESMTP id 1E0AD8559C; Fri, 13 Feb 2004 17:48:15 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 619405ED13; Fri, 13 Feb 2004 14:48:03 +0100 (CET) Date: Fri, 13 Feb 2004 14:48:03 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #329] AutoReply: Usage State Scope Message-ID: <20040213134803.GF5970@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , entmib@ietf.org References: <3549C09B853DD5119B540002A52CDD340A24445E@zcard0ka.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3549C09B853DD5119B540002A52CDD340A24445E@zcard0ka.ca.nortel.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,DATE_IN_PAST_03_06 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: , On Thu, Feb 12, 2004 at 02:46:42PM -0500, Sharon Chisholm wrote: > > Well, this is the one object that most directly relates to its child > component. Our definition only talks about child components in terms of > physical entities. So, the ability of a port to 'contain' an logical > interface isn't reported by this status. I might be convinced to change the > definition but I think this concepts starts getting harder to describe and > understand when we start mixing physical containment and logical to physical > mappings. > > I worry that talking about leafs and containers might confuse people. The > current definition speaks in terms of whether something else can be > contained in it. This is more consistent with the rest of the discussion. I did not propose to use the terms leaf and container - I just tried to explain my issue and I obviously did not a good job. My point is that some of the objects and descriptions seem to apply to the function of a physical entity while others apply to strictly the containment feature. Lets take for example an entity of class "container" and an entity of class "port". I think the interpretation of UsageState or OperState is totally different for these two entities. For a container entity, UsageState active means there are still slots available where I can plug something in. For a port, the entStateUsage is according to the description busy, regardless of the port's functional usage state. So this usage state is purely oriented on the containment hierarchy. If I look at the entStateOper of a container and a port entity, then for the container the state enabled probably means that the container is active and able to host plugins. A port, from a pure containment point of view, it should probably be disabled since it can't host other components. However, from a functional point of view, the port state is probably coupled to the interface state realized by that port. In short: I think the interpretation of the states for the various entity classes needs to be clarified. (I think Dave also wrote something in that direction.) Without guidance from the spec, implementations will just not use the same model and fail to interoperate. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 12:19: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 MAA21134 for ; Fri, 13 Feb 2004 12:19:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Argxx-0006MN-FY; Fri, 13 Feb 2004 12:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Argx2-0006LJ-UM for entmib@optimus.ietf.org; Fri, 13 Feb 2004 12:18:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21080 for ; Fri, 13 Feb 2004 12:18:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Argx1-0005PX-00 for entmib@ietf.org; Fri, 13 Feb 2004 12:18:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Argw3-0005LI-00 for entmib@ietf.org; Fri, 13 Feb 2004 12:17:04 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArgvI-0005DO-00 for entmib@ietf.org; Fri, 13 Feb 2004 12:16:16 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1DHFjS21214 for ; Fri, 13 Feb 2004 12:15:45 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8L10>; Fri, 13 Feb 2004 12:15:45 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A6DC2@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 13 Feb 2004 12:15:43 -0500 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 Subject: [Entmib] RE: Relationship with Alarm MIB 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 In the absence of a time machine, I'm not sure what you are asking for. Are you suggesting that the section explain that there are other ways to get at the alarm information and that this method of starting with physical resource is just one example? Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 2:48 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Relationship with Alarm MIB HI, The entity state MIB document should have proceeded the Alarm MIB document. Thus, section 3.2 is backwards. Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 12:27: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 MAA21473 for ; Fri, 13 Feb 2004 12:27:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arh5h-00079Y-OI; Fri, 13 Feb 2004 12:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arh51-000769-Nt for entmib@optimus.ietf.org; Fri, 13 Feb 2004 12:26:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21428 for ; Fri, 13 Feb 2004 12:26:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arh50-0006A2-00 for entmib@ietf.org; Fri, 13 Feb 2004 12:26:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arh48-00064r-00 for entmib@ietf.org; Fri, 13 Feb 2004 12:25:24 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Arh3c-0005yk-00 for entmib@ietf.org; Fri, 13 Feb 2004 12:24:52 -0500 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 i1DHOLn28579 for ; Fri, 13 Feb 2004 12:24:21 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8LJF>; Fri, 13 Feb 2004 12:24:21 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A6DD2@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] RE: Examples in entity State MIB document Date: Fri, 13 Feb 2004 12:24:20 -0500 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 This is related to closed issue #79 Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Friday, February 13, 2004 9:48 AM To: entmib@ietf.org Subject: [Entmib] RE: Examples in entity State MIB document Hi The document used to have a table like this but it was decided that this made the MIB more difficult to understand and would cause it to be out of date each time a new class of entity was added. Plus, you can't really make sweeping statements that 'fans ever do this' or 'power supplies never do that'. It was decided that instead, we would ensure that the objects and textual conventions were well enough defined so that this could easily be determined by the implementer. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 3:25 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Examples in entity State MIB document HI, The document seems to be missing a table that says how the values are applied to each class of entity. Regards, /david t. perkins _______________________________________________ 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 Fri Feb 13 12:31:29 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 MAA21704 for ; Fri, 13 Feb 2004 12:31:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arh9a-0007OK-QE for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 12:31:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DHV24w028400 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 12:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arh9a-0007Nq-CR; Fri, 13 Feb 2004 12:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arh8q-0007JS-4H for entmib@optimus.ietf.org; Fri, 13 Feb 2004 12:30:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21635 for ; Fri, 13 Feb 2004 12:30:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arh8o-0006YB-00 for entmib@ietf.org; Fri, 13 Feb 2004 12:30:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arh7t-0006Sj-00 for entmib@ietf.org; Fri, 13 Feb 2004 12:29:17 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Arh7T-0006NA-00 for entmib@ietf.org; Fri, 13 Feb 2004 12:28:51 -0500 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 i1DHSKn29004 for ; Fri, 13 Feb 2004 12:28:20 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8LL1>; Fri, 13 Feb 2004 12:28:20 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A6DD8@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] Summary of Issues from Entity State MIB WG Last Call Date: Fri, 13 Feb 2004 12:28:17 -0500 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 I know people generally interpret the end of working group last call fairly loosely, so I've created new issues to track some of the more recently raised comments. 335 Notification Comments 334 Table, Index Descriptions 333 Relationship with Alarm MIB 332 More Standby State/Status Issues The goal is still to get the update out by Monday @ 9am, so we'll try to resolve the new comments and issues with previously proposed resolutions today. Thanks, Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, February 11, 2004 1:10 PM To: entmib@ietf.org Subject: [Entmib] Summary of Issues from Entity State MIB WG Last Call Hi For those of you not regularly visiting http://rt.psg.org (ietf, ietf), here is the current list of open issues on the Entity State MIB. Most of these have been discussed on the list already. I'll start posting proposed resolutions to these to the list with the goal of closing them by the end of the week so that I can make the ID deadline of Monday 9am. A big thanks to everyone who took the time to review the document. 311 DateAndTimeOrZero 325 OID Organization 327 More Editorial Issues 328 Containment Hierach and entPhysicalContainedin 329 Usage State Scope 330 Notification Varbinds 306 entStateTrap rename/oid to entStateNotifs 307 'notSupported' is semantically wrong 308 Shutting Down Admin State 309 Operational State Names and Concepts 310 Alarm State Issues 312 Locked Admin State 322 Textual Convention Names (Prefix) 326 Too many state objects 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 Fri Feb 13 12:38:35 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 LAA19600 for ; Fri, 13 Feb 2004 11:49:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgUw-0003iD-CR for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 11:49:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DGn2HX014251 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 11:49:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgUw-0003hl-5E; Fri, 13 Feb 2004 11:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgU1-0003Xf-68 for entmib@optimus.ietf.org; Fri, 13 Feb 2004 11:48:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19475 for ; Fri, 13 Feb 2004 11:48:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgTz-0002cA-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:48:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgT8-0002Sc-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:47:11 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArgRV-0001xt-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:45:29 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 00252855B0; Fri, 13 Feb 2004 17:44:59 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.54]) by merkur.iu-bremen.de (Postfix) with ESMTP id 486708556E; Fri, 13 Feb 2004 17:44:58 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 5E1CA5ED12; Fri, 13 Feb 2004 14:35:18 +0100 (CET) Date: Fri, 13 Feb 2004 14:35:18 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #328] AutoReply: Containment Hierach and entPhysical Containedin Message-ID: <20040213133518.GE5970@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , entmib@ietf.org References: <3549C09B853DD5119B540002A52CDD340A244352@zcard0ka.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3549C09B853DD5119B540002A52CDD340A244352@zcard0ka.ca.nortel.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,DATE_IN_PAST_03_06 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: , On Thu, Feb 12, 2004 at 01:44:44PM -0500, Sharon Chisholm wrote: > The following is the proposed resolution to entstate-328. The issue > will be considered closed pending the proposed edit being done. > > In the various object definitions replace phrases like > > "as defined by a value of > entPhysicalContainedIn that references this entity" > > With one like > > "as defined by the entPhysicalContainedIn object." So this is not generally transitive? I like Dave Perkin's suggestion on this issue. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 12:38:36 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 LAA19764 for ; Fri, 13 Feb 2004 11:51:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgWr-0004FW-TZ; Fri, 13 Feb 2004 11:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgW4-0004CK-93 for entmib@optimus.ietf.org; Fri, 13 Feb 2004 11:50:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19696 for ; Fri, 13 Feb 2004 11:50:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgW3-0002pD-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:50:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgVJ-0002jg-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:49:25 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArgUh-0002eE-00 for entmib@ietf.org; Fri, 13 Feb 2004 11:48:47 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id E0029855C1; Fri, 13 Feb 2004 17:48:16 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.54]) by merkur.iu-bremen.de (Postfix) with ESMTP id 1E0AD8559C; Fri, 13 Feb 2004 17:48:15 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 619405ED13; Fri, 13 Feb 2004 14:48:03 +0100 (CET) Date: Fri, 13 Feb 2004 14:48:03 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #329] AutoReply: Usage State Scope Message-ID: <20040213134803.GF5970@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , entmib@ietf.org References: <3549C09B853DD5119B540002A52CDD340A24445E@zcard0ka.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3549C09B853DD5119B540002A52CDD340A24445E@zcard0ka.ca.nortel.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,DATE_IN_PAST_03_06 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: , On Thu, Feb 12, 2004 at 02:46:42PM -0500, Sharon Chisholm wrote: > > Well, this is the one object that most directly relates to its child > component. Our definition only talks about child components in terms of > physical entities. So, the ability of a port to 'contain' an logical > interface isn't reported by this status. I might be convinced to change the > definition but I think this concepts starts getting harder to describe and > understand when we start mixing physical containment and logical to physical > mappings. > > I worry that talking about leafs and containers might confuse people. The > current definition speaks in terms of whether something else can be > contained in it. This is more consistent with the rest of the discussion. I did not propose to use the terms leaf and container - I just tried to explain my issue and I obviously did not a good job. My point is that some of the objects and descriptions seem to apply to the function of a physical entity while others apply to strictly the containment feature. Lets take for example an entity of class "container" and an entity of class "port". I think the interpretation of UsageState or OperState is totally different for these two entities. For a container entity, UsageState active means there are still slots available where I can plug something in. For a port, the entStateUsage is according to the description busy, regardless of the port's functional usage state. So this usage state is purely oriented on the containment hierarchy. If I look at the entStateOper of a container and a port entity, then for the container the state enabled probably means that the container is active and able to host plugins. A port, from a pure containment point of view, it should probably be disabled since it can't host other components. However, from a functional point of view, the port state is probably coupled to the interface state realized by that port. In short: I think the interpretation of the states for the various entity classes needs to be clarified. (I think Dave also wrote something in that direction.) Without guidance from the spec, implementations will just not use the same model and fail to interoperate. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 13:13:35 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 MAA21136 for ; Fri, 13 Feb 2004 12:19:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Argxy-0006Mk-0g for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 12:19:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DHJ1bf024464 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 12:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Argxx-0006MN-FY; Fri, 13 Feb 2004 12:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Argx2-0006LJ-UM for entmib@optimus.ietf.org; Fri, 13 Feb 2004 12:18:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21080 for ; Fri, 13 Feb 2004 12:18:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Argx1-0005PX-00 for entmib@ietf.org; Fri, 13 Feb 2004 12:18:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Argw3-0005LI-00 for entmib@ietf.org; Fri, 13 Feb 2004 12:17:04 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArgvI-0005DO-00 for entmib@ietf.org; Fri, 13 Feb 2004 12:16:16 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1DHFjS21214 for ; Fri, 13 Feb 2004 12:15:45 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8L10>; Fri, 13 Feb 2004 12:15:45 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A6DC2@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 13 Feb 2004 12:15:43 -0500 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 Subject: [Entmib] RE: Relationship with Alarm MIB 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 In the absence of a time machine, I'm not sure what you are asking for. Are you suggesting that the section explain that there are other ways to get at the alarm information and that this method of starting with physical resource is just one example? Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 2:48 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Relationship with Alarm MIB HI, The entity state MIB document should have proceeded the Alarm MIB document. Thus, section 3.2 is backwards. Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 13:13:36 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 MAA21474 for ; Fri, 13 Feb 2004 12:27:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arh5h-0007A1-V4 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 12:27:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DHR1Ew027508 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 12:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arh5h-00079Y-OI; Fri, 13 Feb 2004 12:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arh51-000769-Nt for entmib@optimus.ietf.org; Fri, 13 Feb 2004 12:26:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21428 for ; Fri, 13 Feb 2004 12:26:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arh50-0006A2-00 for entmib@ietf.org; Fri, 13 Feb 2004 12:26:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arh48-00064r-00 for entmib@ietf.org; Fri, 13 Feb 2004 12:25:24 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Arh3c-0005yk-00 for entmib@ietf.org; Fri, 13 Feb 2004 12:24:52 -0500 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 i1DHOLn28579 for ; Fri, 13 Feb 2004 12:24:21 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8LJF>; Fri, 13 Feb 2004 12:24:21 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A6DD2@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] RE: Examples in entity State MIB document Date: Fri, 13 Feb 2004 12:24:20 -0500 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 This is related to closed issue #79 Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Friday, February 13, 2004 9:48 AM To: entmib@ietf.org Subject: [Entmib] RE: Examples in entity State MIB document Hi The document used to have a table like this but it was decided that this made the MIB more difficult to understand and would cause it to be out of date each time a new class of entity was added. Plus, you can't really make sweeping statements that 'fans ever do this' or 'power supplies never do that'. It was decided that instead, we would ensure that the objects and textual conventions were well enough defined so that this could easily be determined by the implementer. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 3:25 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Examples in entity State MIB document HI, The document seems to be missing a table that says how the values are applied to each class of entity. Regards, /david t. perkins _______________________________________________ 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 Fri Feb 13 13:18:35 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 MAA21702 for ; Fri, 13 Feb 2004 12:31:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arh9a-0007Nq-CR; Fri, 13 Feb 2004 12:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arh8q-0007JS-4H for entmib@optimus.ietf.org; Fri, 13 Feb 2004 12:30:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21635 for ; Fri, 13 Feb 2004 12:30:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arh8o-0006YB-00 for entmib@ietf.org; Fri, 13 Feb 2004 12:30:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arh7t-0006Sj-00 for entmib@ietf.org; Fri, 13 Feb 2004 12:29:17 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Arh7T-0006NA-00 for entmib@ietf.org; Fri, 13 Feb 2004 12:28:51 -0500 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 i1DHSKn29004 for ; Fri, 13 Feb 2004 12:28:20 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8LL1>; Fri, 13 Feb 2004 12:28:20 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A6DD8@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] Summary of Issues from Entity State MIB WG Last Call Date: Fri, 13 Feb 2004 12:28:17 -0500 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 I know people generally interpret the end of working group last call fairly loosely, so I've created new issues to track some of the more recently raised comments. 335 Notification Comments 334 Table, Index Descriptions 333 Relationship with Alarm MIB 332 More Standby State/Status Issues The goal is still to get the update out by Monday @ 9am, so we'll try to resolve the new comments and issues with previously proposed resolutions today. Thanks, Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, February 11, 2004 1:10 PM To: entmib@ietf.org Subject: [Entmib] Summary of Issues from Entity State MIB WG Last Call Hi For those of you not regularly visiting http://rt.psg.org (ietf, ietf), here is the current list of open issues on the Entity State MIB. Most of these have been discussed on the list already. I'll start posting proposed resolutions to these to the list with the goal of closing them by the end of the week so that I can make the ID deadline of Monday 9am. A big thanks to everyone who took the time to review the document. 311 DateAndTimeOrZero 325 OID Organization 327 More Editorial Issues 328 Containment Hierach and entPhysicalContainedin 329 Usage State Scope 330 Notification Varbinds 306 entStateTrap rename/oid to entStateNotifs 307 'notSupported' is semantically wrong 308 Shutting Down Admin State 309 Operational State Names and Concepts 310 Alarm State Issues 312 Locked Admin State 322 Textual Convention Names (Prefix) 326 Too many state objects 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 Fri Feb 13 14:45:30 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 OAA28559 for ; Fri, 13 Feb 2004 14:45:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjFF-00034I-TA; Fri, 13 Feb 2004 14:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjER-00033I-4n for entmib@optimus.ietf.org; Fri, 13 Feb 2004 14:44:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28534 for ; Fri, 13 Feb 2004 14:44:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArjEO-0002sg-00 for entmib@ietf.org; Fri, 13 Feb 2004 14:44:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArjDS-0002pC-00 for entmib@ietf.org; Fri, 13 Feb 2004 14:43:10 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArjCe-0002hD-00 for entmib@ietf.org; Fri, 13 Feb 2004 14:42:20 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1DJfhS16599 for ; Fri, 13 Feb 2004 14:41:44 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH83KV>; Fri, 13 Feb 2004 14:41:44 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A6F96@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 13 Feb 2004 14:41:42 -0500 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 Subject: [Entmib] FW: [psg.com #335] AutoReply: Notification Comments 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: , The following is the proposed resolution to entstate-335. The issue will be considered closed pending the proposed edit being done. In the description for entStateOperEnabled replace "An entStateOperEnabled trap signifies that the SNMP" With "An entStateOperEnabled Notification signifies that the SNMP" And in the description of entStateOperDisabled replace "An entStateOperDisabled trap signifies that the SNMP" With "An entStateOperDisabled Notification signifies that the SNMP" With respect to the other comments, the only interface that we associate with the physical port is the lowest layer, so it would not be for every linkUp/linkDown that we would end up with two sets of notifications. My feeling is that it is a little late to be discussing additional notifications to add. Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Friday, February 13, 2004 12:20 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #335] AutoReply: Notification Comments ------------------------------------------------------------------------- David T. Perkins [dperkins@dsperkins.com] "So, if an interface goes from down to up, with both a linkUp and a entStateOperEnabled notification be generated? Note the term "trap" needs to be replaced with "notification" in the DESCRIPTION clause. Why no notifications when the value of entStateStandby changes from/to providingService." _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 15:00:32 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 PAA29316 for ; Fri, 13 Feb 2004 15:00:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjTn-0005Ik-SU; Fri, 13 Feb 2004 15:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjTB-0005Bq-6i for entmib@optimus.ietf.org; Fri, 13 Feb 2004 14:59:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29236 for ; Fri, 13 Feb 2004 14:59:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArjT8-0004KC-00 for entmib@ietf.org; Fri, 13 Feb 2004 14:59:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArjSJ-0004EQ-00 for entmib@ietf.org; Fri, 13 Feb 2004 14:58:32 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArjRg-00044s-00 for entmib@ietf.org; Fri, 13 Feb 2004 14:57:52 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1DJvLS18319 for ; Fri, 13 Feb 2004 14:57:21 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH83W4>; Fri, 13 Feb 2004 14:57:21 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A6FD4@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 13 Feb 2004 14:57:17 -0500 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 Subject: [Entmib] RE: Index for table entStateTable 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 With respect to the first point, can you provide me with the specific reference? I've just done a quick look through RFC2578 and the MIB Review Guidelines document and could not find what you were referring to. With respect to the second point, it is a sparse relationship because that was working group consensus. I didn't agree with the logic, so it's difficult to recall. If I remember correctly, the logic was that not all equipment would be able to report all the status information, so people wanted a sparse augment. I'll propose adding some text to this affect. Of course people could just as easily just use the 'notApplicable' (or whatever we decided to call it) value for the enumeration instead. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 3:11 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Index for table entStateTable HI, The SMI requires that the DESCRIPTION for the row of a table describe the index item is that item is not a column in the table. And the DESCRIPTION clause for entStateEntry does not provide the needed info. In general, why is there a "sparse relationship". When should state be provided and when should it not? /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 15:00:33 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 PAA29318 for ; Fri, 13 Feb 2004 15:00:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjTq-0005Jg-40 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 15:00:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DK06RU020411 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 15:00:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjTn-0005Ik-SU; Fri, 13 Feb 2004 15:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjTB-0005Bq-6i for entmib@optimus.ietf.org; Fri, 13 Feb 2004 14:59:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29236 for ; Fri, 13 Feb 2004 14:59:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArjT8-0004KC-00 for entmib@ietf.org; Fri, 13 Feb 2004 14:59:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArjSJ-0004EQ-00 for entmib@ietf.org; Fri, 13 Feb 2004 14:58:32 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArjRg-00044s-00 for entmib@ietf.org; Fri, 13 Feb 2004 14:57:52 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1DJvLS18319 for ; Fri, 13 Feb 2004 14:57:21 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH83W4>; Fri, 13 Feb 2004 14:57:21 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A6FD4@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 13 Feb 2004 14:57:17 -0500 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 Subject: [Entmib] RE: Index for table entStateTable 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 With respect to the first point, can you provide me with the specific reference? I've just done a quick look through RFC2578 and the MIB Review Guidelines document and could not find what you were referring to. With respect to the second point, it is a sparse relationship because that was working group consensus. I didn't agree with the logic, so it's difficult to recall. If I remember correctly, the logic was that not all equipment would be able to report all the status information, so people wanted a sparse augment. I'll propose adding some text to this affect. Of course people could just as easily just use the 'notApplicable' (or whatever we decided to call it) value for the enumeration instead. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 3:11 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Index for table entStateTable HI, The SMI requires that the DESCRIPTION for the row of a table describe the index item is that item is not a column in the table. And the DESCRIPTION clause for entStateEntry does not provide the needed info. In general, why is there a "sparse relationship". When should state be provided and when should it not? /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 15:09:29 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 PAA00017 for ; Fri, 13 Feb 2004 15:09:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjcT-0004B5-SW; Fri, 13 Feb 2004 15:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arjbj-0003xw-8E for entmib@optimus.ietf.org; Fri, 13 Feb 2004 15:08:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29876 for ; Fri, 13 Feb 2004 15:08:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arjbg-0004zq-00 for entmib@ietf.org; Fri, 13 Feb 2004 15:08:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arjaf-0004wI-00 for entmib@ietf.org; Fri, 13 Feb 2004 15:07:09 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ArjZo-0004pY-00 for entmib@ietf.org; Fri, 13 Feb 2004 15:06:16 -0500 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 i1DK5jn00302 for ; Fri, 13 Feb 2004 15:05:45 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH838A>; Fri, 13 Feb 2004 15:05:46 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A6FF9@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #329] AutoReply: Usage State Scope Date: Fri, 13 Feb 2004 15:05:43 -0500 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 I think it is important to distinguish between standardizing on the behaviour and characteristics of physical entities and how this information is reported. I think when you look at different real-world products you can't really generalize by physical class type, only by the features that are supported. Some of the fans and power supplies I've heard about are very sophisticated. I'm not saying that all fans and power supplies should be, but I don't want to put anything in the MIB that would prevent these entities from taking advantage of the reporting capabilities within the MIB. Sharon. -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Friday, February 13, 2004 8:48 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #329] AutoReply: Usage State Scope In short: I think the interpretation of the states for the various entity classes needs to be clarified. (I think Dave also wrote something in that direction.) Without guidance from the spec, implementations will just not use the same model and fail to interoperate. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ 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 Fri Feb 13 15:09:29 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 PAA00018 for ; Fri, 13 Feb 2004 15:09:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjcU-0004Bx-AP for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 15:09:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DK92cs016096 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 15:09:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjcT-0004B5-SW; Fri, 13 Feb 2004 15:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arjbj-0003xw-8E for entmib@optimus.ietf.org; Fri, 13 Feb 2004 15:08:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29876 for ; Fri, 13 Feb 2004 15:08:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arjbg-0004zq-00 for entmib@ietf.org; Fri, 13 Feb 2004 15:08:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arjaf-0004wI-00 for entmib@ietf.org; Fri, 13 Feb 2004 15:07:09 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ArjZo-0004pY-00 for entmib@ietf.org; Fri, 13 Feb 2004 15:06:16 -0500 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 i1DK5jn00302 for ; Fri, 13 Feb 2004 15:05:45 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH838A>; Fri, 13 Feb 2004 15:05:46 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A6FF9@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #329] AutoReply: Usage State Scope Date: Fri, 13 Feb 2004 15:05:43 -0500 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 I think it is important to distinguish between standardizing on the behaviour and characteristics of physical entities and how this information is reported. I think when you look at different real-world products you can't really generalize by physical class type, only by the features that are supported. Some of the fans and power supplies I've heard about are very sophisticated. I'm not saying that all fans and power supplies should be, but I don't want to put anything in the MIB that would prevent these entities from taking advantage of the reporting capabilities within the MIB. Sharon. -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Friday, February 13, 2004 8:48 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #329] AutoReply: Usage State Scope In short: I think the interpretation of the states for the various entity classes needs to be clarified. (I think Dave also wrote something in that direction.) Without guidance from the spec, implementations will just not use the same model and fail to interoperate. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ 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 Fri Feb 13 15:26:31 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 PAA01374 for ; Fri, 13 Feb 2004 15:26:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arjsv-0008B5-Pm; Fri, 13 Feb 2004 15:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arjs7-0008AT-Mt for entmib@optimus.ietf.org; Fri, 13 Feb 2004 15:25:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01335 for ; Fri, 13 Feb 2004 15:25:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arjs6-0006ET-00 for entmib@ietf.org; Fri, 13 Feb 2004 15:25:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arjr9-0006B1-00 for entmib@ietf.org; Fri, 13 Feb 2004 15:24:12 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Arjqb-000663-00 for entmib@ietf.org; Fri, 13 Feb 2004 15:23:37 -0500 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 i1DKN6n02668 for ; Fri, 13 Feb 2004 15:23:06 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8P2A>; Fri, 13 Feb 2004 15:23:07 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7029@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is sema ntically wrong Date: Fri, 13 Feb 2004 15:23:02 -0500 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: , The following is the proposed resolution to entstate-307. The issue will be considered closed pending the proposed edit being done. Replace the enumeration 'notSupported' with 'unavailable' in each of the TCs and any references within the text. For each of the (TC, object definition) pairs, move the following sort of text from the object definition to the textual convention: "A value of 'unavailable' means that this resource is unable to report [this] state." Modifications include section 3.1, pp 3 section 3.4 TC AdminState TC OperState TC UsageState TC AlarmStatus TC StandbyStatus Object entStateAdmin Object entStateOper Object entStateUsage Object entStateAlarm Object entStateStandby Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Thursday, February 12, 2004 3:59 PM To: entmib@ietf.org Subject: RE: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is sema ntically wrong Hi Well, if we are to pick from the three, I think "unavailable" aligns best with resolving this issue. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Thursday, February 12, 2004 3:51 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Re: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is semantically wrong HI, For me, the term "notReportable" is worse than "notSupported". The terms "notSupported", "unknown" and "unavailable" are used in MIB modules indicate an appropriate value cannot be obtained by the access or instrumentation code. Mods: section 3.1, pp 3 section 3.4 TC AdminState TC OperState TC UsageState TC AlarmStatus TC StandbyStatus Object entStateAdmin Object entStateOper Object entStateUsage Object entStateAlarm Object entStateStandby At 01:53 PM 2/11/2004 -0500, Sharon Chisholm wrote: >Hi > >That last bit should read > >""A value >of 'notReportable' means that this resource is unable to report [this] >state." > >Sharon > >-----Original Message----- >From: Chisholm, Sharon [CAR:0S00:EXCH] >Sent: Wednesday, February 11, 2004 1:51 PM >To: 'entmib@ietf.org' >Subject: FW: [psg.com #307] AutoReply: 'notSupported' is semantically >wrong > > >The following is the proposed resolution to entstate-307. The issue >will be considered closed pending the proposed edit being done. > >Replace the enumeration 'notSupported' with 'notReportable' in each of >the TCs and any references within the text. > >For each of the (TC, object definition) pairs, move the following sort >of text from the object definition to the textual convention: > >"A value >of 'notApplicable' means that this resource is unable to report [this] >state." > >Sharon > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 2:50 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #307] AutoReply: 'notSupported' is semantically wrong > > > >----------------------------------------------------------------------- >-- >Keith McCloghrie [kzm@cisco.com] > >" >> 'notSupported' is semantically wrong, because a compliant >implementation >> obviously supports the MIB, but it can return 'notSupported' for >> every object in the MIB. Presumably, the intended semantics is that >> the agent would return the right value if only it knew the right >value; >> i.e., 'unknown' is the desired semantics. Also, why is each >definition >> of 'notSupported' defined in an object's DESCRIPTION, not in the >TC's >> DESCRIPTION ?" /david t. perkins _______________________________________________ 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 Fri Feb 13 15:26:31 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 PAA01384 for ; Fri, 13 Feb 2004 15:26:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arjsw-0008Bh-RR for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 15:26:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DKQ2gQ031461 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 15:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arjsv-0008B5-Pm; Fri, 13 Feb 2004 15:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arjs7-0008AT-Mt for entmib@optimus.ietf.org; Fri, 13 Feb 2004 15:25:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01335 for ; Fri, 13 Feb 2004 15:25:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arjs6-0006ET-00 for entmib@ietf.org; Fri, 13 Feb 2004 15:25:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arjr9-0006B1-00 for entmib@ietf.org; Fri, 13 Feb 2004 15:24:12 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Arjqb-000663-00 for entmib@ietf.org; Fri, 13 Feb 2004 15:23:37 -0500 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 i1DKN6n02668 for ; Fri, 13 Feb 2004 15:23:06 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8P2A>; Fri, 13 Feb 2004 15:23:07 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7029@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is sema ntically wrong Date: Fri, 13 Feb 2004 15:23:02 -0500 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: , The following is the proposed resolution to entstate-307. The issue will be considered closed pending the proposed edit being done. Replace the enumeration 'notSupported' with 'unavailable' in each of the TCs and any references within the text. For each of the (TC, object definition) pairs, move the following sort of text from the object definition to the textual convention: "A value of 'unavailable' means that this resource is unable to report [this] state." Modifications include section 3.1, pp 3 section 3.4 TC AdminState TC OperState TC UsageState TC AlarmStatus TC StandbyStatus Object entStateAdmin Object entStateOper Object entStateUsage Object entStateAlarm Object entStateStandby Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Thursday, February 12, 2004 3:59 PM To: entmib@ietf.org Subject: RE: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is sema ntically wrong Hi Well, if we are to pick from the three, I think "unavailable" aligns best with resolving this issue. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Thursday, February 12, 2004 3:51 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Re: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is semantically wrong HI, For me, the term "notReportable" is worse than "notSupported". The terms "notSupported", "unknown" and "unavailable" are used in MIB modules indicate an appropriate value cannot be obtained by the access or instrumentation code. Mods: section 3.1, pp 3 section 3.4 TC AdminState TC OperState TC UsageState TC AlarmStatus TC StandbyStatus Object entStateAdmin Object entStateOper Object entStateUsage Object entStateAlarm Object entStateStandby At 01:53 PM 2/11/2004 -0500, Sharon Chisholm wrote: >Hi > >That last bit should read > >""A value >of 'notReportable' means that this resource is unable to report [this] >state." > >Sharon > >-----Original Message----- >From: Chisholm, Sharon [CAR:0S00:EXCH] >Sent: Wednesday, February 11, 2004 1:51 PM >To: 'entmib@ietf.org' >Subject: FW: [psg.com #307] AutoReply: 'notSupported' is semantically >wrong > > >The following is the proposed resolution to entstate-307. The issue >will be considered closed pending the proposed edit being done. > >Replace the enumeration 'notSupported' with 'notReportable' in each of >the TCs and any references within the text. > >For each of the (TC, object definition) pairs, move the following sort >of text from the object definition to the textual convention: > >"A value >of 'notApplicable' means that this resource is unable to report [this] >state." > >Sharon > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 2:50 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #307] AutoReply: 'notSupported' is semantically wrong > > > >----------------------------------------------------------------------- >-- >Keith McCloghrie [kzm@cisco.com] > >" >> 'notSupported' is semantically wrong, because a compliant >implementation >> obviously supports the MIB, but it can return 'notSupported' for >> every object in the MIB. Presumably, the intended semantics is that >> the agent would return the right value if only it knew the right >value; >> i.e., 'unknown' is the desired semantics. Also, why is each >definition >> of 'notSupported' defined in an object's DESCRIPTION, not in the >TC's >> DESCRIPTION ?" /david t. perkins _______________________________________________ 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 Fri Feb 13 15:33:38 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 OAA28561 for ; Fri, 13 Feb 2004 14:45:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjFH-00034u-Jg for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 14:45:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DJj3XI011820 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 14:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjFF-00034I-TA; Fri, 13 Feb 2004 14:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjER-00033I-4n for entmib@optimus.ietf.org; Fri, 13 Feb 2004 14:44:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28534 for ; Fri, 13 Feb 2004 14:44:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArjEO-0002sg-00 for entmib@ietf.org; Fri, 13 Feb 2004 14:44:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArjDS-0002pC-00 for entmib@ietf.org; Fri, 13 Feb 2004 14:43:10 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArjCe-0002hD-00 for entmib@ietf.org; Fri, 13 Feb 2004 14:42:20 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1DJfhS16599 for ; Fri, 13 Feb 2004 14:41:44 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH83KV>; Fri, 13 Feb 2004 14:41:44 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A6F96@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 13 Feb 2004 14:41:42 -0500 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 Subject: [Entmib] FW: [psg.com #335] AutoReply: Notification Comments 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: , The following is the proposed resolution to entstate-335. The issue will be considered closed pending the proposed edit being done. In the description for entStateOperEnabled replace "An entStateOperEnabled trap signifies that the SNMP" With "An entStateOperEnabled Notification signifies that the SNMP" And in the description of entStateOperDisabled replace "An entStateOperDisabled trap signifies that the SNMP" With "An entStateOperDisabled Notification signifies that the SNMP" With respect to the other comments, the only interface that we associate with the physical port is the lowest layer, so it would not be for every linkUp/linkDown that we would end up with two sets of notifications. My feeling is that it is a little late to be discussing additional notifications to add. Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Friday, February 13, 2004 12:20 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #335] AutoReply: Notification Comments ------------------------------------------------------------------------- David T. Perkins [dperkins@dsperkins.com] "So, if an interface goes from down to up, with both a linkUp and a entStateOperEnabled notification be generated? Note the term "trap" needs to be replaced with "notification" in the DESCRIPTION clause. Why no notifications when the value of entStateStandby changes from/to providingService." _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 15:45:31 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 PAA02548 for ; Fri, 13 Feb 2004 15:45:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkBJ-0001Zp-KS; Fri, 13 Feb 2004 15:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkAU-0001P3-9P for entmib@optimus.ietf.org; Fri, 13 Feb 2004 15:44:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02544 for ; Fri, 13 Feb 2004 15:44:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArkAS-000081-00 for entmib@ietf.org; Fri, 13 Feb 2004 15:44:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ark9Y-00005K-00 for entmib@ietf.org; Fri, 13 Feb 2004 15:43:13 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ark98-00001s-00 for entmib@ietf.org; Fri, 13 Feb 2004 15:42:46 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1DKgeR09201; Fri, 13 Feb 2004 12:42:40 -0800 Message-Id: <5.2.0.9.2.20040213124134.01fa7978@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Feb 2004 12:42:33 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Subject: RE: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is sema ntically wrong In-Reply-To: <3549C09B853DD5119B540002A52CDD340A2A7029@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, No, no, no - get rid of the "not reportable" terminology! At 03:23 PM 2/13/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-307. The issue >will be considered closed pending the proposed edit being done. > >Replace the enumeration 'notSupported' with 'unavailable' in each of >the TCs and any references within the text. > >For each of the (TC, object definition) pairs, move the following sort >of text from the object definition to the textual convention: > >"A value >of 'unavailable' means that this resource is unable to report [this] >state." > >Modifications include > section 3.1, pp 3 > section 3.4 > TC AdminState > TC OperState > TC UsageState > TC AlarmStatus > TC StandbyStatus > Object entStateAdmin > Object entStateOper > Object entStateUsage > Object entStateAlarm > Object entStateStandby > >Sharon > >-----Original Message----- >From: Chisholm, Sharon [CAR:0S00:EXCH] >Sent: Thursday, February 12, 2004 3:59 PM >To: entmib@ietf.org >Subject: RE: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is sema >ntically wrong > > >Hi > >Well, if we are to pick from the three, I think "unavailable" aligns best >with resolving this issue. > >Sharon > >-----Original Message----- >From: David T. Perkins [mailto:dperkins@dsperkins.com] >Sent: Thursday, February 12, 2004 3:51 PM >To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org >Subject: Re: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is >semantically wrong > > >HI, > >For me, the term "notReportable" is worse than "notSupported". The terms >"notSupported", "unknown" and "unavailable" are used in MIB modules indicate >an appropriate value cannot be obtained by the access or instrumentation >code. > >Mods: >section 3.1, pp 3 >section 3.4 >TC AdminState >TC OperState >TC UsageState >TC AlarmStatus >TC StandbyStatus >Object entStateAdmin >Object entStateOper >Object entStateUsage >Object entStateAlarm >Object entStateStandby > > > >At 01:53 PM 2/11/2004 -0500, Sharon Chisholm wrote: >>Hi >> >>That last bit should read >> >>""A value >>of 'notReportable' means that this resource is unable to report [this] >>state." >> >>Sharon >> >>-----Original Message----- >>From: Chisholm, Sharon [CAR:0S00:EXCH] >>Sent: Wednesday, February 11, 2004 1:51 PM >>To: 'entmib@ietf.org' >>Subject: FW: [psg.com #307] AutoReply: 'notSupported' is semantically >>wrong >> >> >>The following is the proposed resolution to entstate-307. The issue >>will be considered closed pending the proposed edit being done. >> >>Replace the enumeration 'notSupported' with 'notReportable' in each of >>the TCs and any references within the text. >> >>For each of the (TC, object definition) pairs, move the following sort >>of text from the object definition to the textual convention: >> >>"A value >>of 'notApplicable' means that this resource is unable to report [this] >>state." >> >>Sharon >> >>-----Original Message----- >>From: entity-state [mailto:rt+entity-state@rt.psg.com] >>Sent: Tuesday, January 13, 2004 2:50 AM >>To: Chisholm, Sharon [CAR:0S00:EXCH] >>Subject: [psg.com #307] AutoReply: 'notSupported' is semantically wrong >> >> >> >>----------------------------------------------------------------------- >>-- >>Keith McCloghrie [kzm@cisco.com] >> >>" >>> 'notSupported' is semantically wrong, because a compliant >>implementation >>> obviously supports the MIB, but it can return 'notSupported' for >>> every object in the MIB. Presumably, the intended semantics is that >>> the agent would return the right value if only it knew the right >>value; >>> i.e., 'unknown' is the desired semantics. Also, why is each >>definition >>> of 'notSupported' defined in an object's DESCRIPTION, not in the >>TC's >>> DESCRIPTION ?" >/david t. perkins > > >_______________________________________________ >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 Fri Feb 13 15:45:31 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 PAA02550 for ; Fri, 13 Feb 2004 15:45:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkBL-0001ai-NS for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 15:45:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DKj2hu006083 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 15:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkBJ-0001Zp-KS; Fri, 13 Feb 2004 15:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkAU-0001P3-9P for entmib@optimus.ietf.org; Fri, 13 Feb 2004 15:44:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02544 for ; Fri, 13 Feb 2004 15:44:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArkAS-000081-00 for entmib@ietf.org; Fri, 13 Feb 2004 15:44:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ark9Y-00005K-00 for entmib@ietf.org; Fri, 13 Feb 2004 15:43:13 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ark98-00001s-00 for entmib@ietf.org; Fri, 13 Feb 2004 15:42:46 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1DKgeR09201; Fri, 13 Feb 2004 12:42:40 -0800 Message-Id: <5.2.0.9.2.20040213124134.01fa7978@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Feb 2004 12:42:33 -0800 To: "Sharon Chisholm" , entmib@ietf.org From: "David T. Perkins" Subject: RE: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is sema ntically wrong In-Reply-To: <3549C09B853DD5119B540002A52CDD340A2A7029@zcard0ka.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, No, no, no - get rid of the "not reportable" terminology! At 03:23 PM 2/13/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-307. The issue >will be considered closed pending the proposed edit being done. > >Replace the enumeration 'notSupported' with 'unavailable' in each of >the TCs and any references within the text. > >For each of the (TC, object definition) pairs, move the following sort >of text from the object definition to the textual convention: > >"A value >of 'unavailable' means that this resource is unable to report [this] >state." > >Modifications include > section 3.1, pp 3 > section 3.4 > TC AdminState > TC OperState > TC UsageState > TC AlarmStatus > TC StandbyStatus > Object entStateAdmin > Object entStateOper > Object entStateUsage > Object entStateAlarm > Object entStateStandby > >Sharon > >-----Original Message----- >From: Chisholm, Sharon [CAR:0S00:EXCH] >Sent: Thursday, February 12, 2004 3:59 PM >To: entmib@ietf.org >Subject: RE: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is sema >ntically wrong > > >Hi > >Well, if we are to pick from the three, I think "unavailable" aligns best >with resolving this issue. > >Sharon > >-----Original Message----- >From: David T. Perkins [mailto:dperkins@dsperkins.com] >Sent: Thursday, February 12, 2004 3:51 PM >To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org >Subject: Re: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is >semantically wrong > > >HI, > >For me, the term "notReportable" is worse than "notSupported". The terms >"notSupported", "unknown" and "unavailable" are used in MIB modules indicate >an appropriate value cannot be obtained by the access or instrumentation >code. > >Mods: >section 3.1, pp 3 >section 3.4 >TC AdminState >TC OperState >TC UsageState >TC AlarmStatus >TC StandbyStatus >Object entStateAdmin >Object entStateOper >Object entStateUsage >Object entStateAlarm >Object entStateStandby > > > >At 01:53 PM 2/11/2004 -0500, Sharon Chisholm wrote: >>Hi >> >>That last bit should read >> >>""A value >>of 'notReportable' means that this resource is unable to report [this] >>state." >> >>Sharon >> >>-----Original Message----- >>From: Chisholm, Sharon [CAR:0S00:EXCH] >>Sent: Wednesday, February 11, 2004 1:51 PM >>To: 'entmib@ietf.org' >>Subject: FW: [psg.com #307] AutoReply: 'notSupported' is semantically >>wrong >> >> >>The following is the proposed resolution to entstate-307. The issue >>will be considered closed pending the proposed edit being done. >> >>Replace the enumeration 'notSupported' with 'notReportable' in each of >>the TCs and any references within the text. >> >>For each of the (TC, object definition) pairs, move the following sort >>of text from the object definition to the textual convention: >> >>"A value >>of 'notApplicable' means that this resource is unable to report [this] >>state." >> >>Sharon >> >>-----Original Message----- >>From: entity-state [mailto:rt+entity-state@rt.psg.com] >>Sent: Tuesday, January 13, 2004 2:50 AM >>To: Chisholm, Sharon [CAR:0S00:EXCH] >>Subject: [psg.com #307] AutoReply: 'notSupported' is semantically wrong >> >> >> >>----------------------------------------------------------------------- >>-- >>Keith McCloghrie [kzm@cisco.com] >> >>" >>> 'notSupported' is semantically wrong, because a compliant >>implementation >>> obviously supports the MIB, but it can return 'notSupported' for >>> every object in the MIB. Presumably, the intended semantics is that >>> the agent would return the right value if only it knew the right >>value; >>> i.e., 'unknown' is the desired semantics. Also, why is each >>definition >>> of 'notSupported' defined in an object's DESCRIPTION, not in the >>TC's >>> DESCRIPTION ?" >/david t. perkins > > >_______________________________________________ >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 Fri Feb 13 16:02:29 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 QAA03143 for ; Fri, 13 Feb 2004 16:02:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkRk-0002dJ-N5; Fri, 13 Feb 2004 16:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkQz-0002Th-Q8 for entmib@optimus.ietf.org; Fri, 13 Feb 2004 16:01:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03038 for ; Fri, 13 Feb 2004 16:01:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArkQx-0001Im-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:01:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArkQ4-0001Dp-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:00:16 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArkPW-00016q-00 for entmib@ietf.org; Fri, 13 Feb 2004 15:59:42 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1DKx6S00655 for ; Fri, 13 Feb 2004 15:59:06 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8QAW>; Fri, 13 Feb 2004 15:59:07 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A709B@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? Date: Fri, 13 Feb 2004 15:59:03 -0500 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: , The following is the proposed resolution to entstate-311. The issue will be considered closed pending the proposed edit being done. Replace 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed, or zero."' With 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when the value of any of entStateAdmin, entStateOper, entStateUsage, entStateAlarm, or entStateStandby changed for this entity. If there has been no change since the last re-initialization of the local system, this object contains the date and time of local system initialization. If there has been no change since the entity was added to the local system, this object contains the date and time of the insertion."' Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 1:48 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? HI, On this object, the description needs a little more detail. Maybe it's obvious, but the description should be clear that the value is updated whenever the value of any of the objects entStateAdmin, entStateOper, entStateUsage, entStateAlarm, or entStateStandby change in the row. Also, the description needs to describe the value after hot insert or hot removal. At 04:36 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-311. The issue >will be considered closed pending the proposed edit being done. > >Replace > >'entStateLastChanged OBJECT-TYPE >SYNTAX DateAndTime >MAX-ACCESS read-only >STATUS current >DESCRIPTION > "The value of this object is the date and > time when state/status of the entity > last changed, or zero."' > >With > >'entStateLastChanged OBJECT-TYPE >SYNTAX DateAndTime >MAX-ACCESS read-only >STATUS current >DESCRIPTION > "The value of this object is the date and > time when state/status of the entity > last changed. If there has been no change since > the last re-initialization of the local system, > this object contains the date and time of > local system initialization."' > >Sharon > > > >-----Original Message----- >From: Subrahmanya Hegde [mailto:subrah@cisco.com] >Sent: Wednesday, February 11, 2004 4:34 PM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Cc: entmib@ietf.org >Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? > > >Sounds great > >Subra > > >Sharon Chisholm wrote: > > >Hi > > > >The term "during" by its nature implies a span of time, rather than >single > >value. If we replaced "that" with "local system" would that work for >you? > > > >Sharon > > > >-----Original Message----- > >From: Subrahmanya Hegde [mailto:subrah@cisco.com > ] > > >Sent: Wednesday, February 11, 2004 3:53 PM > >To: Chisholm, Sharon [CAR:0S00:EXCH] > >Cc: entmib@ietf.org > >Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? > > > > > >'entStateLastChanged OBJECT-TYPE > > SYNTAX DateAndTime > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The value of this object is the date and > > time when state/status of the entity > > last changed. If there has been no change since > > the last re-initialization of the local system, > > > > this object contains the date and time of > > that initialization."' > > > > > >may be good to rephrase it as : > > > > contains the date and time during initialization > > > >'that' does not seem to fit well > > > >Subra > > > > > > > > > > > >Sharon Chisholm wrote: > > > > > >The following is the proposed resolution to entstate-311. The issue > >will be considered closed pending the proposed edit being done. > > > >Replace > > > >'entStateLastChanged OBJECT-TYPE > > SYNTAX DateAndTime > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The value of this object is the date and > > time when state/status of the entity > > last changed, or zero."' > > > >With > > > >'entStateLastChanged OBJECT-TYPE > > SYNTAX DateAndTime > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The value of this object is the date and > > time when state/status of the entity > > last changed. If there has been no change since > > the last re-initialization of the local system, > > this object contains the date and time of > > that initialization."' > > > >Sharon > > > >-----Original Message----- > >From: entity-state [mailto:rt+entity-state@rt.psg.com > ] > >Sent: Tuesday, January 13, 2004 3:00 AM > >To: Chisholm, Sharon [CAR:0S00:EXCH] > >Subject: [psg.com #311] AutoReply: DateAndTimeOrZero ? > > > > > > > >----------------------------------------------------------------------- > >-- > >Keith McCloghrie [kzm@cisco.com ] > > > >should the MIB define DateAndTimeOrZero ? What does zero mean ? /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 16:02:29 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 QAA03157 for ; Fri, 13 Feb 2004 16:02:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkRl-0002dj-GU for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 16:02:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DL21da010132 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 16:02:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkRk-0002dJ-N5; Fri, 13 Feb 2004 16:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkQz-0002Th-Q8 for entmib@optimus.ietf.org; Fri, 13 Feb 2004 16:01:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03038 for ; Fri, 13 Feb 2004 16:01:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArkQx-0001Im-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:01:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArkQ4-0001Dp-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:00:16 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArkPW-00016q-00 for entmib@ietf.org; Fri, 13 Feb 2004 15:59:42 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1DKx6S00655 for ; Fri, 13 Feb 2004 15:59:06 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8QAW>; Fri, 13 Feb 2004 15:59:07 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A709B@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? Date: Fri, 13 Feb 2004 15:59:03 -0500 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: , The following is the proposed resolution to entstate-311. The issue will be considered closed pending the proposed edit being done. Replace 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when state/status of the entity last changed, or zero."' With 'entStateLastChanged OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the date and time when the value of any of entStateAdmin, entStateOper, entStateUsage, entStateAlarm, or entStateStandby changed for this entity. If there has been no change since the last re-initialization of the local system, this object contains the date and time of local system initialization. If there has been no change since the entity was added to the local system, this object contains the date and time of the insertion."' Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 1:48 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? HI, On this object, the description needs a little more detail. Maybe it's obvious, but the description should be clear that the value is updated whenever the value of any of the objects entStateAdmin, entStateOper, entStateUsage, entStateAlarm, or entStateStandby change in the row. Also, the description needs to describe the value after hot insert or hot removal. At 04:36 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-311. The issue >will be considered closed pending the proposed edit being done. > >Replace > >'entStateLastChanged OBJECT-TYPE >SYNTAX DateAndTime >MAX-ACCESS read-only >STATUS current >DESCRIPTION > "The value of this object is the date and > time when state/status of the entity > last changed, or zero."' > >With > >'entStateLastChanged OBJECT-TYPE >SYNTAX DateAndTime >MAX-ACCESS read-only >STATUS current >DESCRIPTION > "The value of this object is the date and > time when state/status of the entity > last changed. If there has been no change since > the last re-initialization of the local system, > this object contains the date and time of > local system initialization."' > >Sharon > > > >-----Original Message----- >From: Subrahmanya Hegde [mailto:subrah@cisco.com] >Sent: Wednesday, February 11, 2004 4:34 PM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Cc: entmib@ietf.org >Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? > > >Sounds great > >Subra > > >Sharon Chisholm wrote: > > >Hi > > > >The term "during" by its nature implies a span of time, rather than >single > >value. If we replaced "that" with "local system" would that work for >you? > > > >Sharon > > > >-----Original Message----- > >From: Subrahmanya Hegde [mailto:subrah@cisco.com > ] > > >Sent: Wednesday, February 11, 2004 3:53 PM > >To: Chisholm, Sharon [CAR:0S00:EXCH] > >Cc: entmib@ietf.org > >Subject: Re: [Entmib] FW: [psg.com #311] AutoReply: DateAndTimeOrZero ? > > > > > >'entStateLastChanged OBJECT-TYPE > > SYNTAX DateAndTime > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The value of this object is the date and > > time when state/status of the entity > > last changed. If there has been no change since > > the last re-initialization of the local system, > > > > this object contains the date and time of > > that initialization."' > > > > > >may be good to rephrase it as : > > > > contains the date and time during initialization > > > >'that' does not seem to fit well > > > >Subra > > > > > > > > > > > >Sharon Chisholm wrote: > > > > > >The following is the proposed resolution to entstate-311. The issue > >will be considered closed pending the proposed edit being done. > > > >Replace > > > >'entStateLastChanged OBJECT-TYPE > > SYNTAX DateAndTime > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The value of this object is the date and > > time when state/status of the entity > > last changed, or zero."' > > > >With > > > >'entStateLastChanged OBJECT-TYPE > > SYNTAX DateAndTime > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The value of this object is the date and > > time when state/status of the entity > > last changed. If there has been no change since > > the last re-initialization of the local system, > > this object contains the date and time of > > that initialization."' > > > >Sharon > > > >-----Original Message----- > >From: entity-state [mailto:rt+entity-state@rt.psg.com > ] > >Sent: Tuesday, January 13, 2004 3:00 AM > >To: Chisholm, Sharon [CAR:0S00:EXCH] > >Subject: [psg.com #311] AutoReply: DateAndTimeOrZero ? > > > > > > > >----------------------------------------------------------------------- > >-- > >Keith McCloghrie [kzm@cisco.com ] > > > >should the MIB define DateAndTimeOrZero ? What does zero mean ? /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 16:11: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 QAA04009 for ; Fri, 13 Feb 2004 16:11:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkaS-0003xW-UR; Fri, 13 Feb 2004 16:11:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkZk-0003px-0h for entmib@optimus.ietf.org; Fri, 13 Feb 2004 16:10:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03749 for ; Fri, 13 Feb 2004 16:10:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArkZh-0001z2-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:10:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArkYo-0001vF-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:09:18 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ArkXy-0001nS-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:08:26 -0500 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 i1DL7tn15232 for ; Fri, 13 Feb 2004 16:07:55 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8QG9>; Fri, 13 Feb 2004 16:07:56 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A70A9@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #322] AutoReply: Textual Convention Nam es (Prefix) Date: Fri, 13 Feb 2004 16:07:48 -0500 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: , The following is the proposed resolution to entstate-322. The issue will be considered closed with no changes made to the document. As indicated previously >There were various bits of discussion on the list on when it is >appropriate to use a MIB specific prefix on a textual convention and >when it does not. As the intention on these textual conventions is for >general use it would seem that a prefix is not appropriate. The >proposal is to keep the names as is. In response to Dave's comments, I see nothing within the state/status objects that is specific to entities not that would prevent them from being applies elsewhere. They were specifically worded for reuse - the use of the generic term resource for example. In fact, there is a lot of examples within industry where they can been applied to logical items. I'll leave a discussion of whether that is a good idea to those who may choose to re-use these textual conventions. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 2:06 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #322] AutoReply: Textual Convention Names (Prefix) HI, If the TCs are truly "generic", then they shouldn't be identified with a specific MIB module. However, I'm not at all convinced that they are generic. In fact, I really don't believe that thye are appropriate for both physical and logical entities. So, I support changing the descriptors(what is called "names" below) for the TCs. At 03:43 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-322. The issue >will be considered closed with no changes made to the document. > >There were various bits of discussion on the list on when it is >appropriate to use a MIB specific prefix on a textual convention and >when it does not. As the intention on these textual conventions is for >general use it would seem that a prefix is not appropriate. The >proposal is to keep the names as is. > >Sharon >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Friday, February 06, 2004 2:33 PM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #322] AutoReply: Textual Convention Names (Prefix) > > > >----------------------------------------------------------------------- >-- >Andy Bierman [abierman@cisco.com] > >the TCs should be named with a prefix. E.g., >OperState -> EntityOperState. This applies to >all the TCs in the draft. /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 16:11:29 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 QAA04023 for ; Fri, 13 Feb 2004 16:11:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkaT-0003yH-I3 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 16:11:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DLB10D015228 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 16:11:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkaS-0003xW-UR; Fri, 13 Feb 2004 16:11:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkZk-0003px-0h for entmib@optimus.ietf.org; Fri, 13 Feb 2004 16:10:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03749 for ; Fri, 13 Feb 2004 16:10:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArkZh-0001z2-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:10:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArkYo-0001vF-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:09:18 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ArkXy-0001nS-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:08:26 -0500 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 i1DL7tn15232 for ; Fri, 13 Feb 2004 16:07:55 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8QG9>; Fri, 13 Feb 2004 16:07:56 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A70A9@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #322] AutoReply: Textual Convention Nam es (Prefix) Date: Fri, 13 Feb 2004 16:07:48 -0500 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: , The following is the proposed resolution to entstate-322. The issue will be considered closed with no changes made to the document. As indicated previously >There were various bits of discussion on the list on when it is >appropriate to use a MIB specific prefix on a textual convention and >when it does not. As the intention on these textual conventions is for >general use it would seem that a prefix is not appropriate. The >proposal is to keep the names as is. In response to Dave's comments, I see nothing within the state/status objects that is specific to entities not that would prevent them from being applies elsewhere. They were specifically worded for reuse - the use of the generic term resource for example. In fact, there is a lot of examples within industry where they can been applied to logical items. I'll leave a discussion of whether that is a good idea to those who may choose to re-use these textual conventions. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 2:06 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #322] AutoReply: Textual Convention Names (Prefix) HI, If the TCs are truly "generic", then they shouldn't be identified with a specific MIB module. However, I'm not at all convinced that they are generic. In fact, I really don't believe that thye are appropriate for both physical and logical entities. So, I support changing the descriptors(what is called "names" below) for the TCs. At 03:43 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-322. The issue >will be considered closed with no changes made to the document. > >There were various bits of discussion on the list on when it is >appropriate to use a MIB specific prefix on a textual convention and >when it does not. As the intention on these textual conventions is for >general use it would seem that a prefix is not appropriate. The >proposal is to keep the names as is. > >Sharon >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Friday, February 06, 2004 2:33 PM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #322] AutoReply: Textual Convention Names (Prefix) > > > >----------------------------------------------------------------------- >-- >Andy Bierman [abierman@cisco.com] > >the TCs should be named with a prefix. E.g., >OperState -> EntityOperState. This applies to >all the TCs in the draft. /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 16:18: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 QAA04632 for ; Fri, 13 Feb 2004 16:18:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkhF-00058F-34; Fri, 13 Feb 2004 16:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arkge-0004yn-IE for entmib@optimus.ietf.org; Fri, 13 Feb 2004 16:17:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04582 for ; Fri, 13 Feb 2004 16:17:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arkgc-0002dx-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:17:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arkfc-0002XY-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:16:20 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Arkf1-0002S8-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:15:43 -0500 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 i1DLFCn16206 for ; Fri, 13 Feb 2004 16:15:12 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8QLV>; Fri, 13 Feb 2004 16:15:13 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A70BD@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #327] AutoReply: More Editorial Issues Date: Fri, 13 Feb 2004 16:15:10 -0500 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: , The following is the proposed resolution to entstate-327. The issue will be considered closed pending the proposed edit being done. [Note some of the finer bits of this text will be influenced by the resolution to other problems] 1) Change the end of the abstract from "provide information about the state of the entity." to the following: "provide information about the state of physical entities." 2) In the description to StandbyStatus replace " providing service, but is will be immediately able to" With " providing service, but it will be immediately able to" 3) Note that the resolution to issue #311 covers this 4) In the description of entStateAdmin replace "The administrative state for this entity. A value of 'notSupported' means that this entity is unable to report administrative state. This object can not be administratively set to 'notSupported'. For entities that do not support administrative state, changing the value of this object to something other than 'notSupported' is not permitted. A value of 'inconsistentValue' will be returned in either case." With "The administrative state for this entity. A value of 'notSupported' means that this entity is unable to report administrative state. Setting this object to 'notSupported' will result in an 'inconsistentValue' error. For entities that do not support administrative state, all set operations will result in an 'inconsistentValue' error."" 7) Replace " entStateNotificationGroup NOTIFICATION-GROUP" With " entStateNotificationsGroup NOTIFICATION-GROUP " Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Friday, February 13, 2004 8:34 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #327] AutoReply: More Editorial Issues On Thu, Feb 12, 2004 at 01:31:23PM -0500, Sharon Chisholm wrote: > With > > "The administrative state for this entity. A value > of 'notSupported' means that this entity is unable > to report administrative state. This object can not > be manually set to 'notSupported'. For > entities that do not support administrative state, > changing the value of this object to something other > than 'notSupported' is not permitted. A value of > 'inconsistentValue' will be returned in either case." I still find the text confusing from a stylistic point of view. What about this: "The administrative state for this entity. A value of 'notSupported' means that this entity is unable to report administrative state. Setting this object to 'notSupported' will result in an 'inconsistentValue' error. For entities that do not support administrative state, all set operations will result in an 'inconsistentValue' error." /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 16:18:29 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 QAA04635 for ; Fri, 13 Feb 2004 16:18:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkhF-00058o-Jk for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 16:18:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DLI14E019741 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 16:18:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkhF-00058F-34; Fri, 13 Feb 2004 16:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arkge-0004yn-IE for entmib@optimus.ietf.org; Fri, 13 Feb 2004 16:17:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04582 for ; Fri, 13 Feb 2004 16:17:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arkgc-0002dx-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:17:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arkfc-0002XY-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:16:20 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Arkf1-0002S8-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:15:43 -0500 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 i1DLFCn16206 for ; Fri, 13 Feb 2004 16:15:12 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8QLV>; Fri, 13 Feb 2004 16:15:13 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A70BD@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #327] AutoReply: More Editorial Issues Date: Fri, 13 Feb 2004 16:15:10 -0500 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: , The following is the proposed resolution to entstate-327. The issue will be considered closed pending the proposed edit being done. [Note some of the finer bits of this text will be influenced by the resolution to other problems] 1) Change the end of the abstract from "provide information about the state of the entity." to the following: "provide information about the state of physical entities." 2) In the description to StandbyStatus replace " providing service, but is will be immediately able to" With " providing service, but it will be immediately able to" 3) Note that the resolution to issue #311 covers this 4) In the description of entStateAdmin replace "The administrative state for this entity. A value of 'notSupported' means that this entity is unable to report administrative state. This object can not be administratively set to 'notSupported'. For entities that do not support administrative state, changing the value of this object to something other than 'notSupported' is not permitted. A value of 'inconsistentValue' will be returned in either case." With "The administrative state for this entity. A value of 'notSupported' means that this entity is unable to report administrative state. Setting this object to 'notSupported' will result in an 'inconsistentValue' error. For entities that do not support administrative state, all set operations will result in an 'inconsistentValue' error."" 7) Replace " entStateNotificationGroup NOTIFICATION-GROUP" With " entStateNotificationsGroup NOTIFICATION-GROUP " Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Friday, February 13, 2004 8:34 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #327] AutoReply: More Editorial Issues On Thu, Feb 12, 2004 at 01:31:23PM -0500, Sharon Chisholm wrote: > With > > "The administrative state for this entity. A value > of 'notSupported' means that this entity is unable > to report administrative state. This object can not > be manually set to 'notSupported'. For > entities that do not support administrative state, > changing the value of this object to something other > than 'notSupported' is not permitted. A value of > 'inconsistentValue' will be returned in either case." I still find the text confusing from a stylistic point of view. What about this: "The administrative state for this entity. A value of 'notSupported' means that this entity is unable to report administrative state. Setting this object to 'notSupported' will result in an 'inconsistentValue' error. For entities that do not support administrative state, all set operations will result in an 'inconsistentValue' error." /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 16:36:30 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 QAA06993 for ; Fri, 13 Feb 2004 16:36:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arkyf-0006aZ-2q; Fri, 13 Feb 2004 16:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkyB-0006Zg-Ek for entmib@optimus.ietf.org; Fri, 13 Feb 2004 16:35:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06854 for ; Fri, 13 Feb 2004 16:35:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arky9-00066U-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:35:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arkvk-0005YJ-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:33:01 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Arktf-00051J-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:30:52 -0500 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 i1DLUKn18225 for ; Fri, 13 Feb 2004 16:30:20 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8Q4P>; Fri, 13 Feb 2004 16:30:21 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A70D9@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #328] AutoReply: Containment Hierach an d entPhysical Containedin Date: Fri, 13 Feb 2004 16:30:13 -0500 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 Ok. I'll add a section that defines containment hierarchy and be done with it. Or perhaps there is something in the Entity MIB I can point at. While a containment hierarchy is transitive, I think when we are talking about the states it can't really be for two reasons - Usage definitely can't be transitive - I think transitive starts getting into computed states, which we have defined out of scope. Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Friday, February 13, 2004 8:35 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #328] AutoReply: Containment Hierach and entPhysical Containedin On Thu, Feb 12, 2004 at 01:44:44PM -0500, Sharon Chisholm wrote: > The following is the proposed resolution to entstate-328. The issue > will be considered closed pending the proposed edit being done. > > In the various object definitions replace phrases like > > "as defined by a value of > entPhysicalContainedIn that references this entity" > > With one like > > "as defined by the entPhysicalContainedIn object." So this is not generally transitive? I like Dave Perkin's suggestion on this issue. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 16:56:29 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 QAA09293 for ; Fri, 13 Feb 2004 16:56:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlI1-0008Dk-FQ; Fri, 13 Feb 2004 16:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlHH-0008D1-2t for entmib@optimus.ietf.org; Fri, 13 Feb 2004 16:55:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09235 for ; Fri, 13 Feb 2004 16:55:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArlHE-0001C1-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:55:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArlGS-00018H-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:54:24 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArlFf-0000yL-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:53:35 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1DLr4S09831 for ; Fri, 13 Feb 2004 16:53:04 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8Q0C>; Fri, 13 Feb 2004 16:53:05 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7108@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #330] AutoReply: Notification Varbinds Date: Fri, 13 Feb 2004 16:53:02 -0500 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: , The following is the proposed resolution to entstate-330. The issue will be considered closed pending the proposed edit being done. In the description to entStateOperEnabled and entStateOperDisabled add the following text "The entStateAdmin and entStateAlarm varbinds may examined to find out additional information on the administrative state at the time of the operation state change as well to find out whether there were any known alarms against the entity at that time." Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Friday, February 13, 2004 8:23 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #330] AutoReply: Notification Varbinds On Thu, Feb 12, 2004 at 02:57:58PM -0500, Sharon Chisholm wrote: > The alarm status tells you how many outstanding problems have been > reported against this entity. This is interesting from a fault > management perspective. Let me ask again: Why is the alarm status important in the entStateOperEnabled notification? Do you expect that entities transition in the enabled operational state while alarms are pending? Is that spelled out somewhere? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 16:56:29 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 QAA09307 for ; Fri, 13 Feb 2004 16:56:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlI2-0008EK-6y for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 16:56:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DLu1lZ031619 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 16:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlI1-0008Dk-FQ; Fri, 13 Feb 2004 16:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlHH-0008D1-2t for entmib@optimus.ietf.org; Fri, 13 Feb 2004 16:55:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09235 for ; Fri, 13 Feb 2004 16:55:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArlHE-0001C1-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:55:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArlGS-00018H-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:54:24 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArlFf-0000yL-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:53:35 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1DLr4S09831 for ; Fri, 13 Feb 2004 16:53:04 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8Q0C>; Fri, 13 Feb 2004 16:53:05 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7108@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #330] AutoReply: Notification Varbinds Date: Fri, 13 Feb 2004 16:53:02 -0500 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: , The following is the proposed resolution to entstate-330. The issue will be considered closed pending the proposed edit being done. In the description to entStateOperEnabled and entStateOperDisabled add the following text "The entStateAdmin and entStateAlarm varbinds may examined to find out additional information on the administrative state at the time of the operation state change as well to find out whether there were any known alarms against the entity at that time." Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Friday, February 13, 2004 8:23 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #330] AutoReply: Notification Varbinds On Thu, Feb 12, 2004 at 02:57:58PM -0500, Sharon Chisholm wrote: > The alarm status tells you how many outstanding problems have been > reported against this entity. This is interesting from a fault > management perspective. Let me ask again: Why is the alarm status important in the entStateOperEnabled notification? Do you expect that entities transition in the enabled operational state while alarms are pending? Is that spelled out somewhere? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 17:01:37 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 RAA09571 for ; Fri, 13 Feb 2004 17:01:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlMz-0000JE-MB; Fri, 13 Feb 2004 17:01:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlMC-0008Vd-43 for entmib@optimus.ietf.org; Fri, 13 Feb 2004 17:00:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09483 for ; Fri, 13 Feb 2004 17:00:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArlM9-0001cp-00 for entmib@ietf.org; Fri, 13 Feb 2004 17:00:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArlLH-0001Xi-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:59:24 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ArlKa-0001Q4-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:58:40 -0500 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 i1DLw9n21202 for ; Fri, 13 Feb 2004 16:58:09 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8RAX>; Fri, 13 Feb 2004 16:58:10 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7110@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues Date: Fri, 13 Feb 2004 16:58:09 -0500 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 All we need to do is refer to the definitions in the Alarm MIB and we should be good. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 12:51 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues HI, The Alarm Status (not state) brings up the unsettled definition of what is "an alarm" and what is "clearing an alarm". The definition of an alarm MUST be specified for the TC and object to be useful. Or another term must be used (and, of course, that term must be well defined). I suggest that the term "alarm" be replaced by "fault". And the following be used for the TC and object definitions: FaultStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The fault status, which is a bit string. When all the bits are zero, then no faults are present. The bit 'unavailable(0)' indicates that the fault status is unknown. When set, all bits other than 'underRepair(1)' must be zero. The 'underRepair(1)' indicates that the an item is under repair. The following bits are one when one or more faults of the perceived severity exist. The value is zero for a bit when there is no existing fault of the perceived severity. The bits and faults are: 'critical(2)' 'major(3)' 'minor(4)' 'warning(5)' 'indeterminate(6)' (the perceived severity cannot be determined) The entity may continue to operate while a fault condition exists." SYNTAX BITS { unavailable(0), underRepair(1), critical(2), major(3), minor(4), -- The following are not defined in X.733 warning(6), indeterminate(7) } entStateFault OBJECT-TYPE SYNTAX FaultStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The fault status for this entity. It does not include the faults raised on entities within its containment hierarchy. These are entities that specify this entity as the value for object entPhysicalContainedIn directly and indirectly." ::= { entStateEntry 5 } At 02:44 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-310. The issue >will be considered closed pending the proposed edit being done. > >In the description of AlarmStatus replace > >" When the > value of under repair is set, the resource is currently > being repaired." > >With > >" When the > value of under repair is set, the resource is currently > being repaired, which depending on the implementation, > may make the other values in this bit string unreliable." > > >And replace > >" > When the value of 'alarmOutstanding' is set, one or more > alarms is active against the resource. The fault may or may > not be disabling. " > >With > >" > When the value of 'alarmOutstanding' is set, one or more > alarms is active against the resource. The fault may or may > not be disabling. This bit provides a high-level summary that > can be used to determine whether or not to examine the rest of > the values." > > >An explanation on the difference between raw and computed state, as >defined in section 2.1 was previously provided in relation to the >severity of alarms issue. No change appears to be necessary on that >particular issue. > >Sharon > > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 2:58 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #310] AutoReply: Alarm State Issues > > > >----------------------------------------------------------------------- >-- >Keith McCloghrie [kzm@cisco.com] > >"> 'underRepair' is an operState, not an AlarmState. >> >> from what perspective are the alarms classified as >critical/major/minor/etc. >> e.g., does a particular fault have the same alarm status >in 'coldStandby' >> as it does in 'hotStandby' or in 'providingService' ?? (hint: the >answer >> is no!!). >" > > > >Juergen Schoenwaelder [j.schoenwaelder@iu-bremen.de] > >"6) AlarmStatus TC: I do not really understand the alarmOutStanding >bit. It seems like this is set whenever one of critical, major, minor, >warning and indeterminate is set. But if this is true, I think the bit >is not really terrible useful. > >Perhaps the bit has some other meaning. If so, please clarify." Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 17:06: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 RAA10028 for ; Fri, 13 Feb 2004 17:06:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlRh-0001Mg-S4; Fri, 13 Feb 2004 17:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlR2-0001Ll-Kb for entmib@optimus.ietf.org; Fri, 13 Feb 2004 17:05:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09967 for ; Fri, 13 Feb 2004 17:05:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArlR0-0002Cz-00 for entmib@ietf.org; Fri, 13 Feb 2004 17:05:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArlQ3-00027z-00 for entmib@ietf.org; Fri, 13 Feb 2004 17:04:20 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ArlPO-0001ym-00 for entmib@ietf.org; Fri, 13 Feb 2004 17:03:38 -0500 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 i1DM37n29295 for ; Fri, 13 Feb 2004 17:03:07 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8RC7>; Fri, 13 Feb 2004 17:03:08 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A711B@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 13 Feb 2004 17:03:07 -0500 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 Subject: [Entmib] RE: More on Standby #322 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 This and your email titled "Standby" are being tracked as issue #322. I think you might be reading too much into the connection between state, status and their data type. That was certainly never done intentionally on my part and the OSI thing is a status. I'm fine with adding this additional enumeration if there are no objections. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 3:04 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: More on Standby HI, Here is a replacement for TC StandbyStatus: StandbyState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION " Represents the possible values of standby state. The value 'notAvailable(1)' means that no information is available on the standby state for the entity. The value 'hotStandby(2)' means the entity is not providing service, and will be immediately able to start providing service for the entity being backed up without the need for initialization activity, and will contain the same information as the entity being backed up. The value 'coldStandy(3)' means the entity is not providing service, and will be able to start providing service for an entity (possibly one from a set) being backed up, and will require some initialization activity. The value 'providingService(4)' means the entity is providing service. The value 'providingSharedService(5)' means the entity is providing service that is summed with the service provided by other entities." REFERENCE "ITU Recommendation X.731, 'Information Technology - Open Systems Interconnection - System Management: State Management Function', 1992" SYNTAX INTEGER { notAvailable(1), hotStandby(2), coldStandby(3), providingService(4), providingSharedService(5) } And a replacement for entStateStandby: entStateStandby OBJECT-TYPE SYNTAX StandbyStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The standby state for this entity. A value of 'notAvailable' means that this entity is unable to determine standby state. Some entities will exhibit only a subset of the remaining standby state values. If this entity cannot operate in a standby role, then the value with always be 'providingService'." ::= { entStateEntry 6 } >Date: Thu, 12 Feb 2004 23:41:02 -0800 >To: "Sharon Chisholm" , entmib@ietf.org >From: "David T. Perkins" >Subject: Standby > >HI, > >"Standby status" items should be renamed to "standby state" to be >consistent with the other naming of other items in the MIB module. >(Items are "state" when value is an enumerated int, and "status" when >the value is a bit string.) > >There is one important value missing from the enums for standby. It is >the one that means that the service output is combined with other >entities. This is commonly found with power supplies where the output >is "summed". > >Section 2.2 is incorrect. It implies that by reading the value of >entStandbyStatus for all entities, then entities can be classified as >redundant (or protected). This is not true. Say that there are two >entities that are identical and provide a "protected" service. At any >time, only one is providing service, and the other is standing by >protecting the other. A "protection switch" causes the roles to change >(that is the one providing service will switch to standing by, and the >one standing by will start to providing service). > >In general, this MIB module does not provide enough information to >determine 1) which entities are protected, 2) the relationship between >the entities that are protected and the entities providing protection. > >Regards, >/david t. perkins /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 17:06:29 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 RAA10043 for ; Fri, 13 Feb 2004 17:06:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlRi-0001N7-9j for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 17:06:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DM61iI005256 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 17:06:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlRh-0001Mg-S4; Fri, 13 Feb 2004 17:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlR2-0001Ll-Kb for entmib@optimus.ietf.org; Fri, 13 Feb 2004 17:05:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09967 for ; Fri, 13 Feb 2004 17:05:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArlR0-0002Cz-00 for entmib@ietf.org; Fri, 13 Feb 2004 17:05:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArlQ3-00027z-00 for entmib@ietf.org; Fri, 13 Feb 2004 17:04:20 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ArlPO-0001ym-00 for entmib@ietf.org; Fri, 13 Feb 2004 17:03:38 -0500 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 i1DM37n29295 for ; Fri, 13 Feb 2004 17:03:07 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8RC7>; Fri, 13 Feb 2004 17:03:08 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A711B@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 13 Feb 2004 17:03:07 -0500 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 Subject: [Entmib] RE: More on Standby #322 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 This and your email titled "Standby" are being tracked as issue #322. I think you might be reading too much into the connection between state, status and their data type. That was certainly never done intentionally on my part and the OSI thing is a status. I'm fine with adding this additional enumeration if there are no objections. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 3:04 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: More on Standby HI, Here is a replacement for TC StandbyStatus: StandbyState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION " Represents the possible values of standby state. The value 'notAvailable(1)' means that no information is available on the standby state for the entity. The value 'hotStandby(2)' means the entity is not providing service, and will be immediately able to start providing service for the entity being backed up without the need for initialization activity, and will contain the same information as the entity being backed up. The value 'coldStandy(3)' means the entity is not providing service, and will be able to start providing service for an entity (possibly one from a set) being backed up, and will require some initialization activity. The value 'providingService(4)' means the entity is providing service. The value 'providingSharedService(5)' means the entity is providing service that is summed with the service provided by other entities." REFERENCE "ITU Recommendation X.731, 'Information Technology - Open Systems Interconnection - System Management: State Management Function', 1992" SYNTAX INTEGER { notAvailable(1), hotStandby(2), coldStandby(3), providingService(4), providingSharedService(5) } And a replacement for entStateStandby: entStateStandby OBJECT-TYPE SYNTAX StandbyStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The standby state for this entity. A value of 'notAvailable' means that this entity is unable to determine standby state. Some entities will exhibit only a subset of the remaining standby state values. If this entity cannot operate in a standby role, then the value with always be 'providingService'." ::= { entStateEntry 6 } >Date: Thu, 12 Feb 2004 23:41:02 -0800 >To: "Sharon Chisholm" , entmib@ietf.org >From: "David T. Perkins" >Subject: Standby > >HI, > >"Standby status" items should be renamed to "standby state" to be >consistent with the other naming of other items in the MIB module. >(Items are "state" when value is an enumerated int, and "status" when >the value is a bit string.) > >There is one important value missing from the enums for standby. It is >the one that means that the service output is combined with other >entities. This is commonly found with power supplies where the output >is "summed". > >Section 2.2 is incorrect. It implies that by reading the value of >entStandbyStatus for all entities, then entities can be classified as >redundant (or protected). This is not true. Say that there are two >entities that are identical and provide a "protected" service. At any >time, only one is providing service, and the other is standing by >protecting the other. A "protection switch" causes the roles to change >(that is the one providing service will switch to standing by, and the >one standing by will start to providing service). > >In general, this MIB module does not provide enough information to >determine 1) which entities are protected, 2) the relationship between >the entities that are protected and the entities providing protection. > >Regards, >/david t. perkins /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 17:07:27 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 RAA10180 for ; Fri, 13 Feb 2004 17:07:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlSe-0001gD-IY; Fri, 13 Feb 2004 17:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlS6-0001WD-9S for entmib@optimus.ietf.org; Fri, 13 Feb 2004 17:06:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10007 for ; Fri, 13 Feb 2004 17:06:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArlS4-0002L4-00 for entmib@ietf.org; Fri, 13 Feb 2004 17:06:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArlR6-0002Du-00 for entmib@ietf.org; Fri, 13 Feb 2004 17:05:24 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArlQM-000244-00 for entmib@ietf.org; Fri, 13 Feb 2004 17:04:38 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1DM42S14741 for ; Fri, 13 Feb 2004 17:04:02 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8RDJ>; Fri, 13 Feb 2004 17:04:03 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A711D@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 13 Feb 2004 17:04:01 -0500 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 Subject: [Entmib] RE: More on Standby #332 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: , Make that 332 -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Friday, February 13, 2004 5:03 PM To: 'entmib@ietf.org' Subject: RE: More on Standby #322 Hi This and your email titled "Standby" are being tracked as issue #322. I think you might be reading too much into the connection between state, status and their data type. That was certainly never done intentionally on my part and the OSI thing is a status. I'm fine with adding this additional enumeration if there are no objections. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 3:04 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: More on Standby HI, Here is a replacement for TC StandbyStatus: StandbyState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION " Represents the possible values of standby state. The value 'notAvailable(1)' means that no information is available on the standby state for the entity. The value 'hotStandby(2)' means the entity is not providing service, and will be immediately able to start providing service for the entity being backed up without the need for initialization activity, and will contain the same information as the entity being backed up. The value 'coldStandy(3)' means the entity is not providing service, and will be able to start providing service for an entity (possibly one from a set) being backed up, and will require some initialization activity. The value 'providingService(4)' means the entity is providing service. The value 'providingSharedService(5)' means the entity is providing service that is summed with the service provided by other entities." REFERENCE "ITU Recommendation X.731, 'Information Technology - Open Systems Interconnection - System Management: State Management Function', 1992" SYNTAX INTEGER { notAvailable(1), hotStandby(2), coldStandby(3), providingService(4), providingSharedService(5) } And a replacement for entStateStandby: entStateStandby OBJECT-TYPE SYNTAX StandbyStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The standby state for this entity. A value of 'notAvailable' means that this entity is unable to determine standby state. Some entities will exhibit only a subset of the remaining standby state values. If this entity cannot operate in a standby role, then the value with always be 'providingService'." ::= { entStateEntry 6 } >Date: Thu, 12 Feb 2004 23:41:02 -0800 >To: "Sharon Chisholm" , entmib@ietf.org >From: "David T. Perkins" >Subject: Standby > >HI, > >"Standby status" items should be renamed to "standby state" to be >consistent with the other naming of other items in the MIB module. >(Items are "state" when value is an enumerated int, and "status" when >the value is a bit string.) > >There is one important value missing from the enums for standby. It is >the one that means that the service output is combined with other >entities. This is commonly found with power supplies where the output >is "summed". > >Section 2.2 is incorrect. It implies that by reading the value of >entStandbyStatus for all entities, then entities can be classified as >redundant (or protected). This is not true. Say that there are two >entities that are identical and provide a "protected" service. At any >time, only one is providing service, and the other is standing by >protecting the other. A "protection switch" causes the roles to change >(that is the one providing service will switch to standing by, and the >one standing by will start to providing service). > >In general, this MIB module does not provide enough information to >determine 1) which entities are protected, 2) the relationship between >the entities that are protected and the entities providing protection. > >Regards, >/david t. perkins /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 17:23:38 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 QAA06996 for ; Fri, 13 Feb 2004 16:36:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arkyh-0006bh-HM for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 16:36:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DLa3tp025385 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 16:36:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arkyf-0006aZ-2q; Fri, 13 Feb 2004 16:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkyB-0006Zg-Ek for entmib@optimus.ietf.org; Fri, 13 Feb 2004 16:35:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06854 for ; Fri, 13 Feb 2004 16:35:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arky9-00066U-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:35:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arkvk-0005YJ-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:33:01 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Arktf-00051J-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:30:52 -0500 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 i1DLUKn18225 for ; Fri, 13 Feb 2004 16:30:20 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8Q4P>; Fri, 13 Feb 2004 16:30:21 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A70D9@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #328] AutoReply: Containment Hierach an d entPhysical Containedin Date: Fri, 13 Feb 2004 16:30:13 -0500 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 Ok. I'll add a section that defines containment hierarchy and be done with it. Or perhaps there is something in the Entity MIB I can point at. While a containment hierarchy is transitive, I think when we are talking about the states it can't really be for two reasons - Usage definitely can't be transitive - I think transitive starts getting into computed states, which we have defined out of scope. Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Friday, February 13, 2004 8:35 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #328] AutoReply: Containment Hierach and entPhysical Containedin On Thu, Feb 12, 2004 at 01:44:44PM -0500, Sharon Chisholm wrote: > The following is the proposed resolution to entstate-328. The issue > will be considered closed pending the proposed edit being done. > > In the various object definitions replace phrases like > > "as defined by a value of > entPhysicalContainedIn that references this entity" > > With one like > > "as defined by the entPhysicalContainedIn object." So this is not generally transitive? I like Dave Perkin's suggestion on this issue. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 17:53:38 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 RAA10181 for ; Fri, 13 Feb 2004 17:07:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlSf-0001gi-1Y for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 17:07:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DM70Z0006472 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 17:07:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlSe-0001gD-IY; Fri, 13 Feb 2004 17:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlS6-0001WD-9S for entmib@optimus.ietf.org; Fri, 13 Feb 2004 17:06:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10007 for ; Fri, 13 Feb 2004 17:06:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArlS4-0002L4-00 for entmib@ietf.org; Fri, 13 Feb 2004 17:06:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArlR6-0002Du-00 for entmib@ietf.org; Fri, 13 Feb 2004 17:05:24 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ArlQM-000244-00 for entmib@ietf.org; Fri, 13 Feb 2004 17:04:38 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1DM42S14741 for ; Fri, 13 Feb 2004 17:04:02 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8RDJ>; Fri, 13 Feb 2004 17:04:03 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A711D@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Fri, 13 Feb 2004 17:04:01 -0500 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 Subject: [Entmib] RE: More on Standby #332 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: , Make that 332 -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Friday, February 13, 2004 5:03 PM To: 'entmib@ietf.org' Subject: RE: More on Standby #322 Hi This and your email titled "Standby" are being tracked as issue #322. I think you might be reading too much into the connection between state, status and their data type. That was certainly never done intentionally on my part and the OSI thing is a status. I'm fine with adding this additional enumeration if there are no objections. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 3:04 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: More on Standby HI, Here is a replacement for TC StandbyStatus: StandbyState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION " Represents the possible values of standby state. The value 'notAvailable(1)' means that no information is available on the standby state for the entity. The value 'hotStandby(2)' means the entity is not providing service, and will be immediately able to start providing service for the entity being backed up without the need for initialization activity, and will contain the same information as the entity being backed up. The value 'coldStandy(3)' means the entity is not providing service, and will be able to start providing service for an entity (possibly one from a set) being backed up, and will require some initialization activity. The value 'providingService(4)' means the entity is providing service. The value 'providingSharedService(5)' means the entity is providing service that is summed with the service provided by other entities." REFERENCE "ITU Recommendation X.731, 'Information Technology - Open Systems Interconnection - System Management: State Management Function', 1992" SYNTAX INTEGER { notAvailable(1), hotStandby(2), coldStandby(3), providingService(4), providingSharedService(5) } And a replacement for entStateStandby: entStateStandby OBJECT-TYPE SYNTAX StandbyStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The standby state for this entity. A value of 'notAvailable' means that this entity is unable to determine standby state. Some entities will exhibit only a subset of the remaining standby state values. If this entity cannot operate in a standby role, then the value with always be 'providingService'." ::= { entStateEntry 6 } >Date: Thu, 12 Feb 2004 23:41:02 -0800 >To: "Sharon Chisholm" , entmib@ietf.org >From: "David T. Perkins" >Subject: Standby > >HI, > >"Standby status" items should be renamed to "standby state" to be >consistent with the other naming of other items in the MIB module. >(Items are "state" when value is an enumerated int, and "status" when >the value is a bit string.) > >There is one important value missing from the enums for standby. It is >the one that means that the service output is combined with other >entities. This is commonly found with power supplies where the output >is "summed". > >Section 2.2 is incorrect. It implies that by reading the value of >entStandbyStatus for all entities, then entities can be classified as >redundant (or protected). This is not true. Say that there are two >entities that are identical and provide a "protected" service. At any >time, only one is providing service, and the other is standing by >protecting the other. A "protection switch" causes the roles to change >(that is the one providing service will switch to standing by, and the >one standing by will start to providing service). > >In general, this MIB module does not provide enough information to >determine 1) which entities are protected, 2) the relationship between >the entities that are protected and the entities providing protection. > >Regards, >/david t. perkins /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Feb 13 17:54: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 RAA12303 for ; Fri, 13 Feb 2004 17:54:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmC9-0004tU-0B; Fri, 13 Feb 2004 17:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmBX-0004rr-KR for entmib@optimus.ietf.org; Fri, 13 Feb 2004 17:53:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12235 for ; Fri, 13 Feb 2004 17:53:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArmBU-0005yR-00 for entmib@ietf.org; Fri, 13 Feb 2004 17:53:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArmAf-0005tq-00 for entmib@ietf.org; Fri, 13 Feb 2004 17:52:29 -0500 Received: from g46ca.g.pppool.de ([80.185.70.202] helo=james.eecs.iu-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 1Arm9s-0005oT-00 for entmib@ietf.org; Fri, 13 Feb 2004 17:51:44 -0500 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 7784B8406; Fri, 13 Feb 2004 23:51:34 +0100 (CET) Date: Fri, 13 Feb 2004 23:51:34 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #330] AutoReply: Notification Varbinds Message-ID: <20040213225134.GB1403@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , entmib@ietf.org References: <3549C09B853DD5119B540002A52CDD340A2A7108@zcard0ka.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3549C09B853DD5119B540002A52CDD340A2A7108@zcard0ka.ca.nortel.com> User-Agent: Mutt/1.5.5.1+cvs20040105i 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=none 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: , On Fri, Feb 13, 2004 at 04:53:02PM -0500, Sharon Chisholm wrote: > The following is the proposed resolution to entstate-330. The issue > will be considered closed pending the proposed edit being done. > > In the description to entStateOperEnabled and entStateOperDisabled add the > following text > > "The entStateAdmin and entStateAlarm varbinds may examined to find out > additional information on the administrative state at the time of the > operation state change as well to find out whether there were any known > alarms against the entity at that time." The text is OK and does not hurt, but you did not answer my question. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Feb 13 17:54: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 RAA12308 for ; Fri, 13 Feb 2004 17:54:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmCA-0004uL-7e for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 17:54:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DMs2tv018853 for entmib-archive@odin.ietf.org; Fri, 13 Feb 2004 17:54:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmC9-0004tU-0B; Fri, 13 Feb 2004 17:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmBX-0004rr-KR for entmib@optimus.ietf.org; Fri, 13 Feb 2004 17:53:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12235 for ; Fri, 13 Feb 2004 17:53:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArmBU-0005yR-00 for entmib@ietf.org; Fri, 13 Feb 2004 17:53:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArmAf-0005tq-00 for entmib@ietf.org; Fri, 13 Feb 2004 17:52:29 -0500 Received: from g46ca.g.pppool.de ([80.185.70.202] helo=james.eecs.iu-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 1Arm9s-0005oT-00 for entmib@ietf.org; Fri, 13 Feb 2004 17:51:44 -0500 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 7784B8406; Fri, 13 Feb 2004 23:51:34 +0100 (CET) Date: Fri, 13 Feb 2004 23:51:34 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #330] AutoReply: Notification Varbinds Message-ID: <20040213225134.GB1403@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , entmib@ietf.org References: <3549C09B853DD5119B540002A52CDD340A2A7108@zcard0ka.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3549C09B853DD5119B540002A52CDD340A2A7108@zcard0ka.ca.nortel.com> User-Agent: Mutt/1.5.5.1+cvs20040105i 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=none 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: , On Fri, Feb 13, 2004 at 04:53:02PM -0500, Sharon Chisholm wrote: > The following is the proposed resolution to entstate-330. The issue > will be considered closed pending the proposed edit being done. > > In the description to entStateOperEnabled and entStateOperDisabled add the > following text > > "The entStateAdmin and entStateAlarm varbinds may examined to find out > additional information on the administrative state at the time of the > operation state change as well to find out whether there were any known > alarms against the entity at that time." The text is OK and does not hurt, but you did not answer my question. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Sun Feb 15 13:55:30 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 NAA19936 for ; Sun, 15 Feb 2004 13:55:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsRPy-0000hO-EA for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 13:55:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FIt2IW002674 for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 13:55:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsRPy-0000h1-5S; Sun, 15 Feb 2004 13:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsRPf-0000gO-By for entmib@optimus.ietf.org; Sun, 15 Feb 2004 13:54:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19929 for ; Sun, 15 Feb 2004 13:54:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsRPd-00036J-00 for entmib@ietf.org; Sun, 15 Feb 2004 13:54:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsROe-00033U-00 for entmib@ietf.org; Sun, 15 Feb 2004 13:53:40 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AsRNu-0002y8-00 for entmib@ietf.org; Sun, 15 Feb 2004 13:52:54 -0500 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 i1FIqHg23896 for ; Sun, 15 Feb 2004 13:52:17 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8YH2>; Sun, 15 Feb 2004 13:52:18 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7272@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Sun, 15 Feb 2004 13:52:17 -0500 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 Subject: [Entmib] FW: [psg.com #334] AutoReply: Table, Index Descriptions 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: , The following is the proposed resolution to entstate-334. The issue will be considered closed pending the proposed edit being done. In the description for entStateTable replace "A table of information about state/status of entities. This is a sparse augment of the entPhysicalTable. " With "A table of information about state/status of entities. This is a sparse augment of the entPhysicalTable. Entries appear in this table for values of entPhysicalClass [RFC2737] that in this implementation are able to report any of the state or status stored in this table. " In the description for entStateEntry replace "State information about this entity." With "State information about this physical entity." Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Friday, February 13, 2004 12:19 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #334] AutoReply: Table, Index Descriptions ------------------------------------------------------------------------- David T. Perkins [dperkins@dsperkins.com] "The SMI requires that the DESCRIPTION for the row of a table describe the index item is that item is not a column in the table. And the DESCRIPTION clause for entStateEntry does not provide the needed info. In general, why is there a "sparse relationship". When should state be provided and when should it not?" _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Sun Feb 15 13:55:30 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 NAA19934 for ; Sun, 15 Feb 2004 13:55:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsRPy-0000h1-5S; Sun, 15 Feb 2004 13:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsRPf-0000gO-By for entmib@optimus.ietf.org; Sun, 15 Feb 2004 13:54:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19929 for ; Sun, 15 Feb 2004 13:54:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsRPd-00036J-00 for entmib@ietf.org; Sun, 15 Feb 2004 13:54:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsROe-00033U-00 for entmib@ietf.org; Sun, 15 Feb 2004 13:53:40 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AsRNu-0002y8-00 for entmib@ietf.org; Sun, 15 Feb 2004 13:52:54 -0500 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 i1FIqHg23896 for ; Sun, 15 Feb 2004 13:52:17 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8YH2>; Sun, 15 Feb 2004 13:52:18 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7272@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Sun, 15 Feb 2004 13:52:17 -0500 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 Subject: [Entmib] FW: [psg.com #334] AutoReply: Table, Index Descriptions 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: , The following is the proposed resolution to entstate-334. The issue will be considered closed pending the proposed edit being done. In the description for entStateTable replace "A table of information about state/status of entities. This is a sparse augment of the entPhysicalTable. " With "A table of information about state/status of entities. This is a sparse augment of the entPhysicalTable. Entries appear in this table for values of entPhysicalClass [RFC2737] that in this implementation are able to report any of the state or status stored in this table. " In the description for entStateEntry replace "State information about this entity." With "State information about this physical entity." Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Friday, February 13, 2004 12:19 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #334] AutoReply: Table, Index Descriptions ------------------------------------------------------------------------- David T. Perkins [dperkins@dsperkins.com] "The SMI requires that the DESCRIPTION for the row of a table describe the index item is that item is not a column in the table. And the DESCRIPTION clause for entStateEntry does not provide the needed info. In general, why is there a "sparse relationship". When should state be provided and when should it not?" _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Sun Feb 15 14:00:33 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 OAA20107 for ; Sun, 15 Feb 2004 14:00:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsRUq-0000rY-OU; Sun, 15 Feb 2004 14:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsRUZ-0000q6-Aw for entmib@optimus.ietf.org; Sun, 15 Feb 2004 13:59:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20076 for ; Sun, 15 Feb 2004 13:59:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsRUW-0003Ob-00 for entmib@ietf.org; Sun, 15 Feb 2004 13:59:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsRTd-0003LC-00 for entmib@ietf.org; Sun, 15 Feb 2004 13:58:50 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AsRTJ-0003H4-00 for entmib@ietf.org; Sun, 15 Feb 2004 13:58:29 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1FIvwn02058 for ; Sun, 15 Feb 2004 13:57:58 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8YH3>; Sun, 15 Feb 2004 13:57:59 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7273@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Sun, 15 Feb 2004 13:57:58 -0500 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 Subject: [Entmib] FW: [psg.com #333] AutoReply: Relationship with Alarm MIB 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: , The following is the proposed resolution to entstate-333. The issue will be considered closed pending the proposed edit being done. In section 3.2 add the following text: "Alternatively, if the alarmActiveTable is queried first and an active alarm with a value of alarmActiveResourceId that match this entPhysicalIndex is found, then entStateAlarm can be used to quickly determine if there are additional active alarms against this physical entity." Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Friday, February 13, 2004 12:17 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #333] AutoReply: Relationship with Alarm MIB ------------------------------------------------------------------------- David T. Perkins [dperkins@dsperkins.com] "The entity state MIB document should have proceeded the Alarm MIB document. Thus, section 3.2 is backwards." _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Sun Feb 15 14:00: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 OAA20124 for ; Sun, 15 Feb 2004 14:00:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsRUs-0000sO-A3 for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 14:00:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FJ05NG003343 for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 14:00:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsRUq-0000rY-OU; Sun, 15 Feb 2004 14:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsRUZ-0000q6-Aw for entmib@optimus.ietf.org; Sun, 15 Feb 2004 13:59:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20076 for ; Sun, 15 Feb 2004 13:59:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsRUW-0003Ob-00 for entmib@ietf.org; Sun, 15 Feb 2004 13:59:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsRTd-0003LC-00 for entmib@ietf.org; Sun, 15 Feb 2004 13:58:50 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AsRTJ-0003H4-00 for entmib@ietf.org; Sun, 15 Feb 2004 13:58:29 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1FIvwn02058 for ; Sun, 15 Feb 2004 13:57:58 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8YH3>; Sun, 15 Feb 2004 13:57:59 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7273@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Sun, 15 Feb 2004 13:57:58 -0500 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 Subject: [Entmib] FW: [psg.com #333] AutoReply: Relationship with Alarm MIB 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: , The following is the proposed resolution to entstate-333. The issue will be considered closed pending the proposed edit being done. In section 3.2 add the following text: "Alternatively, if the alarmActiveTable is queried first and an active alarm with a value of alarmActiveResourceId that match this entPhysicalIndex is found, then entStateAlarm can be used to quickly determine if there are additional active alarms against this physical entity." Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Friday, February 13, 2004 12:17 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #333] AutoReply: Relationship with Alarm MIB ------------------------------------------------------------------------- David T. Perkins [dperkins@dsperkins.com] "The entity state MIB document should have proceeded the Alarm MIB document. Thus, section 3.2 is backwards." _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Sun Feb 15 14:14:29 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 OAA20373 for ; Sun, 15 Feb 2004 14:14:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsRiK-0001Yd-Nl; Sun, 15 Feb 2004 14:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsRi2-0001YK-3y for entmib@optimus.ietf.org; Sun, 15 Feb 2004 14:13:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20358 for ; Sun, 15 Feb 2004 14:13:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsRhz-00045W-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:13:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsRh3-00042i-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:12:42 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AsRgD-0003xB-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:11:49 -0500 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 i1FJBIg25553 for ; Sun, 15 Feb 2004 14:11:18 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8YJA>; Sun, 15 Feb 2004 14:11:19 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7274@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Sun, 15 Feb 2004 14:11:17 -0500 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 Subject: [Entmib] FW: [psg.com #332] AutoReply: More Standby State/Status 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: , The following is the proposed resolution to entstate-332. The issue will be considered closed pending the proposed edit being done. [Note that this text may be affected by the resolution of other issues] In the description of StandybyStatus add " A value 'providingSharedService' means the entity is providing service that is summed with the service provided by other entities." And add the following enumeration: " providingSharedService (5) " In the description to entStateStandby replace " If this entity cannot operate in a standby role, the value of this object will always be 'providingService'." Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Friday, February 13, 2004 12:13 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #332] AutoReply: More Standby State/Status Issues ------------------------------------------------------------------------- David T. Perkins [dperkins@dsperkins.com] ""Standby status" items should be renamed to "standby state" to be consistent with the other naming of other items in the MIB module. (Items are "state" when value is an enumerated int, and "status" when the value is a bit string.) There is one important value missing from the enums for standby. It is the one that means that the service output is combined with other entities. This is commonly found with power supplies where the output is "summed". Section 2.2 is incorrect. It implies that by reading the value of entStandbyStatus for all entities, then entities can be classified as redundant (or protected). This is not true. Say that there are two entities that are identical and provide a "protected" service. At any time, only one is providing service, and the other is standing by protecting the other. A "protection switch" causes the roles to change (that is the one providing service will switch to standing by, and the one standing by will start to providing service). In general, this MIB module does not provide enough information to determine 1) which entities are protected, 2) the relationship between the entities that are protected and the entities providing protection. " David T. Perkins [dperkins@dsperkins.com] "Here is a replacement for TC StandbyStatus: StandbyState ::= TEXTUAL- CONVENTION STATUS current DESCRIPTION " Represents the possible values of standby state. The value 'notAvailable(1)' means that no information is available on the standby state for the entity. The value 'hotStandby(2)' means the entity is not providing service, and will be immediately able to start providing service for the entity being backed up without the need for initialization activity, and will contain the same information as the entity being backed up. The value 'coldStandy(3)' means the entity is not providing service, and will be able to start providing service for an entity (possibly one from a set) being backed up, and will require some initialization activity. The value 'providingService(4)' means the entity is providing service. The value 'providingSharedService(5)' means the entity is providing service that is summed with the service provided by other entities." REFERENCE "ITU Recommendation X.731, 'Information Technology - Open Systems Interconnection - System Management: State Management Function', 1992" SYNTAX INTEGER { notAvailable(1), hotStandby(2), coldStandby(3), providingService(4), providingSharedService (5) } And a replacement for entStateStandby: entStateStandby OBJECT-TYPE SYNTAX StandbyStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The standby state for this entity. A value of 'notAvailable' means that this entity is unable to determine standby state. Some entities will exhibit only a subset of the remaining standby state values. If this entity cannot operate in a standby role, then the value with always be 'providingService'." ::= { entStateEntry 6 } " _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Sun Feb 15 14:24: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 OAA20618 for ; Sun, 15 Feb 2004 14:24:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsRs0-0001zg-EI; Sun, 15 Feb 2004 14:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsRri-0001zP-SU for entmib@optimus.ietf.org; Sun, 15 Feb 2004 14:23:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20614 for ; Sun, 15 Feb 2004 14:23:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsRrg-0004er-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:23:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsRql-0004cD-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:22:44 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AsRqc-0004ZP-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:22:34 -0500 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 i1FJM3g25924 for ; Sun, 15 Feb 2004 14:22:03 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8YJ9>; Sun, 15 Feb 2004 14:22:04 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7275@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #330] AutoReply: Notification Varbinds Date: Sun, 15 Feb 2004 14:22:02 -0500 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: , The following is the proposed resolution to entstate-330. The issue will be considered closed pending the proposed edit being done. [Note: I'm trying to answer the question without enforcing a particular operational model on the management application. I don't think this is the right place to do that.] In the description to entStateOperDisabled add the following text "The entStateAdmin and entStateAlarm varbinds may be examined to find out additional information on the administrative state at the time of the operation state change as well to find out whether there were any known alarms against the entity at that time that may explain why the physical entity has become operationally disabled. " In the description to entStateOperEnabled add the following text "The entStateAdmin and entStateAlarm varbinds may be examined to find out additional information on the administrative state at the time of the operation state change as well to find out whether there were any known alarms against the entity at that time that may have affect on the physical entity's ability to stay operationally enabled." Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Friday, February 13, 2004 5:52 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #330] AutoReply: Notification Varbinds On Fri, Feb 13, 2004 at 04:53:02PM -0500, Sharon Chisholm wrote: > The following is the proposed resolution to entstate-330. The issue > will be considered closed pending the proposed edit being done. > > In the description to entStateOperEnabled and entStateOperDisabled add > the following text > > "The entStateAdmin and entStateAlarm varbinds may examined to find out > additional information on the administrative state at the time of the > operation state change as well to find out whether there were any > known alarms against the entity at that time." The text is OK and does not hurt, but you did not answer my question. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Sun Feb 15 14:39:29 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 OAA20961 for ; Sun, 15 Feb 2004 14:39:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsS6X-0002li-D5; Sun, 15 Feb 2004 14:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsS6E-0002ik-DK for entmib@optimus.ietf.org; Sun, 15 Feb 2004 14:38:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20956 for ; Sun, 15 Feb 2004 14:38:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsS6B-0005OC-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:38:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsS5F-0005Lt-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:37:41 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AsS4x-0005JK-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:37:23 -0500 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 i1FJaqg26407 for ; Sun, 15 Feb 2004 14:36:52 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8YLB>; Sun, 15 Feb 2004 14:36:53 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7277@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #328] AutoReply: Containment Hierach an d entPhysical Containedin Date: Sun, 15 Feb 2004 14:36:50 -0500 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: , The following is the proposed resolution to entstate-328. The issue will be considered closed pending the proposed edit being done. In section 2.1, replace "Physical entities exist within a containment hierarchy. This raises" With "Physical entities exist within a containment hierarchy. Physical containment is defined by the entPhysicalContainedIn object[RFC2737]. This raises" And remove all explanations of what a physical hierarchy is from within the DESCRIPTION clauses. Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Friday, February 13, 2004 4:30 PM To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #328] AutoReply: Containment Hierach an d entPhysical Containedin Hi Ok. I'll add a section that defines containment hierarchy and be done with it. Or perhaps there is something in the Entity MIB I can point at. While a containment hierarchy is transitive, I think when we are talking about the states it can't really be for two reasons - Usage definitely can't be transitive - I think transitive starts getting into computed states, which we have defined out of scope. Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Friday, February 13, 2004 8:35 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #328] AutoReply: Containment Hierach and entPhysical Containedin On Thu, Feb 12, 2004 at 01:44:44PM -0500, Sharon Chisholm wrote: > The following is the proposed resolution to entstate-328. The issue > will be considered closed pending the proposed edit being done. > > In the various object definitions replace phrases like > > "as defined by a value of > entPhysicalContainedIn that references this entity" > > With one like > > "as defined by the entPhysicalContainedIn object." So this is not generally transitive? I like Dave Perkin's suggestion on this issue. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ 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 Feb 15 14:55:30 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 OAA21512 for ; Sun, 15 Feb 2004 14:55:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsSM2-0003GD-Vk for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 14:55:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FJt2Ah012521 for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 14:55:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsSM2-0003Fh-Kz; Sun, 15 Feb 2004 14:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsSL3-0003Ex-Bp for entmib@optimus.ietf.org; Sun, 15 Feb 2004 14:54:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21380 for ; Sun, 15 Feb 2004 14:53:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsSL0-0006R7-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:53:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsSKC-0006L1-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:53:09 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AsSJY-0006BH-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:52:28 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1FJpvn03772 for ; Sun, 15 Feb 2004 14:51:57 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8YMK>; Sun, 15 Feb 2004 14:51:58 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A727C@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues Date: Sun, 15 Feb 2004 14:51:56 -0500 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: , The following is the proposed resolution to entstate-310. The issue will be considered closed pending the proposed edit being done. In the description of AlarmStatus replace " "Represents the possible values of alarm status. When no bits of this attribute are set, then none of the status conditions described below are present. When the value of under repair is set, the resource is currently being repaired. When the value of 'critical' is set, one or more critical alarms are active against the resource. When the value of 'major' is set, one or more major alarms are active against the resource. When the value of 'minor' is set, one or more minor alarms are active against the resource. When the value of 'warning' is set, one or more warning alarms are active against the resource. When the value of 'indeterminate' is set, one or more alarms of indeterminate severity are active against the resource. When the value of 'alarmOutstanding' is set, one or more alarms is active against the resource. The fault may or may not be disabling. " With " "Represents the possible values of alarm status. An Alarm [ALARM-MIB] is a persistent indication of an error or warning condition. When no bits of this attribute are set, then none of the status conditions described below are present. When the value of under repair is set, the resource is currently being repaired, which depending on the implementation, may make the other values in this bit string unreliable. When the value of 'critical' is set, one or more critical alarms are active against the resource. When the value of 'major' is set, one or more major alarms are active against the resource. When the value of 'minor' is set, one or more minor alarms are active against the resource. When the value of 'warning' is set, one or more warning alarms are active against the resource. When the value of 'indeterminate' is set, one or more alarms whose of perceived severity cannot be determined are active against this resource. When the value of 'alarmOutstanding' is set, one or more alarms is active against the resource. The fault may or may not be disabling. This bit provides a high-level summary that can be used to determine whether or not to examine the rest of the values. " An explanation on the difference between raw and computed state, as defined in section 2.1 was previously provided in relation to the severity of alarms issue. No change appears to be necessary on that particular issue. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 12:51 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues HI, The Alarm Status (not state) brings up the unsettled definition of what is "an alarm" and what is "clearing an alarm". The definition of an alarm MUST be specified for the TC and object to be useful. Or another term must be used (and, of course, that term must be well defined). I suggest that the term "alarm" be replaced by "fault". And the following be used for the TC and object definitions: FaultStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The fault status, which is a bit string. When all the bits are zero, then no faults are present. The bit 'unavailable(0)' indicates that the fault status is unknown. When set, all bits other than 'underRepair(1)' must be zero. The 'underRepair(1)' indicates that the an item is under repair. The following bits are one when one or more faults of the perceived severity exist. The value is zero for a bit when there is no existing fault of the perceived severity. The bits and faults are: 'critical(2)' 'major(3)' 'minor(4)' 'warning(5)' 'indeterminate(6)' (the perceived severity cannot be determined) The entity may continue to operate while a fault condition exists." SYNTAX BITS { unavailable(0), underRepair(1), critical(2), major(3), minor(4), -- The following are not defined in X.733 warning(6), indeterminate(7) } entStateFault OBJECT-TYPE SYNTAX FaultStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The fault status for this entity. It does not include the faults raised on entities within its containment hierarchy. These are entities that specify this entity as the value for object entPhysicalContainedIn directly and indirectly." ::= { entStateEntry 5 } At 02:44 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-310. The issue >will be considered closed pending the proposed edit being done. > >In the description of AlarmStatus replace > >" When the > value of under repair is set, the resource is currently > being repaired." > >With > >" When the > value of under repair is set, the resource is currently > being repaired, which depending on the implementation, > may make the other values in this bit string unreliable." > > >And replace > >" > When the value of 'alarmOutstanding' is set, one or more > alarms is active against the resource. The fault may or may > not be disabling. " > >With > >" > When the value of 'alarmOutstanding' is set, one or more > alarms is active against the resource. The fault may or may > not be disabling. This bit provides a high-level summary that > can be used to determine whether or not to examine the rest of > the values." > > >An explanation on the difference between raw and computed state, as >defined in section 2.1 was previously provided in relation to the >severity of alarms issue. No change appears to be necessary on that >particular issue. > >Sharon > > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 2:58 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #310] AutoReply: Alarm State Issues > > > >----------------------------------------------------------------------- >-- >Keith McCloghrie [kzm@cisco.com] > >"> 'underRepair' is an operState, not an AlarmState. >> >> from what perspective are the alarms classified as >critical/major/minor/etc. >> e.g., does a particular fault have the same alarm status >in 'coldStandby' >> as it does in 'hotStandby' or in 'providingService' ?? (hint: the >answer >> is no!!). >" > > > >Juergen Schoenwaelder [j.schoenwaelder@iu-bremen.de] > >"6) AlarmStatus TC: I do not really understand the alarmOutStanding >bit. It seems like this is set whenever one of critical, major, minor, >warning and indeterminate is set. But if this is true, I think the bit >is not really terrible useful. > >Perhaps the bit has some other meaning. If so, please clarify." Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Sun Feb 15 15:04:29 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 OAA20375 for ; Sun, 15 Feb 2004 14:14:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsRiL-0001Z3-3B for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 14:14:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FJE1Y7006001 for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 14:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsRiK-0001Yd-Nl; Sun, 15 Feb 2004 14:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsRi2-0001YK-3y for entmib@optimus.ietf.org; Sun, 15 Feb 2004 14:13:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20358 for ; Sun, 15 Feb 2004 14:13:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsRhz-00045W-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:13:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsRh3-00042i-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:12:42 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AsRgD-0003xB-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:11:49 -0500 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 i1FJBIg25553 for ; Sun, 15 Feb 2004 14:11:18 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8YJA>; Sun, 15 Feb 2004 14:11:19 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7274@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Sun, 15 Feb 2004 14:11:17 -0500 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 Subject: [Entmib] FW: [psg.com #332] AutoReply: More Standby State/Status 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: , The following is the proposed resolution to entstate-332. The issue will be considered closed pending the proposed edit being done. [Note that this text may be affected by the resolution of other issues] In the description of StandybyStatus add " A value 'providingSharedService' means the entity is providing service that is summed with the service provided by other entities." And add the following enumeration: " providingSharedService (5) " In the description to entStateStandby replace " If this entity cannot operate in a standby role, the value of this object will always be 'providingService'." Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Friday, February 13, 2004 12:13 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #332] AutoReply: More Standby State/Status Issues ------------------------------------------------------------------------- David T. Perkins [dperkins@dsperkins.com] ""Standby status" items should be renamed to "standby state" to be consistent with the other naming of other items in the MIB module. (Items are "state" when value is an enumerated int, and "status" when the value is a bit string.) There is one important value missing from the enums for standby. It is the one that means that the service output is combined with other entities. This is commonly found with power supplies where the output is "summed". Section 2.2 is incorrect. It implies that by reading the value of entStandbyStatus for all entities, then entities can be classified as redundant (or protected). This is not true. Say that there are two entities that are identical and provide a "protected" service. At any time, only one is providing service, and the other is standing by protecting the other. A "protection switch" causes the roles to change (that is the one providing service will switch to standing by, and the one standing by will start to providing service). In general, this MIB module does not provide enough information to determine 1) which entities are protected, 2) the relationship between the entities that are protected and the entities providing protection. " David T. Perkins [dperkins@dsperkins.com] "Here is a replacement for TC StandbyStatus: StandbyState ::= TEXTUAL- CONVENTION STATUS current DESCRIPTION " Represents the possible values of standby state. The value 'notAvailable(1)' means that no information is available on the standby state for the entity. The value 'hotStandby(2)' means the entity is not providing service, and will be immediately able to start providing service for the entity being backed up without the need for initialization activity, and will contain the same information as the entity being backed up. The value 'coldStandy(3)' means the entity is not providing service, and will be able to start providing service for an entity (possibly one from a set) being backed up, and will require some initialization activity. The value 'providingService(4)' means the entity is providing service. The value 'providingSharedService(5)' means the entity is providing service that is summed with the service provided by other entities." REFERENCE "ITU Recommendation X.731, 'Information Technology - Open Systems Interconnection - System Management: State Management Function', 1992" SYNTAX INTEGER { notAvailable(1), hotStandby(2), coldStandby(3), providingService(4), providingSharedService (5) } And a replacement for entStateStandby: entStateStandby OBJECT-TYPE SYNTAX StandbyStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The standby state for this entity. A value of 'notAvailable' means that this entity is unable to determine standby state. Some entities will exhibit only a subset of the remaining standby state values. If this entity cannot operate in a standby role, then the value with always be 'providingService'." ::= { entStateEntry 6 } " _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Sun Feb 15 15:06:29 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 PAA21861 for ; Sun, 15 Feb 2004 15:06:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsSWf-0000h1-RD; Sun, 15 Feb 2004 15:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsSWM-0000Uf-4w for entmib@optimus.ietf.org; Sun, 15 Feb 2004 15:05:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21792 for ; Sun, 15 Feb 2004 15:05:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsSWJ-00071m-00 for entmib@ietf.org; Sun, 15 Feb 2004 15:05:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsSVL-0006zW-00 for entmib@ietf.org; Sun, 15 Feb 2004 15:04:40 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AsSUk-0006vL-00 for entmib@ietf.org; Sun, 15 Feb 2004 15:04:02 -0500 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 i1FK3Vg28217 for ; Sun, 15 Feb 2004 15:03:31 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8YNK>; Sun, 15 Feb 2004 15:03:32 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7282@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #332] AutoReply: More Standby State/Sta tus Issues Date: Sun, 15 Feb 2004 15:03:29 -0500 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 I'm going to object to my own proposed resolution. In going back though the issues list I note that adding an enumeration to support load sharing was already discussed by the working group and was tracked as issue #74. The decision was not the include it since ... "It seems that 'loadSharing' would be more of a specialization of 'providingSerice' than a peer concept. I propose not including it in this list. The question of adding another option to provide this sort of information was briefly discussed in the Vienna meeting and it was felt that our intention was to not provide a full set of objects to support redundancy. I propose we do not add this object at this time." Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Sunday, February 15, 2004 2:11 PM To: entmib@ietf.org Subject: [Entmib] FW: [psg.com #332] AutoReply: More Standby State/Status Issues The following is the proposed resolution to entstate-332. The issue will be considered closed pending the proposed edit being done. [Note that this text may be affected by the resolution of other issues] In the description of StandybyStatus add " A value 'providingSharedService' means the entity is providing service that is summed with the service provided by other entities." And add the following enumeration: " providingSharedService (5) " In the description to entStateStandby replace " If this entity cannot operate in a standby role, the value of this object will always be 'providingService'." Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Friday, February 13, 2004 12:13 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #332] AutoReply: More Standby State/Status Issues ------------------------------------------------------------------------- David T. Perkins [dperkins@dsperkins.com] ""Standby status" items should be renamed to "standby state" to be consistent with the other naming of other items in the MIB module. (Items are "state" when value is an enumerated int, and "status" when the value is a bit string.) There is one important value missing from the enums for standby. It is the one that means that the service output is combined with other entities. This is commonly found with power supplies where the output is "summed". Section 2.2 is incorrect. It implies that by reading the value of entStandbyStatus for all entities, then entities can be classified as redundant (or protected). This is not true. Say that there are two entities that are identical and provide a "protected" service. At any time, only one is providing service, and the other is standing by protecting the other. A "protection switch" causes the roles to change (that is the one providing service will switch to standing by, and the one standing by will start to providing service). In general, this MIB module does not provide enough information to determine 1) which entities are protected, 2) the relationship between the entities that are protected and the entities providing protection. " David T. Perkins [dperkins@dsperkins.com] "Here is a replacement for TC StandbyStatus: StandbyState ::= TEXTUAL- CONVENTION STATUS current DESCRIPTION " Represents the possible values of standby state. The value 'notAvailable(1)' means that no information is available on the standby state for the entity. The value 'hotStandby(2)' means the entity is not providing service, and will be immediately able to start providing service for the entity being backed up without the need for initialization activity, and will contain the same information as the entity being backed up. The value 'coldStandy(3)' means the entity is not providing service, and will be able to start providing service for an entity (possibly one from a set) being backed up, and will require some initialization activity. The value 'providingService(4)' means the entity is providing service. The value 'providingSharedService(5)' means the entity is providing service that is summed with the service provided by other entities." REFERENCE "ITU Recommendation X.731, 'Information Technology - Open Systems Interconnection - System Management: State Management Function', 1992" SYNTAX INTEGER { notAvailable(1), hotStandby(2), coldStandby(3), providingService(4), providingSharedService (5) } And a replacement for entStateStandby: entStateStandby OBJECT-TYPE SYNTAX StandbyStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The standby state for this entity. A value of 'notAvailable' means that this entity is unable to determine standby state. Some entities will exhibit only a subset of the remaining standby state values. If this entity cannot operate in a standby role, then the value with always be 'providingService'." ::= { entStateEntry 6 } " _______________________________________________ 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 Feb 15 15:06:29 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 PAA21863 for ; Sun, 15 Feb 2004 15:06:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsSWg-0000iE-FH for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 15:06:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FK62xn002678 for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 15:06:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsSWf-0000h1-RD; Sun, 15 Feb 2004 15:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsSWM-0000Uf-4w for entmib@optimus.ietf.org; Sun, 15 Feb 2004 15:05:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21792 for ; Sun, 15 Feb 2004 15:05:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsSWJ-00071m-00 for entmib@ietf.org; Sun, 15 Feb 2004 15:05:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsSVL-0006zW-00 for entmib@ietf.org; Sun, 15 Feb 2004 15:04:40 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AsSUk-0006vL-00 for entmib@ietf.org; Sun, 15 Feb 2004 15:04:02 -0500 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 i1FK3Vg28217 for ; Sun, 15 Feb 2004 15:03:31 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8YNK>; Sun, 15 Feb 2004 15:03:32 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7282@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #332] AutoReply: More Standby State/Sta tus Issues Date: Sun, 15 Feb 2004 15:03:29 -0500 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 I'm going to object to my own proposed resolution. In going back though the issues list I note that adding an enumeration to support load sharing was already discussed by the working group and was tracked as issue #74. The decision was not the include it since ... "It seems that 'loadSharing' would be more of a specialization of 'providingSerice' than a peer concept. I propose not including it in this list. The question of adding another option to provide this sort of information was briefly discussed in the Vienna meeting and it was felt that our intention was to not provide a full set of objects to support redundancy. I propose we do not add this object at this time." Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Sunday, February 15, 2004 2:11 PM To: entmib@ietf.org Subject: [Entmib] FW: [psg.com #332] AutoReply: More Standby State/Status Issues The following is the proposed resolution to entstate-332. The issue will be considered closed pending the proposed edit being done. [Note that this text may be affected by the resolution of other issues] In the description of StandybyStatus add " A value 'providingSharedService' means the entity is providing service that is summed with the service provided by other entities." And add the following enumeration: " providingSharedService (5) " In the description to entStateStandby replace " If this entity cannot operate in a standby role, the value of this object will always be 'providingService'." Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Friday, February 13, 2004 12:13 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #332] AutoReply: More Standby State/Status Issues ------------------------------------------------------------------------- David T. Perkins [dperkins@dsperkins.com] ""Standby status" items should be renamed to "standby state" to be consistent with the other naming of other items in the MIB module. (Items are "state" when value is an enumerated int, and "status" when the value is a bit string.) There is one important value missing from the enums for standby. It is the one that means that the service output is combined with other entities. This is commonly found with power supplies where the output is "summed". Section 2.2 is incorrect. It implies that by reading the value of entStandbyStatus for all entities, then entities can be classified as redundant (or protected). This is not true. Say that there are two entities that are identical and provide a "protected" service. At any time, only one is providing service, and the other is standing by protecting the other. A "protection switch" causes the roles to change (that is the one providing service will switch to standing by, and the one standing by will start to providing service). In general, this MIB module does not provide enough information to determine 1) which entities are protected, 2) the relationship between the entities that are protected and the entities providing protection. " David T. Perkins [dperkins@dsperkins.com] "Here is a replacement for TC StandbyStatus: StandbyState ::= TEXTUAL- CONVENTION STATUS current DESCRIPTION " Represents the possible values of standby state. The value 'notAvailable(1)' means that no information is available on the standby state for the entity. The value 'hotStandby(2)' means the entity is not providing service, and will be immediately able to start providing service for the entity being backed up without the need for initialization activity, and will contain the same information as the entity being backed up. The value 'coldStandy(3)' means the entity is not providing service, and will be able to start providing service for an entity (possibly one from a set) being backed up, and will require some initialization activity. The value 'providingService(4)' means the entity is providing service. The value 'providingSharedService(5)' means the entity is providing service that is summed with the service provided by other entities." REFERENCE "ITU Recommendation X.731, 'Information Technology - Open Systems Interconnection - System Management: State Management Function', 1992" SYNTAX INTEGER { notAvailable(1), hotStandby(2), coldStandby(3), providingService(4), providingSharedService (5) } And a replacement for entStateStandby: entStateStandby OBJECT-TYPE SYNTAX StandbyStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The standby state for this entity. A value of 'notAvailable' means that this entity is unable to determine standby state. Some entities will exhibit only a subset of the remaining standby state values. If this entity cannot operate in a standby role, then the value with always be 'providingService'." ::= { entStateEntry 6 } " _______________________________________________ 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 Sun Feb 15 15:09: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 PAA22108 for ; Sun, 15 Feb 2004 15:09:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsSZZ-0002Jb-G2; Sun, 15 Feb 2004 15:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsSZK-0002GF-G4 for entmib@optimus.ietf.org; Sun, 15 Feb 2004 15:08:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22041 for ; Sun, 15 Feb 2004 15:08:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsSZH-0007An-00 for entmib@ietf.org; Sun, 15 Feb 2004 15:08:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsSYK-00077q-00 for entmib@ietf.org; Sun, 15 Feb 2004 15:07:45 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AsSY3-00075A-00 for entmib@ietf.org; Sun, 15 Feb 2004 15:07:27 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1FK6un04614 for ; Sun, 15 Feb 2004 15:06:56 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8YN7>; Sun, 15 Feb 2004 15:06:57 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7283@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #332] AutoReply: More Standby State/Sta tus Issues Date: Sun, 15 Feb 2004 15:06:56 -0500 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: , The following is the proposed resolution to entstate-332. The issue will be considered closed pending the proposed edit being done. In the description to entStateStandby replace " If this entity cannot operate in a standby role, the value of this object will always be 'providingService'." Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Sunday, February 15, 2004 3:03 PM To: 'entmib@ietf.org' Subject: RE: [Entmib] FW: [psg.com #332] AutoReply: More Standby State/Status Issues Hi I'm going to object to my own proposed resolution. In going back though the issues list I note that adding an enumeration to support load sharing was already discussed by the working group and was tracked as issue #74. The decision was not the include it since ... "It seems that 'loadSharing' would be more of a specialization of 'providingSerice' than a peer concept. I propose not including it in this list. The question of adding another option to provide this sort of information was briefly discussed in the Vienna meeting and it was felt that our intention was to not provide a full set of objects to support redundancy. I propose we do not add this object at this time." Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Sunday, February 15, 2004 2:11 PM To: entmib@ietf.org Subject: [Entmib] FW: [psg.com #332] AutoReply: More Standby State/Status Issues The following is the proposed resolution to entstate-332. The issue will be considered closed pending the proposed edit being done. [Note that this text may be affected by the resolution of other issues] In the description of StandybyStatus add " A value 'providingSharedService' means the entity is providing service that is summed with the service provided by other entities." And add the following enumeration: " providingSharedService (5) " In the description to entStateStandby replace " If this entity cannot operate in a standby role, the value of this object will always be 'providingService'." Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Friday, February 13, 2004 12:13 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #332] AutoReply: More Standby State/Status Issues ------------------------------------------------------------------------- David T. Perkins [dperkins@dsperkins.com] ""Standby status" items should be renamed to "standby state" to be consistent with the other naming of other items in the MIB module. (Items are "state" when value is an enumerated int, and "status" when the value is a bit string.) There is one important value missing from the enums for standby. It is the one that means that the service output is combined with other entities. This is commonly found with power supplies where the output is "summed". Section 2.2 is incorrect. It implies that by reading the value of entStandbyStatus for all entities, then entities can be classified as redundant (or protected). This is not true. Say that there are two entities that are identical and provide a "protected" service. At any time, only one is providing service, and the other is standing by protecting the other. A "protection switch" causes the roles to change (that is the one providing service will switch to standing by, and the one standing by will start to providing service). In general, this MIB module does not provide enough information to determine 1) which entities are protected, 2) the relationship between the entities that are protected and the entities providing protection. " David T. Perkins [dperkins@dsperkins.com] "Here is a replacement for TC StandbyStatus: StandbyState ::= TEXTUAL- CONVENTION STATUS current DESCRIPTION " Represents the possible values of standby state. The value 'notAvailable(1)' means that no information is available on the standby state for the entity. The value 'hotStandby(2)' means the entity is not providing service, and will be immediately able to start providing service for the entity being backed up without the need for initialization activity, and will contain the same information as the entity being backed up. The value 'coldStandy(3)' means the entity is not providing service, and will be able to start providing service for an entity (possibly one from a set) being backed up, and will require some initialization activity. The value 'providingService(4)' means the entity is providing service. The value 'providingSharedService(5)' means the entity is providing service that is summed with the service provided by other entities." REFERENCE "ITU Recommendation X.731, 'Information Technology - Open Systems Interconnection - System Management: State Management Function', 1992" SYNTAX INTEGER { notAvailable(1), hotStandby(2), coldStandby(3), providingService(4), providingSharedService (5) } And a replacement for entStateStandby: entStateStandby OBJECT-TYPE SYNTAX StandbyStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The standby state for this entity. A value of 'notAvailable' means that this entity is unable to determine standby state. Some entities will exhibit only a subset of the remaining standby state values. If this entity cannot operate in a standby role, then the value with always be 'providingService'." ::= { entStateEntry 6 } " _______________________________________________ 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 Feb 15 15:29:29 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 OAA20963 for ; Sun, 15 Feb 2004 14:39:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsS6X-0002mB-Sq for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 14:39:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FJd1et010659 for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 14:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsS6X-0002li-D5; Sun, 15 Feb 2004 14:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsS6E-0002ik-DK for entmib@optimus.ietf.org; Sun, 15 Feb 2004 14:38:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20956 for ; Sun, 15 Feb 2004 14:38:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsS6B-0005OC-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:38:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsS5F-0005Lt-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:37:41 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AsS4x-0005JK-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:37:23 -0500 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 i1FJaqg26407 for ; Sun, 15 Feb 2004 14:36:52 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8YLB>; Sun, 15 Feb 2004 14:36:53 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7277@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #328] AutoReply: Containment Hierach an d entPhysical Containedin Date: Sun, 15 Feb 2004 14:36:50 -0500 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: , The following is the proposed resolution to entstate-328. The issue will be considered closed pending the proposed edit being done. In section 2.1, replace "Physical entities exist within a containment hierarchy. This raises" With "Physical entities exist within a containment hierarchy. Physical containment is defined by the entPhysicalContainedIn object[RFC2737]. This raises" And remove all explanations of what a physical hierarchy is from within the DESCRIPTION clauses. Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Friday, February 13, 2004 4:30 PM To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #328] AutoReply: Containment Hierach an d entPhysical Containedin Hi Ok. I'll add a section that defines containment hierarchy and be done with it. Or perhaps there is something in the Entity MIB I can point at. While a containment hierarchy is transitive, I think when we are talking about the states it can't really be for two reasons - Usage definitely can't be transitive - I think transitive starts getting into computed states, which we have defined out of scope. Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Friday, February 13, 2004 8:35 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #328] AutoReply: Containment Hierach and entPhysical Containedin On Thu, Feb 12, 2004 at 01:44:44PM -0500, Sharon Chisholm wrote: > The following is the proposed resolution to entstate-328. The issue > will be considered closed pending the proposed edit being done. > > In the various object definitions replace phrases like > > "as defined by a value of > entPhysicalContainedIn that references this entity" > > With one like > > "as defined by the entPhysicalContainedIn object." So this is not generally transitive? I like Dave Perkin's suggestion on this issue. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ 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 Sun Feb 15 15:44:29 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 OAA21510 for ; Sun, 15 Feb 2004 14:55:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsSM2-0003Fh-Kz; Sun, 15 Feb 2004 14:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsSL3-0003Ex-Bp for entmib@optimus.ietf.org; Sun, 15 Feb 2004 14:54:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21380 for ; Sun, 15 Feb 2004 14:53:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsSL0-0006R7-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:53:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsSKC-0006L1-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:53:09 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AsSJY-0006BH-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:52:28 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1FJpvn03772 for ; Sun, 15 Feb 2004 14:51:57 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8YMK>; Sun, 15 Feb 2004 14:51:58 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A727C@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues Date: Sun, 15 Feb 2004 14:51:56 -0500 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: , The following is the proposed resolution to entstate-310. The issue will be considered closed pending the proposed edit being done. In the description of AlarmStatus replace " "Represents the possible values of alarm status. When no bits of this attribute are set, then none of the status conditions described below are present. When the value of under repair is set, the resource is currently being repaired. When the value of 'critical' is set, one or more critical alarms are active against the resource. When the value of 'major' is set, one or more major alarms are active against the resource. When the value of 'minor' is set, one or more minor alarms are active against the resource. When the value of 'warning' is set, one or more warning alarms are active against the resource. When the value of 'indeterminate' is set, one or more alarms of indeterminate severity are active against the resource. When the value of 'alarmOutstanding' is set, one or more alarms is active against the resource. The fault may or may not be disabling. " With " "Represents the possible values of alarm status. An Alarm [ALARM-MIB] is a persistent indication of an error or warning condition. When no bits of this attribute are set, then none of the status conditions described below are present. When the value of under repair is set, the resource is currently being repaired, which depending on the implementation, may make the other values in this bit string unreliable. When the value of 'critical' is set, one or more critical alarms are active against the resource. When the value of 'major' is set, one or more major alarms are active against the resource. When the value of 'minor' is set, one or more minor alarms are active against the resource. When the value of 'warning' is set, one or more warning alarms are active against the resource. When the value of 'indeterminate' is set, one or more alarms whose of perceived severity cannot be determined are active against this resource. When the value of 'alarmOutstanding' is set, one or more alarms is active against the resource. The fault may or may not be disabling. This bit provides a high-level summary that can be used to determine whether or not to examine the rest of the values. " An explanation on the difference between raw and computed state, as defined in section 2.1 was previously provided in relation to the severity of alarms issue. No change appears to be necessary on that particular issue. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 12:51 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues HI, The Alarm Status (not state) brings up the unsettled definition of what is "an alarm" and what is "clearing an alarm". The definition of an alarm MUST be specified for the TC and object to be useful. Or another term must be used (and, of course, that term must be well defined). I suggest that the term "alarm" be replaced by "fault". And the following be used for the TC and object definitions: FaultStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The fault status, which is a bit string. When all the bits are zero, then no faults are present. The bit 'unavailable(0)' indicates that the fault status is unknown. When set, all bits other than 'underRepair(1)' must be zero. The 'underRepair(1)' indicates that the an item is under repair. The following bits are one when one or more faults of the perceived severity exist. The value is zero for a bit when there is no existing fault of the perceived severity. The bits and faults are: 'critical(2)' 'major(3)' 'minor(4)' 'warning(5)' 'indeterminate(6)' (the perceived severity cannot be determined) The entity may continue to operate while a fault condition exists." SYNTAX BITS { unavailable(0), underRepair(1), critical(2), major(3), minor(4), -- The following are not defined in X.733 warning(6), indeterminate(7) } entStateFault OBJECT-TYPE SYNTAX FaultStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The fault status for this entity. It does not include the faults raised on entities within its containment hierarchy. These are entities that specify this entity as the value for object entPhysicalContainedIn directly and indirectly." ::= { entStateEntry 5 } At 02:44 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-310. The issue >will be considered closed pending the proposed edit being done. > >In the description of AlarmStatus replace > >" When the > value of under repair is set, the resource is currently > being repaired." > >With > >" When the > value of under repair is set, the resource is currently > being repaired, which depending on the implementation, > may make the other values in this bit string unreliable." > > >And replace > >" > When the value of 'alarmOutstanding' is set, one or more > alarms is active against the resource. The fault may or may > not be disabling. " > >With > >" > When the value of 'alarmOutstanding' is set, one or more > alarms is active against the resource. The fault may or may > not be disabling. This bit provides a high-level summary that > can be used to determine whether or not to examine the rest of > the values." > > >An explanation on the difference between raw and computed state, as >defined in section 2.1 was previously provided in relation to the >severity of alarms issue. No change appears to be necessary on that >particular issue. > >Sharon > > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 2:58 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #310] AutoReply: Alarm State Issues > > > >----------------------------------------------------------------------- >-- >Keith McCloghrie [kzm@cisco.com] > >"> 'underRepair' is an operState, not an AlarmState. >> >> from what perspective are the alarms classified as >critical/major/minor/etc. >> e.g., does a particular fault have the same alarm status >in 'coldStandby' >> as it does in 'hotStandby' or in 'providingService' ?? (hint: the >answer >> is no!!). >" > > > >Juergen Schoenwaelder [j.schoenwaelder@iu-bremen.de] > >"6) AlarmStatus TC: I do not really understand the alarmOutStanding >bit. It seems like this is set whenever one of critical, major, minor, >warning and indeterminate is set. But if this is true, I think the bit >is not really terrible useful. > >Perhaps the bit has some other meaning. If so, please clarify." Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Sun Feb 15 15:59:29 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 PAA22110 for ; Sun, 15 Feb 2004 15:09:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsSZZ-0002K9-Md for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 15:09:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FK91E8008910 for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 15:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsSZZ-0002Jb-G2; Sun, 15 Feb 2004 15:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsSZK-0002GF-G4 for entmib@optimus.ietf.org; Sun, 15 Feb 2004 15:08:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22041 for ; Sun, 15 Feb 2004 15:08:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsSZH-0007An-00 for entmib@ietf.org; Sun, 15 Feb 2004 15:08:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsSYK-00077q-00 for entmib@ietf.org; Sun, 15 Feb 2004 15:07:45 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AsSY3-00075A-00 for entmib@ietf.org; Sun, 15 Feb 2004 15:07:27 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1FK6un04614 for ; Sun, 15 Feb 2004 15:06:56 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8YN7>; Sun, 15 Feb 2004 15:06:57 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7283@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #332] AutoReply: More Standby State/Sta tus Issues Date: Sun, 15 Feb 2004 15:06:56 -0500 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: , The following is the proposed resolution to entstate-332. The issue will be considered closed pending the proposed edit being done. In the description to entStateStandby replace " If this entity cannot operate in a standby role, the value of this object will always be 'providingService'." Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Sunday, February 15, 2004 3:03 PM To: 'entmib@ietf.org' Subject: RE: [Entmib] FW: [psg.com #332] AutoReply: More Standby State/Status Issues Hi I'm going to object to my own proposed resolution. In going back though the issues list I note that adding an enumeration to support load sharing was already discussed by the working group and was tracked as issue #74. The decision was not the include it since ... "It seems that 'loadSharing' would be more of a specialization of 'providingSerice' than a peer concept. I propose not including it in this list. The question of adding another option to provide this sort of information was briefly discussed in the Vienna meeting and it was felt that our intention was to not provide a full set of objects to support redundancy. I propose we do not add this object at this time." Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Sunday, February 15, 2004 2:11 PM To: entmib@ietf.org Subject: [Entmib] FW: [psg.com #332] AutoReply: More Standby State/Status Issues The following is the proposed resolution to entstate-332. The issue will be considered closed pending the proposed edit being done. [Note that this text may be affected by the resolution of other issues] In the description of StandybyStatus add " A value 'providingSharedService' means the entity is providing service that is summed with the service provided by other entities." And add the following enumeration: " providingSharedService (5) " In the description to entStateStandby replace " If this entity cannot operate in a standby role, the value of this object will always be 'providingService'." Sharon -----Original Message----- From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] Sent: Friday, February 13, 2004 12:13 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #332] AutoReply: More Standby State/Status Issues ------------------------------------------------------------------------- David T. Perkins [dperkins@dsperkins.com] ""Standby status" items should be renamed to "standby state" to be consistent with the other naming of other items in the MIB module. (Items are "state" when value is an enumerated int, and "status" when the value is a bit string.) There is one important value missing from the enums for standby. It is the one that means that the service output is combined with other entities. This is commonly found with power supplies where the output is "summed". Section 2.2 is incorrect. It implies that by reading the value of entStandbyStatus for all entities, then entities can be classified as redundant (or protected). This is not true. Say that there are two entities that are identical and provide a "protected" service. At any time, only one is providing service, and the other is standing by protecting the other. A "protection switch" causes the roles to change (that is the one providing service will switch to standing by, and the one standing by will start to providing service). In general, this MIB module does not provide enough information to determine 1) which entities are protected, 2) the relationship between the entities that are protected and the entities providing protection. " David T. Perkins [dperkins@dsperkins.com] "Here is a replacement for TC StandbyStatus: StandbyState ::= TEXTUAL- CONVENTION STATUS current DESCRIPTION " Represents the possible values of standby state. The value 'notAvailable(1)' means that no information is available on the standby state for the entity. The value 'hotStandby(2)' means the entity is not providing service, and will be immediately able to start providing service for the entity being backed up without the need for initialization activity, and will contain the same information as the entity being backed up. The value 'coldStandy(3)' means the entity is not providing service, and will be able to start providing service for an entity (possibly one from a set) being backed up, and will require some initialization activity. The value 'providingService(4)' means the entity is providing service. The value 'providingSharedService(5)' means the entity is providing service that is summed with the service provided by other entities." REFERENCE "ITU Recommendation X.731, 'Information Technology - Open Systems Interconnection - System Management: State Management Function', 1992" SYNTAX INTEGER { notAvailable(1), hotStandby(2), coldStandby(3), providingService(4), providingSharedService (5) } And a replacement for entStateStandby: entStateStandby OBJECT-TYPE SYNTAX StandbyStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The standby state for this entity. A value of 'notAvailable' means that this entity is unable to determine standby state. Some entities will exhibit only a subset of the remaining standby state values. If this entity cannot operate in a standby role, then the value with always be 'providingService'." ::= { entStateEntry 6 } " _______________________________________________ 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 Feb 15 15:59:31 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 OAA20619 for ; Sun, 15 Feb 2004 14:24:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsRs0-000206-JT for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 14:24:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FJO0Rt007674 for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 14:24:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsRs0-0001zg-EI; Sun, 15 Feb 2004 14:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsRri-0001zP-SU for entmib@optimus.ietf.org; Sun, 15 Feb 2004 14:23:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20614 for ; Sun, 15 Feb 2004 14:23:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsRrg-0004er-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:23:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsRql-0004cD-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:22:44 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AsRqc-0004ZP-00 for entmib@ietf.org; Sun, 15 Feb 2004 14:22:34 -0500 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 i1FJM3g25924 for ; Sun, 15 Feb 2004 14:22:03 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8YJ9>; Sun, 15 Feb 2004 14:22:04 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7275@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #330] AutoReply: Notification Varbinds Date: Sun, 15 Feb 2004 14:22:02 -0500 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: , The following is the proposed resolution to entstate-330. The issue will be considered closed pending the proposed edit being done. [Note: I'm trying to answer the question without enforcing a particular operational model on the management application. I don't think this is the right place to do that.] In the description to entStateOperDisabled add the following text "The entStateAdmin and entStateAlarm varbinds may be examined to find out additional information on the administrative state at the time of the operation state change as well to find out whether there were any known alarms against the entity at that time that may explain why the physical entity has become operationally disabled. " In the description to entStateOperEnabled add the following text "The entStateAdmin and entStateAlarm varbinds may be examined to find out additional information on the administrative state at the time of the operation state change as well to find out whether there were any known alarms against the entity at that time that may have affect on the physical entity's ability to stay operationally enabled." Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Friday, February 13, 2004 5:52 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #330] AutoReply: Notification Varbinds On Fri, Feb 13, 2004 at 04:53:02PM -0500, Sharon Chisholm wrote: > The following is the proposed resolution to entstate-330. The issue > will be considered closed pending the proposed edit being done. > > In the description to entStateOperEnabled and entStateOperDisabled add > the following text > > "The entStateAdmin and entStateAlarm varbinds may examined to find out > additional information on the administrative state at the time of the > operation state change as well to find out whether there were any > known alarms against the entity at that time." The text is OK and does not hurt, but you did not answer my question. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Sun Feb 15 16:36:31 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 QAA25496 for ; Sun, 15 Feb 2004 16:36:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsTvn-0000jZ-3N for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 16:36:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FLa36i002806 for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 16:36:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsTvm-0000ix-Aj; Sun, 15 Feb 2004 16:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsTvZ-0000ic-Po for entmib@optimus.ietf.org; Sun, 15 Feb 2004 16:35:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25444 for ; Sun, 15 Feb 2004 16:35:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsTvX-0004cr-00 for entmib@ietf.org; Sun, 15 Feb 2004 16:35:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsTuZ-0004Zn-00 for entmib@ietf.org; Sun, 15 Feb 2004 16:34:48 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AsTtn-0004U5-00 for entmib@ietf.org; Sun, 15 Feb 2004 16:33:59 -0500 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 i1FLXSg02071 for ; Sun, 15 Feb 2004 16:33:28 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8YVJ>; Sun, 15 Feb 2004 16:33:29 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7294@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #309] AutoReply: Operational State Name s and Concepts Date: Sun, 15 Feb 2004 16:33:27 -0500 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: , The following is the proposed resolution to entstate-309. The issue will be considered closed pending the proposed edit being done. [Note that this text may be influenced by the resolution of other issues.] Add the following text to entStateOper "Note that some implementations may not be able to accurately report entStateOper while the entStateAdmin object has a value other than 'unlocked'. In these cases, this object MUST have a value of 'notReportable'." Related to the additional points that Dave brought up. We just need to make sure we provide sufficient guidance for how to report status if available, or if it is not. I think we've covered the case where entities can't report. Section 3.1 already covers the relationship between this MIB and the interfaces MIB. I'm still not convinced that 'enabled' is that different than 'up. As for the other states: I swear we've discussed this already, but I can't find it. Personally, I like the cleanness of a two state operational state where additional information is found in supplemental objects, but I'm sure we can agree on a compromise. So, we already have 'unknown'. 'lowerLayerDown' is a computed state so out of scope. 'notPresent' can easily be computed via inventory information. 'dormant' could be considered comparable to the usage object in some ways. That leaves us with 'testing'. We could add that one. Add the following enumeration to OperState testing (4) And he following text to the OperState Description "A value of 'testing' means the resource is currently being tested and cannot there fore report whether it is operational or not." Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Thursday, February 12, 2004 5:13 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #309] AutoReply: Operational State Names and Concepts HI, First, implementing this object to match the semantics of X.731 will be difficult (if not impossible) if the hardware was not designed this way. And for some hardware (such as a power supplys) it may not be economically feasible to implement. (On a power supply, it may "disabled" by disconnecting the input power. If so, you cannot determine if it is working (that is, delivering output power within it's rated range) unless you supply input power. You could fake the oper state value by saving the last value of oper state when admin state was "unlocked" and returning it while the admin state is "locked".) Because of this issue, I believe that a new value needs to be added, such as "disabledDue2Admin". Also, the other values for object IF-MIB::ifOperStatus should be added. These values are: testing(3), -- in some test mode unknown(4), -- status can not be determined -- for some reason. dormant(5), notPresent(6), -- some component is missing lowerLayerDown(7) -- down due to state of -- lower-layer interface(s) But "lowerLayerDown" which be renamed to "containedNotEnabled". Secondly, I would name the terms "up" and "down" instead of "enabled" and "disabled", since enabled/disabled seem to be admin status and not operational state! Thirdly, the relationship between values of contained entities needs to be defined. (Object IF-MIB::ifOperStatus supports this.) At 02:17 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-309. The issue >will be considered closed pending the proposed edit being done. > >Add the following text to entStateOper > >"Note that some implementations may not be able to accurately report >entStateOper while the entStateAdmin object has a value other than >'unlocked'. In these cases, this object MUST have a value of >'notReportable'." > >Sharon > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 2:57 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #309] AutoReply: Operational State Names and Concepts > > >----------------------------------------------------------------------- >-- >Keith McCloghrie [kzm@cisco.com] > >"'enabled' and 'disabled' to me imply that an admin state, i.e., if >> I saw an operState of 'disabled', or a entStateOperDisabled >notification, >> I'd look for the knob by which I could issue the enable command to >enable >> it again. > >> for most things, I believe you have to turn them on to see if they >work; >> if they don't work, you can turn them off again, and label >them "inoperable", >> but what that means is that they were inoperable the last time they >were >> turned on, and it doesn't necessarily mean they are still >inoperable, e.g., >> if something was inoperable the last time it was turned on and has >just >> been repaired, but not yet turned on again, is it still >inoperable ?? >> That is, neither 'disabled' nor 'inoperable' is the right term for >> operState. > >" Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Sun Feb 15 16:36:30 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 QAA25494 for ; Sun, 15 Feb 2004 16:36:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsTvm-0000ix-Aj; Sun, 15 Feb 2004 16:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsTvZ-0000ic-Po for entmib@optimus.ietf.org; Sun, 15 Feb 2004 16:35:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25444 for ; Sun, 15 Feb 2004 16:35:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsTvX-0004cr-00 for entmib@ietf.org; Sun, 15 Feb 2004 16:35:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsTuZ-0004Zn-00 for entmib@ietf.org; Sun, 15 Feb 2004 16:34:48 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AsTtn-0004U5-00 for entmib@ietf.org; Sun, 15 Feb 2004 16:33:59 -0500 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 i1FLXSg02071 for ; Sun, 15 Feb 2004 16:33:28 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8YVJ>; Sun, 15 Feb 2004 16:33:29 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7294@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #309] AutoReply: Operational State Name s and Concepts Date: Sun, 15 Feb 2004 16:33:27 -0500 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: , The following is the proposed resolution to entstate-309. The issue will be considered closed pending the proposed edit being done. [Note that this text may be influenced by the resolution of other issues.] Add the following text to entStateOper "Note that some implementations may not be able to accurately report entStateOper while the entStateAdmin object has a value other than 'unlocked'. In these cases, this object MUST have a value of 'notReportable'." Related to the additional points that Dave brought up. We just need to make sure we provide sufficient guidance for how to report status if available, or if it is not. I think we've covered the case where entities can't report. Section 3.1 already covers the relationship between this MIB and the interfaces MIB. I'm still not convinced that 'enabled' is that different than 'up. As for the other states: I swear we've discussed this already, but I can't find it. Personally, I like the cleanness of a two state operational state where additional information is found in supplemental objects, but I'm sure we can agree on a compromise. So, we already have 'unknown'. 'lowerLayerDown' is a computed state so out of scope. 'notPresent' can easily be computed via inventory information. 'dormant' could be considered comparable to the usage object in some ways. That leaves us with 'testing'. We could add that one. Add the following enumeration to OperState testing (4) And he following text to the OperState Description "A value of 'testing' means the resource is currently being tested and cannot there fore report whether it is operational or not." Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Thursday, February 12, 2004 5:13 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #309] AutoReply: Operational State Names and Concepts HI, First, implementing this object to match the semantics of X.731 will be difficult (if not impossible) if the hardware was not designed this way. And for some hardware (such as a power supplys) it may not be economically feasible to implement. (On a power supply, it may "disabled" by disconnecting the input power. If so, you cannot determine if it is working (that is, delivering output power within it's rated range) unless you supply input power. You could fake the oper state value by saving the last value of oper state when admin state was "unlocked" and returning it while the admin state is "locked".) Because of this issue, I believe that a new value needs to be added, such as "disabledDue2Admin". Also, the other values for object IF-MIB::ifOperStatus should be added. These values are: testing(3), -- in some test mode unknown(4), -- status can not be determined -- for some reason. dormant(5), notPresent(6), -- some component is missing lowerLayerDown(7) -- down due to state of -- lower-layer interface(s) But "lowerLayerDown" which be renamed to "containedNotEnabled". Secondly, I would name the terms "up" and "down" instead of "enabled" and "disabled", since enabled/disabled seem to be admin status and not operational state! Thirdly, the relationship between values of contained entities needs to be defined. (Object IF-MIB::ifOperStatus supports this.) At 02:17 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-309. The issue >will be considered closed pending the proposed edit being done. > >Add the following text to entStateOper > >"Note that some implementations may not be able to accurately report >entStateOper while the entStateAdmin object has a value other than >'unlocked'. In these cases, this object MUST have a value of >'notReportable'." > >Sharon > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 2:57 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #309] AutoReply: Operational State Names and Concepts > > >----------------------------------------------------------------------- >-- >Keith McCloghrie [kzm@cisco.com] > >"'enabled' and 'disabled' to me imply that an admin state, i.e., if >> I saw an operState of 'disabled', or a entStateOperDisabled >notification, >> I'd look for the knob by which I could issue the enable command to >enable >> it again. > >> for most things, I believe you have to turn them on to see if they >work; >> if they don't work, you can turn them off again, and label >them "inoperable", >> but what that means is that they were inoperable the last time they >were >> turned on, and it doesn't necessarily mean they are still >inoperable, e.g., >> if something was inoperable the last time it was turned on and has >just >> been repaired, but not yet turned on again, is it still >inoperable ?? >> That is, neither 'disabled' nor 'inoperable' is the right term for >> operState. > >" Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Sun Feb 15 16:42:29 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 QAA25683 for ; Sun, 15 Feb 2004 16:42:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsU1Z-0001F8-PO for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 16:42:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FLg1fh004764 for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 16:42:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsU1Z-0001Ec-EF; Sun, 15 Feb 2004 16:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsU1I-0001EF-QQ for entmib@optimus.ietf.org; Sun, 15 Feb 2004 16:41:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25664 for ; Sun, 15 Feb 2004 16:41:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsU1G-0004u7-00 for entmib@ietf.org; Sun, 15 Feb 2004 16:41:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsU0J-0004rU-00 for entmib@ietf.org; Sun, 15 Feb 2004 16:40:44 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AsTzc-0004mn-00 for entmib@ietf.org; Sun, 15 Feb 2004 16:40:00 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1FLdTn07106 for ; Sun, 15 Feb 2004 16:39:29 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8YVW>; Sun, 15 Feb 2004 16:39:30 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7295@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is sema ntically wrong Date: Sun, 15 Feb 2004 16:39:28 -0500 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: , The following is the proposed resolution to entstate-307. The issue will be considered closed pending the proposed edit being done. [Note, we've gotten rid of the enumeration 'notReportable' in favour of more standard ones. The descriptive text, as far as I can see, aligns with what we all seem to be agreeing this enumeration means] Replace the enumeration 'notSupported' with 'unavailable' in each of the TCs and any references within the text. For each of the (TC, object definition) pairs, move the following sort of text from the object definition to the textual convention: "A value of 'unavailable' means that this resource is unable to report [this] state." Modifications include section 3.1, pp 3 section 3.4 TC AdminState TC OperState TC UsageState TC AlarmStatus TC StandbyStatus Object entStateAdmin Object entStateOper Object entStateUsage Object entStateAlarm Object entStateStandby Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 3:43 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: RE: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is sema ntically wrong HI, No, no, no - get rid of the "not reportable" terminology! At 03:23 PM 2/13/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-307. The issue >will be considered closed pending the proposed edit being done. > >Replace the enumeration 'notSupported' with 'unavailable' in each of >the TCs and any references within the text. > >For each of the (TC, object definition) pairs, move the following sort >of text from the object definition to the textual convention: > >"A value >of 'unavailable' means that this resource is unable to report [this] >state." > >Modifications include > section 3.1, pp 3 > section 3.4 > TC AdminState > TC OperState > TC UsageState > TC AlarmStatus > TC StandbyStatus > Object entStateAdmin > Object entStateOper > Object entStateUsage > Object entStateAlarm > Object entStateStandby > >Sharon > >-----Original Message----- >From: Chisholm, Sharon [CAR:0S00:EXCH] >Sent: Thursday, February 12, 2004 3:59 PM >To: entmib@ietf.org >Subject: RE: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is sema >ntically wrong > > >Hi > >Well, if we are to pick from the three, I think "unavailable" aligns >best with resolving this issue. > >Sharon > >-----Original Message----- >From: David T. Perkins [mailto:dperkins@dsperkins.com] >Sent: Thursday, February 12, 2004 3:51 PM >To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org >Subject: Re: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is >semantically wrong > > >HI, > >For me, the term "notReportable" is worse than "notSupported". The >terms "notSupported", "unknown" and "unavailable" are used in MIB >modules indicate an appropriate value cannot be obtained by the access >or instrumentation code. > >Mods: >section 3.1, pp 3 >section 3.4 >TC AdminState >TC OperState >TC UsageState >TC AlarmStatus >TC StandbyStatus >Object entStateAdmin >Object entStateOper >Object entStateUsage >Object entStateAlarm >Object entStateStandby > > > >At 01:53 PM 2/11/2004 -0500, Sharon Chisholm wrote: >>Hi >> >>That last bit should read >> >>""A value >>of 'notReportable' means that this resource is unable to report [this] >>state." >> >>Sharon >> >>-----Original Message----- >>From: Chisholm, Sharon [CAR:0S00:EXCH] >>Sent: Wednesday, February 11, 2004 1:51 PM >>To: 'entmib@ietf.org' >>Subject: FW: [psg.com #307] AutoReply: 'notSupported' is semantically >>wrong >> >> >>The following is the proposed resolution to entstate-307. The issue >>will be considered closed pending the proposed edit being done. >> >>Replace the enumeration 'notSupported' with 'notReportable' in each of >>the TCs and any references within the text. >> >>For each of the (TC, object definition) pairs, move the following sort >>of text from the object definition to the textual convention: >> >>"A value >>of 'notApplicable' means that this resource is unable to report [this] >>state." >> >>Sharon >> >>-----Original Message----- >>From: entity-state [mailto:rt+entity-state@rt.psg.com] >>Sent: Tuesday, January 13, 2004 2:50 AM >>To: Chisholm, Sharon [CAR:0S00:EXCH] >>Subject: [psg.com #307] AutoReply: 'notSupported' is semantically >>wrong >> >> >> >>---------------------------------------------------------------------- >>- >>-- >>Keith McCloghrie [kzm@cisco.com] >> >>" >>> 'notSupported' is semantically wrong, because a compliant >>implementation >>> obviously supports the MIB, but it can return 'notSupported' for >>> every object in the MIB. Presumably, the intended semantics is that >>> the agent would return the right value if only it knew the right >>value; >>> i.e., 'unknown' is the desired semantics. Also, why is each >>definition >>> of 'notSupported' defined in an object's DESCRIPTION, not in the >>TC's >>> DESCRIPTION ?" >/david t. perkins > > >_______________________________________________ >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 Sun Feb 15 17:29:29 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 QAA25682 for ; Sun, 15 Feb 2004 16:42:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsU1Z-0001Ec-EF; Sun, 15 Feb 2004 16:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsU1I-0001EF-QQ for entmib@optimus.ietf.org; Sun, 15 Feb 2004 16:41:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25664 for ; Sun, 15 Feb 2004 16:41:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsU1G-0004u7-00 for entmib@ietf.org; Sun, 15 Feb 2004 16:41:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsU0J-0004rU-00 for entmib@ietf.org; Sun, 15 Feb 2004 16:40:44 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AsTzc-0004mn-00 for entmib@ietf.org; Sun, 15 Feb 2004 16:40:00 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1FLdTn07106 for ; Sun, 15 Feb 2004 16:39:29 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8YVW>; Sun, 15 Feb 2004 16:39:30 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7295@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is sema ntically wrong Date: Sun, 15 Feb 2004 16:39:28 -0500 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: , The following is the proposed resolution to entstate-307. The issue will be considered closed pending the proposed edit being done. [Note, we've gotten rid of the enumeration 'notReportable' in favour of more standard ones. The descriptive text, as far as I can see, aligns with what we all seem to be agreeing this enumeration means] Replace the enumeration 'notSupported' with 'unavailable' in each of the TCs and any references within the text. For each of the (TC, object definition) pairs, move the following sort of text from the object definition to the textual convention: "A value of 'unavailable' means that this resource is unable to report [this] state." Modifications include section 3.1, pp 3 section 3.4 TC AdminState TC OperState TC UsageState TC AlarmStatus TC StandbyStatus Object entStateAdmin Object entStateOper Object entStateUsage Object entStateAlarm Object entStateStandby Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 3:43 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: RE: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is sema ntically wrong HI, No, no, no - get rid of the "not reportable" terminology! At 03:23 PM 2/13/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-307. The issue >will be considered closed pending the proposed edit being done. > >Replace the enumeration 'notSupported' with 'unavailable' in each of >the TCs and any references within the text. > >For each of the (TC, object definition) pairs, move the following sort >of text from the object definition to the textual convention: > >"A value >of 'unavailable' means that this resource is unable to report [this] >state." > >Modifications include > section 3.1, pp 3 > section 3.4 > TC AdminState > TC OperState > TC UsageState > TC AlarmStatus > TC StandbyStatus > Object entStateAdmin > Object entStateOper > Object entStateUsage > Object entStateAlarm > Object entStateStandby > >Sharon > >-----Original Message----- >From: Chisholm, Sharon [CAR:0S00:EXCH] >Sent: Thursday, February 12, 2004 3:59 PM >To: entmib@ietf.org >Subject: RE: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is sema >ntically wrong > > >Hi > >Well, if we are to pick from the three, I think "unavailable" aligns >best with resolving this issue. > >Sharon > >-----Original Message----- >From: David T. Perkins [mailto:dperkins@dsperkins.com] >Sent: Thursday, February 12, 2004 3:51 PM >To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org >Subject: Re: [Entmib] RE: [psg.com #307] AutoReply: 'notSupported' is >semantically wrong > > >HI, > >For me, the term "notReportable" is worse than "notSupported". The >terms "notSupported", "unknown" and "unavailable" are used in MIB >modules indicate an appropriate value cannot be obtained by the access >or instrumentation code. > >Mods: >section 3.1, pp 3 >section 3.4 >TC AdminState >TC OperState >TC UsageState >TC AlarmStatus >TC StandbyStatus >Object entStateAdmin >Object entStateOper >Object entStateUsage >Object entStateAlarm >Object entStateStandby > > > >At 01:53 PM 2/11/2004 -0500, Sharon Chisholm wrote: >>Hi >> >>That last bit should read >> >>""A value >>of 'notReportable' means that this resource is unable to report [this] >>state." >> >>Sharon >> >>-----Original Message----- >>From: Chisholm, Sharon [CAR:0S00:EXCH] >>Sent: Wednesday, February 11, 2004 1:51 PM >>To: 'entmib@ietf.org' >>Subject: FW: [psg.com #307] AutoReply: 'notSupported' is semantically >>wrong >> >> >>The following is the proposed resolution to entstate-307. The issue >>will be considered closed pending the proposed edit being done. >> >>Replace the enumeration 'notSupported' with 'notReportable' in each of >>the TCs and any references within the text. >> >>For each of the (TC, object definition) pairs, move the following sort >>of text from the object definition to the textual convention: >> >>"A value >>of 'notApplicable' means that this resource is unable to report [this] >>state." >> >>Sharon >> >>-----Original Message----- >>From: entity-state [mailto:rt+entity-state@rt.psg.com] >>Sent: Tuesday, January 13, 2004 2:50 AM >>To: Chisholm, Sharon [CAR:0S00:EXCH] >>Subject: [psg.com #307] AutoReply: 'notSupported' is semantically >>wrong >> >> >> >>---------------------------------------------------------------------- >>- >>-- >>Keith McCloghrie [kzm@cisco.com] >> >>" >>> 'notSupported' is semantically wrong, because a compliant >>implementation >>> obviously supports the MIB, but it can return 'notSupported' for >>> every object in the MIB. Presumably, the intended semantics is that >>> the agent would return the right value if only it knew the right >>value; >>> i.e., 'unknown' is the desired semantics. Also, why is each >>definition >>> of 'notSupported' defined in an object's DESCRIPTION, not in the >>TC's >>> DESCRIPTION ?" >/david t. perkins > > >_______________________________________________ >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 Sun Feb 15 18:44: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 SAA02399 for ; Sun, 15 Feb 2004 18:44:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsVvd-0007Os-21; Sun, 15 Feb 2004 18:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsVvQ-0007Nt-6l for entmib@optimus.ietf.org; Sun, 15 Feb 2004 18:43:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02361 for ; Sun, 15 Feb 2004 18:43:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsVvN-0006VD-00 for entmib@ietf.org; Sun, 15 Feb 2004 18:43:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsVuO-0006R9-00 for entmib@ietf.org; Sun, 15 Feb 2004 18:42:45 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AsVtP-0006LI-00 for entmib@ietf.org; Sun, 15 Feb 2004 18:41:43 -0500 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 i1FNf7g08587 for ; Sun, 15 Feb 2004 18:41:08 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8ZBW>; Sun, 15 Feb 2004 18:41:07 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A72A0@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #308] AutoReply: Shutting Down Admin St ate Date: Sun, 15 Feb 2004 18:41:07 -0500 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 I'm distilling two things from this email 1. It would be good to better understand the relationship between the admin state and the usage state to ensure there are no issues 2. There is discussion again about containment, which should be explained by the text in section 2.1 Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Thursday, February 12, 2004 4:50 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #308] AutoReply: Shutting Down Admin State HI, I also find several problems with the current definition of the value "shuttingDown" for AdminState. First, the definition of usageState was radically changed in the current draft of the document. From the DESCRIPTION clause of object entStateUsage (with comments in "<...>"): " Note that in the context of a physical entity, this object refers to an entity's ability to service more physical entities in a containment hierarchy. A value of 'idle' means this entity is able to contain other entities but that no other entity is currently contained within this entity, as would have been demonstrated by a value of entPhysicalContainedIn that referenced this entity. A value of 'active' means that at least one entity is contained within this entity and therefore has a value of entPhysicalContainedIn that references this entity, but that it could handle more. A value of 'busy' means that the entity is unable to handle any additional entities being contained in it, as demonstrated by having a value of entPhysicalContainedIn that refers to this entity. Some entities will exhibit only a subset of the usage state values. Entities that are unable to ever service any entities within a containment hierarchy will always have a usage state of 'busy'. Some entities will only ever be able to support one entity within its containment hierarchy and will therefore only exhibit values of 'idle' and 'busy'." Given the above, I don't know how to apply the value of "shuttingDown". But first, let's look at the values. Secondly, the X.731 document models the admin characteristic as with a 3 state diagram. The states are "unlocked", "shutting down", and "locked". The "shutting down" state is meant to represent a graceful shutdown of an "object". The event "shutdown" is a state transition from "unlocked" to "shutting down". Another transition occurs from state "shutting down" to "lock" when event "the last user quits" occurs. Now, if I were to model this in SNMP's SMI, I would have an "action/state" object with values: locked - a state and action unlocked - a state and action shutDown - an action (a write only value) (on a SET with no error, a read would return either value "locked" or "shuttingDown") shuttingDown - a state (a read only value) However, given the change of definition of the meaning of usage state, I'm a little confused as to how to "update" the TC (and object type) definitions. In general, I'm not sure that there is a need for a "graceful" and "force" administrative shutdown action values. If "graceful" shutdown is added, then I suggest that the value of "shuttingDown" be return until the value of "operState" is no longer "enabled". This removes the confusing "user" terminology. (See section 3.1.13 of RFC 2863) Thirdly, object IF-MIB::ifAdminStatus has a value of "testing". I don't know it maps to values for AdminState. This was not covered in the document. Finally, neither the IF MIB document nor X.731 describe the relationship between the admin values and admin (and oper) values of "contained" objects. And thus, this document does not cover this topic. It can be one of: 1) there is no relationship 2) the relationship is implementation defined 3) there is no relationship between admin values, but there is a weak relationship between oper values (more on this in message about #309 (oper state values)) At 01:59 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-308. The issue >will be considered closed with no changes made to the document. > >The following explanations were provided and no questions were raised. > >" >1. Is shutting down really more an operational state? > >The state refers more to whether your administrative model allows >systems to be shut down gracefully or not. The idea being that if it >does, you would still have the options to bring it down less >gracefully. We have allowed in the description of the object for >systems that don't support this value for the state. > >2. Would 'noNewUsage' be a better term. > >Well, except that the idea is that once all the existing 'users' are >gone, the system will shut down. The term 'noNewUsage' does not really >reflect that." > >Sharon > > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 2:55 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #308] AutoReply: Shutting Down Admin State > > >----------------------------------------------------------------------- >-- >Keith McCloghrie [kzm@cisco.com] > >" > >the term 'shuttingDown' suggests that the action of shutting down is >> in progress, which of course is an operational condition, not an >admin >> state. A term more reflective of what the AdminState DESCRIPTION >appears >> to define would be 'noNewUsage'. In any case, this concept >of 'usage' >> is almost always a higher-level usage (e.g., a new ATM connection >on an >> ATM interface, a new Unix login on a cpu module, etc.) and thus >don't >> belong at the physical layer (i.e., don't apply to >> entPhysicalIndex). >" Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Sun Feb 15 18:44: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 SAA02400 for ; Sun, 15 Feb 2004 18:44:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsVve-0007PS-30 for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 18:44:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FNi2Lh028478 for entmib-archive@odin.ietf.org; Sun, 15 Feb 2004 18:44:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsVvd-0007Os-21; Sun, 15 Feb 2004 18:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsVvQ-0007Nt-6l for entmib@optimus.ietf.org; Sun, 15 Feb 2004 18:43:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02361 for ; Sun, 15 Feb 2004 18:43:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsVvN-0006VD-00 for entmib@ietf.org; Sun, 15 Feb 2004 18:43:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsVuO-0006R9-00 for entmib@ietf.org; Sun, 15 Feb 2004 18:42:45 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AsVtP-0006LI-00 for entmib@ietf.org; Sun, 15 Feb 2004 18:41:43 -0500 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 i1FNf7g08587 for ; Sun, 15 Feb 2004 18:41:08 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8ZBW>; Sun, 15 Feb 2004 18:41:07 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A72A0@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #308] AutoReply: Shutting Down Admin St ate Date: Sun, 15 Feb 2004 18:41:07 -0500 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 I'm distilling two things from this email 1. It would be good to better understand the relationship between the admin state and the usage state to ensure there are no issues 2. There is discussion again about containment, which should be explained by the text in section 2.1 Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Thursday, February 12, 2004 4:50 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #308] AutoReply: Shutting Down Admin State HI, I also find several problems with the current definition of the value "shuttingDown" for AdminState. First, the definition of usageState was radically changed in the current draft of the document. From the DESCRIPTION clause of object entStateUsage (with comments in "<...>"): " Note that in the context of a physical entity, this object refers to an entity's ability to service more physical entities in a containment hierarchy. A value of 'idle' means this entity is able to contain other entities but that no other entity is currently contained within this entity, as would have been demonstrated by a value of entPhysicalContainedIn that referenced this entity. A value of 'active' means that at least one entity is contained within this entity and therefore has a value of entPhysicalContainedIn that references this entity, but that it could handle more. A value of 'busy' means that the entity is unable to handle any additional entities being contained in it, as demonstrated by having a value of entPhysicalContainedIn that refers to this entity. Some entities will exhibit only a subset of the usage state values. Entities that are unable to ever service any entities within a containment hierarchy will always have a usage state of 'busy'. Some entities will only ever be able to support one entity within its containment hierarchy and will therefore only exhibit values of 'idle' and 'busy'." Given the above, I don't know how to apply the value of "shuttingDown". But first, let's look at the values. Secondly, the X.731 document models the admin characteristic as with a 3 state diagram. The states are "unlocked", "shutting down", and "locked". The "shutting down" state is meant to represent a graceful shutdown of an "object". The event "shutdown" is a state transition from "unlocked" to "shutting down". Another transition occurs from state "shutting down" to "lock" when event "the last user quits" occurs. Now, if I were to model this in SNMP's SMI, I would have an "action/state" object with values: locked - a state and action unlocked - a state and action shutDown - an action (a write only value) (on a SET with no error, a read would return either value "locked" or "shuttingDown") shuttingDown - a state (a read only value) However, given the change of definition of the meaning of usage state, I'm a little confused as to how to "update" the TC (and object type) definitions. In general, I'm not sure that there is a need for a "graceful" and "force" administrative shutdown action values. If "graceful" shutdown is added, then I suggest that the value of "shuttingDown" be return until the value of "operState" is no longer "enabled". This removes the confusing "user" terminology. (See section 3.1.13 of RFC 2863) Thirdly, object IF-MIB::ifAdminStatus has a value of "testing". I don't know it maps to values for AdminState. This was not covered in the document. Finally, neither the IF MIB document nor X.731 describe the relationship between the admin values and admin (and oper) values of "contained" objects. And thus, this document does not cover this topic. It can be one of: 1) there is no relationship 2) the relationship is implementation defined 3) there is no relationship between admin values, but there is a weak relationship between oper values (more on this in message about #309 (oper state values)) At 01:59 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-308. The issue >will be considered closed with no changes made to the document. > >The following explanations were provided and no questions were raised. > >" >1. Is shutting down really more an operational state? > >The state refers more to whether your administrative model allows >systems to be shut down gracefully or not. The idea being that if it >does, you would still have the options to bring it down less >gracefully. We have allowed in the description of the object for >systems that don't support this value for the state. > >2. Would 'noNewUsage' be a better term. > >Well, except that the idea is that once all the existing 'users' are >gone, the system will shut down. The term 'noNewUsage' does not really >reflect that." > >Sharon > > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 2:55 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #308] AutoReply: Shutting Down Admin State > > >----------------------------------------------------------------------- >-- >Keith McCloghrie [kzm@cisco.com] > >" > >the term 'shuttingDown' suggests that the action of shutting down is >> in progress, which of course is an operational condition, not an >admin >> state. A term more reflective of what the AdminState DESCRIPTION >appears >> to define would be 'noNewUsage'. In any case, this concept >of 'usage' >> is almost always a higher-level usage (e.g., a new ATM connection >on an >> ATM interface, a new Unix login on a cpu module, etc.) and thus >don't >> belong at the physical layer (i.e., don't apply to >> entPhysicalIndex). >" Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Mon Feb 16 05:54: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 FAA10825 for ; Mon, 16 Feb 2004 05:54:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsgO1-0004UL-3V; Mon, 16 Feb 2004 05:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsgNG-0004Th-2u for entmib@optimus.ietf.org; Mon, 16 Feb 2004 05:53:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10795 for ; Mon, 16 Feb 2004 05:53:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsgNC-0002oH-00 for entmib@ietf.org; Mon, 16 Feb 2004 05:53:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsgMK-0002lu-00 for entmib@ietf.org; Mon, 16 Feb 2004 05:52:16 -0500 Received: from g4d24.g.pppool.de ([80.185.77.36] helo=james.eecs.iu-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 1AsgLg-0002iv-00 for entmib@ietf.org; Mon, 16 Feb 2004 05:51:36 -0500 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 4BE579062; Mon, 16 Feb 2004 11:51:36 +0100 (CET) Date: Mon, 16 Feb 2004 11:51:35 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues Message-ID: <20040216105135.GA788@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , entmib@ietf.org References: <3549C09B853DD5119B540002A52CDD340A2A727C@zcard0ka.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3549C09B853DD5119B540002A52CDD340A2A727C@zcard0ka.ca.nortel.com> User-Agent: Mutt/1.5.5.1+cvs20040105i 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=none 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: , On Sun, Feb 15, 2004 at 02:51:56PM -0500, Sharon Chisholm wrote: > When the value of 'alarmOutstanding' is set, one or more > alarms is active against the resource. The fault may or may > not be disabling. This bit provides a high-level summary that > can be used to determine whether or not to examine the rest of > the values. " I still fail to understand why we need a bit to summarize 6 other bits in a single byte. Unless someone can explain what the performance gain is of this summary bit, I tend to object to having this bit. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Mon Feb 16 05:54: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 FAA10837 for ; Mon, 16 Feb 2004 05:54:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsgO1-0004Ui-C4 for entmib-archive@odin.ietf.org; Mon, 16 Feb 2004 05:54:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GAs1Da017264 for entmib-archive@odin.ietf.org; Mon, 16 Feb 2004 05:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsgO1-0004UL-3V; Mon, 16 Feb 2004 05:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsgNG-0004Th-2u for entmib@optimus.ietf.org; Mon, 16 Feb 2004 05:53:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10795 for ; Mon, 16 Feb 2004 05:53:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsgNC-0002oH-00 for entmib@ietf.org; Mon, 16 Feb 2004 05:53:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsgMK-0002lu-00 for entmib@ietf.org; Mon, 16 Feb 2004 05:52:16 -0500 Received: from g4d24.g.pppool.de ([80.185.77.36] helo=james.eecs.iu-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 1AsgLg-0002iv-00 for entmib@ietf.org; Mon, 16 Feb 2004 05:51:36 -0500 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 4BE579062; Mon, 16 Feb 2004 11:51:36 +0100 (CET) Date: Mon, 16 Feb 2004 11:51:35 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues Message-ID: <20040216105135.GA788@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , entmib@ietf.org References: <3549C09B853DD5119B540002A52CDD340A2A727C@zcard0ka.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3549C09B853DD5119B540002A52CDD340A2A727C@zcard0ka.ca.nortel.com> User-Agent: Mutt/1.5.5.1+cvs20040105i 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=none 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: , On Sun, Feb 15, 2004 at 02:51:56PM -0500, Sharon Chisholm wrote: > When the value of 'alarmOutstanding' is set, one or more > alarms is active against the resource. The fault may or may > not be disabling. This bit provides a high-level summary that > can be used to determine whether or not to examine the rest of > the values. " I still fail to understand why we need a bit to summarize 6 other bits in a single byte. Unless someone can explain what the performance gain is of this summary bit, I tend to object to having this bit. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Mon Feb 16 08:03:30 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 IAA14976 for ; Mon, 16 Feb 2004 08:03:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsiOr-0003gV-Tf for entmib-archive@odin.ietf.org; Mon, 16 Feb 2004 08:03:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GD31hW014151 for entmib-archive@odin.ietf.org; Mon, 16 Feb 2004 08:03:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsiOr-0003fo-5F; Mon, 16 Feb 2004 08:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsiO6-0003fE-Pr for entmib@optimus.ietf.org; Mon, 16 Feb 2004 08:02:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14943 for ; Mon, 16 Feb 2004 08:02:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsiO5-0001nW-00 for entmib@ietf.org; Mon, 16 Feb 2004 08:02:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsiNE-0001kq-00 for entmib@ietf.org; Mon, 16 Feb 2004 08:01:21 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AsiMd-0001g9-00 for entmib@ietf.org; Mon, 16 Feb 2004 08:00:43 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1GD0B508808 for ; Mon, 16 Feb 2004 08:00:12 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH869T>; Mon, 16 Feb 2004 08:00:12 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7333@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Mon, 16 Feb 2004 08:00:11 -0500 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 Subject: [Entmib] Updated Entity State MIB 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 The good news is we got in an updated version of the Entity State MIB in before the draft cut-off time. The bad news is that the working group hasn't really reach a consensus on how to resolve a few of the open issues so it looks like we will have to continue working the outstanding problems and get an additional update out after the Seoul meeting. Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Mon Feb 16 08:49:37 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 IAA14974 for ; Mon, 16 Feb 2004 08:03:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsiOr-0003fo-5F; Mon, 16 Feb 2004 08:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsiO6-0003fE-Pr for entmib@optimus.ietf.org; Mon, 16 Feb 2004 08:02:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14943 for ; Mon, 16 Feb 2004 08:02:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsiO5-0001nW-00 for entmib@ietf.org; Mon, 16 Feb 2004 08:02:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsiNE-0001kq-00 for entmib@ietf.org; Mon, 16 Feb 2004 08:01:21 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AsiMd-0001g9-00 for entmib@ietf.org; Mon, 16 Feb 2004 08:00:43 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1GD0B508808 for ; Mon, 16 Feb 2004 08:00:12 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH869T>; Mon, 16 Feb 2004 08:00:12 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7333@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Mon, 16 Feb 2004 08:00:11 -0500 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 Subject: [Entmib] Updated Entity State MIB 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 The good news is we got in an updated version of the Entity State MIB in before the draft cut-off time. The bad news is that the working group hasn't really reach a consensus on how to resolve a few of the open issues so it looks like we will have to continue working the outstanding problems and get an additional update out after the Seoul meeting. Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Feb 18 09:36:29 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 JAA12981 for ; Wed, 18 Feb 2004 09:36:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSnw-0003GG-Jh; Wed, 18 Feb 2004 09:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSn8-00039l-06 for entmib@optimus.ietf.org; Wed, 18 Feb 2004 09:35:10 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12853; Wed, 18 Feb 2004 09:35:06 -0500 (EST) Message-Id: <200402181435.JAA12853@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: entmib@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 18 Feb 2004 09:35:06 -0500 Subject: [Entmib] I-D ACTION:draft-ietf-entmib-state-03.txt 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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Entity MIB Working Group of the IETF. Title : Entity State MIB Author(s) : S. Chisholm, D. Perkins Filename : draft-ietf-entmib-state-03.txt Pages : 18 Date : 2004-2-18 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the entity MIB to provide information about the state of the entity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-entmib-state-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-entmib-state-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-18094750.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-entmib-state-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-entmib-state-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18094750.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Feb 18 09:36:29 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 JAA13002 for ; Wed, 18 Feb 2004 09:36:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSny-0003Gx-65 for entmib-archive@odin.ietf.org; Wed, 18 Feb 2004 09:36:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IEa1NX012551 for entmib-archive@odin.ietf.org; Wed, 18 Feb 2004 09:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSnw-0003GG-Jh; Wed, 18 Feb 2004 09:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSn8-00039l-06 for entmib@optimus.ietf.org; Wed, 18 Feb 2004 09:35:10 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12853; Wed, 18 Feb 2004 09:35:06 -0500 (EST) Message-Id: <200402181435.JAA12853@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: entmib@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 18 Feb 2004 09:35:06 -0500 Subject: [Entmib] I-D ACTION:draft-ietf-entmib-state-03.txt 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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Entity MIB Working Group of the IETF. Title : Entity State MIB Author(s) : S. Chisholm, D. Perkins Filename : draft-ietf-entmib-state-03.txt Pages : 18 Date : 2004-2-18 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the entity MIB to provide information about the state of the entity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-entmib-state-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-entmib-state-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-18094750.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-entmib-state-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-entmib-state-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18094750.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Feb 18 10:49:45 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 KAA23322 for ; Wed, 18 Feb 2004 10:49:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTwr-0006u1-LR; Wed, 18 Feb 2004 10:49:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTvr-0006q9-6Q for entmib@optimus.ietf.org; Wed, 18 Feb 2004 10:48:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23292 for ; Wed, 18 Feb 2004 10:48:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtTvd-0004Pq-00 for entmib@ietf.org; Wed, 18 Feb 2004 10:48:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtTug-0004MR-00 for entmib@ietf.org; Wed, 18 Feb 2004 10:47:03 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AtTtt-0004E7-00 for entmib@ietf.org; Wed, 18 Feb 2004 10:46:13 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1IFjXV02113 for ; Wed, 18 Feb 2004 10:45:33 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH02F2>; Wed, 18 Feb 2004 10:45:27 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A38C647@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 18 Feb 2004 10:45:25 -0500 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 Subject: [Entmib] Entity State MIB Issue Summary & Status 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 Ok, the new draft is out, but there are still three unresolved issues to deal with. Unresolved 308 Shutting Down Admin State 310 Alarm State Issues open entity-state 329 Usage State Scope Resolved 306 entStateTrap rename/oid to entStateNotifs 307 'notSupported' is semantically wrong open 309 Operational State Names and Concepts 311 DateAndTimeOrZero ? open entity-state 312 Locked Admin State open entity-state 322 Textual Convention Names (Prefix) 325 OID Structure 326 Too many state 327 More Editorial Issues 328 Containment Hierach and entPhysicalContainedin 330 Notification Varbinds 332 More Standby State/Status Issues 333 Relationship with Alarm MIB 334 Table, Index Descriptions 335 Notification Comments As always, the details can be found at http://rt.psg.com (ietf, ietf) Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Feb 18 11:43:30 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 LAA27522 for ; Wed, 18 Feb 2004 11:43:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtUmr-000456-E2; Wed, 18 Feb 2004 11:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtUmF-0003fZ-4u for entmib@optimus.ietf.org; Wed, 18 Feb 2004 11:42:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27432 for ; Wed, 18 Feb 2004 11:42:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtUmE-0001sk-00 for entmib@ietf.org; Wed, 18 Feb 2004 11:42:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtUlK-0001mu-00 for entmib@ietf.org; Wed, 18 Feb 2004 11:41:27 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AtUkg-0001bH-00 for entmib@ietf.org; Wed, 18 Feb 2004 11:40:47 -0500 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 i1IGeFJ19299 for ; Wed, 18 Feb 2004 11:40:15 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH0JZ4>; Wed, 18 Feb 2004 11:40:15 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A38C71D@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues Date: Wed, 18 Feb 2004 11:40:15 -0500 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 Ok, while I still think it's a useful little bit, if there are not objections, I'm willing to remove it. Are there any other views on this? Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Monday, February 16, 2004 5:52 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues On Sun, Feb 15, 2004 at 02:51:56PM -0500, Sharon Chisholm wrote: > When the value of 'alarmOutstanding' is set, one or more > alarms is active against the resource. The fault may or may > not be disabling. This bit provides a high-level summary that > can be used to determine whether or not to examine the rest of > the values. " I still fail to understand why we need a bit to summarize 6 other bits in a single byte. Unless someone can explain what the performance gain is of this summary bit, I tend to object to having this bit. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Feb 18 11:43:31 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 LAA27531 for ; Wed, 18 Feb 2004 11:43:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtUms-00046F-Vz for entmib-archive@odin.ietf.org; Wed, 18 Feb 2004 11:43:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IGh2N9015730 for entmib-archive@odin.ietf.org; Wed, 18 Feb 2004 11:43:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtUmr-000456-E2; Wed, 18 Feb 2004 11:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtUmF-0003fZ-4u for entmib@optimus.ietf.org; Wed, 18 Feb 2004 11:42:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27432 for ; Wed, 18 Feb 2004 11:42:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtUmE-0001sk-00 for entmib@ietf.org; Wed, 18 Feb 2004 11:42:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtUlK-0001mu-00 for entmib@ietf.org; Wed, 18 Feb 2004 11:41:27 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AtUkg-0001bH-00 for entmib@ietf.org; Wed, 18 Feb 2004 11:40:47 -0500 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 i1IGeFJ19299 for ; Wed, 18 Feb 2004 11:40:15 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH0JZ4>; Wed, 18 Feb 2004 11:40:15 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A38C71D@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues Date: Wed, 18 Feb 2004 11:40:15 -0500 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 Ok, while I still think it's a useful little bit, if there are not objections, I'm willing to remove it. Are there any other views on this? Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Monday, February 16, 2004 5:52 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues On Sun, Feb 15, 2004 at 02:51:56PM -0500, Sharon Chisholm wrote: > When the value of 'alarmOutstanding' is set, one or more > alarms is active against the resource. The fault may or may > not be disabling. This bit provides a high-level summary that > can be used to determine whether or not to examine the rest of > the values. " I still fail to understand why we need a bit to summarize 6 other bits in a single byte. Unless someone can explain what the performance gain is of this summary bit, I tend to object to having this bit. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Feb 18 11:43:30 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 LAA27524 for ; Wed, 18 Feb 2004 11:43:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtUms-00045S-9q; Wed, 18 Feb 2004 11:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtUmq-00044s-MM for entmib@optimus.ietf.org; Wed, 18 Feb 2004 11:43:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27469 for ; Wed, 18 Feb 2004 11:42:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtUmp-0001wI-00 for entmib@ietf.org; Wed, 18 Feb 2004 11:42:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtUm2-0001r0-00 for entmib@ietf.org; Wed, 18 Feb 2004 11:42:11 -0500 Received: from g5021.g.pppool.de ([80.185.80.33] helo=james.eecs.iu-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 1AtUl6-0001kg-00 for entmib@ietf.org; Wed, 18 Feb 2004 11:41:13 -0500 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 3CA0281D9; Wed, 18 Feb 2004 17:41:11 +0100 (CET) Date: Wed, 18 Feb 2004 17:41:10 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm , Margaret Wasserman Cc: entmib@ietf.org Subject: Re: [Entmib] Entity State MIB Issue Summary & Status Message-ID: <20040218164110.GA982@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , Margaret Wasserman , entmib@ietf.org References: <3549C09B853DD5119B540002A52CDD340A38C647@zcard0ka.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3549C09B853DD5119B540002A52CDD340A38C647@zcard0ka.ca.nortel.com> User-Agent: Mutt/1.5.5.1+cvs20040105i 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=none 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: , On Wed, Feb 18, 2004 at 10:45:25AM -0500, Sharon Chisholm wrote: > Ok, the new draft is out, but there are still three unresolved issues to > deal with. > > Unresolved > > 308 Shutting Down Admin State > 310 Alarm State Issues open entity-state > 329 Usage State Scope > > Resolved > > 306 entStateTrap rename/oid to entStateNotifs > 307 'notSupported' is semantically wrong open > 309 Operational State Names and Concepts > 311 DateAndTimeOrZero ? open entity-state > 312 Locked Admin State open entity-state > 322 Textual Convention Names (Prefix) > 325 OID Structure > 326 Too many state > 327 More Editorial Issues > 328 Containment Hierach and entPhysicalContainedin > 330 Notification Varbinds > 332 More Standby State/Status Issues > 333 Relationship with Alarm MIB > 334 Table, Index Descriptions > 335 Notification Comments I personally did not see concensus on some of the issues that you report as resolved. For example, I did see more people speaking up in favour of prefixed TC names. Also, the feedback on some of the other items listed above were never really consistent with the proposed resolution. You seem to push a bit too strongly your opinion on some issues. This is why I like the see the chair jumping in to determine where we actually have concensus and where not and of course what the determined concensus position actually is. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Feb 18 11:43:31 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 LAA27560 for ; Wed, 18 Feb 2004 11:43:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtUms-00046E-Vo for entmib-archive@odin.ietf.org; Wed, 18 Feb 2004 11:43:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IGh2jh015733 for entmib-archive@odin.ietf.org; Wed, 18 Feb 2004 11:43:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtUms-00045S-9q; Wed, 18 Feb 2004 11:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtUmq-00044s-MM for entmib@optimus.ietf.org; Wed, 18 Feb 2004 11:43:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27469 for ; Wed, 18 Feb 2004 11:42:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtUmp-0001wI-00 for entmib@ietf.org; Wed, 18 Feb 2004 11:42:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtUm2-0001r0-00 for entmib@ietf.org; Wed, 18 Feb 2004 11:42:11 -0500 Received: from g5021.g.pppool.de ([80.185.80.33] helo=james.eecs.iu-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 1AtUl6-0001kg-00 for entmib@ietf.org; Wed, 18 Feb 2004 11:41:13 -0500 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 3CA0281D9; Wed, 18 Feb 2004 17:41:11 +0100 (CET) Date: Wed, 18 Feb 2004 17:41:10 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm , Margaret Wasserman Cc: entmib@ietf.org Subject: Re: [Entmib] Entity State MIB Issue Summary & Status Message-ID: <20040218164110.GA982@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Sharon Chisholm , Margaret Wasserman , entmib@ietf.org References: <3549C09B853DD5119B540002A52CDD340A38C647@zcard0ka.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3549C09B853DD5119B540002A52CDD340A38C647@zcard0ka.ca.nortel.com> User-Agent: Mutt/1.5.5.1+cvs20040105i 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=none 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: , On Wed, Feb 18, 2004 at 10:45:25AM -0500, Sharon Chisholm wrote: > Ok, the new draft is out, but there are still three unresolved issues to > deal with. > > Unresolved > > 308 Shutting Down Admin State > 310 Alarm State Issues open entity-state > 329 Usage State Scope > > Resolved > > 306 entStateTrap rename/oid to entStateNotifs > 307 'notSupported' is semantically wrong open > 309 Operational State Names and Concepts > 311 DateAndTimeOrZero ? open entity-state > 312 Locked Admin State open entity-state > 322 Textual Convention Names (Prefix) > 325 OID Structure > 326 Too many state > 327 More Editorial Issues > 328 Containment Hierach and entPhysicalContainedin > 330 Notification Varbinds > 332 More Standby State/Status Issues > 333 Relationship with Alarm MIB > 334 Table, Index Descriptions > 335 Notification Comments I personally did not see concensus on some of the issues that you report as resolved. For example, I did see more people speaking up in favour of prefixed TC names. Also, the feedback on some of the other items listed above were never really consistent with the proposed resolution. You seem to push a bit too strongly your opinion on some issues. This is why I like the see the chair jumping in to determine where we actually have concensus and where not and of course what the determined concensus position actually is. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Feb 18 11:53:29 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 LAA28114 for ; Wed, 18 Feb 2004 11:53:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtUwX-0004RP-64; Wed, 18 Feb 2004 11:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtUvh-0004Q5-H9 for entmib@optimus.ietf.org; Wed, 18 Feb 2004 11:52:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28006 for ; Wed, 18 Feb 2004 11:52:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtUvg-0002jo-00 for entmib@ietf.org; Wed, 18 Feb 2004 11:52:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtUum-0002e4-00 for entmib@ietf.org; Wed, 18 Feb 2004 11:51:13 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AtUtn-0002Vs-00 for entmib@ietf.org; Wed, 18 Feb 2004 11:50:11 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1IGndx17630 for ; Wed, 18 Feb 2004 11:49:40 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH0KAS>; Wed, 18 Feb 2004 11:49:40 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A38C741@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] Entity State MIB Issue Summary & Status Date: Wed, 18 Feb 2004 11:49:39 -0500 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, I posted these are being resolved, even though I have not closed them officially yet, because I am looking for feedback from people on when they weren't happy with the proposed resolutions. I can't do much with silence. If you think I didn't weight working group consensus correctly, I'm cool with getting a second opinion. (On the prefix issue I counted 2 against, 1 for not including my view but other counts welcome in case I misinterpreted) Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Wednesday, February 18, 2004 11:41 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; Margaret Wasserman Cc: entmib@ietf.org Subject: Re: [Entmib] Entity State MIB Issue Summary & Status I personally did not see concensus on some of the issues that you report as resolved. For example, I did see more people speaking up in favour of prefixed TC names. Also, the feedback on some of the other items listed above were never really consistent with the proposed resolution. You seem to push a bit too strongly your opinion on some issues. This is why I like the see the chair jumping in to determine where we actually have concensus and where not and of course what the determined concensus position actually is. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Feb 18 11:53:29 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 LAA28116 for ; Wed, 18 Feb 2004 11:53:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtUwX-0004Rp-Nj for entmib-archive@odin.ietf.org; Wed, 18 Feb 2004 11:53:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IGr1Uw017085 for entmib-archive@odin.ietf.org; Wed, 18 Feb 2004 11:53:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtUwX-0004RP-64; Wed, 18 Feb 2004 11:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtUvh-0004Q5-H9 for entmib@optimus.ietf.org; Wed, 18 Feb 2004 11:52:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28006 for ; Wed, 18 Feb 2004 11:52:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtUvg-0002jo-00 for entmib@ietf.org; Wed, 18 Feb 2004 11:52:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtUum-0002e4-00 for entmib@ietf.org; Wed, 18 Feb 2004 11:51:13 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AtUtn-0002Vs-00 for entmib@ietf.org; Wed, 18 Feb 2004 11:50:11 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1IGndx17630 for ; Wed, 18 Feb 2004 11:49:40 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH0KAS>; Wed, 18 Feb 2004 11:49:40 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A38C741@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] Entity State MIB Issue Summary & Status Date: Wed, 18 Feb 2004 11:49:39 -0500 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, I posted these are being resolved, even though I have not closed them officially yet, because I am looking for feedback from people on when they weren't happy with the proposed resolutions. I can't do much with silence. If you think I didn't weight working group consensus correctly, I'm cool with getting a second opinion. (On the prefix issue I counted 2 against, 1 for not including my view but other counts welcome in case I misinterpreted) Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Wednesday, February 18, 2004 11:41 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; Margaret Wasserman Cc: entmib@ietf.org Subject: Re: [Entmib] Entity State MIB Issue Summary & Status I personally did not see concensus on some of the issues that you report as resolved. For example, I did see more people speaking up in favour of prefixed TC names. Also, the feedback on some of the other items listed above were never really consistent with the proposed resolution. You seem to push a bit too strongly your opinion on some issues. This is why I like the see the chair jumping in to determine where we actually have concensus and where not and of course what the determined concensus position actually is. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Tue Feb 24 11:01: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 LAA27482 for ; Tue, 24 Feb 2004 11:01:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvezU-0001Br-Sd; Tue, 24 Feb 2004 11:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aveyc-00018Y-Cy for entmib@optimus.ietf.org; Tue, 24 Feb 2004 11:00:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27402 for ; Tue, 24 Feb 2004 11:00:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AveyZ-00047e-00 for entmib@ietf.org; Tue, 24 Feb 2004 11:00:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avexa-000412-00 for entmib@ietf.org; Tue, 24 Feb 2004 10:59:03 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Avewf-0003pK-00 for entmib@ietf.org; Tue, 24 Feb 2004 10:58:05 -0500 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 i1OFvRq02773 for ; Tue, 24 Feb 2004 10:57:27 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Feb 2004 10:57:27 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A46439E@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues Date: Tue, 24 Feb 2004 10:57:19 -0500 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: , The following is the proposed resolution to entstate-310. The issue will be considered closed pending the proposed edit being done. [Note that the previously proposed edits were done and are reflected in version -03 of the Entity State MIB. The following is an additional edit on top of that.] In the DESCRIPTION of AlarmStatus remove the following text: "When the value of 'alarmOutstanding' is set, one or more alarms is active against the resource. The fault may or may not be disabling. This bit provides a high-level summary that can be used to determine whether or not to examine the rest of the values. " And in the enumeration for AlarmStatus, replace: " alarmOutstanding(5), -- The following are not defined in X.733 warning (6), indeterminate (7) " With " -- The following are not defined in X.733 warning (5), indeterminate (6) " Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, February 18, 2004 11:40 AM To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues Hi Ok, while I still think it's a useful little bit, if there are not objections, I'm willing to remove it. Are there any other views on this? Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Monday, February 16, 2004 5:52 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues On Sun, Feb 15, 2004 at 02:51:56PM -0500, Sharon Chisholm wrote: > When the value of 'alarmOutstanding' is set, one or more > alarms is active against the resource. The fault may or may > not be disabling. This bit provides a high-level summary > that > can be used to determine whether or not to examine the > rest of > the values. " I still fail to understand why we need a bit to summarize 6 other bits in a single byte. Unless someone can explain what the performance gain is of this summary bit, I tend to object to having this bit. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ 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 Feb 24 11:01:29 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 LAA27496 for ; Tue, 24 Feb 2004 11:01:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvezW-0001Co-Fa for entmib-archive@odin.ietf.org; Tue, 24 Feb 2004 11:01:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OG11b5004596 for entmib-archive@odin.ietf.org; Tue, 24 Feb 2004 11:01:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvezU-0001Br-Sd; Tue, 24 Feb 2004 11:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aveyc-00018Y-Cy for entmib@optimus.ietf.org; Tue, 24 Feb 2004 11:00:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27402 for ; Tue, 24 Feb 2004 11:00:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AveyZ-00047e-00 for entmib@ietf.org; Tue, 24 Feb 2004 11:00:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avexa-000412-00 for entmib@ietf.org; Tue, 24 Feb 2004 10:59:03 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1Avewf-0003pK-00 for entmib@ietf.org; Tue, 24 Feb 2004 10:58:05 -0500 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 i1OFvRq02773 for ; Tue, 24 Feb 2004 10:57:27 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Feb 2004 10:57:27 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A46439E@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues Date: Tue, 24 Feb 2004 10:57:19 -0500 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: , The following is the proposed resolution to entstate-310. The issue will be considered closed pending the proposed edit being done. [Note that the previously proposed edits were done and are reflected in version -03 of the Entity State MIB. The following is an additional edit on top of that.] In the DESCRIPTION of AlarmStatus remove the following text: "When the value of 'alarmOutstanding' is set, one or more alarms is active against the resource. The fault may or may not be disabling. This bit provides a high-level summary that can be used to determine whether or not to examine the rest of the values. " And in the enumeration for AlarmStatus, replace: " alarmOutstanding(5), -- The following are not defined in X.733 warning (6), indeterminate (7) " With " -- The following are not defined in X.733 warning (5), indeterminate (6) " Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Wednesday, February 18, 2004 11:40 AM To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues Hi Ok, while I still think it's a useful little bit, if there are not objections, I'm willing to remove it. Are there any other views on this? Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Monday, February 16, 2004 5:52 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues On Sun, Feb 15, 2004 at 02:51:56PM -0500, Sharon Chisholm wrote: > When the value of 'alarmOutstanding' is set, one or more > alarms is active against the resource. The fault may or may > not be disabling. This bit provides a high-level summary > that > can be used to determine whether or not to examine the > rest of > the values. " I still fail to understand why we need a bit to summarize 6 other bits in a single byte. Unless someone can explain what the performance gain is of this summary bit, I tend to object to having this bit. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ 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