From nobody Tue Mar 1 14:06:09 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDB11B3C72 for ; Tue, 1 Mar 2016 14:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVVwe3VhYRSx for ; Tue, 1 Mar 2016 14:06:07 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28BDB1B3C01 for ; Tue, 1 Mar 2016 14:06:06 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u21M5m5Y013131 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 Mar 2016 16:05:50 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: Huangyihong Date: Tue, 01 Mar 2016 16:05:48 -0600 Message-ID: In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86E8BBBE@nkgeml513-mbs.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB86E800EB@nkgeml513-mbx.china.huawei.com> <6C5D412D-8627-4017-A39B-C6E14ED0C203@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E840A6@nkgeml513-mbx.china.huawei.com> <858556A2-9151-4818-BDC5-CDF94E2927E4@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E840C4@nkgeml513-mbx.china.huawei.com> <7685C7A0-E5BA-4ED3-BCC9-75818F7354D1@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E840EC@nkgeml513-mbx.china.huawei.com> <65662848-DB29-48EE-8F88-C574B3A692A8@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E8BBBE@nkgeml513-mbs.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5226) Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 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, 01 Mar 2016 22:06:08 -0000 On 29 Feb 2016, at 20:27, Huangyihong (Rachel) wrote: > Hi Ben, > > We author did receive IANA review. But there's no comments in that > review. It was just to confirm the actions that need IANA to complete. > And I think it requires us to respond only when any action they are > going to take is not accurate. That's technically correct, but a confirmation email helps to let them know that you received and understood theirs. > > They also said these actions need to be evaluated by experts reviews > via a separate request. However, we haven't seen any expert review > comments from then on. Maybe they forgot to copy us or maybe there's > no comments at all. We're not sure about it. > They may also not be complete yet. (Hopefully you saw that a late Gen-ART review came out today.( > It's okay for us to bring an update one before the IESG evaluation to > address the further issues you raised before. What do you think? I suggest submitting an update to resolve my comments along with any change that may be needed from the gen-art review. The registration expert reviews may or may not suggest further changes, but we can handle those when they happen. Thanks! Ben. From nobody Tue Mar 1 17:31:20 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DBD1A7007 for ; Tue, 1 Mar 2016 17:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiIz3xuAgY6Q for ; Tue, 1 Mar 2016 17:31:16 -0800 (PST) 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 206E71A033B for ; Tue, 1 Mar 2016 17:31:15 -0800 (PST) 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 CFE96476; Wed, 02 Mar 2016 01:31:13 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 2 Mar 2016 01:31:13 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.35]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0235.001; Wed, 2 Mar 2016 09:31:09 +0800 From: "Huangyihong (Rachel)" To: Ben Campbell Thread-Topic: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-04.txt Thread-Index: AQHRZd0jdgkvVSCpd0uA0RVEQhcYDZ8veK1Q//+frQCAAIc6oP//gvcAgACH2+CAE8JvgIAAh1PwgADHBgCAALR54A== Date: Wed, 2 Mar 2016 01:31:09 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E8C06E@nkgeml513-mbs.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB86E800EB@nkgeml513-mbx.china.huawei.com> <6C5D412D-8627-4017-A39B-C6E14ED0C203@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E840A6@nkgeml513-mbx.china.huawei.com> <858556A2-9151-4818-BDC5-CDF94E2927E4@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E840C4@nkgeml513-mbx.china.huawei.com> <7685C7A0-E5BA-4ED3-BCC9-75818F7354D1@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E840EC@nkgeml513-mbx.china.huawei.com> <65662848-DB29-48EE-8F88-C574B3A692A8@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E8BBBE@nkgeml513-mbs.china.huawei.com> 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.136.79.191] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.56D64262.0027, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.35, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 58c2c95c34f49f92fc4b78b6bc8e30f3 Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 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, 02 Mar 2016 01:31:18 -0000 Hi Ben, Thanks for the suggestion. We'll do it next few days. BR, Rachel > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, March 02, 2016 6:06 AM > To: Huangyihong (Rachel) > Cc: avtext@ietf.org > Subject: Re: [avtext] New Version Notification for > draft-ietf-avtext-splicing-notification-04.txt >=20 > On 29 Feb 2016, at 20:27, Huangyihong (Rachel) wrote: >=20 > > Hi Ben, > > > > We author did receive IANA review. But there's no comments in that > > review. It was just to confirm the actions that need IANA to complete. > > And I think it requires us to respond only when any action they are > > going to take is not accurate. >=20 > That's technically correct, but a confirmation email helps to let them kn= ow that > you received and understood theirs. >=20 > > > > They also said these actions need to be evaluated by experts reviews > > via a separate request. However, we haven't seen any expert review > > comments from then on. Maybe they forgot to copy us or maybe there's > > no comments at all. We're not sure about it. > > >=20 > They may also not be complete yet. (Hopefully you saw that a late Gen-ART > review came out today.( >=20 > > It's okay for us to bring an update one before the IESG evaluation to > > address the further issues you raised before. What do you think? >=20 > I suggest submitting an update to resolve my comments along with any chan= ge > that may be needed from the gen-art review. The registration expert revie= ws > may or may not suggest further changes, but we can handle those when they > happen. >=20 > Thanks! >=20 > Ben. From nobody Wed Mar 2 04:50:38 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0941A00F0; Wed, 2 Mar 2016 04:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2F3vSbet02Kl; Wed, 2 Mar 2016 04:50:34 -0800 (PST) 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 D9BFA1A00FE; Wed, 2 Mar 2016 04:50:26 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-e3-56d6e1906b9b Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 59.D6.20792.091E6D65; Wed, 2 Mar 2016 13:50:25 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.248.2; Wed, 2 Mar 2016 13:50:24 +0100 To: "avtext@ietf.org" , Ben Campbell , From: Magnus Westerlund Message-ID: <56D6E18F.8050603@ericsson.com> Date: Wed, 2 Mar 2016 13:50:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyM2K7k+7Eh9fCDM4uZbL4eO8Gq8X8ztPs FsfPvGN1YPZYsuQnk8esnU9YApiiuGxSUnMyy1KL9O0SuDKavt5iK2g2r5i/WrGBcbF2FyMn h4SAicSrL7/ZIGwxiQv31oPZQgKHGSU2nJDsYuQCspcxSkzY8oQdJCEiUCux8m4PmM0mYCFx 80cjWIOwgIvEhu/rWUBsXgFtiYlb/jKB2CwCKhJvftwAqxcViJE4/u4cI0SNoMTJmU+A6jk4 mAXsJR5sLQMJMwvISzRvnc0McYO2RENTB+sERr5ZSDpmIXTMQtKxgJF5FaNocWpxcW66kZFe alFmcnFxfp5eXmrJJkZgqB3c8ttqB+PB546HGAU4GJV4eD/IXQsTYk0sK67MPcQowcGsJMJr dAcoxJuSWFmVWpQfX1Sak1p8iFGag0VJnJft0+UwIYH0xJLU7NTUgtQimCwTB6dUA2OVg4Nr oEnUzonGXsnfpts/MDl04pj6TuvHOewL3pg/++ykMS35TeVnk37DvK7GLRmzd0t9SQ2U191+ f4meFaP+4Vt2ipfmXzbLfbNv3ZHigERHwT1FM3g/nTge2sVjHSJ+IenLrBrv8zda49j3u5YL rH/WePf8JY4pwQ/ZjJZpednICjxxk1JiKc5INNRiLipOBACAFJk1MQIAAA== Archived-At: Subject: [avtext] Some comments on draft-ietf-avtext-splicing-notification-04 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 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, 02 Mar 2016 12:50:36 -0000 Hi, This are some comments that came out of my review as an IANA expert for the RTP Header Extensions and RTCP Control Packet Types, and which of some is not related to the IANA expert review role. However, I have noted that several of these, issues 1,2,3, and 5, are related to protocol clearness as well as correct usage of RTP which are review criteria for the RTP header extension registry. 1. Section 1.1 and 3.1: What the NTP timestamp included in the extensions represent are not being sufficiently made clear. I think it must be made clear that the NTP timestamp represents the Main RTP senders wall clock timestamp corresponding to these splicing in and out points. The main RTP senders time base may have nothing with any formal time basis distributed by the NTP protocol. 2. Section 3.1: If the 7 octets splicing-out NTP timestamp is smaller than the lower 7 octets splicing-in NTP timestamp, it implies a wrap of the 64-bit splicing-out NTP timestamp which will then be calculated by the 7 octets splicing-out NTP timestamp plus 0x100000000. So I think "smaller" is a underspecified operation here. Although I think loading the 7 octets into one 64 bit unsigned integer respectively and perform a lesser than comparison will actually work. 3. Section 3.1: This section is not clear on what is the data part of the header extension format. As it is not the header extension that can determine if there will be usage of one-byte vs two-byte format that will be used, this needs to be defined in a more un 4. Section 3.2: The RTCP splicing notification message can be appended to RTCP SR the main RTP sender generates in compound RTCP packets, and hence follows the compound RTCP rules defined in Section 6.1 in [RFC3550]. I think the use of "append to RTCP SR" is unfortunate. I believe what would be the right messages is to say that the splicing notification messages is included in the same RTCP compound packet as the RTCP SR for the main RTP stream. Using the SSRC values to relate the two. This is important because there should be no formal requirement on ordering between individual RTCP packets within a compound packet. 5. Section 3.2: This format is similar to the RTCP Sender Report (Section 6.4.1 of [RFC3550]) Why is it only similar and not the same as in RFC 3550? 6. Section 3.2: If the use of non-compound RTCP [RFC5506] was previously negotiated between the sender and the splicer, the RTCP splicing notification message may be sent as non-compound RTCP packets. I wonder over this, I wonder if this RTCP packet type really should be sent in an RTCP non-compound packet without the corresponding RTCP SR packet? The reason I state this is that the RTP main sender has to use SR/RR report block LSR field to determine which is the latest received RTCP SR packet for the SSRC in the splicing RTCP packet. And due to timing of RTCP packet transmission that can be old information. Thus, the splicer can operate on RTP to NTP Timestamps that are not current. Thus, I think it would be a recommendation to include the RTCP SR with the splicing packet. It can still be a non-compound as one could leave out the SDES CNAME items. 7. Section 6.2: Only codecs that are supported both by the main RTP stream and the substitutive RTP stream could be negotiated with SDP O/A. And the splicer MUST choose the same codec for both of these two streams. So this payload type restriction is in my view in the wrong place and not clear enough. So, to be able to splice into one consistent outgoing stream there is a basic requirement that the RTP Payload Types used are having the same clock rate, otherwise RFC 7160 applies, as uncertainty about how RTP maps to NTP and splicing appears to be a bad mix. Further if one is going to express this in this more restrictive way of demanding the same codes, then I do wonder if one actually don't need to go as far as saying that the same payload type configurations needs to be possible to us in both main and substitute streams. 8. Section 7: I find a significant short coming in this security consideration. That is the failure to discuss the importance for the splicer to be able to trust the splicing interval information from the main RTP sender. This information really should be authenticated and integrity protected between the main RTP sender and the splicer. Thus, I am quite worried about this paragraph: Since the mechanism introduced in this document is not dependent on any RTP payload-level hints for finding the splicing in and out points, Secure Real-Time Transport Protocol (SRTP) [3711] can be used to provide confidentiality of the RTP payload while leaving the RTP header in the clear so that the splicer can still carry out splicing without keying materials. However, for a malicious endpoint without the key, it can observe the splicing time in the RTP header, and it can intercept the substitutive content and even replace it with a different one if the substitutive stream does not use any security like SRTP and the splicer does not authenticate the main and substitutive content sources. In the end it hints towards the need for authentication of the streams. But that really should be worded in a stronger way as a requirement for security. I do understand that this is really a case where two layers of security would be good. One between the main and substitute sender and the intended receiver, and an outer layer for sender to splicer. However, I don't argue that such a solution needs to be created. I think having the splicer as a trusted entity is more likely to be a reasonable deployment model. I do note that splicing do have the issue from key-management perspective that both main and substitute sender needs to use the same key if the security is from sender to receiver, rather than splicer to receiver. In the end I think what needs to be changed are: A. Clarify need for source authentication and integrity verification B. The potential issues with having main and substitute stream sender use the same keys end-to-end for the same SSRC. This can be problematic from two-time pad perspective. C. Likely be clear that a security model with a trusted splicer is the one that are easiest to realize without two layer security. 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 Wed Mar 2 09:00:01 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73DA91B2C66; Wed, 2 Mar 2016 09:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyTmLDsstKLL; Wed, 2 Mar 2016 08:59:58 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909511B2C7B; Wed, 2 Mar 2016 08:59:57 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-0d-56d71c0b9651 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 04.7B.15637.B0C17D65; Wed, 2 Mar 2016 17:59:55 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.249]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Wed, 2 Mar 2016 17:59:55 +0100 From: Bo Burman To: Ben Campbell Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-04.txt Thread-Index: AQHRbUwb3uk6Zivzrk2Loi3MEbwNqp83vbfwgAvA2gCAAuzN0A== Date: Wed, 2 Mar 2016 16:59:54 +0000 Message-ID: References: <20160222083618.29656.23198.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7gS63zPUwgynHDS0+3rvBajG/8zS7 xYwpB5gdmD2WLPnJ5DFr5xOWAKYoLpuU1JzMstQifbsEroyXmyeyFvzVrJj3/iRbA+MLhS5G Tg4JAROJpvsrGSFsMYkL99azdTFycQgJHGaUuPl8OhOEs5hR4sz7pSwgVWwCGhLzd9wF6xAR UJJ43ryVBaSIWaCDUeL6w052kISwgLvExx1tTBBFHhJ/elayQdhOElPXzwFrZhFQkXiwYQYz iM0r4Cvxv28KM8S2XYwSTx+fBtvGKWAv8fDnBDCbUUBW4v73e2A2s4C4xK0n85kg7haQWLLn PDOELSrx8vE/VghbUeLjq32MEPU6Egt2f2KDsLUlli18DbVYUOLkzCcsExjFZiEZOwtJyywk LbOQtCxgZFnFKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERhPB7f8Vt3BePmN4yFGAQ5GJR7e D3LXwoRYE8uKK3MPMUpwMCuJ8D6RvB4mxJuSWFmVWpQfX1Sak1p8iFGag0VJnJf10+UwIYH0 xJLU7NTUgtQimCwTB6dUA6PyXoGLEfntn4tavi/ITr97ZkLYtKDL/oUeZa9/u6Q7Cpx17rx6 7WBA4Lmv06Tu1y+e3f3v88ujxX83/VugLF8bvqBEXcfj3H2BG3/rjTlTazrWJcUZuut57bv1 6HLrFN1omfvXu+s/H33zPm7fq6tWPR2qYt8LrGcstv2g59ossv1BztJm0wwlluKMREMt5qLi RAAao+3QowIAAA== Archived-At: Cc: "draft-ietf-avtext-sdes-hdr-ext.all@ietf.org" , "avtext@ietf.org" Subject: Re: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 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, 02 Mar 2016 17:00:00 -0000 Hi, Thank you for the comments. I think they are all good, and I will shortly s= ubmit an updated draft. I chose to make the new sub-registry creation secti= on similar to RFC 5285 section 9.1 that creates the base registry, which I = believe should be clearer than the previous prose text. I checked the current IANA RTP Compact Header Extensions registry for MID (= urn:ietf:params:rtp-hdrext:sdes:mid), and it seems it is no longer present = there, so I removed the text that asks to move it into the new registry. Cheers, /Bo > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: den 29 februari 2016 22:06 > To: Bo Burman > Cc: avtext@ietf.org; draft-ietf-avtext-sdes-hdr-ext.all@ietf.org > Subject: Re: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-04.txt >=20 > Hi, >=20 > I think this version is almost ready to progress, but I do have some mino= r comments about the new IANA section. Since > the IETF last call prompts IANA to start their review and plan their upda= tes, and it might be confusing to have IANA > consideration updates while this is in progress, we probably need to reso= lve this before last call. >=20 > -- 5.1, paragraph 5: >=20 > The text says "IANA is requested to register the below in the RTP Compact= Header Extensions: Extensions, and to create > the corresponding sub-registry:" >=20 > But nothing in the rest of the section appears to describe the creation o= f the sub-registry. Now, I think you've given most > the information needed in 5.0, but that section reads like a summary rath= er than an actual request for action. I propose a > slight rearrangement, along the lines of the following: >=20 > 5.0: Summary > 5.1: registration of the URN. > 5.2: Creation of the sub registry. (The sub-registry probably needs a hum= an-readable name in addition to the URN.) > 5.3: >=20 > -- 5.2, last paragraph >=20 > The RFC editor does not move things in IANA registries. IANA does that. > I suggest the following: > OLD > RFC-editor note: Please move the MID SDES item already registered in > the main registry by [I-D.ietf-mmusic-sdp-bundle-negotiation] to the > newly formed RTP SDES Compact Header Extensions. > NEW > IANA is also requested to move the MID SDES item already registered i= n > the main registry by [I-D.ietf-mmusic-sdp-bundle-negotiation] to the > newly formed RTP SDES Compact Header Extensions. >=20 >=20 >=20 > On 22 Feb 2016, at 2:44, Bo Burman wrote: >=20 > > This update addresses the AD comment on explicitly requesting an IANA > > sub-registry for the urn:ietf:params:rtp-hdrext:sdes sub-space, with > > the additional RTCP SDES concerns described in this draft, compared to > > what is already described for urn:ietf:params:rtp-hdrext. It also > > addresses the AD comment on receiver actions for section 4.2.6, which > > was accidentally omitted from the previous version. > > > > Cheers, > > /Bo > > > >> -----Original Message----- > >> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of > >> internet-drafts@ietf.org > >> Sent: den 22 februari 2016 09:36 > >> To: i-d-announce@ietf.org > >> Cc: avtext@ietf.org > >> Subject: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-04.txt > >> > >> > >> 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 Header Extension for RTCP Source > >> Description Items > >> Authors : Magnus Westerlund > >> Bo Burman > >> Roni Even > >> Mo Zanaty > >> Filename : draft-ietf-avtext-sdes-hdr-ext-04.txt > >> Pages : 15 > >> Date : 2016-02-22 > >> > >> Abstract: > >> Source Description (SDES) items are normally transported in RTP > >> control protocol (RTCP). In some cases it can be beneficial to > >> speed > >> up the delivery of these items. Mainly when a new source (SSRC) > >> joins an RTP session and the receivers needs this source's > >> identity, > >> relation to other sources, or its synchronization context, all of > >> which may be fully or partially identified using SDES items. To > >> enable this optimization, this document specifies a new RTP header > >> extension that can carry SDES items. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ > >> > >> There's also a htmlized version available at: > >> https://tools.ietf.org/html/draft-ietf-avtext-sdes-hdr-ext-04 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-sdes-hdr-ext-04 > >> > >> > >> 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/ > >> > >> _______________________________________________ > >> avtext mailing list > >> avtext@ietf.org > >> https://www.ietf.org/mailman/listinfo/avtext From nobody Wed Mar 2 09:02:29 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 093C91B2CA0; Wed, 2 Mar 2016 09:02:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160302170215.2701.19383.idtracker@ietfa.amsl.com> Date: Wed, 02 Mar 2016 09:02:15 -0800 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-05.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 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, 02 Mar 2016 17:02:16 -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 Header Extension for RTCP Source Description Items Authors : Magnus Westerlund Bo Burman Roni Even Mo Zanaty Filename : draft-ietf-avtext-sdes-hdr-ext-05.txt Pages : 15 Date : 2016-03-02 Abstract: Source Description (SDES) items are normally transported in RTP control protocol (RTCP). In some cases it can be beneficial to speed up the delivery of these items. Mainly when a new source (SSRC) joins an RTP session and the receivers needs this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items. To enable this optimization, this document specifies a new RTP header extension that can carry SDES items. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-sdes-hdr-ext-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-sdes-hdr-ext-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 Thu Mar 3 02:51:28 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB46E1A8952; Thu, 3 Mar 2016 02:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OV3483caUnol; Thu, 3 Mar 2016 02:51:24 -0800 (PST) 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 494201A894B; Thu, 3 Mar 2016 02:51:23 -0800 (PST) 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 CFH14104; Thu, 03 Mar 2016 10:51:19 +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; Thu, 3 Mar 2016 10:51:18 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.35]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Thu, 3 Mar 2016 18:51:11 +0800 From: "Huangyihong (Rachel)" To: Magnus Westerlund , "avtext@ietf.org" , Ben Campbell , "draft-ietf-avtext-splicing-notification@ietf.org" Thread-Topic: Some comments on draft-ietf-avtext-splicing-notification-04 Thread-Index: AQHRdIIhWfIN9oQkKEK98MCsQzahTp9G/RLg Date: Thu, 3 Mar 2016 10:51:10 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E8C95B@nkgeml513-mbs.china.huawei.com> References: <56D6E18F.8050603@ericsson.com> In-Reply-To: <56D6E18F.8050603@ericsson.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.191] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0202.56D81729.005F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.35, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 856ef3418857282536b627697e8f6288 Archived-At: Subject: Re: [avtext] Some comments on draft-ietf-avtext-splicing-notification-04 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 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, 03 Mar 2016 10:51:28 -0000 Hi Magnus, Thank you so much for your careful review and valuable comments. It helps u= s to further improve the document quality. Please see my replies inline. BR, Rachel > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, March 02, 2016 8:50 PM > To: avtext@ietf.org; Ben Campbell; > draft-ietf-avtext-splicing-notification@ietf.org > Subject: Some comments on draft-ietf-avtext-splicing-notification-04 >=20 > Hi, >=20 > This are some comments that came out of my review as an IANA expert for t= he > RTP Header Extensions and RTCP Control Packet Types, and which of some is > not related to the IANA expert review role. However, I have noted that se= veral > of these, issues 1,2,3, and 5, are related to protocol clearness as well = as > correct usage of RTP which are review criteria for the RTP header extensi= on > registry. >=20 >=20 > 1. Section 1.1 and 3.1: >=20 > What the NTP timestamp included in the extensions represent are not being > sufficiently made clear. I think it must be made clear that the NTP times= tamp > represents the Main RTP senders wall clock timestamp corresponding to the= se > splicing in and out points. The main RTP senders time base may have nothi= ng > with any formal time basis distributed by the NTP protocol. [Rachel]: You're right. So how about changing the "splicing interval" in se= ction 1.1 to the following: " Splicing Interval: The NTP-format timestamps, representing the main RTP sender wallclock time,= for the Splicing-In point and Splicing-Out point per [RFC6828] allowing th= e splicer to know when to start and end the RTP splicing. " As for the ones in section 3.1, is it okay to just keep the "NTP-format tim= estamps", since we clarify it in the terminology? >=20 > 2. Section 3.1: >=20 > If the 7 octets splicing-out NTP timestamp is smaller > than the lower 7 octets splicing-in NTP timestamp, it implies a wrap > of the 64-bit splicing-out NTP timestamp which will then be > calculated by the 7 octets splicing-out NTP timestamp plus > 0x100000000. >=20 > So I think "smaller" is a underspecified operation here. Although I think= loading > the 7 octets into one 64 bit unsigned integer respectively and perform a = lesser > than comparison will actually work. [Rachel]: So how about expressing it like this OLD " The top 8 bits of the splicing-out NTP timestamp are inferred from the top = 8 bits of the splicing-in NTP timestamp. This is unambiguous, under the ass= umption that the splicing-out time is after the splicing-in time, and the s= plicing interval is less than 2^25 seconds. If the 7 octets splicing-out NT= P timestamp is smaller than the lower 7 octets splicing-in NTP timestamp, i= t implies a wrap of the 64-bit splicing-out NTP timestamp which will then b= e calculated by the 7 octets splicing-out NTP timestamp plus 0x100000000. O= therwise, the top 8 octets of splicing-out NTP timestamp is equal to the to= p 8 octets of splicing-in NTP timestamp. " NEW " The top 8 bits of the splicing-out NTP timestamp are inferred from the top = 8 bits of the splicing-in NTP timestamp. This is unambiguous, under the ass= umption that the splicing-out time is after the splicing-in time, and the s= plicing interval is less than 2^25 seconds. Therefore, if the 7 octets spli= cing-out NTP-format timestamp is smaller than 64-bit splicing-out NTP-forma= t timestamp modulo 56 bits range, it implies a wrap of the 64-bit splicing-= out NTP-format timestamp which will then be calculated by the 7 octets spli= cing-out NTP timestamp plus 2^64. Otherwise, the top 8 octets of splicing-o= ut NTP timestamp is equal to the top 8 octets of splicing-in NTP timestamp. " >=20 > 3. Section 3.1: >=20 > This section is not clear on what is the data part of the header extensio= n > format. As it is not the header extension that can determine if there wil= l be > usage of one-byte vs two-byte format that will be used, this needs to be > defined in a more un [Rachel]: I don't understand this. The editing seems unfinished. The splici= ng RTP header extension uses one-byte format with the fixed bit pattern 0xB= EDE. >=20 > 4. Section 3.2: > The RTCP splicing notification message can be appended to RTCP SR the > main RTP sender generates in compound RTCP packets, and hence follows > the compound RTCP rules defined in Section 6.1 in [RFC3550]. >=20 > I think the use of "append to RTCP SR" is unfortunate. I believe what wou= ld be > the right messages is to say that the splicing notification messages is i= ncluded > in the same RTCP compound packet as the RTCP SR for the main RTP stream. > Using the SSRC values to relate the two. This is important because there = should > be no formal requirement on ordering between individual RTCP packets with= in > a compound packet. [Rachel]: Good point. How about changing to=20 " The RTCP splicing notification message can be included in the RTCP compound= packet together with RTCP SR generated at the main RTP sender, and hence f= ollows the compound RTCP rules defined in Section 6.1 in [RFC3550]. " >=20 >=20 > 5. Section 3.2: >=20 > This format is > similar to the RTCP Sender Report (Section 6.4.1 of [RFC3550]) >=20 > Why is it only similar and not the same as in RFC 3550? >=20 [Rachel]: Actually it's the same. Bad wording:(. >=20 > 6. Section 3.2: >=20 > If the use of non-compound RTCP [RFC5506] was previously negotiated > between the sender and the splicer, the RTCP splicing notification > message may be sent as non-compound RTCP packets. >=20 > I wonder over this, I wonder if this RTCP packet type really should be se= nt in an > RTCP non-compound packet without the corresponding RTCP SR packet? The > reason I state this is that the RTP main sender has to use SR/RR report b= lock > LSR field to determine which is the latest received RTCP SR packet for th= e SSRC > in the splicing RTCP packet. And due to timing of RTCP packet transmissio= n that > can be old information. Thus, the splicer can operate on RTP to NTP > Timestamps that are not current. > Thus, I think it would be a recommendation to include the RTCP SR with th= e > splicing packet. It can still be a non-compound as one could leave out th= e SDES > CNAME items. [Rachel]: Maybe I got it wrong. But are you saying that the accuracy of map= ping RTP timestamp to NTP timestamp, which should be deduced by the informa= tion in the RTCP SR that should be as close as the splicing starts? But the= RTCP splicing message is sent far ahead of the splicing happens, and shoul= d be sent more than once to increase robustness. For example, may be severa= l RTTs ahead. So in a non-compound case, it is possible that a RTCP SR will= be sent after a RTCP splicing message, hence it seems no meaning to includ= e RTCP SR with RTCP splicing messages.=20 >=20 > 7. Section 6.2: >=20 > Only codecs that are supported both by the main RTP stream and the > substitutive RTP stream could be negotiated with SDP O/A. And the > splicer MUST choose the same codec for both of these two streams. >=20 > So this payload type restriction is in my view in the wrong place and not= clear > enough. So, to be able to splice into one consistent outgoing stream ther= e is a > basic requirement that the RTP Payload Types used are having the same clo= ck > rate, otherwise RFC 7160 applies, as uncertainty about how RTP maps to NT= P > and splicing appears to be a bad mix. [Rachel]: Actually, this has been described in Section 2, 3rd paragraph. It= says " To ensure the Splicing Interval is valid for both the main RTP sender and t= he substitutive RTP sender, the two senders MUST share a common reference c= lock so that the splicer can achieve accurate splicing. The requirements fo= r the common reference clock (e.g. resolution, skew) depend on the codec us= ed by the media content. " >=20 > Further if one is going to express this in this more restrictive way of d= emanding > the same codes, then I do wonder if one actually don't need to go as far = as > saying that the same payload type configurations needs to be possible to = us in > both main and substitute streams. [Rachel]: So you're suggesting that we delete this sentence? >=20 > 8. Section 7: >=20 > I find a significant short coming in this security consideration. That is= the failure > to discuss the importance for the splicer to be able to trust the splicin= g interval > information from the main RTP sender. This information really should be > authenticated and integrity protected between the main RTP sender and the > splicer. >=20 > Thus, I am quite worried about this paragraph: >=20 > Since the mechanism introduced in this document is not dependent on > any RTP payload-level hints for finding the splicing in and out > points, Secure Real-Time Transport Protocol (SRTP) [3711] can be used > to provide confidentiality of the RTP payload while leaving the RTP > header in the clear so that the splicer can still carry out splicing > without keying materials. However, for a malicious endpoint without > the key, it can observe the splicing time in the RTP header, and it > can intercept the substitutive content and even replace it with a > different one if the substitutive stream does not use any security > like SRTP and the splicer does not authenticate the main and > substitutive content sources. >=20 > In the end it hints towards the need for authentication of the streams. > But that really should be worded in a stronger way as a requirement for > security. >=20 > I do understand that this is really a case where two layers of security w= ould be > good. One between the main and substitute sender and the intended receive= r, > and an outer layer for sender to splicer. However, I don't argue that suc= h a > solution needs to be created. I think having the splicer as a trusted ent= ity is > more likely to be a reasonable deployment model. [Rachel]: Okay. How about Add a new paragraph after the 3rd paragraph in Se= ction 7? " To avoid above security issue, the authentication of the main and substitut= ive content sources in the splicer SHOULD be considered. However, separatin= g the security mechanism between senders and the splicer from the end-to-en= d one may complicate the whole system deployment. In such a case, having th= e splicer as a trusted entity is likely to be a reasonable deployment model= . " >=20 > I do note that splicing do have the issue from key-management perspective > that both main and substitute sender needs to use the same key if the sec= urity > is from sender to receiver, rather than splicer to receiver. [Rachel]: Yes. I plan to add a sentence in the paragraph 3 like this: OLD " Since the mechanism introduced in this document is not dependent on any RTP= payload-level hints for finding the splicing in and out points, Secure Rea= l-Time Transport Protocol (SRTP) [RFC3711] can be used to provide confident= iality of the RTP payload while leaving the RTP header in the clear so that= the splicer can still carry out splicing without keying materials. "=20 NEW " Since the mechanism introduced in this document is not dependent on any RTP= payload-level hints for finding the splicing in and out points, Secure Rea= l-Time Transport Protocol (SRTP) [RFC3711] can be used to provide confident= iality of the RTP payload while leaving the RTP header in the clear so that= the splicer can still carry out splicing without keying materials. This im= plies that either the main and substitutive sender use the same SRTP key, o= r the splicer decrypts and re-encrypts with a single key. " >=20 > In the end I think what needs to be changed are: >=20 > A. Clarify need for source authentication and integrity verification B. T= he > potential issues with having main and substitute stream sender use the sa= me > keys end-to-end for the same SSRC. This can be problematic from two-time = pad > perspective. > C. Likely be clear that a security model with a trusted splicer is the on= e that are > easiest to realize without two layer security. [Rachel]: See above proposed modifications. >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From nobody Thu Mar 3 14:00:38 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 BB1581B2CC6; Thu, 3 Mar 2016 14:00:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160303220035.21682.48241.idtracker@ietfa.amsl.com> Date: Thu, 03 Mar 2016 14:00:35 -0800 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rid-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 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, 03 Mar 2016 22:00:36 -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 (RID) Source Description (SDES) Authors : Adam Roach Suhas Nandakumar Peter Thatcher Filename : draft-ietf-avtext-rid-01.txt Pages : 7 Date : 2016-03-03 Abstract: This document defines and registers an RTCP SDES item, RID, for identification of RTP streams associated with Encoded Streams and Dependent Streams. 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-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rid-01 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 Thu Mar 3 14:03:07 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74301B2CE0; Thu, 3 Mar 2016 14:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4zzuYstYmdY; Thu, 3 Mar 2016 14:03:05 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B12A1B2CDE; Thu, 3 Mar 2016 14:03:05 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u23M34ap033216 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 3 Mar 2016 16:03:04 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: internet-drafts@ietf.org, i-d-announce@ietf.org References: <20160303220035.21682.48241.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <56D8B497.1000200@nostrum.com> Date: Thu, 3 Mar 2016 16:03:03 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160303220035.21682.48241.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: avtext@ietf.org Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rid-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 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, 03 Mar 2016 22:03:06 -0000 As Peter, Colin, and I discussed on-list, this version of RID proposes a second identifier, RRID, that is suitable for unique identification of Redundancy RTP Streams, should that become necessary for some application in the future. The only other changes are editorial. Please review the diffs (linked below) and comment. Thanks! /a On 3/3/16 16:00, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Extensions of the IETF. > > Title : RTP Stream Identifier (RID) Source Description (SDES) > Authors : Adam Roach > Suhas Nandakumar > Peter Thatcher > Filename : draft-ietf-avtext-rid-01.txt > Pages : 7 > Date : 2016-03-03 > > Abstract: > This document defines and registers an RTCP SDES item, RID, for > identification of RTP streams associated with Encoded Streams and > Dependent Streams. > > > 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-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rid-01 > > > 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/ > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Fri Mar 4 14:25:28 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188311A9128; Fri, 4 Mar 2016 14:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QePOnNW1kqoy; Fri, 4 Mar 2016 14:25:17 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3027C1A9101; Fri, 4 Mar 2016 14:25:17 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u24MPCnn018355 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 4 Mar 2016 16:25:12 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Bo Burman" Date: Fri, 04 Mar 2016 16:25:11 -0600 Message-ID: <9BB5E987-75E9-4CEC-8428-7CE97458C75D@nostrum.com> In-Reply-To: References: <20160222083618.29656.23198.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5226) Archived-At: Cc: "draft-ietf-avtext-sdes-hdr-ext.all@ietf.org" , "avtext@ietf.org" Subject: Re: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 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, 04 Mar 2016 22:25:20 -0000 Thanks! I have requested IETF Last Call for version 05. Ben. On 2 Mar 2016, at 10:59, Bo Burman wrote: > Hi, > > Thank you for the comments. I think they are all good, and I will > shortly submit an updated draft. I chose to make the new sub-registry > creation section similar to RFC 5285 section 9.1 that creates the base > registry, which I believe should be clearer than the previous prose > text. > > I checked the current IANA RTP Compact Header Extensions registry for > MID (urn:ietf:params:rtp-hdrext:sdes:mid), and it seems it is no > longer present there, so I removed the text that asks to move it into > the new registry. > > Cheers, > /Bo > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: den 29 februari 2016 22:06 >> To: Bo Burman >> Cc: avtext@ietf.org; draft-ietf-avtext-sdes-hdr-ext.all@ietf.org >> Subject: Re: [avtext] I-D Action: >> draft-ietf-avtext-sdes-hdr-ext-04.txt >> >> Hi, >> >> I think this version is almost ready to progress, but I do have some >> minor comments about the new IANA section. Since >> the IETF last call prompts IANA to start their review and plan their >> updates, and it might be confusing to have IANA >> consideration updates while this is in progress, we probably need to >> resolve this before last call. >> >> -- 5.1, paragraph 5: >> >> The text says "IANA is requested to register the below in the RTP >> Compact Header Extensions: Extensions, and to create >> the corresponding sub-registry:" >> >> But nothing in the rest of the section appears to describe the >> creation of the sub-registry. Now, I think you've given most >> the information needed in 5.0, but that section reads like a summary >> rather than an actual request for action. I propose a >> slight rearrangement, along the lines of the following: >> >> 5.0: Summary >> 5.1: registration of the URN. >> 5.2: Creation of the sub registry. (The sub-registry probably needs a >> human-readable name in addition to the URN.) >> 5.3: >> >> -- 5.2, last paragraph >> >> The RFC editor does not move things in IANA registries. IANA does >> that. >> I suggest the following: >> OLD >> RFC-editor note: Please move the MID SDES item already registered >> in >> the main registry by [I-D.ietf-mmusic-sdp-bundle-negotiation] to >> the >> newly formed RTP SDES Compact Header Extensions. >> NEW >> IANA is also requested to move the MID SDES item already >> registered in >> the main registry by [I-D.ietf-mmusic-sdp-bundle-negotiation] to >> the >> newly formed RTP SDES Compact Header Extensions. >> >> >> >> On 22 Feb 2016, at 2:44, Bo Burman wrote: >> >>> This update addresses the AD comment on explicitly requesting an >>> IANA >>> sub-registry for the urn:ietf:params:rtp-hdrext:sdes sub-space, with >>> the additional RTCP SDES concerns described in this draft, compared >>> to >>> what is already described for urn:ietf:params:rtp-hdrext. It also >>> addresses the AD comment on receiver actions for section 4.2.6, >>> which >>> was accidentally omitted from the previous version. >>> >>> Cheers, >>> /Bo >>> >>>> -----Original Message----- >>>> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of >>>> internet-drafts@ietf.org >>>> Sent: den 22 februari 2016 09:36 >>>> To: i-d-announce@ietf.org >>>> Cc: avtext@ietf.org >>>> Subject: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-04.txt >>>> >>>> >>>> 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 Header Extension for RTCP Source >>>> Description Items >>>> Authors : Magnus Westerlund >>>> Bo Burman >>>> Roni Even >>>> Mo Zanaty >>>> Filename : draft-ietf-avtext-sdes-hdr-ext-04.txt >>>> Pages : 15 >>>> Date : 2016-02-22 >>>> >>>> Abstract: >>>> Source Description (SDES) items are normally transported in RTP >>>> control protocol (RTCP). In some cases it can be beneficial to >>>> speed >>>> up the delivery of these items. Mainly when a new source (SSRC) >>>> joins an RTP session and the receivers needs this source's >>>> identity, >>>> relation to other sources, or its synchronization context, all >>>> of >>>> which may be fully or partially identified using SDES items. To >>>> enable this optimization, this document specifies a new RTP >>>> header >>>> extension that can carry SDES items. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ >>>> >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-avtext-sdes-hdr-ext-04 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-sdes-hdr-ext-04 >>>> >>>> >>>> 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/ >>>> >>>> _______________________________________________ >>>> avtext mailing list >>>> avtext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/avtext From nobody Fri Mar 4 14:57:38 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 30F431A92EF; Fri, 4 Mar 2016 14:57:33 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160304225733.3181.410.idtracker@ietfa.amsl.com> Date: Fri, 04 Mar 2016 14:57:33 -0800 Archived-At: Cc: draft-ietf-avtext-sdes-hdr-ext@ietf.org, avtext@ietf.org, avtext-chairs@ietf.org, Jonathan Lennox Subject: [avtext] Last Call: (RTP Header Extension for RTCP Source Description Items) to Proposed Standard X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 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, 04 Mar 2016 22:57:33 -0000 The IESG has received a request from the Audio/Video Transport Extensions WG (avtext) to consider the following document: - 'RTP Header Extension for RTCP Source Description Items' 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-03-18. 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. Abstract Source Description (SDES) items are normally transported in RTP control protocol (RTCP). In some cases it can be beneficial to speed up the delivery of these items. Mainly when a new source (SSRC) joins an RTP session and the receivers needs this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items. To enable this optimization, this document specifies a new RTP header extension that can carry SDES items. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sun Mar 6 04:14:24 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7961B2C22 for ; Sun, 6 Mar 2016 04:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 quQAAfR0XDjc for ; Sun, 6 Mar 2016 04:14:22 -0800 (PST) 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 DF9FB1B2C0A for ; Sun, 6 Mar 2016 04:14:21 -0800 (PST) Received: from [81.187.2.149] (port=49081 helo=[192.168.0.86]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1acXZj-0000oC-CL; Sun, 06 Mar 2016 12:14:20 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: <0404D543-8DE1-4017-8BA1-364C837D2C5C@vidyo.com> Date: Sun, 6 Mar 2016 12:14:14 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160303220035.21682.48241.idtracker@ietfa.amsl.com> <56D8B497.1000200@nostrum.com> <0404D543-8DE1-4017-8BA1-364C837D2C5C@vidyo.com> To: Jonathan Lennox X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: avtext@ietf.org Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rid-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 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, 06 Mar 2016 12:14:23 -0000 Hi Jonathan, This is not my preferred solution, but I don=E2=80=99t object to it = going to WG last call. Colin > On 4 Mar 2016, at 22:47, Jonathan Lennox wrote: >=20 > Colin - can you send a note to the list as to whether this satisfies = your comments on -00? Yours are the only outstanding comments, so if so = I=E2=80=99ll probably go ahead and issue a WGLC. >=20 >> On Mar 3, 2016, at 5:03 PM, Adam Roach wrote: >>=20 >> As Peter, Colin, and I discussed on-list, this version of RID = proposes a second identifier, RRID, that is suitable for unique = identification of Redundancy RTP Streams, should that become necessary = for some application in the future. The only other changes are = editorial. Please review the diffs (linked below) and comment. >>=20 >> Thanks! >>=20 >> /a >>=20 >> On 3/3/16 16:00, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Audio/Video Transport Extensions of = the IETF. >>>=20 >>> Title : RTP Stream Identifier (RID) Source = Description (SDES) >>> Authors : Adam Roach >>> Suhas Nandakumar >>> Peter Thatcher >>> Filename : draft-ietf-avtext-rid-01.txt >>> Pages : 7 >>> Date : 2016-03-03 >>>=20 >>> Abstract: >>> This document defines and registers an RTCP SDES item, RID, for >>> identification of RTP streams associated with Encoded Streams and >>> Dependent Streams. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-avtext-rid/ >>>=20 >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-avtext-rid-01 >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rid-01 >>>=20 >>>=20 >>> 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. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> avtext mailing list >>> avtext@ietf.org >>> https://www.ietf.org/mailman/listinfo/avtext >>=20 >> _______________________________________________ >> avtext mailing list >> avtext@ietf.org >> https://www.ietf.org/mailman/listinfo/avtext >>=20 >=20 --=20 Colin Perkins https://csperkins.org/ From nobody Mon Mar 7 08:02:49 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C589E1B4354 for ; Mon, 7 Mar 2016 08:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.402 X-Spam-Level: X-Spam-Status: No, score=0.402 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 FDxYOhEGMYJV for ; Mon, 7 Mar 2016 08:02:43 -0800 (PST) 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 8F3971B4352 for ; Mon, 7 Mar 2016 08:02:42 -0800 (PST) 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 u27G0HAD025892 for ; Mon, 7 Mar 2016 11:02:37 -0500 Received: from mail.vidyo.com (mail2.vidyo.com [162.209.16.213] (may be forged)) by mx0b-00198e01.pphosted.com with ESMTP id 21fsy417ff-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 07 Mar 2016 11:02:37 -0500 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Mon, 7 Mar 2016 10:02:35 -0600 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: AVTExt: Call for agenda items Thread-Index: AQHReIrDPdCXjJxZnkqm0LJuCupiBA== Date: Mon, 7 Mar 2016 16:02:34 +0000 Message-ID: <430C1C07-A461-41CB-816D-D2DC59B931E5@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: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.38, 0.0.0000 definitions=2016-03-07_09:2016-03-07,2016-03-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-1601100000 definitions=main-1603070293 Archived-At: Subject: [avtext] AVTExt: Call for agenda items X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 07 Mar 2016 16:02:48 -0000 SGVsbG8sIGFsbCDigJQNCg0KVGhlIHByZWxpbWluYXJ5IGFnZW5kYSBmb3IgSUVURiA5NSBpbiBC dWVub3MgQWlyZXMgaGFzIHRoZSBBVlRFeHQgd29ya2luZyBncm91cCBzY2hlZHVsZWQgdG8gbWVl dCBmcm9tIDE2OjIwIHRvIDE4OjIwLCBCdWVub3MgQWlyZXMgdGltZSAoVVRDLTM6MDApIG9uIFRo dXJzZGF5LCBBcHJpbCA3LCAyMDE2Lg0KDQpQbGVhc2Ugc2VuZCBSYWNoZWwgYW5kIG1lIGFueSBw cm9wb3NhbHMgYW5kIHJlcXVlc3RzIGZvciBhZ2VuZGEgdGltZS4NCg0KKFBsZWFzZSBsZXQgdXMg a25vdyBldmVuIGlmIHlvdSBtYXkgb25seSBwb3RlbnRpYWxseSBuZWVkIHRpbWU7IGl0ZW1zIGNh biBhbHdheXMgYmUgZHJvcHBlZCBmcm9tIHRoZSBhZ2VuZGEgaWYgdGhleSB0dXJuIG91dCBub3Qg dG8gbmVlZCBkaXNjdXNzaW9uLikNCg0KVGhhbmsgeW91IQ0KDQpKb25hdGhhbg0KDQo= From nobody Tue Mar 8 12:49: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 9546812D57A for ; Tue, 8 Mar 2016 12:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwIBig4JrKFt for ; Tue, 8 Mar 2016 12:49:05 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F58212D551 for ; Tue, 8 Mar 2016 12:49:05 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u28KmxHp047141 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 8 Mar 2016 14:49:00 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Colin Perkins , Jonathan Lennox References: <20160303220035.21682.48241.idtracker@ietfa.amsl.com> <56D8B497.1000200@nostrum.com> <0404D543-8DE1-4017-8BA1-364C837D2C5C@vidyo.com> From: Adam Roach Message-ID: <56DF3ABB.2080700@nostrum.com> Date: Tue, 8 Mar 2016 14:48:59 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: avtext@ietf.org Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rid-01.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: Tue, 08 Mar 2016 20:49:06 -0000 On 3/6/16 06:14, Colin Perkins wrote: > This is not my preferred solution Can you expand on that? The most recent version introduces two SDES items to allow unique identification of redundancy streams, which is an approach you described as "reasonable" back on February 17th. Basically: the last round of edits were performed exclusively to address your concerns. If you think they don't, I'd like to either fix them or pull them out. Making the mechanism more complicated while also leaving you unsatisfied is a lose/lose situation. /a From nobody Tue Mar 8 13:44:27 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 BEF1012DB17 for ; Tue, 8 Mar 2016 13:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id betag85BRs0P for ; Tue, 8 Mar 2016 13:44:23 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E530312D628 for ; Tue, 8 Mar 2016 13:44:22 -0800 (PST) Received: from [82.132.219.99] (port=61953 helo=[172.20.10.2]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1adPQP-0006u9-HR; Tue, 08 Mar 2016 21:44:19 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: <56DF3ABB.2080700@nostrum.com> Date: Tue, 8 Mar 2016 21:43:35 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3F20A04C-87B0-43EF-A7EE-7943EAD916DB@csperkins.org> References: <20160303220035.21682.48241.idtracker@ietfa.amsl.com> <56D8B497.1000200@nostrum.com> <0404D543-8DE1-4017-8BA1-364C837D2C5C@vidyo.com> <56DF3ABB.2080700@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: Jonathan Lennox , avtext@ietf.org Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rid-01.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: Tue, 08 Mar 2016 21:44:26 -0000 > On 8 Mar 2016, at 20:48, Adam Roach wrote: >=20 > On 3/6/16 06:14, Colin Perkins wrote: >> This is not my preferred solution >=20 > Can you expand on that? >=20 > The most recent version introduces two SDES items to allow unique = identification of redundancy streams, which is an approach you described = as "reasonable=E2=80=9D back on February 17th. It=E2=80=99s a reasonable compromise, and I don=E2=80=99t object to the = new approach, but I also don=E2=80=99t see any great benefit to the = change.=20 > Basically: the last round of edits were performed exclusively to = address your concerns. If you think they don't, I'd like to either fix = them or pull them out. Making the mechanism more complicated while also = leaving you unsatisfied is a lose/lose situation. The introduction to the previous draft noted that none of the previous = attempts to address this problem =E2=80=9Chave the proper ordinality to = refer to an individual stream; all such identifiers can appear in more = than one stream at a time=E2=80=9D, then defined a new identifier that = can appear in more than one stream at a time. That is, it looked like = the draft was aiming to solve the general problem, but it actually = defined something much more narrow.=20 If you just want to solve the current narrowly defined problem, the = approach taken in the previous draft makes more sense than the approach = in the new draft (but the text suggesting it=E2=80=99s addressing the = more general problem needs to be removed). If you want to solve the general problem, then the new draft is a step = in the right direction. It still retains some application specific = semantics around redundancy, that I think will be problematic in future, = though. Accordingly, I=E2=80=99m not sure the new draft goes far enough = to be the general solution. --=20 Colin Perkins https://csperkins.org/ From nobody Fri Mar 11 15:05:51 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 E248F12DDAB; Fri, 11 Mar 2016 15:05:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230524.15028.65382.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:24 -0800 Archived-At: Cc: avtext@ietf.org Subject: [avtext] avtext - Requested session has been scheduled for IETF 95 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, 11 Mar 2016 23:05:28 -0000 Dear Rachel Huang, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. avtext Session 1 (2:00:00) Thursday, Afternoon Session III 1730-1930 Room Name: Buen Ayre A size: 125 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Audio/Video Transport Extensions Area Name: Applications and Real-Time Area Session Requester: Rachel Huang Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 70 Conflicts to Avoid: First Priority: avtcore payload xrblock mmusic perc rmcat dispatch netvc clue Second Priority: tsvwg sipcore lmap tram apparea Special Requests: --------------------------------------------------------- From nobody Fri Mar 18 05:41:02 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 5853112D859; Fri, 18 Mar 2016 05:41:01 -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 yVrIsl5M_B-k; Fri, 18 Mar 2016 05:40:58 -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 246AC12D8D7; Fri, 18 Mar 2016 05:39:11 -0700 (PDT) X-AuditID: c1b4fb30-f79246d00000788a-83-56ebf6ee41b9 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F2.2E.30858.EE6FBE65; Fri, 18 Mar 2016 13:39:10 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.248.2; Fri, 18 Mar 2016 13:39:09 +0100 From: Magnus Westerlund To: "Huangyihong (Rachel)" , "avtext@ietf.org" , Ben Campbell , "draft-ietf-avtext-splicing-notification@ietf.org" References: <56D6E18F.8050603@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E8C95B@nkgeml513-mbs.china.huawei.com> Message-ID: <56EBF6ED.6060207@ericsson.com> Date: Fri, 18 Mar 2016 13:39:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86E8C95B@nkgeml513-mbs.china.huawei.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM2J7uO67b6/DDLaeUbD4eO8Gq8X8ztPs FsfPvGO1WNp5it2BxaPlyFtWjyVLfjJ5zNr5hCWAOYrLJiU1J7MstUjfLoEr49faGawF/9oZ K24+bmJvYNyc08XIySEhYCLxZsNFRghbTOLCvfVsXYxcHEIChxkl9nd1sEA4yxkljv37wQZS xSZgIXHzRyOQzcEhLOAhsecTD0hYROAZo0T7X38QW0igXKJ/6UKwobwC2hLb5h9jBrFZBFQl /qzZADZGVCBG4vi7c1A1ghInZz5hARnJKRAmcabXE8RkFrCXeLC1DKSCWUBeonnrbGaI6doS DU0drBMYBWYhaZ6F0DELSccCRuZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIEBe3DLb4Md jC+fOx5iFOBgVOLhLVj+OkyINbGsuDL3EKMEB7OSCO/Xr0Ah3pTEyqrUovz4otKc1OJDjNIc LErivKyfLocJCaQnlqRmp6YWpBbBZJk4OKUaGGen5s/0kaz0K7Ho3iK8/aqAn5J71/UoxQQ+ H+N9h2V3zLM/4H5K/knyj94HL01c9kz/ZTTjp61Ap5blm4uLO3cIqH69PmHH7g/z1ERm/Tz9 YcZi2TWflwu8i9U47pywKuOCZlKhU6VeyPEavcP521j/hpzg3v6ndqOlgr5A0iKZOwFeRSqO m5VYijMSDbWYi4oTAc4tZ0NUAgAA Archived-At: Subject: Re: [avtext] Some comments on draft-ietf-avtext-splicing-notification-04 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, 18 Mar 2016 12:41:01 -0000 Hi, Sorry for being a bit late in responding on this. I hope you have time to submit this before the cut-off on Monday. Den 2016-03-03 kl. 11:51, skrev Huangyihong (Rachel): > Hi Magnus, > > Thank you so much for your careful review and valuable comments. It > helps us to further improve the document quality. Please see my > replies inline. > > BR, Rachel > > >> -----Original Message----- From: Magnus Westerlund >> [mailto:magnus.westerlund@ericsson.com] Sent: Wednesday, March 02, >> 2016 8:50 PM To: avtext@ietf.org; Ben Campbell; >> draft-ietf-avtext-splicing-notification@ietf.org Subject: Some >> comments on draft-ietf-avtext-splicing-notification-04 >> >> Hi, >> >> This are some comments that came out of my review as an IANA expert >> for the RTP Header Extensions and RTCP Control Packet Types, and >> which of some is not related to the IANA expert review role. >> However, I have noted that several of these, issues 1,2,3, and 5, >> are related to protocol clearness as well as correct usage of RTP >> which are review criteria for the RTP header extension registry. >> >> >> 1. Section 1.1 and 3.1: >> >> What the NTP timestamp included in the extensions represent are not >> being sufficiently made clear. I think it must be made clear that >> the NTP timestamp represents the Main RTP senders wall clock >> timestamp corresponding to these splicing in and out points. The >> main RTP senders time base may have nothing with any formal time >> basis distributed by the NTP protocol. > > [Rachel]: You're right. So how about changing the "splicing interval" > in section 1.1 to the following: > > " Splicing Interval: > > The NTP-format timestamps, representing the main RTP sender wallclock > time, for the Splicing-In point and Splicing-Out point per [RFC6828] > allowing the splicer to know when to start and end the RTP splicing. > " As for the ones in section 3.1, is it okay to just keep the > "NTP-format timestamps", since we clarify it in the terminology? > Yes, I think so. >> >> 2. Section 3.1: >> >> If the 7 octets splicing-out NTP timestamp is smaller than the >> lower 7 octets splicing-in NTP timestamp, it implies a wrap of the >> 64-bit splicing-out NTP timestamp which will then be calculated by >> the 7 octets splicing-out NTP timestamp plus 0x100000000. >> >> So I think "smaller" is a underspecified operation here. Although I >> think loading the 7 octets into one 64 bit unsigned integer >> respectively and perform a lesser than comparison will actually >> work. > > [Rachel]: So how about expressing it like this > > OLD " The top 8 bits of the splicing-out NTP timestamp are inferred > from the top 8 bits of the splicing-in NTP timestamp. This is > unambiguous, under the assumption that the splicing-out time is after > the splicing-in time, and the splicing interval is less than 2^25 > seconds. If the 7 octets splicing-out NTP timestamp is smaller than > the lower 7 octets splicing-in NTP timestamp, it implies a wrap of > the 64-bit splicing-out NTP timestamp which will then be calculated > by the 7 octets splicing-out NTP timestamp plus 0x100000000. > Otherwise, the top 8 octets of splicing-out NTP timestamp is equal to > the top 8 octets of splicing-in NTP timestamp. " > > NEW " The top 8 bits of the splicing-out NTP timestamp are inferred > from the top 8 bits of the splicing-in NTP timestamp. This is > unambiguous, under the assumption that the splicing-out time is after > the splicing-in time, and the splicing interval is less than 2^25 > seconds. Therefore, if the 7 octets splicing-out NTP-format timestamp > is smaller than 64-bit splicing-out NTP-format timestamp modulo 56 > bits range, it implies a wrap of the 64-bit splicing-out NTP-format > timestamp which will then be calculated by the 7 octets splicing-out > NTP timestamp plus 2^64. Otherwise, the top 8 octets of splicing-out > NTP timestamp is equal to the top 8 octets of splicing-in NTP > timestamp. " Hmm, this appears to be wrong about the wrapping. The wrapping that is the concern here that when the 56-bit value of the out is smaller than the 56-bit value of the splicing in point then a wrap of the 56-bit value has happened which will result in that one need to add 0x01 to the top 8-bit value copied from the splicing in point to the splicing out top 8-bit value. > >> >> 3. Section 3.1: >> >> This section is not clear on what is the data part of the header >> extension format. As it is not the header extension that can >> determine if there will be usage of one-byte vs two-byte format >> that will be used, this needs to be defined in a more un > > [Rachel]: I don't understand this. The editing seems unfinished. The > splicing RTP header extension uses one-byte format with the fixed bit > pattern 0xBEDE. Sorry, what is missing is: The definition of the data field need to be done in a way that is agnostic to if 1 or 2-byte headers are being used in the header extension. > >> >> 4. Section 3.2: The RTCP splicing notification message can be >> appended to RTCP SR the main RTP sender generates in compound RTCP >> packets, and hence follows the compound RTCP rules defined in >> Section 6.1 in [RFC3550]. >> >> I think the use of "append to RTCP SR" is unfortunate. I believe >> what would be the right messages is to say that the splicing >> notification messages is included in the same RTCP compound packet >> as the RTCP SR for the main RTP stream. Using the SSRC values to >> relate the two. This is important because there should be no formal >> requirement on ordering between individual RTCP packets within a >> compound packet. > > [Rachel]: Good point. How about changing to > > " The RTCP splicing notification message can be included in the RTCP > compound packet together with RTCP SR generated at the main RTP > sender, and hence follows the compound RTCP rules defined in Section > 6.1 in [RFC3550]. " > Yes, that would work. I realized now that you haven't expanded RTCP SR on its first use. Please do. >> >> >> 5. Section 3.2: >> >> This format is similar to the RTCP Sender Report (Section 6.4.1 of >> [RFC3550]) >> >> Why is it only similar and not the same as in RFC 3550? >> > > [Rachel]: Actually it's the same. Bad wording:(. > >> >> 6. Section 3.2: >> >> If the use of non-compound RTCP [RFC5506] was previously >> negotiated between the sender and the splicer, the RTCP splicing >> notification message may be sent as non-compound RTCP packets. >> >> I wonder over this, I wonder if this RTCP packet type really should >> be sent in an RTCP non-compound packet without the corresponding >> RTCP SR packet? The reason I state this is that the RTP main sender >> has to use SR/RR report block LSR field to determine which is the >> latest received RTCP SR packet for the SSRC in the splicing RTCP >> packet. And due to timing of RTCP packet transmission that can be >> old information. Thus, the splicer can operate on RTP to NTP >> Timestamps that are not current. Thus, I think it would be a >> recommendation to include the RTCP SR with the splicing packet. It >> can still be a non-compound as one could leave out the SDES CNAME >> items. > > [Rachel]: Maybe I got it wrong. But are you saying that the accuracy > of mapping RTP timestamp to NTP timestamp, which should be deduced by > the information in the RTCP SR that should be as close as the > splicing starts? But the RTCP splicing message is sent far ahead of > the splicing happens, and should be sent more than once to increase > robustness. For example, may be several RTTs ahead. So in a > non-compound case, it is possible that a RTCP SR will be sent after a > RTCP splicing message, hence it seems no meaning to include RTCP SR > with RTCP splicing messages. So, yes things will work as long as the RTP to NTP mapping the in the splicer is correct. However, in some cases situations can occur that will modify the RTP to NTP mapping between the a previous sending of the Splicing message and the actual splicing start or stop. So when does the RTP to NTP mapping change? 1. If the Payload Type changes and the clock rate changes and the system does not follow the recommendations in RFC 7160. However this is likely the least likely reason. 2. The more common reason will be clock drift. If the system wall clock progresses at a rate that is not matching the RTP timestamp rate, then periodically adjustments may occur. Thus changing the RTP to NTP mapping. The issue with changing mapping is that one needs to know if it is the RTP timeline or the NTP wall clock that is the most relevant for when the splicing should occur. If it is the RTP one, due to that a specific amount of media samples needs to have been processed. In other words the boundary in the actual content is known and determines when the splice should happen. This I find likely for pre-recorded content. But, I think I actually misrepresented the issue. I agree that it is not necessary that one have the SR and splicing messages in the same compound or reduced size RTCP packet. It is that one acknowledge what occurs if one do receive or not receive an update if the mapping has been updated between initial splicing information transmission and the implementation. Different outcomes occur depending on which timescale is the primary one for when the splicing should occur. If RTP timeline is the important. Then an update of the RTP to NTP mapping requires an updated NTP formated splicing point. In this case the best that one can do is send both Splicing info and RTCP SR. You need both to correctly splice. If the NTP timeline is the one that matters, then an updated RTP to NTP mapping only needs the new values in the RTCP SR, no new splicing message is needed. To conclude, what might be needed is actually rather a comment on that updated information may occur, and in certain cases both the splicing interval and the RTCP SR is needed to correctly splice. > >> >> 7. Section 6.2: >> >> Only codecs that are supported both by the main RTP stream and the >> substitutive RTP stream could be negotiated with SDP O/A. And the >> splicer MUST choose the same codec for both of these two streams. >> >> So this payload type restriction is in my view in the wrong place >> and not clear enough. So, to be able to splice into one consistent >> outgoing stream there is a basic requirement that the RTP Payload >> Types used are having the same clock rate, otherwise RFC 7160 >> applies, as uncertainty about how RTP maps to NTP and splicing >> appears to be a bad mix. > > [Rachel]: Actually, this has been described in Section 2, 3rd > paragraph. It says > > " To ensure the Splicing Interval is valid for both the main RTP > sender and the substitutive RTP sender, the two senders MUST share a > common reference clock so that the splicer can achieve accurate > splicing. The requirements for the common reference clock (e.g. > resolution, skew) depend on the codec used by the media content. " > >> >> Further if one is going to express this in this more restrictive >> way of demanding the same codes, then I do wonder if one actually >> don't need to go as far as saying that the same payload type >> configurations needs to be possible to us in both main and >> substitute streams. > > [Rachel]: So you're suggesting that we delete this sentence? Yes, the section you quote above already have a restriction using RFC 2119 terms. Isn't that sufficient? > >> >> 8. Section 7: >> >> I find a significant short coming in this security consideration. >> That is the failure to discuss the importance for the splicer to be >> able to trust the splicing interval information from the main RTP >> sender. This information really should be authenticated and >> integrity protected between the main RTP sender and the splicer. >> >> Thus, I am quite worried about this paragraph: >> >> Since the mechanism introduced in this document is not dependent >> on any RTP payload-level hints for finding the splicing in and out >> points, Secure Real-Time Transport Protocol (SRTP) [3711] can be >> used to provide confidentiality of the RTP payload while leaving >> the RTP header in the clear so that the splicer can still carry out >> splicing without keying materials. However, for a malicious >> endpoint without the key, it can observe the splicing time in the >> RTP header, and it can intercept the substitutive content and even >> replace it with a different one if the substitutive stream does not >> use any security like SRTP and the splicer does not authenticate >> the main and substitutive content sources. >> >> In the end it hints towards the need for authentication of the >> streams. But that really should be worded in a stronger way as a >> requirement for security. >> >> I do understand that this is really a case where two layers of >> security would be good. One between the main and substitute sender >> and the intended receiver, and an outer layer for sender to >> splicer. However, I don't argue that such a solution needs to be >> created. I think having the splicer as a trusted entity is more >> likely to be a reasonable deployment model. > > > [Rachel]: Okay. How about Add a new paragraph after the 3rd paragraph > in Section 7? > > " To avoid above security issue, the authentication of the main and > substitutive content sources in the splicer SHOULD be considered. > However, separating the security mechanism between senders and the > splicer from the end-to-end one may complicate the whole system > deployment. In such a case, having the splicer as a trusted entity is > likely to be a reasonable deployment model. " No, I don't think this addresses the issue. The second paragraph already describes the trust model, of the trusted splicer. Especially as no alternative do yet exist. Although PERC WG exists and working on a model with end-to-end confidentiality, which could possibly work. That is not a great match either for what I think are the security requirements for services that uses splicing. I think what needs to occur is to rewrite the third paragraph from the perspective that the splicer is trusted. Especially as the stream the splicer forwards will not match the received one from a perspective of number of packets and bytes, thus requiring RTCP changes. This is why a translator or mixer model is required. Thus, the packet forwarded from the splicer to the receiver will not be consistent with either the original or the substitution stream. For the authentication and integrity protection to not blow up the SRTP keys will be needed. A division of the roles of integrity versus confidentiality and you are back into PERC territory. Thus, the discussion of header extension encryption is mote. Rather discuss that the splicer should use authenticated and integrity protected streams to prevent third parties from controlling the splicing as well as the substitution content. > >> >> I do note that splicing do have the issue from key-management >> perspective that both main and substitute sender needs to use the >> same key if the security is from sender to receiver, rather than >> splicer to receiver. > > [Rachel]: Yes. I plan to add a sentence in the paragraph 3 like > this: > > OLD " Since the mechanism introduced in this document is not > dependent on any RTP payload-level hints for finding the splicing in > and out points, Secure Real-Time Transport Protocol (SRTP) [RFC3711] > can be used to provide confidentiality of the RTP payload while > leaving the RTP header in the clear so that the splicer can still > carry out splicing without keying materials. " > > NEW " Since the mechanism introduced in this document is not > dependent on any RTP payload-level hints for finding the splicing in > and out points, Secure Real-Time Transport Protocol (SRTP) [RFC3711] > can be used to provide confidentiality of the RTP payload while > leaving the RTP header in the clear so that the splicer can still > carry out splicing without keying materials. This implies that either > the main and substitutive sender use the same SRTP key, or the > splicer decrypts and re-encrypts with a single key. " > As I said above due to the SRTP keys for confidentiality and integrity are coming from a common master key, it is not possible to define a solution as indicated by the new text above. I am sorry if I mislead you into the two layer security solution. It is a possibility, but require a lot of spec work. Because PERC will most likely not be sufficient for this usage. 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 Mon Mar 21 03:16:00 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 4485D12D5EF; Mon, 21 Mar 2016 03:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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, RP_MATCHES_RCVD=-0.001, 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 5basmQsqApoU; Mon, 21 Mar 2016 03:15:56 -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 E6BC712D582; Mon, 21 Mar 2016 03:15:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLB11299; Mon, 21 Mar 2016 10:15:52 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 21 Mar 2016 10:15:35 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Mon, 21 Mar 2016 18:15:30 +0800 From: "Huangyihong (Rachel)" To: Magnus Westerlund , "avtext@ietf.org" , Ben Campbell , "draft-ietf-avtext-splicing-notification@ietf.org" Thread-Topic: Some comments on draft-ietf-avtext-splicing-notification-04 Thread-Index: AQHRdIIhWfIN9oQkKEK98MCsQzahTp9G/RLggBe6IoCABKGjAA== Date: Mon, 21 Mar 2016 10:15:29 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E99046@nkgeml513-mbx.china.huawei.com> References: <56D6E18F.8050603@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E8C95B@nkgeml513-mbs.china.huawei.com> <56EBF6ED.6060207@ericsson.com> In-Reply-To: <56EBF6ED.6060207@ericsson.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.191] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56EFC9D9.00DB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 34bde8ab86815f8c37acfb7df35083bd Archived-At: Subject: Re: [avtext] Some comments on draft-ietf-avtext-splicing-notification-04 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: Mon, 21 Mar 2016 10:15:59 -0000 Hi Magnus, Thanks for the response. I haven't checked the mail last weekend. Hope I ca= n still have time to submit it^^. Please see inline. BR, Rachel > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Friday, March 18, 2016 8:39 PM > To: Huangyihong (Rachel); avtext@ietf.org; Ben Campbell; > draft-ietf-avtext-splicing-notification@ietf.org > Subject: Re: Some comments on draft-ietf-avtext-splicing-notification-04 >=20 > Hi, >=20 > Sorry for being a bit late in responding on this. I hope you have time to= submit > this before the cut-off on Monday. >=20 > Den 2016-03-03 kl. 11:51, skrev Huangyihong (Rachel): > > Hi Magnus, > > > > Thank you so much for your careful review and valuable comments. It > > helps us to further improve the document quality. Please see my > > replies inline. > > > > BR, Rachel > > > > > >> -----Original Message----- From: Magnus Westerlund > >> [mailto:magnus.westerlund@ericsson.com] Sent: Wednesday, March 02, > >> 2016 8:50 PM To: avtext@ietf.org; Ben Campbell; > >> draft-ietf-avtext-splicing-notification@ietf.org Subject: Some > >> comments on draft-ietf-avtext-splicing-notification-04 > >> > >> Hi, > >> > >> This are some comments that came out of my review as an IANA expert > >> for the RTP Header Extensions and RTCP Control Packet Types, and > >> which of some is not related to the IANA expert review role. > >> However, I have noted that several of these, issues 1,2,3, and 5, are > >> related to protocol clearness as well as correct usage of RTP which > >> are review criteria for the RTP header extension registry. > >> > >> > >> 1. Section 1.1 and 3.1: > >> > >> What the NTP timestamp included in the extensions represent are not > >> being sufficiently made clear. I think it must be made clear that the > >> NTP timestamp represents the Main RTP senders wall clock timestamp > >> corresponding to these splicing in and out points. The main RTP > >> senders time base may have nothing with any formal time basis > >> distributed by the NTP protocol. > > > > [Rachel]: You're right. So how about changing the "splicing interval" > > in section 1.1 to the following: > > > > " Splicing Interval: > > > > The NTP-format timestamps, representing the main RTP sender wallclock > > time, for the Splicing-In point and Splicing-Out point per [RFC6828] > > allowing the splicer to know when to start and end the RTP splicing. > > " As for the ones in section 3.1, is it okay to just keep the > > "NTP-format timestamps", since we clarify it in the terminology? > > >=20 > Yes, I think so. >=20 > >> > >> 2. Section 3.1: > >> > >> If the 7 octets splicing-out NTP timestamp is smaller than the lower > >> 7 octets splicing-in NTP timestamp, it implies a wrap of the 64-bit > >> splicing-out NTP timestamp which will then be calculated by the 7 > >> octets splicing-out NTP timestamp plus 0x100000000. > >> > >> So I think "smaller" is a underspecified operation here. Although I > >> think loading the 7 octets into one 64 bit unsigned integer > >> respectively and perform a lesser than comparison will actually work. > > > > [Rachel]: So how about expressing it like this > > > > OLD " The top 8 bits of the splicing-out NTP timestamp are inferred > > from the top 8 bits of the splicing-in NTP timestamp. This is > > unambiguous, under the assumption that the splicing-out time is after > > the splicing-in time, and the splicing interval is less than 2^25 > > seconds. If the 7 octets splicing-out NTP timestamp is smaller than > > the lower 7 octets splicing-in NTP timestamp, it implies a wrap of the > > 64-bit splicing-out NTP timestamp which will then be calculated by the > > 7 octets splicing-out NTP timestamp plus 0x100000000. > > Otherwise, the top 8 octets of splicing-out NTP timestamp is equal to > > the top 8 octets of splicing-in NTP timestamp. " > > > > NEW " The top 8 bits of the splicing-out NTP timestamp are inferred > > from the top 8 bits of the splicing-in NTP timestamp. This is > > unambiguous, under the assumption that the splicing-out time is after > > the splicing-in time, and the splicing interval is less than 2^25 > > seconds. Therefore, if the 7 octets splicing-out NTP-format timestamp > > is smaller than 64-bit splicing-out NTP-format timestamp modulo 56 > > bits range, it implies a wrap of the 64-bit splicing-out NTP-format > > timestamp which will then be calculated by the 7 octets splicing-out > > NTP timestamp plus 2^64. Otherwise, the top 8 octets of splicing-out > > NTP timestamp is equal to the top 8 octets of splicing-in NTP > > timestamp. " >=20 > Hmm, this appears to be wrong about the wrapping. The wrapping that is th= e > concern here that when the 56-bit value of the out is smaller than the 56= -bit > value of the splicing in point then a wrap of the 56-bit value has happen= ed > which will result in that one need to add 0x01 to the top 8-bit value cop= ied from > the splicing in point to the splicing out top 8-bit value. [Rachel]: You're right. The previous proposal is completely messed up. Here= 's the new proposal: " The top 8 bits of the splicing-out NTP timestamp are inferred from the top 8 bits of the splicing-in NTP timestamp. This is unambiguous, under the assumption that the splicing-out time is after the splicing-in time, and the splicing interval is less than 2^25 seconds. Therefore, if the 7 octets splicing-out NTP-format timestamp is smaller than the value of 7 low octets splicing-out NTP-format, it impli= es a wrap of the 56-bit splicing-out NTP-format=09 timestamp which means the top 8-bit value of the 64-bit splicing-out is equ= al to the top 8-bit value of splicing-in NTP Timestamp plus 0x01. Otherwise, the top 8 bits of splicing-out NTP timestamp is equal to the top 8 bits of splicing-in NTP Timestamp. " >=20 >=20 >=20 > > > >> > >> 3. Section 3.1: > >> > >> This section is not clear on what is the data part of the header > >> extension format. As it is not the header extension that can > >> determine if there will be usage of one-byte vs two-byte format that > >> will be used, this needs to be defined in a more un > > > > [Rachel]: I don't understand this. The editing seems unfinished. The > > splicing RTP header extension uses one-byte format with the fixed bit > > pattern 0xBEDE. >=20 > Sorry, what is missing is: The definition of the data field need to be do= ne in a > way that is agnostic to if 1 or 2-byte headers are being used in the head= er > extension. > [Rachel]: I don't understand why should this extension to be agnostic for e= xtension header types. There's no such limitation in [RFC5285] if I read it= correctly. And based on [RFC5285], it says: " There are two variants of the extension: one-byte and two-byte headers. Since it is expected that (a) the number of extensions in any given RTP session is small and (b) the extensions themselves are small, the one-byte header form is preferred and MUST be supported by all receivers. A stream MUST contain only one-byte or two-byte headers: they MUST NOT be mixed within a stream. Transmitters SHOULD NOT use the two-byte form when all extensions are small enough for the one-byte header form. " For splicing extension, it can be classified into a) case. That's why we us= es one-byte header, and it is preferred and mandated by receivers. So I can= 't imagine any other cases to use 2-byte header. And by the way, [RFC6051] = also only defines one-byte header. =20 > > > >> > >> 4. Section 3.2: The RTCP splicing notification message can be > >> appended to RTCP SR the main RTP sender generates in compound RTCP > >> packets, and hence follows the compound RTCP rules defined in > >> Section 6.1 in [RFC3550]. > >> > >> I think the use of "append to RTCP SR" is unfortunate. I believe > >> what would be the right messages is to say that the splicing > >> notification messages is included in the same RTCP compound packet > >> as the RTCP SR for the main RTP stream. Using the SSRC values to > >> relate the two. This is important because there should be no formal > >> requirement on ordering between individual RTCP packets within a > >> compound packet. > > > > [Rachel]: Good point. How about changing to > > > > " The RTCP splicing notification message can be included in the RTCP > > compound packet together with RTCP SR generated at the main RTP > > sender, and hence follows the compound RTCP rules defined in Section > > 6.1 in [RFC3550]. " > > >=20 > Yes, that would work. >=20 > I realized now that you haven't expanded RTCP SR on its first use. > Please do. [Rachel]: Will do. >=20 > >> > >> > >> 5. Section 3.2: > >> > >> This format is similar to the RTCP Sender Report (Section 6.4.1 of > >> [RFC3550]) > >> > >> Why is it only similar and not the same as in RFC 3550? > >> > > > > [Rachel]: Actually it's the same. Bad wording:(. > > > >> > >> 6. Section 3.2: > >> > >> If the use of non-compound RTCP [RFC5506] was previously > >> negotiated between the sender and the splicer, the RTCP splicing > >> notification message may be sent as non-compound RTCP packets. > >> > >> I wonder over this, I wonder if this RTCP packet type really should > >> be sent in an RTCP non-compound packet without the corresponding > >> RTCP SR packet? The reason I state this is that the RTP main sender > >> has to use SR/RR report block LSR field to determine which is the > >> latest received RTCP SR packet for the SSRC in the splicing RTCP > >> packet. And due to timing of RTCP packet transmission that can be > >> old information. Thus, the splicer can operate on RTP to NTP > >> Timestamps that are not current. Thus, I think it would be a > >> recommendation to include the RTCP SR with the splicing packet. It > >> can still be a non-compound as one could leave out the SDES CNAME > >> items. > > > > [Rachel]: Maybe I got it wrong. But are you saying that the accuracy > > of mapping RTP timestamp to NTP timestamp, which should be deduced by > > the information in the RTCP SR that should be as close as the > > splicing starts? But the RTCP splicing message is sent far ahead of > > the splicing happens, and should be sent more than once to increase > > robustness. For example, may be several RTTs ahead. So in a > > non-compound case, it is possible that a RTCP SR will be sent after a > > RTCP splicing message, hence it seems no meaning to include RTCP SR > > with RTCP splicing messages. >=20 > So, yes things will work as long as the RTP to NTP mapping the in the > splicer is correct. However, in some cases situations can occur that > will modify the RTP to NTP mapping between the a previous sending of the > Splicing message and the actual splicing start or stop. >=20 > So when does the RTP to NTP mapping change? >=20 > 1. If the Payload Type changes and the clock rate changes and the system > does not follow the recommendations in RFC 7160. However this is likely > the least likely reason. >=20 > 2. The more common reason will be clock drift. If the system wall clock > progresses at a rate that is not matching the RTP timestamp rate, then > periodically adjustments may occur. Thus changing the RTP to NTP mapping. >=20 > The issue with changing mapping is that one needs to know if it is the > RTP timeline or the NTP wall clock that is the most relevant for when > the splicing should occur. If it is the RTP one, due to that a specific > amount of media samples needs to have been processed. In other words the > boundary in the actual content is known and determines when the splice > should happen. This I find likely for pre-recorded content. >=20 > But, I think I actually misrepresented the issue. I agree that it is not > necessary that one have the SR and splicing messages in the same > compound or reduced size RTCP packet. It is that one acknowledge what > occurs if one do receive or not receive an update if the mapping has > been updated between initial splicing information transmission and the > implementation. >=20 > Different outcomes occur depending on which timescale is the primary one > for when the splicing should occur. >=20 > If RTP timeline is the important. Then an update of the RTP to NTP > mapping requires an updated NTP formated splicing point. In this case > the best that one can do is send both Splicing info and RTCP SR. You > need both to correctly splice. >=20 > If the NTP timeline is the one that matters, then an updated RTP to NTP > mapping only needs the new values in the RTCP SR, no new splicing > message is needed. >=20 > To conclude, what might be needed is actually rather a comment on that > updated information may occur, and in certain cases both the splicing > interval and the RTCP SR is needed to correctly splice. [Rachel]: Okay. I get your point. So how about adding some texts as followi= ng in Section 3.2, the last 2nd paragraph? " In cases of the mapping from RTP timestamp to NTP timestamp changes, e.g., = clock drift happening before the splicing event, it may be required to send= RTCP SR or even updated Splicing Interval information timely to update the= timestamp mapping for accurate splicing. " >=20 >=20 >=20 > > > >> > >> 7. Section 6.2: > >> > >> Only codecs that are supported both by the main RTP stream and the > >> substitutive RTP stream could be negotiated with SDP O/A. And the > >> splicer MUST choose the same codec for both of these two streams. > >> > >> So this payload type restriction is in my view in the wrong place > >> and not clear enough. So, to be able to splice into one consistent > >> outgoing stream there is a basic requirement that the RTP Payload > >> Types used are having the same clock rate, otherwise RFC 7160 > >> applies, as uncertainty about how RTP maps to NTP and splicing > >> appears to be a bad mix. > > > > [Rachel]: Actually, this has been described in Section 2, 3rd > > paragraph. It says > > > > " To ensure the Splicing Interval is valid for both the main RTP > > sender and the substitutive RTP sender, the two senders MUST share a > > common reference clock so that the splicer can achieve accurate > > splicing. The requirements for the common reference clock (e.g. > > resolution, skew) depend on the codec used by the media content. " > > > >> > >> Further if one is going to express this in this more restrictive > >> way of demanding the same codes, then I do wonder if one actually > >> don't need to go as far as saying that the same payload type > >> configurations needs to be possible to us in both main and > >> substitute streams. > > > > [Rachel]: So you're suggesting that we delete this sentence? >=20 > Yes, the section you quote above already have a restriction using RFC > 2119 terms. Isn't that sufficient? >=20 > > > >> > >> 8. Section 7: > >> > >> I find a significant short coming in this security consideration. > >> That is the failure to discuss the importance for the splicer to be > >> able to trust the splicing interval information from the main RTP > >> sender. This information really should be authenticated and > >> integrity protected between the main RTP sender and the splicer. > >> > >> Thus, I am quite worried about this paragraph: > >> > >> Since the mechanism introduced in this document is not dependent > >> on any RTP payload-level hints for finding the splicing in and out > >> points, Secure Real-Time Transport Protocol (SRTP) [3711] can be > >> used to provide confidentiality of the RTP payload while leaving > >> the RTP header in the clear so that the splicer can still carry out > >> splicing without keying materials. However, for a malicious > >> endpoint without the key, it can observe the splicing time in the > >> RTP header, and it can intercept the substitutive content and even > >> replace it with a different one if the substitutive stream does not > >> use any security like SRTP and the splicer does not authenticate > >> the main and substitutive content sources. > >> > >> In the end it hints towards the need for authentication of the > >> streams. But that really should be worded in a stronger way as a > >> requirement for security. > >> > >> I do understand that this is really a case where two layers of > >> security would be good. One between the main and substitute sender > >> and the intended receiver, and an outer layer for sender to > >> splicer. However, I don't argue that such a solution needs to be > >> created. I think having the splicer as a trusted entity is more > >> likely to be a reasonable deployment model. > > > > > > [Rachel]: Okay. How about Add a new paragraph after the 3rd paragraph > > in Section 7? > > > > " To avoid above security issue, the authentication of the main and > > substitutive content sources in the splicer SHOULD be considered. > > However, separating the security mechanism between senders and the > > splicer from the end-to-end one may complicate the whole system > > deployment. In such a case, having the splicer as a trusted entity is > > likely to be a reasonable deployment model. " >=20 > No, I don't think this addresses the issue. The second paragraph already > describes the trust model, of the trusted splicer. Especially as no > alternative do yet exist. Although PERC WG exists and working on a model > with end-to-end confidentiality, which could possibly work. That is not > a great match either for what I think are the security requirements for > services that uses splicing. >=20 > I think what needs to occur is to rewrite the third paragraph from the > perspective that the splicer is trusted. Especially as the stream the > splicer forwards will not match the received one from a perspective of > number of packets and bytes, thus requiring RTCP changes. This is why a > translator or mixer model is required. Thus, the packet forwarded from > the splicer to the receiver will not be consistent with either the > original or the substitution stream. For the authentication and > integrity protection to not blow up the SRTP keys will be needed. A > division of the roles of integrity versus confidentiality and you are > back into PERC territory. >=20 > Thus, the discussion of header extension encryption is mote. Rather > discuss that the splicer should use authenticated and integrity > protected streams to prevent third parties from controlling the splicing > as well as the substitution content. [Rachel]: Here's my proposal to rewrite 3rd paragraph to discuss the authen= tication between splicer and receiver. Is it what you're looking for? " Since splicer works as a trusted entity, any RTP-level or outside security = mechanism, such IPsec[RFC4301] or Datagram Transport Layer Security [RFC634= 7], will use a security association between the splicer and the receiver. W= hen using the Secure Real-Time Transport Protocol (SRTP) [RFC3711], the spl= icer could be provisioned with the same security association as the main RT= P sender. " >=20 > > > >> > >> I do note that splicing do have the issue from key-management > >> perspective that both main and substitute sender needs to use the > >> same key if the security is from sender to receiver, rather than > >> splicer to receiver. > > > > [Rachel]: Yes. I plan to add a sentence in the paragraph 3 like > > this: > > > > OLD " Since the mechanism introduced in this document is not > > dependent on any RTP payload-level hints for finding the splicing in > > and out points, Secure Real-Time Transport Protocol (SRTP) [RFC3711] > > can be used to provide confidentiality of the RTP payload while > > leaving the RTP header in the clear so that the splicer can still > > carry out splicing without keying materials. " > > > > NEW " Since the mechanism introduced in this document is not > > dependent on any RTP payload-level hints for finding the splicing in > > and out points, Secure Real-Time Transport Protocol (SRTP) [RFC3711] > > can be used to provide confidentiality of the RTP payload while > > leaving the RTP header in the clear so that the splicer can still > > carry out splicing without keying materials. This implies that either > > the main and substitutive sender use the same SRTP key, or the > > splicer decrypts and re-encrypts with a single key. " > > >=20 > As I said above due to the SRTP keys for confidentiality and integrity > are coming from a common master key, it is not possible to define a > solution as indicated by the new text above. >=20 > I am sorry if I mislead you into the two layer security solution. It is > a possibility, but require a lot of spec work. Because PERC will most > likely not be sufficient for this usage. >=20 >=20 > Cheers >=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From nobody Mon Mar 21 06:52:36 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 AB69512D85F; Mon, 21 Mar 2016 06:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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, RP_MATCHES_RCVD=-0.001, 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 9ZPX66Ias8Tb; Mon, 21 Mar 2016 06:52:15 -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 36FBA12D84D; Mon, 21 Mar 2016 06:52:14 -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 CGK18653; Mon, 21 Mar 2016 13:52:11 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 21 Mar 2016 13:52:10 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0235.001; Mon, 21 Mar 2016 21:52:06 +0800 From: "Huangyihong (Rachel)" To: "'Magnus Westerlund'" , "'avtext@ietf.org'" , "'Ben Campbell'" , "'draft-ietf-avtext-splicing-notification@ietf.org'" Thread-Topic: Some comments on draft-ietf-avtext-splicing-notification-04 Thread-Index: AQHRdIIhWfIN9oQkKEK98MCsQzahTp9G/RLggBe6IoCABKGjAIAArNhw Date: Mon, 21 Mar 2016 13:52:05 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E99201@nkgeml513-mbx.china.huawei.com> References: <56D6E18F.8050603@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E8C95B@nkgeml513-mbs.china.huawei.com> <56EBF6ED.6060207@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E99046@nkgeml513-mbx.china.huawei.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86E99046@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.46.126.51] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56EFFC8C.01AF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9abd445df2974bbe02a90df67b3ba5fc Archived-At: Subject: Re: [avtext] Some comments on draft-ietf-avtext-splicing-notification-04 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: Mon, 21 Mar 2016 13:52:18 -0000 SGkgTWFnbnVzLA0KDQpUaGVyZSdyZSBzdGlsbCBzb21lIHR5cG9zIHRvIGJlIGZpeGVkIGluIHRo ZSBmaXJzdCBhbnN3ZXI6DQoNCiINClRoZXJlZm9yZSwgaWYgdGhlIDcgb2N0ZXRzIHNwbGljaW5n LW91dCBOVFAtZm9ybWF0IHRpbWVzdGFtcA0KaXMgc21hbGxlciB0aGFuIHRoZSB2YWx1ZSBvZiA3 IGxvdyBvY3RldHMgc3BsaWNpbmctb3V0IE5UUC1mb3JtYXQsLi4uDQoiDQoNClNob3VsZCBiZSAN Cg0KDQoiIFRoZXJlZm9yZSwgaWYgdGhlIHZhbHVlIG9mIDcgb2N0ZXRzIHNwbGljaW5nLW91dCBO VFAtZm9ybWF0IHRpbWVzdGFtcA0KaXMgc21hbGxlciB0aGFuIHRoZSB2YWx1ZSBvZiA3IGxvd2Vy IG9jdGV0cyBzcGxpY2luZy1pbiBOVFAtZm9ybWF0LC4uLiINCg0KQXBvbG9naXplIGZvciBteSBj YXJlbGVzc25lc3MuDQoNCkJSDQpSYWNoZWwNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R 5Lu25Lq6OiBIdWFuZ3lpaG9uZyAoUmFjaGVsKSANCuWPkemAgeaXtumXtDogMjAxNuW5tDPmnIgy MeaXpSAxODoxNQ0K5pS25Lu25Lq6OiBNYWdudXMgV2VzdGVybHVuZDsgYXZ0ZXh0QGlldGYub3Jn OyBCZW4gQ2FtcGJlbGw7IGRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbkBp ZXRmLm9yZw0K5Li76aKYOiBSRTogU29tZSBjb21tZW50cyBvbiBkcmFmdC1pZXRmLWF2dGV4dC1z cGxpY2luZy1ub3RpZmljYXRpb24tMDQNCg0KSGkgTWFnbnVzLA0KDQpUaGFua3MgZm9yIHRoZSBy ZXNwb25zZS4gSSBoYXZlbid0IGNoZWNrZWQgdGhlIG1haWwgbGFzdCB3ZWVrZW5kLiBIb3BlIEkg Y2FuIHN0aWxsIGhhdmUgdGltZSB0byBzdWJtaXQgaXReXi4gUGxlYXNlIHNlZSBpbmxpbmUuDQoN CkJSLA0KUmFjaGVsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFn bnVzIFdlc3Rlcmx1bmQgW21haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb21dDQo+ IFNlbnQ6IEZyaWRheSwgTWFyY2ggMTgsIDIwMTYgODozOSBQTQ0KPiBUbzogSHVhbmd5aWhvbmcg KFJhY2hlbCk7IGF2dGV4dEBpZXRmLm9yZzsgQmVuIENhbXBiZWxsOyANCj4gZHJhZnQtaWV0Zi1h dnRleHQtc3BsaWNpbmctbm90aWZpY2F0aW9uQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBTb21l IGNvbW1lbnRzIG9uIA0KPiBkcmFmdC1pZXRmLWF2dGV4dC1zcGxpY2luZy1ub3RpZmljYXRpb24t MDQNCj4gDQo+IEhpLA0KPiANCj4gU29ycnkgZm9yIGJlaW5nIGEgYml0IGxhdGUgaW4gcmVzcG9u ZGluZyBvbiB0aGlzLiBJIGhvcGUgeW91IGhhdmUgdGltZSANCj4gdG8gc3VibWl0IHRoaXMgYmVm b3JlIHRoZSBjdXQtb2ZmIG9uIE1vbmRheS4NCj4gDQo+IERlbiAyMDE2LTAzLTAzIGtsLiAxMTo1 MSwgc2tyZXYgSHVhbmd5aWhvbmcgKFJhY2hlbCk6DQo+ID4gSGkgTWFnbnVzLA0KPiA+DQo+ID4g VGhhbmsgeW91IHNvIG11Y2ggZm9yIHlvdXIgY2FyZWZ1bCByZXZpZXcgYW5kIHZhbHVhYmxlIGNv bW1lbnRzLiBJdCANCj4gPiBoZWxwcyB1cyB0byBmdXJ0aGVyIGltcHJvdmUgdGhlIGRvY3VtZW50 IHF1YWxpdHkuIFBsZWFzZSBzZWUgbXkgDQo+ID4gcmVwbGllcyBpbmxpbmUuDQo+ID4NCj4gPiBC UiwgUmFjaGVsDQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9t OiBNYWdudXMgV2VzdGVybHVuZCANCj4gPj4gW21haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmlj c3Nvbi5jb21dIFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMDIsDQo+ID4+IDIwMTYgODo1MCBQTSBU bzogYXZ0ZXh0QGlldGYub3JnOyBCZW4gQ2FtcGJlbGw7IA0KPiA+PiBkcmFmdC1pZXRmLWF2dGV4 dC1zcGxpY2luZy1ub3RpZmljYXRpb25AaWV0Zi5vcmcgU3ViamVjdDogU29tZSANCj4gPj4gY29t bWVudHMgb24gZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmctbm90aWZpY2F0aW9uLTA0DQo+ID4+ DQo+ID4+IEhpLA0KPiA+Pg0KPiA+PiBUaGlzIGFyZSBzb21lIGNvbW1lbnRzIHRoYXQgY2FtZSBv dXQgb2YgbXkgcmV2aWV3IGFzIGFuIElBTkEgZXhwZXJ0IA0KPiA+PiBmb3IgdGhlIFJUUCBIZWFk ZXIgRXh0ZW5zaW9ucyBhbmQgUlRDUCBDb250cm9sIFBhY2tldCBUeXBlcywgYW5kIA0KPiA+PiB3 aGljaCBvZiBzb21lIGlzIG5vdCByZWxhdGVkIHRvIHRoZSBJQU5BIGV4cGVydCByZXZpZXcgcm9s ZS4NCj4gPj4gSG93ZXZlciwgSSBoYXZlIG5vdGVkIHRoYXQgc2V2ZXJhbCBvZiB0aGVzZSwgaXNz dWVzIDEsMiwzLCBhbmQgNSwgDQo+ID4+IGFyZSByZWxhdGVkIHRvIHByb3RvY29sIGNsZWFybmVz cyBhcyB3ZWxsIGFzIGNvcnJlY3QgdXNhZ2Ugb2YgUlRQIA0KPiA+PiB3aGljaCBhcmUgcmV2aWV3 IGNyaXRlcmlhIGZvciB0aGUgUlRQIGhlYWRlciBleHRlbnNpb24gcmVnaXN0cnkuDQo+ID4+DQo+ ID4+DQo+ID4+IDEuIFNlY3Rpb24gMS4xIGFuZCAzLjE6DQo+ID4+DQo+ID4+IFdoYXQgdGhlIE5U UCB0aW1lc3RhbXAgaW5jbHVkZWQgaW4gdGhlIGV4dGVuc2lvbnMgcmVwcmVzZW50IGFyZSBub3Qg DQo+ID4+IGJlaW5nIHN1ZmZpY2llbnRseSBtYWRlIGNsZWFyLiBJIHRoaW5rIGl0IG11c3QgYmUg bWFkZSBjbGVhciB0aGF0IA0KPiA+PiB0aGUgTlRQIHRpbWVzdGFtcCByZXByZXNlbnRzIHRoZSBN YWluIFJUUCBzZW5kZXJzIHdhbGwgY2xvY2sgDQo+ID4+IHRpbWVzdGFtcCBjb3JyZXNwb25kaW5n IHRvIHRoZXNlIHNwbGljaW5nIGluIGFuZCBvdXQgcG9pbnRzLiBUaGUgDQo+ID4+IG1haW4gUlRQ IHNlbmRlcnMgdGltZSBiYXNlIG1heSBoYXZlIG5vdGhpbmcgd2l0aCBhbnkgZm9ybWFsIHRpbWUg DQo+ID4+IGJhc2lzIGRpc3RyaWJ1dGVkIGJ5IHRoZSBOVFAgcHJvdG9jb2wuDQo+ID4NCj4gPiBb UmFjaGVsXTogWW91J3JlIHJpZ2h0LiBTbyBob3cgYWJvdXQgY2hhbmdpbmcgdGhlICJzcGxpY2lu ZyBpbnRlcnZhbCINCj4gPiBpbiBzZWN0aW9uIDEuMSB0byB0aGUgZm9sbG93aW5nOg0KPiA+DQo+ ID4gIiBTcGxpY2luZyBJbnRlcnZhbDoNCj4gPg0KPiA+IFRoZSBOVFAtZm9ybWF0IHRpbWVzdGFt cHMsIHJlcHJlc2VudGluZyB0aGUgbWFpbiBSVFAgc2VuZGVyIA0KPiA+IHdhbGxjbG9jayB0aW1l LCBmb3IgdGhlIFNwbGljaW5nLUluIHBvaW50IGFuZCBTcGxpY2luZy1PdXQgcG9pbnQgcGVyIA0K PiA+IFtSRkM2ODI4XSBhbGxvd2luZyB0aGUgc3BsaWNlciB0byBrbm93IHdoZW4gdG8gc3RhcnQg YW5kIGVuZCB0aGUgUlRQIHNwbGljaW5nLg0KPiA+ICIgQXMgZm9yIHRoZSBvbmVzIGluIHNlY3Rp b24gMy4xLCBpcyBpdCBva2F5IHRvIGp1c3Qga2VlcCB0aGUgDQo+ID4gIk5UUC1mb3JtYXQgdGlt ZXN0YW1wcyIsIHNpbmNlIHdlIGNsYXJpZnkgaXQgaW4gdGhlIHRlcm1pbm9sb2d5Pw0KPiA+DQo+ IA0KPiBZZXMsIEkgdGhpbmsgc28uDQo+IA0KPiA+Pg0KPiA+PiAyLiBTZWN0aW9uIDMuMToNCj4g Pj4NCj4gPj4gSWYgdGhlIDcgb2N0ZXRzIHNwbGljaW5nLW91dCBOVFAgdGltZXN0YW1wIGlzIHNt YWxsZXIgdGhhbiB0aGUgDQo+ID4+IGxvd2VyDQo+ID4+IDcgb2N0ZXRzIHNwbGljaW5nLWluIE5U UCB0aW1lc3RhbXAsIGl0IGltcGxpZXMgYSB3cmFwIG9mIHRoZSA2NC1iaXQgDQo+ID4+IHNwbGlj aW5nLW91dCBOVFAgdGltZXN0YW1wIHdoaWNoIHdpbGwgdGhlbiBiZSBjYWxjdWxhdGVkIGJ5IHRo ZSA3IA0KPiA+PiBvY3RldHMgc3BsaWNpbmctb3V0IE5UUCB0aW1lc3RhbXAgcGx1cyAweDEwMDAw MDAwMC4NCj4gPj4NCj4gPj4gU28gSSB0aGluayAic21hbGxlciIgaXMgYSB1bmRlcnNwZWNpZmll ZCBvcGVyYXRpb24gaGVyZS4gQWx0aG91Z2ggSSANCj4gPj4gdGhpbmsgbG9hZGluZyB0aGUgNyBv Y3RldHMgaW50byBvbmUgNjQgYml0IHVuc2lnbmVkIGludGVnZXIgDQo+ID4+IHJlc3BlY3RpdmVs eSBhbmQgcGVyZm9ybSBhIGxlc3NlciB0aGFuIGNvbXBhcmlzb24gd2lsbCBhY3R1YWxseSB3b3Jr Lg0KPiA+DQo+ID4gW1JhY2hlbF06IFNvIGhvdyBhYm91dCBleHByZXNzaW5nIGl0IGxpa2UgdGhp cw0KPiA+DQo+ID4gT0xEICIgVGhlIHRvcCA4IGJpdHMgb2YgdGhlIHNwbGljaW5nLW91dCBOVFAg dGltZXN0YW1wIGFyZSBpbmZlcnJlZCANCj4gPiBmcm9tIHRoZSB0b3AgOCBiaXRzIG9mIHRoZSBz cGxpY2luZy1pbiBOVFAgdGltZXN0YW1wLiBUaGlzIGlzIA0KPiA+IHVuYW1iaWd1b3VzLCB1bmRl ciB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSBzcGxpY2luZy1vdXQgdGltZSBpcyANCj4gPiBhZnRl ciB0aGUgc3BsaWNpbmctaW4gdGltZSwgYW5kIHRoZSBzcGxpY2luZyBpbnRlcnZhbCBpcyBsZXNz IHRoYW4gDQo+ID4gMl4yNSBzZWNvbmRzLiBJZiB0aGUgNyBvY3RldHMgc3BsaWNpbmctb3V0IE5U UCB0aW1lc3RhbXAgaXMgc21hbGxlciANCj4gPiB0aGFuIHRoZSBsb3dlciA3IG9jdGV0cyBzcGxp Y2luZy1pbiBOVFAgdGltZXN0YW1wLCBpdCBpbXBsaWVzIGEgd3JhcCANCj4gPiBvZiB0aGUgNjQt Yml0IHNwbGljaW5nLW91dCBOVFAgdGltZXN0YW1wIHdoaWNoIHdpbGwgdGhlbiBiZSANCj4gPiBj YWxjdWxhdGVkIGJ5IHRoZQ0KPiA+IDcgb2N0ZXRzIHNwbGljaW5nLW91dCBOVFAgdGltZXN0YW1w IHBsdXMgMHgxMDAwMDAwMDAuDQo+ID4gT3RoZXJ3aXNlLCB0aGUgdG9wIDggb2N0ZXRzIG9mIHNw bGljaW5nLW91dCBOVFAgdGltZXN0YW1wIGlzIGVxdWFsIA0KPiA+IHRvIHRoZSB0b3AgOCBvY3Rl dHMgb2Ygc3BsaWNpbmctaW4gTlRQIHRpbWVzdGFtcC4gIg0KPiA+DQo+ID4gTkVXICIgVGhlIHRv cCA4IGJpdHMgb2YgdGhlIHNwbGljaW5nLW91dCBOVFAgdGltZXN0YW1wIGFyZSBpbmZlcnJlZCAN Cj4gPiBmcm9tIHRoZSB0b3AgOCBiaXRzIG9mIHRoZSBzcGxpY2luZy1pbiBOVFAgdGltZXN0YW1w LiBUaGlzIGlzIA0KPiA+IHVuYW1iaWd1b3VzLCB1bmRlciB0aGUgYXNzdW1wdGlvbiB0aGF0IHRo ZSBzcGxpY2luZy1vdXQgdGltZSBpcyANCj4gPiBhZnRlciB0aGUgc3BsaWNpbmctaW4gdGltZSwg YW5kIHRoZSBzcGxpY2luZyBpbnRlcnZhbCBpcyBsZXNzIHRoYW4gDQo+ID4gMl4yNSBzZWNvbmRz LiBUaGVyZWZvcmUsIGlmIHRoZSA3IG9jdGV0cyBzcGxpY2luZy1vdXQgTlRQLWZvcm1hdCANCj4g PiB0aW1lc3RhbXAgaXMgc21hbGxlciB0aGFuIDY0LWJpdCBzcGxpY2luZy1vdXQgTlRQLWZvcm1h dCB0aW1lc3RhbXAgDQo+ID4gbW9kdWxvIDU2IGJpdHMgcmFuZ2UsIGl0IGltcGxpZXMgYSB3cmFw IG9mIHRoZSA2NC1iaXQgc3BsaWNpbmctb3V0IA0KPiA+IE5UUC1mb3JtYXQgdGltZXN0YW1wIHdo aWNoIHdpbGwgdGhlbiBiZSBjYWxjdWxhdGVkIGJ5IHRoZSA3IG9jdGV0cyANCj4gPiBzcGxpY2lu Zy1vdXQgTlRQIHRpbWVzdGFtcCBwbHVzIDJeNjQuIE90aGVyd2lzZSwgdGhlIHRvcCA4IG9jdGV0 cyBvZiANCj4gPiBzcGxpY2luZy1vdXQgTlRQIHRpbWVzdGFtcCBpcyBlcXVhbCB0byB0aGUgdG9w IDggb2N0ZXRzIG9mIA0KPiA+IHNwbGljaW5nLWluIE5UUCB0aW1lc3RhbXAuICINCj4gDQo+IEht bSwgdGhpcyBhcHBlYXJzIHRvIGJlIHdyb25nIGFib3V0IHRoZSB3cmFwcGluZy4gVGhlIHdyYXBw aW5nIHRoYXQgaXMgDQo+IHRoZSBjb25jZXJuIGhlcmUgdGhhdCB3aGVuIHRoZSA1Ni1iaXQgdmFs dWUgb2YgdGhlIG91dCBpcyBzbWFsbGVyIHRoYW4gDQo+IHRoZSA1Ni1iaXQgdmFsdWUgb2YgdGhl IHNwbGljaW5nIGluIHBvaW50IHRoZW4gYSB3cmFwIG9mIHRoZSA1Ni1iaXQgDQo+IHZhbHVlIGhh cyBoYXBwZW5lZCB3aGljaCB3aWxsIHJlc3VsdCBpbiB0aGF0IG9uZSBuZWVkIHRvIGFkZCAweDAx IHRvIA0KPiB0aGUgdG9wIDgtYml0IHZhbHVlIGNvcGllZCBmcm9tIHRoZSBzcGxpY2luZyBpbiBw b2ludCB0byB0aGUgc3BsaWNpbmcgb3V0IHRvcCA4LWJpdCB2YWx1ZS4NCg0KDQpbUmFjaGVsXTog WW91J3JlIHJpZ2h0LiBUaGUgcHJldmlvdXMgcHJvcG9zYWwgaXMgY29tcGxldGVseSBtZXNzZWQg dXAuIEhlcmUncyB0aGUgbmV3IHByb3Bvc2FsOg0KDQoiDQpUaGUgdG9wIDggYml0cyBvZiB0aGUg c3BsaWNpbmctb3V0IE5UUCB0aW1lc3RhbXAgYXJlIGluZmVycmVkIGZyb20gdGhlIHRvcCA4IGJp dHMgb2YgdGhlIHNwbGljaW5nLWluIE5UUCB0aW1lc3RhbXAuIFRoaXMgaXMgdW5hbWJpZ3VvdXMs IHVuZGVyIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIHNwbGljaW5nLW91dCB0aW1lIGlzIGFmdGVy IHRoZSBzcGxpY2luZy1pbiB0aW1lLCBhbmQgdGhlIHNwbGljaW5nIGludGVydmFsIGlzIGxlc3Mg dGhhbiAyXjI1IHNlY29uZHMuIFRoZXJlZm9yZSwgaWYgdGhlIDcgb2N0ZXRzIHNwbGljaW5nLW91 dCBOVFAtZm9ybWF0IHRpbWVzdGFtcA0KaXMgc21hbGxlciB0aGFuIHRoZSB2YWx1ZSBvZiA3IGxv dyBvY3RldHMgc3BsaWNpbmctb3V0IE5UUC1mb3JtYXQsIGl0IGltcGxpZXMgYSB3cmFwIG9mIHRo ZSA1Ni1iaXQgc3BsaWNpbmctb3V0IE5UUC1mb3JtYXQJDQp0aW1lc3RhbXAgd2hpY2ggbWVhbnMg dGhlIHRvcCA4LWJpdCB2YWx1ZSBvZiB0aGUgNjQtYml0IHNwbGljaW5nLW91dCBpcyBlcXVhbCB0 byB0aGUgdG9wIDgtYml0IHZhbHVlIG9mIHNwbGljaW5nLWluIE5UUCBUaW1lc3RhbXAgcGx1cyAw eDAxLiBPdGhlcndpc2UsIHRoZSB0b3AgOCBiaXRzIG9mIHNwbGljaW5nLW91dCBOVFAgdGltZXN0 YW1wIGlzIGVxdWFsIHRvIHRoZSB0b3AgOCBiaXRzIG9mIHNwbGljaW5nLWluIE5UUCBUaW1lc3Rh bXAuDQoiDQo+IA0KPiANCj4gDQo+ID4NCj4gPj4NCj4gPj4gMy4gU2VjdGlvbiAzLjE6DQo+ID4+ DQo+ID4+IFRoaXMgc2VjdGlvbiBpcyBub3QgY2xlYXIgb24gd2hhdCBpcyB0aGUgZGF0YSBwYXJ0 IG9mIHRoZSBoZWFkZXIgDQo+ID4+IGV4dGVuc2lvbiBmb3JtYXQuIEFzIGl0IGlzIG5vdCB0aGUg aGVhZGVyIGV4dGVuc2lvbiB0aGF0IGNhbiANCj4gPj4gZGV0ZXJtaW5lIGlmIHRoZXJlIHdpbGwg YmUgdXNhZ2Ugb2Ygb25lLWJ5dGUgdnMgdHdvLWJ5dGUgZm9ybWF0IA0KPiA+PiB0aGF0IHdpbGwg YmUgdXNlZCwgdGhpcyBuZWVkcyB0byBiZSBkZWZpbmVkIGluIGEgbW9yZSB1bg0KPiA+DQo+ID4g W1JhY2hlbF06IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGlzLiBUaGUgZWRpdGluZyBzZWVtcyB1bmZp bmlzaGVkLiBUaGUgDQo+ID4gc3BsaWNpbmcgUlRQIGhlYWRlciBleHRlbnNpb24gdXNlcyBvbmUt Ynl0ZSBmb3JtYXQgd2l0aCB0aGUgZml4ZWQgDQo+ID4gYml0IHBhdHRlcm4gMHhCRURFLg0KPiAN Cj4gU29ycnksIHdoYXQgaXMgbWlzc2luZyBpczogVGhlIGRlZmluaXRpb24gb2YgdGhlIGRhdGEg ZmllbGQgbmVlZCB0byBiZSANCj4gZG9uZSBpbiBhIHdheSB0aGF0IGlzIGFnbm9zdGljIHRvIGlm IDEgb3IgMi1ieXRlIGhlYWRlcnMgYXJlIGJlaW5nIA0KPiB1c2VkIGluIHRoZSBoZWFkZXIgZXh0 ZW5zaW9uLg0KPg0KDQpbUmFjaGVsXTogSSBkb24ndCB1bmRlcnN0YW5kIHdoeSBzaG91bGQgdGhp cyBleHRlbnNpb24gdG8gYmUgYWdub3N0aWMgZm9yIGV4dGVuc2lvbiBoZWFkZXIgdHlwZXMuIFRo ZXJlJ3Mgbm8gc3VjaCBsaW1pdGF0aW9uIGluIFtSRkM1Mjg1XSBpZiBJIHJlYWQgaXQgY29ycmVj dGx5LiBBbmQgYmFzZWQgb24gW1JGQzUyODVdLCBpdCBzYXlzOg0KDQoiDQogICBUaGVyZSBhcmUg dHdvIHZhcmlhbnRzIG9mIHRoZSBleHRlbnNpb246IG9uZS1ieXRlIGFuZCB0d28tYnl0ZQ0KICAg aGVhZGVycy4gIFNpbmNlIGl0IGlzIGV4cGVjdGVkIHRoYXQgKGEpIHRoZSBudW1iZXIgb2YgZXh0 ZW5zaW9ucyBpbg0KICAgYW55IGdpdmVuIFJUUCBzZXNzaW9uIGlzIHNtYWxsIGFuZCAoYikgdGhl IGV4dGVuc2lvbnMgdGhlbXNlbHZlcyBhcmUNCiAgIHNtYWxsLCB0aGUgb25lLWJ5dGUgaGVhZGVy IGZvcm0gaXMgcHJlZmVycmVkIGFuZCBNVVNUIGJlIHN1cHBvcnRlZCBieQ0KICAgYWxsIHJlY2Vp dmVycy4gIEEgc3RyZWFtIE1VU1QgY29udGFpbiBvbmx5IG9uZS1ieXRlIG9yIHR3by1ieXRlDQog ICBoZWFkZXJzOiB0aGV5IE1VU1QgTk9UIGJlIG1peGVkIHdpdGhpbiBhIHN0cmVhbS4gIFRyYW5z bWl0dGVycyBTSE9VTEQNCiAgIE5PVCB1c2UgdGhlIHR3by1ieXRlIGZvcm0gd2hlbiBhbGwgZXh0 ZW5zaW9ucyBhcmUgc21hbGwgZW5vdWdoIGZvcg0KICAgdGhlIG9uZS1ieXRlIGhlYWRlciBmb3Jt Lg0KIg0KDQpGb3Igc3BsaWNpbmcgZXh0ZW5zaW9uLCBpdCBjYW4gYmUgY2xhc3NpZmllZCBpbnRv IGEpIGNhc2UuIFRoYXQncyB3aHkgd2UgdXNlcyBvbmUtYnl0ZSBoZWFkZXIsIGFuZCBpdCBpcyBw cmVmZXJyZWQgYW5kIG1hbmRhdGVkIGJ5IHJlY2VpdmVycy4gU28gSSBjYW4ndCBpbWFnaW5lIGFu eSBvdGhlciBjYXNlcyB0byB1c2UgMi1ieXRlIGhlYWRlci4gQW5kIGJ5IHRoZSB3YXksIFtSRkM2 MDUxXSBhbHNvIG9ubHkgZGVmaW5lcyBvbmUtYnl0ZSBoZWFkZXIuDQogDQo+ID4NCj4gPj4NCj4g Pj4gNC4gU2VjdGlvbiAzLjI6IFRoZSBSVENQIHNwbGljaW5nIG5vdGlmaWNhdGlvbiBtZXNzYWdl IGNhbiBiZSANCj4gPj4gYXBwZW5kZWQgdG8gUlRDUCBTUiB0aGUgbWFpbiBSVFAgc2VuZGVyIGdl bmVyYXRlcyBpbiBjb21wb3VuZCBSVENQIA0KPiA+PiBwYWNrZXRzLCBhbmQgaGVuY2UgZm9sbG93 cyB0aGUgY29tcG91bmQgUlRDUCBydWxlcyBkZWZpbmVkIGluIA0KPiA+PiBTZWN0aW9uIDYuMSBp biBbUkZDMzU1MF0uDQo+ID4+DQo+ID4+IEkgdGhpbmsgdGhlIHVzZSBvZiAiYXBwZW5kIHRvIFJU Q1AgU1IiIGlzIHVuZm9ydHVuYXRlLiBJIGJlbGlldmUgDQo+ID4+IHdoYXQgd291bGQgYmUgdGhl IHJpZ2h0IG1lc3NhZ2VzIGlzIHRvIHNheSB0aGF0IHRoZSBzcGxpY2luZyANCj4gPj4gbm90aWZp Y2F0aW9uIG1lc3NhZ2VzIGlzIGluY2x1ZGVkIGluIHRoZSBzYW1lIFJUQ1AgY29tcG91bmQgcGFj a2V0IA0KPiA+PiBhcyB0aGUgUlRDUCBTUiBmb3IgdGhlIG1haW4gUlRQIHN0cmVhbS4gVXNpbmcg dGhlIFNTUkMgdmFsdWVzIHRvIA0KPiA+PiByZWxhdGUgdGhlIHR3by4gVGhpcyBpcyBpbXBvcnRh bnQgYmVjYXVzZSB0aGVyZSBzaG91bGQgYmUgbm8gZm9ybWFsIA0KPiA+PiByZXF1aXJlbWVudCBv biBvcmRlcmluZyBiZXR3ZWVuIGluZGl2aWR1YWwgUlRDUCBwYWNrZXRzIHdpdGhpbiBhIA0KPiA+ PiBjb21wb3VuZCBwYWNrZXQuDQo+ID4NCj4gPiBbUmFjaGVsXTogR29vZCBwb2ludC4gSG93IGFi b3V0IGNoYW5naW5nIHRvDQo+ID4NCj4gPiAiIFRoZSBSVENQIHNwbGljaW5nIG5vdGlmaWNhdGlv biBtZXNzYWdlIGNhbiBiZSBpbmNsdWRlZCBpbiB0aGUgUlRDUCANCj4gPiBjb21wb3VuZCBwYWNr ZXQgdG9nZXRoZXIgd2l0aCBSVENQIFNSIGdlbmVyYXRlZCBhdCB0aGUgbWFpbiBSVFAgDQo+ID4g c2VuZGVyLCBhbmQgaGVuY2UgZm9sbG93cyB0aGUgY29tcG91bmQgUlRDUCBydWxlcyBkZWZpbmVk IGluIFNlY3Rpb24NCj4gPiA2LjEgaW4gW1JGQzM1NTBdLiAiDQo+ID4NCj4gDQo+IFllcywgdGhh dCB3b3VsZCB3b3JrLg0KPiANCj4gSSByZWFsaXplZCBub3cgdGhhdCB5b3UgaGF2ZW4ndCBleHBh bmRlZCBSVENQIFNSIG9uIGl0cyBmaXJzdCB1c2UuDQo+IFBsZWFzZSBkby4NCg0KW1JhY2hlbF06 IFdpbGwgZG8uDQoNCj4gDQo+ID4+DQo+ID4+DQo+ID4+IDUuIFNlY3Rpb24gMy4yOg0KPiA+Pg0K PiA+PiBUaGlzIGZvcm1hdCBpcyBzaW1pbGFyIHRvIHRoZSBSVENQIFNlbmRlciBSZXBvcnQgKFNl Y3Rpb24gNi40LjEgb2YNCj4gPj4gW1JGQzM1NTBdKQ0KPiA+Pg0KPiA+PiBXaHkgaXMgaXQgb25s eSBzaW1pbGFyIGFuZCBub3QgdGhlIHNhbWUgYXMgaW4gUkZDICAzNTUwPw0KPiA+Pg0KPiA+DQo+ ID4gW1JhY2hlbF06IEFjdHVhbGx5IGl0J3MgdGhlIHNhbWUuIEJhZCB3b3JkaW5nOiguDQo+ID4N Cj4gPj4NCj4gPj4gNi4gU2VjdGlvbiAzLjI6DQo+ID4+DQo+ID4+IElmIHRoZSB1c2Ugb2Ygbm9u LWNvbXBvdW5kIFJUQ1AgW1JGQzU1MDZdIHdhcyBwcmV2aW91c2x5IG5lZ290aWF0ZWQgDQo+ID4+ IGJldHdlZW4gdGhlIHNlbmRlciBhbmQgdGhlIHNwbGljZXIsIHRoZSBSVENQIHNwbGljaW5nIG5v dGlmaWNhdGlvbiANCj4gPj4gbWVzc2FnZSBtYXkgYmUgc2VudCBhcyBub24tY29tcG91bmQgUlRD UCBwYWNrZXRzLg0KPiA+Pg0KPiA+PiBJIHdvbmRlciBvdmVyIHRoaXMsIEkgd29uZGVyIGlmIHRo aXMgUlRDUCBwYWNrZXQgdHlwZSByZWFsbHkgc2hvdWxkIA0KPiA+PiBiZSBzZW50IGluIGFuIFJU Q1Agbm9uLWNvbXBvdW5kIHBhY2tldCB3aXRob3V0IHRoZSBjb3JyZXNwb25kaW5nIA0KPiA+PiBS VENQIFNSIHBhY2tldD8gVGhlIHJlYXNvbiBJIHN0YXRlIHRoaXMgaXMgdGhhdCB0aGUgUlRQIG1h aW4gc2VuZGVyIA0KPiA+PiBoYXMgdG8gdXNlIFNSL1JSIHJlcG9ydCBibG9jayBMU1IgZmllbGQg dG8gZGV0ZXJtaW5lIHdoaWNoIGlzIHRoZSANCj4gPj4gbGF0ZXN0IHJlY2VpdmVkIFJUQ1AgU1Ig cGFja2V0IGZvciB0aGUgU1NSQyBpbiB0aGUgc3BsaWNpbmcgUlRDUCANCj4gPj4gcGFja2V0LiBB bmQgZHVlIHRvIHRpbWluZyBvZiBSVENQIHBhY2tldCB0cmFuc21pc3Npb24gdGhhdCBjYW4gYmUg DQo+ID4+IG9sZCBpbmZvcm1hdGlvbi4gIFRodXMsIHRoZSBzcGxpY2VyIGNhbiBvcGVyYXRlIG9u IFJUUCB0byBOVFAgDQo+ID4+IFRpbWVzdGFtcHMgdGhhdCBhcmUgbm90IGN1cnJlbnQuIFRodXMs IEkgdGhpbmsgaXQgd291bGQgYmUgYSANCj4gPj4gcmVjb21tZW5kYXRpb24gdG8gaW5jbHVkZSB0 aGUgUlRDUCBTUiB3aXRoIHRoZSBzcGxpY2luZyBwYWNrZXQuIEl0IA0KPiA+PiBjYW4gc3RpbGwg YmUgYSBub24tY29tcG91bmQgYXMgb25lIGNvdWxkIGxlYXZlIG91dCB0aGUgU0RFUyBDTkFNRSAN Cj4gPj4gaXRlbXMuDQo+ID4NCj4gPiBbUmFjaGVsXTogTWF5YmUgSSBnb3QgaXQgd3JvbmcuIEJ1 dCBhcmUgeW91IHNheWluZyB0aGF0IHRoZSBhY2N1cmFjeSANCj4gPiBvZiBtYXBwaW5nIFJUUCB0 aW1lc3RhbXAgdG8gTlRQIHRpbWVzdGFtcCwgd2hpY2ggc2hvdWxkIGJlIGRlZHVjZWQgDQo+ID4g YnkgdGhlIGluZm9ybWF0aW9uIGluIHRoZSBSVENQIFNSIHRoYXQgc2hvdWxkIGJlIGFzIGNsb3Nl IGFzIHRoZSANCj4gPiBzcGxpY2luZyBzdGFydHM/IEJ1dCB0aGUgUlRDUCBzcGxpY2luZyBtZXNz YWdlIGlzIHNlbnQgZmFyIGFoZWFkIG9mIA0KPiA+IHRoZSBzcGxpY2luZyBoYXBwZW5zLCBhbmQg c2hvdWxkIGJlIHNlbnQgbW9yZSB0aGFuIG9uY2UgdG8gaW5jcmVhc2UgDQo+ID4gcm9idXN0bmVz cy4gRm9yIGV4YW1wbGUsIG1heSBiZSBzZXZlcmFsIFJUVHMgYWhlYWQuIFNvIGluIGEgDQo+ID4g bm9uLWNvbXBvdW5kIGNhc2UsIGl0IGlzIHBvc3NpYmxlIHRoYXQgYSBSVENQIFNSIHdpbGwgYmUg c2VudCBhZnRlciANCj4gPiBhIFJUQ1Agc3BsaWNpbmcgbWVzc2FnZSwgaGVuY2UgaXQgc2VlbXMg bm8gbWVhbmluZyB0byBpbmNsdWRlIFJUQ1AgDQo+ID4gU1Igd2l0aCBSVENQIHNwbGljaW5nIG1l c3NhZ2VzLg0KPiANCj4gU28sIHllcyB0aGluZ3Mgd2lsbCB3b3JrIGFzIGxvbmcgYXMgdGhlIFJU UCB0byBOVFAgbWFwcGluZyB0aGUgaW4gdGhlIA0KPiBzcGxpY2VyIGlzIGNvcnJlY3QuIEhvd2V2 ZXIsIGluIHNvbWUgY2FzZXMgc2l0dWF0aW9ucyBjYW4gb2NjdXIgdGhhdCANCj4gd2lsbCBtb2Rp ZnkgdGhlIFJUUCB0byBOVFAgbWFwcGluZyBiZXR3ZWVuIHRoZSBhIHByZXZpb3VzIHNlbmRpbmcg b2YgDQo+IHRoZSBTcGxpY2luZyBtZXNzYWdlIGFuZCB0aGUgYWN0dWFsIHNwbGljaW5nIHN0YXJ0 IG9yIHN0b3AuDQo+IA0KPiBTbyB3aGVuIGRvZXMgdGhlIFJUUCB0byBOVFAgbWFwcGluZyBjaGFu Z2U/DQo+IA0KPiAxLiBJZiB0aGUgUGF5bG9hZCBUeXBlIGNoYW5nZXMgYW5kIHRoZSBjbG9jayBy YXRlIGNoYW5nZXMgYW5kIHRoZSANCj4gc3lzdGVtIGRvZXMgbm90IGZvbGxvdyB0aGUgcmVjb21t ZW5kYXRpb25zIGluIFJGQyA3MTYwLiBIb3dldmVyIHRoaXMgDQo+IGlzIGxpa2VseSB0aGUgbGVh c3QgbGlrZWx5IHJlYXNvbi4NCj4gDQo+IDIuIFRoZSBtb3JlIGNvbW1vbiByZWFzb24gd2lsbCBi ZSBjbG9jayBkcmlmdC4gSWYgdGhlIHN5c3RlbSB3YWxsIA0KPiBjbG9jayBwcm9ncmVzc2VzIGF0 IGEgcmF0ZSB0aGF0IGlzIG5vdCBtYXRjaGluZyB0aGUgUlRQIHRpbWVzdGFtcCANCj4gcmF0ZSwg dGhlbiBwZXJpb2RpY2FsbHkgYWRqdXN0bWVudHMgbWF5IG9jY3VyLiBUaHVzIGNoYW5naW5nIHRo ZSBSVFAgdG8gTlRQIG1hcHBpbmcuDQo+IA0KPiBUaGUgaXNzdWUgd2l0aCBjaGFuZ2luZyBtYXBw aW5nIGlzIHRoYXQgb25lIG5lZWRzIHRvIGtub3cgaWYgaXQgaXMgdGhlIA0KPiBSVFAgdGltZWxp bmUgb3IgdGhlIE5UUCB3YWxsIGNsb2NrIHRoYXQgaXMgdGhlIG1vc3QgcmVsZXZhbnQgZm9yIHdo ZW4gDQo+IHRoZSBzcGxpY2luZyBzaG91bGQgb2NjdXIuIElmIGl0IGlzIHRoZSBSVFAgb25lLCBk dWUgdG8gdGhhdCBhIA0KPiBzcGVjaWZpYyBhbW91bnQgb2YgbWVkaWEgc2FtcGxlcyBuZWVkcyB0 byBoYXZlIGJlZW4gcHJvY2Vzc2VkLiBJbiANCj4gb3RoZXIgd29yZHMgdGhlIGJvdW5kYXJ5IGlu IHRoZSBhY3R1YWwgY29udGVudCBpcyBrbm93biBhbmQgZGV0ZXJtaW5lcyANCj4gd2hlbiB0aGUg c3BsaWNlIHNob3VsZCBoYXBwZW4uIFRoaXMgSSBmaW5kIGxpa2VseSBmb3IgcHJlLXJlY29yZGVk IGNvbnRlbnQuDQo+IA0KPiBCdXQsIEkgdGhpbmsgSSBhY3R1YWxseSBtaXNyZXByZXNlbnRlZCB0 aGUgaXNzdWUuIEkgYWdyZWUgdGhhdCBpdCBpcyANCj4gbm90IG5lY2Vzc2FyeSB0aGF0IG9uZSBo YXZlIHRoZSBTUiBhbmQgc3BsaWNpbmcgbWVzc2FnZXMgaW4gdGhlIHNhbWUgDQo+IGNvbXBvdW5k IG9yIHJlZHVjZWQgc2l6ZSBSVENQIHBhY2tldC4gSXQgaXMgdGhhdCBvbmUgYWNrbm93bGVkZ2Ug d2hhdCANCj4gb2NjdXJzIGlmIG9uZSBkbyByZWNlaXZlIG9yIG5vdCByZWNlaXZlIGFuIHVwZGF0 ZSBpZiB0aGUgbWFwcGluZyBoYXMgDQo+IGJlZW4gdXBkYXRlZCBiZXR3ZWVuIGluaXRpYWwgc3Bs aWNpbmcgaW5mb3JtYXRpb24gdHJhbnNtaXNzaW9uIGFuZCB0aGUgDQo+IGltcGxlbWVudGF0aW9u Lg0KPiANCj4gRGlmZmVyZW50IG91dGNvbWVzIG9jY3VyIGRlcGVuZGluZyBvbiB3aGljaCB0aW1l c2NhbGUgaXMgdGhlIHByaW1hcnkgDQo+IG9uZSBmb3Igd2hlbiB0aGUgc3BsaWNpbmcgc2hvdWxk IG9jY3VyLg0KPiANCj4gSWYgUlRQIHRpbWVsaW5lIGlzIHRoZSBpbXBvcnRhbnQuIFRoZW4gYW4g dXBkYXRlIG9mIHRoZSBSVFAgdG8gTlRQIA0KPiBtYXBwaW5nIHJlcXVpcmVzIGFuIHVwZGF0ZWQg TlRQIGZvcm1hdGVkIHNwbGljaW5nIHBvaW50LiBJbiB0aGlzIGNhc2UgDQo+IHRoZSBiZXN0IHRo YXQgb25lIGNhbiBkbyBpcyBzZW5kIGJvdGggU3BsaWNpbmcgaW5mbyBhbmQgUlRDUCBTUi4gWW91 IA0KPiBuZWVkIGJvdGggdG8gY29ycmVjdGx5IHNwbGljZS4NCj4gDQo+IElmIHRoZSBOVFAgdGlt ZWxpbmUgaXMgdGhlIG9uZSB0aGF0IG1hdHRlcnMsIHRoZW4gYW4gdXBkYXRlZCBSVFAgdG8gDQo+ IE5UUCBtYXBwaW5nIG9ubHkgbmVlZHMgdGhlIG5ldyB2YWx1ZXMgaW4gdGhlIFJUQ1AgU1IsIG5v IG5ldyBzcGxpY2luZyANCj4gbWVzc2FnZSBpcyBuZWVkZWQuDQo+IA0KPiBUbyBjb25jbHVkZSwg d2hhdCBtaWdodCBiZSBuZWVkZWQgaXMgYWN0dWFsbHkgcmF0aGVyIGEgY29tbWVudCBvbiB0aGF0 IA0KPiB1cGRhdGVkIGluZm9ybWF0aW9uIG1heSBvY2N1ciwgYW5kIGluIGNlcnRhaW4gY2FzZXMg Ym90aCB0aGUgc3BsaWNpbmcgDQo+IGludGVydmFsIGFuZCB0aGUgUlRDUCBTUiBpcyBuZWVkZWQg dG8gY29ycmVjdGx5IHNwbGljZS4NCg0KW1JhY2hlbF06IE9rYXkuIEkgZ2V0IHlvdXIgcG9pbnQu IFNvIGhvdyBhYm91dCBhZGRpbmcgc29tZSB0ZXh0cyBhcyBmb2xsb3dpbmcgaW4gU2VjdGlvbiAz LjIsIHRoZSBsYXN0IDJuZCBwYXJhZ3JhcGg/DQoNCiINCkluIGNhc2VzIG9mIHRoZSBtYXBwaW5n IGZyb20gUlRQIHRpbWVzdGFtcCB0byBOVFAgdGltZXN0YW1wIGNoYW5nZXMsIGUuZy4sIGNsb2Nr IGRyaWZ0IGhhcHBlbmluZyBiZWZvcmUgdGhlIHNwbGljaW5nIGV2ZW50LCBpdCBtYXkgYmUgcmVx dWlyZWQgdG8gc2VuZCBSVENQIFNSIG9yIGV2ZW4gdXBkYXRlZCBTcGxpY2luZyBJbnRlcnZhbCBp bmZvcm1hdGlvbiB0aW1lbHkgdG8gdXBkYXRlIHRoZSB0aW1lc3RhbXAgbWFwcGluZyBmb3IgYWNj dXJhdGUgc3BsaWNpbmcuDQoiDQoNCj4gDQo+IA0KPiANCj4gPg0KPiA+Pg0KPiA+PiA3LiBTZWN0 aW9uIDYuMjoNCj4gPj4NCj4gPj4gT25seSBjb2RlY3MgdGhhdCBhcmUgc3VwcG9ydGVkIGJvdGgg YnkgdGhlIG1haW4gUlRQIHN0cmVhbSBhbmQgdGhlIA0KPiA+PiBzdWJzdGl0dXRpdmUgUlRQIHN0 cmVhbSBjb3VsZCBiZSBuZWdvdGlhdGVkIHdpdGggU0RQIE8vQS4gQW5kIHRoZSANCj4gPj4gc3Bs aWNlciBNVVNUIGNob29zZSB0aGUgc2FtZSBjb2RlYyBmb3IgYm90aCBvZiB0aGVzZSB0d28gc3Ry ZWFtcy4NCj4gPj4NCj4gPj4gU28gdGhpcyBwYXlsb2FkIHR5cGUgcmVzdHJpY3Rpb24gaXMgaW4g bXkgdmlldyBpbiB0aGUgd3JvbmcgcGxhY2UgDQo+ID4+IGFuZCBub3QgY2xlYXIgZW5vdWdoLiBT bywgdG8gYmUgYWJsZSB0byBzcGxpY2UgaW50byBvbmUgY29uc2lzdGVudCANCj4gPj4gb3V0Z29p bmcgc3RyZWFtIHRoZXJlIGlzIGEgYmFzaWMgcmVxdWlyZW1lbnQgdGhhdCB0aGUgUlRQIFBheWxv YWQgDQo+ID4+IFR5cGVzIHVzZWQgYXJlIGhhdmluZyB0aGUgc2FtZSBjbG9jayByYXRlLCBvdGhl cndpc2UgUkZDIDcxNjAgDQo+ID4+IGFwcGxpZXMsIGFzIHVuY2VydGFpbnR5IGFib3V0IGhvdyBS VFAgbWFwcyB0byBOVFAgYW5kIHNwbGljaW5nIA0KPiA+PiBhcHBlYXJzIHRvIGJlIGEgYmFkIG1p eC4NCj4gPg0KPiA+IFtSYWNoZWxdOiBBY3R1YWxseSwgdGhpcyBoYXMgYmVlbiBkZXNjcmliZWQg aW4gU2VjdGlvbiAyLCAzcmQgDQo+ID4gcGFyYWdyYXBoLiBJdCBzYXlzDQo+ID4NCj4gPiAiIFRv IGVuc3VyZSB0aGUgU3BsaWNpbmcgSW50ZXJ2YWwgaXMgdmFsaWQgZm9yIGJvdGggdGhlIG1haW4g UlRQIA0KPiA+IHNlbmRlciBhbmQgdGhlIHN1YnN0aXR1dGl2ZSBSVFAgc2VuZGVyLCB0aGUgdHdv IHNlbmRlcnMgTVVTVCBzaGFyZSBhIA0KPiA+IGNvbW1vbiByZWZlcmVuY2UgY2xvY2sgc28gdGhh dCB0aGUgc3BsaWNlciBjYW4gYWNoaWV2ZSBhY2N1cmF0ZSANCj4gPiBzcGxpY2luZy4gVGhlIHJl cXVpcmVtZW50cyBmb3IgdGhlIGNvbW1vbiByZWZlcmVuY2UgY2xvY2sgKGUuZy4NCj4gPiByZXNv bHV0aW9uLCBza2V3KSBkZXBlbmQgb24gdGhlIGNvZGVjIHVzZWQgYnkgdGhlIG1lZGlhIGNvbnRl bnQuICINCj4gPg0KPiA+Pg0KPiA+PiBGdXJ0aGVyIGlmIG9uZSBpcyBnb2luZyB0byBleHByZXNz IHRoaXMgaW4gdGhpcyBtb3JlIHJlc3RyaWN0aXZlIA0KPiA+PiB3YXkgb2YgZGVtYW5kaW5nIHRo ZSBzYW1lIGNvZGVzLCB0aGVuIEkgZG8gd29uZGVyIGlmIG9uZSBhY3R1YWxseSANCj4gPj4gZG9u J3QgbmVlZCB0byBnbyBhcyBmYXIgYXMgc2F5aW5nIHRoYXQgdGhlIHNhbWUgcGF5bG9hZCB0eXBl IA0KPiA+PiBjb25maWd1cmF0aW9ucyBuZWVkcyB0byBiZSBwb3NzaWJsZSB0byB1cyBpbiBib3Ro IG1haW4gYW5kIA0KPiA+PiBzdWJzdGl0dXRlIHN0cmVhbXMuDQo+ID4NCj4gPiBbUmFjaGVsXTog U28geW91J3JlIHN1Z2dlc3RpbmcgdGhhdCB3ZSBkZWxldGUgdGhpcyBzZW50ZW5jZT8NCj4gDQo+ IFllcywgdGhlIHNlY3Rpb24geW91IHF1b3RlIGFib3ZlIGFscmVhZHkgaGF2ZSBhIHJlc3RyaWN0 aW9uIHVzaW5nIFJGQw0KPiAyMTE5IHRlcm1zLiBJc24ndCB0aGF0IHN1ZmZpY2llbnQ/DQo+IA0K PiA+DQo+ID4+DQo+ID4+IDguIFNlY3Rpb24gNzoNCj4gPj4NCj4gPj4gSSBmaW5kIGEgc2lnbmlm aWNhbnQgc2hvcnQgY29taW5nIGluIHRoaXMgc2VjdXJpdHkgY29uc2lkZXJhdGlvbi4NCj4gPj4g VGhhdCBpcyB0aGUgZmFpbHVyZSB0byBkaXNjdXNzIHRoZSBpbXBvcnRhbmNlIGZvciB0aGUgc3Bs aWNlciB0byBiZSANCj4gPj4gYWJsZSB0byB0cnVzdCB0aGUgc3BsaWNpbmcgaW50ZXJ2YWwgaW5m b3JtYXRpb24gZnJvbSB0aGUgbWFpbiBSVFAgDQo+ID4+IHNlbmRlci4gVGhpcyBpbmZvcm1hdGlv biByZWFsbHkgc2hvdWxkIGJlIGF1dGhlbnRpY2F0ZWQgYW5kIA0KPiA+PiBpbnRlZ3JpdHkgcHJv dGVjdGVkIGJldHdlZW4gdGhlIG1haW4gUlRQIHNlbmRlciBhbmQgdGhlIHNwbGljZXIuDQo+ID4+ DQo+ID4+IFRodXMsIEkgYW0gcXVpdGUgd29ycmllZCBhYm91dCB0aGlzIHBhcmFncmFwaDoNCj4g Pj4NCj4gPj4gU2luY2UgdGhlIG1lY2hhbmlzbSBpbnRyb2R1Y2VkIGluIHRoaXMgZG9jdW1lbnQg aXMgbm90IGRlcGVuZGVudCBvbiANCj4gPj4gYW55IFJUUCBwYXlsb2FkLWxldmVsIGhpbnRzIGZv ciBmaW5kaW5nIHRoZSBzcGxpY2luZyBpbiBhbmQgb3V0IA0KPiA+PiBwb2ludHMsIFNlY3VyZSBS ZWFsLVRpbWUgVHJhbnNwb3J0IFByb3RvY29sIChTUlRQKSBbMzcxMV0gY2FuIGJlIA0KPiA+PiB1 c2VkIHRvIHByb3ZpZGUgY29uZmlkZW50aWFsaXR5IG9mIHRoZSBSVFAgcGF5bG9hZCB3aGlsZSBs ZWF2aW5nIA0KPiA+PiB0aGUgUlRQIGhlYWRlciBpbiB0aGUgY2xlYXIgc28gdGhhdCB0aGUgc3Bs aWNlciBjYW4gc3RpbGwgY2Fycnkgb3V0IA0KPiA+PiBzcGxpY2luZyB3aXRob3V0IGtleWluZyBt YXRlcmlhbHMuIEhvd2V2ZXIsIGZvciBhIG1hbGljaW91cyANCj4gPj4gZW5kcG9pbnQgd2l0aG91 dCB0aGUga2V5LCBpdCBjYW4gb2JzZXJ2ZSB0aGUgc3BsaWNpbmcgdGltZSBpbiB0aGUgDQo+ID4+ IFJUUCBoZWFkZXIsIGFuZCBpdCBjYW4gaW50ZXJjZXB0IHRoZSBzdWJzdGl0dXRpdmUgY29udGVu dCBhbmQgZXZlbiANCj4gPj4gcmVwbGFjZSBpdCB3aXRoIGEgZGlmZmVyZW50IG9uZSBpZiB0aGUg c3Vic3RpdHV0aXZlIHN0cmVhbSBkb2VzIG5vdCANCj4gPj4gdXNlIGFueSBzZWN1cml0eSBsaWtl IFNSVFAgYW5kIHRoZSBzcGxpY2VyIGRvZXMgbm90IGF1dGhlbnRpY2F0ZSANCj4gPj4gdGhlIG1h aW4gYW5kIHN1YnN0aXR1dGl2ZSBjb250ZW50IHNvdXJjZXMuDQo+ID4+DQo+ID4+IEluIHRoZSBl bmQgaXQgaGludHMgdG93YXJkcyB0aGUgbmVlZCBmb3IgYXV0aGVudGljYXRpb24gb2YgdGhlIA0K PiA+PiBzdHJlYW1zLiBCdXQgdGhhdCByZWFsbHkgc2hvdWxkIGJlIHdvcmRlZCBpbiBhIHN0cm9u Z2VyIHdheSBhcyBhIA0KPiA+PiByZXF1aXJlbWVudCBmb3Igc2VjdXJpdHkuDQo+ID4+DQo+ID4+ IEkgZG8gdW5kZXJzdGFuZCB0aGF0IHRoaXMgaXMgcmVhbGx5IGEgY2FzZSB3aGVyZSB0d28gbGF5 ZXJzIG9mIA0KPiA+PiBzZWN1cml0eSB3b3VsZCBiZSBnb29kLiBPbmUgYmV0d2VlbiB0aGUgbWFp biBhbmQgc3Vic3RpdHV0ZSBzZW5kZXIgDQo+ID4+IGFuZCB0aGUgaW50ZW5kZWQgcmVjZWl2ZXIs IGFuZCBhbiBvdXRlciBsYXllciBmb3Igc2VuZGVyIHRvIA0KPiA+PiBzcGxpY2VyLiBIb3dldmVy LCBJIGRvbid0IGFyZ3VlIHRoYXQgc3VjaCBhIHNvbHV0aW9uIG5lZWRzIHRvIGJlIA0KPiA+PiBj cmVhdGVkLiBJIHRoaW5rIGhhdmluZyB0aGUgc3BsaWNlciBhcyBhIHRydXN0ZWQgZW50aXR5IGlz IG1vcmUgDQo+ID4+IGxpa2VseSB0byBiZSBhIHJlYXNvbmFibGUgZGVwbG95bWVudCBtb2RlbC4N Cj4gPg0KPiA+DQo+ID4gW1JhY2hlbF06IE9rYXkuIEhvdyBhYm91dCBBZGQgYSBuZXcgcGFyYWdy YXBoIGFmdGVyIHRoZSAzcmQgDQo+ID4gcGFyYWdyYXBoIGluIFNlY3Rpb24gNz8NCj4gPg0KPiA+ ICIgVG8gYXZvaWQgYWJvdmUgc2VjdXJpdHkgaXNzdWUsIHRoZSBhdXRoZW50aWNhdGlvbiBvZiB0 aGUgbWFpbiBhbmQgDQo+ID4gc3Vic3RpdHV0aXZlIGNvbnRlbnQgc291cmNlcyBpbiB0aGUgc3Bs aWNlciBTSE9VTEQgYmUgY29uc2lkZXJlZC4NCj4gPiBIb3dldmVyLCBzZXBhcmF0aW5nIHRoZSBz ZWN1cml0eSBtZWNoYW5pc20gYmV0d2VlbiBzZW5kZXJzIGFuZCB0aGUgDQo+ID4gc3BsaWNlciBm cm9tIHRoZSBlbmQtdG8tZW5kIG9uZSBtYXkgY29tcGxpY2F0ZSB0aGUgd2hvbGUgc3lzdGVtIA0K PiA+IGRlcGxveW1lbnQuIEluIHN1Y2ggYSBjYXNlLCBoYXZpbmcgdGhlIHNwbGljZXIgYXMgYSB0 cnVzdGVkIGVudGl0eSANCj4gPiBpcyBsaWtlbHkgdG8gYmUgYSByZWFzb25hYmxlIGRlcGxveW1l bnQgbW9kZWwuICINCj4gDQo+IE5vLCBJIGRvbid0IHRoaW5rIHRoaXMgYWRkcmVzc2VzIHRoZSBp c3N1ZS4gVGhlIHNlY29uZCBwYXJhZ3JhcGggDQo+IGFscmVhZHkgZGVzY3JpYmVzIHRoZSB0cnVz dCBtb2RlbCwgb2YgdGhlIHRydXN0ZWQgc3BsaWNlci4gRXNwZWNpYWxseSANCj4gYXMgbm8gYWx0 ZXJuYXRpdmUgZG8geWV0IGV4aXN0LiBBbHRob3VnaCBQRVJDIFdHIGV4aXN0cyBhbmQgd29ya2lu ZyBvbiANCj4gYSBtb2RlbCB3aXRoIGVuZC10by1lbmQgY29uZmlkZW50aWFsaXR5LCB3aGljaCBj b3VsZCBwb3NzaWJseSB3b3JrLiANCj4gVGhhdCBpcyBub3QgYSBncmVhdCBtYXRjaCBlaXRoZXIg Zm9yIHdoYXQgSSB0aGluayBhcmUgdGhlIHNlY3VyaXR5IA0KPiByZXF1aXJlbWVudHMgZm9yIHNl cnZpY2VzIHRoYXQgdXNlcyBzcGxpY2luZy4NCj4gDQo+IEkgdGhpbmsgd2hhdCBuZWVkcyB0byBv Y2N1ciBpcyB0byByZXdyaXRlIHRoZSB0aGlyZCBwYXJhZ3JhcGggZnJvbSB0aGUgDQo+IHBlcnNw ZWN0aXZlIHRoYXQgdGhlIHNwbGljZXIgaXMgdHJ1c3RlZC4gRXNwZWNpYWxseSBhcyB0aGUgc3Ry ZWFtIHRoZSANCj4gc3BsaWNlciBmb3J3YXJkcyB3aWxsIG5vdCBtYXRjaCB0aGUgcmVjZWl2ZWQg b25lIGZyb20gYSBwZXJzcGVjdGl2ZSBvZiANCj4gbnVtYmVyIG9mIHBhY2tldHMgYW5kIGJ5dGVz LCB0aHVzIHJlcXVpcmluZyBSVENQIGNoYW5nZXMuIFRoaXMgaXMgd2h5IA0KPiBhIHRyYW5zbGF0 b3Igb3IgbWl4ZXIgbW9kZWwgaXMgcmVxdWlyZWQuIFRodXMsIHRoZSBwYWNrZXQgZm9yd2FyZGVk IA0KPiBmcm9tIHRoZSBzcGxpY2VyIHRvIHRoZSByZWNlaXZlciB3aWxsIG5vdCBiZSBjb25zaXN0 ZW50IHdpdGggZWl0aGVyIA0KPiB0aGUgb3JpZ2luYWwgb3IgdGhlIHN1YnN0aXR1dGlvbiBzdHJl YW0uIEZvciB0aGUgYXV0aGVudGljYXRpb24gYW5kIA0KPiBpbnRlZ3JpdHkgcHJvdGVjdGlvbiB0 byBub3QgYmxvdyB1cCB0aGUgU1JUUCBrZXlzIHdpbGwgYmUgbmVlZGVkLiBBIA0KPiBkaXZpc2lv biBvZiB0aGUgcm9sZXMgb2YgaW50ZWdyaXR5IHZlcnN1cyBjb25maWRlbnRpYWxpdHkgYW5kIHlv dSBhcmUgDQo+IGJhY2sgaW50byBQRVJDIHRlcnJpdG9yeS4NCj4gDQo+IFRodXMsIHRoZSBkaXNj dXNzaW9uIG9mIGhlYWRlciBleHRlbnNpb24gZW5jcnlwdGlvbiBpcyBtb3RlLiBSYXRoZXIgDQo+ IGRpc2N1c3MgdGhhdCB0aGUgc3BsaWNlciBzaG91bGQgdXNlIGF1dGhlbnRpY2F0ZWQgYW5kIGlu dGVncml0eSANCj4gcHJvdGVjdGVkIHN0cmVhbXMgdG8gcHJldmVudCB0aGlyZCBwYXJ0aWVzIGZy b20gY29udHJvbGxpbmcgdGhlIA0KPiBzcGxpY2luZyBhcyB3ZWxsIGFzIHRoZSBzdWJzdGl0dXRp b24gY29udGVudC4NCg0KW1JhY2hlbF06IEhlcmUncyBteSBwcm9wb3NhbCB0byByZXdyaXRlIDNy ZCBwYXJhZ3JhcGggdG8gZGlzY3VzcyB0aGUgYXV0aGVudGljYXRpb24gYmV0d2VlbiBzcGxpY2Vy IGFuZCByZWNlaXZlci4gSXMgaXQgd2hhdCB5b3UncmUgbG9va2luZyBmb3I/DQoiDQpTaW5jZSBz cGxpY2VyIHdvcmtzIGFzIGEgdHJ1c3RlZCBlbnRpdHksIGFueSBSVFAtbGV2ZWwgb3Igb3V0c2lk ZSBzZWN1cml0eSBtZWNoYW5pc20sIHN1Y2ggSVBzZWNbUkZDNDMwMV0gb3IgRGF0YWdyYW0gVHJh bnNwb3J0IExheWVyIFNlY3VyaXR5IFtSRkM2MzQ3XSwgd2lsbCB1c2UgYSBzZWN1cml0eSBhc3Nv Y2lhdGlvbiBiZXR3ZWVuIHRoZSBzcGxpY2VyIGFuZCB0aGUgcmVjZWl2ZXIuIFdoZW4gdXNpbmcg dGhlIFNlY3VyZSBSZWFsLVRpbWUgVHJhbnNwb3J0IFByb3RvY29sIChTUlRQKSBbUkZDMzcxMV0s IHRoZSBzcGxpY2VyIGNvdWxkIGJlIHByb3Zpc2lvbmVkIHdpdGggdGhlIHNhbWUgc2VjdXJpdHkg YXNzb2NpYXRpb24gYXMgdGhlIG1haW4gUlRQIHNlbmRlci4NCiINCg0KPiANCj4gPg0KPiA+Pg0K PiA+PiBJIGRvIG5vdGUgdGhhdCBzcGxpY2luZyBkbyBoYXZlIHRoZSBpc3N1ZSBmcm9tIGtleS1t YW5hZ2VtZW50IA0KPiA+PiBwZXJzcGVjdGl2ZSB0aGF0IGJvdGggbWFpbiBhbmQgc3Vic3RpdHV0 ZSBzZW5kZXIgbmVlZHMgdG8gdXNlIHRoZSANCj4gPj4gc2FtZSBrZXkgaWYgdGhlIHNlY3VyaXR5 IGlzIGZyb20gc2VuZGVyIHRvIHJlY2VpdmVyLCByYXRoZXIgdGhhbiANCj4gPj4gc3BsaWNlciB0 byByZWNlaXZlci4NCj4gPg0KPiA+IFtSYWNoZWxdOiBZZXMuIEkgcGxhbiB0byBhZGQgYSBzZW50 ZW5jZSBpbiB0aGUgcGFyYWdyYXBoIDMgbGlrZQ0KPiA+IHRoaXM6DQo+ID4NCj4gPiBPTEQgIiBT aW5jZSB0aGUgbWVjaGFuaXNtIGludHJvZHVjZWQgaW4gdGhpcyBkb2N1bWVudCBpcyBub3QgDQo+ ID4gZGVwZW5kZW50IG9uIGFueSBSVFAgcGF5bG9hZC1sZXZlbCBoaW50cyBmb3IgZmluZGluZyB0 aGUgc3BsaWNpbmcgaW4gDQo+ID4gYW5kIG91dCBwb2ludHMsIFNlY3VyZSBSZWFsLVRpbWUgVHJh bnNwb3J0IFByb3RvY29sIChTUlRQKSBbUkZDMzcxMV0gDQo+ID4gY2FuIGJlIHVzZWQgdG8gcHJv dmlkZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlIFJUUCBwYXlsb2FkIHdoaWxlIA0KPiA+IGxlYXZp bmcgdGhlIFJUUCBoZWFkZXIgaW4gdGhlIGNsZWFyIHNvIHRoYXQgdGhlIHNwbGljZXIgY2FuIHN0 aWxsIA0KPiA+IGNhcnJ5IG91dCBzcGxpY2luZyB3aXRob3V0IGtleWluZyBtYXRlcmlhbHMuICIN Cj4gPg0KPiA+IE5FVyAiIFNpbmNlIHRoZSBtZWNoYW5pc20gaW50cm9kdWNlZCBpbiB0aGlzIGRv Y3VtZW50IGlzIG5vdCANCj4gPiBkZXBlbmRlbnQgb24gYW55IFJUUCBwYXlsb2FkLWxldmVsIGhp bnRzIGZvciBmaW5kaW5nIHRoZSBzcGxpY2luZyBpbiANCj4gPiBhbmQgb3V0IHBvaW50cywgU2Vj dXJlIFJlYWwtVGltZSBUcmFuc3BvcnQgUHJvdG9jb2wgKFNSVFApIFtSRkMzNzExXSANCj4gPiBj YW4gYmUgdXNlZCB0byBwcm92aWRlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGUgUlRQIHBheWxvYWQg d2hpbGUgDQo+ID4gbGVhdmluZyB0aGUgUlRQIGhlYWRlciBpbiB0aGUgY2xlYXIgc28gdGhhdCB0 aGUgc3BsaWNlciBjYW4gc3RpbGwgDQo+ID4gY2Fycnkgb3V0IHNwbGljaW5nIHdpdGhvdXQga2V5 aW5nIG1hdGVyaWFscy4gVGhpcyBpbXBsaWVzIHRoYXQgDQo+ID4gZWl0aGVyIHRoZSBtYWluIGFu ZCBzdWJzdGl0dXRpdmUgc2VuZGVyIHVzZSB0aGUgc2FtZSBTUlRQIGtleSwgb3IgDQo+ID4gdGhl IHNwbGljZXIgZGVjcnlwdHMgYW5kIHJlLWVuY3J5cHRzIHdpdGggYSBzaW5nbGUga2V5LiAiDQo+ ID4NCj4gDQo+IEFzIEkgc2FpZCBhYm92ZSBkdWUgdG8gdGhlIFNSVFAga2V5cyBmb3IgY29uZmlk ZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkgDQo+IGFyZSBjb21pbmcgZnJvbSBhIGNvbW1vbiBtYXN0 ZXIga2V5LCBpdCBpcyBub3QgcG9zc2libGUgdG8gZGVmaW5lIGEgDQo+IHNvbHV0aW9uIGFzIGlu ZGljYXRlZCBieSB0aGUgbmV3IHRleHQgYWJvdmUuDQo+IA0KPiBJIGFtIHNvcnJ5IGlmIEkgbWlz bGVhZCB5b3UgaW50byB0aGUgdHdvIGxheWVyIHNlY3VyaXR5IHNvbHV0aW9uLiBJdCANCj4gaXMg YSBwb3NzaWJpbGl0eSwgYnV0IHJlcXVpcmUgYSBsb3Qgb2Ygc3BlYyB3b3JrLiBCZWNhdXNlIFBF UkMgd2lsbCANCj4gbW9zdCBsaWtlbHkgbm90IGJlIHN1ZmZpY2llbnQgZm9yIHRoaXMgdXNhZ2Uu DQo+IA0KPiANCj4gQ2hlZXJzDQo+IA0KPiANCj4gTWFnbnVzIFdlc3Rlcmx1bmQNCj4gDQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gU2VydmljZXMsIE1lZGlhIGFuZCBOZXR3b3JrIGZlYXR1cmVzLCBFcmlj c3NvbiBSZXNlYXJjaCBFQUIvVFhNDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRXJpY3Nzb24gQUIgICAg ICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+IEbDpHLDtmdhdGFuIDYgICAg ICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQo+IFNFLTE2NCA4MCBTdG9ja2hv bG0sIFN3ZWRlbiB8IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0K From nobody Mon Mar 21 07:28:58 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 E418812D5D8; Mon, 21 Mar 2016 07:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, 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 ycZXH_twybgJ; Mon, 21 Mar 2016 07:28:54 -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 8215F12D51D; Mon, 21 Mar 2016 07:28:53 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-48-56f00523fb0c Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 82.8F.23401.32500F65; Mon, 21 Mar 2016 15:28:51 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.248.2; Mon, 21 Mar 2016 15:27:50 +0100 To: "Huangyihong (Rachel)" , "avtext@ietf.org" , Ben Campbell , "draft-ietf-avtext-splicing-notification@ietf.org" References: <56D6E18F.8050603@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E8C95B@nkgeml513-mbs.china.huawei.com> <56EBF6ED.6060207@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E99046@nkgeml513-mbx.china.huawei.com> From: Magnus Westerlund Message-ID: <56F004E5.7070702@ericsson.com> Date: Mon, 21 Mar 2016 15:27:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86E99046@nkgeml513-mbx.china.huawei.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM2K7uq4y64cwg87tphYf791gtZjfeZrd 4viZd6wWSztPsTuweLQcecvqsWTJTyaPWTufsAQwR3HZpKTmZJalFunbJXBlLNx5ir1giV/F pstXGRsYm+y7GDk4JARMJD6u0Ohi5AQyxSQu3FvPBmILCRxmlGiZABTnArKXM0ocnzCDGaRe WMBDYs8nHpAaEYFnjBLtf/0hap4ySvxc8p4VJMEmYCFx80cj2CBeAW2JszP3M4LYLAKqEutv P2UCsUUFYiSOvzvHCFEjKHFy5hMWEJtTIExiz7Q2JpBdzAL2Eg+2loGEmQXkJZq3zmaGuE1b oqGpg3UCo8AsJN2zEDpmIelYwMi8ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwXA9u+W21 g/Hgc8dDjAIcjEo8vAZX3ocJsSaWFVfmHmKU4GBWEuH1eAgU4k1JrKxKLcqPLyrNSS0+xCjN waIkzsv26XKYkEB6YklqdmpqQWoRTJaJg1OqgbHcyu/dmQNzD5v037p+fB3bJDP91tCeGPle vwJpyboHXCcMHiqs0NnHcNzSV9C6q8CkYcX/E1GMVjlHzpnl/TUMuWk0/cFUrqSU3yvZE5le t5vmKVgoq4YZ/7aMmv4v8Sabj6P0PE2xk78sPxnFHlgTtTAvq44r4/olJz03xRC2Gdrus2q+ KbEUZyQaajEXFScCABQgbQdTAgAA Archived-At: Subject: Re: [avtext] Some comments on draft-ietf-avtext-splicing-notification-04 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: Mon, 21 Mar 2016 14:28:57 -0000 Hi, Please see inline. I have removed issues that I think are all fine and you can simply incorporate them. From my perspective, I think it is best that you submit an update prior to the dead-line, then we all can review the changes prior to the meeting. And if any changes are needed, you can update in 2 weeks time. Please see inline. Den 2016-03-21 kl. 11:15, skrev Huangyihong (Rachel): >> -----Original Message----- From: Magnus Westerlund >> [mailto:magnus.westerlund@ericsson.com] Sent: Friday, March 18, >> 2016 8:39 PM To: Huangyihong (Rachel); avtext@ietf.org; Ben >> Campbell; draft-ietf-avtext-splicing-notification@ietf.org Subject: >> Re: Some comments on draft-ietf-avtext-splicing-notification-04 >> >> Hi, >> >> Sorry for being a bit late in responding on this. I hope you have >> time to submit this before the cut-off on Monday. >> >> Den 2016-03-03 kl. 11:51, skrev Huangyihong (Rachel): >>>> >>>> 2. Section 3.1: >>>> > " The top 8 bits of the splicing-out NTP timestamp are inferred from > the top 8 bits of the splicing-in NTP timestamp. This is unambiguous, > under the assumption that the splicing-out time is after the > splicing-in time, and the splicing interval is less than 2^25 > seconds. Therefore, if the 7 octets splicing-out NTP-format > timestamp is smaller than the value of 7 low octets splicing-out > NTP-format, it implies a wrap of the 56-bit splicing-out NTP-format > timestamp which means the top 8-bit value of the 64-bit splicing-out > is equal to the top 8-bit value of splicing-in NTP Timestamp plus > 0x01. Otherwise, the top 8 bits of splicing-out NTP timestamp is > equal to the top 8 bits of splicing-in NTP Timestamp. " Yes, with the correction you added I think this is fine. >> >> >> >>> >>>> >>>> 3. Section 3.1: >>>> >>>> This section is not clear on what is the data part of the >>>> header extension format. As it is not the header extension that >>>> can determine if there will be usage of one-byte vs two-byte >>>> format that will be used, this needs to be defined in a more >>>> un >>> >>> [Rachel]: I don't understand this. The editing seems unfinished. >>> The splicing RTP header extension uses one-byte format with the >>> fixed bit pattern 0xBEDE. >> >> Sorry, what is missing is: The definition of the data field need to >> be done in a way that is agnostic to if 1 or 2-byte headers are >> being used in the header extension. >> > > [Rachel]: I don't understand why should this extension to be agnostic > for extension header types. There's no such limitation in [RFC5285] > if I read it correctly. And based on [RFC5285], it says: > > " There are two variants of the extension: one-byte and two-byte > headers. Since it is expected that (a) the number of extensions in > any given RTP session is small and (b) the extensions themselves are > small, the one-byte header form is preferred and MUST be supported > by all receivers. A stream MUST contain only one-byte or two-byte > headers: they MUST NOT be mixed within a stream. Transmitters > SHOULD NOT use the two-byte form when all extensions are small enough > for the one-byte header form. " > > For splicing extension, it can be classified into a) case. That's why > we uses one-byte header, and it is preferred and mandated by > receivers. So I can't imagine any other cases to use 2-byte header. > And by the way, [RFC6051] also only defines one-byte header. So this debate do gets us into RFC5285 update country. However the issue is that although a particular RTP header extension has a preference or requirement for which format to use. The actual format used in an actual RTP packet will be depending on the union of all the requirement for header extension format. For example the SDES header extension is one that can require to use the 2-byte format due to the SDES item's length (>16 bytes). If that header extension and yours needs to be in the same packet, then also yours need to use the 2-byte header format in this particular packet. This is issue that needs to be clarified in RFC 5285 update, and hopefully to allow a particular SSRC to switch between formats on a packet by packet basis. If not then we end up in a situation where hard choices will have to be done when conflicting requirements occur. The above issue is from my perspective that if one defines a header extension in such a way that it is clear on what is the data part and don't lock down the format to use, then it will work with the updated spec. >>>> >>>> 6. Section 3.2: >>>> > > [Rachel]: Okay. I get your point. So how about adding some texts as > following in Section 3.2, the last 2nd paragraph? > > " In cases of the mapping from RTP timestamp to NTP timestamp > changes, e.g., clock drift happening before the splicing event, it > may be required to send RTCP SR or even updated Splicing Interval > information timely to update the timestamp mapping for accurate > splicing. " > Yes, this at least raises the issue. >>> >>>> >>>> 8. Section 7: >>>> >>>> I find a significant short coming in this security >>>> consideration. That is the failure to discuss the importance >>>> for the splicer to be able to trust the splicing interval >>>> information from the main RTP sender. This information really >>>> should be authenticated and integrity protected between the >>>> main RTP sender and the splicer. >>>> >>>> Thus, I am quite worried about this paragraph: >>>> >>>> Since the mechanism introduced in this document is not >>>> dependent on any RTP payload-level hints for finding the >>>> splicing in and out points, Secure Real-Time Transport Protocol >>>> (SRTP) [3711] can be used to provide confidentiality of the RTP >>>> payload while leaving the RTP header in the clear so that the >>>> splicer can still carry out splicing without keying materials. >>>> However, for a malicious endpoint without the key, it can >>>> observe the splicing time in the RTP header, and it can >>>> intercept the substitutive content and even replace it with a >>>> different one if the substitutive stream does not use any >>>> security like SRTP and the splicer does not authenticate the >>>> main and substitutive content sources. >>>> >>>> In the end it hints towards the need for authentication of the >>>> streams. But that really should be worded in a stronger way as >>>> a requirement for security. >>>> >>>> I do understand that this is really a case where two layers of >>>> security would be good. One between the main and substitute >>>> sender and the intended receiver, and an outer layer for sender >>>> to splicer. However, I don't argue that such a solution needs >>>> to be created. I think having the splicer as a trusted entity >>>> is more likely to be a reasonable deployment model. >>> >>> >>> [Rachel]: Okay. How about Add a new paragraph after the 3rd >>> paragraph in Section 7? >>> >>> " To avoid above security issue, the authentication of the main >>> and substitutive content sources in the splicer SHOULD be >>> considered. However, separating the security mechanism between >>> senders and the splicer from the end-to-end one may complicate >>> the whole system deployment. In such a case, having the splicer >>> as a trusted entity is likely to be a reasonable deployment >>> model. " >> >> No, I don't think this addresses the issue. The second paragraph >> already describes the trust model, of the trusted splicer. >> Especially as no alternative do yet exist. Although PERC WG exists >> and working on a model with end-to-end confidentiality, which could >> possibly work. That is not a great match either for what I think >> are the security requirements for services that uses splicing. >> >> I think what needs to occur is to rewrite the third paragraph from >> the perspective that the splicer is trusted. Especially as the >> stream the splicer forwards will not match the received one from a >> perspective of number of packets and bytes, thus requiring RTCP >> changes. This is why a translator or mixer model is required. Thus, >> the packet forwarded from the splicer to the receiver will not be >> consistent with either the original or the substitution stream. For >> the authentication and integrity protection to not blow up the SRTP >> keys will be needed. A division of the roles of integrity versus >> confidentiality and you are back into PERC territory. >> >> Thus, the discussion of header extension encryption is mote. >> Rather discuss that the splicer should use authenticated and >> integrity protected streams to prevent third parties from >> controlling the splicing as well as the substitution content. > > [Rachel]: Here's my proposal to rewrite 3rd paragraph to discuss the > authentication between splicer and receiver. Is it what you're > looking for? " Since splicer works as a trusted entity, any RTP-level > or outside security mechanism, such IPsec[RFC4301] or Datagram > Transport Layer Security [RFC6347], will use a security association > between the splicer and the receiver. When using the Secure Real-Time > Transport Protocol (SRTP) [RFC3711], the splicer could be provisioned > with the same security association as the main RTP sender. " Yes, it is at least what I believe to be most important. This as we are currently lacking the tools for doing a model where the splicer is only semi-trusted. 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 Mon Mar 21 07:36:41 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 99FC112D870; Mon, 21 Mar 2016 07:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 ahaX19NcCRSB; Mon, 21 Mar 2016 07:36:32 -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 671DE12D87D; Mon, 21 Mar 2016 07:36:31 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2LEaHBg039149 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 21 Mar 2016 09:36:18 -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.10] From: "Ben Campbell" To: "Magnus Westerlund" Date: Mon, 21 Mar 2016 09:36:17 -0500 Message-ID: <92AACA5A-4106-45E4-80D6-A30EE17AA99E@nostrum.com> In-Reply-To: <56F004E5.7070702@ericsson.com> References: <56D6E18F.8050603@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E8C95B@nkgeml513-mbs.china.huawei.com> <56EBF6ED.6060207@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E99046@nkgeml513-mbx.china.huawei.com> <56F004E5.7070702@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "draft-ietf-avtext-splicing-notification@ietf.org" , "avtext@ietf.org" Subject: Re: [avtext] Some comments on draft-ietf-avtext-splicing-notification-04 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: Mon, 21 Mar 2016 14:36:39 -0000 On 21 Mar 2016, at 9:27, Magnus Westerlund wrote: > From my perspective, I think it is best that you submit an update > prior to the dead-line, then we all can review the changes prior to > the meeting. And if any changes are needed, you can update in 2 weeks > time. I agree. Thanks, Ben. From nobody Mon Mar 21 09:00:48 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 79FC012D8D3; Mon, 21 Mar 2016 09:00:33 -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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321160033.31965.43095.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 09:00:33 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-lrr-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, 21 Mar 2016 16:00:34 -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-02.txt Pages : 14 Date : 2016-03-21 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-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-lrr-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 Mon Mar 21 09:07:04 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 3646E12D89C; Mon, 21 Mar 2016 09:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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, RP_MATCHES_RCVD=-0.001, 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 MJvCWUd4qXMq; Mon, 21 Mar 2016 09:07:01 -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 80A9D12D79E; Mon, 21 Mar 2016 09:07:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLB53375; Mon, 21 Mar 2016 16:06:58 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 21 Mar 2016 16:06:57 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0235.001; Tue, 22 Mar 2016 00:06:52 +0800 From: "Huangyihong (Rachel)" To: Magnus Westerlund , "avtext@ietf.org" , Ben Campbell , "draft-ietf-avtext-splicing-notification@ietf.org" Thread-Topic: Some comments on draft-ietf-avtext-splicing-notification-04 Thread-Index: AQHRdIIhWfIN9oQkKEK98MCsQzahTp9G/RLggBe6IoCABKGjAIAAM7iAgACRv0A= Date: Mon, 21 Mar 2016 16:06:51 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E992E0@nkgeml513-mbx.china.huawei.com> References: <56D6E18F.8050603@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E8C95B@nkgeml513-mbs.china.huawei.com> <56EBF6ED.6060207@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E99046@nkgeml513-mbx.china.huawei.com> <56F004E5.7070702@ericsson.com> In-Reply-To: <56F004E5.7070702@ericsson.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.69.243] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.56F01C22.00B7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e1b776470efdd6c388a6ff509261851b Archived-At: Subject: [avtext] =?gb2312?b?tPC4tDogU29tZSBjb21tZW50cyBvbiBkcmFmdC1pZXRm?= =?gb2312?b?LWF2dGV4dC1zcGxpY2luZy1ub3RpZmljYXRpb24tMDQ=?= 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: Mon, 21 Mar 2016 16:07:03 -0000 SGkgTWFndXMsDQoNClRoYW5rIHlvdSBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlLiBJIHRoaW5rIGJl bG93IGlzIHRoZSBvbmx5IGlzc3VlIHRoYXQgd2UncmUgZGlzY3Vzc2luZy4gSSdsbCBzdWJtaXQg YSBuZXcgdmVyc2lvbiB0byByZWZsZWN0IHRoZSBpc3N1ZXMgeW91IGhhdmUuDQoNCkJSLA0KUmFj aGVsDQoNCj4+Pj4NCj4+Pj4gMy4gU2VjdGlvbiAzLjE6DQo+Pj4+DQo+Pj4+IFRoaXMgc2VjdGlv biBpcyBub3QgY2xlYXIgb24gd2hhdCBpcyB0aGUgZGF0YSBwYXJ0IG9mIHRoZSBoZWFkZXIgDQo+ Pj4+IGV4dGVuc2lvbiBmb3JtYXQuIEFzIGl0IGlzIG5vdCB0aGUgaGVhZGVyIGV4dGVuc2lvbiB0 aGF0IGNhbiANCj4+Pj4gZGV0ZXJtaW5lIGlmIHRoZXJlIHdpbGwgYmUgdXNhZ2Ugb2Ygb25lLWJ5 dGUgdnMgdHdvLWJ5dGUgZm9ybWF0IA0KPj4+PiB0aGF0IHdpbGwgYmUgdXNlZCwgdGhpcyBuZWVk cyB0byBiZSBkZWZpbmVkIGluIGEgbW9yZSB1bg0KPj4+DQo+Pj4gW1JhY2hlbF06IEkgZG9uJ3Qg dW5kZXJzdGFuZCB0aGlzLiBUaGUgZWRpdGluZyBzZWVtcyB1bmZpbmlzaGVkLg0KPj4+IFRoZSBz cGxpY2luZyBSVFAgaGVhZGVyIGV4dGVuc2lvbiB1c2VzIG9uZS1ieXRlIGZvcm1hdCB3aXRoIHRo ZSANCj4+PiBmaXhlZCBiaXQgcGF0dGVybiAweEJFREUuDQo+Pg0KPj4gU29ycnksIHdoYXQgaXMg bWlzc2luZyBpczogVGhlIGRlZmluaXRpb24gb2YgdGhlIGRhdGEgZmllbGQgbmVlZCB0byANCj4+ IGJlIGRvbmUgaW4gYSB3YXkgdGhhdCBpcyBhZ25vc3RpYyB0byBpZiAxIG9yIDItYnl0ZSBoZWFk ZXJzIGFyZSBiZWluZyANCj4+IHVzZWQgaW4gdGhlIGhlYWRlciBleHRlbnNpb24uDQo+Pg0KPg0K PiBbUmFjaGVsXTogSSBkb24ndCB1bmRlcnN0YW5kIHdoeSBzaG91bGQgdGhpcyBleHRlbnNpb24g dG8gYmUgYWdub3N0aWMgDQo+IGZvciBleHRlbnNpb24gaGVhZGVyIHR5cGVzLiBUaGVyZSdzIG5v IHN1Y2ggbGltaXRhdGlvbiBpbiBbUkZDNTI4NV0gaWYgDQo+IEkgcmVhZCBpdCBjb3JyZWN0bHku IEFuZCBiYXNlZCBvbiBbUkZDNTI4NV0sIGl0IHNheXM6DQo+DQo+ICIgVGhlcmUgYXJlIHR3byB2 YXJpYW50cyBvZiB0aGUgZXh0ZW5zaW9uOiBvbmUtYnl0ZSBhbmQgdHdvLWJ5dGUgDQo+IGhlYWRl cnMuICBTaW5jZSBpdCBpcyBleHBlY3RlZCB0aGF0IChhKSB0aGUgbnVtYmVyIG9mIGV4dGVuc2lv bnMgaW4gDQo+IGFueSBnaXZlbiBSVFAgc2Vzc2lvbiBpcyBzbWFsbCBhbmQgKGIpIHRoZSBleHRl bnNpb25zIHRoZW1zZWx2ZXMgYXJlIA0KPiBzbWFsbCwgdGhlIG9uZS1ieXRlIGhlYWRlciBmb3Jt IGlzIHByZWZlcnJlZCBhbmQgTVVTVCBiZSBzdXBwb3J0ZWQgYnkgDQo+IGFsbCByZWNlaXZlcnMu ICBBIHN0cmVhbSBNVVNUIGNvbnRhaW4gb25seSBvbmUtYnl0ZSBvciB0d28tYnl0ZQ0KPiBoZWFk ZXJzOiB0aGV5IE1VU1QgTk9UIGJlIG1peGVkIHdpdGhpbiBhIHN0cmVhbS4gIFRyYW5zbWl0dGVy cyBTSE9VTEQgDQo+IE5PVCB1c2UgdGhlIHR3by1ieXRlIGZvcm0gd2hlbiBhbGwgZXh0ZW5zaW9u cyBhcmUgc21hbGwgZW5vdWdoIGZvciB0aGUgDQo+IG9uZS1ieXRlIGhlYWRlciBmb3JtLiAiDQo+ DQo+IEZvciBzcGxpY2luZyBleHRlbnNpb24sIGl0IGNhbiBiZSBjbGFzc2lmaWVkIGludG8gYSkg Y2FzZS4gVGhhdCdzIHdoeSANCj4gd2UgdXNlcyBvbmUtYnl0ZSBoZWFkZXIsIGFuZCBpdCBpcyBw cmVmZXJyZWQgYW5kIG1hbmRhdGVkIGJ5IA0KPiByZWNlaXZlcnMuIFNvIEkgY2FuJ3QgaW1hZ2lu ZSBhbnkgb3RoZXIgY2FzZXMgdG8gdXNlIDItYnl0ZSBoZWFkZXIuDQo+IEFuZCBieSB0aGUgd2F5 LCBbUkZDNjA1MV0gYWxzbyBvbmx5IGRlZmluZXMgb25lLWJ5dGUgaGVhZGVyLg0KDQpTbyB0aGlz IGRlYmF0ZSBkbyBnZXRzIHVzIGludG8gUkZDNTI4NSB1cGRhdGUgY291bnRyeS4gSG93ZXZlciB0 aGUgaXNzdWUgaXMgdGhhdCBhbHRob3VnaCBhIHBhcnRpY3VsYXIgUlRQIGhlYWRlciBleHRlbnNp b24gaGFzIGEgcHJlZmVyZW5jZSBvciByZXF1aXJlbWVudCBmb3Igd2hpY2ggZm9ybWF0IHRvIHVz ZS4gVGhlIGFjdHVhbCBmb3JtYXQgdXNlZCBpbiBhbiBhY3R1YWwgUlRQIHBhY2tldCB3aWxsIGJl IGRlcGVuZGluZyBvbiB0aGUgdW5pb24gb2YgYWxsIHRoZSByZXF1aXJlbWVudCBmb3IgaGVhZGVy IGV4dGVuc2lvbiBmb3JtYXQuIEZvciBleGFtcGxlIHRoZSBTREVTIGhlYWRlciBleHRlbnNpb24g aXMgb25lIHRoYXQgY2FuIHJlcXVpcmUgdG8gdXNlIHRoZSAyLWJ5dGUgZm9ybWF0IGR1ZSB0byB0 aGUgU0RFUyBpdGVtJ3MgbGVuZ3RoDQooPjE2IGJ5dGVzKS4gSWYgdGhhdCBoZWFkZXIgZXh0ZW5z aW9uIGFuZCB5b3VycyBuZWVkcyB0byBiZSBpbiB0aGUgc2FtZSBwYWNrZXQsIHRoZW4gYWxzbyB5 b3VycyBuZWVkIHRvIHVzZSB0aGUgMi1ieXRlIGhlYWRlciBmb3JtYXQgaW4gdGhpcyBwYXJ0aWN1 bGFyIHBhY2tldC4NCg0KW1JhY2hlbF06IFRoZSBSRkM1Mjg1IHVwZGF0ZSBhbHJlYWR5IHBlcm1p dHMgdG8gdXNlIDEtYnl0ZSBhbmQgMi1ieXRlIGZvcm1hdCBpbiB0aGUgc2FtZSBSVFAgc3RyZWFt LiBZb3UncmUgc2F5aW5nIHRoZSBjYXNlIHRoZXkncmUgdXNlZCBpbiBvbmUgUlRQIHBhY2tldC4g Rm9yIHNwbGljaW5nIGhlYWRlciBleHRlbnNpb24sIGl0IG9ubHkgYXBwZWFycyBhIG51bWJlciBv ZiBSVFAgcGFja2V0IGluc3RlYWQgb2YgYWxsIHRoZSBSVFAgcGFja2V0cy4gU28gSSdtIGp1c3Qg Y3VyaW91cyB0aGUgcG9zc2liaWxpdHkgb2YgdGhlIDIga2luZHMgb2YgZXh0ZW5zaW9ucyBtdXN0 IGJlIGluIHRoZSBzYW1lIHBhY2tldC4gDQoNClRoaXMgaXMgaXNzdWUgdGhhdCBuZWVkcyB0byBi ZSBjbGFyaWZpZWQgaW4gUkZDIDUyODUgdXBkYXRlLCBhbmQgaG9wZWZ1bGx5IHRvIGFsbG93IGEg cGFydGljdWxhciBTU1JDIHRvIHN3aXRjaCBiZXR3ZWVuIGZvcm1hdHMgb24gYSBwYWNrZXQgYnkg cGFja2V0IGJhc2lzLiBJZiBub3QgdGhlbiB3ZSBlbmQgdXAgaW4gYSBzaXR1YXRpb24gd2hlcmUg aGFyZCBjaG9pY2VzIHdpbGwgaGF2ZSB0byBiZSBkb25lIHdoZW4gY29uZmxpY3RpbmcgcmVxdWly ZW1lbnRzIG9jY3VyLg0KDQpUaGUgYWJvdmUgaXNzdWUgaXMgZnJvbSBteSBwZXJzcGVjdGl2ZSB0 aGF0IGlmIG9uZSBkZWZpbmVzIGEgaGVhZGVyIGV4dGVuc2lvbiBpbiBzdWNoIGEgd2F5IHRoYXQg aXQgaXMgY2xlYXIgb24gd2hhdCBpcyB0aGUgZGF0YSBwYXJ0IGFuZCBkb24ndCBsb2NrIGRvd24g dGhlIGZvcm1hdCB0byB1c2UsIHRoZW4gaXQgd2lsbCB3b3JrIHdpdGggdGhlIHVwZGF0ZWQgc3Bl Yy4NCg0KW1JhY2hlbF06IEl0J3Mgbm8gaGFybSB0byBpbmNsdWRlIGEgMi1ieXRlIGZvcm1hdCBp biB0aGlzIHZlcnNpb24gdG8gYXZvaWQgdGhlIGNhc2UgdGhhdCB5b3UgbWVudGlvbmVkLiBBbmQg SSdsbCBkbyBpdCByaWdodCBub3cuDQoNCg0KDQo= From nobody Mon Mar 21 09:08:01 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 D60CC12D8D0; Mon, 21 Mar 2016 09:07:57 -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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321160757.31917.81205.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 09:07:57 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-splicing-notification-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: Mon, 21 Mar 2016 16:07: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/RTCP extension for RTP Splicing Notification Authors : Jinwei Xia Roni Even Rachel Huang Lingli Deng Filename : draft-ietf-avtext-splicing-notification-05.txt Pages : 19 Date : 2016-03-21 Abstract: Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content, and delivers the substitutive multimedia content to the receivers for a period of time. The splicer is designed to handle RTP splicing and needs to know when to start and end the splicing. This memo defines two RTP/RTCP extensions to indicate the splicing related information to the splicer: an RTP header extension that conveys the information in-band and an RTCP packet that conveys the information out-of-band. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-splicing-notification-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-splicing-notification-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 Mon Mar 21 09:16:16 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 A3EB512D8D2 for ; Mon, 21 Mar 2016 09:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 ihJ0nriw2yVO for ; Mon, 21 Mar 2016 09:16:10 -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 34FC612D8D0 for ; Mon, 21 Mar 2016 09:16:06 -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 u2LGEu3g020422 for ; Mon, 21 Mar 2016 12:16:06 -0400 Received: from mail.vidyo.com (mail2.vidyo.com [162.209.16.213] (may be forged)) by mx0a-00198e01.pphosted.com with ESMTP id 21ft05sxse-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 21 Mar 2016 12:16:05 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Mon, 21 Mar 2016 11:16:04 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-lrr-02.txt Thread-Index: AQHRg4vOepevt5h890CeFPg73Wbuk59kZqEA Date: Mon, 21 Mar 2016 16:16:04 +0000 Message-ID: <054D44BF-E3CB-40F9-A2CB-3135E0B492F0@vidyo.com> References: <20160321160033.31965.43095.idtracker@ietfa.amsl.com> In-Reply-To: <20160321160033.31965.43095.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.186.160.2] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable 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-03-21_08:2016-03-21,2016-03-21,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-1601100000 definitions=main-1603210257 Archived-At: Subject: Re: [avtext] I-D Action: draft-ietf-avtext-lrr-02.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: Mon, 21 Mar 2016 16:16:15 -0000 This version of the LRR draft takes out the VP9 definitions, as we discusse= d in Yokohama, to move them to the VP9 payload spec. It also formally defines the message semantics, and adds SDP definitions an= d IANA registrations.=20 I believe this document is now complete. Comments welcome. > On Mar 21, 2016, at 6:00 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 Extensions of the = IETF. >=20 > Title : The Layer Refresh Request (LRR) RTCP Feedback Me= ssage > Authors : Jonathan Lennox > Danny Hong > Justin Uberti > Stefan Holmer > Magnus Flodman > Filename : draft-ietf-avtext-lrr-02.txt > Pages : 14 > Date : 2016-03-21 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtext-lrr/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-avtext-lrr-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-lrr-02 >=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 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext >=20 From nobody Mon Mar 21 16:17:52 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 6823312D116; Mon, 21 Mar 2016 16:17:51 -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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321231751.12227.77208.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 16:17:51 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-framemarking-01.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, 21 Mar 2016 23:17:51 -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-01.txt Pages : 8 Date : 2016-03-21 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-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-framemarking-01 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 Mar 21 19:14:35 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 2741F12D0CC for ; Mon, 21 Mar 2016 19:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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, RP_MATCHES_RCVD=-0.001, 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 h-6wmBilmdeW for ; Mon, 21 Mar 2016 19:14:32 -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 9CB7512D517 for ; Mon, 21 Mar 2016 19:14:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGK66926; Tue, 22 Mar 2016 02:14:29 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 22 Mar 2016 02:14:29 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0235.001; Tue, 22 Mar 2016 10:14:21 +0800 From: "Huangyihong (Rachel)" To: "avtext@ietf.org" Thread-Topic: [avtext] FW: New Version Notification for draft-ietf-avtext-splicing-notification-05.txt Thread-Index: AQHRg+CLAQiyyfKyIkqzgpaon8+RiA== Date: Tue, 22 Mar 2016 02:14:21 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E99A15@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.79.191] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56F0AA86.0061, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d31b7cd8ff06091c7d7c51fdcc059dbe Archived-At: Subject: [avtext] FW: New Version Notification for draft-ietf-avtext-splicing-notification-05.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: Tue, 22 Mar 2016 02:14:34 -0000 RGVhciBBbGwsDQoNClRoaXMgbmV3IHZlcnNpb24gcmVmbGVjdHMgdGhlIGNvbW1lbnRzIGZyb20g TWFnbnVzLCBCZW4gYW5kIEdlbi1BUlQvU2VjRGlyIHJldmlld3MuIA0KDQpCUiwNClJhY2hlbA0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFR1ZXNkYXksIE1h cmNoIDIyLCAyMDE2IDEyOjA4IEFNDQpUbzogRGVuZyBMaW5nbGk7IFJvbmkgRXZlbjsgWGlhamlu d2VpOyBIdWFuZ3lpaG9uZyAoUmFjaGVsKTsgTGluZ2xpIERlbmcNClN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmctbm90aWZpY2F0 aW9uLTA1LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLWF2dGV4dC1z cGxpY2luZy1ub3RpZmljYXRpb24tMDUudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IFJhY2hlbCBIdWFuZyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoN Ck5hbWU6CQlkcmFmdC1pZXRmLWF2dGV4dC1zcGxpY2luZy1ub3RpZmljYXRpb24NClJldmlzaW9u OgkwNQ0KVGl0bGU6CQlSVFAvUlRDUCBleHRlbnNpb24gZm9yIFJUUCBTcGxpY2luZyBOb3RpZmlj YXRpb24NCkRvY3VtZW50IGRhdGU6CTIwMTYtMDMtMjENCkdyb3VwOgkJYXZ0ZXh0DQpQYWdlczoJ CTE5DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0wNS50eHQNClN0YXR1czog ICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWF2dGV4 dC1zcGxpY2luZy1ub3RpZmljYXRpb24vDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0wNQ0K RGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLWF2dGV4dC1zcGxpY2luZy1ub3RpZmljYXRpb24tMDUNCg0KQWJzdHJhY3Q6DQogICBDb250 ZW50IHNwbGljaW5nIGlzIGEgcHJvY2VzcyB0aGF0IHJlcGxhY2VzIHRoZSBjb250ZW50IG9mIGEg bWFpbg0KICAgbXVsdGltZWRpYSBzdHJlYW0gd2l0aCBvdGhlciBtdWx0aW1lZGlhIGNvbnRlbnQs IGFuZCBkZWxpdmVycyB0aGUNCiAgIHN1YnN0aXR1dGl2ZSBtdWx0aW1lZGlhIGNvbnRlbnQgdG8g dGhlIHJlY2VpdmVycyBmb3IgYSBwZXJpb2Qgb2YNCiAgIHRpbWUuIFRoZSBzcGxpY2VyIGlzIGRl c2lnbmVkIHRvIGhhbmRsZSBSVFAgc3BsaWNpbmcgYW5kIG5lZWRzIHRvDQogICBrbm93IHdoZW4g dG8gc3RhcnQgYW5kIGVuZCB0aGUgc3BsaWNpbmcuDQoNCiAgIFRoaXMgbWVtbyBkZWZpbmVzIHR3 byBSVFAvUlRDUCBleHRlbnNpb25zIHRvIGluZGljYXRlIHRoZSBzcGxpY2luZw0KICAgcmVsYXRl ZCBpbmZvcm1hdGlvbiB0byB0aGUgc3BsaWNlcjogYW4gUlRQIGhlYWRlciBleHRlbnNpb24gdGhh dA0KICAgY29udmV5cyB0aGUgaW5mb3JtYXRpb24gaW4tYmFuZCBhbmQgYW4gUlRDUCBwYWNrZXQg dGhhdCBjb252ZXlzIHRoZQ0KICAgaW5mb3JtYXRpb24gb3V0LW9mLWJhbmQuDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoN ClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Tue Mar 22 03:35:44 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 7519B12D718; Tue, 22 Mar 2016 03:35:42 -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 iYYxVgrQzyWq; Tue, 22 Mar 2016 03:35:40 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDCDD12D101; Tue, 22 Mar 2016 03:35:39 -0700 (PDT) X-AuditID: c1b4fb25-f79f86d00000400a-2e-56f11ffa1dc8 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 15.DF.16394.AFF11F65; Tue, 22 Mar 2016 11:35:38 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.248.2; Tue, 22 Mar 2016 11:35:37 +0100 To: "Huangyihong (Rachel)" , "avtext@ietf.org" , Ben Campbell , "draft-ietf-avtext-splicing-notification@ietf.org" References: <56D6E18F.8050603@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E8C95B@nkgeml513-mbs.china.huawei.com> <56EBF6ED.6060207@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E99046@nkgeml513-mbx.china.huawei.com> <56F004E5.7070702@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E992E0@nkgeml513-mbx.china.huawei.com> From: Magnus Westerlund Message-ID: <56F11FF9.20604@ericsson.com> Date: Tue, 22 Mar 2016 11:35:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86E992E0@nkgeml513-mbx.china.huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM2K7uu4v+Y9hBq9+C1p8vHeD1WJ+52l2 i+Nn3rFaLO08xe7A4tFy5C2rx5IlP5k8Zu18whLAHMVlk5Kak1mWWqRvl8CV8W69Y8Ff9YrV NxvZGxgfyHcxcnJICJhIzN3xgAXCFpO4cG89G4gtJHCYUeLcbJMuRi4gezmjxOzug6wgCWGB con/24+yg9giAs8YJdr/+kM0XGaSeHGzBsRmE7CQuPmjEWwQr4CmxPrT/8FsFgFViedvD4LZ ogIxEsffnWOEqBGUODnzCdgRnAJhEl33X4PZzEBzFr85yA5hy0s0b53NDLFLW6KhqYN1AqPA LCTts5C0zELSsoCReRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYMge3PJbdQfj5TeOhxgF OBiVeHgNtn4IE2JNLCuuzD3EKMHBrCTCO13uY5gQb0piZVVqUX58UWlOavEhRmkOFiVxXtZP l8OEBNITS1KzU1MLUotgskwcnFINjMyXy/sF6+Sibu4vPhF81LK64XDgkVTGicIP54l/6RLd b6HBvJX1+4mI7Z7H+LJ/MqRs/NWSmepuZvDB2aQy94980jwlbcZbm3cWt7POCkmIi2mU4tXc M2l1tm1QnoybbPnbO4cvS3k/S7mdfGDvl7yd1w1livIOXt0jySmYsIQpuK1gwuZgJZbijERD Leai4kQAvQeAqlUCAAA= Archived-At: Subject: Re: [avtext] =?utf-8?b?562U5aSNOiBTb21lIGNvbW1lbnRzIG9uIGRyYWZ0LWll?= =?utf-8?q?tf-avtext-splicing-notification-04?= 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, 22 Mar 2016 10:35:42 -0000 Den 2016-03-21 kl. 17:06, skrev Huangyihong (Rachel): > Hi Magus, > > Thank you for the quick response. I think below is the only issue > that we're discussing. I'll submit a new version to reflect the > issues you have. > > BR, Rachel > >>>>> >>>>> 3. Section 3.1: >>>>> >>>>> This section is not clear on what is the data part of the >>>>> header extension format. As it is not the header extension >>>>> that can determine if there will be usage of one-byte vs >>>>> two-byte format that will be used, this needs to be defined >>>>> in a more un >>>> >>>> [Rachel]: I don't understand this. The editing seems >>>> unfinished. The splicing RTP header extension uses one-byte >>>> format with the fixed bit pattern 0xBEDE. >>> >>> Sorry, what is missing is: The definition of the data field need >>> to be done in a way that is agnostic to if 1 or 2-byte headers >>> are being used in the header extension. >>> >> >> [Rachel]: I don't understand why should this extension to be >> agnostic for extension header types. There's no such limitation in >> [RFC5285] if I read it correctly. And based on [RFC5285], it says: >> >> " There are two variants of the extension: one-byte and two-byte >> headers. Since it is expected that (a) the number of extensions >> in any given RTP session is small and (b) the extensions themselves >> are small, the one-byte header form is preferred and MUST be >> supported by all receivers. A stream MUST contain only one-byte or >> two-byte headers: they MUST NOT be mixed within a stream. >> Transmitters SHOULD NOT use the two-byte form when all extensions >> are small enough for the one-byte header form. " >> >> For splicing extension, it can be classified into a) case. That's >> why we uses one-byte header, and it is preferred and mandated by >> receivers. So I can't imagine any other cases to use 2-byte >> header. And by the way, [RFC6051] also only defines one-byte >> header. > > So this debate do gets us into RFC5285 update country. However the > issue is that although a particular RTP header extension has a > preference or requirement for which format to use. The actual format > used in an actual RTP packet will be depending on the union of all > the requirement for header extension format. For example the SDES > header extension is one that can require to use the 2-byte format due > to the SDES item's length (>16 bytes). If that header extension and > yours needs to be in the same packet, then also yours need to use the > 2-byte header format in this particular packet. > > [Rachel]: The RFC5285 update already permits to use 1-byte and 2-byte > format in the same RTP stream. You're saying the case they're used in > one RTP packet. For splicing header extension, it only appears a > number of RTP packet instead of all the RTP packets. So I'm just > curious the possibility of the 2 kinds of extensions must be in the > same packet. No, that is not what I try to say. I am saying that within one RTP stream, i.e. under one SSRC. Then in one packet one might need to use the 2-byte format due to that an additional RTP header extension is added to the one with Splicing information. In a later packet where there is need to send a splicing RTP header extension, there might not be any other RTP header extension, nor one that requires the two-byte header extension. Thus, this packet can be sent with the 1-byte format. > > This is issue that needs to be clarified in RFC 5285 update, and > hopefully to allow a particular SSRC to switch between formats on a > packet by packet basis. If not then we end up in a situation where > hard choices will have to be done when conflicting requirements > occur. > > The above issue is from my perspective that if one defines a header > extension in such a way that it is clear on what is the data part and > don't lock down the format to use, then it will work with the updated > spec. > > [Rachel]: It's no harm to include a 2-byte format in this version to > avoid the case that you mentioned. And I'll do it right now. Yes, that is one way of doing it. The point I tried to made is that one can define ones RTP header extension is such a way that it becomes agnostic to if 1-byte or 2-byte format is used for the header extensions. This should be the recommended practice unless the format requires the 2-byte format. I will have to review the RFC 5285 update to see if this has sufficient clarifications in this area. I would recommend that also the rest of the WG do take a look on the document update. 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 Wed Mar 23 01:18:52 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 94A3612DA59 for ; Wed, 23 Mar 2016 01:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 k3PcncmORO9L for ; Wed, 23 Mar 2016 01:18:49 -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 C302412DA08 for ; Wed, 23 Mar 2016 01:18:46 -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 u2N8IgGb028625 for ; Wed, 23 Mar 2016 04:18:42 -0400 Received: from mail.vidyo.com (mail2.vidyo.com [162.209.16.213] (may be forged)) by mx0b-00198e01.pphosted.com with ESMTP id 21fsy4bb1h-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 23 Mar 2016 04:18:41 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Wed, 23 Mar 2016 03:18:41 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: WGLC: draft-ietf-avtext-rid-01.txt Thread-Index: AQHRhNyboSUy9w68Q0mvCSDSWLKl8g== Date: Wed, 23 Mar 2016 08:18:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.186.160.2] Content-Type: text/plain; charset="us-ascii" Content-ID: <03BB60AD6AE3054DB2EA0D4EABCBCC07@vidyo.com> Content-Transfer-Encoding: quoted-printable 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-03-23_05:2016-03-22,2016-03-23,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-1601100000 definitions=main-1603230127 Archived-At: Subject: [avtext] WGLC: draft-ietf-avtext-rid-01.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: Wed, 23 Mar 2016 08:18:50 -0000 This is to announce a 1.5 week Working Group Last Call for draft-ietf-avtext-rid-01 as proposed standard. Please review and provide any comments you may have on the document by Sund= ay, April 3 (the beginning of the Buenos Aires IETF meeting). Comments shou= ld be sent to the document authors and the AVTEXT WG list. If you review the document but do not have any comments, please send a note= to that effect as well. Thank you! Jonathan (AVTEXT co-chair) From nobody Wed Mar 23 02:29: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 8190A12D6FC; Wed, 23 Mar 2016 02:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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, RP_MATCHES_RCVD=-0.001, 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 wX6ydJ4xMH86; Wed, 23 Mar 2016 02:29:42 -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 03EB712DBA8; Wed, 23 Mar 2016 02:29:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGM24743; Wed, 23 Mar 2016 09:29:38 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Mar 2016 09:29:26 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0235.001; Wed, 23 Mar 2016 17:29:22 +0800 From: "Huangyihong (Rachel)" To: Magnus Westerlund , "avtext@ietf.org" , Ben Campbell , "draft-ietf-avtext-splicing-notification@ietf.org" Thread-Topic: =?utf-8?B?562U5aSNOiBTb21lIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtYXZ0ZXh0LXNw?= =?utf-8?Q?licing-notification-04?= Thread-Index: AQHRdIIhWfIN9oQkKEK98MCsQzahTp9G/RLggBe6IoCABKGjAIAAM7iAgACRv0CAAL+2gIABy0Pw Date: Wed, 23 Mar 2016 09:29:21 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E9A264@nkgeml513-mbx.china.huawei.com> References: <56D6E18F.8050603@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E8C95B@nkgeml513-mbs.china.huawei.com> <56EBF6ED.6060207@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E99046@nkgeml513-mbx.china.huawei.com> <56F004E5.7070702@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E992E0@nkgeml513-mbx.china.huawei.com> <56F11FF9.20604@ericsson.com> In-Reply-To: <56F11FF9.20604@ericsson.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.191] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56F26202.01D3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 083c1f42982a291143fb5c1ce7fae8c8 Archived-At: Subject: Re: [avtext] =?utf-8?b?562U5aSNOiBTb21lIGNvbW1lbnRzIG9uIGRyYWZ0LWll?= =?utf-8?q?tf-avtext-splicing-notification-04?= 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, 23 Mar 2016 09:29:44 -0000 SGkgTWFnbnVzLA0KDQpJbmxpbmUgcGxlYXNlLg0KDQpCUiwNClJhY2hlbA0KDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFnbnVzIFdlc3Rlcmx1bmQgW21haWx0bzpt YWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIE1hcmNoIDIy LCAyMDE2IDY6MzYgUE0NCj4gVG86IEh1YW5neWlob25nIChSYWNoZWwpOyBhdnRleHRAaWV0Zi5v cmc7IEJlbiBDYW1wYmVsbDsNCj4gZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmctbm90aWZpY2F0 aW9uQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiDnrZTlpI06IFNvbWUgY29tbWVudHMgb24gZHJh ZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmctbm90aWZpY2F0aW9uLTA0DQo+IA0KPiBEZW4gMjAxNi0w My0yMSBrbC4gMTc6MDYsIHNrcmV2IEh1YW5neWlob25nIChSYWNoZWwpOg0KPiA+IEhpIE1hZ3Vz LA0KPiA+DQo+ID4gVGhhbmsgeW91IGZvciB0aGUgcXVpY2sgcmVzcG9uc2UuIEkgdGhpbmsgYmVs b3cgaXMgdGhlIG9ubHkgaXNzdWUgdGhhdA0KPiA+IHdlJ3JlIGRpc2N1c3NpbmcuIEknbGwgc3Vi bWl0IGEgbmV3IHZlcnNpb24gdG8gcmVmbGVjdCB0aGUgaXNzdWVzIHlvdQ0KPiA+IGhhdmUuDQo+ ID4NCj4gPiBCUiwgUmFjaGVsDQo+ID4NCj4gPj4+Pj4NCj4gPj4+Pj4gMy4gU2VjdGlvbiAzLjE6 DQo+ID4+Pj4+DQo+ID4+Pj4+IFRoaXMgc2VjdGlvbiBpcyBub3QgY2xlYXIgb24gd2hhdCBpcyB0 aGUgZGF0YSBwYXJ0IG9mIHRoZSBoZWFkZXINCj4gPj4+Pj4gZXh0ZW5zaW9uIGZvcm1hdC4gQXMg aXQgaXMgbm90IHRoZSBoZWFkZXIgZXh0ZW5zaW9uIHRoYXQgY2FuDQo+ID4+Pj4+IGRldGVybWlu ZSBpZiB0aGVyZSB3aWxsIGJlIHVzYWdlIG9mIG9uZS1ieXRlIHZzIHR3by1ieXRlIGZvcm1hdA0K PiA+Pj4+PiB0aGF0IHdpbGwgYmUgdXNlZCwgdGhpcyBuZWVkcyB0byBiZSBkZWZpbmVkIGluIGEg bW9yZSB1bg0KPiA+Pj4+DQo+ID4+Pj4gW1JhY2hlbF06IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGlz LiBUaGUgZWRpdGluZyBzZWVtcyB1bmZpbmlzaGVkLg0KPiA+Pj4+IFRoZSBzcGxpY2luZyBSVFAg aGVhZGVyIGV4dGVuc2lvbiB1c2VzIG9uZS1ieXRlIGZvcm1hdCB3aXRoIHRoZQ0KPiA+Pj4+IGZp eGVkIGJpdCBwYXR0ZXJuIDB4QkVERS4NCj4gPj4+DQo+ID4+PiBTb3JyeSwgd2hhdCBpcyBtaXNz aW5nIGlzOiBUaGUgZGVmaW5pdGlvbiBvZiB0aGUgZGF0YSBmaWVsZCBuZWVkIHRvDQo+ID4+PiBi ZSBkb25lIGluIGEgd2F5IHRoYXQgaXMgYWdub3N0aWMgdG8gaWYgMSBvciAyLWJ5dGUgaGVhZGVy cyBhcmUNCj4gPj4+IGJlaW5nIHVzZWQgaW4gdGhlIGhlYWRlciBleHRlbnNpb24uDQo+ID4+Pg0K PiA+Pg0KPiA+PiBbUmFjaGVsXTogSSBkb24ndCB1bmRlcnN0YW5kIHdoeSBzaG91bGQgdGhpcyBl eHRlbnNpb24gdG8gYmUgYWdub3N0aWMNCj4gPj4gZm9yIGV4dGVuc2lvbiBoZWFkZXIgdHlwZXMu IFRoZXJlJ3Mgbm8gc3VjaCBsaW1pdGF0aW9uIGluIFtSRkM1Mjg1XQ0KPiA+PiBpZiBJIHJlYWQg aXQgY29ycmVjdGx5LiBBbmQgYmFzZWQgb24gW1JGQzUyODVdLCBpdCBzYXlzOg0KPiA+Pg0KPiA+ PiAiIFRoZXJlIGFyZSB0d28gdmFyaWFudHMgb2YgdGhlIGV4dGVuc2lvbjogb25lLWJ5dGUgYW5k IHR3by1ieXRlDQo+ID4+IGhlYWRlcnMuICBTaW5jZSBpdCBpcyBleHBlY3RlZCB0aGF0IChhKSB0 aGUgbnVtYmVyIG9mIGV4dGVuc2lvbnMgaW4NCj4gPj4gYW55IGdpdmVuIFJUUCBzZXNzaW9uIGlz IHNtYWxsIGFuZCAoYikgdGhlIGV4dGVuc2lvbnMgdGhlbXNlbHZlcyBhcmUNCj4gPj4gc21hbGws IHRoZSBvbmUtYnl0ZSBoZWFkZXIgZm9ybSBpcyBwcmVmZXJyZWQgYW5kIE1VU1QgYmUgc3VwcG9y dGVkIGJ5DQo+ID4+IGFsbCByZWNlaXZlcnMuICBBIHN0cmVhbSBNVVNUIGNvbnRhaW4gb25seSBv bmUtYnl0ZSBvciB0d28tYnl0ZQ0KPiA+PiBoZWFkZXJzOiB0aGV5IE1VU1QgTk9UIGJlIG1peGVk IHdpdGhpbiBhIHN0cmVhbS4NCj4gPj4gVHJhbnNtaXR0ZXJzIFNIT1VMRCBOT1QgdXNlIHRoZSB0 d28tYnl0ZSBmb3JtIHdoZW4gYWxsIGV4dGVuc2lvbnMgYXJlDQo+ID4+IHNtYWxsIGVub3VnaCBm b3IgdGhlIG9uZS1ieXRlIGhlYWRlciBmb3JtLiAiDQo+ID4+DQo+ID4+IEZvciBzcGxpY2luZyBl eHRlbnNpb24sIGl0IGNhbiBiZSBjbGFzc2lmaWVkIGludG8gYSkgY2FzZS4gVGhhdCdzIHdoeQ0K PiA+PiB3ZSB1c2VzIG9uZS1ieXRlIGhlYWRlciwgYW5kIGl0IGlzIHByZWZlcnJlZCBhbmQgbWFu ZGF0ZWQgYnkNCj4gPj4gcmVjZWl2ZXJzLiBTbyBJIGNhbid0IGltYWdpbmUgYW55IG90aGVyIGNh c2VzIHRvIHVzZSAyLWJ5dGUgaGVhZGVyLg0KPiA+PiBBbmQgYnkgdGhlIHdheSwgW1JGQzYwNTFd IGFsc28gb25seSBkZWZpbmVzIG9uZS1ieXRlIGhlYWRlci4NCj4gPg0KPiA+IFNvIHRoaXMgZGVi YXRlIGRvIGdldHMgdXMgaW50byBSRkM1Mjg1IHVwZGF0ZSBjb3VudHJ5LiBIb3dldmVyIHRoZQ0K PiA+IGlzc3VlIGlzIHRoYXQgYWx0aG91Z2ggYSBwYXJ0aWN1bGFyIFJUUCBoZWFkZXIgZXh0ZW5z aW9uIGhhcyBhDQo+ID4gcHJlZmVyZW5jZSBvciByZXF1aXJlbWVudCBmb3Igd2hpY2ggZm9ybWF0 IHRvIHVzZS4gVGhlIGFjdHVhbCBmb3JtYXQNCj4gPiB1c2VkIGluIGFuIGFjdHVhbCBSVFAgcGFj a2V0IHdpbGwgYmUgZGVwZW5kaW5nIG9uIHRoZSB1bmlvbiBvZiBhbGwgdGhlDQo+ID4gcmVxdWly ZW1lbnQgZm9yIGhlYWRlciBleHRlbnNpb24gZm9ybWF0LiBGb3IgZXhhbXBsZSB0aGUgU0RFUyBo ZWFkZXINCj4gPiBleHRlbnNpb24gaXMgb25lIHRoYXQgY2FuIHJlcXVpcmUgdG8gdXNlIHRoZSAy LWJ5dGUgZm9ybWF0IGR1ZSB0byB0aGUNCj4gPiBTREVTIGl0ZW0ncyBsZW5ndGggKD4xNiBieXRl cykuIElmIHRoYXQgaGVhZGVyIGV4dGVuc2lvbiBhbmQgeW91cnMNCj4gPiBuZWVkcyB0byBiZSBp biB0aGUgc2FtZSBwYWNrZXQsIHRoZW4gYWxzbyB5b3VycyBuZWVkIHRvIHVzZSB0aGUgMi1ieXRl DQo+ID4gaGVhZGVyIGZvcm1hdCBpbiB0aGlzIHBhcnRpY3VsYXIgcGFja2V0Lg0KPiA+DQo+ID4g W1JhY2hlbF06IFRoZSBSRkM1Mjg1IHVwZGF0ZSBhbHJlYWR5IHBlcm1pdHMgdG8gdXNlIDEtYnl0 ZSBhbmQgMi1ieXRlDQo+ID4gZm9ybWF0IGluIHRoZSBzYW1lIFJUUCBzdHJlYW0uIFlvdSdyZSBz YXlpbmcgdGhlIGNhc2UgdGhleSdyZSB1c2VkIGluDQo+ID4gb25lIFJUUCBwYWNrZXQuIEZvciBz cGxpY2luZyBoZWFkZXIgZXh0ZW5zaW9uLCBpdCBvbmx5IGFwcGVhcnMgYQ0KPiA+IG51bWJlciBv ZiBSVFAgcGFja2V0IGluc3RlYWQgb2YgYWxsIHRoZSBSVFAgcGFja2V0cy4gU28gSSdtIGp1c3QN Cj4gPiBjdXJpb3VzIHRoZSBwb3NzaWJpbGl0eSBvZiB0aGUgMiBraW5kcyBvZiBleHRlbnNpb25z IG11c3QgYmUgaW4gdGhlDQo+ID4gc2FtZSBwYWNrZXQuDQo+IA0KPiBObywgdGhhdCBpcyBub3Qg d2hhdCBJIHRyeSB0byBzYXkuIEkgYW0gc2F5aW5nIHRoYXQgd2l0aGluIG9uZSBSVFAgc3RyZWFt LCBpLmUuDQo+IHVuZGVyIG9uZSBTU1JDLiBUaGVuIGluIG9uZSBwYWNrZXQgb25lIG1pZ2h0IG5l ZWQgdG8gdXNlIHRoZSAyLWJ5dGUgZm9ybWF0DQo+IGR1ZSB0byB0aGF0IGFuIGFkZGl0aW9uYWwg UlRQIGhlYWRlciBleHRlbnNpb24gaXMgYWRkZWQgdG8gdGhlIG9uZSB3aXRoIFNwbGljaW5nDQo+ IGluZm9ybWF0aW9uLiBJbiBhIGxhdGVyIHBhY2tldCB3aGVyZSB0aGVyZSBpcyBuZWVkIHRvIHNl bmQgYSBzcGxpY2luZyBSVFAgaGVhZGVyDQo+IGV4dGVuc2lvbiwgdGhlcmUgbWlnaHQgbm90IGJl IGFueSBvdGhlciBSVFAgaGVhZGVyIGV4dGVuc2lvbiwgbm9yIG9uZSB0aGF0DQo+IHJlcXVpcmVz IHRoZSB0d28tYnl0ZSBoZWFkZXIgZXh0ZW5zaW9uLiBUaHVzLCB0aGlzIHBhY2tldCBjYW4gYmUg c2VudCB3aXRoIHRoZQ0KPiAxLWJ5dGUgZm9ybWF0Lg0KDQpbUmFjaGVsXTogWWVzLCBJIHVuZGVy c3RhbmQgeW91IHBvaW50LiBBbmQgdGhhdCdzIGFsbCB3aGF0IFJGQzUyODUgdXBkYXRlIGlzIHRh bGtpbmcgYWJvdXQsIHNlZSBiZWxvdw0KDQoiDQpBIHN0cmVhbSBNVVNUIGNvbnRhaW4gb25seSBv bmUtYnl0ZSBvciB0d28tYnl0ZQ0KaGVhZGVycyB1bmxlc3MgaXQgaXMga25vd24gdGhhdCBhbGwg cmVjaXBpZW50cyBzdXBwb3J0IG1peGluZywgZWl0aGVyDQpieSBvZmZlci9hbnN3ZXIgbmVnb3Rp YXRpb24gKHNlZSBzZWN0aW9uIDYpIG9yIGJ5IG91dC1vZi1iYW5kDQprbm93bGVkZ2UuICBPbmUt Ynl0ZSBhbmQgdHdvLWJ5dGUgaGVhZGVycyBNVVNUIE5PVCBiZSBtaXhlZCBpbiBhDQpzaW5nbGUg UlRQIHBhY2tldC4NCiINCg0KPiANCj4gPg0KPiA+IFRoaXMgaXMgaXNzdWUgdGhhdCBuZWVkcyB0 byBiZSBjbGFyaWZpZWQgaW4gUkZDIDUyODUgdXBkYXRlLCBhbmQNCj4gPiBob3BlZnVsbHkgdG8g YWxsb3cgYSBwYXJ0aWN1bGFyIFNTUkMgdG8gc3dpdGNoIGJldHdlZW4gZm9ybWF0cyBvbiBhDQo+ ID4gcGFja2V0IGJ5IHBhY2tldCBiYXNpcy4gSWYgbm90IHRoZW4gd2UgZW5kIHVwIGluIGEgc2l0 dWF0aW9uIHdoZXJlDQo+ID4gaGFyZCBjaG9pY2VzIHdpbGwgaGF2ZSB0byBiZSBkb25lIHdoZW4g Y29uZmxpY3RpbmcgcmVxdWlyZW1lbnRzIG9jY3VyLg0KPiA+DQo+ID4gVGhlIGFib3ZlIGlzc3Vl IGlzIGZyb20gbXkgcGVyc3BlY3RpdmUgdGhhdCBpZiBvbmUgZGVmaW5lcyBhIGhlYWRlcg0KPiA+ IGV4dGVuc2lvbiBpbiBzdWNoIGEgd2F5IHRoYXQgaXQgaXMgY2xlYXIgb24gd2hhdCBpcyB0aGUg ZGF0YSBwYXJ0IGFuZA0KPiA+IGRvbid0IGxvY2sgZG93biB0aGUgZm9ybWF0IHRvIHVzZSwgdGhl biBpdCB3aWxsIHdvcmsgd2l0aCB0aGUgdXBkYXRlZA0KPiA+IHNwZWMuDQo+ID4NCj4gPiBbUmFj aGVsXTogSXQncyBubyBoYXJtIHRvIGluY2x1ZGUgYSAyLWJ5dGUgZm9ybWF0IGluIHRoaXMgdmVy c2lvbiB0bw0KPiA+IGF2b2lkIHRoZSBjYXNlIHRoYXQgeW91IG1lbnRpb25lZC4gQW5kIEknbGwg ZG8gaXQgcmlnaHQgbm93Lg0KPiANCj4gWWVzLCB0aGF0IGlzIG9uZSB3YXkgb2YgZG9pbmcgaXQu IFRoZSBwb2ludCBJIHRyaWVkIHRvIG1hZGUgaXMgdGhhdCBvbmUgY2FuIGRlZmluZQ0KPiBvbmVz IFJUUCBoZWFkZXIgZXh0ZW5zaW9uIGlzIHN1Y2ggYSB3YXkgdGhhdCBpdCBiZWNvbWVzIGFnbm9z dGljIHRvIGlmIDEtYnl0ZQ0KPiBvciAyLWJ5dGUgZm9ybWF0IGlzIHVzZWQgZm9yIHRoZSBoZWFk ZXIgZXh0ZW5zaW9ucy4gVGhpcyBzaG91bGQgYmUgdGhlDQo+IHJlY29tbWVuZGVkIHByYWN0aWNl IHVubGVzcyB0aGUgZm9ybWF0IHJlcXVpcmVzIHRoZSAyLWJ5dGUgZm9ybWF0Lg0KDQpbUmFjaGVs XTogV2UgZGVzaWduIHRoZSBzcGxpY2luZyBoZWFkZXIgZXh0ZW5zaW9uIGluIGEgYml0LXNhdmlu ZyB3YXksIGJlY2F1c2UgdGhlIGxlbmd0aCBvZiBkYXRhIGZpZWxkIGlzIGZpeGVkLg0KDQo+IA0K PiBJIHdpbGwgaGF2ZSB0byByZXZpZXcgdGhlIFJGQyA1Mjg1IHVwZGF0ZSB0byBzZWUgaWYgdGhp cyBoYXMgc3VmZmljaWVudA0KPiBjbGFyaWZpY2F0aW9ucyBpbiB0aGlzIGFyZWEuIEkgd291bGQg cmVjb21tZW5kIHRoYXQgYWxzbyB0aGUgcmVzdCBvZiB0aGUgV0cgZG8NCj4gdGFrZSBhIGxvb2sg b24gdGhlIGRvY3VtZW50IHVwZGF0ZS4NCj4gDQo+IGNoZWVycw0KPiANCj4gTWFnbnVzIFdlc3Rl cmx1bmQNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gU2VydmljZXMsIE1lZGlhIGFuZCBOZXR3b3Jr IGZlYXR1cmVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFhNDQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g RXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+IEbD pHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQo+IFNF LTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiB8IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJp Y3Nzb24uY29tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K From nobody Wed Mar 23 23:26:32 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 A35DA12D609 for ; Wed, 23 Mar 2016 23:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 WRP5z6eljyRJ for ; Wed, 23 Mar 2016 23:26:28 -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 72B7F12D0CB for ; Wed, 23 Mar 2016 23:26:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGN19130; Thu, 24 Mar 2016 06:26:24 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 24 Mar 2016 06:26:23 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0235.001; Thu, 24 Mar 2016 14:26:20 +0800 From: "Huangyihong (Rachel)" To: "avtext@ietf.org" Thread-Topic: [avtext] Draft agenda for AVTEXT meeting in Buenos Aires Thread-Index: AdGFlhQ1UQPZsQjOSxSpCpavVUGyZA== Date: Thu, 24 Mar 2016 06:26:20 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E9A77F@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.79.191] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB86E9A77Fnkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.56F38890.014A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 772d52c9fc5c1aa034be283fefa3452b Archived-At: Cc: Jonathan Lennox Subject: [avtext] Draft agenda for AVTEXT meeting in Buenos Aires 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, 24 Mar 2016 06:26:30 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB86E9A77Fnkgeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Here's the draft agenda for AVTEXT meeting in Buenos Aires. And I already u= ploaded it. https://www.ietf.org/proceedings/95/agenda/agenda-95-avtext So if you have any changes or other things to discuss, please let Jonathan = or I know. Thanks. BR, Rachel AVTEXT Audio/Video Transport Extensions WG Meeting =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Date and Time: THURSDAY 4/7/16, Afternoon Session III, 17:30-19:30 Room: Buen Ayre A Chairs: Jonathan Lennox / Rachel Huang 1. Note Well, Note Takers, Agenda Bashing - (Chairs, 17:30, 5 min) 2. WG Status - (Chairs, 17:35, 5 min) Status of working group draft: draft-ieft-avtext-lrr-02 [ready for WGLC] draft-ietf-avtext-rid-01 [ready for WGLC] draft-ietf-avtext-sdes-hdr-ext-05 [IETF LC] draft-ietf-avtext-splicing-notification-05 [IANA review] 3. Chartered work: Frame Marking RTP Header Extension (Mo Zanaty, 17:40, 30 min) draft-ietf-avtext-framemarking-01 Codec Control Messages for Layered (Stephan Wenger, 18:10, 20 min) draft-wenger-avtext-avpf-ccm-layered-00 4. Possible topic from RMCAT - (tbd, 18:30, 20 min) 5. Next steps and open mic - (Chairs, 18:50, 10 min) --_000_51E6A56BD6A85142B9D172C87FC3ABBB86E9A77Fnkgeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Here’s the draft agenda f= or AVTEXT meeting in Buenos Aires. And I already uploaded it.

