[Entmib] FW: [psg.com #78] AutoReply: Collection of Editorial Comments

"Sharon Chisholm" <schishol@nortelnetworks.com> Mon, 24 November 2003 21:03 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29663 for <entmib-archive@lists.ietf.org>; Mon, 24 Nov 2003 16:03:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONrJ-0001G4-Ma; Mon, 24 Nov 2003 16: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 1AONr3-0001FP-SK for entmib@optimus.ietf.org; Mon, 24 Nov 2003 16:02:45 -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 QAA29600 for <entmib@ietf.org>; Mon, 24 Nov 2003 16:02:31 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONr2-0004df-00 for entmib@ietf.org; Mon, 24 Nov 2003 16:02:44 -0500
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AONr1-0004d9-00 for entmib@ietf.org; Mon, 24 Nov 2003 16:02: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 hAOL2Bt29701 for <entmib@ietf.org>; Mon, 24 Nov 2003 16:02:11 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <XLSTARB1>; Mon, 24 Nov 2003 16:02:10 -0500
Message-ID: <3549C09B853DD5119B540002A52CDD34095D4A3C@zcard0ka.ca.nortel.com>
From: Sharon Chisholm <schishol@nortelnetworks.com>
To: entmib@ietf.org
Date: Mon, 24 Nov 2003 16:02:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [Entmib] FW: [psg.com #78] AutoReply: Collection of Editorial 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: <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

Proposed Resolution to ent-state-78:


Replace all instances of "entity MIB" with "Entity MIB"

Every time an enumeration name is used within a description, it will be
quoted - 'unsupported' for example.

In section 2, replace

"
   The goal in adding state objects to the Entity MIB [RFC2737] is to
   define a useful subset of the possible state attributes that could
   be tracked for a given entity that both fit into the existing IETF
   model, as well as leveraged existing well-deployed models.  "

With

"
   The goal in adding state objects to the Entity MIB [RFC2737] is to
   define a useful subset of the possible state attributes that could
   be tracked for a given entity that both fit into the state models
   such as those used in the Interfaces MIB [RFC2863]
   as well as leverage existing well-deployed models.  "

In section 2.1 replace

"Physical entities exist within a containment hierarchy. This raises
   some interesting issues not addresses in existing work on state
   management [X.731]."

With

"Physical entities exist within a containment hierarchy. This raises
   some interesting issues not addressed in existing work on state
   management [X.731]."

In section 2.2 replace

"describes what each of these combinations of states means. It also
   compare this combination of states to that of the ifAdminStatus and"

With


"describes what each of these combinations of states means. It also
   compares this combination of states to that of the ifAdminStatus and
"

In section 2 replace

"
   capacity to serve additional users. In the context of this MIB, the
   user is equivalent to an entity, so this term us substituted."

With

"
   capacity to serve additional users. In the context of this MIB, the
   user is equivalent to an entity, so this term is substituted." 

In section 2.2 replace

"
   The Interfaces MIB [RFC2863] defines the ifAdminStatus object, which
   has status of up, down and testing and the ifOperStatus object,
   which has states of up, down, testing, unknown, dormant, notPresent
   and lowerLayerDown."

With

"
   The Interfaces MIB [RFC2863] defines the ifAdminStatus object, which
   has states of up, down and testing and the ifOperStatus object,
   which has states of up, down, testing, unknown, dormant, notPresent
   and lowerLayerDown."

Delete section 2.3 (Physical Classes and States" and ensure that the
descriptions of the objects are sufficiently clear.
 
I'm not sure which key word is not capitalized in section 2.4 (item B12)

In the definition of AlarmStatus replace:

"
                warning (6), -- Not defined in X.731
                indeterminate (7) -- Not defined in X.731
"

With

"               -- The following are Not defined in X.731
                warning (6),
                indeterminate (7)
"




Add in new Intellectual Property section as follows:

"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.

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."
 
Sharon
-----Original Message-----
From: entity-state [mailto:rt+entity-state@rt.psg.com] 
Sent: Tuesday, July 15, 2003 4:29 AM
To: Chisholm, Sharon [CAR:0S00:EXCH]
Subject: [psg.com #78] AutoReply: Collection of Editorial Comments

<clip>

-------------------------------------------------------------------------
Romascanu, Dan (Dan) [dromasca@avaya.com]

"Editorial Comments
B1) Intellectual Property section is missing
B2) Entity MIB and entity MIB are capitalized in an un-consistent 
manner in the document. I suggest to use Entity MIB all over, starting 
with the Abstract section.
B3) What is the 'existing IETF model' mentioned in the first paragraph 
of Section 2?
B4) Also in the first paragraph in Section 2, replace 'leveraged' 
by 'leverage'.
B5) Section 2.1, first paragraph - replace 'addresses' by 'addressed'
B6) Section 2.2 'compares' instead of 'compare'
B7) I understand that 'state' and 'status' are interchangeable in this 
document, but from a style point of view, the same noun should be used 
in the same phrase. See second paragraph in 2.2
B8) All section 2.3 should be better organized. The way it is written, 
it is not clear why some values are being omitted. It would be useful 
to re-write it in a tabular manner, and be specific what values are 
relevant for each entPhysicalType and each object.
B9) replace 'chassis' by 'container'
B10) 2.3.5.2 is incomprehensible
B11) 2.3.9.1, 2.3.9.2 - replace 'system' by 'stack'. 
B12) 2.4. - key word not capitalized
B13) several DESCRIPTION clauses in the MIB would gain in readability 
if enumerated value significance is written in separated lines"

Juergen Schoenwaelder [schoenw@ibr.cs.tu-bs.de]

'a) Typo in section 2: "so this term us substituted".

b) Typo in section 2.1: "interesting issues not addresses in existing 
work"

c) Typo in section 2.2: "It also compare this combination of states" '

'

e) entStatAdmin is actually entStateAdmin
'

Subrahmanya Hegde [subrah@cisco.com]:

 Convention followed in many RFC MIBs is :   The enumeration name used
in the DESCRIPTION should be specified in quotes
'disabled' 'unsupported' etc. In my opinion, it will increase the
readability.

Is it possible you make these editorial changes?

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