Subject: [eman] draft-claise-energy-monitoring-mib-08.txt

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Tue, 24 May 2011 02:44:55 -0500

Hello all, 

Based on the conclusions from the EMAN WG meeting at Prague,
http://www.ietf.org/proceedings/80/minutes/eman.txt  ,

a major revision of the merged Monitoring MIB draft has been submitted
and the new version can be found at
http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-08

The diff can be seen at
http://tools.ietf.org/rfcdiff?url2=draft-claise-energy-monitoring-mib-08
.txt  .

Among other changes, the draft provides support for multiple Power State
Series and an IANA considerations section describing the procedure for
adding new Power State Series and Power States within the series. Many
thanks to all who provided comments.

Changes:

-    Definition of Power State and Power State Series Terminology 

o   3 Power State Series - IEEE1621, DMTF and EMAN have been proposed

o   Description of the Power States in IEEE1621 and DMTF Power State
Series

-    A new section on IANA considerations for adding new Power State
Series and Power States within the series 

o   Textual convention for PowerStateSeries (that can be administered by
IANA)

-    Use cases section has been moved to EMAN Applicability Statement
draft and a sample scenario is presented in this draft

-    MIB OID content

o   MIB OID Tree is presented - to be inline with the EMAN battery MIB

o   UML diagram for the EMAN Monitoring MIB - to be inline with EMAN
Energy-Aware-MIB

-    A section on discovery Power States supported by a device -
with/without implementation of Energy-Aware-MIB

-    pmPowerTable indexed by pmPowerIndex and pmPowerStateSeriesIndex

o   pmPowerRequestedState renamed as pmPowerAdminState;
pmPowerActualState renamed as pmPowerOperState - to be inline with the
ifTable in RFC2863

o   pmPowerManufacturerActualPowerState and pmPowerManufacturerMappingId
have been removed 

o   since there are 3 Power States Series, the Manufacturer Power States
have been removed and as a consequence, the pmPowerStateMappingTable has
been removed 

-    pmPowerStateTable indexed by pmPowerIndex, pmPowerStateSeriesIndex
and pmPowerStateIndex

-    Notifications generated whenever there is change in
pmPowerStateSeries, pmPowerAdminState, pmPowerOperState,
pmPowerStateEnterReason 

-    Many rewording to improve readability

-    Once EMAN-REQ draft has been submitted, this draft may be revised. 

Your comments welcome.

Thanks

Mouli

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 May 2011 11:36:47 +0200

> thanks to all who provided comments.

        PowerStateSeries ::= TEXTUAL-CONVENTION
            STATUS          current
            DESCRIPTION
               "PowerStateSeries is a TC that describes the Power State
               Series a Power Monitor supports. IANA has created a
               registry of Power State Series supported by a Power
               Monitor entity and IANA shall administer the list of
               Power State Series.

               One byte is used to represent the Power State Series.

                      field  octets  contents             range
                      -----  ------  --------             -----
                       1       1     Power State Series   1..255

               Note:
                   the value of Power State Series in network byte
               order

               1 in the first byte indicates IEEE1621 Power State
               Series
               2 in the first byte indicates DMTF Power State Series
               3 in the first byte indicates EMAN Power State Series

             REFERENCE
                    "http://www.iana.org/assignments/eman"
                    "RFC EDITOR NOTE: please change the previous URL
                     if this is not the correct one after IANA assigned
                     it."

             SYNTAX      OCTETSTRING (SIZE(1))

Why is this an OCTET STRING (SIZE(1)) and not simply an enumerated
INTEGER? And if this is to be maintained by IANA, why not create a
IANA-POWER-SERIES-TC MIB module so that one can simply fetch the
latest version from IANA?

   New assignments in Power State Series require a Standards Action
   [RFC5226], i.e., they are to be made via Standards Track RFCs
   approved by the IESG.

This raises the bar pretty high. If some future organization defines
popular power states, do you think someone is going to go through the
trouble of producing a standards-track specification for this?

I also do not see why all objects in the pmPowerEntry are necessarily
indexed by power series - some appear to me to be rather a property of
the monitor and not the power state series the monitor happens to
support.

I also like to see more text moved from the document into DESCRIPTION
clauses. This in particular concerns the actual power state values.
There is no way to find out what power state 2 in power state series 1
means if all you have are MIB modules.

And lastly, I still prefer a design where the power states are simply
enumerated. Since you require a standard-track action to allocate a
new series and you reserved 8 bits for power state series, I fail to
see why a simple TC can not do the job equally well.

Since I started looking at the IANA considerations, I believe this text
needs to be removed:

        Additions to the MIB modules are subject to Expert Review
        [RFC5226], i.e., review by one of a group of experts designated
        by an IETF Area Director.  The group of experts MUST check the
        requested MIB objects for completeness and accuracy of the
        description.  Requests for MIB objects that duplicate the
        functionality of existing objects SHOULD be declined.  The
        smallest available OIDs SHOULD be assigned to the new MIB
        objects.  The specification of new MIB objects SHOULD follow the
        structure specified in Section 10.  and MUST be published using
        a well-established and persistent publication medium.

IETF MIB modules are not modified by Expert Review. This text looks
inconsistent with existing practice in maintaining IETF MIB modules.

/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/>