<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6001.18527" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=356261309-23122010><FONT face=Arial
color=#0000ff size=2>Hi Justin</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=356261309-23122010><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=356261309-23122010><FONT face=Arial
color=#0000ff size=2>In some sense you are very right but I make a slightly
different interpretation. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=356261309-23122010><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=356261309-23122010><FONT face=Arial
color=#0000ff size=2>Quoting section 4 in RFC3711</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=356261309-23122010><FONT face=Arial
color=#0000ff size=2>"<SPAN lang=SV><FONT color=#000000>While there are numerous
encryption and message authentication algorithms that can be used in SRTP, below
we define default algorithms in order to avoid the complexity of specifying the
encodings for the signaling of algorithm and parameter identifiers. The defined
algorithms have been chosen as they fulfill the goals listed in Section 2.
Recommendations on how to extend SRTP with new transforms are given in Section
6.</FONT></SPAN>"</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=356261309-23122010><FONT face=Arial
color=#0000ff size=2>I don't interpret this as mandatory to implement said
algorithms, rather I see this as something needed to make the RFC complete. The
encryption can be negotiated out of band so an implementer can avoid said
algorithms completely if he/she wants to.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=356261309-23122010><FONT face=Arial
color=#0000ff size=2>Now I don't say that this is _the_ interpretation, please
correct me if neecessary.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=356261309-23122010><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=356261309-23122010><FONT face=Arial
color=#0000ff size=2>I don't intend to enter a heated debate about which codecs
should be used. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=356261309-23122010><FONT face=Arial
color=#0000ff size=2>My concern is more that it is not good to end up in a
situation where a mandatory codec is specified in an IETF RFC and
later on gets subject to some legal issues. What is the situation for the RFC
then?, should the codec be demoted to optional in a new RFC that deprecates the
old ?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=356261309-23122010><FONT face=Arial
color=#0000ff size=2>I don't have the answers, hope that some of the
"grey-beards" can chime in and give some guidance later on.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=356261309-23122010><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=356261309-23122010><FONT face=Arial
color=#0000ff size=2>Regards and happy holidays </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=356261309-23122010><FONT face=Arial
color=#0000ff size=2>/Ingemar</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=356261309-23122010><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=356261309-23122010><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=356261309-23122010><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=356261309-23122010><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Justin Uberti [mailto:juberti@google.com]
<BR><B>Sent:</B> den 22 december 2010 17:15<BR><B>To:</B> Ingemar Johansson
S<BR><B>Cc:</B> dispatch@ietf.org; rtc-web@alvestrand.no;
Markus.Isomaki@nokia.com<BR><B>Subject:</B> Re: [RTW] [dispatch] Fwd: New
Version Notification for
draft-alvestrand-dispatch-rtcweb-protocols-00<BR></FONT><BR></DIV>
<DIV></DIV>Ingemar,
<DIV><BR></DIV>
<DIV>RFC 3711 defines AES as the default encryption algorithm and HMAC-SHA1 as
the default authentication algorithm for SRTP. As a result, those algorithms are
used by pretty much every application that uses SRTP, which makes
interoperability much easier.</DIV>
<DIV><BR></DIV>
<DIV>I think a similar statement can be made regarding the selection of MTI
video codecs. There are various reasons why one might choose one codec versus
another. But if we are unable to pick at least one default/MTI codec (for each
media type), interoperability and thereby adoption of this platform will be much
more challenging.</DIV>
<DIV><BR></DIV>
<DIV>--justin</DIV>
<DIV><BR>
<DIV class=gmail_quote>On Tue, Dec 21, 2010 at 11:44 PM, Ingemar Johansson S
<SPAN dir=ltr><<A
href="mailto:ingemar.s.johansson@ericsson.com">ingemar.s.johansson@ericsson.com</A>></SPAN>
wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi<BR><BR>Not
meaning to express any preference in any direction but more a question to the
more experiened IETFers.<BR><BR>My impression here is that algorithms devised
outside the IETF are rarely mandated in IETF frameworks.<BR><BR>Two examples
that I can come up with are<BR><BR>SRTP (RFC3711): Only specifies the
framework for secure RTP but does not mandate any encryption/authentication
algorithms. Not sure if excryption algos are specified in separate
RFC's<BR><BR>FECFRAME (RFC6015): Specifies the framework for generic FEC,
generic enough to plug in any FEC algo, the actual FEC algos are specified in
separate drafs (<A href="http://tools.ietf.org/wg/fecframe/"
target=_blank>http://tools.ietf.org/wg/fecframe/</A>)<BR>Perhaps there are
similar examples in other IETF areas that can serve as guidance ?, you may
want to ping the eriIetf list on this (I leave it up to you)<BR><BR>So to me
it seems like there is preference to _not_ mandate algorithms (compression,
fec, encryption) in IETF frameworks (I can imagine one specific reason to
this). And... as I believe that RTC-Web will be some kind of framework I would
say that this would apply here as well ?.<BR><BR>Please feel free to bash my
conclusion.<BR><BR>/Ingemar<BR><BR><BR>-------------------------------------------<BR>Message:
1<BR>
<DIV class=im>Date: Tue, 21 Dec 2010 21:38:42 +0000<BR></DIV>
<DIV class=im>From: <<A
href="mailto:Markus.Isomaki@nokia.com">Markus.Isomaki@nokia.com</A>><BR></DIV>
<DIV class=im>Subject: Re: [dispatch] Fwd: New Version Notification
for<BR>
draft-alvestrand-dispatch-rtcweb-protocols-00<BR></DIV>
<DIV class=im>To: <<A
href="mailto:peter.musgrave@magorcorp.com">peter.musgrave@magorcorp.com</A>>,
<<A
href="mailto:harald@alvestrand.no">harald@alvestrand.no</A>><BR></DIV>Cc:
<A href="mailto:rtc-web@alvestrand.no">rtc-web@alvestrand.no</A>, <A
href="mailto:dispatch@ietf.org">dispatch@ietf.org</A>, <A
href="mailto:ted.ietf@gmail.com">ted.ietf@gmail.com</A><BR>Message-ID:<BR>
<<A
href="mailto:DD8B10B86502AB488CB2D3DB4C546E3806DA99@008-AM1MPN1-003.mgdnok.nokia.com">DD8B10B86502AB488CB2D3DB4C546E3806DA99@008-AM1MPN1-003.mgdnok.nokia.com</A>><BR><BR>Content-Type:
text/plain; charset="us-ascii"<BR>
<DIV>
<DIV></DIV>
<DIV class=h5><BR>Hi Peter, all,<BR><BR>About the video codec: Are there any
arguments on why VP8 would not have IPR issues? It is available as an open
source implementation, but that does not mean there are no IPR against it. My
understanding is that the IPR situation wrt. VP8 is still unclear and thus
risky. The other issue with VP8 is, as far as I know, the lack of a clear spec
out of which independent interoperable implementations can be
created.<BR><BR>So I don't at least buy the argument that we should choose VP8
as mandatory to implement video codec because of IPR reasons.<BR><BR>I'm
working on a separate review on Harald's drafts (thanks for putting them
together) and will come back to the codec issue there in more detail, but just
wanted to respond to Peter's point here.<BR><BR>Regards,<BR>
Markus<BR><BR>From: <A
href="mailto:dispatch-bounces@ietf.org">dispatch-bounces@ietf.org</A>
[mailto:<A
href="mailto:dispatch-bounces@ietf.org">dispatch-bounces@ietf.org</A>] On
Behalf Of ext Peter Musgrave<BR>Sent: 17 December, 2010 13:48<BR>To: Harald
Alvestrand<BR>Cc: <A
href="mailto:rtc-web@alvestrand.no">rtc-web@alvestrand.no</A>; <A
href="mailto:dispatch@ietf.org">dispatch@ietf.org</A>; Ted Hardie<BR>Subject:
Re: [dispatch] Fwd: New Version Notification for
draft-alvestrand-dispatch-rtcweb-protocols-00<BR><BR>I'd also like to echo
Alan's thanks for these drafts.<BR><BR>The protocol doc is very clear. [If you
read only one dispatch draft this Christmas, make it this one. ;-)
]<BR><BR>One observation to the group. The mandatory to implement video
CODEC is VP8 (presumably since it does not have IPR issues - which some other
choices would have).<BR><BR>Regards,<BR><BR>Peter
Musgrave<BR><BR><BR>Nits<BR>Introduction<BR>s/veichle/vehicle/<BR><BR>Section
2 Para "Within each.."<BR>s/implementaiton/implementation/<BR><BR>Section 4
Para1<BR>"such as" (something missing here?)<BR><BR>Section 5 Para2<BR>"There
is no third mandatory to implement"<BR>? Was there a mention of a third
before. Not sure why this statement is there.<BR><BR><BR>On 2010-11-10, at
6:34 AM, Harald Alvestrand wrote:<BR><BR><BR>This is the overview document for
the IETF-related RTC-WEB work.<BR><BR>-------- Original Message
--------<BR>Subject:<BR><BR>New Version Notification for
draft-alvestrand-dispatch-rtcweb-protocols-00<BR><BR>Date:<BR><BR>Wed, 10 Nov
2010 03:31:05 -0800 (PST)<BR><BR>From:<BR><BR></DIV></DIV>IETF I-D Submission
Tool <<A
href="mailto:idsubmission@ietf.org">idsubmission@ietf.org</A>><mailto:<A
href="mailto:idsubmission@ietf.org">idsubmission@ietf.org</A>><BR><BR>To:<BR><BR><A
href="mailto:harald@alvestrand.no">harald@alvestrand.no</A><mailto:<A
href="mailto:harald@alvestrand.no">harald@alvestrand.no</A>><BR>
<DIV class=im><BR><BR><BR>A new version of I-D,
draft-alvestrand-dispatch-rtcweb-protocols-00.txt has been successfully
submitted by Harald Alvestrand and posted to the IETF
repository.<BR><BR><BR><BR>Filename:
draft-alvestrand-dispatch-rtcweb-protocols<BR><BR>Revision:
00<BR><BR>Title: Overview: Real Time
Protocols for Brower-based Applications<BR><BR>Creation_date:
2010-11-11<BR><BR>WG ID: Independent
Submission<BR><BR>Number_of_pages: 9<BR><BR><BR><BR>Abstract:<BR><BR>This
document gives an overview of a protocol suite intended for use<BR><BR>with
real-time applications that can be deployed in browsers - "real<BR><BR>time
communication on the Web".<BR><BR><BR><BR>It intends to serve as a starting
and coordination point to make sure<BR><BR>all the parts that are needed to
achieve this goal are findable, and<BR><BR>that the parts that belong in the
Internet protocol suite are fully<BR><BR>specified and on the right
publication track.<BR><BR><BR><BR>This work is an attempt to synthesize the
input of many people, but<BR><BR>makes no claims to fully represent the views
of any of them. All<BR><BR>parts of the document should be regarded as
open for discussion.<BR><BR><BR><BR><BR><BR><BR><BR>The IETF
Secretariat.<BR><BR><BR><BR><BR><BR><BR>_______________________________________________<BR>dispatch
mailing list<BR></DIV><A
href="mailto:dispatch@ietf.org">dispatch@ietf.org</A><mailto:<A
href="mailto:dispatch@ietf.org">dispatch@ietf.org</A>><BR>
<DIV class=im><A href="https://www.ietf.org/mailman/listinfo/dispatch"
target=_blank>https://www.ietf.org/mailman/listinfo/dispatch</A><BR><BR></DIV>--------------
next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A
href="http://www.ietf.org/mail-archive/web/dispatch/attachments/20101221/46ec4317/attachment.htm"
target=_blank>http://www.ietf.org/mail-archive/web/dispatch/attachments/20101221/46ec4317/attachment.htm</A>><BR><BR>------------------------------<BR>
<DIV>
<DIV></DIV>
<DIV class=h5>_______________________________________________<BR>RTC-Web
mailing list<BR><A
href="mailto:RTC-Web@alvestrand.no">RTC-Web@alvestrand.no</A><BR><A
href="http://www.alvestrand.no/mailman/listinfo/rtc-web"
target=_blank>http://www.alvestrand.no/mailman/listinfo/rtc-web</A><BR></DIV></DIV></BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>