Subject: [eman] Fwd: Re: RFC 1628 - update or Historical?

From: Benoit Claise <[email-masked]>
Date: Tue, 21 Sep 2010 09:18:45 +0200

[Resent. Not sure if there is something wrong with this mailer, but 
this email does appear on the list, while an email sent later already 
arrived]

Hi Dave,

New work around the UPS-MIB might be required.
However, if we try to conclude _now _that we need to update it or put it 
to historical, then we draw the conclusions before actually doing the 
EMAN work.

For example, will the BATTERY-MIB (item number 5 in the current charter 
proposal) be a subset or a superset of this UPS-MIB? I don't know yet!
For example, in this MIB proposal 
http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-05, there 
is a variable.

             pmPhysicalEntity OBJECT-TYPE
                 SYNTAX          PhysicalIndexOrZero
                 MAX-ACCESS      read-only
                 STATUS          current
                 DESCRIPTION
                    "This object contains the index of a physical entity in
                    the ENTITY MIB.  This physical entity is the given
                    observation point.  If such a physical entity cannot be
                    specified or is not known then the object is zero."
                 ::= { pmEntry 3 }

Basically, it says: "if the Entity-MIB is implement, here is the pointer 
to it". Maybe a single trick like this for the UPS-MIB would be enough. 
I don't know yet.

An extra sentence in the charter such as "this WG should consider exist 
IETF RFCs such as UPS-MIB, ...." would not hurt.
IMHO, "consider" is all that we can do at this point.
Note that we already consider this MIB. Look at the 
http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-01 table 
of content:

      5.1  <http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-01#section-5.1>.  Existing IETF Standards  . . . . . . . . . . . . . . . . .13  <http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-01#page-13>
        5.1.1  <http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-01#section-5.1.1>.  ENTITY STATE MIB . . . . . . . . . . . . . . . . . . .13  <http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-01#page-13>
        5.1.2  <http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-01#section-5.1.2>.  ENTITY SENSOR MIB  . . . . . . . . . . . . . . . . . .13  <http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-01#page-13>
        5.1.3  <http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-01#section-5.1.3>.  UPS MIB  . . . . . . . . . . . . . . . . . . . . . . .14  <http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-01#page-14>
        5.1.4  <http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-01#section-5.1.4>.  POWER ETHERNET MIB . . . . . . . . . . . . . . . . . .14  <http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-01#page-14>
        5.1.5  <http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-01#section-5.1.5>.  LLDP MED MIB . . . . . . . . . . . . . . . . . . . . .14  <http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-01#page-14>

Regards, Benoit.

> Hi,
> When the IESG/IAB consider WG proposals, one of the aspects we look at 
> is the scope of the planned work, as specified in the charter.
> A second aspect we consider is what effect the new work will have on 
> existing IETF documents.
> A UPS is part of energy management, and the UPS-MIB is existing IETF 
> work, but the charter didn't mention it.
> I asked whether updating the UPS-MIB was part of the planned scope, 
> and whether including it in scope had been considered.
> I asked whether the new work would render the existing UPS-MIB 
> obsolete, possiblly requiring it to be declared Historic.
> dbh
>
>     ------------------------------------------------------------------------
>     *From:* Romascanu, Dan (Dan) [mailto:[email-masked]]
>     *Sent:* Monday, September 20, 2010 10:15 AM
>     *To:* Benoit Claise
>     *Cc:* [email-masked]; David B Harrington
>     *Subject:* RE: [eman] RFC 1628 - update or Historical?
>
>     I am copying David Harrington who was the AD who raised the issue
>     (if I remember well).
>     You say in the I-D:
>     >     Both the Power and Energy Monitoring MIB and the UPS MIB may be
>             implemented on the same UPS SNMP agent, without conflict.
>     But the UPS MIB as per 1628 is written in SMI (v1). So an update
>     of 1628 seems to be necessary.
>     Dan
>
>         ------------------------------------------------------------------------
>         *From:* Benoit Claise [mailto:[email-masked]]
>         *Sent:* Monday, September 20, 2010 4:04 PM
>         *To:* Romascanu, Dan (Dan)
>         *Cc:* [email-masked]
>         *Subject:* Re: [eman] RFC 1628 - update or Historical?
>
>         Dan,
>
>         This has been our investigation so far.
>         From
>         http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-05#section-7.4
>
>            
>
>
>               7.4. Link with the UPS MIB
>
>
>
>                  To protect against unexpected power disruption, data centers and
>                  buildings make use of Uninterruptible Power Supplies (UPS).  To
>                  protect critical assets, a UPS can be restricted to a particular
>                  subset or domain of the network.  UPS usage typically can last
>                  only for a finite period of time, until normal power supply is
>                  restored.  Planning is required to decide on the capacity of UPS
>                  based on output power and duration of probable power outage.
>                  From a power provisioning point of view of a data center or
>                  building, it is important to understand the total demand
>                  required to support all the entities in order to plan on the
>                  capacity of the UPS to be installed.  This demand can be
>                  monitored via the Power and Energy Monitoring MIB.
>
>                  UPS MIB [RFC1628  <http://tools.ietf.org/html/rfc1628>] provides information on the state of the UPS
>                  network.  Implementation of UPS MIB is useful at the aggregate
>                  level of a data center or a building.  The MIB module contains
>                  several groups of variables - upsIdent - to identify the UPS
>                  entity (name, model,..), the upsBattery group - to indicate the
>                  battery state, (upsbatteryStatus, upsEstimatedMinutesRemaining,
>                  ...), upsInput group - to characterize the input load to the UPS
>                  (number of input lines, voltage, current,...) , upsOutput - to
>                  characterize the output from the UPS (number of output lines,
>                  voltage, current,...), upsAlarms - to indicate the various alarm
>                  events.  The measurement of power in UPS MIB are in Volts,  Amps
>                  and Watts.  The units of power measurement are RMS volts, RMS
>                  Amps and are not based on EntitySensorDataScale and
>                  EntitySensorDataPrecision of Entity-Sensor MIB.
>
>                  Both the Power and Energy Monitoring MIB and the UPS MIB may be
>                  implemented on the same UPS SNMP agent, without conflict.  In
>                  such a case, the UPS device itself would be the Power Monitor
>                  Parent and any the UPS meters or submeters would be the Power
>                  Monitor Children.
>
>         However, we didn't look at this from an update/historical
>         point of view.
>         Do you need an answer before the WG creation, or could it be
>         an open item for the charter?
>
>         Regards, Benoit.
>>         I would like to remind the eman community that during the IESG review
>>         the question was asked whether the future WG would be interested to
>>         update the UPS MIB (RFC 1628) or to discuss its transition to
>>         Historical. Please address this.
>>
>>         Thanks and Regards,
>>
>>         Dan
>>         _______________________________________________
>>         eman mailing list
>>         [email-masked]
>>         https://www.ietf.org/mailman/listinfo/eman
>