From nobody Fri Apr 3 13:34:01 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56101A0250; Fri, 3 Apr 2015 13:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puSuaZyFaRxU; Fri, 3 Apr 2015 13:33:58 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83BF81A0242; Fri, 3 Apr 2015 13:33:58 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t33KXceX052960 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2015 15:33:48 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Jean-Marc Valin" Date: Fri, 03 Apr 2015 15:33:38 -0500 Message-ID: In-Reply-To: References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" , Derek Atkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 20:34:00 -0000 (+payload@ietf.org) I just noticed this thread is has included the payload mail list. Since the discussion involves potential material changes (i.e. normative language changes) , the working group should at least see it. /Ben. On 1 Apr 2015, at 17:50, Ben Campbell wrote: > On 1 Apr 2015, at 16:20, Jean-Marc Valin wrote: > >> Based on Derek's latest suggestion, the text would become: >> >> "Since Opus does not provide any confidentiality or integrity >> protection, implementations SHOULD use one of the possible RTP >> Security methods (See RFC7201, RFC7202)." >> >> I think that should resolve the issue that was raised. > > I'm not sure that's the right solution. First, 7201 and 7202 are > informational, so I'm not sure we want to insert a normative reference > to them here. > > But more to the point, while I concur with the desire to push for > better protections, I don't think a codec payload spec is the right > place to do it. It risks having different security requirements for > different codecs when used by the same RTP application. I can see that > if there are really security difference (e.g. if some codec had built > in protection.) > > I think this is rather the point of 7202, although I notice section 6 > of that draft says: "It is also expected that a similar [MTI crypto > spec] will be produced for voice-over-IP applications using SIP and > RTP." Unfortunately, I don't think that ever happened. > > So my suggestion would be something more to the effect of: > > "Opus does not provide any built-in confidentiality or integrity > protection. Protection requirements vary between RTP applications. > See RFC 7201 and RFC 7202 for a discussion. > >> >> Jean-Marc >> >> On 01/04/15 05:11 PM, Ben Campbell wrote: >>> Hi Roni and Derek, >>> >>> This thread sort of tailed off in February. Has the discussion been >>> resolved? >>> >>> Thanks! >>> >>> Ben. >>> >>> On 19 Feb 2015, at 11:07, Derek Atkins wrote: >>> >>>> Roni, >>>> >>>> I'm not an RTP guy. To me "SRTP" is a general class of "Secure >>>> RTP" protocols. So let's work on that as my starting point: >>>> implementations SHOULD protect their RTP stream. >>>> >>>> Based on that, how about a re-wording here? Instead of just >>>> saying "MAY use SRTP", how about something like "SHOULD use one >>>> of the possible RTP Security methods (See RFC7201, RFC7202)"? >>>> (Obviously this can be worded better). >>>> >>>> -derek >>>> >>>> Roni Even writes: >>>> >>>>> Hi, The reason for the may is discussed in RFC7201 and RFC >>>>> 7202, it can be a SHOULD and these RFCs exaplain when it is not >>>>> required to use SRTP. Maybe add a reference to these RFCs in >>>>> the security section when saying talking about good reasons for >>>>> not using SRTP >>>>> >>>>> Roni Even >>>>> >>>>> ________________________________________ From: Jean-Marc Valin >>>>> [jvalin@mozilla.com] on behalf of Jean-Marc Valin >>>>> [jmvalin@mozilla.com] Sent: Tuesday, February 17, 2015 10:23 >>>>> PM To: Derek Atkins; iesg@ietf.org; secdir@ietf.org Cc: >>>>> payload-chairs@tools.ietf.org; koenvos74@gmail.com; >>>>> jspittka@gmail.com Subject: Re: sec-dir review of >>>>> draft-ietf-payload-rtp-opus-08 >>>>> >>>>> Hi Derek, >>>>> >>>>> There was no particular reason for the MAY, the text was merely >>>>> copied from other RTP payload RFC. I totally agree with making >>>>> it a SHOULD. >>>>> >>>>> Thanks, >>>>> >>>>> Jean-Marc >>>>> >>>>> On 17/02/15 02:54 PM, Derek Atkins wrote: >>>>>> Hi, >>>>>> >>>>>> I have reviewed this document as part of the security >>>>>> directorate's ongoing effort to review all IETF documents >>>>>> being processed by the IESG. These comments were written >>>>>> with the intent of improving security requirements and >>>>>> considerations in IETF drafts. Comments not addressed in >>>>>> last call may be included in AD reviews during the IESG >>>>>> review. Document editors and WG chairs should treat these >>>>>> comments just like any other last call comments. >>>>>> >>>>>> Summary: >>>>>> >>>>>> Ready to publish with a question: I question why the use of >>>>>> SRTP is a MAY and not a SHOULD (as detailed in the Security >>>>>> Considerations section). Considering PERPASS I believe this >>>>>> should be a SHOULD; someone should have a very good reason >>>>>> why they are NOT using SRTP. >>>>>> >>>>>> Details: >>>>>> >>>>>> This document defines the Real-time Transport Protocol (RTP) >>>>>> payload format for packetization of Opus encoded speech and >>>>>> audio data necessary to integrate the codec in the most >>>>>> compatible way. Further, it describes media type >>>>>> registrations for the RTP payload format. >>>>>> >>>>>> I have no other comments on this document. >>>>>> >>>>>> -derek >>>>>> >>>>> >>>>> _______________________________________________ secdir mailing >>>>> list secdir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/secdir wiki: >>>>> http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>>>> >>>>> >>>> >>>> -- Derek Atkins 617-623-3745 derek@ihtfp.com >>>> www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Apr 3 13:44:16 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587251A0373; Fri, 3 Apr 2015 13:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, SPF_FAIL=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSU0VbJA4HsB; Fri, 3 Apr 2015 13:44:13 -0700 (PDT) Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB631A036C; Fri, 3 Apr 2015 13:44:13 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 45D4CC1AC0; Fri, 3 Apr 2015 20:44:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqwpudNTvkqY; Fri, 3 Apr 2015 20:44:13 +0000 (UTC) Received: from [10.252.25.225] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 26771C15B4; Fri, 3 Apr 2015 20:44:13 +0000 (UTC) Message-ID: <551EFB9C.4040504@xiph.org> Date: Fri, 03 Apr 2015 13:44:12 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: Ben Campbell , Jean-Marc Valin References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" , Derek Atkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 20:44:15 -0000 Ben Campbell wrote: >> So my suggestion would be something more to the effect of: >> >> "Opus does not provide any built-in confidentiality or integrity >> protection. Protection requirements vary between RTP applications. >> See RFC 7201 and RFC 7202 for a discussion. This seems like reasonable text to me. I agree with the rationale that preceded it. As much as I want to see encryption everywhere, a payload format is not the right place to mandate it. From nobody Fri Apr 3 14:16:16 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCB71A1A72; Fri, 3 Apr 2015 14:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-6bCLsroxz8; Fri, 3 Apr 2015 14:16:09 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E7E1A1A65; Fri, 3 Apr 2015 14:16:09 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t33LFqtT056666 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2015 16:16:03 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Jean-Marc Valin" Date: Fri, 03 Apr 2015 16:15:52 -0500 Message-ID: <65E44C9D-D7F2-41C9-B54A-A37FDAEF04A7@nostrum.com> In-Reply-To: References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" , Derek Atkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 21:16:10 -0000 On 3 Apr 2015, at 15:33, Ben Campbell wrote: > I just noticed this thread is has included the payload mail list. Oops, I meant to say has _not_ included... From nobody Mon Apr 6 09:13:53 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC921A8AF5; Mon, 6 Apr 2015 09:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSuxXTk6HAjx; Mon, 6 Apr 2015 09:13:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10EE21A8AED; Mon, 6 Apr 2015 09:13:44 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t36GDUo1007147 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Apr 2015 11:13:40 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Derek Atkins" Date: Mon, 06 Apr 2015 11:13:30 -0500 Message-ID: <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> In-Reply-To: References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 16:13:48 -0000 On 6 Apr 2015, at 11:09, Derek Atkins wrote: > "Timothy B. Terriberry" writes: > >> Ben Campbell wrote: >>>> So my suggestion would be something more to the effect of: >>>> >>>> "Opus does not provide any built-in confidentiality or integrity >>>> protection. Protection requirements vary between RTP applications. >>>> See RFC 7201 and RFC 7202 for a discussion. >> >> This seems like reasonable text to me. I agree with the rationale >> that >> preceded it. As much as I want to see encryption everywhere, a >> payload >> format is not the right place to mandate it. > > As was stated already in this thread, the expected follow up drafts > for > MTI security have not been written. > > I leave it up to the Security ADs who have the real power here, but I > still prefer my original wording (including the SHOULD). > > I understand your reluctance because it's a codec, but it's the first > codec to get through the process since the Perpass work, which > basically > says "everything should be encrypted." Since you cannot go back in > time > to modify the existing RFCs, you can augment them going forward by > other > additions. > > As for the concern about "different security requirements for > different > codecs", frankly I don't buy that argument. Either your RTP > application > supports security or it doesn't. Once it does, it should be able to > negotiate that along side the codec negotitation. So I don't see the > concern -- we're not mandating a specific security technology, just > that > you SHOULD use one. Well, that's true regardless of the codec, isn't > it? > > Or are you really saying "We don't care about security. We just want > to > be able to use this codec in existing, insecure RTP applications > without > adding new securty measures"? I'm saying this is the wrong layer to solve the problem. We had some work planned to better specify this in general for RTP. I think the right answer is finish that work. If we do that right, it should apply regardless of codec. From nobody Mon Apr 6 11:44:54 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5375E1A90BB; Mon, 6 Apr 2015 11:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lb2ooZulJvob; Mon, 6 Apr 2015 11:44:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156561A90B4; Mon, 6 Apr 2015 11:44:43 -0700 (PDT) Received: from unnumerable-2.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t36IiZFP019732 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Apr 2015 13:44:35 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable-2.local Message-ID: <5522D40E.8040402@nostrum.com> Date: Mon, 06 Apr 2015 13:44:30 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ben Campbell , Derek Atkins References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> In-Reply-To: <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 18:44:47 -0000 inline (particularly for Derek) On 4/6/15 11:13 AM, Ben Campbell wrote: > On 6 Apr 2015, at 11:09, Derek Atkins wrote: > >> "Timothy B. Terriberry" writes: >> >>> Ben Campbell wrote: >>>>> So my suggestion would be something more to the effect of: >>>>> >>>>> "Opus does not provide any built-in confidentiality or integrity >>>>> protection. Protection requirements vary between RTP applications. >>>>> See RFC 7201 and RFC 7202 for a discussion. >>> >>> This seems like reasonable text to me. I agree with the rationale that >>> preceded it. As much as I want to see encryption everywhere, a payload >>> format is not the right place to mandate it. >> >> As was stated already in this thread, the expected follow up drafts for >> MTI security have not been written. >> >> I leave it up to the Security ADs who have the real power here, but I >> still prefer my original wording (including the SHOULD). >> >> I understand your reluctance because it's a codec, but it's the first >> codec to get through the process since the Perpass work, which basically >> says "everything should be encrypted." Since you cannot go back in time >> to modify the existing RFCs, you can augment them going forward by other >> additions. >> >> As for the concern about "different security requirements for different >> codecs", frankly I don't buy that argument. Either your RTP application >> supports security or it doesn't. Once it does, it should be able to >> negotiate that along side the codec negotitation. So I don't see the >> concern -- we're not mandating a specific security technology, just that >> you SHOULD use one. Well, that's true regardless of the codec, isn't >> it? >> >> Or are you really saying "We don't care about security. We just want to >> be able to use this codec in existing, insecure RTP applications without >> adding new securty measures"? > > I'm saying this is the wrong layer to solve the problem. > > We had some work planned to better specify this in general for RTP. I > think the right answer is finish that work. If we do that right, it > should apply regardless of codec. > That's exactly right. We've had this conversation several times before. The individual payload documents are not the place to add the kind of guidance Derek is asking for. They should be about how you put things in RTP, not how applications use (and secure RTP), unless there's something unique about the payload that interacts with the general mechanics for using and securing RTP. Stephen will remember that we've queued up work on a document that would describe securing unicast RTP set up with SDP (capturing the outcome of the rtpsec bof at IETF68). The last I heard on the subject Dan Wing was taking the token to work on that document, but it's been awhile. That's where the effort should focus - an individual payload document is not the right place. > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Mon Apr 6 11:51:07 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE771A90CA; Mon, 6 Apr 2015 11:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdMZKNhWXqe7; Mon, 6 Apr 2015 11:50:56 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A131A90C7; Mon, 6 Apr 2015 11:50:56 -0700 (PDT) Received: from [81.187.2.149] (port=39688 helo=[192.168.0.22]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YfC6i-0001si-D2; Mon, 06 Apr 2015 19:50:52 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <5522D40E.8040402@nostrum.com> Date: Mon, 6 Apr 2015 19:50:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" , Derek Atkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 18:51:01 -0000 On 6 Apr 2015, at 19:44, Robert Sparks wrote: > inline (particularly for Derek) > On 4/6/15 11:13 AM, Ben Campbell wrote: >> On 6 Apr 2015, at 11:09, Derek Atkins wrote: >>=20 >>> "Timothy B. Terriberry" writes: >>>=20 >>>> Ben Campbell wrote: >>>>>> So my suggestion would be something more to the effect of: >>>>>>=20 >>>>>> "Opus does not provide any built-in confidentiality or integrity >>>>>> protection. Protection requirements vary between RTP = applications. >>>>>> See RFC 7201 and RFC 7202 for a discussion. >>>>=20 >>>> This seems like reasonable text to me. I agree with the rationale = that >>>> preceded it. As much as I want to see encryption everywhere, a = payload >>>> format is not the right place to mandate it. >>>=20 >>> As was stated already in this thread, the expected follow up drafts = for >>> MTI security have not been written. >>>=20 >>> I leave it up to the Security ADs who have the real power here, but = I >>> still prefer my original wording (including the SHOULD). >>>=20 >>> I understand your reluctance because it's a codec, but it's the = first >>> codec to get through the process since the Perpass work, which = basically >>> says "everything should be encrypted." Since you cannot go back in = time >>> to modify the existing RFCs, you can augment them going forward by = other >>> additions. >>>=20 >>> As for the concern about "different security requirements for = different >>> codecs", frankly I don't buy that argument. Either your RTP = application >>> supports security or it doesn't. Once it does, it should be able to >>> negotiate that along side the codec negotitation. So I don't see = the >>> concern -- we're not mandating a specific security technology, just = that >>> you SHOULD use one. Well, that's true regardless of the codec, = isn't >>> it? >>>=20 >>> Or are you really saying "We don't care about security. We just = want to >>> be able to use this codec in existing, insecure RTP applications = without >>> adding new securty measures"? >>=20 >> I'm saying this is the wrong layer to solve the problem. >>=20 >> We had some work planned to better specify this in general for RTP. I = think the right answer is finish that work. If we do that right, it = should apply regardless of codec. >>=20 > That's exactly right. >=20 > We've had this conversation several times before. The individual = payload documents are not the place to add the kind of guidance Derek is = asking for. They should be about how you put things in RTP, not how = applications use (and secure RTP), unless there's something unique about = the payload that interacts with the general mechanics for using and = securing RTP. >=20 > Stephen will remember that we've queued up work on a document that = would describe securing unicast RTP set up with SDP (capturing the = outcome of the rtpsec bof at IETF68). The last I heard on the subject = Dan Wing was taking the token to work on that document, but it's been = awhile. That's where the effort should focus - an individual payload = document is not the right place. +1=20 As Robert, and others, say, RTP payload format documents are not the = right place to mandate security mechanisms. This is the point of = RFC7202, which is about how strong security can best be defined for = classes of RTP applications. This is not in conflict with the perpass = work, since the goal of RFC7202 is to show how to provide strong = security. --=20 Colin Perkins https://csperkins.org/ From nobody Mon Apr 6 20:04:26 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F07D1AD244; Mon, 6 Apr 2015 20:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pose-c4EYAku; Mon, 6 Apr 2015 20:04:15 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789E01AD23D; Mon, 6 Apr 2015 20:04:15 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3733sDA065769 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Apr 2015 22:04:04 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Spencer Dawkins" Date: Mon, 06 Apr 2015 22:03:53 -0500 Message-ID: <850D891D-3D80-4888-A815-EAC9E712E630@nostrum.com> In-Reply-To: <20150407023433.21936.12615.idtracker@ietfa.amsl.com> References: <20150407023433.21936.12615.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: draft-ietf-payload-rtp-opus@ietf.org, payload-chairs@ietf.org, payload@ietf.org, draft-ietf-payload-rtp-opus.shepherdl@ietf.org, The IESG Subject: Re: [payload] Spencer Dawkins' No Objection on draft-ietf-payload-rtp-opus-08: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 03:04:16 -0000 On 6 Apr 2015, at 21:34, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-payload-rtp-opus-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) > > > Please refer to > http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Meta-comment - it looks like the notification field is pointing only > to > Ali. If that's intentional, rock on, but I've had some > accidentally-minimal notification lists on drafts recently, and wanted > to > mention that. I regenerate the notify list for the draft. But since that doesn't affect this thread, I manually added at least some of the relevant aliases to the CC list. [...] > > In other news, I support Kathleen's Discuss on SHOULD SRTP, and if it > becomes a SHOULD and not a MUST, I'd suggest adding a sentence or two > explaining why not using SRTP is the right thing to do. I mentioned this off-list to Kathleen, but should probably get it on the lists: There is a thread on this topic, triggered by Derek's sec-dir review. The problem is, that sort of security requirement should be up to RTP and the individual application, not the codec. That is, we probably don't want a given RTP application to have to worry about differing security requirements for different codecs, unless those codecs have some unique security implications. The issue is, the situation for RTP is a bit confused. We have RFCs 7201 and 7202, which offer some informational guidance. It would be nice to have some normative guidance for unicast RTP applications, but that's work that needs to be done. So, I think the best thing an RTP payload format can do right now is to say something to the effect that Opus doesn't offer built-in protection, protection requirements are up to the application, and see 7201 and 7202 for discussion. Then we need to do whatever we need to do at the RTP application level to encourage the use of SRTP. Thanks! Ben. From nobody Mon Apr 6 20:06:14 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760F21B2E20; Mon, 6 Apr 2015 20:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQeB1hdZcn68; Mon, 6 Apr 2015 20:06:02 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA821B2E2A; Mon, 6 Apr 2015 20:05:26 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3735Chj065927 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Apr 2015 22:05:22 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Spencer Dawkins" Date: Mon, 06 Apr 2015 22:05:11 -0500 Message-ID: <5901E24F-86E6-45C1-803D-C5A0799D839F@nostrum.com> In-Reply-To: <20150407023433.21936.12615.idtracker@ietfa.amsl.com> References: <20150407023433.21936.12615.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: draft-ietf-payload-rtp-opus@ietf.org, payload-chairs@ietf.org, payload@ietf.org, draft-ietf-payload-rtp-opus.shepherdl@ietf.org, The IESG Subject: Re: [payload] Spencer Dawkins' No Objection on draft-ietf-payload-rtp-opus-08: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 03:06:07 -0000 (Forwarding to additional recipients, due to the notify field issue Spencer mentioned below (now fixed.) On 6 Apr 2015, at 21:34, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-payload-rtp-opus-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) > > > Please refer to > http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Meta-comment - it looks like the notification field is pointing only > to > Ali. If that's intentional, rock on, but I've had some > accidentally-minimal notification lists on drafts recently, and wanted > to > mention that. > > This draft seemed very clear to me, one not skilled in the art. Thank > you > for that. > > I have a few comments. If you have questions, please ask, but they're > non-blocking (so do the right thing). > > In this text: > > 3. Opus Codec > > Further, Opus allows transmitting stereo signals. > > I wasn't sure what this was telling me until I got to section 3.4, and > saw this text: "signaled in-band in the Opus payload". Perhaps adding > that phrase in Section 3 would be helpful? > > In this text: > > 3.1.2. Variable versus Constant Bitrate > > One > reason for choosing CBR is the potential information leak that > _might_ occur when encrypting the compressed stream. See [RFC6562] > for guidelines on when VBR is appropriate for encrypted audio > communications. > > I THINK I know what "potential information leak" means in this case, > but > I'm guessing. I learned a lot from the [RFC6562] reference. Is it > possible to provide a short clue here? Would it be correct to say > something like "One reason for choosing CBR is that some codecs have > been > observed to provide predictable VBR patterns for highly structured > dialogs where only a few phrases are expected, and potentially leaking > information without requiring an eavesdropper to decrypt the payload"? > > Also in 3.1.2: > > The bitrate can be adjusted at any point in time. To avoid > congestion, the average bitrate SHOULD NOT exceed the available > network bandwidth. > > I'm kind of wondering how you intend for the sender to know what the > "available network bandwidth" is. I notice a reference in Section 3.3 > to > > > (2) an externally-provided estimate of the > channel's capacity; > > Is "the available network bandwidth" this externally provided > estimate? > What should a sender be looking at, to fulfill this SHOULD NOT? > > Of course, I'm wondering why this is SHOULD NOT, instead of MUST NOT. > Is > this recognizing that available network bandwidth can change > instantaneously (so a careful sender might still find itself sending > too > fast for a short period of time), or is there something else going on? > > As long as I'm mentioning section 3.3, if the "externally-provided > estimate" had some reference, that would be helpful (unless, of > course, > this is obvious to those skilled in the art). The term only appears > twice > in 3.3, with no pointers. > > In this text: > > 5. Congestion Control > > It is RECOMMENDED that senders of Opus encoded data apply congestion > control. > > Is there a particular mechanism you're thinking of here? If you could > make that clearer, even just providing a reference, that would be > helpful > for me as a reader. > > In other news, I support Kathleen's Discuss on SHOULD SRTP, and if it > becomes a SHOULD and not a MUST, I'd suggest adding a sentence or two > explaining why not using SRTP is the right thing to do. From nobody Mon Apr 6 20:08:30 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A153B1AD350; Mon, 6 Apr 2015 20:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTgxxFgEdpEn; Mon, 6 Apr 2015 20:08:18 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14AAA1B2DDA; Mon, 6 Apr 2015 20:08:08 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3737rBE066147 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Apr 2015 22:08:03 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Spencer Dawkins" Date: Mon, 06 Apr 2015 22:07:52 -0500 Message-ID: <86B9D67A-C5B8-4DDC-8BA5-5EB186A713BB@nostrum.com> In-Reply-To: <20150407023433.21936.12615.idtracker@ietfa.amsl.com> References: <20150407023433.21936.12615.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: draft-ietf-payload-rtp-opus@ietf.org, payload-chairs@ietf.org, draft-ietf-payload-rtp-opus.shepherd@ietf.org, payload@ietf.org, The IESG Subject: Re: [payload] Spencer Dawkins' No Objection on draft-ietf-payload-rtp-opus-08: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 03:08:19 -0000 (... and trying again. Sorry for the repeat;shepherd had too many "L"s) (Forwarding to additional recipients, due to the notify field issue Spencer mentioned below (now fixed.) On 6 Apr 2015, at 21:34, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-payload-rtp-opus-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) > > > Please refer to > http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Meta-comment - it looks like the notification field is pointing only > to > Ali. If that's intentional, rock on, but I've had some > accidentally-minimal notification lists on drafts recently, and wanted > to > mention that. > > This draft seemed very clear to me, one not skilled in the art. Thank > you > for that. > > I have a few comments. If you have questions, please ask, but they're > non-blocking (so do the right thing). > > In this text: > > 3. Opus Codec > > Further, Opus allows transmitting stereo signals. > > I wasn't sure what this was telling me until I got to section 3.4, and > saw this text: "signaled in-band in the Opus payload". Perhaps adding > that phrase in Section 3 would be helpful? > > In this text: > > 3.1.2. Variable versus Constant Bitrate > > One > reason for choosing CBR is the potential information leak that > _might_ occur when encrypting the compressed stream. See [RFC6562] > for guidelines on when VBR is appropriate for encrypted audio > communications. > > I THINK I know what "potential information leak" means in this case, > but > I'm guessing. I learned a lot from the [RFC6562] reference. Is it > possible to provide a short clue here? Would it be correct to say > something like "One reason for choosing CBR is that some codecs have > been > observed to provide predictable VBR patterns for highly structured > dialogs where only a few phrases are expected, and potentially leaking > information without requiring an eavesdropper to decrypt the payload"? > > Also in 3.1.2: > > The bitrate can be adjusted at any point in time. To avoid > congestion, the average bitrate SHOULD NOT exceed the available > network bandwidth. > > I'm kind of wondering how you intend for the sender to know what the > "available network bandwidth" is. I notice a reference in Section 3.3 > to > > > (2) an externally-provided estimate of the > channel's capacity; > > Is "the available network bandwidth" this externally provided > estimate? > What should a sender be looking at, to fulfill this SHOULD NOT? > > Of course, I'm wondering why this is SHOULD NOT, instead of MUST NOT. > Is > this recognizing that available network bandwidth can change > instantaneously (so a careful sender might still find itself sending > too > fast for a short period of time), or is there something else going on? > > As long as I'm mentioning section 3.3, if the "externally-provided > estimate" had some reference, that would be helpful (unless, of > course, > this is obvious to those skilled in the art). The term only appears > twice > in 3.3, with no pointers. > > In this text: > > 5. Congestion Control > > It is RECOMMENDED that senders of Opus encoded data apply congestion > control. > > Is there a particular mechanism you're thinking of here? If you could > make that clearer, even just providing a reference, that would be > helpful > for me as a reader. > > In other news, I support Kathleen's Discuss on SHOULD SRTP, and if it > becomes a SHOULD and not a MUST, I'd suggest adding a sentence or two > explaining why not using SRTP is the right thing to do. From nobody Mon Apr 6 20:12:10 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61E11B2E21; Mon, 6 Apr 2015 20:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-sEPJUB_s4V; Mon, 6 Apr 2015 20:12:04 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332141AD289; Mon, 6 Apr 2015 20:12:03 -0700 (PDT) Received: by lagv1 with SMTP id v1so32506073lag.3; Mon, 06 Apr 2015 20:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8HZwPLQp7FUDLtJ0GKw+bbGVWA0bcMmrzWG75gOyYiU=; b=0A0khBH+pwt70cAO4TZKngNMEKPbCchgBcEqtvtrxnOLJERWfzdKyz/5VExW6R7XsQ gDp7j/zVbDY9a6+Nl4kVxzbDKenqL2anIDDemnnj40fc/m88TWxbXn1Bs1do0RyrmwDe hO9hP8sVn08loo0BAz3U4gjkDmuxlI583hTpWcFKNKRk68hgUqKKNmYLewhsKHDmM6Kd QVLjyb/Jc3LMJOaF9wtWJpy0b7RRDYlKAmrY6qKpq7eaK0ut6h8878wut0oh8Rrnplb+ a2pf08MTj4r+SzA28m8FEVpYhwzvLgutSv0rMMowApgSsJw06FK1+jx2iGEQwB3C/I8U rWxg== MIME-Version: 1.0 X-Received: by 10.152.23.99 with SMTP id l3mr16039187laf.61.1428376321689; Mon, 06 Apr 2015 20:12:01 -0700 (PDT) Received: by 10.152.129.3 with HTTP; Mon, 6 Apr 2015 20:12:01 -0700 (PDT) In-Reply-To: <86B9D67A-C5B8-4DDC-8BA5-5EB186A713BB@nostrum.com> References: <20150407023433.21936.12615.idtracker@ietfa.amsl.com> <86B9D67A-C5B8-4DDC-8BA5-5EB186A713BB@nostrum.com> Date: Mon, 6 Apr 2015 22:12:01 -0500 Message-ID: From: Spencer Dawkins at IETF To: Ben Campbell Content-Type: multipart/alternative; boundary=089e0158ab6c428e9c051319c702 Archived-At: Cc: draft-ietf-payload-rtp-opus@ietf.org, payload-chairs@ietf.org, draft-ietf-payload-rtp-opus.shepherd@ietf.org, payload@ietf.org, The IESG Subject: Re: [payload] Spencer Dawkins' No Objection on draft-ietf-payload-rtp-opus-08: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 03:12:06 -0000 --089e0158ab6c428e9c051319c702 Content-Type: text/plain; charset=UTF-8 Hi, Ben, On Mon, Apr 6, 2015 at 10:07 PM, Ben Campbell wrote: > (... and trying again. Sorry for the repeat;shepherd had too many "L"s) > > (Forwarding to additional recipients, due to the notify field issue > Spencer mentioned below (now fixed.) > > On 6 Apr 2015, at 21:34, Spencer Dawkins wrote: > > Spencer Dawkins has entered the following ballot position for >> draft-ietf-payload-rtp-opus-08: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Meta-comment - it looks like the notification field is pointing only to >> Ali. If that's intentional, rock on, but I've had some >> accidentally-minimal notification lists on drafts recently, and wanted to >> mention that. >> >> This draft seemed very clear to me, one not skilled in the art. Thank you >> for that. >> >> I have a few comments. If you have questions, please ask, but they're >> non-blocking (so do the right thing). >> >> >> ... deleted down to ... > >> In other news, I support Kathleen's Discuss on SHOULD SRTP, and if it >> becomes a SHOULD and not a MUST, I'd suggest adding a sentence or two >> explaining why not using SRTP is the right thing to do. >> > Your explanation in private e-mail makes perfect sense to me, and the responsible parties can safely ignore that part of my comment. Thanks! Spencer --089e0158ab6c428e9c051319c702 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Ben,

On Mon, Apr 6, 2015 at 10:07 PM, Ben Campbell <ben@nostrum.com> wrote:
(... and trying agai= n. Sorry for the repeat;shepherd had too many "L"s)