https://www.ietf.org/proceedings/9= 5/agenda/agenda-95-avtext

So if you have any changes or o= ther things to discuss, please let Jonathan or I know. Thanks.

 

BR,

Rachel

 

AVTEXT A= udio/Video Transport Extensions WG Meeting

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Date and= Time: THURSDAY 4/7/16, Afternoon Session III, 17:30-19:30

Room: Bu= en Ayre A

Chairs: = Jonathan Lennox / Rachel Huang

&nb= sp;

1. Note = Well, Note Takers, Agenda Bashing - (Chairs, 17:30, 5 min)

&nb= sp;

2. WG St= atus - (Chairs, 17:35, 5 min)

&nb= sp;

 &n= bsp; Status of working group draft:

&nb= sp;

 &n= bsp;    draft-ieft-avtext-lrr-02    &nbs= p;       [ready for WGLC]

 &n= bsp;    draft-ietf-avtext-rid-01    &nbs= p;       [ready for WGLC]

 &n= bsp;    draft-ietf-avtext-sdes-hdr-ext-05   [IETF = LC]

 &n= bsp;    draft-ietf-avtext-splicing-notification-05 [IANA rev= iew]

&nb= sp;

3. Chart= ered work:

&nb= sp;

 &n= bsp; Frame Marking RTP Header Extension (Mo Zanaty, 17:40, 30 min)

