draft-ietf-6tisch-coap-00.txt		draft-ietf-6tisch-coap-01.txt
	6TiSCH R. Sudhaakar, Ed.		6TiSCH R. Sudhaakar, Ed.
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track P. Zand		Intended status: Standards Track P. Zand
	Expires: November 7, 2014 University of Twente		Expires: January 4, 2015 University of Twente
	May 6, 2014		July 3, 2014
	6TiSCH Resource Management and Interaction using CoAP		6TiSCH Resource Management and Interaction using CoAP
	draft-ietf-6tisch-coap-00		draft-ietf-6tisch-coap-01
	Abstract		Abstract
	The [IEEE802154e] standardizes the TSCH mode of operation and defines		The [IEEE802154e] standardizes the TSCH mode of operation and defines
	the mechanisms for layer 2 communication between conforming devices.		the mechanisms for layer 2 communication between conforming devices.
	6top defines a set of commands to monitor and manage the TSCH		6top defines a set of commands to monitor and manage the TSCH
	schedule. To realize the full functionality of sensor networks and		schedule. To realize the full functionality of sensor networks and
	allow their adoption and use in real applications we need additional		allow their adoption and use in real applications we need additional
	mechanisms. Specifically, we need to define how to interact with		mechanisms. Specifically, we need to define how to interact with
	6top, control and modify schedules, monitor parameters etc. Higher		6top, control and modify schedules, monitor parameters etc. Higher
	layers monitoring and management entities are then able to use these		layers monitoring and management entities are then able to use these
	capabilities to create feedback loops. Although, there have been		capabilities to create feedback loops. Although, there have been
	many custom implementations of such feedback loops between the		many custom implementations of such feedback loops between the
	routing, transport and MAC layers in sensor network deployments,		routing, transport and MAC layers in sensor network deployments,
	there has been a lack of standards based approaches. The goal of the		there has been a lack of standards based approaches. The goal of the
	memo is to define the messaging between monitoring and management		memo is to define the messaging between monitoring and management
	entities and the 6top layer and a mapping to the 6top commands. The		entities and the 6top layer and a mapping to the 6top commands. The
	document also presents a particular implementation of the generic		document also presents a particular implementation of the generic
	data model specified in [I-D.wang-6tisch-6top-interface] based on		data model specified in [I-D.ietf-6tisch-6top-interface] based on
	CoAP and CBOR.		CoAP and CBOR.
			Requirements Language
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
			"OPTIONAL" in this document are to be interpreted as described in RFC
			2119 [RFC2119].
	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.
	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 November 7, 2014.		This Internet-Draft will expire on January 4, 2015.
	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. Requirements notation . . . . . . . . . . . . . . . . . . . . 2		1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Scope of the document . . . . . . . . . . . . . . . . . . . . 3		3. Scope of the document . . . . . . . . . . . . . . . . . . . . 3
	4. Data Model definition for CoAP . . . . . . . . . . . . . . . 4		4. Data Model definition for CoAP . . . . . . . . . . . . . . . 4
	4.1. Naming Convention for URI schemes . . . . . . . . . . . . 4		4.1. Naming Convention for URI schemes . . . . . . . . . . . . 4
	4.2. Convention for accessing URIs . . . . . . . . . . . . . . 4		4.2. Convention for accessing URIs . . . . . . . . . . . . . . 4
	4.3. 6TiSCH Resources . . . . . . . . . . . . . . . . . . . . 5		4.3. 6TiSCH Resources . . . . . . . . . . . . . . . . . . . . 5
	4.3.1. Management Resources . . . . . . . . . . . . . . . . 5		4.3.1. Management Resources . . . . . . . . . . . . . . . . 5
	4.3.2. Informational Resources . . . . . . . . . . . . . . . 7		4.3.2. Informational Resources . . . . . . . . . . . . . . . 7
	4.3.3. Message Formats . . . . . . . . . . . . . . . . . . . 7		4.3.3. Message Formats . . . . . . . . . . . . . . . . . . . 7
	4.3.4. Extensible Resources . . . . . . . . . . . . . . . . 9		4.3.4. Extensible Resources . . . . . . . . . . . . . . . . 9
	4.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10		4.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.4.1. Request-Response . . . . . . . . . . . . . . . . . . 10		4.4.1. Request-Response . . . . . . . . . . . . . . . . . . 10
	4.4.2. Publish-Subscribe . . . . . . . . . . . . . . . . . . 11		4.4.2. Publish-Subscribe . . . . . . . . . . . . . . . . . . 11
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		5. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.1. Normative References . . . . . . . . . . . . . . . . . . 12		5.1. Normative References . . . . . . . . . . . . . . . . . . 12
	5.2. Informative References . . . . . . . . . . . . . . . . . 12		5.2. Informative References . . . . . . . . . . . . . . . . . 12
	5.3. External Informative References . . . . . . . . . . . . . 13		5.3. External Informative References . . . . . . . . . . . . . 14
	Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13		Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Requirements notation		1. Requirements notation
	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].
	2. Introduction		2. Introduction
	The 6TiSCH Operation Sublayer (6top) [I-D.wang-6tisch-6top-interface]		The 6TiSCH Operation Sublayer (6top) [I-D.ietf-6tisch-6top-interface]
	describes the main commands provided to higher layers that allow them		describes the main commands provided to higher layers that allow them
	to build TSCH schedules, make routing decisions, perform TSCH		to build TSCH schedules, make routing decisions, perform TSCH
	configuration and control procedures and supports centralized and		configuration and control procedures and supports centralized and
	decentralized scheduling policies among other functionalities.		decentralized scheduling policies among other functionalities.
	However, there is still a need for specifying the methods, including		However, there is still a need for specifying the methods, including
	message exchanges and message formats that higher layers use to		message exchanges and message formats that higher layers use to
	invoke these command described by 6top.		invoke these command described by 6top.
	+------------------------------------+		+------------------------------------+
	| Higher Layers |		| Higher Layers |
	skipping to change at page 3, line 45		skipping to change at page 3, line 51
	well as between 6top nodes.		well as between 6top nodes.
	This document also specifies an implementation of this generic		This document also specifies an implementation of this generic
	message exchange and data model using CoAP as the transport		message exchange and data model using CoAP as the transport
	mechanism.		mechanism.
	3. Scope of the document		3. Scope of the document
	This draft defines the communication mechanism between PCE and 6top		This draft defines the communication mechanism between PCE and 6top
	nodes using COAP. We use the generic YANG data model defined in		nodes using COAP. We use the generic YANG data model defined in
	[I-D.wang-6tisch-6top-interface] to define the various CoAP messages		[I-D.ietf-6tisch-6top-interface] to define the various CoAP messages
	and payloads. The payload used CBOR for the encoding format. The		and payloads. The payload used CBOR for the encoding format. The
	document also defines the URIs that used to identify the resources		document also defines the URIs that used to identify the resources
	exposed by 6top.		exposed by 6top.
	This document also defines how users can install custom resources		This document also defines how users can install custom resources
	that allow them to extend the basic resource exposed by 6top.		that allow them to extend the basic resource exposed by 6top.
	4. Data Model definition for CoAP		4. Data Model definition for CoAP
	4.1. Naming Convention for URI schemes		4.1. Naming Convention for URI schemes
	skipping to change at page 4, line 38		skipping to change at page 4, line 43
	5. Typographical conventions as described in A SHOULD be followed		5. Typographical conventions as described in A SHOULD be followed
	These guidelines MUST be followed by users who install extensible		These guidelines MUST be followed by users who install extensible
	resources. It SHOULD be followed for future extensions of the data		resources. It SHOULD be followed for future extensions of the data
	model in order to provide consistency.		model in order to provide consistency.
	4.2. Convention for accessing URIs		4.2. Convention for accessing URIs
	We use the GET, POST and DELETE methods described by CoAP. These		We use the GET, POST and DELETE methods described by CoAP. These
	methods MUST be used in accordance with their definition in Sec. 5.8		methods MUST be used in accordance with their definition in Sec. 5.8
	of [I-D.ietf-core-coap]. We have no need for the PUT method as the		of [RFC7252]. We have no need for the PUT method as the
	functionality of the POST method can be used for all situations that		functionality of the POST method can be used for all situations that
	need updating or modification of a resource. The CoAP methods are		need updating or modification of a resource. The CoAP methods are
	mapped to 6top commands as shown in the figure below.		mapped to 6top commands as shown in the figure below.
	+-------------+--------------+-------------------------+		+-------------+--------------+-------------------------+
	| CoAP method | 6top command | Description |		| CoAP method | 6top command | Description |
	+-------------+--------------+-------------------------+		+-------------+--------------+-------------------------+
	| GET | READ | Retrieves 6top resources|		| GET | READ | Retrieves 6top resources|
	+-------------+--------------+-------------------------+		+-------------+--------------+-------------------------+
	| POST | CREATE / | Creates/Updates a new |		| POST | CREATE / | Creates/Updates a new |
	skipping to change at page 5, line 27		skipping to change at page 5, line 27
	Figure 2: Mapping between CoAP methods and 6top commands		Figure 2: Mapping between CoAP methods and 6top commands
	The GET method may use queries to allow higher layer entities to		The GET method may use queries to allow higher layer entities to
	perform conditional GETs or filter the results of a GET on resource		perform conditional GETs or filter the results of a GET on resource
	that is a collection.		that is a collection.
	The POST method is used in all situations where an argument needs to		The POST method is used in all situations where an argument needs to
	be passed to the 6top layer. The Content-Type option is set to		be passed to the 6top layer. The Content-Type option is set to
	'application/cbor'. The payload is encoded using CBOR format as		'application/cbor'. The payload is encoded using CBOR format as
	described in [I-D.bormann-cbor].		described in [RFC7049].
	The DELETE method is used to invoke the 6top DELETE command on a		The DELETE method is used to invoke the 6top DELETE command on a
	particular resource.		particular resource.
	The GET method may use queries to allow higher layer entities to		The GET method may use queries to allow higher layer entities to
	perform conditional GETs or filter the results of a GET on resource		perform conditional GETs or filter the results of a GET on resource
	that is a collection.		that is a collection.
	4.3. 6TiSCH Resources		4.3. 6TiSCH Resources
	skipping to change at page 7, line 50		skipping to change at page 7, line 50
	Figure 6: Example GET message		Figure 6: Example GET message
	Since this resources points to the entire neighbor list, the response		Since this resources points to the entire neighbor list, the response
	returns all the entries (the list of neighbors of that node) and all		returns all the entries (the list of neighbors of that node) and all
	fields in each entry (i.e. entry for a neighbor) of the list in CBOR		fields in each entry (i.e. entry for a neighbor) of the list in CBOR
	format. A request with a Uri-Query option may be used to retrieve		format. A request with a Uri-Query option may be used to retrieve
	only specific entries in the list. The value of Uri-Query MUST be in		only specific entries in the list. The value of Uri-Query MUST be in
	the ABNF format as described in [RFC5234].		the ABNF format as described in [RFC5234].
	Resources that point to collection within a list, such as '/6t/		Resources that point to collection within a list, such as
	Neighbor/TargetNodeAddr', returns only the values in the		'/6t/Neighbor/TargetNodeAddr', returns only the values in the
	TargetNodeAddr column of the Neighbor list. The usage of the Uri-		TargetNodeAddr column of the Neighbor list. The usage of the Uri-
	Query option has the same effect of filtering on the result.		Query option has the same effect of filtering on the result.
	The endpoint MUST appropriately respond with a 2.05 Content or 4.04		The endpoint MUST appropriately respond with a 2.05 Content or 4.04
	Not Found message as defined in [I-D.ietf-core-coap]. If the		Not Found message as defined in [RFC7252]. If the resource is found
	resource is found then the payload of the response MUST contain a		then the payload of the response MUST contain a CBOR representation
	CBOR representation of the data that is referenced by the URI.		of the data that is referenced by the URI.
	To create or update a Neighbor, the CoAP client MUST send a POST		To create or update a Neighbor, the CoAP client MUST send a POST
	message as shown in Figure 7. The payload MUST describe the argument		message as shown in Figure 7. The payload MUST describe the argument
	that is passed to 6top in CBOR format.		that is passed to 6top in CBOR format.
	+-------------------------------------+		+-------------------------------------+
	Header | POST |		Header | POST |
	+-------------------------------------+		+-------------------------------------+
	Uri-Path| /6t/Neighbor |		Uri-Path| /6t/Neighbor |
	+-------------------------------------+		+-------------------------------------+
	skipping to change at page 10, line 31		skipping to change at page 10, line 31
	Figure 10: Payload format for creating an Extensible Resource		Figure 10: Payload format for creating an Extensible Resource
	4.4. Example		4.4. Example
	This section gives a number of short examples of how to use the data		This section gives a number of short examples of how to use the data
	model and CoAP mapping defined in this document.		model and CoAP mapping defined in this document.
	4.4.1. Request-Response		4.4.1. Request-Response
	Figure 11 shows how a CoAP client adds an entry in the neighbor list		Figure 11 shows how a CoAP client adds an entry in the neighbor list
	of node A. This new neighbor has a target node address 0x1234. The		of node A. This new neighbor has a target node address 0x1234. The
	client sends out a POST request containing the CBOR encoding of		client sends out a POST request containing the CBOR encoding of
	'{TargetNodeAddr: 1234}'. This message is received and processed by		'{TargetNodeAddr: 1234}'. This message is received and processed by
	the CoAP endpoint of Node A and in turn, the 6top command,		the CoAP endpoint of Node A and in turn, the 6top command,
	Create.neighbor is invoked with the appropriate parameters. In this		Create.neighbor is invoked with the appropriate parameters. In this
	case, the address is the 'TargetNodeAddr' parameter passed in the		case, the address is the 'TargetNodeAddr' parameter passed in the
	payload of the POST message and the stats argument has the default		payload of the POST message and the stats argument has the default
	value. In the response to the invocation of the Create.neighbor		value. In the response to the invocation of the Create.neighbor
	command, the 6top sublayer adds an entry to the neighbor list with		command, the 6top sublayer adds an entry to the neighbor list with
	appropriate values and returns a confirm message. The CoAP endpoint		appropriate values and returns a confirm message. The CoAP endpoint
	in turn send out an appropriate CoAP response to indicate success.		in turn send out an appropriate CoAP response to indicate success.
	skipping to change at page 11, line 22		skipping to change at page 11, line 22
	| 1234}) | | with address		| 1234}) | | with address
	| | | 1234		| | | 1234
	| | 6top Confirm |		| | 6top Confirm |
	| CoAP Response |<-----------------------|		| CoAP Response |<-----------------------|
	|<- - - - - - - - - - - -| |		|<- - - - - - - - - - - -| |
	| | |		| | |
	| | |		| | |
	Figure 11: Example of adding a neighbor		Figure 11: Example of adding a neighbor
	In Figure 12, a CoAP client reads a neighbor entry from node A. This		In Figure 12, a CoAP client reads a neighbor entry from node A. This
	neighbor has a target node address 0x1234.		neighbor has a target node address 0x1234.
	CoAP Client Node A Node A		CoAP Client Node A Node A
	(CoAP-endpoint) (6top sublayer)		(CoAP-endpoint) (6top sublayer)
	| CoAP Request | |		| CoAP Request | |
	|- - - - - - - - - - - ->| 6top Request |		|- - - - - - - - - - - ->| 6top Request |
	| GET /6t/Neighbor |----------------------->|		| GET /6t/Neighbor |----------------------->|
	| Uri-Query - | Read.neighbor(address) |Reads neighbor		| Uri-Query - | Read.neighbor(address) |Reads neighbor
	| TargetNodeAddr | |information		| TargetNodeAddr | |information
	| == 0x1234 | |		| == 0x1234 | |
	skipping to change at page 11, line 45		skipping to change at page 11, line 45
	| CoAP Response |<-----------------------|		| CoAP Response |<-----------------------|
	|<- - - - - - - - - - - -| Reads neighbor |		|<- - - - - - - - - - - -| Reads neighbor |
	| 2.05 Content | information |		| 2.05 Content | information |
	| | |		| | |
	Figure 12: Example of reading a neighbor		Figure 12: Example of reading a neighbor
	4.4.2. Publish-Subscribe		4.4.2. Publish-Subscribe
	In Figure 13, a CoAP client subscribes to Monitoring Status of node		In Figure 13, a CoAP client subscribes to Monitoring Status of node
	A. The Monitoring status of Node A is constantly monitored by the		A. The Monitoring status of Node A is constantly monitored by the
	CoAP client.		CoAP client.
	CoAP Client Node A Node A		CoAP Client Node A Node A
	(CoAP-endpoint) (6top sublayer)		(CoAP-endpoint) (6top sublayer)
	| CoAP Register | |		| CoAP Register | |
	|- - - - - - - - - - - - >| 6top Request |		|- - - - - - - - - - - - >| 6top Request |
	| GET /6t/MonitoringStatus|----------------------->|		| GET /6t/MonitoringStatus|----------------------->|
	| | Read.Monitoring.Status |Reads		| | Read.Monitoring.Status |Reads
	| | |the current		| | |the current
	| | |Monitoring		| | |Monitoring
	skipping to change at page 12, line 43		skipping to change at page 12, line 43
	5. References		5. References
	5.1. Normative References		5.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.
	5.2. Informative References		5.2. Informative References
	[I-D.bormann-cbor]		[I-D.ietf-6tisch-6top-interface]
	Bormann, C. and P. Hoffman, "Concise Binary Object		Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
	Representation (CBOR)", draft-bormann-cbor-09 (work in		Operation Sublayer (6top) Interface", draft-ietf-6tisch-
	progress), September 2013.		6top-interface-00 (work in progress), March 2014.
	[I-D.ietf-core-coap]		[I-D.ietf-6tisch-architecture]
	Shelby, Z., Hartke, K., and C. Bormann, "Constrained		Thubert, P., Watteyne, T., and R. Assimiti, "An
	Application Protocol (CoAP)", draft-ietf-core-coap-18		Architecture for IPv6 over the TSCH mode of IEEE
	(work in progress), June 2013.		802.15.4e", draft-ietf-6tisch-architecture-02 (work in
			progress), June 2014.
			[I-D.ietf-6tisch-coap]
			Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and
			Interaction using CoAP", draft-ietf-6tisch-coap-00 (work
			in progress), May 2014.
			[I-D.ietf-6tisch-minimal]
			Vilajosana, X. and K. Pister, "Minimal 6TiSCH
			Configuration", draft-ietf-6tisch-minimal-01 (work in
			progress), June 2014.
			[I-D.ietf-6tisch-terminology]
			Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
			"Terminology in IPv6 over the TSCH mode of IEEE
			802.15.4e", draft-ietf-6tisch-terminology-01 (work in
			progress), February 2014.
			[I-D.ietf-6tisch-tsch]
			Watteyne, T., Palattella, M., and L. Grieco, "Using
			IEEE802.15.4e TSCH in an LLN context: Overview, Problem
			Statement and Goals", draft-ietf-6tisch-tsch-00 (work in
			progress), November 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-14 (work in progress), June 2014.
	[I-D.wang-6tisch-6top-interface]		[I-D.wang-6tisch-6top-sublayer]
	Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH		Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
	Operation Sublayer (6top) Interface", draft-wang-6tisch-		Operation Sublayer (6top)", draft-wang-6tisch-6top-
	6top-interface-02 (work in progress), February 2014.		sublayer-00 (work in progress), February 2014.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66, RFC		Resource Identifier (URI): Generic Syntax", STD 66, RFC
	3986, January 2005.		3986, January 2005.
	[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
			[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
			Representation (CBOR)", RFC 7049, October 2013.
			[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
			Application Protocol (CoAP)", RFC 7252, June 2014.
	5.3. External Informative References		5.3. External Informative References
	[IEEE802154e]		[IEEE802154e]
	IEEE standard for Information Technology, "IEEE std.		IEEE standard for Information Technology, "IEEE std.
	802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area		802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
	Networks (LR-WPANs) Amendment 1: MAC sublayer", April		Networks (LR-WPANs) Amendment 1: MAC sublayer", April
	2012.		2012.
	Appendix A.		Appendix A.
End of changes. 22 change blocks.
	33 lines changed or deleted		69 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/