Subject: Re: [eman] iana powerstate tc proposal

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Wed, 9 Nov 2011 15:53:07 -0600

> Dear all, 
> 
> Based on the feedback from the mailing list, we can conclude that the Juergen's
> TC proposal should be included in the next version of the draft.
> 
> Regards, Benoit.

I am fine with the general scheme advanced by Juergen S. for the encoding of powerstates into a single integer.  I am including below an updated version of his text which includes some minor grammatical corrections/clarifications and I have updated the numeric values to actually correspond to the scheme articulated in the text as I believe they were incorrect in Juergen's version (unless I misunderstand the proposed scheme).

I do have some additional questions which should be clarified somewhere so that the expectations around the use and implementation of state sets is made more clear.  If the following points have already been addressed in the updated drafts please excuse my tardiness and point me to the proper place.  (I am first catching up with the mailing list and will then read the updated drafts.)

(1) Support for multiple power state sets.

It is my understanding that we intend to allow, but not require, a given device to support multiple power state sets.  Looking back it seems that there was some question about whether the device was allowed to support those multiple power state sets *concurrently*.  I take *concurrently* to mean that some device, A, may be interacting with multiple managers, B and C, at the same time using different power state sets for each.  The implication is that temporally device A may receive interleaved powerstate commands/queries from managers B and C.  It is my understanding that we intend to allow this scenario.  Is that agreed?

Assuming that we intend to allow a device to support multiple *concurrent* powerstate sets this raises the question of what we should say or expect of such a device in that case.  I don't believe that we have reached a consensus on this point, but I could be wrong.

My personal position is that in this scenario the minimum requirement to be placed on a device is that it must remain *internally consistent* regardless of which powerstate sets are being accessed and regardless of how the requests are interleaved.  By internally consistent I mean that if manager B interacts using IEE1621 powerstates that the manager should be able to assume that the device will behave reasonably within the expectations of that powerstate set regardless of what manager C might do.  Likewise, if manager C intereacts using DMTF powerstates that it should be able to assume that the device will behave reasonably within the expectations of that powerstate set regardless of what manager B might do.

Obviously this implies an internal mapping between the individual states of the difference supported powerstate sets.  I believe that we are agreed that the EMAN standards will not be able to formalize that mapping, or else would would be able to define the elusive universal powerstate set.  This means that the mapping will necessarily be device and implementation specific.  The best that we can say within the EMAN standards is that a device is required to implement some mapping and to allow a given manager to interact with it safely within the context of a single powerstate set without regard to what other managers might be doing in other powerstate sets.  Is this agreed?

Alternatively we could allow support for multiple powerstate sets but only allow one to be used "at a time".  The definition of "at a time" would need to be clarified and mechanisms for negotiating which of the multiple sets is to be used would need to be defined.  Timescales and rules for how to transition between sets would also likely be required.  This scenario implies the need for some form of exclusion mechanism to prevent concurrent access from the multiple sets.  If this is what is desired then there are additional mechanisms which need to be defined to make it practical.  Is anyone advocating for this approach?

(2) Support for a versioning mechanism.

I am unfamiliar with how these IANA registry based agreements are typically handled, but it seems to me that if the IANA registry can be updated to include additional powerstate sets, or even more importantly to add or remove states from an existnig powerstate set, that some means of coordinating which version of the IANA document or instance of a powerstate set is being supported by a given device.  We need to be able to address the case where a device supports the (hypothetical) Version 1 of the DMTF powerstate set but the manager supports the (hypothetical) Version 2 of the DMTF powerstate set.  We could ignore this issue and thus delegate it to being a matter to be documented and verified by humans at procurement time, or we could provide a means for programmatic discovery and validation.  Obviously the latter is preferred from the perspective of allowing the managers and devices to automatically discover such mismatches.

Do others have any thoughts on how this could or should be accomplished?  What impacts would this have on the details in Juergen's proposal and the IANA managed document?

Thanks,

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
224 Brookhill Drive
Gahanna, OH  43230
Email: [email-masked]
Phone: 614 718 6308

Here is a modified version of Juergen's proposal which I believe fixes some minor inconsistencies in the numbering.  I have updated the description slightly to make the definition (hopefully) more clear.  This results in the "index" of the states within a given set starting at 1 instead of 0 as Juergen's original proposal indicated with his example numbering.  If we prefer to have the "index" begin at 0 for some reason this can be easily accomplished but it means that the special value for the set identifier must move to 255 as Juergen had in his original example numbering, but that would imply the "set indicator value" in the description would need to be adjusted to (S + 1) * 256 - 1 which I believe is less desirable.  Should the description mention the fact that the first block of 256 is "reserved" for special values?

IANA-POWER-STATE-MIB DEFINITIONS ::= BEGIN 