(Forwarding to additional recipients, due to the notify field issue Spencer= mentioned below (now fixed.)

On 6 Apr 2015, at 21:34, Spencer Dawkins wrote:

Spencer Dawkins has entered the following ballot position for
draft-ietf-payload-rtp-opus-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discu= ss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-payload-r= tp-opus/



-------------------------------------------------------------= ---------
COMMENT:
-------------------------------------------------------------= ---------

Meta-comment - it looks like the notification field is pointing only to
Ali. If that's intentional, rock on, but I've had some
accidentally-minimal notification lists on drafts recently, and wanted to mention that.

This draft seemed very clear to me, one not skilled in the art. Thank you for that.

I have a few comments. If you have questions, please ask, but they're non-blocking (so do the right thing).



... deleted d= own to ...
=C2=A0

In other news, I support Kathleen's Discuss on SHOULD SRTP, and if it becomes a SHOULD and not a MUST, I'd suggest adding a sentence or two explaining why not using SRTP is the right thing to do.

Your ex= planation in private e-mail makes perfect sense to me, and the responsible = parties can safely ignore that part of my comment.=C2=A0

Thanks!

Spencer
--089e0158ab6c428e9c051319c702-- From nobody Tue Apr 7 03:06:22 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E7E1A2130; Tue, 7 Apr 2015 03:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQDljscyCBmI; Tue, 7 Apr 2015 03:06:12 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325851A1F73; Tue, 7 Apr 2015 03:06:12 -0700 (PDT) Received: by widdi4 with SMTP id di4so11129918wid.0; Tue, 07 Apr 2015 03:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=qTHiJaAZfY6Tt3S/czRdFEnZoV4UleZNNH+zbhi9NSY=; b=RKNpXX6c85hGtuj2xH534QrKUUGJRdLaT7sWTjRZQnnYuIe32+T4qrZWPH3fWPElVk ylSWJOVq60adBFQwfQmQFRfEA1FiqGtKcrtw31WQU4gXJzKbmxBRV1BmnMHPIfqWh8i6 7twNMjHMKFEzkKFIagt3irIBg95CinTeC25B198dJ8VxRsHQxWNtwVonCtJIfZDyUhLv PRSpDPV6urLpE05ai/TZy0scjbxy/5SKy1mGNvn4CDyGXwRYwRT7FF80xwxGxmIGm/5y nMms+mEWz8HIYNKi/sBJdK97NoP7pvtOTWgMugk9pmzrJck7/AQ6BgU3D+3IjKvNQjIp xVow== X-Received: by 10.194.63.172 with SMTP id h12mr37623368wjs.48.1428401170907; Tue, 07 Apr 2015 03:06:10 -0700 (PDT) Received: from RoniE (bzq-79-180-57-80.red.bezeqint.net. [79.180.57.80]) by mx.google.com with ESMTPSA id o5sm10709647wia.0.2015.04.07.03.06.07 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Apr 2015 03:06:10 -0700 (PDT) From: "Roni Even" To: "'Colin Perkins'" , "'Robert Sparks'" References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> In-Reply-To: <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> Date: Tue, 7 Apr 2015 13:06:05 +0300 Message-ID: <035501d0711a$7856b0a0$690411e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLAzGR07a+fOctgPDsHC1O01O6N4gIDGikzAlk6SHYBNYQq+AJmia1wAkn1xecA0xb2jwI9Vg6LAfUZxTYBDf0c5AGkRBB0AbyniQgCQquMs5qw0GDQ Content-Language: en-us Archived-At: Cc: secdir@ietf.org, payload@ietf.org, jspittka@gmail.com, iesg@ietf.org, payload-chairs@tools.ietf.org, koenvos74@gmail.com, 'Derek Atkins' Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 10:06:16 -0000 > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Colin Perkins > Sent: 06 April, 2015 9:50 PM > To: Robert Sparks > Cc: secdir@ietf.org; payload@ietf.org; jspittka@gmail.com; iesg@ietf.org; > payload-chairs@tools.ietf.org; koenvos74@gmail.com; Derek Atkins > Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 > > On 6 Apr 2015, at 19:44, Robert Sparks wrote: > > inline (particularly for Derek) > > On 4/6/15 11:13 AM, Ben Campbell wrote: > >> On 6 Apr 2015, at 11:09, Derek Atkins wrote: > >> > >>> "Timothy B. Terriberry" writes: > >>> > >>>> Ben Campbell wrote: > >>>>>> So my suggestion would be something more to the effect of: > >>>>>> > >>>>>> "Opus does not provide any built-in confidentiality or integrity > >>>>>> protection. Protection requirements vary between RTP applications. > >>>>>> See RFC 7201 and RFC 7202 for a discussion. > >>>> > >>>> This seems like reasonable text to me. I agree with the rationale > >>>> that preceded it. As much as I want to see encryption everywhere, a > >>>> payload format is not the right place to mandate it. > >>> > >>> As was stated already in this thread, the expected follow up drafts > >>> for MTI security have not been written. > >>> > >>> I leave it up to the Security ADs who have the real power here, but > >>> I still prefer my original wording (including the SHOULD). > >>> > >>> I understand your reluctance because it's a codec, but it's the > >>> first codec to get through the process since the Perpass work, which > >>> basically says "everything should be encrypted." Since you cannot > >>> go back in time to modify the existing RFCs, you can augment them > >>> going forward by other additions. > >>> > >>> As for the concern about "different security requirements for > >>> different codecs", frankly I don't buy that argument. Either your > >>> RTP application supports security or it doesn't. Once it does, it > >>> should be able to negotiate that along side the codec negotitation. > >>> So I don't see the concern -- we're not mandating a specific > >>> security technology, just that you SHOULD use one. Well, that's > >>> true regardless of the codec, isn't it? > >>> > >>> Or are you really saying "We don't care about security. We just > >>> want to be able to use this codec in existing, insecure RTP > >>> applications without adding new securty measures"? > >> > >> I'm saying this is the wrong layer to solve the problem. > >> > >> We had some work planned to better specify this in general for RTP. I think > the right answer is finish that work. If we do that right, it should apply > regardless of codec. > >> > > That's exactly right. > > > > We've had this conversation several times before. The individual payload > documents are not the place to add the kind of guidance Derek is asking for. > They should be about how you put things in RTP, not how applications use (and > secure RTP), unless there's something unique about the payload that interacts > with the general mechanics for using and securing RTP. > > > > Stephen will remember that we've queued up work on a document that would > describe securing unicast RTP set up with SDP (capturing the outcome of the > rtpsec bof at IETF68). The last I heard on the subject Dan Wing was taking the > token to work on that document, but it's been awhile. That's where the effort > should focus - an individual payload document is not the right place. > > +1 > > As Robert, and others, say, RTP payload format documents are not the right > place to mandate security mechanisms. This is the point of RFC7202, which is > about how strong security can best be defined for classes of RTP applications. > This is not in conflict with the perpass work, since the goal of RFC7202 is to > show how to provide strong security. [Roni Even] What Colin says +1 > > -- > Colin Perkins > https://csperkins.org/ > > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Tue Apr 7 06:13:02 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72B01A8AE7; Mon, 6 Apr 2015 09:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.61 X-Spam-Level: X-Spam-Status: No, score=0.61 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbB4rCQMyTzf; Mon, 6 Apr 2015 09:09:34 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF501A8AE6; Mon, 6 Apr 2015 09:09:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 06E3BE2038; Mon, 6 Apr 2015 12:09:33 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 26889-04; Mon, 6 Apr 2015 12:09:27 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 78BE4E2036; Mon, 6 Apr 2015 12:09:27 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t36G9Qnk017843; Mon, 6 Apr 2015 12:09:26 -0400 From: Derek Atkins To: "Timothy B. Terriberry" References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> Date: Mon, 06 Apr 2015 12:09:26 -0400 In-Reply-To: <551EFB9C.4040504@xiph.org> (Timothy B. Terriberry's message of "Fri, 03 Apr 2015 13:44:12 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 06:13:00 -0700 Cc: "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" , Derek Atkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 16:09:38 -0000 "Timothy B. Terriberry" writes: > Ben Campbell wrote: >>> So my suggestion would be something more to the effect of: >>> >>> "Opus does not provide any built-in confidentiality or integrity >>> protection. Protection requirements vary between RTP applications. >>> See RFC 7201 and RFC 7202 for a discussion. > > This seems like reasonable text to me. I agree with the rationale that > preceded it. As much as I want to see encryption everywhere, a payload > format is not the right place to mandate it. As was stated already in this thread, the expected follow up drafts for MTI security have not been written. I leave it up to the Security ADs who have the real power here, but I still prefer my original wording (including the SHOULD). I understand your reluctance because it's a codec, but it's the first codec to get through the process since the Perpass work, which basically says "everything should be encrypted." Since you cannot go back in time to modify the existing RFCs, you can augment them going forward by other additions. As for the concern about "different security requirements for different codecs", frankly I don't buy that argument. Either your RTP application supports security or it doesn't. Once it does, it should be able to negotiate that along side the codec negotitation. So I don't see the concern -- we're not mandating a specific security technology, just that you SHOULD use one. Well, that's true regardless of the codec, isn't it? Or are you really saying "We don't care about security. We just want to be able to use this codec in existing, insecure RTP applications without adding new securty measures"? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Apr 7 08:59:51 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05001B3726; Tue, 7 Apr 2015 08:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zeo2XUPdpx7t; Tue, 7 Apr 2015 08:59:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6E831B3723; Tue, 7 Apr 2015 08:59:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 679AEBE64; Tue, 7 Apr 2015 16:59:39 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Il5B2vZx2p2; Tue, 7 Apr 2015 16:59:39 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 395E9BE57; Tue, 7 Apr 2015 16:59:39 +0100 (IST) Message-ID: <5523FEEB.60000@cs.tcd.ie> Date: Tue, 07 Apr 2015 16:59:39 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Robert Sparks , Ben Campbell , Derek Atkins References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> In-Reply-To: <5522D40E.8040402@nostrum.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 15:59:47 -0000 Hiya, Sorry for coming late to this thread (#include :-) On 06/04/15 19:44, Robert Sparks wrote: [...] >> >> I'm saying this is the wrong layer to solve the problem. >> >> We had some work planned to better specify this in general for RTP. I >> think the right answer is finish that work. If we do that right, it >> should apply regardless of codec. >> > That's exactly right. > > We've had this conversation several times before. The individual payload > documents are not the place to add the kind of guidance Derek is asking > for. They should be about how you put things in RTP, not how > applications use (and secure RTP), unless there's something unique about > the payload that interacts with the general mechanics for using and > securing RTP. Robert is correct. > Stephen will remember that we've queued up work on a document that would > describe securing unicast RTP set up with SDP (capturing the outcome of > the rtpsec bof at IETF68). The last I heard on the subject Dan Wing was > taking the token to work on that document, but it's been awhile. That's > where the effort should focus - an individual payload document is not > the right place. I do recall that now that you mention it. But if it's not actually going to happen, then maybe we should rethink the approach, even if that'd result in repeated text in payload format drafts. Who knows the status of that work? S. > > >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Tue Apr 7 09:04:58 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4B41B3760; Tue, 7 Apr 2015 09:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbD7gFMioqEL; Tue, 7 Apr 2015 09:04:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 758EE1B375B; Tue, 7 Apr 2015 09:04:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150407160451.19098.17210.idtracker@ietfa.amsl.com> Date: Tue, 07 Apr 2015 09:04:51 -0700 Archived-At: Cc: draft-ietf-payload-rtp-opus@ietf.org, draft-ietf-payload-rtp-opus.ad@ietf.org, payload-chairs@ietf.org, draft-ietf-payload-rtp-opus.shepherd@ietf.org, payload@ietf.org Subject: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-opus-08: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 16:04:57 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-payload-rtp-opus-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have one thing I'd like to discuss briefly... cbr=0 (aka vbr) as a default is a security concern since you're making the less secure option the default. Did the WG consider that issue when deciding to pick this default? Given current deployments would it still actually be feasible to switch the default to cbr? Or would it be possible to say that cbr is the default for encrypted traffic but vbr for cleartext? (Note: I don't plan on having a big fight about this if it's really too late and it'd not be possible to change what implementations do for the default. But even in that case, we might be able to usefully add some more/better guidance.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 3.1.2: s/_might_ occur/occurs/ the information leak does occur unquestionably, the only uncertainty is whether or not someone cares about that, whereas the current text implies that the leak might not be real. As written, the text is misleading, though not sufficiently to make this a DISCUSS. (I am assuming there is no result that shows that encrypted OPUS traffic is somehow not leaking information in the way other codecs do.) - 6.1, maxptime and ptime: I read this as saying that 3, 6, 9 etc are all valid values, but that e.g. 43 is not. Is that correct? In other words can I mix frames that contain different durations of audio into one RTP packet? (You may have told me earlier, but I've forgotten already, sorry:-) From nobody Tue Apr 7 09:08:45 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59281B378B; Tue, 7 Apr 2015 09:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4i4fR_aFOqPY; Tue, 7 Apr 2015 09:08:42 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A671B3774; Tue, 7 Apr 2015 09:08:25 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t37G83hm043734 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2015 11:08:14 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Stephen Farrell" Date: Tue, 07 Apr 2015 11:08:03 -0500 Message-ID: In-Reply-To: <5523FEEB.60000@cs.tcd.ie> References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <5523FEEB.60000@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" , Derek Atkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 16:08:44 -0000 On 7 Apr 2015, at 10:59, Stephen Farrell wrote: > Hiya, > > Sorry for coming late to this thread (#include :-) > > On 06/04/15 19:44, Robert Sparks wrote: > [...] >>> >>> I'm saying this is the wrong layer to solve the problem. >>> >>> We had some work planned to better specify this in general for RTP. >>> I >>> think the right answer is finish that work. If we do that right, it >>> should apply regardless of codec. >>> >> That's exactly right. >> >> We've had this conversation several times before. The individual >> payload >> documents are not the place to add the kind of guidance Derek is >> asking >> for. They should be about how you put things in RTP, not how >> applications use (and secure RTP), unless there's something unique >> about >> the payload that interacts with the general mechanics for using and >> securing RTP. > > Robert is correct. > >> Stephen will remember that we've queued up work on a document that >> would >> describe securing unicast RTP set up with SDP (capturing the outcome >> of >> the rtpsec bof at IETF68). The last I heard on the subject Dan Wing >> was >> taking the token to work on that document, but it's been awhile. >> That's >> where the effort should focus - an individual payload document is not >> the right place. > > I do recall that now that you mention it. But if it's not actually > going to happen, then maybe we should rethink the approach, even if > that'd result in repeated text in payload format drafts. > > Who knows the status of that work? I am trying to track that down. But I am working under the assumption it didn't go anywhere. But I'd rather try to revive that work than to take a piecemeal approach of adding it to payload drafts. That doesn't help with pre-existing payload formats, and I think asking RTP application designers to treat privacy requirements on a per-codec basis is untenable. I suspect the best we could expect out of that is for people to ignore us. If we can agree to leave this out of payload drafts, I will track down and try really hard to restart the RTP level effort. /Ben From nobody Tue Apr 7 09:12:38 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE2A1B3750; Tue, 7 Apr 2015 09:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiKBtt-ibzqo; Tue, 7 Apr 2015 09:12:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606E11A8A0B; Tue, 7 Apr 2015 09:12:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2A3A6BE64; Tue, 7 Apr 2015 17:12:30 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVWx5PNL7Ljv; Tue, 7 Apr 2015 17:12:30 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F2AE3BE51; Tue, 7 Apr 2015 17:12:29 +0100 (IST) Message-ID: <552401ED.6060106@cs.tcd.ie> Date: Tue, 07 Apr 2015 17:12:29 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ben Campbell References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <5523FEEB.60000@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" , Derek Atkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 16:12:32 -0000 Thanks Ben, On 07/04/15 17:08, Ben Campbell wrote: >> >> Who knows the status of that work? > > I am trying to track that down. But I am working under the assumption it > didn't go anywhere. > > But I'd rather try to revive that work than to take a piecemeal approach > of adding it to payload drafts. That doesn't help with pre-existing > payload formats, and I think asking RTP application designers to treat > privacy requirements on a per-codec basis is untenable. I suspect the > best we could expect out of that is for people to ignore us. > > If we can agree to leave this out of payload drafts, I will track down > and try really hard to restart the RTP level effort. Yes, that'd definitely be the best approach. I do get how it's not so easy to motivate someone to get it done though, but maybe another push at it will work. I'm happy to help as I can as well too. Cheers, S. From nobody Tue Apr 7 09:16:08 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773021B379A; Tue, 7 Apr 2015 09:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiHV9xBbj0lc; Tue, 7 Apr 2015 09:16:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8151B3791; Tue, 7 Apr 2015 09:16:01 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 95CA5216065D1; Tue, 7 Apr 2015 16:15:56 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t37GFuSI010407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Apr 2015 18:15:56 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.230]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 7 Apr 2015 18:15:56 +0200 From: "DRAGE, Keith (Keith)" To: Derek Atkins , "Timothy B. Terriberry" Thread-Topic: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 Thread-Index: AQHQcIQN7a+fOctgPDsHC1O01O6N4p1BtiGg Date: Tue, 7 Apr 2015 16:15:55 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A124E8A@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "secdir@ietf.org" , "payload@ietf.org" , "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 16:16:06 -0000 You seem to be arguing that there are no security requirements specific for= this codec. I would suggest that the consequence of that is that we do not need RFC 211= 9 language in this document, and that Ben's language is actually more appro= priate. RFC 2119 language should only be used in this area if there is a sp= ecific requirement for the codec. If someone wants to introduce a SHOULD level strength requirement as a resu= lt on the perpass discussion, then that should be a separate generic docume= nt that updates the document that defines the concept of payload type defin= itions in the first place (is that currently RFC 4855?). RFC 7202 is only an informative document and does not contain any requireme= nts in this respect, merely giving guidance. So if someone wants a normative statement in this respect, assuming one can= be written that is actually specific enough to test, then a new document i= s required, probably from AVTCORE. Keith > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of=20 > Derek Atkins > Sent: 06 April 2015 17:09 > To: Timothy B. Terriberry > Cc: secdir@ietf.org; payload@ietf.org; jspittka@gmail.com;=20 > iesg@ietf.org; payload-chairs@tools.ietf.org;=20 > koenvos74@gmail.com; Derek Atkins > Subject: Re: [payload] [secdir] sec-dir review of=20 > draft-ietf-payload-rtp-opus-08 >=20 > "Timothy B. Terriberry" writes: >=20 > > Ben Campbell wrote: > >>> So my suggestion would be something more to the effect of: > >>> > >>> "Opus does not provide any built-in confidentiality or integrity=20 > >>> protection. Protection requirements vary between RTP applications. > >>> See RFC 7201 and RFC 7202 for a discussion. > > > > This seems like reasonable text to me. I agree with the=20 > rationale that=20 > > preceded it. As much as I want to see encryption=20 > everywhere, a payload=20 > > format is not the right place to mandate it. >=20 > As was stated already in this thread, the expected follow up=20 > drafts for MTI security have not been written. >=20 > I leave it up to the Security ADs who have the real power=20 > here, but I still prefer my original wording (including the SHOULD). >=20 > I understand your reluctance because it's a codec, but it's=20 > the first codec to get through the process since the Perpass=20 > work, which basically says "everything should be encrypted." =20 > Since you cannot go back in time to modify the existing RFCs,=20 > you can augment them going forward by other additions. >=20 > As for the concern about "different security requirements for=20 > different codecs", frankly I don't buy that argument. Either=20 > your RTP application supports security or it doesn't. Once=20 > it does, it should be able to negotiate that along side the=20 > codec negotitation. So I don't see the concern -- we're not=20 > mandating a specific security technology, just that you=20 > SHOULD use one. Well, that's true regardless of the codec, isn't it? >=20 > Or are you really saying "We don't care about security. We=20 > just want to be able to use this codec in existing, insecure=20 > RTP applications without adding new securty measures"? >=20 > -derek > --=20 > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > = From nobody Tue Apr 7 11:01:12 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F281B3968; Tue, 7 Apr 2015 11:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zl50hlDQAUFQ; Tue, 7 Apr 2015 11:01:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AB91B395F; Tue, 7 Apr 2015 11:01:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150407180105.13228.22557.idtracker@ietfa.amsl.com> Date: Tue, 07 Apr 2015 11:01:05 -0700 Archived-At: Cc: draft-ietf-payload-rtp-opus@ietf.org, draft-ietf-payload-rtp-opus.ad@ietf.org, payload-chairs@ietf.org, draft-ietf-payload-rtp-opus.shepherd@ietf.org, payload@ietf.org Subject: [payload] Barry Leiba's Yes on draft-ietf-payload-rtp-opus-08: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 18:01:11 -0000 Barry Leiba has entered the following ballot position for draft-ietf-payload-rtp-opus-08: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Very clear document; well written. The Abstract and Introduction both understate what this document is. It doesn't just define the payload format and registrations, but also provides what I would consider an Applicability Statement in Section 3: normative, Standards Track advice about how to use the Opus codec, complete with MUST and SHOULD and SHOULD NOT. That's fine, but both the Abstract and Introduction should say that. -- Section 4.1 -- Opus supports 5 different audio bandwidths, which can be adjusted during a call. Wouldn't "during a stream", or "during active streaming", or perhaps "during an RTP session", or some such be better than referring to "a call"? -- Section 5 -- It is RECOMMENDED that senders of Opus encoded data apply congestion control. Does this SHOULD come with any reference to how to do congestion control? The previous paragraph has some vague statements about doing congestion control, but is there anything more concrete that I could refer to if I were implementing this? -- Section 6.1 -- I see that the document shepherd asked for a media-types review in December, and that there were no comments. Thanks for making sure that got done, Ali. From nobody Tue Apr 7 13:06:58 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A272C1B3BD2 for ; Tue, 7 Apr 2015 13:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYFgGiiySd5b for ; Tue, 7 Apr 2015 13:06:49 -0700 (PDT) Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F0731B3BCF for ; Tue, 7 Apr 2015 13:06:42 -0700 (PDT) Received: by qkhg7 with SMTP id g7so59749537qkh.2 for ; Tue, 07 Apr 2015 13:06:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=moJgF8WQ4/eODqBHctMRgE+PYqflgop3JDTHc0EnlYk=; b=BMfpa5VKpuJRzVUU/UWDm17nhldoM6JOcl73mB/TWTddqy7bXMZpVpew9gOYh7WBbY /bsaZ2A2LKgt/28zujSx+SJMDqiakdlyhSwb0LXS9d0nY91hXJYT7D1/Ip8uDLUw+U8G p9I2SWqovtCICOBtWKRqES+9rTqPjVe8tZZwyIlOCj/NuT7YTkIAE2l04aRZQ06Y4QSh ffiRgyT3ltVsGFkQDWMf2k2ZDPCbBlo0nP/PY2YHwwtkUwenjONQ1g/WmReQKHkRpDWK geTe9T6aTFMU+X61RPnhJ1TqE7iGAfQBkEToxxSLDVJA6vR4rkWCFOQf7ofq0Bh2n1k0 rzfA== X-Gm-Message-State: ALoCoQmfWEXkKnnSVwOKOw6uaV8E7d63aMDQwklZeC55y3E2oW76Vqt5RpSgZN3PXJY/BMQtaxiP X-Received: by 10.55.55.75 with SMTP id e72mr42434928qka.30.1428437201273; Tue, 07 Apr 2015 13:06:41 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by mx.google.com with ESMTPSA id 132sm6052798qhf.17.2015.04.07.13.06.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2015 13:06:40 -0700 (PDT) Message-ID: <552438CE.90807@mozilla.com> Date: Tue, 07 Apr 2015 16:06:38 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150407160451.19098.17210.idtracker@ietfa.amsl.com> In-Reply-To: <20150407160451.19098.17210.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-payload-rtp-opus.shepherd@ietf.org, payload@ietf.org, payload-chairs@ietf.org, draft-ietf-payload-rtp-opus.ad@ietf.org, draft-ietf-payload-rtp-opus@ietf.org Subject: Re: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-opus-08: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 20:06:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Thanks for the review. See comments below. On 07/04/15 12:04 PM, Stephen Farrell wrote: > I have one thing I'd like to discuss briefly... > > cbr=0 (aka vbr) as a default is a security concern since you're > making the less secure option the default. Did the WG consider that > issue when deciding to pick this default? Given current deployments > would it still actually be feasible to switch the default to cbr? > Or would it be possible to say that cbr is the default for > encrypted traffic but vbr for cleartext? (Note: I don't plan on > having a big fight about this if it's really too late and it'd not > be possible to change what implementations do for the default. But > even in that case, we might be able to usefully add some > more/better guidance.) The cbr= parameter is only a receiver-side preference. The sender can always send CBR even if the receiver indicates it is okay with receiving VBR. We need to be aware that in very specific circumstances VBR may be used to recover information about the audio, but in the vast majority of cases, there is no such issue. It is certainly no worse than other information we already give out (VBR video, unencrypted headers, ...). As already noted in the draft, RFC6562 already discusses the few cases where CBR would be more appropriate. In all of these cases, it is the sender that knows there is an issue, so it really doesn't matter at all what the receiver uses for cbr=. In general, considering that Opus is more efficient at VBR than CBR, I believe receivers should be willing to receive it by default, unless they have a reason to require the sender to send CBR. > - 3.1.2: s/_might_ occur/occurs/ the information leak does occur > unquestionably, the only uncertainty is whether or not someone > cares about that, whereas the current text implies that the leak > might not be real. As written, the text is misleading, though not > sufficiently to make this a DISCUSS. (I am assuming there is no > result that shows that encrypted OPUS traffic is somehow not > leaking information in the way other codecs do.) As far as I'm aware of, the only codec for which information leak from VBR has ever been measured is Speex (anyone knows of another one?). As an author on both Speex and Opus, I can at least say that the way the two do VBR is completely different. Enough so that beyond the very basic fact that rate changes have entropy, I don't think we can really use Speex to draw conclusions about Opus. Of course, this is not to say we should ignore the matter. > - 6.1, maxptime and ptime: I read this as saying that 3, 6, 9 etc > are all valid values, but that e.g. 43 is not. Is that correct? In > other words can I mix frames that contain different durations of > audio into one RTP packet? (You may have told me earlier, but I've > forgotten already, sorry:-) Well, technically 43 is a valid ptime (despite being a dumb thing to do) if you put 17 frames of 2.5 ms in a packet. OTOH, 6 and 9 and not valid, since two and three 2.5 ms frames would have ptimes of 5 and 8, respectively. Note that Opus does not allow mixing frame sizes in the same packet, so 43 cannot be achieved by 40+2.5 and only by 17*2.5. Cheers, Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVJDjIAAoJEJ6/8sItn9q9kEoH/1ymMEIyW/5nphXHk9/cXqwy jP022FPDBKAQuO/bbNU6hv95crNW7fjrQrrqnNVE61o/7DHbDDacuco7CFARSJaL FAAHeWjb2lR6Rkv2ngHHdXJxjMAguXL+vrK1a0EIAGXq+Md9Jp5XBFv0RfHkjwuA K/7G1m9NoiOL9vWGHQNnwOp7nM7C0l87Go3K0SxZ2+MLLyT59fwJ9Zm1O9IkQImM ejj2HU2rGY+bjqW+QfgtOkU72Y+WWSPWzMUKNFwjm75EJMPUlrlR89zKXrq7Y1FX 7MR2FIAMzkYQIMzUjj/GltBCeZkioG11J/w2K8VByTW7XiuOI0PBQLOc8SrA4QA= =zA6q -----END PGP SIGNATURE----- From nobody Tue Apr 7 13:12:21 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4601B3B8F; Tue, 7 Apr 2015 13:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZZSmuQbJfhE; Tue, 7 Apr 2015 13:12:14 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37AD81B3B68; Tue, 7 Apr 2015 13:12:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1AF99BE9F; Tue, 7 Apr 2015 21:12:12 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGjIhip_zjoz; Tue, 7 Apr 2015 21:12:11 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EA3ABBE64; Tue, 7 Apr 2015 21:12:10 +0100 (IST) Message-ID: <55243A09.1080004@cs.tcd.ie> Date: Tue, 07 Apr 2015 21:11:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jean-Marc Valin , The IESG References: <20150407160451.19098.17210.idtracker@ietfa.amsl.com> <552438CE.90807@mozilla.com> In-Reply-To: <552438CE.90807@mozilla.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ueNqi3tjM2qrnGirGHbe4MM9sTbUIRMxW" Archived-At: Cc: draft-ietf-payload-rtp-opus.ad@ietf.org, payload-chairs@ietf.org, payload@ietf.org, draft-ietf-payload-rtp-opus.shepherd@ietf.org, draft-ietf-payload-rtp-opus@ietf.org Subject: Re: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-opus-08: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 20:12:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ueNqi3tjM2qrnGirGHbe4MM9sTbUIRMxW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/04/15 21:06, Jean-Marc Valin wrote: > The cbr=3D parameter is only a receiver-side preference Ah sorry, thanks - I figure that makes this into a non-blocking comment. I'll reply fully to your mail and fix that later. Cheers, S. --ueNqi3tjM2qrnGirGHbe4MM9sTbUIRMxW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJVJDoaAAoJEC88hzaAX42igAwH/Ai9d6WLM+CuQqmWiQpKzS21 vIUdzLagw+uJRv9jgh74IhxA412iPzlfmPZ2mCWEDOpQ3QdM+r6J6wnuUmqoJRPn LraICcRGgidvknfZKJhf2HnEQU3+5COkt30sSs+Yvd8l+qS+S4tHLjPDK0tLZ9bm WyipJ1mM8uZccuLXintFgYp5D1WkH6vtJLj4DwSbk+KCrQR6NsY9Hb2cjDX/MYA0 8lw0wTVjn+Zbdb+BcQPsT9S6DGrfPpuWNQZZ5gLrrFo65Ou7IDADyrBCS3G3L1FG B11r9z7y4h1Ihr9XQ1UAaK5wxmgYm3kv99vSCrv5NrAUqZskuwSGbgQQU67G4QE= =9h1W -----END PGP SIGNATURE----- --ueNqi3tjM2qrnGirGHbe4MM9sTbUIRMxW-- From nobody Tue Apr 7 13:53:26 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025F11B3512 for ; Tue, 7 Apr 2015 04:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zF6xGELOaCKe for ; Tue, 7 Apr 2015 04:55:35 -0700 (PDT) Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com [209.85.220.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609C41B3509 for ; Tue, 7 Apr 2015 04:55:30 -0700 (PDT) Received: by qkx62 with SMTP id 62so48927207qkx.0 for ; Tue, 07 Apr 2015 04:55:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Oa9R1HU46bAKGQGYs0DPLBjAB3FRhRrghU/BNi1fSlw=; b=dBfW4HXoH6mZM9F1vtLzuW4bPfF38E0JsWnr6Qi1kS1aXWyN5+vA12+Jibj2Voc/pt nJKTIfjz3vWqljNkHEjtsvTlwDS08LOUZB955rI1hC7lsQVjAbRC5bkddxUbDn0losAZ EQPZPL3tTnxQmdnPqKY4rr7vG+QClU8AGCDalD0LLggp2m+ixfQEa7Dd/JchWtyrkdU2 8ws6oJjLaGA2VZxnjdSW76pNwQWLjMUBpNGPwEPOA3etv6nHQm5XQPg2jeo7ulm50lgI blf+JOk1L4nqrlm5RIMykzYn/X6tGv3rDqeGhIjdwR9uQm2Qsoxs4j6wkS48poFM2vUA GnOg== X-Gm-Message-State: ALoCoQl9Xgb8LbTTmdyMe1icAO3BLLGn65pOK/HdCwS5l7YtiIJH+ImS1CoTMgB8fYUdKqCqJHVK X-Received: by 10.55.52.129 with SMTP id b123mr37517922qka.94.1428407729547; Tue, 07 Apr 2015 04:55:29 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by mx.google.com with ESMTPSA id e110sm5263271qga.13.2015.04.07.04.55.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2015 04:55:28 -0700 (PDT) Message-ID: <5523C5AE.7040108@mozilla.com> Date: Tue, 07 Apr 2015 07:55:26 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Roni Even , 'Colin Perkins' , 'Robert Sparks' References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> In-Reply-To: <035501d0711a$7856b0a0$690411e0$@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 13:53:21 -0700 Cc: secdir@ietf.org, payload@ietf.org, jspittka@gmail.com, iesg@ietf.org, payload-chairs@tools.ietf.org, koenvos74@gmail.com, 'Derek Atkins' Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 11:55:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does anyone object to this earlier proposal? "Opus does not provide any built-in confidentiality or integrity protection. Protection requirements vary between RTP applications. See RFC 7201 and RFC 7202 for a discussion." If not, that's probably what should go in the RFC (assuming it works for Kathleen Moriarty's DISCUSS too). Jean-Marc On 07/04/15 06:06 AM, Roni Even wrote: > > >> -----Original Message----- From: payload >> [mailto:payload-bounces@ietf.org] On Behalf Of Colin Perkins >> Sent: 06 April, 2015 9:50 PM To: Robert Sparks Cc: >> secdir@ietf.org; payload@ietf.org; jspittka@gmail.com; >> iesg@ietf.org; payload-chairs@tools.ietf.org; >> koenvos74@gmail.com; Derek Atkins Subject: Re: [payload] [secdir] >> sec-dir review of > draft-ietf-payload-rtp-opus-08 >> >> On 6 Apr 2015, at 19:44, Robert Sparks >> wrote: >>> inline (particularly for Derek) On 4/6/15 11:13 AM, Ben >>> Campbell wrote: >>>> On 6 Apr 2015, at 11:09, Derek Atkins wrote: >>>> >>>>> "Timothy B. Terriberry" writes: >>>>> >>>>>> Ben Campbell wrote: >>>>>>>> So my suggestion would be something more to the >>>>>>>> effect of: >>>>>>>> >>>>>>>> "Opus does not provide any built-in confidentiality >>>>>>>> or integrity protection. Protection requirements vary >>>>>>>> between RTP applications. See RFC 7201 and RFC 7202 >>>>>>>> for a discussion. >>>>>> >>>>>> This seems like reasonable text to me. I agree with the >>>>>> rationale that preceded it. As much as I want to see >>>>>> encryption everywhere, a payload format is not the right >>>>>> place to mandate it. >>>>> >>>>> As was stated already in this thread, the expected follow >>>>> up drafts for MTI security have not been written. >>>>> >>>>> I leave it up to the Security ADs who have the real power >>>>> here, but I still prefer my original wording (including the >>>>> SHOULD). >>>>> >>>>> I understand your reluctance because it's a codec, but it's >>>>> the first codec to get through the process since the >>>>> Perpass work, which basically says "everything should be >>>>> encrypted." Since you cannot go back in time to modify the >>>>> existing RFCs, you can augment them going forward by other >>>>> additions. >>>>> >>>>> As for the concern about "different security requirements >>>>> for different codecs", frankly I don't buy that argument. >>>>> Either your RTP application supports security or it >>>>> doesn't. Once it does, it should be able to negotiate that >>>>> along side the codec negotitation. So I don't see the >>>>> concern -- we're not mandating a specific security >>>>> technology, just that you SHOULD use one. Well, that's >>>>> true regardless of the codec, isn't it? >>>>> >>>>> Or are you really saying "We don't care about security. We >>>>> just want to be able to use this codec in existing, >>>>> insecure RTP applications without adding new securty >>>>> measures"? >>>> >>>> I'm saying this is the wrong layer to solve the problem. >>>> >>>> We had some work planned to better specify this in general >>>> for RTP. I > think >> the right answer is finish that work. If we do that right, it >> should apply regardless of codec. >>>> >>> That's exactly right. >>> >>> We've had this conversation several times before. The >>> individual payload >> documents are not the place to add the kind of guidance Derek is >> asking > for. >> They should be about how you put things in RTP, not how >> applications use > (and >> secure RTP), unless there's something unique about the payload >> that > interacts >> with the general mechanics for using and securing RTP. >>> >>> Stephen will remember that we've queued up work on a document >>> that would >> describe securing unicast RTP set up with SDP (capturing the >> outcome of > the >> rtpsec bof at IETF68). The last I heard on the subject Dan Wing >> was taking > the >> token to work on that document, but it's been awhile. That's >> where the > effort >> should focus - an individual payload document is not the right >> place. >> >> +1 >> >> As Robert, and others, say, RTP payload format documents are not >> the right place to mandate security mechanisms. This is the point >> of RFC7202, which > is >> about how strong security can best be defined for classes of RTP > applications. >> This is not in conflict with the perpass work, since the goal of >> RFC7202 > is to >> show how to provide strong security. > [Roni Even] What Colin says +1 > >> >> -- Colin Perkins https://csperkins.org/ >> >> >> >> >> _______________________________________________ payload mailing >> list payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload > > _______________________________________________ payload mailing > list payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVI8WrAAoJEJ6/8sItn9q9czQH/jWr/wOYnF/Np5pyGT/VVLQ4 CtfYkhfI3FlwZzz0xldUW7pkiiXMXAV99pQHVV85JQ+yBjpYS+TgScoLmlXKftqt Et41PYxD4MTA/HMqR+ayIXEwu0xLKGKZiCzeI3/4eyJq2yrMa/LoYv0E+2d9+Eow isDpaXfayJ8OmpAEml52ErJm3bRdvuEioIarVgFqgA+jBg8F01jU34PHcw18ppnK c93yERmrCK8wDizGYnICrRpdnLojKZ3aR+xfdFGW3JA5XbkGyR3uJc6ACM7r2ap1 UjkYSYviOjSVk2vRnNzqi1pcnTpTjuWxE+GQTJ9o+rr1M3zESWBvYoLVyaenAQg= =iesF -----END PGP SIGNATURE----- From nobody Tue Apr 7 13:53:27 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9360C1B3578; Tue, 7 Apr 2015 06:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evARzNh8jESj; Tue, 7 Apr 2015 06:34:05 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E68C41B35BB; Tue, 7 Apr 2015 06:33:25 -0700 (PDT) Received: by wiax7 with SMTP id x7so10911551wia.0; Tue, 07 Apr 2015 06:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=Z4NhQLbpjxCoAdHBWJh98hY3TrZjEUyyODi/z0woSE4=; b=T96IekD+u3djS5Lwa8hDydAR5sjf4GuWQpZYnVUzFldpwsXrYGQjTSpfzCTIpliZJZ 1GeXm6Swff6i9YYDHPWcjaBac8ufTZp/6UbVTkupdYg2xkF0EVmZoficVg8mhX9e9jza gPLXJeOWPz0C4IK2K3dnOg9c1kNhDJvJhIoSS1XDPJhuR8T+Mk2OvUYVW2DO2W6kTp1G 0dHobI2F5vkj0260hHpZcQWQl0s2JrjAcdatTG5I+pXmiyY2oU7vS/RlrHggrv20rr+e +2FsQrj4QdQzlOWuQiyIAddCHvkgNNlUhwYpwwPZ+0eIRNAmO60r/1M3yfbO05pSbwyD CLpw== X-Received: by 10.194.110.38 with SMTP id hx6mr39248516wjb.128.1428413604710; Tue, 07 Apr 2015 06:33:24 -0700 (PDT) Received: from RoniE (bzq-79-180-57-80.red.bezeqint.net. [79.180.57.80]) by mx.google.com with ESMTPSA id kr5sm11017404wjc.1.2015.04.07.06.33.21 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Apr 2015 06:33:23 -0700 (PDT) From: "Roni Even" To: "'Jean-Marc Valin'" , "'Colin Perkins'" , "'Robert Sparks'" References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> In-Reply-To: <5523C5AE.7040108@mozilla.com> Date: Tue, 7 Apr 2015 16:33:18 +0300 Message-ID: <036a01d07137$6b6add90$424098b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLAzGR07a+fOctgPDsHC1O01O6N4gIDGikzAlk6SHYBNYQq+AJmia1wAkn1xecA0xb2jwI9Vg6LAfUZxTYBDf0c5AGkRBB0AbyniQgCQquMswFRQeCNAchdTqCamD0VsA== Content-Language: en-us Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 13:53:21 -0700 Cc: secdir@ietf.org, payload@ietf.org, jspittka@gmail.com, iesg@ietf.org, payload-chairs@tools.ietf.org, koenvos74@gmail.com, 'Derek Atkins' Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 13:34:09 -0000 Hi Jean-Marc, I think this sounds good, I suggest also to mention RFC6562 Roni > -----Original Message----- > From: Jean-Marc Valin [mailto:jmvalin@mozilla.com] > Sent: 07 April, 2015 2:55 PM > To: Roni Even; 'Colin Perkins'; 'Robert Sparks' > Cc: secdir@ietf.org; payload@ietf.org; jspittka@gmail.com; iesg@ietf.org; > payload-chairs@tools.ietf.org; koenvos74@gmail.com; 'Derek Atkins' > Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Does anyone object to this earlier proposal? > > "Opus does not provide any built-in confidentiality or integrity protection. > Protection requirements vary between RTP applications. See RFC 7201 and RFC > 7202 for a discussion." > > If not, that's probably what should go in the RFC (assuming it works for > Kathleen Moriarty's DISCUSS too). > > Jean-Marc > > On 07/04/15 06:06 AM, Roni Even wrote: > > > > > >> -----Original Message----- From: payload > >> [mailto:payload-bounces@ietf.org] On Behalf Of Colin Perkins > >> Sent: 06 April, 2015 9:50 PM To: Robert Sparks Cc: > >> secdir@ietf.org; payload@ietf.org; jspittka@gmail.com; iesg@ietf.org; > >> payload-chairs@tools.ietf.org; koenvos74@gmail.com; Derek Atkins > >> Subject: Re: [payload] [secdir] sec-dir review of > > draft-ietf-payload-rtp-opus-08 > >> > >> On 6 Apr 2015, at 19:44, Robert Sparks > >> wrote: > >>> inline (particularly for Derek) On 4/6/15 11:13 AM, Ben Campbell > >>> wrote: > >>>> On 6 Apr 2015, at 11:09, Derek Atkins wrote: > >>>> > >>>>> "Timothy B. Terriberry" writes: > >>>>> > >>>>>> Ben Campbell wrote: > >>>>>>>> So my suggestion would be something more to the effect of: > >>>>>>>> > >>>>>>>> "Opus does not provide any built-in confidentiality or > >>>>>>>> integrity protection. Protection requirements vary between RTP > >>>>>>>> applications. See RFC 7201 and RFC 7202 for a discussion. > >>>>>> > >>>>>> This seems like reasonable text to me. I agree with the rationale > >>>>>> that preceded it. As much as I want to see encryption everywhere, > >>>>>> a payload format is not the right place to mandate it. > >>>>> > >>>>> As was stated already in this thread, the expected follow up > >>>>> drafts for MTI security have not been written. > >>>>> > >>>>> I leave it up to the Security ADs who have the real power here, > >>>>> but I still prefer my original wording (including the SHOULD). > >>>>> > >>>>> I understand your reluctance because it's a codec, but it's the > >>>>> first codec to get through the process since the Perpass work, > >>>>> which basically says "everything should be encrypted." Since you > >>>>> cannot go back in time to modify the existing RFCs, you can > >>>>> augment them going forward by other additions. > >>>>> > >>>>> As for the concern about "different security requirements for > >>>>> different codecs", frankly I don't buy that argument. > >>>>> Either your RTP application supports security or it doesn't. Once > >>>>> it does, it should be able to negotiate that along side the codec > >>>>> negotitation. So I don't see the concern -- we're not mandating a > >>>>> specific security technology, just that you SHOULD use one. Well, > >>>>> that's true regardless of the codec, isn't it? > >>>>> > >>>>> Or are you really saying "We don't care about security. We just > >>>>> want to be able to use this codec in existing, insecure RTP > >>>>> applications without adding new securty measures"? > >>>> > >>>> I'm saying this is the wrong layer to solve the problem. > >>>> > >>>> We had some work planned to better specify this in general for RTP. > >>>> I > > think > >> the right answer is finish that work. If we do that right, it should > >> apply regardless of codec. > >>>> > >>> That's exactly right. > >>> > >>> We've had this conversation several times before. The individual > >>> payload > >> documents are not the place to add the kind of guidance Derek is > >> asking > > for. > >> They should be about how you put things in RTP, not how applications > >> use > > (and > >> secure RTP), unless there's something unique about the payload that > > interacts > >> with the general mechanics for using and securing RTP. > >>> > >>> Stephen will remember that we've queued up work on a document that > >>> would > >> describe securing unicast RTP set up with SDP (capturing the outcome > >> of > > the > >> rtpsec bof at IETF68). The last I heard on the subject Dan Wing was > >> taking > > the > >> token to work on that document, but it's been awhile. That's where > >> the > > effort > >> should focus - an individual payload document is not the right place. > >> > >> +1 > >> > >> As Robert, and others, say, RTP payload format documents are not the > >> right place to mandate security mechanisms. This is the point of > >> RFC7202, which > > is > >> about how strong security can best be defined for classes of RTP > > applications. > >> This is not in conflict with the perpass work, since the goal of > >> RFC7202 > > is to > >> show how to provide strong security. > > [Roni Even] What Colin says +1 > > > >> > >> -- Colin Perkins https://csperkins.org/ > >> > >> > >> > >> > >> _______________________________________________ payload mailing > list > >> payload@ietf.org https://www.ietf.org/mailman/listinfo/payload > > > > _______________________________________________ payload mailing list > > payload@ietf.org https://www.ietf.org/mailman/listinfo/payload > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJVI8WrAAoJEJ6/8sItn9q9czQH/jWr/wOYnF/Np5pyGT/VVLQ4 > CtfYkhfI3FlwZzz0xldUW7pkiiXMXAV99pQHVV85JQ+yBjpYS+TgScoLmlXKftqt > Et41PYxD4MTA/HMqR+ayIXEwu0xLKGKZiCzeI3/4eyJq2yrMa/LoYv0E+2d9+Eow > isDpaXfayJ8OmpAEml52ErJm3bRdvuEioIarVgFqgA+jBg8F01jU34PHcw18ppnK > c93yERmrCK8wDizGYnICrRpdnLojKZ3aR+xfdFGW3JA5XbkGyR3uJc6ACM7r2ap1 > UjkYSYviOjSVk2vRnNzqi1pcnTpTjuWxE+GQTJ9o+rr1M3zESWBvYoLVyaenAQg= > =iesF > -----END PGP SIGNATURE----- From nobody Tue Apr 7 13:53:29 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D8F1B3659; Tue, 7 Apr 2015 07:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsoFJvbBxyGf; Tue, 7 Apr 2015 07:43:25 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C771B3660; Tue, 7 Apr 2015 07:43:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id A67E5E2038; Tue, 7 Apr 2015 10:43:03 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 02205-04; Tue, 7 Apr 2015 10:43:02 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id AC2EBE2036; Tue, 7 Apr 2015 10:43:01 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t37EgxLG007527; Tue, 7 Apr 2015 10:42:59 -0400 From: Derek Atkins To: Jean-Marc Valin References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> Date: Tue, 07 Apr 2015 10:42:59 -0400 In-Reply-To: <5523C5AE.7040108@mozilla.com> (Jean-Marc Valin's message of "Tue, 07 Apr 2015 07:55:26 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 13:53:21 -0700 Cc: secdir@ietf.org, payload@ietf.org, jspittka@gmail.com, iesg@ietf.org, payload-chairs@tools.ietf.org, koenvos74@gmail.com, 'Derek Atkins' , 'Colin Perkins' Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 14:43:27 -0000 Hi, Jean-Marc Valin writes: > Does anyone object to this earlier proposal? > > "Opus does not provide any built-in confidentiality or integrity > protection. Protection requirements vary between RTP applications. See > RFC 7201 and RFC 7202 for a discussion." > > If not, that's probably what should go in the RFC (assuming it works > for Kathleen Moriarty's DISCUSS too). > > Jean-Marc It's not quite as strong a statement as I'd like to see, but if Kathleen is okay with it then I'm okay with it. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Apr 7 13:53:30 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54D41A8A50; Tue, 7 Apr 2015 09:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2e2ox7vLhcr4; Tue, 7 Apr 2015 09:23:53 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9621A8A51; Tue, 7 Apr 2015 09:23:53 -0700 (PDT) Received: from [130.209.247.112] (port=53060 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YfWI1-0003ca-C4; Tue, 07 Apr 2015 17:23:50 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <5523FEEB.60000@cs.tcd.ie> Date: Tue, 7 Apr 2015 17:23:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <5523FEEB.60000@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 13:53:21 -0700 Cc: "secdir@ietf.org" , payload@ietf.org, "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" , Derek Atkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 16:23:55 -0000 On 7 Apr 2015, at 16:59, Stephen Farrell = wrote: > Hiya, >=20 > Sorry for coming late to this thread (#include :-) >=20 > On 06/04/15 19:44, Robert Sparks wrote: > [...] >>>=20 >>> I'm saying this is the wrong layer to solve the problem. >>>=20 >>> We had some work planned to better specify this in general for RTP. = I >>> think the right answer is finish that work. If we do that right, it >>> should apply regardless of codec. >>>=20 >> That's exactly right. >>=20 >> We've had this conversation several times before. The individual = payload >> documents are not the place to add the kind of guidance Derek is = asking >> for. They should be about how you put things in RTP, not how >> applications use (and secure RTP), unless there's something unique = about >> the payload that interacts with the general mechanics for using and >> securing RTP. >=20 > Robert is correct. >=20 >> Stephen will remember that we've queued up work on a document that = would >> describe securing unicast RTP set up with SDP (capturing the outcome = of >> the rtpsec bof at IETF68). The last I heard on the subject Dan Wing = was >> taking the token to work on that document, but it's been awhile. = That's >> where the effort should focus - an individual payload document is not >> the right place. >=20 > I do recall that now that you mention it. But if it's not actually > going to happen, then maybe we should rethink the approach, even if > that'd result in repeated text in payload format drafts. >=20 > Who knows the status of that work? I don't know the status of that work, but irrespective of that, payload = format documents are not the right place to mandate security for RTP.=20 An RTP payload format is a media type registration. RTP is a transport = protocol. Transport security should be defined for the transport, not = for the media type being transported, since there are different ways of = transporting the media that can have different security properties. This = is the argument of RFC 7202.=20 --=20 Colin Perkins https://csperkins.org/ From nobody Tue Apr 7 13:53:32 2015 Return-Path: X-Original-To: expand-draft-ietf-payload-rtp-opus.all@virtual.ietf.org Delivered-To: payload@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2A70C1A8A98; Tue, 7 Apr 2015 10:14:53 -0700 (PDT) X-Original-To: xfilter-draft-ietf-payload-rtp-opus.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-payload-rtp-opus.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE4E1A8A90 for ; Tue, 7 Apr 2015 10:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id di7bChrGYh-i for ; Tue, 7 Apr 2015 10:14:51 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43B5D1A8A86 for ; Tue, 7 Apr 2015 10:14:51 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t37HEedg049185 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Apr 2015 12:14:50 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: draft-ietf-payload-rtp-opus.all@ietf.org Date: Tue, 07 Apr 2015 12:14:39 -0500 Message-ID: <302B7326-56AC-4722-8499-D7A139684698@nostrum.com> References: <20150407160451.19098.17210.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 13:53:21 -0700 Subject: [payload] Fwd: Stephen Farrell's Discuss on draft-ietf-payload-rtp-opus-08: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 17:14:53 -0000 Authors: Any thoughts on Stephen's DISCUSS and comments (below)? Thanks! Ben. Forwarded message: > From: Stephen Farrell > To: The IESG > Cc: draft-ietf-payload-rtp-opus@ietf.org, > draft-ietf-payload-rtp-opus.ad@ietf.org, payload-chairs@ietf.org, > draft-ietf-payload-rtp-opus.shepherd@ietf.org, abegen@cisco.com, > payload@ietf.org > Subject: Stephen Farrell's Discuss on draft-ietf-payload-rtp-opus-08: > (with DISCUSS and COMMENT) > Date: Tue, 07 Apr 2015 09:04:51 -0700 > > Stephen Farrell has entered the following ballot position for > draft-ietf-payload-rtp-opus-08: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) > > > Please refer to > http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > I have one thing I'd like to discuss briefly... > > cbr=0 (aka vbr) as a default is a security concern since > you're making the less secure option the default. Did the WG > consider that issue when deciding to pick this default? > Given current deployments would it still actually be > feasible to switch the default to cbr? Or would it be > possible to say that cbr is the default for encrypted > traffic but vbr for cleartext? (Note: I don't plan on > having a big fight about this if it's really too late and > it'd not be possible to change what implementations do for > the default. But even in that case, we might be able to > usefully add some more/better guidance.) > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - 3.1.2: s/_might_ occur/occurs/ the information leak does > occur unquestionably, the only uncertainty is whether or not > someone cares about that, whereas the current text implies > that the leak might not be real. As written, the text is > misleading, though not sufficiently to make this a DISCUSS. > (I am assuming there is no result that shows that encrypted > OPUS traffic is somehow not leaking information in the way > other codecs do.) > > - 6.1, maxptime and ptime: I read this as saying that 3, 6, > 9 etc are all valid values, but that e.g. 43 is not. Is that > correct? In other words can I mix frames that contain > different durations of audio into one RTP packet? (You may > have told me earlier, but I've forgotten already, sorry:-) > > From nobody Tue Apr 7 13:53:33 2015 Return-Path: X-Original-To: expand-draft-ietf-payload-rtp-opus.all@virtual.ietf.org Delivered-To: payload@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 258981B38AA; Tue, 7 Apr 2015 10:27:34 -0700 (PDT) X-Original-To: xfilter-draft-ietf-payload-rtp-opus.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-payload-rtp-opus.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B2B1B38A8 for ; Tue, 7 Apr 2015 10:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JICrfOx8Tyjf for ; Tue, 7 Apr 2015 10:27:31 -0700 (PDT) Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20B31B38A5 for ; Tue, 7 Apr 2015 10:27:31 -0700 (PDT) Received: by qkgx75 with SMTP id x75so56184017qkg.1 for ; Tue, 07 Apr 2015 10:27:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jwjMVsML7ucCExVDUeLKWBk/UVbtPnWf64I/AU4L8bE=; b=eImAZnUUAO8VO7338kgFH/dMSBi2rl41itsw2BP3zldUago0b3vHVeT9Qvy6xBz1r0 4guqxFO++Me312IqUPSECmRoaCUXLAaIiM11HpabVMKMd4TZ0ruOqiYtmYuiZDbF/XjZ Nc+6Xt2QwUexeLH7xI/T4tVVQKSt512CU8WYI2bKcdlNP3YLY0staay5RmB6Xs6NZuzs FKFmCI7TSbdv1fcEHpMAkMMuRQ9zAw7mknnUY3EwqXAa8pccgUGEUCw3M4Ay98oD/RiN RboBZjZxK4VGyeHt5kWHlWwGlThy2JQyM9l3xdZ8qM8gc87DOhHpkiMOOvhY39hLC5Nc P8rg== X-Gm-Message-State: ALoCoQnOKtGqUJafLWT4r6APy3Hyak7TZncfg9Gv20VznR9tuMPxpj8IQhhX+uNBJFvmjukCEK9F X-Received: by 10.55.16.140 with SMTP id 12mr33574514qkq.39.1428427650876; Tue, 07 Apr 2015 10:27:30 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by mx.google.com with ESMTPSA id z77sm5744532qkg.44.2015.04.07.10.27.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2015 10:27:30 -0700 (PDT) Message-ID: <55241381.3070603@jmvalin.ca> Date: Tue, 07 Apr 2015 13:27:29 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ben Campbell , draft-ietf-payload-rtp-opus.all@ietf.org References: <20150407160451.19098.17210.idtracker@ietfa.amsl.com> <302B7326-56AC-4722-8499-D7A139684698@nostrum.com> In-Reply-To: <302B7326-56AC-4722-8499-D7A139684698@nostrum.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 13:53:21 -0700 Subject: Re: [payload] Fwd: Stephen Farrell's Discuss on draft-ietf-payload-rtp-opus-08: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 17:27:34 -0000 I don't think VBR is a significant security issue. We need to be aware that in very specific circumstances it may leak information, but in the general case it's quite fine, and certainly no worse than other information we give out (VBR video, unencrypted headers, ...). As already noted in the draft, RFC6562 already discusses the few cases where CBR would be more appropriate. Considering that Opus is more efficient at VBR, I believe it should be the default. It's also worth noting that even if VBR=1 is specified by the receiver, there's nothing that prevents the sender from switching to CBR at any point if needed. In general, where should we respond to the IESG comments? Cheers, Jean-Marc On 07/04/15 01:14 PM, Ben Campbell wrote: > Authors: Any thoughts on Stephen's DISCUSS and comments (below)? > > Thanks! > > Ben. > > Forwarded message: > >> From: Stephen Farrell >> To: The IESG >> Cc: draft-ietf-payload-rtp-opus@ietf.org, >> draft-ietf-payload-rtp-opus.ad@ietf.org, payload-chairs@ietf.org, >> draft-ietf-payload-rtp-opus.shepherd@ietf.org, abegen@cisco.com, >> payload@ietf.org >> Subject: Stephen Farrell's Discuss on draft-ietf-payload-rtp-opus-08: >> (with DISCUSS and COMMENT) >> Date: Tue, 07 Apr 2015 09:04:51 -0700 >> >> Stephen Farrell has entered the following ballot position for >> draft-ietf-payload-rtp-opus-08: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> I have one thing I'd like to discuss briefly... >> >> cbr=0 (aka vbr) as a default is a security concern since >> you're making the less secure option the default. Did the WG >> consider that issue when deciding to pick this default? >> Given current deployments would it still actually be >> feasible to switch the default to cbr? Or would it be >> possible to say that cbr is the default for encrypted >> traffic but vbr for cleartext? (Note: I don't plan on >> having a big fight about this if it's really too late and >> it'd not be possible to change what implementations do for >> the default. But even in that case, we might be able to >> usefully add some more/better guidance.) >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - 3.1.2: s/_might_ occur/occurs/ the information leak does >> occur unquestionably, the only uncertainty is whether or not >> someone cares about that, whereas the current text implies >> that the leak might not be real. As written, the text is >> misleading, though not sufficiently to make this a DISCUSS. >> (I am assuming there is no result that shows that encrypted >> OPUS traffic is somehow not leaking information in the way >> other codecs do.) >> >> - 6.1, maxptime and ptime: I read this as saying that 3, 6, >> 9 etc are all valid values, but that e.g. 43 is not. Is that >> correct? In other words can I mix frames that contain >> different durations of audio into one RTP packet? (You may >> have told me earlier, but I've forgotten already, sorry:-) >> >> From nobody Tue Apr 7 13:53:35 2015 Return-Path: X-Original-To: expand-draft-ietf-payload-rtp-opus.all@virtual.ietf.org Delivered-To: payload@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 4A2391B3966; Tue, 7 Apr 2015 11:04:09 -0700 (PDT) X-Original-To: xfilter-draft-ietf-payload-rtp-opus.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-payload-rtp-opus.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266D21A8A73 for ; Tue, 7 Apr 2015 11:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KniowXjYurNX for ; Tue, 7 Apr 2015 11:04:08 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E6471B395F for ; Tue, 7 Apr 2015 11:04:08 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t37I3u5I053351 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2015 13:04:07 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Jean-Marc Valin" Date: Tue, 07 Apr 2015 13:03:56 -0500 Message-ID: <39329665-E265-4D5F-B055-A98EB36C644A@nostrum.com> In-Reply-To: <55241381.3070603@jmvalin.ca> References: <20150407160451.19098.17210.idtracker@ietfa.amsl.com> <302B7326-56AC-4722-8499-D7A139684698@nostrum.com> <55241381.3070603@jmvalin.ca> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 13:53:21 -0700 Cc: draft-ietf-payload-rtp-opus.all@ietf.org Subject: Re: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-opus-08: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 18:04:09 -0000 On 7 Apr 2015, at 12:27, Jean-Marc Valin wrote: > In general, where should we respond to the IESG comments? Did you get the discuss directly? If so, you can reply-all to that. Please make sure the payload list gets copied. Thanks! Ben. From nobody Tue Apr 7 15:37:23 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFF61ACD92; Tue, 7 Apr 2015 15:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veKnqfoFMGxo; Tue, 7 Apr 2015 15:37:17 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B95941ACC8D; Tue, 7 Apr 2015 15:37:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C14C3BE49; Tue, 7 Apr 2015 23:37:14 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXqEDr0mOd2t; Tue, 7 Apr 2015 23:37:13 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F2A74BE33; Tue, 7 Apr 2015 23:37:12 +0100 (IST) Message-ID: <55245C15.6040700@cs.tcd.ie> Date: Tue, 07 Apr 2015 23:37:09 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jean-Marc Valin , The IESG References: <20150407160451.19098.17210.idtracker@ietfa.amsl.com> <552438CE.90807@mozilla.com> In-Reply-To: <552438CE.90807@mozilla.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qTP785KlevKxfLwPA6tpJX0kjBLgcMgxQ" Archived-At: Cc: draft-ietf-payload-rtp-opus.ad@ietf.org, payload-chairs@ietf.org, payload@ietf.org, draft-ietf-payload-rtp-opus.shepherd@ietf.org, draft-ietf-payload-rtp-opus@ietf.org Subject: Re: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-opus-08: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 22:37:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qTP785KlevKxfLwPA6tpJX0kjBLgcMgxQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jean-Marc, On 07/04/15 21:06, Jean-Marc Valin wrote: > Hi, >=20 > Thanks for the review. See comments below. >=20 > On 07/04/15 12:04 PM, Stephen Farrell wrote: >> I have one thing I'd like to discuss briefly... >=20 >> cbr=3D0 (aka vbr) as a default is a security concern since you're >> making the less secure option the default. Did the WG consider that >> issue when deciding to pick this default? Given current deployments >> would it still actually be feasible to switch the default to cbr? >> Or would it be possible to say that cbr is the default for >> encrypted traffic but vbr for cleartext? (Note: I don't plan on=20 >> having a big fight about this if it's really too late and it'd not >> be possible to change what implementations do for the default. But >> even in that case, we might be able to usefully add some >> more/better guidance.) >=20 > The cbr=3D parameter is only a receiver-side preference.=20 As I said earlier, I missed that, but that's good enough to clear the discuss. (I have balloted no-objection now.) > The sender can > always send CBR even if the receiver indicates it is okay with > receiving VBR. We need to be aware that in very specific circumstances > VBR may be used to recover information about the audio, but in the > vast majority of cases, there is no such issue. It is certainly no > worse than other information we already give out (VBR video, > unencrypted headers, ...). >=20 > As already noted in the draft, RFC6562 already discusses the few cases > where CBR would be more appropriate. In all of these cases, it is the > sender that knows there is an issue, so it really doesn't matter at > all what the receiver uses for cbr=3D. In general, considering that Opu= s > is more efficient at VBR than CBR, I believe receivers should be > willing to receive it by default, unless they have a reason to require > the sender to send CBR. Fair enough wrt receivers yes. >=20 >> - 3.1.2: s/_might_ occur/occurs/ the information leak does occur >> unquestionably, the only uncertainty is whether or not someone >> cares about that, whereas the current text implies that the leak >> might not be real. As written, the text is misleading, though not >> sufficiently to make this a DISCUSS. (I am assuming there is no >> result that shows that encrypted OPUS traffic is somehow not >> leaking information in the way other codecs do.) >=20 > As far as I'm aware of, the only codec for which information leak from > VBR has ever been measured is Speex (anyone knows of another one?). As > an author on both Speex and Opus, I can at least say that the way the > two do VBR is completely different. Enough so that beyond the very > basic fact that rate changes have entropy, I don't think we can really > use Speex to draw conclusions about Opus. Of course, this is not to > say we should ignore the matter. So I do think it's fair to say that, in principle, any vbr codec might suffer from such problems. There is a history of researchers finding such issues, with codecs and more generally with compression. As 6562 itself notes, attacks only ever get worse. So I think there is a valid concern. (And the language change suggested above is, I think, justified.) But I do get that there's no currently known (to me anyway) reason to be too concerned with cipphertext carrying opus/vbr, so I'd not argue that we ought prohibit it or similar. However I would suggest that there may be a time in future when, due to someone clever figuring out how to exploit something in opus/vbr, we might want to move to stop sending opus/vbr/dtls say. So maybe it'd be wise to add something along the lines of "While ciphertext carrying opus with vpr is not believed to be currently exploitable in the ways indicated in RFC 6562, there may come a day when such an exploit is found. Implementations ought consider ways in which they could react to such a discovery, e.g. by ensuring it will be possible to stop using vbr and, from that point in time, only use cbr, via whatever mechanisms are appropriate for the implementation concerned." Does that sound reasonable? (But note this is a non-blocking comment.) >=20 >> - 6.1, maxptime and ptime: I read this as saying that 3, 6, 9 etc >> are all valid values, but that e.g. 43 is not. Is that correct? In >> other words can I mix frames that contain different durations of >> audio into one RTP packet? (You may have told me earlier, but I've >> forgotten already, sorry:-) >=20 > Well, technically 43 is a valid ptime (despite being a dumb thing to > do) if you put 17 frames of 2.5 ms in a packet.=20 Heh. I missed that combination;-) > OTOH, 6 and 9 and not > valid, since two and three 2.5 ms frames would have ptimes of 5 and 8, > respectively. Note that Opus does not allow mixing frame sizes in the > same packet, so 43 cannot be achieved by 40+2.5 and only by 17*2.5. That's fine - it does mean what I read it to mean so. No change needed. Thanks, S. >=20 > Cheers, >=20 > Jean-Marc >=20 --qTP785KlevKxfLwPA6tpJX0kjBLgcMgxQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJVJFwYAAoJEC88hzaAX42ibqAH/1iBREc/CRpDR2wOx/SYjbQU AwDVk28trHyTmRt74a/ib8+axZx9Lz9pvYHY4krbQpvL5WnBaWvftsWb0ehl1hCd 9hdnFmfAPWEFW3dpJNd/ppEDtf+Vm0JU6jteiyZsMITqB2NsklKuQKUCZi6REkgJ G1w3gfbVbvjrGCddYW/QPobOK5QtTKbztPxgKeatpvmcBiBpCGb1ECNJLe4a4qkv JDWGAN4eGReGdGP7K0yo6qz9KDpbJsmnQSc7iHww1oQDP/1vesgKaW5Y2QG//nRp 3yA8UxYUE/JuMyk2qomkscXsNeL7MNs193GTTQ6rSbW6+zSxqFJHhXS3yQUA5r8= =mhgd -----END PGP SIGNATURE----- --qTP785KlevKxfLwPA6tpJX0kjBLgcMgxQ-- From nobody Wed Apr 8 05:43:38 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFE91A1AC1; Wed, 8 Apr 2015 05:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVVRO0M3bcGG; Wed, 8 Apr 2015 05:43:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E231A1AB9; Wed, 8 Apr 2015 05:43:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150408124335.2279.31223.idtracker@ietfa.amsl.com> Date: Wed, 08 Apr 2015 05:43:35 -0700 Archived-At: Cc: draft-ietf-payload-rtp-opus@ietf.org, draft-ietf-payload-rtp-opus.ad@ietf.org, payload-chairs@ietf.org, draft-ietf-payload-rtp-opus.shepherd@ietf.org, payload@ietf.org Subject: [payload] Brian Haberman's No Objection on draft-ietf-payload-rtp-opus-08: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 12:43:36 -0000 Brian Haberman has entered the following ballot position for draft-ietf-payload-rtp-opus-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Barry that Section 3 should be explicitly called out as an applicability statement. From nobody Wed Apr 8 08:18:07 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A8E1ACDE7; Tue, 7 Apr 2015 17:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUpd6Pyj9pwM; Tue, 7 Apr 2015 17:12:22 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CD2D1ACDE6; Tue, 7 Apr 2015 17:12:21 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so46356281lbb.3; Tue, 07 Apr 2015 17:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f/5tONVwPB86J5yMSrjNO5p1qHyWbzPUeZ/HbDrG21k=; b=f1uMC9lim1amZyxSf2UoiMKGuukZ4v0jKovkaiglaaYuBTaAsdxIYJtX3lyCvqARbs ERXCojmZ4q+0gnazR8VIFeZ/V/9fHR+pyFa2t/TxZO+pIaoo1/A4zv6OUXfOdLn1Jbdh XSdJTWglVKJhos2XWrm+/0CVDzmHDXGn4CNTeuvaqQh2XrAciLEIl+Oja6ACjF1zTTyK 49r+POxBcIp9xCbWrbZz8GsPfGsJfEIaxydP8PwK1nYeF/Cx1LPainFz8L+sm+Burnxq azOQmqvWp+KprZMioEzp74Z5BOdBvjPaNJXb+QBAsIv71fAwq9Qw7y2yd5YkNpCdfMWE C9cQ== MIME-Version: 1.0 X-Received: by 10.112.167.228 with SMTP id zr4mr20352402lbb.113.1428451939828; Tue, 07 Apr 2015 17:12:19 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Tue, 7 Apr 2015 17:12:19 -0700 (PDT) In-Reply-To: References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> Date: Tue, 7 Apr 2015 20:12:19 -0400 Message-ID: From: Kathleen Moriarty To: Derek Atkins Content-Type: multipart/alternative; boundary=001a11c2432a73c7e005132b6237 Archived-At: X-Mailman-Approved-At: Wed, 08 Apr 2015 08:18:05 -0700 Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 00:12:24 -0000 --001a11c2432a73c7e005132b6237 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 7, 2015 at 10:42 AM, Derek Atkins wrote: > Hi, > > Jean-Marc Valin writes: > > > Does anyone object to this earlier proposal? > > > > "Opus does not provide any built-in confidentiality or integrity > > protection. Protection requirements vary between RTP applications. See > > RFC 7201 and RFC 7202 for a discussion." > I'm okay with this text and did read the subsequent messages in this thread. Since there is a MAY already for session encryption, that's why we were inserting a SHOULD. I'm fine with getting rid of the RFC2119 language, but having some generic advice about RTP payloads. Since there is no draft ready or in the works to fix this problem where it should be fixed, I do think it's a good idea to address the concern here and going forward. Once it's fixed int eh right place, then references and text changes going forward. Thanks for the discussion on this. Kathleen > > > If not, that's probably what should go in the RFC (assuming it works > > for Kathleen Moriarty's DISCUSS too). > > > > Jean-Marc > > It's not quite as strong a statement as I'd like to see, but if Kathleen > is okay with it then I'm okay with it. > > -derek > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > > -- Best regards, Kathleen --001a11c2432a73c7e005132b6237 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 7, 2015 at 10:42 AM, Derek Atkins <derek@ihtfp.com> wrote:
Hi,

Jean-Marc Valin <jmvalin@mozilla.= com> writes:

> Does anyone object to this earlier proposal?
>
> "Opus does not provide any built-in confidentiality or integrity<= br> > protection. Protection requirements vary between RTP applications. See=
> RFC 7201 and RFC 7202 for a discussion."
<= div>
I'm okay with this text and did read the subsequent = messages in this thread.=C2=A0 Since there is a MAY already for session enc= ryption, that's why we were inserting a SHOULD.=C2=A0 I'm fine with= getting rid of the RFC2119 language, but having some generic advice about = RTP payloads.=C2=A0 Since there is no draft ready or in the works to fix th= is problem where it should be fixed, I do think it's a good idea to add= ress the concern here and going forward.=C2=A0 Once it's fixed int eh r= ight place, then references and text changes going forward.

<= /div>
Thanks for the discussion on this.

Kathl= een

>
> If not, that's probably what should go in the RFC (assuming it wor= ks
> for Kathleen Moriarty's DISCUSS too).
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Jean-Marc

It's not quite as strong a statement as I'd like to see, but= if Kathleen
is okay with it then I'm okay with it.

-derek

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0Derek Atkins=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0617-623-3745
=C2=A0 =C2=A0 =C2=A0 =C2=A0derek@ihtfp.c= om=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0www.ihtfp.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0Computer and Internet Security Consultant




--
=

Best regards,
Kathleen
--001a11c2432a73c7e005132b6237-- From nobody Wed Apr 8 08:18:08 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3356E1A1A7B; Wed, 8 Apr 2015 02:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojpD6LajkMeX; Wed, 8 Apr 2015 02:08:31 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B3F1A0078; Wed, 8 Apr 2015 02:08:30 -0700 (PDT) Received: from [130.209.247.112] (port=58266 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YflyG-00035Y-Bt; Wed, 08 Apr 2015 10:08:28 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_38F10A7C-6333-4A3E-881D-A1158D3B11CA" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Wed, 8 Apr 2015 10:08:14 +0100 Message-Id: <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: X-Mailman-Approved-At: Wed, 08 Apr 2015 08:18:05 -0700 Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Derek Atkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 09:08:33 -0000 --Apple-Mail=_38F10A7C-6333-4A3E-881D-A1158D3B11CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 8 Apr 2015, at 01:12, Kathleen Moriarty = wrote: > On Tue, Apr 7, 2015 at 10:42 AM, Derek Atkins wrote: > Hi, >=20 > Jean-Marc Valin writes: >=20 > > Does anyone object to this earlier proposal? > > > > "Opus does not provide any built-in confidentiality or integrity > > protection. Protection requirements vary between RTP applications. = See > > RFC 7201 and RFC 7202 for a discussion." >=20 > I'm okay with this text and did read the subsequent messages in this = thread. Since there is a MAY already for session encryption, that's why = we were inserting a SHOULD. I'm fine with getting rid of the RFC2119 = language, but having some generic advice about RTP payloads. Since = there is no draft ready or in the works to fix this problem where it = should be fixed, I do think it's a good idea to address the concern here = and going forward. Once it's fixed int eh right place, then references = and text changes going forward. There is some guidance in draft-ietf-payload-rtp-howto-13 sections 7.2 = and A.13 for payload format text. That draft is in the RFC Editor queue, = but I'm sure Magnus would be pleased to receive feedback if the = suggestions there are not clear. --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_38F10A7C-6333-4A3E-881D-A1158D3B11CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On 8 = Apr 2015, at 01:12, Kathleen Moriarty <kathleen.moriarty.ietf@gm= ail.com> wrote:
On Tue, Apr 7, 2015 at = 10:42 AM, Derek Atkins <derek@ihtfp.com> wrote:
Hi,

Jean-Marc Valin <jmvalin@mozilla.com> = writes:

> Does anyone object to this earlier proposal?
>
> "Opus does not provide any built-in confidentiality or = integrity
> protection. Protection requirements vary between RTP applications. = See
> RFC 7201 and RFC 7202 for a = discussion."

I'm okay with = this text and did read the subsequent messages in this thread.  = Since there is a MAY already for session encryption, that's why we were = inserting a SHOULD.  I'm fine with getting rid of the RFC2119 = language, but having some generic advice about RTP payloads.  Since = there is no draft ready or in the works to fix this problem where it = should be fixed, I do think it's a good idea to address the concern here = and going forward.  Once it's fixed int eh right place, then = references and text changes going = forward.

There is = some guidance in draft-ietf-payload-rtp-howto-13 sections 7.2 and A.13 = for payload format text. That draft is in the RFC Editor queue, but I'm = sure Magnus would be pleased to receive feedback if the suggestions = there are not clear.


-- 
Colin Perkins

<= /div>


= --Apple-Mail=_38F10A7C-6333-4A3E-881D-A1158D3B11CA-- From nobody Wed Apr 8 08:18:09 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBAA1B315A; Wed, 8 Apr 2015 07:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Of-ERTznzXoQ; Wed, 8 Apr 2015 07:35:37 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB14F1B3100; Wed, 8 Apr 2015 07:35:17 -0700 (PDT) Received: from [130.209.247.112] (port=61738 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Yfr4S-0007u1-PX; Wed, 08 Apr 2015 15:35:14 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Wed, 8 Apr 2015 15:35:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> To: Derek Atkins X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: X-Mailman-Approved-At: Wed, 08 Apr 2015 08:18:05 -0700 Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 14:35:43 -0000 On 8 Apr 2015, at 15:24, Derek Atkins wrote: > Colin, et all, >=20 > I suggest you take a closer look at the existing document. In > particular, I do not accept the argument that this is the wrong place = to > recommend security, because the existing draft already does. See = below: >=20 > Colin Perkins writes: >=20 >> On 8 Apr 2015, at 01:12, Kathleen Moriarty = >> wrote: >>=20 >> On Tue, Apr 7, 2015 at 10:42 AM, Derek Atkins = wrote: >>=20 >> Hi, >>=20 >> Jean-Marc Valin writes: >>=20 >>> Does anyone object to this earlier proposal? >>>=20 >>> "Opus does not provide any built-in confidentiality or integrity >>> protection. Protection requirements vary between RTP applications. >> See >>> RFC 7201 and RFC 7202 for a discussion." >>=20 >> I'm okay with this text and did read the subsequent messages in = this >> thread. Since there is a MAY already for session encryption, = that's why >> we were inserting a SHOULD. I'm fine with getting rid of the = RFC2119 >> language, but having some generic advice about RTP payloads. = Since there >> is no draft ready or in the works to fix this problem where it = should be >> fixed, I do think it's a good idea to address the concern here and = going >> forward. Once it's fixed int eh right place, then references and = text >> changes going forward. >>=20 >> There is some guidance in draft-ietf-payload-rtp-howto-13 sections = 7.2 and >> A.13 for payload format text. That draft is in the RFC Editor queue, = but I'm >> sure Magnus would be pleased to receive feedback if the suggestions = there are >> not clear. >=20 > Let me quote a section of the draft, in particular section 8. Security > Considerations: >=20 > This payload format transports Opus encoded speech or audio data. > Hence, security issues include confidentiality, integrity = protection, > and authentication of the speech or audio itself. Opus does not > provide any confidentiality or integrity protection. Any suitable > external mechanisms, such as SRTP [RFC3711], MAY be used. >=20 > So this draft already DOES make a recommendation about the transport > layer security. I was saying that you should change this MAY to a > SHOULD, which is where this all started. >=20 > You may say "this is the wrong layer", but from where I sit that horse > has already left the barn. The WG already let it pass with this > recommendation as a MAY. As a memeber of the Security Area = Directorate > I think this MAY should be changed to a SHOULD. And as I keep saying, I believe that is inappropriate, since it's = recommending SRTP which is not suitable for many applications. The = rtp-howto draft suggests the following text: RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification RFC3550, and in any applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload formats responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity and source authenticity for RTP in general. This responsibility lays on anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in Options for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. (The two drafts referenced are what became RFCs 7201 and 7202). If you want to augment that with a "strong security SHOULD/MUST be = used", then I certainly don't object. However, a payload format really = shouldn't be trying to recommend use of a particular RTP security = solution, such as SRTP. --=20 Colin Perkins https://csperkins.org/ From nobody Wed Apr 8 08:18:24 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472FD1B3119; Wed, 8 Apr 2015 07:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbKDAsQxRcTH; Wed, 8 Apr 2015 07:24:53 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68AC71B310F; Wed, 8 Apr 2015 07:24:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id E10F3E2039; Wed, 8 Apr 2015 10:24:48 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 09597-01; Wed, 8 Apr 2015 10:24:41 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id BE1FDE2038; Wed, 8 Apr 2015 10:24:41 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t38EOdge013770; Wed, 8 Apr 2015 10:24:39 -0400 From: Derek Atkins To: Colin Perkins References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> Date: Wed, 08 Apr 2015 10:24:39 -0400 In-Reply-To: <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> (Colin Perkins's message of "Wed, 8 Apr 2015 10:08:14 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: X-Mailman-Approved-At: Wed, 08 Apr 2015 08:18:11 -0700 Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Derek Atkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 14:24:54 -0000 Colin, et all, I suggest you take a closer look at the existing document. In particular, I do not accept the argument that this is the wrong place to recommend security, because the existing draft already does. See below: Colin Perkins writes: > On 8 Apr 2015, at 01:12, Kathleen Moriarty > wrote: > > On Tue, Apr 7, 2015 at 10:42 AM, Derek Atkins wrote: > > Hi, > > Jean-Marc Valin writes: > > > Does anyone object to this earlier proposal? > > > > "Opus does not provide any built-in confidentiality or integrity > > protection. Protection requirements vary between RTP applications. > See > > RFC 7201 and RFC 7202 for a discussion." > > I'm okay with this text and did read the subsequent messages in this > thread. Since there is a MAY already for session encryption, that's why > we were inserting a SHOULD. I'm fine with getting rid of the RFC2119 > language, but having some generic advice about RTP payloads. Since there > is no draft ready or in the works to fix this problem where it should be > fixed, I do think it's a good idea to address the concern here and going > forward. Once it's fixed int eh right place, then references and text > changes going forward. > > There is some guidance in draft-ietf-payload-rtp-howto-13 sections 7.2 and > A.13 for payload format text. That draft is in the RFC Editor queue, but I'm > sure Magnus would be pleased to receive feedback if the suggestions there are > not clear. Let me quote a section of the draft, in particular section 8. Security Considerations: This payload format transports Opus encoded speech or audio data. Hence, security issues include confidentiality, integrity protection, and authentication of the speech or audio itself. Opus does not provide any confidentiality or integrity protection. Any suitable external mechanisms, such as SRTP [RFC3711], MAY be used. So this draft already DOES make a recommendation about the transport layer security. I was saying that you should change this MAY to a SHOULD, which is where this all started. You may say "this is the wrong layer", but from where I sit that horse has already left the barn. The WG already let it pass with this recommendation as a MAY. As a memeber of the Security Area Directorate I think this MAY should be changed to a SHOULD. Thanks, -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Apr 8 08:18:26 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5D61B3173; Wed, 8 Apr 2015 07:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44kgDEeQf67S; Wed, 8 Apr 2015 07:43:03 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E281B3171; Wed, 8 Apr 2015 07:43:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 2AC29E2036; Wed, 8 Apr 2015 10:43:02 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 09597-07; Wed, 8 Apr 2015 10:42:59 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id ABEE5E2038; Wed, 8 Apr 2015 10:42:59 -0400 (EDT) Received: from 192.168.248.204 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Wed, 8 Apr 2015 10:42:59 -0400 Message-ID: <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> In-Reply-To: <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> Date: Wed, 8 Apr 2015 10:42:59 -0400 From: "Derek Atkins" To: "Colin Perkins" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: X-Mailman-Approved-At: Wed, 08 Apr 2015 08:18:15 -0700 Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Derek Atkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 14:43:04 -0000 On Wed, April 8, 2015 10:35 am, Colin Perkins wrote: [snip] > > And as I keep saying, I believe that is inappropriate, since it's > recommending SRTP which is not suitable for many applications. The > rtp-howto draft suggests the following text: > [sniped and added below] > > (The two drafts referenced are what became RFCs 7201 and 7202). > > If you want to augment that with a "strong security SHOULD/MUST be used", > then I certainly don't object. However, a payload format really shouldn't > be trying to recommend use of a particular RTP security solution, such as > SRTP. Okay, so if you want to change the text completely (which I'm fine with), how about just adding a single sentence to the end of what you have: RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification RFC3550, and in any applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload formats responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity and source authenticity for RTP in general. This responsibility lays on anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in Options for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. Applications SHOULD implement at least one of the strong security measures suggested by those references. > -- > Colin Perkins > https://csperkins.org/ -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Apr 8 11:53:11 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568011B34FC; Wed, 8 Apr 2015 11:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14i58711_8g3; Wed, 8 Apr 2015 11:53:04 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750191B34FA; Wed, 8 Apr 2015 11:53:01 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t38Iqhrp060012 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2015 13:52:54 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Derek Atkins" Date: Wed, 08 Apr 2015 13:52:43 -0500 Message-ID: In-Reply-To: <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 18:53:05 -0000 On 8 Apr 2015, at 9:42, Derek Atkins wrote: > On Wed, April 8, 2015 10:35 am, Colin Perkins wrote: > [snip] >> >> And as I keep saying, I believe that is inappropriate, since it's >> recommending SRTP which is not suitable for many applications. The >> rtp-howto draft suggests the following text: >> > [sniped and added below] >> >> (The two drafts referenced are what became RFCs 7201 and 7202). >> >> If you want to augment that with a "strong security SHOULD/MUST be >> used", >> then I certainly don't object. However, a payload format really >> shouldn't >> be trying to recommend use of a particular RTP security solution, >> such as >> SRTP. > > Okay, so if you want to change the text completely (which I'm fine > with), > how about just adding a single sentence to the end of what you have: > > RTP packets using the payload format defined in this specification > are subject to the security considerations discussed in the RTP > specification RFC3550, and in any applicable RTP profile such as > RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ > SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: > Why RTP Does Not Mandate a Single Media Security Solution" > [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload > formats responsibility to discuss or mandate what solutions are used > to meet the basic security goals like confidentiality, integrity and > source authenticity for RTP in general. This responsibility lays on > anyone using RTP in an application. They can find guidance on > available security mechanisms and important considerations in Options > for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. > Applications SHOULD implement at least one of the strong security > measures suggested by those references. I'm okay with using the rtp-howto text. But _strictly_as_an_individual_, I'd prefer not to add the last sentence, for 2 reasons: 1) This effectively creates a normative downref to informational RFCs (7201/7202). That's mainly a process issue, and we can do that if it's the right thing to do. But... 2) ... I still don't think a payload format is the right place to put this sort of thing (that is, the last sentence.) Now, if our plan is to put that text into all future payload formats, that's not quite as bad. But unless we plan to revise legacy formats, it still creates confusing inconsistency between formats. For an extreme example, having that sentence in Codec format A and not format B could lead to implementor decisions on the order of "I don't want to bother with crypto, so I will choose codec B because it has lighter requirements" might appear to make sense to someone not steeped in this argument. What I'd _really_ like to do is take the energy in this thread and apply it to creating a standards-track security document for RTP unicast applications. From nobody Wed Apr 8 12:49:25 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CFC1B357E; Wed, 8 Apr 2015 12:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ofd_AwwhPQM; Wed, 8 Apr 2015 12:49:21 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C33F1B3581; Wed, 8 Apr 2015 12:49:21 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t38Jn6hS065356 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2015 14:49:17 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Derek Atkins" Date: Wed, 08 Apr 2015 14:49:05 -0500 Message-ID: <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> In-Reply-To: References: <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 19:49:24 -0000 On 8 Apr 2015, at 14:38, Derek Atkins wrote: > Ben, > > On Wed, April 8, 2015 2:52 pm, Ben Campbell wrote: >> On 8 Apr 2015, at 9:42, Derek Atkins wrote: >> >>> On Wed, April 8, 2015 10:35 am, Colin Perkins wrote: >>> [snip] >>>> >>>> And as I keep saying, I believe that is inappropriate, since it's >>>> recommending SRTP which is not suitable for many applications. The >>>> rtp-howto draft suggests the following text: >>>> >>> [sniped and added below] >>>> >>>> (The two drafts referenced are what became RFCs 7201 and 7202). >>>> >>>> If you want to augment that with a "strong security SHOULD/MUST be >>>> used", >>>> then I certainly don't object. However, a payload format really >>>> shouldn't >>>> be trying to recommend use of a particular RTP security solution, >>>> such as >>>> SRTP. >>> >>> Okay, so if you want to change the text completely (which I'm fine >>> with), >>> how about just adding a single sentence to the end of what you have: >>> >>> RTP packets using the payload format defined in this specification >>> are subject to the security considerations discussed in the RTP >>> specification RFC3550, and in any applicable RTP profile such as >>> RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ >>> SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: >>> Why RTP Does Not Mandate a Single Media Security Solution" >>> [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload >>> formats responsibility to discuss or mandate what solutions are used >>> to meet the basic security goals like confidentiality, integrity and >>> source authenticity for RTP in general. This responsibility lays on >>> anyone using RTP in an application. They can find guidance on >>> available security mechanisms and important considerations in >>> Options >>> for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. >>> Applications SHOULD implement at least one of the strong security >>> measures suggested by those references. >> >> I'm okay with using the rtp-howto text. But >> _strictly_as_an_individual_, >> I'd prefer not to add the last sentence, for 2 reasons: >> >> 1) This effectively creates a normative downref to informational RFCs >> (7201/7202). That's mainly a process issue, and we can do that if >> it's >> the right thing to do. But... > > It's technically not a downref because the referred documents are > guidance > and not protocols. So I don't think there would be any issue. There > is > already precedent for that. As I said, it's just process. > >> 2) ... I still don't think a payload format is the right place to put >> this sort of thing (that is, the last sentence.) Now, if our plan is >> to >> put that text into all future payload formats, that's not quite as >> bad. >> But unless we plan to revise legacy formats, it still creates >> confusing >> inconsistency between formats. > > I'll point out, again, that the original draft *already did this*, so > you > should be talking to the working group about that and not to me. From > where I sit, I saw the "MAY encrypt" and said "please change that from > MAY > to SHOULD." That's where this all started. > > Now, you could say (possibly even correctly -- I wont make that > judgement > call) that the WG made a mistake putting that sentence into the > Security > Considerations at all in the first place, but they did. Clearly the > WG > decided it was worthwhile to mention that; I'm just suggesting to make > the > mention stronger than what was there in -08. I'm not convinced. SHOULD is considerably more constraining that MAY. > >> For an extreme example, having that sentence in Codec format A and >> not >> format B could lead to implementor decisions on the order of "I don't >> want to bother with crypto, so I will choose codec B because it has >> lighter requirements" might appear to make sense to someone not >> steeped >> in this argument. >> >> What I'd _really_ like to do is take the energy in this thread and >> apply >> it to creating a standards-track security document for RTP unicast >> applications. > > Are you willing to hold up this document until that work is done so it > can > refer to the (yet-to-be-written) protocol security update draft? I'm > fine > with that approach and I'm willing to review whatever draft you guys > produce if that's how you'd like to proceed. No, I will go with the consensus on this one. I note that several WG participants objected to the orignally proposed SHOULD. I am pointing out that this SHOULD is not much different, but I will go with what people want to do. OTOH, what I would like to do would fix the problem for this, and all other codec payload formats, after the fact if we do it right (since it would apply to the application) > > Or you can hold your nose and live with the "UGGH" of it based on what > the > WG original created in -08 and move forward for now, knowing that you > can > (and should) correct it "right" later. The work group did not put in a SHOULD. I think this is more of a question of whether people are willing to hold there collective noses about the lack of _normative_ privacy guidance for RTP in general, and if they are willing to let payload formats continue to progress while that is being worked out. > > I have no skin in that decision :) > > -derek > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant From nobody Wed Apr 8 13:13:21 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89A91B35EA for ; Wed, 8 Apr 2015 13:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48TGeuU8nJib for ; Wed, 8 Apr 2015 13:13:19 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2641B35EE for ; Wed, 8 Apr 2015 13:13:17 -0700 (PDT) Received: by qgej70 with SMTP id j70so33824757qge.2 for ; Wed, 08 Apr 2015 13:13:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WcV4EnoA+haGwrSbbIvp3afI7YDBYyJw4B785Sx5yyw=; b=jx3oWpXchssp7uBKptfMLvYaB0S35Z7K3qOuVkezByQ57myR3RLVWgYMvR8bo9IX+9 NpOqetRyQGEsMqPTlukKQjWg7P++CLUlGGHWDBTwSe/P7cV2bUaUtpwFZV0JcdXcmvaA 44WXY87QkZ/YscqE4kw44s/vhOALwWCLQdNpKtVIc4+PTuE5VfDFMC6OzASHeuecOH6t a4waJ0lSfmJso025RJ0niPUe0W3AMhusF0qM8eH8bnne491BLIujzwelGNrOGvyrPy7w lndsloFvpl8gZb6saQsM7vphkZXk6c5XNU/LP2meeznq1bblo7BtF39viNiOGBSBTgbw dI5w== X-Gm-Message-State: ALoCoQllmWcWGWieFjluof6NqhBfZegoakvD40uvNWyNvoUSvozA7/q3u/cttWINaJKbQPSCUaTh X-Received: by 10.140.48.129 with SMTP id o1mr23907011qga.21.1428523996558; Wed, 08 Apr 2015 13:13:16 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by mx.google.com with ESMTPSA id e70sm8157598qka.40.2015.04.08.13.13.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2015 13:13:16 -0700 (PDT) Message-ID: <55258BDB.1020707@jmvalin.ca> Date: Wed, 08 Apr 2015 16:13:15 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Barry Leiba , The IESG References: <20150407180105.13228.22557.idtracker@ietfa.amsl.com> In-Reply-To: <20150407180105.13228.22557.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-payload-rtp-opus@ietf.org, draft-ietf-payload-rtp-opus.ad@ietf.org, payload-chairs@ietf.org, draft-ietf-payload-rtp-opus.shepherd@ietf.org, payload@ietf.org Subject: Re: [payload] Barry Leiba's Yes on draft-ietf-payload-rtp-opus-08: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 20:13:20 -0000 Hi, Thanks for the review. See my comments below. > The Abstract and Introduction both understate what this document is. It > doesn't just define the payload format and registrations, but also > provides what I would consider an Applicability Statement in Section 3: > normative, Standards Track advice about how to use the Opus codec, > complete with MUST and SHOULD and SHOULD NOT. That's fine, but both the > Abstract and Introduction should say that. Would adding a sentence along the lines of: "This document also provides an applicability statement for the use of Opus over RTP" to both the abstract and introduction be sufficient to address the issue? > -- Section 4.1 -- > > Opus supports 5 different audio bandwidths, which can be adjusted > during a call. > > Wouldn't "during a stream", or "during active streaming", or perhaps > "during an RTP session", or some such be better than referring to "a > call"? I totally agree. I would just go with "during a stream". > -- Section 5 -- > > It is RECOMMENDED that senders of Opus encoded data apply congestion > control. > > Does this SHOULD come with any reference to how to do congestion control? > The previous paragraph has some vague statements about doing congestion > control, but is there anything more concrete that I could refer to if I > were implementing this? There is no recommended way to do congestion control here and it would be beyond the scope of this draft. I guess it is something that needs to be done for any kind of streaming. The main reason it's more relevant to mention it for Opus than for some other VoIP codecs (e.g. G.711, G.729) is that Opus supports a large range of bit-rates which means that it's actually possible to adjust the bandwidth. Cheers, Jean-Marc From nobody Wed Apr 8 13:31:07 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4101B3625 for ; Wed, 8 Apr 2015 13:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2upxQmLJ3-cd for ; Wed, 8 Apr 2015 13:30:58 -0700 (PDT) Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com [209.85.220.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F021B1B3620 for ; Wed, 8 Apr 2015 13:30:53 -0700 (PDT) Received: by qkx62 with SMTP id 62so95902297qkx.0 for ; Wed, 08 Apr 2015 13:30:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4F/mmpJ/M2Nv8qot7LU3aflCKQfYglEX8za8R6yYhwk=; b=My12uAlqhFhn/0E/WYXMKdXDcrDqOo5b/p/z0Zexbm6D/yYOGQg5lX+SA/Y9hgeu9q VT4Ji2biRM2T1aRevA6usMa5jIfTqLpJqkyV8809pF4x5r4l1MSTq5f1zKTgpKLxtP+b e85flcAHUNkRVj1wti8cRDmA/eXGdz7D4gmoHtCq6krlrSnNAduXEBmvP5rYlQrwOd8g IOxHg6exv+wqoAh1uYZn4QijHYnb82xRsn+c5p8WzxGSn1ZYLLzDTzfS+0xI/eGr/jO1 Fu3vqdNLZK6nn9f2MRzYxeFXZZFk+jfDfEILvCKXgPvV8vvNJf3Fe85bOKFtvuiCHFin 1n1w== X-Gm-Message-State: ALoCoQnLpzYJjqxqJ9D6yLDfv2+koIKY90JrY57mZxegE5d6mbZuQ8PEvDb4L16JhE81nHf6KDnk X-Received: by 10.55.21.87 with SMTP id f84mr48903954qkh.50.1428525053207; Wed, 08 Apr 2015 13:30:53 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by mx.google.com with ESMTPSA id h14sm1911882qhc.46.2015.04.08.13.30.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2015 13:30:52 -0700 (PDT) Message-ID: <55258FFB.2070900@jmvalin.ca> Date: Wed, 08 Apr 2015 16:30:51 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ben Campbell , Spencer Dawkins References: <20150407023433.21936.12615.idtracker@ietfa.amsl.com> <850D891D-3D80-4888-A815-EAC9E712E630@nostrum.com> In-Reply-To: <850D891D-3D80-4888-A815-EAC9E712E630@nostrum.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-payload-rtp-opus@ietf.org, payload-chairs@ietf.org, payload@ietf.org, draft-ietf-payload-rtp-opus.shepherdl@ietf.org, The IESG Subject: Re: [payload] Spencer Dawkins' No Objection on draft-ietf-payload-rtp-opus-08: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 20:30:59 -0000 > 3. Opus Codec > > Further, Opus allows transmitting stereo signals. > > I wasn't sure what this was telling me until I got to section 3.4, and saw this > text: "signaled in-band in the Opus payload". Perhaps adding that phrase in > Section 3 would be helpful? I can change to "Further, Opus allows transmitting stereo signals with in-band signaling". I'd rather avoid the term "payload" here since the signaling is defined in Opus itself rather than the RTP payload format. > In this text: > > 3.1.2. Variable versus Constant Bitrate > > One > reason for choosing CBR is the potential information leak that > _might_ occur when encrypting the compressed stream. See [RFC6562] > for guidelines on when VBR is appropriate for encrypted audio > communications. > > I THINK I know what "potential information leak" means in this case, but I'm > guessing. I learned a lot from the [RFC6562] reference. Is it possible to > provide a short clue here? Would it be correct to say something like "One > reason for choosing CBR is that some codecs have been observed to provide > predictable VBR patterns for highly structured dialogs where only a few phrases > are expected, and potentially leaking information without requiring an > eavesdropper to decrypt the payload"? Ideally I would rather avoid attempting to summarize RFC6562 in just one or two sentences. I think we managed to strike roughly the right balance in RFC6562 and it would be easy to create confusion by attempting to address the issue in this document too. > Also in 3.1.2: > > The bitrate can be adjusted at any point in time. To avoid > congestion, the average bitrate SHOULD NOT exceed the available > network bandwidth. > > I'm kind of wondering how you intend for the sender to know what the "available > network bandwidth" is. I notice a reference in Section 3.3 to > > (2) an externally-provided estimate of the > channel's capacity; > > Is "the available network bandwidth" this externally provided estimate? What > should a sender be looking at, to fulfill this SHOULD NOT? As I pointed out in my response to Barry Leiba, there's no specific "recipe" we can put in. The goal is mostly to raise awareness of the bandwidth issue. > Of course, I'm wondering why this is SHOULD NOT, instead of MUST NOT. Is this > recognizing that available network bandwidth can change instantaneously (so a > careful sender might still find itself sending too fast for a short period of > time), or is there something else going on? I don't think there's even an exact definition of "available network bandwidth", or at least not a precise measurement, so MUST NOT wouldn't make much sense. > As long as I'm mentioning section 3.3, if the "externally-provided estimate" > had some reference, that would be helpful (unless, of course, this is obvious > to those skilled in the art). The term only appears twice in 3.3, with no > pointers. It is certainly not something obvious. I believe rmcat is working on some sort of solution (not familiar with the details), so I'm not sure what else I can add here. > Is there a particular mechanism you're thinking of here? If you could make that > clearer, even just providing a reference, that would be helpful for me as a > reader. Again, all I can think of here would be to point to some rmcat work. > In other news, I support Kathleen's Discuss on SHOULD SRTP, and if it becomes a > SHOULD and not a MUST, I'd suggest adding a sentence or two explaining why not > using SRTP is the right thing to do. Waiting on a consensus on the exact text to put here. I have no strong opinion on what exactly should go there. Cheers, Jean-Marc From nobody Wed Apr 8 13:36:11 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1BB1B3633; Wed, 8 Apr 2015 13:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pjbGs4OPUDx; Wed, 8 Apr 2015 13:36:08 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1C01B362C; Wed, 8 Apr 2015 13:36:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9EB66BEDF; Wed, 8 Apr 2015 21:36:06 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ah51KuuU63YW; Wed, 8 Apr 2015 21:36:05 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5DF54BEE1; Wed, 8 Apr 2015 21:36:05 +0100 (IST) Message-ID: <55259135.6070304@cs.tcd.ie> Date: Wed, 08 Apr 2015 21:36:05 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jean-Marc Valin , Ben Campbell , Spencer Dawkins References: <20150407023433.21936.12615.idtracker@ietfa.amsl.com> <850D891D-3D80-4888-A815-EAC9E712E630@nostrum.com> <55258FFB.2070900@jmvalin.ca> In-Reply-To: <55258FFB.2070900@jmvalin.ca> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-payload-rtp-opus@ietf.org, payload-chairs@ietf.org, payload@ietf.org, draft-ietf-payload-rtp-opus.shepherdl@ietf.org, The IESG Subject: Re: [payload] Spencer Dawkins' No Objection on draft-ietf-payload-rtp-opus-08: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 20:36:09 -0000 On 08/04/15 21:30, Jean-Marc Valin wrote: >> > >> > I THINK I know what "potential information leak" means in this case, but I'm >> > guessing. I learned a lot from the [RFC6562] reference. Is it possible to >> > provide a short clue here? Would it be correct to say something like "One >> > reason for choosing CBR is that some codecs have been observed to provide >> > predictable VBR patterns for highly structured dialogs where only a few phrases >> > are expected, and potentially leaking information without requiring an >> > eavesdropper to decrypt the payload"? > Ideally I would rather avoid attempting to summarize RFC6562 in just one > or two sentences. I think we managed to strike roughly the right balance > in RFC6562 and it would be easy to create confusion by attempting to > address the issue in this document too. I think I'd agree with Jean-Marc on that one. The actual attack, when possible, is fairly subtle, esp if it affects people speaking. (Way back, I had a DISCUSS on what became 6562 where it took a couple of months for us all to get on the same page about that;-) S. From nobody Wed Apr 8 13:45:17 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF79F1B3647; Wed, 8 Apr 2015 13:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rX29DBimw-B3; Wed, 8 Apr 2015 13:45:15 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74081B3643; Wed, 8 Apr 2015 13:45:14 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so95766457ied.1; Wed, 08 Apr 2015 13:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=aTeEJO3zxyfeVqsD+oEighgl/Kn1bAwvehg5vbaoFkQ=; b=cOQvAZV/TyClaNl9Q+peEcwmI+JkEI4Hun4dAWspnm3xYGlXzx11Z1fLinW+2kMKWw LExlCeaXk7K8In9n329cqPhZ+k/q2tSnCo7ti/xIlDakk6rdyF9iBzsg8X9JakAnInul j06MIeJ25maRgSjtKkusMIdIlzDfKYEjStQaAglVbVf4R7PIocfSAgZIGB5qX6n1ns5B uHUwu7RljU7fkMYz+YCFujtbt3TorEQGLP/v/rd0xO8VRoYR3PttmB0c719W4p2+hFSE PZU73KkbQuMUtYLbRDEwrLJdhyb7tL2NetvNhgXPzscs0j8ylv8mYDZTUEQklpvTxAdq tAyg== MIME-Version: 1.0 X-Received: by 10.50.8.6 with SMTP id n6mr14891851iga.12.1428525914339; Wed, 08 Apr 2015 13:45:14 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.7.130 with HTTP; Wed, 8 Apr 2015 13:45:14 -0700 (PDT) In-Reply-To: <55258BDB.1020707@jmvalin.ca> References: <20150407180105.13228.22557.idtracker@ietfa.amsl.com> <55258BDB.1020707@jmvalin.ca> Date: Wed, 8 Apr 2015 16:45:14 -0400 X-Google-Sender-Auth: Qmi6I2bq2zfcKiLA3bYYFhesfKI Message-ID: From: Barry Leiba To: Jean-Marc Valin Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: draft-ietf-payload-rtp-opus@ietf.org, draft-ietf-payload-rtp-opus.ad@ietf.org, payload-chairs@ietf.org, draft-ietf-payload-rtp-opus.shepherd@ietf.org, payload@ietf.org, The IESG Subject: Re: [payload] Barry Leiba's Yes on draft-ietf-payload-rtp-opus-08: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 20:45:16 -0000 >> The Abstract and Introduction both understate what this document is. It >> doesn't just define the payload format and registrations, but also >> provides what I would consider an Applicability Statement in Section 3: >> normative, Standards Track advice about how to use the Opus codec, >> complete with MUST and SHOULD and SHOULD NOT. That's fine, but both the >> Abstract and Introduction should say that. > > Would adding a sentence along the lines of: "This document also provides > an applicability statement for the use of Opus over RTP" to both the > abstract and introduction be sufficient to address the issue? Completely; thanks. >> -- Section 5 -- >> >> It is RECOMMENDED that senders of Opus encoded data apply congestion >> control. >> >> Does this SHOULD come with any reference to how to do congestion control? >> The previous paragraph has some vague statements about doing congestion >> control, but is there anything more concrete that I could refer to if I >> were implementing this? > > There is no recommended way to do congestion control here and it would > be beyond the scope of this draft. I guess it is something that needs to > be done for any kind of streaming. The main reason it's more relevant to > mention it for Opus than for some other VoIP codecs (e.g. G.711, G.729) > is that Opus supports a large range of bit-rates which means that it's > actually possible to adjust the bandwidth. Hm. The problem I have is that if I'm new to all this -- say, I have a startup company that's implementing streaming with Opus -- and I see that, I'm going to need to know what to do or where to go to find out. Can you think of a sentence or two to add that will help me, even if it's just to let me know that there's nothing written about it yet? Barry From nobody Wed Apr 8 13:58:11 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2480B1B3703 for ; Wed, 8 Apr 2015 13:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fKSwjvO512n for ; Wed, 8 Apr 2015 13:58:06 -0700 (PDT) Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com [209.85.220.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2BB1B3686 for ; Wed, 8 Apr 2015 13:55:49 -0700 (PDT) Received: by qkgx75 with SMTP id x75so96539158qkg.1 for ; Wed, 08 Apr 2015 13:55:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fQdVV+oGU5+hYgGCFjFqOzOA8fhzb23cmq3qW+9lB2I=; b=Wcl4I4VeL+Di2ST2h6tbuX8TaGhD3qzMGWL4Rb0SscsOsa5JdqWqNEAOWkHfyqXkdV yxr4Xw/3QUECfHCwy6VpZIp19kGw3sTUWE6sJDYpTXRd9qOCtmR/gXQmkenpoYq1BXvF 52rDxfXzdqjU3bviaWcDXi4En7bEg/JD0XHPjTZkax387wBNa9fY1tF62ipsvWTJ+U2e YulcTIa9JbzO5KPgIfI0lfK1oEYcfldcpR/Ukw86b07LmvNEMrkr/+MsHua5getXfmox 1dwFy/tSCZ7bD8CvfVjrWQDZU/qkLfd7ztXvd5O6gshKbQ1Pn5dFhlRJhY1VBEGcEBJi iRtw== X-Gm-Message-State: ALoCoQmDS9uGCziVdLxM9dqk/NO2biM7xxk5IOHkklRSPFd5T2kfH1Yd39z7VIINKh3iZtB5dzr6 X-Received: by 10.140.216.67 with SMTP id m64mr33801356qhb.6.1428526548553; Wed, 08 Apr 2015 13:55:48 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by mx.google.com with ESMTPSA id 144sm8239459qhx.45.2015.04.08.13.55.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2015 13:55:48 -0700 (PDT) Message-ID: <552595D3.4030502@jmvalin.ca> Date: Wed, 08 Apr 2015 16:55:47 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Barry Leiba References: <20150407180105.13228.22557.idtracker@ietfa.amsl.com> <55258BDB.1020707@jmvalin.ca> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-payload-rtp-opus@ietf.org, draft-ietf-payload-rtp-opus.ad@ietf.org, payload-chairs@ietf.org, draft-ietf-payload-rtp-opus.shepherd@ietf.org, payload@ietf.org, The IESG Subject: Re: [payload] Barry Leiba's Yes on draft-ietf-payload-rtp-opus-08: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 20:58:07 -0000 On 08/04/15 04:45 PM, Barry Leiba wrote: > Hm. > The problem I have is that if I'm new to all this -- say, I have a > startup company that's implementing streaming with Opus -- and I see > that, I'm going to need to know what to do or where to go to find out. > Can you think of a sentence or two to add that will help me, even if > it's just to let me know that there's nothing written about it yet? I would be tempted to simply reword the abstract from http://tools.ietf.org/html/draft-ietf-rmcat-app-interaction-01 "Since UDP does not provide congestion control, applications that use RTP over UDP have to implement their own congestion control above the UDP layer. [draft-ietf-rmcat-app-interaction-01] describes the interactions and conceptual interfaces necessary between the application components that relate to congestion control, including the RTP layer, the higher-level media codec control layer, and the lower-level transport interface, as well as components dedicated to congestion control functions." Would that do? From nobody Wed Apr 8 14:34:28 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740C81B36E2; Wed, 8 Apr 2015 14:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTBJzKpAbJ5O; Wed, 8 Apr 2015 14:34:23 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC9A1B36E0; Wed, 8 Apr 2015 14:34:23 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so50121368igb.1; Wed, 08 Apr 2015 14:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OubKzv0K9KoWkLrEGmqeF9aq0V3EkOdSTVtjsQyEXDY=; b=TsGB1xi8CJTgphnU4nyvwDtOOB1SjMWGsW/Da1GnxQSNLGRApGYHdnwD9RibdhWBkM K4RzxUYYLXXgg1Jr4CuH6VEFM1P+obIJN1kDubdA6Nxhc18sf2HZ2Y5nv17aP5wiYvyK i+XeRGbyvG7cMabmT58wbjHBeQjZKcTH1dizC5/4ehMIU0ojmbe7KU7owrq8Y7/oy6XZ 1BLXrM2z9ffaNnjqxg4b9o9CYzbxjFSxqBNFluVRMXVYjQiQC63cVpKy2Nf1ScmeC/RL tRFV/cq5Maz+HW67C3Z4RvtAwCPYvo6kBxM8flOs2jW7Wl3x+6GVkw62nEFQPj+aW6om sM9w== MIME-Version: 1.0 X-Received: by 10.50.8.6 with SMTP id n6mr15181141iga.12.1428528862762; Wed, 08 Apr 2015 14:34:22 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.7.130 with HTTP; Wed, 8 Apr 2015 14:34:22 -0700 (PDT) In-Reply-To: <552595D3.4030502@jmvalin.ca> References: <20150407180105.13228.22557.idtracker@ietfa.amsl.com> <55258BDB.1020707@jmvalin.ca> <552595D3.4030502@jmvalin.ca> Date: Wed, 8 Apr 2015 17:34:22 -0400 X-Google-Sender-Auth: bxZb6wC1ikyeDBnukrV1lqHW4-c Message-ID: From: Barry Leiba To: Jean-Marc Valin Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: draft-ietf-payload-rtp-opus@ietf.org, draft-ietf-payload-rtp-opus.ad@ietf.org, payload-chairs@ietf.org, draft-ietf-payload-rtp-opus.shepherd@ietf.org, payload@ietf.org, The IESG Subject: Re: [payload] Barry Leiba's Yes on draft-ietf-payload-rtp-opus-08: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 21:34:24 -0000 >> The problem I have is that if I'm new to all this -- say, I have a >> startup company that's implementing streaming with Opus -- and I see >> that, I'm going to need to know what to do or where to go to find out. >> Can you think of a sentence or two to add that will help me, even if >> it's just to let me know that there's nothing written about it yet? > > I would be tempted to simply reword the abstract from > http://tools.ietf.org/html/draft-ietf-rmcat-app-interaction-01 > > "Since UDP does not provide congestion control, applications that use > RTP over UDP have to implement their own congestion control above the > UDP layer. [draft-ietf-rmcat-app-interaction-01] describes the > interactions and conceptual interfaces necessary between the application > components that relate to congestion control, including the RTP layer, > the higher-level media codec control layer, and the lower-level > transport interface, as well as components dedicated to congestion > control functions." > > Would that do? That'd give me a place to look for more information; I think that would help, yes. And I think it's fine for the rmcat document to be an informative reference. Barry From nobody Thu Apr 9 02:58:44 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D6E1B2D6B; Thu, 9 Apr 2015 02:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJOzNCKcwYwE; Thu, 9 Apr 2015 02:58:38 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A67411AD0AA; Thu, 9 Apr 2015 02:58:38 -0700 (PDT) Received: from [81.187.2.149] (port=33612 helo=[192.168.0.18]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Yg9EG-0001bd-UM; Thu, 09 Apr 2015 10:58:35 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> Date: Thu, 9 Apr 2015 10:58:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> References: <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Derek Atkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 09:58:40 -0000 On 8 Apr 2015, at 20:49, Ben Campbell wrote: > On 8 Apr 2015, at 14:38, Derek Atkins wrote: >>=20 >> On Wed, April 8, 2015 2:52 pm, Ben Campbell wrote: >>> On 8 Apr 2015, at 9:42, Derek Atkins wrote: ...snip... >>> For an extreme example, having that sentence in Codec format A and = not >>> format B could lead to implementor decisions on the order of "I = don't >>> want to bother with crypto, so I will choose codec B because it has >>> lighter requirements" might appear to make sense to someone not = steeped >>> in this argument. >>>=20 >>> What I'd _really_ like to do is take the energy in this thread and = apply >>> it to creating a standards-track security document for RTP unicast >>> applications. >>=20 >> Are you willing to hold up this document until that work is done so = it can >> refer to the (yet-to-be-written) protocol security update draft? I'm = fine >> with that approach and I'm willing to review whatever draft you guys >> produce if that's how you'd like to proceed. >=20 > No, I will go with the consensus on this one. I note that several WG = participants objected to the orignally proposed SHOULD. I am pointing = out that this SHOULD is not much different, but I will go with what = people want to do. I think "SHOULD use an appropriate strong security mechanism" is quite = different to "SHOULD use SRTP", since we know of cases where SRTP isn't = suitable. That was my objection to the original text. > OTOH, what I would like to do would fix the problem for this, and all = other codec payload formats, after the fact if we do it right (since it = would apply to the application) >=20 >>=20 >> Or you can hold your nose and live with the "UGGH" of it based on = what the >> WG original created in -08 and move forward for now, knowing that you = can >> (and should) correct it "right" later. >=20 > The work group did not put in a SHOULD. I think this is more of a = question of whether people are willing to hold there collective noses = about the lack of _normative_ privacy guidance for RTP in general, and = if they are willing to let payload formats continue to progress while = that is being worked out. One of the things RFC 7202 tries to convey is that "normative privacy = guidance for RTP in general" is not possible. The privacy requirements, = for example, of broadcast TV are different to those for a phone call, = but both can use RTP.=20 A document giving normative security guidance for unicast SIP-based = telephony using RTP is something we need, I agree. I'm happy to help = reviewing such a thing, but it should be authored by someone more = familiar with the deployed security mechanisms. --=20 Colin Perkins https://csperkins.org/ From nobody Thu Apr 9 03:04:35 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE6F1B2DA8; Thu, 9 Apr 2015 03:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twiwlq6upyO6; Thu, 9 Apr 2015 03:04:30 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BFC11B2DA7; Thu, 9 Apr 2015 03:04:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2181BBECA; Thu, 9 Apr 2015 11:04:29 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azZWJc-XVRzv; Thu, 9 Apr 2015 11:04:28 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7906CBED1; Thu, 9 Apr 2015 11:04:27 +0100 (IST) Message-ID: <55264EAB.6090804@cs.tcd.ie> Date: Thu, 09 Apr 2015 11:04:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Colin Perkins , Ben Campbell References: <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> In-Reply-To: <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 10:04:31 -0000 I do agree with Colin here (and with Ben and Robert) but... On 09/04/15 10:58, Colin Perkins wrote: > A document giving normative security guidance for unicast SIP-based > telephony using RTP is something we need, I agree. I'm happy to help > reviewing such a thing, but it should be authored by someone more > familiar with the deployed security mechanisms. I've just gotten offlist mail from another secdir reviewer who noted that we had exactly the same discussion 7 years ago for another payload document. And I recall it myself more recently. So that unicast SIP/RTP document really would save us all some time and might help those implementing and deploying security stuff in such cases. (And even if folks were not implementing or deploying security stuff for this 7 years ago, I would say that it's much more likely they will be doing that today and in future.) S. From nobody Thu Apr 9 03:11:29 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222BF1B2DC3; Thu, 9 Apr 2015 03:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIn5TJCF2eJ8; Thu, 9 Apr 2015 03:11:23 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79A281B2DC1; Thu, 9 Apr 2015 03:11:23 -0700 (PDT) Received: from [81.187.2.149] (port=39994 helo=[192.168.0.18]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Yg9Qf-00089G-59; Thu, 09 Apr 2015 11:11:21 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <55264EAB.6090804@cs.tcd.ie> Date: Thu, 9 Apr 2015 11:11:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5D09A2DB-8A85-43ED-9EEC-C5CC2867F68A@csperkins.org> References: <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> <55264EAB.609080 4@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 10:11:25 -0000 On 9 Apr 2015, at 11:04, Stephen Farrell = wrote: > I do agree with Colin here (and with Ben and Robert) but... >=20 > On 09/04/15 10:58, Colin Perkins wrote: >> A document giving normative security guidance for unicast SIP-based >> telephony using RTP is something we need, I agree. I'm happy to help >> reviewing such a thing, but it should be authored by someone more >> familiar with the deployed security mechanisms. >=20 > I've just gotten offlist mail from another secdir reviewer who > noted that we had exactly the same discussion 7 years ago for > another payload document. And I recall it myself more recently. We've been around this loop multiple times. That's why we wrote RFCs = 7201 and 7202, to try to stop repeating the same discussion by = explaining the issues and providing guidance. The recommended text for = new RTP payload formats in the rtp-howto was also intended to help = clarify. Clearly something more is needed. If the issue is that RFC7202 = isn't clear, then I'm happy to work with someone to clarify in an = update, but I suspect we need the suggested documents giving normative = requirements for different application classes. > So that unicast SIP/RTP document really would save us all some > time and might help those implementing and deploying security > stuff in such cases. (And even if folks were not implementing > or deploying security stuff for this 7 years ago, I would say > that it's much more likely they will be doing that today and > in future.) Agreed. --=20 Colin Perkins https://csperkins.org/ From nobody Thu Apr 9 03:39:53 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519BC1B332E; Wed, 8 Apr 2015 09:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iy-B_icQeT6D; Wed, 8 Apr 2015 09:01:18 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A6B1B333F; Wed, 8 Apr 2015 08:59:21 -0700 (PDT) Received: from [130.209.247.112] (port=62464 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YfsNq-0006cd-IS; Wed, 08 Apr 2015 16:59:18 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: Colin Perkins X-Priority: 3 (Normal) In-Reply-To: <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> Date: Wed, 8 Apr 2015 16:59:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> To: Derek Atkins X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 03:39:52 -0700 Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 16:01:20 -0000 On 8 Apr 2015, at 15:42, Derek Atkins wrote: > On Wed, April 8, 2015 10:35 am, Colin Perkins wrote: > [snip] >>=20 >> And as I keep saying, I believe that is inappropriate, since it's >> recommending SRTP which is not suitable for many applications. The >> rtp-howto draft suggests the following text: >>=20 > [sniped and added below] >>=20 >> (The two drafts referenced are what became RFCs 7201 and 7202). >>=20 >> If you want to augment that with a "strong security SHOULD/MUST be = used", >> then I certainly don't object. However, a payload format really = shouldn't >> be trying to recommend use of a particular RTP security solution, = such as >> SRTP. >=20 > Okay, so if you want to change the text completely (which I'm fine = with), > how about just adding a single sentence to the end of what you have: >=20 > RTP packets using the payload format defined in this specification > are subject to the security considerations discussed in the RTP > specification RFC3550, and in any applicable RTP profile such as > RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ > SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: > Why RTP Does Not Mandate a Single Media Security Solution" > [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload > formats responsibility to discuss or mandate what solutions are used > to meet the basic security goals like confidentiality, integrity and > source authenticity for RTP in general. This responsibility lays on > anyone using RTP in an application. They can find guidance on > available security mechanisms and important considerations in = Options > for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. > Applications SHOULD implement at least one of the strong security > measures suggested by those references. Sure, that's fine (Magnus might want to update the rtp-howto with that = extra text too). --=20 Colin Perkins https://csperkins.org/ From nobody Thu Apr 9 03:39:55 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685081B3564; Wed, 8 Apr 2015 12:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5YSvfGtpH3Q; Wed, 8 Apr 2015 12:38:19 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F2A1B3554; Wed, 8 Apr 2015 12:38:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 859F6E2036; Wed, 8 Apr 2015 15:38:17 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 11189-08; Wed, 8 Apr 2015 15:38:13 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 0CFA3E2038; Wed, 8 Apr 2015 15:38:13 -0400 (EDT) Received: from 192.168.248.204 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Wed, 8 Apr 2015 15:38:13 -0400 Message-ID: In-Reply-To: References: <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> Date: Wed, 8 Apr 2015 15:38:13 -0400 From: "Derek Atkins" To: "Ben Campbell" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 03:39:52 -0700 Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Derek Atkins , Colin Perkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 19:38:21 -0000 Ben, On Wed, April 8, 2015 2:52 pm, Ben Campbell wrote: > On 8 Apr 2015, at 9:42, Derek Atkins wrote: > >> On Wed, April 8, 2015 10:35 am, Colin Perkins wrote: >> [snip] >>> >>> And as I keep saying, I believe that is inappropriate, since it's >>> recommending SRTP which is not suitable for many applications. The >>> rtp-howto draft suggests the following text: >>> >> [sniped and added below] >>> >>> (The two drafts referenced are what became RFCs 7201 and 7202). >>> >>> If you want to augment that with a "strong security SHOULD/MUST be >>> used", >>> then I certainly don't object. However, a payload format really >>> shouldn't >>> be trying to recommend use of a particular RTP security solution, >>> such as >>> SRTP. >> >> Okay, so if you want to change the text completely (which I'm fine >> with), >> how about just adding a single sentence to the end of what you have: >> >> RTP packets using the payload format defined in this specification >> are subject to the security considerations discussed in the RTP >> specification RFC3550, and in any applicable RTP profile such as >> RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ >> SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: >> Why RTP Does Not Mandate a Single Media Security Solution" >> [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload >> formats responsibility to discuss or mandate what solutions are used >> to meet the basic security goals like confidentiality, integrity and >> source authenticity for RTP in general. This responsibility lays on >> anyone using RTP in an application. They can find guidance on >> available security mechanisms and important considerations in Options >> for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. >> Applications SHOULD implement at least one of the strong security >> measures suggested by those references. > > I'm okay with using the rtp-howto text. But _strictly_as_an_individual_, > I'd prefer not to add the last sentence, for 2 reasons: > > 1) This effectively creates a normative downref to informational RFCs > (7201/7202). That's mainly a process issue, and we can do that if it's > the right thing to do. But... It's technically not a downref because the referred documents are guidance and not protocols. So I don't think there would be any issue. There is already precedent for that. > 2) ... I still don't think a payload format is the right place to put > this sort of thing (that is, the last sentence.) Now, if our plan is to > put that text into all future payload formats, that's not quite as bad. > But unless we plan to revise legacy formats, it still creates confusing > inconsistency between formats. I'll point out, again, that the original draft *already did this*, so you should be talking to the working group about that and not to me. From where I sit, I saw the "MAY encrypt" and said "please change that from MAY to SHOULD." That's where this all started. Now, you could say (possibly even correctly -- I wont make that judgement call) that the WG made a mistake putting that sentence into the Security Considerations at all in the first place, but they did. Clearly the WG decided it was worthwhile to mention that; I'm just suggesting to make the mention stronger than what was there in -08. > For an extreme example, having that sentence in Codec format A and not > format B could lead to implementor decisions on the order of "I don't > want to bother with crypto, so I will choose codec B because it has > lighter requirements" might appear to make sense to someone not steeped > in this argument. > > What I'd _really_ like to do is take the energy in this thread and apply > it to creating a standards-track security document for RTP unicast > applications. Are you willing to hold up this document until that work is done so it can refer to the (yet-to-be-written) protocol security update draft? I'm fine with that approach and I'm willing to review whatever draft you guys produce if that's how you'd like to proceed. Or you can hold your nose and live with the "UGGH" of it based on what the WG original created in -08 and move forward for now, knowing that you can (and should) correct it "right" later. I have no skin in that decision :) -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 9 03:39:56 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96D01B357E; Wed, 8 Apr 2015 12:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Otwp-6Upopz; Wed, 8 Apr 2015 12:49:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4E41B357F; Wed, 8 Apr 2015 12:49:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AAD5EBEE1; Wed, 8 Apr 2015 20:49:21 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N423azQ3jPkN; Wed, 8 Apr 2015 20:49:20 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 71509BEDF; Wed, 8 Apr 2015 20:49:20 +0100 (IST) Message-ID: <5525863D.2050006@cs.tcd.ie> Date: Wed, 08 Apr 2015 20:49:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ben Campbell , Derek Atkins References: <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 03:39:52 -0700 Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 19:49:26 -0000 On 08/04/15 19:52, Ben Campbell wrote: > > What I'd _really_ like to do is take the energy in this thread and apply > it to creating a standards-track security document for RTP unicast > applications. Fully agree that, if it's achievable, that is better. As with Derek, I'm not objecting to this draft handling this either with Derek's latest suggested SHOULD, nor with the original, nor if it ends up tweaked to match other payload specs. S. From nobody Thu Apr 9 03:39:57 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933EE1B363A; Wed, 8 Apr 2015 13:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBjMkZmoziPo; Wed, 8 Apr 2015 13:40:01 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20BFC1B3637; Wed, 8 Apr 2015 13:40:01 -0700 (PDT) Received: by qkgx75 with SMTP id x75so96107323qkg.1; Wed, 08 Apr 2015 13:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=345UK6C4sX8p4KnxC3gaO3pb9/IVaNMsFd1cEKpBnwo=; b=M7/MW9aV9y/9PjeV0rmZwt3dtPRpV5pvzvHgeFAEhW82eafECjJAiNSxAf3qfQfpRG eHWYOF9WZVf1mdIAnGvIait547t9V1GI03kc5DXz94sRMUiHourX+kp/hUuj+dcfV3rL W+uY570iSL1A2ezA8I6FzsknYG389YhGqWVQTxm+CcoO/PYmYl+Q5hjz8bQvJil6E1CZ 4jkfikG4o7ZfbSNWDOiCUa7LmlALv3nifIN4ML1qouBL9OBUAaBaSJUwhiIEfWHfDTTE AwpWqeMbDayEzB+TzbvIOQHnsCcEisq3U9Uc71JWWWGVfueCXTZP0dRI7NMIOTnRh/Gr ahAw== X-Received: by 10.55.15.129 with SMTP id 1mr53946955qkp.29.1428525600460; Wed, 08 Apr 2015 13:40:00 -0700 (PDT) Received: from [172.20.28.228] ([66.228.68.140]) by mx.google.com with ESMTPSA id 28sm8216890qkw.13.2015.04.08.13.39.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Apr 2015 13:39:58 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <5525863D.2050006@cs.tcd.ie> Date: Wed, 8 Apr 2015 16:39:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8F0ACB34-EE96-4348-AC20-EB6727A1EDA7@gmail.com> References: <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> <5525863D.2050006@cs.tcd.ie> To: Stephen Farrell Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 03:39:52 -0700 Cc: "secdir@ietf.org" , "payload@ietf.org" , "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" , Derek Atkins , Colin Perkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 20:40:02 -0000 Sent from my iPhone > On Apr 8, 2015, at 3:49 PM, Stephen Farrell wr= ote: >=20 >=20 >=20 >> On 08/04/15 19:52, Ben Campbell wrote: >>=20 >> What I'd _really_ like to do is take the energy in this thread and apply >> it to creating a standards-track security document for RTP unicast >> applications. >=20 > Fully agree that, if it's achievable, that is better. >=20 > As with Derek, I'm not objecting to this draft handling this > either with Derek's latest suggested SHOULD, nor with the > original, nor if it ends up tweaked to match other payload > specs. >=20 > S. Sorry I've been tied up in meetings. Where are we at with text changes for= this draft versus what's planned in another draft? It would be good to cle= ar my discuss before tomorrow if we can. Thanks, Kathleen=20= From nobody Thu Apr 9 03:39:59 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C7C1B2DC1; Thu, 9 Apr 2015 03:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIw9ZHXQJ6TJ; Thu, 9 Apr 2015 03:10:44 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DF211B2DC0; Thu, 9 Apr 2015 03:10:44 -0700 (PDT) Received: by wgsk9 with SMTP id k9so92327178wgs.3; Thu, 09 Apr 2015 03:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=3Rku2aadSWhpxRV/cF86B0xs8b9/9g9N/cdl9ctw08M=; b=PGsDbUVysk+YvZt4Zqvy9saUKoBNCvPM8P4KLRO/4PT9jVtVRcvXlP7C0Bcmc+zGHT /ptdfhbRKEpuu7HQYDJY3LyCsdDvb4jruN8pvpqmqB+wTkTg6slWuIr/W/lBJ94vvstt 5p9Yp5cOKpVq861n0s5rL7RhT1jnfTKWhi58YUd2PSn+IvyJv815TTQjhJeI40/vgIt3 MrwPtw/egm7UPGABSoSdlCrvhXnnKWNp8fPhLofuN0ZcjnVFna8zm+C/m9D2fQTG88Qk y8NNsz1zzeb5yr1/TcFt4CWzukKFzTkpLhk8Er/B4K9nj4667EZsfpey1r7YJCzLjrdK Pnag== X-Received: by 10.180.208.7 with SMTP id ma7mr4995445wic.0.1428574242808; Thu, 09 Apr 2015 03:10:42 -0700 (PDT) Received: from RoniE (bzq-79-183-196-8.red.bezeqint.net. [79.183.196.8]) by mx.google.com with ESMTPSA id mc20sm14944120wic.15.2015.04.09.03.10.38 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Apr 2015 03:10:42 -0700 (PDT) From: "Roni Even" To: "'Colin Perkins'" , "'Ben Campbell'" References: <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> In-Reply-To: <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> Date: Thu, 9 Apr 2015 13:10:34 +0300 Message-ID: <04a301d072ad$6ee870a0$4cb951e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLAzGR07a+fOctgPDsHC1O01O6N4gJZOkh2ATWEKvgCZomtcAJJ9cXnANMW9o8CPVYOiwH1GcU2AQ39HOQBpEQQdAG8p4kIAkKrjLMBUUHgjQHIXU6gAppERrgBK5MMvQKboLQIAa/Y3NwBfX3BqQKwtyf3Aft3YkEBlH20xgMMyKefAePqaP+aBT9KYA== Content-Language: en-us Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 03:39:52 -0700 Cc: secdir@ietf.org, payload@ietf.org, jspittka@gmail.com, 'Kathleen Moriarty' , iesg@ietf.org, payload-chairs@tools.ietf.org, koenvos74@gmail.com, 'Derek Atkins' Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 10:10:46 -0000 Hi, I support what Colin says about SRTP being a security tool for unicast telephony but other applications including multicast and broadcast that use RTP may use other security mechanism. Defining security for media in a specific application may be done when defining the application like in RTCweb (https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-23 section 4.2) Roni Even > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Colin Perkins > Sent: 09 April, 2015 12:58 PM > To: Ben Campbell > Cc: secdir@ietf.org; payload@ietf.org; jspittka@gmail.com; Kathleen Moriarty; > iesg@ietf.org; payload-chairs@tools.ietf.org; koenvos74@gmail.com; Derek > Atkins > Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 > > On 8 Apr 2015, at 20:49, Ben Campbell wrote: > > On 8 Apr 2015, at 14:38, Derek Atkins wrote: > >> > >> On Wed, April 8, 2015 2:52 pm, Ben Campbell wrote: > >>> On 8 Apr 2015, at 9:42, Derek Atkins wrote: > ...snip... > >>> For an extreme example, having that sentence in Codec format A and > >>> not format B could lead to implementor decisions on the order of "I > >>> don't want to bother with crypto, so I will choose codec B because > >>> it has lighter requirements" might appear to make sense to someone > >>> not steeped in this argument. > >>> > >>> What I'd _really_ like to do is take the energy in this thread and > >>> apply it to creating a standards-track security document for RTP > >>> unicast applications. > >> > >> Are you willing to hold up this document until that work is done so > >> it can refer to the (yet-to-be-written) protocol security update > >> draft? I'm fine with that approach and I'm willing to review > >> whatever draft you guys produce if that's how you'd like to proceed. > > > > No, I will go with the consensus on this one. I note that several WG > participants objected to the orignally proposed SHOULD. I am pointing out that > this SHOULD is not much different, but I will go with what people want to do. > > I think "SHOULD use an appropriate strong security mechanism" is quite > different to "SHOULD use SRTP", since we know of cases where SRTP isn't > suitable. That was my objection to the original text. > > > OTOH, what I would like to do would fix the problem for this, and all > > other codec payload formats, after the fact if we do it right (since > > it would apply to the application) > > > >> > >> Or you can hold your nose and live with the "UGGH" of it based on > >> what the WG original created in -08 and move forward for now, knowing > >> that you can (and should) correct it "right" later. > > > > The work group did not put in a SHOULD. I think this is more of a question of > whether people are willing to hold there collective noses about the lack of > _normative_ privacy guidance for RTP in general, and if they are willing to let > payload formats continue to progress while that is being worked out. > > One of the things RFC 7202 tries to convey is that "normative privacy guidance > for RTP in general" is not possible. The privacy requirements, for example, of > broadcast TV are different to those for a phone call, but both can use RTP. > > A document giving normative security guidance for unicast SIP-based telephony > using RTP is something we need, I agree. I'm happy to help reviewing such a > thing, but it should be authored by someone more familiar with the deployed > security mechanisms. > > > -- > Colin Perkins > https://csperkins.org/ > > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Thu Apr 9 05:41:07 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6461ACEE3; Thu, 9 Apr 2015 05:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SER8A2UpGmH7; Thu, 9 Apr 2015 05:41:02 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32FC31ACCE1; Thu, 9 Apr 2015 05:41:01 -0700 (PDT) Received: by laat2 with SMTP id t2so81351904laa.1; Thu, 09 Apr 2015 05:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vuHSJ8oXA+Bz1pMOXzYseKsELwE16htC4a4r7uG3sX4=; b=UMb8aWhTXJqYgRieSdEdrTMrQUo6j4b8BL5qX/aTd/M2h8/cXQJ3FOFfpppk4UagnR 8UWItjvQgSQQ/RPfoGzvkDwjTWcshpfU7Nc+mQyCwQwROUR9Gn1yl8rmirk6ynmciq3X Rh78oNHa/ddOD89j2Dy8I/a6pdJ7QyhCk6idbQfcxp2/d4mVk57MNuUMwMBZiXxAouRc ydscPv4qHWSBjg0v8c1HFxXlFcLIR0lnkWiSky3htslmO85Dqz+U9Kl0qrcPV7z1qxqo pSRg6RxE26OnTg0CtVhWgQbmKFPXgj2xyhaJEWeq3vpC5PNu6lxroVR1Q/xiK7KJX6QL gWjA== MIME-Version: 1.0 X-Received: by 10.152.23.99 with SMTP id l3mr4480234laf.61.1428583259620; Thu, 09 Apr 2015 05:40:59 -0700 (PDT) Received: by 10.152.129.3 with HTTP; Thu, 9 Apr 2015 05:40:59 -0700 (PDT) In-Reply-To: References: <20150407180105.13228.22557.idtracker@ietfa.amsl.com> <55258BDB.1020707@jmvalin.ca> <552595D3.4030502@jmvalin.ca> Date: Thu, 9 Apr 2015 07:40:59 -0500 Message-ID: From: Spencer Dawkins at IETF To: Barry Leiba Content-Type: multipart/alternative; boundary=089e0158ab6cb8c9c4051349f5a9 Archived-At: Cc: draft-ietf-payload-rtp-opus@ietf.org, draft-ietf-payload-rtp-opus.ad@ietf.org, payload-chairs@ietf.org, payload@ietf.org, Jean-Marc Valin , draft-ietf-payload-rtp-opus.shepherd@ietf.org, The IESG Subject: Re: [payload] Barry Leiba's Yes on draft-ietf-payload-rtp-opus-08: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 12:41:04 -0000 --089e0158ab6cb8c9c4051349f5a9 Content-Type: text/plain; charset=UTF-8 On one minor point ... On Wed, Apr 8, 2015 at 4:34 PM, Barry Leiba wrote: > >> The problem I have is that if I'm new to all this -- say, I have a > >> startup company that's implementing streaming with Opus -- and I see > >> that, I'm going to need to know what to do or where to go to find out. > >> Can you think of a sentence or two to add that will help me, even if > >> it's just to let me know that there's nothing written about it yet? > > > > I would be tempted to simply reword the abstract from > > http://tools.ietf.org/html/draft-ietf-rmcat-app-interaction-01 > > > > "Since UDP does not provide congestion control, applications that use > > RTP over UDP have to implement their own congestion control above the > > UDP layer. [draft-ietf-rmcat-app-interaction-01] describes the > > interactions and conceptual interfaces necessary between the application > > components that relate to congestion control, including the RTP layer, > > the higher-level media codec control layer, and the lower-level > > transport interface, as well as components dedicated to congestion > > control functions." > > > > Would that do? > > That'd give me a place to look for more information; I think that > would help, yes. And I think it's fine for the rmcat document to be > an informative reference. > As best I can tell, RMCAT is doing some fairly heavy lifting on app-interaction (as in, splitting into two documents, one targeting application developers and the other targeting codec developers). I know we can cite work in progress as informative, but this work is still pretty active (the two drafts would be individual drafts, and I don't believe either exists at this moment in time - the working group decided to do this in Dallas, so that's not surprising). Is that going to be OK? Thanks, Spencer --089e0158ab6cb8c9c4051349f5a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On one minor point ...

<= div class=3D"gmail_quote">On Wed, Apr 8, 2015 at 4:34 PM, Barry Leiba <barryleiba@computer.org> wrote:
>> The problem I have= is that if I'm new to all this -- say, I have a
>> startup company that's implementing streaming with Opus -- and= I see
>> that, I'm going to need to know what to do or where to go to f= ind out.
>> Can you think of a sentence or two to add that will help me, even = if
>> it's just to let me know that there's nothing written abou= t it yet?
>
> I would be tempted to simply reword the abstract from
> http://tools.ietf.org/html/draft-ietf-rmcat-app-inte= raction-01
>
> "Since UDP does not provide congestion control, applications that= use
> RTP over UDP have to implement their own congestion control above the<= br> > UDP layer. [draft-ietf-rmcat-app-interaction-01] describes the
> interactions and conceptual interfaces necessary between the applicati= on
> components that relate to congestion control, including the RTP layer,=
> the higher-level media codec control layer, and the lower-level
> transport interface, as well as components dedicated to congestion
> control functions."
>
> Would that do?

That'd give me a place to look for more information; I thin= k that
would help, yes.=C2=A0 And I think it's fine for the rmcat document to = be
an informative reference.

As best I can= tell, RMCAT is doing some fairly heavy lifting on app-interaction (as in, = splitting into two documents, one targeting application developers and the = other targeting codec developers).=C2=A0

I know we= can cite work in progress as informative, but this work is still pretty ac= tive (the two drafts would be individual drafts, and I don't believe ei= ther exists at this moment in time - the working group decided to do this i= n Dallas, so that's not surprising).

Is that g= oing to be OK?

Thanks,

Sp= encer=C2=A0

--089e0158ab6cb8c9c4051349f5a9-- From nobody Thu Apr 9 06:25:04 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE9F1A1A7C; Thu, 9 Apr 2015 06:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ilsbqx_tD3k; Thu, 9 Apr 2015 06:25:01 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA831B2D3E; Thu, 9 Apr 2015 06:24:54 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t39DOWb4087002 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 08:24:43 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Colin Perkins" Date: Thu, 09 Apr 2015 08:24:32 -0500 Message-ID: In-Reply-To: <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> References: <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Derek Atkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 13:25:02 -0000 On 9 Apr 2015, at 4:58, Colin Perkins wrote: > The work group did not put in a SHOULD. I think this is more of a > question of whether people are willing to hold there collective noses > about the lack of _normative_ privacy guidance for RTP in general, and > if they are willing to let payload formats continue to progress while > that is being worked out. > > > One of the things RFC 7202 tries to convey is that "normative privacy > guidance for RTP in general" is not possible. The privacy > requirements, for example, of broadcast TV are different to those for > a phone call, but both can use RTP. > > A document giving normative security guidance for unicast SIP-based > telephony using RTP is something we need, I agree. I'm happy to help > reviewing such a thing, but it should be authored by someone more > familiar with the deployed security mechanisms. Sorry, I mean for unicast. I just dropped the word when typing :-) From nobody Thu Apr 9 06:41:30 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F4F1B2D85; Thu, 9 Apr 2015 06:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7Xqt-BEMwQW; Thu, 9 Apr 2015 06:41:28 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A411B2D80; Thu, 9 Apr 2015 06:41:22 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t39Df1tb088420 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 08:41:11 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Colin Perkins" Date: Thu, 09 Apr 2015 08:41:01 -0500 Message-ID: In-Reply-To: <5D09A2DB-8A85-43ED-9EEC-C5CC2867F68A@csperkins.org> References: <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> <55264EAB.609080 4@cs.tcd.ie> <5D09A2DB-8A85-43ED-9EEC-C5CC2867F68A@csperkins.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Stephen Farrell Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 13:41:30 -0000 On 9 Apr 2015, at 5:11, Colin Perkins wrote: > On 9 Apr 2015, at 11:04, Stephen Farrell > wrote: >> I do agree with Colin here (and with Ben and Robert) but... >> >> On 09/04/15 10:58, Colin Perkins wrote: >>> A document giving normative security guidance for unicast SIP-based >>> telephony using RTP is something we need, I agree. I'm happy to help >>> reviewing such a thing, but it should be authored by someone more >>> familiar with the deployed security mechanisms. >> >> I've just gotten offlist mail from another secdir reviewer who >> noted that we had exactly the same discussion 7 years ago for >> another payload document. And I recall it myself more recently. > > We've been around this loop multiple times. That's why we wrote RFCs > 7201 and 7202, to try to stop repeating the same discussion by > explaining the issues and providing guidance. The recommended text for > new RTP payload formats in the rtp-howto was also intended to help > clarify. Clearly something more is needed. If the issue is that > RFC7202 isn't clear, then I'm happy to work with someone to clarify in > an update, but I suspect we need the suggested documents giving > normative requirements for different application classes. The problem is not that 7202 is not clear. It "clearly" says that the each class of RTP application needs to specify MTI strong security. The problem is that no such specification exists for SIP-based RTP unicast applications. So saying we SHOULD follow 7202 doesn't really help. > >> So that unicast SIP/RTP document really would save us all some >> time and might help those implementing and deploying security >> stuff in such cases. (And even if folks were not implementing >> or deploying security stuff for this 7 years ago, I would say >> that it's much more likely they will be doing that today and >> in future.) > > Agreed. > > -- > Colin Perkins > https://csperkins.org/ From nobody Thu Apr 9 06:45:34 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E191A00F1; Thu, 9 Apr 2015 06:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqQN8z8Iw7Ee; Thu, 9 Apr 2015 06:45:23 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B72C1A01D5; Thu, 9 Apr 2015 06:45:23 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t39Dj5Dh088743 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 08:45:15 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Derek Atkins" Date: Thu, 09 Apr 2015 08:45:05 -0500 Message-ID: In-Reply-To: References: <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 13:45:29 -0000 On 9 Apr 2015, at 8:31, Derek Atkins wrote: > Colin Perkins writes: > >> I think "SHOULD use an appropriate strong security mechanism" is >> quite >> different to "SHOULD use SRTP", since we know of cases where SRTP >> isn't suitable. That was my objection to the original text. > > I'm fine with "SHOULD use an appropriate strong security mechanism", > which is what I tried to convey with my added sentence to the guidance > paragraph. I would be okay with "SHOULD use an appropriate strong security mechanism". I assume the intended difference is the removal of the "as suggested by those references" part. > > -derek > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant From nobody Thu Apr 9 07:08:15 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D631A1B29; Thu, 9 Apr 2015 07:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25Qv1XCpXd1e; Thu, 9 Apr 2015 07:08:10 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7218C1A1B51; Thu, 9 Apr 2015 07:08:10 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t39E7ufX090728 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 09:08:06 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Derek Atkins" Date: Thu, 09 Apr 2015 09:07:55 -0500 Message-ID: In-Reply-To: <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org> References: <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:08:11 -0000 On 9 Apr 2015, at 9:00, Derek Atkins wrote: > Ben, > > On Thu, April 9, 2015 9:45 am, Ben Campbell wrote: >> On 9 Apr 2015, at 8:31, Derek Atkins wrote: >> >>> Colin Perkins writes: >>> >>>> I think "SHOULD use an appropriate strong security mechanism" is >>>> quite >>>> different to "SHOULD use SRTP", since we know of cases where SRTP >>>> isn't suitable. That was my objection to the original text. >>> >>> I'm fine with "SHOULD use an appropriate strong security mechanism", >>> which is what I tried to convey with my added sentence to the >>> guidance >>> paragraph. >> >> I would be okay with "SHOULD use an appropriate strong security >> mechanism". I assume the intended difference is the removal of the >> "as >> suggested by those references" part. > > So you're suggesting (and would be okay with) this text: > > RTP packets using the payload format defined in this specification > are subject to the security considerations discussed in the RTP > specification RFC3550, and in any applicable RTP profile such as > RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ > SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: > Why RTP Does Not Mandate a Single Media Security Solution" > [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload > formats responsibility to discuss or mandate what solutions are used > to meet the basic security goals like confidentiality, integrity and > source authenticity for RTP in general. This responsibility lays on > anyone using RTP in an application. They can find guidance on > available security mechanisms and important considerations in Options > for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. > Applications SHOULD use an appropriate strong security mechanism. > I am okay with that text. > I think I'm okay with this. (I kind of prefer my previous wording, > "Applications SHOULD implement at least one of the strong security > measures suggested by those references" only because it suggests that > multiple mechanisms are okay, whereas this new wording seems to imply > choosing only one). How about "Applications SHOULD use one or more strong security mechanisms, as appropriate"? > > -derek > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant From nobody Thu Apr 9 07:22:14 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36941A6F27; Thu, 9 Apr 2015 07:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5l9LSg56hmI2; Thu, 9 Apr 2015 07:22:12 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16941A212D; Thu, 9 Apr 2015 07:22:11 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t39ELvxb091995 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 09:22:08 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Derek Atkins" Date: Thu, 09 Apr 2015 09:21:57 -0500 Message-ID: <6666FE0B-39E1-4FA5-94C4-72AAEF5CB7C2@nostrum.com> In-Reply-To: References: <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org> MIME-Version: 1.0 X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:22:13 -0000 On 9 Apr 2015, at 9:19, Derek Atkins wrote: > On Thu, April 9, 2015 10:07 am, Ben Campbell wrote: >> On 9 Apr 2015, at 9:00, Derek Atkins wrote: >> >>> Ben, >>> > [snip] >>> So you're suggesting (and would be okay with) this text: >>> >>> RTP packets using the payload format defined in this specification >>> are subject to the security considerations discussed in the RTP >>> specification RFC3550, and in any applicable RTP profile such as >>> RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ >>> SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: >>> Why RTP Does Not Mandate a Single Media Security Solution" >>> [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload >>> formats responsibility to discuss or mandate what solutions are used >>> to meet the basic security goals like confidentiality, integrity and >>> source authenticity for RTP in general. This responsibility lays on >>> anyone using RTP in an application. They can find guidance on >>> available security mechanisms and important considerations in Options >>> for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. >>> Applications SHOULD use an appropriate strong security mechanism. >>> >> >> I am okay with that text. >> >>> I think I'm okay with this. (I kind of prefer my previous wording, >>> "Applications SHOULD implement at least one of the strong security >>> measures suggested by those references" only because it suggests that >>> multiple mechanisms are okay, whereas this new wording seems to imply >>> choosing only one). >> >> How about "Applications SHOULD use one or more strong security >> mechanisms, as appropriate"? > > Clearly now we're just getting down to wordsmithing.. :) Yeah, we should probably let the authors wordsmith their own draft :-) > > How about "Applications SHOULD use one or more appropriate strong security > mechanisms"? (The subclause "as apporpriate" feels to me like it could be > ignored, as in "well, using a strong security mechanism isn't > appropriate"). I think the goal is to make sure that "appropriate" > modifies the "strong security mechanism" and not the "SHOULD use" ;) > > What say you? WFM > > -derek > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant From nobody Thu Apr 9 07:22:34 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD551A6F02; Thu, 9 Apr 2015 07:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NgMCg_XWWBv; Thu, 9 Apr 2015 07:22:19 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACDAF1A6F34; Thu, 9 Apr 2015 07:22:19 -0700 (PDT) Received: by igblo3 with SMTP id lo3so67712686igb.1; Thu, 09 Apr 2015 07:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Lj7Nk3n6NTGwGo3w+27zPhaWcexZho1ypgpg0Pl9YXo=; b=D+6HOMF+OoIPPXZT5qqJY+24tJzMzmr4ykSuRxcsJnHUxPZb463+7RAOWiWYFPD8I9 +AQsJKEColIXlWZb0vPZYXRYzKks+jTFUeDrKKX9E3TDlqxR6uFugGIPvOcyRtolqWpV rN/krL+q7oNBoj8hcLv65Ig84ZVe1apVxXnwLCPcndfU1Ju0iRLQx9mIjotN7vqrnN1f klvB+1itBh7LiMHF+dufdHhZRY+sRebZ05Ldr2GmTgk+AU7eN+vZhhyjYo6ImNPGnhYG eTJ3dnmJFSzmjChzs3RBSVV5k+/nWQZWZUZYT8TA5Nr/f9x9e2VvgAnk/jfnq61L/Gxw S7dQ== MIME-Version: 1.0 X-Received: by 10.50.30.130 with SMTP id s2mr20567255igh.11.1428589339097; Thu, 09 Apr 2015 07:22:19 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.7.130 with HTTP; Thu, 9 Apr 2015 07:22:19 -0700 (PDT) In-Reply-To: References: <20150407180105.13228.22557.idtracker@ietfa.amsl.com> <55258BDB.1020707@jmvalin.ca> <552595D3.4030502@jmvalin.ca> Date: Thu, 9 Apr 2015 10:22:19 -0400 X-Google-Sender-Auth: 2e2qov9QvTFzFRyuZon8alLgxbw Message-ID: From: Barry Leiba To: Spencer Dawkins at IETF Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: draft-ietf-payload-rtp-opus@ietf.org, draft-ietf-payload-rtp-opus.ad@ietf.org, payload-chairs@ietf.org, payload@ietf.org, Jean-Marc Valin , draft-ietf-payload-rtp-opus.shepherd@ietf.org, The IESG Subject: Re: [payload] Barry Leiba's Yes on draft-ietf-payload-rtp-opus-08: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:22:26 -0000 >> >> The problem I have is that if I'm new to all this -- say, I have a >> >> startup company that's implementing streaming with Opus -- and I see >> >> that, I'm going to need to know what to do or where to go to find out. >> >> Can you think of a sentence or two to add that will help me, even if >> >> it's just to let me know that there's nothing written about it yet? >> > >> > I would be tempted to simply reword the abstract from >> > http://tools.ietf.org/html/draft-ietf-rmcat-app-interaction-01 >> > >> > "Since UDP does not provide congestion control, applications that use >> > RTP over UDP have to implement their own congestion control above the >> > UDP layer. [draft-ietf-rmcat-app-interaction-01] describes the >> > interactions and conceptual interfaces necessary between the application >> > components that relate to congestion control, including the RTP layer, >> > the higher-level media codec control layer, and the lower-level >> > transport interface, as well as components dedicated to congestion >> > control functions." >> > >> > Would that do? >> >> That'd give me a place to look for more information; I think that >> would help, yes. And I think it's fine for the rmcat document to be >> an informative reference. > > As best I can tell, RMCAT is doing some fairly heavy lifting on > app-interaction (as in, splitting into two documents, one targeting > application developers and the other targeting codec developers). > > I know we can cite work in progress as informative, but this work is still > pretty active (the two drafts would be individual drafts, and I don't > believe either exists at this moment in time - the working group decided to > do this in Dallas, so that's not surprising). > > Is that going to be OK? I'd be happy even with something that referred to "work being done in the rmcat working group". The point is just not to leave the reader wondering. b From nobody Thu Apr 9 07:26:40 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C001A700D; Thu, 9 Apr 2015 06:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcbbVyXEkczz; Thu, 9 Apr 2015 06:32:47 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CF5D1B2D2F; Thu, 9 Apr 2015 06:31:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id C7CB6E2038; Thu, 9 Apr 2015 09:31:51 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16692-02; Thu, 9 Apr 2015 09:31:46 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 2AE79E2036; Thu, 9 Apr 2015 09:31:46 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t39DViFJ016134; Thu, 9 Apr 2015 09:31:44 -0400 From: Derek Atkins To: Colin Perkins References: <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> Date: Thu, 09 Apr 2015 09:31:43 -0400 In-Reply-To: <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> (Colin Perkins's message of "Thu, 9 Apr 2015 10:58:17 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 07:26:38 -0700 Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Derek Atkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 13:32:49 -0000 Colin Perkins writes: > I think "SHOULD use an appropriate strong security mechanism" is quite > different to "SHOULD use SRTP", since we know of cases where SRTP > isn't suitable. That was my objection to the original text. I'm fine with "SHOULD use an appropriate strong security mechanism", which is what I tried to convey with my added sentence to the guidance paragraph. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 9 07:26:42 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3131B2D83; Thu, 9 Apr 2015 06:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVT5gCgoQ7TD; Thu, 9 Apr 2015 06:33:49 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873B21B2D80; Thu, 9 Apr 2015 06:33:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 48497E203A; Thu, 9 Apr 2015 09:33:01 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16692-03; Thu, 9 Apr 2015 09:32:55 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id C6ECDE2039; Thu, 9 Apr 2015 09:32:55 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t39DWr26016182; Thu, 9 Apr 2015 09:32:53 -0400 From: Derek Atkins To: Kathleen Moriarty References: <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> <5525863D.2050006@cs.tcd.ie> <8F0ACB34-EE96-4348-AC20-EB6727A1EDA7@gmail.com> Date: Thu, 09 Apr 2015 09:32:53 -0400 In-Reply-To: <8F0ACB34-EE96-4348-AC20-EB6727A1EDA7@gmail.com> (Kathleen Moriarty's message of "Wed, 8 Apr 2015 16:39:58 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 07:26:38 -0700 Cc: "secdir@ietf.org" , "payload@ietf.org" , "jspittka@gmail.com" , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" , Derek Atkins , Colin Perkins , Stephen Farrell Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 13:33:50 -0000 Hi, Kathleen Moriarty writes: > Sorry I've been tied up in meetings. Where are we at with text > changes for this draft versus what's planned in another draft? It > would be good to clear my discuss before tomorrow if we can. We have some proposed text (which was a sentence I added to a paragraph that came from the guidance document), but I don't know if we've come to consensus on that suggestion. > Thanks, > Kathleen -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 9 07:26:43 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12661A1B2E; Thu, 9 Apr 2015 07:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QyBfGb0bxqH; Thu, 9 Apr 2015 07:00:33 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF941A1B0B; Thu, 9 Apr 2015 07:00:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id EBAB5E2038; Thu, 9 Apr 2015 10:00:31 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16926-02; Thu, 9 Apr 2015 10:00:29 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 84D63E2039; Thu, 9 Apr 2015 10:00:29 -0400 (EDT) Received: from 192.168.248.204 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 9 Apr 2015 10:00:29 -0400 Message-ID: <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org> In-Reply-To: References: <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> Date: Thu, 9 Apr 2015 10:00:29 -0400 From: "Derek Atkins" To: "Ben Campbell" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 07:26:39 -0700 Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Derek Atkins , Colin Perkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:00:36 -0000 Ben, On Thu, April 9, 2015 9:45 am, Ben Campbell wrote: > On 9 Apr 2015, at 8:31, Derek Atkins wrote: > >> Colin Perkins writes: >> >>> I think "SHOULD use an appropriate strong security mechanism" is >>> quite >>> different to "SHOULD use SRTP", since we know of cases where SRTP >>> isn't suitable. That was my objection to the original text. >> >> I'm fine with "SHOULD use an appropriate strong security mechanism", >> which is what I tried to convey with my added sentence to the guidance >> paragraph. > > I would be okay with "SHOULD use an appropriate strong security > mechanism". I assume the intended difference is the removal of the "as > suggested by those references" part. So you're suggesting (and would be okay with) this text: RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification RFC3550, and in any applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload formats responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity and source authenticity for RTP in general. This responsibility lays on anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in Options for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. Applications SHOULD use an appropriate strong security mechanism. I think I'm okay with this. (I kind of prefer my previous wording, "Applications SHOULD implement at least one of the strong security measures suggested by those references" only because it suggests that multiple mechanisms are okay, whereas this new wording seems to imply choosing only one). -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 9 07:26:45 2015 Return-Path: X-Original-To: expand-draft-ietf-payload-rtp-opus.all@virtual.ietf.org Delivered-To: payload@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A696A1B33D5; Thu, 9 Apr 2015 04:05:52 -0700 (PDT) X-Original-To: xfilter-draft-ietf-payload-rtp-opus.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-payload-rtp-opus.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808121B33B4 for ; Thu, 9 Apr 2015 04:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ3LzBUvYOc3 for ; Thu, 9 Apr 2015 04:05:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920C31B338D for ; Thu, 9 Apr 2015 04:05:51 -0700 (PDT) Received: from p130.piuha.net ([2a00:1d50:2::130]:51251) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YgAHO-00080k-6G for draft-ietf-payload-rtp-opus.all@tools.ietf.org; Thu, 09 Apr 2015 04:05:51 -0700 Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2964E2CC6F; Thu, 9 Apr 2015 14:05:44 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQ-1lRUEJvgE; Thu, 9 Apr 2015 14:05:42 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id E6A432CC5D; Thu, 9 Apr 2015 14:05:42 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Content-Type: multipart/signed; boundary="Apple-Mail=_875957F6-2958-41C5-B2A1-CFE9BEEC29E7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6A2193@ESESSMB209.ericsson.se> Date: Thu, 9 Apr 2015 14:05:41 +0300 Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D696341@ESESSMB209.ericsson.se> <54D5092F.7080803@jmvalin.ca> <7594FB04B1934943A5C02806D1A2204B1D6A2193@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1878.6) X-SA-Exim-Connect-IP: 2a00:1d50:2::130 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-opus.all@tools.ietf.org X-SA-Exim-Mail-From: jari.arkko@piuha.net X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-payload-rtp-opus.all@ietf.org Resent-Message-Id: <20150409110551.920C31B338D@ietfa.amsl.com> Resent-Date: Thu, 9 Apr 2015 04:05:51 -0700 (PDT) Resent-From: jari.arkko@piuha.net Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 07:26:39 -0700 Cc: "gen-art@ietf.org" , "draft-ietf-payload-rtp-opus.all@tools.ietf.org" Subject: Re: [payload] [Gen-art] Gen-ART review of draft-ietf-payload-rtp-opus-07 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 11:05:52 -0000 --Apple-Mail=_875957F6-2958-41C5-B2A1-CFE9BEEC29E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thank you very much for the review, Christer. Jari On 07 Feb 2015, at 09:53, Christer Holmberg = wrote: > Hi, >=20 > Thanks for the reply! I'm fine with your suggestions. I have one more = comment, at the end. >=20 >>> I assume the last sentence should say "...transmitting OF stereo = signals."? >>=20 >> After consulting with two native English speakers, they told me that=20= >> "transmitting stereo signals" was the correct way. Ultimately the RFC = Editor will have the last word on this. >=20 > If native speakers say the current text is correct, I won't argue = against that :) >=20 > Regarding SDP, I think it would be good to have the ABNF syntax for = the a=3Dfmtp parameter (currently you only have descriptive text of the = different parameters). It makes the life for the parser implementers = much easier :) >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_875957F6-2958-41C5-B2A1-CFE9BEEC29E7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVJl0FAAoJEM80gCTQU46qtNMP/jg9WHZpMdqT/IbujTVgfXAa HzM8h/lRX83R6wMLKY3qiYfIc7VqGrmxRghl59rAiP4pTqv1SDmie3/Hot0WcVpn 4iGdHKm0OFbet78JzsEKmjdy2g4iy1Ni7d09GwQQeFbQM6bVyskCagTpGDbBxe8/ N5DUybHVeNKJDBnxkDaXSu81nmjcRmpE9A0hzbhOgEYIo2sURtU57KTgvAIa3cqO 7G+DWjzaNtHgJxSSUE1Dsoo0Kn0RdZ6NVr8ALD6DnOVLQi0gWW6spGT73uoJbkzw EpGy801SHFb3JsQpU4Go/5e8QMwK/Lfn1DMuwx+a2HTsHb6TwDU4iQxdXzrCgeY5 GIv+jWoAXP71p4LqCmf9dD69jCF3dRae8NgdJqCjpOgQGP8tO0dV43Z9zAKPCcUW DwNjXO5iQdGHMQvtHfxSz651TXv2lzH1wSQAdBH+UCpA+kfve4MkDDtPaYuc6Qg1 sUCVbaCN8Hx0MeHFlxs4wGtXn/LC/bT7bOUq54Owcc1JWdOBvtq1ltJ2mYnmg+eA 7tKTgiJFcH762S3ZJ/fE9XP2PF5FkX6g8lSCs/raDxpIg7gl522yPolVTQDDaRYy NJYJ+Wr1IiCb4QqQbIEw/gMPJjq91YVJeMIJU7rQAjL4WRR/kFpjxGS3O0Q6DbMq 02wCYZ/jawIN4n0y1Amr =UJxC -----END PGP SIGNATURE----- --Apple-Mail=_875957F6-2958-41C5-B2A1-CFE9BEEC29E7-- From nobody Thu Apr 9 07:26:46 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646D51A1AE3; Thu, 9 Apr 2015 06:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCqJlBjuqe66; Thu, 9 Apr 2015 06:55:34 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6737D1A1ADB; Thu, 9 Apr 2015 06:55:33 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t39DtGpr089659 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 08:55:26 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Derek Atkins" Date: Thu, 09 Apr 2015 08:55:15 -0500 Message-ID: In-Reply-To: References: <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> <5525863D.2050006@cs.tcd.ie> <8F0ACB34-EE96-4348-AC20-EB6727A1EDA7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 07:26:39 -0700 Cc: "secdir@ietf.org" , "payload@ietf.org" , "jspittka@gmail.com" , Kathleen Moriarty , "iesg@ietf.org" , "payload-chairs@tools.ietf.org" , "koenvos74@gmail.com" , Colin Perkins , Stephen Farrell Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 13:55:35 -0000 I think we have a general agreement for text that talks about how the choice of MTI security depends on the RTP application class. There's an ongoing discussion as to whether that should include something to the effect of "SHOULD implement appropriate protections". I seemed to be the principle nay-sayer as of this morning, and I'm okay with Derek's latest suggestion, so I _think_ people are very close to an agreement on exact language. On 9 Apr 2015, at 8:32, Derek Atkins wrote: > Hi, > > Kathleen Moriarty writes: > >> Sorry I've been tied up in meetings. Where are we at with text >> changes for this draft versus what's planned in another draft? It >> would be good to clear my discuss before tomorrow if we can. > > We have some proposed text (which was a sentence I added to a > paragraph > that came from the guidance document), but I don't know if we've come > to > consensus on that suggestion. > >> Thanks, >> Kathleen > > -derek > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant From nobody Thu Apr 9 07:26:47 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64AC1A6F02; Thu, 9 Apr 2015 07:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhqOe9T9nh37; Thu, 9 Apr 2015 07:19:39 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB7B1A1F00; Thu, 9 Apr 2015 07:19:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 31EB8E2036; Thu, 9 Apr 2015 10:19:38 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 17099-01; Thu, 9 Apr 2015 10:19:35 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id A0B74E2038; Thu, 9 Apr 2015 10:19:35 -0400 (EDT) Received: from 192.168.248.204 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 9 Apr 2015 10:19:35 -0400 Message-ID: In-Reply-To: References: <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org> Date: Thu, 9 Apr 2015 10:19:35 -0400 From: "Derek Atkins" To: "Ben Campbell" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 07:26:39 -0700 Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Derek Atkins , Colin Perkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:19:40 -0000 On Thu, April 9, 2015 10:07 am, Ben Campbell wrote: > On 9 Apr 2015, at 9:00, Derek Atkins wrote: > >> Ben, >> [snip] >> So you're suggesting (and would be okay with) this text: >> >> RTP packets using the payload format defined in this specification >> are subject to the security considerations discussed in the RTP >> specification RFC3550, and in any applicable RTP profile such as >> RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ >> SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: >> Why RTP Does Not Mandate a Single Media Security Solution" >> [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload >> formats responsibility to discuss or mandate what solutions are used >> to meet the basic security goals like confidentiality, integrity and >> source authenticity for RTP in general. This responsibility lays on >> anyone using RTP in an application. They can find guidance on >> available security mechanisms and important considerations in Options >> for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. >> Applications SHOULD use an appropriate strong security mechanism. >> > > I am okay with that text. > >> I think I'm okay with this. (I kind of prefer my previous wording, >> "Applications SHOULD implement at least one of the strong security >> measures suggested by those references" only because it suggests that >> multiple mechanisms are okay, whereas this new wording seems to imply >> choosing only one). > > How about "Applications SHOULD use one or more strong security > mechanisms, as appropriate"? Clearly now we're just getting down to wordsmithing.. :) How about "Applications SHOULD use one or more appropriate strong security mechanisms"? (The subclause "as apporpriate" feels to me like it could be ignored, as in "well, using a strong security mechanism isn't appropriate"). I think the goal is to make sure that "appropriate" modifies the "strong security mechanism" and not the "SHOULD use" ;) What say you? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 9 07:26:49 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EC91A6F27; Thu, 9 Apr 2015 07:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTGLlg7l3ISl; Thu, 9 Apr 2015 07:24:35 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97511A6F1E; Thu, 9 Apr 2015 07:24:34 -0700 (PDT) Received: by labbd9 with SMTP id bd9so79374648lab.2; Thu, 09 Apr 2015 07:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sePa/wHDFIqpRK17xjkk6smoE4LEpfe7lvwy9zaNf1w=; b=HXRHMTIKUQGT5E4Pn5FLuN+iHhhfr6n/b9f/vdjfZjn76UByb3a5aKi/krF6wAIKu/ mfgEnYfJrH5O0VAqEhWEm7SOzyKSUal928Rx4wTXACdKazo9bASfaWqL5HxzHDF8gbH1 +LnguvIXg4WxxK9dd0G/JhFOgMI7kihH2EEqmHwzuUPLQ+8wY+TAX5+rJDL2yG2+nkvT aPRpiiFyAp+LYPAI+vHy/2Xd8IlmFAt0FffznKXrn3cu3mD/6NjMtp5j2NfJqbp8iM34 ZCXyxYi1TuvXhZgC8a5aQGBdIXEd2aq/kegVvRc4dN9wY96GECAVo/bWe1eXHYritT4e ejiQ== MIME-Version: 1.0 X-Received: by 10.152.120.70 with SMTP id la6mr4945472lab.65.1428589473168; Thu, 09 Apr 2015 07:24:33 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Thu, 9 Apr 2015 07:24:32 -0700 (PDT) In-Reply-To: <6666FE0B-39E1-4FA5-94C4-72AAEF5CB7C2@nostrum.com> References: <551EFB9C.4040504@xiph.org> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org> <6666FE0B-39E1-4FA5-94C4-72AAEF5CB7C2@nostrum.com> Date: Thu, 9 Apr 2015 10:24:32 -0400 Message-ID: From: Kathleen Moriarty To: Ben Campbell Content-Type: multipart/alternative; boundary=089e012299d414006d05134b6893 Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 07:26:39 -0700 Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Derek Atkins , Colin Perkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:24:37 -0000 --089e012299d414006d05134b6893 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 9, 2015 at 10:21 AM, Ben Campbell wrote: > On 9 Apr 2015, at 9:19, Derek Atkins wrote: > > > On Thu, April 9, 2015 10:07 am, Ben Campbell wrote: > >> On 9 Apr 2015, at 9:00, Derek Atkins wrote: > >> > >>> Ben, > >>> > > [snip] > >>> So you're suggesting (and would be okay with) this text: > >>> > >>> RTP packets using the payload format defined in this specification > >>> are subject to the security considerations discussed in the RTP > >>> specification RFC3550, and in any applicable RTP profile such as > >>> RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ > >>> SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: > >>> Why RTP Does Not Mandate a Single Media Security Solution" > >>> [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload > >>> formats responsibility to discuss or mandate what solutions are used > >>> to meet the basic security goals like confidentiality, integrity and > >>> source authenticity for RTP in general. This responsibility lays on > >>> anyone using RTP in an application. They can find guidance on > >>> available security mechanisms and important considerations in Options > >>> for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. > >>> Applications SHOULD use an appropriate strong security mechanism. > >>> > >> > >> I am okay with that text. > >> > >>> I think I'm okay with this. (I kind of prefer my previous wording, > >>> "Applications SHOULD implement at least one of the strong security > >>> measures suggested by those references" only because it suggests that > >>> multiple mechanisms are okay, whereas this new wording seems to imply > >>> choosing only one). > >> > >> How about "Applications SHOULD use one or more strong security > >> mechanisms, as appropriate"? > > > > Clearly now we're just getting down to wordsmithing.. :) > > Yeah, we should probably let the authors wordsmith their own draft :-) > > > > > How about "Applications SHOULD use one or more appropriate strong > security > > mechanisms"? (The subclause "as apporpriate" feels to me like it could > be > > ignored, as in "well, using a strong security mechanism isn't > > appropriate"). I think the goal is to make sure that "appropriate" > > modifies the "strong security mechanism" and not the "SHOULD use" ;) > > > > What say you? > > WFM > This text works for me as well. Please let me know once the draft has been updated and thanks for the discussion on this point. Kathleen > > > > > -derek > > > > -- > > Derek Atkins 617-623-3745 > > derek@ihtfp.com www.ihtfp.com > > Computer and Internet Security Consultant > -- Best regards, Kathleen --089e012299d414006d05134b6893 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 9, 2015 at 10:21 AM, Ben Campbell <ben@nostrum.com> wrote:
On 9 Apr 2015, at 9:19, Derek Atkins wrote:

> On Thu, April 9, 2015 10:07 am, Ben Campbell wrote:
>> On 9 Apr 2015, at 9:00, Derek Atkins wrote:
>>
>>> Ben,
>>>
> [snip]
>>> So you're suggesting (and would be okay with) this text: >>>
>>> RTP packets using the payload format defined in this specifica= tion
>>> are subject to the security considerations discussed in the RT= P
>>> specification RFC3550, and in any applicable RTP profile such = as
>>> RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or R= TP/
>>> SAVPF [RFC5124].=C2=A0 However, as "Securing the RTP Prot= ocol Framework:
>>> Why RTP Does Not Mandate a Single Media Security Solution"= ;
>>> [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP p= ayload
>>> formats responsibility to discuss or mandate what solutions ar= e used
>>> to meet the basic security goals like confidentiality, integri= ty and
>>> source authenticity for RTP in general.=C2=A0 This responsibil= ity lays on
>>> anyone using RTP in an application.=C2=A0 They can find guidan= ce on
>>> available security mechanisms and important considerations in = Options
>>> for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-optio= ns].
>>> Applications SHOULD use an appropriate strong security mechani= sm.
>>>
>>
>> I am okay with that text.
>>
>>> I think I'm okay with this.=C2=A0 (I kind of prefer my pre= vious wording,
>>> "Applications SHOULD implement at least one of the strong= security
>>> measures suggested by those references" only because it s= uggests that
>>> multiple mechanisms are okay, whereas this new wording seems t= o imply
>>> choosing only one).
>>
>> How about "Applications SHOULD use one or more strong securit= y
>> mechanisms, as appropriate"?
>
> Clearly now we're just getting down to wordsmithing..=C2=A0 :)

