idnits 2.17.1 draft-greevenbosch-coman-candidate-tech-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 03, 2013) is 3950 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6130' is defined on line 1103, but no explicit reference was found in the text == Unused Reference: 'OMA-FUMO' is defined on line 1220, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-25) exists of draft-ietf-core-groupcomm-09 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-08 == Outdated reference: A later version (-11) exists of draft-ietf-tls-oob-pubkey-07 == Outdated reference: A later version (-04) exists of draft-bormann-core-cocoa-00 == Outdated reference: A later version (-05) exists of draft-li-core-conditional-observe-04 == Outdated reference: A later version (-08) exists of draft-mcgrew-tls-aes-ccm-ecc-06 == Outdated reference: A later version (-05) exists of draft-rahman-core-sleepy-02 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 coman B. Greevenbosch 3 Internet-Draft K. Li 4 Intended status: Informational Huawei Technologies 5 Expires: January 04, 2014 P. van der Stok 6 vanderstok consultancy 7 July 03, 2013 9 Candidate Technologies for COMAN 10 draft-greevenbosch-coman-candidate-tech-03 12 Abstract 14 This draft identifies candidate technologies and considerations for 15 the COMAN use cases and requirements. 17 Note 19 Discussion and suggestions for improvement are requested, and should 20 be sent to coman@ietf.org. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 04, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Identified candidate technologies for the requirements . . . 3 59 3.1. OMA-LwM2M . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.2. OMA Device Management . . . . . . . . . . . . . . . . . . 4 61 3.2.1. OMA-DM Management Objects . . . . . . . . . . . . . . 4 62 3.2.2. ACL mechanism in OMA-DM . . . . . . . . . . . . . . . 5 63 3.3. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.3.1. CoAP main specification . . . . . . . . . . . . . . . 6 65 3.3.2. CoAP capability discovery specifications . . . . . . 6 66 3.3.3. CoAP group communication . . . . . . . . . . . . . . 7 67 3.3.4. CoAP energy saving technology . . . . . . . . . . . . 7 68 3.3.5. Congestion avoidance in CoAP . . . . . . . . . . . . 8 69 3.4. Cryptography considerations . . . . . . . . . . . . . . . 8 70 3.5. MANET . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.6. BACnet . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.7. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 3.8. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 3.9. Other requirements and candidate technologies . . . . . . 15 75 4. High level requirements that need to be observed continuously 16 76 5. Table of requirements and related technologies . . . . . . . 16 77 6. Conclusion and recommendations . . . . . . . . . . . . . . . 21 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 79 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21 80 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 83 10.2. Informative References . . . . . . . . . . . . . . . . . 22 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 86 1. Requirements notation 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 2. Introduction 94 In [I-D.ersue-constrained-mgmt], several use cases and associated 95 requirements are defined for the management of constrained devices, 96 in a possibly constrained network. 98 This document identifies possible technologies associated with the 99 use cases and requirements. 101 In addition, this document includes several considerations associated 102 with the requirements, that are relevant for choosing proper 103 technologies. 105 The goal of this document is to identify what has been done, and what 106 still needs to be done. Especially, it aims at establishing a 107 clearer view of the scope and work in COMAN. 109 3. Identified candidate technologies for the requirements 111 3.1. OMA-LwM2M 113 OMA Lightweight M2M [OMA-LwM2M-TS] aims at providing an underlying 114 layer agnostic protocol to allow M2M service enablement and 115 management between the LwM2M Server and the LwM2M Client, which is 116 placed in the resource constrained devices. The first version of 117 enabler is currently being specified. The enabler provides a light 118 and compact protocol and a flat data structure, and can satisfy 119 various management requirements for constrained devices. 121 OMA-LwM2M has overlap with the following COMAN requirements: 123 o 4.2.002 Compact encoding of management data 125 o 4.4.001 Device status monitoring 127 o 4.4.002 Energy status monitoring 129 o 4.4.012 Logging 131 o 4.6.001 Authentication on management system and devices 133 o 4.6.002 Support suitable security bootstrapping mechanisms 135 o 4.6.003 Access control on management system and devices 137 Because of the overlap and early stage of OMA-LwM2M, good 138 coordination between COMAN and OMA-LwM2M is advisable. 140 3.2. OMA Device Management 142 OMA Device Management [OMA-DM] provides various functions for mobile 143 device management. OMA-DM specifies and depends heavily on the 144 SyncML language, which uses XML. The typical underlying transport 145 protocol is HTTP. This makes OMA-DM in unaltered form infeasible for 146 constrained devices. Especially, it violates the following 147 requirements: 149 o 4.1.001 Support multiple device classes within a single network 151 o 4.2.002 Compact encoding of management data 153 Nevertheless, there is much overlap between OMA-DM functionality and 154 COMAN requirements. As such, OMA-DM MAY be used as inspiration for 155 the COMAN solution. 157 OMA-DM defines a general data model for management purpose, which is 158 called a Management Object (MO). MOs are stored on the device and 159 can be manipulated by management actions carried over the OMA-DM 160 protocol. For each management purpose, a specific MO has been 161 defined. MOs relevant to the COMAN requirements include "FUMO" for 162 firmware update requirements, "DiagMon MO" for diagnostic and 163 monitoring requirements and the "Scheduling MO" for scheduling 164 requirements. The various MOs are discussed in Section 3.2.1 and its 165 subsections. 167 Apart from requirements covered by MOs, the following COMAN 168 requirements intersect with the general OMA-DM functionality: 170 o 4.1.007 Network-wide configuration - Use broadcast capability from 171 OMA-DM 1.3 - Sessionless specification. 173 3.2.1. OMA-DM Management Objects 175 3.2.1.1. OMA DiagMon MO 177 OMA DiagMon MO builds on and leverages the OMA DM v1.x protocol. It 178 provides standard DM Management Objects and associated client-side 179 and server-side behaviour necessary to conduct diagnostics and 180 monitoring activities on mobile devices. 182 Requirements related to OMA DiagMon MO: 184 o 4.4.003 Monitoring of current and estimated device availability: 185 can be achieved by DiagMon functions MO. 187 o 4.4.004 Network status monitoring: can be achieved by DiagMon 188 functions MO. 190 o 4.4.006 Performance monitoring: can be achieved by DiagMon 191 functions MO. 193 o 4.4.007 Fault detection monitoring: can be achieved by Trap MO. 195 o 4.4.011 Notifications: can be achieved by reporting functions in 196 DiagMon MO. 198 o 4.4.008 Passive and reactive monitoring: can be achieved by Trap 199 MO. 201 o 4.5.001 Self-management - Self-Healing: device events can be 202 captured by Trap MO, also periodically, to achieve self- 203 management. 205 3.2.1.2. OMA Scheduling MO 207 The OMA-DM Scheduling MO enabler [OMA-Scheduling-MO] specifies the 208 scheduling framework as well as its Management Objects that can be 209 layered on top of OMA-DM v1.x, to seamlessly add the common 210 scheduling capability to the OMA-DM based management infrastructure. 211 With this capability, the OMA-DM system is able to schedule 212 management operations on the device, and have them executed offline 213 when the schedule - time-based or event-based - matches. 215 Requirements related to OMA Scheduling MO: 217 o 4.5.001 Self-management - Self-Healing: time-based scheduled task 218 can achieve periodic self-management. 220 3.2.1.3. OMA-FUMO 222 OMA-FUMO provides information on management objects associated with 223 firmware updates in OMA-DM based mobile devices and the behaviour 224 associated with the processing of the management objects. 226 3.2.2. ACL mechanism in OMA-DM 228 OMA-DM [OMA-DM] defines the Access Control List (ACL) mechanism to 229 control the access to the Management Objects. ACL is a property 230 associated with the Management Object nodes, and is used to grant 231 access permissions to the server identifiers. 233 Related requirements: 235 o 4.6.002 Support suitable security bootstrapping mechanisms 237 o 4.6.003 Access control on management system and devices 239 3.3. CoAP 241 The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is 242 defined by the IETF. It provides an application layer protocol 243 especially designed for constrained devices. It is binary and easy 244 to parse. 246 CoAP is especially suitable on top of IPv6 and UDP. However, other 247 lower level protocols are possible too. 249 In addition, several drafts have been specified to target specific 250 issues. 252 3.3.1. CoAP main specification 254 The following requirements are met by the CoAP main specification: 256 o 4.1.001 Support multiple device classes within a single network - 257 the low complexity of CoAP allows usage in all device classes. 259 o 4.1.004 Minimise state maintained on constrained devices - CoAP 260 has been designed to keep servers stateless. 262 o 4.1.006 Support for lossy links and unreliable devices - through 263 the CoAP CON retransmission mechanism. 265 o 4.2.004 Mapping of management protocol interactions - CoAP 266 provides HTTP/Coap Mapping. 268 o 4.2.007 Protocol extensibility - mainly provided by options 269 mechanism. 271 o 4.3.003 Asynchronous transaction support - CoAP supports separate 272 response and piggy-backed response. 274 o 4.4.007 Fault detection monitoring (partly) - CoAP pinging allows 275 verification if a device is online. 277 3.3.2. CoAP capability discovery specifications 279 Various CoAP drafts cover different aspects of capability discovery. 281 o RFC 6690 [RFC6690] defines a link format, which provides 282 information on resources a server is offering. 284 o The draft [I-D.greevenbosch-core-profile-description] allows 285 signalling a CoAP server profile. 287 o The draft [I-D.shelby-core-resource-directory] allows acquiring 288 information about resources from another server, called the 289 "Resource Directory". 291 o The draft [I-D.lynn-core-discovery-mapping] provides a mapping 292 between the resource directory and a DNS lookup. This allows 293 usage of DNS lookup for the discovery of CoAP servers. 295 o The informational draft [I-D.vanderstok-core-dna] discusses 296 mapping between IP address and a Fully Qualified Domain Name 297 (FQDN), proposing DNS for lookup of the IP address. In addition, 298 it discusses possible naming conventions, group communication and 299 resource discovery. Towards the latter, registration of new 300 devices to the resource directory is discussed. 302 Related COMAN requirement: 304 o 4.3.002 Capability discovery 306 3.3.3. CoAP group communication 308 The informational CoAP group communication draft 309 [I-D.ietf-core-groupcomm] discusses various aspects of group 310 communication through IP multicast [RFC4604] in CoAP. 312 Another informational draft discussing group communication is 313 [I-D.vanderstok-core-dna]. This draft gives detailed examples, and 314 discusses multicast, naming and DNS mapping of groups. 316 Related COMAN requirement: 318 o 4.8.001 Group-based provisioning 320 3.3.4. CoAP energy saving technology 322 The draft [I-D.rahman-core-sleepy] provides a mechanisms for sleepy 323 devices. These mechanisms include informing an intermediate resource 324 directory (defined in [I-D.shelby-core-resource-directory]) of its 325 waking up or intent to fall asleep. Through these two drafts, 326 clients can use the observe mechanism [I-D.ietf-core-observe] to be 327 informed of whether a device is sleeping or active. 329 Related COMAN requirements: 331 o 4.1.006 Support for lossy links and unreachable devices 332 o 4.7.002 Support of energy-optimized communication protocols 334 3.3.5. Congestion avoidance in CoAP 336 The considerations in this section relate to: 338 o 4.9.001 Congestion avoidance 340 o 4.9.003 Traffic delay schemes 342 The draft [I-D.bormann-core-cocoa] provides general background 343 information about CoAP congestion control, and its challenges. 345 The draft [I-D.li-core-conditional-observe] defines a mechanism to 346 signal minimum time between CoAP observations. 348 The draft [I-D.greevenbosch-core-minimum-request-interval] defines a 349 mechanism to restrict the speed in which a CoAP client sends requests 350 to the CoAP server. 352 Other ways to delay the traffic in CoAP is by sending delayed ACKs. 353 However, this has limitations as too much delay will lead to 354 retransmits from the client side. In addition, this method requires 355 the server to maintain bookkeeping of the delayed ACKs. 357 3.4. Cryptography considerations 359 4.6.001 Authentication of management system and devices 361 o The raw public key as defined in [I-D.ietf-tls-oob-pubkey] can be 362 used for establishing security and authentication. 364 o OCSP-lite as defined in [I-D.greevenbosch-tls-ocsp-lite] can be 365 used for revocation checking of the raw public key. 367 4.6.002 Support suitable security bootstrapping mechanisms 369 o The draft [I-D.jennings-core-transitive-trust-enrollment] 370 describes a system in which a Device is introduced to a Controller 371 by a Introducer. In this draft, it is suggested that the Device 372 symmetric key is coded as a QR code on the box, which can be read 373 by the Controller, which may be a mobile phone with internet 374 access. 376 4.6.004 Select cryptographic algorithms that are efficient in both 377 code space and execution time 379 o Candidates for asymmetric cryptography: 381 * RSA 383 * ECC 385 Keysize TBD. 387 o Candidates for symmetric cryptography: 389 * AES (keysize 128/192/256) 391 Keysize TBD. 393 o Candidates for hashing: 395 * SHA-1 397 * SHA-256 399 * SHA-512 401 o For CoAP [I-D.ietf-core-coap], the following choices have been 402 made: 404 * Cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 specified in 405 [I-D.mcgrew-tls-aes-ccm-ecc], [RFC5246], [RFC4492] 407 * Hash: SHA-256 409 * ECC with curve secp256r1 (equivalent to NIST P-256) [RFC4492] 411 * AES-128 in CCM mode [RFC5116], [CCM] 413 4.6.008 Select cryptographic algorithms that are to be supported in 414 hardware 416 o TBD 418 3.5. MANET 420 TBD. 422 3.6. BACnet 424 BACnet exists under the auspices of the American Society of Heating, 425 Refrigerating and Air-Conditioning Engineers (ASHRAE). BACnet is an 426 American national standard, a European standard, a national standard 427 in more than 30 countries, and an ISO global standard. The protocol 428 is supported and maintained by ASHRAE Standing Standard Project 429 Committee (SSPC) 135. BACnet is the most deployed communications 430 standard for building control in the USA. It consists of a number of 431 working groups. Their results are published in one BACnet 432 specification document: International ISO standard 16484-5 433 [ISO16484-5]. It defines a network architecture on top of several 434 PHYs (ARCnet, MS/TP, Ethernet, P2P, LONTalk) and IP. It specifies a 435 number of object types from which a control system can be composed. 436 Central is the device objects (unique per device) that maintains all 437 organization information for a given devices. Object types are 438 defined for scheduling, grouping, alarm handling, object and device 439 management, and service discovery. The BACnet specification includes 440 an extensive Alarm and Event service, and object access service for 441 system configuration purposes, and remote device management services. 443 The following requirements are met by the BACnet specification: 445 o 4.1.001 Support multiple device classes within a single network - 446 the BACnet standard has an open source implementation that fits on 447 the smallest devices and can also be deployed on larger devices 449 o 4.1.002 Management scalability - the BACnet standard defines a 450 hierarchical management structure where data are collected from 451 all devices with support from information in the device object. 452 Group objects can be defined which aggregate information from 453 multiple objects within the same device. A working group, BACnet/ 454 WS, is dedicated to defining the architecture for storing 455 historical data of the control system in a central repository 456 using the ATOM Publishing standard and exploiting the xml modeling 457 facilities. 459 o 4.1.003 Hierarchical management - hierarchical management is 460 supported by the device and object structure, the independent 461 structure in alarm management, and the group object which supports 462 the grouping of commands. 464 o 4.1.004 Minimize state maintained on constrained devices - state 465 is minimized by selecting relevant objects in the control devices. 467 o 4.1.008 Distributed Management - BACnet does provide the 468 possibility to export management to multiple managers, however, no 469 atomic write and read is specified, although there is a 470 transaction concept at network level. 472 o 4.2.001 Modular implementation of management protocols - BACnet 473 encourages and prescribes a modular implementation by segmenting 474 the management functions and distributing them over different 475 objects. 477 o 4.2.002 Compact encoding of management data - BACnet transports 478 binary data encoded according to ASN.1, reduces storage space as 479 much as feasible given the specified functionality. 481 o 4.2.005 Consistency of data models with the underlying information 482 model - BACnet has an information model based on the ATOM 483 publishing protocol. The BACnet Annex N standard prescribes the 484 mapping between the information model and the data model present 485 in the nodes. 487 o 4.2.007 Protocol extensibility - the BACnet model encourages 488 extensibility, as proven by the constant backwards compatible 489 standards updates. The standards extension process is slow and 490 sets the extension pace. 492 o 4.3.001 Self-configuration capability - BACnet supports discovery 493 of devices, their objects and properties via WHO-HAS, I-AM and 494 similar messages. 496 o 4.3.002 Capability Discovery - See 4.3.001. 498 o 4.3.004 Network reconfiguration - BACnet knows the concept of 499 BACnet routers. Routers declare themselves to network segments, 500 and can be allocated started, stopped. No automatic procedures 501 are described for full auto-configuration. 503 o 4.4.001 Device status monitoring - BACnet provides extensive tools 504 for network and device status monitoring, specified in the Alarm 505 and Event services section. BACnet supports a very flexible event 506 and alarm reporting. Clients can subscribe to generators of 507 events and alarms, which can be changes of values in objects or 508 status changes. Classes of events can be specified with 509 appropriate handling by the clients. 511 o 4.4.002 Energy status monitoring - This can be provided in BACnet 512 by creating a binary value object type connected to the energy 513 c.q. power attributes to monitor and specify a change of state 514 with an appropriate client. 516 o 4.4.003 Monitoring of current and estimated device availability - 517 See text in 4.4.002. 519 o 4.4.004 Network status monitoring - BACnet provides facilities to 520 configure and install routers on the BACnet network. BACnet 521 specifies the MS/TP and PTP link protocols with the possibility to 522 monitor link status. 524 o 4.4.006 Performance Monitoring - BACnet defines a set of 525 application layer objects. Dependent on their function, 526 performance measures are monitored and events or alarms are 527 generated to be monitored by an alarm handling service. 529 o 4.4.007 Fault detection monitoring - BACnet includes fault 530 detection monitoring at network level. 532 o 4.4.009 Recovery - BACnet provides functions for network recovery 533 and object, device recovery without specifying how these functions 534 must be used in case of given errors. 536 o 4.4.010 Network topology discovery - this is a rather basic 537 capability of a BACnet network. 539 o 4.4.011 Notifications - the BACnet alarm and event services are 540 dedicated to this topic. 542 o 4.4.012 Logging - BACnet annex N specifies how logged values can 543 be stored in a server using the ATOM publishing protocol. 545 o 4.6.001 Authentication of management system and devices - BACnet 546 security service provides authentication of peers, operators and 547 data source. 549 o 4.10.002 Reliable unicast transport - BACnet provides a 550 transaction service over the network. 552 o 4.10.003 Best-effort multicast - BACnet goes to great pains to 553 provide a broadcast facility which is essential for its 554 configuration purposes. 556 o 4.11.001 Avoid complex application layer transactions requiring 557 large application messages - BACnet has a finite set of 558 application message constructs in which application messages 559 should fit. 561 o 4.11.002 Avoid reassembly of messages at multiple layers in the 562 protocol stack - BACnet avoids reassembly by contruction. 564 3.7. SNMP 566 The Simple Network Management Protocol (SNMP) can be used to monitor 567 and manage various network entities. It is the most popular network 568 management protocol today based on IETF standards. In [RFC3410] an 569 introduction and overview of SNMP is presented. The architecture of 570 the Internet Standard management framework consists of: 572 o A data definition language, referred to as Structure of Management 573 Information (SMI), is defined in [RFC2578], [RFC2579], [RFC2580]. 575 o The Management Information Base (MIB) which contains the 576 information to be managed and is defined for each specific 577 function to be managed [RFC3418]. 579 o A protocol definition referred to as Simple Network Management 580 Protocol. Version 3 (SNMPv3) is defined in [RFC3411], [RFC3412], 581 [RFC3413], [RFC3416], and [RFC3417]. 583 o Security and administration that provides SNMP message based 584 security on the basis of the user-based security model, discussed 585 in [RFC3414] and [RFC3415]. 587 Separation in modules was motivated by the wish to respond to the 588 evolution of Internet. The protocol part (SNMP) and data definition 589 part (MIB) are independent of each other. The separation has enabled 590 the progressive passage from SNMPv1 via SNMPv2 to SNMPv3. The SNMP 591 protocol supports seven types of access supported by as many Protocol 592 Data Unit (PDU) types. Two types of message exchange are used: 594 o The SNMP client sends out a request message after which the SNMP 595 server returns a Response message. 597 o The SNMP server sends a confirmed or unconfirmed notification 598 message with a list of (OBJECT-IDENTIFIERs, value) pairs to a 599 notification requesting end-point. 601 The MIB objects are defined in ASN.1, for various protocols, at 602 different layers. For example, [RFC4113] defines a MIB for UDP, 603 whereas the draft [I-D.schoenw-6lowpan-mib] defines a MIB module for 604 6LoWPAN [RFC4944]. 606 The interesting part of SNMP is that it provides a framework that 607 enables request/response and notification type message exchanges. 608 The purpose of the message exchange is defined by the contents of the 609 MIBs which are declared independently for many different purposes. 610 Related requirements are: 612 o 4.1.001 Multiple device classes, SNMP and MIB are class 613 independent. 615 o 4.1.002 Management scalability, SNMP can be the basis for extended 616 management functionality. 618 o 4.2.001 Modular implementation, Separation between MIB and SNMP 619 provides basic modularity. Separation in MIBs and SNMP entities 620 provides a second level of modularity. 622 o 4.2.005 Consistency between data and information model, Encouraged 623 by separation of MIBs. 625 o 4.2.007 Protocol Extensibility, Supported by design, but lacks in 626 message PDU type extensibility. 628 o 4.3.004 Network reconfiguration, Several MIBs support network 629 configuration but not in an automatic network state driven 630 fashion. 632 o 4.4.001 Device status monitoring, Appropriate MIB is specified. 634 o 4.4.002 Energy state monitoring, MIB specified by Eman. 636 o 4.4.004 Network status monitoring, Appropriate MIB is specified 638 o 4.4.006 Performance monitoring, Appropriate MIBs may be specified 639 outside IETF 641 o 4.4.007 Fault detection monitoring, Appropriate MIBs are 642 specified. 644 o 4.4.011 Notifications, Basic SNMP function. 646 o 4.6.001 Authentication of management system and devices, supported 647 by SNMPv3. 649 o 4.6.003 Access control on management system and devices, supported 650 by SNMPv3. 652 o 4.7.001 Management of Energy Resources, supported by Eman MIBs. 654 o 4.11.001 Avoid large messages, SNMP supports progessive transport 655 of data in self contained chunks. 657 o 4.11.002 Avoid reassembly at multiple layers, SNMP request 658 specifies data size per message. 660 Since much MIB creation effort can be done offline through macros, 661 and BER encoding is not extremely complex, it is feasible to 662 implement SNMP in constrained environments. Sharing the security 663 code between SNMP and DTLS/CoAP makes the inclusion of SNMP even more 664 attractive. 666 3.8. NETCONF 668 Cover at least: 670 o The NETCONF protocol is defined in [RFC6241] 672 o The YANG module is defined in [RFC6022] 674 o NETCONF is based on XML 676 3.9. Other requirements and candidate technologies 678 4.1.005 Automatic re-synchronisation with eventual consistency 680 4.1.006 Support for lossy links and unreachable devices 682 o Mechanisms for devices that are not sleepy, but have unstable 683 network connections (e.g. mobile devices) are needed. 685 4.1.008 Distributed management 687 4.2.006 Loss-less mapping of management data models 689 4.3.002 Capability discovery 691 4.3.004 Network reconfiguration 693 4.4.009 Recovery 695 4.4.010 Network topology discovery 697 4.7.001 Management of energy resources 699 4.7.002 Support of energy-optimized communication protocols 701 o 6LoWPAN [RFC4944] provides IPv6 functionality for IEEE 802.15.4 702 networks. 704 4.7.003 Support for layer 2 energy-aware protocols 706 o IEEE 802.15.4 [IEEE-802.15.4] provides wireless low power 707 communication on short distance. 709 4.7.004 Dying gasp 711 4.9.002 Redirect traffic 713 4.10.001 Scalable transport layer 714 4.10.002 Reliable unicast transport 716 4.10.004 Secure message transport 718 4.11.001 Avoid complex application layer transactions requiring large 719 application layer messages 721 4.11.002 Avoid reassembly of messages at multiple layers in the 722 protocol stack 724 4. High level requirements that need to be observed continuously 726 4.1.001 Support multiple device classes within a single network 728 4.1.002 Management scalability 730 4.1.004 Minimise state maintained on constrained devices 732 4.1.006 Support for lossy links and unreachable devices 734 4.2.002 Compact encoding of management data 736 o A binary format would be most compact. 738 o TLV could be considered. 740 o XML would be counter productive. 742 o JSON may be counter productive. 744 4.2.003 Compression of management data or complete messages 746 o When the messages are designed compact enough, compression will be 747 unnecessary. 749 4.2.007 Protocol extensibility 751 5. Table of requirements and related technologies 753 The Table 1 summarises the requirements and related or possible 754 candidate technologies. 756 +-----------+----------------+--------------------------------------+ 757 | Requireme | Name | Associated technology | 758 | nt number | | | 759 +-----------+----------------+--------------------------------------+ 760 | 4.1.001 | Support | [I-D.ietf-core-coap], [ISO16484-5], | 761 | | multiple | [RFC3410] | 762 | | device classes | | 763 | | within a | | 764 | | single network | | 765 | | | | 766 | 4.1.002 | Management | [ISO16484-5], [RFC3410] | 767 | | scalability | | 768 | | | | 769 | 4.1.003 | Hierarchical | [ISO16484-5] | 770 | | management | | 771 | | | | 772 | 4.1.004 | Minimise state | [I-D.ietf-core-coap], [ISO16484-5] | 773 | | maintained on | | 774 | | constrained | | 775 | | devices | | 776 | | | | 777 | 4.1.005 | Automatic re-s | | 778 | | ynchronisation | | 779 | | with eventual | | 780 | | consistency | | 781 | | | | 782 | 4.1.006 | Support for | [I-D.ietf-core-coap] [I-D.rahman- | 783 | | lossy links | core-sleepy], [I-D.shelby-core- | 784 | | and | resource-directory], [I-D.ietf-core- | 785 | | unreachable | observe] | 786 | | devices | | 787 | | | | 788 | 4.1.007 | Network-wide | [OMA-DM], [ISO16484-5] | 789 | | configuration | | 790 | | | | 791 | 4.1.008 | Distributed | [ISO16484-5] | 792 | | management | | 793 | | | | 794 | 4.2.001 | Modular | [ISO16484-5], [RFC3410] | 795 | | implementation | | 796 | | of management | | 797 | | protocols | | 798 | | | | 799 | 4.2.002 | Compact | [OMA-LwM2M-TS], [ISO16484-5] | 800 | | encoding of | | 801 | | management | | 802 | | data | | 803 | | | | 804 | 4.2.003 | Compression of | | 805 | | management | | 806 | | data or | | 807 | | complete | | 808 | | messages | | 809 | | | | 810 | 4.2.004 | Mapping of | [I-D.ietf-core-coap] | 811 | | management | | 812 | | protocol | | 813 | | interactions | | 814 | | | | 815 | 4.2.005 | Consistency of | [ISO16484-5], [RFC3410] | 816 | | data models | | 817 | | with the | | 818 | | underlying | | 819 | | information | | 820 | | model | | 821 | | | | 822 | 4.2.006 | Loss-less | | 823 | | mapping of | | 824 | | management | | 825 | | data models | | 826 | | | | 827 | 4.2.007 | Protocol | [I-D.ietf-core-coap], [ISO16484-5], | 828 | | extensibility | [RFC3410] | 829 | | | | 830 | 4.3.001 | Self- | [ISO16484-5] | 831 | | configuration | | 832 | | capability | | 833 | | | | 834 | 4.3.002 | Capability | [RFC6690], [I-D.greevenbosch-core- | 835 | | discovery | profile-description], [I-D.shelby- | 836 | | | core-resource-directory], [I-D.lynn- | 837 | | | core-discovery-mapping], [I-D | 838 | | | .vanderstok-core-dna], [ISO16484-5] | 839 | | | | 840 | 4.3.003 | Asynchronous | [I-D.ietf-core-coap] | 841 | | transaction | | 842 | | support | | 843 | | | | 844 | 4.3.004 | Network reconf | [ISO16484-5], [RFC3410] | 845 | | iguration | | 846 | | | | 847 | 4.4.001 | Device status | [OMA-LwM2M-TS], [ISO16484-5], | 848 | | monitoring | [RFC3410] | 849 | | | | 850 | 4.4.002 | Energy status | [OMA-LwM2M-TS], [ISO16484-5], | 851 | | monitoring | [RFC3410] | 852 | | | | 853 | 4.4.003 | Monitoring of | [OMA-DiagMon-MO], [ISO16484-5] | 854 | | current and | | 855 | | estimated | | 856 | | device | | 857 | | availability | | 858 | | | | 859 | 4.4.004 | Network status | [OMA-DiagMon-MO], [ISO16484-5], | 860 | | monitoring | [RFC3410] | 861 | | | | 862 | 4.4.005 | Self- | [OMA-DiagMon-MO], [ISO16484-5] | 863 | | monitoring | | 864 | | | | 865 | 4.4.006 | Performance | [OMA-DiagMon-MO], [ISO16484-5], | 866 | | monitoring | [RFC3410] | 867 | | | | 868 | 4.4.007 | Fault | [I-D.ietf-core-coap], [OMA-DiagMon- | 869 | | detection | MO], [ISO16484-5], [RFC3410] | 870 | | monitoring | | 871 | | | | 872 | 4.4.008 | Passive and | [OMA-DiagMon-MO] | 873 | | reactive | | 874 | | monitoring | | 875 | | | | 876 | 4.4.009 | Recovery | [ISO16484-5] | 877 | | | | 878 | 4.4.010 | Network | [ISO16484-5] | 879 | | topology | | 880 | | discovery | | 881 | | | | 882 | 4.4.011 | Notifications | [OMA-DiagMon-MO], [ISO16484-5], | 883 | | | [RFC3410] | 884 | | | | 885 | 4.4.012 | Logging | [OMA-LwM2M-TS], [ISO16484-5] | 886 | | | | 887 | 4.5.001 | Self- | [OMA-DiagMon-MO], [OMA-Scheduling- | 888 | | management - | MO] | 889 | | Self-healing | | 890 | | | | 891 | 4.6.001 | Authentication | [OMA-LwM2M-TS], [I-D.ietf-tls-oob- | 892 | | of management | pubkey], [I-D.greevenbosch-tls-ocsp- | 893 | | system and | lite], [ISO16484-5], [RFC3410] | 894 | | devices | | 895 | | | | 896 | 4.6.002 | Support | [OMA-LwM2M-TS], [OMA-DM], [I-D | 897 | | suitable | .jennings-core-transitive-trust- | 898 | | security | enrollment] | 899 | | bootstrapping | | 900 | | mechanisms | | 901 | | | | 902 | 4.6.003 | Access control | [OMA-LwM2M-TS], [OMA-DM], [RFC3410] | 903 | | on management | | 904 | | system and | | 905 | | devices | | 906 | | | | 907 | 4.6.004 | Select | | 908 | | cryptographic | | 909 | | algorithms | | 910 | | that are | | 911 | | efficient in | | 912 | | both code | | 913 | | space and | | 914 | | execution time | | 915 | | | | 916 | 4.7.001 | Management of | [IEEE-802.15.4], [I-D.rahman-core- | 917 | | energy | sleepy], [RFC3410] | 918 | | resources | | 919 | | | | 920 | 4.7.002 | Support of | [I-D.ietf-core-coap], [RFC4944], | 921 | | energy- | [I-D.rahman-core-sleepy], [I-D.ietf- | 922 | | optimized | core-observe], [I-D.shelby-core- | 923 | | communication | resource-directory] | 924 | | protocols | | 925 | | | | 926 | 4.7.003 | Support for | [IEEE-802.15.4] | 927 | | layer 2 | | 928 | | energy-aware | | 929 | | protocols | | 930 | | | | 931 | 4.7.004 | Dying gasp | | 932 | | | | 933 | 4.8.001 | Group-based | [I-D.ietf-core-groupcomm], [I-D | 934 | | provisioning | .vanderstok-core-dna], [RFC4604] | 935 | | | | 936 | 4.9.001 | Congestion | [I-D.ietf-core-coap], [I-D.li-core- | 937 | | avoidance | conditional-observe], [I-D.bormann- | 938 | | | core-cocoa], [I-D.greevenbosch-core- | 939 | | | minimum-request-interval] | 940 | | | | 941 | 4.9.002 | Redirect | | 942 | | traffic | | 943 | | | | 944 | 4.9.003 | Traffic delay | [I-D.ietf-core-coap], [I-D.li-core- | 945 | | schemes | conditional-observe], [I-D.bormann- | 946 | | | core-cocoa], [I-D.greevenbosch-core- | 947 | | | minimum-request-interval] | 948 | | | | 949 | 4.10.001 | Scalable | | 950 | | transport | | 951 | | layer | | 952 | | | | 953 | 4.10.002 | Reliable | | 954 | | unicast | | 955 | | transport | | 956 | | | | 957 | 4.10.003 | Best-effort | [ISO16484-5] | 958 | | multicast | | 959 | | | | 960 | 4.10.004 | Secure message | | 961 | | transport | | 962 | | | | 963 | 4.11.001 | Avoid complex | [RFC3410] | 964 | | application | | 965 | | layer | | 966 | | transactions | | 967 | | requiring | | 968 | | large | | 969 | | application | | 970 | | layer messages | | 971 | | | | 972 | 4.11.002 | Avoid | [ISO16484-5], [RFC3410] | 973 | | reassembly of | | 974 | | messages at | | 975 | | multiple | | 976 | | layers in the | | 977 | | protocol stack | | 978 +-----------+----------------+--------------------------------------+ 980 Table 1: Requirements and technologies 982 6. Conclusion and recommendations 984 In this document, we have identified technology standards that 985 currently cover many of the COMAN use cases. COMAN should consider 986 referencing these technologies when appropriate. In addition, this 987 document points at technologies that are not deployed in a standard, 988 and hence need new standardisation. We recommend to write a document 989 in COMAN that describes the overall envisaged management system and 990 suggests standardisation topics for IETF. 992 7. Security Considerations 994 TBD 996 8. IANA considerations 998 TBD 1000 9. Change Log 1001 v00 -> v01: 1003 o Added text about BACnet. 1005 v01 -> v02: 1007 o Updated text about BACnet. 1009 o Updated to match new requirements numbering in I-D.ersue- 1010 constrained-mgmt v04. 1012 v02 -> v03: 1014 o Added text about SNMP. 1016 o Added bullets about security choices in CoAP. 1018 10. References 1020 10.1. Normative References 1022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1023 Requirement Levels", BCP 14, RFC 2119, March 1997. 1025 10.2. Informative References 1027 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1028 Schoenwaelder, Ed., "Structure of Management Information 1029 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1031 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1032 Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 1033 58, RFC 2579, April 1999. 1035 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1036 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1037 April 1999. 1039 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1040 "Introduction and Applicability Statements for Internet- 1041 Standard Management Framework", RFC 3410, December 2002. 1043 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1044 Architecture for Describing Simple Network Management 1045 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1046 December 2002. 1048 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 1049 "Message Processing and Dispatching for the Simple Network 1050 Management Protocol (SNMP)", STD 62, RFC 3412, December 1051 2002. 1053 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 1054 Management Protocol (SNMP) Applications", STD 62, RFC 1055 3413, December 2002. 1057 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 1058 (USM) for version 3 of the Simple Network Management 1059 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 1061 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 1062 Access Control Model (VACM) for the Simple Network 1063 Management Protocol (SNMP)", STD 62, RFC 3415, December 1064 2002. 1066 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the 1067 Simple Network Management Protocol (SNMP)", STD 62, RFC 1068 3416, December 2002. 1070 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 1071 Management Protocol (SNMP)", STD 62, RFC 3417, December 1072 2002. 1074 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 1075 Simple Network Management Protocol (SNMP)", STD 62, RFC 1076 3418, December 2002. 1078 [RFC4113] Fenner, B. and J. Flick, "Management Information Base for 1079 the User Datagram Protocol (UDP)", RFC 4113, June 2005. 1081 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1082 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1083 for Transport Layer Security (TLS)", RFC 4492, May 2006. 1085 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1086 Group Management Protocol Version 3 (IGMPv3) and Multicast 1087 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1088 Specific Multicast", RFC 4604, August 2006. 1090 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1091 "Transmission of IPv6 Packets over IEEE 802.15.4 1092 Networks", RFC 4944, September 2007. 1094 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1095 Encryption", RFC 5116, January 2008. 1097 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1098 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1100 [RFC6022] Scott, M. and M. Bjorklund, "YANG Module for NETCONF 1101 Monitoring", RFC 6022, October 2010. 1103 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 1104 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 1105 RFC 6130, April 2011. 1107 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1108 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1109 6241, June 2011. 1111 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1112 Format", RFC 6690, August 2012. 1114 [I-D.ietf-core-coap] 1115 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 1116 Application Protocol (CoAP)", draft-ietf-core-coap-18 1117 (work in progress), June 2013. 1119 [I-D.ietf-core-groupcomm] 1120 Rahman, A. and E. Dijk, "Group Communication for CoAP", 1121 draft-ietf-core-groupcomm-09 (work in progress), May 2013. 1123 [I-D.ietf-core-observe] 1124 Hartke, K., "Observing Resources in CoAP", draft-ietf- 1125 core-observe-08 (work in progress), February 2013. 1127 [I-D.ietf-tls-oob-pubkey] 1128 Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 1129 T. Kivinen, "Out-of-Band Public Key Validation for 1130 Transport Layer Security (TLS)", draft-ietf-tls-oob- 1131 pubkey-07 (work in progress), February 2013. 1133 [I-D.bormann-core-cocoa] 1134 Bormann, C., "CoAP Simple Congestion Control/Advanced", 1135 draft-bormann-core-cocoa-00 (work in progress), August 1136 2012. 1138 [I-D.ersue-constrained-mgmt] 1139 Ersue, M., Romascanu, D., and J. Schoenwaelder, 1140 "Management of Networks with Constrained Devices: Problem 1141 Statement, Use Cases and Requirements", draft-ersue- 1142 constrained-mgmt-03 (work in progress), February 2013. 1144 [I-D.greevenbosch-core-minimum-request-interval] 1145 Greevenbosch, B., "CoAP Minimum Request Interval", draft- 1146 greevenbosch-core-minimum-request-interval-01 (work in 1147 progress), April 2013. 1149 [I-D.greevenbosch-core-profile-description] 1150 Greevenbosch, B., Hoebeke, J., Ishaq, I., and F. Abeele, 1151 "CoAP Profile Description Format", draft-greevenbosch- 1152 core-profile-description-02 (work in progress), June 2013. 1154 [I-D.greevenbosch-tls-ocsp-lite] 1155 Greevenbosch, B., "OCSP-lite - Revocation of raw public 1156 keys", draft-greevenbosch-tls-ocsp-lite-01 (work in 1157 progress), June 2013. 1159 [I-D.jennings-core-transitive-trust-enrollment] 1160 Jennings, C., "Transitive Trust Enrollment for Constrained 1161 Devices", draft-jennings-core-transitive-trust- 1162 enrollment-01 (work in progress), October 2012. 1164 [I-D.li-core-conditional-observe] 1165 Li, S., Hoebeke, J., Abeele, F., and A. Jara, "Conditional 1166 observe in CoAP", draft-li-core-conditional-observe-04 1167 (work in progress), June 2013. 1169 [I-D.lynn-core-discovery-mapping] 1170 Lynn, K. and Z. Shelby, "CoRE Link-Format to DNS-Based 1171 Service Discovery Mapping", draft-lynn-core-discovery- 1172 mapping-02 (work in progress), October 2012. 1174 [I-D.mcgrew-tls-aes-ccm-ecc] 1175 McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 1176 CCM ECC Cipher Suites for TLS", draft-mcgrew-tls-aes-ccm- 1177 ecc-06 (work in progress), February 2013. 1179 [I-D.rahman-core-sleepy] 1180 Rahman, A., "Enhanced Sleepy Node Support for CoAP", 1181 draft-rahman-core-sleepy-02 (work in progress), February 1182 2013. 1184 [I-D.schoenw-6lowpan-mib] 1185 Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou, 1186 "Definition of Managed Objects for IPv6 over Low-Power 1187 Wireless Personal Area Networks (6LoWPANs)", draft- 1188 schoenw-6lowpan-mib-03 (work in progress), February 2013. 1190 [I-D.shelby-core-resource-directory] 1191 Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource 1192 Directory", draft-shelby-core-resource-directory-05 (work 1193 in progress), February 2013. 1195 [I-D.vanderstok-core-dna] 1196 Stok, P., Lynn, K., and A. Brandt, "CoRE Discovery, 1197 Naming, and Addressing", draft-vanderstok-core-dna-02 1198 (work in progress), July 2012. 1200 [CCM] , "Recommendation for Block Cipher Modes of Operation: The 1201 CCM Mode for Authentication and Confidentiality ", 1202 National Institute of Standards and Technology SP 800-38C, 1203 May 2004. 1205 [IEEE-802.15.4] 1206 IEEE Computer Society, ., "IEEE std. 802.15.4-2003", 1207 October 2003. 1209 [ISO16484-5] 1210 , "Building automation and control systems -- Part 5: Data 1211 communication protocol", ISO 16484-5, 2012. 1213 [OMA-DM] , "OMA Device Management 1.3", OMA-ERP-DM-V1_3-20121213-C 1214 , December 2012. 1216 [OMA-DiagMon-MO] 1217 , "OMA Diagnostics and Monitoring Management Object", OMA- 1218 ERP-DiagMon-V1_0-20120313-A , March 2012. 1220 [OMA-FUMO] 1221 , "Firmware Update Management Object", OMA-TS-DM-FUMO- 1222 V1_0-20070209-A , February 2007. 1224 [OMA-Scheduling-MO] 1225 , "OMA DM Scheduling Management Object", OMA-ERP- 1226 DM_Scheduling-V1_0-20110614-C , June 2011. 1228 [OMA-LwM2M-TS] 1229 , "OMA Lightweight M2M", OMA-TS-LightweightM2M- 1230 V1_0-20130123-D (work in progress), January 2013. 1232 Authors' Addresses 1233 Bert Greevenbosch 1234 Huawei Technologies Co., Ltd. 1235 Huawei Industrial Base 1236 Bantian, Longgang District 1237 Shenzhen 518129 1238 P.R. China 1240 Email: bert.greevenbosch@huawei.com 1242 Kepeng Li 1243 Huawei Technologies Co., Ltd. 1244 Huawei Industrial Base 1245 Bantian, Longgang District 1246 Shenzhen 518129 1247 P.R. China 1249 Phone: +86-755-28971807 1250 Email: likepeng@huawei.com 1252 Peter van der Stok 1253 vanderstok consultancy 1255 Phone: +31-492474673 (Netherlands), +33-966015248 (France) 1256 Email: consultancy@vanderstok.org 1257 URI: www.vanderstok.org