&nb= sp;

 &n= bsp;    draft-ietf-avtext-framemarking-01<= /p>

&nb= sp;

 &n= bsp; Codec Control Messages for Layered (Stephan Wenger, 18:10, 20 min)

&nb= sp;

 &n= bsp;    draft-wenger-avtext-avpf-ccm-layered-00

&nb= sp;

4. Possi= ble topic from RMCAT - (tbd, 18:30, 20 min)

&nb= sp;

5. Next = steps and open mic - (Chairs, 18:50, 10 min)

 

 

--_000_51E6A56BD6A85142B9D172C87FC3ABBB86E9A77Fnkgeml513mbxchi_-- From nobody Tue Mar 29 08:37:31 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 B0CF912D94C for ; Tue, 29 Mar 2016 08:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, 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 EFdYXLUjhXKp for ; Tue, 29 Mar 2016 08:37:27 -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 478BE12D95C for ; Tue, 29 Mar 2016 08:36:13 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-99-56faa0eb842d Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 41.7C.23401.BE0AAF65; Tue, 29 Mar 2016 17:36:11 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.11]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Tue, 29 Mar 2016 17:36:10 +0200 From: Bo Burman To: Jonathan Lennox , "avtext@ietf.org" Thread-Topic: WGLC: draft-ietf-avtext-rid-01.txt Thread-Index: AQHRhNyboSUy9w68Q0mvCSDSWLKl8p9wfYfg Date: Tue, 29 Mar 2016 15:36:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM2K7q+7rBb/CDD706Vh8vHeD1WL/4vPM DkweS5b8ZPJoe3aHPYApissmJTUnsyy1SN8ugSvjwEuegskiFdvfTWZrYHzI38XIySEhYCKx 6kobG4QtJnHh3nogm4tDSOAIo0Tv5kesEM5iRondnV2sIFVsAhoS83fcZexi5OAQEfCV+L8l CSQsLKAvsXrBN7BBIgIGEpP3rWaGKDGS+PrUBCTMIqAq8Xp2JxOIzQvUueLlBrByIQEbiS+/ XzGBlHMK2Er8/W0MEmYUkJW4//0eC4jNLCAucevJfCaIMwUkluw5zwxhi0q8fPyPFcJWlPj4 ah8jRL2OxILdn9ggbG2JZQtfM0OsFZQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMYoWpxYX 56YbGemlFmUmFxfn5+nlpZZsYgRGyMEtv612MB587niIUYCDUYmHN2HlzzAh1sSy4srcQ4wS HMxKIrx983+FCfGmJFZWpRblxxeV5qQWH2KU5mBREudl+3Q5TEggPbEkNTs1tSC1CCbLxMEp 1cBowb9r3Z/IrdW//jFc/aT85cXZLWciPwdt9Gfby/mD+YtQ0pwvC5hZRUPiPeQW9N392C5t /d7X7Lb06aTyp6xXgyTkn85IXXjAae//T6HLlvsey524f4VtzOuHE+fFfl80VWbnKeetH7WM t4WK7n3Qfebly82cpwQ+CT36/n9/4IKXG9fzr35Z/VmJpTgj0VCLuag4EQDpAaYzjAIAAA== Archived-At: Subject: Re: [avtext] WGLC: draft-ietf-avtext-rid-01.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: Tue, 29 Mar 2016 15:37:29 -0000 I've reviewed this and have the following comments: 1) In section 3 you use capitalized versions of terms from RFC7656. One of = the late changes in the publication process of RFC7656 was to not use capit= alized terms, so you might want to align to non-capitalized versions. No st= rong opinion on that one, though. 2) Would it be correct, semantically, to add the following text at the end = of the second paragraph in section 3; "...to refer to this construct of a s= ource RTP stream that originates either from an encoded stream or a depende= nt stream, but is not a redundancy RTP stream"? If so, I suggest to make th= at clarification, or otherwise change text in that paragraph to make it cle= ar. 3) To align with a recent update of draft-ietf-avtext-sdes-hdr-ext, IANA re= gistration of RID and RRID in RTP SDES Compact Header Extensions registry s= hould also be added to sections 5.1 and 5.2, respectively, like: 5.1: ... It is requested that the following SDES item is registered in the RTP SDES Compact Header Extensions registry: Extension URI: urn:ietf:params:rtp-hdrext:sdes:rid Description: Source Description: RTP Stream Identifier (SDES RID) Contact: Authors of [RFCXXXX] Reference: [RFCXXXX] 5.2: ... It is requested that the following SDES item is registered in the RTP SDES Compact Header Extensions registry: Extension URI: urn:ietf:params:rtp-hdrext:sdes:rrid Description: Source Description: Redundancy RTP Stream Identifier (SDES RRID) Contact: Authors of [RFCXXXX] Reference: [RFCXXXX] Cheers, Bo > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Jonathan Lenno= x > Sent: den 23 mars 2016 09:19 > To: avtext@ietf.org > Subject: [avtext] WGLC: draft-ietf-avtext-rid-01.txt >=20 > This is to announce a 1.5 week Working Group Last Call for >=20 > draft-ietf-avtext-rid-01 >=20 > as proposed standard. >=20 > Please review and provide any comments you may have on the document by Su= nday, April 3 (the beginning of the > Buenos Aires IETF meeting). Comments should be sent to the document autho= rs and the AVTEXT WG list. >=20 > If you review the document but do not have any comments, please send a no= te to that effect as well. >=20 > Thank you! >=20 > Jonathan (AVTEXT co-chair) >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Tue Mar 29 09:31: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 B33C712DBC0 for ; Tue, 29 Mar 2016 09:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ImOaS9pAtqTe for ; Tue, 29 Mar 2016 09:31:43 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBE0E12DAF1 for ; Tue, 29 Mar 2016 09:26:12 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id k1so25417626vkb.0 for ; Tue, 29 Mar 2016 09:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C4Xezc14utXXGAINduO+6fEufDErY800UdvRg7W5c+8=; b=tIA7oFagW1A4RHR7cwMLFP6LMvl36y7EJfC8DVoJkiAmXATKkO2C804Nk660PP1yM2 YsSJSWM9d/5HRo+Vbx7e6R5ZRSX1A+HUIipsxil18a4NqIQ/95w+QXbF3td/YRQg9xTG 8MDgThDotBwy3WWVDULoQhM0LIVe7qOdmCtaxZUHHDI1WAunLMOEYtAG9VJY51202JhH nnKH0ZpGCCNNjJHRdIWRJxCYQvruRT1o+UwwzgZ0tQhMz5m1RhVpJ5eVpMoApUE0Vy90 uHRrNXRRPquOGfoXwW5RZYlY3d3pYzfvrmpa0FCPxOOk24qLMG6ZWDsQCxODdmG5g2Lk 9Mmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C4Xezc14utXXGAINduO+6fEufDErY800UdvRg7W5c+8=; b=lNUx4Du5ztkxfzPr2Y2BoRg+LPgj+06avM4I0aABu+jGh/S8nXqRDcD9b5Abfx/wSY 6OoPtZ4g6kCWIIwg9KsjHEZIfL4Cipx5GukBqLTf4s0MG26DUL3NQWFRoZeYlFL7IU4f vPnB1GjF9O9dpmpCSyDzdjqGQNU+3vZzt99UVmi5MX0yhlgS3HdeR3v1g0l3LtvVZanq R7N6Qf7dJEyFDZhPaAjqGfhW2h9N9vl4YGR+QH6g9njXVXl6Lm6zA+qdXN+VhXCY+69Q Hy9K8CXwYBtODxxDaekh9rfN8NkULaQUL+PN0TRg6VfVql1PjFcsD7KJJ9EyO4OOYUc+ kdwQ== X-Gm-Message-State: AD7BkJLhfs2BJ5xdMihBfYGtRTpiKHzLYY7tL//9sqEoXMwUXRkr+q/ZYYhCfTcsGIRXSlYn2vY0TS4x9A26BA== X-Received: by 10.159.39.196 with SMTP id b62mr1758181uab.69.1459268771734; Tue, 29 Mar 2016 09:26:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.3.65 with HTTP; Tue, 29 Mar 2016 09:25:52 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Tue, 29 Mar 2016 09:25:52 -0700 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=94eb2c123344c56b4c052f327c53 Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] WGLC: draft-ietf-avtext-rid-01.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: Tue, 29 Mar 2016 16:31:47 -0000 --94eb2c123344c56b4c052f327c53 Content-Type: text/plain; charset=UTF-8 I have reviewed the document and have the following comment: Need for RRID. Currently, draft-ietf-mmusic-rid does not make use of the RRID. As I understand it, no WebRTC browsers are currently planning to implement the RRID. Furthermore, neither the WebRTC 1.0 API nor ORTC supports the RRID. Given this, do we really need to include the RRID in this document? Minor editorial issues below On Wed, Mar 23, 2016 at 1:18 AM, Jonathan Lennox wrote: > This is to announce a 1.5 week Working Group Last Call for > > draft-ietf-avtext-rid-01 > > as proposed standard. > > Please review and provide any comments you may have on the document by > Sunday, April 3 (the beginning of the Buenos Aires IETF meeting). Comments > should be sent to the document authors and the AVTEXT WG list. > > If you review the document but do not have any comments, please send a > note to that effect as well. > > Thank you! > > Jonathan (AVTEXT co-chair) > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > --94eb2c123344c56b4c052f327c53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed the document and have the following commen= t:=C2=A0

