Last Call Review of draft-ietf-eman-framework-15
review-ietf-eman-framework-15-secdir-lc-nir-2014-02-27-00

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