IMPORTS
    MODULE-IDENTITY, mib-2           FROM SNMPv2-SMI
    TEXTUAL-CONVENTION               FROM SNMPv2-TC;

ianaRtProtoMIB  MODULE-IDENTITY
    LAST-UPDATED "201107280000Z" -- July 28, 2011
    ORGANIZATION "IANA"
    CONTACT-INFO
            "Internet Assigned Numbers Authority
             Internet Corporation for Assigned Names and Numbers
             4676 Admiralty Way, Suite 330
             Marina del Rey, CA 90292-6601

             Phone: +1 310 823 9358
             EMail: iana&iana.org"
    DESCRIPTION
            "TBD"

    REVISION     "201107280000Z"  --  July 28, 2011
    DESCRIPTION  "Original version, published in coordination
                  with RFC XXXX."

    ::= { mib-2 XXXX }

IANAPowerStateSet ::= TEXTUAL-CONVENTION 
    STATUS	current 
    DESCRIPTION 

        "IANAPowerState is a textual convention that describes Power
         State Sets and Power State Set Values a Power Monitor
         supports. IANA has created a registry of Power State Sets supported
         by a Power Monitor entity and IANA shall administer the list
         of Power State Sets and Power States.

         The textual convention assumes that power states in a power
         state set are limited to 255 distinct values. For a Power
         State Set S (where S >= 1), the named number with the value S * 256 is
         allocated to indicate the identity of the power state set. For a 
         Power State X (where 1 <= X <= 255) in the Power State Set S, the named 
         number with the value S * 256 + X is allocated to represent that 
         distinct power state."
                
    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      INTEGER {
            unknown(0),             -- unknown power state
            other(255),             -- indicates other set

            ieee1621(256),          -- indicates IEEE1621 set (S=1)
            ieee1621On(257),        -- X=1
            ieee1621Off(258),       -- X=2
            ieee1621Sleep(259),     -- X=3

            dmtf(512),              -- indicates DMTF set (S=2)
            dmtfOn(513),
            dmtfSleepLight(514),
            dmtfSleepDeep(515),
            dmtfOffHard(516),
            dmtfOffSoft(517),
            dmtfHibernate(518),
            dmtfPowerOffSoft(519),
            dmtfPowerOffHard(520),
            dmtfMasterBusReset(521),
            dmtfDiagnosticInterrapt(522),
            dmtfOffSoftGraceful(523),
            dmtfOffHardGraceful(524),
            dmtfMasterBusResetGraceful(525),
            dmtfPowerCycleOffSoftGraceful(526),
            dmtfPowerCycleHardGraceful(527),

            eman(768),              -- indicates EMAN set (S=3)
            emanTBD(769)
        }

END

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Thu, 10 Nov 2011 02:48:43 -0600

Hi Bill,

Thanks for the email and your comments. 

1. support of multiple power state sets - your first line is also my
understanding - it was observed that the EMAN standard should allow (but
not require) a device 
to support multiple power state sets. As you have observed, this seems
the pragmatic approach given the universally agreed (but seems elusive)
power state 
set is not defined yet. 

In the case a device has implemented multiple power state sets, as you
have indicated, there should be a clear/unambiguous mapping between the
power state sets for the two EMS to monitor the network as you have
indicated. 

    1.1 . In a multi-vendor network (let us think of multi-vendor
switching network which also support multiple power state sets) 
      it is possible that the mapping between IEEE1621 and DMTF can be
different between vendors.  In that case, the EMS-B and EMS-C should
take those 
      vendor specific mappings into account to have a clear picture of
the network. 

2. IANA versioning of power states - the first part of your question
seems simpler. 

The Textual convention of the most recent power state set shall be
maintained at http://www.iana.org/assignments/eman 
The process for additions or updates to the IANA registry are covered in
Section 12.2. 

The second part of the question - 

In the heterogeneous situation you have mentioned is interesting and
important -   some devices using Power States from version 1 of DMTF and
some newer devices supporting Power State sets DMTF version 2. Let us
assume a new power state state is introduced in the middle between -
dmtfOffHard (516), and dmtfOffSoft(517)

There are a couple of options - 
 -  2.1. it is possible to have DMTF1 - as a power state set (not
deprecate this) and DMTF2 as a new power state set and registered with
IANA. 
 -  2.2. it is possible to deprecate DMTF1 as a power state set and
report the device is other(0) power state set. 

I think the first approach (2.1) is preferable. 

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mielke, William F (Bill)
Sent: Thursday, November 10, 2011 3:23 AM
To: [email-masked]
Subject: Re: [eman] iana powerstate tc proposal

> TC proposal should be included in the next version of the draft.

