Subject: Re: [dispatch] Reminder: IETF-88 deadlines

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Tue, 1 Oct 2013 15:30:31 +0000

Hi Mary, All,
I have added a problem statement to the beginning of http://www.ietf.org/id/draft-dawes-dispatch-mediasec-parameter-07.txt in order to explain why I think dispatch should consider the draft, and have copied the problem statement below. I will not be at IETF-88 but I am posting this now to meet the Oct. 1 deadline in case dispatch would like to discuss the topic in Vancouver.

Regards,
Peter

1.  Problem Statement

   In the 3GPP defined architecture and SIP profile for packet-domain
   communication, SIP signalling is security protected at the network
   layer but media-plane traffic is not (it is protected by the cellular
   wireless access).  The SIP signalling security used by 3GPP runs from
   the user device to the first hop proxy and negotiation of security
   mechanism and the start of security protection is described in RFC
   3329 [4].  Because the 3GPP architecture also allows access
   technologies that do not protect media, e.g. WiFi, this document
   extends the negotiation of security mechanism to the media plane.
   During previous discussion of the topic of media plane security it
   was suggested that DTLS-SRTP should be used, but 3GPP considered this
   impractical to implement in the 3GPP-defined architecture and also
   limited in terms of meeting all 3GPP requirements which include
   protection of non-RTP media such as MSRP.

   The purpose of this specification is to define a new header field
   parameter for the Session Initiation Protocol (SIP) [1] that
   distinguishes security mechanisms that apply to the media plane and
   to create an IANA registry for these mechanisms.  This header field
   parameter may be used with the Security-Client, Security-Server, and
   Security-Verify header fields defined by RFC 3329 [4].

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: 16 September 2013 22:35
To: DISPATCH
Cc: Cullen Jennings
Subject: [dispatch] Reminder: IETF-88 deadlines

As a reminder, the DISPATCH deadlines for IETF-88 per the wiki are as follows:  http://trac.tools.ietf.org/wg/dispatch/trac/wiki

  *   Oct 1, 2013. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal.

  *   Oct 7, 2013. Cutoff for charter proposals for topics.

  *   Oct 21, 2013. Draft deadline.
We do not assume that just because you've submitted a draft that you might want agenda time.  We need explicit emails - you can send those directly to the chairs.  Including "IETF-88 Agenda request" or "IETF-88 Topic Proposal" in the subject line will ensure we don't miss your request.

As a reminder, we don't need solutions at this stage in DISPATCH - we need problem statements, objectives, milestones, etc.  We need to understand why you want to do the work and exactly what work you believe needs to be done.  You should be starting threads of discussion on the mailing list and include a link to any relevant drafts. We generally do not allocate agenda time or dispatch topics unless there is mailing list discussion.

Regards,
Mary
DISPATCH WG co-chair

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Mon, 7 Oct 2013 18:18:43 +0000

This is a charter proposal for "SDP negotiation of DataChannel sub-protocols" in accordance with the Oct.  7 deadline for dispatch.

The rtcweb DataChannel is the primary mechanism available for a WebRTC application to establish transport for media protocols other than audio and video, such as MSRP, BFCP, T.140, T.38 and the CLUE control protocol.  While WebSockets is an option for transport of some of these protocols, DataChannels provides a more general solution that works in all cases, particularly peer-to-peer cases.  Many applications using these kinds of protocols (usually based on SIP or XMPP) also expect to negotiate their use with SDP.

The rtcweb DataChannel design allows two means of creating a DataChannel: either via in-band negotiation, or external negotiation.  No external negotiation mechanism is defined in the core DataChannel specification to allow applications the freedom to choose how to perform the external negotiation.

We propose to charter work to:

1.       Define generic SDP procedures to enable external negotiation of DataChannel sub-protocols to establish DataChannel transport for sub-protocol sessions, and to negotiate the use of sub-protocol specific options.

2.       Describe how to use the generic SDP procedures defined in 1 to negotiate DataChannel transport for specific protocols, potentially including MSRP, BFCP, T.140, T.38 and the CLUE control protocol.

We envision that one draft is sufficient for item 1, and one draft per protocol is needed for item 2.  We provided an early draft in http://datatracker.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels/ that describes a solution for 1 and provides details specific to MSRP.  We have split this document in two parts and made some significant revisions based on off-line discussions (including a bar bof in Berlin).  We intend to upload both new documents well in advance of the doc deadline.

Two high level issues were identified, which the new docs will attempt to address:

1.       How will DataChannel sub-protocols be registered (re-use an existing registry or create a new one) and if it's a new registry how to define the relationship to existing protocols.  This issue deserves additional review and discussion.

2.       Issues related to SCTP stream id assignment.  We have very recently concluded that there should be no impact on the DataChannel design as long as the application has free reign to create a DataChannel at each peer using the same stream id number.

