[OPSAWG] comments resolution for draft-ietf-opsawg-coman-probstate-reqs-00

["Romascanu, Dan (Dan)" <[e-mail]>]

Hi,

We received a number of valuable comments  for draft-ietf-opsawg-coman-probstate-reqs-00. Thanks to everybody who reviewed and commented. Here are our proposed comments resolution and edits.

First review was mine: http://www.ietf.org/mail-archive/web/opsawg/current/msg03077.html


Ø  1. The draft uses the 'adjective' small device in association with constrained device in a few place. I suggest to remove this. There is no automatic association of a device being small implying that it is also constrained. Nor are all constrained devices small in size.

PROPOSED RESOLUTION: s/small devices/constrained devices/ (there are three instances in the document)


Ø  2. We have made an effort in the last few versions and especially in this one to distinguish between the constrained devices and constrained networks, but the clean-up on this issue is not complete. For example section 1.6 still has text about constrained networks - this section and other in which constrained networks are mentioned should be carefully examined to make sure that the focus of the document stays with constrained devices, and that if constrained networks are mentioned at all this is in the context of their relationship with the constrained devices.

DISCUSSION: Fix the last two bullets in section 1.5. In 4.1.006, and Section A.2 rephrase as 'network of constrained devices'


Ø  3. I do not believe that we can get away with a zero-content security considerations section here either. The document even says:


Ø  If specific requirements for
   security will be identified, they will be described in future
   versions of this document.


Ø  This is not accurate - section 3.6 already speaks about requirments for security and access control, and section 1.6 mentions limitations that would prevent the implementation of strong scryptographic algorythms. The text needs to be reviewed and revised from this perspective.

PROPOSED RESOLUTION:

OLD:


5.  Security Considerations

   This document discusses the problem statement and requirements on the
   network of constrained devices.  If specific requirements for
   security will be identified, they will be described in future
   versions of this document.


NEW:



5.  Security Considerations

   This document discusses the problem statement and requirements on
   networks of constrained devices. Section 1.6 mentions a number of limitations

   that could prevent the implementation of strong cryptographic algorithms.

   Requirements for security and access  control are listed in Section 3.6.




Message from Zhen Cao: http://www.ietf.org/mail-archive/web/opsawg/current/msg03104.html


Ø  One cent to the document is, shall we consider the management of

sleepy nodes in section 3? There are many discussions in coap/lwig for

these sleepy nodes. The management of these devices is rather

challenging. Although there are some discussion in 'Energy

management', the scope of sleepy nodes management should be broader

than that.



PROPOSED RESOLUTION:



Sleepy devices as well as putting interfaces to sleep are already mentioned in section 3.7. A couple of more clarification edits can help:



In section 1.6:



OLD:



      might only be able to support a limited operating time (e.g. based
      on the available battery), i.e. the devices need to economize
      their energy usage with suitable mechanisms and the managing
      entity needs to monitor and control the energy status of the
      constrained devices it manages.



NEW:



      might only be able to support a limited operating time (e.g. based
      on the available battery), or may behave as 'sleepy endpoints'

      setting their network links to a disconnected state during long

      periods of time i.e. the devices need to economize
      their energy usage with suitable mechanisms and the managing
      entity needs to monitor and control the energy status of the
      constrained devices it manages.



Req. 4.1.006:



OLD:



Description:  Some constrained devices will only be able to support
      lossy and unreliable links characterized by a limited data rate, a
      high latency, and a high transmission error rate.  Furthermore
      constrained devices often duty cycle their radio or the whole
      device in order to save energy.  In both cases the management
      system must not assume that constrained devices are always
      reachable.



NEW:



Description:  Some constrained devices will only be able to support
      lossy and unreliable links characterized by a limited data rate, a
      high latency, and a high transmission error rate.  Furthermore
      constrained devices often duty cycle their radio or the whole
      device in order to save energy. Some classes of devices labelled as

      'sleepy endpoints' set their network links to a disconnected state

      during long periods of time. In all cases the management
      system must not assume that constrained devices are always
      reachable.





Comments from Bert Wijnen: http://www.ietf.org/mail-archive/web/opsawg/current/msg03096.html





Ø  - for requirement 4.2.0001

  I wonder why a C0 device would have to implement in a modular fashion.

  I could see that a C0 device (Maybe even C1) does the minimal

  modular-function-set implementation, but that the implementation is in

  fact monolythic. It often save memory and possibly cpu cycles.



