< draft-vanderstok-core-comi-03.txt		draft-vanderstok-core-comi-04.txt >
	core P. van der Stok		core P. van der Stok
	Internet-Draft consultant		Internet-Draft consultant
	Intended status: Informational B. Greevenbosch		Intended status: Informational B. Greevenbosch
	Expires: August 17, 2014 Huawei Technologies		Expires: November 9, 2014 Huawei Technologies
	February 13, 2014		May 8, 2014
	CoAp Management Interfaces		CoAp Management Interfaces
	draft-vanderstok-core-comi-03		draft-vanderstok-core-comi-04
	Abstract		Abstract
	The draft describes an interface based on CoAP to manage constrained		The draft describes an interface based on CoAP to manage constrained
	devices via MIBs. The proposed integration of CoAP with SNMP reduces		devices via MIBs. The proposed integration of CoAP with SNMP reduces
	the code- and application development complexity by accessing MIBs		the code- and application development complexity by accessing MIBs
	via a standard CoAP server. The payload of the MIB request is CBOR		via a standard CoAP server. The payload of the MIB request is CBOR
	based on JSON. The mapping from SMI to CBOR is specified.		based on JSON. The mapping from SMI to CBOR is specified. The
			introduction motivates the choices of CoMI with respect to
			utilization of YANG, NETCONF, SMI, CBOR, CoAP, and URI structure.
	Note		Note
	Discussion and suggestions for improvement are requested, and should		Discussion and suggestions for improvement are requested, and should
	be sent to core@ietf.org.		be sent to core@ietf.org.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 42 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 17, 2014.		This Internet-Draft will expire on November 9, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Design considerations . . . . . . . . . . . . . . . . . . 4
			1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	2. CoAP Interface . . . . . . . . . . . . . . . . . . . . . . . 5		2. CoAP Interface . . . . . . . . . . . . . . . . . . . . . . . 5
	3. MIB Function Set . . . . . . . . . . . . . . . . . . . . . . 5		3. MIB Function Set . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. SNMP/MIB architecture . . . . . . . . . . . . . . . . . . 5		3.1. SNMP/MIB architecture . . . . . . . . . . . . . . . . . . 6
	3.1.1. SNMP functions . . . . . . . . . . . . . . . . . . . 6		3.1.1. SNMP functions . . . . . . . . . . . . . . . . . . . 7
	3.1.2. MIB structure . . . . . . . . . . . . . . . . . . . . 7		3.1.2. MIB structure . . . . . . . . . . . . . . . . . . . . 7
	3.2. CoMI Function Set . . . . . . . . . . . . . . . . . . . . 8		3.2. CoMI Function Set . . . . . . . . . . . . . . . . . . . . 9
	3.2.1. Single MIB values . . . . . . . . . . . . . . . . . . 9		3.2.1. Single MIB values . . . . . . . . . . . . . . . . . . 10
	3.2.2. multi MIB values . . . . . . . . . . . . . . . . . . 11		3.2.2. multi MIB values . . . . . . . . . . . . . . . . . . 12
	3.2.3. Table row . . . . . . . . . . . . . . . . . . . . . . 13		3.2.3. Table row . . . . . . . . . . . . . . . . . . . . . . 14
	3.2.4. Error returns . . . . . . . . . . . . . . . . . . . . 14		3.2.4. MIB discovery . . . . . . . . . . . . . . . . . . . . 15
	4. Mapping SMI to CoMI payload . . . . . . . . . . . . . . . . . 14		3.2.5. Error returns . . . . . . . . . . . . . . . . . . . . 16
	4.1. Mapping strings to CBOR . . . . . . . . . . . . . . . . . 15		4. Mapping SMI to CoMI payload . . . . . . . . . . . . . . . . . 16
	4.2. Mapping SMI to CBOR . . . . . . . . . . . . . . . . . . . 16		4.1. CBOR format for MIB data . . . . . . . . . . . . . . . . 16
	4.2.1. General overview . . . . . . . . . . . . . . . . . . 16		4.2. Table generation . . . . . . . . . . . . . . . . . . . . 17
	4.2.2. Conversion from YANG datatypes to CBOR datatypes . . 16		4.3. Mapping SMI to CBOR . . . . . . . . . . . . . . . . . . . 18
	4.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 18		4.3.1. General overview . . . . . . . . . . . . . . . . . . 18
	4.2.4. 6LoWPAN MIB . . . . . . . . . . . . . . . . . . . . . 20		4.3.2. Conversion from YANG datatypes to CBOR datatypes . . 18
	5. MIB discovery . . . . . . . . . . . . . . . . . . . . . . . . 23		4.3.3. Examples . . . . . . . . . . . . . . . . . . . . . . 20
	6. Trap functions . . . . . . . . . . . . . . . . . . . . . . . 24		4.3.4. 6LoWPAN MIB . . . . . . . . . . . . . . . . . . . . . 22
	7. MIB access management . . . . . . . . . . . . . . . . . . . . 24		5. Trap functions . . . . . . . . . . . . . . . . . . . . . . . 23
	7.1. Notify destinations . . . . . . . . . . . . . . . . . . . 24		6. MIB access management . . . . . . . . . . . . . . . . . . . . 23
	7.2. Conversion tables . . . . . . . . . . . . . . . . . . . . 25		6.1. Notify destinations . . . . . . . . . . . . . . . . . . . 23
	8. Error handling . . . . . . . . . . . . . . . . . . . . . . . 25		6.2. Conversion table management . . . . . . . . . . . . . . . 23
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 26		7. Error handling . . . . . . . . . . . . . . . . . . . . . . . 24
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
	12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 27		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28		11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	13.1. Normative References . . . . . . . . . . . . . . . . . . 28		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
	13.2. Informative References . . . . . . . . . . . . . . . . . 29		12.1. Normative References . . . . . . . . . . . . . . . . . . 27
	Appendix A. Notational Convention for CBOR data . . . . . . . . 31		12.2. Informative References . . . . . . . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32		Appendix A. Notational Convention for CBOR data . . . . . . . . 30
			Appendix B. Example conversion table and instance for the LOWPAN
			MIB . . . . . . . . . . . . . . . . . . . . . . . . 31
			B.1. Generating the convTableId . . . . . . . . . . . . . . . 31
			B.2. Generating the string numbers . . . . . . . . . . . . . . 31
			B.3. Example instance . . . . . . . . . . . . . . . . . . . . 35
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
	1. Introduction		1. Introduction
	The Constrained RESTful Environments (CoRE) working group aims at		The Constrained RESTful Environments (CoRE) working group aims at
	Machine to Machine (M2M) applications such as smart energy and		Machine to Machine (M2M) applications such as smart energy and
	building control.		building control.
	Small M2M devices need to be managed in an automatic fashion to		Small M2M devices need to be managed in an automatic fashion to
	handle the large quantities of devices that are expected to be		handle the large quantities of devices that are expected to be
	installed in future installations. The management protocol of choice		installed in future installations. The management protocol of choice
	skipping to change at page 3, line 37 ¶		skipping to change at page 3, line 42 ¶
	standardized data-sets in a stateless client-server fashion and is		standardized data-sets in a stateless client-server fashion and is
	thus closer to SNMP than to NETCONF. Standardized data sets promote		thus closer to SNMP than to NETCONF. Standardized data sets promote
	interoperability between small devices and applications from		interoperability between small devices and applications from
	different manufacturers. Stateless communication is encouraged to		different manufacturers. Stateless communication is encouraged to
	keep communications simple and the amount of state information small		keep communications simple and the amount of state information small
	in line with the design objectives of 6lowpan [RFC4944] [RFC6775],		in line with the design objectives of 6lowpan [RFC4944] [RFC6775],
	RPL [RFC6650], and CoAP [I-D.ietf-core-coap].		RPL [RFC6650], and CoAP [I-D.ietf-core-coap].
	The draft [I-D.bierman-netconf-restconf] describes a restful		The draft [I-D.bierman-netconf-restconf] describes a restful
	interface to NETCONF data stores and approaches the CoMI approach.		interface to NETCONF data stores and approaches the CoMI approach.
	CoMI uses SMI encoded in CBOR, and CoAP/UDP to access MIBs, where		CoMI uses SMI encoded in CBOR, and CoAP/UDP to access MIBs, whereas
	restconf uses YANG encoded in JSON and HTTP/TCP to access NETCONF		RESTCONF uses YANG encoded in JSON and HTTP/TCP to access NETCONF
	data stores. CoMI is more low resource oriented than restconf is.		data stores. CoMI is more low resource oriented than RESTCONF is,
			and only supports the methods GET, PUT, POST and DELETE. RESTCONF
			also uses uses the HTTP methods HEAD, OPTIONS and PATCH, which are
			not available in CoAP.
			Given the automatic conversion from SMI to YANG, from YANG to JSON,
			from YANG to XML and from JSON to CBOR, the transported data format
			is not strongly related to the chosen management protocol.
	Currently, managed devices need to support two protocols: CoAP and		Currently, managed devices need to support two protocols: CoAP and
	SNMP. When the MIB can be accessed with the CoAP protocol, the SNMP		SNMP. When the MIB can be accessed with the CoAP protocol, the SNMP
	protocol can be replaced with the CoAP protocol. This arrangement		protocol can be replaced with the CoAP protocol. This arrangement
	reduces the code complexity of the stack in the constrained device,		reduces the code complexity of the stack in the constrained device,
	and harmonizes applications development.		and harmonizes applications development.
	The objective of CoMI is to provide a CoAP based Function Set that		The objective of CoMI is to provide a CoAP based Function Set that
	reads and sets values of MIB variables in devices to (1) initialize		reads and sets values of MIB variables in devices to (1) initialize
	parameter values at start-up, (2) acquire statistics during		parameter values at start-up, (2) acquire statistics during
	operation, and (3) maintain nodes by adjusting parameter values		operation, and (3) maintain nodes by adjusting parameter values
	during operation.		during operation.
	The payload of CoMI is encoded in CBOR [RFC7049] which similar to		The payload of CoMI is encoded in CBOR [RFC7049] which is similar to
	JSON [JSON], but has a binary format and hence has more coding		JSON [JSON], but has a binary format and hence has more coding
	efficiency. CoMI is intended for small devices. The JSON overhead		efficiency. CoMI is intended for small devices. The JSON overhead
	can be prohibitive. It is therefore chosen to transport CBOR in the		can be prohibitive. It is therefore chosen to transport CBOR in the
	payload. CBOR, like BER used for SNMP, transports the data type in		payload. CBOR, like BER used for SNMP, transports the data type in
	the payload.		the payload.
	The end goal of CoMI is to provide information exchange over the CoAP		The end goal of CoMI is to provide information exchange over the CoAP
	transport protocol in a uniform manner to approach the full		transport protocol in a uniform manner as a first step to the full
	management functionality as specified in		management functionality as specified in
	[I-D.ersue-constrained-mgmt].		[I-D.ersue-constrained-mgmt].
	1.1. Terminology		1.1. Design considerations
			COMI supports discovery of resources, accompanied by reading, writing
			and notification of resource values. As such it is close to the
			device management of the Open Mobile Alliance described in [OMA].
			However, the structure of the MIB does not reflect the structure of
			the OMA management objects. It is assumed that the structure and
			semantics of the management data are the most important aspect of a
			standard like the MIB. The right path forward to integrate OMA
			management with COMI is the adapatation of the MIB structure by OMA.
			COMI supports the conversion of SMIv2 via YANG to CBOR. Assuming
			that CBOR is used for the tanport of NETCONF data, the utilization of
			the CBOR conversion table to reduce payload size can be envisaged for
			NETCONF data as well.
			COMI uses a simple URI to access the MIB resources. Complexity
			introduced by module name, context specification, or row selection,
			is expressed with uri-query attributes. The choice for uri-query
			attributes makes the uri structure less context dependent.
			1.2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Readers of this specification are required to be familiar with all		Readers of this specification are required to be familiar with all
	the terms and concepts discussed in [RFC3410], [RFC3416], and		the terms and concepts discussed in [RFC3410], [RFC3416], and
	[RFC2578].		[RFC2578].
	Core Management Interface (CoMI) specifies the profile of Function		Core Management Interface (CoMI) specifies the profile of Function
	skipping to change at page 5, line 17 ¶		skipping to change at page 5, line 49 ¶
	In CoRE a group of links can constitute a Function Set. The format of		In CoRE a group of links can constitute a Function Set. The format of
	the links is specified in [I-D.ietf-core-interfaces]. This note		the links is specified in [I-D.ietf-core-interfaces]. This note
	specifies a Management Function Set. CoMI end-points that implement		specifies a Management Function Set. CoMI end-points that implement
	the CoMI management protocol support at least one discoverable		the CoMI management protocol support at least one discoverable
	management resource of resource type (rt): core.mg, with path: /mg,		management resource of resource type (rt): core.mg, with path: /mg,
	where mg is short-hand for management. The mg resource has two sub-		where mg is short-hand for management. The mg resource has two sub-
	resources accessible with the paths:		resources accessible with the paths:
	o MIB with path /mg/mib and a CBOR content format.		o MIB with path /mg/mib and a CBOR content format.
	o XLAT with path /mg/xlat and CBOR content format.		o conv with path /mg/conv and CBOR content format.
	The mib resource provides access to the MIBs as described in		The mib resource provides access to the MIBs as described in
	Section 3.2. The xlat resource provides access to a string to CBOR		Section 3.2. The conv resource provides access to a table that maps
	identifier table as described in Section 4.1. The mib and xlat		a string to CBOR identifier, as described in Section 4.1. The mib
	resources are introduced as sub resources to mg to permit later		and conv resources are introduced as sub resources to mg to permit
	additions to CoMI mg resource.		later additions to CoMI mg resource.
	The profile of the management function set, with IF=core.mg.mib, is		The profile of the management function set, with IF=core.mg.mib, is
	shown in the table below, following the guidelines of		shown in the table below, following the guidelines of
	[I-D.ietf-core-interfaces]:		[I-D.ietf-core-interfaces]:
	+-----------------+-----------+---------------+-------------------+		+-----------------+-----------+---------------+-------------------+
	| name | path | RT | Data Type |		| name | path | RT | Data Type |
	+-----------------+-----------+---------------+-------------------+		+-----------------+-----------+---------------+-------------------+
	| Management | /mg | core.mg | n/a |		| Management | /mg | core.mg | n/a |
	| | | | |		| | | | |
	| MIB | /mg/mib | core.mg.mib | application/cbor |		| MIB | /mg/mib | core.mg.mib | application/cbor |
	| | | | |		| | | | |
	| XLAT | /mg/xlat | core.mg.xlat | application/cbor |		| conv | /mg/conv | core.mg.conv | application/cbor |
	+-----------------+-----------+---------------+-------------------+		+-----------------+-----------+---------------+-------------------+
	3. MIB Function Set		3. MIB Function Set
	The MIB Function Set provides a CoAP interface to perform equivalent		The MIB Function Set provides a CoAP interface to perform equivalent
	functions to the ones provided by SNMP. Section 3.1 explains the		functions to the ones provided by SNMP. Section 3.1 explains the
	structure of SNMP Protocol Data Units (PDU), their transport, and the		structure of SNMP Protocol Data Units (PDU), their transport, and the
	structure of the MIB modules. An excellent overview of the documents		structure of the MIB modules. An excellent overview of the documents
	describing the SNMP/MIB architecture is provided in section 7 of		describing the SNMP/MIB architecture is provided in section 7 of
	[RFC3410].		[RFC3410].
	skipping to change at page 7, line 11 ¶		skipping to change at page 7, line 42 ¶
	o Set Request, transmits a list of (OBJECT-IDENTIFIERs, value) pairs		o Set Request, transmits a list of (OBJECT-IDENTIFIERs, value) pairs
	to be set in the specified MIB object.		to be set in the specified MIB object.
	o Trap, sends an unconfirmed message with a list of (OBJECT-		o Trap, sends an unconfirmed message with a list of (OBJECT-
	IDENTIFIERs, value) pairs to a notification requesting end-point.		IDENTIFIERs, value) pairs to a notification requesting end-point.
	o Inform Request, sends a confirmed message with a list of (OBJECT-		o Inform Request, sends a confirmed message with a list of (OBJECT-
	IDENTIFIERs, value) pairs to a notification requesting end-point.		IDENTIFIERs, value) pairs to a notification requesting end-point.
	The binding of the notification to a destination is discussed in
	Section 6.
	3.1.2. MIB structure		3.1.2. MIB structure
	A MIB module is composed of MIB objects. MIB objects are		A MIB module is composed of MIB objects. MIB objects are
	standardized by the IETF or by other relevant Standards Developing		standardized by the IETF or by other relevant Standards Developing
	Organizations (SDO).		Organizations (SDO).
	MIB objects have a descriptor and an identifier: OBJECT-IDENTIFIER		MIB objects have a descriptor and an identifier: OBJECT-IDENTIFIER
	(OID). The identifier, following the OSI hierarchy, is an ordered		(OID). The identifier, following the OSI hierarchy, is an ordered
	list of non-negative numbers [RFC2578]. OID values are unique. Each		list of non-negative numbers [RFC2578]. OID values are unique. Each
	number in the list is referred as a sub-identifier. The descriptor		number in the list is referred as a sub-identifier. The descriptor
	skipping to change at page 8, line 37 ¶		skipping to change at page 9, line 37 ¶
	ipv6InterfaceIdentifier Ipv6AddressIfIdentifierTC,		ipv6InterfaceIdentifier Ipv6AddressIfIdentifierTC,
	ipv6InterfaceEnableStatus INTEGER,		ipv6InterfaceEnableStatus INTEGER,
	ipv6InterfaceReachableTime Unsigned32,		ipv6InterfaceReachableTime Unsigned32,
	ipv6InterfaceRetransmitTime Unsigned32,		ipv6InterfaceRetransmitTime Unsigned32,
	ipv6InterfaceForwarding INTEGER		ipv6InterfaceForwarding INTEGER
	}		}
	The descriptor (name) of the MIB table is used for the name of the		The descriptor (name) of the MIB table is used for the name of the
	CoMI variable. However, there is no explicit mention of the names		CoMI variable. However, there is no explicit mention of the names
	"ipv6InterfaceEntry" and "Ipv6InterfaceEntry". Instead, the value of		"ipv6InterfaceEntry" and "Ipv6InterfaceEntry". Instead, the value of
	the main CoMI variable consists of an array, each element of which		the main CoMI variable, ipv6InterfaceTable, consists of an array,
	contains 7 CoMI variables: one element for "ipv6InterfaceIfIndex",		each element of which contains 7 CoMI variables: one element for
	one for "ipv6InterfaceReasmMaxSize" and so on until		"ipv6InterfaceIfIndex", one for "ipv6InterfaceReasmMaxSize" and so on
	"ipv6InterfaceForwarding".		until "ipv6InterfaceForwarding".
	3.2. CoMI Function Set		3.2. CoMI Function Set
	Two types of interfaces are supported by CoMI:		Three types of interfaces are supported by CoMI:
	single value Reading/Writing one MIB variable, specified in the URI		Single value: Reading/Writing one MIB variable, specified in the URI
	with path /mg/mib/descriptor or with path /mg/mib/OID.		with path /mg/mib/descriptor or with path /mg/mib/OID.
	multiple values Reading writing arrays or multiple MIB variables,		Multiple values: Reading writing arrays or multiple MIB variables,
	specified in the payload.		specified in the payload.
			Discovery: Discovery of MIB descriptors as specified in [RFC6690].
	The examples in this section use a JSON payload with one or more		The examples in this section use a JSON payload with one or more
	entries describing the pair (descriptor, value), or (OID, value).		entries describing the pair (descriptor, value), or (OID, value).
			CoMI transports the CBOR format to transport the equivalent contents.
	The CBOR syntax of the payloads is specified in Section 4.		The CBOR syntax of the payloads is specified in Section 4.
	3.2.1. Single MIB values		3.2.1. Single MIB values
	A request to read the value of a MIB variable is sent with a		A request to read the value of a MIB variable is sent with a
	confirmable CoAP GET message. The single MIB variable is specified		confirmable CoAP GET message. The single MIB variable is specified
	in the URI path with the OID or descriptor suffixing the /mg/mib/		in the URI path with the OID or descriptor suffixing the /mg/mib/
	path name. When the descriptor is used to specify the MIB value, the		path name. When the descriptor is used to specify the MIB value, the
	same descriptor may be present in multiple module. To disambiguate		same descriptor may be present in multiple module. To disambiguate
	the descriptor the "mod" uri-query attribute specifies the enveloping		the descriptor the "mod" uri-query attribute specifies the enveloping
	skipping to change at page 9, line 28 ¶		skipping to change at page 10, line 31 ¶
	confirmable CoAP PUT message. The Response is piggybacked to the		confirmable CoAP PUT message. The Response is piggybacked to the
	CoAP ACK message corresponding with the Request.		CoAP ACK message corresponding with the Request.
	TODO: for multicast send unconfirmed PUT		TODO: for multicast send unconfirmed PUT
	Using for example the same MIB from [RFC1213] as used in [RFC3416], a		Using for example the same MIB from [RFC1213] as used in [RFC3416], a
	request is sent to retrieve the value of sysUpTime specified in		request is sent to retrieve the value of sysUpTime specified in
	module SNMPv2-MIB. The answer to the request returns a (descriptor,		module SNMPv2-MIB. The answer to the request returns a (descriptor,
	value) pair.		value) pair.
	For clarity of the examples, in this and all following examples the		As announced, in all examples the payload is expressed in JSON,
	payload is expressed in JSON, although the operational payload is		although the operational payload is specified to be in CBOR.
	specified to be in CBOR, as described in Section 4.
	REQ: GET example.com/mg/mib/sysUpTime?mod=SNMPv2-MIB		REQ: GET example.com/mg/mib/sysUpTime?mod=SNMPv2-MIB
	RES: 2.05 Content (Content-Format: application/json)		RES: 2.05 Content (Content-Format: application/json)
	{		{
	"sysUpTime" : 123456		"sysUpTime" : 123456
	}		}
	Another way to express the descriptor of the required value is by		Another way to express the descriptor of the required value is by
	specifying the pair (descriptor or oid, null value) in the payload of		specifying the pair (descriptor or oid, null value) in the payload of
	skipping to change at page 11, line 52 ¶		skipping to change at page 12, line 52 ¶
	Notice that the Block mechanism splits the data at fixed positions,		Notice that the Block mechanism splits the data at fixed positions,
	such that individual data fields may become fragmented. Therefore,		such that individual data fields may become fragmented. Therefore,
	assembly of multiple blocks may be required to process the complete		assembly of multiple blocks may be required to process the complete
	data field.		data field.
	3.2.2. multi MIB values		3.2.2. multi MIB values
	A request to read multiple MIB variables is done by expressing the		A request to read multiple MIB variables is done by expressing the
	pairs (MIB descriptor, null) in the payload of the GET request		pairs (MIB descriptor, null) in the payload of the GET request
	message. A request to set multiple MIB variables is done by		message. A request to set multiple MIB variables is done by
	expressing the pairs (MIB descriptor, null value) in the payload of		expressing the pairs (MIB descriptor, value) in the payload of the
	the PUT request message. The key word _multiMIB is used as array		PUT request message. The key word _multiMIB is used as array name to
	name to signal that the payload contains multiple MIB values as		signal that the payload contains multiple MIB values as separate
	separate _multiMIB array entries.		_multiMIB array entries.
	The following example shows a request that specifies to return the		The following example shows a request that specifies to return the
	values of sysUpTime and ipNetToMediaTable:		values of sysUpTime and ipNetToMediaTable:
	REQ: GET example.com/mg/mib (Content-Format: application/json)		REQ: GET example.com/mg/mib (Content-Format: application/json)
	{		{
	"_multiMIB" : [		"_multiMIB" : [
	{ "sysUpTime" : "null"},		{ "sysUpTime" : "null"},
	{ "ipNetToMediaTable" : "null" }		{ "ipNetToMediaTable" : "null" }
	]		]
	skipping to change at page 14, line 35 ¶		skipping to change at page 15, line 35 ¶
	Constrained devices MAY support this kind of filtering. However, if		Constrained devices MAY support this kind of filtering. However, if
	they don't support it, they MUST ignore the payload in the GET		they don't support it, they MUST ignore the payload in the GET
	request and handle the message as if the payload was empty.		request and handle the message as if the payload was empty.
	It is advised to keep MIBs for constrained entities as simple as		It is advised to keep MIBs for constrained entities as simple as
	possible, and therefore it would be best to avoid extensive tables.		possible, and therefore it would be best to avoid extensive tables.
	TODO: Describe how the contents of the next lexicographical row can		TODO: Describe how the contents of the next lexicographical row can
	be returned.		be returned.
	3.2.4. Error returns		3.2.4. MIB discovery
			MIB objects are discovered like resources with the standard CoAP
			resource discovery. Performing a GET on "/.well-known/core" with
			rt=core.mg.mib returns all MIB descriptors and all OIDs which are
			available on this device. For table objects there is no further
			possibility to discover the row descriptors. For example, consider
			there are two MIB objects with descriptors "sysUpTime" and
			"ipNetToMediaTable" associated with OID 1.3.6.1.2.1.1.3 and
			1.3.6.1.2.1.4.22
			REQ: GET example.com/.well-known/core?rt=core.mg.mib
			RES: 2.05 Content (Content-Format: application/text)
			</mg/mib/sysUpTime>;rt="core.mg.mib";oid="1.3.6.1.2.1.1.3";
			mod="SNMPv2-MIB"
			</mg/mib/ipNetToMediaTable>;rt="core.mg.mib";oid="1.3.6.1.2.1.4.22";
			mod="ipMIB"
			The link format attribute 'oid' is used to associate the name of the
			MIB resource with its OID. The OID is written as a string in its
			conventional form.
			Notice that a MIB variable normally is associated with a descriptor
			and an OID. The OID is unique, whereas the descriptor is unique in
			combination with the module name.
			The "mod", "con", and "rt" attributes can be used to filter resource
			queries as specified in [RFC6690].
			3.2.5. Error returns
	When a variable with the specified name cannot be processed, CoAP		When a variable with the specified name cannot be processed, CoAP
	Error code 5.01 is returned. In addition, a MIB specific error can		Error code 5.01 is returned. In addition, a MIB specific error can
	be returned in the payload as specified in Section 8.		be returned in the payload as specified in Section 7.
	4. Mapping SMI to CoMI payload		4. Mapping SMI to CoMI payload
	The SMI syntax is mapped to CBOR necessary for the transport of MIB		The SMI syntax is mapped to CBOR necessary for the transport of MIB
	data in the CoAP payload. This section first describes an additional		data in the CoAP payload. This section first describes an additional
	data reduction technique by creating a table that maps string values		data reduction technique by creating a table that maps string values
	to numbers used in CBOR encoded data.		to numbers used in CBOR encoded data.
	The section continues by describing the mapping from SMI to CBOR.		The section continues by describing the mapping from SMI to CBOR.
	The mapping is inspired by the mapping from SMI to JSON via YANG		The mapping is inspired by the mapping from SMI to JSON via YANG
	[RFC6020], as described in [RFC6643] defining a mapping from SMI to		[RFC6020], as described in [RFC6643] defining a mapping from SMI to
	YANG, and [I-D.lhotka-netmod-yang-json] defining a mapping from YANG		YANG, and [I-D.lhotka-netmod-yang-json] defining a mapping from YANG
	to JSON.		to JSON.
	Notice that such conversion chain MAY be virtual only, as SMI could		Notice that such conversion chain MAY be virtual only, as SMI could
	be converted directly to JSON by combining the rules from the above		be converted directly to JSON by combining the rules from the above
	documents.		documents.
	4.1. Mapping strings to CBOR		4.1. CBOR format for MIB data
	Because descriptors may be rather long and may occur repeatedly, CoMI		Because descriptors may be rather long and may occur repeatedly, CoMI
	allows for association of a string with an integer, henceforth called		allows for association of a given string value with an integer,
	"string number". The association between string and string number is		henceforth called "string number". The association between string
	done through a translation table, leveraging CBOR encoding.		value and string number is done through a conversion table,
			leveraging CBOR encoding. Section 4.2 defines how the conversion
			table is generated.
	Using the notational convention from Appendix A, the CBOR data has		Using the notational convention from Appendix A, the CBOR data has
	the following syntax:		the following syntax:
	cBorMIB : CBorMIB;		cBorMIB : CBorMIB;
	*CBorMIB {		*CBorMIB {
	xlatTableID : uint;		convTableId : tstr;
	mibString : map( uint, . );		mibData : map( uint, . );
	}		}
	The main structure consist of an array of two elements: "xlatTableID"		The main structure consist of an array of two elements: "convTableId"
	and "mibString".		and "mibData".
	The values of the MIB strings are stored in the "mibString" field.		The conversion table identifier "convTableId" is constructed from the
			LAST_UPDATED attribute and module name as defined in Section 4.2.
			The values of the MIB variables are stored in the "mibData" field.
	This field consist of integer-value pairs. The integers correspond		This field consist of integer-value pairs. The integers correspond
	to the string numbers, whereas the values contain the actual value of		to the string numbers, whereas the values contain the actual value of
	the associated string.		the associated MIB variable. Section 4.3 elaborates on the mapping
			from SMI to CBOR.
	The "xlatTableID" contains an integer that is used to indentify the		4.2. Table generation
	translation table. The translation table can be acquired as follows:
	GET /mg/xlat/[xlatTableID]		The conversion table contents MUST be automatically generated from
			the MIB module as specified in this section. Automatic generation in
			the managed device removes the need to transport the tables and
			subsequently store them in the nodes, and avoids a cumbersome
			management of the conversion tables.
	where "[xlatTableID]" is replaced by the the value of xlatId from the		The conversion table identifier "convTableId" is generated from the
	CBorMIB structure, encoded as a hexidecimal integer without leading		LAST-UPDATED field in the MODULE IDENTITY macro, and the module name
	zeros.		as follows:
	The maintenance of the table is described in Section 7.2.		convTableId = moduleName UNDERSCORE lastUpdateTimestamp
			UNDERSCORE = %x5F
	The use of the table is to initialize devices with the strings which		where moduleName is the module name, and lastUpdateTimestamp is the
	will be frequently used, such as the strings of the descriptors in		value of the related LAST-UPDATED field in the MODULE-IDENTITY macro,
	the MIB variables. The transmitted CBOR data will contain the string		using the format with four year digits as defined in [RFC2578].
	numbers and not the entire descriptor strings, leading to appreciable
	data reduction.
	It is important that sender and receiver have identical versions of		The conversion table is generated using the following algorithm:
	the table.
	The translation table is serialized to the payload in the following		1. Collect all used OIDs/descriptors defined in the MIB object, and
	fashion:		as well as those imported using IMPORTS.
	xlatTable : XLatTable;		2. Sort the collection of OIDs according to the following rules:
	*XLatTable {		1. x.y.z < x.y.z.k
	xlatId : uint;
	xlatData : map( uint, tstr );
	}
	where "xlatId" has the same value as "xlatId" in the CBorMIB		2. x.y.z... < x.y.k... if z<k
	structure, and "xlatData" is a CBOR map between the string number and
	associated variable descriptor.
	4.2. Mapping SMI to CBOR		3. Assign the string numbers to the sorted list of OIDs, in
			numerical order starting with 1.
	4.2.1. General overview		Note that variables imported with IMPORTS could be tables, such that
			the OIDs of the table entries need to be included in the collection
			of OIDs as well.
			4.3. Mapping SMI to CBOR
			4.3.1. General overview
	Starting from the intermediate conversion from SMI to YANG as defined		Starting from the intermediate conversion from SMI to YANG as defined
	in [RFC6643], This section defines how to convert the resulting YANG		in [RFC6643], This section defines how to convert the resulting YANG
	structure to CBOR [RFC7049]. The actual conversion code from SMI to		structure to CBOR [RFC7049]. The actual conversion code from SMI to
	YANG and subsequently YANG to CBOR MAY be direct conversion code from		CBOR MAY be direct conversion code from SMI to CBOR or a sequence of
	SMI to CBOR or a sequence of existing SMI to YANG conversion code		existing SMI to YANG conversion code followed by YANG to CBOR
	followed by YANG to CBOR conversion code.		conversion code.
	4.2.2. Conversion from YANG datatypes to CBOR datatypes		4.3.2. Conversion from YANG datatypes to CBOR datatypes
	Table 1 defines the mapping between YANG datatypes and CBOR		Table 1 defines the mapping between YANG datatypes and CBOR
	datatypes.		datatypes.
	Elements of types not in this table, and of which the type cannot be		Elements of types not in this table, and of which the type cannot be
	inferred from a type in this table, are ignored in the CBOR encoding		inferred from a type in this table, are ignored in the CBOR encoding
	by default. Examples include the "description" and "key" elements.		by default. Examples include the "description" and "key" elements.
	However, conversion rules for some elements to CBOR MAY be defined		However, conversion rules for some elements to CBOR MAY be defined
	elsewhere.		elsewhere.
	skipping to change at page 18, line 16 ¶		skipping to change at page 20, line 5 ¶
	| | | the container. |		| | | the container. |
	| | | |		| | | |
	| smiv2:oid | array of | Each integer contains an element |		| smiv2:oid | array of | Each integer contains an element |
	| | integers | of the OID, the first integer in |		| | integers | of the OID, the first integer in |
	| | | the array corresponds to the |		| | | the array corresponds to the |
	| | | most left element in the OID. |		| | | most left element in the OID. |
	+-------------+------------------+----------------------------------+		+-------------+------------------+----------------------------------+
	Table 1: Conversion of YANG datatypes to CBOR		Table 1: Conversion of YANG datatypes to CBOR
	4.2.3. Examples		4.3.3. Examples
	4.2.3.1. ipNetToMediaTable to JSON/CBOR		4.3.3.1. ipNetToMediaTable to JSON/CBOR
	The YANG translation of the SMI specifying the		The YANG translation of the SMI specifying the
	ipNetToMediaTable yields:		ipNetToMediaTable yields:
	container ipNetToMediaTable {		container ipNetToMediaTable {
	list ipNetToMediaEntry {		list ipNetToMediaEntry {
	leaf ipNetToMediaIfIndex {		leaf ipNetToMediaIfIndex {
	type: int32;		type: int32;
	}		}
	leaf ipNetToPhysAddress {		leaf ipNetToPhysAddress {
	skipping to change at page 19, line 23 ¶		skipping to change at page 21, line 4 ¶
	},		},
	{		{
	"ipNetToMediaIfIndex " : 1,		"ipNetToMediaIfIndex " : 1,
	"ipNetToMediaPhysAddress " : "00:00::10:54:32:10",		"ipNetToMediaPhysAddress " : "00:00::10:54:32:10",
	"ipNetToMediaNetAddress" : "9.2.3.4",		"ipNetToMediaNetAddress" : "9.2.3.4",
	"ipNetToMediaType " : "dynamic"		"ipNetToMediaType " : "dynamic"
	}		}
	]		]
	}		}
	}		}
	An example CBOR instance of the MIB can be found in Figure 1. The		An example CBOR instance of the MIB can be found in Figure 1. The
	names "ipNetToMediaTable", "ipNetToMediaEntry", and		names "ipNetToMediaTable", "ipNetToMediaEntry", and
	"ipNetToMediaIfIndex" are represented with the string numbers 00, 01,		"ipNetToMediaIfIndex" are represented with the string numbers 00, 01,
	and 02 as described in Section 4.1.		and 02 as described in Section 4.1.
	82 # two element array		82 # two element array
	19 43 A1 # translation table ID 43A1		74 49 50 2d 4d 49 42 5f
			32 30 30 36 30 32 30 32
			30 30 30 30 5a # "IP-MIB_200602020000Z"
	BF # indefinite length map		BF # indefinite length map
	00 # descriptor number related to		00 # descriptor number related to
	# ipNetToMediaTable		# ipNetToMediaTable
	BF # indefinite length map related to		BF # indefinite length map related to
	# ipNetToMediaTable		# ipNetToMediaTable
	01 # descriptor number related to		01 # descriptor number related to
	# ipNetToMediaEntry		# ipNetToMediaEntry
	BF # map related to ipNetToMediaEntry		BF # map related to ipNetToMediaEntry
	02 # descriptor number associated with		02 # descriptor number associated with
	# ipNetToMediaIfIndex		# ipNetToMediaIfIndex
	1A 00 00 00 01 # associated value as 32-bit integer		1A 00 00 00 01 # associated value as 32-bit integer
	# ...		# ...
	FF		FF
	FF		FF
	FF		FF
	Figure 1: Example CBOR encoding for ifTable		Figure 1: Example CBOR encoding for ifTable
	The associated "descriptor string" to "string number" translation		The associated "descriptor string" to "string number" conversion
	table is given in Figure 2.		table is given in Figure 2.
	82 # two element array		82 # two element array
	19 43 A1 # translation table ID 43A1		74 49 50 2d 4d 49 42 5f
			32 30 30 36 30 32 30 32
			30 30 30 30 5a # "IP-MIB_200602020000Z"
	BF # indefinite length map		BF # indefinite length map
	00 # descriptor number related to		00 # descriptor number related to
	# ipNetToMediaTable		# ipNetToMediaTable
	72 69 70 50 65 74 57		72 69 70 50 65 74 57
	6F 51 65 64 61 57 61		6F 51 65 64 61 57 61
	62 6C 65 # "ipNetToMediaTable"		62 6C 65 # "ipNetToMediaTable"
	01 # descriptor number related to		01 # descriptor number related to
	# ipNetToMediaEntry		# ipNetToMediaEntry
	72 69 70 50 65 74 57		72 69 70 50 65 74 57
	6F 51 65 64 61 45 6E		6F 51 65 64 61 45 6E
	74 72 78 # "ipNetToMediaEntry"		74 72 78 # "ipNetToMediaEntry"
	02 # descriptor number related to		02 # descriptor number related to
	# ipNetToMediaIfIndex		# ipNetToMediaIfIndex
	75 69 70 50 65 74 57		75 69 70 50 65 74 57
	6F 51 65 64 61 61 49		6F 51 65 64 61 61 49
	66 49 6E 64 65 77 # "ipNetToMediaIfIndex"		66 49 6E 64 65 77 # "ipNetToMediaIfIndex"
	# ...		# ...
	FF		FF
	Figure 2: Translation table for ifTable		Figure 2: Conversion table for ifTable
	4.2.4. 6LoWPAN MIB
	A MIB for 6LoWPAN is defined in [I-D.schoenw-6lowpan-mib]. The
	document also provides an example JSON representation in its
	Appendix A. Figure 3 shows the associated CBOR representation with
	string number, and Figure 4 shows the corresponding string to string
	number conversion table.
	82 # two element array
	1A 8B 47 88 F3 # translation table ID 8B4788F3
	BF # indefinite length map
	00 # "LOWPAN-MIB:LOWPAN-MIB"
	BF # indefinite length map related to ifTable
	01 # "lowpanReasmTimeout"
	14 # 20
	02 # "lowpanInReceives"
	18 2A # 42
	03 # "lowpanInHdrErrors"
	00 # 0
	04 # "lowpanInMeshReceives"
	08 # 8
	05 # "lowpanInMeshForwds"
	00 # 0
	06 # "lowpanInMeshDelivers"
	00 # 0
	07 # "lowpanInReasmReqds"
	16 # 22
	08 # "lowpanInReasmFails"
	02 # 02
	09 # "lowpanInReasmOKs"
	14 # 20
	0A # "lowpanInCompReqds"
	10 # 16
	0B # "lowpanInCompFails"
	02 # 2
	0C # "lowpanInCompOKs"
	0E # 14
	0D # "lowpanInDiscards"
	01 # 01
	0E # "lowpanInDelivers"
	0C # 12
	0F # "lowpanOutRequests"
	0C # 12
	10 # "lowpanOutCompReqds"
	00 # 0
	11 # "lowpanOutCompFails"
	00 # 0
	12 # "lowpanOutCompOKs"
	00 # 0
	13 # "lowpanOutFragReqds"
	05 # 5
	14 # "lowpanOutFragFails"
	00 # 0
	15 # "lowpanOutFragOKs"
	05 # 5
	16 # "lowpanOutFragCreates"
	08 # 8
	17 # "lowpanOutMeshHopLimitExceeds"
	00 # 0
	18 18 # "lowpanOutMeshNoRoutes"
	00 # 0
	18 19 # "lowpanOutMeshRequests"
	00 # 0
	18 1A # "lowpanOutMeshForwds"
	00 # 0
	18 1B # "lowpanOutMeshTransmits"
	00 # 0
	18 1C # "lowpanOutDiscards"
	00 # 0
	18 1D # "lowpanOutTransmits"
	0F # 15
	FF
	FF
	Figure 3: Example CBOR encoding for the 6LoWPAN MIB
	82 # two element array		4.3.4. 6LoWPAN MIB
	1A 8B 47 88 F3 # translation table ID 8B4788F3
	BF # indefinite length map
	00
	75 # "LOWPAN-MIB:LOWPAN-MIB"
	01 #
	72 ... # "lowpanReasmTimeout"
	02
	70 ... # "lowpanInReceives"
	03
	71 ... # "lowpanInHdrErrors"
	04
	74 ... # "lowpanInMeshReceives"
	05
	72 ... # "lowpanInMeshForwds"
	06
	74 ... # "lowpanInMeshDelivers"
	07
	72 ... # "lowpanInReasmReqds"
	08
	72 ... # "lowpanInReasmFails"
	09
	70 ... # "lowpanInReasmOKs"
	0A
	71 ... # "lowpanInCompReqds"
	0B
	71 ... # "lowpanInCompFails"
	0C
	6F ... # "lowpanInCompOKs"
	0D
	70 ... # "lowpanInDiscards"
	0E
	70 ... # "lowpanInDelivers"
	0F
	71 ... # "lowpanOutRequests"
	10
	72 ... # "lowpanOutCompReqds"
	11
	72 ... # "lowpanOutCompFails"
	12
	70 ... # "lowpanOutCompOKs"
	13
	72 ... # "lowpanOutFragReqds"
	14
	72 ... # "lowpanOutFragFails"
	15
	70 ... # "lowpanOutFragOKs"
	16
	74 ... # "lowpanOutFragCreates"
	17
	78 1B ... # "lowpanOutMeshHopLimitExceeds"
	18 18
	75 ... # "lowpanOutMeshNoRoutes"
	18 19
	75 ... # "lowpanOutMeshRequests"
	18 1A
	73 ... # "lowpanOutMeshForwds"
	18 1B
	76 ... # "lowpanOutMeshTransmits"
	18 1C
	71 ... # "lowpanOutDiscards"
	18 1D
	72 ... # "lowpanOutTransmits"
	FF
	Figure 4: Translation table for the 6LoWPAN MIB		A MIB for 6LoWPAN is defined in [I-D.ietf-6lo-lowpan-mib] with an
			example JSON representation in its Appendix A. Appendix B.3 shows
			the associated CBOR representation with string number, and the
			corresponding string to string number conversion table.
	In this example, a GET to /mg/mib/lowpanOutFragFails would give:		In this example, a GET to /mg/mib/lowpanOutFragFails would give:
	82 # two element array		82 # two element array
	1A 8B 47 88 F3 # translation table ID 8B4788F3		78 18 4c 4f 57 50 41 4e
			2d 4d 49 42 5f 32 30 31
			34 30 34 30 38 30 30 30
			30 5a # conversion table id:
			# "LOWPAN-MIB_201404080000Z"
	BF # indefinite length map		BF # indefinite length map
	14 # "lowpanOutFragFails"		18 1B # "lowpanOutFragFails"
	00 # 0		00 # 0
	FF		FF
	5. MIB discovery		5. Trap functions
	MIB objects are discovered like resources with the standard CoAP
	resource discovery. Performing a GET on "/.well-known/core" with
	rt=core.mg.mib returns all MIB descriptors and all OIDs which are
	available on this device. For table objects there is no further
	possibility to discover the row descriptors. For example, consider
	there are two MIB objects with descriptors "sysUpTime" and
	"ipNetToMediaTable" associated with OID 1.3.6.1.2.1.1.3 and
	1.3.6.1.2.1.4.22
	REQ: GET example.com/.well-known/core?rt=core.mg.mib
	RES: 2.05 Content (Content-Format: application/text)
	</mg/mib/sysUpTime>;rt="core.mg.mib";oid="1.3.6.1.2.1.1.3";mod="SNMPv2-MIB"
	</mg/mib/ipNetToMediaTable>;rt="core.mg.mib";oid="1.3.6.1.2.1.4.22";mod="ipMIB"
	The link format attribute 'oid' is used to associate the name of the
	MIB resource with its OID. The OID is written as a string in its
	conventional form.
	Notice that a MIB variable normally is associated with a descriptor
	and an OID. The OID is unique, whereas the descriptor is unique in
	combination with the module name.
	The "mod", "con", and "rt" attributes can be used to filter resource
	queries as specified in [RFC6690].
	6. Trap functions
	A trap can be set through the CoAP Observe [I-D.ietf-core-observe]		A trap can be set through the CoAP Observe [I-D.ietf-core-observe]
	function. As regular with Observe, the managing entity subscribes to		function. As regular with Observe, the managing entity subscribes to
	the variable by sending a GET request with an "Observe" option.		the variable by sending a GET request with an "Observe" option.
	TODO: Observe example		TODO: Observe example
	In the registration request, the managing entity MAY include a		In the registration request, the managing entity MAY include a
	"Response-To-Uri-Host" and optionally "Response-To-Uri-Port" option		"Response-To-Uri-Host" and optionally "Response-To-Uri-Port" option
	as defined in [I-D.becker-core-coap-sms-gprs]. In this case, the		as defined in [I-D.becker-core-coap-sms-gprs]. In this case, the
	observations SHOULD be sent to the address and port indicated in		observations SHOULD be sent to the address and port indicated in
	these options. This can be useful when the managing entity wants the		these options. This can be useful when the managing entity wants the
	managed device to send the trap information to a multicast address.		managed device to send the trap information to a multicast address.
	7. MIB access management		6. MIB access management
	Two topics are relevant: (1) the definition of the destination of		Two topics are relevant: (1) the definition of the destination of
	Notify messages, and (2) the creation and maintenance of "string to		Notify messages, and (2) the creation and maintenance of "string to
	number" tables.		number" tables.
	7.1. Notify destinations		6.1. Notify destinations
	The destination of notifications need to be communicated to the		The destination of notifications need to be communicated to the
	applications sending them. Draft [I-D.ietf-core-interfaces]		applications sending them. Draft [I-D.ietf-core-interfaces]
	describes the binding of end-points to end-points on remote devices.		describes the binding of end-points to end-points on remote devices.
	The object with type "binding table" contains a sequence of bindings.		The object with type "binding table" contains a sequence of bindings.
	The contents of bindings contains the methods, location, the interval		The contents of bindings contains the methods, location, the interval
	specifications, and the step value as suggested in		specifications, and the step value as suggested in
	[I-D.ietf-core-interfaces]. The method "notify" has been added to		[I-D.ietf-core-interfaces]. The method "notify" has been added to
	the binding methods "poll", "obs" and "push", to cater for the		the binding methods "poll", "obs" and "push", to cater for the
	binding of notification source to the receiver.		binding of notification source to the receiver.
	TODO: describe interface for NOTIFY destination definition.		TODO: describe interface for NOTIFY destination definition.
	7.2. Conversion tables		6.2. Conversion table management
	POST is used to initialize a conversion table. At the arrival of the		Since the conversion table is unique for a MIB, it can be generated
	POST, all existing tables are removed and new tables as specified by		off-line by a managing entity, and independently generated in the
	the payload are created with the contents specified in the payload.		managed device with the same result. Because different versions of a
	When the payload of the POST is empty, no table is created.		given MIB may be available the managing entity must be able to check
			the version on the managed device. The convTableId can be acquired
			with a confirmable GET request:
	PUT is used to create new entries in an existing table and overwrite		REQ: GET example.com/mg/conv/ident
	existing entries. When the payload of the PUT contains a non
	existing table, a new table with the new identity is created. When
	the payload of the PUT contains a table with an already existing
	identifier, two possiblities exist:
	exiting string value the contents of the existing pair is		RES: 2.05 Content (Content-Format: application/json)
	overwritten with the pair in the payload.		{
			"convTableId" : convTableId
			}
	new string value A new pair is created in the table with the pair in		The conversion table MAY be available on a managed device, and can
	the payload.		then be acquired as follows:
	8. Error handling		GET /mg/conv/[convTableId]
			where "[convTableId]" is replaced by the the value of convTableId
			from the CBorMIB structure.
			In case the managed device provides the table, it must be transmitted
			in the payload of the GET response using the following format:
			convTable : ConvTable;
			*ConvTable {
			convTableId : tstr;
			convData : map( uint, tstr );
			}
			where "convTableId" is the conversion table identifier, as defined in
			Section 4.2, and "convData" is a CBOR map between the string number
			and associated variable descriptor.
			7. Error handling
	In case a request is received which cannot be processed properly, the		In case a request is received which cannot be processed properly, the
	managed entity MUST return an error message. This error message MUST		managed entity MUST return an error message. This error message MUST
	contain a CoAP 4.xx or 5.xx response code, and SHOULD include		contain a CoAP 4.xx or 5.xx response code, and SHOULD include
	additional information in the payload.		additional information in the payload.
	Such an error message payload is encoded in CBOR, using the following		Such an error message payload is encoded in CBOR, using the following
	structure:		structure:
	errorMsg : ErrorMsg;		errorMsg : ErrorMsg;
	skipping to change at page 25, line 44 ¶		skipping to change at page 25, line 4 ¶
	Such an error message payload is encoded in CBOR, using the following		Such an error message payload is encoded in CBOR, using the following
	structure:		structure:
	errorMsg : ErrorMsg;		errorMsg : ErrorMsg;
	*ErrorMsg {		*ErrorMsg {
	errorCode : uint;		errorCode : uint;
	?errorText : tstr;		?errorText : tstr;
	}		}
	The variable "errorCode" has one of the values from the table below,		The variable "errorCode" has one of the values from the table below,
	and the OPTIONAL "errorText" field contains a human readible		and the OPTIONAL "errorText" field contains a human readible
	explanation of the error.		explanation of the error.
	+----------------+----------------+---------------------------------+		+----------------+----------------+---------------------------------+
	| CoMI Error | CoAP Error | Description |		| CoMI Error | CoAP Error | Description |
	| Code | Code | |		| Code | Code | |
	+----------------+----------------+---------------------------------+		+----------------+----------------+---------------------------------+
	| 0 | 4.00 | General error |		| 0 | 4.00 | General error |
	| | | |		| | | |
	| 1 | 4.00 | Malformed CBOR data |		| 1 | 4.00 | Malformed CBOR data |
	| | | |		| | | |
	| 2 | 4.00 | Incorrect CBOR datatype |		| 2 | 4.00 | Incorrect CBOR datatype |
	| | | |		| | | |
	| 3 | 4.00 | Unknown MIB variable |		| 3 | 4.00 | Unknown MIB variable |
	| | | |		| | | |
	| 4 | 4.00 | Unknown translation table |		| 4 | 4.00 | Unknown conversion table |
	| | | |		| | | |
	| 5 | 4.05 | Attempt to write read-only |		| 5 | 4.05 | Attempt to write read-only |
	| | | variable |		| | | variable |
	| | | |		| | | |
	| 0..2 | 5.01 | Access exceptions |		| 0..2 | 5.01 | Access exceptions |
	| | | |		| | | |
	| 0..18 | 5.00 | SMI error status |		| 0..18 | 5.00 | SMI error status |
	+----------------+----------------+---------------------------------+		+----------------+----------------+---------------------------------+
	The CoAP error code 5.01 is associted with the exceptions defined in		The CoAP error code 5.01 is associted with the exceptions defined in
	[RFC3416] and CoAP error code 5.00 is associated with the error-		[RFC3416] and CoAP error code 5.00 is associated with the error-
	status defined in [RFC3416].		status defined in [RFC3416].
	9. Security Considerations		8. Security Considerations
	For secure network management, it is important to restrict access to		For secure network management, it is important to restrict access to
	MIB variables only to authorised parties. This requires integrity		MIB variables only to authorised parties. This requires integrity
	protection of both requests and responses, and depending on the		protection of both requests and responses, and depending on the
	application encryption.		application encryption.
	CoMI re-uses the security mechanisms already available to CoAP as		CoMI re-uses the security mechanisms already available to CoAP as
	much as possible. This includes DTLS for protected access to		much as possible. This includes DTLS for protected access to
	resources, as well suitable authentication and authorisation		resources, as well suitable authentication and authorisation
	mechanisms.		mechanisms.
	skipping to change at page 27, line 9 ¶		skipping to change at page 26, line 12 ¶
	all, but is easy to implement, whereas the X.509 mode is quite		all, but is easy to implement, whereas the X.509 mode is quite
	secure, but may be too complex for constrained devices.		secure, but may be too complex for constrained devices.
	In addition, mechanisms for authentication and authorisation may need		In addition, mechanisms for authentication and authorisation may need
	to be selected.		to be selected.
	CoMI avoids defining new security mechanisms as much as possible.		CoMI avoids defining new security mechanisms as much as possible.
	However some adaptations may still be required, to cater for CoMI's		However some adaptations may still be required, to cater for CoMI's
	specific requirements.		specific requirements.
	10. IANA Considerations		9. IANA Considerations
	'rt="core.mg.mib"' needs registration with IANA.		'rt="core.mg.mib"' needs registration with IANA.
	Content types to be registered:		Content types to be registered:
	o application/comi+json		o application/comi+json
	o application/comi+cbor		o application/comi+cbor
	11. Acknowledgements		10. Acknowledgements
	Mehmet Ersue and Bert Wijnen explained the encoding aspects of PDUs		Mehmet Ersue and Bert Wijnen explained the encoding aspects of PDUs
	transported under SNMP. Carsten Bormann has given feedback on the		transported under SNMP. Carsten Bormann has given feedback on the
	use of CBOR. Juergen Schoenwalder has commented on inconsistencies		use of CBOR. Juergen Schoenwalder has commented on inconsistencies
	and missing aspects of SNMP in earlier versions of the draft. The		and missing aspects of SNMP in earlier versions of the draft. The
	draft has benefited from comments by Thomas Watteyne, Dee Denteneer,		draft has benefited from comments (alphabetical order) by Dee
	Esko Dijk, and Michael van Hartskamp. The CBOR encoding borrows		Denteneer, Esko Dijk, Michael van Hartskamp, Zach Shelby, Michael
			Verschoor, and Thomas Watteyne. The CBOR encoding borrows
	extensively from Ladislav Lhotka's description on conversion from		extensively from Ladislav Lhotka's description on conversion from
	YANG to JSON.		YANG to JSON.
	12. Changelog		11. Changelog
	Changes from version 00 to version 01		Changes from version 00 to version 01
	o Focus on MIB only		o Focus on MIB only
	o Introduced CBOR, JSON, removed BER		o Introduced CBOR, JSON, removed BER
	o defined mappings from SMI to xx		o defined mappings from SMI to xx
	o Introduced the concept of addressable table rows		o Introduced the concept of addressable table rows
	skipping to change at page 28, line 4 ¶		skipping to change at page 27, line 8 ¶
	Changes from version 01 to version 02		Changes from version 01 to version 02
	o Focus on CBOR, used JSON for examples, removed XML and EXI		o Focus on CBOR, used JSON for examples, removed XML and EXI
	o added uri-query attributes mod and con to specify modules and		o added uri-query attributes mod and con to specify modules and
	contexts		contexts
	o Definition of CBOR string conversion tables for data reduction		o Definition of CBOR string conversion tables for data reduction
	o use of Block for multiple fragments		o use of Block for multiple fragments
	o Error returns generalized		o Error returns generalized
	o SMI - YANG - CBOR conversion		o SMI - YANG - CBOR conversion
	Changes from version 02 to version 03		Changes from version 02 to version 03
	o Added security considerations		o Added security considerations
	13. References		Changes from version 03 to version 04
	13.1. Normative References		o Added design considerations section
			o Extended comparison of management protocols in introduction
			o Added automatic generation of CBOR tables
			o Moved lowpan table to Appendix
			12. References
			12.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the		[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
	Network Configuration Protocol (NETCONF)", RFC 6020,		Network Configuration Protocol (NETCONF)", RFC 6020,
	October 2010.		October 2010.
	[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", RFC 7049, October 2013.		Representation (CBOR)", RFC 7049, October 2013.
	skipping to change at page 28, line 42 ¶		skipping to change at page 28, line 12 ¶
	Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP",		Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP",
	draft-ietf-core-block-14 (work in progress), October 2013.		draft-ietf-core-block-14 (work in progress), October 2013.
	[I-D.ietf-core-coap]		[I-D.ietf-core-coap]
	Shelby, Z., Hartke, K., and C. Bormann, "Constrained		Shelby, Z., Hartke, K., and C. Bormann, "Constrained
	Application Protocol (CoAP)", draft-ietf-core-coap-18		Application Protocol (CoAP)", draft-ietf-core-coap-18
	(work in progress), June 2013.		(work in progress), June 2013.
	[I-D.ietf-core-observe]		[I-D.ietf-core-observe]
	Hartke, K., "Observing Resources in CoAP", draft-ietf-		Hartke, K., "Observing Resources in CoAP", draft-ietf-
	core-observe-11 (work in progress), October 2013.		core-observe-13 (work in progress), April 2014.
	[I-D.ietf-json-rfc4627bis]		[I-D.ietf-json-rfc4627bis]
	Bray, T., "The JSON Data Interchange Format", draft-ietf-		Bray, T., "The JSON Data Interchange Format", draft-ietf-
	json-rfc4627bis-10 (work in progress), December 2013.		json-rfc4627bis-10 (work in progress), December 2013.
	[I-D.lhotka-netmod-yang-json]		[I-D.lhotka-netmod-yang-json]
	Lhotka, L., "Modeling JSON Text with YANG", draft-lhotka-		Lhotka, L., "Modeling JSON Text with YANG", draft-lhotka-
	netmod-yang-json-02 (work in progress), September 2013.		netmod-yang-json-02 (work in progress), September 2013.
	13.2. Informative References		12.2. Informative References
	[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base		[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
	for Network Management of TCP/IP-based internets:MIB-II",		for Network Management of TCP/IP-based internets:MIB-II",
	STD 17, RFC 1213, March 1991.		STD 17, RFC 1213, March 1991.
	[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.		[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
	Schoenwaelder, Ed., "Structure of Management Information		Schoenwaelder, Ed., "Structure of Management Information
	Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.		Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
	[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group		[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
	skipping to change at page 31, line 5 ¶		skipping to change at page 30, line 20 ¶
	[I-D.ietf-core-interfaces]		[I-D.ietf-core-interfaces]
	Shelby, Z. and M. Vial, "CoRE Interfaces", draft-ietf-		Shelby, Z. and M. Vial, "CoRE Interfaces", draft-ietf-
	core-interfaces-01 (work in progress), December 2013.		core-interfaces-01 (work in progress), December 2013.
	[I-D.ersue-constrained-mgmt]		[I-D.ersue-constrained-mgmt]
	Ersue, M., Romascanu, D., and J. Schoenwaelder,		Ersue, M., Romascanu, D., and J. Schoenwaelder,
	"Management of Networks with Constrained Devices: Problem		"Management of Networks with Constrained Devices: Problem
	Statement, Use Cases and Requirements", draft-ersue-		Statement, Use Cases and Requirements", draft-ersue-
	constrained-mgmt-03 (work in progress), February 2013.		constrained-mgmt-03 (work in progress), February 2013.
	[I-D.schoenw-6lowpan-mib]		[I-D.ietf-6lo-lowpan-mib]
	Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou,		Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou,
	"Definition of Managed Objects for IPv6 over Low-Power		"Definition of Managed Objects for IPv6 over Low-Power
	Wireless Personal Area Networks (6LoWPANs)", draft-		Wireless Personal Area Networks (6LoWPANs)", draft-ietf-
	schoenw-6lowpan-mib-03 (work in progress), February 2013.		6lo-lowpan-mib-01 (work in progress), April 2014.
	[I-D.bierman-netconf-restconf]		[I-D.bierman-netconf-restconf]
	Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando,		Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando,
	"RESTCONF Protocol", draft-bierman-netconf-restconf-03		"RESTCONF Protocol", draft-bierman-netconf-restconf-04
	(work in progress), December 2013.		(work in progress), February 2014.
	[STD0001] "Official Internet Protocols Standard", Web		[STD0001] "Official Internet Protocols Standard", Web
	http://www.rfc-editor.org/rfcxx00.html, .		http://www.rfc-editor.org/rfcxx00.html, .
	[XML] "Extensible Markup Language (XML)", Web		[XML] "Extensible Markup Language (XML)", Web
	http://www.w3.org/xml, .		http://www.w3.org/xml, .
	[JSON] "JavaScript Object Notation (JSON)", Web		[JSON] "JavaScript Object Notation (JSON)", Web
	http://www.json.org, .		http://www.json.org, .
			[OMA] "OMA-TS-LightweightM2M-V1_0-20131210-C", Web
			http://technical.openmobilealliance.org/Technical/
			current_releases.aspx, .
	Appendix A. Notational Convention for CBOR data		Appendix A. Notational Convention for CBOR data
	To express CBOR structures [RFC7049], this document uses the		To express CBOR structures [RFC7049], this document uses the
	following conventions:		following conventions:
	A declaration of a CBOR variable has the form:		A declaration of a CBOR variable has the form:
	name : datatype;		name : datatype;
	where "name" is the name of the variable, and "datatype" its CBOR		where "name" is the name of the variable, and "datatype" its CBOR
	skipping to change at page 32, line 15 ¶		skipping to change at page 31, line 35 ¶
	character.		character.
	A CBOR structure can be encapsulated in an array, in which case its		A CBOR structure can be encapsulated in an array, in which case its
	name in its definition is preceeded by a '*' character. Otherwise		name in its definition is preceeded by a '*' character. Otherwise
	the structure is just a grouping of fields, but without actual		the structure is just a grouping of fields, but without actual
	encoding of such grouping.		encoding of such grouping.
	The name of an optional field is preceded by a '?' character. This		The name of an optional field is preceded by a '?' character. This
	means, that the field may be omitted if not required.		means, that the field may be omitted if not required.
			Appendix B. Example conversion table and instance for the LOWPAN MIB
			The conversion table of the 6LoWPAN MIB [I-D.ietf-6lo-lowpan-mib] is
			generated as described in this section.
			B.1. Generating the convTableId
			The module name is "LOWPAN-MIB", and the LAST-UPDATED field in the
			MODULE-IDENTITY has the value "201404080000Z". Hence the convId has
			the value "LOWPAN-MIB_201404080000Z".
			B.2. Generating the string numbers
			The following table shows how the string numbers are associated with
			the related strings and object IDs.
			+--------------------------+-------------------------------+--------+
			| Object ID | Descriptor | String |
			| | | number |
			+--------------------------+-------------------------------+--------+
			| 1.3.6.1.2.1 | mib-2 | 1 |
			| | | |
			| 1.3.6.1.2.1.2.2.1.1 | ifIndex | 2 |
			| | | |
			| 1.3.6.1.2.1.XXXX | lowpanMib | 3 |
			| | | |
			| 1.3.6.1.2.1.XXXX.0 | lowpanNotifications | 4 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1 | lowpanObjects | 5 |
			| | | |
			| 1.3.6.1.2.1.XXXX.2 | lowpanConformance | 6 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1 | lowpanStats | 7 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.1 | lowpanReasmTimeout | 8 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.2 | lowpanInReceives | 9 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.3 | lowpanInHdrErrors | 10 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.4 | lowpanInMeshReceives | 11 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.5 | lowpanInMeshForwds | 12 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.6 | lowpanInMeshDelivers | 13 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.7 | lowpanInReasmReqds | 14 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.8 | lowpanInReasmFails | 15 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.9 | lowpanInReasmOKs | 16 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.10 | lowpanInCompReqds | 17 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.11 | lowpanInCompFails | 18 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.12 | lowpanInCompOKs | 19 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.13 | lowpanInDiscards | 20 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.14 | lowpanInDelivers | 21 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.15 | lowpanOutRequests | 22 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.16 | lowpanOutCompReqds | 23 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.17 | lowpanOutCompFails | 24 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.18 | lowpanOutCompOKs | 25 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.19 | lowpanOutFragReqds | 26 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.20 | lowpanOutFragFails | 27 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.21 | lowpanOutFragOKs | 28 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.22 | lowpanOutFragCreates | 29 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.23 | lowpanOutMeshHopLimitExceeds | 30 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.24 | lowpanOutMeshNoRoutes | 31 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.25 | lowpanOutMeshRequests | 32 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.26 | lowpanOutMeshForwds | 33 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.27 | lowpanOutMeshTransmits | 34 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.28 | lowpanOutDiscards | 35 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.1.29 | lowpanOutTransmits | 36 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2 | lowpanIfStatsTable | 37 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1 | lowpanIfStatsEntry | 38 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.1 | lowpanIfReasmTimeout | 39 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.2 | lowpanIfInReceives | 40 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.3 | lowpanIfInHdrErrors | 41 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.4 | lowpanIfInMeshReceives | 42 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.5 | lowpanIfInMeshForwds | 43 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.6 | lowpanIfInMeshDelivers | 44 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.7 | lowpanIfInReasmReqds | 45 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.8 | lowpanIfInReasmFails | 46 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.9 | lowpanIfInReasmOKs | 47 |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.1 | lowpanIfInCompReqds | 48 |
			| 0 | | |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.1 | lowpanIfInCompFails | 49 |
			| 1 | | |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.1 | lowpanIfInCompOKs | 50 |
			| 2 | | |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.1 | lowpanIfInDiscards | 51 |
			| 3 | | |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.1 | lowpanIfInDelivers | 52 |
			| 4 | | |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.1 | lowpanIfOutRequests | 53 |
			| 5 | | |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.1 | lowpanIfOutCompReqds | 54 |
			| 6 | | |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.1 | lowpanIfOutCompFails | 55 |
			| 7 | | |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.1 | lowpanIfOutCompOKs | 56 |
			| 8 | | |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.1 | lowpanIfOutFraqRegds | 57 |
			| 9 | | |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.2 | lowpanIfOutFragFails | 58 |
			| 0 | | |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.2 | lowpanIfOutFragOKs | 59 |
			| 1 | | |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.2 | lowpanIfOutFragCreates | 60 |
			| 2 | | |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.2 | lowpanIfOutMeshHopLimitExceed | 61 |
			| 3 | s | |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.2 | lowpanIfOutMeshNoRoutes | 62 |
			| 4 | | |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.2 | lowpanIfOutMeshRequests | 63 |
			| 5 | | |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.2 | lowpanIfOutMeshForwds | 64 |
			| 6 | | |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.2 | lowpanIfOutMeshTransmits | 65 |
			| 7 | | |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.2 | lowpanIfOutDiscards | 66 |
			| 8 | | |
			| | | |
			| 1.3.6.1.2.1.XXXX.1.2.1.2 | lowpanIfOutTransmits | 67 |
			| 9 | | |
			| | | |
			| 1.3.6.1.2.1.XXXX.2.1 | lowpanGroups | 68 |
			| | | |
			| 1.3.6.1.2.1.XXXX.2.1.1 | lowpanStatsGroup | 69 |
			| | | |
			| 1.3.6.1.2.1.XXXX.2.1.2 | lowpanStatsMeshGroup | 70 |
			| | | |
			| 1.3.6.1.2.1.XXXX.2.1.3 | lowpanIfStatsGroup | 71 |
			| | | |
			| 1.3.6.1.2.1.XXXX.2.1.4 | lowpanIfStatsMeshGroup | 72 |
			| | | |
			| 1.3.6.1.2.1.XXXX.2.2 | lowpanCompliances | 73 |
			| | | |
			| 1.3.6.1.2.1.XXXX.2.2.1 | lowpanCompliance | 74 |
			+--------------------------+-------------------------------+--------+
			Notes:
			o The IMPORTS "MODULE-IDENTITY", "OBJECT-TYPE", "Unsigned32",
			"Counter32", "OBJECT-GROUP" and "MODULE-COMPLIANCE" do not have
			associated Object IDs, and hence do not show up in the table.
			o The OBJECT-GROUPs lowpanStatsGroup, lowpanIfStatsGroup,
			lowpanIfStatsMeshGroup cannot appear in the CBOR instance, as they
			are lost in the intermediate MIB to YANG conversion step.
			However, as they have been defined in the original MIB, they still
			appear in the conversion table.
			o (FOR THE EDITOR:) the value XXXX is defined to be the RFC number
			once [I-D.ietf-6lo-lowpan-mib] becomes an RFC. It is logically
			greater than 7000.
			B.3. Example instance
			A MIB for 6LoWPAN is defined in [I-D.ietf-6lo-lowpan-mib]. The
			document also provides an example JSON representation in its
			Appendix A. Figure 3 shows the associated CBOR representation with
			string number, using the string numbers derived in Appendix B.2.
			The request would have been as follows:
			GET /mg/mib/lowpanIfStatsTable
			The resulting table would be as follows:
			82 # two element array
			78 18 4c 4f 57 50 41 4e
			2d 4d 49 42 5f 32 30 31
			34 30 34 30 38 30 30 30
			30 5a # conversion table id:
			# "LOWPAN-MIB_201404080000Z"
			BF # indefinite length map
			18 25 # "lowpanIfStatsTable"
			BF # indefinite length map related
			# to lowpanIfStatsTable
			18 27 # "lowpanIfReasmTimeout"
			14 # 20
			18 28 # "lowpanIfInReceives"
			18 2A # 42
			18 29 # "lowpanIfInHdrErrors"
			00 # 0
			18 2A # "lowpanIfInMeshReceives"
			08 # 8
			18 2B # "lowpanIfInMeshForwds"
			00 # 0
			18 2C # "lowpanIfInMeshDelivers"
			00 # 0
			18 2D # "lowpanIfInReasmReqds"
			16 # 22
			18 2E # "lowpanIfInReasmFails"
			02 # 02
			18 2F # "lowpanIfInReasmOKs"
			14 # 20
			18 30 # "lowpanIfInCompReqds"
			10 # 16
			18 31 # "lowpanIfInCompFails"
			02 # 2
			18 32 # "lowpanIfInCompOKs"
			0E # 14
			18 33 # "lowpanIfInDiscards"
			01 # 01
			18 34 # "lowpanIfInDelivers"
			0C # 12
			18 35 # "lowpanIfOutRequests"
			0C # 12
			18 36 # "lowpanIfOutCompReqds"
			00 # 0
			18 37 # "lowpanIfOutCompFails"
			00 # 0
			18 38 # "lowpanIfOutCompOKs"
			00 # 0
			18 39 # "lowpanIfOutFragReqds"
			05 # 5
			18 3A # "lowpanIfOutFragFails"
			00 # 0
			18 3B # "lowpanIfOutFragOKs"
			05 # 5
			18 3C # "lowpanIfOutFragCreates"
			08 # 8
			18 3D # "lowpanIfOutMeshHopLimitExceeds"
			00 # 0
			18 3E # "lowpanIfOutMeshNoRoutes"
			00 # 0
			18 3F # "lowpanIfOutMeshRequests"
			00 # 0
			18 40 # "lowpanIfOutMeshForwds"
			00 # 0
			18 41 # "lowpanIfOutMeshTransmits"
			00 # 0
			18 42 # "lowpanIfOutDiscards"
			00 # 0
			18 43 # "lowpanIfOutTransmits"
			0F # 15
			FF
			FF
			Figure 3: Example CBOR encoding for the 6LoWPAN MIB
	Authors' Addresses		Authors' Addresses
	Peter van der Stok		Peter van der Stok
	consultant		consultant
	Phone: +31-492474673 (Netherlands), +33-966015248 (France)		Phone: +31-492474673 (Netherlands), +33-966015248 (France)
	Email: consultancy@vanderstok.org		Email: consultancy@vanderstok.org
	URI: www.vanderstok.org		URI: www.vanderstok.org
	Bert Greevenbosch		Bert Greevenbosch
	Huawei Technologies Co., Ltd.		Huawei Technologies Co., Ltd.
	Huawei Industrial Base		Huawei Industrial Base
	Bantian, Longgang District		Bantian, Longgang District
	Shenzhen 518129		Shenzhen 518129
	P.R. China		P.R. China
	Email: bert.greevenbosch@huawei.com		Email: bert.greevenbosch@huawei.com
End of changes. 83 change blocks.
	322 lines changed or deleted		563 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/