[coman] requirement selection

[peter van der Stok <[e-mail]>]

Dear coman list,

In my personal notes I found that I volunteered to propose a selection 
of requirements from the ones proposed in the constrained-mgmt-03 draft.
Below I propose a selection based on some additional grouping. 
Questions are welcome.

I hope that other selections will be proposed in addition to mine.

Peter

____________________________________________________________________________________________________________________________________________-


Reading through the requirements of draft-ersue-constrained-mgmt-03 
means covering a wide area of technological requirements. Making a 
selection of just 3-4 requirements proves to be very hard because 
sometimes a group of requirements exhibits very tight relations between 
its members and selecting one almost implies selecting all the 
accompanying ones as well. Another aspect is that some of the 
requirements seem to be covered, or are likely to be covered by existing 
IETF working groups. Below I will group and comment the requirements 
according to my own whimsy (being a fan of Dorothy Sayers). A criterion 
I thought helpful is selecting those requirements which can be covered 
by a possible COMAN working group. All comments below are motivated by 
my knowledge of building control and reflect my own opinion and nothing 
else.
Group 1: Req. 4.1.001, Req. 4.1.002, Req. 4.1.004, Req. 4.1.006 are 
basic to any work done on management of devices for future large scale 
networks. Basing the management on a RESTful approach may indeed lead to 
a minimization of protocol code and leads to abolishment/replacement of 
SNMP?
Group 2: Req. 4.1.003. A hierarchical approach seems the best 
understood way forward to manage a large set of devices and can be used 
as design axiom.
Group 3: Req. 4.1.005, Req. 4.1.007, Req. 4.1.008, Req. 4.3.004, Req. 
4.4.009, Req. 4.5.001, Req. 4.9.002 discuss auto management, auto 
reconfiguration and fault tolerance. They point at a future in which 
enough knowledge and rules exist in which auto management is possible. 
However, appropriate solutions may need quite a lot of application 
specific assumptions, and satisfying these requirements is probably best 
left to other Standards Developing Organizations (SDO).
Group 4: Req. 4.2.005, Req. 4.2.006, Req. 4.2.007. These may be 
interpreted as defining a management model that provides basic 
facilities for low resource devices on which the SDOs can build in a 
later stage. This looks like work for COMAN. The design satisfying the 
requirements should follow the group 1 and group 2 requirements.
Group 5: Req. 4.3.001, Req. 4.3.002, Req. 4.3.003, These may be 
interpreted as a plug and play behavior of the devices. Part of the 
requirements is looked after by Homenet wg and the new to start DNSext 
wg. Additional work will need to be defined on top of Homenet and DNSext 
results. In particular it is interesting that clients can automatically 
bind to servers at start-up and possibly during operation.
Group 6: Req. 4.4.001 - Req. 4.4.008, Req. 4.4.011, and Req. 4.4.012, 
and Req. 4.7.001-4.7.004. concern monitoring and notification mechanisms 
which can be specified in COMAN using the results of group 4. SDOs can 
define their own functions on top.
Group 7:  Req. 4.6.001- 4.6.004, Req. 4.10.004 all concern security 
aspects which are the concern of future security wgs beyond TLS. Already 
efforts have started in lwig and an initiative exists to start a common 
Sec and APPS area spin-out.
Group 8: Req. 4.8.001 The requirement for a SW update for a group 
devices stands on its own and is indeed wanted. Up till now these 
facilities are specified by SDOs in a rather ad-hoc manner.
Group 9: Req. 4.9.001, 4.9.003, 4.10.001 – 4.10.003 concern reliable 
transport, congestion avoidance, time aspects, etc. Specifying these 
requirements correctly taking into account the relevant operational 
boundary conditions would be a major step forward from the current clash 
of opinions and initiatives. Does not look like a COMAN subject.
Group 10: Req. 4.2.001 - 4.2.004, Req. 4.11.001, Req. 4.11.002 concern 
modular and lean implementation and are probably best served by lwig
In conclusion: groups 4 and 5 requirements, supported by group 1 and 2 
requirements, are for me the most opportune ones in connection to the 
management of low resource devices in large scale networks. My hope is 
that it leads to ONE secure RESTful protocol that supports boot 
strapping, configuration of devices, followed by binding of clients to 
servers without operator intervention.
Automating of the configuration and reconfiguration, group 3, is 
interesting but may rely on a large number of application dependent 
characteristics and objectives.
Gap analysis: plug and play and management is done by SDOs for 
different application areas, often with much functional overlap but 
without common technical solutions apart from the reliance on 
multicasting techniques. A new common solution supported by IETF is 
needed given the large scale networks composed of low-cost IP based 
devices. Low resource devices may profit from one RESTful protocol with 
one security solution that is the same for the applications as for the 
management. Provisioning of multiple management solutions based on 
different protocols like snmp, http, and other protocols will need too 
much memory for storage of code.
The management based on MIBs misses the modeling flexibility needed by 
future solutions which support the auto-management of the devices.

-- 
Peter van der Stok
mailto: [e-mail]
www: www.vanderstok.org
tel NL: [phone]     F: [phone]