Internet Engineering Task Force M. Veillette, Ed. Internet-Draft Trilliant Networks Inc. Intended status: Informational A. Pelov, Ed. Expires: May 4, 2016 Acklio S. Somaraju Tridonic GmbH & Co KG R. Somaraju Landis+Gyr November 1, 2015 Constrained Objects Language draft-veillette-core-cool-00 Abstract This document describes a management interface adapted to constrained devices and constrained (e.g., low-power, lossy) networks. CoOL resources (datastores, protocol operations and notifications) are defined using the YANG modelling language [RFC6020]. Interactions with these resources are performed using the CoAP web transfer protocol [RFC7252]. Payloads and specific CoAP options are encoded using the CBOR data format [RFC7049]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 4, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Veillette, et al. Expires May 4, 2016 [Page 1]
Internet-Draft Constrained Objects Language November 2015 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 3. CoAP Interface . . . . . . . . . . . . . . . . . . . . . . . 5 4. Textual representation of CBOR contents . . . . . . . . . . . 6 5. YANG to CBOR mapping . . . . . . . . . . . . . . . . . . . . 7 5.1. YANG leaf . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1.1. YANG type: binary . . . . . . . . . . . . . . . . . . 8 5.1.2. YANG type: bits . . . . . . . . . . . . . . . . . . . 8 5.1.3. YANG type: boolean . . . . . . . . . . . . . . . . . 9 5.1.4. YANG type: decimal64 . . . . . . . . . . . . . . . . 9 5.1.5. YANG type: empty . . . . . . . . . . . . . . . . . . 9 5.1.6. YANG type: enumeration . . . . . . . . . . . . . . . 10 5.1.7. YANG type: identityref . . . . . . . . . . . . . . . 10 5.1.8. YANG type: instance-identifier . . . . . . . . . . . 11 5.1.9. YANG type: int8, int16, int32, int64 . . . . . . . . 13 5.1.10. YANG type: leafref . . . . . . . . . . . . . . . . . 13 5.1.11. YANG type: string . . . . . . . . . . . . . . . . . . 14 5.1.12. YANG type: uint8, uint16, uint32, uint64 . . . . . . 14 5.1.13. YANG type: union . . . . . . . . . . . . . . . . . . 14 5.1.14. YANG type: anyxml . . . . . . . . . . . . . . . . . . 15 5.1.15. YANG type: container . . . . . . . . . . . . . . . . 16 5.1.16. YANG type: leaf-list . . . . . . . . . . . . . . . . 17 5.1.17. YANG type: list . . . . . . . . . . . . . . . . . . . 18 5.1.18. YANG type: choice . . . . . . . . . . . . . . . . . . 20 6. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Module ID . . . . . . . . . . . . . . . . . . . . . . . . 21 6.2. Data node ID (DNID) . . . . . . . . . . . . . . . . . . . 21 6.3. Fully-qualified data node ID (FQDNID) . . . . . . . . . . 22 6.4. Notification ID . . . . . . . . . . . . . . . . . . . . . 23 6.5. Notification parameter ID . . . . . . . . . . . . . . . . 23 6.6. Protocol operation ID . . . . . . . . . . . . . . . . . . 24 6.7. Input parameter ID . . . . . . . . . . . . . . . . . . . 24 6.8. Output parameter ID . . . . . . . . . . . . . . . . . . . 25 6.9. Identifier examples . . . . . . . . . . . . . . . . . . . 26 7. Protocol details . . . . . . . . . . . . . . . . . . . . . . 30 7.1. Retrieving data node(s) . . . . . . . . . . . . . . . . . 30 7.2. The Fields CoAP option . . . . . . . . . . . . . . . . . 32 Veillette, et al. Expires May 4, 2016 [Page 2]
Internet-Draft Constrained Objects Language November 2015 7.3. Retrieving all data nodes . . . . . . . . . . . . . . . . 32 7.4. Updating data node(s) . . . . . . . . . . . . . . . . . . 34 7.5. Retrieving data node(s) from a list . . . . . . . . . . . 35 7.6. Retrieving multiple entries from a list . . . . . . . . . 37 7.7. Retrieving multiple entries of a single data node from a list . . . . . . . . . . . . . . . . . . . . . . . . . . 39 7.8. Updating a list entry . . . . . . . . . . . . . . . . . . 39 7.9. Adding a list entry . . . . . . . . . . . . . . . . . . . 41 7.10. Deleting list entries . . . . . . . . . . . . . . . . . . 42 7.11. Patch . . . . . . . . . . . . . . . . . . . . . . . . . . 43 7.12. Protocol operation . . . . . . . . . . . . . . . . . . . 45 7.13. Event stream . . . . . . . . . . . . . . . . . . . . . . 46 7.14. Observe . . . . . . . . . . . . . . . . . . . . . . . . . 49 7.15. Resource discovery . . . . . . . . . . . . . . . . . . . 50 7.16. Modules, sub-modules, and objects discovery . . . . . . . 51 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 53 9. Security Considerations . . . . . . . . . . . . . . . . . . . 54 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 10.1. Module ID . . . . . . . . . . . . . . . . . . . . . . . 54 10.2. "Fields" CoAP Option Number . . . . . . . . . . . . . . 55 10.3. "PATCH" CoAP Method Code . . . . . . . . . . . . . . . . 55 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 11.1. Normative References . . . . . . . . . . . . . . . . . . 56 11.2. Informative References . . . . . . . . . . . . . . . . . 56 Appendix A. ietf-cool YANG module . . . . . . . . . . . . . . . 57 Appendix B. ietf-cool-library YANG module . . . . . . . . . . . 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 1. Introduction CoOL is based on the current [I-D.vanderstok-core-comi] draft but instead of using YANG hashes to identify objects, CoOL uses structured identifiers. This approach reduces both message size and implementation footprints. This approach facilitates its use in both centralized (e.g. Network Management System, Path Computation Element), and decentralized scenarios. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This specification makes use of the following terminology: o CoOL client: The originating endpoint of a request, and the destination endpoint of a response. Veillette, et al. Expires May 4, 2016 [Page 3]
Internet-Draft Constrained Objects Language November 2015 o CoOL server: The destination endpoint of a request, and the originating endpoint of a response. o Data node: A node in the YANG schema that can be instantiated in a Datastore. One of container, leaf, leaf-list, list, or anyxml. o Data node ID (DNID): Identifier automatically or manually assigned to a data node. This identifier is unique within the scope of a YANG module. o Data tree: Hierarchy of instantiated data nodes. o Child data node: A data node defined within a container or a list is a child of this container or list. The container or list is the parent of the data node. o Datastore resource: Resource used to store and access information. o Endpoint: An entity participating in the CoOL protocol. Multiple CoOL endpoints may be accessible using a single CoAP endpoint. In this case, each CoOL enpoint is accessed using a distinct URI. o Event stream resource: Resource used to access event notifications generated by a CoOL server. Events are defined using the YANG notification statement. o Fully qualified data node ID (FQDNID): Concatenation of the Module ID and the Data node ID. This identifier uniquely identifies a data node. o Identifier: An identifier embodies the information required to distinguish what is being identified from all other things within its scope of identification. o Instance selector: A CBOR array containing the information required to identify one or multiple entries within a YANG list. o Module ID: Registered identifier assigned to a YANG module. o Notification ID: Identifier automatically or manually assigned to a YANG notification. This identifier is unique within the scope of a YANG module. o Object: Within CoOL, objects are a data node within a datastore resource, an RPC within a protocol operation resource, or a notification within an event stream resource. o Parent data node: See Child data node. Veillette, et al. Expires May 4, 2016 [Page 4]
Internet-Draft Constrained Objects Language November 2015 o Protocol operation resource: Resource used to invoke remote procedure calls as defined by the YANG "rpc" statement. o Protocol operation ID: Identifier automatically or manually assigned to a YANG "rpc". This identifier is unique within the scope of a YANG module. o Resource: Content identified by a URI. o Schema tree: Hierarchy of data nodes specified within a module. 2. Architecture The CoOL protocol is based on the client-server model. The CoOL server is the provider of the datastore resource, the protocol operation resource, and the notification resource. The CoOL client is the requester of these resources. CoOL objects are defined using the YANG modeling language [RFC6020]. Interactions with these objects are performed using the Constrained Application Protocol (CoAP) [RFC7252]. Payloads are encoded using the Concise Binary Object Representation (CBOR) [RFC7049]. This specification is applicable to any transport or security protocols supported by CoAP. Implementers are free to select the most appropriate transport for the targeted applications. +--------------+ +----------------------------------+ | CoOL client | | CoOL Server | | | | - Datastore resource(s) | | | | - Event stream resource(s) | | | | - Protocol operation resource(s) | +--------------+ +----------------------------------+ | CoAP client | <-------> | CoAP Server | +--------------+ +----------------------------------+ | | | | | Lower layers | | Lower layers | | | | | +--------------+ +----------------------------------+ 3. CoAP Interface This section lists the URIs recommended for the different CoOL resources. A CoOL server MAY implement a different set of URIs. (See the Resource discovery section (Section 7.15) for more details on how a CoOL client can discover the list of URIs supported by a CoOL server using the "/.well-known/core" resource.) Veillette, et al. Expires May 4, 2016 [Page 5]
Internet-Draft Constrained Objects Language November 2015 o /cool - URI used to access the datastore resource of the default endpoint. o /cool/rpc - URI used to access the protocol operation resource of the default endpoint. o /cool/ep0, /cool/ep1, ... - URI used to access the datastore resource of a specific endpoint. o /cool/ep0/rpc, /cool/ep1/rpc, ... - URI used to access the protocol operation resource of a specific endpoint. o /cool/stream - URI used to access the default event stream for this device. o /cool/ep0/stream, /cool/ep1/stream, ... - URI used to access the default event stream of a specific endpoint. o /cool/stream/0, /cool/stream/1, ... - URI used to access alternate event streams. Support of endpoints and event streams are optional. The CoAP response code 4.04 (Not Found) MUST be returned when a CoOL client tries to access a resource that is unavailable. 4. Textual representation of CBOR contents CoOL encodes payloads and the "Fields" CoAP option using the Concise Binary Object Representation (CBOR) as defined by [RFC7049]. Within this document, this binary encoding is represented using an equivalent textual form. This textual form is used strictly for documentation purposes and is never transmitted as such. Veillette, et al. Expires May 4, 2016 [Page 6]
Internet-Draft Constrained Objects Language November 2015 The following table summarizes this representation. To facilitate its understanding, this representation follows the JSON syntax (when possible). +----------+------+--------------------------+-----------+----------+ | CBOR | CBOR | Text representation | Example | CBOR | | content | type | | | encoding | +----------+------+--------------------------+-----------+----------+ | Unsigned | 0 | Decimal digits | 123 | 18 7b | | integer | | | | | | | | | | | | Negative | 1 | Decimal digits prefixed | -123 | 38 7a | | integer | | by a minus sign. | | | | | | | | | | Byte | 2 | Hexadecimal value | h' f15c' | 42 f15c | | string | | enclosed between single | | | | | | quotes and prefixed by | | | | | | an 'h'. | | | | | | | | | | Text | 3 | String of Unicode | "txt" | 63 | | string | | characters enclosed | | 747874 | | | | between double quotes | | | | | | | | | | Array | 4 | Comma separated list | [ 1, 2 ] | 82 01 02 | | | | of values within | | | | | | square brackets. | | | | | | | | | | Map | 5 | Comma separated list | { | a2 | | | | of name/value pair | 1: 123, | 01187b | | | | within curly braces. | 2: 456 | 021901c8| | | | | } | | | | | | | | | Boolean | 7/20 | false | false | f4 | | | 7/21 | true | true | f5 | | | | | | | | Null | 7/22 | null | null | f6 | | | | | | | | Not | 7/23 | undefined | undefined | f7 | | assigned | | | | | +----------+------+--------------------------+-----------+----------+ 5. YANG to CBOR mapping Objects defined using the YANG modeling language are encoded using CBOR [RFC7049] based on the rules defined in this section. We assume that the reader is already familiar with both YANG [RFC6020] and CBOR [RFC7049]. Veillette, et al. Expires May 4, 2016 [Page 7]
Internet-Draft Constrained Objects Language November 2015 5.1. YANG leaf The leaf statement defines a data node associated with a value. The following subsections describe the encoding of different leaf types. 5.1.1. YANG type: binary Leafs of type binary MUST be encoded using a CBOR byte string data item (major type 0). Definition example: leaf aes128-key { type binary { length 16; } } Textual form: h'1f1ce6a3f42660d888d92a4d8030476e' CBOR encoding: 50 1f1ce6a3f42660d888d92a4d8030476e 5.1.2. YANG type: bits Leafs of type bits MUST be encoded using a CBOR byte string data item (major type 0). Bits position 0 to 7 are assigned to the first byte within the byte string, bits 8 to 15 to the second byte, and subsequent bytes are assigned similarly. Within each byte, bits are assigned from least to most significant. Definition example [RFC6020]: leaf mybits { type bits { bit disable-nagle { position 0; } bit auto-sense-speed { position 1; } bit 10-Mb-only { position 2; } } } Textual form: h'05' (Represents bits disable-nagle and 10-Mb-only set) Veillette, et al. Expires May 4, 2016 [Page 8]
Internet-Draft Constrained Objects Language November 2015 CBOR encoding: 41 05 5.1.3. YANG type: boolean Leafs of type boolean MUST be encoded using a CBOR true (major type 7, additional information 21) or false data item (major type 7, additional information 20). Definition example [RFC7317]: leaf enabled { type boolean; } Textual form: true CBOR encoding: f5 5.1.4. YANG type: decimal64 Leafs of type decimal64 MUST be encoded using a CBOR unsigned integer data item (major type 0). Definition example [RFC7317]: leaf my-decimal { type decimal64 { fraction-digits 2; range "1 .. 3.14 | 10 | 20..max"; } } Textual form: 257 (Represents decimal value 2.57) CBOR encoding: 19 0101 5.1.5. YANG type: empty Leafs of type empty MUST be encoded using the CBOR null value (major type 7, additional information 22). Definition example [RFC7277]: leaf is-router { type empty; } Textual form: null Veillette, et al. Expires May 4, 2016 [Page 9]
Internet-Draft Constrained Objects Language November 2015 CBOR encoding: f6 5.1.6. YANG type: enumeration Leafs of type enumeration MUST be encoded using a CBOR unsigned integer data item (major type 0). Definition example [RFC7317]: leaf oper-status { type enumeration { enum up { value 1; } enum down { value 2; } enum testing { value 3; } enum unknown { value 4; } enum dormant { value 5; } enum not-present { value 6; } enum lower-layer-down { value 7; } } } Textual form: 3 (Represents enumeration value "testing") CBOR encoding: 03 5.1.7. YANG type: identityref Leafs of type identityref MUST be encoded using a CBOR text string data item (major type 3). Unlike XML, CBOR does not support namespaces. To overcome this limitation, identities are encoded using a concatenation of the identity name(s) of the referenced identities, excluding the base identity and separated by dot(s). Veillette, et al. Expires May 4, 2016 [Page 10]
Internet-Draft Constrained Objects Language November 2015 Definition example [RFC7223]: identity interface-type { } identity iana-interface-type { base interface-type; } identity ethernetCsmacd { base iana-interface-type; } leaf type { type identityref { base interface-type; } } Textual form: "iana-interface-type.ethernetCsmacd" CBOR encoding: 78 22 69616e612d696e746572666163652d747970652e65746865726e657443736d616364 5.1.8. YANG type: instance-identifier When a leaf node of type instance-identifier identifies a single instance data node (data node not part of a list), its value MUST be encoded using a CBOR unsigned integer data item (major type 0) containing the targeted data node ID. Definition example [RFC7317]: container system { leaf contact { type string; } leaf hostname { type inet:domain-name; } } Textual form: 69635 CBOR encoding: 1a 00011003 Veillette, et al. Expires May 4, 2016 [Page 11]
Internet-Draft Constrained Objects Language November 2015 In this example, the value 69635 identifies the instance of the data node "hostname" within the ietf-system module. Assuming module ID = 68 and data node ID = 3. When a leaf node of type instance-identifier identifies a data node supporting multiple instances (data node part of a list), its value MUST be encoded using a CBOR array data item (major type 4) containing the following entries: o a CBOR unsigned integer data item (major type 0) containing the fully-qualified data node ID of the targeted data node. o a CBOR array data item (major type 4) containing the value of each key required to identify the instance of the targeted data node. These keys MUST be ordered as defined in the "key" YANG statement, starting from top level list, and follow by each of the subordinate list(s). Definition example [RFC7317]: list user { key name; leaf name { type string; } leaf password { type ianach:crypt-hash; } list authorized-key { key name; leaf name { type string; } leaf algorithm { type string; } leaf key-data { type binary; } } Textual form: [69679, ["bob", "admin"]] CBOR encoding: 82 1a 0001102f 82 63 626f62 65 61646d696e Veillette, et al. Expires May 4, 2016 [Page 12]
Internet-Draft Constrained Objects Language November 2015 This example identifies the instance of the data node "key-data" within the ietf-system module, associated with user name "bob" and authorized-key name "admin". Assuming module ID = 68 and data node ID = 47. 5.1.9. YANG type: int8, int16, int32, int64 Leafs of type int8, int16, int32 and int64 MUST be encoded using either CBOR unsigned integer (major type 0) or CBOR signed integer (major type 0), depending on the actual value. Definition example [RFC7317]: leaf timezone-utc-offset { type int16 { range "-1500 .. 1500"; } } Textual form: -300 CBOR encoding: 39 012b 5.1.10. YANG type: leafref Leafs of type leafref MUST be encoded using the rules of the data node referenced by the "path" YANG statement. Definition example [RFC7223]: typedef interface-state-ref { type leafref { path "/interfaces-state/interface/name"; } } container interfaces-state { list interface { key "name"; leaf name { type string; } leaf-list higher-layer-if { type interface-state-ref; } } } Veillette, et al. Expires May 4, 2016 [Page 13]
Internet-Draft Constrained Objects Language November 2015 Textual form: "eth1.10" CBOR encoding: 67 657468312e3130 5.1.11. YANG type: string Leafs of type string MUST be encoded using a CBOR text string data item (major type 3). Definition example [RFC7223]: leaf name { type string; } Textual form: "eth0" CBOR encoding: 64 65746830 5.1.12. YANG type: uint8, uint16, uint32, uint64 Leafs of type uint8, uint16, uint32 and uint64 MUST be encoded using a CBOR unsigned integer data item (major type 0). Definition example [RFC7277]: leaf mtu { type uint16 { range "68..max"; } } Textual form: 1280 CBOR encoding: 19 0500 5.1.13. YANG type: union Leafs of type union MUST be encoded using the rules associated with one of the type listed. Veillette, et al. Expires May 4, 2016 [Page 14]
Internet-Draft Constrained Objects Language November 2015 Definition example [RFC7317]: typedef ipv4-address { type string { pattern '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3} ([0-9][1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])(%[\p{N} \p{L}]+)?'; } } typedef ipv6-address { type string { pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}((([0-9a -fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|(((25[0-5]|2[0-4][0 -9]|[01]?[0-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0 -9]?[0-9])))(%[\p{N}\p{L}]+)?'; pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|((([^:]+:)*[^:]+) ?::(([^:]+:)*[^:]+)?)(%.+)?'; } } typedef ip-address { type union { type ipv4-address; type ipv6-address; } } leaf address { type inet:ip-address; } Textual form: "[2001:db8:0:1]:80" CBOR encoding: 71 5b323030313a6462383a303a315d3a3830 5.1.14. YANG type: anyxml The "anyxml" statement represents an unknown data node. The encoding of this data node MUST follow the rules of one of the YANG statements listed in Section 5. Definition example [RFC6020]: anyxml data; Textual form: 123 Veillette, et al. Expires May 4, 2016 [Page 15]
Internet-Draft Constrained Objects Language November 2015 CBOR encoding: 18 7b Alternate value: { 1 : 2, 2 : 55 } CBOR encoding: a2 01 02 02 18 37 5.1.15. YANG type: container A container MUST be encoded using a CBOR map data item (major type 5). A map is comprised of pairs of data items, with each data item consisting of a key and a value. CBOR map keys MUST be encoded using a CBOR unsigned integer (major type 0) and set to a data node ID or a fully-qualified data node ID. Data node IDs MUST be used when a parent node exists and this parent shares the same module ID as the current data node. CBOR map values MUST be encoded using the rules associated with the data node type. Definition example [RFC7317]: typedef date-and-time { type string { pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?(Z|[\+\-] \d{2}:\d{2})'; } } container clock { leaf current-datetime { type date-and-time; } leaf boot-datetime { type date-and-time; } } Veillette, et al. Expires May 4, 2016 [Page 16]
Internet-Draft Constrained Objects Language November 2015 Textual form: { 69667 : { 36 : "2015-10-02T14:47:24Z-05:00", 37 : "2015-09-15T09:12:58Z-05:00" } } CBOR encoding: a1 1a 00011023 a2 18 24 78 1a 323031352d31302d30325431343a34373a32345a2d30353a3030 18 25 78 1a 323031352d30392d31355430393a31323a35385a2d30353a3030 In this example, we assume that the module ID = 68, data node IDs clock = 35, current-datetime = 36 and boot-datetime 37. 5.1.16. YANG type: leaf-list A leaf-list MUST be encoded using a CBOR array data item (major type 4). Each entry MUST be encoded using the rules defined by the type specified. Definition example [RFC7317]: typedef domain-name { type string { length "1..253"; pattern '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9].) *([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.? )|\.'; } } leaf-list search { type domain-name; ordered-by user; } Textual form: [ "ietf.org", "ieee.org" ] CBOR encoding: 82 68 696574662e6f7267 68 696565652e6f7267 Veillette, et al. Expires May 4, 2016 [Page 17]
Internet-Draft Constrained Objects Language November 2015 5.1.17. YANG type: list A list MUST be encoded using a CBOR array data item (major type 4). Each entry of this array is encoded using a CBOR map data item (major type 5) following the same rules as a YANG container. Definition example [RFC7317]: list server { key name; leaf name { type string; } choice transport { case udp { container udp { leaf address { type host; mandatory true; } leaf port { type port-number; } } } } leaf association-type { type enumeration { enum server; enum peer; enum pool; } default server; } leaf iburst { type boolean; default false; } leaf prefer { type boolean; default false; } } Veillette, et al. Expires May 4, 2016 [Page 18]
Internet-Draft Constrained Objects Language November 2015 Textual form: { 69642 : [ { 11: "NRC TIC server", 12 : { 13: "tic.nrc.ca", 14: 123 }, 15 : 0, 16 : false, 17 : true }, { 11: "NRC TAC server", 12 : { 13: "tac.nrc.ca" } } ] } CBOR encoding: a1 1a 0001100a 82 a5 0b 6e 4e52432054494320736572766572 0c a2 0d 6a 7469632e6e72632e6361 0e 18 7b 0f 00 10 f4 11 f5 a2 0b 6f 4e5243205441432073657276657220 0c a1 0d 6a 7461632e6e72632e6361 In this example, we assume that the module ID = 68, data node IDs server = 10, name = 11, udp = 12, address = 13, port = 14, association-type = 15, iburst = 16, prefer = 17. Veillette, et al. Expires May 4, 2016 [Page 19]
Internet-Draft Constrained Objects Language November 2015 5.1.18. YANG type: choice YANG allows the data model to segregate incompatible nodes into distinct choices using the "choice" and "case" statements. Encoded payload MUST carry data nodes defined in only one of the possible cases. Definition example [RFC7317]: typedef timezone-name { type string; } choice timezone { case timezone-name { leaf timezone-name { type timezone-name; } } case timezone-utc-offset { leaf timezone-utc-offset { type int16 { range "-1500 .. 1500"; } units "minutes"; } } } Textual form: { 69638 : "Europe/Stockholm" } CBOR encoding: a1 1a 00011006 70 4575726f70652f53746f636b686f6c6d 6. Identifiers All CoOL objects are associated with a unique identifier. The uniqueness of these identifiers is guaranteed by the registration of a module ID used as a prefix for the different manually or automatically assigned identifiers. Veillette, et al. Expires May 4, 2016 [Page 20]
Internet-Draft Constrained Objects Language November 2015 6.1. Module ID A module ID is shared by all objects defined by a module. This includes data nodes, protocol operations, and notifications defined by a YANG module and included YANG sub-modules. Module IDs SHALL be registered; see Section 10.1 for more details. A registered module ID can be added to a YANG definition file using the YANG extension module-id. Refer to Appendix A for the definition of this extension. Example: module example { import ietf-cool { prefix "cool"; } cool:module-id "123"; ... } 6.2. Data node ID (DNID) Each data node defined within a YANG module and included YANG sub- module(s) MUST be associated with a unique identifier within the scope of this module. Data node IDs can be assigned automatically or manually. Data node IDs are assigned manually using the YANG extension "id". The argument of this extension contains the path of the assigned data node followed by the associated identifier; these two parts are separated by a space. Example: cool:id "/container-name/leaf-name 5"; When assigned automatically, data nodes are numbered based on their location in the schema tree. o Top level data nodes are listed in the same order as defined in the YANG module or sub-module. Veillette, et al. Expires May 4, 2016 [Page 21]
Internet-Draft Constrained Objects Language November 2015 o Top level data nodes defined in sub-modules are listed after those defined in the module. Sub-modules are ordered based on the order of the include statements in the associated module. o Data nodes within containers or lists are listed following their parent node and in the same order as defined. o Data nodes defined within an augment YANG statement are considered top-level nodes and numbered accordingly. o The "first-assigned-node-id" YANG extension can be used to control the data node ID of the first data node automatically assigned. When this extension is absent, the first data node ID is one. Subsequent data nodes are assigned sequentially. o Data node that are manually assigned are skipped. o It is the responsibility of the module author to avoid any conflicts between the manually and automatically assigned data node IDs. Manually assigned identifiers MUST be either lower than the value of "first-assigned-node-id" extension or higher than any identifiers assigned automatically. o When a module is updated, old Data node IDs can be preserved by adding top level data nodes to the end of the module or by manually assigning new data nodes within the schema tree. o Data node ID zero is reserved for a virtual root containing all top level objects for a module. 6.3. Fully-qualified data node ID (FQDNID) The fully-qualified data node ID is the concatenation of the module ID and the data node ID. A fully-qualified data node ID is globally unique. The fully-qualified data node ID is constructed as follows: o Bits 0 to 9 (least significant bits) are set to the data node ID assigned to the data node. o Bits 10 to 29 are set to the module ID registered to the YANG module containing the data node. o Bits 30 to 31 are reserved and set to zero. Data node IDs MUST be used when the module ID can be inferred from the parent data node in a YANG container or YANG list, or from the Veillette, et al. Expires May 4, 2016 [Page 22]
Internet-Draft Constrained Objects Language November 2015 previous ID in the array of the "Fields" CoAP option. Otherwise, the fully qualified ID MUST be used. 6.4. Notification ID Each notification defined MUST be associated with a unique identifier within the scope of its associated YANG module and YANG sub- module(s). Notification IDs can be assigned automatically or manually. Notification IDs can be assigned manually using the YANG extension "id". The argument of this extension contains the path of the assigned notification followed by the associated identifier. Example: cool:id "/system-status-update 1"; When assigned automatically, Notification IDs are assigned as follows: o Notifications are ordered based on their location in the YANG definition file. o Notifications defined in the sub-module are listed after those defined in the module. Sub-modules are ordered based on the order of the include statements in the associated module. o The "first-assigned-notification-id" YANG extension can be used to control the notification ID of the first notification automatically assigned. When this extension is absent, the first notification ID is one. Subsequent notifications are assigned sequentially. 6.5. Notification parameter ID Each notification parameter MUST be associated with a unique identifier within the scope of this notification. Notification parameter IDs can be assigned automatically or manually. Notification parameter IDs are assigned manually using the YANG extension "id". The argument of this extension contains the path of the assigned notification parameter followed by the associated identifier. Example: cool:id "/system-status-update/current-time 2"; Veillette, et al. Expires May 4, 2016 [Page 23]
Internet-Draft Constrained Objects Language November 2015 When assigned automatically, Notification parameter IDs are assigned as follows: o Top level parameters are listed in the same order as defined. o Parameters defined within a container or a list are listed following their parent node and in the same order as defined. o The first parameter is assigned to ID one, subsequent parameters are assigned sequentially. o Manually assigned parameters are skipped. 6.6. Protocol operation ID Each protocol operation defined MUST be associated with a unique identifier within the scope of its associated YANG module and YANG sub-module(s). Protocol operation IDs can be assigned automatically or manually. Protocol operation IDs are assigned manually using the YANG extension "id". The argument of this extension contains the path of the assigned protocol operation followed by the associated identifier. Example: cool:id "/system-shutdown 3"; When assigned automatically, Protocol operation IDs are assigned as follows: o RPCs are ordered based on their location in the YANG definition file. o RPCs defined in the sub-module are listed after those defined in the module. Sub-modules are ordered based on the order of the include statements in the associated module. o The "first-assigned-rpc-id" YANG extension can be used to control the protocol operation ID of the first RPC automatically assigned. When this extension is absent, the first protocol operation ID is one. Subsequent RPCs are assigned sequentially. 6.7. Input parameter ID Each input parameter MUST be associated with a unique identifier within the scope of the RPC input. Veillette, et al. Expires May 4, 2016 [Page 24]
Internet-Draft Constrained Objects Language November 2015 Input parameter IDs can be assigned automatically or manually. Input parameter IDs are assigned manually using the YANG extension "id". The argument of this extension contains the path of the assigned input parameter followed by the associated identifier. Example: cool:id "/is-supported/input/module-id 1"; When assigned automatically, Input parameter IDs are assigned as follows: o Top level input parameters are listed in the same order as defined. o Input parameters defined within a container or a list are listed following their parent nodes and in the same order as defined. o The first input parameter is assigned to ID one, subsequent input parameters are assigned sequentially. o Manually assigned input parameters are skipped. 6.8. Output parameter ID Each output parameter MUST be associated with a unique identifier within the scope of the RPC output. Output parameter IDs can be assigned automatically or manually. Output parameter IDs are assigned manually using the YANG extension "id". The argument of this extension contains the path of the assigned output parameter followed by the associated identifier. Example: cool:id " /is-supported/output/supported 1"; When assigned automatically, Output parameter IDs are assigned as follows: o Top level output parameters are listed in the same order as defined. o Output parameters defined within a container or a list are listed following their parent node and in the same order as defined. o The first output parameter is assigned to ID one, subsequent output parameters are assigned sequentially. Veillette, et al. Expires May 4, 2016 [Page 25]
Internet-Draft Constrained Objects Language November 2015 o Manually assigned output parameters are skipped. 6.9. Identifier examples YANG modules do not need to be updated to be implemented using CoOL. Identifiers can be automatically assigned without the presence of any YANG extensions. Following is the outcome of this process applied to the ietf-system YANG module [RFC7317]. +------+--------+--------------------------------------------------+ | DNID | FQDNID | Data node | +------+--------+--------------------------------------------------+ | 0 | 69632 | / | | 1 | 69633 | /system | | 2 | 69634 | /system/contact | | 3 | 69635 | /system/hostname | | 4 | 69636 | /system/location | | 5 | 69637 | /system/clock | | 6 | 69638 | /system/clock/timezone/timezone-name/ | | | | timezone-name | | 7 | 69639 | /system/clock/timezone/timezone-utc-offset | | | | /timezone-utc-offset | | 8 | 69640 | /system/ntp | | 9 | 69641 | /system/ntp/enabled | | 10 | 69642 | /system/ntp/server | | 11 | 69643 | /system/ntp/server/name | | 12 | 69644 | /system/ntp/server/transport/udp/udp | | 13 | 69645 | /system/ntp/server/transport/udp/udp/address | | 14 | 69646 | /system/ntp/server/transport/udp/udp/port | | 15 | 69647 | /system/ntp/server/association-type | | 16 | 69648 | /system/ntp/server/iburst | | 17 | 69649 | /system/ntp/server/prefer | | 18 | 69650 | /system/dns-resolver | | 19 | 69651 | /system/dns-resolver/search | | 20 | 69652 | /system/dns-resolver/server | | 21 | 69653 | /system/dns-resolver/server/name | | 22 | 69654 | /system/dns-resolver/server/transport/ | | | | udp-and-tcp/udp-and-tcp | | 23 | 69655 | /system/dns-resolver/server/transport/ | | | | udp-and-tcp/udp-and-tcp/address | | 24 | 69656 | /system/dns-resolver/server/transport/ | | | | udp-and-tcp/udp-and-tcp/port | | 25 | 69657 | /system/dns-resolver/options | | 26 | 69658 | /system/dns-resolver/options/timeout | | 27 | 69659 | /system/dns-resolver/options/attempts | | 28 | 69660 | /system/radius | | 29 | 69661 | /system/radius/server | | 30 | 69662 | /system/radius/server/name | Veillette, et al. Expires May 4, 2016 [Page 26]
Internet-Draft Constrained Objects Language November 2015 | 31 | 69663 | /system/radius/server/transport/udp/udp | | 32 | 69664 | /system/radius/server/transport/udp/udp/address | | 33 | 69665 | /system/radius/server/transport/udp/udp/ | | | | authentication-port | | 34 | 69666 | /system/radius/server/transport/udp/udp/ | | | | shared-secret | | 35 | 69667 | /system/radius/server/authentication-type | | 36 | 69668 | /system/radius/options | | 37 | 69669 | /system/radius/options/timeout | | 38 | 69670 | /system/radius/options/attempts | | 39 | 69671 | /system/authentication | | 40 | 69672 | /system/authentication/user-authentication-order | | 41 | 69673 | /system/authentication/user | | 42 | 69674 | /system/authentication/user/name | | 43 | 69675 | /system/authentication/user/password | | 44 | 69676 | /system/authentication/user/authorized-key | | 45 | 69677 | /system/authentication/user/authorized-key/name | | 46 | 69678 | /system/authentication/user/authorized-key/ | | | | algorithm | | 47 | 69679 | /system/authentication/user/authorized-key/ | | | | key-data | | 48 | 69680 | /system-state | | 49 | 69681 | /system-state/platform | | 50 | 69682 | /system-state/platform/os-name | | 51 | 69683 | /system-state/platform/os-release | | 52 | 69684 | /system-state/platform/os-version | | 53 | 69685 | /system-state/platform/machine | | 54 | 69686 | /system-state/clock | | 55 | 69687 | /system-state/clock/current-datetime | | 56 | 69688 | /system-state/clock/boot-datetime | +------+--------+--------------------------------------------------+ +----------------------+--------------------------------------------+ | Protocol operation | Protocol operation | | IDs | | +----------------------+--------------------------------------------+ | 1 | /set-current-datetime | | | +--------------------+-------------------+ | | | | Input parameter ID | Input parameter | | | | +--------------------+-------------------+ | | | | 1 | /current-datetime | | | | +--------------------+-------------------+ | | | | | 2 | /system-restart | | 3 | /system-shutdown | +----------------------+--------------------------------------------+ Veillette, et al. Expires May 4, 2016 [Page 27]
Internet-Draft Constrained Objects Language November 2015 If we assume that the extensions shown below have been added to this module: Example: module ietf-system { import ietf-cool { prefix "cool"; } cool:module-id "68"; cool:first-assigned-node-id "20" cool:first-assigned-rpc-id "10" cool:id "/system/location 1" cool:id "/system/dns-resolver/server/name 2" cool:id "/system-restart 1" ... } The generated identifiers will be affected as follows: +------+--------+--------------------------------------------------+ | DNID | FQDNID | Data node | +------+--------+--------------------------------------------------+ | 0 | 69632 | / | | 20 | 69652 | /system | | 21 | 69653 | /system/contact | | 22 | 69654 | /system/hostname | | 1 | 69633 | /system/location | | 23 | 69655 | /system/clock | | 24 | 69656 | /system/clock/timezone/timezone-name/ | | | | timezone-name | | 25 | 69657 | /system/clock/timezone/timezone-utc-offset | | | | /timezone-utc-offset | | 26 | 69658 | /system/ntp | | 27 | 69659 | /system/ntp/enabled | | 28 | 69660 | /system/ntp/server | | 29 | 69661 | /system/ntp/server/name | | 30 | 69662 | /system/ntp/server/transport/udp/udp | | 31 | 69663 | /system/ntp/server/transport/udp/udp/address | | 32 | 69664 | /system/ntp/server/transport/udp/udp/port | | 33 | 69665 | /system/ntp/server/association-type | | 34 | 69666 | /system/ntp/server/iburst | | 35 | 69667 | /system/ntp/server/prefer | | 36 | 69668 | /system/dns-resolver | | 37 | 69669 | /system/dns-resolver/search | Veillette, et al. Expires May 4, 2016 [Page 28]
Internet-Draft Constrained Objects Language November 2015 | 38 | 69670 | /system/dns-resolver/server | | 2 | 69634 | /system/dns-resolver/server/name | | 39 | 69671 | /system/dns-resolver/server/transport/ | | | | udp-and-tcp/udp-and-tcp | | 40 | 69672 | /system/dns-resolver/server/transport/ | | | | udp-and-tcp/udp-and-tcp/address | | 41 | 69673 | /system/dns-resolver/server/transport/ | | | | udp-and-tcp/udp-and-tcp/port | | 42 | 69674 | /system/dns-resolver/options | | 43 | 69675 | /system/dns-resolver/options/timeout | | 44 | 69676 | /system/dns-resolver/options/attempts | | 45 | 69677 | /system/radius | | 46 | 69678 | /system/radius/server | | 47 | 69679 | /system/radius/server/name | | 48 | 69680 | /system/radius/server/transport/udp/udp | | 49 | 69681 | /system/radius/server/transport/udp/udp/address | | 50 | 69682 | /system/radius/server/transport/udp/udp/ | | | | authentication-port | | 51 | 69683 | /system/radius/server/transport/udp/udp/ | | | | shared-secret | | 52 | 69684 | /system/radius/server/authentication-type | | 53 | 69685 | /system/radius/options | | 54 | 69686 | /system/radius/options/timeout | | 55 | 69687 | /system/radius/options/attempts | | 56 | 69688 | /system/authentication | | 57 | 69689 | /system/authentication/user-authentication-order | | 58 | 69690 | /system/authentication/user | | 59 | 69691 | /system/authentication/user/name | | 60 | 69692 | /system/authentication/user/password | | 61 | 69693 | /system/authentication/user/authorized-key | | 62 | 69694 | /system/authentication/user/authorized-key/name | | 63 | 69695 | /system/authentication/user/authorized-key/ | | | | algorithm | | 64 | 69696 | /system/authentication/user/authorized-key/ | | | | key-data | | 65 | 69697 | /system-state | | 66 | 69698 | /system-state/platform | | 67 | 69699 | /system-state/platform/os-name | | 68 | 69700 | /system-state/platform/os-release | | 69 | 69701 | /system-state/platform/os-version | | 70 | 69702 | /system-state/platform/machine | | 71 | 69703 | /system-state/clock | | 72 | 69704 | /system-state/clock/current-datetime | | 73 | 69705 | /system-state/clock/boot-datetime | +------+--------+--------------------------------------------------+ Veillette, et al. Expires May 4, 2016 [Page 29]
Internet-Draft Constrained Objects Language November 2015 +----------------------+--------------------------------------------+ | Protocol operation | Protocol operation | | IDs | | +----------------------+--------------------------------------------+ | 10 | /set-current-datetime | | | +--------------------+-------------------+ | | | | Input parameter ID | Input parameter | | | | +--------------------+-------------------+ | | | | 1 | /current-datetime | | | | +--------------------+-------------------+ | | | | | 1 | /system-restart | | 11 | /system-shutdown | +----------------------+--------------------------------------------+ 7. Protocol details This section defines the different interactions supported between a CoOL client and a CoOL server. 7.1. Retrieving data node(s) The CoAP GET method is used by a CoOL client to retrieve the value of one or multiple data nodes. The URI of the GET request MUST be set to the URI of the targeted datastore. The data node(s) to be retrieved MUST be specified within the "Fields" CoAP option. This CoAP option contains a list of data node IDs encoded using a CBOR array. The first data node ID MUST be fully-qualified. Subsequence IDs MUST be elided if the module ID is shared with the previous array entry. On successful processing of the CoAP request, the CoOL server MUST return a CoAP response with a response code 2.05 (Content). The payload of the GET response MUST carry a CBOR map containing the data node(s) requested. The subsection "YANG container" of the "YANG to CBOR mapping" section defines the rules used to construct this CBOR map. The CBOR value undefined (0xf7) must be returned for each data node requested but not currently available. Veillette, et al. Expires May 4, 2016 [Page 30]
Internet-Draft Constrained Objects Language November 2015 Example: CoAP request: GET /cool Fields([69637, 55]) CoAP response: 2.05 Content Content-Format(application/cbor) { 69637 : { 7 : 540 }, 69687 : "2015-10-08T14:10:08Z09:00" } In this example, a CoOL client retrieves the data nodes "/system/ clock" and "/system-state/clock/current-datetime" defined in the ietf-system module. This example makes use of the following IDs: o module ietf-system: module ID 68 o leaf clock: data node ID 5, fully-qualified ID 69637 o leaf timezone-utc-offset: data node ID 7 o leaf current-datetime: data node ID 55, fully-qualified ID 69687 These CoAP requests and responses MUST be encoded in accordance with [RFC7252]. An encoding example is shown below: CoAP request: +-----------------------------------------+---------+---------------+ | CoAP field | Size | Value | | | (bytes) | | +-----------------------------------------+---------+---------------+ | Version, Type, Token Length, Code | 2 | | | Message ID | 2 | | | Token ID | 0 to 8 | | | option Uri-Path (Delta and Length) | 1 | | | option Uri-Path (Value) | 5 | "/cool" | | option Fields (Delta and Length) | 1 | | | option Fields (Value) | 8 | 82 | | | | 1a 00011005 | | | | 18 37 | +-----------------------------------------+---------+---------------+ Veillette, et al. Expires May 4, 2016 [Page 31]
Internet-Draft Constrained Objects Language November 2015 CoAP response: +-----------------------------------------+---------+---------------+ | CoAP field | Size | Value | | | (bytes) | | +-----------------------------------------+---------+---------------+ | Version, Type, Token Length, Code | 2 | | | Message ID | 2 | | | Token ID | 0 to 8 | | | Option Content-Format (Delta and Length)| 1 | | | Option Content-Format (Value) | 1 | 60 | | Payload | 43 | a2 | | | | 1a 00011005 | | | | a1 | | | | 07 | | | | 19 021c | | | | 1a 00011037| | | | 78 19 | | | | 32303135 | | | | 2d31302d | | | | 30385431 | | | | 343a3130 | | | | 2d30385a | | | | 30393a30 | | | | 30 | +-----------------------------------------+---------+---------------+ 7.2. The Fields CoAP option The "Fields" CoAP option is used to specify the list of data node(s) accessed. This option contains a CBOR array. Each entry of this array can be an unsigned integer representing a data node ID or a CBOR array representing an instance selector. Example: +-----+---+---+---+---+---------+--------+--------+---------+ | No. | C | U | N | R | Name | Format | Length | Default | +-----+---+---+---+---+---------+--------+--------+---------+ | 6 | x | x | - | x | Fields | opaque | 0-3 B | (none) | +-----+---+---+---+---+---------+--------+--------+---------+ 7.3. Retrieving all data nodes To retrieve all data nodes associated with a YANG module, the Fields CoAP option MUST be present and the CBOR array MUST contain the data node ID zero for this module. Data nodes added to the specified module by other modules using the augment YANG statement are returned Veillette, et al. Expires May 4, 2016 [Page 32]
Internet-Draft Constrained Objects Language November 2015 but data nodes added by the specified module to other modules are not returned. To retrieve all data nodes of all YANG modules, the Fields CoAP option MUST be absent. On successful processing of the CoAP request, the CoOL server MUST return a CoAP response with a response code 2.05 (Content). The payload of the GET response MUST carry a CBOR map containing a container for each module reported and identified using the data node ID zero. Example: CoAP Request: GET /cool Fields([66560]) CoAP response: 2.05 Content Content-Format(application/cbor) { 66560 : { 1 : { 2 : [ { 3 : "eth0", 4 : "Ethernet adapter Local Area Connection", 5 : "iana-interface-type.ethernetCsmacd", 6 : true, 68620 : { 13 : true, 14 : true, 15 : 1280, 16 : [ { 17 : "fe80::200:f8ff:fe21:67cf", 18 : 10 } ] } } ] } } } In this example, a CoOL client retrieves all data nodes of the YANG module "ietf-interfaces". Data nodes defined using the augment YANG statement in the "ietf-ip" module are also returned. Veillette, et al. Expires May 4, 2016 [Page 33]
Internet-Draft Constrained Objects Language November 2015 If we assume that the CoOL server implements only the "ietf- interfaces" and the "ietf-ip" modules, then the following request returns the same response as above. GET /cool This example makes use of the following IDs: o module ietf-interfaces: module ID 65 o module root : data node ID 0, fully-qualified 66560 o container interfaces: data node ID 1 o list interface: data node ID 2 o leaf name: data node ID 3 o leaf description: data node ID 4 o leaf type: data node ID 5 o leaf enabled: data node ID 6 o module ietf-ip: module ID 67 o container ipv6: data node ID 12, fully-qualified 68620 o leaf enabled: data node ID 13 o leaf forwarding: data node ID 14 o leaf mtu: data node ID 15 o list address: data node ID 16 o leaf ip: data node ID 17 o leaf prefix-length: data node ID 18 7.4. Updating data node(s) The CoAP PUT method is used by CoOL clients to change the value of one or multiple data nodes. The URI of the PUT request MUST be set to the URI of the targeted datastore. Veillette, et al. Expires May 4, 2016 [Page 34]
Internet-Draft Constrained Objects Language November 2015 The payload of the PUT request carry a CBOR map containing the list of data node(s) to be updated. The subsection "YANG container" of the "YANG to CBOR mapping" section defines the rules used to construct this CBOR map. It is important to note that the CBOR map itself does not represent a data node; rather, each tag-value pair in that map represents a data node to be updated. On successful processing of the CoAP request, the CoOL server MUST return a CoAP response with a response code 2.04 (Changed). If at least one of the targeted data nodes doesn't exist, the CoOL server MUST return a response code 4.00 (Bad Request) carrying a payload with the data node "/error-info/error-code" set to 4 (doesNotExist). PUT methods SHOULD be processed as atomic transactions, if any errors occur, then the target datastore SHOULD NOT be changed by the PUT operation. Example: CoAP request: PUT /cool Content-Format(application/cbor) { 69639 : 540, 69687 : "2015-10-08T14:10:08Z09:00" } CoAP response: 2.04 Changed In this example, a CoOL client updates data nodes /system/clock/timezone/timezone-utc-offset/timezone-utc-offset" and "/system-state/clock/current-datetime". This example makes use of the following IDs: o module ietf-interfaces: module ID 65 o leaf timezone-utc-offset: data node ID 7, fully-qualified 69639 o leaf current-datetime: data node ID 55, fully-qualified 69687 7.5. Retrieving data node(s) from a list The CoAP GET method is used by CoOL clients to retrieve the value of one or multiple data nodes within a list. To retrieve data node(s) within a list, the Fields option MUST carry an instance selector. An instance selector is a CBOR array containing these elements: Veillette, et al. Expires May 4, 2016 [Page 35]
Internet-Draft Constrained Objects Language November 2015 o The first element of the CBOR array MUST be set to the data node ID of the list containing the requested data nodes. o The second element of the array MUST be set to a CBOR array containing the value of the different keys required to select the requested data nodes. Key values MUST be provided in the same order as defined in the YANG key sub-statement. When a list is defined within list(s), the key values are ordered starting with the top level list and ending with the list containing the requested data nodes. o The third element is optional. When present, this element MUST be set to a CBOR array containing the data node IDs of the data nodes requested. When absent, all data nodes within the targeted list entry MUST be returned. On successful processing of the CoAP request, the CoOL server MUST return a CoAP response with a response code 2.05 (Content). The payload of the GET response MUST carry a CBOR map containing the requested data nodes. The subsection "YANG container" of the "YANG to CBOR mapping" section defines the rules used to construct this CBOR map. When the list entry specified in the request does not exist, the returned payload MUST contain a map entry set to the CBOR value undefined (0xf7). Example: CoAP request: GET /cool Fields([69635, [66562, ["eth0"], [5, 6]]) CoAP response: 2.05 Content Content-Format(application/cbor) { 69635 : "datatracker.ietf.org", 66562 : { 5 : "iana-interface-type.ethernetCsmacd", 6 : true } } In this example, a CoOL client retrieves the data node "/system/ hostname" defined in the ietf-system module and the data nodes "/interfaces/interface/type" and "/interfaces/interface/enabled" member of the "/interfaces/interface" list defined in the ietf- interfaces module. Veillette, et al. Expires May 4, 2016 [Page 36]
Internet-Draft Constrained Objects Language November 2015 Altername CoAP response: 2.05 Content Content-Format(application/cbor) { 69635 : "datatracker.ietf.org", 66562 : undefined } This alternate CoAP response represents the case where the interface name "eth0" doesn't exist within the "/interfaces/interface" list. This example makes use of the following IDs: o module ietf-interfaces: module ID 65 o module ietf-system: module ID 68 o leaf hostname: data node ID 3, fully-qualified 69635 o list interface: data node ID 2, fully-qualified 66562 o leaf type: data node ID 5 o leaf enabled: data node ID 6 7.6. Retrieving multiple entries from a list Two approaches are supported to retrieve multiple list entries. The first approach consists of providing a list of key sets. Each key set selects one entry within the YANG list. In this case, the second element of the instance selector MUST be encoded as a CBOR array for which each entry is itself a CBOR array containing the key(s). The second approach consists of setting one or multiple keys to null (0xf6). In this case, all possible values for this key are returned. On successful processing of the CoAP request, the CoOL server MUST return a CoAP response with a response code 2.05 (Content). The payload of the GET response MUST carry a CBOR map containing the different data nodes requested. The subsection "YANG container" of the "YANG to CBOR mapping" section defines the rules used to construct this CBOR map. When the list entry specified in the request does not exist, the returned payload MUST contain a map entry set to the CBOR value undefined (0xf7). Veillette, et al. Expires May 4, 2016 [Page 37]
Internet-Draft Constrained Objects Language November 2015 Example: CoAP request: GET /cool Fields([ [66569,[["eth0"], ["eth1"]], [10, 22, 27]] ]) CoAP response: 2.05 Content Content-Format(application/cbor) { 66569 : [ { 10 : "eth0", 22 : 1572864, 27 : 0 }, { 10 : "eth1", 22 : 1572864, 27 : 0 } ] } In this example, a CoOL client retrieves data nodes "/interfaces- state/interface/statistics/in-octets" and "/interfaces- state/interface/statistics/in-errors" for the interface name "eth0" and "eth1". Assuming that only two interfaces exist for this host, the following request returns the same response as above. CoAP request: GET /cool Fields([ [66569,[ null ], [10, 22, 27]] ]) This example makes use of the following IDs: o module ietf-interfaces: module ID 65 o list interface: data node ID 9, fully-qualified 66569 o leaf name: data node ID 10 o leaf in-octets: data node ID 22 o leaf in-errors: data node ID 27 Veillette, et al. Expires May 4, 2016 [Page 38]
Internet-Draft Constrained Objects Language November 2015 7.7. Retrieving multiple entries of a single data node from a list Retrieval of a single data node within a list MUST be optimized as follows: In the request, the third element of the instance selector MUST be encoded as a CBOR unsigned integer instead of a CBOR ARRAY. In the response, the instances of the selected data node MUST be encoded as a CBOR ARRAY associated directly with the ID of this data node. On successful processing of the CoAP request, the CoOL server MUST return a CoAP response with a response code 2.05 (Content). When the list entry specified in the request does not exist, the returned payload MUST contain a map entry set to the CBOR value undefined (0xf7). Example: CoAP request: GET /cool Fields([ [66569,[ null ], 10] ]) CoAP response: 2.05 Content Content-Format(application/cbor) { 66570 : [ "eth0", "eth1", "wlan0" ] } In this example, a CoOL client retrieves all instances of data node "/interfaces-state/interface/name" within the "/interfaces-state/ interface" list. This example makes use of the following IDs: o module ietf-interfaces: module ID 65 o list interface: data node ID 9, fully-qualified 66569 o leaf name: data node ID 10, fully-qualified 66570 7.8. Updating a list entry The CoAP PUT method is used by a CoOL client to update the value of one or multiple data nodes within a list. The URI of the PUT request MUST be set to the URI of the targeted datastore. Veillette, et al. Expires May 4, 2016 [Page 39]
Internet-Draft Constrained Objects Language November 2015 The Fields CoAP option MUST be set to an instance selector composed of the following elements: o The first element MUST be set to the data node ID of the list. o The second element MUST be set to a CBOR array containing the value of the different keys required to select the targeted entry within the specified list. The payload of the PUT request MUST carry a CBOR map containing the list entry to be updated. The subsection "YANG container" of the "YANG to CBOR mapping" section defines the rules used to construct this CBOR map. On successful processing of the CoAP request, the CoOL server MUST return a CoAP response with a response code 2.04 (Changed). If the list specified doesn't exist, the CoOL server MUST return a response code 4.00 (Bad Request) carrying a payload with data node "/error- info/error-code" set to 4 (doesNotExist). PUT methods SHOULD be processed as atomic transactions, if any errors occur, then the target datastore SHOULD NOT be changed by the PUT operation. Example: CoAP request: PUT /cool Fields([69642,[ "NTP Pool server 2" ]]) { 69642 : { 12 : { 13: "2620:10a:800f::11", 14: 123 } } } CoAP response: 2.04 Changed In this example, a CoOL client update data nodes "/system/ntp/server/transport/udp/udp/address" and "/system/ntp/server/transport/udp/udp/port" within the "/system/ntp/ server" list. This example makes use of the following IDs: o module ietf-system: module ID 68 o list server: data node ID 10, fully-qualified 69642 Veillette, et al. Expires May 4, 2016 [Page 40]
Internet-Draft Constrained Objects Language November 2015 o container udp: data node ID 12 o leaf address: data node ID 13 o leaf port: data node ID 14 7.9. Adding a list entry The CoAP POST method is used by a CoOL client to insert an entry into a list. The URI of the POST request MUST be set to the URI of the targeted datastore. The payload of the POST request MUST carry a CBOR map containing the data node ID of the list targeted. The subsection "YANG container" of the "YANG to CBOR mapping" section defines the rules used to construct this CBOR map. On successful processing of the CoAP request, the CoOL server MUST return a CoAP response with a response code 2.01 (Created). If the entry provided already exists in the targeted list (duplicate key), the CoOL server MUST return a response code 4.00 (Bad Request) carrying a payload with data node "/error-info/error-code" set to 5 (alreadyExist). Example: CoAP request: POST /cool { 69642 : { 12 : { 13: "132.246.11.231", 14: 123 } } } CoAP response: 2.01 Created In this example, a CoOL client adds an entry in the "/system/ntp/ server" list. The entry added contains data nodes "/system/ntp/server/transport/udp/udp/address" and "/system/ntp/server/transport/udp/udp/port". This example makes use of the following IDs: Veillette, et al. Expires May 4, 2016 [Page 41]
Internet-Draft Constrained Objects Language November 2015 o module ietf-system: module ID 68 o list server: data node ID 10, fully-qualified 69642 o container udp: data node ID 12 o leaf address: data node ID 13 o leaf port: data node ID 14 7.10. Deleting list entries The CoAP DELETE method is used by a CoOL client to delete an entry within a list. The URI of the PUT request MUST be set to the URI of the targeted datastore. The Field CoAP option MUST contain an instance selector composed of the following elements: o The first element MUST be set to the data node ID of the list. o The second element MUST be set to a CBOR array containing the value of the different keys required to identify the entry to be deleted. On successful processing of the CoAP request, the CoOL server MUST return a CoAP response with a response code 2.02 (Deleted). If the targeted entry doesn't exist, the CoOL server MUST return a response code 4.00 (Bad Request) carrying a payload with data node "/error- info/error-code" set to 4 (doesNotExist). Example: CoAP request: DELETE /cool Fields([69642,[ "NTP Pool server 2" ]]) CoAP response: 2.02 Deleted In this example, a CoOL client deletes the entry within the "/system/ntp/server" list for the key "/system/ntp/server/name" = "NTP Pool server 2". This example makes use of the following IDs: o module ietf-system: module ID 68 Veillette, et al. Expires May 4, 2016 [Page 42]
Internet-Draft Constrained Objects Language November 2015 o list server: data node ID 10, fully-qualified 69642 7.11. Patch The CoAP PATCH method is used by CoOL clients to perform complex atomic transactions on a datastore. To perform a patch, the CoAP method MUST be set to PATCH. The payload of the CoAP request MUST carry a "patch-request" list as defined by the ietf-cool module. This list carries a sequence of edits on a datastore. Each edit MUST be applied in ascending order, and all edits MUST be applied. If any errors occur, then the target datastore SHOULD NOT be changed by the patch operation. On successful processing of the CoAP request, the CoOL server MUST return a CoAP response with a response code 2.04 (Changed). If at least one of the edit is rejected, the CoOL server MUST return a CoAP response with a response code 4.00 (Bad Request) and the payload MUST carry a "patch-response" list as defined by the ietf- cool module. In the following example, a CoOL client performs the following operations using the patch method: o Remove all entries present in the"/system/ntp/server" list. o Create an entry in the "/system/ntp/server" list with the server name set to "NTP Pool server 2" and the server address set to "2.pool.ntp.org". o Set the data node "/system/ntp/enabled" to true. Veillette, et al. Expires May 4, 2016 [Page 43]
Internet-Draft Constrained Objects Language November 2015 Example: CoAP request: PATCH /cool Content-Format(application/cbor) { 1028 : [ { 5 : 0, 6 : 4, 7 : [69642, [null]] }, { 5 : 1, 6 : 0, 8 : { 69642 : { 11 : "NTP Pool server 2", 12 : { 13 : "2.pool.ntp.org" } } } }, { 5 : 2, 6 : 3, 8 : { 69641 : true } } ] } CoAP response: 2.04 Changed Alternate CoAP response: 4.00 Bad Request (Content-Format: application/cbor) { 1033 : [ { 10 : 1, 11 : 3 } ] } Veillette, et al. Expires May 4, 2016 [Page 44]
Internet-Draft Constrained Objects Language November 2015 This alternate response represents the case where the second edit have been rejected because of an invalid value. This example makes use of the following IDs: o module ietf-cool: module ID 1 o list patch-request: data node ID 4, fully-qualified 1028 o leaf operation: data node ID 5 o leaf list-entry: data node ID 6 o anyxml value: data node ID 8 o list patch-response o leaf edit-id o leaf edit-status o module ietf-system: module ID 68 o leaf enabled : data node ID 9, fully-qualified 69641 o list server: data node ID 10, fully-qualified 69642 o leaf name: data node ID 11 o container udp: data node ID 12 o leaf address: data node ID 13 7.12. Protocol operation Protocol operations are defined using the YANG "rpc" statement. Protocol operations are invoked by CoOL clients using a CoAP POST method on the protocol operation resource. When input parameter(s) are defined for the invoked protocol operation and are needed by the CoOL client, they are carried in the CoAP request payload. These parameter(s) are encoded using a CBOR map. The subsection "YANG container" of the "YANG to CBOR mapping" section defines the rules used to construct this CBOR map. The response code of the CoAP response MUST be set to 2.05 (Content). When output parameters are returned by the CoOL server, these parameter(s) are carried in the CoAP response payload. These Veillette, et al. Expires May 4, 2016 [Page 45]
Internet-Draft Constrained Objects Language November 2015 parameter(s) are encoded using a CBOR map. The subsection "YANG container" of the "YANG to CBOR mapping" section defines the rules used to construct this CBOR map. Example: CoAP request: POST /cool/rpc/68/1 Content-Format(application/cbor) { 1 : "2015-10-08T14:10:08Z09:00" } CoAP response: 2.05 Content In this example, a CoOL client invokes the protocol operation "/set- current-datetime". The "current-datetime" value is provided as input parameter. This example makes use of the following IDs: o module ietf-system: module ID 68 o rpc set-current-datetime: protocol operation ID 1 o input parameter current-datetime: input parameter ID 1 7.13. Event stream Notifications are defined using the YANG "notification" statement. Subscriptions to an event stream and notification reporting are performed using an event stream resource. When multiple event stream resources are supported, the list of notifications associated with each stream is either pre-defined or configured in the CoOL server. CoOL clients MAY subscribe to one or more event stream resources. To subscribe to an event stream resource, a CoOL client MUST send a CoAP GET with the Observe CoAP option set to 0. To unsubscribe, a CoOL client MAY send a CoAP reset or a CoAP GET with the Observe option set to 1. For more information on the observe mechanism, see [RFC7641]. Each notification transferred by a CoOL server to each of the registered CoOL client is carried in a CoAP response with a response code set to 2.05 (Content). Each CoAP response MUST carry in its payload at least one notification but MAY carry multiple. Each notification MUST be encoded as a CBOR map. The subsection "YANG container" of the "YANG to CBOR mapping" section defines the rules Veillette, et al. Expires May 4, 2016 [Page 46]
Internet-Draft Constrained Objects Language November 2015 used to construct this CBOR map. When multiple notifications are reported, the CoAP response payload carries a CBOR array, with each entry containing a notification encoded using a CBOR map. For this example, we assume that the following notifications have been added to the ietf-system module. Example: notification system-status-update { leaf status-update { type enumeration { enum system-down { value 0; } enum system-up { value 1; } } } leaf current-time { type yang:date-and-time; } } notification ntp-time-updated { leaf new-time { type yang:date-and-time; } leaf time-drift { type uint64; units "milliseconds"; } } In this example, a CoOL client starts by registering to the default event stream resource "/cool/streams". CoAP request: GET /cool/streams Observe(0) Token(0x9372) The CoOL server confirms this registration by returning a first CoAP response. The payload of this CoAP response may be empty or may carry the last notification reported by this server. CoAP response: 2.05 Content Observe(52) Token(0xD937) After detecting an event, the CoOL server sends its first notification to the registered CoOL client. Veillette, et al. Expires May 4, 2016 [Page 47]
Internet-Draft Constrained Objects Language November 2015 CoAP response: 2.05 Content Observe(53) Token(0xD937) Content-Format(application/cbor) { 69634 : { 1 : "2015-10-08T14:10:08Z09:00", 2 : 271 } } To optimize communications or because of other constrains, the CoOL server might transfer multiple notifications in a single CoAP response. CoAP response: 2.05 Content Observe(52) Token(0xD937) Content-Format(application/cbor) [ { 69633 : { 1 : 0, 2 : "2015-10-08T15:23:51Z09:00" } }, { 69633 : { 1 : 1, 2 : "2015-10-08T15:25:36Z09:00" } } ] This example makes use of the following IDs: o module ietf-system: module ID 68 o notification system-status-update: notification ID 69633 o leaf status-update: notification parameter ID 1 o leaf current-time: notification parameter ID 2 o notification ntp-time-updated : notification ID 69634 o leaf updated-time: notification parameter ID 1 o leaf time-drift: notification parameter ID 2 Veillette, et al. Expires May 4, 2016 [Page 48]
Internet-Draft Constrained Objects Language November 2015 7.14. Observe A CoOL server MAY support state change notifications to some or all its leaf data nodes. When supported the CoOL server MUST implement the Server-Side requirements defined in [RFC7641] section 3 and the CoOL client MUST implement the Client-Side requirements defined in [RFC7641] section 4. To start observing a leaf data node, a CoOL client MUST send a CoAP GET with the Observe CoAP option set to 0. The Fields CoAP option may be set to any content previously defined within this section. The first data node selected represents the resource observed as described in [RFC7641]. Subsequent data nodes selected represent coincidental values. These data nodes are included in each notification, but changes to these extra data nodes MUST not trigger notification messages. A subscription can be terminated by the CoOL client by returning a CoAP Reset message or by sending a GET request with an Observe CoAP option set to deregister (1). More details are available in [RFC7641]. Example: CoAP request: GET /cool Fields([ [66594, ["eth0"]], [34, 29]]) Observe(0) CoAP response: 2.05 Content Content-Format(application/cbor) Observe(2631) { 66594: { 29 : 605873, 34 : 42 } } ... CoAP response: 2.05 Content Content-Format(application/cbor) Observe(2632) { 66594: { 29 : 6493721, 34 : 43 } } Veillette, et al. Expires May 4, 2016 [Page 49]
Internet-Draft Constrained Objects Language November 2015 In this example, a CoOL client subscribes to state changes of the data node "/interfaces-state/interface/statistics/out-errors" and requests that data node "/interfaces-state/interface/statistics/out- octets" is reported as coincidental value. A first response is immediately returned by the CoOL server to confirm the subscription and to report the current values of the requested data nodes. Subsequent responses are returned by the CoOL server each time the data node "/interfaces-state/interface/statistics/out-errors" changes. 7.15. Resource discovery The "/.well-known/core" resource is used by CoOL clients to discover resources implemented by CoOL servers. Each CoOL server MUST have an entry in the "/.well-known/core" resource for each datastore resource, protocol operation resource, and event stream resource supported. Resource discovery MUST be performed using a CoAP GET request. The CoAP response MUST have a response code set to 2.05 (Content), a Content-Format set to "application/link-format", and a payload containing a list of web links. To enable discovery of specific resource types, the CoAP server MUST support the query string "rt". Link format and the "/.well-known/core" resource are defined in [RFC6690]. Example: CoAP request: GET /.well-known/core CoAP response: 2.05 Content Content-Format(application/link-format) </cool>;rt="cool.datastore", </cool/rpc>;rt="cool.protocol-operation", </cool/stream>;rt="cool.event-stream", In this example, a CoOL client retrieves the list of all resources available on a CoOL server. Veillette, et al. Expires May 4, 2016 [Page 50]
Internet-Draft Constrained Objects Language November 2015 Alternatively, the CoOL client may query for a specific resource type. In this example, the CoOL client queries for resource type (rt) "cool.datastore". CoAP request: GET /.well-known/core?rt=cool.datastore CoAP response: 2.05 Content Content-Format(application/link-format) </cool>;rt="cool.datastore", 7.16. Modules, sub-modules, and objects discovery CoOL clients can discover the list of modules, sub-modules, data nodes, protocol operations, and event streams implemented by CoOL servers by requesting this information from the "ietf-cool-library" YANG module. CoOL servers MUST implement the "ietf-cool-library" YANG module. This module MUST contain information about all modules supported by this CoOL server. The "ietf-cool-library" YANG module also reports detailed information about each module, such as "name", "features", "deviations", "submodule", "data-nodes", "protocol-operation" and "notifications". CoOL servers SHOULD support this detail information if the amount of resources available allow their implementation. Veillette, et al. Expires May 4, 2016 [Page 51]
Internet-Draft Constrained Objects Language November 2015 Example: CoAP request: GET /cool Fields([2049]) CoAP response: 2.05 Content Content-Format(application/cbor) { 2049 : [ { 2 : 65, 3 : "ietf-interfaces", 4 : "2014-05-08", 5 : ["arbitrary-names", "pre-provisioning"], 10 : [1, 2, 3, 5, 6, 8, 9, 10, 11, 12, 13, 14, 16, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34] }, { 2 : 68, 3 : "ietf-system", 4 : "2014-08-06", 5 : ["ntp", "ntp-udp-port"], 10 : [1, 2, 3, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17], 11 : [1, 2, 3] } ] } In this example, a CoOL client retrieves the entire content of the "module" list. The CoOL protocol can be used by a CoOL client to retrieve specific information within this list. Second example: CoAP request: POST /cool/rpc/2/1 Content-Format(application/cbor) { 1 : 68, 2 : 5 } CoAP response: 2.05 Content Content-Format(application/cbor) { 1 : true } Veillette, et al. Expires May 4, 2016 [Page 52]
Internet-Draft Constrained Objects Language November 2015 In this second example, a CoOL client uses the is-supported protocol operation to verify support of data node "/system/clock". These examples make use of the following IDs: o module ietf-cool-library: module ID 2 o module ietf-interfaces: module ID 65 o module ietf-system: module ID 68 o list modules: data node ID 1, fully-qualified 2049 o leaf module-id: data node ID 2 o leaf name: data node ID 3 o leaf revision: data node ID 4 o leaf-list features: data node ID 5 o leaf-list data-nodes: data node ID 10 o leaf-list protocol-operations: data node ID 11 o rpc is-supported: protocol operation ID 1 8. Error Handling All CoAP response codes defined by [RFC7552] MUST be accepted and processed accordingly by CoOL clients. Optionally, client errors (CoAP response codes 4.xx) or server errors (CoAP response codes 5.xx) MAY have a payload providing further information about the cause of the error. This payload contain the "error-info" container defined in the ietf-cool YANG module. Example: CoAP response: 4.00 Bad Request (Content-Format: application/cbor) { 1025 : 2, 1026 : "Data node 69687 is unknown" } Veillette, et al. Expires May 4, 2016 [Page 53]
Internet-Draft Constrained Objects Language November 2015 9. Security Considerations This application protocol relies on the lower layers to provide confidentiality, integrity, and availability. A typical approach to archive these requirements is to implement CoAP using the DTLS binding as defined in [RFC7252] section 9. Other approaches are possible to fulfill these requirements, such as the use of a network layer security mechanism as discussed in [I-D.bormann-core-ipsec-for-coap] or a link layer security mechanism for exchanges done within a single sub-network (e.g. [I-D.wang-6tisch-6top-coapie]. In some applications, different access rights to CoOL resources and objects need to be granted to different CoOL clients. Different solutions are possible, such as the implementation of Access Control Lists (ACL) using YANG module(s) or the use of an authorization certificate as defined in [RFC5755]. These access control mechanisms need to be addressed in complementary specifications. The Security Considerations section of CoAP [RFC7252] is especially relevant to this application protocol and should be reviewed carefully by implementers. 10. IANA Considerations 10.1. Module ID This document defines a registry for YANG module IDs. The name of this registry is "CoOL module ID". The registry shall record for each entry: The assigned identifier. The name of the YANG module. A reference to the module and associated sub-module documentation (e.g. RFC number). Contact information of the owner of the module, such as name, email, and phone number. Veillette, et al. Expires May 4, 2016 [Page 54]
Internet-Draft Constrained Objects Language November 2015 +--------+-----------------+------------------------------+---------+ | Module | Module name | Reference | Owner | | ID | | | | +--------+-----------------+------------------------------+---------+ | 0 | Reserved | | | | 1 | cool | Defined in annex A | IETF | | 2 | cool-library | Defined in annex B | IETF | | 3 to | Reserved | Expert Review. Reserved for | | | 63 | | standardized YANG modules | | | | | targeting constrained | | | | | networks and devices. These | | | | | module IDs require less | | | | | overhead when encoded using | | | | | CBOR. | | | 64 | ietf-inet-types | [RFC6021] | IETF | | 65 | ietf-interfaces | [RFC7223] | IETF | | 66 | iana-if-type | [RFC7224] | IETF | | 67 | ietf-ip | [RFC7277] | IETF | | 68 | ietf-system | [RFC7317] | IETF | | 100 to | Reserved | Experimental use | | | 127 | | | | | 128 to | Reserved | Temporary registry | Authors | | 1023 | | maintained by the authors to | | | | | allow initial | | | | | implementations. These | | | | | identifiers should be | | | | | transferred to the official | | | | | registry when appropriate. | | +--------+-----------------+------------------------------+---------+ 10.2. "Fields" CoAP Option Number The Fields CoAP option is used to specify a list of data nodes to be retrieved by a CoAP GET. This option needs to be registered in the CoAP Option Numbers registry as defined in [RFC7252] section 12.2. 10.3. "PATCH" CoAP Method Code This draft makes use of the PATCH CoAP method as defined in [I-D.vanderstok-core-patch]. This method needs to be registered in the CoAP Method Codes sub-registry as defined in [RFC7252] section 12.1.1. 11. References Veillette, et al. Expires May 4, 2016 [Page 55]
Internet-Draft Constrained Objects Language November 2015 11.1. Normative References [I-D.vanderstok-core-patch] Stok, P. and A. Sehgal, "Patch Method for Constrained Application Protocol (CoAP)", draft-vanderstok-core- patch-02 (work in progress), October 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>. [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <http://www.rfc-editor.org/info/rfc6690>. [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <http://www.rfc-editor.org/info/rfc7049>. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>. [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for System Management", RFC 7317, DOI 10.17487/RFC7317, August 2014, <http://www.rfc-editor.org/info/rfc7317>. [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <http://www.rfc-editor.org/info/rfc7641>. 11.2. Informative References [I-D.bormann-core-ipsec-for-coap] Bormann, C., "Using CoAP with IPsec", draft-bormann-core- ipsec-for-coap-00 (work in progress), December 2012. Veillette, et al. Expires May 4, 2016 [Page 56]
Internet-Draft Constrained Objects Language November 2015 [I-D.vanderstok-core-comi] Stok, P., Bierman, A., Schoenwaelder, J., and A. Sehgal, "CoAP Management Interface", draft-vanderstok-core-comi-08 (work in progress), October 2015. [I-D.wang-6tisch-6top-coapie] Wang, Q., Vilajosana, X., Watteyne, T., Sudhaakar, R., and P. Zand, "Transporting CoAP Messages over IEEE802.15.4e Information Elements", draft-wang-6tisch-6top-coapie-01 (work in progress), July 2015. [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet Attribute Certificate Profile for Authorization", RFC 5755, DOI 10.17487/RFC5755, January 2010, <http://www.rfc-editor.org/info/rfc5755>. [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6021, DOI 10.17487/RFC6021, October 2010, <http://www.rfc-editor.org/info/rfc6021>. [RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, <http://www.rfc-editor.org/info/rfc7223>. [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", RFC 7224, DOI 10.17487/RFC7224, May 2014, <http://www.rfc-editor.org/info/rfc7224>. [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC 7277, DOI 10.17487/RFC7277, June 2014, <http://www.rfc-editor.org/info/rfc7277>. [RFC7552] Asati, R., Pignataro, C., Raza, K., Manral, V., and R. Papneja, "Updates to LDP for IPv6", RFC 7552, DOI 10.17487/RFC7552, June 2015, <http://www.rfc-editor.org/info/rfc7552>. Appendix A. ietf-cool YANG module Module containing YANG extensions for the CoOL protocol. module ietf-cool { namespace "urn:ietf:ns:cool"; prefix cool; organization "IETF Core Working Group"; Veillette, et al. Expires May 4, 2016 [Page 57]
Internet-Draft Constrained Objects Language November 2015 contact "Michel Veillette <mailto:michel.veillette@trilliantinc.com> Randy Turner <mailto:Randy.Turner@landisgyr.com> Alexander Pelov <mailto:a@ackl.io> Abhinav Somaraju <mailto:abhinav.somaraju@tridonic.com>"; description "This module contains the different definitions required by the CoOL protocol."; revision 2015-09-30 { description "Initial revision."; reference "draft-veillette-core-cool"; } // YANG modeling language extensions extension module-id { description "YANG statement used to assign a module ID."; argument "module-identifier"; } extension first-assigned-node-id { description "YANG statement used to specify the first identifier automatically assigned to a data node within a YANG module. Subsequent data nodes are assigned sequentially. Values lower than the first-assigned-node-id are reserved for manual assignment."; argument "first-data-node-identifier"; } extension first-assigned-rpc-id { description "YANG statement used to specify the first identifier automatically assigned to a protocol operation within a YANG module. Subsequent protocol operations are assigned sequentially. Values lower than the first-assigned-rpc-id are reserved for manual assignment."; Veillette, et al. Expires May 4, 2016 [Page 58]
Internet-Draft Constrained Objects Language November 2015 argument "first-rpc-identifier"; } extension first-assigned-notification-id { description "YANG statement used to specify the first identifier automatically assigned to a notification within a Yang module. Subsequent notifications are assigned sequentially. Values lower than the first-assigned-notification-id are reserved for manual assignment."; argument "first-notification-identifier"; } extension id { description "YANG statement used to assign a specific identifier to a data node, a protocol operation, a input parameter, a output parameter, a notification or a notification parameter. The argument of this extension contain two information, the path of the specified object and the associated identifier. These two parts are separated by a space."; argument "path-vs-id"; } typedef status-code { type enumeration { enum ok { value 0; description "The requested edit have been performed successfully."; } enum error { value 1; description "Unspecified error."; } enum malformed { value 2; description "Malformed CBOR payload."; } enum invalid { value 3; description "The value specified in the request can't be apply to the target data node."; } Veillette, et al. Expires May 4, 2016 [Page 59]
Internet-Draft Constrained Objects Language November 2015 enum doesNotExist { value 4; description "The target data node specified in the request don't exist."; } enum alreadyExist { value 5; description "The target data node specified in the request already exist."; } enum readOnly { value 6; description "Attempt to update a read-only data node."; } } } container error-info { description "Optional payload of a client error (CoAP response 4.xx) or server error (CoAP response 5.xx)."; leaf error-code { mandatory true; type status-code; } leaf error-text { mandatory false; type string; description "Textual descriptions of the error."; } } list patch-request { key "edit-id"; description "This list represents the payload of a patch request message. It carry a sequence of edits on a datastore. Each edit MUST be applied in ascending order, and all edits MUST be applied. If any errors occur, then the target datastore SOULD NOT be changed by the patch operation."; leaf edit-id { mandatory true; type uint8; Veillette, et al. Expires May 4, 2016 [Page 60]
Internet-Draft Constrained Objects Language November 2015 description "Error messages returned by the server pertaining to a specific edit will be identified by this value."; } leaf operation { mandatory true; type enumeration { enum "create" { value 0; description "The target data node is created using the supplied value, only if it does not already exist."; } enum "delete" { value 1; description "Delete the target node, only if the data resource currently exists, otherwise return an error."; } enum "merge" { value 2; description "The supplied value is merged with the target data node."; } enum "replace" { value 3; description "The supplied value is used to replace the target data node."; } enum "remove" { value 4; description "Delete the target node if it currently exists."; } enum insert-first { value 5; description "Insert the supplied value at the beginning of an user-ordered-list."; } enum insert-last { value 6; description "Insert the supplied value at the end of an user-ordered-list."; Veillette, et al. Expires May 4, 2016 [Page 61]
Internet-Draft Constrained Objects Language November 2015 } enum insert-before { value 7; description "Insert the supplied value in a user-ordered-list just before the entry identified by 'list-entry' parameter."; } enum insert-after { value 8; description "Insert the supplied value in a user-ordered-list just after the entry identified by 'list-entry' parameter."; } } } leaf list-entry { when "(../operation = 'delete' or ../operation = 'remove' or" + " ../operation = 'insert-before' or" + " ../operation = 'insert-after' )"; type binary; mandatory true; description "CBOR array containing an instance identifier used to identify an entry within a list."; } anyxml value { when "(../operation = 'create' or ../operation = 'merge' or" + " ../operation = 'replace' or " + " ../operation = 'insert-first' or" + " ../operation = 'insert-last' or" + " ../operation = 'insert-before' or" + " ../operation = 'insert-after')"; description "CBOR map containing the tag and value used for this edit operation."; } } list patch-response { key "edit-id"; description "This list represents the payload of a patch request response. Veillette, et al. Expires May 4, 2016 [Page 62]
Internet-Draft Constrained Objects Language November 2015 Each entry contain the status of an operation included in the corresponding request message."; leaf edit-id { mandatory true; type uint8; description "This value is used to match this entry with the corresponding entry in the patch-request list"; } leaf edit-status { mandatory true; type status-code; } leaf error-text { mandatory false; type string; description "Textual descriptions of the error."; } } } The following identifiers are assigned to the different objects of the ietf-cool module. +------+--------+---------------------------------------------------+ | DNID | FQDNID | Data node | +------+--------+---------------------------------------------------+ | 0 | 1024 | / | | 1 | 1025 | container /error-info | | 2 | 1026 | leaf /error-info/error-code | | 3 | 1027 | leaf /error-info/error-text | | 4 | 1028 | list /patch-request | | 5 | 1029 | leaf /patch-request/edit-id | | 6 | 1030 | leaf /patch-request/operation | | 7 | 1031 | leaf /patch-request/list-entry | | 8 | 1032 | anyxml /patch-request/value | | 9 | 1033 | list /patch-response | | 10 | 1034 | leaf /patch-response/edit-id | | 11 | 1035 | leaf /patch-response/edit-status | | 12 | 1036 | leaf /patch-response/error-text | +------+--------+---------------------------------------------------+ Veillette, et al. Expires May 4, 2016 [Page 63]
Internet-Draft Constrained Objects Language November 2015 Appendix B. ietf-cool-library YANG module This YANG module provides Meta information about modules and sub- modules implemented by the CoOL server. module ietf-cool-library { namespace "urn:ietf:ns:cool:library"; prefix cool; description "This YANG module provides Meta information about modules and sub-modules implemented by the CoOL server"; revision "2015-09-30" { description "Initial revision."; } typedef module-id { description "Registered identifier of a YANG module."; type uint32 { range "1..1048575"; } } list modules { key "module-id revision"; description "Each entry represents one module currently supported by the server."; leaf module-id { mandatory true; type module-id; description "Registered module ID for this YANG module."; } leaf name { type string; description "Name of this YANG module."; } leaf revision { mandatory true; type string { Veillette, et al. Expires May 4, 2016 [Page 64]
Internet-Draft Constrained Objects Language November 2015 pattern '\d{4}-\d{2}-\d{2}'; } description "Revision of this YANG module. An empty string is used if no revision statement is present in the YANG module."; } leaf-list features { type string; description "List of YANG feature names from this module that are supported by the server."; } leaf-list deviations { type string; description "List of YANG deviation module names used by this server to modify the conformance of the module associated with this entry."; } list submodules { key "name revision"; description "Each entry represents one submodule within the parent module."; leaf name { type string; description "Name of this YANG submodule."; } leaf revision { mandatory true; type string { pattern '\d{4}-\d{2}-\d{2}'; } description "The YANG submodule revision. An empty string is used if no revision statement is present in the YANG submodule."; } } leaf-list data-nodes { type uint32; Veillette, et al. Expires May 4, 2016 [Page 65]
Internet-Draft Constrained Objects Language November 2015 description "ID of each data node supported by this module, including those defined in sub-modules."; } leaf-list protocol-operations { type uint32; description "ID of each rpc supported by this module, including those defined in sub-modules."; } leaf-list notifications { type uint32; description "ID of each notification supported by this module, including those defined in sub-modules."; } } rpc is-supported { description "Used to verify if an object is supported by a CoOL server"; input { leaf module-id { type module-id; mandatory true; description "Module ID."; } choice object { case data-node { leaf data-node-id { type uint16 { range "1..1023"; } mandatory true; description "Data node ID."; } } case protocol-operation { leaf protocol-operation-id { type uint16; mandatory true; Veillette, et al. Expires May 4, 2016 [Page 66]
Internet-Draft Constrained Objects Language November 2015 description "Protocol operation ID."; } } case notification { leaf notification-id { type uint16; mandatory true; description "Notification ID."; } } } } output { leaf supported { type boolean; mandatory true; description "Return true is the specified object is supported."; } } } } The following identifiers are assigned to the different objects of the cool-library module. +------+--------+---------------------------------------------------+ | DNID | FQDNID | Data node | +------+--------+---------------------------------------------------+ | 0 | 2048 | / | | 1 | 2049 | list /modules | | 2 | 2050 | leaf /modules/module-id | | 3 | 2051 | leaf /modules/name | | 4 | 2052 | leaf /modules/revision | | 5 | 2053 | leaf-list /modules/features | | 6 | 2054 | leaf-list /modules/deviations | | 7 | 2055 | list /modules/submodules | | 8 | 2056 | leaf /modules/submodules/name | | 9 | 2057 | leaf /modules/submodules/revision | | 10 | 2058 | leaf-list /modules/data-nodes | | 11 | 2059 | leaf-list /modules/protocol-operations | | 12 | 2060 | leaf-list /modules/notifications | +------+--------+---------------------------------------------------+ Veillette, et al. Expires May 4, 2016 [Page 67]
Internet-Draft Constrained Objects Language November 2015 +---------------+---------------------------------------------------+ | Protocol | Protocol operation | | operation IDs | | +---------------+---------------------------------------------------+ | 1 | /is-supported | | | +---------------------+-----------------------+ | | | | Input parameter ID | Input parameter | | | | +---------------------+-----------------------+ | | | | 1 | module-id | | | | | 2 | data-node-id | | | | | 3 | protocol-operation-id | | | | | 4 | notification-id | | | | +---------------------+-----------------------+ | | | | | | +---------------------+-----------------------+ | | | | Output parameter ID | Output parameter | | | | +---------------------+-----------------------+ | | | | 1 | supported | | | | +---------------------+-----------------------+ | +---------------+---------------------------------------------------+ Authors' Addresses Michel Veillette (editor) Trilliant Networks Inc. 610 Rue du Luxembourg Granby, Quebec J2J 2V2 Canada Phone: +14503750556 Email: michel.veillette@trilliantinc.com Alexander Pelov (editor) Acklio 2 Rue de la Chataigneraie Cesson-Sevigne, Bretagne 35510 France Phone: +33299127004 Email: a@ackl.io Veillette, et al. Expires May 4, 2016 [Page 68]
Internet-Draft Constrained Objects Language November 2015 Somaraju Abhinav Tridonic GmbH & Co KG Farbergasse 15 Dornbirn, Vorarlberg 6850 Austria Phone: +43664808926169 Email: abhinav.somaraju@tridonic.com Randy Turner Landis+Gyr 30000 Mill Creek Ave Suite 100 Alpharetta, GA 30022 US Phone: ++16782581292 Email: randy.turner@landisgyr.com URI: http://www.landisgyr.com/ Veillette, et al. Expires May 4, 2016 [Page 69]