Subject: [eman] Review of draft-norwin-energy-consider-01

From: "Brad Schoening -X (braschoe - Piepeople Consulting, Inc. at Cisco)" <[email-masked]>
Date: Mon, 8 Nov 2010 10:30:50 -0600

This document is inconsistent with the EMAN charter and should be tabled
or withdrawn.  It is deeply flawed in several areas.  First, it ignores
the basic concepts of SNMP MIB management.   Secondly, without
explaining why, it ought right opposes the power models presented in
several widely used standards such as ACPI,  DMTF's Power State and IEC
61850. 

These three standards for power management are well established and
supported on millions of devices.  

*         The ACPI standard for CPU power management was released in
1996 and  is ubiquitous today.  It defines seven power levels.  

*         IEC 61850 is supported by utilities worldwide and power
equipment  manufacturers.   IEC 61850 has an extensive Common
Information Model (CIM) that is the basis for many smart grid standards.

*          The DMTF Power State Management Profile was adopted in 2008
and defines an information model over web services.  It defines six
power levels and aligns them with the ACPI power levels. 

Below are some detailed comments, but my view is that this document does
nothing to advance the charter of the working group and will be a
distraction.  Instead we should focus on furthering the  existing drafts

http://tools.ietf.org/html/draft-quittek-power-mib-02

http://tools.ietf.org/html/draft-parello-eman-energy-aware-mib-00

http://ietfreport.isoc.org/all-ids/draft-claise-energy-monitoring-mib-06
.txt

--------------------------------------------------

3. "Scope of Devices" section seems to misunderstand the nature of SNMP.
Only devices with a network connection AND a SNMP agent can implement
these MIBs.

4.1. The 'Terminology' section on power states don't align with existing
standards for networked equipment (DMTF and ACPI).  The authors need to
clarify why they believe these pre-existing standards are in error or
not applicable.

5.1. Control "Device Considerations" also doesn't seem to understand how
SNMP management works " We should not forbid power state management of
devices that is done externally/centrally.  Today, centralized
management is the norm with SNMP.

Also, the authors need to explain how this idea relates to the current
marketplace of existing devices that in general are externally
controlled and only occasionally have distributed intelligence.

5.2 The comment about URL's seems ignorant of SysObjectID and not
relevant to the EMAN charter 

5.3 For "NMS Considerations", the authors need to clarify how this
relates to existing energy management systems and existing standards
such as IEC 61850 that define interval measurements.  

5.7 "For the device power state, the following information is considered
to be relevant"...   This doesn't reference any existing standards and
is therefore largely irrelevant.

5.8 "Devices can report power for another device only if they are the

entity providing the power"  This would rule out managing PC's which
typically don't have a SNMP agent.   We probably don't want to forbid
this.

6.o "Use Case: A house... A vehicle"  This further ignores basics about
SNMP.  Existing use cases for SNMP are not homes or vehicles.

Brad Schoening
Consultant
Product Development
[email-masked] <mailto:[email-masked]> 
Phone: +1 408 424 0363
Mobile: +1 917 304 7190

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
<http://www.cisco.com/web/about/doing_business/legal/cri/index.html>

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 8 Nov 2010 19:09:45 +0000

Wow, what a review ...

Dear Brad,

Below please find some replies on your comments inline.
Please cool down before you reply again and read carefully what you write.

Thanks,

    Juergen

On 09.11.10 00:30  "Brad Schoening -X (braschoe - Piepeople Consulting, Inc.
at Cisco)" <[email-masked]> wrote:

> or withdrawn. 

As a general comment since you do not seem to be familiar with the IETF:
Internet drafts are preferred means to contribute discussion items and
opinions to the IETF. Asking someone to withdraw a draft is comparable to
asking someone to withdraw her or his opinion. This is not what we do in the
IETF, at least as long as it is a technical opinion. Anyway, I would not
know means for removing a draft from the Internet draft repository.

More specifically: I am not sure what you mean with "inconsistent with the
EMAN charter". It is indeed not one of the documents that we envision to
produce in the eman WG. But so far nobody claimed that this draft would
match any of the envisioned drafts. In contrary, Bruce stated in his message
on this draft that this document should "reflect conclusions", "clarify
issues" and "drive decisions". No one is talking about making it an RFC.
Please find and read Bruce's announcement in the eman mailing list archive
at http://www.ietf.org/mail-archive/web/eman/current/msg00071.html

