From nobody Wed Jul 6 12:47:03 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F1A12B008; Wed, 6 Jul 2016 12:46:58 -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.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160706194658.26736.4327.idtracker@ietfa.amsl.com> Date: Wed, 06 Jul 2016 12:46:58 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rid-05.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 19:46:58 -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 Extensions of the IETF. Title : RTP Stream Identifier Source Description (SDES) Authors : Adam Roach Suhas Nandakumar Peter Thatcher Filename : draft-ietf-avtext-rid-05.txt Pages : 8 Date : 2016-07-06 Abstract: This document defines and registers two new RTCP SDES items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream a redundancy RTP stream is to be used to repair. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-rid-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rid-05 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 Wed Jul 6 12:48:46 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553A312B008 for ; Wed, 6 Jul 2016 12:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 YDuBoUFIAoW5 for ; Wed, 6 Jul 2016 12:48:44 -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 3B34112D10F for ; Wed, 6 Jul 2016 12:48:44 -0700 (PDT) Received: from Orochi.local (ip-64-134-50-209.public.wayport.net [64.134.50.209]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u66JmWAI003380 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 6 Jul 2016 14:48:35 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host ip-64-134-50-209.public.wayport.net [64.134.50.209] claimed to be Orochi.local To: Jonathan Lennox References: <12858949-AD94-4B45-B383-9D5396DA16D0@vidyo.com> From: Adam Roach Message-ID: Date: Wed, 6 Jul 2016 14:48:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <12858949-AD94-4B45-B383-9D5396DA16D0@vidyo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "avtext@ietf.org" , "Suhas Nandakumar \(snandaku\)" Subject: Re: [avtext] RID needs proper header extension registrations X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 19:48:45 -0000 Sorry this took so long to get around to. I think I've added the appropriate text to -05. Please let me know if you think anything additional is needed. /a On 6/22/16 11:09, Jonathan Lennox wrote: > Hi, Adam — > > I realized on writing up the PubReq for RID that it needs proper registration for the sdes-hdr-ext items — we need to mention the SDES header extension IANA registry, explicitly state the URNs implementations should use, etc. > > See the discussion of MID on MMUSIC in the last few days. > > It probably needs more explanation of the privacy and timeliness considerations for the SDES items, too, as Magnus pointed out for MID. > > Sorry I didn’t catch this sooner. > > -Jonathan > From nobody Thu Jul 7 08:27:38 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718CA12B05F for ; Thu, 7 Jul 2016 08:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 iUInWh1nbPUH for ; Thu, 7 Jul 2016 08:27:35 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45810127058 for ; Thu, 7 Jul 2016 08:27:35 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u67FPNep012552 for ; Thu, 7 Jul 2016 11:27:35 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 23s7e89cga-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 07 Jul 2016 11:27:35 -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; Thu, 7 Jul 2016 10:27:34 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: AVTExt agenda requests for Berlin Thread-Index: AQHR2GQVMSxCm4fu/0ixfl26g8Ysng== Date: Thu, 7 Jul 2016 15:27:33 +0000 Message-ID: <24FD244E-4A0A-4D41-839A-8D85D8E8712B@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: <396808D480AD1D498C4AB03FA9AD0472@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-07-07_09:2016-07-07,2016-07-07,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-1603290000 definitions=main-1607070141 Archived-At: Subject: [avtext] AVTExt agenda requests for Berlin X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 15:27:36 -0000 VGhlIEFWVEV4dCB3b3JraW5nIGdyb3VwIHdpbGwgYmUgbWVldGluZyBpbiBCZXJsaW4sIG9uIFR1 ZXNkYXkgYWZ0ZXJub29uICgxOSBKdWx5KSwgc2NoZWR1bGVkIGZyb20gMTY6MjAgLSAxODoyMC4N Cg0KUGxlYXNlIHNlbmQgYWdlbmRhIHJlcXVlc3RzIHRvIHRoZSBjaGFpcnMsIGluZGljYXRpbmcg d2hhdCB0b3BpYyB5b3XigJlkIGxpa2UgdG8gZGlzY3Vzcywgd2hvIHdpbGwgYmUgcHJlc2VudGlu ZywgYW5kIGhvdyBtdWNoIHRpbWUgeW91IGV4cGVjdCB0byBuZWVkLg0KDQpUaGFua3MhDQoNCkpv bmF0aGFuIChBVlRFeHQgY28tY2hhaXIpLg0KDQo= From nobody Thu Jul 7 09:45:13 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93BAE12D826 for ; Thu, 7 Jul 2016 09:44:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160707164457.23709.37735.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 09:44:57 -0700 From: IETF Secretariat Archived-At: Subject: [avtext] Milestones changed for avtext WG X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 16:44:59 -0000 Changed milestone "Submit Mechanism for Identifying Encoded and Dependent Streams for Proposed Standard", resolved as "Done". URL: https://datatracker.ietf.org/wg/avtext/charter/ From nobody Fri Jul 8 14:04:21 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DF312D60D; Fri, 8 Jul 2016 14:04:15 -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.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708210415.32193.9938.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 14:04:15 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-lrr-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 21:04:15 -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 Extensions of the IETF. Title : The Layer Refresh Request (LRR) RTCP Feedback Message Authors : Jonathan Lennox Danny Hong Justin Uberti Stefan Holmer Magnus Flodman Filename : draft-ietf-avtext-lrr-03.txt Pages : 14 Date : 2016-07-08 Abstract: This memo describes the RTCP Payload-Specific Feedback Message "Layer Refresh Request" (LRR), which can be used to request a state refresh of one or more substreams of a layered media stream. It also defines its use with several RTP payloads for scalable media formats. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-lrr/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-lrr-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-lrr-03 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 Jul 8 14:07:17 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A9C12D533 for ; Fri, 8 Jul 2016 14:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 4-eBWGG9jPrE for ; Fri, 8 Jul 2016 14:07:14 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477E512B034 for ; Fri, 8 Jul 2016 14:07:14 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u68L5ghl027469 for ; Fri, 8 Jul 2016 17:07:13 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 241uh68te9-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 08 Jul 2016 17:07:13 -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; Fri, 8 Jul 2016 16:07:12 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-lrr-03.txt Thread-Index: AQHR2VxgOPDaoBoglk2sSVbbG5ls/aAPWnyA Date: Fri, 8 Jul 2016 21:07:12 +0000 Message-ID: <336D76E1-508C-4E84-A4CA-B427CF73F9C5@vidyo.com> References: <20160708210415.32193.9938.idtracker@ietfa.amsl.com> In-Reply-To: <20160708210415.32193.9938.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="utf-8" Content-ID: <3E8E76B230339D4A8528515E1962A1A0@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-07-08_13:2016-07-08,2016-07-08,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-1603290000 definitions=main-1607080205 Archived-At: Subject: Re: [avtext] I-D Action: draft-ietf-avtext-lrr-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 21:07:16 -0000 SGV5LCBhbGwg4oCUDQoNClRoaXMgdmVyc2lvbiBjaGFuZ2VzIHRoZSBiaXRmaWVsZCBsYXlvdXRz IG9mIHRoZSBsYXllciBpZGVudGlmaWVycyB0byBtYXRjaCB0aGUgb25lcyBpbiB0aGUgZnJhbWUg bWFya2luZyBkcmFmdCAoYW5kIHJlcXVpcmVzIHRoYXQgbmV3IHBheWxvYWQgZm9ybWF0cyB0aGF0 IHN1cHBvcnQgYm90aCBMUlIgYW5kIGZyYW1lIG1hcmtpbmcgTVVTVCBhbHNvIHVzZSB0aGUgbWF0 Y2hpbmcgbGF5b3V0cyBmb3IgYm90aC4pDQoNCk5vIG90aGVyIHN1YnN0YW50aXZlIGNoYW5nZXMg KHNvbWUgcmVmZXJlbmNlcyB3ZXJlIHVwZGF0ZWQpLg0KDQpDb21tZW50cyB3ZWxjb21lLg0KDQo+ IE9uIEp1bCA4LCAyMDE2LCBhdCA1OjA0IFBNLCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgd3Jv dGU6DQo+IA0KPiANCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEg d29yayBpdGVtIG9mIHRoZSBBdWRpby9WaWRlbyBUcmFuc3BvcnQgRXh0ZW5zaW9ucyBvZiB0aGUg SUVURi4NCj4gDQo+ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBUaGUgTGF5ZXIgUmVmcmVzaCBS ZXF1ZXN0IChMUlIpIFJUQ1AgRmVlZGJhY2sgTWVzc2FnZQ0KPiAgICAgICAgQXV0aG9ycyAgICAg ICAgIDogSm9uYXRoYW4gTGVubm94DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBEYW5ueSBI b25nDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBKdXN0aW4gVWJlcnRpDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICBTdGVmYW4gSG9sbWVyDQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICBNYWdudXMgRmxvZG1hbg0KPiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1hdnRleHQt bHJyLTAzLnR4dA0KPiAJUGFnZXMgICAgICAgICAgIDogMTQNCj4gCURhdGUgICAgICAgICAgICA6 IDIwMTYtMDctMDgNCj4gDQo+IEFic3RyYWN0Og0KPiAgIFRoaXMgbWVtbyBkZXNjcmliZXMgdGhl IFJUQ1AgUGF5bG9hZC1TcGVjaWZpYyBGZWVkYmFjayBNZXNzYWdlICJMYXllcg0KPiAgIFJlZnJl c2ggUmVxdWVzdCIgKExSUiksIHdoaWNoIGNhbiBiZSB1c2VkIHRvIHJlcXVlc3QgYSBzdGF0ZSBy ZWZyZXNoDQo+ICAgb2Ygb25lIG9yIG1vcmUgc3Vic3RyZWFtcyBvZiBhIGxheWVyZWQgbWVkaWEg c3RyZWFtLiAgSXQgYWxzbyBkZWZpbmVzDQo+ICAgaXRzIHVzZSB3aXRoIHNldmVyYWwgUlRQIHBh eWxvYWRzIGZvciBzY2FsYWJsZSBtZWRpYSBmb3JtYXRzLg0KPiANCj4gDQo+IFRoZSBJRVRGIGRh dGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWF2dGV4dC1scnIvDQo+IA0KPiBUaGVyZSdz IGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXZ0ZXh0LWxyci0wMw0KPiANCj4gQSBkaWZmIGZyb20g dGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1hdnRleHQtbHJyLTAzDQo+IA0KPiANCj4gUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzLw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gYXZ0ZXh0IG1haWxpbmcgbGlzdA0KPiBhdnRleHRAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnRleHQNCj4gDQoN Cg== From nobody Sat Jul 9 06:55:02 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3355A12B014; Sat, 9 Jul 2016 06:55:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160709135501.25504.78750.idtracker@ietfa.amsl.com> Date: Sat, 09 Jul 2016 06:55:01 -0700 Archived-At: Cc: draft-ietf-avtext-splicing-notification@ietf.org, avtext@ietf.org, jonathan@vidyo.com, avtext-chairs@ietf.org Subject: [avtext] Stephen Farrell's No Objection on draft-ietf-avtext-splicing-notification-08: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 13:55:01 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-avtext-splicing-notification-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to 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-avtext-splicing-notification/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for handling my discuss points. Old comments below, I didn't check those. ----- - I agree with Alia's discuss, but suspect the ship has sailed. (Sadly IMO, but sailed nonetheless.) - The security considerations here are similar to but not quite the same as those in RFC6828 which I think was the last time a similar document was before the IESG. I wondered if those differences were significant or not, it might be no harm to commpare the two (if that's not already been done) since they really ought be pretty much the same. From nobody Tue Jul 12 08:00:57 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C0512D929; Tue, 12 Jul 2016 08:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 47-cS_THW5g3; Tue, 12 Jul 2016 08:00:54 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91F0712D92A; Tue, 12 Jul 2016 07:30:02 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-a8-5784fee7ee22 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6C.96.12516.7EEF4875; Tue, 12 Jul 2016 16:30:00 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.294.0; Tue, 12 Jul 2016 16:29:58 +0200 To: "avtext@ietf.org" , "draft-ietf-avtext-rid@ietf.org" From: Magnus Westerlund Message-ID: <7f554d73-47e1-5401-98cd-056268406a2c@ericsson.com> Date: Tue, 12 Jul 2016 16:29:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM2K7iu6Lfy3hBof+KVh8vHeD1WLfjods DkweS5b8ZApgjOKySUnNySxLLdK3S+DKuLLlM0vBV4OKpQvfsDUwdqp3MXJySAiYSCz6+4gd whaTuHBvPRuILSRwhFGia7dpFyMXkL2cUeL67wusIAkRgRyJk8d6wIrYBCwkbv5oBLI5OIQF TCVeHc8BCfMK2EtsuLOCCcRmEVCVaPrzlgWkRFQgRmJ9XwJEiaDEyZlPwMLMQOUPtpaBhJkF 5CWat85mhrhAW6KhqYN1AiPfLCQdsxA6ZiHpWMDIvIpRtDi1uDg33chYL7UoM7m4OD9PLy+1 ZBMjMKgObvmtu4Nx9WvHQ4wCHIxKPLwL7jWHC7EmlhVX5h5ilOBgVhLhbfnZEi7Em5JYWZVa lB9fVJqTWnyIUZqDRUmc1/+lYriQQHpiSWp2ampBahFMlomDU6qBUez7QfHtXsdkK9Vm7uX4 eem43984q12qqz8c4rgRuO/5dlWj4i0NCzWWhW7Rq+HXq2BiOGh9q35Vb/T5br8kFd0TRlvu m2xSzv2mfXfhziWp+W17l6Sevu7+y19zil/knktWVxKaphy2uu7/hzv3Z4PujO+57DNveNr2 nQk9GXDt1ZF+J27OhUosxRmJhlrMRcWJAC8+PScmAgAA Archived-At: Subject: [avtext] draft-ietf-avtext-rid-05: A couple of issues X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 15:00:55 -0000 Hi, Doing a review across the whole RID+RID and Simulcast document I have some significant comment on draft-ietf-avtext-rid-05. I am sorry I missed WGLC for this document. So please consider this early IETF last call comments. 1. The definition of the RepairedRtpStreamId in Section 3 is not particular clear on the limitations this design have. As the SDES item can only contain a single RtpStreamId value the implication is that RepairedRtpStreamId can only be used when the redundancy mechanism has a one to one relation with a source RTP stream. This can't be used with redundancy mechanisms that protects multiple RTP streams. I think this could be made clearer in Section 3. 2. Section 4.4: Extension URI: urn:ietf:params:rtp-hdrext:sdes:repair-rtp-sream-id Why is this URI not "Extension URI: urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-sream-id"? 3. Section 3.3 and 5: I think the privacy considerations in the security consideration needs to be strengthen. Section 3.3: Implementors are warned, in particular, not to include any information in the identifier that is derived from potentially user- identifying information, such as user ID or IP address. To avoid identification of specific implementations based on their pattern of tag generation, implementations are encouraged to use a simple scheme that starts with the ASCII digit "1", and increments by one for each subsequent identifier. Section 5: The actual identifiers used for RtpStreamIds (and therefore RepairedRtpStreamIds) are expected to be opaque. As such, they are not expected to contain information that would be sensitive, were it observed by third-parties. I think my main criticism is how section 5 is formulated. I think it could start out in the risks, as an SDES items can carry any UTF-8 string that is not to long. Therefore the generation of the string is important so that it does not contain any privacy sensitive information. I will also note that this fails to discuss the importance of the labels being possible to trust. Otherwise replacing the labels have interesting effects in the applications. I would suggest for Section 5: --- Start of proposed text --- The SDES items has the potential to carry any UTF-8 string. Therefore it exists a risk that it carries privacy sensitive information. Implementations needs to take care when generating identifiers so that they do not contains information that can identify the user or allow for long term tracking of the device. Following the generation recommendations in Section 3.3 will result in non instance specific labels, with only minor fingerprinting possibilities in the total number of used RtpStreamIds and RepairedRtpStreamIds. Even if the SDES items are generated to be as information less as possible, it is RECOMMENDED that the SDES items are encrypted to preserve privacy against third parties. The means encryption of both RTCP as well as the RTP header extension part. As the SDES items are used for identification of the RTP streams for different application purposes, it is important that the intended values are received. An attacker, either a third party or malicious RTP middlebox, that removes, or exchanges the values for these SDES items can severely impact the application. The impact can include failure to decode or display the media content of the RTP stream, it can also result in incorrectly attribute media content to identifiers of the media source, such as the wrongly label the speaker. To prevent this from occurring due to third party attacks, integrity and source authentication is needed. Options for Securing RTP Sessions [RFC7201] discusses options for how the encryption, integrity and source authentication can be accomplished. --- End of proposed text --- 4. Section 3: This specification defines two new RTCP SDES items [RFC3550]. The first item is 'RtpStreamId', which is used to carry RTP stream identifiers within RTCP SDES packets. This makes it possible for a receiver to associate received RTP packets (identifying the RTP stream) with a media description having the format constraint specified. The definition of the RtpStreamId is missing a discussion of requiremetns on the value. mmusic-rid document in Section 4 is indicating through the following line: A given "rid-id" MUST NOT be repeated in a given media description ("m=" section). From my perspective I do wonder if the definition in this document needs to makes this clear. And also possibly make it clear that there exist no requirement for it be unique across all RTP streams in the RTP session, something the name may imply. This clearly also indicates that if one have multiple media sources that can use the same RtpStreamIds then one needs some additional mechanism to identify them. Media sources from different endpoints can be seperated using SDES CNAME. So the main issue appears to exist in cases where one endpoint sends multiple media sources in the same RTP session, such as when BUNDLE is used. See my review of draft-ietf-mmusic-rid for additional aspects of this on the a=rid side. 5. Section 3. I think adding a sentence that SDES items are UTF-8 and have a maximum length of 255 Octets, and with a warning that as many symbols encoded in UTF-8 have multi-octet representations, the limit to the number of symbols that fits may be much lower than 255. This as RFC3550 is not super clear on this implication, even if the limitations are clear when it comes to SDES items having a max length of 255 octets. 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 ---------------------------------------------------------------------- From nobody Thu Jul 14 16:18:08 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9799012D8E7; Thu, 14 Jul 2016 16:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 ZdQGD0hGKHf5; Thu, 14 Jul 2016 16:18:05 -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 4F34112D8DE; Thu, 14 Jul 2016 16:18:04 -0700 (PDT) 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.15.2) with ESMTPSA id u6ENHx5t087599 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 Jul 2016 18:17:59 -0500 (CDT) (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: Magnus Westerlund , "avtext@ietf.org" , "draft-ietf-avtext-rid@ietf.org" References: <7f554d73-47e1-5401-98cd-056268406a2c@ericsson.com> From: Adam Roach Message-ID: <39d6b6ec-cf78-9074-b700-4da4eb7e08f0@nostrum.com> Date: Thu, 14 Jul 2016 18:17:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7f554d73-47e1-5401-98cd-056268406a2c@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [avtext] draft-ietf-avtext-rid-05: A couple of issues X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 23:18:06 -0000 On 7/12/16 09:29, Magnus Westerlund wrote: > 1. The definition of the RepairedRtpStreamId in Section 3 is not > particular clear on the limitations this design have. As the SDES item > can only contain a single RtpStreamId value the implication is that > RepairedRtpStreamId can only be used when the redundancy mechanism has > a one to one relation with a source RTP stream. This can't be used > with redundancy mechanisms that protects multiple RTP streams. I think > this could be made clearer in Section 3. I'm not sure that's a limitation of the current design -- packet types are allowed to appear more than once, right? It seems that it would be reasonable to include more than one RepairedRtpStreamId SDES packet in a single compound packet, right? I agree that we need to say more about this, but the limitation you imply is necessary seems artificial. I'm adding: "For those schemes in which a redundancy stream contains information used to repair more than one stream, multiple RepairedRtpStreamId SDES items may appear in a single compound packet. Due to the foregoing scoping rules, the RepairedRtpStreamId cannot be used to indicate streams in multiple sessions or with varying MIDs." > 2. Section 4.4: > > Extension URI: urn:ietf:params:rtp-hdrext:sdes:repair-rtp-sream-id > > Why is this URI not "Extension URI: > urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-sream-id"? Jetlag. I've fixed it. > 3. Section 3.3 and 5: > > I think the privacy considerations in the security consideration needs > to be strengthen. > ... > I would suggest for Section 5: > > --- Start of proposed text --- > > The SDES items has the potential to carry any UTF-8 string. Therefore > it exists a risk that it carries privacy sensitive information. > Implementations needs to take care when generating identifiers so that > they do not contains information that can identify the user or allow > for long term tracking of the device. Following the generation > recommendations in Section 3.3 will result in non instance specific > labels, with only minor fingerprinting possibilities in the total > number of used RtpStreamIds and RepairedRtpStreamIds. > > Even if the SDES items are generated to be as information less as > possible, it is RECOMMENDED that the SDES items are encrypted to > preserve privacy against third parties. The means encryption of both > RTCP as well as the RTP header extension part. > > As the SDES items are used for identification of the RTP streams for > different application purposes, it is important that the intended > values are received. An attacker, either a third party or malicious > RTP middlebox, that removes, or exchanges the values for these SDES > items can severely impact the application. The impact can include > failure to decode or display the media content of the RTP stream, it > can also result in incorrectly attribute media content to identifiers > of the media source, such as the wrongly label the speaker. To prevent > this from occurring due to third party attacks, integrity and source > authentication is needed. > > Options for Securing RTP Sessions [RFC7201] discusses options for how > the encryption, integrity and source authentication can be accomplished. > > --- End of proposed text --- Excellent. Thanks for sending text. I'm editing it slightly and replacing the entire security section with it. > 4. Section 3: > > This specification defines two new RTCP SDES items [RFC3550]. The > first item is 'RtpStreamId', which is used to carry RTP stream > identifiers within RTCP SDES packets. This makes it possible for a > receiver to associate received RTP packets (identifying the RTP > stream) with a media description having the format constraint > specified. > > The definition of the RtpStreamId is missing a discussion of > requiremetns on the value. > > mmusic-rid document in Section 4 is indicating through the following > line: > > A given > "rid-id" MUST NOT be repeated in a given media description ("m=" > section). > > From my perspective I do wonder if the definition in this document > needs to makes this clear. And also possibly make it clear that there > exist no requirement for it be unique across all RTP streams in the > RTP session, something the name may imply. This clearly also indicates > that if one have multiple media sources that can use the same > RtpStreamIds then one needs some additional mechanism to identify > them. Media sources from different endpoints can be seperated using > SDES CNAME. Yes, a discussion of scoping is certainly called for. I propose: RtpStreamId and RepairedRtpStreamId values are scoped by source identifier (e.g., CNAME) and by media session. When the media is multiplexed using the BUNDLE extension {{I-D.ietf-mmusic-sdp-bundle-negotiation}}, these values are further scoped by their associated MID values. For example: an RtpStreamId of "1" may be present in the stream identified with a CNAME of "1234@example.com", and may also be present in a stream with a CNAME of "5678@example.org", and these would refer to different streams. Similarly, an RtpStreamId of "1" may be present with an MID of "A", and again with a MID of "B", and also refer to two different streams. > 5. Section 3. > > I think adding a sentence that SDES items are UTF-8 and have a maximum > length of 255 Octets, and with a warning that as many symbols encoded > in UTF-8 have multi-octet representations, the limit to the number of > symbols that fits may be much lower than 255. I would think that "make them as small as possible" and "use this approach that keeps them one character long" should be sufficient, but I'll add text just to be triple-sure. As with all SDES items, RtpStreamId and RepairedRtpStreamId are limited to a total of 255 octets in length. Since the values of these items are encoded with UTF-8, the use of multi-octet characters will result in limitations smaller than 255 characters. It is in implementations' interests to keep these values as small as possible in any case, so this limitation is not expected to have any significant impact. /a From nobody Mon Jul 18 01:31:06 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A5712D150; Mon, 18 Jul 2016 01:31:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160718083101.12452.96667.idtracker@ietfa.amsl.com> Date: Mon, 18 Jul 2016 01:31:01 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rid-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 08:31:01 -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 Extensions of the IETF. Title : RTP Stream Identifier Source Description (SDES) Authors : Adam Roach Suhas Nandakumar Peter Thatcher Filename : draft-ietf-avtext-rid-06.txt Pages : 9 Date : 2016-07-18 Abstract: This document defines and registers two new RTCP SDES items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream a redundancy RTP stream is to be used to repair. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-rid-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rid-06 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 18 16:36:42 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9825912DB93; Mon, 18 Jul 2016 16:36:37 -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.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160718233637.18059.43874.idtracker@ietfa.amsl.com> Date: Mon, 18 Jul 2016 16:36:37 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-framemarking-02.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 23:36:37 -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 Extensions of the IETF. Title : Frame Marking RTP Header Extension Authors : Espen Berger Suhas Nandakumar Mo Zanaty Filename : draft-ietf-avtext-framemarking-02.txt Pages : 9 Date : 2016-07-18 Abstract: This document describes a Frame Marking RTP header extension used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middleboxes or network nodes. It is most useful when media is encrypted, and essential when the middlebox or node has no access to the media encryption keys. It is also useful for codec-agnostic processing of encrypted or unencrypted media, while it also supports extensions for codec-specific information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-framemarking/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-framemarking-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-framemarking-02 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 Jul 19 07:15:34 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E1C12D9D7; Tue, 19 Jul 2016 07:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 BhL0E5mwZMRz; Tue, 19 Jul 2016 07:15:29 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75DD012D9F2; Tue, 19 Jul 2016 06:33:11 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-de-578e2c154617 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F1.A4.27088.51C2E875; Tue, 19 Jul 2016 15:33:09 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.294.0; Tue, 19 Jul 2016 15:33:08 +0200 To: Adam Roach , "avtext@ietf.org" , "draft-ietf-avtext-rid@ietf.org" References: <7f554d73-47e1-5401-98cd-056268406a2c@ericsson.com> <39d6b6ec-cf78-9074-b700-4da4eb7e08f0@nostrum.com> From: Magnus Westerlund Message-ID: <9a82f380-edec-1d87-5afc-2d2b6f061f5d@ericsson.com> Date: Tue, 19 Jul 2016 15:33:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <39d6b6ec-cf78-9074-b700-4da4eb7e08f0@nostrum.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM2K7n66oTl+4QXenksWev4vYLT7eu8Fq sW/HQzYHZo8lS34yecza+YQlgCmKyyYlNSezLLVI3y6BK+Nj613Wgk6dik9t1xkbGGcpdzFy ckgImEjcer2WFcIWk7hwbz1bFyMXh5DAEUaJ/yfusEA4yxkl+vqeMoFUCQtYSsxseccEkhAR 6AaqunGbHSQhJFAi0TJ7FtgoNgELiZs/GtlAbF4Be4meVS3MIDaLgKrEuSk3gZo5OEQFYiTW 9yVAlAhKnJz5hAUkzAlU/vOwM0iYGWjKzPnnGSFseYnmrbOZITZpSzQ0dbBOYBSYhaR7FpKW WUhaFjAyr2IULU4tTspNNzLSSy3KTC4uzs/Ty0st2cQIDNCDW34b7GB8+dzxEKMAB6MSD6+C ZG+4EGtiWXFl7iFGCQ5mJRHe41p94UK8KYmVValF+fFFpTmpxYcYpTlYlMR5/V8qhgsJpCeW pGanphakFsFkmTg4pRoYN7LdfZC0OOOO/UG11LWP+SbfCTEKmCmV+TnNeLvVy/Mc+ouqT3C3 dy246a3JEbhdfP6elugD+1d+5LLfyDDrNuPkTueHCv9n6Gx2XdRhskuq16frfbDFLHXvcyul 0yYE7fUWmfEz3NFmc9+au5c2eHZNW7gwut1Rw4Lx12F96wDPLRk3dZ/IKrEUZyQaajEXFScC AOQoDwBMAgAA Archived-At: Subject: Re: [avtext] draft-ietf-avtext-rid-05: A couple of issues X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 14:15:33 -0000 Den 2016-07-15 kl. 01:17, skrev Adam Roach: > On 7/12/16 09:29, Magnus Westerlund wrote: >> 1. The definition of the RepairedRtpStreamId in Section 3 is not >> particular clear on the limitations this design have. As the SDES item >> can only contain a single RtpStreamId value the implication is that >> RepairedRtpStreamId can only be used when the redundancy mechanism has >> a one to one relation with a source RTP stream. This can't be used >> with redundancy mechanisms that protects multiple RTP streams. I think >> this could be made clearer in Section 3. > > I'm not sure that's a limitation of the current design -- packet types > are allowed to appear more than once, right? It seems that it would be > reasonable to include more than one RepairedRtpStreamId SDES packet in a > single compound packet, right? I agree that we need to say more about > this, but the limitation you imply is necessary seems artificial. > I agree that this may not be really clear in RFC 3550, but use of multiple SDES items of the same type within a session is likely very error prone. Such usage would require an RTP extension, that is straight forward, but should not be attempted without prior agreement. > I'm adding: "For those schemes in which a redundancy stream contains > information used to repair more than one stream, multiple > RepairedRtpStreamId SDES items may appear in a single compound packet. > Due to the foregoing scoping rules, the RepairedRtpStreamId cannot be > used to indicate streams in multiple sessions or with varying MIDs." > I am really worried about adding this to this document. > >> 2. Section 4.4: >> >> Extension URI: urn:ietf:params:rtp-hdrext:sdes:repair-rtp-sream-id >> >> Why is this URI not "Extension URI: >> urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-sream-id"? > > Jetlag. I've fixed it. > > >> 4. Section 3: >> >> This specification defines two new RTCP SDES items [RFC3550]. The >> first item is 'RtpStreamId', which is used to carry RTP stream >> identifiers within RTCP SDES packets. This makes it possible for a >> receiver to associate received RTP packets (identifying the RTP >> stream) with a media description having the format constraint >> specified. >> >> The definition of the RtpStreamId is missing a discussion of >> requiremetns on the value. >> >> mmusic-rid document in Section 4 is indicating through the following >> line: >> >> A given >> "rid-id" MUST NOT be repeated in a given media description ("m=" >> section). >> >> From my perspective I do wonder if the definition in this document >> needs to makes this clear. And also possibly make it clear that there >> exist no requirement for it be unique across all RTP streams in the >> RTP session, something the name may imply. This clearly also indicates >> that if one have multiple media sources that can use the same >> RtpStreamIds then one needs some additional mechanism to identify >> them. Media sources from different endpoints can be seperated using >> SDES CNAME. > > Yes, a discussion of scoping is certainly called for. I propose: > > RtpStreamId and RepairedRtpStreamId values are scoped by source > identifier > (e.g., CNAME) and by media session. When the media is multiplexed > using the BUNDLE extension {{I-D.ietf-mmusic-sdp-bundle-negotiation}}, > these values are further scoped by their associated MID values. > For example: an RtpStreamId of "1" may be present in the stream > identified with a CNAME of "1234@example.com", and may also be > present in a stream with a CNAME of "5678@example.org", and these > would refer to different streams. Similarly, an RtpStreamId of "1" > may be present with an MID of "A", and again with a MID of "B", > and also refer to two different streams. > Yes, I think this works. My one comment is to call "CNAME" for source identifier. With MID it is clearly the media source, but otherwise CNAME = Canonical End-Point Identifier, so it identifies the endpoint only. When I read it as currently formulated, it reads like Source IDentity = CNAME. That I find problematic. >> 5. Section 3. >> >> I think adding a sentence that SDES items are UTF-8 and have a maximum >> length of 255 Octets, and with a warning that as many symbols encoded >> in UTF-8 have multi-octet representations, the limit to the number of >> symbols that fits may be much lower than 255. > > I would think that "make them as small as possible" and "use this > approach that keeps them one character long" should be sufficient, but > I'll add text just to be triple-sure. > > As with all SDES items, RtpStreamId and RepairedRtpStreamId are limited > to a total of 255 octets in length. Since the values of these items > are encoded with UTF-8, the use of multi-octet characters will result > in limitations smaller than 255 characters. It is in implementations' > interests to keep these values as small as possible in any case, so > this limitation is not expected to have any significant impact. > Yes, works for me. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jul 19 08:21:48 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B99212E059; Tue, 19 Jul 2016 08:21:42 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=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 m66U0PXmJ0Ec; Tue, 19 Jul 2016 08:21:40 -0700 (PDT) Received: from beetle.oak.relay.mailchannels.net (beetle.oak.relay.mailchannels.net [23.83.215.15]) (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 B2EFB12E173; Tue, 19 Jul 2016 08:01:43 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 8DC7C101101; Tue, 19 Jul 2016 15:01:42 +0000 (UTC) Received: from rcentral501.webserversystems.com (ip-10-229-2-62.us-west-2.compute.internal [10.229.2.62]) by relay.mailchannels.net (Postfix) with ESMTPA id 6443710187D; Tue, 19 Jul 2016 15:01:41 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from rcentral501.webserversystems.com ([TEMPUNAVAIL]. [10.132.194.146]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.7.1); Tue, 19 Jul 2016 15:01:42 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1468940501854:2267864172 X-MC-Ingress-Time: 1468940501854 Received: from pool-71-162-135-19.phlapa.fios.verizon.net ([71.162.135.19]:63492 helo=[192.168.1.12]) by rcentral501.webserversystems.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bPWX4-0000TR-VZ; Tue, 19 Jul 2016 11:02:03 -0400 References: <4179289c-9e21-2a36-7a6e-3821131d109b@gmail.com> To: rmcat@ietf.org, avtext@ietf.org From: Randell Jesup Message-ID: Date: Tue, 19 Jul 2016 10:59:07 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------774AE1A03009E75CEBC3D435" X-AuthUser: randell@jesup.org Archived-At: Subject: Re: [avtext] [rmcat] Colin's feedback bandwidth analysis X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 15:21:43 -0000 This is a multi-part message in MIME format. --------------774AE1A03009E75CEBC3D435 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Adding avtext: On 7/19/2016 8:51 AM, Randell Jesup wrote: > Colin - thanks for the analysis! > > Agree with Mo that this implies we're way over the default 5% (which > can be bumped, of course, but knowing how far we need to bump it is > important). > > As for expected rates... I would expect a common range of rates > (especially at the start of a stream) would be 200-500kbps @ 30fps, > extending up to 1-3Mbps @ 30fps. I would expect to see bandwidths > scale down to 40-50Kbps @ 30fps (I've deployed videophones operating > well down to that (QCIF H264)). At the high end, I expect to scale up > to 5+Mbps @ 30 or even 60fps. And there may be use for 60fps down in > the 500Kbps-2Mbps range for some usecases. > > This speaks to: > * improve compression of the feedback data (RLE the loss data (or > huffman encode, etc), and delta-encode the arrival times). I was > pretty sure we'd need to do this, and this confirms it. > ** There's more to win with compressing the arrival times aggressively > * negotiate the needed resolution and reporting intervals with the > sender-side control in some manner. If need be, do it in-band in RTCP. > ** while more painful in implementation, even the resolution/range of > the timestamps could be negotiated > * we should consider if there's a way to compress or omit the repeated > information that's in every report that Colin enumerated > ** list of streams etc rarely changes I'll add: * at lower bandwidths relax the reporting interval to reduce effects of overhead and improve compression of the data, at the cost of less-reactive results in the congestion control ** Implies the need to test the algorithms for sensitivity to less-than-ideal feedback intervals * look at (with some annoying complexity implied) piggybacking this data on RTP packets in header extensions ** shares overhead with reverse-direction RTP (good), may add to delay in receiving them (bad), but given that packets may be queued in both directions, piggybacking may work well in practice at higher framerates. If we need to send feedback and the next anticipated packet going out isn't for a "while", we'd send an RTCP. If we're pacing packets out or likely to send one "soon" relative to the reporting frequency, piggyback it. ** size of the extension might be an issue (packet size limits) ** this definitely adds complexity, but can save a considerable amount of overhead > > The bandwidth implications of this was part of why (for adaptation in > the 30-250Kbps @ 30fps) I used sparse receiver-side congestion control > in the Ojo, reporting only significant changes in derived bandwidth > via RTCP. The challenge here will be to find a way to fit feedback > needed for sender-side congestion control into the available > bandwidth. I'm not concerned with having to increase the 5% default > per se, but I am concerned with how much "goodput" we get in two-way > traffic. I don't want 200Kbps @ 30 spending 50Kbps on feedback.... -- Randell Jesup -- rjesup a t mozilla d o t com Please please please don't email randell-ietf@jesup.org! Way too much spam --------------774AE1A03009E75CEBC3D435 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Adding avtext:

On 7/19/2016 8:51 AM, Randell Jesup wrote:
Colin - thanks for the analysis!

Agree with Mo that this implies we're way over the default 5% (which can be bumped, of course, but knowing how far we need to bump it is important).

As for expected rates... I would expect a common range of rates (especially at the start of a stream) would be 200-500kbps @ 30fps, extending up to 1-3Mbps @ 30fps.=C2=A0 I would expect to see bandwidths scale down to=C2=A0 40-50Kbps @ 30fps (I've deployed videophones operating well down to that (QCIF H264)).=C2=A0 At the = high end, I expect to scale up to 5+Mbps @ 30 or even 60fps.=C2=A0 And t= here may be use for 60fps down in the 500Kbps-2Mbps range for some usecases.

This speaks to:
* improve compression of the feedback data (RLE the loss data (or huffman encode, etc), and delta-encode the arrival times).=C2=A0 I = was pretty sure we'd need to do this, and this confirms it.
** There's more to win with compressing the arrival times aggressively
* negotiate the needed resolution and reporting intervals with the sender-side control in some manner.=C2=A0 If need be, do it in-band= in RTCP.
** while more painful in implementation, even the resolution/range of the timestamps could be negotiated
* we should consider if there's a way to compress or omit the repeated information that's in every report that Colin enumerated ** list of streams etc rarely changes


I'll add:
* at lower bandwidths relax the reporting interval to reduce effects of overhead and improve compression of the data, at the cost of less-reactive results in the congestion control
** Implies the need to test the algorithms for sensitivity to less-than-ideal feedback intervals
* look at (with some annoying complexity implied) piggybacking this data on RTP packets in header extensions
** shares overhead with reverse-direction RTP (good), may add to delay in receiving them (bad), but given that packets may be queued in both directions, piggybacking may work well in practice at higher framerates.=C2=A0 If we need to send feedback and the next anticipate= d packet going out isn't for a "while", we'd send an RTCP.=C2=A0 If we'= re pacing packets out or likely to send one "soon" relative to the reporting frequency, piggyback it.
** size of the extension might be an issue (packet size limits)
** this definitely adds complexity, but can save a considerable amount of overhead


The bandwidth implications of this was part of why (for adaptation in the 30-250Kbps @ 30fps) I used sparse receiver-side congestion control in the Ojo, reporting only significant changes in derived bandwidth via RTCP.=C2=A0 The challenge here will be to find a way = to fit feedback needed for sender-side congestion control into the available bandwidth.=C2=A0 I'm not concerned with having to increas= e the 5% default per se, but I am concerned with how much "goodput" we get in two-way traffic.=C2=A0 I don't want 200Kbps @ 30 spending 50Kbps on feedback....

--=20
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too=
 much spam
--------------774AE1A03009E75CEBC3D435-- From nobody Fri Jul 22 04:20:22 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914D012DBED for ; Fri, 22 Jul 2016 04:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 ktq6RSfagEAD for ; Fri, 22 Jul 2016 04:20:19 -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 B3CC212D14B for ; Fri, 22 Jul 2016 04:20:18 -0700 (PDT) Received: from dhcp-b221.meeting.ietf.org (dhcp-b221.meeting.ietf.org [31.133.178.33]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6MBKG4x031916 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 22 Jul 2016 06:20:18 -0500 (CDT) (envelope-from adam@nostrum.com) To: "avtext@ietf.org" From: Adam Roach Message-ID: Date: Fri, 22 Jul 2016 13:20:15 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [avtext] RtpStreamId value restrictions X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 11:20:20 -0000 During today's MMUSIC face-to-face session, we had a brief discussion about the fact that RtpStreamId values are restricted to be alphanumeric. It was observed that the avtext RID document specifies the character set to be any valid UTF8. The conclusion reached in the room was that these character sets should match each other, and that the more restricted set (alphanumeric) was appropriate. This has impact on the RID draft: specifically, this means we will restrict RtpStreamId and RepairedRtpStreamId will be constrained to be alphanumeric. If anyone objects to this change, please speak up soon. /a From nobody Sun Jul 24 07:17:37 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7A712D526 for ; Sun, 24 Jul 2016 07:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 eQjkzMx5DE3B for ; Sun, 24 Jul 2016 07:17:33 -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 016B912D1A2 for ; Sun, 24 Jul 2016 07:17:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COF73394; Sun, 24 Jul 2016 14:17:30 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sun, 24 Jul 2016 15:17:26 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.179]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Sun, 24 Jul 2016 22:17:21 +0800 From: "Huangyihong (Rachel)" To: "avtext@ietf.org" Thread-Topic: [avtext] WGLC: draft-ietf-avtext-avpf-ccm-layered-01 Thread-Index: AdHlthZ/E9ExfLvAT4e5qHcBOT9VPA== Date: Sun, 24 Jul 2016 14:17:21 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86F111AB@nkgeml513-mbx.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.200.219.199] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB86F111ABnkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5794CDFA.0154, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.179, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c116122090bdd3ca1cf22c18732015a9 Archived-At: Subject: [avtext] WGLC: draft-ietf-avtext-avpf-ccm-layered-01 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 14:17:35 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB86F111ABnkgeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, As we agreed in the meeting, draft-ietf-avtext-avpf-ccm-layered-01 is ready= for WGLC now. Today will begin a two-week WGLC on https://tools.ietf.org/html/draft-ietf-= avtext-avpf-ccm-layered-01. Please have a careful review and raise any issu= es you find, and state your support (or lack thereof) on list. This is impo= rtant to ensure that the document we move on to the IESG has been double-ch= ecked in detail. The WGLC will end on Sunday, August 7, 2016. BR, Rachel --_000_51E6A56BD6A85142B9D172C87FC3ABBB86F111ABnkgeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

As we agreed in the meeting, dr= aft-ietf-avtext-avpf-ccm-layered-01 is ready for WGLC now.

 

Today will begin a two-week = WGLC on https://tools.ietf.org/html/draft-ietf-avtext-avpf-ccm-layered-01. = Please have a careful review and raise any issues you find, and state your = support (or lack thereof) on list. This is important to ensure that the document we move on to the IESG has been d= ouble-checked in detail.

 

The WGLC will end on Sunday,= August 7, 2016.

 

BR,

Rachel

 

--_000_51E6A56BD6A85142B9D172C87FC3ABBB86F111ABnkgeml513mbxchi_-- From nobody Mon Jul 25 14:43:27 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD3512D544; Mon, 25 Jul 2016 14:43:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160725214325.11526.32611.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2016 14:43:25 -0700 Archived-At: Cc: draft-ietf-avtext-splicing-notification@ietf.org, avtext@ietf.org, jonathan@vidyo.com, avtext-chairs@ietf.org Subject: [avtext] Alia Atlas' No Objection on draft-ietf-avtext-splicing-notification-08: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 21:43:25 -0000 Alia Atlas has entered the following ballot position for draft-ietf-avtext-splicing-notification-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to 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-avtext-splicing-notification/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you very much for addressing my discuss. I particularly found Sec 2.1 helped to clarify the architecture. From nobody Tue Jul 26 15:18:25 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0EF12D09A; Tue, 26 Jul 2016 15:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 eZ1jht6wW892; Tue, 26 Jul 2016 15:18:22 -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 00CE012DA33; Tue, 26 Jul 2016 15:18:18 -0700 (PDT) Received: from [10.0.1.14] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6QMIHWo078876 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 26 Jul 2016 17:18:18 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.14] From: "Ben Campbell" To: draft-ietf-avtext-rid.all@ietf.org, avtext@ietf.org Date: Tue, 26 Jul 2016 17:18:17 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: [avtext] AD Evaluation of draft-ietf-avtext-rid-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 22:18:23 -0000 Hi, This is my AD evaluation of draft-ietf-avtext-rid-06. IIUC, the discussion about Magnus's comments is almost but not quite complete. I will hold IETF last call until the shepherd informs me that has been resolved, or that the resolution is unlikely to involve material changes. Otherwise, my comments are pretty minor and can be handled in parallel to the IETF last call. Thanks! Ben. ------------------- Minor Comments: - 4.3, last paragraph (and similar text in other registrations) The first sentence is only guaranteed true if the implementation follows the guidance in 3.3. That says “strongly encouraged”. Maybe it should say something stronger? (Or mention the condition here?) - 6: Did you actually mean to acknowledge a co-author? (Peter) Editorial Comments and Nits: - Please expand first mention of "SDES" in both the abstract and body. - 5, 2nd paragraph: s/ impelementors / implementors ; unless you meant "impalementors". :-) Also, does _this_ document strongly encourage encryption, or is that general encouragement from elsewhere that can be cited? -5, 3rd paragraph: s/exchange/change From nobody Fri Jul 29 13:15:15 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2968E12D144; Fri, 29 Jul 2016 13:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 KR0ZYi5EPWfX; Fri, 29 Jul 2016 13:15:12 -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 D56E612D108; Fri, 29 Jul 2016 13:15:12 -0700 (PDT) Received: from [10.0.1.14] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6TKFBxm082469 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 29 Jul 2016 15:15:12 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.14] From: "Ben Campbell" To: draft-ietf-avtext-rid.all@ietf.org, avtext@ietf.org Date: Fri, 29 Jul 2016 15:15:11 -0500 Message-ID: <61ECAE57-3786-479E-80A3-129DFF65672B@nostrum.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-rid-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 20:15:14 -0000 (This will be a repeat message for several, but I just realized I had not copied the working group.) Based on discussion with Adam, I'm am going to go ahead and request IETF last call for this. I think the open issues are easily enough solved that they can be handled in parallel with the last call. Ben. On 26 Jul 2016, at 17:18, Ben Campbell wrote: > Hi, > > This is my AD evaluation of draft-ietf-avtext-rid-06. IIUC, the > discussion about Magnus's comments is almost but not quite complete. I > will hold IETF last call until the shepherd informs me that has been > resolved, or that the resolution is unlikely to involve material > changes. Otherwise, my comments are pretty minor and can be handled in > parallel to the IETF last call. > > Thanks! > > Ben. > > ------------------- > > Minor Comments: > > - 4.3, last paragraph (and similar text in other registrations) > > The first sentence is only guaranteed true if the implementation > follows the guidance in 3.3. That says “strongly encouraged”. > Maybe it should say something stronger? (Or mention the condition > here?) > > - 6: Did you actually mean to acknowledge a co-author? (Peter) > > > Editorial Comments and Nits: > > - Please expand first mention of "SDES" in both the abstract and body. > > - 5, 2nd paragraph: > s/ impelementors / implementors ; unless you meant "impalementors". > :-) > > Also, does _this_ document strongly encourage encryption, or is that > general encouragement from elsewhere that can be cited? > > -5, 3rd paragraph: > s/exchange/change > > > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Fri Jul 29 13:53:07 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E0412D87E; Fri, 29 Jul 2016 13:52:48 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160729205248.27001.87227.idtracker@ietfa.amsl.com> Date: Fri, 29 Jul 2016 13:52:48 -0700 Archived-At: Cc: draft-ietf-avtext-rid@ietf.org, avtext@ietf.org, avtext-chairs@ietf.org, Jonathan Lennox Subject: [avtext] Last Call: (RTP Stream Identifier Source Description (SDES)) to Proposed Standard X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 20:52:48 -0000 The IESG has received a request from the Audio/Video Transport Extensions WG (avtext) to consider the following document: - 'RTP Stream Identifier Source Description (SDES)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-08-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This document contains a normative reference to RFC 7656, which is an informational RFC. Abstract This document defines and registers two new RTCP SDES items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream a redundancy RTP stream is to be used to repair. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-avtext-rid/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-avtext-rid/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7656: A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources (Informational - IETF stream) Note that some of these references may already be listed in the acceptable Downref Registry. From nobody Fri Jul 29 14:19:38 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14ABE12D565; Fri, 29 Jul 2016 14:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 NsfIujD2X5UT; Fri, 29 Jul 2016 14:19:35 -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 D8FE412D097; Fri, 29 Jul 2016 14:19:35 -0700 (PDT) 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.15.2) with ESMTPSA id u6TLJUOQ089256 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 29 Jul 2016 16:19:31 -0500 (CDT) (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: Magnus Westerlund , "avtext@ietf.org" , "draft-ietf-avtext-rid@ietf.org" References: <7f554d73-47e1-5401-98cd-056268406a2c@ericsson.com> <39d6b6ec-cf78-9074-b700-4da4eb7e08f0@nostrum.com> <9a82f380-edec-1d87-5afc-2d2b6f061f5d@ericsson.com> From: Adam Roach Message-ID: Date: Fri, 29 Jul 2016 16:19:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <9a82f380-edec-1d87-5afc-2d2b6f061f5d@ericsson.com> Content-Type: multipart/alternative; boundary="------------5F6D4A6AF2AEDF6AA17FD825" Archived-At: Subject: Re: [avtext] draft-ietf-avtext-rid-05: A couple of issues X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 21:19:37 -0000 This is a multi-part message in MIME format. --------------5F6D4A6AF2AEDF6AA17FD825 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 7/19/16 08:33, Magnus Westerlund wrote: >> I'm adding: "For those schemes in which a redundancy stream contains >> information used to repair more than one stream, multiple >> RepairedRtpStreamId SDES items may appear in a single compound packet. >> Due to the foregoing scoping rules, the RepairedRtpStreamId cannot be >> used to indicate streams in multiple sessions or with varying MIDs." >> > > I am really worried about adding this to this document. Okay, so let's not support it and simply document that restriction. "Note that the RepairedRtpStreamId mechanism is limited to indicating one repaired stream per redundancy stream. If systems require correlation for schemes in which a redundancy stream contains information used to repair more than one stream, they will have to use a more complex mechanism than the one defined in this specification." /a --------------5F6D4A6AF2AEDF6AA17FD825 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 7/19/16 08:33, Magnus Westerlund wrote:
I'm adding: "For those schemes in which a redundancy stream contains
information used to repair more than one stream, multiple
RepairedRtpStreamId SDES items may appear in a single compound packet.
Due to the foregoing scoping rules, the RepairedRtpStreamId cannot be
used to indicate streams in multiple sessions or with varying MIDs."


