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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 20 Sep 2010 15:28:16 +0200

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

---

From: Benoit Claise <[email-masked]>
Date: Mon, 20 Sep 2010 16:04:24 +0200

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.
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 20 Sep 2010 16:14:44 +0200

I am copying David Harrington who was the AD who raised the issue (if I
remember well). 

>     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

	     
	        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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 20 Sep 2010 16:15:10 +0200

Dan

	Dan,

	     

	
	Regards, Benoit.

		Thanks and Regards,
		
		Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Sep 2010 16:36:07 +0200

On Mon, Sep 20, 2010 at 04:14:44PM +0200, Romascanu, Dan (Dan) wrote:
> I am copying David Harrington who was the AD who raised the issue (if I remember well).
> 
> You say in the I-D:
> 
> But the UPS MIB as per 1628 is written in SMI (v1). So an update of 1628 seems to be necessary.

I fail to follow the reasoning. First of all, please convince yourself
that RFC 1628 is written in SMIv2 - it is not in SMIv1 format.
Furthermore, the rfc-index says it is INFORMATIONAL - so it is not
even on the standards-track (despite the category claimed in the
document itself).

Yes, the MIB module has some flaws but this is known for a long time
and unrelated to the WG being chartered here. So why should this WG be
responsible to do something about this situation?

I also note that I have seen this MIB implemented in real-world UPS
devices. So why should this moved to historic? Why do we have to touch
this at all? Are there any UPS implementors here asking to revise or
fix this MIB module? Then they should probably speak up.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 20 Sep 2010 16:47:49 +0200

See in-text. 

Regards,

Dan

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Monday, September 20, 2010 4:36 PM
> To: Romascanu, Dan (Dan)
> Cc: Benoit Claise; [email-masked]
> I fail to follow the reasoning. First of all, please convince 
> yourself that RFC 1628 is written in SMIv2 - it is not in 
> SMIv1 format.

You are right - I stand corrected on this one. 

> Furthermore, the rfc-index says it is INFORMATIONAL - so it 
> is not even on the standards-track (despite the category 
> claimed in the document itself).
> 
> Yes, the MIB module has some flaws but this is known for a 
> long time and unrelated to the WG being chartered here. So 
> why should this WG be responsible to do something about this 
> situation?

Because its scope is as close as any WG will get to 1628, and if these
flaws need a fix it's probably now or never. 

Can you help list them? 

> 
> I also note that I have seen this MIB implemented in 
> real-world UPS devices. So why should this moved to historic? 

Historic was the option in case the MIB is not implemented in
real-world. 

> Why do we have to touch this at all? Are there any UPS 
> implementors here asking to revise or fix this MIB module? 
> Then they should probably speak up.
> 

That's indeed the time.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Sep 2010 17:00:18 +0200

> flaws need a fix it's probably now or never. 

The serious problems:

- macro `TEXTUAL-CONVENTION' has not been imported from module `SNMPv2-TC'
- unknown object identifier label `mib-2' (missing import)
- upsShutdownAfterDelay range limit exceeds underlying basetype
- upsStartupAfterDelay range limit exceeds underlying basetype
- object `upsAlarmId' should be 'accessible-for-notify'
- broken enumeration values in conformance definitions
  (normal(2), battery(4))
- nodes not covered by conformance statements

I am attaching the full output of smilint. Most of these issues are
really easy to fix. But once you open the MIB module, you might get
semantic change proposals and then it is hard to set a limit. And
given that this document appears to be informational...

/js

---

From: Jon Saperia <[email-masked]>
Date: Mon, 20 Sep 2010 13:48:15 -0400

The UPS MIB does have value, though an update may be in order.  I agree, that should be part of the charter.  While on that subject, I suggest people look at the Smart Battery Data Specification.  I know of at least one SNMP implementation that uses this as a base.  It might even be useful in a reconsideration of the UPS MIB Module.
On Sep 20, 2010, at 10:04 AM, Benoit Claise wrote:

> From http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-05#section-7.4
>   
>         UPS MIB [RFC1628] provides information on the state of the UPS
> Do you need an answer before the WG creation, or could it be an open item for the charter?
> 
> Regards, Benoit.

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 20 Sep 2010 18:34:02 +0000

