[RTW] WG charter, take 4

Thu Feb 24 22:05:32 CET 2011

On 02/24/11 20:51, Bernard Aboba wrote:
> Agree with Jonathan on the security issues below.
>
> Personally, I'd like to see an analysis of the issues added to the charter
> -- along with some opportunity for the
> security community to review the document.   Allowing P2P media is a
> non-trivial change to the security threat
> model of the browser.
I think the security issues need to be addressed explicitly, and it's 
not just limited to the RTP interworking case.

Should we add something like the below?

"The WG will evaluate the security implications of the changes proposed, 
and will ensure that adequate security mechanisms are included in the 
protocol suite"

I also note that we don't seem to have said anything about congestion 
management, something we have also discussed the need for earlier.

> -----Original Message-----
> From: rtc-web-bounces at alvestrand.no [mailto:rtc-web-bounces at alvestrand.no]
> On Behalf Of Rosenberg, Jonathan
> Sent: Thursday, February 24, 2011 8:33 AM
> To: 'Harald Alvestrand'; RTC-Web at alvestrand.no
> Subject: Re: [RTW] WG charter, take 4
>
> A few comments:
>
> I'm happy with the charter language around discussion of session
> management protocols being in scope for the WG. I don't understand why,
> during the BoF, we will discuss whether to bake a decision on this into
> the charter. Determining the protocols needed for browser RTC - both the
> types of protocols and specific protocol instances and profiles - is the
> work of the group and NOT the work of the charter.
>
> This piece of wording is also concerning:
>> have interactive real time voice and video pairwise between browsers or
>> other devices using RTP
> While I think we agree this is a goal, there are real security issues in
> play here that the group needs to iron out. I do not want to bake in a
> charter requirement that says we MUST deliver a solution that allows
> point-to-point media (i.e., no gateways or SBCs or other intermediaries)
> between browsers and existing RTP endpoints. I'd suggest something softer
> like:
>
> "enable real-time voice and video communications between browsers and
> non-browser endpoints, with direct media when possible based on security
> and interoperability considerations"
>
> Which states the intent but leaves the recommendation to the wg.
>
> Thanks,
> Jonathan R.
>
>
> Jonathan D. Rosenberg, Ph.D.               SkypeID: jdrosen
> Skype Chief Technology Strategist
> jdrosen at skype.net                          http://www.skype.com
> jdrosen at jdrosen.net                        http://www.jdrosen.net
>
>
> -----Original Message-----
> From: rtc-web-bounces at alvestrand.no [mailto:rtc-web-bounces at alvestrand.no]
> On Behalf Of Harald Alvestrand
> Sent: Thursday, February 24, 2011 8:45 AM
> To: RTC-Web at alvestrand.no
> Subject: [RTW] WG charter, take 4
>
> This is the current charter text - it's updated somewhat based on
> discussions on the list.
>
> In particular, there's now suggested language about the relationship to
> session management protocols.
> We'll make this an explicit discussion at the BOF, with the aim of
> getting one of three conclusions in the charter:
>
> - The WG will not address session management protocols
> - The WG will choose one or more session management protocols
> - The WG will discuss session management protocols, and do what makes
> sense.
>
> The last one is the one suggested by the current charter text; the other
> possible outcomes should be easier to write text for.
>
> Comments welcome!
>
> Harald
>
> (Note: The below is not going out in<  80 columns, I think. Please
> forgive the formatting issue.)
>
> ------------------------------------------------
>
> Version: 4
>
> Name: RTCWEB
> WG Chair(s): Cullen Jennings<fluffy at cisco.com>
>
> Body:
>
> Many implementations have been made that use a Web browser to support
> direct, interactive communications, including voice, video,
> collaboration, and gaming. In these implementations, the web server acts
> as the signaling path between these applications, using locally
> significant identifiers to set up the association. Up till now, such
> applications have typically required the installation of plugins or
> non-standard browser extensions. There is a desire to standardize this
> functionality, so that this type of application can be run in any
> compatible browser and allow for high-quality real-time communications
> experiences within the browser.
>
> Traditionally, the W3C has defined API and markup languages such as HTML
> that work in conjunction with with the IETF over the wire protocols such
> as HTTP to allow web browsers to display media that does not have real
> time interactive constraints with another human.
>
> The W3C and IETF plan to collaborate together in their traditional way
> to meet the evolving needs of browsers. Specifically the IETF will
> provide a set of on the wire protocols, including RTP, to meet the needs
> on interactive communications, and the W3C will define the API and
> markup to allow web application developers to control the on the wire
> protocols. This will allow application developers to write applications
> that run in a browser and facilitate interactive communications between
> users for voice and video communications, collaboration, and gaming.
>
> This working group will select and define a minimal set of protocols
> that will enable browsers to:
> have interactive real time voice and video pairwise between browsers or
> other devices using RTP
> have interactive real time application data for collaboration and gaming
> pairwise between browsers
>
>
> Fortunately very little development of new protocol at IETF is required
> for this, only selection of existing protocols and selection of minimum
> capabilities to ensure interoperability. The following protocols are
> candidates for including in the profile set:
>
> 1) RTP/ RTCP
>
> 2) a baseline audio codec for high quality interactive audio. Opus will
> be one of the codecs considered
>
> 3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will
> be some of the codecs considered
>
> 4) a baseline video codec. H.264 and VP8 will be some of the codecs
> considered
>
> 5) Diffserv based QoS
>
> 6) NAT traversal using ICE
>
> 7) media based DTMF
>
> 8) support for identifying streams’ purpose using semantics labels
> mappable to the labels described in RFC 4574
>
> 9) Secure RTP and keying
>
> 10) support for IPv4, IPv6 and dual stack browsers
>
> Please note the above list is only a set of candidates that the WG may
> consider and is not list of things that will be in the profile the set.
>
> This group's primary aim is to enable web applications to manage
> real-time communication sessions with other web-context applications
> that implement this specification. When making choices, the working
> group will also consider the impact of those choices on interoperability
> with other devices that create or manage multimedia sessions, including
> the complexity imposed
> on any gateways which may be required.
>
> The Working group will identify information needed for session
> negotiation and management in web contexts, and its output documents
> will describe the relationship of this to information carried in session
> protocols used in other standardized contexts.
>
> The Working Group will consider the possibility of defining a browser
> component that implements an existing session negotiation and management
> protocol.
>
> The working group will cooperate closely with the W3C activity that
> specifies a semantic level API that allows the control and manipulation
> of all the functionality above. In addition, the API needs to
> communicate state information and events about what is happening in the
> browser to applications running in the browser. These events and state
> need to include information such as: receiving DTMF in the RTP, RTP and
> RTCP statistics, and the state of DTLS/SRTP handshakes. The output of
> this WG will form input to the W3C group that specifies the API, and if
> there are parts of the mapping between the API and the protocols that
> need to be done outside of the W3C, this group will do it.
>
> The working group will follow BCP 79, and adhere to the spirit of BCP
> 79. The working group cannot explicitly rule out the possibility of
> adopting encumbered technologies; however, the working group will try to
> avoid encumbered technologies that require royalties or other
> encumbrances that would prevent such technologies from being easy to use
> in web browsers.
>
> The following topics will be out of scope for the initial phase of the
> WG but could be added after a recharter: RTSP, RSVP, NSIS, LOST,
> Geolocation, IM&  Presence, NSIS, Resource Priority. RTP Payload formats
> will not be done in this WG.
>
> Deliverables:
> An overview document describing the architecture
> A scenarios document describing scenarios that are expected to be
> supported
> A profile document specifying the protocols and options that must be
> supported by a conforming implementation
> (If needed) A mapping document describing the relationship between the
> protocols and the W3C-defined API.
>
>
> Milestones:
>
> May 2011 Main alternatives identified in drafts
>
> Aug 2011 WG draft with text reflecting agreement of what the profile set
> should be
>
> Sept 2011 Scenarios specification to IESG as Informational
>
> Nov 2011 Draft available of documentation specifying mapping of protocol
> functionality to W3C-specified API produced. This is an input to W3C API
> work.
>
> Dec 2011 Profile specification to IESG as PS
>
> Apr 2012 Mapping document submitted to the IESG as Informational (if
> needed)
>
>
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>
>