Subject: [Entmib] I-D ACTION:draft-ietf-entmib-state-06.txt

From: [email-masked]
Date: Tue, 04 Jan 2005 15:31:05 -0500

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-06.txt
	Pages		: 19
	Date		: 2005-1-4
	
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 physical entities.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-06.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-entmib-state-06.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.
_______________________________________________
Entmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/entmib

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 16 Jan 2005 08:00:01 -0500

The Entity State MIB has also been updated to address the issues 
raised in WG Last Call (see below).  I've reviewed this document, and 
it seems to contain the changes that were agreed on the list.

This document has also been through several WG Last Calls and should 
be ready for submission to the IESG for Proposed Standard.

So, if you have any objections to submitting this document to the 
IESG for publication as a Proposed Standard RFC, please send them to 
the [email-masked] mailing list by Wednesday, January 19th.

Thanks,
Margaret

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Jan 2005 16:07:27 +0100

> the [email-masked] mailing list by Wednesday, January 19th.

I have checked <draft-ietf-entmib-state-06.txt> and I support
the document being submitted to the IESG. I have some editorial
nits that probably should be addressed before submitting the
document to that the IESG to reduce confusion/trouble/delay
later on.

- IANA Considerations section is missing. See the MIB guidelines
  document about what to put there.

- Reference [RFC2737] should probably be referring to the updated
  ENTITY-MIB (or at least a comment to the RFC Ed. concerning this
  should be added).

- Citations such as [Alarm-MIB] should be replaced with [RFC3877].

- The following sentence in section 3.2. does not read well:

   [...] If there are active alarms, then
   the alarmActiveTable in the Alarm MIB [Alarm MIB] should be searched
   for alarmActiveResourceId that match this entPhysicalIndex.

  Here is a first proposal to improve the wording:

   [...] If there are active alarms, then
   the alarmActiveTable in the Alarm MIB [RFC3877] should be searched
   for rows whose alarmActiveResourceId matches this entPhysicalIndex.

  I think it is important to be clear that there can be multiple
  matching rows.

- The following sentence in section 3.2. is probably not quite right:

   Alternatively, if the alarmActiveTable is queried first and an
   active alarm with a value of alarmActiveResourceId that matches
   this entPhysicalIndex is found, then entStateAlarm can be used to
   quickly determine if there are additional active alarms against
   this physical entity.

  My understanding is that entStateAlarm allows me to detect what kind
  of alarms I have but not how many. So if there are multiple alarms
  of the same severity, then entStateAlarm will not really allow me to
  detect that "there are additional active alarms against this physical
  entity".

   Alternatively, if the alarmActiveTable is queried first and an
   active alarm with a value of alarmActiveResourceId that matches
   this entPhysicalIndex is found, then entStateAlarm can be used to
   quickly determine if there are additional active alarms with a
   different severity against this physical entity.

- Security considerations:

  I suggest to insert "(entStateAdmin)" into the first sentence
  directly after "management object" and remove the second paragraph.

  In addition, I suggest to move the last and next to last paragraph
  directly below the first paragraph in this section so that the MIB
  specific stuff stays together and is not mixed with the more general
  "why you should use SNMPv3" statement.

  Putting things together, I suggest the following text for the
  security considerations section:

   There is one management object (entStateAdmin) defined in this MIB
   that has a MAX-ACCESS clause of read-write. The object may be
   considered sensitive or vulnerable in some network environments.
   The support for SET operations in a non-secure environment without
   proper protection can have a negative effect on network operations.

   Note that setting the entStateAdmin to 'locked' or 'shuttingDown'
   can cause disruption of services ranging from those running on a
   port to those on an entire device, depending on the type of entity.
   Access to this object should be properly protected.

   Access to the objects defined in this MIB allows one to figure out
   what the active and standby resources in a network are. This
   information can be used to optimize attacks on networks so even
   read-only access to this MIB should be properly protected.

   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 (entities) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 21 Jan 2005 08:48:11 -0500

Thanks, Juergen!  These comments are clear and actionable, and 
addressing them will certainly improve the quality of the document.

Sharon, can you do a quick spin to make these changes, and we will 
submit the resulting
document to the IESG?

Thanks,
Margaret