I am fine with the general scheme advanced by Juergen S. for the
encoding of powerstates into a single integer.  I am including below an
updated version of his text which includes some minor grammatical
corrections/clarifications and I have updated the numeric values to
actually correspond to the scheme articulated in the text as I believe
they were incorrect in Juergen's version (unless I misunderstand the
proposed scheme).

I do have some additional questions which should be clarified somewhere
so that the expectations around the use and implementation of state sets
is made more clear.  If the following points have already been addressed
in the updated drafts please excuse my tardiness and point me to the
proper place.  (I am first catching up with the mailing list and will
then read the updated drafts.)

It is my understanding that we intend to allow, but not require, a given
device to support multiple power state sets.  Looking back it seems that
there was some question about whether the device was allowed to support
those multiple power state sets *concurrently*.  I take *concurrently*
to mean that some device, A, may be interacting with multiple managers,
B and C, at the same time using different power state sets for each.
The implication is that temporally device A may receive interleaved
powerstate commands/queries from managers B and C.  It is my
understanding that we intend to allow this scenario.  Is that agreed?

Assuming that we intend to allow a device to support multiple
*concurrent* powerstate sets this raises the question of what we should
say or expect of such a device in that case.  I don't believe that we
have reached a consensus on this point, but I could be wrong.

My personal position is that in this scenario the minimum requirement to
be placed on a device is that it must remain *internally consistent*
regardless of which powerstate sets are being accessed and regardless of
how the requests are interleaved.  By internally consistent I mean that
if manager B interacts using IEE1621 powerstates that the manager should
be able to assume that the device will behave reasonably within the
expectations of that powerstate set regardless of what manager C might
do.  Likewise, if manager C intereacts using DMTF powerstates that it
should be able to assume that the device will behave reasonably within
the expectations of that powerstate set regardless of what manager B
might do.

Obviously this implies an internal mapping between the individual states
of the difference supported powerstate sets.  I believe that we are
agreed that the EMAN standards will not be able to formalize that
mapping, or else would would be able to define the elusive universal
powerstate set.  This means that the mapping will necessarily be device
and implementation specific.  The best that we can say within the EMAN
standards is that a device is required to implement some mapping and to
allow a given manager to interact with it safely within the context of a
single powerstate set without regard to what other managers might be
doing in other powerstate sets.  Is this agreed?

Alternatively we could allow support for multiple powerstate sets but
only allow one to be used "at a time".  The definition of "at a time"
would need to be clarified and mechanisms for negotiating which of the
multiple sets is to be used would need to be defined.  Timescales and
rules for how to transition between sets would also likely be required.
This scenario implies the need for some form of exclusion mechanism to
prevent concurrent access from the multiple sets.  If this is what is
desired then there are additional mechanisms which need to be defined to
make it practical.  Is anyone advocating for this approach?

I am unfamiliar with how these IANA registry based agreements are
typically handled, but it seems to me that if the IANA registry can be
updated to include additional powerstate sets, or even more importantly
to add or remove states from an existnig powerstate set, that some means
of coordinating which version of the IANA document or instance of a
powerstate set is being supported by a given device.  We need to be able
to address the case where a device supports the (hypothetical) Version 1
of the DMTF powerstate set but the manager supports the (hypothetical)
Version 2 of the DMTF powerstate set.  We could ignore this issue and
thus delegate it to being a matter to be documented and verified by
humans at procurement time, or we could provide a means for programmatic
discovery and validation.  Obviously the latter is preferred from the
perspective of allowing the managers and devices to automatically
discover such mismatches.

Do others have any thoughts on how this could or should be accomplished?
What impacts would this have on the details in Juergen's proposal and
the IANA managed document?

Thanks,

William F. Mielke
Alcatel-Lucent

Here is a modified version of Juergen's proposal which I believe fixes
some minor inconsistencies in the numbering.  I have updated the
description slightly to make the definition (hopefully) more clear.
This results in the "index" of the states within a given set starting at
1 instead of 0 as Juergen's original proposal indicated with his example
numbering.  If we prefer to have the "index" begin at 0 for some reason
this can be easily accomplished but it means that the special value for
the set identifier must move to 255 as Juergen had in his original
example numbering, but that would imply the "set indicator value" in the
description would need to be adjusted to (S + 1) * 256 - 1 which I
believe is less desirable.  Should the description mention the fact that
the first block of 256 is "reserved" for special values?

IMPORTS

             Phone: +1 310 823 9358
             EMail: iana&iana.org"
    DESCRIPTION
            "TBD"

    ::= { mib-2 XXXX }

         supports. IANA has created a registry of Power State Sets
supported

         The textual convention assumes that power states in a power
         state set are limited to 255 distinct values. For a Power
         State Set S (where S >= 1), the named number with the value S *