I am really worried about adding this to this document.

Okay, so let's not support it and simply document that restriction.

"Note that the RepairedRtpStreamId mechanism is limited to indicating one repaired stream per redundancy stream. If systems require correlation for schemes in which a redundancy stream contains information used to repair more than one stream, they will have to use a more complex mechanism than the one defined in this specification."


/a

--------------5F6D4A6AF2AEDF6AA17FD825-- From nobody Fri Jul 29 23:10:33 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EF612D0F0 for ; Fri, 29 Jul 2016 23:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 rxo_hIWjn3b9 for ; Fri, 29 Jul 2016 23:10:29 -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 2567C12B029 for ; Fri, 29 Jul 2016 23:10:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COO31254; Sat, 30 Jul 2016 06:10:26 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 30 Jul 2016 07:10:25 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.179]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Sat, 30 Jul 2016 14:10:18 +0800 From: "Huangyihong (Rachel)" To: "avtext@ietf.org" Thread-Topic: [avtext] IETF 96 AVTEXT WG session minutes Thread-Index: AdHqKQr+uikEC2ZPQEWb7SnsO6C9yQ== Date: Sat, 30 Jul 2016 06:10:17 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86F19BCC@nkgeml513-mbx.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.136.78.28] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB86F19BCCnkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.579C44D2.00E8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.179, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a3d3bce09f4a2cccf4b3972cb22a7c11 Archived-At: Subject: [avtext] IETF 96 AVTEXT WG session minutes X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 06:10:32 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB86F19BCCnkgeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The initial version of the minutes for the AVTEXT WG meeting in Berlin (IET= F 96) is available now https://www.ietf.org/proceedings/96/minutes/minutes-= 96-avtext. Thanks to Peter and Marc in taking the notes. If there are any c= orrections or discrepancy, please let me know. BR, Rachel --_000_51E6A56BD6A85142B9D172C87FC3ABBB86F19BCCnkgeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The initial version of the minu= tes for the AVTEXT WG meeting in Berlin (IETF 96) is available now h= ttps://www.ietf.org/proceedings/96/minutes/minutes-96-avtext. Thanks to= Peter and Marc in taking the notes. If there are any corrections or discre= pancy, please let me know.

 

BR,

Rachel

 

--_000_51E6A56BD6A85142B9D172C87FC3ABBB86F19BCCnkgeml513mbxchi_--