>               It is deeply flawed in several areas.

I don't see that it even slightly flawed. Please see my replies below to all
issues that you consider to be a flaw.

>                                                     First, it ignores
> the basic concepts of SNMP MIB management.

You are right in the sense that it ignores SNMP by not mentioning it. But
that is all ignorance I can find. Nothing in this document is in conflict
with any concept of SNMP.

>                                            Secondly, without

There is no statement opposing any other standard. None of the draft we have
received for eman uses exactly ACPI or DMTF (see my next comment below).
They don't even argue why they don't do so. Are they all deeply flawed?

> 1996 and  is ubiquitous today.  It defines seven power levels.

So far, none of the existing draft suggested using exactly the ACPI model
for power states. draft-claise-power-management-arch-02 is close to ACPI,
but it compresses the three stage model of ACPI (G,S,P) into a single stage
model of 12 power states. No other document that I have seen for eman
suggests ignoring ACPI or does not provides means for supporting it. Still,
the existing drafts differ in how far they limit themselves to ACPI that was
defined specifically for PCs.

> Information Model (CIM) that is the basis for many smart grid standards.

This is correct. Where do you see the draft you have reviewed opposing
IEC 61850?

> power levels and aligns them with the ACPI power levels.

The DMTF has only 6 power states, 5 of them non-operational. They merged all
operational power states into a single one: "on". This way it deviates from
ACPI providing means for several more states. It looks like Bruce's and
Rolf's draft is going into the same direction.

BTW, so far none of the drafts contributing to eman has suggested to adopt
the DMTF model of six power states although the DMTF focusing on network
management is much closer to the IETF network management issues than ACPI
focusing on PC motherboards.

> http://ietfreport.isoc.org/all-ids/draft-claise-energy-monitoring-mib-06

These are all MIB modules. Right, they are on the eman charter. But as well
on the charter are drafts on requirements, framework, and applicability.
I think the draft you reviewed is much more related to these three drafts
than to the one you refer to.

I do not see any relation between this section and SNMP at all. It
definitely does not mention MIBs or SNMP. Consequently, I cannot detect any
misunderstanding of SNMP. Are you really referring to this section or do you
have another one in mind?

> clarify why they believe these pre-existing standards are in error or

The drafts argues for introducing "power state categories" on, off, and
sleep. I see not problem with mapping power states defined by DMTF, ACPI or
other bodies to these categories. Do you?

But yes, I agree that if we adopt this proposal we should elaborate on the
mapping between these categories and the power states defined by other
bodies.

> management is the norm with SNMP.

There is no statement forbidding anything in this short section.
Particularly, I see no indication of anyone misunderstanding SNMP. After
working with SNMP for more than 10 years now and after editing a few
standard MIB modules I still cannot see your point. Can you help me seeing
it?

> controlled and only occasionally have distributed intelligence.

Good point. But you are probably aware that, for example, for mobile access
networks so-called "Self-Organizing Networks" (SON) for self-management of
base stations is already included in 3GPP standards. And energy management
functions is the next application area for SON.

> relevant to the EMAN charter

Maybe. But so far, I do not consider the identification of energy consumers
being solved by the eman WG. Proposals are still welcome. Whether the eman
WG or another WG will solve this problem is to be discussed.

> such as IEC 61850 that define interval measurements.

Good point. IEC 61850 is important and should not be ignored.

> is therefore largely irrelevant.

A very strange argument. Issues not covered already by existing standards
should not be dealt with by the IETF?

> typically don't have a SNMP agent.   We probably don't want to forbid

No, it rules out PCs that do not report their own power consumption. If no
device is connected to the PCs power line then the PC has to report power on
its own, because no other device will know its current power. This is quite
obvious. But I agree with you, that the authors should think about including
relaying of information from such PCs into their considerations.

> SNMP.  Existing use cases for SNMP are not homes or vehicles.

You talk about "basics". Do you claim that a "basic" property of SNMP is
that it cannot be applied in homes?

Let's try to be more constructive next time.

    Juergen

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

---

