< draft-ietf-clue-datachannel-15.txt		draft-ietf-clue-datachannel-16.txt >
	CLUE Working Group C. Holmberg		CLUE Working Group C. Holmberg
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Standards Track August 23, 2018		Intended status: Standards Track April 17, 2019
	Expires: February 24, 2019		Expires: October 19, 2019
	CLUE Protocol data channel		CLUE Protocol data channel
	draft-ietf-clue-datachannel-15		draft-ietf-clue-datachannel-16
	Abstract		Abstract
	This document defines how to use the WebRTC data channel mechanism in		This document defines how to use the WebRTC data channel mechanism in
	order to realize a data channel, referred to as a CLUE data channel,		order to realize a data channel, referred to as a CLUE data channel,
	for transporting CLUE protocol messages between two CLUE entities.		for transporting CLUE protocol messages between two CLUE entities.
	The document defines how to describe the SCTPoDTLS association used
	to realize the CLUE data channel using the Session Description
	Protocol (SDP), and defines usage of SDP-based "SCTP over DTLS" data
	channel negotiation mechanism for establishing a CLUE data channel.
	Details and procedures associated with the CLUE protocol, and the SDP
	Offer/Answer procedures for negotiating usage of a CLUE data channel,
	are outside the scope of this document.
	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 https://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 February 24, 2019.		This Internet-Draft will expire on October 19, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. CLUE data channel . . . . . . . . . . . . . . . . . . . . . . 4		3. CLUE data channel . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.2. SCTP Considerations . . . . . . . . . . . . . . . . . . . 4		3.2. SCTP Considerations . . . . . . . . . . . . . . . . . . . 4
	3.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 4		3.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 4
	3.2.2. SCTP Payload Protocol Identifier (PPID) . . . . . . . 4		3.2.2. SCTP Payload Protocol Identifier (PPID) . . . . . . . 4
	3.2.3. Reliability . . . . . . . . . . . . . . . . . . . . . 5		3.2.3. Reliability . . . . . . . . . . . . . . . . . . . . . 4
	3.2.4. Order . . . . . . . . . . . . . . . . . . . . . . . . 5		3.2.4. Order . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.2.5. Stream Reset . . . . . . . . . . . . . . . . . . . . 5		3.2.5. Stream Reset . . . . . . . . . . . . . . . . . . . . 5
	3.2.6. SCTP Multihoming . . . . . . . . . . . . . . . . . . 5		3.2.6. SCTP Multihoming . . . . . . . . . . . . . . . . . . 5
	3.2.7. Close CLUE data channel . . . . . . . . . . . . . . . 5		3.2.7. Closing the CLUE data channel . . . . . . . . . . . . 5
	3.3. SDP Considerations . . . . . . . . . . . . . . . . . . . 6		3.3. SDP Considerations . . . . . . . . . . . . . . . . . . . 5
	3.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 6		3.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 5
	3.3.2. SDP dcmap Attribute . . . . . . . . . . . . . . . . . 7		3.3.2. SDP dcmap Attribute . . . . . . . . . . . . . . . . . 6
	3.3.3. SDP dcsa Attribute . . . . . . . . . . . . . . . . . 7		3.3.3. SDP dcsa Attribute . . . . . . . . . . . . . . . . . 7
	3.3.4. Example . . . . . . . . . . . . . . . . . . . . . . . 7		3.3.4. Example . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 8		4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	5.1. New WebRTC data channel Protocol Value . . . . . . . . . 8		5.1. New WebRTC data channel Protocol Value . . . . . . . . . 8
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8		7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . 12		8.1. Normative References . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . 13		8.2. Informative References . . . . . . . . . . . . . . . . . 13
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	This document defines how to use the WebRTC data channel mechanism		This document defines how to use the WebRTC data channel mechanism
	[I-D.ietf-rtcweb-data-channel] in order to realize a data channel,		[I-D.ietf-rtcweb-data-channel] in order to realize a data channel,
	referred to as a CLUE data channel, for transporting CLUE protocol		referred to as a CLUE data channel, for transporting CLUE protocol
	[I-D.ietf-clue-protocol]messages between two CLUE entities.		[I-D.ietf-clue-protocol] messages between two CLUE entities.
	The document defines how to describe the SCTPoDTLS association		The document defines how to describe the SCTPoDTLS association
	[RFC8261] used to realize the CLUE data channel using the Session		[RFC8261] used to realize the CLUE data channel using the Session
	Description Protocol (SDP) [RFC4566], and defines usage of the SDP-		Description Protocol (SDP) [RFC4566], and defines usage of the SDP-
	based "SCTP over DTLS" data channel negotiation mechanism		based "SCTP over DTLS" data channel negotiation mechanism
	[I-D.ietf-mmusic-data-channel-sdpneg]. This includes SCTP		[I-D.ietf-mmusic-data-channel-sdpneg]. This includes SCTP
	considerations specific to a CLUE data channel, the SDP Media		considerations specific to a CLUE data channel, the SDP Media
	Description (m- line) values, and usage of SDP attributes specific to		Description ("m=" line) values, and usage of SDP attributes specific
	a CLUE data channel.		to a CLUE data channel.
	Details and procedures associated with the CLUE protocol, and the SDP		Details and procedures associated with the CLUE protocol, and the SDP
	Offer/Answer [RFC3264] procedures for negotiating usage of a CLUE		Offer/Answer [RFC3264] procedures for negotiating usage of a CLUE
	data channel, are outside the scope of this document.		data channel, are outside the scope of this document.
	NOTE: The usage of the data channel Establishment Protocol (DCEP)		NOTE: The usage of the Data Channel Establishment Protocol (DCEP)
	[I-D.ietf-rtcweb-data-protocol] for establishing a CLUE data channel		[I-D.ietf-rtcweb-data-protocol] for establishing a CLUE data channel
	is outside the scope of this document.		is outside the scope of this document.
	2. Conventions		2. Conventions
	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", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in BCP 14, RFC 2119		"OPTIONAL" in this document are to be interpreted as described in BCP
	[RFC2119].		14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	SCTPoDTLS association refers to an SCTP association carried over an		SCTPoDTLS association refers to an SCTP association carried over an
	DTLS connection [RFC8261].		DTLS connection [RFC8261].
	WebRTC data channel refers to a pair of SCTP streams over a SCTPoDTLS		WebRTC data channel refers to a pair of SCTP streams over a SCTPoDTLS
	association that is used to transport non-media data between two		association that is used to transport non-media data between two
	entities, as defined in [I-D.ietf-rtcweb-data-channel].		entities, as defined in [I-D.ietf-rtcweb-data-channel].
	CLUE data channel refers to a WebRTC data channel		CLUE data channel refers to a WebRTC data channel
	[I-D.ietf-rtcweb-data-channel] realization, with a specific set of		[I-D.ietf-rtcweb-data-channel] realization, with a specific set of
	skipping to change at page 4, line 11 ¶		skipping to change at page 3, line 50 ¶
	SCTP identifier is defined in [RFC4960] as an unsigned integer, which		SCTP identifier is defined in [RFC4960] as an unsigned integer, which
	identifies an SCTP stream.		identifies an SCTP stream.
	3. CLUE data channel		3. CLUE data channel
	3.1. General		3.1. General
	This section describes the realization of a CLUE data channel, using		This section describes the realization of a CLUE data channel, using
	the WebRTC data channel mechanism. This includes a set of SCTP		the WebRTC data channel mechanism. This includes a set of SCTP
	characteristics specific to a CLUE data channel, the values of the m-		characteristics specific to a CLUE data channel, the values of the
	line describing the SCTPoDTLS association associated with the WebRTC		"m=" line describing the SCTPoDTLS association associated with the
	data channel, and the usage of the SDP-based "SCTP over DTLS" data		WebRTC data channel, and the usage of the SDP-based "SCTP over DTLS"
	channel negotiation mechanism for creating the CLUE data channel.		data channel negotiation mechanism for creating the CLUE data
			channel.
	As described in [I-D.ietf-rtcweb-data-channel], the SCTP streams		As described in [I-D.ietf-rtcweb-data-channel], the SCTP streams
	realizing a WebRTC data channel must be associated with the same SCTP		realizing a WebRTC data channel must be associated with the same SCTP
	association. In addition, both SCTP streams realizing the WebRTC		association. In addition, both SCTP streams realizing the WebRTC
	data channel must use the same SCTP stream identifier value. These		data channel must use the same SCTP stream identifier value. These
	rules also apply to a CLUE data channel.		rules also apply to a CLUE data channel.
	Within a given CLUE session, a CLUE entity MUST use a single CLUE		Within a given CLUE session, a CLUE entity MUST use a single CLUE
	data channel for transport of all CLUE messages towards its peer.		data channel for transport of all CLUE messages towards its peer.
	3.2. SCTP Considerations		3.2. SCTP Considerations
	3.2.1. General		3.2.1. General
	As described in [I-D.ietf-rtcweb-data-channel], different SCTP		As described in [I-D.ietf-rtcweb-data-channel], different SCTP
	options (e.g. regarding ordered delivery ), can be used for a data		options (e.g., regarding ordered delivery ), can be used for a data
	channel. This section describes the SCTP options used for a CLUE		channel. This section describes the SCTP options used for a CLUE
	data channel. Section 3.3 describes how SCTP options are signalled		data channel. Section 3.3 describes how SCTP options are signaled
	using SDP.		using SDP.
	NOTE: While SCTP allows SCTP options to be applied per SCTP message,		NOTE: While SCTP allows SCTP options to be applied per SCTP message,
	[I-D.ietf-rtcweb-data-channel] mandates that, for a given data		[I-D.ietf-rtcweb-data-channel] mandates that, for a given data
	channel, the same SCTP options are applied to each SCTP message		channel, the same SCTP options are applied to each SCTP message
	associated with that data channel.		associated with that data channel.
	3.2.2. SCTP Payload Protocol Identifier (PPID)		3.2.2. SCTP Payload Protocol Identifier (PPID)
	A CLUE entity MUST use the PPID value 51 when sending a CLUE message		A CLUE entity MUST use the PPID value 51 when sending a CLUE message
	on a CLUE data channel.		on a CLUE data channel.
	NOTE: As described in [I-D.ietf-rtcweb-data-channel], the PPID value		NOTE: As described in [I-D.ietf-rtcweb-data-channel], the PPID value
	51 indicates that the SCTP message contains data encoded in a UTF-8		51 indicates that the SCTP message contains data encoded in a UTF-8
	format. The PPID value 51 does not indicate what application		format. The PPID value 51 does not indicate which application
	protocol the SCTP message is associated with, only the format in		protocol the SCTP message is associated with, only the format in
	which the data is encoded.		which the data is encoded.
	3.2.3. Reliability		3.2.3. Reliability
	The usage of SCTP for the CLUE data channel ensures reliable		The usage of SCTP for the CLUE data channel ensures reliable
	transport of CLUE protocol [I-D.ietf-clue-protocol] messages.		transport of CLUE protocol [I-D.ietf-clue-protocol] messages.
	A CLUE entity MUST NOT use the partial reliability or limited		[I-D.ietf-rtcweb-data-channel] requires the support of the partial
	retransmission SCTP extensions, described in [RFC3758], for the CLUE		reliability extension defined in [RFC3758] and the limited
	data channel.		retransmission policy defined in [RFC7496]. A CLUE entity MUST NOT
			use these extensions, as messages are required to always be sent
	NOTE: [I-D.ietf-rtcweb-data-channel] requires the support of the		reliably. A CLUE entity MUST terminate the session if it detects
	partial reliability extension defined in [RFC3758]. This is not		that the peer entity uses any of the extensions.
	needed for a CLUE data channel, as messages are required to always be
	sent reliably. [I-D.ietf-rtcweb-data-channel] also mandates support
	of the limited retransmission policy defined in [RFC7496].
	3.2.4. Order		3.2.4. Order
	A CLUE entity MUST use the ordered delivery SCTP service, as		A CLUE entity MUST use the ordered delivery SCTP service, as
	described in [RFC4960], for the CLUE data channel.		described in [RFC4960], for the CLUE data channel.
	3.2.5. Stream Reset		3.2.5. Stream Reset
	A CLUE entity MUST support the stream reset extension defined in		A CLUE entity MUST support the stream reset extension defined in
	[RFC6525].		[RFC6525].
	skipping to change at page 5, line 41 ¶		skipping to change at page 5, line 28 ¶
	reconfiguration extension ('Supported Extensions Parameter'		reconfiguration extension ('Supported Extensions Parameter'
	parameter) defined in [RFC5061] must be used to signal the support of		parameter) defined in [RFC5061] must be used to signal the support of
	the stream reset extension defined in [RFC6525]. Other features of		the stream reset extension defined in [RFC6525]. Other features of
	[RFC5061] MUST NOT be used for CLUE data channels.		[RFC5061] MUST NOT be used for CLUE data channels.
	3.2.6. SCTP Multihoming		3.2.6. SCTP Multihoming
	SCTP multi-homing is not supported for SCTPoDTLS associations, and		SCTP multi-homing is not supported for SCTPoDTLS associations, and
	can therefore not be used for a CLUE data channel.		can therefore not be used for a CLUE data channel.
	3.2.7. Close CLUE data channel		3.2.7. Closing the CLUE data channel
	As described in [I-D.ietf-rtcweb-data-protocol], in order to close a		As described in [I-D.ietf-rtcweb-data-channel], in order to close a
	data channel, an entity sends an SCTP reset message [RFC6525] on its		data channel, an entity sends an SCTP reset message [RFC6525] on its
	outgoing SCTP stream associated with the data channel. When the		outgoing SCTP stream associated with the data channel. When the
	remote peer receives the reset message, it also sends (unless already		remote peer receives the reset message, it also sends (unless already
	sent) a reset message on its outgoing SCTP stream associated with the		sent) a reset message on its outgoing SCTP stream associated with the
	data channel. The SCTPoDTLS association, and other data channels		data channel. The SCTPoDTLS association, and other data channels
	established on the same association, are not affected by the SCTP		established on the same association, are not affected by the SCTP
	reset messages.		reset messages.
	3.3. SDP Considerations		3.3. SDP Considerations
	3.3.1. General		3.3.1. General
	This section defines how to construct the SDP Media Description (m-		This section defines how to construct the SDP Media Description ("m="
	line) for describing the SCTPoDTLS association used to realize a CLUE		line) for describing the SCTPoDTLS association used to realize a CLUE
	data channel. The section also defines how to use the SDP-based		data channel. The section also defines how to use the SDP-based
	"SCTP over DTLS" data channel negotiation mechanism		"SCTP over DTLS" data channel negotiation mechanism
	[I-D.ietf-mmusic-data-channel-sdpneg] for establishing a CLUE data		[I-D.ietf-mmusic-data-channel-sdpneg] for establishing a CLUE data
	channel on the SCTPoDTLS association.		channel on the SCTPoDTLS association.
	NOTE: Other protocols than SDP for negotiating usage of an SCTPoDTLS		NOTE: Other protocols than SDP for negotiating usage of an SCTPoDTLS
	association for realizing a CLUE data channel are outside the scope		association for realizing a CLUE data channel are outside the scope
	of this specification.		of this specification.
	[I-D.ietf-clue-signaling] describes the SDP Offer/Answer procedures		[I-D.ietf-clue-signaling] describes the SDP Offer/Answer procedures
	for negotiating a CLUE session, including the CLUE controlled media		for negotiating a CLUE session, including the CLUE controlled media
	streams and the CLUE data channel.		streams and the CLUE data channel.
	3.3.1.1. SDP Media Description Fields		3.3.1.1. SDP Media Description Fields
	As defined in [I-D.ietf-mmusic-sctp-sdp], the field values of an m-		As defined in [I-D.ietf-mmusic-sctp-sdp], the field values of an "m="
	line describing an SCTPoDTLS association are set as following:		line describing an SCTPoDTLS association are set as following:
	+---------------+--------------+-----------------+------------------+		+---------------+--------------+-----------------+------------------+
	| media | port | proto | fmt |		| media | port | proto | fmt |
	+---------------+--------------+-----------------+------------------+		+---------------+--------------+-----------------+------------------+
	| "application" | UDP port | "UDP/DTLS/SCTP" | application |		| "application" | UDP port | "UDP/DTLS/SCTP" | application |
	| | value | | usage |		| | value | | usage |
	| "application" | TCP port | "TCP/DTLS/SCTP" | application |		| "application" | TCP port | "TCP/DTLS/SCTP" | application |
	| | value | | usage |		| | value | | usage |
	+---------------+--------------+-----------------+------------------+		+---------------+--------------+-----------------+------------------+
	skipping to change at page 7, line 9 ¶		skipping to change at page 6, line 44 ¶
	transport is required).		transport is required).
	As defined in [I-D.ietf-mmusic-sctp-sdp], when the SCTPoDTLS		As defined in [I-D.ietf-mmusic-sctp-sdp], when the SCTPoDTLS
	association is used to realize a WebRTC data channel, the value of		association is used to realize a WebRTC data channel, the value of
	the application usage part is 'webrtc-datachannel'.		the application usage part is 'webrtc-datachannel'.
	3.3.1.2. SDP sctp-port Attribute		3.3.1.2. SDP sctp-port Attribute
	As defined in [I-D.ietf-mmusic-sctp-sdp], the SDP sctp-port attribute		As defined in [I-D.ietf-mmusic-sctp-sdp], the SDP sctp-port attribute
	value is set to the SCTP port of the SCTPoDTLS association. A CLUE		value is set to the SCTP port of the SCTPoDTLS association. A CLUE
	entity can choose any valid SCTP port value.		entity can choose any valid SCTP port value
			[I-D.ietf-mmusic-sctp-sdp].
	3.3.2. SDP dcmap Attribute		3.3.2. SDP dcmap Attribute
	The values of the SDP dcmap attribute		The values of the SDP dcmap attribute
	[I-D.ietf-mmusic-data-channel-sdpneg], associated with the m- line		[I-D.ietf-mmusic-data-channel-sdpneg], associated with the "m=" line
	describing the SCTPoDTLS association used to realize the WebRTC data		describing the SCTPoDTLS association used to realize the WebRTC data
	channel, are set as following:		channel, are set as following:
	+----------+------------+------------+--------+----------+----------+		+----------+------------+------------+--------+----------+----------+
	| stream- | subprotoco | label | ordere | max-retr | max-time |		| stream- | subprotoco | label | ordere | max-retr | max-time |
	| id | l | | d | | |		| id | l | | d | | |
	+----------+------------+------------+--------+----------+----------+		+----------+------------+------------+--------+----------+----------+
	| Value of | "CLUE" | Applicatio | "true" | N/A | N/A |		| Value of | "CLUE" | Applicatio | "true" | N/A | N/A |
	| the SCTP | | n specific | | | |		| the SCTP | | n specific | | | |
	| stream | | | | | |		| stream | | | | | |
	skipping to change at page 8, line 4 ¶		skipping to change at page 7, line 33 ¶
	[I-D.ietf-mmusic-data-channel-sdpneg] the max-retr and max-time		[I-D.ietf-mmusic-data-channel-sdpneg] the max-retr and max-time
	attribute parameters are not used when negotiating CLUE data		attribute parameters are not used when negotiating CLUE data
	channels.		channels.
	3.3.3. SDP dcsa Attribute		3.3.3. SDP dcsa Attribute
	The SDP dcsa attribute [I-D.ietf-mmusic-data-channel-sdpneg] is not		The SDP dcsa attribute [I-D.ietf-mmusic-data-channel-sdpneg] is not
	used when establishing a CLUE data channel.		used when establishing a CLUE data channel.
	3.3.4. Example		3.3.4. Example
			The example in Figure 1 shows an SDP media description for a CLUE
			data channel. Examples of complete SDP examples can be found in
			[I-D.ietf-clue-signaling].
	m=application 54111 UDP/DTLS/SCTP webrtc-datachannel		m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
	a=sctp-port: 5000		a=sctp-port: 5000
	a=dcmap:2 subprotocol="CLUE";ordered=true		a=dcmap:2 subprotocol="CLUE";ordered=true
	Figure 1: SDP Media Description for a CLUE data channel		Figure 1: SDP Media Description for a CLUE data channel
	4. Security Considerations		4. Security Considerations
	This specification relies on the security properties of the WebRTC		This specification relies on the security properties of the WebRTC
	data channel described in [I-D.ietf-rtcweb-data-channel], including		data channel described in [I-D.ietf-rtcweb-data-channel], including
	skipping to change at page 8, line 44 ¶		skipping to change at page 8, line 31 ¶
	6. Acknowledgments		6. Acknowledgments
	Thanks to Paul Kyzivat, Christian Groves and Mark Duckworth for		Thanks to Paul Kyzivat, Christian Groves and Mark Duckworth for
	comments on the document.		comments on the document.
	7. Change Log		7. Change Log
	[RFC EDITOR NOTE: Please remove this section when publishing]		[RFC EDITOR NOTE: Please remove this section when publishing]
			Changes from draft-ietf-clue-datachannel-15
			o Updates based on IESG review by Roman Danyliw.
			o Make CLUE references Informative, as they are going to be
			published as Experimental RFCs.
	Changes from draft-ietf-clue-datachannel-14		Changes from draft-ietf-clue-datachannel-14
	o ICE reference update.		o ICE reference update.
	o Reference draft versions updates.		o Reference draft versions updates.
	Changes from draft-ietf-clue-datachannel-13		Changes from draft-ietf-clue-datachannel-13
	o Editorial changes based on Gen-ART review from Brian Carpenter.		o Editorial changes based on Gen-ART review from Brian Carpenter.
	Changes from draft-ietf-clue-datachannel-12		Changes from draft-ietf-clue-datachannel-12
	skipping to change at page 10, line 43 ¶		skipping to change at page 10, line 37 ¶
	o Updates based on technical changes in referenced specifications.		o Updates based on technical changes in referenced specifications.
	o Reference to draft-ietf-mmusic-sctp-sdp added.		o Reference to draft-ietf-mmusic-sctp-sdp added.
	Changes from draft-ietf-clue-datachannel-03		Changes from draft-ietf-clue-datachannel-03
	o IANA considerations added.		o IANA considerations added.
	o Editorial changes based on comments from Christian Groves.		o Editorial changes based on comments from Christian Groves.
	Changes from draft-ietf-clue-datachannel-02		Changes from draft-ietf-clue-datachannel-02
	o SDP m- line example fixed.		o SDP "m=" line example fixed.
	o OPEN ISSUE #1 closed.		o OPEN ISSUE #1 closed.
	o - It was agreed (IETF#91) to use draft-ejzak-mmusic-data-channel-		o - It was agreed (IETF#91) to use draft-ejzak-mmusic-data-channel-
	sdpneg, as it was adopted as a WG item in MMUSIC.		sdpneg, as it was adopted as a WG item in MMUSIC.
	o - Details for draft-ejzak-mmusic-data-channel-sdpneg usage added.		o - Details for draft-ejzak-mmusic-data-channel-sdpneg usage added.
	o SDP Offer/Answer procedures removed, as they will be defined in		o SDP Offer/Answer procedures removed, as they will be defined in
	the CLUE protocol draft.		the CLUE protocol draft.
	o References updated.		o References updated.
	Changes from draft-ietf-clue-datachannel-01		Changes from draft-ietf-clue-datachannel-01
	o Support of interleaving "MUST"->"SHOULD".		o Support of interleaving "MUST"->"SHOULD".
	o Example updated.		o Example updated.
	o Reference update.		o Reference update.
	Changes from draft-ietf-clue-datachannel-00		Changes from draft-ietf-clue-datachannel-00
	o SDP Offer/Answer procedures structures according to RFC 3264.		o SDP Offer/Answer procedures structures according to RFC 3264.
	o Reference update.		o Reference update.
	Changes from draft-holmberg-clue-datachannel-04		Changes from draft-holmberg-clue-datachannel-04
	o Draft submitted as draft-ietf-clue-data-channel-00.		o Draft submitted as draft-ietf-clue-data-channel-00.
	o Editorial nits fixed.		o Editorial nits fixed.
	o Changes based on comments from Paul Kyzivat (http://www.ietf.org/		o Changes based on comments from Paul Kyzivat (http://www.ietf.org/
	mail-archive/web/clue/current/msg03559.html).		mail-archive/web/clue/current/msg03559.html).
	o - Proto value fixed.		o - Proto value fixed.
	o - Explicit text that the partial reliability and limited		o - Explicit text that the partial reliability and limited
	retransmission policies MUST NOT be used.		retransmission policies MUST NOT be used.
	o - Added open issue on whether the DCEP 'protocol' field value for		o - Added open issue on whether the DCEP 'protocol' field value for
	CLUE should contain a version number.		CLUE should contain a version number.
	o - Removed paragraph saying that an offerer must not insert more		o - Removed paragraph saying that an offerer must not insert more
	than one m- line describing an SCTPoDTLS association to be used to		than one "m=" line describing an SCTPoDTLS association to be used
	realize a CLUE data channel, as the draft already states that only		to realize a CLUE data channel, as the draft already states that
	one CLUE data channel per CLUE session shall be opened.		only one CLUE data channel per CLUE session shall be opened.
	o - Added reference to draft-ietf-rtcweb-data-protocol regarding		o - Added reference to draft-ietf-rtcweb-data-protocol regarding
	details on reseting SCTP streams.		details on reseting SCTP streams.
	o - Added text saying that the value of the DCEP 'channel type' MUST		o - Added text saying that the value of the DCEP 'channel type' MUST
	be DATA_CHANNEL_RELIABLE.		be DATA_CHANNEL_RELIABLE.
	o - Clarified that DCEP must be supported, and used in the absence		o - Clarified that DCEP must be supported, and used in the absence
	of another mechanism for opening a CLUE data channel.		of another mechanism for opening a CLUE data channel.
	Changes from draft-holmberg-clue-datachannel-03		Changes from draft-holmberg-clue-datachannel-03
	o Procedures updated, based on WG agreement (IETF#89) to use DCEP		o Procedures updated, based on WG agreement (IETF#89) to use DCEP
	skipping to change at page 12, line 4 ¶		skipping to change at page 11, line 46 ¶
	specifications.		specifications.
	Changes from draft-holmberg-clue-datachannel-02		Changes from draft-holmberg-clue-datachannel-02
	o PPID value for CLUE messages added		o PPID value for CLUE messages added
	o References updated		o References updated
	Changes from draft-holmberg-clue-datachannel-01		Changes from draft-holmberg-clue-datachannel-01
	o More text added		o More text added
	Changes from draft-holmberg-clue-datachannel-00		Changes from draft-holmberg-clue-datachannel-00
	o Editorial corrections based on comments from Paul K		o Editorial corrections based on comments from Paul K
	8. References		8. References
	8.1. Normative References		8.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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002,		DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc3261>.		editor.org/info/rfc3261>.
	[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model		[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
	with Session Description Protocol (SDP)", RFC 3264,		with Session Description Protocol (SDP)", RFC 3264,
	DOI 10.17487/RFC3264, June 2002,		DOI 10.17487/RFC3264, June 2002, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc3264>.		editor.org/info/rfc3264>.
	[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session		[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
	Description Protocol", RFC 4566, DOI 10.17487/RFC4566,		Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
	July 2006, <https://www.rfc-editor.org/info/rfc4566>.		July 2006, <https://www.rfc-editor.org/info/rfc4566>.
	[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",		[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
	RFC 4960, DOI 10.17487/RFC4960, September 2007,		RFC 4960, DOI 10.17487/RFC4960, September 2007,
	<https://www.rfc-editor.org/info/rfc4960>.		<https://www.rfc-editor.org/info/rfc4960>.
	[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.		[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
	Kozuka, "Stream Control Transmission Protocol (SCTP)		Kozuka, "Stream Control Transmission Protocol (SCTP)
	Dynamic Address Reconfiguration", RFC 5061,		Dynamic Address Reconfiguration", RFC 5061,
	DOI 10.17487/RFC5061, September 2007,		DOI 10.17487/RFC5061, September 2007, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc5061>.		editor.org/info/rfc5061>.
	[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control		[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control
	Transmission Protocol (SCTP) Stream Reconfiguration",		Transmission Protocol (SCTP) Stream Reconfiguration",
	RFC 6525, DOI 10.17487/RFC6525, February 2012,		RFC 6525, DOI 10.17487/RFC6525, February 2012,
	<https://www.rfc-editor.org/info/rfc6525>.		<https://www.rfc-editor.org/info/rfc6525>.
	[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,		[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,
	"Additional Policies for the Partially Reliable Stream		"Additional Policies for the Partially Reliable Stream
	Control Transmission Protocol Extension", RFC 7496,		Control Transmission Protocol Extension", RFC 7496,
	DOI 10.17487/RFC7496, April 2015,		DOI 10.17487/RFC7496, April 2015, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc7496>.		editor.org/info/rfc7496>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,		[RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,
	"Datagram Transport Layer Security (DTLS) Encapsulation of		"Datagram Transport Layer Security (DTLS) Encapsulation of
	SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November		SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November
	2017, <https://www.rfc-editor.org/info/rfc8261>.		2017, <https://www.rfc-editor.org/info/rfc8261>.
	[I-D.ietf-clue-protocol]
	Presta, R. and S. Romano, "CLUE protocol", draft-ietf-
	clue-protocol-16.txt (work in progress), August 2018.
	[I-D.ietf-clue-signaling]
	Kyzivat, P., Xiao, L., Groves, C., and S. Romano, "CLUE
	Signaling", draft-ietf-clue-signaling-13.txt (work in
	progress), November 2017.
	[I-D.ietf-mmusic-sctp-sdp]		[I-D.ietf-mmusic-sctp-sdp]
	Holmberg, C., Loreto, S., and G. Camarillo, "Stream		Holmberg, C., Loreto, S., and G. Camarillo, "Stream
	Control Transmission Protocol (SCTP)-Based Media Transport		Control Transmission Protocol (SCTP)-Based Media Transport
	in the Session Description Protocol (SDP)", draft-ietf-		in the Session Description Protocol (SDP)", draft-ietf-
	mmusic-sctp-sdp-26.txt (work in progress), April 2017.		mmusic-sctp-sdp-26.txt (work in progress), April 2017.
	[I-D.ietf-rtcweb-data-channel]		[I-D.ietf-rtcweb-data-channel]
	Jesup, R., Loreto, S., and M. Tuexen, "WebRTC data		Jesup, R., Loreto, S., and M. Tuexen, "WebRTC data
	channels", draft-ietf-rtcweb-data-channel-13.txt (work in		channels", draft-ietf-rtcweb-data-channel-13.txt (work in
	progress), January 2015.		progress), January 2015.
	[I-D.ietf-mmusic-data-channel-sdpneg]		[I-D.ietf-mmusic-data-channel-sdpneg]
	Drage, K., Makaraju, R., Stoetzer-Bradler, J., Ejzak, R.,		Drage, K., Makaraju, R., Stoetzer-Bradler, J., Ejzak, R.,
	and J. Marcon, "SDP-based "SCTP over DTLS" data channel		and J. Marcon, "SDP-based "SCTP over DTLS" data channel
	negotiation", draft-ietf-mmusic-data-channel-sdpneg-20.txt		negotiation", draft-ietf-mmusic-data-channel-sdpneg-25.txt
	(work in progress), June 2018.		(work in progress), March 2019.
	8.2. Informative References		8.2. Informative References
	[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.		[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
	Conrad, "Stream Control Transmission Protocol (SCTP)		Conrad, "Stream Control Transmission Protocol (SCTP)
	Partial Reliability Extension", RFC 3758,		Partial Reliability Extension", RFC 3758,
	DOI 10.17487/RFC3758, May 2004,		DOI 10.17487/RFC3758, May 2004, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc3758>.		editor.org/info/rfc3758>.
	[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive		[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
	Connectivity Establishment (ICE): A Protocol for Network		Connectivity Establishment (ICE): A Protocol for Network
	Address Translator (NAT) Traversal", RFC 8445,		Address Translator (NAT) Traversal", RFC 8445,
	DOI 10.17487/RFC8445, July 2018,		DOI 10.17487/RFC8445, July 2018, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc8445>.		editor.org/info/rfc8445>.
	[I-D.ietf-rtcweb-data-protocol]		[I-D.ietf-rtcweb-data-protocol]
	Jesup, R., Loreto, S., and M. Tuexen, "WebRTC data channel		Jesup, R., Loreto, S., and M. Tuexen, "WebRTC data channel
	Establishment Protocol", draft-ietf-rtcweb-data-protocol-		Establishment Protocol", draft-ietf-rtcweb-data-protocol-
	09.txt (work in progress), January 2015.		09.txt (work in progress), January 2015.
			[I-D.ietf-clue-protocol]
			Presta, R. and S. Romano, "CLUE protocol", draft-ietf-
			clue-protocol-17.txt (work in progress), September 2018.
			[I-D.ietf-clue-signaling]
			Kyzivat, P., Xiao, L., Groves, C., and S. Romano, "CLUE
			Signaling", draft-ietf-clue-signaling-14.txt (work in
			progress), October 2018.
	Author's Address		Author's Address
	Christer Holmberg		Christer Holmberg
	Ericsson		Ericsson
	Hirsalantie 11		Hirsalantie 11
	Jorvas 02420		Jorvas 02420
	Finland		Finland
	Email: christer.holmberg@ericsson.com		Email: christer.holmberg@ericsson.com
End of changes. 44 change blocks.
	84 lines changed or deleted		90 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/