Management of Networks with Constrained Devices: Problem Statement and Requirements
draft-ietf-opsawg-coman-probstate-reqs-05

[Ballot comment]
Switching this to abstain -- I see no need to block the document from advancing on the basis of my comments.

It's really hard to tell how the "requirements" listed in this document are intended to be used. In fact, it seems incorrect to call them "requirements" at all -- in the sense of somehow being "required" -- given the following:

  This document provides a problem statement and lists potential
  requirements for the management of a network with constrained
  devices. ... Depending on the concrete
  circumstances, an implementer may decide to address a certain
  relevant subset of the requirements.
...
  This document in general
  does not recommend the realization of any subset of the described
  requirements.  As such this document avoids selecting any of the
  requirements as mandatory to implement.  A device might be able to
  provide only a particular selected set of requirements and might not
  be capable to provide all requirements in this document.  On the
  other hand a device vendor might select a specific relevant subset of
  the requirements to implement.

It's hard to see how the approach described above will contribute towards useful standardization. The "requirements" seem more like a laundry list of all the properties that a management architecture, management protocols, networks of constrained devices, and/or individual implementations might find desirable.

This also makes me wonder how the WG intends for these "requirements" to be used. What is the next step as far as standardization goes? To design the "management architecture" that is mentioned? Or the "management protocols" that are mentioned -- one or more, working together or separately? Or to consider how existing management protocols can be repurposed for constrained networks (which is sort of hinted at in section 2, but not stated explicitly), to meet some undefined subset of the listed "requirements"?

I think publishing a laundry list of desirable properties is ok if people find value in it, but I'm having trouble seeing how this document specifies either a problem statement or requirements that will somehow contribute to standardization efforts in the future.

[Ballot discuss]
I have not had time to read the full draft, but do see a gap in the security requirements that I'd like to see if we can address.  The section on access controls for management systems and devices reads as follows:

  Req-ID:  6.003

  Title:  Access control on management system and devices

  Description:  Systems acting in a management role must provide an
      access control mechanism that allows the security administrator to
      restrict which devices can access the managing system (e.g., using
      an access control white list of known devices).  On the other hand
      managed constrained devices must provide an access control
      mechanism that allows the security administrator to restrict how
      systems in a management role can access the device (e.g., no-
      access, read-only access, and read-write access).

  Source:  Basic security requirement for use cases where access
      control is essential.

The way I read this, there is no statement about general access protections to the device outside of what is designated by a security administrator.  I would think a statement on access controls on the device would be very important in consideration of safety concerns that put a strong need for security on such devices (medical, environmental monitors, etc.).  Are there additional access mechanisms to the device besides what is possible by the management connection?  Could there be factory defaults in place with local access work-arounds or even wireless int he even that there are issues accessing devices from management stations?  Do these cause security problems?  Are there ports other than those for management open that could lead to security breaches?  Or are these out-of-scope because the discussion is about management connections?  If it's out-of-scope, it would be good to state that it is even though that would be a concern.  Text on this should be added to the security considerations section as a general discussion if it's a concern, but not in scope, similar to what was done for privacy.

[Ballot discuss]
I'm putting this in as a DISCUSS in the event that the authors/WG want to discuss it or that I'm just missing some context, but I will happily move to ABSTAIN if there is no appetite for such discussion -- I see no need to block the document from advancing on the basis of my comments.

It's really hard to tell how the "requirements" listed in this document are intended to be used. In fact, it seems incorrect to call them "requirements" at all -- in the sense of somehow being "required" -- given the following:

  This document provides a problem statement and lists potential
  requirements for the management of a network with constrained
  devices. ... Depending on the concrete
  circumstances, an implementer may decide to address a certain
  relevant subset of the requirements.
...
  This document in general
  does not recommend the realization of any subset of the described
  requirements.  As such this document avoids selecting any of the
  requirements as mandatory to implement.  A device might be able to
  provide only a particular selected set of requirements and might not
  be capable to provide all requirements in this document.  On the
  other hand a device vendor might select a specific relevant subset of
  the requirements to implement.

It's hard to see how the approach described above will contribute towards useful standardization. The "requirements" seem more like a laundry list of all the properties that a management architecture, management protocols, networks of constrained devices, and/or individual implementations might find desirable.

This also makes me wonder how the WG intends for these "requirements" to be used. What is the next step as far as standardization goes? To design the "management architecture" that is mentioned? Or the "management protocols" that are mentioned -- one or more, working together or separately? Or to consider how existing management protocols can be repurposed for constrained networks (which is sort of hinted at in section 2, but not stated explicitly), to meet some undefined subset of the listed "requirements"?

I think publishing a laundry list of desirable properties is ok if people find value in it, but I'm having trouble seeing how this document specifies either a problem statement or requirements that will somehow contribute to standardization efforts in the future.

[Ballot comment]
No objection to the publication of this draft, but of course a number of comments about Section 3.10 on Transport protocols:

- Req-ID:  10.001: Not sure if this is really a requirement for a transport protocol. I would read this as a requirement for the implementation of a transport protocol.

- Req-ID:  10.002 says
      Description:  Diverse applications need a reliable transport of
      messages.  The reliability might be achieved based on a transport
      protocol such as TCP or can be supported based on message
      repetition if an acknowledgment is missing.

Repitition without any limitation on the number of repititions, etc is not a feature of a reliable transport protocol. I would remove "or can be supported based on message repetition if an acknowledgment is missing". Otherwise the text will blow up when you try to specific what features a reliable transport protocol should have.

- Req-ID:  10.003: Multicast is not a feature of the transport layer.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-opsawg-coman-probstate-reqs-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: Problem Statement and Requirements) 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: Problem Statement and
  Requirements'
  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 provides a problem statement, deployment and management
  topology options as well as potential requirements for the management
  of networks where constrained devices are involved.




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

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


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

Document: draft-ietf-opsawg-coman-probstate-reqs
WG: OpsAWG.
Shepherd: Warren Kumari

This version of the writeup is dated 24 February 2012.

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

Management of constrained devices, and constrained device networks
present some unique challenges. This document provides a problem
statement,deployment and management topology options, as well as
potential requirements for management of networks with constrained
devices.

Document Quality:

This document provides an overview and introduction to managing
networks with constrained devices. It clearly outlines the issues
and limitation, and lays out some requirements. It is clear and well
written. 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.