From: "Brad Schoening -X (braschoe - Piepeople Consulting, Inc. at Cisco)" <[email-masked]>
Date: Mon, 8 Nov 2010 14:19:54 -0600

Juergen,

It seems like we're in basic agreement here, that drafts and comments
should take into account existing standards.  Then, we can have an
honest debate about which standards are most relevant to our work.  

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]] 
Sent: Monday, November 08, 2010 2:10 PM
To: Brad Schoening -X (braschoe - Piepeople Consulting,Inc. at Cisco);
eman mailing list
Subject: Re: [eman] Review of draft-norwin-energy-consider-01

Wow, what a review ...

Dear Brad,

Below please find some replies on your comments inline.
Please cool down before you reply again and read carefully what you
write.

Thanks,

    Juergen

On 09.11.10 00:30  "Brad Schoening -X (braschoe - Piepeople Consulting,
Inc.

As a general comment since you do not seem to be familiar with the IETF:
Internet drafts are preferred means to contribute discussion items and
opinions to the IETF. Asking someone to withdraw a draft is comparable
to
asking someone to withdraw her or his opinion. This is not what we do in
the
IETF, at least as long as it is a technical opinion. Anyway, I would not
know means for removing a draft from the Internet draft repository.

More specifically: I am not sure what you mean with "inconsistent with
the
EMAN charter". It is indeed not one of the documents that we envision to
produce in the eman WG. But so far nobody claimed that this draft would
match any of the envisioned drafts. In contrary, Bruce stated in his
message
on this draft that this document should "reflect conclusions", "clarify
issues" and "drive decisions". No one is talking about making it an RFC.
Please find and read Bruce's announcement in the eman mailing list
archive
at http://www.ietf.org/mail-archive/web/eman/current/msg00071.html

>               It is deeply flawed in several areas.

I don't see that it even slightly flawed. Please see my replies below to
all
issues that you consider to be a flaw.

> the basic concepts of SNMP MIB management.

You are right in the sense that it ignores SNMP by not mentioning it.
But
that is all ignorance I can find. Nothing in this document is in
conflict
with any concept of SNMP.

> several widely used standards such as ACPI,  DMTF's Power State and
IEC

There is no statement opposing any other standard. None of the draft we
have
received for eman uses exactly ACPI or DMTF (see my next comment below).
They don't even argue why they don't do so. Are they all deeply flawed?

> 1996 and  is ubiquitous today.  It defines seven power levels.

So far, none of the existing draft suggested using exactly the ACPI
model
for power states. draft-claise-power-management-arch-02 is close to
ACPI,
but it compresses the three stage model of ACPI (G,S,P) into a single
stage
model of 12 power states. No other document that I have seen for eman
suggests ignoring ACPI or does not provides means for supporting it.
Still,
the existing drafts differ in how far they limit themselves to ACPI that
was
defined specifically for PCs.

> power levels and aligns them with the ACPI power levels.

The DMTF has only 6 power states, 5 of them non-operational. They merged
all
operational power states into a single one: "on". This way it deviates
from
ACPI providing means for several more states. It looks like Bruce's and
Rolf's draft is going into the same direction.

BTW, so far none of the drafts contributing to eman has suggested to
adopt
the DMTF model of six power states although the DMTF focusing on network
management is much closer to the IETF network management issues than
ACPI
focusing on PC motherboards.

> .txt

These are all MIB modules. Right, they are on the eman charter. But as
well
on the charter are drafts on requirements, framework, and applicability.
I think the draft you reviewed is much more related to these three
drafts
than to the one you refer to.

I do not see any relation between this section and SNMP at all. It
definitely does not mention MIBs or SNMP. Consequently, I cannot detect
any
misunderstanding of SNMP. Are you really referring to this section or do
you
have another one in mind?

The drafts argues for introducing "power state categories" on, off, and
sleep. I see not problem with mapping power states defined by DMTF, ACPI
or
other bodies to these categories. Do you?

But yes, I agree that if we adopt this proposal we should elaborate on
the
mapping between these categories and the power states defined by other
bodies.

There is no statement forbidding anything in this short section.
Particularly, I see no indication of anyone misunderstanding SNMP. After
working with SNMP for more than 10 years now and after editing a few
standard MIB modules I still cannot see your point. Can you help me
seeing
it?