Need for RRID.=C2=A0 Currently, draft-ietf-mmus= ic-rid does not make use of the RRID.=C2=A0 As I understand it, no WebRTC b= rowsers are currently planning to implement the RRID.=C2=A0 Furthermore, ne= ither the WebRTC 1.0 API nor ORTC supports the RRID. =C2=A0=C2=A0

Given this, do we really need to include the RRID in this d= ocument? =C2=A0




<= /div>

Minor editorial issues below



On Wed, Mar 23, 2016 at 1:18 AM, Jonathan Lennox <jona= than@vidyo.com> wrote:
This= is to announce a 1.5 week Working Group Last Call for

=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-avtext-rid-01

as proposed standard.

Please review and provide any comments you may have on the document by Sund= ay, April 3 (the beginning of the Buenos Aires IETF meeting). Comments shou= ld be sent to the document authors and the AVTEXT WG list.

If you review the document but do not have any comments, please send a note= to that effect as well.

Thank you!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jonathan (AVTEXT co-chair)

_______________________________________________
avtext mailing list
avtext@ietf.org
https://www.ietf.org/mailman/listinfo/avtext

--94eb2c123344c56b4c052f327c53-- From nobody Tue Mar 29 14:35:07 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 830E212D0FF; Tue, 29 Mar 2016 14:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 I5J1UBUTYJq4; Tue, 29 Mar 2016 14:35:04 -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 EF68E12DA65; Tue, 29 Mar 2016 14:19:10 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2TLIvN4000905 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 29 Mar 2016 16:18:57 -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.10] From: "Ben Campbell" To: Huangyihong , "Magnus Westerlund" Date: Tue, 29 Mar 2016 16:18:56 -0500 Message-ID: In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86E9A264@nkgeml513-mbx.china.huawei.com> References: <56D6E18F.8050603@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E8C95B@nkgeml513-mbs.china.huawei.com> <56EBF6ED.6060207@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E99046@nkgeml513-mbx.china.huawei.com> <56F004E5.7070702@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E992E0@nkgeml513-mbx.china.huawei.com> <56F11FF9.20604@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E9A264@nkgeml513-mbx.china.huawei.com> 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: Cc: "draft-ietf-avtext-splicing-notification@ietf.org" , "avtext@ietf.org" Subject: Re: [avtext] Some comments on draft-ietf-avtext-splicing-notification-04 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, 29 Mar 2016 21:35:06 -0000 Hi, Where have we landed with this? Will a new revision be required? Thanks! Ben. On 23 Mar 2016, at 4:29, Huangyihong (Rachel) wrote: > Hi Magnus, > > Inline please. > > BR, > Rachel > > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Tuesday, March 22, 2016 6:36 PM >> To: Huangyihong (Rachel); avtext@ietf.org; Ben Campbell; >> draft-ietf-avtext-splicing-notification@ietf.org >> Subject: Re: 答复: Some comments on >> draft-ietf-avtext-splicing-notification-04 >> >> Den 2016-03-21 kl. 17:06, skrev Huangyihong (Rachel): >>> Hi Magus, >>> >>> Thank you for the quick response. I think below is the only issue >>> that >>> we're discussing. I'll submit a new version to reflect the issues >>> you >>> have. >>> >>> BR, Rachel >>> >>>>>>> >>>>>>> 3. Section 3.1: >>>>>>> >>>>>>> This section is not clear on what is the data part of the header >>>>>>> extension format. As it is not the header extension that can >>>>>>> determine if there will be usage of one-byte vs two-byte format >>>>>>> that will be used, this needs to be defined in a more un >>>>>> >>>>>> [Rachel]: I don't understand this. The editing seems unfinished. >>>>>> The splicing RTP header extension uses one-byte format with the >>>>>> fixed bit pattern 0xBEDE. >>>>> >>>>> Sorry, what is missing is: The definition of the data field need >>>>> to >>>>> be done in a way that is agnostic to if 1 or 2-byte headers are >>>>> being used in the header extension. >>>>> >>>> >>>> [Rachel]: I don't understand why should this extension to be >>>> agnostic >>>> for extension header types. There's no such limitation in [RFC5285] >>>> if I read it correctly. And based on [RFC5285], it says: >>>> >>>> " There are two variants of the extension: one-byte and two-byte >>>> headers. Since it is expected that (a) the number of extensions in >>>> any given RTP session is small and (b) the extensions themselves >>>> are >>>> small, the one-byte header form is preferred and MUST be supported >>>> by >>>> all receivers. A stream MUST contain only one-byte or two-byte >>>> headers: they MUST NOT be mixed within a stream. >>>> Transmitters SHOULD NOT use the two-byte form when all extensions >>>> are >>>> small enough for the one-byte header form. " >>>> >>>> For splicing extension, it can be classified into a) case. That's >>>> why >>>> we uses one-byte header, and it is preferred and mandated by >>>> receivers. So I can't imagine any other cases to use 2-byte header. >>>> And by the way, [RFC6051] also only defines one-byte header. >>> >>> So this debate do gets us into RFC5285 update country. However the >>> issue is that although a particular RTP header extension has a >>> preference or requirement for which format to use. The actual format >>> used in an actual RTP packet will be depending on the union of all >>> the >>> requirement for header extension format. For example the SDES header >>> extension is one that can require to use the 2-byte format due to >>> the >>> SDES item's length (>16 bytes). If that header extension and yours >>> needs to be in the same packet, then also yours need to use the >>> 2-byte >>> header format in this particular packet. >>> >>> [Rachel]: The RFC5285 update already permits to use 1-byte and >>> 2-byte >>> format in the same RTP stream. You're saying the case they're used >>> in >>> one RTP packet. For splicing header extension, it only appears a >>> number of RTP packet instead of all the RTP packets. So I'm just >>> curious the possibility of the 2 kinds of extensions must be in the >>> same packet. >> >> No, that is not what I try to say. I am saying that within one RTP >> stream, i.e. >> under one SSRC. Then in one packet one might need to use the 2-byte >> format >> due to that an additional RTP header extension is added to the one >> with Splicing >> information. In a later packet where there is need to send a splicing >> RTP header >> extension, there might not be any other RTP header extension, nor one >> that >> requires the two-byte header extension. Thus, this packet can be sent >> with the >> 1-byte format. > > [Rachel]: Yes, I understand you point. And that's all what RFC5285 > update is talking about, see below > > " > A stream MUST contain only one-byte or two-byte > headers unless it is known that all recipients support mixing, either > by offer/answer negotiation (see section 6) or by out-of-band > knowledge. One-byte and two-byte headers MUST NOT be mixed in a > single RTP packet. > " > >> >>> >>> This is issue that needs to be clarified in RFC 5285 update, and >>> hopefully to allow a particular SSRC to switch between formats on a >>> packet by packet basis. If not then we end up in a situation where >>> hard choices will have to be done when conflicting requirements >>> occur. >>> >>> The above issue is from my perspective that if one defines a header >>> extension in such a way that it is clear on what is the data part >>> and >>> don't lock down the format to use, then it will work with the >>> updated >>> spec. >>> >>> [Rachel]: It's no harm to include a 2-byte format in this version to >>> avoid the case that you mentioned. And I'll do it right now. >> >> Yes, that is one way of doing it. The point I tried to made is that >> one can define >> ones RTP header extension is such a way that it becomes agnostic to >> if 1-byte >> or 2-byte format is used for the header extensions. This should be >> the >> recommended practice unless the format requires the 2-byte format. > > [Rachel]: We design the splicing header extension in a bit-saving way, > because the length of data field is fixed. > >> >> I will have to review the RFC 5285 update to see if this has >> sufficient >> clarifications in this area. I would recommend that also the rest of >> the WG do >> take a look on the document update. >> >> 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 Mar 29 17:48:55 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 1DB0C12D120; Tue, 29 Mar 2016 17:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 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, T_RP_MATCHES_RCVD=-0.01] 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 QzAuTqPD6yz5; Tue, 29 Mar 2016 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 62DB112D165; Tue, 29 Mar 2016 17:48:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLJ73993; Wed, 30 Mar 2016 00:48:47 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 30 Mar 2016 01:46:00 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Wed, 30 Mar 2016 08:45:56 +0800 From: "Huangyihong (Rachel)" To: Ben Campbell , Magnus Westerlund Thread-Topic: Some comments on draft-ietf-avtext-splicing-notification-04 Thread-Index: AQHRigCkpPvGOEYLAE2hMIKdnAnFu59xJUew Date: Wed, 30 Mar 2016 00:45:56 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E9C134@nkgeml513-mbx.china.huawei.com> References: <56D6E18F.8050603@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E8C95B@nkgeml513-mbs.china.huawei.com> <56EBF6ED.6060207@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E99046@nkgeml513-mbx.china.huawei.com> <56F004E5.7070702@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E992E0@nkgeml513-mbx.china.huawei.com> <56F11FF9.20604@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86E9A264@nkgeml513-mbx.china.huawei.com> 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.136.79.191] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.56FB2270.026B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 34bde8ab86815f8c37acfb7df35083bd Archived-At: Cc: "draft-ietf-avtext-splicing-notification@ietf.org" , "avtext@ietf.org" Subject: Re: [avtext] Some comments on draft-ietf-avtext-splicing-notification-04 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, 30 Mar 2016 00:48:54 -0000 SGkgQmVuLA0KDQpBIG5ldyB2ZXJzaW9uIGhhcyBiZWVuIGFscmVhZHkgc3VibWl0dGVkIHRvIHJl ZmxlY3QgYWxsIHRoZSBjb21tZW50cyBmcm9tIE1hZ251cywgd2hpY2ggYWxyZWFkeSBpbmNsdWRl cyBhIHNvbHV0aW9uIGZvciB0aGUgZm9sbG93aW5nIGlzc3VlLiBIZSB3aWxsIGNoZWNrIGlmIGl0 IGFkZHJlc3NlcyBhbGwgaGlzIGNvbmNlcm5zLg0KDQpCUiwNClJhY2hlbA0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJlbkBub3N0 cnVtLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBNYXJjaCAzMCwgMjAxNiA1OjE5IEFNDQo+IFRv OiBIdWFuZ3lpaG9uZyAoUmFjaGVsKTsgTWFnbnVzIFdlc3Rlcmx1bmQNCj4gQ2M6IGF2dGV4dEBp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmctbm90aWZpY2F0aW9uQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBTb21lIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGlj aW5nLW5vdGlmaWNhdGlvbi0wNA0KPiANCj4gSGksDQo+IA0KPiBXaGVyZSBoYXZlIHdlIGxhbmRl ZCB3aXRoIHRoaXM/IFdpbGwgYSBuZXcgcmV2aXNpb24gYmUgcmVxdWlyZWQ/DQo+IA0KPiBUaGFu a3MhDQo+IA0KPiBCZW4uDQo+IA0KPiBPbiAyMyBNYXIgMjAxNiwgYXQgNDoyOSwgSHVhbmd5aWhv bmcgKFJhY2hlbCkgd3JvdGU6DQo+IA0KPiA+IEhpIE1hZ251cywNCj4gPg0KPiA+IElubGluZSBw bGVhc2UuDQo+ID4NCj4gPiBCUiwNCj4gPiBSYWNoZWwNCj4gPg0KPiA+DQo+ID4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IE1hZ251cyBXZXN0ZXJsdW5kIFttYWlsdG86 bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tXQ0KPiA+PiBTZW50OiBUdWVzZGF5LCBNYXJj aCAyMiwgMjAxNiA2OjM2IFBNDQo+ID4+IFRvOiBIdWFuZ3lpaG9uZyAoUmFjaGVsKTsgYXZ0ZXh0 QGlldGYub3JnOyBCZW4gQ2FtcGJlbGw7DQo+ID4+IGRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5n LW5vdGlmaWNhdGlvbkBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTog562U5aSNOiBTb21lIGNv bW1lbnRzIG9uDQo+ID4+IGRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0w NA0KPiA+Pg0KPiA+PiBEZW4gMjAxNi0wMy0yMSBrbC4gMTc6MDYsIHNrcmV2IEh1YW5neWlob25n IChSYWNoZWwpOg0KPiA+Pj4gSGkgTWFndXMsDQo+ID4+Pg0KPiA+Pj4gVGhhbmsgeW91IGZvciB0 aGUgcXVpY2sgcmVzcG9uc2UuIEkgdGhpbmsgYmVsb3cgaXMgdGhlIG9ubHkgaXNzdWUNCj4gPj4+ IHRoYXQgd2UncmUgZGlzY3Vzc2luZy4gSSdsbCBzdWJtaXQgYSBuZXcgdmVyc2lvbiB0byByZWZs ZWN0IHRoZQ0KPiA+Pj4gaXNzdWVzIHlvdSBoYXZlLg0KPiA+Pj4NCj4gPj4+IEJSLCBSYWNoZWwN Cj4gPj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiAzLiBTZWN0aW9uIDMuMToNCj4gPj4+Pj4+Pg0K PiA+Pj4+Pj4+IFRoaXMgc2VjdGlvbiBpcyBub3QgY2xlYXIgb24gd2hhdCBpcyB0aGUgZGF0YSBw YXJ0IG9mIHRoZSBoZWFkZXINCj4gPj4+Pj4+PiBleHRlbnNpb24gZm9ybWF0LiBBcyBpdCBpcyBu b3QgdGhlIGhlYWRlciBleHRlbnNpb24gdGhhdCBjYW4NCj4gPj4+Pj4+PiBkZXRlcm1pbmUgaWYg dGhlcmUgd2lsbCBiZSB1c2FnZSBvZiBvbmUtYnl0ZSB2cyB0d28tYnl0ZSBmb3JtYXQNCj4gPj4+ Pj4+PiB0aGF0IHdpbGwgYmUgdXNlZCwgdGhpcyBuZWVkcyB0byBiZSBkZWZpbmVkIGluIGEgbW9y ZSB1bg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFtSYWNoZWxdOiBJIGRvbid0IHVuZGVyc3RhbmQgdGhp cy4gVGhlIGVkaXRpbmcgc2VlbXMgdW5maW5pc2hlZC4NCj4gPj4+Pj4+IFRoZSBzcGxpY2luZyBS VFAgaGVhZGVyIGV4dGVuc2lvbiB1c2VzIG9uZS1ieXRlIGZvcm1hdCB3aXRoIHRoZQ0KPiA+Pj4+ Pj4gZml4ZWQgYml0IHBhdHRlcm4gMHhCRURFLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBTb3JyeSwgd2hh dCBpcyBtaXNzaW5nIGlzOiBUaGUgZGVmaW5pdGlvbiBvZiB0aGUgZGF0YSBmaWVsZCBuZWVkDQo+ ID4+Pj4+IHRvIGJlIGRvbmUgaW4gYSB3YXkgdGhhdCBpcyBhZ25vc3RpYyB0byBpZiAxIG9yIDIt Ynl0ZSBoZWFkZXJzIGFyZQ0KPiA+Pj4+PiBiZWluZyB1c2VkIGluIHRoZSBoZWFkZXIgZXh0ZW5z aW9uLg0KPiA+Pj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gW1JhY2hlbF06IEkgZG9uJ3QgdW5kZXJzdGFu ZCB3aHkgc2hvdWxkIHRoaXMgZXh0ZW5zaW9uIHRvIGJlDQo+ID4+Pj4gYWdub3N0aWMNCj4gPj4+ PiBmb3IgZXh0ZW5zaW9uIGhlYWRlciB0eXBlcy4gVGhlcmUncyBubyBzdWNoIGxpbWl0YXRpb24g aW4gW1JGQzUyODVdDQo+ID4+Pj4gaWYgSSByZWFkIGl0IGNvcnJlY3RseS4gQW5kIGJhc2VkIG9u IFtSRkM1Mjg1XSwgaXQgc2F5czoNCj4gPj4+Pg0KPiA+Pj4+ICIgVGhlcmUgYXJlIHR3byB2YXJp YW50cyBvZiB0aGUgZXh0ZW5zaW9uOiBvbmUtYnl0ZSBhbmQgdHdvLWJ5dGUNCj4gPj4+PiBoZWFk ZXJzLiAgU2luY2UgaXQgaXMgZXhwZWN0ZWQgdGhhdCAoYSkgdGhlIG51bWJlciBvZiBleHRlbnNp b25zIGluDQo+ID4+Pj4gYW55IGdpdmVuIFJUUCBzZXNzaW9uIGlzIHNtYWxsIGFuZCAoYikgdGhl IGV4dGVuc2lvbnMgdGhlbXNlbHZlcw0KPiA+Pj4+IGFyZQ0KPiA+Pj4+IHNtYWxsLCB0aGUgb25l LWJ5dGUgaGVhZGVyIGZvcm0gaXMgcHJlZmVycmVkIGFuZCBNVVNUIGJlIHN1cHBvcnRlZA0KPiA+ Pj4+IGJ5DQo+ID4+Pj4gYWxsIHJlY2VpdmVycy4gIEEgc3RyZWFtIE1VU1QgY29udGFpbiBvbmx5 IG9uZS1ieXRlIG9yIHR3by1ieXRlDQo+ID4+Pj4gaGVhZGVyczogdGhleSBNVVNUIE5PVCBiZSBt aXhlZCB3aXRoaW4gYSBzdHJlYW0uDQo+ID4+Pj4gVHJhbnNtaXR0ZXJzIFNIT1VMRCBOT1QgdXNl IHRoZSB0d28tYnl0ZSBmb3JtIHdoZW4gYWxsIGV4dGVuc2lvbnMNCj4gPj4+PiBhcmUNCj4gPj4+ PiBzbWFsbCBlbm91Z2ggZm9yIHRoZSBvbmUtYnl0ZSBoZWFkZXIgZm9ybS4gIg0KPiA+Pj4+DQo+ ID4+Pj4gRm9yIHNwbGljaW5nIGV4dGVuc2lvbiwgaXQgY2FuIGJlIGNsYXNzaWZpZWQgaW50byBh KSBjYXNlLiBUaGF0J3MNCj4gPj4+PiB3aHkNCj4gPj4+PiB3ZSB1c2VzIG9uZS1ieXRlIGhlYWRl ciwgYW5kIGl0IGlzIHByZWZlcnJlZCBhbmQgbWFuZGF0ZWQgYnkNCj4gPj4+PiByZWNlaXZlcnMu IFNvIEkgY2FuJ3QgaW1hZ2luZSBhbnkgb3RoZXIgY2FzZXMgdG8gdXNlIDItYnl0ZSBoZWFkZXIu DQo+ID4+Pj4gQW5kIGJ5IHRoZSB3YXksIFtSRkM2MDUxXSBhbHNvIG9ubHkgZGVmaW5lcyBvbmUt Ynl0ZSBoZWFkZXIuDQo+ID4+Pg0KPiA+Pj4gU28gdGhpcyBkZWJhdGUgZG8gZ2V0cyB1cyBpbnRv IFJGQzUyODUgdXBkYXRlIGNvdW50cnkuIEhvd2V2ZXIgdGhlDQo+ID4+PiBpc3N1ZSBpcyB0aGF0 IGFsdGhvdWdoIGEgcGFydGljdWxhciBSVFAgaGVhZGVyIGV4dGVuc2lvbiBoYXMgYQ0KPiA+Pj4g cHJlZmVyZW5jZSBvciByZXF1aXJlbWVudCBmb3Igd2hpY2ggZm9ybWF0IHRvIHVzZS4gVGhlIGFj dHVhbCBmb3JtYXQNCj4gPj4+IHVzZWQgaW4gYW4gYWN0dWFsIFJUUCBwYWNrZXQgd2lsbCBiZSBk ZXBlbmRpbmcgb24gdGhlIHVuaW9uIG9mIGFsbA0KPiA+Pj4gdGhlDQo+ID4+PiByZXF1aXJlbWVu dCBmb3IgaGVhZGVyIGV4dGVuc2lvbiBmb3JtYXQuIEZvciBleGFtcGxlIHRoZSBTREVTIGhlYWRl cg0KPiA+Pj4gZXh0ZW5zaW9uIGlzIG9uZSB0aGF0IGNhbiByZXF1aXJlIHRvIHVzZSB0aGUgMi1i eXRlIGZvcm1hdCBkdWUgdG8NCj4gPj4+IHRoZQ0KPiA+Pj4gU0RFUyBpdGVtJ3MgbGVuZ3RoICg+ MTYgYnl0ZXMpLiBJZiB0aGF0IGhlYWRlciBleHRlbnNpb24gYW5kIHlvdXJzDQo+ID4+PiBuZWVk cyB0byBiZSBpbiB0aGUgc2FtZSBwYWNrZXQsIHRoZW4gYWxzbyB5b3VycyBuZWVkIHRvIHVzZSB0 aGUNCj4gPj4+IDItYnl0ZQ0KPiA+Pj4gaGVhZGVyIGZvcm1hdCBpbiB0aGlzIHBhcnRpY3VsYXIg cGFja2V0Lg0KPiA+Pj4NCj4gPj4+IFtSYWNoZWxdOiBUaGUgUkZDNTI4NSB1cGRhdGUgYWxyZWFk eSBwZXJtaXRzIHRvIHVzZSAxLWJ5dGUgYW5kDQo+ID4+PiAyLWJ5dGUNCj4gPj4+IGZvcm1hdCBp biB0aGUgc2FtZSBSVFAgc3RyZWFtLiBZb3UncmUgc2F5aW5nIHRoZSBjYXNlIHRoZXkncmUgdXNl ZA0KPiA+Pj4gaW4NCj4gPj4+IG9uZSBSVFAgcGFja2V0LiBGb3Igc3BsaWNpbmcgaGVhZGVyIGV4 dGVuc2lvbiwgaXQgb25seSBhcHBlYXJzIGENCj4gPj4+IG51bWJlciBvZiBSVFAgcGFja2V0IGlu c3RlYWQgb2YgYWxsIHRoZSBSVFAgcGFja2V0cy4gU28gSSdtIGp1c3QNCj4gPj4+IGN1cmlvdXMg dGhlIHBvc3NpYmlsaXR5IG9mIHRoZSAyIGtpbmRzIG9mIGV4dGVuc2lvbnMgbXVzdCBiZSBpbiB0 aGUNCj4gPj4+IHNhbWUgcGFja2V0Lg0KPiA+Pg0KPiA+PiBObywgdGhhdCBpcyBub3Qgd2hhdCBJ IHRyeSB0byBzYXkuIEkgYW0gc2F5aW5nIHRoYXQgd2l0aGluIG9uZSBSVFANCj4gPj4gc3RyZWFt LCBpLmUuDQo+ID4+IHVuZGVyIG9uZSBTU1JDLiBUaGVuIGluIG9uZSBwYWNrZXQgb25lIG1pZ2h0 IG5lZWQgdG8gdXNlIHRoZSAyLWJ5dGUNCj4gPj4gZm9ybWF0DQo+ID4+IGR1ZSB0byB0aGF0IGFu IGFkZGl0aW9uYWwgUlRQIGhlYWRlciBleHRlbnNpb24gaXMgYWRkZWQgdG8gdGhlIG9uZQ0KPiA+ PiB3aXRoIFNwbGljaW5nDQo+ID4+IGluZm9ybWF0aW9uLiBJbiBhIGxhdGVyIHBhY2tldCB3aGVy ZSB0aGVyZSBpcyBuZWVkIHRvIHNlbmQgYSBzcGxpY2luZw0KPiA+PiBSVFAgaGVhZGVyDQo+ID4+ IGV4dGVuc2lvbiwgdGhlcmUgbWlnaHQgbm90IGJlIGFueSBvdGhlciBSVFAgaGVhZGVyIGV4dGVu c2lvbiwgbm9yIG9uZQ0KPiA+PiB0aGF0DQo+ID4+IHJlcXVpcmVzIHRoZSB0d28tYnl0ZSBoZWFk ZXIgZXh0ZW5zaW9uLiBUaHVzLCB0aGlzIHBhY2tldCBjYW4gYmUgc2VudA0KPiA+PiB3aXRoIHRo ZQ0KPiA+PiAxLWJ5dGUgZm9ybWF0Lg0KPiA+DQo+ID4gW1JhY2hlbF06IFllcywgSSB1bmRlcnN0 YW5kIHlvdSBwb2ludC4gQW5kIHRoYXQncyBhbGwgd2hhdCBSRkM1Mjg1DQo+ID4gdXBkYXRlIGlz IHRhbGtpbmcgYWJvdXQsIHNlZSBiZWxvdw0KPiA+DQo+ID4gIg0KPiA+IEEgc3RyZWFtIE1VU1Qg Y29udGFpbiBvbmx5IG9uZS1ieXRlIG9yIHR3by1ieXRlDQo+ID4gaGVhZGVycyB1bmxlc3MgaXQg aXMga25vd24gdGhhdCBhbGwgcmVjaXBpZW50cyBzdXBwb3J0IG1peGluZywgZWl0aGVyDQo+ID4g Ynkgb2ZmZXIvYW5zd2VyIG5lZ290aWF0aW9uIChzZWUgc2VjdGlvbiA2KSBvciBieSBvdXQtb2Yt YmFuZA0KPiA+IGtub3dsZWRnZS4gIE9uZS1ieXRlIGFuZCB0d28tYnl0ZSBoZWFkZXJzIE1VU1Qg Tk9UIGJlIG1peGVkIGluIGENCj4gPiBzaW5nbGUgUlRQIHBhY2tldC4NCj4gPiAiDQo+ID4NCj4g Pj4NCj4gPj4+DQo+ID4+PiBUaGlzIGlzIGlzc3VlIHRoYXQgbmVlZHMgdG8gYmUgY2xhcmlmaWVk IGluIFJGQyA1Mjg1IHVwZGF0ZSwgYW5kDQo+ID4+PiBob3BlZnVsbHkgdG8gYWxsb3cgYSBwYXJ0 aWN1bGFyIFNTUkMgdG8gc3dpdGNoIGJldHdlZW4gZm9ybWF0cyBvbiBhDQo+ID4+PiBwYWNrZXQg YnkgcGFja2V0IGJhc2lzLiBJZiBub3QgdGhlbiB3ZSBlbmQgdXAgaW4gYSBzaXR1YXRpb24gd2hl cmUNCj4gPj4+IGhhcmQgY2hvaWNlcyB3aWxsIGhhdmUgdG8gYmUgZG9uZSB3aGVuIGNvbmZsaWN0 aW5nIHJlcXVpcmVtZW50cw0KPiA+Pj4gb2NjdXIuDQo+ID4+Pg0KPiA+Pj4gVGhlIGFib3ZlIGlz c3VlIGlzIGZyb20gbXkgcGVyc3BlY3RpdmUgdGhhdCBpZiBvbmUgZGVmaW5lcyBhIGhlYWRlcg0K PiA+Pj4gZXh0ZW5zaW9uIGluIHN1Y2ggYSB3YXkgdGhhdCBpdCBpcyBjbGVhciBvbiB3aGF0IGlz IHRoZSBkYXRhIHBhcnQNCj4gPj4+IGFuZA0KPiA+Pj4gZG9uJ3QgbG9jayBkb3duIHRoZSBmb3Jt YXQgdG8gdXNlLCB0aGVuIGl0IHdpbGwgd29yayB3aXRoIHRoZQ0KPiA+Pj4gdXBkYXRlZA0KPiA+ Pj4gc3BlYy4NCj4gPj4+DQo+ID4+PiBbUmFjaGVsXTogSXQncyBubyBoYXJtIHRvIGluY2x1ZGUg YSAyLWJ5dGUgZm9ybWF0IGluIHRoaXMgdmVyc2lvbiB0bw0KPiA+Pj4gYXZvaWQgdGhlIGNhc2Ug dGhhdCB5b3UgbWVudGlvbmVkLiBBbmQgSSdsbCBkbyBpdCByaWdodCBub3cuDQo+ID4+DQo+ID4+ IFllcywgdGhhdCBpcyBvbmUgd2F5IG9mIGRvaW5nIGl0LiBUaGUgcG9pbnQgSSB0cmllZCB0byBt YWRlIGlzIHRoYXQNCj4gPj4gb25lIGNhbiBkZWZpbmUNCj4gPj4gb25lcyBSVFAgaGVhZGVyIGV4 dGVuc2lvbiBpcyBzdWNoIGEgd2F5IHRoYXQgaXQgYmVjb21lcyBhZ25vc3RpYyB0bw0KPiA+PiBp ZiAxLWJ5dGUNCj4gPj4gb3IgMi1ieXRlIGZvcm1hdCBpcyB1c2VkIGZvciB0aGUgaGVhZGVyIGV4 dGVuc2lvbnMuIFRoaXMgc2hvdWxkIGJlDQo+ID4+IHRoZQ0KPiA+PiByZWNvbW1lbmRlZCBwcmFj dGljZSB1bmxlc3MgdGhlIGZvcm1hdCByZXF1aXJlcyB0aGUgMi1ieXRlIGZvcm1hdC4NCj4gPg0K PiA+IFtSYWNoZWxdOiBXZSBkZXNpZ24gdGhlIHNwbGljaW5nIGhlYWRlciBleHRlbnNpb24gaW4g YSBiaXQtc2F2aW5nIHdheSwNCj4gPiBiZWNhdXNlIHRoZSBsZW5ndGggb2YgZGF0YSBmaWVsZCBp cyBmaXhlZC4NCj4gPg0KPiA+Pg0KPiA+PiBJIHdpbGwgaGF2ZSB0byByZXZpZXcgdGhlIFJGQyA1 Mjg1IHVwZGF0ZSB0byBzZWUgaWYgdGhpcyBoYXMNCj4gPj4gc3VmZmljaWVudA0KPiA+PiBjbGFy aWZpY2F0aW9ucyBpbiB0aGlzIGFyZWEuIEkgd291bGQgcmVjb21tZW5kIHRoYXQgYWxzbyB0aGUg cmVzdCBvZg0KPiA+PiB0aGUgV0cgZG8NCj4gPj4gdGFrZSBhIGxvb2sgb24gdGhlIGRvY3VtZW50 IHVwZGF0ZS4NCj4gPj4NCj4gPj4gY2hlZXJzDQo+ID4+DQo+ID4+IE1hZ251cyBXZXN0ZXJsdW5k DQo+ID4+DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gU2VydmljZXMsIE1lZGlhIGFuZCBOZXR3 b3JrIGZlYXR1cmVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFhNDQo+ID4+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gPj4gRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4 Mjg3DQo+ID4+IEbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAw OTQ5MDc5DQo+ID4+IFNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiB8IG1haWx0bzogbWFnbnVz Lndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== From nobody Wed Mar 30 08:39:04 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 A74CA12D19F for ; Wed, 30 Mar 2016 08:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 wrqIa-oZ7FgD for ; Wed, 30 Mar 2016 08:39:01 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39F3212D73C for ; Wed, 30 Mar 2016 08:38:58 -0700 (PDT) Received: from [130.209.247.112] (port=59427 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1alICt-00048b-RG; Wed, 30 Mar 2016 16:38:56 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: Date: Wed, 30 Mar 2016 16:38:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jonathan Lennox X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] WGLC: draft-ietf-avtext-rid-01.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: Wed, 30 Mar 2016 15:39:02 -0000 > On 23 Mar 2016, at 08:18, Jonathan Lennox wrote: >=20 > This is to announce a 1.5 week Working Group Last Call for >=20 > draft-ietf-avtext-rid-01 >=20 > as proposed standard. >=20 > Please review and provide any comments you may have on the document by = Sunday, April 3 (the beginning of the Buenos Aires IETF meeting). = Comments should be sent to the document authors and the AVTEXT WG list. The introduction to this draft still says: > To address this situation, we define a new RTCP SDES identifier = that > uniquely identifies a single stream.=20 shortly followed by: > when this new > identifier is in use, it appears (and contains the same value) in > both in the Redundancy RTP Stream as well as the stream it is > correcting. That seems contradictory to me.=20 I understand that there=E2=80=99s no consensus to make the RID a unique = per-stream identifier, and I=E2=80=99m not asking to revisit that = discussion. However, the draft does need to be revised to not claim that = the RID uniquely identifies a stream, since it doesn=E2=80=99t in all = cases. --=20 Colin Perkins https://csperkins.org/ From nobody Wed Mar 30 12:07:52 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 0A78812D8C6 for ; Wed, 30 Mar 2016 12:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 29LT16Ua8qPn for ; Wed, 30 Mar 2016 12:07:50 -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 CB6A912D8CB for ; Wed, 30 Mar 2016 12:07:49 -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.14.9) with ESMTPSA id u2UJ7i7V075272 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 30 Mar 2016 14:07:45 -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: Bernard Aboba , Jonathan Lennox References: From: Adam Roach Message-ID: <56FC2400.2050108@nostrum.com> Date: Wed, 30 Mar 2016 14:07:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000706090304030600070704" Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] WGLC: draft-ietf-avtext-rid-01.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: Wed, 30 Mar 2016 19:07:52 -0000 This is a multi-part message in MIME format. --------------000706090304030600070704 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 3/29/16 11:25, Bernard Aboba wrote: > I have reviewed the document and have the following comment: > > Need for RRID. Currently, draft-ietf-mmusic-rid does not make use of > the RRID. As I understand it, no WebRTC browsers are currently > planning to implement the RRID. Furthermore, neither the WebRTC 1.0 > API nor ORTC supports the RRID. > > Given this, do we really need to include the RRID in this document? > ...and then, on 3/30/16 10:38, Colin Perkins wrote: > The introduction to this draft still says: > >> To address this situation, we define a new RTCP SDES identifier that >> uniquely identifies a single stream. > shortly followed by: > >> when this new >> identifier is in use, it appears (and contains the same value) in >> both in the Redundancy RTP Stream as well as the stream it is >> correcting. > That seems contradictory to me. > > I understand that there’s no consensus to make the RID a unique per-stream identifier, and I’m not asking to revisit that discussion. However, the draft does need to be revised to not claim that the RID uniquely identifies a stream, since it doesn’t in all cases. > I'm finding this a bit perplexing. RRID provides the means to uniquely identify a stream (making the introductory text true). The introductory text motivates the inclusion of RRID, and the presence of RRID satisfies the goal stated in the introduction. It seems to me we can proceed in one of two ways: 1. Strip RRID from the document, thereby eliminating the ability to uniquely identify streams, and remove the consequently erroneous statement from the introduction, or 2. Leave RRID in the document, which makes the cited statement in the introduction actually true -- effectively, leave the current document as-is. I'd be interested in hearing Bernard and Colin's take on this, and even *more* interested in having additional parties weigh in. /a --------------000706090304030600070704 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 3/29/16 11:25, Bernard Aboba wrote:
I have reviewed the document and have the following comment: 

