Cullen, Let's say hypothetically that the AVTcore WG will propose and get consensus that for RTCweb usage the security mechanism MUST use SDES for key exchange, do you see this as a binding recommendation for RTCweb? The selection was done by RTCweb and not by AVTcore. The document does not say that there should be no security but says that it is up to the usage or a for a decision. The security option document provide the information about the different security options available and where they are used. Roni Even > -----Original Message----- > From: avt [mailto:avt-bounces@xxxxxxxx] On Behalf Of Cullen Jennings (fluffy) > Sent: 05 December, 2013 6:57 PM > To: ietf@xxxxxxxx > Cc: avt@xxxxxxxx WG > Subject: Re: [AVTCORE] Last Call: <draft-ietf-avt-srtp-not-mandatory-14.txt> > (Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single > Media Security Solution) to Informational RFC > > > Given the hum in the IETF plenary at the last IETF, I no longer think this > document represents IETF consensus. Given the hum in RTCWeb working group, > I doubt this represents the consensus of the RAI area either. > > I think I would be tempted to resolve this by saying for each different scenario > RTP is used in (SIP, RTSP, Mulitcast etc) exactly how it needs to be secured and > for scenarios not listed such as new usages, what the requirements are. For > something like SIP, having just one way to secure RTP is much better than > having many ways. > > > > On Nov 22, 2013, at 3:07 PM, The IESG <iesg-secretary@xxxxxxxx> wrote: > > > > > The IESG has received a request from the Audio/Video Transport Core > > Maintenance WG (avtcore) to consider the following document: > > - 'Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single > > Media Security Solution' > > <draft-ietf-avt-srtp-not-mandatory-14.txt> as Informational RFC > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@xxxxxxxx mailing lists by 2013-12-06. Exceptionally, comments may > > be sent to iesg@xxxxxxxx instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This memo discusses the problem of securing real-time multimedia > > sessions, and explains why the Real-time Transport Protocol (RTP), > > and the associated RTP Control Protocol (RTCP), do not mandate a > > single media security mechanism. Guidelines for designers and > > reviewers of future RTP extensions are provided, to ensure that > > appropriate security mechanisms are mandated, and that any such > > mechanisms are specified in a manner that conforms with the RTP > > architecture. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory/ball > > ot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance avt@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/avt > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@xxxxxxxx > https://www.ietf.org/mailman/listinfo/avt