[Entmib] entstate-648 Wordsmith - various (A, B, C, G, H)

"Sharon Chisholm" <schishol@nortelnetworks.com> Wed, 15 December 2004 18:36 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26356 for <entmib-archive@lists.ietf.org>; Wed, 15 Dec 2004 13:36:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CedeX-000772-Ut; Wed, 15 Dec 2004 13:13:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CedVz-00046o-K0 for entmib@megatron.ietf.org; Wed, 15 Dec 2004 13:04:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23459 for <entmib@ietf.org>; Wed, 15 Dec 2004 13:04:40 -0500 (EST)
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CedeG-0004wg-AX for entmib@ietf.org; Wed, 15 Dec 2004 13:13:16 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iBFI46Z07458 for <entmib@ietf.org>; Wed, 15 Dec 2004 13:04:06 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <YZAC6XQK>; Wed, 15 Dec 2004 13:04:06 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4021DE67C@zcarhxm2.corp.nortel.com>
From: "Sharon Chisholm" <schishol@nortelnetworks.com>
To: entmib@ietf.org
Date: Wed, 15 Dec 2004 13:03:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Subject: [Entmib] entstate-648 Wordsmith - various (A, B, C, G, H)
X-BeenThere: entmib@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Entity MIB WG <entmib.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/entmib>, <mailto:entmib-request@ietf.org?subject=unsubscribe>
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>
Sender: entmib-bounces@ietf.org
Errors-To: entmib-bounces@ietf.org

hi

Rest of #648 to be sent in separate email.

<Juergen>
a) Section says:

Usage state indicates whether or not the entity is in use at a
specific instance, and if so, whether or not it currently has spare
capacity to serve additional users. In the context of this MIB, the
user is equivalent to an entity, so this term is substituted. This
state refers to the ability of the entity to service other entities
within its containment hierarchy.

I think this can be made shorter without loosing significance:

Usage state indicates whether or not the entity is in use at a
specific instance, and if so, whether or not it currently has spare
capacity to serve additional users. In the context of this MIB, the
usage state refers to the ability of an entity to service other 
entities within its containment hierarchy.

But I do not feel strongly about this change. (I just found the
term substitution a bit awkward.)
</Juergen>

I read this a number of times before seeing the difference, but a UNIX diff
showed me that you combined the last two sentences

< user is equivalent to an entity, so this term is substituted. 
< This
< state refers to the ability of the entity to service other entities
< within its containment hierarchy.
---
> usage state refers to the ability of an entity to service other 
> entities within its containment hierarchy.

I suggest we make this change. 

<Juergen>
b) I suggest to replace 'status' with 'states' in the sentence below:

In addition to those alarm status defined in
X.731 [X.731], warning and indeterminate status are also defined to
provide a more complete mapping to the Alarm MIB [Alarm-MIB].
</Juergen>

I suggest we make this change.

<Juergen>
c) I suggest to remove the following sentence from section 2.1:

This raises some interesting issues not addressed
in existing work on state management [X.731].

Rationale: Only one issue is mentioned and not multiple and it is
not really relevant whether X.731 addresses the same issue or not.'
</Juergen>

I propose then that we remove the reference to X.731 and keep the rest of
the sentence. The fact that the addition of hierarchy to the concept of
state is not well understood is an important note given it precedes a
statement indicating that this computed state is out of scope.

<Juergen>
g) In the ENTITY-STATE-TC module, replace

This MIB defines a state textual conventions.

with

This MIB defines state textual conventions.
</Juergen>

I suggest we make this change.

<Juergen>
h) You may want to decide where you like spaces between the name of
and enumerated number and the value or not. Right now, this is done
differently throughout the module.
</Juergen>

Propose consistently putting a space.

Sharon Chisholm
Nortel Networks
Ottawa, Ontario
Canada

_______________________________________________
Entmib mailing list
Entmib@ietf.org
https://www1.ietf.org/mailman/listinfo/entmib