Need for RRID.  Currently, draft-ietf-mmusic-rid does not make use of the RRID.  As I understand it, no WebRTC browsers are currently planning to implement the RRID.  Furthermore, neither the WebRTC 1.0 API nor ORTC supports the RRID.   

Given this, do we really need to include the RRID in this document?  


...and then, on 3/30/16 10:38, Colin Perkins wrote:
The introduction to this draft still says:


   To address this situation, we define a new RTCP SDES identifier that
   uniquely identifies a single stream. 

shortly followed by:


                                                      when this new
   identifier is in use, it appears (and contains the same value) in
   both in the Redundancy RTP Stream as well as the stream it is
   correcting.

That seems contradictory to me. 

I understand that there’s no consensus to make the RID a unique per-stream identifier, and I’m not asking to revisit that discussion. However, the draft does need to be revised to not claim that the RID uniquely identifies a stream, since it doesn’t in all cases.

I'm finding this a bit perplexing. RRID provides the means to uniquely identify a stream (making the introductory text true). The introductory text motivates the inclusion of RRID, and the presence of RRID satisfies the goal stated in the introduction.

It seems to me we can proceed in one of two ways:

  1. Strip RRID from the document, thereby eliminating the ability to uniquely identify streams, and remove the consequently erroneous statement from the introduction, or

  2. Leave RRID in the document, which makes the cited statement in the introduction actually true -- effectively, leave the current document as-is.


