Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00
Hi Not meaning to express any preference in any direction but more a question to the more experiened IETFers. My impression here is that algorithms devised outside the IETF are rarely mandated in IETF frameworks. Two examples that I can come up with are 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 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 (http://tools.ietf.org/wg/fecframe/) 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) 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 ?. Please feel free to bash my conclusion. /Ingemar ------------------------------------------- Message: 1 Date: Tue, 21 Dec 2010 21:38:42 +0000 From: <Markus.Isomaki@nokia.com> Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 To: <peter.musgrave@magorcorp.com>, <harald@alvestrand.no> Cc: rtc-web@alvestrand.no, dispatch@ietf.org, ted.ietf@gmail.com Message-ID: <DD8B10B86502AB488CB2D3DB4C546E3806DA99@008-AM1MPN1-003.mgdnok.nokia.com> Content-Type: text/plain; charset="us-ascii" Hi Peter, all, 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. So I don't at least buy the argument that we should choose VP8 as mandatory to implement video codec because of IPR reasons. 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. Regards, Markus From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Peter Musgrave Sent: 17 December, 2010 13:48 To: Harald Alvestrand Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 I'd also like to echo Alan's thanks for these drafts. The protocol doc is very clear. [If you read only one dispatch draft this Christmas, make it this one. ;-) ] 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). Regards, Peter Musgrave Nits Introduction s/veichle/vehicle/ Section 2 Para "Within each.." s/implementaiton/implementation/ Section 4 Para1 "such as" (something missing here?) Section 5 Para2 "There is no third mandatory to implement" ? Was there a mention of a third before. Not sure why this statement is there. On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote: This is the overview document for the IETF-related RTC-WEB work. -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Date: Wed, 10 Nov 2010 03:31:05 -0800 (PST) From: IETF I-D Submission Tool <idsubmission@ietf.org><mailto:idsubmission@ietf.org> To: harald@alvestrand.no<mailto:harald@alvestrand.no> 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. Filename: draft-alvestrand-dispatch-rtcweb-protocols Revision: 00 Title: Overview: Real Time Protocols for Brower-based Applications Creation_date: 2010-11-11 WG ID: Independent Submission Number_of_pages: 9 Abstract: This document gives an overview of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This work is an attempt to synthesize the input of many people, but makes no claims to fully represent the views of any of them. All parts of the document should be regarded as open for discussion. The IETF Secretariat. _______________________________________________ dispatch mailing list dispatch@ietf.org<mailto:dispatch@ietf.org> https://www.ietf.org/mailman/listinfo/dispatch
Ingemar, 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. 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. --justin On Tue, Dec 21, 2010 at 11:44 PM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote:
Hi
Not meaning to express any preference in any direction but more a question to the more experiened IETFers.
My impression here is that algorithms devised outside the IETF are rarely mandated in IETF frameworks.
Two examples that I can come up with are
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
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 (http://tools.ietf.org/wg/fecframe/) 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)
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 ?.
Please feel free to bash my conclusion.
/Ingemar
------------------------------------------- Message: 1 Date: Tue, 21 Dec 2010 21:38:42 +0000 From: <Markus.Isomaki@nokia.com> Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 To: <peter.musgrave@magorcorp.com>, <harald@alvestrand.no> Cc: rtc-web@alvestrand.no, dispatch@ietf.org, ted.ietf@gmail.com Message-ID: < DD8B10B86502AB488CB2D3DB4C546E3806DA99@008-AM1MPN1-003.mgdnok.nokia.com>
Content-Type: text/plain; charset="us-ascii"
Hi Peter, all,
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.
So I don't at least buy the argument that we should choose VP8 as mandatory to implement video codec because of IPR reasons.
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.
Regards, Markus
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Peter Musgrave Sent: 17 December, 2010 13:48 To: Harald Alvestrand Cc: rtc-web@alvestrand.no; dispatch@ietf.org; Ted Hardie Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00
I'd also like to echo Alan's thanks for these drafts.
The protocol doc is very clear. [If you read only one dispatch draft this Christmas, make it this one. ;-) ]
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).
Regards,
Peter Musgrave
Nits Introduction s/veichle/vehicle/
Section 2 Para "Within each.." s/implementaiton/implementation/
Section 4 Para1 "such as" (something missing here?)
Section 5 Para2 "There is no third mandatory to implement" ? Was there a mention of a third before. Not sure why this statement is there.
On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote:
This is the overview document for the IETF-related RTC-WEB work.
-------- Original Message -------- Subject:
New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00
Date:
Wed, 10 Nov 2010 03:31:05 -0800 (PST)
From:
IETF I-D Submission Tool <idsubmission@ietf.org><mailto: idsubmission@ietf.org>
To:
harald@alvestrand.no<mailto:harald@alvestrand.no>
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.
Filename: draft-alvestrand-dispatch-rtcweb-protocols
Revision: 00
Title: Overview: Real Time Protocols for Brower-based Applications
Creation_date: 2010-11-11
WG ID: Independent Submission
Number_of_pages: 9
Abstract:
This document gives an overview of a protocol suite intended for use
with real-time applications that can be deployed in browsers - "real
time communication on the Web".
It intends to serve as a starting and coordination point to make sure
all the parts that are needed to achieve this goal are findable, and
that the parts that belong in the Internet protocol suite are fully
specified and on the right publication track.
This work is an attempt to synthesize the input of many people, but
makes no claims to fully represent the views of any of them. All
parts of the document should be regarded as open for discussion.
The IETF Secretariat.
_______________________________________________ dispatch mailing list dispatch@ietf.org<mailto:dispatch@ietf.org> https://www.ietf.org/mailman/listinfo/dispatch
Hi Justin, It would be very desirable to agree on the MTI codecs for both audio and video to ensure interoperability. As you say people/companies have different reasons for preferring codecs. In case of video codecs the reality is that it will be very difficult to reach an agreement over VP8 vs. H.264. One of the practical reasons to prefer H.264 is that is already so widely supported. For instance in mobile devices HW acceleration is important (especially for encoding), and we have it today in many platforms for H.264, but not necessarily for other video codecs. Markus From: ext Justin Uberti [mailto:juberti@google.com] Sent: 22 December, 2010 18:15 To: Ingemar Johansson S Cc: dispatch@ietf.org; rtc-web@alvestrand.no; Isomaki Markus (Nokia-CIC/Espoo) Subject: Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Ingemar, 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. 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. --justin On Tue, Dec 21, 2010 at 11:44 PM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com<mailto:ingemar.s.johansson@ericsson.com>> wrote: Hi Not meaning to express any preference in any direction but more a question to the more experiened IETFers. My impression here is that algorithms devised outside the IETF are rarely mandated in IETF frameworks. Two examples that I can come up with are 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 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 (http://tools.ietf.org/wg/fecframe/) 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) 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 ?. Please feel free to bash my conclusion. /Ingemar ------------------------------------------- Message: 1 Date: Tue, 21 Dec 2010 21:38:42 +0000 From: <Markus.Isomaki@nokia.com<mailto:Markus.Isomaki@nokia.com>> Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 To: <peter.musgrave@magorcorp.com<mailto:peter.musgrave@magorcorp.com>>, <harald@alvestrand.no<mailto:harald@alvestrand.no>> Cc: rtc-web@alvestrand.no<mailto:rtc-web@alvestrand.no>, dispatch@ietf.org<mailto:dispatch@ietf.org>, ted.ietf@gmail.com<mailto:ted.ietf@gmail.com> Message-ID: <DD8B10B86502AB488CB2D3DB4C546E3806DA99@008-AM1MPN1-003.mgdnok.nokia.com<mailto:DD8B10B86502AB488CB2D3DB4C546E3806DA99@008-AM1MPN1-003.mgdnok.nokia.com>> Content-Type: text/plain; charset="us-ascii" Hi Peter, all, 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. So I don't at least buy the argument that we should choose VP8 as mandatory to implement video codec because of IPR reasons. 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. Regards, Markus From: dispatch-bounces@ietf.org<mailto:dispatch-bounces@ietf.org> [mailto:dispatch-bounces@ietf.org<mailto:dispatch-bounces@ietf.org>] On Behalf Of ext Peter Musgrave Sent: 17 December, 2010 13:48 To: Harald Alvestrand Cc: rtc-web@alvestrand.no<mailto:rtc-web@alvestrand.no>; dispatch@ietf.org<mailto:dispatch@ietf.org>; Ted Hardie Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 I'd also like to echo Alan's thanks for these drafts. The protocol doc is very clear. [If you read only one dispatch draft this Christmas, make it this one. ;-) ] 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). Regards, Peter Musgrave Nits Introduction s/veichle/vehicle/ Section 2 Para "Within each.." s/implementaiton/implementation/ Section 4 Para1 "such as" (something missing here?) Section 5 Para2 "There is no third mandatory to implement" ? Was there a mention of a third before. Not sure why this statement is there. On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote: This is the overview document for the IETF-related RTC-WEB work. -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Date: Wed, 10 Nov 2010 03:31:05 -0800 (PST) From: IETF I-D Submission Tool <idsubmission@ietf.org<mailto:idsubmission@ietf.org>><mailto:idsubmission@ietf.org<mailto:idsubmission@ietf.org>> To: harald@alvestrand.no<mailto:harald@alvestrand.no><mailto:harald@alvestrand.no<mailto:harald@alvestrand.no>> 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. Filename: draft-alvestrand-dispatch-rtcweb-protocols Revision: 00 Title: Overview: Real Time Protocols for Brower-based Applications Creation_date: 2010-11-11 WG ID: Independent Submission Number_of_pages: 9 Abstract: This document gives an overview of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This work is an attempt to synthesize the input of many people, but makes no claims to fully represent the views of any of them. All parts of the document should be regarded as open for discussion. The IETF Secretariat. _______________________________________________ dispatch mailing list dispatch@ietf.org<mailto:dispatch@ietf.org><mailto:dispatch@ietf.org<mailto:dispatch@ietf.org>> https://www.ietf.org/mailman/listinfo/dispatch -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.ietf.org/mail-archive/web/dispatch/attachments/20101221/46ec4317/attachment.htm> ------------------------------ _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web
Hi Justin In some sense you are very right but I make a slightly different interpretation. Quoting section 4 in RFC3711 "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." 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. Now I don't say that this is _the_ interpretation, please correct me if neecessary. I don't intend to enter a heated debate about which codecs should be used. 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 ? I don't have the answers, hope that some of the "grey-beards" can chime in and give some guidance later on. Regards and happy holidays /Ingemar ________________________________ From: Justin Uberti [mailto:juberti@google.com] Sent: den 22 december 2010 17:15 To: Ingemar Johansson S Cc: dispatch@ietf.org; rtc-web@alvestrand.no; Markus.Isomaki@nokia.com Subject: Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Ingemar, 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. 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. --justin On Tue, Dec 21, 2010 at 11:44 PM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com<mailto:ingemar.s.johansson@ericsson.com>> wrote: Hi Not meaning to express any preference in any direction but more a question to the more experiened IETFers. My impression here is that algorithms devised outside the IETF are rarely mandated in IETF frameworks. Two examples that I can come up with are 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 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 (http://tools.ietf.org/wg/fecframe/) 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) 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 ?. Please feel free to bash my conclusion. /Ingemar ------------------------------------------- Message: 1 Date: Tue, 21 Dec 2010 21:38:42 +0000 From: <Markus.Isomaki@nokia.com<mailto:Markus.Isomaki@nokia.com>> Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 To: <peter.musgrave@magorcorp.com<mailto:peter.musgrave@magorcorp.com>>, <harald@alvestrand.no<mailto:harald@alvestrand.no>> Cc: rtc-web@alvestrand.no<mailto:rtc-web@alvestrand.no>, dispatch@ietf.org<mailto:dispatch@ietf.org>, ted.ietf@gmail.com<mailto:ted.ietf@gmail.com> Message-ID: <DD8B10B86502AB488CB2D3DB4C546E3806DA99@008-AM1MPN1-003.mgdnok.nokia.com<mailto:DD8B10B86502AB488CB2D3DB4C546E3806DA99@008-AM1MPN1-003.mgdnok.nokia.com>> Content-Type: text/plain; charset="us-ascii" Hi Peter, all, 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. So I don't at least buy the argument that we should choose VP8 as mandatory to implement video codec because of IPR reasons. 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. Regards, Markus From: dispatch-bounces@ietf.org<mailto:dispatch-bounces@ietf.org> [mailto:dispatch-bounces@ietf.org<mailto:dispatch-bounces@ietf.org>] On Behalf Of ext Peter Musgrave Sent: 17 December, 2010 13:48 To: Harald Alvestrand Cc: rtc-web@alvestrand.no<mailto:rtc-web@alvestrand.no>; dispatch@ietf.org<mailto:dispatch@ietf.org>; Ted Hardie Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 I'd also like to echo Alan's thanks for these drafts. The protocol doc is very clear. [If you read only one dispatch draft this Christmas, make it this one. ;-) ] 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). Regards, Peter Musgrave Nits Introduction s/veichle/vehicle/ Section 2 Para "Within each.." s/implementaiton/implementation/ Section 4 Para1 "such as" (something missing here?) Section 5 Para2 "There is no third mandatory to implement" ? Was there a mention of a third before. Not sure why this statement is there. On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote: This is the overview document for the IETF-related RTC-WEB work. -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Date: Wed, 10 Nov 2010 03:31:05 -0800 (PST) From: IETF I-D Submission Tool <idsubmission@ietf.org<mailto:idsubmission@ietf.org>><mailto:idsubmission@ietf.org<mailto:idsubmission@ietf.org>> To: harald@alvestrand.no<mailto:harald@alvestrand.no><mailto:harald@alvestrand.no<mailto:harald@alvestrand.no>> 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. Filename: draft-alvestrand-dispatch-rtcweb-protocols Revision: 00 Title: Overview: Real Time Protocols for Brower-based Applications Creation_date: 2010-11-11 WG ID: Independent Submission Number_of_pages: 9 Abstract: This document gives an overview of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This work is an attempt to synthesize the input of many people, but makes no claims to fully represent the views of any of them. All parts of the document should be regarded as open for discussion. The IETF Secretariat. _______________________________________________ dispatch mailing list dispatch@ietf.org<mailto:dispatch@ietf.org><mailto:dispatch@ietf.org<mailto:dispatch@ietf.org>> https://www.ietf.org/mailman/listinfo/dispatch
On 12/23/10 10:44, Ingemar Johansson S wrote:
Hi Justin In some sense you are very right but I make a slightly different interpretation. Quoting section 4 in RFC3711 "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." 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. Now I don't say that this is _the_ interpretation, please correct me if neecessary. I don't intend to enter a heated debate about which codecs should be used. 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 ? I don't have the answers, hope that some of the "grey-beards" can chime in and give some guidance later on. Regards and happy holidays /Ingemar
------------------------------------------------------------------------ *From:* Justin Uberti [mailto:juberti@google.com] *Sent:* den 22 december 2010 17:15 *To:* Ingemar Johansson S *Cc:* dispatch@ietf.org; rtc-web@alvestrand.no; Markus.Isomaki@nokia.com *Subject:* Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00
Ingemar,
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. Ingemar,
I think you misinterpret RFC 3711 slightly. More important than the text you quote is the text in section 5 of RFC 3711: 5. Default and mandatory-to-implement Transforms The default transforms also are mandatory-to-implement transforms in SRTP. Of course, "mandatory-to-implement" does not imply "mandatory-to-use". Table 1 summarizes the pre-defined transforms. The default values below are valid for the pre-defined transforms. mandatory-to-impl. optional default encryption AES-CM, NULL AES-f8 AES-CM message integrity HMAC-SHA1 - HMAC-SHA1 key derivation (PRF) AES-CM - AES-CM Table 1: Mandatory-to-implement, optional and default transforms in SRTP and SRTCP. In other words, an SRTP implementation that does not implement AES-CM and HMAC-SHA1 is not a conformant SRTP implementation.
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.
I completely agree with your reasoning here. Note that neither AES nor HMAC are IETF defined algorithms. It is indeed quite common to refer to non-IETF technologies in mandatory-to-implement statements (even if, as in the case of UTF-8, we sometimes choose to reference those specifications by writing an RFC that describes the link). Harald
Hi I must admit that I am a real bad reader, can only blame it on Santa... :-( Tried to find some background info on AES-CTR and according to http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/workshop1/papers/lipmaa... it was devised already in 1979, this probably explains a lack of IPR disclosure for RFC3711 (at least I have not found any) Regards Ingemar ________________________________________ Från: Harald Alvestrand [harald@alvestrand.no] Skickat: den 26 december 2010 00:11 Till: Ingemar Johansson S Kopia: Justin Uberti; rtc-web@alvestrand.no; dispatch@ietf.org; Markus.Isomaki@nokia.com Ämne: Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 On 12/23/10 10:44, Ingemar Johansson S wrote: Hi Justin In some sense you are very right but I make a slightly different interpretation. Quoting section 4 in RFC3711 "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." 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. Now I don't say that this is _the_ interpretation, please correct me if neecessary. I don't intend to enter a heated debate about which codecs should be used. 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 ? I don't have the answers, hope that some of the "grey-beards" can chime in and give some guidance later on. Regards and happy holidays /Ingemar ________________________________ From: Justin Uberti [mailto:juberti@google.com] Sent: den 22 december 2010 17:15 To: Ingemar Johansson S Cc: dispatch@ietf.org<mailto:dispatch@ietf.org>; rtc-web@alvestrand.no<mailto:rtc-web@alvestrand.no>; Markus.Isomaki@nokia.com<mailto:Markus.Isomaki@nokia.com> Subject: Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Ingemar, 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. Ingemar, I think you misinterpret RFC 3711 slightly. More important than the text you quote is the text in section 5 of RFC 3711: 5. Default and mandatory-to-implement Transforms The default transforms also are mandatory-to-implement transforms in SRTP. Of course, "mandatory-to-implement" does not imply "mandatory-to-use". Table 1 summarizes the pre-defined transforms. The default values below are valid for the pre-defined transforms. mandatory-to-impl. optional default encryption AES-CM, NULL AES-f8 AES-CM message integrity HMAC-SHA1 - HMAC-SHA1 key derivation (PRF) AES-CM - AES-CM Table 1: Mandatory-to-implement, optional and default transforms in SRTP and SRTCP. In other words, an SRTP implementation that does not implement AES-CM and HMAC-SHA1 is not a conformant SRTP implementation. 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. I completely agree with your reasoning here. Note that neither AES nor HMAC are IETF defined algorithms. It is indeed quite common to refer to non-IETF technologies in mandatory-to-implement statements (even if, as in the case of UTF-8, we sometimes choose to reference those specifications by writing an RFC that describes the link). Harald
On 12/26/2010 12:37 PM, Ingemar Johansson S wrote:
Hi
I must admit that I am a real bad reader, can only blame it on Santa... :-(
Tried to find some background info on AES-CTR and according to http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/workshop1/papers/lipmaa... it was devised already in 1979, this probably explains a lack of IPR disclosure for RFC3711 (at least I have not found any) I think a general IPR release was part of the requirements for Rijndael to enter into the NIST competition for the selection of the AES algorithm.
If the US Government insists that something should be unencumbered, it's a little more likely to be....
Regards Ingemar
________________________________________ Från: Harald Alvestrand [harald@alvestrand.no] Skickat: den 26 december 2010 00:11 Till: Ingemar Johansson S Kopia: Justin Uberti; rtc-web@alvestrand.no; dispatch@ietf.org; Markus.Isomaki@nokia.com Ämne: Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00
On 12/23/10 10:44, Ingemar Johansson S wrote: Hi Justin
In some sense you are very right but I make a slightly different interpretation.
Quoting section 4 in RFC3711 "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." 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. Now I don't say that this is _the_ interpretation, please correct me if neecessary.
I don't intend to enter a heated debate about which codecs should be used. 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 ? I don't have the answers, hope that some of the "grey-beards" can chime in and give some guidance later on.
Regards and happy holidays /Ingemar
________________________________ From: Justin Uberti [mailto:juberti@google.com] Sent: den 22 december 2010 17:15 To: Ingemar Johansson S Cc: dispatch@ietf.org<mailto:dispatch@ietf.org>; rtc-web@alvestrand.no<mailto:rtc-web@alvestrand.no>; Markus.Isomaki@nokia.com<mailto:Markus.Isomaki@nokia.com> Subject: Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00
Ingemar,
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. Ingemar,
I think you misinterpret RFC 3711 slightly.
More important than the text you quote is the text in section 5 of RFC 3711:
5. Default and mandatory-to-implement Transforms
The default transforms also are mandatory-to-implement transforms in SRTP. Of course, "mandatory-to-implement" does not imply "mandatory-to-use". Table 1 summarizes the pre-defined transforms. The default values below are valid for the pre-defined transforms.
mandatory-to-impl. optional default
encryption AES-CM, NULL AES-f8 AES-CM message integrity HMAC-SHA1 - HMAC-SHA1 key derivation (PRF) AES-CM - AES-CM
Table 1: Mandatory-to-implement, optional and default transforms in SRTP and SRTCP.
In other words, an SRTP implementation that does not implement AES-CM and HMAC-SHA1 is not a conformant SRTP implementation.
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. I completely agree with your reasoning here.
Note that neither AES nor HMAC are IETF defined algorithms. It is indeed quite common to refer to non-IETF technologies in mandatory-to-implement statements (even if, as in the case of UTF-8, we sometimes choose to reference those specifications by writing an RFC that describes the link).
Harald
participants (4)
-
Harald Alvestrand -
Ingemar Johansson S -
Justin Uberti -
Markus.Isomaki＠nokia.com