256 is
         allocated to indicate the identity of the power state set. For
a 
         Power State X (where 1 <= X <= 255) in the Power State Set S,
the named 
         number with the value S * 256 + X is allocated to represent
that 
         distinct power state."
                
    REFERENCE 
              
    SYNTAX      INTEGER {

END
_______________________________________________
eman mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/eman

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Nov 2011 10:24:54 +0100

> Obviously this implies an internal mapping between the individual states of the difference supported powerstate sets.  I believe that we are agreed that the EMAN standards will not be able to forma…

What is "behave reasonably"? If we can't define the mappings, how are
implementors going to figure this out? And surely, implementations
will exhibit different ideas what "behave reasonably" means. For me,
the poor devices are really the wrong place to please the managers who
prefer to live a world that has only one set of power states.

Anyway, if the WG really is eager to go down this path, there should
in my view very clear words telling implementors "do not cheat with
your interpretation of behave reasonably" and there should be clear
words how to react if a "behave reasonably" mapping does not exist,
e.g. to fail any set requests that fall out of the "behave reasonably"
space for some definition of "behave reasonably".

> Alternatively we could allow support for multiple powerstate sets but only allow one to be used "at a time".  The definition of "at a time" would need to be clarified and mechanisms for negotiating…

I think the burden of coordination should be on the manager side. We
have many MIB objects in SNMP land where uncoordinated managers will
screw things up. So this is nothing new or specific to EMAN. And if
two uncoordinated manages like to exercise power management by
modifying power states on a device without knowing of each other, I
believe you are likely screwed even if both stay in the same set of
power states or if you allow concurrent power states. Coordination
really is a separate issue.

/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: "Mielke, William F (Bill)" <[email-masked]>
Date: Thu, 10 Nov 2011 11:01:58 -0600

Comments provided inline below.

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Thursday, November 10, 2011 4:25 AM
> To: Mielke, William F (Bill)
> Cc: [email-masked]

> space for some definition of "behave reasonably".

I am actually in agreement with this point which is why I raised the issue.  We must provide some guidance on how the devices are expected to behave if they support multiple powerstate sets concurrently.  I fully agree that "behave reasonably" is insufficient and vague which is why I attempted to provide some characterization of what the problem was.

I believe that the definition of "behave reasonably" is likely to be technology and perhaps even device specific which is why we have been thus far unable to articulate a universal mapping.  In the absence of such a universal mapping what are we to do?  Say nothing at all?  I believe that we need to push through and provide some level of guidance, even if that guidance is known to be imperfect.  But that is my opinion.

I would be OK with also providing the general guidance that in the event that a given device cannot devise a "reasonable" mapping and set of behaviors to insure that different managers acting independently each receive a set of responses which are consistent with their respective interfaces that we simply recommend that they not attempt to support multiple powerstate sets.

> really is a separate issue.

I also agree with Juergen that the scenario I raise of having two uncoordinated managers both attempting to control powerstates is almost guaranteed to lead to chaos, regardless of whether they are using the same or different powerstate sets.  But we must work within the framework we have.  Given the device centric nature of SNMP we are naturally driven to device centric solutions, or at least half solutions.

I am still relatively new to IETF.  Are there accepted mechanisms within IETF whereby we can constrain what the managers are allowed to do?  Are there mechanisms by which we can force the managers to coordinate their activities?  If so I would be open to exploring those as well to help insure that what we define is as rigorous as possible.

Are there any examples of how other working groups have approached this type of issue?

William F. Mielke
Alcatel-Lucent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Nov 2011 21:22:01 +0100

> Are there any examples of how other working groups have approached this type of issue?

SNMP has an access control model - you can configure it such that only
one manager has write access. This forces managers to coordinate with
each other. (But if you do this, supporting multiple concurrent power
states _on the device_ becomes a mood point.)

Except access control, SNMP does not provide a generic coordination
service. The SNMP approach has always been that agents should be
simple, following the general idea that complex functions are cheaper
to implement on managers than on agents embedded on devices.

That said, there are a few MIB modules where functions are maintained
for potentially multiple managers. The typical solution is to tag rows
such that managers get different "sandboxes" to play with. This kind
of works if the functions are mostly independent. Unfortunately, a
power state is bound to the device itself and thus sandboxing does not
work.

/js

---

From: Benoit Claise <[email-masked]>
Date: Mon, 14 Nov 2011 10:35:42 +0800

Hi Bill,
> I am fine with the general scheme advanced by Juergen S. for the encoding of powerstates into a single integer.  I am including below an updated version of his text which includes some minor gramma…
The latest proposal is at 
http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-01. I 
believe that this is in line with what you want to do, except the 
"other" and "unknow" that are inverted.
Note that I found a problem in 
http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-01

SYNTAX      INTEGER {
                            other(0),        -- indicates other set
                            unknown(255),    -- unknown power state

                            ieee1621(256), -- indicates IEEE1621 set
                            ieee1621On(257),
                            ieee1621Off(258),
                            ieee1621Sleep(259),

                            dmtf(512),   -- indicates DMTF set
                            dmtfOn(513),
                            dmtfSleepLight(514),
                            dmtfSleepDeep(515),
                            dmtfOffHard(516),
                            dmtfOffSoft(517),
                            dmtfHibernate(518),
                            dmtfPowerOffSoft(519),
                            dmtfPowerOffHard(520),
                            dmtfMasterBusReset(521),
                            dmtfDiagnosticInterrapt(522),
                            dmtfOffSoftGraceful(523),

                            eman(1024),       -- indicates EMAN set
                            emanmechoff(1025),
                            emansoftoff(1026),
                            emanhibernate(1027),
                            emansleep(1028),
                            emanstandby(1029),
                            emanready(1030),
                            emanlowMinus(1031),
                            emanlow(1032),
                            emanmediumMinus(1033),
                            emanmedium(1034),
                            emanhighMinus(1035),
                            emanhigh(1036)
                        }

The eman should start at 768.
> Alternatively we could allow support for multiple powerstate sets but only allow one to be used "at a time".  The definition of "at a time" would need to be clarified and mechanisms for negotiating…
Let me answer this issue with the last email in the thread.
> Do others have any thoughts on how this could or should be accomplished?  What impacts would this have on the details in Juergen's proposal and the IANA managed document?
The question is: should we allow power state series to become 
"deprecated".?I believe it makes sense. At least, we want to explain 
what IANA should do in such a case. Currently this is not covered by  
http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-01#section-12, 
which only speaks about addition.

Regards, Benoit (as a contributor)
>           State Set S (where S>= 1), the named number with the value S * 256 is
>           Power State X (where 1<= X<= 255) in the Power State Set S, the named

---

From: Benoit Claise <[email-masked]>
Date: Mon, 14 Nov 2011 11:38:37 +0800

Dear all,

There is no universal mapping, otherwise we would have a single power 
state series. This is obviously true on both the EnMS and the device.

"two uncoordinated managers both attempting to control powerstates is 
almost guaranteed to lead to chaos, regardless of whether they are using 
the same or different powerstate sets." Agreed, but let's decompose this 
problem into two
1. two uncoordinated managers both attempting to control powerstates 
with the same power state series.
     1.1 if the two EnMS disagree on what needs to be done, there is 
nothing EMAN can do...
2. two uncoordinated managers both attempting to control powerstates 
with different power state series.
     2.1 if the two EnMS disagree on what needs to be done, there is 
nothing EMAN can do...  (like 1.1)
     2.2 however, if the two EnMS attempt to set the same "profile" on 
the energy object, then EMAN can potentially help

Now, taking a step back regarding this concurrent power state 
requirement, [EMAN-REQ] specifies

            5.2.3. Multiple power state sets

        The energy management standard must provide means for supporting
        multiple power state sets simultaneously at a powered entity.

Which solutions do we have?
1. we remove this requirement: a single power state series is supported. 
This pushes the potential mapping from different device types/vendors to 
the EnMS
2. the device can support multiple power state series for reading, but 
only one for control. This solves the problem 2.2
      2.1 A variant: the device can expose multiple power state series 
for both monitoring and control, but the first EnMS that accesses it 
fixes the interface to communicate with the device, i.e. the power state 
series. Concern is: what if the first EnMS accessing the device is not 
the right one.
3 . the device does its best in terms of mappings between the power 
state series. This solves the problem 2.2, by basically saying: "we 
trust the vendor to do what's right for his device type".

As a contributor, I'm still undecided what the best approach is!

Regards, Benoit

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Mon, 14 Nov 2011 00:25:51 -0600

> From: Benoit Claise [mailto:[email-masked]] 
> http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-01. 
> I believe that this is in line with what you want to do, except the 
> ...

I believe that we are in agreement with respect to the convention to be adopted.  I am attaching below a revised version of the text from http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-01 which I believe provides the following improvements:

(1) It corrects a typo wherein "For a Power State X in the Power State S" has been changed to "For a Power State X in the Power State Set S".  Note the addition of "Set" before the "S".

(2) It makes the ranges for both S and X explicit to avoid confusion.

(3) It sets the range for X to be between 1 and 255, inclusive, which allows us to drop the "+ 1" in the computation of the values for Power States thus simplifying the text.

(4) It expands the comments within the enumeration of the Power State values to include a few example values for S and X so as to make the relationship between S, X, and the resulting Power State values (hopefully) more understandable to the reader.

(5) It corrects the starting point for the EMAN power state definitions to 768.

I believe that the version provided below can be copy and pasted directly into the document and would ask that this version be adopted for the above reasons.  I am unconcerned with the ordering and values assigned for "other" and "unknown".

Thanks,

William F. Mielke
Alcatel-Lucent
 
Proposed revision to the description of the tectual convention for Power States:

                "IANAPowerStateSet is a textual convention that describes
                 Power State Sets and Power State Set Values an Energy Object
                 supports. IANA has created a registry of Power State supported
                 by an Energy Object and IANA shall administer the list of Power
                 State Sets and Power States.

                 number with the value (S * 256) + X is allocated to represent that 
                 distinct power state."

            REFERENCE

            SYNTAX      INTEGER {

                    emanmechoff(769),
                    emansoftoff(770),
                    emanhibernate(771),
                    emansleep(772),
                    emanstandby(773),
                    emanready(774),
                    emanlowMinus(775),
                    emanlow(776),
                    emanmediumMinus(777),
                    emanmedium(778),
                    emanhighMinus(779),
                    emanhigh(780)
                }

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Mon, 14 Nov 2011 01:14:14 -0600

Bill,

Thanks for your suggestions. 

I have one comment on the Power State Set. 

Clearly, as you have indicated,  Power State X within a Power State can
be 1 <= X < = 255. 

In http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-01
I had assumed that Power State Set can be a unique bit beyond the lower
8 bits designated for the Power states. 

For e.g 

2^8 = 256   -  ieee 1621 
2^9 = 512   -  dmtf
2^10 = 1024 -  eman 
2^11 = 2048  - some future ...
2^12 
2^13 

it is possible to optimize  in multiples of 256 you have indicated ;
2^8 + 2^9 = 768 as another power state set. 

If the size of the octet string is large enough, and if the number of
IANA registered power state sets are small, both schemes would work ? 

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mielke, William F (Bill)
Sent: Monday, November 14, 2011 11:56 AM
To: [email-masked]
Subject: Re: [eman] iana powerstate tc proposal

> The eman should start at 768.

I believe that we are in agreement with respect to the convention to be
adopted.  I am attaching below a revised version of the text from
http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-01
which I believe provides the following improvements:

(1) It corrects a typo wherein "For a Power State X in the Power State
S" has been changed to "For a Power State X in the Power State Set S".
Note the addition of "Set" before the "S".

(3) It sets the range for X to be between 1 and 255, inclusive, which
allows us to drop the "+ 1" in the computation of the values for Power
States thus simplifying the text.

(4) It expands the comments within the enumeration of the Power State
values to include a few example values for S and X so as to make the
relationship between S, X, and the resulting Power State values
(hopefully) more understandable to the reader.

(5) It corrects the starting point for the EMAN power state definitions
to 768.

I believe that the version provided below can be copy and pasted
directly into the document and would ask that this version be adopted
for the above reasons.  I am unconcerned with the ordering and values
assigned for "other" and "unknown".

Thanks,

William F. Mielke
Alcatel-Lucent
 
Proposed revision to the description of the tectual convention for Power
States:

                "IANAPowerStateSet is a textual convention that
describes
                 Power State Sets and Power State Set Values an Energy
Object
                 supports. IANA has created a registry of Power State
supported
                 by an Energy Object and IANA shall administer the list
of Power
                 State Sets and Power States.

                 The textual convention assumes that power states in a
power
                 state set are limited to 255 distinct values. For a
Power
                 State Set S (where S >= 1), the named number with the
value S * 256 is
                 allocated to indicate the identity of the power state
set. For a 
                 Power State X (where 1 <= X <= 255) in the Power State
Set S, the named 
                 number with the value (S * 256) + X is allocated to
represent that 
                 distinct power state."

            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      INTEGER {

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Mon, 14 Nov 2011 02:57:58 -0600

> From: Mouli Chandramouli (moulchan) [mailto:[email-masked]] 

It is good that we have these discussions as it will clear up any confusion.

> 8 bits designated for the Power states. 

I am afraid that I do not understand what you are trying to say here.  Please clarify.

> 2^11 = 2048  - some future ...

I don't understand why you are using powers of 2 here.  The stated convention was to be S * 256, not 2^S.  The reason that Juergen has limited the number of distinct states within a power state set to 255 is so that they can be enumerated using a single byte, or 8 bits.

Perhaps a picture would help here.  How big are SNMP integers? 32 bits? 64 bits?  For our discussion here assume 16 bit integers.  Using the convention that each set starts at S * 256 has the effect of partitioning the 16 bits as follows:

  High Order       Low Order
1 1 1 1 1 1 0 | 0 0 0 0 0 0 0 0 0
5 4 3 2 1 0 9 | 8 7 6 5 4 3 2 1 0
---------------------------------
S S S S S S S | X X X X X X X X X

0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 0  -->  other(0)
0 0 0 0 0 0 0 | 1 1 1 1 1 1 1 1 1  -->  unknown(255)

0 0 0 0 0 0 1 | 0 0 0 0 0 0 0 0 0  -->  ieee1621(256)       S=1
0 0 0 0 0 0 1 | 0 0 0 0 0 0 0 0 1  -->  ieee1621On(257)     S=1, X=1
0 0 0 0 0 0 1 | 0 0 0 0 0 0 0 1 0  -->  ieee1621Off(258)    S=1, X=2
0 0 0 0 0 0 1 | 0 0 0 0 0 0 0 1 1  -->  ieee1621Sleep(259)  S=1, X=3

0 0 0 0 0 1 0 | 0 0 0 0 0 0 0 0 0  -->  dmtf(512)           S=2
0 0 0 0 0 1 0 | 0 0 0 0 0 0 0 0 1  -->  dmtfOn(513)         S=2, X=1
0 0 0 0 0 1 0 | 0 0 0 0 0 0 0 1 0  -->  dmtfSleepLight(514) S=2, X=2
...

0 0 0 0 0 1 1 | 0 0 0 0 0 0 0 0 0  -->  eman(768)           S=3
0 0 0 0 0 1 1 | 0 0 0 0 0 0 0 0 1  -->  emanmechoff(769)    S=3, X=1
0 0 0 0 0 1 1 | 0 0 0 0 0 0 0 1 0  -->  emansoftoff(770)    S=3, X=2

Note that the value of X will always end up in the low order bits, as shown, and the value for S will always end up in the high order bits.

This scheme is useful because it allows us to easily extract S and X from any Power State Value, in effect giving us a "set ID" and a "state ID" in one integer.  This is Juergen's way of addressing our orginal desire to have two values, one to identify the set and a second to identify the state within that set.

> 2^8 + 2^9 = 768 as another power state set. 

The fact that 2^8 + 2^9 = 768 is a coincidence in this case.  The EMAN set should begin at 768 because it is the third set (S=3) and the stated convention says assign the value S * 256 = 3 * 256 = 768.  A future fourth set (S=4) would start at S * 256 = 4 * 256 = 1024.

Does that help clarify what the proposed convention actually is? 

> IANA registered power state sets are small, both schemes would work ? 

We are defining an INTEGER, not an Octet String, correct?  So the size will be whatever an SNMP INTEGER maps to.  We could adopt a powers of 2 scheme like what you articulate but to what benefit?  Power state sets with more than 256 distinct states?

OK, but then the text of the convention would need to be modified to articulate the new scheme and extracting the original S and X from an arbitrary Power State Value would be harder and more computationally expensive.

If your concern is that 255 states is insufficient I think that the preferable solution would be to just allocate more low order bits to the power states until we have enough.  The basic scheme would still work. 511 unique states? 1023 unique states? Take your pick, but make it something that is (2^n)-1 so we get the benefit of easily extractable set IDs and state IDs.  Juergen just arbitrarily picked n=8 as a convenient size because it is 1 byte's worth.  If you want more then pick a larger value for n.  But once we pick we are sort of locked in, I think.

I think that 255 unique states is reasonable.  These are enumerated sets of states after all.  Is someone ever going to come up with names for 1023 different states?  I doubt it.  Or at least I would argue that doing so would be unreasonable.  Beyond 255 the scheme sort of falls apart from a practicality perspective, IMHO.

Perhaps Juergen S would have more to say about this?

William F. Mielke
Alcatel-Lucent

---

From: Benoit Claise <[email-masked]>
Date: Mon, 14 Nov 2011 17:11:33 +0800

Hi Bill, Mouli,

I agree with Bill's conclusion, and I believe that 255 is enough.
The only exception is a dimmer (if we need one in EMAN), but that would 
certainly require a different construct...

---

From: Bruce Nordman <[email-masked]>
Date: Mon, 14 Nov 2011 02:48:20 -0800

I am guessing that the great majority of devices will support only a single
power state series, so few will even have the potentiality for a problem.
For the remainder, they will find the mapping obvious.

Does anyone have a concrete example about how bad things could happen?
I think that would help the discussion.  On the other hand, I don't think
there
is a problem here so don't want to necessarily encourage the thread.

More below.

On Sun, Nov 13, 2011 at 7:38 PM, Benoit Claise <[email-masked]> wrote:

> 1. two uncoordinated managers both attempting to control powerstates with
> the same power state series.
> 2. two uncoordinated managers both attempting to control powerstates with
> different power state series.
>     2.2 however, if the two EnMS attempt to set the same "profile" on the
> energy object, then EMAN can potentially help
>
> Now, taking a step back regarding this concurrent power state requirement,
> [EMAN-REQ] specifies
>
> 5.2.3.  Multiple power state sets   The energy management standard must provide means for supporting
>      2.1 A variant: the device can expose multiple power state series for
> both monitoring and control, but the first EnMS that accesses it fixes the
> interface to communicate with the device, i.e. the power state series.
> Concern is: what if the first EnMS accessing the device is not the right
> one.
> 3 . the device does its best in terms of mappings between the power state
> series. This solves the problem 2.2, by basically saying: "we trust the
> vendor to do what's right for his device type".
>

I support 1. I assumed that most people wanted multiple state setss as an
option.
I don't see 2 or 2.1 as workable.
3. Seems fine.

--Bruce

-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
[email-masked]
510-486-7089
m: 510-501-7943

---

From: Rolf Winter <[email-masked]>
Date: Tue, 15 Nov 2011 14:00:16 +0000

Hi,

I assume that the Eman states mentioned are just placeholders until we have actual consensus on them, correct?

Best,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> Benoit Claise
> Sent: Montag, 14. November 2011 03:36
> >> Based on the feedback from the mailing list, we can conclude that
> the
> >> Juergen's TC proposal should be included in the next version of the
> draft.
> >>
> >> Regards, Benoit.
> > I do have some additional questions which should be clarified
> > somewhere so that the expectations around the use and implementation
> > of state sets is made more clear.  If the following points have
> > already been addressed in the updated drafts please excuse my
> > tardiness and point me to the proper place.  (I am first catching up
> > with the mailing list and will then read the updated drafts.)
> >
> > It is my understanding that we intend to allow, but not require, a
> given device to support multiple power state sets.  Looking back it
> seems that there was some question about whether the device was allowed
> to support those multiple power state sets *concurrently*.  I take
> *concurrently* to mean that some device, A, may be interacting with
> multiple managers, B and C, at the same time using different power
> state sets for each.  The implication is that temporally device A may
> receive interleaved powerstate commands/queries from managers B and C.
> It is my understanding that we intend to allow this scenario.  Is that
> agreed?
> >
> > My personal position is that in this scenario the minimum requirement
> to be placed on a device is that it must remain *internally consistent*
> regardless of which powerstate sets are being accessed and regardless
> of how the requests are interleaved.  By internally consistent I mean
> that if manager B interacts using IEE1621 powerstates that the manager
> the expectations of that powerstate set regardless of what manager C
> might do.  Likewise, if manager C intereacts using DMTF powerstates
> that it should be able to assume that the device will behave reasonably
> within the expectations of that powerstate set regardless of what
> manager B might do.
> >
> > Obviously this implies an internal mapping between the individual
> states of the difference supported powerstate sets.  I believe that we
> are agreed that the EMAN standards will not be able to formalize that
> allow a given manager to interact with it safely within the context of
> a single powerstate set without regard to what other managers might be
> desired then there are additional mechanisms which need to be defined
> to make it practical.  Is anyone advocating for this approach?
> to add or remove states from an existnig powerstate set, that some
> means of coordinating which version of the IANA document or instance of
> a powerstate set is being supported by a given device.  We need to be
> able to address the case where a device supports the (hypothetical)
> Version 1 of the DMTF powerstate set but the manager supports the
> (hypothetical) Version 2 of the DMTF powerstate set.  We could ignore
> this issue and thus delegate it to being a matter to be documented and
> verified by humans at procurement time, or we could provide a means for
> programmatic discovery and validation.  Obviously the latter is
> preferred from the perspective of allowing the managers and devices to
> automatically discover such mismatches.
> >
> > Do others have any thoughts on how this could or should be
> accomplished?  What impacts would this have on the details in Juergen's
> proposal and the IANA managed document?
> > Here is a modified version of Juergen's proposal which I believe
> fixes some minor inconsistencies in the numbering.  I have updated the
> This results in the "index" of the states within a given set starting
> at 1 instead of 0 as Juergen's original proposal indicated with his
> example numbering.  If we prefer to have the "index" begin at 0 for
> some reason this can be easily accomplished but it means that the
> special value for the set identifier must move to 255 as Juergen had in
> his original example numbering, but that would imply the "set indicator
> value" in the description would need to be adjusted to (S + 1) * 256 -
> 1 which I believe is less desirable.  Should the description mention
> the fact that the first block of 256 is "reserved" for special values?
> >

---

From: Benoit Claise <[email-masked]>
Date: Wed, 16 Nov 2011 10:58:46 +0800

Rolf,
> I assume that the Eman states mentioned are just placeholders until we have actual consensus on them, correct?
As always.

Regards, Benoit.