I'd be interested in hearing Bernard and Colin's take on this, and even *more* interested in having additional parties weigh in.

/a

--------------000706090304030600070704-- From nobody Wed Mar 30 15:12:56 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 CA72712D0DB for ; Wed, 30 Mar 2016 15:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 oWLAyAfLekuP for ; Wed, 30 Mar 2016 15:12:52 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC1D12D093 for ; Wed, 30 Mar 2016 15:12:52 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id z68so80111998vkg.3 for ; Wed, 30 Mar 2016 15:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p3UNvd+AGDSSmIYFn80rp7pVSdiSAUL7AnAzG/UVcSE=; b=u6bCd0c8zKbiyfTW9kZe8BPuEU5CZvnZgflzmOcC/6uaYLnIBhMNOpFjiKXeI1xTpI G0LIjCTPH9+FcoQBMzzukgh2I244yFWuBe6yM6zk0WaJX/adS2ECNXqmxQkP1l9XysVd npfV9RG3U3unkGdGRu1yVvFV0AQABD1jWiQ+xTMlSXL9jFNcNvHAOrpVhYJgzYEU/DNd cvgGI+kRM+siQXaWeIORw549bsBx4EGLPFq1hRPMyzA086iBFKhfJysTvPpaeEmBnQu2 HNVPNgNt/q+0dUlns4AeG4PVwYyXMzwrzQEUOR9YduqM3synQr+YedC9cEdn0G0ioVtc Ug4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p3UNvd+AGDSSmIYFn80rp7pVSdiSAUL7AnAzG/UVcSE=; b=Hwbx4Bg+zYu8b6O2SxQ6Jse/TquwkYHomq40UDpF+dJgFJBKkkbjP4hakeUUhOdQw5 Y8eIRnt6erRnLm32QJImfklwSo4m3lbjbkh+Unw73Zz61OrWYNdVj67lnt++BtTrZj19 shshno2KtuZh7khL5LacsuKd/12mVHHkCNGMf9aKPGV8aCbDDEQY3PPK0HtuCGQlB+n1 zQAXO8Xs9Bu8M88c/n/cqYOsoBfbCDNXT00hf+leiG0MUvru2LuGRY4OCS80FTA75iOL L+fW35k9bNWxPq2tAFksT1jnY+HkT+3q/L/26zpMdTlMckzMiglLhYk869RwUmD2W5tq X4Tw== X-Gm-Message-State: AD7BkJI/bLZ5mC3FHt8XjZL9MDXMKx2g+uRoW1Jwlfukay12VJhdaIJLTdJWr75+3Dj9fwYhub3gu5o7nRrJlw== X-Received: by 10.31.158.204 with SMTP id h195mr6904839vke.147.1459375971444; Wed, 30 Mar 2016 15:12:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.40 with HTTP; Wed, 30 Mar 2016 15:12:32 -0700 (PDT) In-Reply-To: <56FC2400.2050108@nostrum.com> References: <56FC2400.2050108@nostrum.com> From: Bernard Aboba Date: Wed, 30 Mar 2016 15:12:32 -0700 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=001a1142702c5f2f60052f4b72fc Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] WGLC: draft-ietf-avtext-rid-01.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: Wed, 30 Mar 2016 22:12:55 -0000 --001a1142702c5f2f60052f4b72fc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Adam said: "It seems to me we can proceed in one of two ways: 1. Strip RRID from the document, thereby eliminating the ability to uniquely identify streams, and remove the consequently erroneous stateme= nt from the introduction, or 2. Leave RRID in the document, which makes the cited statement in the introduction actually true -- effectively, leave the current document as= -is. I'd be interested in hearing Bernard and Colin's take on this, and even *more* interested in having additional parties weigh in." [BA] I agree with your assessment of the choices. My only request is that the document actually reflect what implementers intend to support, in the absence of the additional requirements language provided in RFC 6919 which describes the apparent status of the RRID quite well (but alas is only an April 1 RFC): 1 . MUST (BUT WE KNOW YOU W= ON'T) The phrase "MUST (BUT WE KNOW YOU WON'T)" is used to indicate requirements that are needed to meet formal review criteria (e.g., mandatory-to-implement security mechanisms), when these mechanisms are too inconvenient for implementers to actually implement. On Wed, Mar 30, 2016 at 12:07 PM, Adam Roach wrote: > On 3/29/16 11:25, Bernard Aboba wrote: > > I have reviewed the document and have the following comment: > > Need for RRID. Currently, draft-ietf-mmusic-rid does not make use of the > RRID. As I understand it, no WebRTC browsers are currently planning to > implement the RRID. Furthermore, neither the WebRTC 1.0 API nor ORTC > supports the RRID. > > Given this, do we really need to include the RRID in this document? > > > ...and then, on 3/30/16 10:38, Colin Perkins wrote: > > The introduction to this draft still says: > > > To address this situation, we define a new RTCP SDES identifier that > uniquely identifies a single stream. > > shortly followed by: > > > when this new > identifier is in use, it appears (and contains the same value) in > both in the Redundancy RTP Stream as well as the stream it is > correcting. > > That seems contradictory to me. > > I understand that there=E2=80=99s no consensus to make the RID a unique p= er-stream identifier, and I=E2=80=99m not asking to revisit that discussion= . However, the draft does need to be revised to not claim that the RID uniq= uely identifies a stream, since it doesn=E2=80=99t in all cases. > > > > I'm finding this a bit perplexing. RRID provides the means to uniquely > identify a stream (making the introductory text true). The introductory > text motivates the inclusion of RRID, and the presence of RRID satisfies > the goal stated in the introduction. > > It seems to me we can proceed in one of two ways: > > > 1. Strip RRID from the document, thereby eliminating the ability to > uniquely identify streams, and remove the consequently erroneous state= ment > from the introduction, or > > 2. Leave RRID in the document, which makes the cited statement in the > introduction actually true -- effectively, leave the current document = as-is. > > > I'd be interested in hearing Bernard and Colin's take on this, and even > *more* interested in having additional parties weigh in. > > /a > --001a1142702c5f2f60052f4b72fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adam said:=C2=A0

