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

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.

I support Alissa's DISCUSS, but since she's already there, I'm heading straight to ABSTAIN.