From nobody Mon Jul 6 04:02:31 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40861A017D for ; Mon, 6 Jul 2015 04:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fIw4kuFEfZi for ; Mon, 6 Jul 2015 04:02:28 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF771A0194 for ; Mon, 6 Jul 2015 04:02:28 -0700 (PDT) Received: by lagx9 with SMTP id x9so149858508lag.1 for ; Mon, 06 Jul 2015 04:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=KeJPh8wnWk5P62CKKwfFlFKsAPslyeikCrKd8SFm7Uw=; b=pK4NvRm9oBxz/EjT8qX6PTlwVVnwf8VI89gSIF1u60hC0H8N0HuhlPLsxhveJLqSbf e5vCxR7C+HIgnglsgkqPgkMSgH1mb2LzTG86QstAmOui1aj6iPRdBukAftx7EEh2ic+R xigmw5cPWO079PM4xuTP5IpLVDl1XKyQq/E7GviiiDTONDtKOfJSbgB2JQUblB+NVp08 0Hm5ofY0mSMNL2fnP4Ah53IYPWj+sOJRPkf6yUDnHGPyfg0siOuf8neKq7K0VDa6qgGE a1j7fTharQJMOntDiuvNwqMIQvC31j4QGNk0QAIHL7S8nOpBMaXOCC6HFJtA6X976SbV B1cQ== MIME-Version: 1.0 X-Received: by 10.112.160.73 with SMTP id xi9mr47712710lbb.92.1436180546563; Mon, 06 Jul 2015 04:02:26 -0700 (PDT) Received: by 10.112.118.99 with HTTP; Mon, 6 Jul 2015 04:02:26 -0700 (PDT) Date: Mon, 6 Jul 2015 14:02:26 +0300 Message-ID: From: Ron Even To: payload Content-Type: multipart/mixed; boundary=001a11c235f64fb554051a32d7ff Archived-At: Subject: [payload] Payload agenda for Prague X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 11:02:29 -0000 --001a11c235f64fb554051a32d7ff Content-Type: text/plain; charset=UTF-8 Hi, Here is the proposed agenda, any comments? If we will not have more presentations we may have the payload session joined with another of the AVT WGs See you in Prague Roni Even --001a11c235f64fb554051a32d7ff Content-Type: text/plain; charset=US-ASCII; name="p1507.txt" Content-Disposition: attachment; filename="p1507.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: file0 QXVkaW8vVmlkZW8gVHJhbnNwb3J0IFBheW9hZHMgIChQYXlsb2FkKSBXb3JraW5nIEdyb3VwDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0K Q0hBSVJTOiAgQWxpIEJlZ2VuICAgICAgIDxhYmVnZW5AY2lzY28uY29tPg0KICAgICAgICAgUm9u aSBFdmVuICAgICAgICAgPHJvbmkuZXZlbkBtYWlsMDEuaHVhd2VpLmNvbT4NCg0KQUdFTkRBDQoN Ck1vbmRheSwgMjAgSnVseSAyMDE1IGF0IDE3OjQwLTE4OjQwIChDb250aW5lbnRhbCkNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCjE3OjQwICAgUGF5 bG9hZCBTdGF0dXMgVXBkYXRlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChDaGFpcnMs IDEwKQ0KDQoxNzo1MCAgIFJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgTUVMUGUgQ29kZWMgICAgICAg KFZpY3RvciBEZW1qYW5lbmtvLCAxMCkNCiAgICAgICAgZHJhZnQtZGVtamFuZW5rby1wYXlsb2Fk LW1lbHBlLTAzDQoNCjE4OjAwICAgRW5kDQo= --001a11c235f64fb554051a32d7ff-- From nobody Mon Jul 6 06:09:58 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6CB1A1A70 for ; Mon, 6 Jul 2015 06:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.232 X-Spam-Level: X-Spam-Status: No, score=-0.232 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHqpyziigfhI for ; Mon, 6 Jul 2015 06:09:56 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (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 C9B9A1A1B1E for ; Mon, 6 Jul 2015 06:08:29 -0700 (PDT) Received: by labgy5 with SMTP id gy5so1547916lab.2 for ; Mon, 06 Jul 2015 06:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=d5U70FfCCTe9ZIlaYhl6+ykr+EvpIybVp6nirjC9vAU=; b=XTe+1pW5kgRlAFdOFwNjzyz6exZYm/SaE938aWOJBflTkjTZXEJfOkq6SmwQdDJd3Y oxXDPYy2Hp8LTbR0OUWpWktrnP5w0dpxaO+u0vj1TFLMkH4sYTBrqPoBdAGFFe4lAXZ/ wN5WsQ//td6T0z4l9a1CwTafDh18e09tJJ77y2XYo3tDlxRqvy/EriKRVhE+4015s2Tv SmTyIc6/LrmU430SIyPFSdaUHFq7xedQeHpwDIo8sqf29DEA5/8nFWcSxD39h+lxPknF t6LzW3Jyrh2ov+1SUDnFWLD8MxYuS0d6bEqz74Y5M8qwTZIfNJbOUHRdbRzp13CKLa3Z LnGA== MIME-Version: 1.0 X-Received: by 10.152.28.73 with SMTP id z9mr48725169lag.93.1436188108330; Mon, 06 Jul 2015 06:08:28 -0700 (PDT) Received: by 10.112.118.99 with HTTP; Mon, 6 Jul 2015 06:08:27 -0700 (PDT) Date: Mon, 6 Jul 2015 16:08:27 +0300 Message-ID: From: Ron Even To: payload Content-Type: multipart/mixed; boundary=089e0158c026075597051a349ad8 Archived-At: Subject: [payload] updated agenda X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 13:09:57 -0000 --089e0158c026075597051a349ad8 Content-Type: text/plain; charset=UTF-8 Hi, Here is the updated agenda, any comments? See you in Prague Roni Even --089e0158c026075597051a349ad8 Content-Type: text/plain; charset=US-ASCII; name="p1507.txt" Content-Disposition: attachment; filename="p1507.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: file2 QXVkaW8vVmlkZW8gVHJhbnNwb3J0IFBheW9hZHMgIChQYXlsb2FkKSBXb3JraW5nIEdyb3VwDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0K Q0hBSVJTOiAgQWxpIEJlZ2VuICAgICAgIDxhYmVnZW5AY2lzY28uY29tPg0KICAgICAgICAgUm9u aSBFdmVuICAgICAgICAgPHJvbmkuZXZlbkBtYWlsMDEuaHVhd2VpLmNvbT4NCg0KQUdFTkRBDQoN Ck1vbmRheSwgMjAgSnVseSAyMDE1IGF0IDE3OjQwLTE4OjQwIChDb250aW5lbnRhbCkNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCjE3OjQwICAgUGF5 bG9hZCBTdGF0dXMgVXBkYXRlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChDaGFpcnMs IDEwKQ0KDQoxNzo1MCAgIFJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgTUVMUGUgQ29kZWMgICAgICAg KFZpY3RvciBEZW1qYW5lbmtvLCAxMCkNCiAgICAgICAgZHJhZnQtZGVtamFuZW5rby1wYXlsb2Fk LW1lbHBlLTAzDQoNCjE4OjAwICAgUlRQIFBheWxvYWQgRm9ybWF0IGZvciBOb24tSW50ZXJsZWF2 ZWQgYW5kIEludGVybGVhdmVkIFBhcml0eSBGRUMoVmFydW4gU2luZ2ggLCAyMCkNCiAgICAgICAg ZHJhZnQtaWV0Zi1wYXlsb2FkLWZsZXhpYmxlLWZlYy1zY2hlbWUtMDANCg0KMTg6MjAgICBFbmQN Cg== --089e0158c026075597051a349ad8 Content-Type: text/html; charset=US-ASCII; name="p1507.html" Content-Disposition: attachment; filename="p1507.html" Content-Transfer-Encoding: base64 X-Attachment-Id: file0 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5BdWRpby9WaWRlbyBUcmFuc3BvcnQgUGF5b2FkcyAgKFBh eWxvYWQpIFdvcmtpbmcgR3JvdXAgQWdlbmRhPC90aXRsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29s b3I9IiNmZmZmZmYiPjxoMT5BdWRpby9WaWRlbyBUcmFuc3BvcnQgUGF5b2FkcyAgKFBheWxvYWQp IFdvcmtpbmcgR3JvdXAgQWdlbmRhPC9oMT4NCjxocj4NCjxwPg0KPGgzPg0KQ2hhaXJzOiBBbGkg QmVnZW4gICAgICAgPGFiZWdlbkBjaXNjby5jb20+LCBSb25pIEV2ZW4gICAgICAgICA8cm9uaS5l dmVuQG1haWwwMS5odWF3ZWkuY29tPg0KPC9oMz4NCjxwPg0KPGgyPk1vbmRheSwgMjAgSnVseSAy MDE1IGF0IDE3OjQwLTE4OjQwIChDb250aW5lbnRhbCk8L2gyPg0KPHA+DQo8dGFibGUgYm9yZGVy PSIwIiBjZWxscGFkZGluZz0iNSI+DQo8dHI+DQo8dGggYWxpZ249ImxlZnQiPjE3OjQwDQo8dGgg YWxpZ249ImxlZnQiPlBheWxvYWQgU3RhdHVzIFVwZGF0ZTx0aCBhbGlnbj0ibGVmdCI+Q2hhaXJz DQo8dHI+DQo8dGggYWxpZ249ImxlZnQiPjE3OjUwDQo8dGggYWxpZ249ImxlZnQiPlJUUCBQYXls b2FkIEZvcm1hdCBmb3IgTUVMUGUgQ29kZWM8dGggYWxpZ249ImxlZnQiPlZpY3RvciBEZW1qYW5l bmtvDQo8dHI+DQo8dGQgYWxpZ249ImxlZnQiPg0KPHRkIGFsaWduPSJsZWZ0Ij48YSBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtZGVtamFuZW5rby1wYXlsb2FkLW1lbHBlLTAz Ij5kcmFmdC1kZW1qYW5lbmtvLXBheWxvYWQtbWVscGUtMDM8L2E+DQo8dHI+DQo8dGggYWxpZ249 ImxlZnQiPjE4OjAwDQo8dGggYWxpZ249ImxlZnQiPlJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgTm9u LUludGVybGVhdmVkIGFuZCBJbnRlcmxlYXZlZCBQYXJpdHkgRkVDPHRoIGFsaWduPSJsZWZ0Ij5W YXJ1biBTaW5naCANCjx0cj4NCjx0ZCBhbGlnbj0ibGVmdCI+DQo8dGQgYWxpZ249ImxlZnQiPjxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXBheWxvYWQtZmxleGli bGUtZmVjLXNjaGVtZS0wMCI+ZHJhZnQtaWV0Zi1wYXlsb2FkLWZsZXhpYmxlLWZlYy1zY2hlbWUt MDA8L2E+DQo8dHI+DQo8dGggYWxpZ249ImxlZnQiPjE4OjIwDQo8dGggYWxpZ249ImxlZnQiPkVu ZDwvdGFibGU+DQo= --089e0158c026075597051a349ad8-- From nobody Mon Jul 6 14:43:15 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661811A1B4C; Mon, 6 Jul 2015 14:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ev9QyHoeHkBM; Mon, 6 Jul 2015 14:43:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7121A1A56; Mon, 6 Jul 2015 14:43:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706214312.30969.51474.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 14:43:12 -0700 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-vp9-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 21:43:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for VP9 Video Authors : Justin Uberti Stefan Holmer Magnus Flodman Jonathan Lennox Danny Hong Filename : draft-ietf-payload-vp9-00.txt Pages : 20 Date : 2015-07-06 Abstract: This memo describes an RTP payload format for the VP9 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. It includes provisions for temporal and spatial scalability. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-vp9/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-payload-vp9-00 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 Jul 6 15:03:04 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A9B1A1AB6 for ; Mon, 6 Jul 2015 15:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, 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 bZBYdYlm1Vyq for ; Mon, 6 Jul 2015 15:03:01 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (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 BD8BA1A1A9E for ; Mon, 6 Jul 2015 15:03:01 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t66M31CP004926 for ; Mon, 6 Jul 2015 18:03:01 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1vbhntbeua-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 06 Jul 2015 18:03:01 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 6 Jul 2015 17:02:59 -0500 From: Jonathan Lennox To: "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-vp9-00.txt Thread-Index: AQHQuDTxZ/M3InmUCkGf2o6eHecIAJ3PUnAA Date: Mon, 6 Jul 2015 22:02:58 +0000 Message-ID: <781CB6F3-B016-42BC-8D87-EF8340C93770@vidyo.com> References: <20150706214312.30969.51474.idtracker@ietfa.amsl.com> In-Reply-To: <20150706214312.30969.51474.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="us-ascii" Content-ID: <9300439E10E419479E0FEE085C0D2913@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-06_09:2015-07-06,2015-07-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507060324 Archived-At: Subject: Re: [payload] I-D Action: draft-ietf-payload-vp9-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 22:03:02 -0000 This version is largely unchanged from the individual submission, other tha= n chasing some corresponding changes in the VP8 payload. The RTP payload formats are probably stable at this point. SDP negotiation= still needs to be worked out. Please read and comment. > On Jul 6, 2015, at 5:43 PM, Internet-Drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Audio/Video Transport Payloads Working G= roup of the IETF. >=20 > Title : RTP Payload Format for VP9 Video > Authors : Justin Uberti > Stefan Holmer > Magnus Flodman > Jonathan Lennox > Danny Hong > Filename : draft-ietf-payload-vp9-00.txt > Pages : 20 > Date : 2015-07-06 >=20 > Abstract: > This memo describes an RTP payload format for the VP9 video codec. > The payload format has wide applicability, as it supports > applications from low bit-rate peer-to-peer usage, to high bit-rate > video conferences. It includes provisions for temporal and spatial > scalability. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-payload-vp9/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-payload-vp9-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 From nobody Mon Jul 6 17:47:20 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902BB1A87A0 for ; Mon, 6 Jul 2015 17:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1xJlb8VPye4 for ; Mon, 6 Jul 2015 17:47:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63AE1A8770 for ; Mon, 6 Jul 2015 17:47:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUT98981; Tue, 07 Jul 2015 00:47:16 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 7 Jul 2015 01:47:16 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.233]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Tue, 7 Jul 2015 08:47:08 +0800 From: "Huangyihong (Rachel)" To: "payload@ietf.org" Thread-Topic: [payload]FW: New Version Notification for draft-huang-payload-rtp-interleave-00.txt Thread-Index: AQHQuE5zcXb9zWduEE2C1I7caBZ/Kg== Date: Tue, 7 Jul 2015 00:47:08 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB8636F813@nkgeml501-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.144] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [payload] FW: New Version Notification for draft-huang-payload-rtp-interleave-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 00:47:19 -0000 RGVhciBhbGwsDQoNCkkgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgdG8gZGlzY3VzcyBhIGNv bW1vbiBSVFAgZW5jYXBzdWxhdGlvbiBmb3IgaW50ZXJsZWF2ZWQgbWVkaWEuIEl0IGNhbiBiZSB1 c2VkIHRvIGFueSBSVFAgcGF5bG9hZCBmb3JtYXRzIGZvciBhbnkgYXBwbGljYXRpb25zIHdoZW4g bGF0ZW5jeSBpcyBub3QgYW4gaXNzdWUuIFlvdXIgY29tbWVudHMgYW5kIHJldmlld3MgYXJlIGhp Z2hseSBhcHByZWNpYXRlZC4NCg0KQlIsDQpSYWNoZWwNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgSnVseSAwNiwgMjAxNSAxMTozOSBBTQ0K VG86IEh1YW5neWlob25nIChSYWNoZWwpOyBIdWFuZ3lpaG9uZyAoUmFjaGVsKQ0KU3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odWFuZy1wYXlsb2FkLXJ0cC1pbnRl cmxlYXZlLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1odWFuZy1wYXls b2FkLXJ0cC1pbnRlcmxlYXZlLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBSYWNoZWwgSHVhbmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpO YW1lOgkJZHJhZnQtaHVhbmctcGF5bG9hZC1ydHAtaW50ZXJsZWF2ZQ0KUmV2aXNpb246CTAwDQpU aXRsZToJCVJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgSW50ZXJsZWF2ZWQgUGFja2V0cw0KRG9jdW1l bnQgZGF0ZToJMjAxNS0wNy0wNg0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2Vz OgkJMTANClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtaHVhbmctcGF5bG9hZC1ydHAtaW50ZXJsZWF2ZS0wMC50eHQNClN0YXR1czogICAg ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1odWFuZy1wYXlsb2Fk LXJ0cC1pbnRlcmxlYXZlLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1odWFuZy1wYXlsb2FkLXJ0cC1pbnRlcmxlYXZlLTAwDQoNCg0KQWJzdHJhY3Q6 DQogICBUaGlzIG1lbW8gaW50cm9kdWNlcyBhIGNvbW1vbiBSVFAgZW5jYXBzdWxhdGlvbiBmb3Ig aW50ZXJsZWF2ZWQNCiAgIG1lZGlhLiBUaGlzIG1ldGhvZCBjYW4gYmUgYXBwbGllZCB0byBhbnkg UlRQIHBheWxvYWQgZm9ybWF0cyBmb3IgYW55DQogICBhcHBsaWNhdGlvbnMgd2hlbiBsYXRlbmN5 IGlzIG5vdCBhbiBpc3N1ZS4NCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Mon Jul 6 17:48:54 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BBC1A87B0 for ; Mon, 6 Jul 2015 17:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYIAPMdSp1u3 for ; Mon, 6 Jul 2015 17:48:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86C971A87A1 for ; Mon, 6 Jul 2015 17:48:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUT99054; Tue, 07 Jul 2015 00:48:50 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 7 Jul 2015 01:48:49 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.233]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 7 Jul 2015 08:48:46 +0800 From: "Huangyihong (Rachel)" To: Ron Even , payload Thread-Topic: [payload] updated agenda Thread-Index: AQHQt+0TucPl28P7W0eBTyAaDXaFlZ3PLRZA Date: Tue, 7 Jul 2015 00:48:45 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB8636F828@nkgeml501-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.144] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [payload] updated agenda X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 00:48:52 -0000 SGkgUm9uaSwNCg0KSWYgdGltZSBpcyBhbGxvd2VkLCBJJ2QgbGlrZSB0byByZXF1ZXN0IGEgdGlt ZSBzbG90IHRvIGludHJvZHVjZSBkcmFmdC1odWFuZy1wYXlsb2FkLXJ0cC1pbnRlcmxlYXZlLiAx MCBtaW51dGVzIHdpbGwgYmUgZmluZS4gVGhhbmtzLg0KDQpCUiwNClJhY2hlbA0KDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogcGF5bG9hZCBbbWFpbHRvOnBheWxvYWQt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbiBFdmVuDQo+IFNlbnQ6IE1vbmRheSwg SnVseSAwNiwgMjAxNSA5OjA4IFBNDQo+IFRvOiBwYXlsb2FkDQo+IFN1YmplY3Q6IFtwYXlsb2Fk XSB1cGRhdGVkIGFnZW5kYQ0KPiANCj4gSGksDQo+IEhlcmUgaXMgdGhlIHVwZGF0ZWQgYWdlbmRh LCBhbnkgY29tbWVudHM/DQo+IFNlZSB5b3UgaW4gUHJhZ3VlDQo+IFJvbmkgRXZlbg0K From nobody Mon Jul 13 13:57:29 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8151A8977; Mon, 13 Jul 2015 13:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhyJhvlUY_9h; Mon, 13 Jul 2015 13:57:24 -0700 (PDT) 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 78C621A8937; Mon, 13 Jul 2015 13:57:23 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6DKv1VA061151 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 13 Jul 2015 15:57:12 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Elwyn Davies" Date: Mon, 13 Jul 2015 15:57:01 -0500 Message-ID: In-Reply-To: <55A3A7F1.8010109@dial.pipex.com> References: <55A3A7F1.8010109@dial.pipex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: draft-ietf-payload-vp8.all@ietf.org, IETF Discussion List , General area reviewing team , payload-chairs@ietf.org, payload@ietf.org Subject: Re: [payload] Gen-art 2nd LC review of draft-ietf-payload-vp8-16 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 20:57:26 -0000 (+payload and Harald) Elwyn: Thanks for the detailed review! Authors: Please address Elwyn's comments at your earliest convenience. There's quite a bit here, and I assume we will need a new revision before taking this to the IESG telechat, but it would be helpful to discuss any proposed changes via email before submitting. Thanks! Ben. On 13 Jul 2015, at 6:58, Elwyn Davies wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-payload-vp8-16.txt > Reviewer: Elwyn Davies > Review Date: 2015/07/10 > IETF LC End Date: 2015/07/13 > IESG Telechat date: (if known) - > > Summary: Gosh, it has been a long time since the last review! > > Major issues: > > Minor issues: > s4.2: Various of the frame indices either SHOULD or, in the case of > KEYIDX, MAY start at random values. The rationale(s) for these > requirements are not explained - nor is the reason why it it is only a > MAY for KEYIDX whereas it is SHOULD for PictureID and what might > happen > were the MAY/SHOULD to be ignored. > > Is the rationale something that should be mentioned in the security > considerations? > > s10.1: The downref to RFC 6386 identified by idnits was duly noted in > the last call > announcement. I don't have a problem with the downref. > > Nits/editorial comments: > > General: Consistent usage of "prediction and mode" vs > "prediction/mode" would be desirable. > > s1, para 2: Needs to introduce the 'macroblock' jargon defined in RFC > 6386. Suggest: > OLD: > VP8 is based on decomposition of frames into square sub-blocks of > pixels, prediction of such sub-blocks using previously constructed > blocks, and... > NEW: > VP8 is based on decomposition of frames into square sub-blocks of > pixels known as "macroblocks" (see Section 2 of [RFC6386]). > Prediction > of such sub-blocks using previously constructed blocks, and... > END > > s2: There are a number of technical terms brought over from RFC 6386. > These should be listed in s2. At least the following would be in the > list: > key frame, interframe, golden frame, altref frame, macroblock. > Also the terms picture selection index (RPSI) and slice loss > indication (SLI) from RFC 4585. > > s3, para 2: Providing a reference to explain what temporal scalability > and the hierarchy selection is all about would be useful. One > possibility > would be: > > Lim, J. Yang, and B. Jeon,”Fast Coding Mode Decision for Scalable > Video Coding”, > 10th Int’l Conf. on Advanced Communication Technology, vol. 3, pp. > 1897-1900, 2008. > > It would also help to add a pointer to the TL0PICIDX description in > s4.2, thus: > ADD: > Support for temporal scalability is provided by the optional TL0PICIDX > and TID/Y/KEYIDX > fields described in Section 4.2. > END > > ss3 and 4: The discussion of how the frame payload might or might not > be distributed across > multiple packets is not very clear. The draft has in mind a > 'preferred use case' (para 1 > of s4.4 says: > >> In the preferred use case, the S bit and PID fields >> described in Section 4.2 should be used to indicate what the packet >> contains. > > I think it would be helpful to be a bit more positive about this in > s3, para 3: > OLD: > This memo > allows the partitions to be sent separately or in the same RTP > packet. It may be beneficial for decoder error-concealment to send > the partitions in different packets, even though it is not mandatory > according to this specification. > NEW: > Accordingly, this document RECOMMENDS that the frame is packetized by > the sender > with each data partition in a separate packet or packets. This may be > beneficial > for decoder error concealment and the payload format described in > Section 4 provides > fields that allow the partitions to be identified even if the first > partition is > not available. The sender can, alternatively, aggregate the data > partitions into > a single data stream and, optionally, split it into several packets > without > consideration of the partition boundaries. The receiver can use the > length > information in the first partition to identify the partitions during > decoding. > END > > s4/Figure 1: s/bytes/octets/ (2 places) > > Figure 1, caption: s/sequel/Sections 4.2 and 4.3/ > > Figure 1: The format shown is correct only for the first packet in a > frame. Subsequent > packets will not contain the payload header and will have later octets > of the frame payload. > This should be mentioned in drawing and/or in the caption. > > s4.1, last two paras: >> Sequence number: The sequence numbers are monotonically increasing >> and set as packets are sent. >> >> The remaining RTP header fields are used as specified in >> [RFC3550]. > Redefining the Sequence Number field seems gratuitous and potentially > dangerous, > given that it is *very carefully* defined in RFC 3550 and the overall > intent does > not seem any different from that in RFC 3550. OTOH a note about the > (non?-)use of the X bit > and the Payload Type field (PT) would be useful. I suggest replacing > the paras above with: > NEW: > X bit: MUST be 0. The VP8 RTP profile does not use the RTP Header > Extension capability. > > PT (Payload Type): In line with the policy in Section 3 of [RFC3551], > applications > using the VP8 RTP payload profile MUST assign a dynamic payload > type number to > be used in each RTP session and provide a mechanism to indicate the > mapping. > See Section 6.2 for the mechanism to be used with the Session > Description Protocol (SDP) > [RFC4566]. > > The remaining RTP Fixed Header Fields (V, P, CC, sequence number, > SSRC and CSRC > identfiers) are used as specified in Section 5.1 of [RFC5330]. > END > Note that this may be considered to make the reference to RFC 3551 > normative. > > s4.2, X bit: There is potential for confusion between the X bit in > the fixed header > and the X bit in the VP8 Payload Descriptor. Perhaps changing this to > C for control bits > would avoid the problem. > > s4.2, M bit: Similarly, it might be better to use B (for BIG) in place > of M to avoid confusion. > > s4.2, para 7 after Fig 2: For consistency: > OLD: > When the X bit is set to 1 in the first octet, the extension bit > field octet MUST be provided as the second octet. If the X bit is 0, > the extension bit field octet MUST NOT be present, and no extensions > (I, L, T, or K) are permitted. > NEW: > When the X [or C] bit is set to 1 in the first octet, the Extended > Control Bits > field octet MUST be provided as the second octet. If the X [or C] bit > is 0, > the extension bit field octet MUST NOT be present, and no extensions > (I, L, T, or K) are permitted. > END > > s4.2: The issue of using either 'wrap' or 'restart' but not both for > restarting number sequences has been raised in various comments by > IESG members. > > s4.2, TL0PICIDX: I think, given the statements in s3 about not > defining the hierarchy, that more explanation is needed of what the > 'lowest or base layer' actually means. > > s4.2, TL0PICIDX: >> If TID is larger than 0, TL0PICIDX >> indicates which base layer frame the current image depends on. >> TL0PICIDX MUST be incremented when TID is 0. > What happens if L=1 but both T=0 and K=0 so that there is no TID value > present? Or indeed if T=0 but K=1 so that the TID field is there but > 'MUST be ignored by the receiver' (definition of TID field)? > > s4.3: It would be useful to include the section number (9.1) where the > uncompressed data chunk specification is found. I was somewhat > surprised that the ordering is reversed in the protocol spec. > > s4.3, VER: The receiver should validate this field - currently only > values 0-3 are valid. > > s4.3, SizeN: Make it clear these are integer fields: s/in Size0,/in > integer fields Size0,/ > > s4.3 and s4.4: It would be helpful to implementers to explain what > the offsets in the first partition payload are for the additional > partition count and additional partition sizes. Having rummaged > around in RFC 6386, I have to say that I am unclear whether the > values are placed after the full chunk of data indicated by > 1stPartitionSize or are part of this data. And if the latter is the > case, how to work out where the partition sizes are. I guess that > they ought to be at offset (1stPartitionSize+10 - key frame - or > 1stPartitionSize+3 - interframe) in the VP8 Payload field as it is > difficult to work out where they are without decoding the partition > otherwise. Also exactly how many partition sizes to expect - I think > I read in RFC 6386 that the last partition size is implicit. Help! > > In the course of clearing this up, it might be appropriate to move the > last sentence of the first para of s4.4 and the second para of s4.4 > into s4.3 as part of the explanation. This is the relevant text: >> Note that the length of the first partition can >> always be obtained from the first partition size parameter in the VP8 >> payload header. >> >> The VP8 bitstream format [RFC6386] specifies that if multiple DCT/WHT >> partitions are produced, the location of each partition start is >> found at the end of the first (prediction/mode) partition. In this >> RTP payload specification, the location offsets are considered to be >> part of the first partition. > > > s4.4: I found this section very difficult to parse. It is a bit > 'stream of consciousness' and would benefit from a reordering and > rewrite. Suggestion (assuming the second para gets moved to s4.3): > NEW SECTION 4.4: > An encoded VP8 frame can be divided into two or more partitions, as > described in Section 1. It is OPTIONAL for a packetizer implementing > this RTP specification > to pay attention to the partition boundaries within an encoded frame. > If packetization of a frame is done without considering the partition > boundaries, the PID field MAY be set to zero for all packets, and the > S bit MUST NOT be set to one for any other packet than the first. > > If the preferred usage suggested in Section 3 is followed, with each > packet > carrying data from exactly one partition, the S bit and PID fields > described in Section 4.2 SHOULD be used to indicate what the packet > contains. The PID field should indicate which partition the first > octet of the payload belongs to, and the S bit indicates that the > packet starts on a new partition. > > If the packetizer does not pay attention to the partition boundaries, > one > packet can contain a fragment of a partition, a complete partition, > or an > aggregate of fragments and partitions. There is no explicit signaling > of > partition boundaries in the payload and the partition lengths at the > end of > the first partition have to be used to identify the boundaries. > Partitions > MUST be aggregated in decoding order. Two fragments from different > partitions MAY be aggregated into the same packet along with one or > more > complete partitions. > > In all cases, the payload of a packet MUST contain data from only one > video > frame. Consequently the set of packets carrying the data from a > particular > frame will contain exactly one VP8 Payload Header (see Section 4.3) > carried > in the first packet of the frame. The last, or only, packet carrying > data for the > frame MUST have the M bit set in the RTP header. > > s4.5.1: Th algorithm only applies for the RECOMMENDED use case with > partitions in separate packets. > This should be noted. > > s5.2, last para: s/only parts of the frame is corrupted./only part of > the frame is corrupted./ > > s6: s/This payload format has two required parameters./This payload > format has two optional parameters./ > [I think this is probably a hangover from the previous version.] > > s7: s/Cryptographic system may also allow/The cryptographic system may > also allow/ > > s7: >> the usage of SRTP [RFC3711] is recommended. > RECOMMENDED? > > s10.2: I suspect that RFC 3551 is normative. From nobody Tue Jul 14 02:48:04 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C811A9149; Tue, 14 Jul 2015 02:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=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 IcG7pouqNUgH; Tue, 14 Jul 2015 02:47:55 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58B8F1A9056; Tue, 14 Jul 2015 02:47:55 -0700 (PDT) Received: from [130.209.247.112] (port=61927 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZEwoY-0001Yk-9I; Tue, 14 Jul 2015 10:47:51 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <55A3A8B2.1030302@dial.pipex.com> Date: Tue, 14 Jul 2015 10:47:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9369ADFB-9B30-4D2A-BA9B-325B27879B6D@csperkins.org> References: <55A3A8B2.1030302@dial.pipex.com> To: Elwyn Davies X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: General area reviewing team , draft-ietf-payload-vp8.all@tools.ietf.org, payload@ietf.org Subject: Re: [payload] Gen-art 2nd LC review of draft-ietf-payload-vp8-16 (with summary) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 09:48:01 -0000 [cc to payload wg, rather than ietf-discuss] Some comments inline.=20 Colin On 13 Jul 2015, at 13:01, Elwyn Davies wrote: > I am the assigned Gen-ART reviewer for this draft. For background on = Gen-ART, please see the FAQ at >=20 > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-payload-vp8-16.txt > Reviewer: Elwyn Davies > Review Date: 2015/07/10 > IETF LC End Date: 2015/07/13 > IESG Telechat date: (if known) - >=20 > Summary: Gosh, it has been a long time since the last review! Almost = ready. Still needs various minor nits fixed and some clarifications. ... > Nits/editorial comments: ... > s4.1, last two paras: >> Sequence number: The sequence numbers are monotonically = increasing >> and set as packets are sent. >>=20 >> The remaining RTP header fields are used as specified in >> [RFC3550]. > Redefining the Sequence Number field seems gratuitous and potentially = dangerous, > given that it is *very carefully* defined in RFC 3550 and the overall = intent does > not seem any different from that in RFC 3550. OTOH a note about the = (non?-)use of the X bit > and the Payload Type field (PT) would be useful. I suggest replacing = the paras above with: > NEW: > X bit: MUST be 0. The VP8 RTP profile does not use the RTP Header = Extension capability. This is not correct. The draft is an RTP Payload Format, not an RTP = Profile. RTP Payload Formats cannot prohibit the use of RTP header = extensions.=20 > PT (Payload Type): In line with the policy in Section 3 of = [RFC3551], applications > using the VP8 RTP payload profile MUST assign a dynamic payload = type number to This cannot be a MUST strength requirement, since the RTP/AVP profile = [RFC3551] cannot be mandated (other, incompatible, RTP Profile could = exist). > be used in each RTP session and provide a mechanism to indicate = the mapping. > See Section 6.2 for the mechanism to be used with the Session = Description Protocol (SDP) > [RFC4566]. >=20 > The remaining RTP Fixed Header Fields (V, P, CC, sequence number, = SSRC and CSRC > identfiers) are used as specified in Section 5.1 of [RFC5330]. > END > Note that this may be considered to make the reference to RFC 3551 = normative. >=20 > s4.2, X bit: There is potential for confusion between the X bit in = the fixed header > and the X bit in the VP8 Payload Descriptor. Perhaps changing this to = C for control bits > would avoid the problem. >=20 > s4.2, M bit: Similarly, it might be better to use B (for BIG) in place = of M to avoid confusion. Agree with these two. ... > s7: s/Cryptographic system may also allow/The cryptographic system may = also allow/ >=20 > s7: >> the usage of SRTP [RFC3711] is recommended. > RECOMMENDED? No - see RFC 7202. Section A.13 of draft-ietf-payload-rtp-howto-14 has = suggested text for this. > s10.2: I suspect that RFC 3551 is normative. It shouldn't need to be. --=20 Colin Perkins https://csperkins.org/ From nobody Tue Jul 14 08:08:29 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDFE1ACE9F for ; Tue, 14 Jul 2015 08:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, 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 Kv4KFU3yUt0g for ; Tue, 14 Jul 2015 08:08:23 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (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 5FB0C1ACEA2 for ; Tue, 14 Jul 2015 08:08:23 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6EF040S002727 for ; Tue, 14 Jul 2015 11:08:22 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1vg8weudd4-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 14 Jul 2015 11:08:22 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 14 Jul 2015 10:08:21 -0500 From: Jonathan Lennox To: "payload@ietf.org" Thread-Topic: VP8 payload's definition of temporal layers Thread-Index: AQHQvkbro5AGJFpedkGYU9gW8AaCaA== Date: Tue, 14 Jul 2015 15:08:20 +0000 Message-ID: <57711C65-E3E6-4169-8F70-4883B0B61DEE@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <51D58595FF53FB43B89709E218C961E1@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-14_07:2015-07-14,2015-07-14,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507140204 Archived-At: Subject: [payload] VP8 payload's definition of temporal layers X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 15:08:29 -0000 SW4gdGhlIGNvdXJzZSBvZiB3b3JraW5nIG9uIGRyYWZ0LWlldGYtYXZ0ZXh0LWxyciwgYW5kIGFs c28gZm9sbG93aW5nIHVwIG9uIHRoZSBWUDggcGF5bG9hZCBzcGVj4oCZcyBHZW5BcnQgcmV2aWV3 LCBJ4oCZdmUgY29tZSB0byByZWFsaXplIHRoYXQgdGhlIFZQOCBwYXlsb2FkIHNwZWMgaXMgYWN0 dWFsbHkgcHJldHR5IHZhZ3VlIGFib3V0IHdoYXQgYSDigJx0ZW1wb3JhbCBsYXllcuKAnSBpcy4N Cg0KSSB1bmRlcnN0YW5kIHRoYXQgdGhlcmXigJlzIGFuIGludGVyZXN0IGluIG5vdCBkZWZpbmlu ZyBob3cgdG8gc2V0IHVwIHRoZSByZWZlcmVuY2UgZnJhbWVzIHRvIGFjaGlldmUgdGVtcG9yYWwg c2NhbGFiaWxpdHksIGJ1dCBJIHRoaW5rIHRoZXJlIG5lZWQgdG8gYmUgbm9ybWF0aXZlIHByb21p c2VzIGFib3V0IHdoYXQgc2VtYW50aWNzIGEgdGVtcG9yYWwgbGF5ZXIgYWNoaWV2ZXMuDQoNCklu IHBhcnRpY3VsYXIsIEkgdGhpbmsgaXQgd291bGQgYmUgdmVyeSBoZWxwZnVsIGlmIHRoZSBzcGVj IGRlZmluZWQgd2hldGhlciBWUDggdGVtcG9yYWwgbGF5ZXJzIHdlcmUgYWx3YXlzIHRlbXBvcmFs bHkgbmVzdGVkIG9yIG5vdC4gIChTZWUgZHJhZnQtaWV0Zi1hdnRleHQtbHJyIGZvciB0aGUgZGVm aW5pdGlvbiBvZiB0ZW1wb3JhbCBuZXN0aW5nLCBpZiB5b3UgaGF2ZW7igJl0IGZvbGxvd2VkIHRo YXQgd29yay4pICBJIHdvdWxkIGJlIGluY2xpbmVkIHRvIHNheSB0aGV5IHNob3VsZCBiZSwgaW4g dGhlIGludGVyZXN0IG9mIG1ha2luZyBpbXBsZW1lbnRhdGlvbnMgc2ltcGxlciwgYW5kIHRoaXMg c2hvdWxkIGJlIHBhcnQgb2YgdGhlIFZQOCBzcGVj4oCZcyBkZWZpbml0aW9uIG9mIHRlbXBvcmFs IGxheWVycy4NCg0KDQo= From nobody Wed Jul 15 07:20:58 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E881A914F; Wed, 15 Jul 2015 07:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBgOCPe1A8XE; Wed, 15 Jul 2015 07:20:53 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0231A914E; Wed, 15 Jul 2015 07:20:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 42CE37C3AAA; Wed, 15 Jul 2015 16:20:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcHK7CBRRQ_i; Wed, 15 Jul 2015 16:20:50 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:3da7:4293:4c8b:1565] (unknown [IPv6:2001:470:de0a:27:3da7:4293:4c8b:1565]) by mork.alvestrand.no (Postfix) with ESMTPSA id 840A17C3A97; Wed, 15 Jul 2015 16:20:50 +0200 (CEST) Message-ID: <55A66C41.1030902@alvestrand.no> Date: Wed, 15 Jul 2015 16:20:49 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ben Campbell , draft-ietf-payload-vp8.all@ietf.org, payload-chairs@ietf.org, payload@ietf.org References: <8163A1DE-531A-4CDA-AA6F-61ADCDAE784B@nostrum.com> In-Reply-To: <8163A1DE-531A-4CDA-AA6F-61ADCDAE784B@nostrum.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [payload] Questions on draft-ietf-payload-vp8-16 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 14:20:55 -0000 Den 29. juni 2015 23:50, skrev Ben Campbell: > Hi, > > I'm doing a quick re-look at draft-ietf-payload-vp8-16 before starting a > repeat IETF Last Call. I have a few comments. I don't think any of these > need delay the last call, so please address them along with any last > call comments. > > Please bear in mind that I am reconstructing a lot of history here, so I > apologize in advance if I bring up things that have already been discussed. > > Thanks! > > Ben. > > ------------ > > General: > > Ted Lemon and Pete Resnick made some AD comments when they were still > ADs. Even though they are no longer on the IESG, their comments look > reasonable. I don't see evidence that they have been addressed--please > consider addressing them. > > It looks like you have addressed some, but not all, of Stephen Farrell's > comments. Has there been discussion on why the ones not addressed were > not addressed? I'm afraid we missed some :-( We'll consider these for the next update round - as far as I remember, they were all of an editorial nature ("this can be stated more clearly" or "this needs some more justification"). It wasn't immediately clear to us where responses to those comments should go either, given that they were never posted to the mailing list, and we can't respond in the tool that was used to keep them. > (Note that in both of the paragraphs above, I don't mean by "addressed" > that the draft necessarily needs to change--just that the authors > respond to the input--even if only to say why they don't agree with a > comment.) > > -- 4.5 and 4.5.1: It would be helpful to explain why these are listed as > examples. I assume it's one of those cases where this algorithm gives > the right results, but others could also do so. If so, some words to > that effect would be helpful. It might also be helpful to include a few > words indicating why 4.5.1 is a child of 4.5 rather than a peer. (I > assume because partition reconstruction is a subset of frame > reconstruction?) A tidier format would be to have 4.5 Reconstruction algorithms 4.5.1 Frame reconstruction 4.5.2 Partition reconstruction The sections were added in version -09 (July 2013), in response to Richard Barnes' AD review (where he pointed out that it was "mostly clear", but that it would be nice to make it explicit). I guess nobody looked hard at the table of content for the next 2 years. > > -- 7: > > I don't see a response to the secdir review ( Secdir review of > draft-ietf-payload-vp8-08 ). For the SRTP question, please consider > using the boilerplate in the appendix of draft-ietf-payload-rtp-howto-14 > (section A.13). > The secdir review was another one that we spent considerable time finding, and then did not address explicitly... The text about pathological data refers to the fact that some codecs have algorithms that allow very high complexity operations to be triggered by a suitably crafted data stream (10x or more beyond the decoding of an ordinary stream); VP8 does not contain such algorithms, so people shouldn't be too worried about this threat. It is in fact a direct quote from draft-ietf-payload-rtp-howto, so it seems a bit strange that the reviewer hadn't seen that one before. The security section seems mostly to be a direct copy from draft-ietf-payload-rtp-howto-00, including the lowercase "recommended". I like the text in -14 better, so I'll suggest replacing the -00 boilerplate with the -14 boilerplate for the next version. (Any objections?) We'll get there sooner or later... From nobody Wed Jul 15 09:36:23 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC26A1A1F04; Wed, 15 Jul 2015 09:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCDONR7l0eCv; Wed, 15 Jul 2015 09:36:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC061A1B9A; Wed, 15 Jul 2015 09:36:19 -0700 (PDT) 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.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150715163619.6432.50098.idtracker@ietfa.amsl.com> Date: Wed, 15 Jul 2015 09:36:19 -0700 Archived-At: Cc: draft-ietf-payload-g7110@ietf.org, payload-chairs@ietf.org, payload@ietf.org Subject: [payload] Joel Jaeggli's Yes on draft-ietf-payload-g7110-06: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 16:36:21 -0000 Joel Jaeggli has entered the following ballot position for draft-ietf-payload-g7110-06: 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-payload-g7110/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- all good. Thanks all joel From nobody Wed Jul 15 18:40:02 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918D11B2CCE; Wed, 15 Jul 2015 18:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDVENpK7iDzL; Wed, 15 Jul 2015 18:40:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8C11B2CEF; Wed, 15 Jul 2015 18:40:00 -0700 (PDT) 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.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150716014000.23044.59048.idtracker@ietfa.amsl.com> Date: Wed, 15 Jul 2015 18:40:00 -0700 Archived-At: Cc: draft-ietf-payload-g7110@ietf.org, payload-chairs@ietf.org, payload@ietf.org Subject: [payload] Ben Campbell's Yes on draft-ietf-payload-g7110-06: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 01:40:01 -0000 Ben Campbell has entered the following ballot position for draft-ietf-payload-g7110-06: 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-payload-g7110/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please consider updating the security considerations to use the boilerplate from the first paragraph of A.13 of draft-ietf-payload-rtp-howto-14. From nobody Sat Jul 18 07:15:53 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE4D1B2C6D for ; Sat, 18 Jul 2015 07:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqZy0Tz0Q2J7 for ; Sat, 18 Jul 2015 07:15:51 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4951B2CDB for ; Sat, 18 Jul 2015 07:15:50 -0700 (PDT) Received: by widjy10 with SMTP id jy10so60942474wid.1 for ; Sat, 18 Jul 2015 07:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=eoDfMObloT9KC7FpFpfZfuZGOCX/zHVFFymzJIP4TBs=; b=raFP/ldhENOqd1q8ofCcHH29XrBU1EPtBnVN73IfdR99XWpvbXsRZvUdr1Aw0Qv9R/ vRZ2o+FNcAMJNLS0/34Bb7jT6oXvrC4wFOfmGw01gdS5qcIRhE/35d0Phtc9IEftbmb3 yDEUe4i2cfmKVj1YOvm7s9WvhbhSVcQ4sKka1srjG0kG5IehKS6S7NA5/ihbYjWZwH4H KWcXcJMRDQSo9msM9qj3ckO2mO2hVwXKptpbR7k29EHXnl8cb0h6xokhuS5OK6GWAH7z WJQJTuYC7wVZztPPDCFuwverxEH6GMIr7Am3sovh3+q5X0PVBb9fsS2BflZAkJlwNVN3 otbA== X-Received: by 10.180.82.134 with SMTP id i6mr5052149wiy.15.1437228948755; Sat, 18 Jul 2015 07:15:48 -0700 (PDT) Received: from RoniPC ([62.168.35.66]) by smtp.gmail.com with ESMTPSA id dz4sm2717091wib.17.2015.07.18.07.15.45 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 18 Jul 2015 07:15:47 -0700 (PDT) From: "Roni Even" To: Date: Sat, 18 Jul 2015 17:15:39 +0300 Message-ID: <000001d0c164$3db1d7a0$b91586e0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D0C17D.6300BD50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDBYUPkmH+unQ86Qo6zrh24yTi0DQ== Content-Language: he Archived-At: Subject: [payload] Presentations for the payload session X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 14:15:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D0C17D.6300BD50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Please send the chairs the presentations for the Payload session by Monday morning Thanks Roni Even ------=_NextPart_000_0001_01D0C17D.6300BD50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Please send the = chairs the presentations for the Payload session by Monday = morning

Thanks

Roni Even

------=_NextPart_000_0001_01D0C17D.6300BD50-- From nobody Mon Jul 20 02:11:48 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7173B1A014C for ; Mon, 20 Jul 2015 02:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3e8SMuZlbVA for ; Mon, 20 Jul 2015 02:11:45 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::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 E84411A0123 for ; Mon, 20 Jul 2015 02:11:44 -0700 (PDT) Received: by wgav7 with SMTP id v7so59890470wga.2 for ; Mon, 20 Jul 2015 02:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=/GYRFk+lrXR4LArkkSlA8TG5IaK4GUdBu+UvLs6lwFA=; b=J0R9MyqiAtoY1JCKSTuHhaKBWUvFhs/CR2COQdMojOwjKHcXu7Km1S1TMp6PY7WTw0 EVh1+oU3w+GQZppETaRU8zXObzLiI5wFMPXWph/rSnttuN3yIuqOmqYkTWY11RQzojMs qd18/+IOMWPCmnPmCS2pLx/mhFjHdjraDz7aZ47LUMx24ppIumjYpXgcmAX0m0Zdm1yA 1V3r/SH1qV+FUTk181BglHBFxNJb7i6OTVIKSIU65+VT4BH4DjOm2a9N3oneOkqrLVXK PQlYGgnv9BGcTzobRCLri0TfFvPvhV0E3WuIav5mX74KQLpnAbRs0r7DHzgAPFr8Yvdb Cm7A== X-Received: by 10.180.206.41 with SMTP id ll9mr9467148wic.88.1437383503715; Mon, 20 Jul 2015 02:11:43 -0700 (PDT) Received: from RoniPC ([2001:67c:370:176:7886:9f27:b1c5:9452]) by smtp.gmail.com with ESMTPSA id js3sm31022653wjc.5.2015.07.20.02.11.24 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 20 Jul 2015 02:11:43 -0700 (PDT) From: "Roni Even" To: Date: Mon, 20 Jul 2015 12:11:25 +0300 Message-ID: <00c301d0c2cc$18c142a0$4a43c7e0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C4_01D0C2E5.3E0EEFD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDCzAqYEOrQTA8FSAGhunJ0tpfx7w== Content-Language: he Archived-At: Subject: [payload] Presentations for the payload session -reminder X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 09:11:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C4_01D0C2E5.3E0EEFD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Please send the chairs the presentations for the Payload session by Monday morning Thanks Roni Even ------=_NextPart_000_00C4_01D0C2E5.3E0EEFD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Please send the = chairs the presentations for the Payload session by Monday = morning

Thanks

Roni Even

------=_NextPart_000_00C4_01D0C2E5.3E0EEFD0-- From nobody Tue Jul 21 09:05:56 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765041B2F8E for ; Tue, 21 Jul 2015 09:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eq8k6wek2rXD for ; Tue, 21 Jul 2015 09:05:53 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFADA1A8F46 for ; Tue, 21 Jul 2015 09:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4730; q=dns/txt; s=iport; t=1437494753; x=1438704353; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Dls053A65U74fdlR3u/9yrNN8eupfCBw59YP+WOaqqQ=; b=RdEGSLaQkgCFSkkNIq/wLkElwEkamucfc2pxxjG5gZHXvT25LHDsRqXs ezgdELt33KDy9pCFMYf82tQG9ZzRf9Wc1soax1LhKHbAASy/QAKs4tpvh ZTqzpluXXWgNCnq5QhdgssYKqXKoA4HhryBarTnZ5K9ac2fI+hQAA8YTR o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQDZbK5V/4QNJK1cgxNUaQa8E4F1hh+BHjoSAQEBAQEBAYEKhCgCIxE4ChUBIgImAgQwFRIEiEENpUqPX5ZAAQEBAQEBAQMBAQEBAQEBAQEBGIEikh8vgRQFlFMBhHSHNQGBQkaDVoMQiAaIGSaCDRyBU28BgUaBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,517,1432598400"; d="scan'208";a="170843255" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-8.cisco.com with ESMTP; 21 Jul 2015 16:05:52 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t6LG5qJY023301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 Jul 2015 16:05:52 GMT Received: from xmb-aln-x01.cisco.com ([169.254.2.64]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 11:05:52 -0500 From: "Ali C. Begen (abegen)" To: "payload@ietf.org" Thread-Topic: Payload WG notes - Please read Thread-Index: AQHQw88dRc8Bj1w5zkONpq1MAxj7sQ== Date: Tue, 21 Jul 2015 16:05:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150701 x-originating-ip: [10.61.108.86] Content-Type: text/plain; charset="utf-8" Content-ID: <9F5BA00587213F48B3F3D616A26B1558@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [payload] Payload WG notes - Please read X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 16:05:55 -0000 IA0KUGxlYXNlIGhhdmUgYSBsb29rIGFuZCBzZW5kIGFueSBjb3JyZWN0aW9ucyB0byB0aGUgY2hh aXJzIGJ5IEp1bHkgMjh0aC4gUHJlc2VudGVycywgcGxlYXNlIGZpbGwgaW4gdGhlIGdhcHMgZGVu b3RlZCBieSBhIHF1ZXN0aW9uIG1hcmsuDQoNClRoYW5rcy4NCi1hY2JlZ2VuDQoNCklFVEYgOTMg LSBQYXlsb2FkIE5vdGVzDQpDaGFpcnM6IFJvbmkgRXZlbiwgQWxpIEJlZ2VuDQpOb3RlIHRha2Vy czogU3RlcGhhbiBXZW5nZXIsIE1vIFphbmF0eQ0KSmFiYmVyIHNjcmliZTogSm9uYXRoYW4gTGVu bm94DQogDQoNClBheWxvYWQgU3RhdHVzIFVwZGF0ZSBDaGFpcnMNCmh0dHBzOi8vd3d3LmlldGYu b3JnL3Byb2NlZWRpbmdzLzkzL3NsaWRlcy9zbGlkZXMtOTMtcGF5bG9hZC0wLnBkZg0KIA0KSDI2 NTogU0RQIGRpcmVjdG9yYXRlIHJldmlldyBieSBGbGVtbWluZyBBbmRyZWFzZW4gbm90ZWQgbm8g b3ZlcmFsbA0KZ3JhbW1hciBhbmQgbm8gZm9ybWFsIGdyYW1tYXIgZm9yIGZtdHAgcGFyYW1ldGVy cy4gTm8gaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMsDQpzbyBubyBjaGFuZ2UgbmVlZGVkLCBhY2Nv cmRpbmcgdG8gU3RlcGhhbiwgTWFnbnVzIFdlc3Rlcmx1bmQsIG90aGVycy4gTWFnbnVzOg0KcmVj b21tZW5kYXRpb24gaW4gaG93LXRvOiB3aGVuIHlvdSBoYXZlIGNvbXBsZXggcGFyYW1ldGVycywg dGhlbiB5b3Ugc2hvdWxkDQppbmNsdWRlIEFCTkYuICBPdGhlcndpc2Ugbm90Lg0KU3RlcGhhbjog dGhlcmUgaXMgYW4gQUJORiBpbiB0aGUgZHJhZnQgZm9yIG9uZSBjb21wbGV4IHBhcmFtZXRlci4N CiANCg0KVlA5IFJUUCBQYXlsb2FkIEZvcm1hdCAoTWFnbnVzIEZsb2RtYW4pDQpkcmFmdC1pZXRm LXBheWxvYWQtdnA5LTAwIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1wYXls b2FkLXZwOS0wMD4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkzL3NsaWRlcy9z bGlkZXMtOTMtcGF5bG9hZC0zLnBkZg0KIA0KRmxleGlibGUgYW5kIE5vbi1GbGV4aWJsZSBHT0Yg KEdyb3VwIG9mIEZyYW1lcykgc3RydWN0dXJlOiBNbyB0aGlua3MNCnRoaXMgbWF5IGJlIHVzZWZ1 bCBmb3Igb3RoZXIgY29kZWNzLCBhdXRob3JzIGhhdmUgbm8gaXNzdWVzIHdpdGggcmV1c2luZyB0 aGlzLg0KU3RlcGhhbiBub3RlZCB0aGF0IG90aGVyIGNvZGVjcyAoZS5nLiBILjI2NC81KSBoYXZl IG90aGVyIG1lYW5zIHRvIGNvbnZleSB0aGlzDQp3aXRoaW4gdGhlIHBheWxvYWQgaXRzZWxmIG5v dCBpbiBwYXlsb2FkIGhlYWRlcnMuDQogDQoNCkZsZXhpYmxlIEZFQyBSVFAgUGF5bG9hZCBGb3Jt YXQgKFZhcnVuIFNpbmdoKQ0KZHJhZnQtaWV0Zi1wYXlsb2FkLWZsZXhpYmxlLWZlYy1zY2hlbWUt MDAgPGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXBheWxvYWQtZmxleGlibGUt ZmVjLXNjaGVtZS0wMD4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkzL3NsaWRl cy9zbGlkZXMtOTMtcGF5bG9hZC0xLnBkZg0KIA0KQmVybmFyZCBBYm9iYTogSG93IGNhbiBhIHNl bmRlciBzaWduYWwgc3BlY2lmaWMgRkVDIHBhdHRlcm5zLCBsaWtlIG9ubHkNCnByb3RlY3QgdGhl IGJhc2UgbGF5ZXIgb2YgU1JTVCBSVFAgc3RyZWFtcz8gQXV0aG9ycyBjbGFyaWZpZWQgdGhhdCBu byBzdGF0aWMNCnNpZ25hbGluZyAoZS5nLiBTRFApIGlzIG5lY2Vzc2FyeSBzaW5jZSB0aGUgc2Vu ZGVyIGlzIGZyZWUgdG8gcGljayBkeW5hbWljDQpwYXR0ZXJucyBhbmQgYWxsIHJlY2VpdmVycyBt dXN0IGhhbmRsZSB0aGlzLg0KIA0KU2xpZGUgODogb3BlbiBpc3N1ZTogDQpKb25hdGhhbjogcHV0 dGluZyBTU1JDIGludG8gUlRQIHBheWxvYWQgaXMgc2NhcnkgKGxheWVyIHZpb2xhdGlvbikNCk1v OiB3ZSBhcmUgYWxyZWFkeSBpbiBsYXllciB2aW9sYXRpb24gZHVlIHRvIFNOOyBjb3VsZCBnbyBG ZWNmcmFtZSBtb2RlbA0KSm9uYXRoYW46ID8/PyBzb21ldGhpbmcgYWJvdXQgUGVyYywgDQpmZWMg b3ZlciBlbmNyeXB0ZWQgcGF5bG9hZA0KIA0KTWFnbnVzOiBEaXNsaWtlcyBubyBzdXBwb3J0IGZv ciBqdW1ibyBwYWNrZXRzID4gNEtCLiBCZXR0ZXIgdG8NCnN1cHBvcnQgNjRLQiBwYWNrZXRzIGFu ZCBleHBhbmQgdGhlIEZFQyBoZWFkZXIuIFN0ZXBoYW4gYWdyZWVzIHdpdGggZXhwYW5zaW9uLg0K IA0KRGlmZmVyZW50IG9waW5pb25zIGV4cHJlc3NlZCBvbiB3aGV0aGVyIHNvdXJjZSBmbG93IFNT UkMocykgc2hvdWxkIGJlDQppbmNsdWRlZCBpbiB0aGUgRkVDIGhlYWRlciwgb3Igb3RoZXIgaWRl bnRpZmllcnMgbGlrZSBNSUQgb3IgdGhlIG5ld2x5IHByb3Bvc2VkDQpFU0lEL1JTSUQuIEFsc28g ZGlmZmVyZW50IHZpZXdzIG9uIHNpZ25hbGluZyBtdWx0aXBsZSBzb3VyY2UgZmxvd3MuDQpSZXN1 bHQ6IE5lZWQgYSBzaWRlIG1lZXRpbmcgdG8gZGVjaWRlIHdoYXQgc291cmNlIGZsb3cgaWRlbnRp ZmllciBpcw0KdXNlZCB0byBhc3NvY2lhdGUgd2l0aCBhIEZFQyByZXBhaXIgZmxvdyBhbmQgaG93 IHRvIGhhbmRsZSBtdWx0aXBsZSBzb3VyY2UNCmZsb3dzLiBWYXJ1biB3aWxsIGxlYWQgYW5kIGNv cHkgdGhlIGxpc3QuDQogDQoNCk1FTFBlIENvZGVjIChSb25pIEV2ZW4gZm9yIFZpY3RvciBEZW1q YW5lbmtvKQ0KZHJhZnQtZGVtamFuZW5rby1wYXlsb2FkLW1lbHBlLTAzIDxodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaWQvZHJhZnQtZGVtamFuZW5rby1wYXlsb2FkLW1lbHBlLTAzPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTMvc2xpZGVzL3NsaWRlcy05My1wYXlsb2FkLTQucGRm DQogDQpTdGVwaGFuIGhhcyByZWFkIGl0IGFuZCB0aGlua3MgaXQgaXMgYSB3ZWxsIHdyaXR0ZW4g UlRQIHBheWxvYWQgZm9ybWF0DQpkcmFmdC4gTm8gb3RoZXIgcmV2aWV3ZXJzLCBzbyBjaGFpcnMg d2lsbCBhc2sgdGhlIGxpc3QgdG8gcmV2aWV3Lg0KIA0KDQpJbnRlcmxlYXZlZCBSVFAgUGF5bG9h ZCBGb3JtYXQgKFJhY2hlbCBIdWFuZykNCmRyYWZ0LWh1YW5nLXBheWxvYWQtcnRwLWludGVybGVh dmUtMDAgPGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1odWFuZy1wYXlsb2FkLXJ0cC1p bnRlcmxlYXZlLTAwPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTMvc2xpZGVz L3NsaWRlcy05My1wYXlsb2FkLTIucGRmDQogDQpKb25hdGhhbjogTm90ZSB0aGF0IFBUIG11c3Qg YmUgdGhlIHNhbWUuDQpSYWNoZWw6IHllcw0KSm9uYXRoYW46IGFzc3VtcHRpb24gYWdncmVnYXRp b24gbmV2ZXIgY2hhbmdlcyBudW1iZXIgb2YgcGFja2V0cy4gIA0KUmFjaGVsOiB5ZXMNCkpvbmF0 aGFuOiB3aXRoIG1vcmUgZmxleGlibGUgc2VxdWVuY2UgbnVtYmVyIG1lY2hhbmlzbSwgeW91IGNv dWxkIGRvIGJldHRlcg0KUmFjaGVsOiB5ZXMNCkltZWQ6IEludGVybGVhdmUgYW4gSURSLCB3aGF0 4oCZcyB0aGUgZ2Fpbj8NClJhY2hlbDogPz8/DQoNCg0KDQo= From nobody Tue Jul 21 09:08:01 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073841B2F96; Tue, 21 Jul 2015 09:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJS00tn_ZcHr; Tue, 21 Jul 2015 09:07:55 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B15261B2F92; Tue, 21 Jul 2015 09:07:54 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-05-55ae6e58ab08 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id EE.DF.25217.85E6EA55; Tue, 21 Jul 2015 18:07:52 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.210.2; Tue, 21 Jul 2015 18:07:51 +0200 To: IETF AVTCore WG , "payload@ietf.org" From: Magnus Westerlund Message-ID: <55AE6E55.4090309@ericsson.com> Date: Tue, 21 Jul 2015 18:07:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------090403010507040300030401" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+JvjW5E3rpQg/1XzC1e9qxkt7h08SyT A5PHkiU/mQIYo7hsUlJzMstSi/TtErgy7p45yFpwajtjxcdvb1gaGNdPYexi5OSQEDCRuLvm KRuELSZx4d56IJuLQ0jgKKPEi0f9jBDOckaJm3PXg3WICHhKLNi1EKyDTcBC4uaPRjBbWMBS YtGsK0wgNq+AtsT+IzuYQWwWAVWJu/u62EFsUYEYifkrpjND1AhKnJz5hAXEZhYIkGjfcxLM FgLqbWjqYJ3AyDsLSdksJGWzGDmAbHuJB1vLIMLyEs1bZzNDhP0lFjwKhQhrSyxb+JoZwnaW WH91PtMCRvZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIFhenDLb6sdjAefOx5iFOBgVOLh XbB8bagQa2JZcWXuIUZpDhYlcd4Zm/NChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTB25BVv urVqzXsWl3MnZ6xynZBh/G+ubdgidrcqVZ3+VTuCOAtPp/se3P1HeT2fyW69R/uTbjLw1Jxl t93BunOXWXhd+aLcKz5J7Z6vI66za6h3zNCbGd85K+TMnNvKN6O8Mnel/NnJ8pLXT9T9cUKT c4WodeYdtx8TpGt45j1NaM4+svsj6wQlluKMREMt5qLiRADTdlOdNAIAAA== Archived-At: Subject: [payload] Erratas on RFC 4867 (The AMR RTP Payload Format) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 16:07:59 -0000 --------------090403010507040300030401 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit AVTCORE and PAYLOAD, There has been three erratas submitted toward RFC 4867 the AMR RTP payload format: http://www.rfc-editor.org/errata_search.php?rfc=4867 The numbers for the Erratas are 4347, 4348, and 4349. I am one of the co-authors and I want to resolve these erratas. I am sending this to both AVTCORE and PAYLOAD WG due to that the erratas arriving on AVTCORE's mailing list, but is more in PAYLOAD's scope. So please keep both lists in the reply. Any judgment of the consensus will be done by Roni Even. They are all related to text regarding the usage of the Codec Mode Request field. Unclarities and contradictions in the RFC has caused interoperability problems. These have been discussed in 3GPP SA4 and they have discussed and agreed on this proposal for addressing these issues. The proposed changes can be seen in the errata as well as the motivations. I have produced a side-by-side diff for the text changes which is attached to make it easier to see what is proposed to be changed in the text. From my perspective these erratas should be VERIFIED. The reason is that the changes proposed appear to be enforcing what I can remember being the intention of the document, but being more easier to understand and without the conflict. However, there has been substantial amount of time since this was specified and people may have other views. Thus, I really like to see if someone disagree with that the erratas encode the intention and therefore should not be VERIFIED. It would be good if people could provide any feedback no later than the 22nd of August. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------090403010507040300030401 Content-Type: text/html; charset="ISO-8859-1"; name="Diff-errata-rfc4867.htm" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Diff-errata-rfc4867.htm" =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Diff: amr-orig.txt - amr-changed.txt=20 =20 =20 =20 =20 =20 = = = = <= td class=3D"right"> mode set, but can always be used. If mod= e-set is
 amr-orig.txt   amr-changed.txt 
CM= R (4 bits): Indicates a codec mode request sent to the speech CMR (4 bits): Indicates a codec mode request sent t= o the speech
= encoder at the site of the receiver of this payload. The value of encoder at the site of the receiver of thi= s payload. The value of
= the CMR field is set to the frame type index of the corresponding= the CMR field is set to the frame type inde= x of the corresponding
= speech mode being requested. The frame type index may be 0-7 for= speech mode being requested. The frame typ= e index may be 0-7 for
= AMR, as defined in Table 1a in [2], or 0-8 for AMR-WB, as defined= AMR, as defined in Table 1a in [2], or 0-8 = for AMR-WB, as defined
= in Table 1a in [4]. CMR value 15 indicates that no mode request in Table 1a= in [4]. CMR value 15 indicates that the receiver h= as
is present, and other values are for futur= e use. no p= reference in which mode within the negotiated= mode set to
receive, and other values are for future use.
Th= e codec mode request received in the CMR field is valid until the = The codec mode request received in the CMR fiel= d is valid until the
ne= xt codec mode request is received, i.e., a newly received CMR value next codec mode request is received, i.e., a = newly received CMR value
= corresponding to a speech mode, or NO_DATA ov= errides the previously corresponding = to a speech mode, or CMR=3D15 overrides the p= reviously
= received CMR value corresponding to a speech mode or NO_DATA. received CMR value c= orresponding to a speech mode or CMR=3D15.
= Therefore, if a terminal continuously wishes to receive frames in the Therefore, = if a terminal continuously wishes to receive frames = not
same mode X, it needs to set CMR=3DX for all = its outbound payloads, and higher than mode X, it needs to set CMR=3DX for all i= ts outbound
= if a terminal has no preference in which mode to receive, it SHOULD payloads, and if a terminal has no preferenc= e in which mode within
= set CMR=3D15 in all its outbound payloads. the negotiated mode set to receive, it = SHOULD set CMR=3D15 in all its
outbound payloads.
If= receiving a payload with a CMR value that is not a speech mode or= If receiving a payload with a CMR value that i= s not a speech mode or
= NO_DATA, the CMR MUST be ignored by the recei= ver. CMR=3D15<= /span>, the CMR MUST be ignored by the receiver.
= The encoder SHOULD follow a received codec mo= de request, but MAY The encoder MUST follow a rece= ived codec mode request as soon as
= change to a lower-numbered mode if it so chooses, for example, to = possible. It SHOULD use= the requested mode, but MAY change to a
= control congestion. lower-numbered mo= de if it so chooses, for example, to
control congestion. However, the encoder MUST NOT use a
higher-numbered = mode than the received codec mode request.
= mode-set: Restricts the active codec mode set to a subset of all = mode-set: Restricts the active codec mode se= t to a subset of all
= modes, for example, to be able to support transport modes, for example, to be able to suppo= rt transport
= channels such as GSM networks in gateway use cases. channels such as GSM networks in gatewa= y use cases.
= Possible values are a comma separated list of modes from= Possible values are a comma separa= ted list of modes from
= the set: 0,...,7 (see Table 1a [2]). The SID frame type= the set: 0,...,7 (see Table 1a [2]= ). The SID frame type
= 8 and NO_DATA (frame type 15) are never included in the = 8 and NO_DATA (frame type 15) are n= ever included in the
= mode set, but can always be used. If mode-set is
= specified, it MUST be abided, and= frames encoded with spec= ified, it MUST be abided, i.e. frames encoded= with
= modes outside of the subset MUST NOT be sent in any RTP = modes outside of the subset MUST NO= T be sent in any RTP
= payload or used in codec mode requests. If not present, payload and code= c mode requests MUST only use modes
= all codec modes are allowed for the payload type. within the mode= -set or CMR=3D15. If the mode-set parameter
is not present, then all codec modes are a= llowed for the
payload type.
 End of changes. 6 change blocks. 
13 lines changed or deleted 17 lines changed or added

This html = diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/to= ols/rfcdiff/
X-Generator: pyht 0.35