Monitoring and Control MIB for Power and Energy
draft-ietf-eman-energy-monitoring-mib-13

[Ballot comment]

Thanks for adding the new privacy boilerplate. I guess I'd
be happier if the privacy issues with power monitoring
were more to the fore, but at least recognising the issues
is a start and my preference in that regard aren't a good
basis on which to block progress.

[Ballot comment]
Thank you for adding in text on privacy considerations as well as strengthening the language on the possibility of attacks to motivate use of SNMPv3 with associated security controls.

[Ballot discuss]

I'm going to pile on to the privacy point raised by Alissa.
It's not common to put on another discuss in cases like that
but I'm asking to talk about another part of that same topic.
As with others, I think these issues may affect more than one
document here so we should consider them for the full eman wg
output and even broader (for my point 2) and not just for one
document. 

(1) I think this MIB is for a device that wants to tell the
world all about its power consumption. Perhaps that is just
not suitable for a device where the owner would prefer to be
more discrete. Did the WG consider how to structure a MIB for
that latter case?  For example, is there any way to tell a
device (via SNMP) that I am in fact such a privacy sensitive
user and would prefer the device to be discrete, and e.g.
aggregate measurements over much longer periods or report less
fine grained values generally?  If there is no such mechanism,
why not?

(2) On MIB privacy boilerplate: it is not clear to me that
boilerplate is really the right thing here - one common way to
handle privacy concerns is data minimisation which here could
map to not exposing an element or to only exposing aggregate
information rather than fine grained values. Those are things
that have to be thought about by the MIB developers and can't
just be handled via current SNMP security since once the data
is out there the privacy breach has happened. (This point is
broader than the eman WG of course so more for the AD and
MIB doctors.)

[Ballot comment]
I support Alissa's discuss, but am wondering if the proposed text should also include security considerations in addition to privacy if the home use case is mentioned.  In addition to revealing privacy information, protections for IoT devices accessed in the home may need to be called out specifically. 

The current section does call out the need for authenticated access and the use of SNMPv3 to provide adequate security for read/write and read/create functions.  How practical is this for the home? Not sure, but warnings on this use case could be helpful in the long run to push for SNMPv3 support for devices used in the home.  It would be a shame to see attacks be a cause for change, so it may be better to call this out as an area of concern (consideration for security).

I'd hate to have someone able to play with my heat while I am away at an IETF meeting and come home to frozen pipes because I had a discuss on their draft ;-)

How about adding the last sentence to Alissa's proposed text:

"In certain situations, energy and power monitoring can reveal sensitive
information about individuals' activities and habits. Implementors of this
specification should use appropriate privacy protections as discussed in
Section 9 of RFC 6988 and monitoring of individuals and homes should only occur
with proper authorization.  Secure authenticated access via SNMPv3 implemented in
such devices is RECOMMENDED to prevent unauthorized write access that could be
used to attack individuals and devices in their homes."


I'll note that Tero called this out in his SecDir review too.  Thanks for updating to the new boilerplate as a result.  I do think some mention of the security implications are important, otherwise, we won't get the level of security needed to protect IoT devices in the home.

[Ballot comment]
I support Alissa's discuss, but am wondering if the proposed text should also include security considerations in addition to privacy if the home use case is mentioned.  In addition to revealing privacy information, protections for IoT devices accessed in the home may need to be called out specifically. 

The current section does call out the need for authenticated access and the use of SNMPv3 to provide adequate security for read/write and read/create functions.  How practical is this for the home? Not sure, but warnings on this use case could be helpful in the long run to push for SNMPv3 support for devices used in the home.  It would be a shame to see attacks be a cause for change, so it may be better to call this out as an area of concern (consideration for security).

I'd hate to have someone able to play with my heat while I am away at an IETF meeting and come home to frozen pipes because I had a discuss on their draft ;-)

How about adding the last sentence to Alissa's proposed text:

"In certain situations, energy and power monitoring can reveal sensitive
information about individuals' activities and habits. Implementors of this
specification should use appropriate privacy protections as discussed in
Section 9 of RFC 6988 and monitoring of individuals and homes should only occur
with proper authorization.  Secure authenticated access via SNMPv3 extended
to such devices can be used to prevent write access that might be used to attack
individuals and devices in their homes."


I'll note that Tero called this out in his SecDir review too.  Thanks for updating to the new boilerplate as a result.  I do think some mention of the security implications are important, otherwise, we won't get the level of security needed to protect IoT devices in the home.

[Ballot comment]
I support Alissa's discuss, but am wondering if the proposed text should also include security considerations in addition to privacy if the home use case is mentioned.  In addition to revealing privacy information, protections for IoT devices accessed in the home may need to be called out specifically. 