I would rather suggest that we do not include the UPS MIB
in the charter right now.

We should make progress on the Battery MIB module first.
If we have a stable version of it, we can check if the UPS MIB
would benefit from an update and consider it as a future work item.

    Juergen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Sep 2010 21:40:41 +0200

> would benefit from an update and consider it as a future work item.

Full support for this from me.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 20 Sep 2010 21:45:07 +0200

As a contributor I agree. 

As AD I would like to hear whether there are different opinions. 

Thanks and Regards,

Dan

> Sent: Monday, September 20, 2010 9:41 PM
> To: Juergen Quittek
> Cc: Romascanu, Dan (Dan); David B Harrington; [email-masked]
> > I would rather suggest that we do not include the UPS MIB in the 
> > charter right now.
> > 
> > If we have a stable version of it, we can check if the UPS 
> MIB would 
> > benefit from an update and consider it as a future work item.
>

---

From: Benoit Claise <[email-masked]>
Date: Tue, 21 Sep 2010 08:47:47 +0200

Jon,

Are you referring to http://sbs-forum.org/specs/sbdat110.pdf?

Regards, Benoit.
> The UPS MIB does have value, though an update may be in order.  I 
> agree, that should be part of the charter.  While on that subject, I 
> suggest people look at the Smart Battery Data Specification.  I know 
> of at least one SNMP implementation that uses this as a base.  It 
> might even be useful in a reconsideration of the UPS MIB Module.
>> [email-masked] <mailto:[email-masked]>

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 20 Sep 2010 16:03:51 -0400

Hi,

Benoit's reply shows that the relation to UPS-MIB was considered.
JuergenQ's replay indicates that updating UPS-MIB, or its status, is
not proposed to be in scope at this point.

That answers my questions.
Thanks,
dbh

> From: Juergen Quittek [mailto:[email-masked]] 
> Sent: Monday, September 20, 2010 2:34 PM
> To: Juergen Schoenwaelder; Dan Romascanu
> Cc: David B Harrington; [email-masked]
> I would rather suggest that we do not include the UPS MIB in 
> the charter right now.
> 
> MIB would benefit from an update and consider it as a future 
> work item.
> 
>     Juergen
> 
> 
> >>> and unrelated to the WG being chartered here. So why 
> should this WG 
> >>> be responsible to do something about this situation?
> >> 
> >> Because its scope is as close as any WG will get to 1628, and if 
> >> these flaws need a fix it's probably now or never.
> >> 
> >> Can you help list them?
> > 
> > The serious problems:
> >

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 20 Sep 2010 15:59:10 -0400

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

 
But the UPS MIB as per 1628 is written in SMI (v1). So an update of
1628 seems to be necessary. 
 
Dan

  _____  

Dan,

This has been our investigation so far.
From
http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-05#secti
on-7.4

     

        To protect against unexpected power disruption, data centers
and

        buildings make use of Uninterruptible Power Supplies (UPS).
To

        restored.  Planning is required to decide on the capacity of
UPS

        entity (name, model,..), the upsBattery group - to indicate
the

        ...), upsInput group - to characterize the input load to the
UPS

        voltage, current,...), upsAlarms - to indicate the various
alarm

        events.  The measurement of power in UPS MIB are in Volts,
Amps

        Both the Power and Energy Monitoring MIB and the UPS MIB may
be

        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.

Thanks and Regards,

Dan

eman mailing list

[email-masked]

---

From: Benoit Claise <[email-masked]>
Date: Tue, 21 Sep 2010 08:36:50 +0200

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.

>     ------------------------------------------------------------------------
>     *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?
>
>         ------------------------------------------------------------------------
>         *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,
>

---

From: Jon Saperia <[email-masked]>
Date: Tue, 21 Sep 2010 07:20:29 -0400

Yes, that is exactly correct. While there is a good deal of similarity between this spec and objects in the UPS Module (a good thing) there are some differences.  Whatever group decides to take up the issue should evaluate these differences and missing attributes to see if they matter. 

Thanks,

Jon Saperia
JDS Management Software, Inc.
[email-masked]
(office) 978-461-0249
(mobil) 617-201-2655