PROPOSED RESOLUTION: clarify that the requirement is for the specification of the protocol and not for the implementation on the devices.



OLD:



   Description:  Management protocols should allow modular
      implementations, i.e., it should be possible to implement only a
      basic set of protocol primitives on highly constrained devices
      while devices with additional resources may provide more support
      for additional protocol primitives.



NEW:



   Description:  Management protocols should be specified so that they allow

      for modular implementations, i.e., it should be possible to implement

      only a basic set of protocol primitives on highly constrained devices
      while devices with additional resources may provide more support
      for additional protocol primitives.





Ø  - for requirement 4.9.001

  It might be good to add a refereence to RFC2914 ??

  Just thinking aloud.



PROPOSED RESOLUTION:



OLD:



Description:  Provide the ability to avoid congestion by modifying
      the device's reporting rate for periodical data (which is usually
      redundant) based on the importance and reliability level of the
      management data.  This functionality is usually controlled by the
      managing entity, where the managing entity marks the data as
      important or relevant for reliability.  However reducing a
      device's reporting rate can also be initiated by a device if it is
      able to detect congestion or has insufficient buffer memory.

NEW:



Description:  Support congestion control principles as defined by [RFC2914],

      e.g.  the ability to avoid congestion by modifying
      the device's reporting rate for periodical data (which is usually
      redundant) based on the importance and reliability level of the
      management data.  This functionality is usually controlled by the
      managing entity, where the managing entity marks the data as
      important or relevant for reliability.  However reducing a
      device's reporting rate can also be initiated by a device if it is
      able to detect congestion or has insufficient buffer memory.

Add [RFC2914] to the Informational References section





- for requirement 4.9.003

  is that more or less an "implementation" suggestion for requirement 4.9.001 ??



PROPOSED RESOLUTION: reject - congestion avoidance is only one of the reasons traffic delay is applied in networks, so 4.9.003 is not necessarily related to 4.9.001





Comments from Bert Greevenbosch: http://www.ietf.org/mail-archive/web/opsawg/current/msg03116.html



(BG1) Section 2: "tininess" can be replaced by "contraints"



PROPOSED RESOLUTION: s/tininess/constraints/



(BG2) Section 2: "constraindness" -> constrainedness", "therefor" -> "therefore"



PROPOSED RESOLUTION: accept



(BG3) Section 3.1, req 4.1.001: Device type should be "C0, C1 and/or C2" as described in section 3.



PROPOSED RESOLUTION: accept



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



PROPOSED RESOLUTION: reject - this sentence clarifies scalability as enounced in the previous sentence.



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



PROPOSED RESOLUTION: accept - delete or separate the sentence in a note after the requirement



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



PROPOSED RESOLUTION: same as the previous



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



PROPOSED RESOLUTION: move text starting from this sentence to a separate note. The text is important to be maintained as in underlines the use of templates filtered by device roles and capacities



(BG8) Section 3.2, req 4.2.002: is this a non-functional requirement? If so, write this in requirement type.



PROPOSED RESOLUTION: reject - this is a functional requirement



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



PROPOSED RESOLUTION: accept



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



PROPOSED RESOLUTION: accept



(BG11) Sentences like those in BG9 and BG10 appear also elsewhere. Propose to remove.



PROPOSED RESOLUTION: accept



(BG12) Section 3.2, req 4.2.004: "Device type: C2", add "C1". (related to BG10)



PROPOSED RESOLUTION: add "C1 (optional)". s/Hence this requirement is marked optional for devices class C2/ Hence this requirement is marked optional for devices class C1/



(BG12) Section 3.2, req 4.2.006: "Device type: C2", add "C1".



PROPOSED RESOLUTION: add "C1 (optional)". s/Hence this requirement is marked optional for devices class C2/ Hence this requirement is marked optional for devices class C1/



(BG13) Section 3.3, req 4.3.003: the description should be more verbose and explicit.



PROPOSED RESOLUTION: reject - what is missing?



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



PROPOSED RESOLUTION: reject - we do not believe rollback can be implemented on C0 devices



(BG15) Section 3.4, req 4.4.001: "data caching mechanism" requires a definition or explanation.



PROPOSED RESOLUTION: accept