Yeah, we should probably let the authors wordsmith their own dr= aft :-)

>
> How about "Applications SHOULD use one or more appropriate strong= security
> mechanisms"?=C2=A0 (The subclause "as apporpriate" feel= s to me like it could be
> ignored, as in "well, using a strong security mechanism isn't=
> appropriate").=C2=A0 I think the goal is to make sure that "= appropriate"
> modifies the "strong security mechanism" and not the "S= HOULD use"=C2=A0 ;)
>
> What say you?

WFM

This text works for me as we= ll.=C2=A0 Please let me know once the draft has been updated and thanks for= the discussion on this point.

Kathleen=C2=A0

>
> -derek
>
> --
>=C2=A0 =C2=A0 =C2=A0 Derek Atkins=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0617-623-3745
>=C2=A0 =C2=A0 =C2=A0 derek@ihtfp.com= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0www.ihtfp.com
>=C2=A0 =C2=A0 =C2=A0 Computer and Internet Security Consultant



--
=

Best regards,
Kathleen
--089e012299d414006d05134b6893-- From nobody Thu Apr 9 10:56:38 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D111B3029; Thu, 9 Apr 2015 10:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrw35_UorAxh; Thu, 9 Apr 2015 10:56:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD681B302A; Thu, 9 Apr 2015 10:56:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150409175631.12065.2164.idtracker@ietfa.amsl.com> Date: Thu, 09 Apr 2015 10:56:31 -0700 From: IETF Secretariat Archived-At: Subject: [payload] ID Tracker State Update Notice: X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 17:56:36 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ From nobody Thu Apr 9 13:39:25 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01271A1BCF for ; Thu, 9 Apr 2015 07:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2ZfVawKTnuf for ; Thu, 9 Apr 2015 07:27:35 -0700 (PDT) Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79CC11A6FF5 for ; Thu, 9 Apr 2015 07:27:31 -0700 (PDT) Received: by qkgx75 with SMTP id x75so126165560qkg.1 for ; Thu, 09 Apr 2015 07:27:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZpO6J98U3naU/96/r0uWWFgxV3xLrdzN4hQ1HpC0xjU=; b=Cp7a9FHKdLlM334ByISdkH2b+M/L7J/wvWyHF50G+uIsU0mg8I0rECy8KDrZ6Jd8Cu hQdSpCnu/bxj43Ksi8+IiYLNshI154N/LaXNEguypBJnTN/fdKYM8eBvLM4YptmcU9UY 23lW3tDPYzDNet9KdDICSsWFsV089VbsnYuSPg8nVDYj1Nhs0tkkbC6YVayIUqR7ALMw Q+RweADwWHO7E60OGKXpGbpUoebwuaxPh+FVVWb2cThwFxI2UYNToh/iAFzBWb3BJRg8 0Jo3dAVnhE8DVzJaQWv6W8WgLldZQ1dA4IfpCOfvmqFE2GmPImN/KynAP2IgPaytKxc1 VYDg== X-Gm-Message-State: ALoCoQlIvsv+eBr1begi83rzk9ogUfo+g81ff0fVM38/LymoHuhnqaHspzmMUAmPUu0ZlZRuspCB X-Received: by 10.140.239.76 with SMTP id k73mr20854769qhc.66.1428589650705; Thu, 09 Apr 2015 07:27:30 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by mx.google.com with ESMTPSA id 138sm9880801qhx.7.2015.04.09.07.27.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 07:27:29 -0700 (PDT) Message-ID: <55268C4F.6020608@mozilla.com> Date: Thu, 09 Apr 2015 10:27:27 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ben Campbell , Derek Atkins References: <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org> <6666FE0B-39E1-4FA5-94C4-72AAEF5CB7C2@nostrum.com> In-Reply-To: <6666FE0B-39E1-4FA5-94C4-72AAEF5CB7C2@nostrum.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 13:39:21 -0700 Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Colin Perkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:27:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/04/15 10:21 AM, Ben Campbell wrote: >> Clearly now we're just getting down to wordsmithing.. :) > > Yeah, we should probably let the authors wordsmith their own draft > :-) Actually, on that one I'd rather not wordsmith myself. If there's consensus on exact text, I'd rather just put it in as-is. Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVJoxNAAoJEJ6/8sItn9q90aQH/219fCXj07/QN96Msaffe9oG pMRwKtIUPH6BvHZFj8cNNkyT0VF9TsTAXzQ7dRb1DgCPRLiTBnqiUUAeXByb0F7Z 5EVXqLyZM0QXLrnqNjokh6nQJ3YQgOnq9TCq5JmOFWB6BgMSmIjNl6DNu0WH9uqU SmI73lxKV/l+2Hbag2qcf9HsN/Rz3rBtXRswBsYWBJm0bq0mNLchfN2OWJm2KhsM CZxz0h3DCiZm7g5bXRsUeRlwLBr5pw/eTBm7bmVjLOFXwd74hMFG2SBgwqdVkOUs qHgnx1PxPDSVu86T1cxwD0GMLyKGG/6iZbuvEkmGu7SMAnXHqTHcWYcF4i10P0Y= =tJx3 -----END PGP SIGNATURE----- From nobody Thu Apr 9 23:56:27 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2D01AD0C4; Thu, 9 Apr 2015 23:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YAk1tvY2V_e; Thu, 9 Apr 2015 23:56:24 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BF71AD0C1; Thu, 9 Apr 2015 23:56:23 -0700 (PDT) X-AuditID: c1b4fb3a-f79146d0000070a3-ab-5527741584d0 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E1.D1.28835.51477255; Fri, 10 Apr 2015 08:56:22 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.210.2; Fri, 10 Apr 2015 08:56:21 +0200 Message-ID: <55277415.9060309@ericsson.com> Date: Fri, 10 Apr 2015 08:56:21 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Derek Atkins , Ben Campbell References: <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org> In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+Jvja5YiXqowaR7jBbzO0+zW6yctIPd YsaficwWDTvzLS5dPMtk8WHhQxYHNo+ds+6yeyxZ8pPJY/nXBywes3Y+YQlgieKySUnNySxL LdK3S+DKOL/oLFvBU6mKiSvvsDUw3hftYuTkkBAwkVjesZwFwhaTuHBvPVsXIxeHkMBRRokD e68zQTjLGSX+9M5gBKniFdCWWPn1OTOIzSKgKtGw4i4riM0mYCFx80cjG4gtKhAs0fSikR2i XlDi5MwnYBtEBJwk9j/cwwgylFlgCqPElEnzwAYJCwRIXJ1+H6xBSOAqu8S0J3EgNqeAh0TH 2l9gC5gFDCSOLJoDZctLNG+dzQxRry3R0NTBOoFRcBaSfbOQtMxC0rKAkXkVo2hxanFxbrqR kV5qUWZycXF+nl5easkmRmCwH9zy22oH48HnjocYBTgYlXh4H6SphwqxJpYVV+YeYpTmYFES 57UzPhQiJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXHq+VPbPsh7fuHvimcvvKm1y+dU4OXW Z57HJTo/VEysTOcID7x+xtL1vcOW35vy4rdwzj5+JPbm2QUXl4quvhwmoxLpV+njvbPY+2nT Is3D3JpN02IyNly346yy3nh7utDsSevKBL+kTBJYcaB6lvDxmn2Xri4xWPJ3Gc+vtEfV2jbb Iho+bpquxFKckWioxVxUnAgAOcQpblcCAAA= Archived-At: Cc: Kathleen Moriarty , "iesg@ietf.org" , payload@ietf.org, "secdir@ietf.org" Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 06:56:26 -0000 On 2015-04-09 16:19, Derek Atkins wrote: > > On Thu, April 9, 2015 10:07 am, Ben Campbell wrote: >> On 9 Apr 2015, at 9:00, Derek Atkins wrote: >> >>> Ben, >>> > [snip] >>> So you're suggesting (and would be okay with) this text: >>> >>> RTP packets using the payload format defined in this specification >>> are subject to the security considerations discussed in the RTP >>> specification RFC3550, and in any applicable RTP profile such as >>> RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ >>> SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: >>> Why RTP Does Not Mandate a Single Media Security Solution" >>> [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload >>> formats responsibility to discuss or mandate what solutions are used >>> to meet the basic security goals like confidentiality, integrity and >>> source authenticity for RTP in general. This responsibility lays on >>> anyone using RTP in an application. They can find guidance on >>> available security mechanisms and important considerations in Options >>> for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. >>> Applications SHOULD use an appropriate strong security mechanism. >>> >> >> I am okay with that text. >> >>> I think I'm okay with this. (I kind of prefer my previous wording, >>> "Applications SHOULD implement at least one of the strong security >>> measures suggested by those references" only because it suggests that >>> multiple mechanisms are okay, whereas this new wording seems to imply >>> choosing only one). >> >> How about "Applications SHOULD use one or more strong security >> mechanisms, as appropriate"? > > Clearly now we're just getting down to wordsmithing.. :) > > How about "Applications SHOULD use one or more appropriate strong security > mechanisms"? (The subclause "as apporpriate" feels to me like it could be > ignored, as in "well, using a strong security mechanism isn't > appropriate"). I think the goal is to make sure that "appropriate" > modifies the "strong security mechanism" and not the "SHOULD use" ;) > > What say you? Yes, I think that is fine. I don't see this contradicting RFC7202, and are happy to include this in draft-ietf-payload-rtp-howto's template text. I will wait a week before submitting an update version of the HOWTO with this text and updated references. I will send an separate email to the list and IESG to make clear that we are proposing this change. I note that the document is approved by IESG and thus I like to ensure that we still have consensus on this. I hope that other RTP Payload format authors are paying attention to this. The template text is fairly carefully constructed to be clear and not blur the lines of responsibility in this matter. The point of the above paragraph of template is to avoid this type of discussions. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Apr 10 00:13:29 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572D61A00C2; Fri, 10 Apr 2015 00:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f_aFDoYCSKKm; Fri, 10 Apr 2015 00:13:25 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA1E1A00BE; Fri, 10 Apr 2015 00:13:24 -0700 (PDT) X-AuditID: c1b4fb3a-f79146d0000070a3-47-552778130433 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 85.25.28835.31877255; Fri, 10 Apr 2015 09:13:23 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.210.2; Fri, 10 Apr 2015 09:13:22 +0200 Message-ID: <55277811.70905@ericsson.com> Date: Fri, 10 Apr 2015 09:13:21 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "payload@ietf.org" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjluLIzCtJLcpLzFFi42KZGfG3Rle4Qj3UYNckcYsZfyYyW1y6eJbJ gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZ395MZSx4J1mx5v095gbGlyJdjJwcEgImEjteNbNB 2GISF+6tB7K5OIQEjjJKfNr6jRXCWc4oMXUyiMPJwSugKbFq6wKwDhYBVYlnK78zgthsAhYS N380gsVFBYIlml40skPUC0qcnPmEpYuRg0MEqPfRdyGQMLOAhETL52dgI4UFPCWePz8HVsIM VLJ+lz5EibxE89bZzCC2kIC2RENTB+sERv5ZSIbOQuiYhaRjASPzKkbR4tTi4tx0IyO91KLM 5OLi/Dy9vNSSTYzAgDu45bfVDsaDzx0PMQpwMCrx8D5IUw8VYk0sK67MPcQozcGiJM5rZ3wo REggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOj8Omj7Sov9uz8bJwXXPRgT1TrtSTWiKBg9jkb Jqs0zD9cFHPUpzf+SqUqo+mEsLlT+U36cv6VanafUnueyriuiUdHzemvYU0vg6DujKyeiTvV 1MNY15ecf/Y2XFtiVbCf/6EZE9zdv7befC4X13/A/1yFzIfFS2blbTDZfXrii4RJcSf+dq1X YinOSDTUYi4qTgQAMDZskhkCAAA= Archived-At: Cc: IESG Subject: [payload] Update of security template text in draft-ietf-payload-rtp-howto X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 07:13:27 -0000 Payload WG and IESG, Due to the discussion regarding the security considerations in draft-ietf-payload-rtp-opus it has been proposed that a small edit is performed on the security consideration template text that discusses the role of the security considerations for payload formats. "How to Write an RTP Payload Format" (draft-ietf-payload-rtp-howto) is an approved I-D and thus I like to make this consensus call for this change before acting on it. Section A.13: OLD: RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] , and in any applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload formats responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity and source authenticity for RTP in general. This responsibility lays on anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in Options for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. The rest of the this security consideration discusses the security impacting properties of the payload format itself. NEW: RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] , and in any applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] discusses it is not an RTP payload formats responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity and source authenticity for RTP in general. This responsibility lays on anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in Options for Securing RTP Sessions [RFC7201]. Applications SHOULD use one or more appropriate strong security mechanisms. The rest of the this security consideration discusses the security impacting properties of the payload format itself. Change is the new second to last sentence, and updated references. If no objections are heard in 2 weeks time, by the 25th of April 2015, I will submit a new version with this change. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Apr 10 01:40:01 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336761A033A; Fri, 10 Apr 2015 01:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfXiieRnNE-6; Fri, 10 Apr 2015 01:39:58 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27EC1A0354; Fri, 10 Apr 2015 01:39:57 -0700 (PDT) Received: by wgsk9 with SMTP id k9so10652632wgs.3; Fri, 10 Apr 2015 01:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=FF2VETje45nRaZGsb6ahKiOFD4KUVLlHDiMFMu46Xoo=; b=S9ouHHclShekddxdeEmWQooEfVB4B8r4StXV6RjgI3iZ9OYQ4e+xlEvqrzsp0gT1Mp gHnhID9iDh2/anVimtTQGKrob8B8RR2B6QxGYV3VImJmTcf+IWZIqr/o2KKPRk1qOgTJ SNNxxoYoQLFNkdP/GbacXJAGwOhFvzE+o1zjaOYgkJS6IZEJwuQI1inxZfsdCFmYmyGQ SVquDpEY4JIF+fOGQuSQRB7QLLkGwixVluKDfG73MRKSYYeCdVqxTo/Kzz7hiTLE43U5 TrGuQd/h28qVW6JgQCqoYbqIRRn8v6AhgJIP15WxfTYjYbvImzpC6P6h0VNPqQZdzofT 8EVA== X-Received: by 10.180.102.228 with SMTP id fr4mr2886478wib.4.1428655196421; Fri, 10 Apr 2015 01:39:56 -0700 (PDT) Received: from RoniE (bzq-79-179-125-202.red.bezeqint.net. [79.179.125.202]) by mx.google.com with ESMTPSA id it5sm23786769wid.3.2015.04.10.01.39.54 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 10 Apr 2015 01:39:55 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , References: <55277811.70905@ericsson.com> In-Reply-To: <55277811.70905@ericsson.com> Date: Fri, 10 Apr 2015 11:39:49 +0300 Message-ID: <004b01d07369$e9f963a0$bdec2ae0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLJTn5m8zEOLo/nXI6nm7TcqkTanJtUNmHw Content-Language: en-us Archived-At: Cc: 'IESG' Subject: Re: [payload] Update of security template text in draft-ietf-payload-rtp-howto X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 08:40:00 -0000 Hi, I think this change is important and support it as individual. Roni Even > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus > Westerlund > Sent: 10 April, 2015 10:13 AM > To: payload@ietf.org > Cc: IESG > Subject: [payload] Update of security template text in = draft-ietf-payload-rtp- > howto >=20 > Payload WG and IESG, >=20 > Due to the discussion regarding the security considerations in = draft-ietf- > payload-rtp-opus it has been proposed that a small edit is performed = on the > security consideration template text that discusses the role of the = security > considerations for payload formats. >=20 > "How to Write an RTP Payload Format" (draft-ietf-payload-rtp-howto) is = an > approved I-D and thus I like to make this consensus call for this = change before > acting on it. >=20 > Section A.13: >=20 > OLD: >=20 > RTP packets using the payload format defined in this specification > are subject to the security considerations discussed in the RTP > specification [RFC3550] , and in any applicable RTP profile such as > RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ > SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: > Why RTP Does Not Mandate a Single Media Security Solution" > [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP = payload > formats responsibility to discuss or mandate what solutions are = used > to meet the basic security goals like confidentiality, integrity = and > source authenticity for RTP in general. This responsibility lays = on > anyone using RTP in an application. They can find guidance on > available security mechanisms and important considerations in = Options > for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. > The rest of the this security consideration discusses the security > impacting properties of the payload format itself. >=20 >=20 > NEW: >=20 > RTP packets using the payload format defined in this specification > are subject to the security considerations discussed in the RTP > specification [RFC3550] , and in any applicable RTP profile such as > RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ > SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: > Why RTP Does Not Mandate a Single Media Security Solution" = [RFC7202] > discusses it is not an RTP payload formats responsibility to = discuss > or mandate what solutions are used to meet the basic security goals > like confidentiality, integrity and source authenticity for RTP in > general. This responsibility lays on anyone using RTP in an > application. They can find guidance on available security = mechanisms > and important considerations in Options for Securing RTP Sessions > [RFC7201]. Applications SHOULD use one or more appropriate strong > security mechanisms. The rest of the this security consideration > discusses the security impacting properties of the payload format > itself. >=20 > Change is the new second to last sentence, and updated references. >=20 > If no objections are heard in 2 weeks time, by the 25th of April 2015, = I will > submit a new version with this change. >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Fri Apr 10 01:44:43 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAF01A00B5; Fri, 10 Apr 2015 00:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYjxShkM5Tl5; Fri, 10 Apr 2015 00:24:20 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3401A00B7; Fri, 10 Apr 2015 00:24:11 -0700 (PDT) Received: from [81.187.2.149] (port=38464 helo=[192.168.0.18]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YgTIO-0005Sg-LW; Fri, 10 Apr 2015 08:24:09 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <5527732E.60701@ericsson.com> Date: Fri, 10 Apr 2015 08:24:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> <92033c98980490d44f219907a64e6434.squirrel@mail2.ihtfp.org> <5527732E.60701@ ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: X-Mailman-Approved-At: Fri, 10 Apr 2015 01:44:41 -0700 Cc: "secdir@ietf.org" , payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty , "iesg@ietf.org" , payload-chairs@tools.ietf.org, koenvos74@gmail.com, Derek Atkins Subject: Re: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 07:24:22 -0000 On 10 Apr 2015, at 07:52, Magnus Westerlund = wrote: > On 2015-04-09 16:19, Derek Atkins wrote: >>=20 >> On Thu, April 9, 2015 10:07 am, Ben Campbell wrote: >>> On 9 Apr 2015, at 9:00, Derek Atkins wrote: >>>=20 >>>> Ben, >>>>=20 >> [snip] >>>> So you're suggesting (and would be okay with) this text: >>>>=20 >>>> RTP packets using the payload format defined in this specification >>>> are subject to the security considerations discussed in the RTP >>>> specification RFC3550, and in any applicable RTP profile such as >>>> RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ >>>> SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: >>>> Why RTP Does Not Mandate a Single Media Security Solution" >>>> [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP = payload >>>> formats responsibility to discuss or mandate what solutions are = used >>>> to meet the basic security goals like confidentiality, integrity = and >>>> source authenticity for RTP in general. This responsibility lays = on >>>> anyone using RTP in an application. They can find guidance on >>>> available security mechanisms and important considerations in = Options >>>> for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. >>>> Applications SHOULD use an appropriate strong security mechanism. >>>>=20 >>>=20 >>> I am okay with that text. >>>=20 >>>> I think I'm okay with this. (I kind of prefer my previous wording, >>>> "Applications SHOULD implement at least one of the strong security >>>> measures suggested by those references" only because it suggests = that >>>> multiple mechanisms are okay, whereas this new wording seems to = imply >>>> choosing only one). >>>=20 >>> How about "Applications SHOULD use one or more strong security >>> mechanisms, as appropriate"? >>=20 >> Clearly now we're just getting down to wordsmithing.. :) >>=20 >> How about "Applications SHOULD use one or more appropriate strong = security >> mechanisms"? (The subclause "as apporpriate" feels to me like it = could be >> ignored, as in "well, using a strong security mechanism isn't >> appropriate"). I think the goal is to make sure that "appropriate" >> modifies the "strong security mechanism" and not the "SHOULD use" ;) >>=20 >> What say you? >=20 > Yes, I think that is fine. I don't see this contradicting RFC7202, and > are happy to include this in draft-ietf-payload-rtp-howto's template > text. I will wait a week before submitting an update version of the > HOWTO with this text and updated references. I will send an separate > email to the list and IESG to make clear that we are proposing this > change. I note that the document is approved by IESG and thus I like = to > ensure that we still have consensus on this. >=20 > I hope that other RTP Payload format authors are paying attention to > this. The template text is fairly carefully constructed to be clear = and > not blur the lines of responsibility in this matter. The point of the > above paragraph of template is to avoid this type of discussions. +1 no objections --=20 Colin Perkins https://csperkins.org/ From nobody Fri Apr 10 02:11:06 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EBF1ACED1; Fri, 10 Apr 2015 02:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, TVD_FROM_1=0.999, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoXzio4chqgG; Fri, 10 Apr 2015 02:11:01 -0700 (PDT) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5CC1ACEC7; Fri, 10 Apr 2015 02:11:00 -0700 (PDT) Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.9/8.14.9) with ESMTP id t3A9Ar3c034212; Fri, 10 Apr 2015 02:10:53 -0700 (PDT) (envelope-from finlayson@live555.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ross Finlayson In-Reply-To: <55277811.70905@ericsson.com> Date: Fri, 10 Apr 2015 02:10:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55277811.70905@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.2098) Archived-At: Cc: IESG , "payload@ietf.org" Subject: Re: [payload] Update of security template text in draft-ietf-payload-rtp-howto X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 09:11:02 -0000 This looks good. However, fixing some minor nits: > NEW: >=20 > RTP packets using the payload format defined in this specification > are subject to the security considerations discussed in the RTP > specification [RFC3550] , and in any applicable RTP profile such as > RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ > SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: > Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] > discusses it is not an RTP payload formats responsibility to discuss Add a comma after =E2=80=9Cdiscusses=E2=80=99. Also: =E2=80=9Cformats=E2=80= =9D -> =E2=80=9Cformat=E2=80=99s=E2=80=9D > or mandate what solutions are used to meet the basic security goals > like confidentiality, integrity and source authenticity for RTP in > general. This responsibility lays on anyone using RTP in an > application. They can find guidance on available security = mechanisms > and important considerations in Options for Securing RTP Sessions > [RFC7201]. Applications SHOULD use one or more appropriate strong > security mechanisms. The rest of the this security consideration Remove =E2=80=9Cthe=E2=80=9D. Also, perhaps, add =E2=80=9Csection=E2=80=9D= before the following: > discusses the security impacting properties of the payload format > itself. Ross. From nobody Fri Apr 10 04:16:28 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFAA1B2C5A; Fri, 10 Apr 2015 04:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUBiOX25F9yE; Fri, 10 Apr 2015 04:16:26 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9EF41B2C5B; Fri, 10 Apr 2015 04:16:25 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-dd-5527b1076cbd Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6C.63.19337.701B7255; Fri, 10 Apr 2015 13:16:24 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.3.210.2; Fri, 10 Apr 2015 13:16:23 +0200 Message-ID: <5527B105.5000305@ericsson.com> Date: Fri, 10 Apr 2015 13:16:21 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ross Finlayson References: <55277811.70905@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUyM+JvjS7HRvVQg+MnmCymNv5ntZjxZyKz xaWLZ5kcmD2WLPnJ5LF6yR/WAKYoLpuU1JzMstQifbsEroxTq2+wFxzkr7j68xl7A+Mani5G Tg4JAROJ9WvamCFsMYkL99azdTFycQgJHGWUeLH3BROEs5xRYvudf2wgVbwC2hLr3l8As1kE VCU+3H/LCmKzCVhI3PzRCBYXFQiWaHrRyA5RLyhxcuYTli5GDg4RAS2Jq5NqQExmAXuJpT89 QCqEBcIlvrXvZgGxhQRiJI7ebGAEsTmBSqa8e8sCUa4psX6XPkiYWUBeonnrbGaIcm2JhqYO 1gmMgrOQ7JqF0DELSccCRuZVjKLFqcVJuelGxnqpRZnJxcX5eXp5qSWbGIEhe3DLb9UdjJff OB5iFOBgVOLhfZCmHirEmlhWXJl7iFGag0VJnNfO+FCIkEB6YklqdmpqQWpRfFFpTmrxIUYm Dk6pBka7pohjxxQDVidPaZi10lVY9OO2qQolhj/9/33YoDj90dseAfs1guvO/dhxLChD8fw7 k4tSb1m04rlXHL3W6hhab3L+4a9UJ59TXJoClyJq7vj/VdmgnTNf6V16e6CIR4fGcac9DxxU xXWur9y48Y6q9sQTb14kbOqKXOqXl/Rb/qr9zK7eQzxKLMUZiYZazEXFiQBETr8sOgIAAA== Archived-At: Cc: IESG , "payload@ietf.org" Subject: Re: [payload] Update of security template text in draft-ietf-payload-rtp-howto X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 11:16:28 -0000 Thanks, will happily apply this editorial fixes. /Magnus On 2015-04-10 11:10, Ross Finlayson wrote: > This looks good. However, fixing some minor nits: > >> NEW: >> >> RTP packets using the payload format defined in this specification >> are subject to the security considerations discussed in the RTP >> specification [RFC3550] , and in any applicable RTP profile such as >> RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ >> SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: >> Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] >> discusses it is not an RTP payload formats responsibility to discuss > > Add a comma after “discusses’. Also: “formats†-> “format’s†> >> or mandate what solutions are used to meet the basic security goals >> like confidentiality, integrity and source authenticity for RTP in >> general. This responsibility lays on anyone using RTP in an >> application. They can find guidance on available security mechanisms >> and important considerations in Options for Securing RTP Sessions >> [RFC7201]. Applications SHOULD use one or more appropriate strong >> security mechanisms. The rest of the this security consideration > > Remove “theâ€. Also, perhaps, add “section†before the following: > >> discusses the security impacting properties of the payload format >> itself. > > > Ross. > > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Apr 10 05:48:00 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9381B333B; Fri, 10 Apr 2015 05:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qskaxaac8cWO; Fri, 10 Apr 2015 05:47:57 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7B41B33D8; Fri, 10 Apr 2015 05:47:53 -0700 (PDT) Received: by qkhg7 with SMTP id g7so28637917qkh.2; Fri, 10 Apr 2015 05:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RlqortXcF+z0Tx7KyFr8jfojBo2R5k+OWOGFHd2H3Qw=; b=T03jCae2qASVae6hUypIAMg8pqaqMLc+s73mLq9zkQ124FoDralsjpvid6pgcuR6kk Q/BPmlB7J2M8mgb/MN+sqJTSx+3ofEj1If+rpq1J255heWCHE25rRtadJav3AlBM0yRa Etzvvm+eMDafZRd9a+o0Z1JjT7QHgFuQRbyaGsSJDtkK+EJ9o+aN3wRS9kIWTlFXoxUD AOKnqn1NZu22Rb95w988R65BZnSsLH9VP/rnGF1vvYM6r5WbQSusPLV5Wiqi87CI8OK+ vcEwg5Rc0d+dCXUb52fISbQvHeyvj+6NIEQSAL80jdBPCqLOqzuEv8sHdp4FQvJn1GRe e1jg== X-Received: by 10.55.31.90 with SMTP id f87mr2357764qkf.38.1428670072791; Fri, 10 Apr 2015 05:47:52 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id x66sm1527619qha.6.2015.04.10.05.47.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Apr 2015 05:47:51 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <5527B105.5000305@ericsson.com> Date: Fri, 10 Apr 2015 08:47:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <158277FA-817F-4192-9339-3DDA565E2607@gmail.com> References: <55277811.70905@ericsson.com> <5527B105.5000305@ericsson.com> To: Magnus Westerlund Archived-At: Cc: IESG , "payload@ietf.org" Subject: Re: [payload] Update of security template text in draft-ietf-payload-rtp-howto X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 12:47:59 -0000 Thank you, Magnus. I think the new text represents the current considerations well. The recomm= endation to use one or more strong security mechanism works for me. Best regards, Kathleen=20 Sent from my iPhone > On Apr 10, 2015, at 7:16 AM, Magnus Westerlund wrote: >=20 > Thanks, >=20 > will happily apply this editorial fixes. >=20 > /Magnus >=20 >> On 2015-04-10 11:10, Ross Finlayson wrote: >> This looks good. However, fixing some minor nits: >>=20 >>> NEW: >>>=20 >>> RTP packets using the payload format defined in this specification >>> are subject to the security considerations discussed in the RTP >>> specification [RFC3550] , and in any applicable RTP profile such as >>> RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ >>> SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: >>> Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] >>> discusses it is not an RTP payload formats responsibility to discuss >>=20 >> Add a comma after =E2=80=9Cdiscusses=E2=80=99. Also: =E2=80=9Cformats=E2= =80=9D -> =E2=80=9Cformat=E2=80=99s=E2=80=9D >>=20 >>> or mandate what solutions are used to meet the basic security goals >>> like confidentiality, integrity and source authenticity for RTP in >>> general. This responsibility lays on anyone using RTP in an >>> application. They can find guidance on available security mechanisms >>> and important considerations in Options for Securing RTP Sessions >>> [RFC7201]. Applications SHOULD use one or more appropriate strong >>> security mechanisms. The rest of the this security consideration >>=20 >> Remove =E2=80=9Cthe=E2=80=9D. Also, perhaps, add =E2=80=9Csection=E2=80=9D= before the following: >>=20 >>> discusses the security impacting properties of the payload format >>> itself. >>=20 >>=20 >> Ross. >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 From nobody Fri Apr 10 14:53:25 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823201ACCDF; Fri, 10 Apr 2015 14:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-r2WPgRomZ4; Fri, 10 Apr 2015 14:53:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A90F1A8F3B; Fri, 10 Apr 2015 14:53:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150410215320.1386.82868.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 14:53:20 -0700 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-opus-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 21:53:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for the Opus Speech and Audio Codec Authors : Julian Spittka Koen Vos Jean-Marc Valin Filename : draft-ietf-payload-rtp-opus-09.txt Pages : 18 Date : 2015-04-10 Abstract: This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus encoded speech and audio data necessary to integrate the codec in the most compatible way. It also provides an applicability statement for the use of Opus over RTP. Further, it describes media type registrations for the RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-opus-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-opus-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 10 14:53:26 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BED71ACCDF; Fri, 10 Apr 2015 14:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6I9_lVSSIL-L; Fri, 10 Apr 2015 14:53:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 663711A8F3F; Fri, 10 Apr 2015 14:53:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150410215320.1386.97345.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 14:53:20 -0700 Archived-At: Subject: [payload] New Version Notification - draft-ietf-payload-rtp-opus-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 21:53:22 -0000 A new version (-09) has been submitted for draft-ietf-payload-rtp-opus: http://www.ietf.org/internet-drafts/draft-ietf-payload-rtp-opus-09.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-opus-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Fri Apr 10 16:16:06 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F261B2E49; Fri, 10 Apr 2015 16:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIRzxRd_Ho1Q; Fri, 10 Apr 2015 16:16:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD321B2E42; Fri, 10 Apr 2015 16:16:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150410231601.909.23579.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 16:16:01 -0700 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-08.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 23:16:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for High Efficiency Video Coding Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-08.txt Pages : 101 Date : 2015-04-10 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. When multiple RTP streams are used, a single or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-h265-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 10 16:35:46 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3DD1B2EA7 for ; Fri, 10 Apr 2015 16:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2HFhQ8zCgYZ for ; Fri, 10 Apr 2015 16:35:42 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D0161B2E8F for ; Fri, 10 Apr 2015 16:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1428708934; x=1460244934; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6ORsLjNzS2sCfRGbR8EQvbSBRnD857BgwReMSPjyqNk=; b=a0MTslTAFdvwB79ujAvF3A0Bm4jYRW2KjisKovMhtiSlKyg4vEO/nWFD kOA8FDa9IWiquJhJGDi1cmzdIyZf50t8djrVH89R3BkK14n9+BsFAmhU9 JnySKUqyPH6INLHnfnVjQADu6gVovj8s9kccrN3tpnQWuMGn8iXuiwdhD g=; X-IronPort-AV: E=McAfee;i="5700,7163,7767"; a="86728320" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2015 16:35:23 -0700 X-IronPort-AV: E=Sophos;i="5.11,559,1422950400"; d="scan'208";a="892242526" Received: from nasanexm01b.na.qualcomm.com ([10.85.0.82]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Apr 2015 16:35:23 -0700 Received: from NASANEXM01H.na.qualcomm.com (10.85.0.34) by NASANEXM01B.na.qualcomm.com (10.85.0.82) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 10 Apr 2015 16:35:23 -0700 Received: from NASANEXM01H.na.qualcomm.com ([10.85.0.34]) by NASANEXM01H.na.qualcomm.com ([10.85.0.34]) with mapi id 15.00.1044.021; Fri, 10 Apr 2015 16:35:23 -0700 From: "Wang, Ye-Kui" To: "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-h265-08.txt Thread-Index: AQHQc+RjceP5zldIe0mPqRLfsaLVl51G49ww Date: Fri, 10 Apr 2015 23:35:22 +0000 Message-ID: References: <20150410231601.909.23579.idtracker@ietfa.amsl.com> In-Reply-To: <20150410231601.909.23579.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.80.80.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-08.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 23:35:45 -0000 This version ONLY includes a technical change that was proposed by Mo Zanat= y and Stephan Wenger, to enable de-packetization of multiple received RTP s= treams based on NTP timestamps instead of on decoding order numbers. The pr= oponents and the authors (with Stephan being both) discussed and worked out= the text changes together, targeting enabling the feature with minimal tex= t changes. Please review and let us know if you have any comments on these changes. Next, we will make all the editorial changes agreed earlier on the reflecto= r in discussing Richard Barnes' AD review, as soon as possible. BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Friday, April 10, 2015 4:16 PM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP Payload Format for High Efficiency Video Codi= ng Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-08.txt Pages : 101 Date : 2015-04-10 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. When multiple RTP streams are used, a single or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-h265-08 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Fri Apr 10 20:25:19 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F0D1B2EAB; Fri, 10 Apr 2015 20:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BF_Sap4iD_Xk; Fri, 10 Apr 2015 20:25:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FABA1A912F; Fri, 10 Apr 2015 20:25:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150411032516.30773.38067.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 20:25:16 -0700 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-opus-10.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 03:25:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for the Opus Speech and Audio Codec Authors : Julian Spittka Koen Vos Jean-Marc Valin Filename : draft-ietf-payload-rtp-opus-10.txt Pages : 18 Date : 2015-04-10 Abstract: This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus encoded speech and audio data necessary to integrate the codec in the most compatible way. It also provides an applicability statement for the use of Opus over RTP. Further, it describes media type registrations for the RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-opus-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-opus-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 10 20:25:26 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D621A9134; Fri, 10 Apr 2015 20:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OrAovQ1UOl8; Fri, 10 Apr 2015 20:25:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E3A1A9168; Fri, 10 Apr 2015 20:25:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150411032516.30773.13626.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 20:25:16 -0700 Archived-At: Subject: [payload] New Version Notification - draft-ietf-payload-rtp-opus-10.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 03:25:19 -0000 A new version (-10) has been submitted for draft-ietf-payload-rtp-opus: http://www.ietf.org/internet-drafts/draft-ietf-payload-rtp-opus-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-opus-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Sat Apr 11 09:03:22 2015 Return-Path: X-Original-To: expand-draft-ietf-payload-rtp-opus.all@virtual.ietf.org Delivered-To: payload@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 334F51AD289; Sat, 11 Apr 2015 06:23:15 -0700 (PDT) X-Original-To: xfilter-draft-ietf-payload-rtp-opus.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-payload-rtp-opus.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A901AD272 for ; Sat, 11 Apr 2015 06:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.634 X-Spam-Level: X-Spam-Status: No, score=-0.634 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKdN1g-3eXvp for ; Sat, 11 Apr 2015 06:23:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 047B11AD17F for ; Sat, 11 Apr 2015 06:23:13 -0700 (PDT) Received: from sesbmg23.ericsson.net ([193.180.251.37]:46731) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YgvNQ-0002l5-0S for draft-ietf-payload-rtp-opus.all@tools.ietf.org; Sat, 11 Apr 2015 06:23:12 -0700 X-AuditID: c1b4fb25-f79126d000004b89-ee-5529203c828e Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id DD.1F.19337.C3029255; Sat, 11 Apr 2015 15:23:08 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0210.002; Sat, 11 Apr 2015 15:23:07 +0200 From: Christer Holmberg To: "gen-art@ietf.org" Thread-Topic: Gen-ART review of draft-ietf-payload-rtp-opus-08 Thread-Index: AdB0YZrD1UZTCkzGSwKoMQ0d3L+1AA== Date: Sat, 11 Apr 2015 13:23:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D7939BB@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D7939BBESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvja6NgmaowddH4hZbtu9lsrj66jOL A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJWxYdF1poKb5hVTNi9gamB8btDFyMEhIWAi 0btatouRE8gUk7hwbz1bFyMXh5DAUUaJczuvsIAkhASWMEos3WQHUs8mYCHR/U8bJCwioCkx d8VbJpAws0C6xLlOKZCwsIClxKRtLSwQJXYS1+bcZYew9SSWNLYwgdgsAqoSqw79AKvhFfCV eLqnHSzOCHTC91NrwGxmAXGJW0/mM0GcJiCxZM95ZghbVOLl43+sELaSxIrtlxgh6vMl3p9a ywYxU1Di5MwnLBMYhWchGTULSdksJGUQcR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FaNo cWpxUm66kbFealFmcnFxfp5eXmrJJkZg5Bzc8lt1B+PlN46HGAU4GJV4eBUaNEKFWBPLiitz DzFKc7AoifPaGR8KERJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCYnB8hMSu8++X96LK1JclC i9OL1j+a1nd+98Ucnlse2uZyoYWh2kIzOYL/rzrZKxC34G9/MXdq4bQXl1lXMr0Wkn92V37N KrfPexYtuMTGcahZ9961YsZ7v6J3yuo1yZnkLbvreaFVrqrALulnWunlc0WztN/uSZrZoZKS ++BXDt+uk/Z7dgspsRRnJBpqMRcVJwIA7w26t30CAAA= X-SA-Exim-Connect-IP: 193.180.251.37 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-opus.all@tools.ietf.org X-SA-Exim-Mail-From: christer.holmberg@ericsson.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-payload-rtp-opus.all@ietf.org Resent-Message-Id: <20150411132313.047B11AD17F@ietfa.amsl.com> Resent-Date: Sat, 11 Apr 2015 06:23:13 -0700 (PDT) Resent-From: christer.holmberg@ericsson.com Archived-At: Archived-At: X-Mailman-Approved-At: Sat, 11 Apr 2015 09:03:20 -0700 Cc: "draft-ietf-payload-rtp-opus.all@tools.ietf.org" Subject: [payload] Gen-ART review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 13:23:15 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D7939BBESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at Document: draft-ietf-payload-rtp-opus-08 Reviewer: Christer Holmberg Review Date: 11 April 2015 IETF LC End Date: 17 February 2015 IETF Telechat Date: 9 April 2015 Summary: Most of the comments I gave on a previous version of the do= cument have been addressed. However, it seems like one of the comments have= not been addressed. Major Issues: None Minor Issues: I previously gave the following comment: "Regarding SDP, I think it would be good to have the ABNF syntax for the a= =3Dfmtp parameter (currently you only have descriptive text of the differen= t parameters). It makes the life for the parser implementers much easier :)= " I guess one, by reading section 7 and the examples, can figure out how to e= ncode the a=3Dfmtp parameter, but I think it would to explicitly define the= syntax. Editorial nits: None --_000_7594FB04B1934943A5C02806D1A2204B1D7939BBESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am the assigned Gen-ART revie= wer for this draft. For background on Gen-ART, please see the FAQ at <http://wi= ki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

 

