Subject: [OPSAWG] Alissa Cooper's Abstain on draft-ietf-opsawg-coman-probstate-reqs-04: (with COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Tue, 24 Feb 2015 17:42:59 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-opsawg-coman-probstate-reqs-04: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/

----------------------------------------------------------------------
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.