I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.

These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Although I am reviewing this for SECDIR, I have to begin with some editorial remarks. I don't know what tool was used, but it's producing a very ill-formatted draft. It's true that the RFC editor staff will get it right, but it is apparent that this is a combination of several sources. See for example section 2 for a jarring mixture of line lengths.  Or the broken-in-half artwork of Figure 1 at the bottom of page 14. When you do that, someone (that's the RFC editor) has to put your diagrams back together, an error-prone process that should be done by the authors.

The middle of section 1 has a paragraph whose entire text is "Energy Management Documents Overview". Was this supposed to be the title to a subsection?

The document also contains some parts that are supposed to be removed before publication, for example the URL to the issue tracker. Please add a label like "RFC EDITOR NOTE: REMOVE THE FOLLOWING PARAGRAPH" before this. They know to look for it, and we don't end up with things we didn't want in the draft.

Speaking of issues, I followed that URL, and found that it is showing three open issues. Are these resolved?

I confess to being totally ignorant of the subject matter, but reading through this I noticed something that surprised me. In section 3.1 there is this paragraph:
        A simple device such as a light bulb can be switched on or off 
        only by switching its power supply.  More complex devices may 
        have the ability to switch off themselves or to bring 
        themselves to states in which they consume very little power.
Is the "may" here appropriate? Don't these complex devices *require* that they switch themselves off rather than have their power switched off?

Finally, the security considerations section. The most important recommendation there is to use SNMPv3, because it includes authentication and privacy, unlike earlier versions. I agree with the recommendation, but it should be noted that authentication was part of SNMPv1 as well, although different mechanisms (not based on community strings) were only added in SNMPv3. "Privacy" is a loaded term with multiple meanings. In SNMP privacy simply means confidentiality, and it's preferable to use that term rather than "privacy" which today is no longer used interchangeably with confidentiality.

The section does an OK job of enumerating the risks, but IMO downplays them. For example, "Unauthorized changes to the Energy Management Domain or business context of an Energy Object may result in misreporting or interruption of power."  There's no "may" about it. If an attacker can modify the energy management domain, then they can at least shut down the network.

Yoav