Document:   &nbs= p;            &= nbsp;        draft-ietf-payload-rtp-opus= -08

 

Reviewer:   &nbs= p;             =           Christer Holmbe= rg

 

Review Date:   &= nbsp;           &nbs= p;     11 April 2015

 

IETF LC End Date:  &n= bsp;          17 February 2015=

 

IETF Telechat Date:  =        9 April 2015

 

Summary:    &nbs= p;   Most of the comments I gave on a previous version of the doc= ument have been addressed. However, it seems like one of the comments have = not been addressed.

 

Major Issues: None

 

Minor Issues: I previously gave= the following comment:

 

“Regarding SDP= , I think it would be good to have the ABNF syntax for the a=3Dfmtp paramet= er (currently you only have descriptive text of the different parameters). = It makes the life for the parser implementers much easier :)”

 

I guess one, by reading section= 7 and the examples, can figure out how to encode the a=3Dfmtp parameter, b= ut I think it would to explicitly define the syntax.

 

 

Editorial nits: None=

 

--_000_7594FB04B1934943A5C02806D1A2204B1D7939BBESESSMB209erics_-- From nobody Tue Apr 14 05:01:25 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0CA1A8ACA; Tue, 14 Apr 2015 05:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlB7ASWS9ctr; Tue, 14 Apr 2015 05:01:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D701A8AF4; Tue, 14 Apr 2015 05:01:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150414120122.6747.36436.idtracker@ietfa.amsl.com> Date: Tue, 14 Apr 2015 05:01:22 -0700 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 12:01:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for High Efficiency Video Coding Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-09.txt Pages : 100 Date : 2015-04-14 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. When multiple RTP streams are used, a single or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-h265-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 14 05:06:35 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6616C1A8F3C for ; Tue, 14 Apr 2015 05:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFaH7M-2E0Tv for ; Tue, 14 Apr 2015 05:06:31 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D1831A8F35 for ; Tue, 14 Apr 2015 05:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1429013191; x=1460549191; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=2/YrNnVu58ET1ThUfn4KWpkLAgtyOBggm23WluEhc18=; b=udtJS0y5rdNkhRtJUD2OvUzWuA2dnrBIGBYu7DTYCzoiM+gI+s+AuQ2F IaYdATWoHnTM7cAXnaqLpldCoTXvyP1vj9RhQ+/rk97Ov2KerXRubQjw1 LqB2dr8kbJ3luAsTPRKtdvxCEjgcOKoL3IwLERxOLZn2rA/3IbaKu+OjO Q=; X-IronPort-AV: E=McAfee;i="5700,7163,7770"; a="205486832" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Apr 2015 05:06:30 -0700 X-IronPort-AV: E=Sophos;i="5.11,576,1422950400"; d="scan'208";a="894459256" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Apr 2015 05:06:30 -0700 Received: from NASANEXM01H.na.qualcomm.com (10.85.0.34) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 14 Apr 2015 05:06:29 -0700 Received: from NASANEXM01H.na.qualcomm.com ([10.85.0.34]) by NASANEXM01H.na.qualcomm.com ([10.85.0.34]) with mapi id 15.00.1044.021; Tue, 14 Apr 2015 05:06:29 -0700 From: "Wang, Ye-Kui" To: "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-h265-09.txt Thread-Index: AQHQdqq9Ch2zX9i3yUG7sQISt+81+51MaH6Q Date: Tue, 14 Apr 2015 12:06:29 +0000 Message-ID: <3fea0b00e6664e13a4910a9b2df678e2@NASANEXM01H.na.qualcomm.com> References: <20150414120122.6747.36436.idtracker@ietfa.amsl.com> In-Reply-To: <20150414120122.6747.36436.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.106.115.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 12:06:34 -0000 This version includes all the editorial changes agreed earlier on the refle= ctor when discussing Richard Barnes' AD review. We should have addressed all comments received recently. Unless there are c= omments to the changes made to -08 (submitted last Friday) and -09, the dra= ft should be sent to the publication process. BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Tuesday, April 14, 2015 5:01 AM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-09.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP Payload Format for High Efficiency Video Codi= ng Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-09.txt Pages : 100 Date : 2015-04-14 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. When multiple RTP streams are used, a single or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-h265-09 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Tue Apr 14 18:22:24 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888A51B2B17; Tue, 14 Apr 2015 18:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lc8rCxUoqu7n; Tue, 14 Apr 2015 18:22:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 872451B2B0D; Tue, 14 Apr 2015 18:22:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150415012216.29872.58959.idtracker@ietfa.amsl.com> Date: Tue, 14 Apr 2015 18:22:16 -0700 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-opus-11.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 01:22:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for the Opus Speech and Audio Codec Authors : Julian Spittka Koen Vos Jean-Marc Valin Filename : draft-ietf-payload-rtp-opus-11.txt Pages : 18 Date : 2015-04-14 Abstract: This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus encoded speech and audio data necessary to integrate the codec in the most compatible way. It also provides an applicability statement for the use of Opus over RTP. Further, it describes media type registrations for the RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-opus-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-opus-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 14 18:22:28 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F1B1B2B17; Tue, 14 Apr 2015 18:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuAh8qdPQvjD; Tue, 14 Apr 2015 18:22:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0D01B2B10; Tue, 14 Apr 2015 18:22:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150415012216.29872.89344.idtracker@ietfa.amsl.com> Date: Tue, 14 Apr 2015 18:22:16 -0700 Archived-At: Subject: [payload] New Version Notification - draft-ietf-payload-rtp-opus-11.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 01:22:24 -0000 A new version (-11) has been submitted for draft-ietf-payload-rtp-opus: http://www.ietf.org/internet-drafts/draft-ietf-payload-rtp-opus-11.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-opus-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Wed Apr 15 03:54:17 2015 Return-Path: X-Original-To: expand-draft-ietf-payload-rtp-opus.all@virtual.ietf.org Delivered-To: payload@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7C69E1B3025; Tue, 14 Apr 2015 15:42:20 -0700 (PDT) X-Original-To: xfilter-draft-ietf-payload-rtp-opus.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-payload-rtp-opus.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612621B3022 for ; Tue, 14 Apr 2015 15:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2wHFgL92S93 for ; Tue, 14 Apr 2015 15:42:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57D91B3023 for ; Tue, 14 Apr 2015 15:42:19 -0700 (PDT) Received: from raven-v6.nostrum.com ([2001:470:d:1130::1]:27027 helo=nostrum.com) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yi9X9-0000jI-6N for draft-ietf-payload-rtp-opus.all@tools.ietf.org; Tue, 14 Apr 2015 15:42:19 -0700 Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3EMg4TN088095 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2015 17:42:14 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Christer Holmberg" Date: Tue, 14 Apr 2015 17:42:04 -0500 Message-ID: <14C2C001-48AE-4142-8E64-2D066EFC380A@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D7939BB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D7939BB@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) X-Helo-Check-Failed: Verification failed for HELO nostrum.com X-SA-Exim-Connect-IP: 2001:470:d:1130::1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-opus.all@tools.ietf.org X-SA-Exim-Mail-From: ben@nostrum.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-payload-rtp-opus.all@ietf.org Resent-Message-Id: <20150414224219.B57D91B3023@ietfa.amsl.com> Resent-Date: Tue, 14 Apr 2015 15:42:19 -0700 (PDT) Resent-From: ben@nostrum.com Archived-At: Archived-At: X-Mailman-Approved-At: Wed, 15 Apr 2015 03:54:17 -0700 Cc: "gen-art@ietf.org" , "draft-ietf-payload-rtp-opus.all@tools.ietf.org" Subject: Re: [payload] [Gen-art] Gen-ART review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 22:42:20 -0000 On 11 Apr 2015, at 8:23, Christer Holmberg wrote: > Minor Issues: I previously gave the following comment: >   > “Regarding SDP, I think it would be good to have the ABNF syntax for > the a=fmtp parameter (currently you only have descriptive text of the > different parameters). It makes the life for the parser implementers > much easier :)†>   > I guess one, by reading section 7 and the examples, can figure out how > to encode the a=fmtp parameter, but I think it would to explicitly > define the syntax. Hi Christer, (For the record, I just recently took over responsibility for PAYLOAD, so if I'm misinterpreting things, someone please tell me :-) ) While I can see that as a "might be nice" addition, I don't think it's something that we have required of other payload drafts. draft-ietf-payload-rtp (in RFC ed queue) says the following about ABNF for SDP parameters: "Not that commonly used in RTP payload formats but may be useful when defining Media Type parameters of some complexity." If I'm reading correctly, the FMTP parameters in this draft fit the pretty common "semicolon delimited list of parameter=value pairs", so I don't think this rises to the level of "some complexity". So unless you think the parameters in this draft are more complex than average, I don't think we need to add them at this late stage. It might be worth discussing whether we should ask authors of future payload drafts to include ABNF for this sort of thing. Thanks! Ben. From nobody Wed Apr 15 03:54:19 2015 Return-Path: X-Original-To: expand-draft-ietf-payload-rtp-opus.all@virtual.ietf.org Delivered-To: payload@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9BE721B33E5; Wed, 15 Apr 2015 02:38:51 -0700 (PDT) X-Original-To: xfilter-draft-ietf-payload-rtp-opus.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-payload-rtp-opus.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807371B33E1 for ; Wed, 15 Apr 2015 02:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWlaUyjlNZJu for ; Wed, 15 Apr 2015 02:38:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09E91B33DA for ; Wed, 15 Apr 2015 02:38:49 -0700 (PDT) Received: from sesbmg22.ericsson.net ([193.180.251.48]:61904) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YiJmS-00015i-Lx for draft-ietf-payload-rtp-opus.all@tools.ietf.org; Wed, 15 Apr 2015 02:38:49 -0700 X-AuditID: c1b4fb30-f79996d000006ebb-76-552e31a4c99e Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 9D.07.28347.4A13E255; Wed, 15 Apr 2015 11:38:44 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0210.002; Wed, 15 Apr 2015 11:38:44 +0200 From: Christer Holmberg To: Ben Campbell Thread-Topic: [Gen-art] Gen-ART review of draft-ietf-payload-rtp-opus-08 Thread-Index: AdB0YZrD1UZTCkzGSwKoMQ0d3L+1AACkdxEAABiprTA= Date: Wed, 15 Apr 2015 09:38:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D79A1AA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D7939BB@ESESSMB209.ericsson.se> <14C2C001-48AE-4142-8E64-2D066EFC380A@nostrum.com> In-Reply-To: <14C2C001-48AE-4142-8E64-2D066EFC380A@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+Jvje4SQ71Qg5YuE4v5nafZLbZs38tk cfXVZxYHZo8lS34yecza+YTF48vlz2wBzFFcNimpOZllqUX6dglcGR/uXWAt+CBYMW/JaZYG xi2CXYwcHBICJhLb1vB1MXICmWISF+6tZ+ti5OIQEjjKKLGvvYsNJCEksIRR4sF/I5B6NgEL ie5/2iBhEQEliefNW1lA6pkFJjBKND9byQqSEBZwl5j6dQI7RJGHxJL2VcwQtpXE4fbtYDNZ BFQl2g4sYwKxeQV8Jbq2zWKF2NXEKPFogy6IzSlgL3Fs5xlGEJsR6Ljvp9aA1TMLiEvcejKf CeJoAYkle84zQ9iiEi8f/2OF+EtRYnm/HIjJLKApsX6XPkSnosSU7ofsEFsFJU7OfMIygVFs FpKhsxA6ZiHpmIWkYwEjyypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwFg6uOW3wQ7Gl88d DzEKcDAq8fAqHNMNFWJNLCuuzD3EKM3BoiTOa2d8KERIID2xJDU7NbUgtSi+qDQntfgQIxMH p1QDI8+53JAn6vu/TDx43OXVgWyFbkvDNJtPou9mzbl2d5O95POED7mGrK5LC5IK/j28PF1z sqH2d8ek0Edn19SvXSlYPdFp8x07aZ85jLIxGx+c23C/4vu210uaXU67Jb0UXHj9kJ/81uJO bu8okamM3Hv/O+T9Oz93lab9PcPIy6FrZssV5a3KW6HEUpyRaKjFXFScCAA21zxDhgIAAA== X-SA-Exim-Connect-IP: 193.180.251.48 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-opus.all@tools.ietf.org X-SA-Exim-Mail-From: christer.holmberg@ericsson.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-payload-rtp-opus.all@ietf.org Resent-Message-Id: <20150415093849.E09E91B33DA@ietfa.amsl.com> Resent-Date: Wed, 15 Apr 2015 02:38:49 -0700 (PDT) Resent-From: christer.holmberg@ericsson.com Archived-At: Archived-At: X-Mailman-Approved-At: Wed, 15 Apr 2015 03:54:17 -0700 Cc: "gen-art@ietf.org" , "draft-ietf-payload-rtp-opus.all@tools.ietf.org" Subject: Re: [payload] [Gen-art] Gen-ART review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 09:38:51 -0000 SGksDQoNCj4+IE1pbm9yIElzc3VlczogSSBwcmV2aW91c2x5IGdhdmUgdGhlIGZvbGxvd2luZyBj b21tZW50Og0KPj4gwqANCj4+IOKAnFJlZ2FyZGluZyBTRFAsIEkgdGhpbmsgaXQgd291bGQgYmUg Z29vZCB0byBoYXZlIHRoZSBBQk5GIHN5bnRheCBmb3IgDQo+PiB0aGUgYT1mbXRwIHBhcmFtZXRl ciAoY3VycmVudGx5IHlvdSBvbmx5IGhhdmUgZGVzY3JpcHRpdmUgdGV4dCBvZiB0aGUgDQo+PiBk aWZmZXJlbnQgcGFyYW1ldGVycykuIEl0IG1ha2VzIHRoZSBsaWZlIGZvciB0aGUgcGFyc2VyIGlt cGxlbWVudGVycyANCj4+IG11Y2ggZWFzaWVyIDop4oCdDQo+PiDCoA0KPj4gSSBndWVzcyBvbmUs IGJ5IHJlYWRpbmcgc2VjdGlvbiA3IGFuZCB0aGUgZXhhbXBsZXMsIGNhbiBmaWd1cmUgb3V0IGhv dyANCj4+IHRvIGVuY29kZSB0aGUgYT1mbXRwIHBhcmFtZXRlciwgYnV0IEkgdGhpbmsgaXQgd291 bGQgdG8gZXhwbGljaXRseSANCj4+IGRlZmluZSB0aGUgc3ludGF4Lg0KPg0KPiAoRm9yIHRoZSBy ZWNvcmQsIEkganVzdCByZWNlbnRseSB0b29rIG92ZXIgcmVzcG9uc2liaWxpdHkgZm9yIFBBWUxP QUQsIHNvIGlmIEknbSBtaXNpbnRlcnByZXRpbmcgdGhpbmdzLCBzb21lb25lIHBsZWFzZSB0ZWxs IG1lIDotKSAgKQ0KPg0KPiBXaGlsZSBJIGNhbiBzZWUgdGhhdCBhcyBhICJtaWdodCBiZSBuaWNl IiBhZGRpdGlvbiwgSSBkb24ndCB0aGluayBpdCdzIHNvbWV0aGluZyB0aGF0IHdlIGhhdmUgcmVx dWlyZWQgb2Ygb3RoZXIgcGF5bG9hZCBkcmFmdHMuIA0KDQpBZnRlciBhbGwgbXkgeWVhcnMgb2Yg dGFraW5nIGRyYWZ0cyB0aHJvdWdoIHRoZSBJRVRGIHB1YmxpY2F0aW9uIHByb2Nlc3MsIEkgaGF2 ZSBsZWFybmVkIHRoYXQgdGhlcmUgaXMgbm8gc3VjaCB0aGluZyBhcyBjb25zaXN0ZW5jeSA6KQ0K DQo+IGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAgKGluIFJGQyBlZCBxdWV1ZSkgc2F5cyB0aGUgZm9s bG93aW5nIGFib3V0IEFCTkYgZm9yIFNEUCBwYXJhbWV0ZXJzOg0KPg0KPiAiTm90IHRoYXQgY29t bW9ubHkgdXNlZCBpbiBSVFAgcGF5bG9hZCBmb3JtYXRzIGJ1dCBtYXkgYmUgdXNlZnVsIHdoZW4g ZGVmaW5pbmcgTWVkaWEgVHlwZSBwYXJhbWV0ZXJzIG9mIHNvbWUgY29tcGxleGl0eS4iDQo+DQo+ IElmIEknbSByZWFkaW5nIGNvcnJlY3RseSwgdGhlIEZNVFAgcGFyYW1ldGVycyBpbiB0aGlzIGRy YWZ0IGZpdCB0aGUgcHJldHR5IGNvbW1vbiAic2VtaWNvbG9uIGRlbGltaXRlZCBsaXN0IG9mIHBh cmFtZXRlcj12YWx1ZSBwYWlycyIsIHNvIEkgZG9uJ3QgdGhpbmsgdGhpcyByaXNlcyB0byB0aGUg bGV2ZWwgb2YgInNvbWUgY29tcGxleGl0eSIuDQo+DQo+IFNvIHVubGVzcyB5b3UgdGhpbmsgdGhl IHBhcmFtZXRlcnMgaW4gdGhpcyBkcmFmdCBhcmUgbW9yZSBjb21wbGV4IHRoYW4gYXZlcmFnZSwg SSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIGFkZCB0aGVtIGF0IHRoaXMgbGF0ZSBzdGFnZS4gSXQg bWlnaHQgYmUgd29ydGggZGlzY3Vzc2luZyB3aGV0aGVyIHdlIHNob3VsZCBhc2sgYXV0aG9ycyBv ZiBmdXR1cmUgcGF5bG9hZCBkcmFmdHMgdG8gaW5jbHVkZSBBQk5GIGZvciB0aGlzIHNvcnQgb2Yg dGhpbmcuDQoNCkkgY2FuIGxpdmUgd2l0aG91dCBhbnkgY2hhbmdlcy4NCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KDQoNCg== From nobody Sat Apr 18 14:35:07 2015 Return-Path: X-Original-To: expand-draft-ietf-payload-rtp-opus.all@virtual.ietf.org Delivered-To: payload@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2E41E1B3526; Wed, 15 Apr 2015 06:56:58 -0700 (PDT) X-Original-To: xfilter-draft-ietf-payload-rtp-opus.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-payload-rtp-opus.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1266F1B3522 for ; Wed, 15 Apr 2015 06:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OiUVzo478Nd for ; Wed, 15 Apr 2015 06:56:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C3A21B349F for ; Wed, 15 Apr 2015 06:56:57 -0700 (PDT) Received: from raven-v6.nostrum.com ([2001:470:d:1130::1]:34298 helo=nostrum.com) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YiNoF-000768-SP for draft-ietf-payload-rtp-opus.all@tools.ietf.org; Wed, 15 Apr 2015 06:56:57 -0700 Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3FDuaSG073914 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2015 08:56:46 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Christer Holmberg" Date: Wed, 15 Apr 2015 08:56:35 -0500 Message-ID: <431C8AC8-B068-4A06-9017-964A4C145C04@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D79A1AA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D7939BB@ESESSMB209.ericsson.se> <14C2C001-48AE-4142-8E64-2D066EFC380A@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D79A1AA@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) X-Helo-Check-Failed: Verification failed for HELO nostrum.com X-SA-Exim-Connect-IP: 2001:470:d:1130::1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-opus.all@tools.ietf.org X-SA-Exim-Mail-From: ben@nostrum.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-payload-rtp-opus.all@ietf.org Resent-Message-Id: <20150415135657.4C3A21B349F@ietfa.amsl.com> Resent-Date: Wed, 15 Apr 2015 06:56:57 -0700 (PDT) Resent-From: ben@nostrum.com Archived-At: Archived-At: X-Mailman-Approved-At: Sat, 18 Apr 2015 14:35:05 -0700 Cc: "gen-art@ietf.org" , "draft-ietf-payload-rtp-opus.all@tools.ietf.org" Subject: Re: [payload] [Gen-art] Gen-ART review of draft-ietf-payload-rtp-opus-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 13:56:58 -0000 On 15 Apr 2015, at 4:38, Christer Holmberg wrote: > Hi, > >>> Minor Issues: I previously gave the following comment: >>>   >>> “Regarding SDP, I think it would be good to have the ABNF syntax >>> for >>> the a=fmtp parameter (currently you only have descriptive text of >>> the >>> different parameters). It makes the life for the parser implementers >>> much easier :)†>>>   >>> I guess one, by reading section 7 and the examples, can figure out >>> how >>> to encode the a=fmtp parameter, but I think it would to explicitly >>> define the syntax. >> >> (For the record, I just recently took over responsibility for >> PAYLOAD, so if I'm misinterpreting things, someone please tell me :-) >> ) >> >> While I can see that as a "might be nice" addition, I don't think >> it's something that we have required of other payload drafts. > > After all my years of taking drafts through the IETF publication > process, I have learned that there is no such thing as consistency :) > That is absolutely true. And I do think it's worth discussing whether future payload specs should do that. It's just a matter of who gets stuck with a new documentation requirement :-) >> draft-ietf-payload-rtp (in RFC ed queue) says the following about >> ABNF for SDP parameters: >> >> "Not that commonly used in RTP payload formats but may be useful when >> defining Media Type parameters of some complexity." >> >> If I'm reading correctly, the FMTP parameters in this draft fit the >> pretty common "semicolon delimited list of parameter=value pairs", so >> I don't think this rises to the level of "some complexity". >> >> So unless you think the parameters in this draft are more complex >> than average, I don't think we need to add them at this late stage. >> It might be worth discussing whether we should ask authors of future >> payload drafts to include ABNF for this sort of thing. > > I can live without any changes. Thanks! > > Regards, > > Christer From nobody Mon Apr 20 07:34:37 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5271B2E0F; Mon, 20 Apr 2015 07:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghkLFY3Tb1LX; Mon, 20 Apr 2015 07:34:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 353241B2E04; Mon, 20 Apr 2015 07:34:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150420143435.12161.75522.idtracker@ietfa.amsl.com> Date: Mon, 20 Apr 2015 07:34:35 -0700 Archived-At: Cc: draft-ietf-payload-rtp-opus@ietf.org, draft-ietf-payload-rtp-opus.ad@ietf.org, payload-chairs@ietf.org, draft-ietf-payload-rtp-opus.shepherd@ietf.org, payload@ietf.org Subject: [payload] Kathleen Moriarty's No Objection on draft-ietf-payload-rtp-opus-11: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 14:34:36 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-payload-rtp-opus-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for adjusting the text int he security considerations section to encourage the use of strong security mechanisms. From nobody Mon Apr 20 15:07:37 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA931B32E1; Mon, 20 Apr 2015 15:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEgbp1JPJLa0; Mon, 20 Apr 2015 15:07:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8589E1B32E4; Mon, 20 Apr 2015 15:07:23 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150420220723.22695.38302.idtracker@ietfa.amsl.com> Date: Mon, 20 Apr 2015 15:07:23 -0700 Archived-At: Cc: payload chair , payload mailing list , RFC Editor Subject: [payload] Protocol Action: 'RTP Payload Format for the Opus Speech and Audio Codec' to Proposed Standard (draft-ietf-payload-rtp-opus-11.txt) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 22:07:35 -0000 The IESG has approved the following document: - 'RTP Payload Format for the Opus Speech and Audio Codec' (draft-ietf-payload-rtp-opus-11.txt) as Proposed Standard This document is the product of the Audio/Video Transport Payloads Working Group. The IESG contact persons are Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ Technical Summary This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus encoded speech and audio data necessary to integrate the codec in the most compatible way. Working Group Summary The document was discussed on the mailing list. The open issues were addressed and there were no controversies. Document Quality There are several existing implementations (E.g., Chrome, Firefox, libav/FFmpeg, gstreamer, Bria, Freeswitch, Jitsi, Meetecho, Linphone, PJSIP, and VLC). The request for a media type review was posted on Dec. 31st , 2014. Personnel Ali C. Begen is the document shepherd and Ben Campbell is the responsible AD. From nobody Thu Apr 23 00:41:37 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFBA1B2F23 for ; Thu, 23 Apr 2015 00:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W99jJJYJKqov for ; Thu, 23 Apr 2015 00:41:34 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46D0E1B2EFF for ; Thu, 23 Apr 2015 00:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6752; q=dns/txt; s=iport; t=1429774895; x=1430984495; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=M3zaR4G/Foq5xu4HNXwp3KUpELq5kvcEbla/ODD4KXE=; b=QTk7phMaQj5YRnyYHiGizcsS+YB2Y2yYZ5N1rmOTmkeCo9IBumKkdFkD 19PdMR0h17eSHnFpB4qgKJwR2qCOXFCGXUSzs4bCFye/xx343FApi3is7 RcEwOXCZ2BDpiYcNIY5QrqbYDbP20cLQ4nJUCWBmqnofU95YnNNdjasL6 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D3BgDyoDhV/5ldJa1bgkVHUlwFgxXDGIIChgQCHIEaTAEBAQEBAYELhCABAQEEHQYKQRsCAQgOAwMBAigDAgICMBQJCAEBBAESiCsNtyqVEgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLN4RzGIJoL4EWBZFBhAGGMIEiO4MEjQ2DTiODc28BgUOBAAEBAQ X-IronPort-AV: E=Sophos;i="5.11,629,1422921600"; d="scan'208,217";a="414109646" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 23 Apr 2015 07:41:34 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t3N7fXBV013983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 07:41:33 GMT Received: from xmb-aln-x01.cisco.com ([169.254.2.66]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 02:41:33 -0500 From: "Ali C. Begen (abegen)" To: Roni Even , "payload@ietf.org" Thread-Topic: [payload] call for adoption of RTP Payload for VP9 video Thread-Index: AdBn7cR52AX3AZTXSv+SES1FWYbjWAV7jPGA Date: Thu, 23 Apr 2015 07:42:14 +0000 Message-ID: <370B9D11-04B5-4DEE-B6FF-2C638508B408@cisco.com> References: <010d01d067ed$cc9d8610$65d89230$@gmail.com> In-Reply-To: <010d01d067ed$cc9d8610$65d89230$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.9.0.150408 x-originating-ip: [10.86.240.30] Content-Type: multipart/alternative; boundary="_000_370B9D1104B54DEEB6FF2C638508B408ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [payload] call for adoption of RTP Payload for VP9 video X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 07:41:35 -0000 --_000_370B9D1104B54DEEB6FF2C638508B408ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXV0aG9ycywNCg0KWW91IGNhbiBzdWJtaXQgdGhlIFdHIHZlcnNpb24gb2YgeW91ciBkcmFmdC4N Cg0KLWFjYmVnZW4sIGNvLWNoYWlyDQoNCkZyb206IFJvbmkgRXZlbg0KRGF0ZTogVGh1cnNkYXks IE1hcmNoIDI2LCAyMDE1IGF0IDc6NTMgUE0NClRvOiAicGF5bG9hZEBpZXRmLm9yZzxtYWlsdG86 cGF5bG9hZEBpZXRmLm9yZz4iDQpTdWJqZWN0OiBbcGF5bG9hZF0gY2FsbCBmb3IgYWRvcHRpb24g b2YgUlRQIFBheWxvYWQgZm9yIFZQOSB2aWRlbw0KDQpIaSwNCkF0IHRoZSBJRVRGOTIgc2Vzc2lv biB0aGVyZSB3YXMgc3VwcG9ydCB0byB3b3JrIG9uIFJUUCBQYXlsb2FkIGZvciBWUDkgdmlkZW8u IFRoZSBXRyBjaGFpcnMgd291bGQgbGlrZSB0byBjb25maXJtIGl0IG9uIHRoZSBtYWlsaW5nIGxp c3QuDQpXZSB3b3VsZCBsaWtlIHRvIGNyZWF0ZSBhIG5ldyBtaWxlc3RvbmUgZm9yIHRoaXMgdG9w aWMgYW5kIGFkb3B0IGRyYWZ0LXViZXJ0aS1wYXlsb2FkLXZwOS0wMTxodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaWQvZHJhZnQtdWJlcnRpLXBheWxvYWQtdnA5LTAxLnR4dD4gYXMgdGhlIGluaXRpYWwg ZG9jdW1lbnQgZm9yIHRoZSBuZXcgbWlsZXN0b25lDQoNClBsZWFzZSBwcm92aWRlIGZlZWRiYWNr IG9uIGJvdGggdG9waWNzIChtaWxlc3RvbmUgYW5kIGRvY3VtZW50IGFkb3B0aW9uKSBvbiB0aGUg bWFpbGluZyBsaXN0IHRpbGwgQXByaWwgMTB0aCAyMDE1DQoNClRoYW5rcw0KUm9uaSBFdmVuDQpQ YXlsb2FkIFdHIGNvLWNoYWlyDQoNCg0K --_000_370B9D1104B54DEEB6FF2C638508B408ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4854652D44745744AADA1286B634C283@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj5BdXRob3JzLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+WW91IGNhbiBzdWJt aXQgdGhlIFdHIHZlcnNpb24gb2YgeW91ciBkcmFmdC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2Pi1hY2JlZ2VuLCBjby1jaGFpcjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRM T09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9y OmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBu b25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdI VDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRp dW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+RnJvbTogPC9zcGFuPlJvbmkgRXZlbjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5EYXRlOiA8L3NwYW4+VGh1cnNkYXksIE1hcmNoIDI2LCAyMDE1IGF0IDc6NTMgUE08YnI+ DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDs8YSBocmVm PSJtYWlsdG86cGF5bG9hZEBpZXRmLm9yZyI+cGF5bG9hZEBpZXRmLm9yZzwvYT4mcXVvdDs8YnI+ DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPltwYXlsb2Fk XSBjYWxsIGZvciBhZG9wdGlvbiBvZiBSVFAgUGF5bG9hZCBmb3IgVlA5IHZpZGVvPGJyPg0KPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJ QlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQ QURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2IHhtbG5zOnY9InVybjpzY2hl bWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t Om9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNl OndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQv MTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPG1ldGEg bmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVk aXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4yNWluIDEuMGluIDEuMjVpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXQgdGhlIElFVEY5MiBzZXNzaW9u IHRoZXJlIHdhcyBzdXBwb3J0IHRvIHdvcmsgb24gPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4N ClJUUCBQYXlsb2FkIGZvciBWUDkgdmlkZW8uIFRoZSBXRyBjaGFpcnMgd291bGQgbGlrZSB0byBj b25maXJtIGl0IG9uIHRoZSBtYWlsaW5nIGxpc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5XZSB3b3VsZCBsaWtl IHRvIGNyZWF0ZSBhIG5ldyBtaWxlc3RvbmUgZm9yIHRoaXMgdG9waWMgYW5kIGFkb3B0DQo8YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtdWJlcnRpLXBheWxvYWQtdnA5LTAx LnR4dCI+ZHJhZnQtdWJlcnRpLXBheWxvYWQtdnA5LTAxPC9hPjwvc3Bhbj4mbmJzcDthcyB0aGUg aW5pdGlhbCBkb2N1bWVudCBmb3IgdGhlIG5ldyBtaWxlc3RvbmU8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UGxlYXNlIHByb3ZpZGUgZmVlZGJhY2sgb24gYm90aCB0b3BpY3MgKG1pbGVzdG9uZSBh bmQgZG9jdW1lbnQgYWRvcHRpb24pIG9uIHRoZSBtYWlsaW5nIGxpc3QgdGlsbCBBcHJpbCAxMDxz dXA+dGg8L3N1cD4gMjAxNTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3M8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJvbmkgRXZlbjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UGF5bG9hZCBXRyBjby1jaGFpcjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_370B9D1104B54DEEB6FF2C638508B408ciscocom_-- From nobody Thu Apr 23 00:42:43 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B115B1B2F3A for ; Thu, 23 Apr 2015 00:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pg2dn3vbb938 for ; Thu, 23 Apr 2015 00:42:40 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 507171B2F38 for ; Thu, 23 Apr 2015 00:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1180; q=dns/txt; s=iport; t=1429774960; x=1430984560; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Gvo6MwmYe9ojgqZqIDwt6xR1054EbNhNNMYzxMjXrJk=; b=VTXMp4SQq7WCCfV5LM5RiklvIXQw6jnRaKAHDpxfJB/1Pz/7508XHHZu jtIYEo5Jp5gm+2Hs65zZJpp1kPyzyopY/uVrB/sgV6OwXnXfJCcmsougK Q2SpQrzegfsUxdTWCYq1WdTiM684cZ4KFhhxTzNKSpRX2dWUhE/yIEJkQ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgBQAkoThV/5BdJa1bgwxSXAWDFcUahgQCHIEaTAEBAQEBAYELhCABAQEEHQYROgsQAgEIDgMDAQIDAiYCAgIwFQgIAgQBDQWIKw23KpUSAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIYoWgT2DRweCaC+BFgEEkUGEAYYwgSKDP40Ng04jghOBYG8BgUOBAAEBAQ X-IronPort-AV: E=Sophos;i="5.11,629,1422921600"; d="scan'208";a="414455441" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP; 23 Apr 2015 07:42:40 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t3N7gd9q011248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 07:42:39 GMT Received: from xmb-aln-x01.cisco.com ([169.254.2.66]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 02:42:39 -0500 From: "Ali C. Begen (abegen)" To: Roni Even , Thomas Edwards Thread-Topic: [payload] call for adoption of RTP Payload for SMPTE ST 291 Ancillary Data Thread-Index: AQHQfZkSK3HI32JO/ECybUnH0GCwng== Date: Thu, 23 Apr 2015 07:43:20 +0000 Message-ID: <6C564882-C244-4009-8D25-577C8AD6CF95@cisco.com> References: <006401d067d2$03e9a020$0bbce060$@gmail.com> In-Reply-To: <006401d067d2$03e9a020$0bbce060$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.9.0.150408 x-originating-ip: [10.86.240.30] Content-Type: text/plain; charset="utf-8" Content-ID: <7706B6E90E15F844BD13739D338A4F08@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] call for adoption of RTP Payload for SMPTE ST 291 Ancillary Data X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 07:42:41 -0000 VGhvbWFzLA0KDQpZb3UgY2FuIHN1Ym1pdCB0aGUgV0cgdmVyc2lvbiBvZiB5b3VyIGRyYWZ0ICgg ZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1hbmNpbGxhcnktMDApDQoNCi1hY2JlZ2VuLCBjby1jaGFp cg0KDQoNCkZyb206ICBSb25pIEV2ZW4NCkRhdGU6ICBUaHVyc2RheSwgTWFyY2ggMjYsIDIwMTUg YXQgNDozNCBQTQ0KVG86ICAicGF5bG9hZEBpZXRmLm9yZyINClN1YmplY3Q6ICBbcGF5bG9hZF0g Y2FsbCBmb3IgYWRvcHRpb24gb2YgUlRQIFBheWxvYWQgZm9yIFNNUFRFIFNUIDI5MQlBbmNpbGxh cnkgRGF0YQ0KDQoNCj5IaSwNCj5BdCB0aGUgSUVURjkyIHNlc3Npb24gdGhlcmUgd2FzIHN1cHBv cnQgdG8gd29yayBvbiANCj5SVFAgUGF5bG9hZCBmb3IgU01QVEUgU1QgMjkxIEFuY2lsbGFyeSBE YXRhLiBUaGUgV0cgY2hhaXJzIHdvdWxkIGxpa2UgdG8gY29uZmlybSBpdCBvbiB0aGUgbWFpbGlu ZyBsaXN0Lg0KPldlIHdvdWxkIGxpa2UgdG8gY3JlYXRlIGEgbmV3IG1pbGVzdG9uZSBmb3IgdGhp cyB0b3BpYyBhbmQgYWRvcHQNCj5kYWZ0LWVkd2FyZHMtcGF5bG9hZC1ydHAtYW5jaWxsYXJ5LTAx IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWVkd2FyZHMtcGF5bG9hZC1ydHAtYW5j aWxsYXJ5LTAxLnR4dD4gYXMgdGhlIGluaXRpYWwgZG9jdW1lbnQgZm9yIHRoZSBuZXcgbWlsZXN0 b25lDQo+IA0KPlBsZWFzZSBwcm92aWRlIGZlZWRiYWNrIG9uIGJvdGggdG9waWNzIChtaWxlc3Rv bmUgYW5kIGRvY3VtZW50IGFkb3B0aW9uKSBvbiB0aGUgbWFpbGluZyBsaXN0IHRpbGwgQXByaWwg MTB0aCAyMDE1DQo+IA0KPlRoYW5rcw0KPlJvbmkgRXZlbg0KPlBheWxvYWQgV0cgY28tY2hhaXIg DQo+IA0K From nobody Mon Apr 27 08:30:40 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7401A87D5 for ; Mon, 27 Apr 2015 08:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58uDVH86RcM8 for ; Mon, 27 Apr 2015 08:30:37 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9F301A87EB for ; Mon, 27 Apr 2015 08:30:34 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so86958349wic.1 for ; Mon, 27 Apr 2015 08:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=mlVcsYD/VWoKBaXs2/Fv2HYhZrboFrK3KZsHGxyp7TE=; b=S4/7rQT3FI3IWwKifeoWqOA9NLIf3PE8TMYJjJo/nIqOeKggrvLDVEdUzrdXN8FZ2S 1zqZFTBn2OfsCYneu9URWijMdjL1Ebg5NIbdQYGncSMQ3xDXGIX9rUJinuhAN0USBV3K EMRxozC6nd3sFSs2UP5X0TSKSj0tER+VxQ3hY8Gy4+FZv4X1+NFULINuwnaglpFpLQgl j23zQo2WmiohGMK7vHVwKhu9/JOvm6B7fJVFCiBR6ad2RqTqQ6mHXSiClQQmOIjnOxgr NhSrkUcLqz0wGdRO5dwdoT/meHloKfX2W2w14eqQgJUOHW19Fs2UiD00lAPzp+eMGe2S c3lQ== X-Received: by 10.194.192.226 with SMTP id hj2mr352631wjc.51.1430148633587; Mon, 27 Apr 2015 08:30:33 -0700 (PDT) Received: from RoniE ([109.65.21.99]) by mx.google.com with ESMTPSA id l3sm12086541wiv.18.2015.04.27.08.30.32 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Apr 2015 08:30:33 -0700 (PDT) From: "Roni Even" To: Date: Mon, 27 Apr 2015 18:30:29 +0300 Message-ID: <03e901d080ff$1946f1c0$4bd4d540$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03EA_01D08118.3E94C600" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCA/nAt4OoJ50MsRw2bpgMJhsYzDQ== Content-Language: en-us Archived-At: Cc: payload@ietf.org Subject: [payload] Milestone for draft-ietf-payload-rtp-sbc-07 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 15:30:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03EA_01D08118.3E94C600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We have the following milestone for the expired draft-ietf-payload-rtp-sbc-07 Aug 2012 - Submit RTP Payload Format for Bluetooth's SBC audio codec for Proposed Standard Is there still interest and time for finishing this milestone. Please let the chairs know If there is no interest we will remove the mile sone Thanks Roni Even Payload co-chair ------=_NextPart_000_03EA_01D08118.3E94C600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We have the following milestone for the expired draft-ietf-payload-rtp-sbc-07

=

Aug 2012 - Submit RTP Payload Format for = Bluetooth's SBC audio codec for Proposed = Standard

 

Is there still = interest and time for finishing this milestone.

Please let the chairs know =

If there is no = interest we will remove the mile sone

 

Thanks

Roni = Even

Payload = co-chair

 

 

------=_NextPart_000_03EA_01D08118.3E94C600-- From nobody Mon Apr 27 08:34:06 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9EA1A8820 for ; Mon, 27 Apr 2015 08:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fEm2oH3Dx_Y for ; Mon, 27 Apr 2015 08:34:00 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7AF81A87E8 for ; Mon, 27 Apr 2015 08:33:59 -0700 (PDT) Received: by wiun10 with SMTP id n10so94537505wiu.1 for ; Mon, 27 Apr 2015 08:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=AONTw8v5drMFuz7QLjdtelfsa3sDYidDeWb+fz+4f1g=; b=L+/2FZXMiQfhfwyUTpbM8UIcHeHh87OoWvJ4iMpLdb7y/wUkDWOLbYuNgKKpCP8NfA EEbv9XRO2Vy9IH691OHLOMElvcWpBmzwfzFIwoIxK2L813RkZeFU6ZWQoigykvf0WZin LVpRh6TbuczcSowxD903NvGeZPduin4almWtHezjS7Ilaqm5RcyKw0ZeqkOlyamxtKH5 BbIC2o9TMDmz3sMQBfqtLzdZZCwM5FoiX1MkhGA9I2g++hE1C5lMWH4VtqLJ6Go0CAej wbU3VwDxgoSu5lvTBVeJJKnivO3ntUsSKQRYu6P2TDEvGRc6pnNO3HleUj/VL69weIr4 givA== X-Received: by 10.180.81.3 with SMTP id v3mr21123451wix.36.1430148838491; Mon, 27 Apr 2015 08:33:58 -0700 (PDT) Received: from RoniE (bzq-109-65-21-99.red.bezeqint.net. [109.65.21.99]) by mx.google.com with ESMTPSA id cf12sm29881750wjb.10.2015.04.27.08.33.56 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Apr 2015 08:33:57 -0700 (PDT) From: "Roni Even" To: Date: Mon, 27 Apr 2015 18:33:54 +0300 Message-ID: <03ee01d080ff$93587c90$ba0975b0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03EF_01D08118.B8A629C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCA/5GFc3x4XaJeTu6yLUDLbVI1Tg== Content-Language: en-us Archived-At: Cc: payload@ietf.org Subject: [payload] milestone for draft-ietf-payload-rtp-g718-03 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 15:34:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03EF_01D08118.B8A629C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We have the following milestone for the expired draft-ietf-payload-rtp-g718-03 Sep 2012 - Submit RTP Payload Format for EVBR/G.718 for Proposed Standard Is there still interest and time for finishing this milestone. Please let the chairs know If there is no interest we will remove the milestone Thanks Roni Even Payload co-chair ------=_NextPart_000_03EF_01D08118.B8A629C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We have the following milestone for the expired draft-ietf-payload-rtp-g718-03

Sep 2012 - Submit RTP Payload Format for = EVBR/G.718 for Proposed Standard

 

Is there still = interest and time for finishing this milestone.

Please let the chairs know =

If there is no = interest we will remove the milestone

 

Thanks

Roni = Even

Payload = co-chair

 

 

------=_NextPart_000_03EF_01D08118.B8A629C0-- From nobody Mon Apr 27 08:42:34 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06B61A884B for ; Mon, 27 Apr 2015 08:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dF9kvtvXjDDS for ; Mon, 27 Apr 2015 08:42:25 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024F11A87BE for ; Mon, 27 Apr 2015 08:42:25 -0700 (PDT) Received: by wgen6 with SMTP id n6so120388476wge.3 for ; Mon, 27 Apr 2015 08:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=El46S11hJLVsS8CMzftSMhdT6jsEWErSdzZeGQ7M74M=; b=ZvWKOcorFU3th9xKyPbqkIZhNmycAIuQZxkffQQVCumO6iAsFvfjGWK5VqJIXIwX02 DOfueFWE/eS7AadAfRRbNKlL9igIuO1V4lbuxR0+3dPOKJXNcGXCWILo6lxVeVw3Nzzj +gAa/BgvCXJTtMwE4LURuMQRrKNPjUVz92iX20MhElLApXWRsfqkOU1RQarOzNoosliY N3Ov9LyoZN4Yy3/6FHKai53wKCIO68z/d8PewXRC4DX8pIe0A4PgCF2oUU2ytX/Hwuvp /3rZh8hhCRT1lQ6TSlv0e0xsTldjSB8EUZk1p+7odANpJF1aIIqedzo/LsTF0ir8Y+W+ q0Sw== X-Received: by 10.180.9.5 with SMTP id v5mr21423763wia.93.1430149343691; Mon, 27 Apr 2015 08:42:23 -0700 (PDT) Received: from RoniE ([109.65.21.99]) by mx.google.com with ESMTPSA id xb3sm25458776wjc.38.2015.04.27.08.42.22 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Apr 2015 08:42:23 -0700 (PDT) From: "Roni Even" To: Date: Mon, 27 Apr 2015 18:42:19 +0300 Message-ID: <03f301d08100$c07831b0$41689510$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03F4_01D08119.E5C605F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCBAEsHYBuj+JEKQuuYJwunmW/3/g== Content-Language: en-us Archived-At: Cc: payload@ietf.org Subject: [payload] Milestone for draft-ietf-payload-rtp-mvc-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 15:42:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03F4_01D08119.E5C605F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We have the following milestone for the expired draft-ietf-payload-rtp-mvc-02. Mar 2013 - Submit RTP Payload Format for MVC Video for Proposed Standard I understand from Ye-Kui that he will not be able to continue the work on MVC payload. Is there still interest and time for finishing this milestone. Please let the chairs know if anyone want to be the editor of this document. If there is no interest we will remove the milestone. Thanks Roni Even Payload co-chair ------=_NextPart_000_03F4_01D08119.E5C605F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We have the following milestone for the expired draft-ietf-payload-rtp-mvc-02.

Mar 2013 - Submit RTP Payload Format for MVC Video = for Proposed Standard

 

I understand from  Ye-Kui = that he will not be able to continue the work on MVC = payload.

Is there still = interest and time for finishing this milestone.

Please let the chairs know if anyone want to be = the editor of this document.

If there is no = interest we will remove the milestone.

 

Thanks

Roni = Even

Payload = co-chair

 

 

------=_NextPart_000_03F4_01D08119.E5C605F0-- From nobody Mon Apr 27 09:39:00 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5AE1A89A7 for ; Mon, 27 Apr 2015 09:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoHgwhD0dW51 for ; Mon, 27 Apr 2015 09:38:56 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8A61A89A3 for ; Mon, 27 Apr 2015 09:38:55 -0700 (PDT) Received: by wiax7 with SMTP id x7so88474937wia.0; Mon, 27 Apr 2015 09:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=V3br095SULWI2OCyfSR0RCrbzIYZMEi4wtDDScJdNyo=; b=HkRONmSn5DcpA5R1G0CXCjLvbh/eRLyupdX38pyvxlGgrvkO4gQm/UpUHbxrINCpaX HbDLW6B5TOS3ugsud4VQ9gDTdNrdjZaDCkH/IcOght+6VeKTmT+ipPT7sJ5iJnYkrXvJ vpyfXI3vQQN/g6tKSjqB+8x7sJjq742cXU7V4NORZ7vC0SLLsRgB7clMzYaBGvP9fovf BOFqnQIPCx4hcmuRO96FTisgSM+1DgA+lNBqnuYBZeha9aPqAsleRQ/0yYX9+U0qinDv WS6+zS5qdseLuT37r8DV1ANjxEdRC9AL3JZ8sYvyeXM+KK800lUdti7yxxnvOgrV9Dtt hi7w== X-Received: by 10.194.63.225 with SMTP id j1mr24521433wjs.120.1430152734557; Mon, 27 Apr 2015 09:38:54 -0700 (PDT) Received: from RoniE (bzq-109-65-21-99.red.bezeqint.net. [109.65.21.99]) by mx.google.com with ESMTPSA id w5sm12348108wiz.11.2015.04.27.09.38.53 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Apr 2015 09:38:53 -0700 (PDT) From: "Roni Even" To: Date: Mon, 27 Apr 2015 19:38:50 +0300 Message-ID: <040d01d08108$a5a94600$f0fbd200$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_040E_01D08121.CAF71A40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCA/5GFc3x4XaJeTu6yLUDLbVI1Tg== Content-Language: en-us Archived-At: Cc: payload@ietf.org Subject: [payload] milestone for draft-ietf-payload-rtp-g718-03 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 16:38:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_040E_01D08121.CAF71A40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We have the following milestone for the expired draft-ietf-payload-rtp-g718-03 Sep 2012 - Submit RTP Payload Format for EVBR/G.718 for Proposed Standard Is there still interest and time for finishing this milestone. Please let the chairs know If there is no interest we will remove the milestone Thanks Roni Even Payload co-chair ------=_NextPart_000_040E_01D08121.CAF71A40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We have the following milestone for the expired draft-ietf-payload-rtp-g718-03

Sep 2012 - Submit RTP Payload Format for = EVBR/G.718 for Proposed Standard

 

Is there still = interest and time for finishing this milestone.

Please let the chairs know =

If there is no = interest we will remove the milestone

 

Thanks

Roni = Even

Payload = co-chair

 

 

------=_NextPart_000_040E_01D08121.CAF71A40-- From nobody Mon Apr 27 09:39:48 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCEA1A89A7 for ; Mon, 27 Apr 2015 09:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPbBNpiFgbw9 for ; Mon, 27 Apr 2015 09:39:45 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7850A1A898F for ; Mon, 27 Apr 2015 09:39:45 -0700 (PDT) Received: by widdi4 with SMTP id di4so96907393wid.0; Mon, 27 Apr 2015 09:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=Ya1SNYd4z3kLnKNxjCo1LwrLtHEnLEy8mxvPfCMU67s=; b=CK64tNlXcVsrx78xF7U353CkkFitZ9g892rzRn2EQtCAaVKLkhUJOtt5PIz89ok4dQ KbAUKInEdz3mX5RWw1+gLlpHtgx34cIDBiF/U3bio3g90Br7dVYsfPI/uC6OXvBHXpRo 1nnIYAT0mcMYYX2ykmjkXCLDnXzz8KNkW/QpHPpOiNUnVHZpwaGZyE6dQzP6z6lo4HBS hZqR7iVv0ZQ9sKlAd1q6VfahSIez8lbKX/rRNSmVlg+yF3Cux+M2waHkQN7galqtpIPt P1ZgT4I/uRwoIpWYerAmo2SRohwEB8o8ooKEJUAsD7gGXtk2C/REMIMISCP7eGhLpWXA eEug== X-Received: by 10.180.82.41 with SMTP id f9mr21559476wiy.48.1430152784242; Mon, 27 Apr 2015 09:39:44 -0700 (PDT) Received: from RoniE ([109.65.21.99]) by mx.google.com with ESMTPSA id wo10sm30143806wjb.35.2015.04.27.09.39.42 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Apr 2015 09:39:43 -0700 (PDT) From: "Roni Even" To: Date: Mon, 27 Apr 2015 19:39:39 +0300 Message-ID: <041201d08108$c3244540$496ccfc0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0413_01D08121.E8721980" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCBAEsHYBuj+JEKQuuYJwunmW/3/g== Content-Language: en-us Archived-At: Cc: payload@ietf.org Subject: [payload] Milestone for draft-ietf-payload-rtp-mvc-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 16:39:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0413_01D08121.E8721980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We have the following milestone for the expired draft-ietf-payload-rtp-mvc-02. Mar 2013 - Submit RTP Payload Format for MVC Video for Proposed Standard I understand from Ye-Kui that he will not be able to continue the work on MVC payload. Is there still interest and time for finishing this milestone. Please let the chairs know if anyone want to be the editor of this document. If there is no interest we will remove the milestone. Thanks Roni Even Payload co-chair ------=_NextPart_000_0413_01D08121.E8721980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We have the following milestone for the expired draft-ietf-payload-rtp-mvc-02.

Mar 2013 - Submit RTP Payload Format for MVC Video = for Proposed Standard

 

I understand from  Ye-Kui = that he will not be able to continue the work on MVC = payload.

Is there still = interest and time for finishing this milestone.

Please let the chairs know if anyone want to be = the editor of this document.

If there is no = interest we will remove the milestone.

 

Thanks

Roni = Even

Payload = co-chair

 

 

------=_NextPart_000_0413_01D08121.E8721980-- From nobody Tue Apr 28 01:28:04 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD191A1A75 for ; Tue, 28 Apr 2015 01:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeTqAJppEZv2 for ; Tue, 28 Apr 2015 01:28:01 -0700 (PDT) Received: from vwp12996.webpack.hosteurope.de (vwp12996.webpack.hosteurope.de [IPv6:2a01:488:42:1000:523:eb55::]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEACA1A1A60 for ; Tue, 28 Apr 2015 01:28:00 -0700 (PDT) Received: from u-173-c040.cs.uni-tuebingen.de ([134.2.173.40] helo=samsung7); authenticated by vwp12996.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Yn0rz-0002WQ-Sr; Tue, 28 Apr 2015 10:27:55 +0200 From: "Christian Hoene" To: "'Roni Even'" , References: <03e901d080ff$1946f1c0$4bd4d540$@gmail.com> In-Reply-To: <03e901d080ff$1946f1c0$4bd4d540$@gmail.com> Date: Tue, 28 Apr 2015 10:27:59 +0200 Organization: Symonics GmbH Message-ID: <028401d0818d$3c4a2b90$b4de82b0$@symonics.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0285_01D0819D.FFD54580" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGtevY5d5mEcaN8cj1QcjS9/FtvBp2oI8YQ Content-Language: de X-bounce-key: webpack.hosteurope.de; christian.hoene@symonics.com; 1430209680; 8d419f85; Archived-At: Cc: payload@ietf.org Subject: Re: [payload] Milestone for draft-ietf-payload-rtp-sbc-07 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 08:28:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0285_01D0819D.FFD54580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, the draft is finished and the protocol has been implemented. >From our side, we could progress anytime. However, if there are no interests from other sides, we can skip the draft and milestone. With best regards, Christian Hoene Von: Roni Even [mailto:ron.even.tlv@gmail.com] Gesendet: Montag, 27. April 2015 17:30 An: draft-ietf-payload-rtp-sbc@tools.ietf.org Cc: payload@ietf.org Betreff: [payload] Milestone for draft-ietf-payload-rtp-sbc-07 Hi, We have the following milestone for the expired draft-ietf-payload-rtp-sbc-07 Aug 2012 - Submit RTP Payload Format for Bluetooth's SBC audio codec for Proposed Standard Is there still interest and time for finishing this milestone. Please let the chairs know If there is no interest we will remove the mile sone Thanks Roni Even Payload co-chair ------=_NextPart_000_0285_01D0819D.FFD54580 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

the draft is finished = and the protocol has been implemented.

 

From our side, we = could progress anytime.

 

However, if there are = no interests from other sides, we can skip the draft and = milestone.

 

With best = regards,

 

Christian = Hoene

 

 

 

 

 

 

Von: Roni = Even [mailto:ron.even.tlv@gmail.com]
Gesendet: Montag, 27. = April 2015 17:30
An: = draft-ietf-payload-rtp-sbc@tools.ietf.org
Cc: = payload@ietf.org
Betreff: [payload] Milestone for = draft-ietf-payload-rtp-sbc-07

 

Hi,

We have the following milestone for the = expired draft-ietf-payload-rtp-sbc-07

Aug 2012 - Submit RTP Payload Format = for Bluetooth's SBC audio codec for Proposed = Standard

 

Is = there still interest and time for finishing this = milestone.

Please let the chairs know =

If = there is no interest we will remove the mile = sone

 

Thanks

Roni = Even

Payload co-chair

 

 

------=_NextPart_000_0285_01D0819D.FFD54580-- From nobody Tue Apr 28 01:34:46 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532001A1B40 for ; Tue, 28 Apr 2015 01:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2bq1ZyvB_3f for ; Tue, 28 Apr 2015 01:34:44 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBFF81A1B34 for ; Tue, 28 Apr 2015 01:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2034; q=dns/txt; s=iport; t=1430210084; x=1431419684; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LGIAUUE4S3koRSPUbR/ZnLappn+LhapInCH3pbcXYIM=; b=RvoPTIJQa9B2MxrxPucDZPqgni8PfJxBVvh8lV2sa9zBJlaFiAyjhX8B Ga98rW5EkgE4Mctmz/1Q21X8y/n6PtsPmHoltKkhWzPz/usb8ubHhwXFm jXTFrDB+6NpZMbI9vfZeLfBtlE6idmOLYHHyqjbukV/BgrPr+7sBNmuAe c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CABABSRT9V/5RdJa1cgwxTXAWDFcNmCYFShgQCHIEZOBQBAQEBAQEBgQqEIAEBAQQjEUUQAgEIEQMBAgMCIwMCAgIfERQBCAgBAQQBDQUfh3gDEQ2yNI5FDYU0AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIYoXgk2BSjszB4JoL4EWAQSRVYQBhGSBVIEig0iKIoMFg1Ajg3RvAYFDgQABAQE X-IronPort-AV: E=Sophos;i="5.11,662,1422921600"; d="scan'208";a="145159492" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP; 28 Apr 2015 08:34:43 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t3S8Yh5l002586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Apr 2015 08:34:43 GMT Received: from xmb-aln-x01.cisco.com ([169.254.2.217]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Tue, 28 Apr 2015 03:34:43 -0500 From: "Ali C. Begen (abegen)" To: Christian Hoene , "'Roni Even'" , "draft-ietf-payload-rtp-sbc@tools.ietf.org" Thread-Topic: [payload] Milestone for draft-ietf-payload-rtp-sbc-07 Thread-Index: AdCA/nAt4OoJ50MsRw2bpgMJhsYzDQAuLSeAAAaFOoA= Date: Tue, 28 Apr 2015 08:36:01 +0000 Message-ID: <9729BBE2-B3C4-4D4F-9E11-797A8A7F95F5@cisco.com> References: <03e901d080ff$1946f1c0$4bd4d540$@gmail.com> <028401d0818d$3c4a2b90$b4de82b0$@symonics.com> In-Reply-To: <028401d0818d$3c4a2b90$b4de82b0$@symonics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.9.0.150408 x-originating-ip: [10.86.252.24] Content-Type: text/plain; charset="utf-8" Content-ID: <1A0415CC7FADE44D88ECEAA85A1CF344@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] Milestone for draft-ietf-payload-rtp-sbc-07 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 08:34:45 -0000 SGkgQ2hyaXN0aWFuDQoNCklmIHRoZSBmb2xsb3dpbmcgZHJhZnQgaXMgaW4gYSBnb29kIHNoYXBl IChpLmUuLCBxdWl0ZSBjbG9zZSB0byB3aGF0IGhhcyBiZWVuIGltcGxlbWVudGVkKSwgcHJvYmFi bHkgaXQgd29u4oCZdCBiZSBtdWNoIHdvcmsgb24geW91ciBzaWRlIHRvIGZpbmlzaCBpdC4NCg0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXZ0LXJ0cC1zYmMtMDENCg0K QXJlIHlvdSB3aWxsaW5nIHRvIHRha2UgdGhlIHBlbiBhbmQgcmV2aXNlIGFuZCBmaW5pc2ggaXQ/ DQoNCi1hY2JlZ2VuDQoNCg0KDQoNCkZyb206ICBDaHJpc3RpYW4gSG9lbmUNCk9yZ2FuaXphdGlv bjogIFN5bW9uaWNzIEdtYkgNCkRhdGU6ICBUdWVzZGF5LCBBcHJpbCAyOCwgMjAxNSBhdCAxMToy NyBBTQ0KVG86ICAnUm9uaSBFdmVuJywgImRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtc2JjQHRvb2xz LmlldGYub3JnIg0KQ2M6ICAicGF5bG9hZEBpZXRmLm9yZyINClN1YmplY3Q6ICBSZTogW3BheWxv YWRdIE1pbGVzdG9uZSBmb3IgZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1zYmMtMDcNCg0KDQo+SGVs bG8sDQo+IA0KPnRoZSBkcmFmdCBpcyBmaW5pc2hlZCBhbmQgdGhlIHByb3RvY29sIGhhcyBiZWVu IGltcGxlbWVudGVkLg0KPiANCj5Gcm9tIG91ciBzaWRlLCB3ZSBjb3VsZCBwcm9ncmVzcyBhbnl0 aW1lLg0KPiANCj5Ib3dldmVyLCBpZiB0aGVyZSBhcmUgbm8gaW50ZXJlc3RzIGZyb20gb3RoZXIg c2lkZXMsIHdlIGNhbiBza2lwIHRoZSBkcmFmdCBhbmQgbWlsZXN0b25lLg0KPiANCj5XaXRoIGJl c3QgcmVnYXJkcywNCj4gDQo+Q2hyaXN0aWFuIEhvZW5lDQo+IA0KPiANCj4gDQo+IA0KPiANCj4g DQo+Vm9uOiBSb25pIEV2ZW4gW21haWx0bzpyb24uZXZlbi50bHZAZ21haWwuY29tXSANCj5HZXNl bmRldDogTW9udGFnLCAyNy4gQXByaWwgMjAxNSAxNzozMA0KPkFuOiBkcmFmdC1pZXRmLXBheWxv YWQtcnRwLXNiY0B0b29scy5pZXRmLm9yZw0KPkNjOiBwYXlsb2FkQGlldGYub3JnDQo+QmV0cmVm ZjogW3BheWxvYWRdIE1pbGVzdG9uZSBmb3IgZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1zYmMtMDcN Cj4NCj4NCj4gDQo+SGksDQo+V2UgaGF2ZSB0aGUgZm9sbG93aW5nIG1pbGVzdG9uZSBmb3IgdGhl IGV4cGlyZWQgDQo+ZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1zYmMtMDcNCj5BdWcgMjAxMiAtIFN1 Ym1pdCBSVFAgUGF5bG9hZCBGb3JtYXQgZm9yIEJsdWV0b290aCdzIFNCQyBhdWRpbyBjb2RlYyBm b3IgUHJvcG9zZWQgU3RhbmRhcmQNCj4gDQo+SXMgdGhlcmUgc3RpbGwgaW50ZXJlc3QgYW5kIHRp bWUgZm9yIGZpbmlzaGluZyB0aGlzIG1pbGVzdG9uZS4NCj5QbGVhc2UgbGV0IHRoZSBjaGFpcnMg a25vdw0KPg0KPklmIHRoZXJlIGlzIG5vIGludGVyZXN0IHdlIHdpbGwgcmVtb3ZlIHRoZSBtaWxl IHNvbmUNCj4gDQo+VGhhbmtzDQo+Um9uaSBFdmVuDQo+UGF5bG9hZCBjby1jaGFpcg0KPiANCj4g DQo= From nobody Tue Apr 28 06:03:33 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9448D1A90F7 for ; Tue, 28 Apr 2015 06:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMy2cl_cmB4g for ; Tue, 28 Apr 2015 06:03:31 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB95F1A902A for ; Tue, 28 Apr 2015 06:03:30 -0700 (PDT) Received: by wiun10 with SMTP id n10so28240762wiu.1 for ; Tue, 28 Apr 2015 06:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=nCntzR8yH3ijyi5oiVhH96Vw8lG3kbQ1sTrdIu1vSKc=; b=SnLOrnzTQYg900PIMoRz+fo+J8WgIOXPs4Le7ympKlgFMHNuvLprvGXL8q1VVmGGrv B9J7f7+73plFPVKKwIzPXE1+zN8TCLnJ2WdqCv3fUVGnZEy2TcDu7xTTCsZEDzRTPyaH q84ZIk3oPNh8ltaONpgI3yYQtEECbfsiIwLbTawGS+SctPPhVv7Oel5mnzhPLW8AarJ4 +fAaOndI236f0NUiwqwnigtTJAq8WqHpI6StFFm7f5LBAMgeXD3miNlfUiS/W1wxcMD5 SBJr1cWwg7IXEE2/cybEDR6sL9Y+lAcMriSANK5OQsSsdkhSVkT0ypxZ9eaM9QKtdOGG ocfg== X-Received: by 10.180.74.37 with SMTP id q5mr29859225wiv.59.1430226209567; Tue, 28 Apr 2015 06:03:29 -0700 (PDT) Received: from RoniE ([109.65.21.99]) by mx.google.com with ESMTPSA id it5sm16350704wid.3.2015.04.28.06.03.27 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Apr 2015 06:03:28 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , "'Christian Hoene'" , References: <03e901d080ff$1946f1c0$4bd4d540$@gmail.com> <028401d0818d$3c4a2b90$b4de82b0$@symonics.com> <9729BBE2-B3C4-4D4F-9E11-797A8A7F95F5@cisco.com> In-Reply-To: <9729BBE2-B3C4-4D4F-9E11-797A8A7F95F5@cisco.com> Date: Tue, 28 Apr 2015 16:03:24 +0300 Message-ID: <046a01d081b3$b7e3c0b0$27ab4210$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGtevY5d5mEcaN8cj1QcjS9/FtvBgIHi2xhAUI+txydjiFpgA== Content-Language: en-us Archived-At: Cc: payload@ietf.org Subject: Re: [payload] Milestone for draft-ietf-payload-rtp-sbc-07 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 13:03:32 -0000 Christian, Can you please submit an update revision , so it will be active, you can = also address the error in the nits = https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-= payload-rtp-sbc-07.txt (line too long) I also suggest that you look at the security section in the opus payload = and use the text from there since it is based on discussion with the = security area=20 We can afterwards start a WG last call Roni > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: 28 April, 2015 11:36 AM > To: Christian Hoene; 'Roni Even'; = draft-ietf-payload-rtp-sbc@tools.ietf.org > Cc: payload@ietf.org > Subject: Re: [payload] Milestone for draft-ietf-payload-rtp-sbc-07 >=20 > Hi Christian >=20 > If the following draft is in a good shape (i.e., quite close to what = has been > implemented), probably it won=E2=80=99t be much work on your side to = finish it. >=20 > https://tools.ietf.org/html/draft-ietf-avt-rtp-sbc-01 >=20 > Are you willing to take the pen and revise and finish it? >=20 > -acbegen >=20 >=20 >=20 >=20 > From: Christian Hoene > Organization: Symonics GmbH > Date: Tuesday, April 28, 2015 at 11:27 AM > To: 'Roni Even', "draft-ietf-payload-rtp-sbc@tools.ietf.org" > Cc: "payload@ietf.org" > Subject: Re: [payload] Milestone for draft-ietf-payload-rtp-sbc-07 >=20 >=20 > >Hello, > > > >the draft is finished and the protocol has been implemented. > > > >From our side, we could progress anytime. > > > >However, if there are no interests from other sides, we can skip the = draft and > milestone. > > > >With best regards, > > > >Christian Hoene > > > > > > > > > > > > > >Von: Roni Even [mailto:ron.even.tlv@gmail.com] > >Gesendet: Montag, 27. April 2015 17:30 > >An: draft-ietf-payload-rtp-sbc@tools.ietf.org > >Cc: payload@ietf.org > >Betreff: [payload] Milestone for draft-ietf-payload-rtp-sbc-07 > > > > > > > >Hi, > >We have the following milestone for the expired > >draft-ietf-payload-rtp-sbc-07 > >Aug 2012 - Submit RTP Payload Format for Bluetooth's SBC audio codec = for > Proposed Standard > > > >Is there still interest and time for finishing this milestone. > >Please let the chairs know > > > >If there is no interest we will remove the mile sone > > > >Thanks > >Roni Even > >Payload co-chair > > > > From nobody Thu Apr 30 01:21:54 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAC61ACEEF for ; Thu, 30 Apr 2015 01:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2Hc-TmzO63W for ; Thu, 30 Apr 2015 01:21:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 859591ACF07 for ; Thu, 30 Apr 2015 01:21:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150430082151.22314.10164.idtracker@ietfa.amsl.com> Date: Thu, 30 Apr 2015 01:21:51 -0700 From: IETF Secretariat Archived-At: Subject: [payload] Milestones changed for payload WG X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 08:21:53 -0000 Deleted milestone "Submit RTP Payload Format for MVC Video for Proposed Standard". Changed milestone "Submit RTP Payload Format for Opus Speech and Audio Codec as proposed standard", resolved as "Done". Changed milestone "Submit RTP Payload Format for Bluetooth's SBC audio codec for Proposed Standard", set due date to November 2015 from August 2012. Changed milestone "Submit RTP Payload Format for MPEG2-TS preamble for Proposed Standard", set due date to March 2016 from April 2011, added draft-begen-avt-rtp-mpeg2ts-preamble to milestone. URL: https://datatracker.ietf.org/wg/payload/charter/ From nobody Thu Apr 30 06:58:03 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCB61B2A91 for ; Thu, 30 Apr 2015 06:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saAyMop8GCw6 for ; Thu, 30 Apr 2015 06:58:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 319EC1A908D for ; Thu, 30 Apr 2015 06:57:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150430135759.21132.8692.idtracker@ietfa.amsl.com> Date: Thu, 30 Apr 2015 06:57:59 -0700 From: IETF Secretariat Archived-At: Subject: [payload] Milestones changed for payload WG X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 13:58:02 -0000 Changed milestone "Submit RTP Payload Format for Non-Interleaved and Interleaved Parity FEC", set state to active from review, accepting new milestone. Changed milestone "Submit RTP Payload Format for VP9 Video for Proposed Standard", set state to active from review, accepting new milestone. Changed milestone "Submit RTP Payload Format for SMPTE ST 291 Ancillary Data for Proposed Standard", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/payload/charter/