The current section does call out the need for authenticated access and the use of SNMPv3 to provide adequate security for read/write and read/create functions.  How practical is this for the home? Not sure, but warnings on this use case could be helpful in the long run to push for SNMPv3 support for devices used in the home.  It would be a shame to see attacks be a cause for change, so it may be better to call this out as an area of concern (consideration for security).

I'd hate to have someone able to play with my heat while I am away at an IETF meeting and come home to frozen pipes because I had a discuss on their draft ;-)

How about adding the last sentence to Alissa's proposed text:

"In certain situations, energy and power monitoring can reveal sensitive
information about individuals' activities and habits. Implementors of this
specification should use appropriate privacy protections as discussed in
Section 9 of RFC 6988 and monitoring of individuals and homes should only occur
with proper authorization.  Secure authenticated access via SNMPv3 extended
to such devices can be used to prevent write access that might be used to attack
individuals and devices in their homes."

[Ballot comment]
former discuss, we processed this.

-12 should soon be forthcoming to address the accidental inclusion of

  eoPowerStorageType              StorageType

in draft 11 which was merged from a previous draft.

[Ballot discuss]
Section 11 is missing a discussion of the privacy considerations of energy and power monitoring. I would suggest something along the lines of the following:

"In certain situations, energy and power monitoring can reveal sensitive information about individuals' activities and habits. Implementors of this specification should use appropriate privacy protections as discussed in Section 9 of RFC 6988 and monitoring of individuals and homes should only occur with proper authorization."

[Ballot comment]
Section 12.1:
"New Assignments (and potential deprecation) to Power State Sets
        shall be administered by IANA and the guidelines and procedures
        are specified in [EMAN-FMWK], and will, as a consequence, the
        IANAPowerStateSet Textual Convention should be updated."
       
Not sure what this sentence means.

[Ballot discuss]
-12 should soon be forthcoming to address the accidental inclusion of

  eoPowerStorageType              StorageType

in draft 11 which was merged from a previous draft.

[Ballot comment]
-12 should soon be forthcoming to address the accidental inclusion of

  eoPowerStorageType              StorageType

in draft 11 which was merged from a previous draft.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-eman-energy-monitoring-mib-10.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA has questions about the requested action in this document.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the SMI Network Management MGMT Codes Internet-standard MIB subregistry of the Network Management Parameters registry located at:

http://www.iana.org/assignments/smi-numbers

three new MIBs will be registered as follows:

Decimal: [ TBD by IANA at time of registration ]
Name: IANAPowerStateSet-MIB
Description: Power State MIB
References: [ RFC-to-be ]

Decimal: [ TBD by IANA at time of registration ]
Name: energyObjectMIB
Description: Energy Object MIB
References: [ RFC-to-be ]

Decimal: [ TBD by IANA at time of registration ]
Name: powerAttributesMIB
Description: POWER ATTRIBUTES MIB
References: [ RFC-to-be ]

QUESTIONS:
1) In the IC section you have:

IANAPowerStateSet-MIB              { mib-2 xxx }
   
          energyObjectMIB                    { mib-2 yyy }
   
          powerAttributesMIB                { mib-2 zzz }
   
However, in section 9.1 you have 'yyy' placeholder:

          -- RFC Editor, please replace YYY with the IANA allocation
          -- for this MIB module and YYY with the number of the
          -- approved RFC
   
          ::= { mib-2 xxx }

Is that 'YYY' a typo?  Should it be 'xxx' rather?

2) Is there any actions requested to IANA in section 12.1
"IANAPowerStateSet-MIB module"?  Or is that section simply to tell
users to refer to those EMAN Power State Sets listed at
http://www.iana.org/assignments/power-state-sets?

IANA understands this to be the only action (not including 12.1)
required of IANA upon approval of this document

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Power and Energy Monitoring MIB) to Proposed Standard


The IESG has received a request from the Energy Management WG (eman) to
consider the following document:
- 'Power and Energy Monitoring MIB'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-06-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


      This document defines a subset of the Management Information
      Base (MIB) for power and energy monitoring of devices.

   



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/2147/

Document:  draft-ietf-eman-energy-monitoring-mib-10
Title:    Power and Energy Monitoring MIB
Editors:  M. Chandramouli, B. Claise, B. Schoening,
          J. Quittek and T. Dietz
Intended status:  Proposed Standard

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)?
    Why is this the proper type of RFC?  Is this type of RFC
    indicated in the title page header?

Proposed Standard.  Now that the EMAN Framework is in the RFC Editor
Queue, EMAN's three MIB drafts are ready for submission to the IESG.
Being MIBs, interoperability requires that they be Standards Track
RFCs.  Yes, their headers say Standards Track.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up. Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the
    following sections:

Technical Summary:

The Energy Monitoring MIB has two independent MIB modules,
energyObjectMIB and powerAttributesMIB. The first, energyObjectMIB,
is focused on measurement of power and energy. The second,
powerAttributesMIB, is focused on power quality measurements for
Energy Objects.
       
This document defines a subset of the Management Information Base
(MIB) for power and energy monitoring of devices.  Devices and their
sub-components can be modeled using the containment tree of the
ENTITY-MIB [RFC6933].

Working Group Summary

Version -01 of the draft was published in February 2012.
New versions were published about every three months from then
until version -08 in early December 2013.

Document Quality

Version -08 had its WG Last Call from 13 to 30 December 2013;
as part of that it was reviewed by the MIB-Doctors.  Six reviews
were received from the EMAN list, as well as a detailed list of
changes and improvements from the MIB Doctors.
The authors have modified the draft in response to that feedback;
we believe that the current (-09) version has resolved all the
issues.  That discussion raged on the EMAN list through January
2014.

Personnel

Document Shepherd:        Nevil Brownlee
Responsible Area Director: Joel Jaegli

(3) Briefly describe the review of this document that was performed
    by the Document Shepherd.  If this version of the document is not
    ready for publication, please explain why the document is being
    forwarded to the IESG.

I have read the draft carefully.  As well as the ASN1 MIB definitions,
it has lots of supporting detail, including a brief summary of the EMAN
Framework, the architecture of the MIBs (with UML diagrams for them),
and clear descriptions of all the concepts on which Energy Monitoring
depends.  It also has discussions of how these MIBS fit together
with other IETF MIBs, a realistic Security Considerations section
and a brief overview of two known implementations of the MIBs.

(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

No.  The only reason that this draft has waited since February 2014
is that it depends on the EMAN Framework - which is now in the RFC
Editor Queue.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the
    review that took place.

This draft was carefully reviewed by the MIB Doctors.  Several problems
with it were pointed out; they have been fixed in the current version.

(6) Describe any specific concerns or issues that the Document
    Shepherd has with this document that the Responsible Area
    Director and/or the IESG should be aware of? For example, perhaps
    he or she is uncomfortable with certain parts of the document, or
    has concerns whether there really is a need for it. In any event,
    if the WG has discussed those issues and has indicated that it
    still wishes to advance the document, detail those concerns here.

No known problems.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of
    BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
    If so, summarize any WG discussion and conclusion regarding the
    IPR disclosures.

Yes, IPR disclosure # 2147 covers this draft.  The WG was aware
of that from very early on, there;s been no discussion of IPR within
the WG.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with
    others being silent, or does the WG as a whole understand and
    agree with it?

There is strong consensus for this draft within the EMAN WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
    document. (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist). Boilerplate checks are not enough;
    this check needs to be thorough.

No nits.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type
    reviews.

It was reviewed by the MIB Doctors during its WG Last Call.

(13) Have all references within this document been identified as
    either normative or informative?

Yes.  There is normative references to IEEE 802.1AB's LLDP MIB
and to ANSI's LLDP MIB extension module, both of which were
published in 2005.

(14) Are there normative references to documents that are not ready
    for advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their
    completion?

Yes.  This draft has a normative reference to the EMAN Energy Aware
MIB draft (and vice versa).  These two drafts are being submitted
together.

(15) Are there downward normative references references (see RFC
    3967)?  If so, list these downward references to support the Area
    Director in the Last Call procedure.

No.  There is a reference to ANSI's LLDP MIB extension module,
but that was published in 2005.

(16) Will publication of this document change the status of any
    existing RFCs? Are those RFCs listed on the title page header,
    listed in the abstract, and discussed in the introduction? If the
    RFCs are not listed in the Abstract and Introduction, explain
    why, and point to the part of the document where the relationship
    of this document to the other RFCs is discussed. If this
    information is not in the document, explain why the WG considers
    it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA
    considerations section, especially with regard to its consistency
    with the body of the document. Confirm that all protocol
    extensions that the document makes are associated with the
    appropriate reservations in IANA registries.  Confirm that any
    referenced IANA registries have been clearly identified. Confirm
    that newly created IANA registries include a detailed
    specification of the initial contents for the registry, that
    allocations procedures for future registrations are defined, and
    a reasonable name for the new registry has been suggested (see
    RFC 5226).

IANA is asked to assign two indeces in mib-2 for these MIBs.
[There are two other EMAN MIB drafts being submitted concurrently with
this one, it would be good if all the EMAN MIBs had consecutive
numbers].

(18) List any new IANA registries that require Expert Review for
    future allocations. Provide any public guidance that the IESG
    would find useful in selecting the IANA Experts for these new
    registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

I don't have any SMI checking software; I assume that the MIB Doctors
have performed such checks.

-----