Comments/support are encouraged.

Richard

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 14 Oct 2013 11:11:52 +0200

For the purposes of RTCWEB, this option was discussed at the IETF 
meeting in Orlando, and soundly rejected in favour of using an inband 
approach (with the option of leaving the negotiation to be done by 
non-standardized means).

As long as the approach proposed is that of using WebRTC data channels, 
I do not see any advantage to revising that decision.

Defining how to use WebRTC data channels to carry MSRP, BFCP, T.140, 
T.38 and CLUE control seems like perfectly reasonable things to do.

I don't see any reason to believe that revisiting RTCWEB's decision 
about SDP usage for such negotiation is reasonable.

On 10/07/2013 08:18 PM, Ejzak, Richard P (Richard) wrote:
>
> This is a charter proposal for "SDP negotiation of DataChannel 
> sub-protocols" in accordance with the Oct.  7 deadline for dispatch.
>
> The rtcweb DataChannel is the primary mechanism available for a WebRTC 
> application to establish transport for media protocols other than 
> audio and video, such as MSRP, BFCP, T.140, T.38 and the CLUE control 
> protocol.  While WebSockets is an option for transport of some of 
> these protocols, DataChannels provides a more general solution that 
> works in all cases, particularly peer-to-peer cases.  Many 
> applications using these kinds of protocols (usually based on SIP or 
> XMPP) also expect to negotiate their use with SDP.
>
> The rtcweb DataChannel design allows two means of creating a 
> DataChannel: either via in-band negotiation, or external negotiation.  
> No external negotiation mechanism is defined in the core DataChannel 
> specification to allow applications the freedom to choose how to 
> perform the external negotiation.
>
> 1.Define generic SDP procedures to enable external negotiation of 
> DataChannel sub-protocols to establish DataChannel transport for 
> sub-protocol sessions, and to negotiate the use of sub-protocol 
> specific options.
>
> 2.Describe how to use the generic SDP procedures defined in 1 to 
> negotiate DataChannel transport for specific protocols, potentially 
> including MSRP, BFCP, T.140, T.38 and the CLUE control protocol.
>
> We envision that one draft is sufficient for item 1, and one draft per 
> protocol is needed for item 2.  We provided an early draft in 
> http://datatracker.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels/that 
> describes a solution for 1 and provides details specific to MSRP.  We 
> have split this document in two parts and made some significant 
> revisions based on off-line discussions (including a bar bof in 
> Berlin).  We intend to upload both new documents well in advance of 
> the doc deadline.
>
> 1.How will DataChannel sub-protocols be registered (re-use an existing 
> registry or create a new one) and if it's a new registry how to define 
> the relationship to existing protocols.  This issue deserves 
> additional review and discussion.
>
> 2.Issues related to SCTP stream id assignment.  We have very recently 
> concluded that there should be no impact on the DataChannel design as 
> long as the application has free reign to create a DataChannel at each 
> peer using the same stream id number.
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Mon, 14 Oct 2013 13:46:28 +0000

Hi Harald,
We are not proposing to revisit any decision of the rtcweb group.  We are not proposing to change the design of the data channel (although we identify one small issue where a small change might be appropriate but is not necessary).  The data channel design allows for use of an external negotiation mechanism as an alternative to in-band negotiation.  This draft simply describes how one can use SDP to facilitate such an external negotiation mechanism.

Please see the draft that we uploaded yesterday on the topic.

BR, Richard

From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: Monday, October 14, 2013 4:12 AM
To: [email-masked]
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols

For the purposes of RTCWEB, this option was discussed at the IETF meeting in Orlando, and soundly rejected in favour of using an inband approach (with the option of leaving the negotiation to be done by non-standardized means).

As long as the approach proposed is that of using WebRTC data channels, I do not see any advantage to revising that decision.

Defining how to use WebRTC data channels to carry MSRP, BFCP, T.140, T.38 and CLUE control seems like perfectly reasonable things to do.

I don't see any reason to believe that revisiting RTCWEB's decision about SDP usage for such negotiation is reasonable.

Richard

dispatch mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Mon, 14 Oct 2013 22:48:16 +0000

Hi Harald,
I just realized that there may be some confusion over the role of the browser in preparing SDP for external negotiation of DataChannels in our proposal.  The answer is zip/nada/zero/nothing/nichevo.  The browser just prepares the m line for the SCTP association, while the JS application creates DataChannels using the existing API (selecting to not use the in-band Open message) and adds the DataChannel-specific attributes defined in the document to the SDP (to perform the external DataChannel negotiation with the peer).  The browser's role in supporting external DataChannel negotiation is exactly what is documented in the current DC drafts (although some minor clarifications might be appropriate).

BR, Richard

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ejzak, Richard P (Richard)
Sent: Monday, October 14, 2013 8:46 AM
To: Harald Alvestrand; [email-masked]
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols

Hi Harald,

BR, Richard

Richard

dispatch mailing list

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 15 Oct 2013 08:40:08 +0200

On 10/15/2013 12:48 AM, Ejzak, Richard P (Richard) wrote:
>
> Hi Harald,
>
> I just realized that there may be some confusion over the role of the
> browser in preparing SDP for external negotiation of DataChannels in
> our proposal.  The answer is zip/nada/zero/nothing/nichevo.  The
> browser just prepares the m line for the SCTP association, while the
> JS application creates DataChannels using the existing API (selecting
> to not use the in-band Open message) and adds the DataChannel-specific
> attributes defined in the document to the SDP (to perform the external
> DataChannel negotiation with the peer).  The browser's role in
> supporting external DataChannel negotiation is exactly what is
> documented in the current DC drafts (although some minor
> clarifications might be appropriate).
>

Re-reading the proposal, and matching up with
draft-ietf-mmusic-sctp-sdp-04.txt, I'm less worried about this proposal
than I initially was. The attributes you are defining aren't extensions
of attributes defined there (which worried me), they're new, and
therefore, by the rules of SDP, ignorable.

I still think it's a Bad Idea, for all the reasons that came up in the
RTCWEB meeting in Florida, but it shouldn't be actively harmful.

>  
>
> BR, Richard
>
>  
>
> *From:[email-masked] [mailto:[email-masked]]
> *On Behalf Of *Ejzak, Richard P (Richard)
> *Sent:* Monday, October 14, 2013 8:46 AM
> *To:* Harald Alvestrand; [email-masked]
> *Subject:* Re: [dispatch] Charter proposal: SDP negotiation of
> DataChannel sub-protocols
>
>  
>
> Hi Harald,
>
> We are not proposing to revisit any decision of the rtcweb group.  We
> are not proposing to change the design of the data channel (although
> we identify one small issue where a small change might be appropriate
> but is not necessary).  The data channel design allows for use of an
> external negotiation mechanism as an alternative to in-band
> negotiation.  This draft simply describes how one can use SDP to
> facilitate such an external negotiation mechanism.
>
>  
>
> *From:[email-masked] [mailto:[email-masked]]
> *On Behalf Of *Harald Alvestrand
> *Sent:* Monday, October 14, 2013 4:12 AM
> *To:* [email-masked]
> *Subject:* Re: [dispatch] Charter proposal: SDP negotiation of
> DataChannel sub-protocols
>
>  
>
> As long as the approach proposed is that of using WebRTC data
> channels, I do not see any advantage to revising that decision.
>
>     The rtcweb DataChannel is the primary mechanism available for a
>     WebRTC application to establish transport for media protocols
>     other than audio and video, such as MSRP, BFCP, T.140, T.38 and
>     the CLUE control protocol.  While WebSockets is an option for
>     transport of some of these protocols, DataChannels provides a more
>     general solution that works in all cases, particularly
>     peer-to-peer cases.  Many applications using these kinds of
>     protocols (usually based on SIP or XMPP) also expect to negotiate
>     their use with SDP.
>
>      
>
>     DataChannel: either via in-band negotiation, or external
>     negotiation.  No external negotiation mechanism is defined in the
>     core DataChannel specification to allow applications the freedom
>     to choose how to perform the external negotiation.
>
>      
>
>     1.      Define generic SDP procedures to enable external
>     negotiation of DataChannel sub-protocols to establish DataChannel
>     transport for sub-protocol sessions, and to negotiate the use of
>     sub-protocol specific options.
>
>     2.      Describe how to use the generic SDP procedures defined in
>     1 to negotiate DataChannel transport for specific protocols,
>     potentially including MSRP, BFCP, T.140, T.38 and the CLUE control
>     protocol.
>
>      
>
>     We envision that one draft is sufficient for item 1, and one draft
>     per protocol is needed for item 2.  We provided an early draft in
>     describes a solution for 1 and provides details specific to MSRP. 
>     We have split this document in two parts and made some significant
>     Berlin).  We intend to upload both new documents well in advance
>     of the doc deadline.
>
>      
>
>     1.      How will DataChannel sub-protocols be registered (re-use
>     an existing registry or create a new one) and if it's a new
>     registry how to define the relationship to existing protocols. 
>     This issue deserves additional review and discussion.
>
>     2.      Issues related to SCTP stream id assignment.  We have very
>     recently concluded that there should be no impact on the
>     DataChannel design as long as the application has free reign to
>     create a DataChannel at each peer using the same stream id number. 
>
>      
>
>     [email-masked] <mailto:[email-masked]>
>

-- 
Surveillance is pervasive. Go Dark.

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Tue, 15 Oct 2013 19:51:50 +0000

Hi Harald,
At least we are making some progress...

