Re: Mini WG LAST CALL:draft-ietf-entmib-state-06.txt

On Sun, Jan 16, 2005 at 08:00:01AM -0500, Margaret Wasserman wrote:

> 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 protected] 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