Management of Networks with Constrained Devices: Problem Statement and Requirements
draft-ietf-opsawg-coman-probstate-reqs-05
Yes
(Joel Jaeggli)
No Objection
(Adrian Farrel)
(Alia Atlas)
(Jari Arkko)
(Spencer Dawkins)
Abstain
Note: This ballot was opened for revision 04 and is now closed.
Joel Jaeggli Former IESG member
Yes
Yes
(for -04)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -04)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -04)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -04)
Unknown
Kathleen Moriarty Former IESG member
(was Discuss)
No Objection
No Objection
(2015-03-01)
Unknown
Thanks for the changes for security considerations.
Martin Stiemerling Former IESG member
No Objection
No Objection
(2015-02-17 for -04)
Unknown
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.
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -04)
Unknown
Alissa Cooper Former IESG member
(was Discuss)
Abstain
Abstain
(2015-02-24 for -04)
Unknown
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.
Richard Barnes Former IESG member
Abstain
Abstain
(2015-02-18 for -04)
Unknown
I support Alissa's DISCUSS, but since she's already there, I'm heading straight to ABSTAIN.