rfc8850xml2.original.xml		rfc8850.xml
	<?xml version="1.0" encoding="iso-8859-1"?>		<?xml version='1.0' encoding='utf-8'?>
			<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
	<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC		category="exp" docName="draft-ietf-clue-datachannel-18" number="8850"
	.2119.xml">		obsoletes="" updates="" submissionType="IETF" consensus="true" xml:lang="en
	<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC		" tocInclude="true" sortRefs="true" version="3">
	.3261.xml">		<!-- xml2rfc v2v3 conversion 2.38.1 -->
	<!ENTITY RFC3264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC		<front>
	.3264.xml">		<title abbrev="CLUE Data Channel">Controlling Multiple Streams for
			Telepresence (CLUE) Protocol Data&nbsp;Channel</title>
	]>
	<?rfc toc="yes" ?>
	<?rfc compact="yes" ?>
	<?rfc subcompact="yes" ?>
	<?rfc sortrefs="no" ?>
	<?rfc strict="yes" ?>
	<rfc ipr="trust200902" category="exp" docName="draft-ietf-clue-datachannel-18" o
	bsoletes="" updates="" submissionType="IETF" xml:lang="en">
	<front>
	<title abbrev="CLUE data channel">
	CLUE Protocol data channel
	</title>
	<author initials="C.H." surname="Holmberg" fullname="Christer Hol
	mberg">
	<organization>Ericsson</organization>
	<address>
	<postal>
	<street>Hirsalantie 11</street>
	<code>02420</code>
	<city>Jorvas</city>
	<country>Finland</country>
	</postal>
	<email>christer.holmberg@ericsson.com</email>
	</address>
	</author>
	<date year="2019" />		<seriesInfo name="RFC" value="8850"/>
	<area>Transport</area>		<author initials="C." surname="Holmberg" fullname="Christer Holmberg">
	<workgroup>CLUE Working Group</workgroup>		<organization>Ericsson</organization>
	<keyword>SIP</keyword>		<address>
	<keyword>SDP</keyword>		<postal>
	<keyword>DTLS</keyword>		<street>Hirsalantie 11</street>
	<keyword>SCTP</keyword>		<code>02420</code>
	<keyword>DATA</keyword>		<city>Jorvas</city>
	<keyword>CHANNEL</keyword>		<country>Finland</country>
	<keyword>DCEP</keyword>		</postal>
	<keyword>DATA_CHANNEL_OPEN</keyword>		<email>christer.holmberg@ericsson.com</email>
	<keyword>DATA_CHANNEL_ACK</keyword>		</address>
	<keyword>PPID</keyword>		</author>
	<keyword>TELEPRESENCE</keyword>		<date month="January" year="2021"/>
	<keyword>RTCWEB</keyword>
	<keyword>WEBRTC</keyword>
	<abstract>
	<t>
	This document defines how to use the WebRTC data
	channel
	mechanism to realize a data channel, referred to
	as a CLUE data channel, for transporting CLUE pro
	tocol
	messages between two CLUE entities.
	</t>
	</abstract>
	</front>
	<middle>		<keyword>SIP</keyword>
	<section title="Introduction" toc="default">		<keyword>SDP</keyword>
	<t>		<keyword>DTLS</keyword>
	This document defines how to use the WebRTC data		<keyword>SCTP</keyword>
	channel		<keyword>DATA</keyword>
	mechanism <xref target="I-D.ietf-rtcweb-data-chan		<keyword>CHANNEL</keyword>
	nel"		<keyword>DCEP</keyword>
	pageno="false" format="default" /> to realize a		<keyword>DATA_CHANNEL_OPEN</keyword>
	data channel, referred to as a CLUE data channel,		<keyword>DATA_CHANNEL_ACK</keyword>
	for		<keyword>PPID</keyword>
	transporting CLUE protocol <xref target="I-D.ietf		<keyword>TELEPRESENCE</keyword>
	-clue-protocol"		<keyword>RTCWEB</keyword>
	pageno="false" format="default" /> messages betwe		<keyword>WEBRTC</keyword>
	en two CLUE entities.		<abstract>
	</t>		<t>
	<t>		This document defines how to use the WebRTC data channel
	The document defines how to describe the SCTPoDTL		mechanism to realize a data channel, referred to
	S association		as a Controlling Multiple Streams for Telepresence (CLUE) data channel,
	<xref target="RFC8261" pageno="false" format="def		for transporting CLUE protocol
	ault" /> used to		messages between two CLUE entities.
			</t>
			</abstract>
			</front>
			<middle>
			<section toc="default" numbered="true">
			<name>Introduction</name>
			<t>
			This document defines how to use the WebRTC data channel
			mechanism <xref target="RFC8831" format="default"/> to realize a
			data channel, referred to as a Controlling Multiple Streams for
			Telepresence (CLUE) data channel, for
			transporting CLUE protocol messages <xref target="RFC8847" format="defau
			lt"/> between two CLUE entities.
			</t>
			<t>
			This document also defines how to describe the SCTPoDTLS association
			<xref target="RFC8261" format="default"/> (also referred to as
			"SCTP over DTLS" in this document) used to
	realize the CLUE data channel using the Session Description Prot ocol (SDP)		realize the CLUE data channel using the Session Description Prot ocol (SDP)
	<xref target="RFC4566" pageno="false" format="default" />, and d		<xref target="RFC4566" format="default"/> and defines usage of t
	efines usage of the		he
	SDP-based "SCTP over DTLS" data channel negotiati		SDP-based "SCTP over DTLS" data channel negotiation mechanism
	on mechanism		<xref target="RFC8864" format="default"/>. ("SCTP" stands for "Stream
	<xref target="I-D.ietf-mmusic-data-channel-sdpneg		Control Transmission Protocol".) This includes SCTP
	"		considerations specific to a CLUE data channel, the SDP media
	pageno="false" format="default" />. This includes		description ("m=" line) values, and usage of SDP attributes specific
	SCTP		to a CLUE data channel.
	considerations specific to a CLUE data channel, t		</t>
	he SDP Media		<t>
	Description ("m=" line) values, and usage of SDP		Details and procedures associated with the CLUE protocol, and the
	attributes specific		SDP Offer/Answer procedures <xref target="RFC3264" format="default"/>
	to a CLUE data channel.		for negotiating usage of a CLUE data channel, are outside
	</t>		the scope of this document.
	<t>		</t>
	Details and procedures associated with the CLUE p
	rotocol, and the
	SDP Offer/Answer <xref target="RFC3264" pageno="f
	alse" format="default" />
	procedures for negotiating usage of a CLUE data c
	hannel, are outside
	the scope of this document.
	</t>
	<t>
	NOTE: The usage of the Data Channel Establishment
	Protocol (DCEP)
	<xref target="I-D.ietf-rtcweb-data-protocol" page
	no="false" format="default" />
	for establishing a CLUE data channel is outside t
	he scope of this document.
	</t>
	</section>
	<section title="Conventions" toc="default">
	<t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "S
	HALL
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMME
	NDED",
	"MAY", and "OPTIONAL" in this document are to be interpre
	ted as
	described in BCP 14 <xref target="RFC2119"></xref> <xref
	target="RFC8174"></xref>
	when, and only when, they appear in all capitals, as show
	n here.
	</t>
	<t>
	SCTPoDTLS association refers to an SCTP associati
	on carried
	over an DTLS connection <xref target="RFC8261" pa
	geno="false" format="default" />.
	</t>
	<t>
	WebRTC data channel refers to a pair of SCTP stre
	ams over a
	SCTPoDTLS association that is used to transport n
	on-media
	data between two entities, as defined in <xref ta
	rget="I-D.ietf-rtcweb-data-channel"
	pageno="false" format="default" />.
	</t>
	<t>
	CLUE data channel refers to a WebRTC data channel
	<xref
	target="I-D.ietf-rtcweb-data-channel" pageno="fal
	se"
	format="default" /> realization, with a specific
	set of
	SCTP characteristics, with the purpose of transpo
	rting CLUE
	protocol <xref target="I-D.ietf-clue-protocol" pa
	geno="false"
	format="default" /> messages between two CLUE ent
	ities.
	</t>
	<t>
	CLUE entity refers to a SIP User Agent (UA) <xref
	target="RFC3261"
	pageno="false" format="default" /> that supports
	the CLUE data channel
	and the CLUE protocol.
	</t>
	<t>
	CLUE session refers to a SIP session <xref target
	="RFC3261"
	pageno="false" format="default" /> between two SI
	P UAs, where a
	CLUE data channel, associated with the SIP sessio
	n, has been
	established between the SIP UAs.
	</t>
	<t>
	SCTP stream is defined in <xref target="RFC4960"
	pageno="false"
	format="default" /> as a unidirectional logical c
	hannel
	established from one to another associated SCTP e
	ndpoint,
	within which all user messages are delivered in s
	equence except
	for those submitted to the unordered delivery ser
	vice.
	</t>
	<t>
	SCTP identifier is defined in <xref target="RFC49
	60" pageno="false"
	format="default" /> as an unsigned integer, which
	identifies an SCTP stream.
	</t>
	</section>
	<section anchor="section.dtls" title="CLUE data channel" toc="def		<aside><t>NOTE: The usage of the Data Channel Establishment Protocol (DC
	ault">		EP)
	<section anchor="section.cdc.gen" title="General" toc="de		<xref target="RFC8832" format="default"/>
	fault">		for establishing a CLUE data channel is outside the scope of this docume
	<t>		nt.</t></aside>
	This section describes the realization of		</section>
	a CLUE data channel,		<section toc="default" numbered="true">
	using the WebRTC data channel mechanism.		<name>Conventions</name>
	This includes a set of SCTP characteristi		<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	cs specific to a		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
	CLUE data channel, the values of the "m="		"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
	line describing		"<bcp14>SHOULD NOT</bcp14>",
	the SCTPoDTLS association associated with		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	the WebRTC		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
	data channel, and the usage of the SDP-ba		to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
	sed "SCTP		<xref target="RFC8174"/> when, and only when, they appear in all capitals,
	over DTLS" data channel negotiation mecha		as shown here.</t>
	nism for creating the
	CLUE data channel.
	</t>
	<t>
	As described in <xref target="I-D.ietf-rt
	cweb-data-channel"
	pageno="false" format="default" />, the S
	CTP streams realizing
	a WebRTC data channel must be associated
	with the same SCTP association.
	In addition, both SCTP streams realizing
	the WebRTC data channel must
	use the same SCTP stream identifier value
	. These rules also apply to
	a CLUE data channel.
	</t>
	<t>
	Within a given CLUE session, a CLUE entit
	y MUST use a single CLUE
	data channel for transport of all CLUE me
	ssages towards its peer.
	</t>
	</section>
	<section anchor="section.cdc.sctp" title="SCTP Considerat		<dl newline="true" spacing="normal">
	ions" toc="default">		<dt>SCTPoDTLS association</dt>
	<section anchor="section.cdc.sctp.gen" title="Gen		<dd>Refers to an SCTP association carried over a DTLS connection <xref
	eral" toc="default">		target="RFC8261" format="default"/>.</dd>
	<t>
	As described in <xref target="I-D
	.ietf-rtcweb-data-channel"
	pageno="false" format="default" /
	>, different SCTP options
	(e.g., regarding ordered delivery
	), can be used for a
	data channel. This section descri
	bes the SCTP options
	used for a CLUE data channel. <xr
	ef target="section.oa" pageno="false"
	format="default" /> describes how
	SCTP options are signaled using SDP.
	</t>
	<t>
	NOTE: While SCTP allows SCTP opti
	ons to be applied per SCTP message,
	<xref target="I-D.ietf-rtcweb-dat
	a-channel" pageno="false" format="default" />
	mandates that, for a given data c
	hannel, the same SCTP options are applied
	to each SCTP message associated w
	ith that data channel.
	</t>
	</section>
	<section anchor="section.cdc.sctp.ppid" title="SC
	TP Payload Protocol Identifier (PPID)" toc="default">
	<t>
	A CLUE entity MUST use the PPID v
	alue 51 when sending a CLUE message
	on a CLUE data channel.
	</t>
	<t>
	NOTE: As described in <xref targe
	t="I-D.ietf-rtcweb-data-channel"
	pageno="false" format="default" /
	>, the PPID value 51 indicates that
	the SCTP message contains data en
	coded in a UTF-8 format. The PPID
	value 51 does not indicate which
	application protocol the SCTP message
	is associated with, only the form
	at in which the data is encoded.
	</t>
	</section>
	<section anchor="section.cdc.sctp.reliability" ti
	tle="Reliability" toc="default">
	<t>
	The usage of SCTP for the CLUE da
	ta channel ensures reliable transport of
	CLUE protocol <xref target="I-D.i
	etf-clue-protocol" pageno="false" format="default" />
	messages.
	</t>
	<t>
	<xref target="I-D.ietf-rtcweb-dat
	a-channel" pageno="false" format="default" />
	requires the support of the parti
	al reliability extension defined in <xref target="RFC3758"
	pageno="false" format="default" /
	> and the limited retransmission policy defined in
	<xref target="RFC7496" pageno="fa
	lse" format="default" />. A CLUE entity MUST NOT use
	these extensions, as messages are
	required to always be sent reliably. A CLUE entity MUST
	terminate the session if it detec
	ts that the peer entity uses any of the extensions.
	</t>
	</section>
	<section anchor="section.cdc.sctp.order" title="O
	rder" toc="default">
	<t>
	A CLUE entity MUST use the ordere
	d delivery SCTP service, as
	described in <xref target="RFC496
	0" pageno="false" format="default" />,
	for the CLUE data channel.
	</t>
	</section>
	<section anchor="section.cdc.sctp.streamreset" ti
	tle="Stream Reset" toc="default">
	<t>
	A CLUE entity MUST support the st
	ream reset extension defined in <xref target="RFC6525"
	pageno="false" format="default" /
	>.
	</t>
	<t>
	As defined in <xref target="I-D.i
	etf-rtcweb-data-channel" pageno="false" format="default" />,
	the dynamic address reconfigurati
	on extension ('Supported Extensions Parameter' parameter)
	defined in <xref target="RFC5061"
	pageno="false" format="default" /> must be used to signal the
	support of the stream reset extension defined in <xref target="RFC65
	25" pageno="false"
	format="default" />. Other featur
	es of <xref target="RFC5061" pageno="false" format="default" />
	MUST NOT be used for CLUE data channels.
	</t>
	</section>
	<section anchor="section.cdc.sctp.multihome" titl
	e="SCTP Multihoming" toc="default">
	<t>
	SCTP multi-homing is not supporte
	d for SCTPoDTLS associations, and can therefore
	not be used for a CLUE data chann
	el.
	</t>
	</section>
	<section anchor="section.cdcp.proc.close" title="
	Closing the CLUE data channel" toc="default">
	<t>
	As described in <xref target="I-D
	.ietf-rtcweb-data-channel" pageno="false"
	format="default" />, to close a d
	ata channel, an entity sends an SCTP reset
	message <xref target="RFC6525" pa
	geno="false" format="default" /> on its outgoing
	SCTP stream associated with the d
	ata channel. When the remote peer receives the reset
	message, it also sends (unless al
	ready sent) a reset message on its outgoing SCTP
	stream associated with the data c
	hannel. The SCTPoDTLS association, and other data channels
	established on the same associati
	on, are not affected by the SCTP reset messages.
	</t>
	</section>
	</section>
	<section anchor="section.oa" title="SDP Considerations" t		<dt>WebRTC data channel</dt>
	oc="default">		<dd>Refers to a pair of SCTP streams over an
	<section anchor="section.oa.gen" title="General"		SCTPoDTLS association that is used to transport non-media
	toc="default">		data between two entities, as defined in <xref
	<t>		target="RFC8831" format="default"/>.</dd>
	This section defines how to const
	ruct the SDP Media Description
	("m=" line) for describing the SC
	TPoDTLS association used to realize
	a CLUE data channel. The section
	also defines how to use the
	SDP-based "SCTP over DTLS" data
	channel negotiation mechanism
	<xref target="I-D.ietf-mmusic-dat
	a-channel-sdpneg" /> for establishing
	a CLUE data channel on the SCTPoD
	TLS association.
	</t>
	<t>
	NOTE: Other protocols than SDP fo
	r negotiating usage of an SCTPoDTLS
	association for realizing a CLUE
	data channel are outside the scope
	of this specification.
	</t>
	<t>
	<xref target="I-D.ietf-clue-signa
	ling" pageno="false" format="default" />
	describes the SDP Offer/Answer pr
	ocedures for negotiating a CLUE session,
	including the CLUE controlled med
	ia streams and the CLUE data channel.
	</t>
	<section anchor="section.oa.mediadesc" ti
	tle="SDP Media Description Fields" toc="default">
	<t>
	<xref target="I-D.ietf-mmusic
	-sctp-sdp" pageno="false" format="default" /> defines how
	to set the values of an "
	m=" line describing an SCTPoDTLS association. As defined in
	<xref target="I-D.ietf-mm
	usic-sctp-sdp" pageno="false" format="default" />, for a
	CLUE data channel the val
	ues are set as following:
	</t>
	<texttable anchor="table_SDP_medi
	adesc" title='SDP "proto" field values'>
	<ttcol align='center'>med
	ia</ttcol>
	<ttcol align='center'>por
	t</ttcol>
	<ttcol align='center'>pro
	to</ttcol>
	<ttcol align='center'>fmt
	</ttcol>
	<c>"application"</c>
	<c>UDP port value</c>
	<c>"UDP/DTLS/SCTP"</c>
	<c>"webrtc-datachannel"</
	c>
	<c>"application"</c>
	<c>TCP port value</c>
	<c>"TCP/DTLS/SCTP"</c>
	<c>"webrtc-datachannel"</
	c>
	</texttable>
	<t>
	CLUE entities SHOULD NOT
	transport the SCTPoDTLS association used to
	realize the CLUE data cha
	nnel over TCP (using the "TCP/DTLS/SCTP"
	proto value), unless it i
	s known that UDP/DTLS/SCTP will not work
	(for instance, when the I
	nteractive Connectivity Establishment
	(ICE) mechanism <xref for
	mat="default" pageno="false" target="RFC8445"/>
	is used and the ICE proce
	dures determine that TCP transport is required).
	</t>
	</section>
	<section anchor="section.oa.sctpport" tit
	le="SDP sctp-port Attribute" toc="default">
	<t>
	As defined in <xref targe
	t="I-D.ietf-mmusic-sctp-sdp" pageno="false" format="default"/>,
	the SDP sctp-port attribu
	te value is set to the SCTP port of the SCTPoDTLS association. A
	CLUE entity can choose an
	y valid SCTP port value <xref target="I-D.ietf-mmusic-sctp-sdp"
	pageno="false" format="de
	fault"/>.
	</t>
	</section>
	</section>
	<section anchor="section.oa.dcmap" title="SDP dcm
	ap Attribute" toc="default">
	<t>
	The values of the SDP dcmap attri
	bute <xref target="I-D.ietf-mmusic-data-channel-sdpneg"
	pageno="false" format="default" /
	>, associated with the "m=" line describing the SCTPoDTLS
	association used to realize the W
	ebRTC data channel, are set as following:
	</t>
	<texttable anchor="table_SDP_dcmap" title
	='SDP dcmap attribute values'>
	<ttcol align='center'>stream-id</
	ttcol>
	<ttcol align='center'>sub-protoco
	l</ttcol>
	<ttcol align='center'>label</ttco
	l>
	<ttcol align='center'>ordered</tt
	col>
	<ttcol align='center'>max-retr</t
	tcol>
	<ttcol align='center'>max-time</t
	tcol>
	<c>Value of the SCTP stream used
	to realize the CLUE data channel</c>
	<c>"CLUE"</c>
	<c>Appli-cation specific</c>
	<c>"true"</c>
	<c>N/A</c>
	<c>N/A</c>
	</texttable>
	<t>
	NOTE: As CLUE entities are requir
	ed to use ordered SCTP message delivery,
	with full reliability, according
	to the procedures in
	<xref target="I-D.ietf-mmusic-dat
	a-channel-sdpneg" pageno="false"
	format="default" /> the max-retr
	and max-time attribute parameters
	are not used when negotiating CLU
	E data channels.
	</t>
	</section>
	<section anchor="section.oa.dcsa" title="SDP dcsa
	Attribute" toc="default">
	<t>
	The SDP dcsa attribute <xref targ
	et="I-D.ietf-mmusic-data-channel-sdpneg" pageno="false"
	format="default" /> is not used w
	hen establishing a CLUE data channel.
	</t>
	</section>
	<section anchor="section.oa.example" title="Examp		<dt>CLUE data channel</dt>
	le" toc="default">		<dd>Refers to a WebRTC data channel realization <xref target="RFC8831" forma
	<t>		t="default"/>, with a specific set of
	The example in <xref target="figu		SCTP characteristics, with the purpose of transporting CLUE
	re_SDP_example" pageno="false" format="default" /> shows		protocol messages <xref target="RFC8847" format="default"/> between two CLUE ent
	an SDP media description for a CL		ities.</dd>
	UE data channel. Examples of complete SDP examples can be found
	in <xref target="I-D.ietf-clue-si
	gnaling" pageno="false" format="default" />.
	</t>
	<figure anchor="figure_SDP_example" title
	="SDP Media Description for a CLUE data channel">
	<artwork><![CDATA[
	m=application 54111 UDP/DTLS/SCTP webrtc-datachannel		<dt>CLUE entity</dt>
	a=sctp-port: 5000		<dd>Refers to a SIP User Agent (UA) <xref target="RFC3261" format="default"/
	a=dcmap:2 subprotocol="CLUE";ordered=true		> that supports the CLUE data channel
			and the CLUE protocol.</dd>
	]]></artwork>		<dt>CLUE session</dt>
	</figure>		<dd>Refers to a SIP session <xref target="RFC3261" format="default"/> betwee
	</section>		n two SIP UAs, where a
	</section>		CLUE data channel, associated with the SIP session, has been
	</section>		established between the SIP UAs.</dd>
	<section anchor="section.sec" title="Security Considerations">		<dt>SCTP stream</dt>
			<dd>Defined in <xref target="RFC4960" format="default"/> as a unidirectional
			logical channel
			established from one to another associated SCTP endpoint,
			within which all user messages are delivered in sequence except
			for those submitted to the unordered delivery service.</dd>
			<dt>SCTP stream identifier</dt>
			<dd>Defined in <xref target="RFC4960" format="default"/> as an unsigned
			integer. Identifies an SCTP stream.</dd>
			</dl>
			</section>
			<section anchor="section.dtls" toc="default" numbered="true">
			<name>CLUE Data Channel</name>
			<section anchor="section.cdc.gen" toc="default" numbered="true">
			<name>General</name>
			<t>
			This section describes the realization of a CLUE data channel,
			using the WebRTC data channel mechanism.
			This includes a set of SCTP characteristics specific to a
			CLUE data channel, the values of the "m=" line describing
			the SCTPoDTLS association associated with the WebRTC
			data channel, and the usage of the SDP-based "SCTP
			over DTLS" data channel negotiation mechanism for creating the
			CLUE data channel.
			</t>
			<t>
			As described in <xref target="RFC8831" format="default"/>, the SCTP stre
			ams realizing
			a WebRTC data channel must be associated with the same SCTP association.
			In addition, both SCTP streams realizing the WebRTC data channel must
			use the same SCTP stream identifier value. These rules also apply to
			a CLUE data channel.
			</t>
			<t>
			Within a given CLUE session, a CLUE entity <bcp14>MUST</bcp14> use a sin
			gle CLUE
			data channel for transport of all CLUE messages towards its peer.
			</t>
			</section>
			<section anchor="section.cdc.sctp" toc="default" numbered="true">
			<name>SCTP Considerations</name>
			<section anchor="section.cdc.sctp.gen" toc="default" numbered="true">
			<name>General</name>
			<t>
			As described in <xref target="RFC8831" format="default"/>, diffe
			rent SCTP options
			(e.g., regarding ordered delivery) can be used for a
			data channel. This section describes the SCTP options
			used for a CLUE data channel. <xref target="section.oa" format="
			default"/> describes how SCTP options are signaled using SDP.
			</t>
			</section>
			<section anchor="section.cdc.sctp.ppid" toc="default" numbered="true">
			<name>SCTP Payload Protocol Identifier (PPID)</name>
			<t>
			A CLUE entity <bcp14>MUST</bcp14> use the PPID value 51 when sen
			ding a CLUE message
			on a CLUE data channel.
			</t>
			<aside><t>
			NOTE: As described in <xref target="RFC8831" format="default"
			/>, the PPID value 51 indicates that
			the SCTP message contains data encoded in UTF-8 format. The PPID
			value 51 does not indicate which application protocol the SCTP m
			essage
			is associated with -- only the format in which the data is encod
			ed.
			</t></aside>
			</section>
			<section anchor="section.cdc.sctp.reliability" toc="default" numbered="t
			rue">
			<name>Reliability</name>
			<t>
			The usage of SCTP for the CLUE data channel ensures reliable tra
			nsport of
			CLUE protocol messages <xref target="RFC8847" format="default"/>
			.</t>
			<t>
			<xref target="RFC8831" format="default"/>
			requires the support of the partial reliability extension defined
			in <xref target="RFC3758" format="default"/> and the limited retransmission pol
			icy defined in
			<xref target="RFC7496" format="default"/>. A CLUE entity <bcp14>M
			UST NOT</bcp14> use
			these extensions, as messages are required to always be sent rel
			iably. A CLUE entity <bcp14>MUST</bcp14>
			terminate the session if it detects that the peer entity uses an
			y of the extensions.
			</t>
			</section>
			<section anchor="section.cdc.sctp.order" toc="default" numbered="true">
			<name>Order</name>
			<t>
			A CLUE entity <bcp14>MUST</bcp14> use the ordered delivery SCTP
			service, as
			described in <xref target="RFC4960" format="default"/>,
			for the CLUE data channel.
			</t>
			</section>
			<section anchor="section.cdc.sctp.streamreset" toc="default" numbered="t
			rue">
			<name>Stream Reset</name>
			<t>
			A CLUE entity <bcp14>MUST</bcp14> support the stream reset exten
			sion defined in <xref target="RFC6525" format="default"/>.
			</t>
			<t>
			Per <xref target="RFC8831" format="default"/>,
			the dynamic address reconfiguration extension parameter ('Suppor
			ted Extensions Parameter')
			defined in <xref target="RFC5061" format="default"/> must be use
			d to signal the
			support of the stream reset extension defined in <xref
			target="RFC6525" format="default"/>.
			Other features defined in <xref target="RFC5061" format="default"/>
			<bcp14>MUST NOT</bcp14> be used for CLUE data channels.
			</t>
			</section>
			<section anchor="section.cdc.sctp.multihome" toc="default" numbered="tru
			e">
			<name>SCTP Multihoming</name>
			<t>
			SCTP multihoming is not supported for SCTPoDTLS associations
			and therefore cannot be used for a CLUE data channel.
			</t>
			</section>
			<section anchor="section.cdcp.proc.close" toc="default" numbered="true">
			<name>Closing the CLUE Data Channel</name>
			<t>
			As described in <xref target="RFC8831" format="default"/>, to cl
			ose a data channel, an entity sends an SCTP reset
			message <xref target="RFC6525" format="default"/> on its outgoin
			g
			SCTP stream associated with the data channel. When the remote pe
			er receives the reset
			message, it also sends (unless already sent) a reset message on
			its outgoing SCTP
			stream associated with the data channel. The SCTPoDTLS associati
			on, and other data channels
			established on the same association, are not affected by the SCT
			P reset messages.
			</t>
			</section>
			</section>
			<section anchor="section.oa" toc="default" numbered="true">
			<name>SDP Considerations</name>
			<section anchor="section.oa.gen" toc="default" numbered="true">
			<name>General</name>
			<t>This section defines how to (1) construct the SDP media description
			("m=" line) for describing the SCTPoDTLS association used to realize
			a CLUE data channel and (2)&nbsp;use the
			SDP-based "SCTP over DTLS" data channel negotiation mechanism
			<xref target="RFC8864" format="default"/> for establishing
			a CLUE data channel on the SCTPoDTLS association.</t>
			<aside><t>
			NOTE: Protocols other than SDP for negotiating usage of an SCTPo
			DTLS
			association for realizing a CLUE data channel are outside the sc
			ope
			of this specification.
			</t></aside>
			<t>
			<xref target="RFC8848" format="default"/>
			describes the SDP Offer/Answer procedures for negotiating a CLUE
			session,
			including the CLUE-controlled media streams and the CLUE data ch
			annel.
			</t>
			<section anchor="section.oa.mediadesc" toc="default" numbered="true">
			<name>SDP Media Description Fields</name>
			<t>
			<xref target="RFC8841" format="default"/> defines how
			to set the values of an "m=" line describing an SCTPoDTLS associ
			ation. As defined in
			<xref target="RFC8841" format="default"/>, for a
			CLUE data channel the values are set as follows:
			</t>
			<table anchor="table_SDP_mediadesc" align="center">
			<name>SDP "proto" Field Values</name>
			<thead>
			<tr>
			<th align="center">media</th>
			<th align="center">port</th>
			<th align="center">proto</th>
			<th align="center">fmt</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td align="center">"application"</td>
			<td align="center">UDP port value</td>
			<td align="center">"UDP/DTLS/SCTP"</td>
			<td align="center">"webrtc-datachannel"</td>
			</tr>
			<tr>
			<td align="center">"application"</td>
			<td align="center">TCP port value</td>
			<td align="center">"TCP/DTLS/SCTP"</td>
			<td align="center">"webrtc-datachannel"</td>
			</tr>
			</tbody>
			</table>
	<t>		<t>
			CLUE entities <bcp14>SHOULD NOT</bcp14> transport the SCTPoDTLS
			association used to
			realize the CLUE data channel over TCP (using the "TCP/DTLS/SCTP
			"
			proto value), unless it is known that UDP/DTLS/SCTP will not wor
			k
			(for instance, when the Interactive Connectivity Establishment
			(ICE) mechanism <xref format="default" target="RFC8445"/>
			is used and the ICE procedures determine that TCP transport is r
			equired).
			</t>
			</section>
			<section anchor="section.oa.sctpport" toc="default" numbered="true">
			<name>SDP sctp-port Attribute</name>
			<t>
			As defined in <xref target="RFC8841" format="default"/>,
			the SDP sctp-port attribute value is set to the SCTP port of the
			SCTPoDTLS association. A
			CLUE entity can choose any valid SCTP port value <xref target="R
			FC8841" format="default"/>.
			</t>
			</section>
			</section>
			<section anchor="section.oa.dcmap" toc="default" numbered="true">
			<name>SDP dcmap Attribute</name>
			<t>
			The values of the SDP dcmap attribute <xref target="RFC8864" for
			mat="default"/>, associated with the "m=" line describing the SCTPoDTLS
			association used to realize the WebRTC data channel, are set as
			follows:
			</t>
			<table anchor="table_SDP_dcmap" align="center">
			<name>SDP dcmap Attribute Values</name>
			<thead>
			<tr>
			<th align="center">stream-id</th>
			<th align="center">subprotocol</th>
			<th align="center">label</th>
			<th align="center">ordered</th>
			<th align="center">max-retr</th>
			<th align="center">max-time</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td align="center">Value of the SCTP stream used to realize the
			CLUE data channel</td>
			<td align="center">"CLUE"</td>
			<td align="center">Application specific</td>
			<td align="center">"true"</td>
			<td align="center">N/A</td>
			<td align="center">N/A</td>
			</tr>
			</tbody>
			</table>
			<aside><t>
			NOTE: As CLUE entities are required to use ordered SCTP message
			delivery,
			with full reliability, according to the procedures in
			<xref target="RFC8864" format="default"/> the max-retr and max-t
			ime attribute parameters
			are not used when negotiating CLUE data channels.
			</t></aside>
			</section>
			<section anchor="section.oa.dcsa" toc="default" numbered="true">
			<name>SDP dcsa Attribute</name>
			<t>
			The SDP dcsa attribute <xref target="RFC8864" format="default"/>
			is not used when establishing a CLUE data channel.
			</t>
			</section>
			<section anchor="section.oa.example" toc="default" numbered="true">
			<name>Example</name>
			<t>
			The example in <xref target="figure_SDP_example" format="default
			"/> shows
			an SDP media description for a CLUE data channel. Complete SDP e
			xamples can be found
			in <xref target="RFC8848" format="default"/>.
			</t>
			<figure anchor="figure_SDP_example">
			<name>SDP Media Description for a CLUE Data Channel</name>
			<sourcecode name="sdp-1" type="sdp"><![CDATA[
			m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
			a=sctp-port: 5000
			a=dcmap:2 subprotocol="CLUE";ordered=true]]></sourcecode> </figure>
			</section>
			</section>
			</section>
			<section anchor="section.sec" numbered="true" toc="default">
			<name>Security Considerations</name>
			<t>
	This specification relies on the security properties of the WebR TC data channel described in		This specification relies on the security properties of the WebR TC data channel described in
	<xref target="I-D.ietf-rtcweb-data-channel" pageno="false" forma t="default" />, including		<xref target="RFC8831" format="default"/>, including
	reliance on DTLS. Since CLUE sessions are established using SIP/ SDP, protecting the data		reliance on DTLS. Since CLUE sessions are established using SIP/ SDP, protecting the data
	channel against message modification and recovery requires the u se of SIP authentication		channel against message modification and recovery requires the u se of SIP authentication
	and authorization mechanisms described in <xref target="RFC3261" pageno="false" format="default" />		and authorization mechanisms described in <xref target="RFC3261" format="default"/>
	for session establishment prior to establishing the data channel .		for session establishment prior to establishing the data channel .
	</t>		</t>
	</section>		</section>
	<section anchor="section.iana" title="IANA Considerations">		<section anchor="section.iana" numbered="true" toc="default">
	<section anchor="section.iana.dc" title="New WebRTC data		<name>IANA Considerations</name>
	channel Protocol Value">		<section anchor="section.iana.dc" numbered="true" toc="default">
	<t>		<name>Subprotocol Identifier &quot;clue&quot;</name>
	[RFC EDITOR NOTE: Please replace RFC-XXXX		<t>
	with the RFC number of this document.]		This document adds the subprotocol identifier "clue" to the "WebSocket S
	</t>		ubprotocol Name Registry"
	<t>		as follows:
	This document adds the 'CLUE' value to th		</t>
	e "WebSocket Subprotocol Name Registry"
	as follows:
	</t>
	<figure>
	<artwork align="left"><![CDATA[
	Subprotocl Identifier: CLUE		<table anchor="clue-reg">
	Subprotocol Common Name: CLUE		<name>Registration of 'clue' Value</name>
	Subprotocol Definition: RFC-XXXX		<tbody>
	Reference: RFC-XXXX		<tr>
			<td>Subprotocol Identifier</td>
			<td>clue</td>
			</tr>
			<tr>
			<td>Subprotocol Common Name</td>
			<td>CLUE</td>
			</tr>
			<tr>
			<td>Subprotocol Definition</td>
			<td>RFC 8850</td>
			</tr>
			<tr>
			<td>Reference</td>
			<td>RFC 8850</td>
			</tr>
			</tbody>
			</table>
			</section>
			</section>
			</middle>
			<back>
			<references>
			<name>References</name>
			<references>
			<name>Normative References</name>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3264.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4566.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5061.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6525.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7496.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8261.
			xml"/>
	]]></artwork>		<!-- draft-ietf-mmusic-sctp-sdp (RFC 8841) -->
	</figure>		<reference anchor="RFC8841" target="https://www.rfc-editor.org/info/rfc8
	</section>		841">
	</section>		<front>
	<section title="Acknowledgments">		<title>Session Description Protocol (SDP) Offer/Answer Procedures
	<t>		for Stream Control Transmission Protocol (SCTP) over Datagram
	Thanks to Paul Kyzivat, Christian Groves and Mark		Transport Layer Security (DTLS) Transport</title>
	Duckworth for comments		<author initials="C" surname="Holmberg" fullname="Christer Holmberg"
	on the document.		>
	</t>		<organization/>
	</section>		</author>
	<section title="Change Log">		<author initials="R." surname="Shpount" fullname="Roman Shpount">
	<t>		<organization/>
	[RFC EDITOR NOTE: Please remove this section when		</author>
	publishing]		<author initials="S" surname="Loreto" fullname="Salvatore Loreto">
	</t>		<organization/>
	<t>		</author>
	Changes from draft-ietf-clue-datachannel-17		<author initials="G" surname="Camarillo" fullname="Gonzalo Camarillo
	<list style="symbols">		">
	<t>		<organization/>
	Editorial changes to Tables based on TSV-ART review.		</author>
	</t>		<date month="January" year="2021"/>
	</list>		</front>
	</t>		<seriesInfo name="RFC" value="8841"/>
	<t>		<seriesInfo name="DOI" value="10.17487/RFC8841"/>
	Changes from draft-ietf-clue-datachannel-16		</reference>
	<list style="symbols">
	<t>		<!-- draft-ietf-rtcweb-data-channel (RFC 8831) -->
	Category changed to Experimental.		<reference anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc8831">
	</t>		<front>
	</list>		<title>WebRTC Data Channels</title>
	</t>		<author initials="R" surname="Jesup" fullname="Randell Jesup">
	<t>		<organization/>
	Changes from draft-ietf-clue-datachannel-15		</author>
	<list style="symbols">		<author initials="S" surname="Loreto" fullname="Salvatore Loreto">
	<t>		<organization/>
	Updates based on IESG review by Roman Danyliw.		</author>
	</t>		<author initials="M" surname="Tüxen" fullname="Michael Tüxen">
	<t>		<organization/>
	Make CLUE references Informative, as they		</author>
	are going to be published as		<date month='January' year='2021'/>
	Experimental RFCs.		</front>
	</t>		<seriesInfo name="RFC" value="8831"/>
	</list>		<seriesInfo name="DOI" value="10.17487/RFC8831"/>
	</t>		</reference>
	<t>
	Changes from draft-ietf-clue-datachannel-14		<!-- draft-ietf-mmusic-data-channel-sdpneg (RFC 8864) -->
	<list style="symbols">		<reference anchor="RFC8864" target="https://www.rfc-editor.org/info/rfc886
	<t>		4">
	ICE reference update.		<front>
	</t>		<title>Negotiation Data Channels Using the Session Description
	<t>		Protocol (SDP)</title>
	Reference draft versions updates.		<author fullname="Keith Drage" initials="K." surname="Drage">
	</t>		<organization>Unaffiliated</organization>
	</list>		</author>
	</t>		<author fullname="Raju Makaraju" initials="M." surname="Makaraju">
	<t>		<organization>Nokia</organization>
	Changes from draft-ietf-clue-datachannel-13		</author>
	<list style="symbols">		<author fullname="Richard Ejzak" initials="R." surname="Ejzak">
	<t>		<organization>Unaffiliated</organization>
	Editorial changes based on Gen-ART review from Brian Carpent		</author>
	er.		<author fullname="Jerome Marcon" initials="J." surname="Marcon">
	</t>		<organization>Unaffiliated</organization>
	</list>		</author>
	</t>		<author fullname="Roni Even" initials="R." surname="Even" role="editor
	<t>		">
	Changes from draft-ietf-clue-datachannel-12		<organization>Huawei</organization>
	<list style="symbols">		</author>
	<t>		<date month="January" year="2021"/>
	Changes based on AD comments from Alissa Cooper (https://www.ietf.		</front>
	org/mail-archive/web/clue/current/msg04911.html):		<seriesInfo name="RFC" value="8864"/>
	</t>		<seriesInfo name="DOI" value="10.17487/RFC8864"/>
	<t>		</reference>
	- DCEP reference removed from s		</references>
	ecurity considerations.		<references>
	</t>		<name>Informative References</name>
	<t>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3758.
	- Editorial fixes.		xml"/>
	</t>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8445.
	<t>		xml"/>
	- NOTE: Comment regarding the S
	ecurity Considerations is still pending.		<!-- draft-ietf-rtcweb-data-protocol (RFC 8832) -->
	</t>		<reference anchor="RFC8832" target="https://www.rfc-editor.org/info/rfc8832">
	</list>		<front>
	</t>		<title>WebRTC Data Channel Establishment Protocol</title>
	<t>		<author initials='R.' surname='Jesup' fullname='Randell Jesup'>
	Changes from draft-ietf-clue-datachannel-11		<organization/>
	<list style="symbols">		</author>
	<t>		<author initials='S.' surname='Loreto' fullname='Salvatore Loreto'>
	Changes based on WGLC comments from Juergen Stoetzer-Bra		<organization/>
	dler and Christian groves:		</author>
	</t>		<author initials='M' surname='Tüxen' fullname='Michael Tüxen'>
	<t>		<organization/>
	- Reference updates.		</author>
	</t>		<date month='January' year='2021'/>
	<t>		</front>
	- 'Reference' added to IANA registration data.		<seriesInfo name="RFC" value="8832"/>
	</t>		<seriesInfo name="DOI" value="10.17487/RFC8832"/>
	</list>		</reference>
	</t>
	<t>		<!-- draft-ietf-clue-protocol (RFC 8847) -->
	Changes from draft-ietf-clue-datachannel-10		<reference anchor='RFC8847' target='https://www.rfc-editor.org/info/rfc8847'>
	<list style="symbols">		<front>
	<t>		<title>Protocol for Controlling Multiple Streams for Telepresence (CLUE)</title>
	Security Considerations modified and enhanced, based on		<author initials='R' surname='Presta' fullname='Roberta Presta'>
	comments		<organization />
	provided by Alissa Cooper.		</author>
	</t>		<author initials='S P.' surname='Romano' fullname='Simon Pietro Romano'>
	</list>		<organization />
	</t>		</author>
	<t>		<date month='January' year='2021' />
	Changes from draft-ietf-clue-datachannel-09		</front>
	<list style="symbols">		<seriesInfo name="RFC" value="8847" />
	<t>Reference updates:</t>		<seriesInfo name='DOI' value='10.17487/RFC8847' />
	<t> - draft-ietf-tsvwg-sctp-prpolicies published as RFC 7496		</reference>
	</t>
	<t> - Reference update of draft versions</t>		<!-- draft-ietf-clue-signaling (RFC 8848) -->
	</list>		<reference anchor="RFC8848" target="https://www.rfc-editor.org/info/rfc8
	</t>		848">
	<t>		<front>
	Changes from draft-ietf-clue-datachannel-08		<title>Session Signaling for Controlling Multiple Streams for Telepr
	<list style="symbols">		esence (CLUE)</title>
	<t>Changes based on WGLC comments from Da		<author fullname="Robert Hanton" initials="R." surname="Hanton">
	niel Burnett:</t>		<organization>Cisco</organization>
	<t>- Editorial corrections.</t>		</author>
	<t>Changes based on WGLC comments from Pa		<author fullname="Paul Kyzivat" initials="P." surname="Kyzivat">
	ul Kyzivat:</t>		</author>
	<t>- Editorial corrections.</t>		<author fullname="Lennard Xiao" initials="L." surname="Xiao">
	</list>		<organization>Huawei</organization>
	</t>		</author>
	<t>		<author fullname="Christian Groves" initials="C." surname="Groves">
	Changes from draft-ietf-clue-datachannel-07		<organization>Huawei</organization>
	<list style="symbols">		</author>
	<t>Changes based on WGLC comments from Ch		<date month="January" year="2021"/>
	ristian Groves:</t>		</front>
	<t>- IANA considerations for dcmap attrib		<seriesInfo name="RFC" value="8848"/>
	ute removed.</t>		<seriesInfo name="DOI" value="10.17487/RFC8848"/>
	<t>- Explicit clarification that the dcma		</reference>
	p attribute max-time		</references>
	and max-retr parameters are not		</references>
	used with ordered/reliable		<section numbered="false" toc="default">
	transmission of SCTP messages.</		<name>Acknowledgements</name>
	t>		<t>
	<t>- Indication that TCP transport should		Thanks to <contact fullname="Paul Kyzivat"/>,
	only be used if ICE is used,		<contact fullname="Christian Groves"/>, and
	and if usage of TCP is required by I		<contact fullname="Mark Duckworth"/> for comments
	CE.</t>		on this document.
	<t>- Informative reference to ICE added.<		</t>
	/t>		</section>
	<t>- Editorial corrections.</t>		</back>
	<t>Changes based on WGLC comments from Ma
	rk Duckworth:</t>
	<t>- Make it more clear that the rules re
	garding usage of partial
	reliability and ordered reliability
	apply to CLUE data channels.</t>
	<t>Changes based on WGLC comments from Pa
	ul Kyzivat:</t>
	<t>- Clarify that same SCTP options are a
	pplied to each SCTP message
	associated with a given data channel
	.</t>
	<t>- Switched location of sections 3.2 an
	d 3.3.</t>
	<t>- PPID table removed. Not needed, sinc
	e only one value is used.</t>
	<t>- Editorial corrections.</t>
	</list>
	</t>
	<t>
	Changes from draft-ietf-clue-datachannel-06
	<list style="symbols">
	<t>Usage of DCEP removed.</t>
	</list>
	</t>
	<t>
	Changes from draft-ietf-clue-datachannel-05
	<list style="symbols">
	<t>"DTLS/SCTP" split into "UDP/DTLS/SCTP"
	and "TCP/DTLS/SCTP".</t>
	<t>Removed note regarding optionality of
	including the SDP
	sctp-port attribute.</t>
	<t>Added defintion of 'SCTPoDTLS associat
	ion' to the
	Conventions.</t>
	<t>Reference to RFC 4566 (SDP) added.</t>
	</list>
	</t>
	<t>
	Changes from draft-ietf-clue-datachannel-04
	<list style="symbols">
	<t>Defines DCEP and external SDP negotiat
	ion as two separate mechanisms
	for negotiating a CLUE data channel.</t>
	<t>Updates based on technical changes in
	referenced specifications.</t>
	<t>Reference to draft-ietf-mmusic-sctp-sd
	p added.</t>
	</list>
	</t>
	<t>
	Changes from draft-ietf-clue-datachannel-03
	<list style="symbols">
	<t>IANA considerations added.</t>
	<t>Editorial changes based on comments fr
	om Christian Groves.</t>
	</list>
	</t>
	<t>
	Changes from draft-ietf-clue-datachannel-02
	<list style="symbols">
	<t>SDP "m=" line example fixed.</t>
	<t>OPEN ISSUE #1 closed.</t>
	<t>- It was agreed (IETF#91) to use draft
	-ejzak-mmusic-data-channel-sdpneg,
	as it was adopted as a WG item in
	MMUSIC.
	</t>
	<t>- Details for draft-ejzak-mmusic-data-
	channel-sdpneg usage added.</t>
	<t>SDP Offer/Answer procedures removed, a
	s they will be defined in the CLUE protocol draft.</t>
	<t>References updated.</t>
	</list>
	</t>
	<t>
	Changes from draft-ietf-clue-datachannel-01
	<list style="symbols">
	<t>Support of interleaving "MUST"->"SHOUL
	D".</t>
	<t>Example updated.</t>
	<t>Reference update.</t>
	</list>
	</t>
	<t>
	Changes from draft-ietf-clue-datachannel-00
	<list style="symbols">
	<t>SDP Offer/Answer procedures structures
	according to RFC 3264.</t>
	<t>Reference update.</t>
	</list>
	</t>
	<t>
	Changes from draft-holmberg-clue-datachannel-04
	<list style="symbols">
	<t>Draft submitted as draft-ietf-clue-dat
	a-channel-00.</t>
	<t>Editorial nits fixed.</t>
	<t>Changes based on comments from Paul Ky
	zivat (http://www.ietf.org/mail-archive/web/clue/current/msg03559.html).</t>
	<t>- Proto value fixed.</t>
	<t>- Explicit text that the partial relia
	bility and limited retransmission
	policies MUST NOT be used.</t>
	<t>- Added open issue on whether the DCEP
	'protocol' field value for CLUE
	should contain a version number.<
	/t>
	<t>- Removed paragraph saying that an off
	erer must not insert more than
	one "m=" line describing an SCTPo
	DTLS association to be used to
	realize a CLUE data channel, as t
	he draft already states that
	only one CLUE data channel per CL
	UE session shall be opened.</t>
	<t>- Added reference to draft-ietf-rtcweb
	-data-protocol regarding details
	on reseting SCTP streams.</t>
	<t>- Added text saying that the value of
	the DCEP 'channel type' MUST
	be DATA_CHANNEL_RELIABLE.</t>
	<t>- Clarified that DCEP must be supporte
	d, and used in the absence of another
	mechanism for opening a CLUE data
	channel.</t>
	</list>
	</t>
	<t>
	Changes from draft-holmberg-clue-datachannel-03
	<list style="symbols">
	<t>Procedures updated, based on WG agreem
	ent (IETF#89) to
	use DCEP for the CLUE data channe
	l.</t>
	<t>Procedures updated, based on WG agreem
	ent (IETF#89) that
	offerer is responsible for sendin
	g DCEP DATA_CHANNEL_OPEN.</t>
	<t>Editorial changes, and alignments caus
	ed by
	changes in referenced specificati
	ons.</t>
	</list>
	</t>
	<t>
	Changes from draft-holmberg-clue-datachannel-02
	<list style="symbols">
	<t>PPID value for CLUE messages added</t>
	<t>References updated</t>
	</list>
	</t>
	<t>
	Changes from draft-holmberg-clue-datachannel-01
	<list style="symbols">
	<t>More text added</t>
	</list>
	</t>
	<t>
	Changes from draft-holmberg-clue-datachannel-00
	<list style="symbols">
	<t>Editorial corrections based on comment
	s from Paul K</t>
	</list>
	</t>
	</section>
	</middle>
	<back>
	<references title="Normative References">
	<?rfc include="reference.RFC.2119"?>
	<?rfc include="reference.RFC.3261"?>
	<?rfc include="reference.RFC.3264"?>
	<?rfc include="reference.RFC.4566"?>
	<?rfc include="reference.RFC.4960"?>
	<?rfc include="reference.RFC.5061"?>
	<?rfc include="reference.RFC.6525"?>
	<?rfc include="reference.RFC.7496"?>
	<?rfc include="reference.RFC.8174"?>
	<?rfc include="reference.RFC.8261"?>
	<reference anchor="I-D.ietf-mmusic-sctp-sdp">
	<front>
	<title abbrev="The SCTP protocol identifi
	er for SDP">
	Stream Control Transmission Proto
	col (SCTP)-Based Media
	Transport in the Session Descript
	ion Protocol (SDP)
	</title>
	<author initials="C." surname="Holmberg"
	fullname="Christer Holmberg">
	<organization>Ericsson</organizat
	ion>
	</author>
	<author initials="S." surname="Loreto" fu
	llname="Salvatore Loreto">
	<organization>Ericsson</organizat
	ion>
	</author>
	<author initials="G." surname="Camarillo"
	fullname="Gonzalo Camarillo">
	<organization>Ericsson</organizat
	ion>
	</author>
	<date day="20" month="April" year="2017"
	/>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ie
	tf-mmusic-sctp-sdp-26.txt" />
	</reference>
	<reference anchor="I-D.ietf-rtcweb-data-channel">
	<front>
	<title abbrev="WebRTC data channels">
	WebRTC data channels
	</title>
	<author fullname="Randell Jesup" initials
	="R.J" surname="Jesup">
	<organization>WorldGate Communica
	tions</organization>
	</author>
	<author fullname="Salvatore Loreto" initi
	als="S.L" surname="Loreto">
	<organization>Ericsson</organizat
	ion>
	</author>
	<author fullname="Michael Tuexen" initial
	s="M.T" surname="Tuexen">
	<organization>Muenster University
	of Applied Sciences</organization>
	</author>
	<date day="4" month="January" year="2015"
	/>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ie
	tf-rtcweb-data-channel-13.txt" />
	</reference>
	<reference anchor="I-D.ietf-mmusic-data-channel-sdpneg">
	<front>
	<title abbrev="SDP-based 'SCTP over DTLS'
	data channel negotiation">
	SDP-based "SCTP over DTLS" data c
	hannel negotiation
	</title>
	<author fullname="Keith Drage" initials="
	K.D" surname="Drage">
	<organization>Alcatel-Lucent</org
	anization>
	</author>
	<author fullname="Raju Makaraju" initials
	="R.M" surname="Makaraju">
	<organization>Alcatel-Lucent</org
	anization>
	</author>
	<author fullname="Juergen Stoetzer-Bradle
	r" initials="J.S" surname="Stoetzer-Bradler">
	<organization>Alcatel-Lucent</org
	anization>
	</author>
	<author fullname="Richard Ejzak" initials
	="R.E" surname="Ejzak">
	<organization>Unaffiliated</organ
	ization>
	</author>
	<author fullname="Jerome Marcon" initials
	="J.M" surname="Marcon">
	<organization>Unaffiliated</organ
	ization>
	</author>
	<date day="23" month="April" year="2019"
	/>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ie
	tf-mmusic-data-channel-sdpneg-26.txt" />
	</reference>
	</references>
	<references title="Informative References">
	<?rfc include="reference.RFC.3758"?>
	<?rfc include="reference.RFC.8445"?>
	<reference anchor="I-D.ietf-rtcweb-data-protocol">
	<front>
	<title abbrev="WebRTC data channel Establ
	ishment Protocol">
	WebRTC data channel Establishment
	Protocol
	</title>
	<author fullname="Randell Jesup" initials
	="R.J" surname="Jesup">
	<organization>WorldGate Communica
	tions</organization>
	</author>
	<author fullname="Salvatore Loreto" initi
	als="S.L" surname="Loreto">
	<organization>Ericsson</organizat
	ion>
	</author>
	<author fullname="Michael Tuexen" initial
	s="M.T" surname="Tuexen">
	<organization>Muenster University
	of Applied Sciences</organization>
	</author>
	<date day="4" month="January" year="2015"
	/>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ie
	tf-rtcweb-data-protocol-09.txt" />
	</reference>
	<reference anchor="I-D.ietf-clue-
	protocol">
	<front>
	<title abbrev="CLUE protocol">
	CLUE protocol
	</title>
	<author fullname="Roberta Presta" initial
	s="R.P" surname="Presta">
	<organization>University of Napol
	i</organization>
	</author>
	<author fullname="Simon Pietro Romano" in
	itials="S P.R" surname="Romano">
	<organization>University of Napol
	i</organization>
	</author>
	<date day="21" month="September" year="20
	18" />
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ie
	tf-clue-protocol-17.txt" />
	</reference>
	<reference anchor="I-D.ietf-clue-signaling">
	<front>
	<title abbrev="CLUE signaling">
	CLUE Signaling
	</title>
	<author fullname="Paul Kyzivat" initials=
	"P.K" surname="Kyzivat">
	</author>
	<author fullname="Lennard Xiao" initials=
	"L.X" surname="Xiao">
	<organization>Huawei</organizatio
	n>
	</author>
	<author fullname="Christian Groves" initi
	als="C.G" surname="Groves">
	<organization>Huawei</organizatio
	n>
	</author>
	<author fullname="Robert Hansen" initials
	="S P.R" surname="Romano">
	<organization>Cisco</organization
	>
	</author>
	<date day="22" month="October" year="2018
	" />
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ie
	tf-clue-signaling-14.txt" />
	</reference>
	</references>
	</back>
	</rfc>		</rfc>
End of changes. 17 change blocks.
	1069 lines changed or deleted		625 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/