My recollection of the Florida rtcweb session was that external data channel negotiation was considered to  be a useful concept (which is why it was included in the data channel design), but that it was premature to assume that SDP should be the primary mechanism to realize it.  So the application has the responsibility to implement whatever external negotiation mechanism it chooses to use.  Options include using another data channel to transport external negotiation messages, and using other non-SDP format protocols.  I don't recall any specific arguments against using SDP for external data channel negotiation, other than the general anti-SDP comments.

Please correct/elaborate my recollection of the Florida discussion to help me understand your position here, as "Bad Idea" is a bit too ambiguous to be helpful.

I fully concur that there can be multiple ways to realize external data channel negotiation, and encourage specification of any useful alternative mechanisms.  We are simply proposing A mechanism to perform external data channel negotiation using SDP for use in applications that desire to negotiate the use of specific protocols, such as MSRP and T140, that are usually negotiated using SDP.  One advantage of using SDP is to ease interworking through gateways to endpoints that only support other transport options for the negotiated protocols (e.g., TLS/TCP for MSRP).  We specifically selected MSRP, BFCP, T140 and T38 as example protocols for this because of their common use by SIP and XMPP endpoints that expect to negotiate their use with SDP.  It becomes even more valuable when the protocol comes with various SDP attributes that also need to be negotiated (like accept-types and other file attributes for MSRP).

BR, Richard

From: Harald Alvestrand [mailto:[email-masked]]
Sent: Tuesday, October 15, 2013 1:40 AM
To: Ejzak, Richard P (Richard); [email-masked]
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols

Re-reading the proposal, and matching up with draft-ietf-mmusic-sctp-sdp-04.txt, I'm less worried about this proposal than I initially was. The attributes you are defining aren't extensions of attributes defined there (which worried me), they're new, and therefore, by the rules of SDP, ignorable.

I still think it's a Bad Idea, for all the reasons that came up in the RTCWEB meeting in Florida, but it shouldn't be actively harmful.

BR, Richard

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ejzak, Richard P (Richard)
Sent: Monday, October 14, 2013 8:46 AM
To: Harald Alvestrand; [email-masked]<mailto:[email-masked]>
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols

Hi Harald,

BR, Richard

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: Monday, October 14, 2013 4:12 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols

Richard

dispatch mailing list

--

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Oct 2013 18:22:42 -0400

Harald,

> RTCWEB meeting in Florida, but it shouldn't be actively harmful.

What do you imagine is a reasonable alternative for SIP?

The fundamental difference between SIP and WebRTC here is that with 
WebRTC there is one application in charge of both ends, while in SIP 
there are separate applications at each end.

With one application you can preplan how you want to assign channels.

With two applications, if SDP only allows you to set up the SCTP 
association, and not the channels, then some other mechanism for that 
must be negotiated by the two ends. And that mechanism would generally 
entail devising a protocol and a way to transport it.

Or else we become very restrictive. E.g., in clue we could dedicate the 
entire SCTP association to the one clue channel. But it would be nice if 
some independent things that can work with CLUE could also have the 
option of using channels on the same SCTP association.

	Thanks,
	Paul

---

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 16 Oct 2013 15:40:06 +0000

Hi Richard,

For T.140, there is an RTP payload format defined (RFC4103).
What would be the benefit for standardizing an additional Data Channel binding for it, as opposed to using RTP?

Kind regards,
Uwe

From: Ejzak, Richard P (Richard) [mailto:[email-masked]]
Sent: Tuesday, October 15, 2013 9:52 PM
To: Harald Alvestrand; [email-masked]
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols

Hi Harald,

BR, Richard

From: Harald Alvestrand [mailto:[email-masked]]
Sent: Tuesday, October 15, 2013 1:40 AM
To: Ejzak, Richard P (Richard); [email-masked]<mailto:[email-masked]>
Subject: Re: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols

BR, Richard

Hi Harald,

BR, Richard

Richard

dispatch mailing list

--

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Wed, 16 Oct 2013 15:51:51 +0000

Hi Uwe,
Of course this would be the easiest approach.  But I have seen no support for such an option in WebRTC, even after lengthy discussion on the list some months ago.  WebRTC only supports audio and video media over SRTP.  If a WebRTC application is to be able to use T140, the only option in the media plane is to use DataChannel transport.  We could potentially define a signaling plane option based on WebSockets, and we can have the discussion about which is the better option (in my opinion DataChannel transport wins), but it seems quite reasonable to at least propose the option for discussion.

BR, Richard

From: Rauschenbach, Uwe (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Wednesday, October 16, 2013 10:40 AM
To: Ejzak, Richard P (Richard); Harald Alvestrand; [email-masked]
Subject: RE: [dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols

Hi Richard,

Kind regards,
Uwe

Hi Harald,

BR, Richard

BR, Richard

Hi Harald,

BR, Richard

Richard

dispatch mailing list

--