idnits 2.17.00 (12 Aug 2021) /tmp/idnits57979/draft-vanderstok-core-comi-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1088 has weird spacing: '...g value the c...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 9, 2014) is 3053 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-json-rfc4627bis' is defined on line 1225, but no explicit reference was found in the text == Unused Reference: 'RFC2863' is defined on line 1243, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 1267, but no explicit reference was found in the text == Unused Reference: 'RFC4113' is defined on line 1275, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 1278, but no explicit reference was found in the text == Unused Reference: 'RFC6347' is defined on line 1292, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-groupcomm' is defined on line 1311, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-06) exists of draft-becker-core-coap-sms-gprs-04 == Outdated reference: draft-ietf-core-block has been published as RFC 7959 == Outdated reference: draft-ietf-core-coap has been published as RFC 7252 == Outdated reference: draft-ietf-core-observe has been published as RFC 7641 == Outdated reference: draft-ietf-json-rfc4627bis has been published as RFC 7158 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: draft-ietf-core-groupcomm has been published as RFC 7390 == Outdated reference: A later version (-14) exists of draft-ietf-core-interfaces-01 == Outdated reference: A later version (-04) exists of draft-bierman-netconf-restconf-02 Summary: 2 errors (**), 0 flaws (~~), 19 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 core P. van der Stok 3 Internet-Draft consultant 4 Intended status: Informational B. Greevenbosch 5 Expires: July 13, 2014 Huawei Technologies 6 January 9, 2014 8 CoAp Management Interfaces 9 draft-vanderstok-core-comi-02 11 Abstract 13 The draft describes an interface based on CoAP to manage constrained 14 devices via MIBs. The proposed integration of CoAP with SNMP reduces 15 the code- and application development complexity by accessing MIBs 16 via a standard CoAP server. The payload of the MIB request is CBOR 17 based on JSON. The mapping from SMI to CBOR is specified. 19 Note 21 Discussion and suggestions for improvement are requested, and should 22 be sent to core@ietf.org. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 13, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. CoAP Interface . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. MIB Function Set . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. SNMP/MIB architecture . . . . . . . . . . . . . . . . . . 5 63 3.1.1. SNMP functions . . . . . . . . . . . . . . . . . . . 6 64 3.1.2. MIB structure . . . . . . . . . . . . . . . . . . . . 7 65 3.2. CoMI Function Set . . . . . . . . . . . . . . . . . . . . 8 66 3.2.1. Single MIB values . . . . . . . . . . . . . . . . . . 9 67 3.2.2. multi MIB values . . . . . . . . . . . . . . . . . . 11 68 3.2.3. Table row . . . . . . . . . . . . . . . . . . . . . . 13 69 3.2.4. Error returns . . . . . . . . . . . . . . . . . . . . 14 70 4. Mapping SMI to CoMI payload . . . . . . . . . . . . . . . . . 14 71 4.1. Mapping strings to CBOR . . . . . . . . . . . . . . . . . 15 72 4.2. Mapping SMI to CBOR . . . . . . . . . . . . . . . . . . . 16 73 4.2.1. General overview . . . . . . . . . . . . . . . . . . 16 74 4.2.2. Conversion from YANG datatypes to CBOR datatypes . . 16 75 4.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 18 76 4.2.4. 6LoWPAN MIB . . . . . . . . . . . . . . . . . . . . . 20 77 5. MIB discovery . . . . . . . . . . . . . . . . . . . . . . . . 23 78 6. Trap functions . . . . . . . . . . . . . . . . . . . . . . . 24 79 7. MIB access management . . . . . . . . . . . . . . . . . . . . 24 80 7.1. Notify destinations . . . . . . . . . . . . . . . . . . . 24 81 7.2. Conversion tables . . . . . . . . . . . . . . . . . . . . 25 82 8. Error handling . . . . . . . . . . . . . . . . . . . . . . . 25 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 85 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 86 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 27 87 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 88 13.1. Normative References . . . . . . . . . . . . . . . . . . 27 89 13.2. Informative References . . . . . . . . . . . . . . . . . 28 90 Appendix A. Notational Convention for CBOR data . . . . . . . . 30 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 93 1. Introduction 95 The Constrained RESTful Environments (CoRE) working group aims at 96 Machine to Machine (M2M) applications such as smart energy and 97 building control. 99 Small M2M devices need to be managed in an automatic fashion to 100 handle the large quantities of devices that are expected to be 101 installed in future installations. The management protocol of choice 102 for Internet is SNMP [RFC3410] as is testified by the large number of 103 Management Information Base (MIB) [RFC3418] specifications currently 104 published [STD0001]. More recently, the NETCONF protocol [RFC6241] 105 was developed with an extended set of messages using XML [XML] as 106 data format. The data syntax is specified with YANG [RFC6020] and a 107 mapping from Yang to XML is specified. In [RFC6643] SMIv2 syntax is 108 expressed in Yang. Contrary to SNMP and also CoAP, NETCONF assumes 109 persistent connections for example provided by SSH. The NETCONF 110 protocol provides operations to retrieve, configure, copy, and delete 111 configuration data-stores. Configuring data-stores distinguishes 112 NETCONF from SNMP which operates on standardized MIBs. 114 The CoRE Management Interface (CoMI) is intended to work on 115 standardized data-sets in a stateless client-server fashion and is 116 thus closer to SNMP than to NETCONF. Standardized data sets promote 117 interoperability between small devices and applications from 118 different manufacturers. Stateless communication is encouraged to 119 keep communications simple and the amount of state information small 120 in line with the design objectives of 6lowpan [RFC4944] [RFC6775], 121 RPL [RFC6650], and CoAP [I-D.ietf-core-coap]. 123 The draft [I-D.bierman-netconf-restconf] describes a restful 124 interface to NETCONF data stores and approaches the CoMI approach. 125 CoMI uses SMI encoded in CBOR, and CoAP/UDP to access MIBs, where 126 restconf uses YANG encoded in JSON and HTTP/TCP to access NETCONF 127 data stores. CoMI is more low resource oriented than restconf is. 129 Currently, managed devices need to support two protocols: CoAP and 130 SNMP. When the MIB can be accessed with the CoAP protocol, the SNMP 131 protocol can be replaced with the CoAP protocol. This arrangement 132 reduces the code complexity of the stack in the constrained device, 133 and harmonizes applications development. 135 The objective of CoMI is to provide a CoAP based Function Set that 136 reads and sets values of MIB variables in devices to (1) initialize 137 parameter values at start-up, (2) acquire statistics during 138 operation, and (3) maintain nodes by adjusting parameter values 139 during operation. 141 The payload of CoMI is encoded in CBOR [RFC7049] which similar to 142 JSON [JSON], but has a binary format and hence has more coding 143 efficiency. CoMI is intended for small devices. The JSON overhead 144 can be prohibitive. It is therefore chosen to transport CBOR in the 145 payload. CBOR, like BER used for SNMP, transports the data type in 146 the payload. 148 The end goal of CoMI is to provide information exchange over the CoAP 149 transport protocol in a uniform manner to approach the full 150 management functionality as specified in 151 [I-D.ersue-constrained-mgmt]. 153 1.1. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 Readers of this specification are required to be familiar with all 160 the terms and concepts discussed in [RFC3410], [RFC3416], and 161 [RFC2578]. 163 Core Management Interface (CoMI) specifies the profile of Function 164 Sets which access MIBs with the purpose of managing the operation of 165 constrained devices in a network. 167 The following list defines the terms used in this document: 169 Managing Entity: An entity that manages one or more managed devices. 170 Within the CoMI framework, the managing entity acts as a CoAP 171 client for CoMI. 173 Managed Device: An entity that is being managed. The managed device 174 acts as a CoAP server for CoMI. 176 NOTE: It is assumed that the managed device is the most constrained 177 entity. The managing entity might be more capable, however this is 178 not necessarily the case. 180 The following list contains the abbreviations used in this document. 182 OID: ASN.1 OBJECT-IDENTIFIER, which is used to uniquely identify MIB 183 objects in the managed device. 185 2. CoAP Interface 187 In CoRE a group of links can constitute a Function Set. The format of 188 the links is specified in [I-D.ietf-core-interfaces]. This note 189 specifies a Management Function Set. CoMI end-points that implement 190 the CoMI management protocol support at least one discoverable 191 management resource of resource type (rt): core.mg, with path: /mg, 192 where mg is short-hand for management. The mg resource has two sub- 193 resources accessible with the paths: 195 o MIB with path /mg/mib and a CBOR content format. 197 o XLAT with path /mg/xlat and CBOR content format. 199 The mib resource provides access to the MIBs as described in 200 Section 3.2. The xlat resource provides access to a string to CBOR 201 identifier table as described in Section 4.1. The mib and xlat 202 resources are introduced as sub resources to mg to permit later 203 additions to CoMI mg resource. 205 The profile of the management function set, with IF=core.mg.mib, is 206 shown in the table below, following the guidelines of 207 [I-D.ietf-core-interfaces]: 209 +-----------------+-----------+---------------+-------------------+ 210 | name | path | RT | Data Type | 211 +-----------------+-----------+---------------+-------------------+ 212 | Management | /mg | core.mg | n/a | 213 | | | | | 214 | MIB | /mg/mib | core.mg.mib | application/cbor | 215 | | | | | 216 | XLAT | /mg/xlat | core.mg.xlat | application/cbor | 217 +-----------------+-----------+---------------+-------------------+ 219 3. MIB Function Set 221 The MIB Function Set provides a CoAP interface to perform equivalent 222 functions to the ones provided by SNMP. Section 3.1 explains the 223 structure of SNMP Protocol Data Units (PDU), their transport, and the 224 structure of the MIB modules. An excellent overview of the documents 225 describing the SNMP/MIB architecture is provided in section 7 of 226 [RFC3410]. 228 3.1. SNMP/MIB architecture 230 The architecture of the Internet Standard management framework 231 consists of: 233 o A data definition language that is referred to as Structure of 234 Management Information (SMI)[RFC2578]. 236 o The Management Information Base (MIB) which contains the 237 information to be managed and is defined for each specific 238 function to be managed [RFC3418]. 240 o A protocol definition referred to as Simple Network Management 241 Protocol (SNMP) [RFC3416]. 243 o Security and administration that provides SNMP message based 244 security on the basis of the user-based security model [RFC3414]. 246 o A management domain definition where a SNMP entity has access to a 247 collection of management information called a "context" [RFC3411]. 249 In addition [RFC4088] describes a URI scheme to refer to a specific 250 MIB instance. 252 Separation in modules was motivated by the wish to respond to the 253 evolution of Internet. The protocol part (SNMP) and data definition 254 part (MIB) are independent of each other. The separation has enabled 255 the progressive passage from SNMPv1 via SNMPv2 to SNMPv3. This draft 256 leverages this separation to replace the SNMP protocol with a CoAP 257 based protocol. 259 3.1.1. SNMP functions 261 The SNMP protocol supports seven types of access supported by as many 262 Protocol Data Unit (PDU) types: 264 o Get Request, transmits a list of OBJECT-IDENTIFIERs to be paired 265 with values. 267 o GetNext Request, transmits a list of OBJECT-IDENTIFIERs to which 268 lexicographic successors are returned for table traversal. 270 o GetBulk Request, transmits a list of OBJECT-IDENTIFIERs and the 271 maximum number of expected paired values. 273 o Response, returns an error or the (OBJECT-IDENTIFIER, value) pairs 274 for the OBJECT-IDENTIFIERs specified in Get, GetNext, GetBulk, 275 Set, or Inform Requests. 277 o Set Request, transmits a list of (OBJECT-IDENTIFIERs, value) pairs 278 to be set in the specified MIB object. 280 o Trap, sends an unconfirmed message with a list of (OBJECT- 281 IDENTIFIERs, value) pairs to a notification requesting end-point. 283 o Inform Request, sends a confirmed message with a list of (OBJECT- 284 IDENTIFIERs, value) pairs to a notification requesting end-point. 286 The binding of the notification to a destination is discussed in 287 Section 6. 289 3.1.2. MIB structure 291 A MIB module is composed of MIB objects. MIB objects are 292 standardized by the IETF or by other relevant Standards Developing 293 Organizations (SDO). 295 MIB objects have a descriptor and an identifier: OBJECT-IDENTIFIER 296 (OID). The identifier, following the OSI hierarchy, is an ordered 297 list of non-negative numbers [RFC2578]. OID values are unique. Each 298 number in the list is referred as a sub-identifier. The descriptor 299 is unique within a module. Different modules may contain the same 300 descriptor. Consequently, a descriptor can be related to several 301 OIDs. 303 Many instances of an object type exist within a management domain. 304 Each instance can be identified within some scope or "context", where 305 there are multiple such contexts within the management domain. 306 Often, a context is a physical or logical device. A context is 307 always defined as a subset of a single SNMP entity. To identify an 308 individual item of management information within the management 309 domain, its contextName and contextEngineID must be identified in 310 addition to its object type and its instance. A default context is 311 assumed when no context is specified. 313 A MIB object is usually a scalar object. A MIB object may have a 314 tabular form with rows and columns. Such an object is composed of a 315 sequence of rows, with each row composed of a sequence of typed 316 values. The index is a subset (1-2 items) of the typed values in the 317 row. An index value identifies the row in the table. 319 In SMI, a table is constructed as a SEQUENCE OF its entries. For 320 example, the IpAddrTable from [RFC4293] has the following definition: 322 ipv6InterfaceTable OBJECT-TYPE 323 SYNTAX SEQUENCE OF Ipv6InterfaceEntry 324 MAX-ACCESS not-accessible 325 STATUS current 326 DESCRIPTION 327 "The table containing per-interface IPv6-specific 328 information." 329 ::= { ip 30 } 331 ipv6InterfaceEntry OBJECT-TYPE 332 SYNTAX Ipv6InterfaceEntry 333 MAX-ACCESS not-accessible 334 STATUS current 335 DESCRIPTION 336 "An entry containing IPv6-specific information for a given 337 interface." 338 INDEX { ipv6InterfaceIfIndex } 339 ::= { ipv6InterfaceTable 1 } 341 Ipv6InterfaceEntry ::= SEQUENCE { 342 ipv6InterfaceIfIndex InterfaceIndex, 343 ipv6InterfaceReasmMaxSize Unsigned32, 344 ipv6InterfaceIdentifier Ipv6AddressIfIdentifierTC, 345 ipv6InterfaceEnableStatus INTEGER, 346 ipv6InterfaceReachableTime Unsigned32, 347 ipv6InterfaceRetransmitTime Unsigned32, 348 ipv6InterfaceForwarding INTEGER 349 } 351 The descriptor (name) of the MIB table is used for the name of the 352 CoMI variable. However, there is no explicit mention of the names 353 "ipv6InterfaceEntry" and "Ipv6InterfaceEntry". Instead, the value of 354 the main CoMI variable consists of an array, each element of which 355 contains 7 CoMI variables: one element for "ipv6InterfaceIfIndex", 356 one for "ipv6InterfaceReasmMaxSize" and so on until 357 "ipv6InterfaceForwarding". 359 3.2. CoMI Function Set 361 Two types of interfaces are supported by CoMI: 363 single value Reading/Writing one MIB variable, specified in the URI 364 with path /mg/mib/descriptor or with path /mg/mib/OID. 366 multiple values Reading writing arrays or multiple MIB variables, 367 specified in the payload. 369 The examples in this section use a JSON payload with one or more 370 entries describing the pair (descriptor, value), or (OID, value). 371 The CBOR syntax of the payloads is specified in Section 4. 373 3.2.1. Single MIB values 375 A request to read the value of a MIB variable is sent with a 376 confirmable CoAP GET message. The single MIB variable is specified 377 in the URI path with the OID or descriptor suffixing the /mg/mib/ 378 path name. When the descriptor is used to specify the MIB value, the 379 same descriptor may be present in multiple module. To disambiguate 380 the descriptor the "mod" uri-query attribute specifies the enveloping 381 modules. A request to set the value of a MIB variable is sent with a 382 confirmable CoAP PUT message. The Response is piggybacked to the 383 CoAP ACK message corresponding with the Request. 385 TODO: for multicast send unconfirmed PUT 387 Using for example the same MIB from [RFC1213] as used in [RFC3416], a 388 request is sent to retrieve the value of sysUpTime specified in 389 module SNMPv2-MIB. The answer to the request returns a (descriptor, 390 value) pair. 392 For clarity of the examples, in this and all following examples the 393 payload is expressed in JSON, although the operational payload is 394 specified to be in CBOR, as described in Section 4. 396 REQ: GET example.com/mg/mib/sysUpTime?mod=SNMPv2-MIB 398 RES: 2.05 Content (Content-Format: application/json) 399 { 400 "sysUpTime" : 123456 401 } 403 Another way to express the descriptor of the required value is by 404 specifying the pair (descriptor or oid, null value) in the payload of 405 the request message. 407 REQ: GET example.com/mg/mib/(Content-Format: application/json) 408 { 409 "SNMPv2-MIB.sysUpTime" : "null" 410 } 412 RES: 2.05 Content (Content-Format: application/json) 413 { 414 "SNMPv2-MIB.sysUpTime" : 123456 415 } 417 The module name SNMPv2-MIB can be omitted when there is no 418 possibility of ambiguity. The module.descriptor can of course be 419 replaced with the corresponding oid. 421 In some cases it is necessary to determine the "context" by 422 specifying a context name and a contextEngine identifier. The 423 context can be specified in the URI with the uri-query attribute 424 "con". Based on the example of figure 3 in section 3.3 of [RFC3411], 425 the context name, bridge1, and the context Engine Identifier, 426 800002b804616263, separated by an underscore, are specified in the 427 following example: 429 REQ: GET example.com/mg/mib/sysUPTime?con=bridge1_800002b804616263 431 RES: 2.05 Content (Content-Format: application/json) 432 { 433 "sysUpTime" : 123456 434 } 436 The specified object can be a table. The returned payload is 437 composed of all the rows associated with the table. Each row is 438 returned as a set of (column name, value) pairs. For example the GET 439 of the ipNetToMediaTable, sent by the managing entity, results in the 440 following returned payload sent by the managed entity: 442 REQ: GET example.com/mg/mib/ipNetToMediaTable 444 RES: 2.05 Content (Content-Format: application/json) 445 { 446 "ipNetTOMediaTable" : [ 447 { 448 "ipNetToMediaIfIndex" : 1, 449 "ipNetToMediaPhysAddress" : "00:00::10:01:23:45", 450 "ipNetToMediaNetAddress" : "10.0.0.51", 451 "ipNetToMediaType" : "static" 452 }, 453 { 454 "ipNetToMediaIfIndex" : 1, 455 "ipNetToMediaPhysAddress" : "00:00::10:54:32:10", 456 "ipNetToMediaNetAddress" : "9.2.3.4", 457 "ipNetToMediaType" : "dynamic" 458 }, 459 { 460 "ipNetToMediaIfIndex" : 2, 461 "ipNetToMediaPhysAddress" : "00:00::10:98:76:54", 462 "ipNetToMediaNetAddress" : "10.0.0.15", 463 "ipNetToMediaType" : "dynamic" 464 } 465 ] 466 } 468 It is possible that the size of the returned payload is too large to 469 fit in a single message. 471 CoMI gives the possibility to send the contents of the objects in 472 several fragments with a maximum size. The "sz" link-format 473 attribute [RFC6690] can be used to specify the expected maximum size 474 of the mib resource in (identifier, value) pairs. The returned data 475 MUST terminate with a complete (identifier, value) pair. 477 In the case that management data is bigger than the maximum supported 478 payload size, the Block mechanism from [I-D.ietf-core-block] is used. 479 Notice that the Block mechanism splits the data at fixed positions, 480 such that individual data fields may become fragmented. Therefore, 481 assembly of multiple blocks may be required to process the complete 482 data field. 484 3.2.2. multi MIB values 486 A request to read multiple MIB variables is done by expressing the 487 pairs (MIB descriptor, null) in the payload of the GET request 488 message. A request to set multiple MIB variables is done by 489 expressing the pairs (MIB descriptor, null value) in the payload of 490 the PUT request message. The key word _multiMIB is used as array 491 name to signal that the payload contains multiple MIB values as 492 separate _multiMIB array entries. 494 The following example shows a request that specifies to return the 495 values of sysUpTime and ipNetToMediaTable: 497 REQ: GET example.com/mg/mib (Content-Format: application/json) 498 { 499 "_multiMIB" : [ 500 { "sysUpTime" : "null"}, 501 { "ipNetToMediaTable" : "null" } 502 ] 503 } 505 RES: 2.05 Content (Content-Format: application/json) 506 { 507 "_multiMIB" : [ 508 { "sysUpTime" : 123456}, 509 { "ipNetTOMediaTable" : [ 510 { 511 "ipNetToMediaIfIndex" : 1, 512 "ipNetToMediaPhysAddress" : "00:00::10:01:23:45", 513 "ipNetToMediaNetAddress" : "10.0.0.51", 514 "ipNetToMediaType" : "static" 515 }, 516 { 517 "ipNetToMediaIfIndex" : 1, 518 "ipNetToMediaPhysAddress" : "00:00::10:54:32:10", 519 "ipNetToMediaNetAddress" : "9.2.3.4", 520 "ipNetToMediaType" : "dynamic" 521 }, 522 { 523 "ipNetToMediaIfIndex" : 2, 524 "ipNetToMediaPhysAddress" : "00:00::10:98:76:54", 525 "ipNetToMediaNetAddress" : "10.0.0.15", 526 "ipNetToMediaType" : "dynamic" 527 } 528 ] 529 } 530 ] 531 } 533 3.2.3. Table row 535 The managing entity MAY be interested only in certain table entries. 536 One way to specify a row is to specify its row number in the URI with 537 the "row" uri-query attribute. The specification of row=1 returns 538 row 1 values of the ipNetToMediaTable in the example: 540 REQ: GET example.com/mg/mib/ipNetToMediaTable?row=1 542 RES: 2.05 Content (Content-Format: application/json) 543 { "ipNetTOMediaTable" : [ 544 { 545 "ipNetToMediaIfIndex" : 1, 546 "ipNetToMediaPhysAddress" : "00:00::10:01:23:45", 547 "ipNetToMediaNetAddress" : "10.0.0.51", 548 "ipNetToMediaType" : "static" 549 } 550 ] 551 } 553 An alternative mode of selection is by specifying the value of the 554 INDEX attributes. Towards this end, the managing entity can include 555 the required entries in the payload of its "GET" request by 556 specifying the values of the index attributes. The key word 557 _indexMIB is used to specify the index value. 559 For example, to obtain a table entry from ipNetToMediaTable, the rows 560 are specified by specifying the index attributes: ipNetToMediaIfIndex 561 and ipNetToMediaNetAddress. The managing entity could have sent a 562 GET with the following payload: 564 REQ: GET example.com/mg/mib/ipNetToMediaTable(Content-Format: application/json) 566 { "_indexMIB" : 567 { 568 "ipNetToMediaIfIndex" : 1, 569 "ipNetToMediaNetAddress" : "9.2.3.4" 570 } 571 } 573 RES: 2.05 Content (Content-Format: application/json) 574 { "ipNetTOMediaTable" : [ 575 { 576 "ipNetToMediaIfIndex" : 1, 577 "ipNetToMediaPhysAddress" : "00:00::10:01:23:45", 578 "ipNetToMediaNetAddress" : "9.2.3.4", 579 "ipNetToMediaType" : "static" 580 } 581 ] 582 } 584 Constrained devices MAY support this kind of filtering. However, if 585 they don't support it, they MUST ignore the payload in the GET 586 request and handle the message as if the payload was empty. 588 It is advised to keep MIBs for constrained entities as simple as 589 possible, and therefore it would be best to avoid extensive tables. 591 TODO: Describe how the contents of the next lexicographical row can 592 be returned. 594 3.2.4. Error returns 596 When a variable with the specified name cannot be processed, CoAP 597 Error code 5.01 is returned. In addition, a MIB specific error can 598 be returned in the payload as specified in Section 8. 600 4. Mapping SMI to CoMI payload 602 The SMI syntax is mapped to CBOR necessary for the transport of MIB 603 data in the CoAP payload. This section first describes an additional 604 data reduction technique by creating a table that maps string values 605 to numbers used in CBOR encoded data. 607 The section continues by describing the mapping from SMI to CBOR. 608 The mapping is inspired by the mapping from SMI to JSON via YANG 609 [RFC6020], as described in [RFC6643] defining a mapping from SMI to 610 YANG, and [I-D.lhotka-netmod-yang-json] defining a mapping from YANG 611 to JSON. 613 Notice that such conversion chain MAY be virtual only, as SMI could 614 be converted directly to JSON by combining the rules from the above 615 documents. 617 4.1. Mapping strings to CBOR 619 Because descriptors may be rather long and may occur repeatedly, CoMI 620 allows for association of a string with an integer, henceforth called 621 "string number". The association between string and string number is 622 done through a translation table, leveraging CBOR encoding. 624 Using the notational convention from Appendix A, the CBOR data has 625 the following syntax: 627 cBorMIB : CBorMIB; 629 *CBorMIB { 630 xlatTableID : uint; 631 mibString : map( uint, . ); 632 } 634 The main structure consist of an array of two elements: "xlatTableID" 635 and "mibString". 637 The values of the MIB strings are stored in the "mibString" field. 638 This field consist of integer-value pairs. The integers correspond 639 to the string numbers, whereas the values contain the actual value of 640 the associated string. 642 The "xlatTableID" contains an integer that is used to indentify the 643 translation table. The translation table can be acquired as follows: 645 GET /mg/xlat/[xlatTableID] 647 where "[xlatTableID]" is replaced by the the value of xlatId from the 648 CBorMIB structure, encoded as a hexidecimal integer without leading 649 zeros. 651 The maintenance of the table is described in Section 7.2. 653 The use of the table is to initialize devices with the strings which 654 will be frequently used, such as the strings of the descriptors in 655 the MIB variables. The transmitted CBOR data will contain the string 656 numbers and not the entire descriptor strings, leading to appreciable 657 data reduction. 659 It is important that sender and receiver have identical versions of 660 the table. 662 The translation table is serialized to the payload in the following 663 fashion: 665 xlatTable : XLatTable; 667 *XLatTable { 668 xlatId : uint; 669 xlatData : map( uint, tstr ); 670 } 672 where "xlatId" has the same value as "xlatId" in the CBorMIB 673 structure, and "xlatData" is a CBOR map between the string number and 674 associated variable descriptor. 676 4.2. Mapping SMI to CBOR 678 4.2.1. General overview 680 Starting from the intermediate conversion from SMI to YANG as defined 681 in [RFC6643], This section defines how to convert the resulting YANG 682 structure to CBOR [RFC7049]. The actual conversion code from SMI to 683 YANG and subsequently YANG to CBOR MAY be direct conversion code from 684 SMI to CBOR or a sequence of existing SMI to YANG conversion code 685 followed by YANG to CBOR conversion code. 687 4.2.2. Conversion from YANG datatypes to CBOR datatypes 689 Table 1 defines the mapping between YANG datatypes and CBOR 690 datatypes. 692 Elements of types not in this table, and of which the type cannot be 693 inferred from a type in this table, are ignored in the CBOR encoding 694 by default. Examples include the "description" and "key" elements. 695 However, conversion rules for some elements to CBOR MAY be defined 696 elsewhere. 698 +-------------+------------------+----------------------------------+ 699 | YANG type | CBOR type | Specification | 700 +-------------+------------------+----------------------------------+ 701 | int8, | unsigned int | The CBOR integer type depends on | 702 | int16, | (major type 0) | the sign of the actual value. | 703 | int32, | or negative int | | 704 | int64, | (mayor type 1) | | 705 | uint16, | | | 706 | uint32, | | | 707 | uint64, | | | 708 | decimal64 | | | 709 | | | | 710 | boolean | either "true" | | 711 | | (major type 7, | | 712 | | simple value 21) | | 713 | | or "false" | | 714 | | (major type 7, | | 715 | | simple value 20) | | 716 | | | | 717 | string | text string | | 718 | | (major type 3) | | 719 | | | | 720 | enumeration | unsigned int | | 721 | | (major type 0) | | 722 | | | | 723 | bits | array of text | Each text string contains the | 724 | | strings | name of a bit value that is set. | 725 | | | | 726 | binary | byte string | | 727 | | (major type 2) | | 728 | | | | 729 | empty | null (major type | TBD: This MAY not be applicable | 730 | | 7, simple value | to true MIBs, as SNMP may not | 731 | | 22) | support empty variables... | 732 | | | | 733 | union | | Similar ot the JSON | 734 | | | transcription from | 735 | | | [I-D.lhotka-netmod-yang-json], | 736 | | | the elements in a union MUST be | 737 | | | determined using the procedure | 738 | | | specified in section 9.12 of | 739 | | | [RFC6020]. | 740 | | | | 741 | leaf-list | array (major | The array is encapsulated in the | 742 | | type 4) | map associated with the | 743 | | | descriptor. | 744 | | | | 745 | list | map (major type | Like the higher level map, the | 746 | | 4) | lower level map contains | 747 | | | descriptor number - value pairs | 748 | | | of the elements in the list. | 749 | | | | 750 | container | map (major type | The map contains decriptor | 751 | | 5) | number - value pairs | 752 | | | corresponding to the elements in | 753 | | | the container. | 754 | | | | 755 | smiv2:oid | array of | Each integer contains an element | 756 | | integers | of the OID, the first integer in | 757 | | | the array corresponds to the | 758 | | | most left element in the OID. | 759 +-------------+------------------+----------------------------------+ 761 Table 1: Conversion of YANG datatypes to CBOR 763 4.2.3. Examples 765 4.2.3.1. ipNetToMediaTable to JSON/CBOR 767 The YANG translation of the SMI specifying the 768 ipNetToMediaTable yields: 770 container ipNetToMediaTable { 771 list ipNetToMediaEntry { 772 leaf ipNetToMediaIfIndex { 773 type: int32; 774 } 775 leaf ipNetToPhysAddress { 776 type: phys-address; 777 } 778 leaf ipNetToMediaNetAddress { 779 type: ipv4-address; 780 } 781 leaf ipNetToMediaType { 782 type: int32; 783 } 784 } 785 } 787 The coresponding JSON looks like: 789 { 790 "ipNetToMediaTable" : { 791 "ipNetToMediaEntry" : [ 792 { 793 "ipNetToMediaIfIndex" : 1. 794 "ipNetToMediaPhysAddress" : "00:00::10:01:23:45", 795 "ipNetToMediaNetAddress" : "10.0.0.51", 796 "ipNetToMediaType" : "static" 797 }, 798 { 799 "ipNetToMediaIfIndex " : 1, 800 "ipNetToMediaPhysAddress " : "00:00::10:54:32:10", 801 "ipNetToMediaNetAddress" : "9.2.3.4", 802 "ipNetToMediaType " : "dynamic" 803 } 804 ] 805 } 806 } 808 An example CBOR instance of the MIB can be found in Figure 1. The 809 names "ipNetToMediaTable", "ipNetToMediaEntry", and 810 "ipNetToMediaIfIndex" are represented with the string numbers 00, 01, 811 and 02 as described in Section 4.1. 813 82 # two element array 814 19 43 A1 # translation table ID 43A1 815 BF # indefinite length map 816 00 # descriptor number related to 817 # ipNetToMediaTable 818 BF # indefinite length map related to 819 # ipNetToMediaTable 820 01 # descriptor number related to 821 # ipNetToMediaEntry 822 BF # map related to ipNetToMediaEntry 823 02 # descriptor number associated with 824 # ipNetToMediaIfIndex 825 1A 00 00 00 01 # associated value as 32-bit integer 826 # ... 827 FF 828 FF 829 FF 831 Figure 1: Example CBOR encoding for ifTable 833 The associated "descriptor string" to "string number" translation 834 table is given in Figure 2. 836 82 # two element array 837 19 43 A1 # translation table ID 43A1 838 BF # indefinite length map 839 00 # descriptor number related to 840 # ipNetToMediaTable 841 72 69 70 50 65 74 57 842 6F 51 65 64 61 57 61 843 62 6C 65 # "ipNetToMediaTable" 844 01 # descriptor number related to 845 # ipNetToMediaEntry 846 72 69 70 50 65 74 57 847 6F 51 65 64 61 45 6E 848 74 72 78 # "ipNetToMediaEntry" 849 02 # descriptor number related to 850 # ipNetToMediaIfIndex 851 75 69 70 50 65 74 57 852 6F 51 65 64 61 61 49 853 66 49 6E 64 65 77 # "ipNetToMediaIfIndex" 854 # ... 855 FF 857 Figure 2: Translation table for ifTable 859 4.2.4. 6LoWPAN MIB 861 A MIB for 6LoWPAN is defined in [I-D.schoenw-6lowpan-mib]. The 862 document also provides an example JSON representation in its 863 Appendix A. Figure 3 shows the associated CBOR representation with 864 string number, and Figure 4 shows the corresponding string to string 865 number conversion table. 867 82 # two element array 868 1A 8B 47 88 F3 # translation table ID 8B4788F3 869 BF # indefinite length map 870 00 # "LOWPAN-MIB:LOWPAN-MIB" 871 BF # indefinite length map related to ifTable 872 01 # "lowpanReasmTimeout" 873 14 # 20 874 02 # "lowpanInReceives" 875 18 2A # 42 876 03 # "lowpanInHdrErrors" 877 00 # 0 878 04 # "lowpanInMeshReceives" 879 08 # 8 880 05 # "lowpanInMeshForwds" 881 00 # 0 882 06 # "lowpanInMeshDelivers" 883 00 # 0 884 07 # "lowpanInReasmReqds" 885 16 # 22 886 08 # "lowpanInReasmFails" 887 02 # 02 888 09 # "lowpanInReasmOKs" 889 14 # 20 890 0A # "lowpanInCompReqds" 891 10 # 16 892 0B # "lowpanInCompFails" 893 02 # 2 894 0C # "lowpanInCompOKs" 895 0E # 14 896 0D # "lowpanInDiscards" 897 01 # 01 898 0E # "lowpanInDelivers" 899 0C # 12 900 0F # "lowpanOutRequests" 901 0C # 12 902 10 # "lowpanOutCompReqds" 903 00 # 0 904 11 # "lowpanOutCompFails" 905 00 # 0 906 12 # "lowpanOutCompOKs" 907 00 # 0 908 13 # "lowpanOutFragReqds" 909 05 # 5 910 14 # "lowpanOutFragFails" 911 00 # 0 912 15 # "lowpanOutFragOKs" 913 05 # 5 914 16 # "lowpanOutFragCreates" 915 08 # 8 916 17 # "lowpanOutMeshHopLimitExceeds" 917 00 # 0 918 18 18 # "lowpanOutMeshNoRoutes" 919 00 # 0 920 18 19 # "lowpanOutMeshRequests" 921 00 # 0 922 18 1A # "lowpanOutMeshForwds" 923 00 # 0 924 18 1B # "lowpanOutMeshTransmits" 925 00 # 0 926 18 1C # "lowpanOutDiscards" 927 00 # 0 928 18 1D # "lowpanOutTransmits" 929 0F # 15 930 FF 932 FF 934 Figure 3: Example CBOR encoding for the 6LoWPAN MIB 936 82 # two element array 937 1A 8B 47 88 F3 # translation table ID 8B4788F3 938 BF # indefinite length map 939 00 940 75 # "LOWPAN-MIB:LOWPAN-MIB" 941 01 # 942 72 ... # "lowpanReasmTimeout" 943 02 944 70 ... # "lowpanInReceives" 945 03 946 71 ... # "lowpanInHdrErrors" 947 04 948 74 ... # "lowpanInMeshReceives" 949 05 950 72 ... # "lowpanInMeshForwds" 951 06 952 74 ... # "lowpanInMeshDelivers" 953 07 954 72 ... # "lowpanInReasmReqds" 955 08 956 72 ... # "lowpanInReasmFails" 957 09 958 70 ... # "lowpanInReasmOKs" 959 0A 960 71 ... # "lowpanInCompReqds" 961 0B 962 71 ... # "lowpanInCompFails" 963 0C 964 6F ... # "lowpanInCompOKs" 965 0D 966 70 ... # "lowpanInDiscards" 967 0E 968 70 ... # "lowpanInDelivers" 969 0F 970 71 ... # "lowpanOutRequests" 971 10 972 72 ... # "lowpanOutCompReqds" 973 11 974 72 ... # "lowpanOutCompFails" 975 12 976 70 ... # "lowpanOutCompOKs" 977 13 978 72 ... # "lowpanOutFragReqds" 979 14 980 72 ... # "lowpanOutFragFails" 981 15 982 70 ... # "lowpanOutFragOKs" 983 16 984 74 ... # "lowpanOutFragCreates" 985 17 986 78 1B ... # "lowpanOutMeshHopLimitExceeds" 987 18 18 988 75 ... # "lowpanOutMeshNoRoutes" 989 18 19 990 75 ... # "lowpanOutMeshRequests" 991 18 1A 992 73 ... # "lowpanOutMeshForwds" 993 18 1B 994 76 ... # "lowpanOutMeshTransmits" 995 18 1C 996 71 ... # "lowpanOutDiscards" 997 18 1D 998 72 ... # "lowpanOutTransmits" 999 FF 1001 Figure 4: Translation table for the 6LoWPAN MIB 1003 In this example, a GET to /mg/mib/lowpanOutFragFails would give: 1005 82 # two element array 1006 1A 8B 47 88 F3 # translation table ID 8B4788F3 1007 BF # indefinite length map 1008 14 # "lowpanOutFragFails" 1009 00 # 0 1010 FF 1012 5. MIB discovery 1014 MIB objects are discovered like resources with the standard CoAP 1015 resource discovery. Performing a GET on "/.well-known/core" with 1016 rt=core.mg.mib returns all MIB descriptors and all OIDs which are 1017 available on this device. For table objects there is no further 1018 possibility to discover the row descriptors. For example, consider 1019 there are two MIB objects with descriptors "sysUpTime" and 1020 "ipNetToMediaTable" associated with OID 1.3.6.1.2.1.1.3 and 1021 1.3.6.1.2.1.4.22 1023 REQ: GET example.com/.well-known/core?rt=core.mg.mib 1025 RES: 2.05 Content (Content-Format: application/text) 1026 ;rt="core.mg.mib";oid="1.3.6.1.2.1.1.3";mod="SNMPv2-MIB" 1027 ;rt="core.mg.mib";oid="1.3.6.1.2.1.4.22";mod="ipMIB" 1029 The link format attribute 'oid' is used to associate the name of the 1030 MIB resource with its OID. The OID is written as a string in its 1031 conventional form. 1033 Notice that a MIB variable normally is associated with a descriptor 1034 and an OID. The OID is unique, whereas the descriptor is unique in 1035 combination with the module name. 1037 The "mod", "con", and "rt" attributes can be used to filter resource 1038 queries as specified in [RFC6690]. 1040 6. Trap functions 1042 A trap can be set through the CoAP Observe [I-D.ietf-core-observe] 1043 function. As regular with Observe, the managing entity subscribes to 1044 the variable by sending a GET request with an "Observe" option. 1046 TODO: Observe example 1048 In the registration request, the managing entity MAY include a 1049 "Response-To-Uri-Host" and optionally "Response-To-Uri-Port" option 1050 as defined in [I-D.becker-core-coap-sms-gprs]. In this case, the 1051 observations SHOULD be sent to the address and port indicated in 1052 these options. This can be useful when the managing entity wants the 1053 managed device to send the trap information to a multicast address. 1055 7. MIB access management 1057 Two topics are relevant: (1) the definition of the destination of 1058 Notify messages, and (2) the creation and maintenance of "string to 1059 number" tables. 1061 7.1. Notify destinations 1063 The destination of notifications need to be communicated to the 1064 applications sending them. Draft [I-D.ietf-core-interfaces] 1065 describes the binding of end-points to end-points on remote devices. 1066 The object with type "binding table" contains a sequence of bindings. 1067 The contents of bindings contains the methods, location, the interval 1068 specifications, and the step value as suggested in 1069 [I-D.ietf-core-interfaces]. The method "notify" has been added to 1070 the binding methods "poll", "obs" and "push", to cater for the 1071 binding of notification source to the receiver. 1073 TODO: describe interface for NOTIFY destination definition. 1075 7.2. Conversion tables 1077 POST is used to initialize a conversion table. At the arrival of the 1078 POST, all existing tables are removed and new tables as specified by 1079 the payload are created with the contents specified in the payload. 1080 When the payload of the POST is empty, no table is created. 1082 PUT is used to create new entries in an existing table and overwrite 1083 existing entries. When the payload of the PUT contains a non 1084 existing table, a new table with the new identity is created. When 1085 the payload of the PUT contains a table with an already existing 1086 identifier, two possiblities exist: 1088 exiting string value the contents of the existing pair is 1089 overwritten with the pair in the payload. 1091 new string value A new pair is created in the table with the pair in 1092 the payload. 1094 8. Error handling 1096 In case a request is received which cannot be processed properly, the 1097 managed entity MUST return an error message. This error message MUST 1098 contain a CoAP 4.xx or 5.xx response code, and SHOULD include 1099 additional information in the payload. 1101 Such an error message payload is encoded in CBOR, using the following 1102 structure: 1104 errorMsg : ErrorMsg; 1106 *ErrorMsg { 1107 errorCode : uint; 1108 ?errorText : tstr; 1109 } 1111 The variable "errorCode" has one of the values from the table below, 1112 and the OPTIONAL "errorText" field contains a human readible 1113 explanation of the error. 1115 +----------------+----------------+---------------------------------+ 1116 | CoMI Error | CoAP Error | Description | 1117 | Code | Code | | 1118 +----------------+----------------+---------------------------------+ 1119 | 0 | 4.00 | General error | 1120 | | | | 1121 | 1 | 4.00 | Malformed CBOR data | 1122 | | | | 1123 | 2 | 4.00 | Incorrect CBOR datatype | 1124 | | | | 1125 | 3 | 4.00 | Unknown MIB variable | 1126 | | | | 1127 | 4 | 4.00 | Unknown translation table | 1128 | | | | 1129 | 5 | 4.05 | Attempt to write read-only | 1130 | | | variable | 1131 | | | | 1132 | 0..2 | 5.01 | Access exceptions | 1133 | | | | 1134 | 0..18 | 5.00 | SMI error status | 1135 +----------------+----------------+---------------------------------+ 1137 The CoAP error code 5.01 is associted with the exceptions defined in 1138 [RFC3416] and CoAP error code 5.00 is associated with the error- 1139 status defined in [RFC3416]. 1141 9. Security Considerations 1143 TODO: follows CoAP security provisioning. 1145 10. IANA Considerations 1147 'rt="core.mg.mib"' needs registration with IANA. 1149 Content types to be registered: 1151 o application/comi+json 1153 o application/comi+cbor 1155 11. Acknowledgements 1157 Mehmet Ersue and Bert Wijnen explained the encoding aspects of PDUs 1158 transported under SNMP. Carsten Bormann has given feedback on the 1159 use of CBOR. Juergen Schoenwalder has commented on inconsistencies 1160 and missing aspects of SNMP in earlier versions of the draft. The 1161 draft has benefited from comments by Thomas Watteyne, Dee Denteneer, 1162 Esko Dijk, and Michael van Hartskamp. The CBOR encoding borrows 1163 extensively from Ladislav Lhotka's description on conversion from 1164 YANG to JSON. 1166 12. Changelog 1168 Changes from version 00 to version 01 1170 o Focus on MIB only 1172 o Introduced CBOR, JSON, removed BER 1174 o defined mappings from SMI to xx 1176 o Introduced the concept of addressable table rows 1178 Changes from version 01 to version 02 1180 o Focus on CBOR, used JSON for examples, removed XML and EXI 1182 o added uri-query attributes mod and con to specify modules and 1183 contexts 1185 o Definition of CBOR string conversion tables for data reduction 1187 o use of Block for multiple fragments 1189 o Error returns generalized 1191 o SMI - YANG - CBOR conversion 1193 13. References 1195 13.1. Normative References 1197 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1198 Requirement Levels", BCP 14, RFC 2119, March 1997. 1200 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1201 Network Configuration Protocol (NETCONF)", RFC 6020, 1202 October 2010. 1204 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1205 Representation (CBOR)", RFC 7049, October 2013. 1207 [I-D.becker-core-coap-sms-gprs] 1208 Becker, M., Li, K., Poetsch, T., and K. Kuladinithi, 1209 "Transport of CoAP over SMS", draft-becker-core-coap-sms- 1210 gprs-04 (work in progress), August 2013. 1212 [I-D.ietf-core-block] 1213 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 1214 draft-ietf-core-block-14 (work in progress), October 2013. 1216 [I-D.ietf-core-coap] 1217 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 1218 Application Protocol (CoAP)", draft-ietf-core-coap-18 1219 (work in progress), June 2013. 1221 [I-D.ietf-core-observe] 1222 Hartke, K., "Observing Resources in CoAP", draft-ietf- 1223 core-observe-11 (work in progress), October 2013. 1225 [I-D.ietf-json-rfc4627bis] 1226 Bray, T., "The JSON Data Interchange Format", draft-ietf- 1227 json-rfc4627bis-10 (work in progress), December 2013. 1229 [I-D.lhotka-netmod-yang-json] 1230 Lhotka, L., "Modeling JSON Text with YANG", draft-lhotka- 1231 netmod-yang-json-02 (work in progress), September 2013. 1233 13.2. Informative References 1235 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 1236 for Network Management of TCP/IP-based internets:MIB-II", 1237 STD 17, RFC 1213, March 1991. 1239 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1240 Schoenwaelder, Ed., "Structure of Management Information 1241 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1243 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1244 MIB", RFC 2863, June 2000. 1246 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1247 "Introduction and Applicability Statements for Internet- 1248 Standard Management Framework", RFC 3410, December 2002. 1250 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1251 Architecture for Describing Simple Network Management 1252 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1253 December 2002. 1255 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 1256 (USM) for version 3 of the Simple Network Management 1257 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 1259 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the 1260 Simple Network Management Protocol (SNMP)", STD 62, RFC 1261 3416, December 2002. 1263 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 1264 Simple Network Management Protocol (SNMP)", STD 62, RFC 1265 3418, December 2002. 1267 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1268 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1269 3986, January 2005. 1271 [RFC4088] Black, D., McCloghrie, K., and J. Schoenwaelder, "Uniform 1272 Resource Identifier (URI) Scheme for the Simple Network 1273 Management Protocol (SNMP)", RFC 4088, June 2005. 1275 [RFC4113] Fenner, B. and J. Flick, "Management Information Base for 1276 the User Datagram Protocol (UDP)", RFC 4113, June 2005. 1278 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1279 Architecture", RFC 4291, February 2006. 1281 [RFC4293] Routhier, S., "Management Information Base for the 1282 Internet Protocol (IP)", RFC 4293, April 2006. 1284 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1285 "Transmission of IPv6 Packets over IEEE 802.15.4 1286 Networks", RFC 4944, September 2007. 1288 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1289 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1290 6241, June 2011. 1292 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1293 Security Version 1.2", RFC 6347, January 2012. 1295 [RFC6643] Schoenwaelder, J., "Translation of Structure of Management 1296 Information Version 2 (SMIv2) MIB Modules to YANG 1297 Modules", RFC 6643, July 2012. 1299 [RFC6650] Falk, J. and M. Kucherawy, "Creation and Use of Email 1300 Feedback Reports: An Applicability Statement for the Abuse 1301 Reporting Format (ARF)", RFC 6650, June 2012. 1303 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1304 Format", RFC 6690, August 2012. 1306 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1307 "Neighbor Discovery Optimization for IPv6 over Low-Power 1308 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1309 November 2012. 1311 [I-D.ietf-core-groupcomm] 1312 Rahman, A. and E. Dijk, "Group Communication for CoAP", 1313 draft-ietf-core-groupcomm-18 (work in progress), December 1314 2013. 1316 [I-D.ietf-core-interfaces] 1317 Shelby, Z. and M. Vial, "CoRE Interfaces", draft-ietf- 1318 core-interfaces-01 (work in progress), December 2013. 1320 [I-D.ersue-constrained-mgmt] 1321 Ersue, M., Romascanu, D., and J. Schoenwaelder, 1322 "Management of Networks with Constrained Devices: Problem 1323 Statement, Use Cases and Requirements", draft-ersue- 1324 constrained-mgmt-03 (work in progress), February 2013. 1326 [I-D.schoenw-6lowpan-mib] 1327 Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou, 1328 "Definition of Managed Objects for IPv6 over Low-Power 1329 Wireless Personal Area Networks (6LoWPANs)", draft- 1330 schoenw-6lowpan-mib-03 (work in progress), February 2013. 1332 [I-D.bierman-netconf-restconf] 1333 Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, 1334 "RESTCONF Protocol", draft-bierman-netconf-restconf-02 1335 (work in progress), October 2013. 1337 [STD0001] "Official Internet Protocols Standard", Web 1338 http://www.rfc-editor.org/rfcxx00.html, . 1340 [XML] "Extensible Markup Language (XML)", Web 1341 http://www.w3.org/xml, . 1343 [JSON] "JavaScript Object Notation (JSON)", Web 1344 http://www.json.org, . 1346 Appendix A. Notational Convention for CBOR data 1348 To express CBOR structures [RFC7049], this document uses the 1349 following conventions: 1351 A declaration of a CBOR variable has the form: 1353 name : datatype; 1355 where "name" is the name of the variable, and "datatype" its CBOR 1356 datatype. 1358 The name of the variable has no encoding in the CBOR data. 1360 "datatype" can be a CBOR primitive such as: 1362 tstr: A text string (major type 3) 1364 uint: An unsigned integer (major type 0) 1366 map(x,y): A map (major type 5), where each first element of a pair 1367 is of datatype x, and each second element of datatype y. A '.' 1368 character for either x or y means that all datatypes for that 1369 element are valid. 1371 A datatype can also be a CBOR structure, in which case the variable's 1372 "datatype" field contains the name of the CBOR structure. Such CBOR 1373 structure is defined by a character sequence consisting of first its 1374 name, then a '{' character, then its subfields and finally a '}' 1375 character. 1377 A CBOR structure can be encapsulated in an array, in which case its 1378 name in its definition is preceeded by a '*' character. Otherwise 1379 the structure is just a grouping of fields, but without actual 1380 encoding of such grouping. 1382 The name of an optional field is preceded by a '?' character. This 1383 means, that the field may be omitted if not required. 1385 Authors' Addresses 1387 Peter van der Stok 1388 consultant 1390 Phone: +31-492474673 (Netherlands), +33-966015248 (France) 1391 Email: consultancy@vanderstok.org 1392 URI: www.vanderstok.org 1394 Bert Greevenbosch 1395 Huawei Technologies Co., Ltd. 1396 Huawei Industrial Base 1397 Bantian, Longgang District 1398 Shenzhen 518129 1399 P.R. China 1401 Email: bert.greevenbosch@huawei.com