RE: [Entmib] Final Closure on Entity State MIB Issues
"Sharon Chisholm" <schishol@nortelnetworks.com> Tue, 23 March 2004 14:30 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28987 for <entmib-archive@lists.ietf.org>; Tue, 23 Mar 2004 09: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 1B5mun-0002ZT-1t; Tue, 23 Mar 2004 09:30:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5muc-0002YY-DU for entmib@optimus.ietf.org; Tue, 23 Mar 2004 09:29: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 JAA28920 for <entmib@ietf.org>; Tue, 23 Mar 2004 09:29:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5mua-0001aQ-00 for entmib@ietf.org; Tue, 23 Mar 2004 09:29:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5mtS-0001QS-00 for entmib@ietf.org; Tue, 23 Mar 2004 09:28:39 -0500
Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1B5msv-0001GB-00 for entmib@ietf.org; Tue, 23 Mar 2004 09:28:05 -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 i2NERV522569 for <entmib@ietf.org>; Tue, 23 Mar 2004 09:27:31 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <GXT62538>; Tue, 23 Mar 2004 09:27:31 -0500
Message-ID: <3549C09B853DD5119B540002A52CDD340A967516@zcard0ka.ca.nortel.com>
From: Sharon Chisholm <schishol@nortelnetworks.com>
To: entmib@ietf.org
Subject: RE: [Entmib] Final Closure on Entity State MIB Issues
Date: Tue, 23 Mar 2004 09:27:26 -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: <https://www1.ietf.org/mailman/listinfo/entmib>, <mailto:entmib-request@ietf.org?subject=unsubscribe>
List-Id: IETF Entity MIB WG <entmib.ietf.org>
List-Post: <mailto:entmib@ietf.org>
List-Help: <mailto:entmib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/entmib>, <mailto:entmib-request@ietf.org?subject=subscribe>
hi I've updated the issues in http://rt.psg.com. The tool often has a lot of issues with timeouts and things. I've learned a few tricks to work around them. Comments inline... -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Monday, March 22, 2004 4:32 PM To: Margaret Wasserman Cc: entmib@ietf.org Subject: Re: [Entmib] Final Closure on Entity State MIB Issues <clip> #307: 'notSupported' is semantically wrong I think "unknown" as suggested by Keith is what we typically use and prefer this over "unavailable" or any other terms. Sharon> I don't have a strong opinion on this. Others did though. #308: Shutting Down Admin State I tend to agree with Keith' comment and I do not think that the response addresses Keith issue with the name/state itself. Sharon> Well, shutting down has to be an administrative state since you have a choice of graceful shutdown and just shutting it down. As far as the name goes, in order to fully describe state, it would have to be 'noNewUsageThenShuttingDown'. It's sort of a fun name, but some may think it too long. <clip> #311: DateAndTimeOrZero ? The new text refers to the initialization of "the local system" - whatever that may be. In a subagent environment, the actual instrumentation might not have easy access to what an operator would consider "the local system". So I think it would be better to adopt the approach where a the special value '0000000000000000'H is returned. Sure, this value falls not strictly under the DateAndTime TC set of values, but we have several MIBs using this special value on the standards track so this should work here as well. Sharon> I like this simpler approach. I had been half way down the path of defining new TCs to behave like this when I looked up how we did it in the Alarm MIB. Would answering the question of what the 'local system' is or using a better term help? <clip> #322: Textual Convention Names (Prefix) I think the TC names should be prefixed. Sharon> Ok. I think we need to step back a level on this one. We seemed to have had agreement on the list that if the TCs were intended to be not specific to Entities, then they should not have the prefix but if they were they should. So, I suspect we are disagreeing on whether these TCs are specific to Entities. I certainly never intended them to be and went out of my way to ensure they weren't. Is there something in their definition that leads you to believe they are limited in their application to Entities? #325: The figures in the discussion of this issue are wrong as xxxCompliances(1) and xxxGroups(2) are typically registered below xxxConformance(2). Sharon> This is from the MIB Review Guidelines. <clip> #328: Containment Hierach and entPhysicalContainedin I think this issue is not really solved. It must be clear in all cases where a description clause talks about containment what this really means. Sharon> Embedded? Perhaps. <clip> #334: Table, Index Descriptions I am having problems with the suggested new text. In particular the following sentence: 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. I think that the class is not necessarily the property which defines whether a component will be able to report useful information in a subagent environment. I think this sentence hurts more than it helps. BTW, the most obvious reason for sparse augmentations is that new hardware and software will in practice be mixed with old hardware and software in subagent environments. (Not sure we need to document this. I think it is sufficient to say it is a sparse augmentation.) Sharon>I have had a lot of trouble with this text since I actually don't think this table should be sparse augment. I was just going with a working group consensus we agreed to a long time ago. Your reasons makes more sense. I'll try to rework the text. #335: Notification Comments To me, entStateStandby related notifications might make sense and this should not be ruled out by being late. However, there needs to be a concrete proposal to look at. Without a concrete proposal, no change seems OK. Sharon> Ok, so in the absence of that ... Sharon _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib
- [Entmib] Final Closure on Entity State MIB Issues Margaret Wasserman
- Re: [Entmib] Final Closure on Entity State MIB Is… Juergen Schoenwaelder
- RE: [Entmib] Final Closure on Entity State MIB Is… Sharon Chisholm
- RE: [Entmib] Final Closure on Entity State MIB Is… Wijnen, Bert (Bert)
- RE: [Entmib] Final Closure on Entity State MIB Is… Sharon Chisholm
- Re: [Entmib] Final Closure on Entity State MIB Is… Juergen Schoenwaelder