Hi Alissa, Let me try to address the issues that you are raising. The coman team worked as a non-WG team for about 2-3 years, and only at the last phase of the work decided to send the two resulting informational documents to the OPSAWG for a broader review and exposure, at the advice of our AD. The two documents are informational, one describes the use cases and the second one the requirements for the broader space discussed by the use cases related to management of networks with constrained devices.. One of the conclusions of the work is that we do not believe that there is one single solution that would fit all use cases, this there is no single set of mandatory requirements that apply to all the use cases. No follow-up work is planned in OPS. We feel however that the two informational documents will be useful for further reference for these teams or WGs that try to build management solutions for one or more of the use cases.
In order to make the goals of the document more clear we suggest the following edits: In Abstract: OLD: 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. NEW: This document provides a problem statement, deployment and management topology options as well as requirements addressing the different use cases of the management of networks where constrained devices are involved. In Section 1.1: OLD: This document provides a problem statement and lists potential requirements for the management of a network with constrained devices. Section 1.3 and Section 1.5 describe different topology options for the networking and management of constrained devices. Section 2 provides a problem statement on the issue of the management of networked constrained devices. Section 3 lists requirements on the management of applications and networks with constrained devices. Note that the requirements listed in Section 3 have been separated from the context in which they may appear. Depending on the concrete circumstances, an implementer may decide to address a certain relevant subset of the requirements. The use cases in the context of networks with constrained devices can be found in the companion document [COM-USE]. NEW: This document provides a problem statement and lists requirements for the different use cases of management of a network with constrained devices. Section 1.3 and Section 1.5 describe different topology options for the networking and management of constrained devices. Section 2 provides a problem statement on the issue of the management of networked constrained devices. Section 3 lists requirements on the management of applications and networks with constrained devices. Note that the requirements listed in Section 3 have been separated from the context in which they may appear. Depending on the concrete circumstances, an implementer may decide to address a certain relevant subset of the requirements. The use cases in the context of networks with constrained devices can be found in the companion document [COM-USE]. This informational document provides a list of objectives for discussions and does not aim to be a strict requirements document for all use cases. In fact, there likely is not a single solution that works equally well for all the use cases. Thanks and Regards, Dan > -----Original Message----- > From: Alissa Cooper [mailto:[email protected]] > Sent: Thursday, February 19, 2015 1:55 AM > To: The IESG > Cc: [email protected]; [email protected]; draft-ietf-opsawg-coman- > [email protected]; [email protected] > Subject: Alissa Cooper's Discuss on draft-ietf-opsawg-coman-probstate-reqs- > 04: (with DISCUSS) > > Alissa Cooper has entered the following ballot position for > draft-ietf-opsawg-coman-probstate-reqs-04: Discuss > > 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 https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.ietf.org_iesg_statement_discuss- > 2Dcriteria.html&d=AwICaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31Oc > NXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=LRTLiND5zLlekWUmsFoaVKjkrugZ > M-KnuAq0u86hymQ&s=eJjAd- > BOQzGyu9hy1bhI6vQIl7xsHAWMzBLsPjwGVPU&e= > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://urldefense.proofpoint.com/v2/url?u=http- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dopsawg-2Dcoman- > 2Dprobstate- > 2Dreqs_&d=AwICaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQ > zvlsiLQfucBXRucPvdrphpBsFA&m=LRTLiND5zLlekWUmsFoaVKjkrugZM- > KnuAq0u86hymQ&s=KmEim4gFKCTNKbrps2bQskPznlkrThRg- > bO0gjTvxEM&e= > > > > ---------------------------------------------------------------------- > 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. > > > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
