From nobody Tue Feb 2 12:02:19 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DE21B2BBE; Tue, 2 Feb 2016 12:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 KRHPl4GEJMnq; Tue, 2 Feb 2016 12:02:14 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 04F871B3087; Tue, 2 Feb 2016 12:01:35 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u12K1X1O090899 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 2 Feb 2016 14:01:34 -0600 (CST) (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.10] From: "Ben Campbell" To: "Timothy B. Terriberry" Date: Tue, 02 Feb 2016 14:01:33 -0600 Message-ID: <0788691E-6F5B-4076-8BA2-AF461B4B4D48@nostrum.com> In-Reply-To: <56AA91AA.3020102@xiph.org> References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <56AA78C9.9030304@joelhalpern.com> <56AA811F.8010201@mozilla.com> <56AA8310.2010300@joelhalpern.com> <56AA91AA.3020102@xiph.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5213) Archived-At: Cc: ietf@ietf.org, codec@ietf.org, codec-chairs@ietf.org, "Joel M. Halpern" , draft-ietf-codec-oggopus@ietf.org Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 20:02:16 -0000 On 28 Jan 2016, at 16:09, Timothy B. Terriberry wrote: > Joel M. Halpern wrote: >> The second, changing the text, is not something I or the IETF >> community >> support. > > Well, I don't claim to speak for the whole IETF community, but this is > certainly something I support. > > No one is claiming that someone is going to edit the RFC and claim to > have a new, better RFC (without going through the RFC update/errata > process), and the grant in question specifically disclaims anyone's > right to do that. > > But, particularly for a document like this, which is defining a codec > mapping, I would hope that people would be free to borrow this text > for future mappings: either of Opus into another container or another > codec into Ogg, or even something totally unrelated to either if it > applies. The IETF made an exception to the TLP policies for RFC 6716 not because it was a codec definition per se, but because the normative definition was in the code components. The BSD licensing for code components already allowed derivative works for the code components themselves, but there was a perceived need to also be able to modify text to document any modification of "normative" code components. That reasoning does not apply to this draft, since it does not have normative code components. Can you elaborate on whether it is different from other IETF standards track documents in some other way that might justify such an exception? Thanks! Ben. From nobody Tue Feb 2 12:51:50 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D012C1B30F9; Tue, 2 Feb 2016 12:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-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 74tXRBvtVfou; Tue, 2 Feb 2016 12:51:45 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E188D1B3059; Tue, 2 Feb 2016 12:51:45 -0800 (PST) Received: from unnumerable.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u12KpcmR040803 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 2 Feb 2016 14:51:38 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be unnumerable.local To: Ron References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> From: Robert Sparks Message-ID: <56B116DA.9010507@nostrum.com> Date: Tue, 2 Feb 2016 14:51:38 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160129031044.GB3153@hex.shelbyville.oz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: ietf@ietf.org, codec@ietf.org, codec-chairs@ietf.org, draft-ietf-codec-oggopus@ietf.org Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 20:51:47 -0000 Ben's recent response to Tim captures the main point, but to reinforce what's said there: We learned a lot as a community from going through the development of RFC6716, and there's been strong sentiment expressed that we wouldn't do things like produce normative code again. I think if we were able to repeat the exercise fresh, knowing what we learned, that we also wouldn't have made this copyright change in just this way. However, the most relevant point is that with RFC6716 we at least had an exceptional condition to point to. This draft does not have that. It is not clear to me how the things you are hoping to achieve with this extra language are not already available to you (under fair use for example). In the copy below, you elided my suggestion that the draft argue why the existing boilerplate is insufficient. It _is_ fairly clear to me that the kind of change you're asking for is not really specific to this draft, though. The community developed a set of acceptable boilerplate text blocks. The draft should use what we have, or convince the community that we need to change what we allow for RFCs. RjS On 1/28/16 9:10 PM, Ron wrote: > Hi Robert, > > On Wed, Jan 27, 2016 at 02:44:41PM -0600, Robert Sparks wrote: >> This document has an unusual feature that I think needs to be highlighted in >> this last call. >> >> Section 13 instructs the RFC editor to: >>> In the Copyright Notice at the start of the document, the following >>> paragraph is to be appended after the regular copyright notice text: >>> >>> "The licenses granted by the IETF Trust to this RFC under Section 3.c >>> of the Trust Legal Provisions shall also include the right to extract >>> text from Sections 1 through 14 of this RFC and create derivative >>> works from these extracts, and to copy, publish, display, and >>> distribute such derivative works in any medium and for any purpose, >>> provided that no such derivative work shall be presented, displayed, >>> or published in a manner that states or implies that it is part of >>> this RFC or any other IETF Document." >> I understand why we did what we did for RFC6716 (the specification for OPUS, >> where the additional grants were to deal with the code being normative). >> >> I do not think it is the right thing to do for this document. > Could you spell out in a bit more detail what you see as being different > for this document, and what your concerns are with either (or both!) the > letter and the intent in this case. > > I really would like to understand your concerns, and if necessary have > this evolve into language that does cover everyone's needs and fears as > comprehensively as we can. > > We've got nearly 4 years behind us now with no terrible abuse of this > grant having occurred for 6716, but if you think it's less than ideal, > I'd like us to consider ways we can still improve on that. > > Cheers, > Ron > > From nobody Tue Feb 2 14:27:02 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575311A010E; Tue, 2 Feb 2016 14:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 IPDXMEWjxWLS; Tue, 2 Feb 2016 14:26:55 -0800 (PST) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (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 D0DDA1A010D; Tue, 2 Feb 2016 14:26:55 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 1758FC52F5; Tue, 2 Feb 2016 22:26:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnZ8wtDg33Nf; Tue, 2 Feb 2016 22:26:55 +0000 (UTC) Received: from [10.252.26.95] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 9C77BC3182; Tue, 2 Feb 2016 22:26:50 +0000 (UTC) Message-ID: <56B12D2A.4020906@xiph.org> Date: Tue, 02 Feb 2016 14:26:50 -0800 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: Robert Sparks , Ron References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> In-Reply-To: <56B116DA.9010507@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: codec-chairs@ietf.org, codec@ietf.org, ietf@ietf.org, draft-ietf-codec-oggopus@ietf.org Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 22:26:57 -0000 Robert Sparks wrote: > It is not clear to me how the things you are hoping to achieve with this > extra language are not already available to you (under fair use for > example). In the copy below, you elided my suggestion that the draft > argue why the existing boilerplate is insufficient. We weren't ignoring it. But first we need to get consensus on an argument. I don't think fair use is sufficient. That might be acceptable for some examples given (e.g., quoting one or two sentences in API documentation), but would not be acceptable for the examples I gave of using the text as a basis for a mapping for a new codec into Ogg, or a new mapping of Opus into some other container. I mean, IANAL, but my understanding is that both of those would go against the spirit of Folsom v. Marsh and not qualify for fair use. > It _is_ fairly clear to me that the kind of change you're asking for is > not really specific to this draft, though. Well, the specific thing about this draft is that we wish to include the XML source as documentation alongside an open-source software library, with all of the usual open-source rights associated with that. That is not a property of every draft, at least (for example, it was not a property of RFC 7007). > The community developed a set of acceptable boilerplate text blocks. The > draft should use what we have, or convince the community that we need to > change what we allow for RFCs. Reading what the community said in Section 4.4 of RFC 5377, it says, "There is no consensus at this time to permit the use of text from RFCs in contexts where the right to modify the text is required. The authors of IETF Contributions may be able and willing to grant such rights independently of the rights they have granted to the IETF by making the Contribution." We are able and willing. If adding an additional boilerplate text block is not the way to go about it (and I have no particular ties to that solution, we were simply doing what had been done before with RFC 6716), what should we do? From nobody Tue Feb 2 14:46:38 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94CB1A0173; Tue, 2 Feb 2016 14:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 KBBEQ6LhTbGP; Tue, 2 Feb 2016 14:46:32 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1281A0171; Tue, 2 Feb 2016 14:46:31 -0800 (PST) Received: from BLUPR17MB0275.namprd17.prod.outlook.com (10.162.235.146) by BLUPR17MB0275.namprd17.prod.outlook.com (10.162.235.146) with Microsoft SMTP Server (TLS) id 15.1.396.15; Tue, 2 Feb 2016 22:46:11 +0000 Received: from BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) by BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) with mapi id 15.01.0396.020; Tue, 2 Feb 2016 22:46:11 +0000 From: Stephan Wenger To: "Timothy B. Terriberry" , Robert Sparks , Ron Thread-Topic: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard Thread-Index: AQHRWUOYu4dc40trYEmucQwFwKPFWJ8R0sEAgAdxvQCAABqZAP//f0mA Date: Tue, 2 Feb 2016 22:46:10 +0000 Message-ID: <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> <56B12D2A.4020906@xiph.org> In-Reply-To: <56B12D2A.4020906@xiph.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: xiph.org; dkim=none (message not signed) header.d=none;xiph.org; dmarc=none action=none header.from=stewe.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [50.174.30.183] x-microsoft-exchange-diagnostics: 1; BLUPR17MB0275; 5:buNjcbX+SyYfIM7m0G1WwFLIVvIPllPhaCBYizEWXYrOTGE3SlNorP3wYlp0u7Ph0iHHDB2eW4/tPoSWIelTXworKaW63WulfM6SzxaIxfbPg51Xw/am6R01DZYN2/KXASyyRdzABn4DV7KfaW7BkQ==; 24:WBVHn3g/3pg73GpNvOu964VDjzm2JOQHGC/2AsK5k+1vwrmO0B5wdhflAFDROo8bYSJXVsXHDbWQx3aXAPQou4XKnV96Zeh3uyz5kqk7TjM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR17MB0275; x-ms-office365-filtering-correlation-id: 746107f1-c225-4c14-4b35-08d32c22a5be x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR17MB0275; BCL:0; PCL:0; RULEID:; SRVR:BLUPR17MB0275; x-forefront-prvs: 084080FC15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(54356999)(19580405001)(5008740100001)(19580395003)(36756003)(76176999)(5001960100002)(50986999)(86362001)(82746002)(66066001)(11100500001)(106116001)(99286002)(15975445007)(586003)(10400500002)(83716003)(2900100001)(2950100001)(1220700001)(102836003)(1096002)(77096005)(3846002)(33656002)(6116002)(5002640100001)(2906002)(3280700002)(3660700001)(40100003)(5001770100001)(122556002)(87936001)(92566002)(93886004)(5004730100002)(4326007)(189998001)(230783001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR17MB0275; H:BLUPR17MB0275.namprd17.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2016 22:46:10.5281 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR17MB0275 Archived-At: Cc: "codec-chairs@ietf.org" , "codec@ietf.org" , "ietf@ietf.org" , "draft-ietf-codec-oggopus@ietf.org" Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 22:46:37 -0000 U2VlIGJlbG93Og0KDQoNCg0KDQpPbiAyLzIvMTYsIDE0OjI2LCAiY29kZWMgb24gYmVoYWxmIG9m IFRpbW90aHkgQi4gVGVycmliZXJyeSIgPGNvZGVjLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxm IG9mIHR0ZXJyaWJlQHhpcGgub3JnPiB3cm90ZToNCg0KPlvigKZdDQo+DQo+V2UgYXJlIGFibGUg YW5kIHdpbGxpbmcuIElmIGFkZGluZyBhbiBhZGRpdGlvbmFsIGJvaWxlcnBsYXRlIHRleHQgYmxv Y2sgDQo+aXMgbm90IHRoZSB3YXkgdG8gZ28gYWJvdXQgaXQgKGFuZCBJIGhhdmUgbm8gcGFydGlj dWxhciB0aWVzIHRvIHRoYXQgDQo+c29sdXRpb24sIHdlIHdlcmUgc2ltcGx5IGRvaW5nIHdoYXQg aGFkIGJlZW4gZG9uZSBiZWZvcmUgd2l0aCBSRkMgNjcxNiksIA0KPndoYXQgc2hvdWxkIHdlIGRv Pw0KDQpUYWtlIHRoZSB0ZXh0LCBtaW51cyBSRkMgYm9pbGVycGxhdGUgYW5kIGZvcm1hdHRpbmcs IGFuZCBwdWJsaXNoIGl0IHdoZXJldmVyIGFuZCBob3dldmVyIHlvdSB3YW50LCBidXQgbm90IGlu IGEgZm9ybSB0aGF0IGNvdWxkIGJlIGNvbmZ1c2VkIHdpdGggYW4gUkZDLiAgVGhhdOKAmXMgYSBs ZWFzdCBteSByZWNvbGxlY3Rpb24gb2YgdGhlIHNwaXJpdCBvZiB0aGUgZGlzY3Vzc2lvbnMgd2Ug aGFkIHdoZW4gZGVsaWJlcmF0aW5nIFJGQyA1Mzc3LiAgQXQgdGhlIHRpbWUsIG15IHJlY29sbGVj dGlvbiBvZiB0aGUgY29uc2Vuc3VzIHdhcyB0aGF0IHdlIHNwZWNpZmljYWxseSBESUQgTk9UIHdh bnQgdG8gZ2l2ZSBvcGVuIHNvdXJjZSBmb2xrcyB0aGUgb3B0aW9uIHRvIHRha2UgYW4gUkZDIGFu ZCDigJxydW4gd2l0aCBpdOKAnS4gIERlYmlhbiBhbmQgaXRzIHJlcXVpcmVtZW50cyB3ZXJlIHNw ZWNpZmljYWxseSBtZW50aW9uZWQgdGhlbi4NCg0KU3RlcGhhbg0KDQo+DQo+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5jb2RlYyBtYWlsaW5nIGxpc3QN Cj5jb2RlY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y29kZWMNCg== From nobody Tue Feb 2 14:51:29 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E7B1A0197; Tue, 2 Feb 2016 14:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 M7oDaLfiNdSX; Tue, 2 Feb 2016 14:51:22 -0800 (PST) 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 543861A0196; Tue, 2 Feb 2016 14:51:22 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 01D74C4042; Tue, 2 Feb 2016 22:51:22 +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 yN5kn0rhQOI3; Tue, 2 Feb 2016 22:51:21 +0000 (UTC) Received: from [10.252.26.95] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id B33ACC3FE0; Tue, 2 Feb 2016 22:51:21 +0000 (UTC) Message-ID: <56B132E9.504@xiph.org> Date: Tue, 02 Feb 2016 14:51:21 -0800 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: Stephan Wenger , Robert Sparks , Ron References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> <56B12D2A.4020906@xiph.org> <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> In-Reply-To: <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "codec-chairs@ietf.org" , "codec@ietf.org" , "ietf@ietf.org" , "draft-ietf-codec-oggopus@ietf.org" Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 22:51:26 -0000 Stephan Wenger wrote: > Take the text, minus RFC boilerplate and formatting, and publish it wherever and however you want, but not in a form that could be confused with an RFC. That’s a least my recollection of the spirit of the discussions we had when deliberating RFC 5377. At the time, my recollection of the consensus was that we specifically DID NOT want to give open source folks the option to take an RFC and “run with it”. Debian and its requirements were specifically mentioned then. Is it your opinion that the XML source for the latest draft (which includes instructions to produce the boilerplate and formatting, but not the actual boilerplate and formatting) would qualify as "not in a form that could be confused with an RFC"? From nobody Tue Feb 2 14:54:45 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7051A01E7; Tue, 2 Feb 2016 14:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 KMZTQNYeQyHr; Tue, 2 Feb 2016 14:54:37 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A7A01A01D8; Tue, 2 Feb 2016 14:54:36 -0800 (PST) Received: from BLUPR17MB0275.namprd17.prod.outlook.com (10.162.235.146) by BLUPR17MB0273.namprd17.prod.outlook.com (10.162.235.144) with Microsoft SMTP Server (TLS) id 15.1.396.15; Tue, 2 Feb 2016 22:54:34 +0000 Received: from BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) by BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) with mapi id 15.01.0396.020; Tue, 2 Feb 2016 22:54:33 +0000 From: Stephan Wenger To: "Timothy B. Terriberry" , Robert Sparks , Ron Thread-Topic: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard Thread-Index: AQHRWUOYu4dc40trYEmucQwFwKPFWJ8R0sEAgAdxvQCAABqZAP//f0mAgACHkID//3rIAA== Date: Tue, 2 Feb 2016 22:54:33 +0000 Message-ID: <780287DC-988D-4279-86B9-58932506698A@stewe.org> References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> <56B12D2A.4020906@xiph.org> <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> <56B132E9.504@xiph.org> In-Reply-To: <56B132E9.504@xiph.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: xiph.org; dkim=none (message not signed) header.d=none;xiph.org; dmarc=none action=none header.from=stewe.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [50.174.30.183] x-microsoft-exchange-diagnostics: 1; BLUPR17MB0273; 5:0rQIk/9FfJxUD+RtgsssQ2zwllusRlvilD3EK7SzH69ij6enrOwU4RszGx6imsfbsiRo8jaKv9q1qSz7SR2UL1SHLeCs+dQBWqIlavfrdRE3XVB2I3NM7vLx8H0E6+chQajKMeNX1MUX3xkvouMWMA==; 24:ghecEiKTZE1xAWZrdws6Dp24UgQ1v6mLyKIMnO7AEVdjKvw2Cz/ZMU65aP4KAPWP4bmHhjnCqAGd7e65zOHZ1nrtk3CF1HX7BmMImleP5kc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR17MB0273; x-ms-office365-filtering-correlation-id: 76309365-d4cf-48fd-643b-08d32c23d174 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR17MB0273; BCL:0; PCL:0; RULEID:; SRVR:BLUPR17MB0273; x-forefront-prvs: 084080FC15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(106116001)(50986999)(54356999)(76176999)(83716003)(36756003)(10400500002)(82746002)(2950100001)(2900100001)(93886004)(86362001)(5002640100001)(230783001)(99286002)(77096005)(87936001)(3280700002)(5001960100002)(19580405001)(19580395003)(1096002)(3660700001)(2906002)(4326007)(1220700001)(40100003)(189998001)(122556002)(586003)(5001770100001)(33656002)(92566002)(5008740100001)(6116002)(66066001)(102836003)(3846002)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR17MB0273; H:BLUPR17MB0275.namprd17.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <99FFBFB517D0C949820794C0EEE6168D@namprd17.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2016 22:54:33.6259 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR17MB0273 Archived-At: Cc: "codec-chairs@ietf.org" , "codec@ietf.org" , "ietf@ietf.org" , "draft-ietf-codec-oggopus@ietf.org" Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 22:54:42 -0000 WWVzLCB1bmZvcnR1bmF0ZWx5Lg0KU3RlcGhhbg0KDQoNCg0KDQpPbiAyLzIvMTYsIDE0OjUxLCAi VGltb3RoeSBCLiBUZXJyaWJlcnJ5IiA8dHRlcnJpYmVAeGlwaC5vcmc+IHdyb3RlOg0KDQo+U3Rl cGhhbiBXZW5nZXIgd3JvdGU6DQo+PiBUYWtlIHRoZSB0ZXh0LCBtaW51cyBSRkMgYm9pbGVycGxh dGUgYW5kIGZvcm1hdHRpbmcsIGFuZCBwdWJsaXNoIGl0IHdoZXJldmVyIGFuZCBob3dldmVyIHlv dSB3YW50LCBidXQgbm90IGluIGEgZm9ybSB0aGF0IGNvdWxkIGJlIGNvbmZ1c2VkIHdpdGggYW4g UkZDLiAgVGhhdOKAmXMgYSBsZWFzdCBteSByZWNvbGxlY3Rpb24gb2YgdGhlIHNwaXJpdCBvZiB0 aGUgZGlzY3Vzc2lvbnMgd2UgaGFkIHdoZW4gZGVsaWJlcmF0aW5nIFJGQyA1Mzc3LiAgQXQgdGhl IHRpbWUsIG15IHJlY29sbGVjdGlvbiBvZiB0aGUgY29uc2Vuc3VzIHdhcyB0aGF0IHdlIHNwZWNp ZmljYWxseSBESUQgTk9UIHdhbnQgdG8gZ2l2ZSBvcGVuIHNvdXJjZSBmb2xrcyB0aGUgb3B0aW9u IHRvIHRha2UgYW4gUkZDIGFuZCDigJxydW4gd2l0aCBpdOKAnS4gIERlYmlhbiBhbmQgaXRzIHJl cXVpcmVtZW50cyB3ZXJlIHNwZWNpZmljYWxseSBtZW50aW9uZWQgdGhlbi4NCj4NCj5JcyBpdCB5 b3VyIG9waW5pb24gdGhhdCB0aGUgWE1MIHNvdXJjZSBmb3IgdGhlIGxhdGVzdCBkcmFmdCAod2hp Y2ggDQo+aW5jbHVkZXMgaW5zdHJ1Y3Rpb25zIHRvIHByb2R1Y2UgdGhlIGJvaWxlcnBsYXRlIGFu ZCBmb3JtYXR0aW5nLCBidXQgbm90IA0KPnRoZSBhY3R1YWwgYm9pbGVycGxhdGUgYW5kIGZvcm1h dHRpbmcpIHdvdWxkIHF1YWxpZnkgYXMgIm5vdCBpbiBhIGZvcm0gDQo+dGhhdCBjb3VsZCBiZSBj b25mdXNlZCB3aXRoIGFuIFJGQyI/DQo= From nobody Tue Feb 2 15:40:59 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F170C1A90C1 for ; Tue, 2 Feb 2016 15:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.913 X-Spam-Level: X-Spam-Status: No, score=-3.913 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 ugDbqrOkxsDh for ; Tue, 2 Feb 2016 15:40:55 -0800 (PST) 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 A93AC1A01A5 for ; Tue, 2 Feb 2016 15:40:55 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 4950DC3C6E; Tue, 2 Feb 2016 23:40:55 +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 vGNIfUdCmmDl; Tue, 2 Feb 2016 23:40:55 +0000 (UTC) Received: from [10.252.26.95] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 227D1C1989; Tue, 2 Feb 2016 23:40:55 +0000 (UTC) Message-ID: <56B13E86.107@xiph.org> Date: Tue, 02 Feb 2016 15:40:54 -0800 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: Mark Harris , "codec@ietf.org" References: <20160128183904.8076.80585.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [codec] I-D Action: draft-ietf-codec-oggopus-11.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 23:40:57 -0000 > It is possible to run an Opus decoder at other sampling rates, but > a sampling rate of 48 kHz is sufficient to capture the full audio > bandwidth of any Opus packet. Therefore, the value in the granule > position field always counts samples assuming a 48 kHz decoding rate > ... I think this loses the important property that the other sample rates evenly divide 48 kHz. That property implies that a 48 kHz rate is sufficient to capture sample-accurate timing information without having to introduce specific rules around propagation of rounding errors, etc., regardless of the sample rate used at either endpoint. That is why we chose 48 kHz instead of say, 40 kHz (which would also have been sufficient to capture the full audio bandwidth, but would have made sample-accurate operations quite cumbersome). Would you be satisfied with saying, "It is possible to run the decoder in the Opus reference implementation at other sampling rates..." instead? From nobody Tue Feb 2 19:09:01 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3FD1B3228; Tue, 2 Feb 2016 19:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 B9cSgfDeO-Z2; Tue, 2 Feb 2016 19:08:58 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by ietfa.amsl.com (Postfix) with ESMTP id E7B4D1B3225; Tue, 2 Feb 2016 19:08:56 -0800 (PST) Received: from ppp14-2-77-60.lns21.adl6.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.77.60]) by ipmail04.adl6.internode.on.net with ESMTP; 03 Feb 2016 13:37:02 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 772B6FFC6C; Wed, 3 Feb 2016 13:37:01 +1030 (ACDT) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pg4SWQ0x7Pii; Wed, 3 Feb 2016 13:37:00 +1030 (ACDT) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailservice.shelbyville.oz (Postfix) with ESMTPS id A2EEFFF83C; Wed, 3 Feb 2016 13:37:00 +1030 (ACDT) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 8FC4D80470; Wed, 3 Feb 2016 13:37:00 +1030 (ACDT) Date: Wed, 3 Feb 2016 13:37:00 +1030 From: Ron To: Robert Sparks Message-ID: <20160203030700.GN3153@hex.shelbyville.oz> References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B116DA.9010507@nostrum.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: ietf@ietf.org, codec@ietf.org, codec-chairs@ietf.org, draft-ietf-codec-oggopus@ietf.org Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 03:09:00 -0000 On Tue, Feb 02, 2016 at 02:51:38PM -0600, Robert Sparks wrote: > Ben's recent response to Tim captures the main point, but to reinforce > what's said there: > > We learned a lot as a community from going through the development of > RFC6716, and there's been strong sentiment expressed that we wouldn't do > things like produce normative code again. I think if we were able to repeat > the exercise fresh, knowing what we learned, that we also wouldn't have made > this copyright change in just this way. However, the most relevant point is > that with RFC6716 we at least had an exceptional condition to point to. This > draft does not have that. This draft does however include things which are directly applicable to any code which might implement it, even if they don't appear in it in the form of "normative code". At the very least things like the header definitions and downmixing matrices would seem to fall quite squarely under what is described in RFC 5377 4.3, which says: Rights Granted for Implementing Based on IETF Contributions ... As such, the rough consensus is that the IETF Trust is to grant rights such that code components of IETF Contributions can be extracted, modified, and used by anyone in any way desired. And above that gives examples of things considered "code components" and a rationale which I think is congruent with many of the reasons we've given for thinking this is needed in this case. The nature of a codec mapping means this document is full of such things in various places, and we're keen to avoid the mistakes which severely limited the use of RFC 3951, which people could only use by distributing a parser to extract them from the RFC and compile them on the end user's machine. > It is not clear to me how the things you are hoping to achieve with this > extra language are not already available to you (under fair use for > example). There is no international consensus on what constitutes "fair use", and the IETF has no change control over the exceptions that regional jurisdictions might grant to the terms of the explicit licence granted. If the intention is to allow things, we should say explicitly what we intend to allow. I think we have reasonably broad agreement on what "common sense" says people should be allowed to do with this text, we just need to agree on the language which actually allows them to do that - without needing to resort to external 'loopholes'. > In the copy below, you elided my suggestion that the draft argue > why the existing boilerplate is insufficient. Sorry, that didn't mean I was ignoring it. To me that question was implicit, and I thought the previous discussion that you referred to in that had already answered it - which is why I was trying to understand the basis upon which you thought it didn't in this case. > It _is_ fairly clear to me that the kind of change you're asking for is not > really specific to this draft, though. > The community developed a set of acceptable boilerplate text blocks. The > draft should use what we have, or convince the community that we need to > change what we allow for RFCs. I'm not actually sure that the things which we do need to make this a practically useful document are actually applicable to *all* RFCs. I do think they may be applicable to many more of them, and in more parts of them, than have currently addressed this question head on. But this discussion seems to make it clear that we are still at the "understanding the problem" stage of fixing that, which makes it a bit premature to be heading straight for "propose a general solution for all documents" on the basis of what this one needs. The IETF clearly recognises there is nuance in what rights it needs to grant individual documents to maximise their usefulness. RFC 5377 defines some broad categories for the type of rights which may be required in different cases. RFC 5744 extends that and requires independent submissions published as RFCs to always have the sort of liberal grant that we've requested here, except in exceptional circumstances. I think the intended uses for *this* document falls across a range of the categories recommended for use in RFC 5377 section 4. And that unless we want to get into a horrible game of trying to individually salami slice which clauses in it most fit into which categories for which users, the only sensible and pragmatic choice from that set which could be applied singly is 4.3. Which is essentially what asking for this extra header text has done. I think that's a somewhat blunt instrument, and I agree there are other ways that we can achieve the same outcome, and I agree that there are questions here which the community will at some point need to address as it continues to refine the boilerplate options which it recommends. Personally, I think that separately publishing the content of this document, under a licence equivalent to what 4.3 would allow, is not the option which minimises the risk of having people diverge from this document in ways I think we all agree would be undesirable. But I think it does need to be available under such a licence to cover all the use cases we can already reasonably envisage. Which is why I think the best option is to have a single publication as an RFC, which people can only exercise the rights of 4.3 to if they no longer claim the result is still an RFC. And I think the method used for 6716 fits this well, and falls within the existing recommendations. Reasonable people could disagree with that though, so I think the question as it relates to this document is whether the consensus is that the IETF is best served by doing this, and remaining the single authoritative source until someone does exercise that right. Or whether the authors should publish a separate grant, which would effectively create two sources of this document immediately, in its unmodified form. One of which has a less restrictive licence than the other, and (as Gresham's Law tells us) may then be the most likely to become the common currency with the widest circulation. I think that's a question the community does need to form a good understanding of and address, but the immediate question is what is the best answer for us to employ with this document? The broader question will need to consider many more cases based on the needs of many more documents, but I think this is a good example of one of those cases for us to explore solutions to. Cheers, Ron From nobody Tue Feb 2 19:39:09 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4808A1B3232; Tue, 2 Feb 2016 19:39:07 -0800 (PST) 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 Yu-UIzVpKE4s; Tue, 2 Feb 2016 19:39:03 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by ietfa.amsl.com (Postfix) with ESMTP id C31A81B32D3; Tue, 2 Feb 2016 19:39:01 -0800 (PST) Received: from ppp14-2-77-60.lns21.adl6.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.77.60]) by ipmail04.adl6.internode.on.net with ESMTP; 03 Feb 2016 14:09:01 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 10B07FFC6C; Wed, 3 Feb 2016 14:09:00 +1030 (ACDT) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9DSxkF_JIziQ; Wed, 3 Feb 2016 14:08:56 +1030 (ACDT) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 12FC3FF83C; Wed, 3 Feb 2016 14:08:56 +1030 (ACDT) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 003FD80470; Wed, 3 Feb 2016 14:08:55 +1030 (ACDT) Date: Wed, 3 Feb 2016 14:08:55 +1030 From: Ron To: Stephan Wenger Message-ID: <20160203033855.GO3153@hex.shelbyville.oz> References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> <56B12D2A.4020906@xiph.org> <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "ietf@ietf.org" , "draft-ietf-codec-oggopus@ietf.org" , "codec@ietf.org" , "codec-chairs@ietf.org" Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 03:39:07 -0000 Hi Stephan, On Tue, Feb 02, 2016 at 10:46:10PM +0000, Stephan Wenger wrote: > On 2/2/16, 14:26, "codec on behalf of Timothy B. Terriberry" wrote: > > >[…] > > > >We are able and willing. If adding an additional boilerplate text block > >is not the way to go about it (and I have no particular ties to that > >solution, we were simply doing what had been done before with RFC 6716), > >what should we do? > > Take the text, minus RFC boilerplate and formatting, and publish it > wherever and however you want, but not in a form that could be > confused with an RFC. That's *exactly* what this grant allows, yes :) The only difference is it defers that actually happening until someone actually has a compelling reason to do so, rather than preemptively creating that situation even if ultimately nobody ever does. > That’s a least my recollection of the spirit of the discussions we had > when deliberating RFC 5377. RFC 5377 is Informational and offers a number of options for rights grants. Including the option we are asking to exercise here. That does not conflict with RFC 5378 though (aka BCP 78) which says: Ownership of the copyright in an RFC does not diminish the Contributors' rights in their underlying contributions, but it does prevent anyone other than the IETF Trust (and its licensees) from republishing or modifying an RFC in RFC format. In this respect, Contributors are treated the same as anybody else: though they may extract and republish their own Contributions without limitation, they may not do so in the RFC format used by the IETF. And while this principle (which is included in Section 5.9 below) may appear to be new to the IETF, it actually reflects historical practice and has been observed for many years through the inclusion of an ISOC or IETF Trust copyright notice on all RFC documents since the publication of RFC 2026. > At the time, my recollection of the consensus was that we specifically > DID NOT want to give open source folks the option to take an RFC and > “run with it”. And we are specifically not proposing to give *anyone*, open source or otherwise, "the option to take an RFC and “run with it”" ... We're trying to find consensus on the best way to apply BCP 78 and the options outlined in RFC 5377 to the needs of this document, in a way that best matches the needs of its intended users to the best interests of the IETF. > Debian and its requirements were specifically mentioned then. The problem we are trying to find a solution for here is not in any way specific to Debian, or even specific to "open source folks". I may wear a hat from both groups, but here I speak "for Debian" in the same way that I speak "for the IETF". As an individual participant. And since this is an IETF list, and not a Debian one, I speak with only the best interests of the IETF as the focus of my contributions to this question. I'm not yet convinced that forking this document immediately is the best solution here, or that we have consensus on that being the best approach, but that does seem to be the question we are now looking to answer in the best way that the collective wisdom here can. Cheers, Ron From nobody Tue Feb 2 20:19:22 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2488C1A026C; Tue, 2 Feb 2016 20:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 wXbwF1vN5fbY; Tue, 2 Feb 2016 20:19:17 -0800 (PST) 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 E68091A026A; Tue, 2 Feb 2016 20:19:17 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 88584C42EC; Wed, 3 Feb 2016 04:19:17 +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 tveJ8osc91j7; Wed, 3 Feb 2016 04:19:17 +0000 (UTC) Received: from [172.17.0.49] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 051A5BFF51; Wed, 3 Feb 2016 04:19:17 +0000 (UTC) Message-ID: <56B17FC4.7000901@xiph.org> Date: Tue, 02 Feb 2016 20:19:16 -0800 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: Ron , Stephan Wenger References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> <56B12D2A.4020906@xiph.org> <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> <20160203033855.GO3153@hex.shelbyville.oz> In-Reply-To: <20160203033855.GO3153@hex.shelbyville.oz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-codec-oggopus@ietf.org" , "codec-chairs@ietf.org" , "codec@ietf.org" , "ietf@ietf.org" Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 04:19:19 -0000 Ron wrote: > And we are specifically not proposing to give *anyone*, open source or > otherwise, "the option to take an RFC and “run with it”" ... > > We're trying to find consensus on the best way to apply BCP 78 and the > options outlined in RFC 5377 to the needs of this document, in a way > that best matches the needs of its intended users to the best interests > of the IETF. It seems to me like putting a BSD copyright header in an XML comment at the top of the XML source file and dropping Section 13 from the draft would resolve all of the issues, if everyone agrees that is an acceptable thing to do. Ron? From nobody Tue Feb 2 21:35:53 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB251A1B71; Tue, 2 Feb 2016 21:35:51 -0800 (PST) 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 oTOKMoQ3f-dY; Tue, 2 Feb 2016 21:35:50 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5C77E1A1B6A; Tue, 2 Feb 2016 21:35:49 -0800 (PST) Received: from ppp14-2-77-60.lns21.adl6.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.77.60]) by ipmail04.adl6.internode.on.net with ESMTP; 03 Feb 2016 16:05:48 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 53AA4FFC9E; Wed, 3 Feb 2016 16:05:47 +1030 (ACDT) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QV9Q7TP7ZUaE; Wed, 3 Feb 2016 16:05:46 +1030 (ACDT) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailservice.shelbyville.oz (Postfix) with ESMTPS id BA677FFAA4; Wed, 3 Feb 2016 16:05:46 +1030 (ACDT) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id A97C680470; Wed, 3 Feb 2016 16:05:46 +1030 (ACDT) Date: Wed, 3 Feb 2016 16:05:46 +1030 From: Ron To: "Timothy B. Terriberry" Message-ID: <20160203053546.GP3153@hex.shelbyville.oz> References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> <56B12D2A.4020906@xiph.org> <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> <20160203033855.GO3153@hex.shelbyville.oz> <56B17FC4.7000901@xiph.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56B17FC4.7000901@xiph.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "draft-ietf-codec-oggopus@ietf.org" , "codec@ietf.org" , "codec-chairs@ietf.org" , "ietf@ietf.org" Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 05:35:51 -0000 On Tue, Feb 02, 2016 at 08:19:16PM -0800, Timothy B. Terriberry wrote: > Ron wrote: > >And we are specifically not proposing to give *anyone*, open source or > >otherwise, "the option to take an RFC and “run with it”" ... > > > >We're trying to find consensus on the best way to apply BCP 78 and the > >options outlined in RFC 5377 to the needs of this document, in a way > >that best matches the needs of its intended users to the best interests > >of the IETF. > > It seems to me like putting a BSD copyright header in an XML comment at the > top of the XML source file and dropping Section 13 from the draft would > resolve all of the issues, if everyone agrees that is an acceptable thing to > do. Ron? It leaves us with the issue of creating a perverse incentive for some parties to prefer distributing the "non-rfc" version over the official RFC - even when they themselves have not modified it and don't have any direct plans to. And in some cases, will force their hand, making that the only version they can redistribute ... But aside from that, I think it would cover the practical problems which we currently see for implementors needing to use this in their own work. Which is the most immediate issue here. It's not my first preference, and not what I think serves the IETF's interest best, for all of the reasons I've outlined earlier in this thread -- but if we can't get consensus for adding a RFC 5377 4.3 exception to add the "Rights Granted for Implementing" to it, and nobody has a better suggestion, then I can accept this option as the pragmatic way we should proceed here. I think both options are in the scope of current recommendations to allow, but I'll defer to peer review on that. From nobody Tue Feb 2 22:22:58 2016 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A71441A6EE8; Tue, 2 Feb 2016 22:22:47 -0800 (PST) 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.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160203062247.24521.57445.idtracker@ietfa.amsl.com> Date: Tue, 02 Feb 2016 22:22:47 -0800 Archived-At: Cc: codec@ietf.org Subject: [codec] I-D Action: draft-ietf-codec-oggopus-12.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 06:22:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Wideband Audio Codec Working Group of the IETF. Title : Ogg Encapsulation for the Opus Audio Codec Authors : Timothy B. Terriberry Ron Lee Ralph Giles Filename : draft-ietf-codec-oggopus-12.txt Pages : 32 Date : 2016-02-02 Abstract: This document defines the Ogg encapsulation for the Opus interactive speech and audio codec. This allows data encoded in the Opus format to be stored in an Ogg logical bitstream. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-codec-oggopus-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-codec-oggopus-12 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 Feb 2 22:26:48 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE681A6F13; Tue, 2 Feb 2016 22:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 z8bAPklYfPM5; Tue, 2 Feb 2016 22:26:46 -0800 (PST) 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 423841A6F05; Tue, 2 Feb 2016 22:26:46 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id D354EC4944; Wed, 3 Feb 2016 06:26:45 +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 tHOOoEWpeL9I; Wed, 3 Feb 2016 06:26:45 +0000 (UTC) Received: from [172.17.0.49] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 1FA78C4935; Wed, 3 Feb 2016 06:26:45 +0000 (UTC) Message-ID: <56B19DA4.7040602@xiph.org> Date: Tue, 02 Feb 2016 22:26:44 -0800 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: Ron References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> <56B12D2A.4020906@xiph.org> <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> <20160203033855.GO3153@hex.shelbyville.oz> <56B17FC4.7000901@xiph.org> <20160203053546.GP3153@hex.shelbyville.oz> In-Reply-To: <20160203053546.GP3153@hex.shelbyville.oz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-codec-oggopus@ietf.org" , "codec@ietf.org" , "codec-chairs@ietf.org" , "ietf@ietf.org" Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 06:26:47 -0000 Ron wrote: > But aside from that, I think it would cover the practical problems > which we currently see for implementors needing to use this in their > own work. Which is the most immediate issue here. I've gone ahead and published a new version implementing this suggestion. Please holler if I've missed anything. Thank you everyone for your patience on this. From nobody Wed Feb 3 03:27:55 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CE81B3420 for ; Wed, 3 Feb 2016 03:27:54 -0800 (PST) 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 fMVakklQnbzK for ; Wed, 3 Feb 2016 03:27:53 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::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 4D6701B341D for ; Wed, 3 Feb 2016 03:27:53 -0800 (PST) Received: by mail-ig0-x232.google.com with SMTP id z14so83373617igp.1 for ; Wed, 03 Feb 2016 03:27:53 -0800 (PST) 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:content-type; bh=88vKuA7fnISYlUzAJ3i8s3uhAvJkOsAxT70poWCOKuY=; b=C36ZpeCpKPACxgPmO1ZD52LLHB8xGHvLCWvstIZmJQDFszKGE3G64Nz/d+dOpNpZPL T4XlbYT9ZXImKdUYkpHOh+6+Ao54MPwenBBZYMRXxjDjE04nDtQigYPLivai/zGzAqLU cgNOS4eKMiL5TstNSSbOu2aMWqcemZ5ZPE4xRQMzBkWIprYfaAJuKeuQlk5m9uF9r6D2 3z1jDqoqOeM3uoFsfyPLEmuVsgiPWE9Ae4r94H5a3yTAHyNW7n4asZukPdcvUsUWYQvc U6F6QAgPCaud7mw9ZJKhXgylhvR1eH7LAjqYpl82pNLurKJY5GTXafTmKlRfonHy/5EP bzoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=88vKuA7fnISYlUzAJ3i8s3uhAvJkOsAxT70poWCOKuY=; b=JmsYJe5Vyibg6QjiGoTQpdlMVlfzTZV5fBqAN4a5rbUxlWUQRJjDCSChfYfCIayUuM Hjdp7OzN0Y4LZM97uV6UfMrdkUTlVOlBMA/S5qXvJlu1rALK3rg7qnAHcz4490YVU58Y EQEaT//MDUSVsaVwbsg/FuxQPS+1F25kOlxdewLfUwT2P3ECqRzX4Nv/+kH8HT7Y8xP1 fNGcsu8nr3kos7LiwuEtNZiQFmSXm8GDtB/bH7X81/gcFlqQbFI5FZqAZwk7D90VnFf3 yJ44TXeGo4MbryCyRH2D2uFL4N2yiNk787mq9/UhJHwzAmqJjzKCOUbbpW5y01EyDFXr 76GQ== X-Gm-Message-State: AG10YORmSBiTpmwsLAe+sWnJ6F56xUulFxhbukk3WuX7gVr2H2hj8dJIvV7Qx5g+VoBDvQOGvhwIKBpmiMgwsw== MIME-Version: 1.0 X-Received: by 10.50.20.197 with SMTP id p5mr23619974ige.89.1454498872763; Wed, 03 Feb 2016 03:27:52 -0800 (PST) Sender: markh.sj@gmail.com Received: by 10.107.10.96 with HTTP; Wed, 3 Feb 2016 03:27:52 -0800 (PST) In-Reply-To: <56B13E86.107@xiph.org> References: <20160128183904.8076.80585.idtracker@ietfa.amsl.com> <56B13E86.107@xiph.org> Date: Wed, 3 Feb 2016 03:27:52 -0800 X-Google-Sender-Auth: cgIZUzgDHHWvvU9c6S8hlkKWWEI Message-ID: From: Mark Harris To: "Timothy B. Terriberry" , "codec@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [codec] I-D Action: draft-ietf-codec-oggopus-11.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 11:27:54 -0000 >> It is possible to run an Opus decoder at other sampling rates, but >> a sampling rate of 48 kHz is sufficient to capture the full audio >> bandwidth of any Opus packet. Therefore, the value in the granule >> position field always counts samples assuming a 48 kHz decoding rate >> ... > > > I think this loses the important property that the other sample rates evenly > divide 48 kHz. That property implies that a 48 kHz rate is sufficient to > capture sample-accurate timing information without having to introduce > specific rules around propagation of rounding errors, etc., regardless of > the sample rate used at either endpoint. That is why we chose 48 kHz instead > of say, 40 kHz (which would also have been sufficient to capture the full > audio bandwidth, but would have made sample-accurate operations quite > cumbersome). > > Would you be satisfied with saying, "It is possible to run the decoder in > the Opus reference implementation at other sampling rates..." instead? > The request that led to the additional text was a request to clarify that a fixed 48 kHz rate for the granule position is sufficiently broad to cover all needed cases. I'm not sure that an explanation based solely on the decoding rates supported by a particular implementation addresses that. If anything it actually draws attention to the question (without answering it) of whether the chosen fixed rate is sufficiently broad, or is tailored to the needs of that particular implementation. How about this: "It is possible to run an Opus decoder at other sampling rates, but all Opus packets encode samples at a sampling rate that evenly divides 48 kHz. Therefore, the value in the granule position field always counts samples assuming a 48 kHz decoding rate..." - Mark From nobody Wed Feb 3 05:42:09 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29EF1AC3F3 for ; Wed, 3 Feb 2016 05:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 Qh90_HcEwqoz for ; Wed, 3 Feb 2016 05:42:03 -0800 (PST) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (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 9C56C1AC3F1 for ; Wed, 3 Feb 2016 05:42:03 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 318A8C3793; Wed, 3 Feb 2016 13:42:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8u2nUnQhi80; Wed, 3 Feb 2016 13:42:03 +0000 (UTC) Received: from [172.17.0.49] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id B0058C27F1; Wed, 3 Feb 2016 13:42:02 +0000 (UTC) Message-ID: <56B203AA.7010409@xiph.org> Date: Wed, 03 Feb 2016 05:42:02 -0800 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: Mark Harris , "codec@ietf.org" References: <20160128183904.8076.80585.idtracker@ietfa.amsl.com> <56B13E86.107@xiph.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [codec] I-D Action: draft-ietf-codec-oggopus-11.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 13:42:07 -0000 Mark Harris wrote: > How about this: > > "It is possible to run an Opus decoder at other sampling rates, but > all Opus packets encode samples at a sampling rate that evenly divides > 48 kHz. Therefore, the value in the granule position field always > counts samples assuming a 48 kHz decoding rate..." That works for me. Thanks. From nobody Wed Feb 3 07:52:37 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770771ACEC4; Wed, 3 Feb 2016 07:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 ZkO-lpVep6EP; Wed, 3 Feb 2016 07:52:33 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 AD4101ACDFF; Wed, 3 Feb 2016 07:52:33 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u13FqWe5017090 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 3 Feb 2016 09:52:32 -0600 (CST) (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.10] From: "Ben Campbell" To: "Timothy B. Terriberry" Date: Wed, 03 Feb 2016 09:52:32 -0600 Message-ID: In-Reply-To: <56B17FC4.7000901@xiph.org> References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> <56B12D2A.4020906@xiph.org> <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> <20160203033855.GO3153@hex.shelbyville.oz> <56B17FC4.7000901@xiph.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5213) Archived-At: Cc: "draft-ietf-codec-oggopus@ietf.org" , "codec@ietf.org" , "codec-chairs@ietf.org" , "ietf@ietf.org" Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 15:52:35 -0000 On 2 Feb 2016, at 22:19, Timothy B. Terriberry wrote: > Ron wrote: >> And we are specifically not proposing to give *anyone*, open source >> or >> otherwise, "the option to take an RFC and “run with it”" ... >> >> We're trying to find consensus on the best way to apply BCP 78 and >> the >> options outlined in RFC 5377 to the needs of this document, in a way >> that best matches the needs of its intended users to the best >> interests >> of the IETF. > > It seems to me like putting a BSD copyright header in an XML comment > at the top of the XML source file and dropping Section 13 from the > draft would resolve all of the issues, if everyone agrees that is an > acceptable thing to do. Ron? I think that's acceptable in theory. In practice, keep in mind that if someone uses xml2rfc to render the text, it's going to create IETF headers and boilerplate, at least if the "external" version of the XML uses the same settings. That's probably not what you want, regardless of whether the section 13 language stays or goes. How did this end up working for 6716? Ben. From nobody Wed Feb 3 08:11:09 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F961AD255; Wed, 3 Feb 2016 08:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 lMQWY29hcHZ4; Wed, 3 Feb 2016 08:11:03 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7331AD2A9; Wed, 3 Feb 2016 08:11:02 -0800 (PST) Received: from BLUPR17MB0275.namprd17.prod.outlook.com (10.162.235.146) by BLUPR17MB0273.namprd17.prod.outlook.com (10.162.235.144) with Microsoft SMTP Server (TLS) id 15.1.396.15; Wed, 3 Feb 2016 16:10:58 +0000 Received: from BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) by BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) with mapi id 15.01.0396.020; Wed, 3 Feb 2016 16:10:59 +0000 From: Stephan Wenger To: "Timothy B. Terriberry" , Ron Thread-Topic: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard Thread-Index: AQHRWUOYu4dc40trYEmucQwFwKPFWJ8R0sEAgAdxvQCAABqZAP//f0mAgADX6YCAAAtGAIAAQLuA Date: Wed, 3 Feb 2016 16:10:58 +0000 Message-ID: <9B1A525A-5ADE-4AB1-962C-DD826D86C5DA@stewe.org> References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> <56B12D2A.4020906@xiph.org> <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> <20160203033855.GO3153@hex.shelbyville.oz> <56B17FC4.7000901@xiph.org> In-Reply-To: <56B17FC4.7000901@xiph.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: xiph.org; dkim=none (message not signed) header.d=none;xiph.org; dmarc=none action=none header.from=stewe.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [50.174.30.183] x-microsoft-exchange-diagnostics: 1; BLUPR17MB0273; 5:89rDN34OiddLi5Z4Yt0TUr7e4LthNgbiH0B3gAyGLMV/QWGS7nU37imFD4m2olEqqz/1LI1iMg63Gj3iUKpSwMvCMTUTwOpZG3+k3Rvt6CedfCyw4OFtPUU/ByKA5TJ51kpHzDpGcMxPGeZoEg81pQ==; 24:OnYkZEPbp08N7Bd0yRf8nWxsOmHFfwfrkddsczzdhfb9cZ95tcw6Y8MId9aWDP2mtxXcOOMWpF79LzrFOCkiZA9LsSosKR52TuAN2jhvA0Y= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR17MB0273; x-ms-office365-filtering-correlation-id: 94b47f3d-bcd1-4578-ce32-08d32cb49ab2 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR17MB0273; BCL:0; PCL:0; RULEID:; SRVR:BLUPR17MB0273; x-forefront-prvs: 08417837C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(4326007)(3660700001)(2906002)(1220700001)(3280700002)(1096002)(5001960100002)(19580405001)(66066001)(33656002)(92566002)(102836003)(19580395003)(3846002)(6116002)(5008740100001)(189998001)(5001770100001)(122556002)(586003)(10400500002)(87936001)(40100003)(50986999)(106116001)(76176999)(54356999)(83716003)(36756003)(230783001)(99286002)(5002640100001)(2900100001)(86362001)(5004730100002)(82746002)(93886004)(2950100001)(77096005)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR17MB0273; H:BLUPR17MB0275.namprd17.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <33DCE19DAB1C7345A6D47447E6653908@namprd17.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2016 16:10:58.4422 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR17MB0273 Archived-At: Cc: "draft-ietf-codec-oggopus@ietf.org" , "codec-chairs@ietf.org" , "codec@ietf.org" , "ietf@ietf.org" Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 16:11:08 -0000 VGltLA0KDQoNCg0KT24gMi8yLzE2LCAyMDoxOSwgIlRpbW90aHkgQi4gVGVycmliZXJyeSIgPHR0 ZXJyaWJlQHhpcGgub3JnPiB3cm90ZToNCg0KPlJvbiB3cm90ZToNCj4+IEFuZCB3ZSBhcmUgc3Bl Y2lmaWNhbGx5IG5vdCBwcm9wb3NpbmcgdG8gZ2l2ZSAqYW55b25lKiwgb3BlbiBzb3VyY2Ugb3IN Cj4+IG90aGVyd2lzZSwgInRoZSBvcHRpb24gdG8gdGFrZSBhbiBSRkMgYW5kIOKAnHJ1biB3aXRo IGl04oCdIiAuLi4NCj4+DQo+PiBXZSdyZSB0cnlpbmcgdG8gZmluZCBjb25zZW5zdXMgb24gdGhl IGJlc3Qgd2F5IHRvIGFwcGx5IEJDUCA3OCBhbmQgdGhlDQo+PiBvcHRpb25zIG91dGxpbmVkIGlu IFJGQyA1Mzc3IHRvIHRoZSBuZWVkcyBvZiB0aGlzIGRvY3VtZW50LCBpbiBhIHdheQ0KPj4gdGhh dCBiZXN0IG1hdGNoZXMgdGhlIG5lZWRzIG9mIGl0cyBpbnRlbmRlZCB1c2VycyB0byB0aGUgYmVz dCBpbnRlcmVzdHMNCj4+IG9mIHRoZSBJRVRGLg0KPg0KPkl0IHNlZW1zIHRvIG1lIGxpa2UgcHV0 dGluZyBhIEJTRCBjb3B5cmlnaHQgaGVhZGVyIGluIGFuIFhNTCBjb21tZW50IGF0IA0KPnRoZSB0 b3Agb2YgdGhlIFhNTCBzb3VyY2UgZmlsZSBhbmQgZHJvcHBpbmcgU2VjdGlvbiAxMyBmcm9tIHRo ZSBkcmFmdCANCj53b3VsZCByZXNvbHZlIGFsbCBvZiB0aGUgaXNzdWVzLCBpZiBldmVyeW9uZSBh Z3JlZXMgdGhhdCBpcyBhbiANCj5hY2NlcHRhYmxlIHRoaW5nIHRvIGRvLiBSb24/DQoNCkkgYmVs aWV2ZSB0aGF0LCBldmVuIGlmIEkgd2VyZSBzbyBpbmNsaW5lZCAod2hpY2ggSeKAmW0gbm90KSwg SSBjb3VsZCBub3QgcHJldmVudCBhbnlvbmUgZnJvbSBkb3dubG9hZGluZyB0aGUgc28tbGFiZWxs ZWQgWE1MIHNvdXJjZSBmcm9tIHRoZSBJRVRGIGRhdGF0cmFja2VyIGFuZCBtb2RpZnkgaXQgaW4g YW55IHdheSBJIHdpc2guICBTbywgeWVzLCBpdCBhcHBlYXJzIHRvIG1lIHRoYXQgdGhpcyBpcyBh biBvcHRpb24gdGhhdCBzb2x2ZXMgeW91ciBwcm9ibGVtLg0KDQpIb3dldmVyLCBpdCBpcyBzdGls bCBhIHByb2NlZHVyYWwgZW5kLXJ1biBhcm91bmQgdGhlIGN1cnJlbnRseSBpbi1mb3JjZSBJRVRG IHBvc2l0aW9uIHRoYXQgdGhlIElFVEYgcmVzZXJ2ZXMgdGhlIHJpZ2h0IGZvciBpdHNlbGYgdG8g Y3JlYXRlIGRlcml2YXRpdmUgd29ya3MgZnJvbSB0aGUgUkZDcyBpdCBjcmVhdGVkIChteSBwYXJh cGhyYXNpbmcpLiAgV2hpbGUgcGVyaGFwcyBub3QgcmVsZXZhbnQgZm9yIG9nZ29wdXMsIGl04oCZ cyBhbHNvIGFnYWluc3QgdGhlIG1haW4gbWlzc2lvbiBvZiBzdGFuZGFyZGl6YXRpb246IGVuc3Vy ZSBpbnRlcm9wZXJhYmlsaXR5LiAgRnJvbSBhIHN0YW5kYXJkaXplcuKAmXMgdmlld3BvaW50LCBk ZXJpdmF0aXZlIHdvcmsgaXMgZXZpbCAodW5sZXNzIGNvbmR1Y3RlZCBpbiBhIGJhY2t3YXJkIGNv bXBhdGlibGUgd2F5KSwgYmVjYXVzZSBpdCBsZWFkcyB0byBub24taW50ZXJvcGVyYWJsZSBpbXBs ZW1lbnRhdGlvbnMgc29sdmluZyB0aGUgc2FtZSBwcm9ibGVtLiAgU28gaWYgSSB3ZXJlIG9uIHRo ZSBJRVNHLCBJIHdvdWxkIHByb2JhYmx5IGluc2lzdCBvbiBhbiBJRVNHIG5vdGUgdG8gdGhlIFJG QyBlZGl0b3IgcmVxdWlyaW5nIHRoYXQgdGhpcyB3ZWlyZCBjb21tZW50IGluIHRoZSBYTUwgc291 cmNlIGJlIHJlbW92ZWQgYXMgb2YgdGhlIHRpbWUgb2YgcHVibGljYXRpb24gb2YgdGhlIFJGQy4N Cg0KVHJ5aW5nIHRvIGJlIGNyZWF0aXZlIGhlcmU6IEkgdGhpbmsgeW91ciBtYWluIG1vdGl2YXRp b24gZm9yIGFza2luZyB0aGUgSUVURiB0byBhbGxvdyBkZXJpdmF0aXZlIHdvcmsgb3V0c2lkZSB0 aGUgSUVURiBjb250ZXh0IGlzIHRoYXQgdGhlIHRleHQgY291bGQgYmUgdXNlZCBvdXRzaWRlIHRo ZSBJRVRGIHRvIGNyZWF0ZSBuZXcgY29udGFpbmVycyBmb3IgY29kZWNzIG90aGVyIHRoYW4gb3B1 cy4gIFRoYXTigJlzIHBlcmhhcHMgc29tZXdoYXQganVzdGlmaWFibGUsIGFzIHRoZSBvZ2cgYmFz ZSBzcGVjIGlzIG5vdCBhbiBJRVRGIHNwZWMsIGFuZCBtYW55IGNvZGVjcyBhcmUgbm90IElFVEYg Y29kZWNzLiAgKEl0IHdvdWxkIG5vdCBiZSByaWdodCwgZm9yIGV4YW1wbGUsIGZvciBvcHVz4oCZ IFJUUCBwYXlsb2FkIGZvcm1hdC4pICBJcyB0aGF0IGFib3V0IHJpZ2h0PyAgSWYgeWVzLCB0aGVu IHdoeSBub3QgZXhwcmVzcyBpdCBpbiBhIGZpZWxkIG9mIHVzZSBsaW1pdGF0aW9uIGluIHRoZSBs aWNlbnNlIGdyYW50ZWQ/ICBUaGF0IHNlZW1zIGxpa2UgYSByZWFzb25hYmxlIGFuZCBzdWZmaWNp ZW50bHkgbmFycm93bHkgZGVmaW5lZCBleGNlcHRpb24gdGhhdCBjb3VsZCBiZSBqdXN0aWZpZWQu ICANCg0KTm93LCBzdWNoIGEgbmFycm93IGV4Y2VwdGlvbiBkb2VzIG5vdCBzb2x2ZSB0aGUgb3Bl biBzb3VyY2UgcmVsYXRlZCBwcm9ibGVtcywgYnV0IGZvciB0aGF0IHlvdSBzaG91bGQgcmVhbGx5 IHN0YXJ0IGEgZGViYXRlIGFib3V0IHRoZSBjb3B5cmlnaHQgcG9saWN5IGFzIGEgd2hvbGUsIGJl Y2F1c2UgaXQgd291bGQgYmUgYSBtYWpvciBjaGFuZ2UgYWZmZWN0aW5nIGtleSB0cmFkZW9mZnMg b2YgdGhhdCBwb2xpY3kgdGhhdCB3ZXJlIGRlbGliZXJhdGVkIGxpdGVyYWxseSBmb3IgeWVhcnMu DQoNClN0ZXBoYW4NCg0KDQo= From nobody Wed Feb 3 08:28:08 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4337F1AD373; Wed, 3 Feb 2016 08:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 C_IhUjmoQCnz; Wed, 3 Feb 2016 08:28:04 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 557A21AD372; Wed, 3 Feb 2016 08:28:04 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u13GS3B3021103 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 3 Feb 2016 10:28:03 -0600 (CST) (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.10] From: "Ben Campbell" To: "Timothy B. Terriberry" Date: Wed, 03 Feb 2016 10:28:02 -0600 Message-ID: In-Reply-To: References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> <56B12D2A.4020906@xiph.org> <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> <20160203033855.GO3153@hex.shelbyville.oz> <56B17FC4.7000901@xiph.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5213) Archived-At: Cc: "draft-ietf-codec-oggopus@ietf.org" , "codec@ietf.org" , "codec-chairs@ietf.org" , "ietf@ietf.org" Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 16:28:06 -0000 On 3 Feb 2016, at 9:52, Ben Campbell wrote: > On 2 Feb 2016, at 22:19, Timothy B. Terriberry wrote: [...] >> >> It seems to me like putting a BSD copyright header in an XML comment >> at the top of the XML source file and dropping Section 13 from the >> draft would resolve all of the issues, if everyone agrees that is an >> acceptable thing to do. Ron? > > I think that's acceptable in theory. In practice, keep in mind that if > someone uses xml2rfc to render the text, it's going to create IETF > headers and boilerplate, at least if the "external" version of the XML > uses the same settings. > > That's probably not what you want, regardless of whether the section > 13 language stays or goes. To clarify: I think that would only matter for versions with modified content. [...] From nobody Wed Feb 3 09:34:08 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64261B3584 for ; Wed, 3 Feb 2016 09:34:06 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 Ht_IVbOYjU_D for ; Wed, 3 Feb 2016 09:34:05 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 3A8F41B3582 for ; Wed, 3 Feb 2016 09:34:05 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id s5so10789369qkd.0 for ; Wed, 03 Feb 2016 09:34:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jmvalin-ca.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=aDpjaudWqhY/gN+/usxDI5brU5Qqa+EM6yDhhr3B2h0=; b=n36+VIO4pAgK4hyrHDrK+FYVrdB3iCFIScYTXI1fUpjdWEaXlCdERXCgdfHyYHc42z mAP8VeLrc98iZ1Nuch5iRfS7h+5sDrtNtlmVsF7lT5xsxiO89B4Imd5QHG8cs5ZP9Y5T s8dt5U1fUKfKWNZK8gYXtA5XlG2tphqZDhN1aFjtaOH17Qda6f5jmJwARci0T0nlK7bj Egl3/6eNizVdl7BxAyh7ssELzbsife0xGtu1VnQdFzC4fpJGmlPHganXaWWmfGqsjY1P zcnXWcbWUm9O34/9Xi8JZmqEFX3pFLSAWjqLB59XLVyG7z3ikGumhN2AUPpsVv7edIJP dMrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=aDpjaudWqhY/gN+/usxDI5brU5Qqa+EM6yDhhr3B2h0=; b=mS9OkFTTCkzHNUIIW4hzxA283OUAA3yVSNuoOF7T5FU4RARlSCQ332dX6GIeflpx0X /k1qE9nhURMe6OYtfE5HEVZUCDRESXQd5Wh3wpeZ6JvWePX1kyINIxcXTP/o4ogzz1qg i85tgL/XYQ4t4vB3uaQ2ud75SyVuNL8SsWCEf20GlvhjkR+YKnjJS6ftpf0iBNlalWnh n/JqKWHvZtILOUEOpZfVuuDZBaI9J26M9HCAZUG57mG3sSSdVeJsovqkOCyANbk958tO ROdK1E2aM4aewXB+vf1dChu9lfoQ2eprsW6BTM8RP1JlgaF2k9LzmbWwdTeQ3zQqIGYu s+iw== X-Gm-Message-State: AG10YORETvpWnoWwmeJDgwTZy1NfC20o+zjjRYbZC8NszEBlpIhE2JiM3wESQ80EeezyJw== X-Received: by 10.55.78.207 with SMTP id c198mr3105150qkb.34.1454520844307; Wed, 03 Feb 2016 09:34:04 -0800 (PST) Received: from panoramix.jmvalin.ca (modemcable121.240-21-96.mc.videotron.ca. [96.21.240.121]) by smtp.gmail.com with ESMTPSA id m11sm3067416qkl.47.2016.02.03.09.34.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Feb 2016 09:34:03 -0800 (PST) To: Ben Campbell , "Timothy B. Terriberry" References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> <56B12D2A.4020906@xiph.org> <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> <20160203033855.GO3153@hex.shelbyville.oz> <56B17FC4.7000901@xiph.org> From: Jean-Marc Valin X-Enigmail-Draft-Status: N1110 Message-ID: <56B23A08.6040407@jmvalin.ca> Date: Wed, 3 Feb 2016 12:34:00 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "codec-chairs@ietf.org" , "codec@ietf.org" , "draft-ietf-codec-oggopus@ietf.org" , "ietf@ietf.org" Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 17:34:07 -0000 On 02/03/2016 10:52 AM, Ben Campbell wrote: > I think that's acceptable in theory. In practice, keep in mind that if > someone uses xml2rfc to render the text, it's going to create IETF > headers and boilerplate, at least if the "external" version of the XML > uses the same settings. > > That's probably not what you want, regardless of whether the section 13 > language stays or goes. > > How did this end up working for 6716? For 6716, we made sure that the XML version in the git repository produces a draft, not an RFC when run with xml2rfc. That's the best way to avoid accidents and ensure it's never "presented, displayed or published in a manner that states or implies that it is part of this RFC or any other IETF Document". Jean-Marc From nobody Wed Feb 3 09:42:10 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6852B1A902A; Wed, 3 Feb 2016 09:42:05 -0800 (PST) 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 Tqam4ASXogcE; Wed, 3 Feb 2016 09:42:01 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 489351A9004; Wed, 3 Feb 2016 09:42:00 -0800 (PST) Received: from ppp14-2-77-60.lns21.adl6.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.77.60]) by ipmail06.adl6.internode.on.net with ESMTP; 04 Feb 2016 04:11:58 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 61E2CFFABD; Thu, 4 Feb 2016 04:11:57 +1030 (ACDT) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KvEvoRP9NUxV; Thu, 4 Feb 2016 04:11:52 +1030 (ACDT) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailservice.shelbyville.oz (Postfix) with ESMTPS id A7F3EFF81F; Thu, 4 Feb 2016 04:11:52 +1030 (ACDT) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 95BBC80470; Thu, 4 Feb 2016 04:11:52 +1030 (ACDT) Date: Thu, 4 Feb 2016 04:11:52 +1030 From: Ron To: Stephan Wenger Message-ID: <20160203174152.GT3153@hex.shelbyville.oz> References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> <56B12D2A.4020906@xiph.org> <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> <20160203033855.GO3153@hex.shelbyville.oz> <56B17FC4.7000901@xiph.org> <9B1A525A-5ADE-4AB1-962C-DD826D86C5DA@stewe.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9B1A525A-5ADE-4AB1-962C-DD826D86C5DA@stewe.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "ietf@ietf.org" , "draft-ietf-codec-oggopus@ietf.org" , "codec@ietf.org" , "codec-chairs@ietf.org" Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 17:42:05 -0000 On Wed, Feb 03, 2016 at 04:10:58PM +0000, Stephan Wenger wrote: > On 2/2/16, 20:19, "Timothy B. Terriberry" wrote: > > > >It seems to me like putting a BSD copyright header in an XML comment at > >the top of the XML source file and dropping Section 13 from the draft > >would resolve all of the issues, if everyone agrees that is an > >acceptable thing to do. Ron? > > However, it is still a procedural end-run around the currently > in-force IETF position that the IETF reserves the right for itself to > create derivative works from the RFCs it created (my paraphrasing). I can quote more directly without paraphrasing if that helps. The current TLP says: The IETF Trust does not limit the ability of IETF Contributors to license their Contributions, so long as those licenses do not affect the rights granted to the IETF Trust under RFC 5378. And RFC 5377 4.5 says: Authors of Contributions retain all rights in their Contributions. As such, an author may directly grant any rights they wish separately from what the IETF grants. And this is one of the options canvassed with Robert for 6716 before it was decided the header text was the option of choice there. The mechanics of the best way to do it, I'm open to suggestions about, but characterising it as an 'end-run' would seem to be misrepresenting both the documented position of the IETF and the intent of the authors. Ron From nobody Wed Feb 3 09:58:03 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31111AC43A for ; Wed, 3 Feb 2016 09:57:58 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 bUkmFu6AZa9f for ; Wed, 3 Feb 2016 09:57:57 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::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 4DBCE1AC3FF for ; Wed, 3 Feb 2016 09:57:57 -0800 (PST) Received: by mail-qg0-x229.google.com with SMTP id u30so21641313qge.1 for ; Wed, 03 Feb 2016 09:57:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jmvalin-ca.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=PhCoNfVPzTI1Ogg7v4t7tAmV81qn3Xkl15AfdGTDkNk=; b=hsRkLRRO0rziTbQPpyf6Rg7lPIcBQpbsyT/dBQuTijkDQKDZOmQ42zR+dikg7FIF7V A/icGY6JZMhK2a+kl6DEdS972+Ef1h3PIPxHRXtUjBsMiiZuEEcZePMTv+5gxw9NRS9L JwjiA92iOMSwyo+Vj/IuPRKm39WMGw3RssQWjTW6f7kqxioQraqc8GKdcYJZc9p5eSSF gYjgdybaM7mUab5TvU9EIXGigJxad6mdOAr4kt/bQyTFGxBV8dAqh9D7DwxQ7ybJ9fk7 N6rmp3hL1ESA5W6xTsUGscJ3RqGq6Dn5WHDZ1NhPY5CsBQGlY7aRlmP72CdSo+SzGFGn qgrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=PhCoNfVPzTI1Ogg7v4t7tAmV81qn3Xkl15AfdGTDkNk=; b=lKVWJ3qm+DMZgqxt4Ut8VhxcxTI6b0nyYIBOrJ1vt3tuhbm2UPrJ0vKFjVfjubjdnO R44HeyLBYM2sbwVI552C+tjjQROShFUXPr7AUJCa6kLTMXaZfe1GPwc9Ey9MAiiqh3N4 uLpxBeBUQEpPsUYLbo0O1HTn8DkkLb4Ue2uwYgghbqBvpKMlXhxMK+KT7hrfpNlTBqKM FvXK540CS411Y6G0RWx2Ti4KCqIS10YkWr2te+sbwMd1iA4KpOqTVC0hK4HETgJOGpy5 O1wO4YkXtDJoDF6xjHg5InuoVm5uBYX1XlEq53eOlNJ+IghVQfr03ReiPZ7YbUWkqDbY Xc2A== X-Gm-Message-State: AG10YOTq6p4jDOuXWsxyGC3IDhTqNmCL/4qyY6pYvAZHmVGlWePg/5rEdIykIcG2FvkuDA== X-Received: by 10.140.94.50 with SMTP id f47mr3308273qge.0.1454522276534; Wed, 03 Feb 2016 09:57:56 -0800 (PST) Received: from panoramix.jmvalin.ca (modemcable121.240-21-96.mc.videotron.ca. [96.21.240.121]) by smtp.gmail.com with ESMTPSA id h206sm3105018qhh.8.2016.02.03.09.57.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Feb 2016 09:57:55 -0800 (PST) To: Stephan Wenger , "Timothy B. Terriberry" , Ron References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> <56B12D2A.4020906@xiph.org> <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> <20160203033855.GO3153@hex.shelbyville.oz> <56B17FC4.7000901@xiph.org> <9B1A525A-5ADE-4AB1-962C-DD826D86C5DA@stewe.org> From: Jean-Marc Valin X-Enigmail-Draft-Status: N1110 Message-ID: <56B23FA2.60501@jmvalin.ca> Date: Wed, 3 Feb 2016 12:57:54 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <9B1A525A-5ADE-4AB1-962C-DD826D86C5DA@stewe.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "codec-chairs@ietf.org" , "codec@ietf.org" , "draft-ietf-codec-oggopus@ietf.org" , "ietf@ietf.org" Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 17:57:58 -0000 On 02/03/2016 11:10 AM, Stephan Wenger wrote: > However, it is still a procedural end-run around the currently > in-force IETF position that the IETF reserves the right for itself to > create derivative works from the RFCs it created (my paraphrasing). > While perhaps not relevant for oggopus, it’s also against the main > mission of standardization: ensure interoperability. From a > standardizer’s viewpoint, derivative work is evil (unless conducted > in a backward compatible way), because it leads to non-interoperable > implementations solving the same problem. So if I were on the IESG, > I would probably insist on an IESG note to the RFC editor requiring > that this weird comment in the XML source be removed as of the time > of publication of the RFC. You cannot ensure interoperability through legal means here. I've seen several cases where the text of the standard is not free so people implement it from second-hand descriptions that are freely available on the web and end up making mistakes. In the case of the IETF, the fact that the unmodified text is freely (as in beer) distributable helps a lot, but in any cases where someone needs to distribute a modified copy, you're always better off given them permission than have them paraphrase the whole thing the way they understand it. > Trying to be creative here: I think your main motivation for asking > the IETF to allow derivative work outside the IETF context is that > the text could be used outside the IETF to create new containers for > codecs other than opus. That's one of them, but there's also mapping Opus to non-Ogg containers, experimenting with new channel mapping families, and probably others I can't think of at the moment. > That’s perhaps somewhat justifiable, as the > ogg base spec is not an IETF spec, and many codecs are not IETF > codecs. (It would not be right, for example, for opus’ RTP payload > format.) Even text of the RTP spec is something that can reasonably be borrowed for a different container. Not to mention there's still the documentation-related issue. > Is that about right? If yes, then why not express it in a > field of use limitation in the license granted? That seems like a > reasonable and sufficiently narrowly defined exception that could be > justified. > > Now, such a narrow exception does not solve the open source related > problems, but for that you should really start a debate about the > copyright policy as a whole, because it would be a major change > affecting key tradeoffs of that policy that were deliberated > literally for years. Well, for the open-source issue, I think the best solution is still the license given by authors on the XML. Jean-Marc From nobody Wed Feb 3 10:07:40 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58AF1B2A59; Wed, 3 Feb 2016 10:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 aNlhA2CtsNql; Wed, 3 Feb 2016 10:07:35 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0104.outbound.protection.outlook.com [207.46.100.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A156F1B2A56; Wed, 3 Feb 2016 10:07:35 -0800 (PST) Received: from BLUPR17MB0275.namprd17.prod.outlook.com (10.162.235.146) by BLUPR17MB0274.namprd17.prod.outlook.com (10.162.235.145) with Microsoft SMTP Server (TLS) id 15.1.396.15; Wed, 3 Feb 2016 18:07:33 +0000 Received: from BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) by BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) with mapi id 15.01.0396.020; Wed, 3 Feb 2016 18:07:33 +0000 From: Stephan Wenger To: Jean-Marc Valin , "Timothy B. Terriberry" , Ron Thread-Topic: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard Thread-Index: AQHRWUOYu4dc40trYEmucQwFwKPFWJ8R0sEAgAdxvQCAABqZAP//f0mAgADX6YCAAAtGAIAAQLuAgACj/gD//3yUgA== Date: Wed, 3 Feb 2016 18:07:32 +0000 Message-ID: <89930318-C5A6-46DD-BCBF-26797CD1CD98@stewe.org> References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> <56B12D2A.4020906@xiph.org> <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> <20160203033855.GO3153@hex.shelbyville.oz> <56B17FC4.7000901@xiph.org> <9B1A525A-5ADE-4AB1-962C-DD826D86C5DA@stewe.org> <56B23FA2.60501@jmvalin.ca> In-Reply-To: <56B23FA2.60501@jmvalin.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jmvalin.ca; dkim=none (message not signed) header.d=none;jmvalin.ca; dmarc=none action=none header.from=stewe.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [50.174.30.183] x-microsoft-exchange-diagnostics: 1; BLUPR17MB0274; 5:L+qNFURf1Yq5sjrsVHNfXSUmCoY/pRauBxHmW9R8U/4Fn8+VXoK14Im1JJynOOrOVRvpCvy6UWcFzomQE7IHnB/iq6DM5Qd7QQu80mBzIACr7BMjhHAl3JcWwpFb5n0qt8PSJuTRLU5nLbWfZHKpTw==; 24:NDZbzSYXVqkz5ATE7lhJdMXrGpQzcdF4i59TyLL6ot6aM8UDukc0dcKpIeycnCXr7TwY7JLVWF5rAyBmNiuhlQ4cQzH+iO7GoAIsMNeD4BI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR17MB0274; x-ms-office365-filtering-correlation-id: 79f8119f-8652-478c-ed22-08d32cc4e36e x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR17MB0274; BCL:0; PCL:0; RULEID:; SRVR:BLUPR17MB0274; x-forefront-prvs: 08417837C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(479174004)(24454002)(99286002)(2900100001)(106116001)(33656002)(2950100001)(77096005)(86362001)(92566002)(19580405001)(66066001)(19580395003)(36756003)(82746002)(54356999)(189998001)(561944003)(76176999)(93886004)(2906002)(50986999)(87936001)(5001960100002)(4326007)(230783001)(3280700002)(3660700001)(102836003)(11100500001)(6116002)(3846002)(83716003)(5004730100002)(1220700001)(1096002)(5001770100001)(10400500002)(40100003)(5008740100001)(586003)(122556002)(5002640100001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR17MB0274; H:BLUPR17MB0275.namprd17.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4E70AD407F1A104287020AED13E944D8@namprd17.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2016 18:07:32.4812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR17MB0274 Archived-At: Cc: "codec-chairs@ietf.org" , "codec@ietf.org" , "draft-ietf-codec-oggopus@ietf.org" , "ietf@ietf.org" Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 18:07:40 -0000 SGkgSmVhbi1NYXJjLA0KDQoNCg0KT24gMi8zLzE2LCAwOTo1NywgIkplYW4tTWFyYyBWYWxpbiIg PGptdmFsaW5Aam12YWxpbi5jYT4gd3JvdGU6DQoNCj5PbiAwMi8wMy8yMDE2IDExOjEwIEFNLCBT dGVwaGFuIFdlbmdlciB3cm90ZToNCj4+IEhvd2V2ZXIsIGl0IGlzIHN0aWxsIGEgcHJvY2VkdXJh bCBlbmQtcnVuIGFyb3VuZCB0aGUgY3VycmVudGx5DQo+PiBpbi1mb3JjZSBJRVRGIHBvc2l0aW9u IHRoYXQgdGhlIElFVEYgcmVzZXJ2ZXMgdGhlIHJpZ2h0IGZvciBpdHNlbGYgdG8NCj4+IGNyZWF0 ZSBkZXJpdmF0aXZlIHdvcmtzIGZyb20gdGhlIFJGQ3MgaXQgY3JlYXRlZCAobXkgcGFyYXBocmFz aW5nKS4NCj4+IFdoaWxlIHBlcmhhcHMgbm90IHJlbGV2YW50IGZvciBvZ2dvcHVzLCBpdOKAmXMg YWxzbyBhZ2FpbnN0IHRoZSBtYWluDQo+PiBtaXNzaW9uIG9mIHN0YW5kYXJkaXphdGlvbjogZW5z dXJlIGludGVyb3BlcmFiaWxpdHkuICBGcm9tIGENCj4+IHN0YW5kYXJkaXplcuKAmXMgdmlld3Bv aW50LCBkZXJpdmF0aXZlIHdvcmsgaXMgZXZpbCAodW5sZXNzIGNvbmR1Y3RlZA0KPj4gaW4gYSBi YWNrd2FyZCBjb21wYXRpYmxlIHdheSksIGJlY2F1c2UgaXQgbGVhZHMgdG8gbm9uLWludGVyb3Bl cmFibGUNCj4+IGltcGxlbWVudGF0aW9ucyBzb2x2aW5nIHRoZSBzYW1lIHByb2JsZW0uICBTbyBp ZiBJIHdlcmUgb24gdGhlIElFU0csDQo+PiBJIHdvdWxkIHByb2JhYmx5IGluc2lzdCBvbiBhbiBJ RVNHIG5vdGUgdG8gdGhlIFJGQyBlZGl0b3IgcmVxdWlyaW5nDQo+PiB0aGF0IHRoaXMgd2VpcmQg Y29tbWVudCBpbiB0aGUgWE1MIHNvdXJjZSBiZSByZW1vdmVkIGFzIG9mIHRoZSB0aW1lDQo+PiBv ZiBwdWJsaWNhdGlvbiBvZiB0aGUgUkZDLg0KPg0KPllvdSBjYW5ub3QgZW5zdXJlIGludGVyb3Bl cmFiaWxpdHkgdGhyb3VnaCBsZWdhbCBtZWFucyBoZXJlLiBJJ3ZlIHNlZW4NCj5zZXZlcmFsIGNh c2VzIHdoZXJlIHRoZSB0ZXh0IG9mIHRoZSBzdGFuZGFyZCBpcyBub3QgZnJlZSBzbyBwZW9wbGUN Cj5pbXBsZW1lbnQgaXQgZnJvbSBzZWNvbmQtaGFuZCBkZXNjcmlwdGlvbnMgdGhhdCBhcmUgZnJl ZWx5IGF2YWlsYWJsZSBvbg0KPnRoZSB3ZWIgYW5kIGVuZCB1cCBtYWtpbmcgbWlzdGFrZXMuIElu IHRoZSBjYXNlIG9mIHRoZSBJRVRGLCB0aGUgZmFjdA0KPnRoYXQgdGhlIHVubW9kaWZpZWQgdGV4 dCBpcyBmcmVlbHkgKGFzIGluIGJlZXIpIGRpc3RyaWJ1dGFibGUgaGVscHMgYQ0KPmxvdCwgYnV0 IGluIGFueSBjYXNlcyB3aGVyZSBzb21lb25lIG5lZWRzIHRvIGRpc3RyaWJ1dGUgYSBtb2RpZmll ZCBjb3B5LA0KPnlvdSdyZSBhbHdheXMgYmV0dGVyIG9mZiBnaXZlbiB0aGVtIHBlcm1pc3Npb24g dGhhbiBoYXZlIHRoZW0gcGFyYXBocmFzZQ0KPnRoZSB3aG9sZSB0aGluZyB0aGUgd2F5IHRoZXkg dW5kZXJzdGFuZCBpdC4NCg0KSSB0ZW5kIHRvIGFncmVlIChleGNlcHQgcGVyaGFwcyBmb3IgdGhl IHdvcmQg4oCcYWx3YXlz4oCdIGluIHRoZSBsYXN0IHNlbnRlbmNlKSwgYnV0IHdoYXQgSSBkZXNj cmliZWQgaXMgbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgSUVURuKAmXMgcG9zaXRpb24gd2hlbiBj cmVhdGluZyB0aGUgY3VycmVudGx5IGluIGZvcmNlIGNvcHlyaWdodCBwb2xpY3ksIGFuZCBub3Qg YW4gYWJzb2x1dGUgdHJ1dGguDQoNCj4NCj4+IFRyeWluZyB0byBiZSBjcmVhdGl2ZSBoZXJlOiBJ IHRoaW5rIHlvdXIgbWFpbiBtb3RpdmF0aW9uIGZvciBhc2tpbmcNCj4+IHRoZSBJRVRGIHRvIGFs bG93IGRlcml2YXRpdmUgd29yayBvdXRzaWRlIHRoZSBJRVRGIGNvbnRleHQgaXMgdGhhdA0KPj4g dGhlIHRleHQgY291bGQgYmUgdXNlZCBvdXRzaWRlIHRoZSBJRVRGIHRvIGNyZWF0ZSBuZXcgY29u dGFpbmVycyBmb3INCj4+IGNvZGVjcyBvdGhlciB0aGFuIG9wdXMuDQo+DQo+VGhhdCdzIG9uZSBv ZiB0aGVtLCBidXQgdGhlcmUncyBhbHNvIG1hcHBpbmcgT3B1cyB0byBub24tT2dnIGNvbnRhaW5l cnMsDQo+ZXhwZXJpbWVudGluZyB3aXRoIG5ldyBjaGFubmVsIG1hcHBpbmcgZmFtaWxpZXMsIGFu ZCBwcm9iYWJseSBvdGhlcnMgSQ0KPmNhbid0IHRoaW5rIG9mIGF0IHRoZSBtb21lbnQuDQoNClNv IHRoZSBpc3N1ZSB3aXRoIHRoYXQgcHJvcG9zYWwgd291bGQgYmUgdGhhdCBpdCBpcyBkaWZmaWN1 bHQgdG8gY3JlYXRlIGEgc3VmZmljaWVudGx5IHdpZGUgY2FydmUtb3V0IChzaG9ydCBvZiDigJxn byBhbmQgZG8gd2l0aCBpdCB3aGF0ZXZlciB5b3Ugd2FudOKAnSk/ICBJIHNvbWV3aGF0IGRvdWJ0 IHRoYXQuICBVbmZvcnR1bmF0ZWx5LCBJIGRvbuKAmXQgaGF2ZSB0aGUgdGltZSByaWdodCBub3cg dG8gYmUgbW9yZSBjcmVhdGl2ZSA6LSkNCg0KPg0KPj4gVGhhdOKAmXMgcGVyaGFwcyBzb21ld2hh dCBqdXN0aWZpYWJsZSwgYXMgdGhlDQo+PiBvZ2cgYmFzZSBzcGVjIGlzIG5vdCBhbiBJRVRGIHNw ZWMsIGFuZCBtYW55IGNvZGVjcyBhcmUgbm90IElFVEYNCj4+IGNvZGVjcy4gIChJdCB3b3VsZCBu b3QgYmUgcmlnaHQsIGZvciBleGFtcGxlLCBmb3Igb3B1c+KAmSBSVFAgcGF5bG9hZA0KPj4gZm9y bWF0LikgDQo+DQo+RXZlbiB0ZXh0IG9mIHRoZSBSVFAgc3BlYyBpcyBzb21ldGhpbmcgdGhhdCBj YW4gcmVhc29uYWJseSBiZSBib3Jyb3dlZA0KPmZvciBhIGRpZmZlcmVudCBjb250YWluZXIuIE5v dCB0byBtZW50aW9uIHRoZXJlJ3Mgc3RpbGwgdGhlDQo+ZG9jdW1lbnRhdGlvbi1yZWxhdGVkIGlz c3VlLg0KDQpJIGFzc3VtZSB5b3UgYXJlIHJlZmVycmluZyB0byB0aGUgUlRQIHBheWxvYWQgZm9y bWF0IHNwZWMgZm9yIG9wdXMsIGFuZCBub3QgUkZDIDM1NTAuICBXaXRoIHRoYXQgc3BlYyB0aGVy ZSBpcyBhYnNvbHV0ZWx5IG5vdGhpbmcgZGlmZmVyZW50IGZyb20gb3RoZXIgUlRQIHBheWxvYWQg Zm9ybWF0cyBhbmQgbm90aGluZywgaW4gbXkgdmlldywgdGhhdCB3b3VsZCBqdXN0aWZ5IGFueSBk ZXRvdXIgZnJvbSBvdXIgZXN0YWJsaXNoZWQgcG9saWNpZXMgYW5kIHByb2NlZHVyZXMuDQoNCj4N Cj4+IElzIHRoYXQgYWJvdXQgcmlnaHQ/ICBJZiB5ZXMsIHRoZW4gd2h5IG5vdCBleHByZXNzIGl0 IGluIGENCj4+IGZpZWxkIG9mIHVzZSBsaW1pdGF0aW9uIGluIHRoZSBsaWNlbnNlIGdyYW50ZWQ/ ICBUaGF0IHNlZW1zIGxpa2UgYQ0KPj4gcmVhc29uYWJsZSBhbmQgc3VmZmljaWVudGx5IG5hcnJv d2x5IGRlZmluZWQgZXhjZXB0aW9uIHRoYXQgY291bGQgYmUNCj4+IGp1c3RpZmllZC4NCj4+IA0K Pj4gTm93LCBzdWNoIGEgbmFycm93IGV4Y2VwdGlvbiBkb2VzIG5vdCBzb2x2ZSB0aGUgb3BlbiBz b3VyY2UgcmVsYXRlZA0KPj4gcHJvYmxlbXMsIGJ1dCBmb3IgdGhhdCB5b3Ugc2hvdWxkIHJlYWxs eSBzdGFydCBhIGRlYmF0ZSBhYm91dCB0aGUNCj4+IGNvcHlyaWdodCBwb2xpY3kgYXMgYSB3aG9s ZSwgYmVjYXVzZSBpdCB3b3VsZCBiZSBhIG1ham9yIGNoYW5nZQ0KPj4gYWZmZWN0aW5nIGtleSB0 cmFkZW9mZnMgb2YgdGhhdCBwb2xpY3kgdGhhdCB3ZXJlIGRlbGliZXJhdGVkDQo+PiBsaXRlcmFs bHkgZm9yIHllYXJzLg0KPg0KPldlbGwsIGZvciB0aGUgb3Blbi1zb3VyY2UgaXNzdWUsIEkgdGhp bmsgdGhlIGJlc3Qgc29sdXRpb24gaXMgc3RpbGwgdGhlDQo+bGljZW5zZSBnaXZlbiBieSBhdXRo b3JzIG9uIHRoZSBYTUwuDQoNCldpdGhpbiB0aGUgbmFycm93bHkgaW50ZXJwcmV0ZWQgbGFuZ3Vh Z2Ugb2YgdGhlIGNvcHlyaWdodCBwb2xpY3kgUkZDcywgcGVyaGFwcyB5ZXMuICBCdXQgSSBjb250 aW51ZSB0byBtYWludGFpbiBpdCB3b3VsZCBzdGlsbCBnbyBhZ2FpbnN0IHRoZSBzcGlyaXQgb2Yg dGhlIGNvcHlyaWdodCBwb2xpY3kuDQoNCj4NCj4JSmVhbi1NYXJjDQo= From nobody Wed Feb 3 11:20:09 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC20A1B2B7E; Wed, 3 Feb 2016 11:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 BLLkNpxcejLz; Wed, 3 Feb 2016 11:20:00 -0800 (PST) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (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 870D81B2B7C; Wed, 3 Feb 2016 11:20:00 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 0ED68C57C9; Wed, 3 Feb 2016 19:20:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeZ1jaVaT9Di; Wed, 3 Feb 2016 19:19:59 +0000 (UTC) Received: from [10.252.26.68] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id DE2ACC56EF; Wed, 3 Feb 2016 19:19:51 +0000 (UTC) Message-ID: <56B252D6.9050202@xiph.org> Date: Wed, 03 Feb 2016 11:19:50 -0800 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: Stephan Wenger , Ron References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> <56B12D2A.4020906@xiph.org> <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> <20160203033855.GO3153@hex.shelbyville.oz> <56B17FC4.7000901@xiph.org> <9B1A525A-5ADE-4AB1-962C-DD826D86C5DA@stewe.org> In-Reply-To: <9B1A525A-5ADE-4AB1-962C-DD826D86C5DA@stewe.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-codec-oggopus@ietf.org" , "codec-chairs@ietf.org" , "codec@ietf.org" , "ietf@ietf.org" Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 19:20:06 -0000 Hi Stephan, Stephan Wenger wrote: > However, it is still a procedural end-run around the currently > in-force IETF position that the IETF reserves the right for itself to > create derivative works from the RFCs it created (my paraphrasing). I am trying to follow the procedure. RFC 5377 says that authors should be able to grant these rights. The first example I know of people doing this was by putting a copyright statement in the XML source (RFC 2629). But my understanding was that it was later preferred that an additional grant be added in a section of the draft (see RFC 5215 Section 11). Then with RFC 6716 the IETF decided it was better to add this grant to the boilerplate text. Now there are objections to that approach, and we've come full circle to a copyright statement in the XML source again. As long as there is some way to do it, then I am happy. > Now, such a narrow exception does not solve the open source related > problems, but for that you should really start a debate about the > copyright policy as a whole, because it would be a major change > affecting key tradeoffs of that policy that were deliberated literally > for years. I am actually personally fine if most authors do not want to grant these rights. To my mind, they are the ones who wrote the documents, and if they see these restrictions as beneficial, it's not my place to tell them they are not allowed to have them. From nobody Wed Feb 3 12:23:02 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F63D1B2C6C; Wed, 3 Feb 2016 12:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 qaNUMgDsVyMl; Wed, 3 Feb 2016 12:22:56 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0115.outbound.protection.outlook.com [207.46.100.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEFCF1B2C6B; Wed, 3 Feb 2016 12:22:55 -0800 (PST) Received: from BLUPR17MB0275.namprd17.prod.outlook.com (10.162.235.146) by BLUPR17MB0274.namprd17.prod.outlook.com (10.162.235.145) with Microsoft SMTP Server (TLS) id 15.1.396.15; Wed, 3 Feb 2016 20:22:53 +0000 Received: from BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) by BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) with mapi id 15.01.0396.020; Wed, 3 Feb 2016 20:22:53 +0000 From: Stephan Wenger To: "Timothy B. Terriberry" , Ron Thread-Topic: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard Thread-Index: AQHRWUOYu4dc40trYEmucQwFwKPFWJ8R0sEAgAdxvQCAABqZAP//f0mAgADX6YCAAAtGAIAAQLuAgAC64gD//4t/gA== Date: Wed, 3 Feb 2016 20:22:53 +0000 Message-ID: <898C4A76-102D-41D0-9155-BBA3FC2804D8@stewe.org> References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> <56B12D2A.4020906@xiph.org> <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> <20160203033855.GO3153@hex.shelbyville.oz> <56B17FC4.7000901@xiph.org> <9B1A525A-5ADE-4AB1-962C-DD826D86C5DA@stewe.org> <56B252D6.9050202@xiph.org> In-Reply-To: <56B252D6.9050202@xiph.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: xiph.org; dkim=none (message not signed) header.d=none;xiph.org; dmarc=none action=none header.from=stewe.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [50.174.30.183] x-microsoft-exchange-diagnostics: 1; BLUPR17MB0274; 5:bCQ2jwEUeB+uhajHGtGgrdQHmoKoVUR4La4SpEI8QLwsvgRqw3/8E3MtqWSIgTI/vUhmyN7ETl2UqjFzG1QIoSQQ3E2rwWNg4H58wia7iCOzDZ+JmXfwRZDZbsCwCDxX9/3TLyNkEFjZxaqW+nkORw==; 24:q4Z4fhoBCzpn2y7RIpyS3CEh/zq5EgeqBRNf9Jw8JwUikYXBDxL12rLnsbDl57tkByuthaMaR1aVLnOo5Yv4pQpL5Fj7LtA4YW1oC3VTlQs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR17MB0274; x-ms-office365-filtering-correlation-id: 6b3c8d4e-de57-402f-d6c6-08d32cd7cbc4 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR17MB0274; BCL:0; PCL:0; RULEID:; SRVR:BLUPR17MB0274; x-forefront-prvs: 08417837C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(24454002)(5001960100002)(4326007)(87936001)(230783001)(93886004)(50986999)(2906002)(40100003)(5008740100001)(122556002)(10400500002)(5002640100001)(586003)(3846002)(102836003)(6116002)(11100500001)(1096002)(5001770100001)(1220700001)(83716003)(5004730100002)(77096005)(86362001)(99286002)(2950100001)(33656002)(106116001)(54356999)(82746002)(76176999)(189998001)(19580405001)(66066001)(92566002)(36756003)(19580395003)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR17MB0274; H:BLUPR17MB0275.namprd17.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <5A205FE2CFA67D43922FA512EF741DE5@namprd17.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2016 20:22:53.2321 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR17MB0274 Archived-At: Cc: "draft-ietf-codec-oggopus@ietf.org" , "codec-chairs@ietf.org" , "codec@ietf.org" , "ietf@ietf.org" Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 20:23:01 -0000 DQoNCg0KDQoNCk9uIDIvMy8xNiwgMTE6MTksICJUaW1vdGh5IEIuIFRlcnJpYmVycnkiIDx0dGVy cmliZUB4aXBoLm9yZz4gd3JvdGU6DQoNCj5IaSBTdGVwaGFuLA0KPg0KPlN0ZXBoYW4gV2VuZ2Vy IHdyb3RlOg0KPj4gSG93ZXZlciwgaXQgaXMgc3RpbGwgYSBwcm9jZWR1cmFsIGVuZC1ydW4gYXJv dW5kIHRoZSBjdXJyZW50bHkNCj4gPiBpbi1mb3JjZSBJRVRGIHBvc2l0aW9uIHRoYXQgdGhlIElF VEYgcmVzZXJ2ZXMgdGhlIHJpZ2h0IGZvciBpdHNlbGYgdG8NCj4gPiBjcmVhdGUgZGVyaXZhdGl2 ZSB3b3JrcyBmcm9tIHRoZSBSRkNzIGl0IGNyZWF0ZWQgKG15IHBhcmFwaHJhc2luZykuDQo+DQo+ SSBhbSB0cnlpbmcgdG8gZm9sbG93IHRoZSBwcm9jZWR1cmUuIFJGQyA1Mzc3IHNheXMgdGhhdCBh dXRob3JzIHNob3VsZCANCj5iZSBhYmxlIHRvIGdyYW50IHRoZXNlIHJpZ2h0cy4gVGhlIGZpcnN0 IGV4YW1wbGUgSSBrbm93IG9mIHBlb3BsZSBkb2luZyANCj50aGlzIHdhcyBieSBwdXR0aW5nIGEg Y29weXJpZ2h0IHN0YXRlbWVudCBpbiB0aGUgWE1MIHNvdXJjZSAoUkZDIDI2MjkpLiANCj5CdXQg bXkgdW5kZXJzdGFuZGluZyB3YXMgdGhhdCBpdCB3YXMgbGF0ZXIgcHJlZmVycmVkIHRoYXQgYW4g YWRkaXRpb25hbCANCj5ncmFudCBiZSBhZGRlZCBpbiBhIHNlY3Rpb24gb2YgdGhlIGRyYWZ0IChz ZWUgUkZDIDUyMTUgU2VjdGlvbiAxMSkuIFRoZW4gDQo+d2l0aCBSRkMgNjcxNiB0aGUgSUVURiBk ZWNpZGVkIGl0IHdhcyBiZXR0ZXIgdG8gYWRkIHRoaXMgZ3JhbnQgdG8gdGhlIA0KPmJvaWxlcnBs YXRlIHRleHQuIE5vdyB0aGVyZSBhcmUgb2JqZWN0aW9ucyB0byB0aGF0IGFwcHJvYWNoLCBhbmQg d2UndmUgDQo+Y29tZSBmdWxsIGNpcmNsZSB0byBhIGNvcHlyaWdodCBzdGF0ZW1lbnQgaW4gdGhl IFhNTCBzb3VyY2UgYWdhaW4uIEFzIA0KPmxvbmcgYXMgdGhlcmUgaXMgc29tZSB3YXkgdG8gZG8g aXQsIHRoZW4gSSBhbSBoYXBweS4NCg0KTG9vaywgdGhlcmUgYXJlIGNvdW50bGVzcyB3YXlzIGZv ciBSRkMgYXV0aG9ycyB0byBwdWJsaXNoIGEgY29sbGVjdGlvbiBvZiBjaGFyYWN0ZXJzIG91dHNp ZGUgdGhlIElFVEYgdGhhdCBhbHNvIGhhcHBlbiB0byBiZSBwYXJ0IG9mIHRoZSBSRkMuICBGb3Ig dGhpcyBwYXJ0aWN1bGFyIGNhc2UsIGl04oCZcyBJTU8gYWJzb2x1dGVseSBPSyBhbmQgc3VwcG9y dGVkIGJ5IGxhbmd1YWdlIGFuZCBzcGlyaXQgb2YgdGhlIElFVEbigJlzIGNvcHlyaWdodCBwb2xp Y3ksIG5vdCB0byBtZW50aW9uIGFkZXF1YXRlLCBpZiB5b3UgYXV0aG9ycyB0YWtlIHRoZSBSRkMg b25jZSBkb25lLCBzdHJpcCBpdCBvZiBJRVRGIHNwZWNpZmljIGJvaWxlcnBsYXRlLCAob3B0aW9u YWxseSBhZGQgeW91ciBvd24gd2l0aCB3aGF0ZXZlciB0ZXJtIHlvdSBjaG9vc2UpLCBhbmQgcHV0 IGl0IG9uIHRoZSB4aXBoLm9yZyB3ZWJwYWdlLiAgDQoNClRoYXQgd29ya3MgZm9yIGFzIGxvbmcg YXMgeW91IGFyZSByZWFzb25hYmx5IGNlcnRhaW4gdGhhdCB5b3UgYXV0aG9ycyBhcmUgdGhlIG9u bHkgb25lcyB3aG8gbWFkZSBzdWJzdGFudGlhbCBjb250cmlidXRpb25zIHRvIHRoZSB0ZXh0LiAg SWYsIGZvciBleGFtcGxlLCB0aGUgSUVTRyBwdXQgaW4gYSAxMCBwYWdlIElFU0cgbm90ZSBpbnRv IHRoZSBkb2MsIG9yIGlmIHRoZSBSRkMgZWRpdG9yIHJld3JpdGVzIHlvdXIgd2hvbGUgdGV4dCwg dGhlbiB5b3UgcHJvYmFibHkgc2hvdWxkIGdldCB0aGVpciBPSyBhcyB3ZWxsLiAgQnV0IHRoZXNl IGFyZSBjb3JuZXItY2FzZXMgeW91IGNhbiBjb250cm9sIHdlbGwgZW5vdWdoIHNvIHRoYXQgSSBk b27igJl0IHdvcnJ5IGFib3V0IHRoZW0uICBBbmQsIGl04oCZcyB5b3VyIHJpc2sgYW5kIGl04oCZ cyBlYXN5IGVub3VnaCB0byBtaXRpZ2F0ZS4NCg0KWW91IGZvbGtzIGNhbiBjZXJ0YWlubHkgZW5z dXJlIHRoYXQgdGhlIHRleHQgeW91IHB1Ymxpc2ggaXMgaWRlbnRpY2FsIHRvIHRoZSBSRkMgbWlu dXMgYm9pbGVycGxhdGUuICBZb3UgY2FuIGFsc28gbWFrZSBhIHN0YXRlbWVudCBpbiB0aGlzIHJl Z2FyZCBvbiB0aGUgd2ViIHBhZ2UuICBUaGlzIGlzLCBpbiBteSB1bmRlcnN0YW5kaW5nLCB3aGF0 IHdhcyBtZWFudCBpbiB0aG9zZSBzZWN0aW9ucyBvZiBSRkMgNTM3NyB0aGF0IFJvbiBjaXRlZC4N Cg0KTm90ZSB0aGF0IEkgZG8gbm90IGNvbnNpZGVyIHRoaXMgYSDigJxHb29kIFRoaW5n4oCdIHRv IGltcGxlbWVudCBmb3IgYWxsLCBvciBldmVuIGEgc3Vic3RhbnRpYWwgbnVtYmVyLCBvZiBSRkNz LiAgSXQgaGFzIHRoZSBwb3RlbnRpYWwgdG8gY3JlYXRlIGFuIHVucmVsaWFibGUgKGluIHRoZSBz ZW5zZSB0aGF0IG5vdCBhbGwgSUVURiBSRkNzIGFyZSBwcmVzZW50KSBxdWFzaS1taXJyb3Igb2Yg dGhlIElFVEYgUkZDIGRvY3VtZW50cy4gIEJ1dCBmb3IgdGhpcyBwYXJ0aWN1bGFyIFJGQy10by1i ZSwgaXQgbWF5IGJlIHRoZSByaWdodCB0aGluZyB0byBkby4NCiAgDQoNCj4NCj4+IE5vdywgc3Vj aCBhIG5hcnJvdyBleGNlcHRpb24gZG9lcyBub3Qgc29sdmUgdGhlIG9wZW4gc291cmNlIHJlbGF0 ZWQNCj4+IHByb2JsZW1zLCBidXQgZm9yIHRoYXQgeW91IHNob3VsZCByZWFsbHkgc3RhcnQgYSBk ZWJhdGUgYWJvdXQgdGhlDQo+PiBjb3B5cmlnaHQgcG9saWN5IGFzIGEgd2hvbGUsIGJlY2F1c2Ug aXQgd291bGQgYmUgYSBtYWpvciBjaGFuZ2UNCj4+IGFmZmVjdGluZyBrZXkgdHJhZGVvZmZzIG9m IHRoYXQgcG9saWN5IHRoYXQgd2VyZSBkZWxpYmVyYXRlZCBsaXRlcmFsbHkNCj4+IGZvciB5ZWFy cy4NCj4NCj5JIGFtIGFjdHVhbGx5IHBlcnNvbmFsbHkgZmluZSBpZiBtb3N0IGF1dGhvcnMgZG8g bm90IHdhbnQgdG8gZ3JhbnQgdGhlc2UgDQo+cmlnaHRzLiBUbyBteSBtaW5kLCB0aGV5IGFyZSB0 aGUgb25lcyB3aG8gd3JvdGUgdGhlIGRvY3VtZW50cywgYW5kIGlmIA0KPnRoZXkgc2VlIHRoZXNl IHJlc3RyaWN0aW9ucyBhcyBiZW5lZmljaWFsLCBpdCdzIG5vdCBteSBwbGFjZSB0byB0ZWxsIA0K PnRoZW0gdGhleSBhcmUgbm90IGFsbG93ZWQgdG8gaGF2ZSB0aGVtLg0KDQoNCg== From nobody Thu Feb 11 17:30:18 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487241B3187; Thu, 11 Feb 2016 17:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 rf6x7q6W5YEJ; Thu, 11 Feb 2016 17:30:04 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 AD6A41B319C; Thu, 11 Feb 2016 17:29:59 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u1C1Twf0066010 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 11 Feb 2016 19:29:59 -0600 (CST) (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.10] From: "Ben Campbell" To: codec-chairs@ietf.org, codec@ietf.org Date: Thu, 11 Feb 2016 19:29:58 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5213) Archived-At: Subject: [codec] Progressing draft-ietf-codec-oggopus X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 01:30:08 -0000 Hi CODEC working group, The authors of draft-ietf-codec-oggopus have agreed to progress the draft without the additional copyright licensing text that appeared in earlier revisions. Under the assumption that the working group agrees, I will put the draft on the agenda for next week's Telechat. This means that the draft will progress with the standard boilerplate, as is currently in revision 12. The copyright license will be as usual per the Trust Legal Provisions[1]. If the authors wish to grant other rights, they may do so independently. If anyone objects to this approach, please send email to the codec list, and to me, no later than Wednesday, Feb 17. Thanks! Ben. From nobody Thu Feb 11 17:42:29 2016 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 541C21B3D8C; Thu, 11 Feb 2016 17:42:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160212014216.9641.75338.idtracker@ietfa.amsl.com> Date: Thu, 11 Feb 2016 17:42:16 -0800 Archived-At: Cc: codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-oggopus@ietf.org Subject: [codec] Ben Campbell's Yes on draft-ietf-codec-oggopus-12: (with COMMENT) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 01:42:16 -0000 Ben Campbell has entered the following ballot position for draft-ietf-codec-oggopus-12: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- There has been considerable last call discussion about the inclusion of additional copyright licensing language by the authors. The authors have agreed to progress the draft without such language, as reflected in revision 12. If the authors choose to grant additional rights, they may do so independently. Please note, however, that the xml2rfc source in the data tracker contains additional copyright text in comments. It is my understanding that this text will be removed prior to approval for publication. There has also been last call discussion about the fact that this draft is intended to be a proposed standard, but it normatively depends on RFC 3533 (the Ogg container format) , which is informational. In my opinion, this is appropriate because the draft specifies the encapsulation of Opus, which is a proposed standard. (RFC 6716). From nobody Fri Feb 12 13:05:24 2016 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C051A8AA0; Fri, 12 Feb 2016 13:05:22 -0800 (PST) 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.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160212210522.1099.32944.idtracker@ietfa.amsl.com> Date: Fri, 12 Feb 2016 13:05:22 -0800 Archived-At: Cc: codec@ietf.org Subject: [codec] I-D Action: draft-ietf-codec-oggopus-13.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 21:05:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Wideband Audio Codec of the IETF. Title : Ogg Encapsulation for the Opus Audio Codec Authors : Timothy B. Terriberry Ron Lee Ralph Giles Filename : draft-ietf-codec-oggopus-13.txt Pages : 32 Date : 2016-02-12 Abstract: This document defines the Ogg encapsulation for the Opus interactive speech and audio codec. This allows data encoded in the Opus format to be stored in an Ogg logical bitstream. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-codec-oggopus-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-codec-oggopus-13 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 Feb 12 13:10:19 2016 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 268D51A8AB5; Fri, 12 Feb 2016 13:10:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160212211018.3914.5578.idtracker@ietfa.amsl.com> Date: Fri, 12 Feb 2016 13:10:18 -0800 Archived-At: Cc: codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-oggopus@ietf.org Subject: [codec] Ben Campbell's Yes on draft-ietf-codec-oggopus-13: (with COMMENT) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 21:10:18 -0000 Ben Campbell has entered the following ballot position for draft-ietf-codec-oggopus-13: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- There has been considerable last call discussion about the inclusion of additional copyright licensing language by the authors. The authors have agreed to progress the draft without such language, as reflected in revision 12. If the authors choose to grant additional rights, they may do so independently. [Thanks to the authors for fixing the xml2rfc source issue. I've removed that bit from these comments] There has also been last call discussion about the fact that this draft is intended to be a proposed standard, but it normatively depends on RFC 3533 (the Ogg container format) , which is informational. In my opinion, this is appropriate because the draft specifies the encapsulation of Opus, which is a proposed standard. (RFC 6716). From nobody Mon Feb 15 10:02:34 2016 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FB41A9106; Mon, 15 Feb 2016 10:02:33 -0800 (PST) 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: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160215180233.30650.39279.idtracker@ietfa.amsl.com> Date: Mon, 15 Feb 2016 10:02:33 -0800 Archived-At: Cc: codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-oggopus@ietf.org Subject: [codec] Stephen Farrell's No Objection on draft-ietf-codec-oggopus-13: (with COMMENT) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 18:02:33 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-codec-oggopus-13: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - general, (but a nit): there are some odd unexplained numbers here, which is fine ... but odd. (E.g. 125,829,120) It might be nicer to explain to the reader why these values were chosen. I assume there are unstated reasons that an implementer need not know - if an implementer really should grok why one of these odd numbers is used, then that would be better explained. - An example or diagram in the intro or section 3 would maybe have helped. - section 5: Q7.8 is a new one to me. Maybe add a reference? - 5.1.1.5: Could figures 3-8 do with some body text to explain them? That's (having body text that refers to the figures), general good practice and I'm not sure if they're sufficiently clear for an implementer to get right. (But as I'm not coding this, I don't know, so just checking:-) - 5.2: You don't say that the user comment strings must also be UTF8, but you do for the vendor string. Why not? I think it'd be good to call that out. - 5.2.1: [vorbis-comment] is, correctly, a normative reference here but I wonder if a xiph.org URL is a good enough reference for that. Is there anything better, or are we confident enough in that URL? - 5.2.1: From what namespace are the -573 and 111 values here selected? How is that managed? (Just wondering.) - section 9: While I like the MUST NOT here, it's really only wishful thinking and isn't a strictly valid use of 2119 terms. I'm ok with that though. The SHOULD NOT statement is also kind of bogus. Generally this section would be better if it had guidance on where implementers are likely to go wrong in ways that cause security issues. Reference such as are provided in RFC 6562 about the dangers of VBR might also be useful here, not sure. From nobody Tue Feb 16 09:00:19 2016 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D65491B2FBE; Tue, 16 Feb 2016 09:00:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Joel Jaeggli" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160216170016.13734.77381.idtracker@ietfa.amsl.com> Date: Tue, 16 Feb 2016 09:00:16 -0800 Archived-At: Cc: codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-oggopus@ietf.org Subject: [codec] Joel Jaeggli's No Objection on draft-ietf-codec-oggopus-13: (with COMMENT) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 17:00:17 -0000 Joel Jaeggli has entered the following ballot position for draft-ietf-codec-oggopus-13: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Scott Bradner performed the OPSdir review. There was an ask for a paragraph covering the following That said, I wonder if it would be possible to as a OAM-like ability to support "in-band" condition information - for example by adding an OAM channel to the channel mapping function (i.e. the "Opus Channel Mapping Families" registry) where the definition would be that the channel is for the use of OAM services and is otherwise passed unmodified. Having the ability to have real time "what the customer is seeing" RTCP like, but with more expansion abilities, feedback could be quite helpful operations-wise which has not yet come to conclusion. From nobody Tue Feb 16 16:20:03 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515F91B2DBA; Tue, 2 Feb 2016 17:43:26 -0800 (PST) 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 CRndBGse2Mzl; Tue, 2 Feb 2016 17:43:25 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 2C2361B2DA2; Tue, 2 Feb 2016 17:43:25 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id j78so4095944lfb.1; Tue, 02 Feb 2016 17:43:25 -0800 (PST) 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=lUoK8pH8/TphfudbQLB4vKoN6HCaw1EUKDoqXjapUlQ=; b=X6JY0AUEyvNYPVTP3SdPWncLpauV5Dxky4o6l9phxlloxPJRlkNjli3UNrNwNONoW4 GhduxcZOwRacDTuS6HZIITeiyABdxhrQDtYyDAoVmC0Wp0FQ4q0quzAhYohTbrlVzxcf OTmLrRZfibPCQyjygV1argXNOvfLifDj0l0G5/jPTQji+dBEGD00YK2kl5bEMmbJVhe8 YQ1DFptGsVznqlnPhZxs85rTEk/Ta0oYVcQ3BNGYB3VfzYu7tCDybVE3qo0id4s6yKO4 Gtambbxxho8P17mKhr/8OWbU9gr7ms17Gm23COzVGaRWa5FeTKD5Rd58imt0385bk0UK 4W6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lUoK8pH8/TphfudbQLB4vKoN6HCaw1EUKDoqXjapUlQ=; b=h95Uui+23WE6NOPNJBS6KZqHOw5JMRhvyIX8wHjXpSZdVb5ZQALD9574mp9NRKgc2s CVZIdBDBZWxRNzX5I6XCU+wNGnxg+UkEUzkiLRyEDU81kAT5IgW7/6i/RJAGaKIKctrZ tZb07yMr6dgMhUr9O/sBG2n8S9M2mG5qT/DTxNwekgpWU1+zV1hJ65rPhXzcBZHYByk7 dB9V0jKCgx/diebAI7Q1lP+G5rvoJ5R5PDEwTiYVY3vUMSB47MG5XTJHQn/yNCK1erR7 B0GXq2LLTZl2hUHqFbW4pohARYo/ORMpHpCL9/ZepNzzQ+78l5JSiUpwqMayiymDCcV/ 7Y6g== X-Gm-Message-State: AG10YOSfEw94ZlbuWXcmgeALLiCD1Tqlt9RjI4nYitBwYDiH54TUnLIZPwvFjjEyGbA9mmgaZBuL/IfVL590Rg== MIME-Version: 1.0 X-Received: by 10.25.165.4 with SMTP id o4mr4008649lfe.43.1454463803333; Tue, 02 Feb 2016 17:43:23 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.49.80 with HTTP; Tue, 2 Feb 2016 17:43:23 -0800 (PST) In-Reply-To: <780287DC-988D-4279-86B9-58932506698A@stewe.org> References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> <56B12D2A.4020906@xiph.org> <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> <56B132E9.504@xiph.org> <780287DC-988D-4279-86B9-58932506698A@stewe.org> Date: Tue, 2 Feb 2016 20:43:23 -0500 X-Google-Sender-Auth: ITuc7clHuTS-QyUPxfwuN4dXdbM Message-ID: From: Phillip Hallam-Baker To: Stephan Wenger Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Tue, 16 Feb 2016 16:20:02 -0800 Cc: "ietf@ietf.org" , "codec@ietf.org" , "draft-ietf-codec-oggopus@ietf.org" , "codec-chairs@ietf.org" Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 01:43:26 -0000 I think people need to remember that 'forks happen'. IETF has forked other standards bodies on quite a few occasions. Notably the WebPKI is built on PKIX, not X.509. If we are OK with that, we should be OK with other people forking our work. That doesn't seem to be the intention here but it is a possible outcome. The issue seems to be that they are sure other people will want to build on the CODEC but not precisely how it would modularize. At least not now. My concern is not so much version N versus version N', it is the question of what happens for version N+1. Do the forks continue or is one orphaned (like X.509v3). Another possibility to consider is that the group goes off and does its 'thing' and when it is ready, comes back with an update, supplement or whatever. That way we can merge the streams back into one at a later date (should that seem desirable). From nobody Tue Feb 16 16:20:05 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A401B3627; Wed, 3 Feb 2016 14:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 qxYGjqqsuAMz; Wed, 3 Feb 2016 14:59:38 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 DF2A71B3626; Wed, 3 Feb 2016 14:59:37 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u13MxaWH069679 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 3 Feb 2016 16:59:36 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "Timothy B. Terriberry" , Stephan Wenger , Ron References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> <56B12D2A.4020906@xiph.org> <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> <20160203033855.GO3153@hex.shelbyville.oz> <56B17FC4.7000901@xiph.org> <9B1A525A-5ADE-4AB1-962C-DD826D86C5DA@stewe.org> <56B252D6.9050202@xiph.org> From: Adam Roach Message-ID: <56B28657.3050801@nostrum.com> Date: Wed, 3 Feb 2016 16:59:35 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B252D6.9050202@xiph.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 16 Feb 2016 16:20:02 -0800 Cc: "codec-chairs@ietf.org" , "codec@ietf.org" , "draft-ietf-codec-oggopus@ietf.org" , "ietf@ietf.org" Subject: Re: [codec] Last Call: (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 22:59:41 -0000 From what I can see, the text in RFC 5378 is pretty unambiguous that the rights granted to the IETF trust are non-exclusive. I don't imagine we're arguing about whether authors have the legal ability to grant rights in their work to others under different terms, as long as those terms don't somehow interfere with the rights granted to the IETF. For this document, it's clear that the authors intend to grant additional rights to their text. I think there are two questions here: the first is whether the authors are allowed to be transparent and include the extra rights grant as part of the IETF document, or if they simply indicate that rights grant in some other venue and leave the RFC silent on the topic. I suspect that more information is better than less, and that is not in the IETF's interest to bury the intention to grant additional rights. To that end, I see the RFC 5215 and RFC 6716 approaches as vastly superior to hiding the grant in the XML source [1] or precluding mention altogether. The second question is whether the authors should have the IETF Trust grant these additional rights (in the style of RFC 6716), or whether the authors grant these rights directly (as in RFC 5215). I don't think it matters, but we should certainly allow at least one of the two formulations. It would also be nice if we settled on a recommended practice, and documented it somewhere so that it didn't cause a hullabaloo whenever authors tried to grant additional rights. /a _____ [1] Obligatory Douglas Adams reference: Prosser: But Mr. Dent, the plans have been available in the local planning office for the last nine months. Arthur: Oh yes, well as soon as I heard I went straight round to see them, yesterday afternoon. You hadn't exactly gone out of your way to call attention to them had you? I mean like actually telling anybody or anything. Prosser: But the plans were on display... Arthur: On display? I eventually had to go down to the cellar to find them. Prosser: That's the display department. Arthur: With a torch. Prosser: The lights had probably gone out. Arthur: So had the stairs. Prosser: But look, you found the notice, didn't you? Arthur: Yes. Yes I did. It was on display at the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "beware of the leopard." On 2/3/16 13:19, Timothy B. Terriberry wrote: > Hi Stephan, > > Stephan Wenger wrote: >> However, it is still a procedural end-run around the currently > > in-force IETF position that the IETF reserves the right for itself to > > create derivative works from the RFCs it created (my paraphrasing). > > I am trying to follow the procedure. RFC 5377 says that authors should > be able to grant these rights. The first example I know of people > doing this was by putting a copyright statement in the XML source (RFC > 2629). But my understanding was that it was later preferred that an > additional grant be added in a section of the draft (see RFC 5215 > Section 11). Then with RFC 6716 the IETF decided it was better to add > this grant to the boilerplate text. Now there are objections to that > approach, and we've come full circle to a copyright statement in the > XML source again. As long as there is some way to do it, then I am happy. > >> Now, such a narrow exception does not solve the open source related >> problems, but for that you should really start a debate about the >> copyright policy as a whole, because it would be a major change >> affecting key tradeoffs of that policy that were deliberated literally >> for years. > > I am actually personally fine if most authors do not want to grant > these rights. To my mind, they are the ones who wrote the documents, > and if they see these restrictions as beneficial, it's not my place to > tell them they are not allowed to have them. > From nobody Tue Feb 16 18:11:21 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6484D1B2AF7; Tue, 16 Feb 2016 18:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 BEo3QpXgrnHB; Tue, 16 Feb 2016 18:11:14 -0800 (PST) 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 2BB931AC409; Tue, 16 Feb 2016 18:11:14 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 8BCD0C128D; Wed, 17 Feb 2016 02:11:12 +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 LRVWgKE6JTgo; Wed, 17 Feb 2016 02:11:12 +0000 (UTC) Received: from [10.252.26.22] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 5FD45C0531; Wed, 17 Feb 2016 02:11:12 +0000 (UTC) Message-ID: <56C3D6C0.70904@xiph.org> Date: Tue, 16 Feb 2016 18:11:12 -0800 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: Stephen Farrell , The IESG References: <20160215180233.30650.39279.idtracker@ietfa.amsl.com> In-Reply-To: <20160215180233.30650.39279.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------050606040502040502050105" Archived-At: Cc: codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-oggopus@ietf.org Subject: Re: [codec] Stephen Farrell's No Objection on draft-ietf-codec-oggopus-13: (with COMMENT) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 02:11:19 -0000 This is a multi-part message in MIME format. --------------050606040502040502050105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks for the detailed comments. Responses are in-line below. Stephen Farrell wrote: > - general, (but a nit): there are some odd unexplained numbers > here, which is fine ... but odd. (E.g. 125,829,120) It might be > nicer to explain to the reader why these values were chosen. I The number quoted is just 120 MB (120*1024*1024). I added a parenthetical to clarify this. The 61,440 number in the same paragraph is explained later in the text. Happy to clarify any others you think should be explained better. > - An example or diagram in the intro or section 3 would maybe > have helped. The appropriate figure for the introduction is probably the one from Section 5 of RFC 3533. We could copy it here, but I think the reference is enough (it would probably require more text to explain it, text which is already in RFC 3533). Section 3 is a bit more specific to this draft. I added the following figure: Page 1 Pages 2 ... n Pages (n+1) ... +------------+ +---+ +---+ ... +---+ +-----------+ +---------+ +-- | | | | | | | | | | | | | |+----------+| |+-----------------+| |+-------------------+ +----- |||ID Header|| || Comment Header || ||Audio Data Packet 1| | ... |+----------+| |+-----------------+| |+-------------------+ +----- | | | | | | | | | | | | | +------------+ +---+ +---+ ... +---+ +-----------+ +---------+ +-- ^ ^ ^ | | | | | Mandatory page break | | | ID header is contained on a single page | 'Beggining Of Stream' Figure 1: Example packet organization for a logical Ogg Opus stream > - section 5: Q7.8 is a new one to me. Maybe add a reference? Added a reference to . > - 5.1.1.5: Could figures 3-8 do with some body text to explain > them? That's (having body text that refers to the figures), > general good practice and I'm not sure if they're sufficiently > clear for an implementer to get right. (But as I'm not coding > this, I don't know, so just checking:-) I think the meaning is relatively unambiguous, but certainly adding a reference to the figures instead of just saying "the following matrices" would be clearer, so I have done that. > - 5.2: You don't say that the user comment strings must also be > UTF8, but you do for the vendor string. Why not? I think it'd be > good to call that out. The text doesn't but the header says: "User Comment #i String (variable length, UTF-8 vector):" I've normalized the text to match that of the vendor string for consistency, however. > - 5.2.1: [vorbis-comment] is, correctly, a normative reference > here but I wonder if a xiph.org URL is a good enough reference > for that. Is there anything better, or are we confident enough > in that URL? According to archive.org, that URL has been stable since at least 2005 (since the year 2000, according to our svn logs, but the final version for Vorbis 1.0 wasn't posted until July 11th 2002). I don't know of a better authority. > - 5.2.1: From what namespace are the -573 and 111 values here > selected? How is that managed? (Just wondering.) Those values are just examples. I've added a sentence saying that, since it must not have been clear. The syntax for them is described in the paragraph below. If people feel that description is imprecise we could probably add some EBNF. > - section 9: While I like the MUST NOT here, it's really only > wishful thinking and isn't a strictly valid use of 2119 terms. > I'm ok with that though. The SHOULD NOT statement is also kind > of bogus. Generally this section would be better if it had > guidance on where implementers are likely to go wrong in ways > that cause security issues. Reference such as are provided in I agree. The current text was adapted from RFC 6716, but I think we have enough implementation experience at this point to write something better. I propose the following additional text: Header parsing code contains the most likely area for potential overruns. It is important for implementations to ensure their buffers contain enough data for all of the required fields before attempting to read it (for example, for all of the channel map data in the ID header). Implementations would do well to validate the indices of the channel map, also, to ensure they meet all of the restrictions outlined in Section 5.1.1, in order to avoid attempting to read data from channels that do not exist. To avoid excessive resource usage, we advise implementations to be especially wary of streams that might cause them to process far more data than was actually transmitted. For example, a relatively small comment header may contain values for the string lengths or user comment list length that imply that it is many gigabytes in size. Even computing the size of the required buffer could overflow a 32-bit integer, and actually attempting to allocate such a buffer before verifying it would be a reasonable size is a bad idea. After reading the user comment list length, implementations might wish to verify that the header contains at least the minimum amount of data for that many comments (4 additional octets per comment, to indicate each has a length of zero) before proceeding any further, again taking care to avoid overflow in these calculations. If allocating an array of pointers to point at these strings, the size of the pointers may be larger than 4 octets, potentially requiring a separate overflow check. Another bug in this class we have observed more than once involves the handling of invalid data at the end of a stream. Often, implementations will seek to the end of a stream to locate the last timestamp in order to compute its total duration. If they do not find a valid capture pattern and Ogg page from the desired logical stream, they will back up and try again. If care is not taken to avoid re-scanning data that was already scanned, this search can quickly devolve into something with a complexity that is quadratic in the amount of invalid data. In general when seeking, implementations will wish to be cautious about the effects of invalid granule position values, and ensure all algorithms will continue to make progress and eventually terminate, even if these are missing or out-of-order. > RFC 6562 about the dangers of VBR might also be useful here, not > sure. In most of the expected uses of Ogg Opus on the internet (e.g., https streaming), the encryption and network packetization would be separate from the container's packetization/pagination, so I don't think the dangers referred to by RFC 6562 apply (if you can see the Ogg packet sizes, it's because you already have access to the decrypted plaintext). In other contexts, RFC 6716 already includes a reference to 6562. I've attached a diff of the relevant changes to the XML. --------------050606040502040502050105 Content-Type: text/x-patch; name="0001-oggopus-Address-Stephen-Farrell-s-IESG-comments.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-oggopus-Address-Stephen-Farrell-s-IESG-comments.patch" >From f26c35306410228f3870e136502620b4177b9112 Mon Sep 17 00:00:00 2001 From: "Timothy B. Terriberry" Date: Tue, 16 Feb 2016 18:05:10 -0800 Subject: [PATCH] oggopus: Address Stephen Farrell's IESG comments. - Clarify that 125,829,120 is just 120 MB. - Add a figure to Section 3 of an example logical stream. - Add a reference for Q notation. - Refer to the downmixing figures in the text. - Clarify that user comments are UTF-8. - Clarify that the -573 and 111 gain values are examples. - Add specific advice to implementors on areas that have security implications. --- doc/draft-ietf-codec-oggopus.xml | 106 +++++++++++++++++++++++++++++++++++---- 1 file changed, 97 insertions(+), 9 deletions(-) diff --git a/doc/draft-ietf-codec-oggopus.xml b/doc/draft-ietf-codec-oggopus.xml index e2b38aa..ff65ae6 100644 --- a/doc/draft-ietf-codec-oggopus.xml +++ b/doc/draft-ietf-codec-oggopus.xml @@ -159,18 +159,42 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .
-An Ogg Opus stream is organized as follows. +An Ogg Opus stream is organized as follows (see + for an example). + +
+ +
+ There are two mandatory header packets. The first packet in the logical Ogg bitstream MUST contain the identification (ID) header, which uniquely identifies a stream as Opus audio. The format of this header is defined in . It is placed alone (without any other packet data) on the first page of the logical Ogg bitstream, and completes on that page. This page has its 'beginning of stream' flag set. @@ -734,17 +758,18 @@ Rates outside this range MAY be ignored by falling back to the default rate of 48 kHz instead. Output Gain (16 bits, signed, little endian): This is a gain to be applied when decoding. It is 20*log10 of the factor by which to scale the decoder output to achieve the desired playback volume, stored in a 16-bit, signed, two's complement - fixed-point value with 8 fractional bits (i.e., Q7.8). + fixed-point value with 8 fractional bits (i.e., + Q7.8 ). To apply the gain, an implementation could use
where output_gain is the raw 16-bit value from the header. @@ -986,19 +1011,22 @@ A demuxer implementation encountering a reserved channel mapping family value An Ogg Opus player MUST support any valid channel mapping with a channel mapping family of 0 or 1, even if the number of channels does not match the physically connected audio hardware. Players SHOULD perform channel mixing to increase or reduce the number of channels as needed. -Implementations MAY use the following matrices to implement downmixing from - multichannel files using Channel Mapping - Family 1, which are known to give acceptable results for stereo. +Implementations MAY use the matrices in + Figures  + through  to implement + downmixing from multichannel files using + Channel Mapping Family 1, which are + known to give acceptable results for stereo. Matrices for 3 and 4 channels are normalized so each coefficient row sums to 1 to avoid clipping. For 5 or more channels they are normalized to 2 as a compromise between clipping and dynamic range reduction. In these matrices the front left and front right channels are generally passed through directly. @@ -1205,17 +1233,18 @@ It MUST NOT indicate that there are so many comments that the comment string This field gives the length of the following user comment string, in octets. There is one for each user comment indicated by the 'user comment list length' field. It MUST NOT indicate that the string is longer than the rest of the packet. User Comment #i String (variable length, UTF-8 vector): -This field contains a single user comment string. +This field contains a single user comment encoded as a UTF-8 + string . There is one for each user comment indicated by the 'user comment list length' field. The vendor string length and user comment list length are REQUIRED, and @@ -1241,19 +1270,19 @@ This allows informal experimentation with the format of this binary data until The comment header can be arbitrarily large and might be spread over a large number of Ogg pages. Implementations MUST avoid attempting to allocate excessive amounts of memory when presented with a very large comment header. To accomplish this, implementations MAY treat a stream as invalid if it has a - comment header larger than 125,829,120 octets, and MAY ignore individual - comments that are not fully contained within the first 61,440 octets of - the comment header. + comment header larger than 125,829,120 octets (120 MB), and MAY + ignore individual comments that are not fully contained within the first + 61,440 octets of the comment header.
The user comment strings follow the NAME=value format described by with the same recommended tag names: ARTIST, TITLE, DATE, ALBUM, and so on. @@ -1282,16 +1311,17 @@ This tag is similar to the REPLAYGAIN_TRACK_GAIN tag in R128_ALBUM_GAIN=111 ]]> representing the volume shift needed to normalize the overall volume when played as part of a particular collection of tracks. The gain is also a Q7.8 fixed point number in dB, as in the ID header's 'output gain' field. +The values '-573' and '111' given here are just examples. An Ogg Opus stream MUST NOT have more than one of each of these tags, and if present their values MUST be an integer from -32768 to 32767, inclusive, represented in ASCII as a base 10 number with no whitespace. A leading '+' or '-' character is valid. Leading zeros are also permitted, but the value MUST be represented by no more than 6 characters. @@ -1517,16 +1547,66 @@ Malicious payloads MUST NOT cause an implementation to overrun its allocated Although problems in encoding applications are typically rarer, the same applies to the muxer. Malicious audio input streams MUST NOT cause an implementation to overrun its allocated memory or consume excessive resources because this would allow an attacker to attack transcoding gateways. +Header parsing code contains the most likely area for potential overruns. +It is important for implementations to ensure their buffers contain enough + data for all of the required fields before attempting to read it (for example, + for all of the channel map data in the ID header). +Implementations would do well to validate the indices of the channel map, also, + to ensure they meet all of the restrictions outlined in + , in order to avoid attempting to read data + from channels that do not exist. + + + +To avoid excessive resource usage, we advise implementations to be especially + wary of streams that might cause them to process far more data than was + actually transmitted. +For example, a relatively small comment header may contain values for the + string lengths or user comment list length that imply that it is many + gigabytes in size. +Even computing the size of the required buffer could overflow a 32-bit integer, + and actually attempting to allocate such a buffer before verifying it would be + a reasonable size is a bad idea. +After reading the user comment list length, implementations might wish to + verify that the header contains at least the minimum amount of data for that + many comments (4 additional octets per comment, to indicate each has a + length of zero) before proceeding any further, again taking care to avoid + overflow in these calculations. +If allocating an array of pointers to point at these strings, the size of the + pointers may be larger than 4 octets, potentially requiring a separate + overflow check. + + + +Another bug in this class we have observed more than once involves the handling + of invalid data at the end of a stream. +Often, implementations will seek to the end of a stream to locate the last + timestamp in order to compute its total duration. +If they do not find a valid capture pattern and Ogg page from the desired + logical stream, they will back up and try again. +If care is not taken to avoid re-scanning data that was already scanned, this + search can quickly devolve into something with a complexity that is quadratic + in the amount of invalid data. + + + +In general when seeking, implementations will wish to be cautious about the + effects of invalid granule position values, and ensure all algorithms will + continue to make progress and eventually terminate, even if these are missing + or out-of-order. + + + Like most other container formats, Ogg Opus streams SHOULD NOT be used with insecure ciphers or cipher modes that are vulnerable to known-plaintext attacks. Elements such as the Ogg page capture pattern and the magic signatures in the ID header and the comment header all have easily predictable values, in addition to various elements of the codec data itself.
@@ -1712,16 +1792,24 @@ In , "RFCXXXX" is to be replaced with the RFC number Autocorrelation LPC coeff generation algorithm (Vorbis source code) + + +Q (number format) +Wikipedia + + + VorbisComment: Replay Gain -- 1.8.3.2 --------------050606040502040502050105-- From nobody Tue Feb 16 18:26:27 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF221A0273; Tue, 16 Feb 2016 18:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.307 X-Spam-Level: X-Spam-Status: No, score=-4.307 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_MED=-2.3, RP_MATCHES_RCVD=-0.006, 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 i7ZJvzYm8CtK; Tue, 16 Feb 2016 18:26:18 -0800 (PST) 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 1B6A11A026F; Tue, 16 Feb 2016 18:26:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B6A21BE54; Wed, 17 Feb 2016 02:26:16 +0000 (GMT) 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 KxLEJlcPbS61; Wed, 17 Feb 2016 02:26:12 +0000 (GMT) Received: from [10.10.11.56] (unknown [104.220.240.149]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3FC34BE3E; Wed, 17 Feb 2016 02:26:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1455675972; bh=deRjZ0NgYE5CSla3I8Aj/vTy1VM2734c5bbOXPiZNUQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=odrD3iPLdr7WnRqy23WnLtv108K9ok2RLbo0yXxQe/MKrjGLdl+Z3BCTGLZGEWf7u JlHgAjhqBtXR4Vz5+WWcmzJeibpkSyZrs3ubbLYggifQXUBEUp+44dcN1kohlmRHA0 kmcWtdnqX7yjNsOieMv6WUQoN6uMvdKsz/q//rZ8= To: "Timothy B. Terriberry" , The IESG References: <20160215180233.30650.39279.idtracker@ietfa.amsl.com> <56C3D6C0.70904@xiph.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56C3DA41.60107@cs.tcd.ie> Date: Wed, 17 Feb 2016 02:26:09 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56C3D6C0.70904@xiph.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060905080102020604090300" Archived-At: Cc: codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-oggopus@ietf.org Subject: Re: [codec] Stephen Farrell's No Objection on draft-ietf-codec-oggopus-13: (with COMMENT) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 02:26:23 -0000 This is a cryptographically signed message in MIME format. --------------ms060905080102020604090300 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Thanks - I'm fine with all that and especially the new security considerations text which seems much better, Cheers, S. On 17/02/16 02:11, Timothy B. Terriberry wrote: > Thanks for the detailed comments. Responses are in-line below. >=20 > Stephen Farrell wrote: >> - general, (but a nit): there are some odd unexplained numbers >> here, which is fine ... but odd. (E.g. 125,829,120) It might be >> nicer to explain to the reader why these values were chosen. I >=20 > The number quoted is just 120 MB (120*1024*1024). I added a > parenthetical to clarify this. The 61,440 number in the same paragraph > is explained later in the text. Happy to clarify any others you think > should be explained better. >=20 >> - An example or diagram in the intro or section 3 would maybe >> have helped. >=20 > The appropriate figure for the introduction is probably the one from > Section 5 of RFC 3533. We could copy it here, but I think the reference= > is enough (it would probably require more text to explain it, text whic= h > is already in RFC 3533). >=20 > Section 3 is a bit more specific to this draft. I added the following > figure: >=20 > Page 1 Pages 2 ... n Pages (n+1) ... > +------------+ +---+ +---+ ... +---+ +-----------+ +---------+ +--= > | | | | | | | | | | | | | > |+----------+| |+-----------------+| |+-------------------+ +-----= > |||ID Header|| || Comment Header || ||Audio Data Packet 1| | ... > |+----------+| |+-----------------+| |+-------------------+ +-----= > | | | | | | | | | | | | | > +------------+ +---+ +---+ ... +---+ +-----------+ +---------+ +--= > ^ ^ ^ > | | | > | | Mandatory page break > | | > | ID header is contained on a single page > | > 'Beggining Of Stream' >=20 > Figure 1: Example packet organization for a logical Ogg Opus stream= >=20 >=20 >> - section 5: Q7.8 is a new one to me. Maybe add a reference? >=20 > Added a reference to > . >=20 >=20 >> - 5.1.1.5: Could figures 3-8 do with some body text to explain >> them? That's (having body text that refers to the figures), >> general good practice and I'm not sure if they're sufficiently >> clear for an implementer to get right. (But as I'm not coding >> this, I don't know, so just checking:-) >=20 > I think the meaning is relatively unambiguous, but certainly adding a > reference to the figures instead of just saying "the following matrices= " > would be clearer, so I have done that. >=20 >> - 5.2: You don't say that the user comment strings must also be >> UTF8, but you do for the vendor string. Why not? I think it'd be >> good to call that out. >=20 > The text doesn't but the header says: >=20 > "User Comment #i String (variable length, UTF-8 vector):" >=20 > I've normalized the text to match that of the vendor string for > consistency, however. >=20 >> - 5.2.1: [vorbis-comment] is, correctly, a normative reference >> here but I wonder if a xiph.org URL is a good enough reference >> for that. Is there anything better, or are we confident enough >> in that URL? >=20 > According to archive.org, that URL has been stable since at least 2005 > (since the year 2000, according to our svn logs, but the final version > for Vorbis 1.0 wasn't posted until July 11th 2002). I don't know of a > better authority. >=20 >> - 5.2.1: From what namespace are the -573 and 111 values here >> selected? How is that managed? (Just wondering.) >=20 > Those values are just examples. I've added a sentence saying that, sinc= e > it must not have been clear. The syntax for them is described in the > paragraph below. If people feel that description is imprecise we could > probably add some EBNF. >=20 >> - section 9: While I like the MUST NOT here, it's really only >> wishful thinking and isn't a strictly valid use of 2119 terms. >> I'm ok with that though. The SHOULD NOT statement is also kind >> of bogus. Generally this section would be better if it had >> guidance on where implementers are likely to go wrong in ways >> that cause security issues. Reference such as are provided in >=20 > I agree. The current text was adapted from RFC 6716, but I think we hav= e > enough implementation experience at this point to write something > better. I propose the following additional text: >=20 > Header parsing code contains the most likely area for potential > overruns. It is important for implementations to ensure their > buffers contain enough data for all of the required fields before > attempting to read it (for example, for all of the channel map data > in the ID header). Implementations would do well to validate the > indices of the channel map, also, to ensure they meet all of the > restrictions outlined in Section 5.1.1, in order to avoid attempting= > to read data from channels that do not exist. >=20 > To avoid excessive resource usage, we advise implementations to be > especially wary of streams that might cause them to process far more= > data than was actually transmitted. For example, a relatively small= > comment header may contain values for the string lengths or user > comment list length that imply that it is many gigabytes in size. > Even computing the size of the required buffer could overflow a > 32-bit integer, and actually attempting to allocate such a buffer > before verifying it would be a reasonable size is a bad idea. After= > reading the user comment list length, implementations might wish to > verify that the header contains at least the minimum amount of data > for that many comments (4 additional octets per comment, to indicate= > each has a length of zero) before proceeding any further, again > taking care to avoid overflow in these calculations. If allocating > an array of pointers to point at these strings, the size of the > pointers may be larger than 4 octets, potentially requiring a > separate overflow check. >=20 > Another bug in this class we have observed more than once involves > the handling of invalid data at the end of a stream. Often, > implementations will seek to the end of a stream to locate the last > timestamp in order to compute its total duration. If they do not > find a valid capture pattern and Ogg page from the desired logical > stream, they will back up and try again. If care is not taken to > avoid re-scanning data that was already scanned, this search can > quickly devolve into something with a complexity that is quadratic i= n > the amount of invalid data. >=20 > In general when seeking, implementations will wish to be cautious > about the effects of invalid granule position values, and ensure all= > algorithms will continue to make progress and eventually terminate, > even if these are missing or out-of-order. >=20 >=20 >> RFC 6562 about the dangers of VBR might also be useful here, not >> sure. >=20 > In most of the expected uses of Ogg Opus on the internet (e.g., https > streaming), the encryption and network packetization would be separate > from the container's packetization/pagination, so I don't think the > dangers referred to by RFC 6562 apply (if you can see the Ogg packet > sizes, it's because you already have access to the decrypted plaintext)= =2E > In other contexts, RFC 6716 already includes a reference to 6562. >=20 > I've attached a diff of the relevant changes to the XML. --------------ms060905080102020604090300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAyMTcw MjI2MDlaMC8GCSqGSIb3DQEJBDEiBCDRq322QvtH38fmWoN+zIE57dI7zXpA90RA3lPB4M8m /jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCQ9ArG1nQSUK9jh4TVOvECH+z+2qrxpXyw8vNQSD7p8uzc3fyD41zo 2GNzqkp0wYUuJks83z9MxQxFRnVhf4MPlpjMKS1aGLGyFarFLKVwqOB6P6y79W7muoqFoG9t zddWOPmi+zq30b91o/+3ZJQwZH1zguCZ0GscuWW8iZMR8Fc0eavxlbbqaPaCktT5lRnKPNfR 7ZOWaCpx3kMeMRdRDOqaMe23GNRohl+kcW4fw3lP6c9Ig4EzfwyF7OuKLe6QMd9b+dCCTR1P Kt3Oodn+qYUaC0Naqd7F1BzxVL/NSwgPnjRfsaiDk7+EDOwJchFNAQp7hrS7OnOO3lQtvApN AAAAAAAA --------------ms060905080102020604090300-- From nobody Tue Feb 16 18:27:44 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17421A1BB5; Tue, 16 Feb 2016 18:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 yME6uOHDTsLF; Tue, 16 Feb 2016 18:27:41 -0800 (PST) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (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 39C821A1BA4; Tue, 16 Feb 2016 18:27:38 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id BF152C5199; Wed, 17 Feb 2016 02:27:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZ9fCB579a0r; Wed, 17 Feb 2016 02:27:37 +0000 (UTC) Received: from [10.252.26.22] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id A2A4BC0332; Wed, 17 Feb 2016 02:27:37 +0000 (UTC) Message-ID: <56C3DA99.8060400@xiph.org> Date: Tue, 16 Feb 2016 18:27:37 -0800 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: Joel Jaeggli , The IESG References: <20160216170016.13734.77381.idtracker@ietfa.amsl.com> In-Reply-To: <20160216170016.13734.77381.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-oggopus@ietf.org Subject: Re: [codec] Joel Jaeggli's No Objection on draft-ietf-codec-oggopus-13: (with COMMENT) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 02:27:42 -0000 Joel Jaeggli wrote: > Scott Bradner performed the OPSdir review. > > There was an ask for a paragraph covering the following > > That said, I wonder if it would be possible to as a OAM-like ability to > support "in-band" condition information - for example by adding an OAM > channel to the channel mapping function (i.e. the "Opus Channel Mapping > Families" registry) where the definition would be that the channel is for > the use of OAM services and is otherwise passed unmodified. Having the > ability to have real time "what the customer is seeing" RTCP like, but > with more expansion abilities, feedback could be quite helpful > operations-wise > > which has not yet come to conclusion. I'll attempt to summarize where I think the discussion currently is: both Scott and I agreed that it is probably too late in the process to make changes to the channel mappings in this document, and that could be done later via the IANA registry. A general paragraph stating that someone should be thinking about OAM type things would be welcome, but I don't feel qualified to write one, and we currently lack a volunteer to do so. From nobody Tue Feb 16 22:36:05 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D451ACD8E; Tue, 16 Feb 2016 22:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 rkDqBRSQZavy; Tue, 16 Feb 2016 22:36:02 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 1D3301A8A60; Tue, 16 Feb 2016 22:36:02 -0800 (PST) Received: from mb-2.local ([IPv6:2601:647:4204:51:c4fd:c888:b630:384a]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u1H6a0eX040130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 Feb 2016 06:36:01 GMT (envelope-from joelja@bogus.com) To: "Timothy B. Terriberry" , The IESG References: <20160216170016.13734.77381.idtracker@ietfa.amsl.com> <56C3DA99.8060400@xiph.org> From: joel jaeggli Message-ID: <006463b0-052f-dcef-b902-1d72ddd664de@bogus.com> Date: Tue, 16 Feb 2016 22:36:01 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <56C3DA99.8060400@xiph.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L3BKPWofP69AuK7nq3Uc0uukFvbffRvVH" Archived-At: Cc: codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-oggopus@ietf.org Subject: Re: [codec] Joel Jaeggli's No Objection on draft-ietf-codec-oggopus-13: (with COMMENT) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 06:36:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --L3BKPWofP69AuK7nq3Uc0uukFvbffRvVH Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/16/16 6:27 PM, Timothy B. Terriberry wrote: > Joel Jaeggli wrote: >> Scott Bradner performed the OPSdir review. >> >> There was an ask for a paragraph covering the following >> >> That said, I wonder if it would be possible to as a OAM-like ability t= o >> support "in-band" condition information - for example by adding an OAM= >> channel to the channel mapping function (i.e. the "Opus Channel Mappin= g >> Families" registry) where the definition would be that the channel is = for >> the use of OAM services and is otherwise passed unmodified. Having th= e >> ability to have real time "what the customer is seeing" RTCP like, but= >> with more expansion abilities, feedback could be quite helpful >> operations-wise >> >> which has not yet come to conclusion. >=20 > I'll attempt to summarize where I think the discussion currently is: > both Scott and I agreed that it is probably too late in the process to > make changes to the channel mappings in this document, and that could b= e > done later via the IANA registry. A general paragraph stating that > someone should be thinking about OAM type things would be welcome, but = I > don't feel qualified to write one, and we currently lack a volunteer to= > do so. yup, I don't hold a discuss so I'm not an obstacle to progress, but if we come up with that either collectively or indivudally then great. --L3BKPWofP69AuK7nq3Uc0uukFvbffRvVH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbEFNIACgkQ8AA1q7Z/VrJPBwCggqv82GF+yAojmbnl8B2gpUA6 qnkAnR6PiKeFGFfC8HSsyyEZbju7aBSJ =3LOv -----END PGP SIGNATURE----- --L3BKPWofP69AuK7nq3Uc0uukFvbffRvVH-- From nobody Wed Feb 17 09:14:55 2016 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E88081ACE99; Wed, 17 Feb 2016 09:14:53 -0800 (PST) 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: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160217171453.30561.96304.idtracker@ietfa.amsl.com> Date: Wed, 17 Feb 2016 09:14:53 -0800 Archived-At: Cc: codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-oggopus@ietf.org Subject: [codec] Barry Leiba's No Objection on draft-ietf-codec-oggopus-13: (with COMMENT) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 17:14:54 -0000 Barry Leiba has entered the following ballot position for draft-ietf-codec-oggopus-13: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- Section 3 -- A demuxer SHOULD NOT attempt to decode the data for the first packet on a page with the 'continued packet' flag set if the previous page with packet data does not end in a continued packet (i.e., did not end with a lacing value of 255) or if the page sequence numbers are not consecutive, unless the demuxer has some special knowledge that would allow it to interpret this data despite the missing pieces. This "SHOULD NOT" requirement is in a very long sentence with a few "ifs" and "buts", which make it hard to see what's really being required. Rewording to put the conditions up front might help. It'd also be good to explain why it's SHOULD NOT, rather than, say, MUST NOT. Under what conditions might I want to decode the first packet anyway, and what are the consequences of my doing that? It looks like the "unless" clause is there to explain that, in which case "MUST NOT ... unless" seems right. For the rewording, maybe this?: NEW If a page has the "continued packet" flag set and one of the following conditions is also true: - the previous page with packet data does not end in a continued packet (a lacing value of 255) OR - the page sequence numbers are not consecutive, then the demuxer SHOULD NOT attempt to decode the data for the first packet on the page unless the demuxer has some special knowledge that would allow it to interpret this data despite the missing pieces. END ...and then consider whether it really should be "MUST NOT ... unless". You should take similar action with the "SHOULD NOT" sentence in the next paragraph as well, as it has the same convolution problem. -- Section 5.2 -- In bullet 4, might it not be clearer to call it "User Comment List Count", rather than "Length"? In the list in general, I think it'd be clearer and more accurate to group all the "MUST NOT indicate that there are so many..." sorts of things into one one-sentence pargraph that says that the Vendor String and all the User Comments, together, MUST fit into the packet. No? -- Section 9 -- Malicious payloads MUST NOT cause an implementation to overrun its allocated memory or to take an excessive amount of resources to decode. ... Malicious audio input streams MUST NOT cause an implementation to overrun its allocated memory or consume excessive resources It's a small thing, rather at the nit level, but it doesn't make much sense to levy normative requirements on malicious actors. These would be much better if worded as requirements on the implementation, somewhat like this: NEW Malicious payloads and/or input streams can be used to attack codec implementations. Implementations MUST NOT overrun their allocated memory nor take an excessive amount of resources when decoding payloads or processing input streams. END -- Section 11 -- Modifications to this registry follow the "Specification Required with Expert Review" registration policy as defined in [RFC5226]. RFC 5226 does not define a policy with that name. The name is just "Specification Required"; please change this. And thanks for the paragraph giving guidance to the designated expert. From nobody Wed Feb 17 18:28:15 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3928C1B2F82; Wed, 17 Feb 2016 18:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 2lJsJRJaUeIw; Wed, 17 Feb 2016 18:28:06 -0800 (PST) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (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 B43491B2E9B; Wed, 17 Feb 2016 18:28:06 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 27B30C2D8F; Thu, 18 Feb 2016 02:28:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4i2uzr4akC2f; Thu, 18 Feb 2016 02:28:06 +0000 (UTC) Received: from [10.252.26.22] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 078A4C2036; Thu, 18 Feb 2016 02:28:06 +0000 (UTC) Message-ID: <56C52C35.5020603@xiph.org> Date: Wed, 17 Feb 2016 18:28:05 -0800 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: Barry Leiba , The IESG References: <20160217171453.30561.96304.idtracker@ietfa.amsl.com> In-Reply-To: <20160217171453.30561.96304.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------080606090204060306040500" Archived-At: Cc: codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-oggopus@ietf.org Subject: Re: [codec] Barry Leiba's No Objection on draft-ietf-codec-oggopus-13: (with COMMENT) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 02:28:11 -0000 This is a multi-part message in MIME format. --------------080606090204060306040500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks for these comments. Responses in-line below. Barry Leiba wrote: > For the rewording, maybe this?: > > NEW > If a page has the "continued packet" flag set and one of the following > conditions is also true: > - the previous page with packet data does not end in a continued packet > (a lacing value of 255) OR > - the page sequence numbers are not consecutive, > then the demuxer SHOULD NOT attempt to decode the data for the first > packet on the page unless the demuxer has some special knowledge that > would allow it to interpret this data despite the missing pieces. > END Applied (with minor edits). > ...and then consider whether it really should be "MUST NOT ... unless". I think you're right. Originally we had "SHOULD NOTs" for _muxers_ discouraging them from creating such streams, but we changed them to requirements specifying how _demuxers_ should handle them (because the burden of avoiding them in the live streaming case is such that we don't expect muxers to do it, and they have not historically in the past). But I can't think of a good reason (other than the provided exception) for a demuxer to do anything else. > You should take similar action with the "SHOULD NOT" sentence in the next > paragraph as well, as it has the same convolution problem. Done. > -- Section 5.2 -- > In bullet 4, might it not be clearer to call it "User Comment List > Count", rather than "Length"? It would be, but I wanted consistency with the terminology in the Vorbis spec. > In the list in general, I think it'd be clearer and more accurate to > group all the "MUST NOT indicate that there are so many..." sorts of > things into one one-sentence pargraph that says that the Vendor String > and all the User Comments, together, MUST fit into the packet. No? The intention here was that each MUST NOT corresponded to a specific check an implementation would do. That makes it easy for someone writing a parser to say, "Do I have a check corresponding to this restriction?" and realize they are missing something if they do not (though they do not cover everything, see also the new security considerations text). > NEW > Malicious payloads and/or input streams can be used to attack codec > implementations. Implementations MUST NOT overrun their allocated memory > nor take an excessive amount of resources when decoding payloads or > processing input streams. > END Applied (with additional revisions to the subsequent sentences). > -- Section 11 -- > > Modifications to this registry follow the "Specification > Required with Expert Review" registration policy as defined in > [RFC5226]. > > RFC 5226 does not define a policy with that name. The name is just Fixed. > "Specification Required"; please change this. And thanks for the > paragraph giving guidance to the designated expert. You're welcome! A diff of the changes against the XML source is attached. --------------080606090204060306040500 Content-Type: text/x-patch; name="0001-oggopus-Address-Barry-Leiba-s-IESG-comments.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-oggopus-Address-Barry-Leiba-s-IESG-comments.patch" >From 2c038009119a27fd7223500feadca7397cfe29ca Mon Sep 17 00:00:00 2001 From: "Timothy B. Terriberry" Date: Wed, 17 Feb 2016 18:24:35 -0800 Subject: [PATCH] oggopus: Address Barry Leiba's IESG comments. Thanks to Barry for proposing specific text for the changes. --- doc/draft-ietf-codec-oggopus.xml | 52 +++++++++++++++++++++++----------------- 1 file changed, 30 insertions(+), 22 deletions(-) diff --git a/doc/draft-ietf-codec-oggopus.xml b/doc/draft-ietf-codec-oggopus.xml index 1b4c131..61da699 100644 --- a/doc/draft-ietf-codec-oggopus.xml +++ b/doc/draft-ietf-codec-oggopus.xml @@ -243,40 +243,49 @@ The combination of coding mode, audio bandwidth, and frame size is referred to Packets are placed into Ogg pages in order until the end of stream. Audio data packets might span page boundaries. The first audio data page could have the 'continued packet' flag set (indicating the first audio data packet is continued from a previous page) if, for example, it was a live stream joined mid-broadcast, with the headers pasted on the front. -A demuxer SHOULD NOT attempt to decode the data for the first packet on a page - with the 'continued packet' flag set if the previous page with packet data - does not end in a continued packet (i.e., did not end with a lacing value of - 255) or if the page sequence numbers are not consecutive, unless the demuxer - has some special knowledge that would allow it to interpret this data - despite the missing pieces. +If a page has the 'continued packet' flag set and one of the following + conditions is also true: + +the previous page with packet data does not end in a continued packet (does + not end with a lacing value of 255) OR +the page sequence numbers are not consecutive, + + then a demuxer MUST NOT attempt to decode the data for the first packet on the + page unless the demuxer has some special knowledge that would allow it to + interpret this data despite the missing pieces. An implementation MUST treat a zero-octet audio data packet as if it were a malformed Opus packet as described in Section 3.4 of . A logical stream ends with a page with the 'end of stream' flag set, but implementations need to be prepared to deal with truncated streams that do not have a page marked 'end of stream'. There is no reason for the final packet on the last page to be a continued packet, i.e., for the final lacing value to be 255. However, demuxers might encounter such streams, possibly as the result of a transfer that did not complete or of corruption. -A demuxer SHOULD NOT attempt to decode the data from a packet that continues - onto a subsequent page (i.e., when the page ends with a lacing value of 255) - if the next page with packet data does not have the 'continued packet' flag - set or does not exist, or if the page sequence numbers are not consecutive, - unless the demuxer has some special knowledge that would allow it to interpret - this data despite the missing pieces. +If a packet continues onto a subsequent page (i.e., when the page ends with a + lacing value of 255) and one of the following conditions is also true: + +the next page with packet data does not have the 'continued packet' flag + set OR +there is no next page with packet data OR +the page sequence numbers are not consecutive, + + then a demuxer MUST NOT attempt to decode the data from that packet unless the + demuxer has some special knowledge that would allow it to interpret this data + despite the missing pieces. There MUST NOT be any more pages in an Opus logical bitstream after a page marked 'end of stream'.
The granule position MUST be zero for the ID header page and the @@ -1536,24 +1545,23 @@ A brief summary of major implementations of this draft is available
Implementations of the Opus codec need to take appropriate security considerations into account, as outlined in . This is just as much a problem for the container as it is for the codec itself. -Robustness against malicious payloads is extremely important. -Malicious payloads MUST NOT cause an implementation to overrun its allocated - memory or to take an excessive amount of resources to decode. -Although problems in encoding applications are typically rarer, the same - applies to the muxer. -Malicious audio input streams MUST NOT cause an implementation to overrun its - allocated memory or consume excessive resources because this would allow an - attacker to attack transcoding gateways. +Malicious payloads and/or input streams can be used to attack codec + implementations. +Implementations MUST NOT overrun their allocated memory nor consume excessive + resources when decoding payloads or processing input streams. +Although problems in encoding applications are typically rarer, this still + applies to a muxer, as vulnerabilities would allow an attacker to attack + transcoding gateways. Header parsing code contains the most likely area for potential overruns. It is important for implementations to ensure their buffers contain enough data for all of the required fields before attempting to read it (for example, for all of the channel map data in the ID header). Implementations would do well to validate the indices of the channel map, also, @@ -1663,18 +1671,18 @@ This document updates the IANA Media Types registry to add .opus This document defines a new registry "Opus Channel Mapping Families" to indicate how the semantic meanings of the channels in a multi-channel Opus stream are described. IANA is requested to create a new name space of "Opus Channel Mapping Families". This will be a new registry on the IANA Matrix, and not a subregistry of an existing registry. -Modifications to this registry follow the "Specification Required with Expert - Review" registration policy as defined in . +Modifications to this registry follow the "Specification Required" registration + policy as defined in . Each registry entry consists of a Channel Mapping Family Number, which is specified in decimal in the range 0 to 255, inclusive, and a Reference (or list of references) Each Reference must point to sufficient documentation to describe what information is coded in the Opus identification header for this channel mapping family, how a demuxer determines the Stream Count ('N') and Coupled Stream Count ('M') from this information, and how it determines the proper interpretation of each of the decoded channels. -- 1.8.3.2 --------------080606090204060306040500-- From nobody Mon Feb 22 17:57:42 2016 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA17E1A8F4A; Mon, 22 Feb 2016 17:57:38 -0800 (PST) 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.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160223015738.12187.11344.idtracker@ietfa.amsl.com> Date: Mon, 22 Feb 2016 17:57:38 -0800 Archived-At: Cc: codec@ietf.org Subject: [codec] I-D Action: draft-ietf-codec-oggopus-14.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 01:57:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Wideband Audio Codec of the IETF. Title : Ogg Encapsulation for the Opus Audio Codec Authors : Timothy B. Terriberry Ron Lee Ralph Giles Filename : draft-ietf-codec-oggopus-14.txt Pages : 34 Date : 2016-02-22 Abstract: This document defines the Ogg encapsulation for the Opus interactive speech and audio codec. This allows data encoded in the Opus format to be stored in an Ogg logical bitstream. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-codec-oggopus-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-codec-oggopus-14 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 Mon Feb 22 18:28:01 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9D11B3CBF for ; Mon, 22 Feb 2016 18:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 7Jrd2EbcbZhJ for ; Mon, 22 Feb 2016 18:27:58 -0800 (PST) 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 788A21B3CBC for ; Mon, 22 Feb 2016 18:27:58 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 00378C0E76 for ; Tue, 23 Feb 2016 02:27:58 +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 u5L2NUhWQrlr for ; Tue, 23 Feb 2016 02:27:57 +0000 (UTC) Received: from [10.252.25.218] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id E1E2BC0B4E for ; Tue, 23 Feb 2016 02:27:57 +0000 (UTC) Message-ID: <56CBC3AD.7030501@xiph.org> Date: Mon, 22 Feb 2016 18:27:57 -0800 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: codec@ietf.org References: <20160223015738.12187.11344.idtracker@ietfa.amsl.com> In-Reply-To: <20160223015738.12187.11344.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [codec] I-D Action: draft-ietf-codec-oggopus-14.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 02:27:59 -0000 internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Internet Wideband Audio Codec of the IETF. This version addresses all of the comments from IESG review. This includes a new example diagram and some new advice to implementors in the Security Considerations section, as well as some re-wording of a few points for clarity, and a few fixes to the informational references. Also, the requirements that a demuxer not attempt to decode partial packets unless it has some special knowledge that would allow it to interpret this data despite the missing pieces has been upgraded from a SHOULD to a MUST. From nobody Tue Feb 23 08:50:23 2016 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D01C51B3623; Tue, 23 Feb 2016 08:50:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160223165020.9067.46663.idtracker@ietfa.amsl.com> Date: Tue, 23 Feb 2016 08:50:20 -0800 Archived-At: Cc: codec@ietf.org, ipr-announce@ietf.org Subject: [codec] IPR Disclosure Xiph.Org Foundation and contributors' Statement about IPR related to draft-ietf-codec-oggopus X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 16:50:21 -0000 Dear Timothy Terriberry, Ron Lee, Ralph Giles: An IPR disclosure that pertains to your Internet-Draft entitled "Ogg Encapsulation for the Opus Audio Codec" (draft-ietf-codec-oggopus) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2762/). The title of the IPR disclosure is "Xiph.Org Foundation and contributors' Statement about IPR related to draft-ietf-codec-oggopus" Thank you IETF Secretariat From nobody Tue Feb 23 18:04:12 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD291B41F4; Tue, 23 Feb 2016 18:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 9PAfcq3yS4gr; Tue, 23 Feb 2016 18:04:08 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 CA5B21B41DC; Tue, 23 Feb 2016 18:04:08 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u1O247dL007487 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 23 Feb 2016 20:04:08 -0600 (CST) (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.10] From: "Ben Campbell" To: codec@ietf.org, codec-chairs@ietf.org Date: Tue, 23 Feb 2016 20:04:08 -0600 Message-ID: <9511C3DB-1F12-46CE-B4AB-A113FBFB9EC5@nostrum.com> In-Reply-To: <56CBC3AD.7030501@xiph.org> References: <20160223015738.12187.11344.idtracker@ietfa.amsl.com> <56CBC3AD.7030501@xiph.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5226) Archived-At: Subject: Re: [codec] I-D Action: draft-ietf-codec-oggopus-14.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 02:04:10 -0000 Hi Everyone, Please note that this version has an IPR disclosure[1] from the authors. In my strictly _individual_ opinion, this does not create a problem. My (again, _individual_) reading is that the disclosure has the same intent as copyright license language that was in the version of the draft that the working group approved, but was later removed due to IETF last call and IESG discussion. If anyone in the working group objects to publication with the disclosure, please say so as soon as possible. Otherwise, the draft is likely to be approved in the next few days. Thanks! Ben. [1] https://datatracker.ietf.org/ipr/2762/ On 22 Feb 2016, at 20:27, Timothy B. Terriberry wrote: > internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Internet Wideband Audio Codec of the >> IETF. > > This version addresses all of the comments from IESG review. This > includes a new example diagram and some new advice to implementors in > the Security Considerations section, as well as some re-wording of a > few points for clarity, and a few fixes to the informational > references. > > Also, the requirements that a demuxer not attempt to decode partial > packets unless it has some special knowledge that would allow it to > interpret this data despite the missing pieces has been upgraded from > a SHOULD to a MUST. > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From nobody Fri Feb 26 12:32:34 2016 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB1C1B2FE0; Fri, 26 Feb 2016 12:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 2fUsPrrCgPUB; Fri, 26 Feb 2016 12:32:33 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 EC3D21B2FE4; Fri, 26 Feb 2016 12:32:32 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u1QKWVEa049417 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 26 Feb 2016 14:32:32 -0600 (CST) (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.10] From: "Ben Campbell" To: IESG Date: Fri, 26 Feb 2016 14:32:30 -0600 Message-ID: <709407E2-3829-4CCA-8B18-05C58B7D0C21@nostrum.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.4r5226) Archived-At: Cc: codec@ietf.org, draft-ietf-codec-oggopus-14@ietf.org Subject: [codec] Approved: draft-ietf-codec-oggopus-14 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 20:32:34 -0000 Hello IESG Secretary (bcc'd) draft-ietf-codec-oggopus-14 is approved. There are no RFC editor notes. Thanks! Ben. From nobody Fri Feb 26 13:23:35 2016 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 843DD1B3095; Fri, 26 Feb 2016 13:23:31 -0800 (PST) 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.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160226212331.17188.60225.idtracker@ietfa.amsl.com> Date: Fri, 26 Feb 2016 13:23:31 -0800 Archived-At: Cc: draft-ietf-codec-oggopus@ietf.org, codec@ietf.org, The IESG , codec-chairs@ietf.org, rfc-editor@rfc-editor.org Subject: [codec] Protocol Action: 'Ogg Encapsulation for the Opus Audio Codec' to Proposed Standard (draft-ietf-codec-oggopus-14.txt) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:23:31 -0000 The IESG has approved the following document: - 'Ogg Encapsulation for the Opus Audio Codec' (draft-ietf-codec-oggopus-14.txt) as Proposed Standard This document is the product of the Internet Wideband Audio Codec Working Group. The IESG contact persons are Barry Leiba, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ Technical Summary This specification defines the encapsulation of the Opus [RFC6716] audio codec in the Ogg [RFC3533] container format. This allows Opus audio bitstreams to be stored in Ogg files or streamed over networks in a form that is identical to the file storage format. Working Group Summary Solid WG consensus on this spec throughout the process with no controversy or objections. Document Quality Multiple existing implementations of this specification are listed at: https://wiki.xiph.org/OggOpusImplementation Multiple reviews of this specification had no substantive issues, other than some discussion about reasonable guidelines for protecting implementations from malicious input streams.