"It seems to me we can proceed in one of two ways:
  1. Strip RRID from the document, thereby eliminating the= ability to uniquely identify streams, and remove the consequently erroneou= s statement from the introduction, or

  2. Leave RRID in the document, which makes the cited statement in the in= troduction actually true -- effectively, leave the current document as-is.<= /li>


I'd be interested in hearing Bernard and Colin's take on = this, and even *more* interested in having additional parties weigh in."

[BA] I agree with your assessment of the= choices.=C2=A0 My only request is that the document actually reflect what = implementers intend to support, in the absence of the =C2=A0additional requ= irements language provided in RFC 6919 which describes the apparent status = of the RRID quite well (but alas is only an April 1 RFC):=C2=A0
<= br>
1.  MUST (BUT WE KNOW YOU WON'T)


   The phrase "MUST (BUT WE KNOW YOU WON'T)" is used to indic=
ate
   requirements that are needed to meet formal review criteria (e.g.,
   mandatory-to-implement security mechanisms), when these mechanisms
   are too inconvenient for implementers to actually implement.
=

On Wed, Mar= 30, 2016 at 12:07 PM, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
On 3/29/16 11:25, Bernard Aboba wrote:
I have reviewed the document and have the following comment:=C2=A0

Need for RRID.=C2=A0 Currently, draft-ietf-mmusic-rid does not make use of the RRID.=C2=A0 As I understand it, no WebRTC browser= s are currently planning to implement the RRID.=C2=A0 Furthermore, neither the WebRTC 1.0 API nor ORTC supports the RRID. =C2=A0=C2= =A0

Given this, do we really need to include the RRID in this document? =C2=A0


 ...and then, on 3/30/16 10:38, Colin Perkins wrote:
The introduction to this draft still says:


   To address this situation, we define a new RTCP SDES identi=
fier that
   uniquely identifies a single stream.=20

shortly followed by:


                                                      when thi=
s new
   identifier is in use, it appears (and contains the same value) in
   both in the Redundancy RTP Stream as well as the stream it is
   correcting.

That seems contradictory to me.=20

I understand that there=E2=80=99s no consensus to make the RID a unique per=
-stream identifier, and I=E2=80=99m not asking to revisit that discussion. =
However, the draft does need to be revised to not claim that the RID unique=
ly identifies a stream, since it doesn=E2=80=99t in all cases.

I'm finding this a bit perplexing. RRID provides the means to uniquely identify a stream (making the introductory text true). The introductory text motivates the inclusion of RRID, and the presence of RRID satisfies the goal stated in the introduction.

It seems to me we can proceed in one of two ways:

  1. Strip RRID from the document, thereby eliminating the ability to uniquely identify streams, and remove the consequently erroneous statement from the introduction, or

  2. Leave RRID in the document, which makes the cited statement in the introduction actually true -- effectively, leave the current document as-is.


I'd be interested in hearing Bernard and Colin's take on this= , and even *more* interested in having additional parties weigh in.

/a


--001a1142702c5f2f60052f4b72fc-- From nobody Wed Mar 30 15:15:14 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 D8B5E12D0BC for ; Wed, 30 Mar 2016 15:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 cEcR2g1WQVKR for ; Wed, 30 Mar 2016 15: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 82A4D12D0AB for ; Wed, 30 Mar 2016 15:15:12 -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.14.9) with ESMTPSA id u2UMFAfm093280 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 30 Mar 2016 17:15:11 -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: Bernard Aboba References: <56FC2400.2050108@nostrum.com> From: Adam Roach Message-ID: <56FC4FEE.9060809@nostrum.com> Date: Wed, 30 Mar 2016 17:15:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] WGLC: draft-ietf-avtext-rid-01.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: Wed, 30 Mar 2016 22:15:14 -0000 On 3/30/16 17:12, Bernard Aboba wrote: > [BA] I agree with your assessment of the choices. My only request is > that the document actually reflect what implementers intend to > support, in the absence of the additional requirements language > provided in RFC 6919 which describes the apparent status of the RRID > quite well (but alas is only an April 1 RFC): Ah, I thought it was clear that support for either or both mechanisms is completely optional and independent of each other. Would it help to add text to that effect? /a From nobody Wed Mar 30 15:30:20 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 BDD4112D0C3 for ; Wed, 30 Mar 2016 15:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 Gtz5BUtARGGF for ; Wed, 30 Mar 2016 15:30:17 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10CB212D101 for ; Wed, 30 Mar 2016 15:30:16 -0700 (PDT) Received: from [81.187.2.149] (port=47850 helo=[192.168.0.86]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1alOcr-0000BD-Sb; Wed, 30 Mar 2016 23:30:10 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <56FC2400.2050108@nostrum.com> Date: Wed, 30 Mar 2016 23:30:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56FC2400.2050108@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] WGLC: draft-ietf-avtext-rid-01.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: Wed, 30 Mar 2016 22:30:19 -0000 > On 30 Mar 2016, at 20:07, Adam Roach wrote: > On 3/29/16 11:25, Bernard Aboba wrote: >> I have reviewed the document and have the following comment:=20 >>=20 >> Need for RRID. Currently, draft-ietf-mmusic-rid does not make use of = the RRID. As I understand it, no WebRTC browsers are currently planning = to implement the RRID. Furthermore, neither the WebRTC 1.0 API nor ORTC = supports the RRID. =20 >>=20 >> Given this, do we really need to include the RRID in this document? =20= >=20 > ...and then, on 3/30/16 10:38, Colin Perkins wrote: >> The introduction to this draft still says: >>=20 >>=20 >>> To address this situation, we define a new RTCP SDES identifier = that >>> uniquely identifies a single stream.=20 >>>=20 >> shortly followed by: >>=20 >>=20 >>> when this new >>> identifier is in use, it appears (and contains the same value) in >>> both in the Redundancy RTP Stream as well as the stream it is >>> correcting. >>>=20 >> That seems contradictory to me.=20 >>=20 >> I understand that there=E2=80=99s no consensus to make the RID a = unique per-stream identifier, and I=E2=80=99m not asking to revisit that = discussion. However, the draft does need to be revised to not claim that = the RID uniquely identifies a stream, since it doesn=E2=80=99t in all = cases. >>=20 >>=20 >=20 > I'm finding this a bit perplexing. RRID provides the means to uniquely = identify a stream (making the introductory text true). The introductory = text motivates the inclusion of RRID, and the presence of RRID satisfies = the goal stated in the introduction. >=20 > It seems to me we can proceed in one of two ways: >=20 > =E2=80=A2 Strip RRID from the document, thereby eliminating the = ability to uniquely identify streams, and remove the consequently = erroneous statement from the introduction, or >=20 > =E2=80=A2 Leave RRID in the document, which makes the cited = statement in the introduction actually true =E2=80=94 effectively, leave = the current document as-is. I read the Introduction as saying *both* that the RID has to be unique = for each stream, *and* that the RID has to have the same value in the = main stream and in the redundant stream. This seems like a = contradiction, irrespective of what you do with the RRID. The fix might = be as simple as changing =E2=80=9CTo address this situation, we define a = new RTCP SDES identifier that uniquely identifies a single stream=E2=80=9D= to =E2=80=9C=E2=80=A6that identifies a stream and any redundant = encoding of that stream=E2=80=9D. > I'd be interested in hearing Bernard and Colin's take on this, and = even *more* interested in having additional parties weigh in. --=20 Colin Perkins https://csperkins.org/ From nobody Thu Mar 31 07:30:51 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 D788F12D180; Thu, 31 Mar 2016 07:30:48 -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 6GEB-1KYfyKZ; Thu, 31 Mar 2016 07:30:45 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AFBE12D156; Thu, 31 Mar 2016 07:30:45 -0700 (PDT) X-AuditID: c1b4fb25-f79f86d00000400a-71-56fd3493e7a6 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 88.43.16394.3943DF65; Thu, 31 Mar 2016 16:30:43 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.248.2; Thu, 31 Mar 2016 16:30:42 +0200 To: , References: From: Magnus Westerlund Message-ID: <56FD3492.8080600@ericsson.com> Date: Thu, 31 Mar 2016 16:30:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM2J7uO5kk79hBo/eylt8vHeD1WLfjods DkweS5b8ZApgjOKySUnNySxLLdK3S+DKeHtyLWPBN+uK5lcXWRoYp+t3MXJySAiYSHza+5cZ whaTuHBvPVsXIxeHkMARRon1O3cwQzjLGSWOLutkAqkSFrCQ+DtnEjuILSJgLjHt+StWEFtI wEbiy+9XYDVsQDU3fzSygdi8AtoSC3rPgNWzCKhKPL+1FqxGVCBG4vi7c4wQNYISJ2c+Yeli 5ODgFLCV+PvbGMRkFrCXeLC1DKSCWUBeonnrbGaITdoSDU0drBMYBWYhaZ6F0DELSccCRuZV jKLFqcVJuelGxnqpRZnJxcX5eXp5qSWbGIGBeHDLb9UdjJffOB5iFOBgVOLhXdDyJ0yINbGs uDL3EKMEB7OSCG+t8d8wId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rysny6HCQmkJ5akZqemFqQW wWSZODilGhh5t5k7HIiW+fLujBzX7gstv9cXsIutfPUqw7uvM8U1O3c/98RryYfNFR5tf5K5 8t5BprzophTPnEXScgx/rU4dPmmxXDJlstrsZn2lPS13tGaeNX713HrWt+SuII9JZw3Ftx4N mK4+Z8GCjslPS/2/als/lb624c47YYWWpXeex66o9fh8o7lFiaU4I9FQi7moOBEAlh7n+kAC AAA= Archived-At: Subject: Re: [avtext] WGLC: draft-ietf-avtext-rid-01.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: Thu, 31 Mar 2016 14:30:49 -0000 Hi, Here are my comments on the draft-ietf-avtext-rid-01. I think it is very good that we have an upcoming meeting where we can discuss the below issues. 1. Abstract: This document defines and registers an RTCP SDES item, RID, for identification of RTP streams associated with Encoded Streams and Dependent Streams. Should this really use plural of RTP streams as well as Encoded Streams. A particular RID value is the identifier for one Encoded or Dependent Stream in its RTP packetized form plus. Thus I think this abstract could be clearer. However, I think it may need to addressed anyway based on comment 3 and 4. 2. Section 1: RTP sessions frequently consist of multiple streams, each of which is identified at any given time by its SSRC; however, the SSRC associated with a stream is not guaranteed to be stable over its lifetime. Within a session, these streams can be tagged with a number of identifiers, including CNAMEs and MSIDs [I-D.ietf-mmusic-msid]. Unfortunately, none of these have the proper ordinality to refer to an individual stream; all such identifiers can appear in more than one stream at a time. While approaches that use unique Payload Types (PTs) per stream have been used in some applications, I think the usage of Stream should at least on the first usage say "RTP Stream" and with a reference to RFC7656 to make it clear what entity you are discussing in this paragraph. 3. Section 3: For Encoded Streams, the RID refers to the "Source RTP Stream" as defined by [RFC7656] Section 2.1.10. For Dependent Streams, it refers to the RTP Stream that, like the Source RTP Stream of an Encoded Stream, is the RTP Stream that is not a Redundancy RTP Stream. For conciseness, we define the term "RID RTP Stream" to refer to this construct. I think this definition is not correct. From my perspective it might be better to talk about the RTP stream produced by the media packetizer from a encoded or set of dependent streams. I write a set of dependent stream as on RTP stream can be produced by packetizing multiple dependent streams in the same. This would occur if one is not producing different RTP streams for all produced scalability layers. However, the main issue is that the definition does not correctly identifies what the RID refers to. To my understanding the RID refers to one RTP stream [A] packetized from either one encoded stream and zero or more dependent streams, or one or more dependent streams and the one or more redundancy streams protecting the RTP stream [A]. This also has the consequence that RID RTP Stream is not a suitable term as the RID identifies an possible aggregate of RTP streams, one source and zero or more redundancy RTP streams. The above changed definition could be used, however I am not certain that it is what we really like to use here. For that purpose see next comment. 4. Section 3: For clarity, when RID is used, Redundancy RTP Streams that can be used to repair Received RTP Streams will use the same RID value as the Received RTP Stream they are intended to be combined with. If applications want to identify individual redundancy streams, they can add an RRID to them instead of or in addition to the RID. So the intention with RRID, is to identify Redundancy RTP streams. Considering that RID doesn't actually only represent the source RTP stream for the media, there is a mismatch. Also, the needs for RRID is also not clear, however, the basics of identifying the RTP stream only has the advantage of high likelihood of re-use in other mechanisms. However, I would like to take a collected consideration of the RID and RRID definitions and actually propose that we change the RID definition. To be clear on that this is another definition this new identifier I will refer to as RTP Stream IDentifier (SID). The definition of SID would be: "An identifier for a single RTP stream." This of course have implication on the RID mechanism expressing the payload format constraints. However, I think it fulfil the basic needs very nicely. The a=rid lines points at a SID for which is the RTP stream for which the set of constraints apply. This is the basic part of the RID proposal. And this removes the need for RRID, as also Redundancy RTP streams can have a SID, if needed by the application. We get a generic basic identification that is likely to be re-usable while solving the current needs. Some may protest, hey but we are loosing the coupling method between the source RTP stream and the Redundancy stream. Yes, I have a proposal below for how to resolve that, but at the same time, it is this coupling that creates the complicated definition of the RID SDES item. And this is actually quite a separate problem. One which has existed for some time, and may actually benefit from being taken on a separate work item. Especially as we may want to retrofit the outcome onto some existing mechanisms such as RTP Retransmission and Generic XOR FEC to enable single RTP session usage efficiently for both. So below is a possible solution if one desire to have a way of coupling the redundancy stream to the source RTP stream already in signalling and identifying it with the same properties as we get with RID for the Source RTP streams. The solution is simple, we simply have a=RID lines also for the Redundancy RTP streams. Then we define a new constraint which I will call "protect" which is a list of SIDs that points at one or more RTP streams for which this Redundancy RTP Stream is constrained to protect and provide redundancy for. An basic SDP example for this would be the following: m=video 10000 RTP/SAVPF 100 101 108 109 a=rtpmap:100 H264/90000 a=fmtp:100 profile-level-id=42401f; packetization-mode=0 a=rtpmap:101 H264/90000 a=fmtp:101 profile-level-id=42401f; packetization-mode=1 a=rtpmap:108 rtx/90000 a=fmtp:108 apt=100 a=rtpmap:109 rtx/90000 a=fmtp:109 apt=101 a=sendrecv a=mid:v1 (max resolution) a=rid:1 send max-width=1280;max-height=720;max-fps=30 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 a=rid:A send pt=108,109;protect=1 a=rid:B recv pt=108,109;protect=2 So at RTP session startup when the offerer of the above starts sending it will send two RTP streams from the above block. One for the video using SID=1 and another for the RTX packets using SID=A. 5. Section 4 and 6. What I am missing in this is a discussion of privacy and the potential for tracking the streams across an RTP system. This is usually fine, but may reveal things to a third party, thus their value should be protected towards third parties. The next part of this issue is the generation of these values should avoid leaking any information about the user and implementation. This leads to the question if the values should be using random values, with tag lengths as needed by the application. 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 ----------------------------------------------------------------------