Hi all, I have reviewed the "Management of Networks with Constrained Devices: Problem Statement and Requirements" draft.
I think it is good work, and look forward to its finalising. I have the following comments, most of them (all?) quite easy to resolve: (BG1) Section 2: "tininess" can be replaced by "contraints" (BG2) Section 2: "constraindness" -> constrainedness", "therefor" -> "therefore" (BG3) Section 3.1, req 4.1.001: Device type should be "C0, C1 and/or C2" as described in section 3. (BG4) Section 3.1, req 4.1.002: "This implies that e.g. the managing entity is able to handle huge amount of device monitoring data and the management protocol is not sensitive to the decrease of the time between two client requests." - I think this would better be a separate requirement. (BG5) Section 3.1, req 4.1.004: "One way to achieve this is to adopt a RESTful architecture that minimizes the amount of state maintained by managed constrained devices and that makes resources of a device addressable via URIs." - This is a solution, not a requirement. I think the text can be deleted. (BG6) Section 3.1, req 4.1.006: "Intermediaries may be used that provide information for devices currently inactive or that take responsibility to resynchronize devices when they become reachable again after an extended offline period." - This is a solution, not a requirement. I think the text can be deleted. (BG7) Section 3.1, req 4.1.007: "The identification of the relevant subset of policies to be provisioned is according to the capabilities of each device and can be obtained from a pre-configured data-repository." - This is a solution, not a requirement. I think the text can be deleted. (BG8) Section 3.2, req 4.2.002: is this a non-functional requirement? If so, write this in requirement type. (BG9) Section 3.2, req 4.2.003: "As such, this requirement is marked as optional." - I think most requirements are optional at this point, since the draft does not point at a specific solution. Delete the sentence. (BG10) Section 3.2, req 4.2.004: "Hence this requirement is marked optional for device class C2." - This can be deleted; it should have been device class C0 (most constrained) anyway. (BG11) Sentences like those in BG9 and BG10 appear also elsewhere. Propose to remove. (BG12) Section 3.2, req 4.2.004: "Device type: C2", add "C1". (related to BG10) (BG12) Section 3.2, req 4.2.006: "Device type: C2", add "C1". (BG13) Section 3.3, req 4.3.003: the description should be more verbose and explicit. (BG14) Section 3.3, req 4.3.003: why does the requirement not apply to C0 devices? They may be sleepy and thus require asynchronous transactions. (BG15) Section 3.4, req 4.4.001: "data caching mechanism" requires a definition or explanation. (BG16) Section 3.4, req 4.4.004 is marked as "low priority". Isn't network status monitoring a major use-case? (BG17) Section 3.4, req 4.4.006 contains "(TBD)". Remove. (BG18) Section 3.4, req 4.4.011: should C0 (low priority) be mentioned? (BG19) Section 3.6, req 4.6.001: "In certain application scenarios, it is possible that a large number of devices need to be (re)started at about the same time. Protocols and authentication systems should be designed such that a large number of devices (re)starting simultaneously does not negatively impact the device authentication process." - I think this should be a requirement on its own. (BG20) Section 3.6, req 4.6.002: propose to change "add them to access control lists." to "provide them with appropriate access control permissions.", as "access control lists" are a specific solution. (BG21) Section 3.6, req 4.6.004: "(like some elliptic curve algorithm)" can be deleted, as it seems unnecessary information. (BG22) Section 3.6, req 4.6.004: why is there a distinction in priority between hardware-supported algorithms and other algorithms? I propose to set the priority of all to "high". (BG23) Section 3.7, req 4.7.003: "The device will support layer 2 energy management protocols (e.g. energy-efficient Ethernet IEEE 802.3az) and be able to report on these." - This should be rephrased to "If the device supports layer 2 ..., it should be able to report on these". (BG24) Section 3.10, req 4.10.001: "not sensitive to the decrease of the time between two client requests." - Propose to change to "not sensitive to a high rate of incoming client requests." (BG25) Section 3.10: put a "---" line between reqs 4.10.003 and 4.10.004. (BG26) Section 3.11: put a "---" line between reqs 4.11.001 and 4.11.002. (BG27) Section 5: "If specific requirements for security will be identified, they will be described in future versions of this document." - There are already security requirements in section 3.6, let's mention that in the security considerations section. (BG28) Appendix A has some overlap with draft-greevenbosch-coman-candidate-tech, which also describes current available technology. (BG29) Appendix A.3 "OMA" should mention that the OMA LwM2M Technical Specification (TS) has now reached candidate status. The appendix currently only mentions the LwM2M requirements document. (BG30) Appendix C: "Section 4 on the management requirements ... needs further consolidation." - I think this has already been done. In any case, the appendix can be removed. I hope this helps! Best regards, Bert _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