> controlled and only occasionally have distributed intelligence.

Good point. But you are probably aware that, for example, for mobile
access
networks so-called "Self-Organizing Networks" (SON) for self-management
of
base stations is already included in 3GPP standards. And energy
management
functions is the next application area for SON.

> relevant to the EMAN charter

Maybe. But so far, I do not consider the identification of energy
consumers
being solved by the eman WG. Proposals are still welcome. Whether the
eman
WG or another WG will solve this problem is to be discussed.

> is therefore largely irrelevant.

A very strange argument. Issues not covered already by existing
standards
should not be dealt with by the IETF?

> typically don't have a SNMP agent.   We probably don't want to forbid

No, it rules out PCs that do not report their own power consumption. If
no
device is connected to the PCs power line then the PC has to report
power on
its own, because no other device will know its current power. This is
quite
obvious. But I agree with you, that the authors should think about
including
relaying of information from such PCs into their considerations.

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 8 Nov 2010 21:19:36 +0000

Hi Brad,

Wow, again. 

I objected almost every point you made and you see us in basic agreement.
Are you now fine with the draft that you reviewed?
No problems with it anymore?

Great!

    Juergen

On 09.11.10 04:19  "Brad Schoening -X (braschoe - Piepeople Consulting,Inc.

---

From: Rolf Winter <[email-masked]>
Date: Tue, 9 Nov 2010 00:53:40 +0000

Wow, what an excellent reply :) I have nothing to add to that. Thanks Juergen!

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Juergen Quittek
> Sent: Montag, 8. November 2010 20:10
> To: Brad Schoening -X (braschoe - Piepeople Consulting, Inc. at Cisco);
> eman mailing list
> > This document is inconsistent with the EMAN charter and should be
> > tabled or withdrawn.
> 
> to asking someone to withdraw her or his opinion. This is not what we
> do in the IETF, at least as long as it is a technical opinion. Anyway,
> I would not know means for removing a draft from the Internet draft
> repository.
> 
> the EMAN charter". It is indeed not one of the documents that we
> envision to produce in the eman WG. But so far nobody claimed that this
> draft would match any of the envisioned drafts. In contrary, Bruce
> stated in his message on this draft that this document should "reflect
> conclusions", "clarify issues" and "drive decisions". No one is talking
> about making it an RFC.
> archive at http://www.ietf.org/mail-
> archive/web/eman/current/msg00071.html
> 
> I don't see that it even slightly flawed. Please see my replies below
> to all issues that you consider to be a flaw.
> 
> >                                                     First, it ignores
> But that is all ignorance I can find. Nothing in this document is in
> conflict with any concept of SNMP.
> 
> >                                            Secondly, without
> > several widely used standards such as ACPI,  DMTF's Power State and
> > IEC 61850.
> 
> have received for eman uses exactly ACPI or DMTF (see my next comment
> below).
> model for power states. draft-claise-power-management-arch-02 is close
> to ACPI, but it compresses the three stage model of ACPI (G,S,P) into a
> single stage model of 12 power states. No other document that I have
> seen for eman suggests ignoring ACPI or does not provides means for
> supporting it. Still, the existing drafts differ in how far they limit
> themselves to ACPI that was defined specifically for PCs.
> 
> The DMTF has only 6 power states, 5 of them non-operational. They
> merged all operational power states into a single one: "on". This way
> it deviates from ACPI providing means for several more states. It looks
> like Bruce's and Rolf's draft is going into the same direction.
> 
> adopt the DMTF model of six power states although the DMTF focusing on
> network management is much closer to the IETF network management issues
> than ACPI focusing on PC motherboards.
> 
> > Below are some detailed comments, but my view is that this document
> > does nothing to advance the charter of the working group and will be
> a
> > http://ietfreport.isoc.org/all-ids/draft-claise-energy-monitoring-
> mib-
> > 06
> > .txt
> 
> well on the charter are drafts on requirements, framework, and
> applicability.
> drafts than to the one you refer to.
> 
> any misunderstanding of SNMP. Are you really referring to this section
> or do you have another one in mind?
> 
> > 4.1. The 'Terminology' section on power states don't align with
> > existing standards for networked equipment (DMTF and ACPI).  The
> > authors need to clarify why they believe these pre-existing standards
> > are in error or not applicable.
> 
> sleep. I see not problem with mapping power states defined by DMTF,
> ACPI or other bodies to these categories. Do you?
> 
> the mapping between these categories and the power states defined by
> other bodies.
> 
> > 5.1. Control "Device Considerations" also doesn't seem to understand
> > how SNMP management works " We should not forbid power state
> > management of devices that is done externally/centrally.  Today,
> > centralized management is the norm with SNMP.
> 
> Particularly, I see no indication of anyone misunderstanding SNMP.
> After working with SNMP for more than 10 years now and after editing a
> few standard MIB modules I still cannot see your point. Can you help me
> seeing it?
> 
> access networks so-called "Self-Organizing Networks" (SON) for self-
> management of base stations is already included in 3GPP standards. And
> energy management functions is the next application area for SON.
> 
> consumers being solved by the eman WG. Proposals are still welcome.
> Whether the eman WG or another WG will solve this problem is to be
> discussed.
> 
> standards should not be dealt with by the IETF?
> 
> no device is connected to the PCs power line then the PC has to report
> power on its own, because no other device will know its current power.
> This is quite obvious. But I agree with you, that the authors should
> think about including relaying of information from such PCs into their
> considerations.
> 
> > 6.o "Use Case: A house... A vehicle"  This further ignores basics
> > about SNMP.  Existing use cases for SNMP are not homes or vehicles.
> 
> You talk about "basics". Do you claim that a "basic" property of SNMP
> is that it cannot be applied in homes?
>