(BG16) Section 3.4, req 4.4.004 is marked as "low priority". Isn't network status monitoring a major use-case?



PROPOSED RESOLUTION: reject - we are talking about the computed network status



(BG17) Section 3.4, req 4.4.006 contains "(TBD)". Remove.



PROPOSED RESOLUTION: accept



(BG18) Section 3.4, req 4.4.011: should C0 (low priority) be mentioned?



PROPOSED RESOLUTION: s/Low for C1/Low for C0 and C1/



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



PRPOSED RESOLUTION: reject, this sentence defines a specific mode of work and scalability for authentication - it does belong here



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



PROPOSED RESOLUTION: accept



(BG21) Section 3.6, req 4.6.004: "(like some elliptic curve algorithm)" can be deleted, as it seems unnecessary information.



PROPOSED RESOLUTION: accept



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



PROPOSED RESOLUTION: reject, the difference in priority originates in the fact that SW-based mechanisms are more resource demanding



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



PROPOSED RESOLUTION: accept



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



PROPOSED RESOLUTION: accept



(BG25) Section 3.10: put a "---" line between reqs 4.10.003 and 4.10.004.



PROPOSED RESOLUTION: accept



(BG26) Section 3.11: put a "---" line between reqs 4.11.001 and 4.11.002.



PROPOSED RESOLUTION: accept



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



PROPOSED RESOLUTION: accept, already addressed by the resolution to a previous comment



(BG28) Appendix A has some overlap with draft-greevenbosch-coman-candidate-tech, which also describes current available technology.



PROPOSED RESOLUTION: deleted appendices A and B



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



PROPOSED RESOLUTION: see above



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



PROPOSED RESOLUTION: accept - remove section





Comments from Hui Deng: http://www.ietf.org/mail-archive/web/opsawg/current/msg03105.html



1.       in section 3., a section of 'IPv4/v6 address management' could be helpful, including the discussion of different types of ip addresses on devices, link-local, global, private, etc..

It is not really clear what the commenter means here. Mehmet asked, we did not see an answer yet.

2. in Appendix A, any relevant discussion in 'oneM2M'?



PROPOSED RESOLUTION: see above, appendix removed





Comments from James Nguyen: http://www.ietf.org/mail-archive/web/opsawg/current/msg03127.html


(1) Req-ID 4.3.002 Title: Capacity Discovery

     I don't quite understand this req.  Please be more specific.

The commenter took back his comment after being pointed by Juergen to the relevant text.

(2) Section 3.3 Configuration Management

     Session-oriented configuration protocol may be expensive for managing a large number of similar devices.  In a case when common redundant configurations is issued, reliable multicast with negative acknowledgement (e.g. Negative ACKnowledgement (NACK)-Oriented Reliable Multicast (NORM)) would work best.  I suggest to add a reliable transport requirement in this section.  Moreover, a common data model would be needed.

     Stateless configuration update solution would also work well for constrained networks.

DISCUSS: Juergen had an exchange of mails with the commenter - not clear what edits are required if any. : The concern is that 4.10.003 asks for Best-effort multicast only and lets reliable multicast out. We cannot list reliable multicast as a requirements as it is hard to achieve and only needed by special use cases like the ones James is mentioning. We are in favor of keeping the draft more generic and not include such special use cases mentioned by James. Also we mentioned "stateless" already in the architecture requirement 4.1.004 with req on RESTful protocols.


(3) Section 3.8 Group-based provisioning

     As I mentioned in (2), a common data model would be required for common redundant configurations.  I suggest to add this requirement here.

PROPOSED RESOLUTION: In section 3.8:

OLD:


Description:  Support group-based provisioning, i.e. firmware update
      and configuration management, of a large set of constrained
      devices with eventual consistency and coordinated reload times.
      The device should accept group-based configuration management
      based on bulk commands, which aim similar configurations of a
      large set of constrained devices of the same type in a given
      group.  Activation of configuration may be based on pre-loaded
      sets of default values.
NEW:


Description:  Support group-based provisioning, i.e. firmware update
      and configuration management, of a large set of constrained
      devices with eventual consistency and coordinated reload times.
      The device should accept group-based configuration management
      based on bulk commands, which aim similar configurations of a
      large set of constrained devices of the same type in a given
      group, and which may share a common data model. Activation of

      configuration may be based on pre-loaded sets of default values.
Regards,

Dan