Management of Networks with Constrained Devices: Use Cases
draft-ietf-opsawg-coman-use-cases-05

[Ballot comment]
I'm dropping my DISCUSS since Kathleen raised the same point with a lot more detail than I did.  FTR, I support Kathleen's DISCUSS.  Here is the text of my former DISCUSS:

I was surprised to see no mention of the specific security requirements of the various use cases described here.  E.g., the medical use case makes no mention at all of security.  While in general security is required in all cases, I think there are differences in the level of security that is required for the various use cases described here, and I wonder if the authors considered this, and if so, why it wasn't mentioned.

I don't necessarily want to delay the document's publication pending a resolution to this issue, but I'd like to have a quick discussion about it.

[Ballot discuss]
Thanks for your work on this draft, I just have some security stuff I'd like to discuss that should be easy to resolve as some text is provided.

In section 4.5, it is critical to also include a statement on security in addition to privacy.  Medical devices with network attachments could be used to kill someone. 
http://abcnews.go.com/Health/dick-cheneys-fear-heart-device-hacks-justified-experts/story?id=20633284

Suggest changing this text from:
  In both cases, however,
  it is crucial to protect the privacy of the people to which medical
  devices are attached.  Even though the data collected by a heart beat
  monitor might be protected, the pure fact that someone carries such a
  device may need protection.  As such, certain medical appliances may
  not want to participate in discovery and self-configuration protocols
  in order to remain invisible.
To:
  In both cases, however,
  it is crucial to protect the safety and privacy of the people to which medical
  devices are attached.  Security precautions to protect access (authentication, encryption, integrity protections, etc.) to such devices may be critical to protecting the safety of the individual. Even though the data collected by a heart beat
  monitor might be protected, the pure fact that someone carries such a
  device may need protection.  As such, certain medical appliances may
  not want to participate in discovery and self-configuration protocols
  in order to remain invisible.

General statement:
Many of the other use case scenarios also have safety as a concern, requiring security protections (Confidentiality, Integrity, Availability).  Sensors used to control environmental settings is another example where air regulation might include detection of harmful things in the air (carbon monoxide).  I'm sure there are other safety concerns that motivate security protections in each of the use cases, it's not just privacy (which is important).  What if a sensor was tampered with to report or not report something detected?  That's not covered in the discussion on availability related problems in 4.6, but does represent another set of security considerations that could lead to safety issues.  More text on access control considerations for NMS may help.

[Ballot discuss]
I was surprised to see no mention of the specific security requirements of the various use cases described here.  E.g., the medical use case makes no mention at all of security.  While in general security is required in all cases, I think there are differences in the level of security that is required for the various use cases described here, and I wonder if the authors considered this, and if so, why it wasn't mentioned.

I don't necessarily want to delay the document's publication pending a resolution to this issue, but I'd like to have a quick discussion about it.

[Ballot comment]
The write-up says something about additional reviews. Does this include reviews by an outside party of the IETF that, for instance, an entity that operates building automation systems?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-opsawg-coman-use-cases-03, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Management of Networks with Constrained Devices: Use Cases) to Informational RFC


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document:
- 'Management of Networks with Constrained Devices: Use Cases'
  as Informational RFC

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 2015-01-14. 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 discusses use cases concerning the management of
  networks, where constrained devices are involved.  A problem
  statement, deployment options and the requirements on the networks
  with constrained devices can be found in the companion document on
  "Management of Networks with Constrained Devices: Problem Statement
  and Requirements".




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ballot/


No IPR declarations have been submitted directly on this I-D.

Document: draft-ietf-opsawg-coman-use-cases
WG: OpsAWG.
Shepherd: Warren Kumari

This version of the writeup is dated 24 February 2012.

[ Note: This document is a companion document to
draft-ietf-opsawg-coman-probstate-reqs. They should probably progress
together. The shepherd writeup is also very similar...


(1)Informational - this document is an informational
problem statement and requirements document.

(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:

Constrained devices (limited CPU, memory, and power resources) can be
connected to a network. This network may also be constrained or
challenged (unreliable or lossy channels, wireless technologies with
limited bandwidth and a dynamic topology). This may make traditional
network management a poor fit for these networks. This document
outlines use cases for a network with constrained devices.

Document Quality:

This document provides an overview and introduction to constrained
networks / networks with constrained devices. It discusses where they
are typically used, and some of the challenges in managing them.
Special thanks to Thomas Watteyne and Pascal Thubert for
arranging additional review.

Personnel:

Warren Kumari will be the document shepherd, Benoit Claise will be the
AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd:
The DS followed the progression of the document through the working
group process, and reviewed the document.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
Nope. During the Working Group Last Call the chairs of 6TiSCH and 6LO
asked that the WGLC be extended to allow their WG participants to
review the document, and so we extend it by a few weeks. The feedback
from these WGs was positive, and we are counting it in the consensus.


(5) Do portions of the document need review from a particular or from
broader perspective?
Nope.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document.
None.

(7) Has each author confirmed all appropriate IPR disclosures?
Yes.


(8) Has an IPR disclosure been filed that references this document?
No.


(9) How solid is the WG consensus behind this document?
There is strong consensus from a small group, and good feedback
from 6TiSCH and 6LO.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?
Nope. Not at all.

(11) Identify any ID nits the Document Shepherd has found in this
document.
No issues found here.

(12) Describe how the document meets any required formal review
criteria.
No formal material in the document.


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

(14) Are there normative references to documents that are not ready
for advancement?
No normative references exist.

(15) Are there downward normative references references?
No normative references exist.


(16) Will publication of this document change the status of any
existing RFCs?
Nope.

(17) Describe the Document Shepherd's review of the IANA
considerations section.
No action required (clearly stated)


(18) List any new IANA registries that require Expert Review for
future allocations.
None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language.
None.