---

From: "Brad Schoening -X (braschoe - Piepeople Consulting, Inc. at Cisco)" <[email-masked]>
Date: Mon, 8 Nov 2010 19:55:53 -0600

Juergen,

Looking at the big picture, if we agree that the EMAN working group must
take into consideration the existing standards for energy management,
then, yes, I'd say we're in basic agreement.  Bruce and Rolf's document
did not do that.

You stated the following which gives me confidence we're on the same
page...

	"Good point. IEC 61850 is important and should not be ignored."

	"But yes, I agree that if we adopt this proposal we should
elaborate on the mapping 
	between these categories and the power states defined by other
bodies."

	"No other document that I have seen for eman suggests ignoring
ACPI or does not 
	provides means for supporting it"

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]] 
Sent: Monday, November 08, 2010 4:20 PM
To: Brad Schoening -X (braschoe - Piepeople Consulting,Inc. at Cisco);
eman mailing list

Hi Brad,

Wow, again. 

I objected almost every point you made and you see us in basic
agreement.
Are you now fine with the draft that you reviewed?
No problems with it anymore?

Great!

    Juergen

On 09.11.10 04:19  "Brad Schoening -X (braschoe - Piepeople
Consulting,Inc.
at Cisco)" <[email-masked]> wrote:

> tabled
to
> The DMTF has only 6 power states, 5 of them non-operational. They
merged
> does
> existing
ACPI
> how
After
> about
is

---

From: Bruce Nordman <[email-masked]>
Date: Tue, 9 Nov 2010 10:31:19 +0800

Brad--

There are MANY potentially relevant standards with definitions of power
states.  ACPI is certainly one of the most important for a certain category
of devices.  Some aspects of ACPI are extremely relevant to eman - some
are not.  While we need to take into account all relevant standards, there
is generally considerable difference between their origins, goals, concerns,
and scopes, and those of eman  -- which is where the "consideration"
process comes in.

I have not read IEC 61850, but the description of it being intended for
substation automation seems to make it at least one step removed from
the eman focus.  I do look forward though to seeing what it has to offer.

The norwin draft was not intended to repeat information already in the
other drafts, so it was not felt necessary to cite the importance of ACPI
(or SNMP or IP for that matter).

--Bruce

On Tue, Nov 9, 2010 at 9:55 AM, Brad Schoening -X (braschoe - Piepeople
Consulting, Inc. at Cisco) <[email-masked]> wrote:

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

---

From: Benoit Claise <[email-masked]>
Date: Tue, 09 Nov 2010 10:49:56 +0800

Brad,

<Working Chair hats on>
Energy Management is a new work area at the IETF.
This implies that there are a couple of a newcomers at the IETF. This is 
a good thing!
Many of us are passionate. This is also a good thing!

"Internet drafts are preferred means to contribute discussion items and 
opinions to the IETF. Asking someone to withdraw a draft is comparable 
to asking someone to withdraw her or his opinion. This is not what we do 
in the IETF, at least as long as it is a technical opinion. Anyway, I 
would not know means for removing a draft from the Internet draft 
repository."
Juergen wrote this, but I could have written that myself

Without abandoning our passion, let's bring back the discussions to 
technical arguments and facts.

If deem useful, Bruce and I are available for any private or public 
discussions (this is valid for anybody in the WG)

</Working Chair hats off>

Regards, Bruce & Benoit.
> tabled or withdrawn.  It is deeply flawed in several areas.  First, it 
> ignores the basic concepts of SNMP MIB management.   Secondly, without 
> ·The ACPI standard for CPU power management was released in 1996 and 
>  is ubiquitous today.  It defines seven power levels.
>
> ·IEC 61850 is supported by utilities worldwide and power equipment  
> manufacturers.   IEC 61850 has an extensive Common Information Model 
> (CIM) that is the basis for many smart grid standards.
>
> · The DMTF Power State Management Profile was adopted in 2008 and 
> defines an information model over web services.  It defines six power 
> levels and aligns them with the ACPI power levels.
>
> does nothing to advance the charter of the working group and will be a 
> http://ietfreport.isoc.org/all-ids/draft-claise-energy-monitoring-mib-06.txt
>
> 3. "Scope of Devices" section seems to misunderstand the nature of 
> SNMP.   Only devices with a network connection AND a SNMP agent can 
> implement these MIBs.
>
> 5.7 "For the device power state, the following information is 
> considered to be relevant"...   This doesn't reference any existing 
> standards and is therefore largely irrelevant.
>
> http://www.cisco.com/swa/i/logo.gif
>
> *Brad Schoening*
> *Consultant*
> *Product Development*
> Phone: *+1 408 424 0363*
> Mobile: *+1 917 304 7190***
>

---

From: "Brad Schoening -X (braschoe - Piepeople Consulting, Inc. at Cisco)" <[email-masked]>
Date: Mon, 8 Nov 2010 21:34:19 -0600

Bruce,

There are probably only a few standards that are highly relevant for
EMAN.  I would think these are ones from ACPI, DMTF and IEC, but I'm
open to hearing how others are relevant.   As Juergen suggests, it would
be helpful if you could elaborate on the mapping between your proposed
power states and those used in the DMTF and ACPI standards.  I wouldn't
really be worried that you're repeating information, because its highly
relevant how your consideration draft  ties in with these other
standards.  That's not something found in the mib drafts, since you have
suggested a new model.

I agree, "Substation Automation" sounds odd, but its relevant to power
quality and interval reporting .  There is also IEC 61970 which is the
Common Information Model (CIM) / Energy Management which is in turn
related to 61850.  You should already have short excerpts of 61850 which
I previously sent you, but I can resend.

Regards,

Brad

References

http://www.dmtf.org/sites/default/files/standards/documents/DSP1027_2.0.
0.pdf

http://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface

From: Bruce Nordman [mailto:[email-masked]] 
Sent: Monday, November 08, 2010 9:31 PM
To: Brad Schoening -X (braschoe - Piepeople Consulting,Inc. at Cisco)
Cc: eman mailing list
Subject: Re: [eman] Review of draft-norwin-energy-consider-01

Brad--

There are MANY potentially relevant standards with definitions of power
states.  ACPI is certainly one of the most important for a certain
category
of devices.  Some aspects of ACPI are extremely relevant to eman - some
are not.  While we need to take into account all relevant standards,
there
is generally considerable difference between their origins, goals,
concerns,
and scopes, and those of eman  -- which is where the "consideration" 
process comes in.

I have not read IEC 61850, but the description of it being intended for
substation automation seems to make it at least one step removed from
the eman focus.  I do look forward though to seeing what it has to
offer.

The norwin draft was not intended to repeat information already in the
other drafts, so it was not felt necessary to cite the importance of
ACPI
(or SNMP or IP for that matter).

--Bruce

Juergen,

 

-- 
Bruce Nordman