From nobody Wed Jun 1 03:21: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 7AD6512D0F0 for ; Wed, 1 Jun 2016 03:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 n01Fo56OwxL5 for ; Wed, 1 Jun 2016 03:21:48 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B8A812D098 for ; Wed, 1 Jun 2016 03:21:48 -0700 (PDT) Received: from [130.209.254.10] (port=53175 helo=vpn10.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1b83HW-0006yA-Hr; Wed, 01 Jun 2016 11:21:46 +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: <3186E797-0143-4A35-B693-CF719778B986@vidyo.com> Date: Wed, 1 Jun 2016 11:21:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4074AF67-B840-481B-A0CD-82109A26F397@csperkins.org> References: <3186E797-0143-4A35-B693-CF719778B986@vidyo.com> 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] 2nd WGLC: draft-ietf-avtext-rid-02 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, 01 Jun 2016 10:21:50 -0000 > On 16 May 2016, at 16:46, Jonathan Lennox wrote: >=20 > Following the document=E2=80=99s changes after the Buenos Aires = discussion, this is to announce a second, 2 week Working Group Last Call = for >=20 > draft-ietf-avtext-rid-02 >=20 > as proposed standard. >=20 > Please review and provide any comments you may have on the document by = Monday, May 30th. Comments should be sent to the document authors and = the AVTEXT WG list. >=20 > If you review the document but do not have any comments, please send a = note to that effect as well. I reviewed the draft when it was announced, and as I said, have no = objection to it progressing. --=20 Colin Perkins https://csperkins.org/ From nobody Wed Jun 8 14:16:26 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 08C1112D7E4 for ; Wed, 8 Jun 2016 14:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3I_eevPS5eps for ; Wed, 8 Jun 2016 14:16:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F089D12D736 for ; Wed, 8 Jun 2016 14:16:23 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u58LGMpi004712 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 8 Jun 2016 16:16:22 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Stephen Farrell" , "Magnus Westerlund" Date: Wed, 08 Jun 2016 16:16:22 -0500 Message-ID: <24185FDB-9BB5-4161-84F3-2AB3E8542094@nostrum.com> In-Reply-To: <5739CF49.4080007@cs.tcd.ie> References: <20160503152115.8264.83977.idtracker@ietfa.amsl.com> <5730A70B.5050300@ericsson.com> <5739CF49.4080007@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: avtext-chairs@ietf.org, Jonathan Lennox , avtext@ietf.org, The IESG , draft-ietf-avtext-sdes-hdr-ext@ietf.org Subject: Re: [avtext] Stephen Farrell's Discuss on draft-ietf-avtext-sdes-hdr-ext-06: (with DISCUSS and COMMENT) 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, 08 Jun 2016 21:16:26 -0000 Hi, Where did we end up with this? Magnus, any thoughts on Stephen's last mail? Thanks! Ben. On 16 May 2016, at 8:46, Stephen Farrell wrote: > Hiya, > > Sorry for the slow response, was travelling... > > On 09/05/16 16:04, Magnus Westerlund wrote: >> Hi Stephen, >> >> Please see inline. >> >> Den 2016-05-03 kl. 17:21, skrev Stephen Farrell: >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-avtext-sdes-hdr-ext-06: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> >>> I'd like to check if there's a small hole in the >>> security/privacy properties here. If there is I hope that >>> a little re-wording will handle it. >>> >>> You say: (1) "In RTP sessions where any type of >>> confidentiality protection is enabled for RTCP, the SDES >>> item header extensions MUST also be protected." And then >>> you say: (2) "The security level that is applied to RTCP >>> packets carrying SDES items SHOULD also be applied to >>> SDES items carried as RTP header extensions." >>> >>> My concerns are that the SHOULD in (2) isn't really well >>> motivated (for me) - you just seem to say that someone >>> who doesn't follow the SHOULD has to say why, but I don't >>> think that's likely a run-time concept. >> >> So there are two aspects of this. The first is that protection really >> should be applied on matching level, if there are exceptions to this, >> then this is not a run-time decision for it. The run-time property here >> that makes this a bit more complicated, is that we have a much more >> limited set of algorithms for RTP header extension confidentiality >> protection, than we have for RTP and RTCP packets in general. Thus, >> there are a risk that there is not possible to find a matching security >> level. And we fairly often can end up in situations where the same >> security level is not available. However, this later case is handled by >> the general formulation of "security level" which gives some leeway for >> not having the same algorithms. > > Ok, if this is down to crypto algorithms or modes of operation of > crypto algorithms, then would something like "MUST use commensurate > strength algorithms and SHOULD use the same cryptographic > primitives (algorithms, modes)" work? > >> >> >> Secondly, (1) >>> doesn't say that the new stuff has to be protected in the >>> same way, e.g. with the same endpoints having the keys, >>> and not e.g. where the RTCP data has e2e protection but >>> the new header field just has hop-by-hop protection. >> >> No, and for basic SRTP and existing specifications we only have >> mechanisms dealing with protection to the next RTP hop, that are >> trusted. > > I think that'd be worth explaining a bit in the document, > as it wasn't at all clear to me. Would it be clear to folks > who know loads about RTP/RTCP but less about security? If > not, then I'd say explaining it would be good. > > The distinctions you are getting into become relevant in the >> PERC context, where it might not exist matching capabilities between >> hop-by-hop and end-to-end. If I correctly remember where the WGs >> discussion has ended up, we will be able to protected the SDES data >> end-to-end in the RTP header extension, but not in RTCP. >> >> I will note that the CNAME SDES item, when correctly generated is not >> privacy sensitive and also needed in the intermediate node to know which >> RTP streams that share synchronization context. >> >> I will also note that in my view having the same security level will >> mean that you will have to provide the same treatment in a PERC context >> in respect to end-to-end vs hop-by-hop. >> >>> >>> Are my concerns justified? (If not, that's fine you'll >>> tell me and we're done:-) >> >> Yes, I think they are justified. >> >>> >>> If these are justified concerns, I think we can easily >>> get around them by (a) closing that potential loophole in >>> (1) and (b) s/SHOULD/MUST/ in (2) or else (c) better >>> specify an exception to the SHOULD that makes sense at >>> coding time or at run time. >> >> I am fine with changing this to a MUST. I note that this might require a >> bit of an upgrade of the header extension protection mechanism to fulfil >> the MUST, but I don't see the lack of algorithm a valid exception to the >> SHOULD either. > > See if the text suggestion above works. > > Cheers, > S. > > PS: Your responses to the comments below are just fine too. > >> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> - So this one confused me for a bit but I was thinking >>> about RFC4568 - shame about that acronym collision;-) >>> It'd have helped this reader to say that this is not >>> about sending keys in header fields:-) But I'm probably >>> not the intended reader, so it's fine that you didn't. >> >> I agree that the collision is confusing, but I think we are fairly clear >> in the first sentences in the Introduction and abstract: >> >> This specification defines an RTP header extension [RFC3550][RFC5285] >> that can carry RTCP source description (SDES) items. Normally the >> SDES items are carried in their own RTCP packet type [RFC3550]. >> >> I intended to ignore this comment. >> >>> >>> - I wonder if confidentiality protection of these header >>> fields is likely? Is that more or less likely to be >>> deployed than some security for RTCP? If there's a >>> significant difference then I think that ought be called >>> out. Just pointing at rfc6904 doesn't seem entirely >>> sufficient to me if nobody ever does it. >> >> I don't really know about the implementation status for RFC6904. I found >> that Google just a couple of days ago committed to chronium a patch for >> RFC6904 support. >> >>> >>> - Has someone done an analysis of the privacy >>> implications of moving values from one context (RTCP) to >>> another (RTP) over the range of likely deployments? Note: >>> I'm not asserting that there is a significant privacy >>> exposure here, I don't know if there is or not. So I'm >>> just asking if folks have thought about that and e.g. >>> whether or not some data exposed in this header field >>> could allow easier re-identification or correlation or >>> some similar and possibly subtle privacy issue. >> >> So RTP/RTCP really is one protocol. >> >> However, I don't think there has been any deeper analytics of this. What >> I believe this can reveal to a party watching the packet fly by, is >> identifying the RTP/RTCP implementation. >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> From nobody Fri Jun 10 02:49: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 37C6212D159; Fri, 10 Jun 2016 02:48:59 -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 QCNKterpMIUo; Fri, 10 Jun 2016 02:48:57 -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 2672012D572; Fri, 10 Jun 2016 02:48:55 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-5b-575a8d05b3aa Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8B.39.12926.50D8A575; Fri, 10 Jun 2016 11:48:53 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.294.0; Fri, 10 Jun 2016 11:48:52 +0200 To: Ben Campbell , Stephen Farrell References: <20160503152115.8264.83977.idtracker@ietfa.amsl.com> <5730A70B.5050300@ericsson.com> <5739CF49.4080007@cs.tcd.ie> <24185FDB-9BB5-4161-84F3-2AB3E8542094@nostrum.com> From: Magnus Westerlund Message-ID: <6dcd6d2b-8b37-c447-adac-8921f84b87a9@ericsson.com> Date: Fri, 10 Jun 2016 11:48:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <24185FDB-9BB5-4161-84F3-2AB3E8542094@nostrum.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM2K7ty5rb1S4wZ8mRYv2cydYLD7eu8Fq Mb/zNLvF7TWf2Cxm/JnIbLF/8Xlmi+l7r7E7sHus7b7K5rFkyU8mj1k7n7B4tD27wx7AEsVl k5Kak1mWWqRvl8CVcWTZMraC+y4VF65fZGtgvGzexcjJISFgIvHx2H8WCFtM4sK99WxdjFwc QgJHGCWmHWtihnCWM0qs2r8fyOHgEBbIlDh3TAHEFBEIlFg5pxyiZAujxPY5/1lBHGaBeYwS f3sPsoJMZROwkLj5o5ENxOYVsJdobH3PCGKzCKhKPJ6zgB3EFhWIkWi8fZgdokZQ4uTMJ2AX cQLVL7r5lgnEZgaaM3P+eUYIW16ieetsZhBbSEBboqGpg3UCo+AsJO2zkLTMQtKygJF5FaNo cWpxUm66kbFealFmcnFxfp5eXmrJJkZg2B/c8lt1B+PlN46HGAU4GJV4eB88iwwXYk0sK67M PcQowcGsJML7uCMqXIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv/0vFcCGB9MSS1OzU1ILUIpgs EwenVANj8fqUYhUmeQZT8aWuT18bPU5l2Mq2Mu3Az3V7ekpnvEgpE7I52e/17E7Ej5khv6T/ fA5jmqHSF7oVGNpxOqHZzLsPG68WLl/TWa1QKfPMmKdG9+Oep9qGZ94cOxQtJbbpebxNlYDf HFcLvy3Pu6+YCM5X6dp/7mlkupe5YuCOzrU8e++5FyixFGckGmoxFxUnAgAmxrzRdwIAAA== Archived-At: Cc: avtext-chairs@ietf.org, Jonathan Lennox , avtext@ietf.org, The IESG , draft-ietf-avtext-sdes-hdr-ext@ietf.org Subject: Re: [avtext] Stephen Farrell's Discuss on draft-ietf-avtext-sdes-hdr-ext-06: (with DISCUSS and COMMENT) 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, 10 Jun 2016 09:48:59 -0000 Den 2016-06-08 kl. 23:16, skrev Ben Campbell: > Hi, > > Where did we end up with this? Magnus, any thoughts on Stephen's last mail? Yes, Stephen's suggestion works for us. We are submitting a new version now. Please check that these do resolve the issue. Cheers Magnus > > Thanks! > > Ben. > > > On 16 May 2016, at 8:46, Stephen Farrell wrote: > >> Hiya, >> >> Sorry for the slow response, was travelling... >> >> On 09/05/16 16:04, Magnus Westerlund wrote: >>> Hi Stephen, >>> >>> Please see inline. >>> >>> Den 2016-05-03 kl. 17:21, skrev Stephen Farrell: >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-avtext-sdes-hdr-ext-06: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> I'd like to check if there's a small hole in the >>>> security/privacy properties here. If there is I hope that >>>> a little re-wording will handle it. >>>> >>>> You say: (1) "In RTP sessions where any type of >>>> confidentiality protection is enabled for RTCP, the SDES >>>> item header extensions MUST also be protected." And then >>>> you say: (2) "The security level that is applied to RTCP >>>> packets carrying SDES items SHOULD also be applied to >>>> SDES items carried as RTP header extensions." >>>> >>>> My concerns are that the SHOULD in (2) isn't really well >>>> motivated (for me) - you just seem to say that someone >>>> who doesn't follow the SHOULD has to say why, but I don't >>>> think that's likely a run-time concept. >>> >>> So there are two aspects of this. The first is that protection really >>> should be applied on matching level, if there are exceptions to this, >>> then this is not a run-time decision for it. The run-time property here >>> that makes this a bit more complicated, is that we have a much more >>> limited set of algorithms for RTP header extension confidentiality >>> protection, than we have for RTP and RTCP packets in general. Thus, >>> there are a risk that there is not possible to find a matching security >>> level. And we fairly often can end up in situations where the same >>> security level is not available. However, this later case is handled by >>> the general formulation of "security level" which gives some leeway for >>> not having the same algorithms. >> >> Ok, if this is down to crypto algorithms or modes of operation of >> crypto algorithms, then would something like "MUST use commensurate >> strength algorithms and SHOULD use the same cryptographic >> primitives (algorithms, modes)" work? >> >>> >>> >>> Secondly, (1) >>>> doesn't say that the new stuff has to be protected in the >>>> same way, e.g. with the same endpoints having the keys, >>>> and not e.g. where the RTCP data has e2e protection but >>>> the new header field just has hop-by-hop protection. >>> >>> No, and for basic SRTP and existing specifications we only have >>> mechanisms dealing with protection to the next RTP hop, that are >>> trusted. >> >> I think that'd be worth explaining a bit in the document, >> as it wasn't at all clear to me. Would it be clear to folks >> who know loads about RTP/RTCP but less about security? If >> not, then I'd say explaining it would be good. >> >> The distinctions you are getting into become relevant in the >>> PERC context, where it might not exist matching capabilities between >>> hop-by-hop and end-to-end. If I correctly remember where the WGs >>> discussion has ended up, we will be able to protected the SDES data >>> end-to-end in the RTP header extension, but not in RTCP. >>> >>> I will note that the CNAME SDES item, when correctly generated is not >>> privacy sensitive and also needed in the intermediate node to know which >>> RTP streams that share synchronization context. >>> >>> I will also note that in my view having the same security level will >>> mean that you will have to provide the same treatment in a PERC context >>> in respect to end-to-end vs hop-by-hop. >>> >>>> >>>> Are my concerns justified? (If not, that's fine you'll >>>> tell me and we're done:-) >>> >>> Yes, I think they are justified. >>> >>>> >>>> If these are justified concerns, I think we can easily >>>> get around them by (a) closing that potential loophole in >>>> (1) and (b) s/SHOULD/MUST/ in (2) or else (c) better >>>> specify an exception to the SHOULD that makes sense at >>>> coding time or at run time. >>> >>> I am fine with changing this to a MUST. I note that this might require a >>> bit of an upgrade of the header extension protection mechanism to fulfil >>> the MUST, but I don't see the lack of algorithm a valid exception to the >>> SHOULD either. >> >> See if the text suggestion above works. >> >> Cheers, >> S. >> >> PS: Your responses to the comments below are just fine too. >> >>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> - So this one confused me for a bit but I was thinking >>>> about RFC4568 - shame about that acronym collision;-) >>>> It'd have helped this reader to say that this is not >>>> about sending keys in header fields:-) But I'm probably >>>> not the intended reader, so it's fine that you didn't. >>> >>> I agree that the collision is confusing, but I think we are fairly clear >>> in the first sentences in the Introduction and abstract: >>> >>> This specification defines an RTP header extension [RFC3550][RFC5285] >>> that can carry RTCP source description (SDES) items. Normally the >>> SDES items are carried in their own RTCP packet type [RFC3550]. >>> >>> I intended to ignore this comment. >>> >>>> >>>> - I wonder if confidentiality protection of these header >>>> fields is likely? Is that more or less likely to be >>>> deployed than some security for RTCP? If there's a >>>> significant difference then I think that ought be called >>>> out. Just pointing at rfc6904 doesn't seem entirely >>>> sufficient to me if nobody ever does it. >>> >>> I don't really know about the implementation status for RFC6904. I found >>> that Google just a couple of days ago committed to chronium a patch for >>> RFC6904 support. >>> >>>> >>>> - Has someone done an analysis of the privacy >>>> implications of moving values from one context (RTCP) to >>>> another (RTP) over the range of likely deployments? Note: >>>> I'm not asserting that there is a significant privacy >>>> exposure here, I don't know if there is or not. So I'm >>>> just asking if folks have thought about that and e.g. >>>> whether or not some data exposed in this header field >>>> could allow easier re-identification or correlation or >>>> some similar and possibly subtle privacy issue. >>> >>> So RTP/RTCP really is one protocol. >>> >>> However, I don't think there has been any deeper analytics of this. What >>> I believe this can reveal to a party watching the packet fly by, is >>> identifying the RTP/RTCP implementation. >>> >>> 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 >>> ---------------------------------------------------------------------- >>> > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Jun 10 02:49: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 B6E2B12D0DF; Fri, 10 Jun 2016 02:49:48 -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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160610094948.15416.15649.idtracker@ietfa.amsl.com> Date: Fri, 10 Jun 2016 02:49:48 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-07.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 09:49:48 -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-07.txt Pages : 16 Date : 2016-06-10 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 need 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-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-sdes-hdr-ext-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 10 03:27:42 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 502EE12D7C2; Fri, 10 Jun 2016 03:27:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160610102734.15503.56339.idtracker@ietfa.amsl.com> Date: Fri, 10 Jun 2016 03:27:34 -0700 Archived-At: Cc: jonathan@vidyo.com, avtext@ietf.org, draft-ietf-avtext-sdes-hdr-ext@ietf.org, avtext-chairs@ietf.org Subject: [avtext] Stephen Farrell's No Objection on draft-ietf-avtext-sdes-hdr-ext-07: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 10:27:35 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-avtext-sdes-hdr-ext-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for handling my DISCUSS point. --- OLD COMMENTS below, I didn't check 'em - So this one confused me for a bit but I was thinking about RFC4568 - shame about that acronym collision;-) It'd have helped this reader to say that this is not about sending keys in header fields:-) But I'm probably not the intended reader, so it's fine that you didn't. - I wonder if confidentiality protection of these header fields is likely? Is that more or less likely to be deployed than some security for RTCP? If there's a significant difference then I think that ought be called out. Just pointing at rfc6904 doesn't seem entirely sufficient to me if nobody ever does it. - Has someone done an analysis of the privacy implications of moving values from one context (RTCP) to another (RTP) over the range of likely deployments? Note: I'm not asserting that there is a significant privacy exposure here, I don't know if there is or not. So I'm just asking if folks have thought about that and e.g. whether or not some data exposed in this header field could allow easier re-identification or correlation or some similar and possibly subtle privacy issue. From nobody Fri Jun 10 13:11:43 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 100EC128B44 for ; Fri, 10 Jun 2016 13:11:42 -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 MVgVqvu8PoP3 for ; Fri, 10 Jun 2016 13:11:40 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D40612D8FB for ; Fri, 10 Jun 2016 13:11:40 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id d64so111877712vkb.0 for ; Fri, 10 Jun 2016 13:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=/QYNJQEtVa3DYuKnJO3dlOK0v+tK1XnRz3W3E1N/KF4=; b=H0EAs9Nta5s6X4NOkHsW4eJa9jN2Y3BBzGae9nW6bLB8XODNGz3CRLNpD621xPj7qE JiLVQOvBgmW7u6UdMdL1P294ni6YGCkRiQ2hsENYBXfpU4ozjhxVxYuglvdQF5LdH+5s ugEk7LNbKzvgo6djhEYY0vdkQiy0tmCeY9HtDU5QnWf6LSDb0PVOG3AFFmoZeON82vrt 1fxhDnrFTXed4NfIrOTsUS26ibPDgiYF2ZeFtsZjEQssrEYzT40M+bFU0EpCygKHkx66 DstQBt6/Ey4ZDWqPzxEcWuRWKny1hf2WFH2S123BrQLOKOz6hbA9wG5NZ8Fi5njo/Nzm HHdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/QYNJQEtVa3DYuKnJO3dlOK0v+tK1XnRz3W3E1N/KF4=; b=IB46G1t8Z51glgBl/R+8e+n8fpdWsjGGY84lA2q7o6pYUqLKeMa78/OQmuVXHebdCO PPEN1mFdT3KUQnhiDy/mMSO18JqO7iRBU6CQCK/1R/I5hKmbbJzJgy2yhXuN4kjDfVct 5zzup2KzF8toDqzQtJSvsefWNFTa3yY6i/PBLj9onbzhZ5Q8mPuGK49ZvqfAyT4wZX4J YSXrgIe7qFQf5MLV9MG7GmZQUIXPK3oV1w2ze2mZIp9OWCfvmhP0W9gGOyPLHyMAppxJ 9UhMUFkymVk8JpfjCat+HFM0geU977eg/0O9JyeTVoA2bX7j1rJo6c9Ok9z7j2+/VTz1 rq4A== X-Gm-Message-State: ALyK8tIRNB6w6yUsMhUxCg705s4ro45+apfXBLv3N8ExN+g2wf5KHeNiJodnZiSplGf5FezJLfzE/eKwRuQz3g== X-Received: by 10.31.7.200 with SMTP id 191mr98323vkh.74.1465589499468; Fri, 10 Jun 2016 13:11:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.40 with HTTP; Fri, 10 Jun 2016 13:11:20 -0700 (PDT) From: Bernard Aboba Date: Fri, 10 Jun 2016 13:11:20 -0700 Message-ID: To: avtext@ietf.org Content-Type: multipart/alternative; boundary=001a1143d31880a3ac0534f22506 Archived-At: Subject: Re: [avtext] 2nd WGLC: draft-ietf-avtext-rid-02 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, 10 Jun 2016 20:11:42 -0000 --001a1143d31880a3ac0534f22506 Content-Type: text/plain; charset=UTF-8 I have one comment. " To address this situation, we define a new RTCP SDES identifier, RtpStreamId, that uniquely identifies a single RTP stream. A key motivator for defining this identifier is the ability to differentiate among different encodings of a single Source Stream that are sent simultaneously (i.e., simulcast). This need for unique identification extends to dependent streams (i.e., layers used by a layered codec)" [BA] Where the layers of a layered codec are transmitted within the same RTP stream (SRST transport), each of the layers would utilize the same RtpStreamId. So presumably the need for unique identification is met only where MRST transport is used. So should the last sentence say: "where layers used by a layered codec are transmitted on separate streams" ? --001a1143d31880a3ac0534f22506 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have one comment.=C2= =A0

" To address this situation, we define a new RTCP SDES i= dentifier,
   RtpStreamId, that uniquely identifies a single RTP stream.  A key
   motivator for defining this identifier is the ability to
   differentiate among different encodings of a single Source Stream
   that are sent simultaneously (i.e., simulcast).  This need for unique
   identification extends to dependent streams (i.e., layers used by a
   layered codec)"

[BA] Where the layers =
of a layered codec are transmitt=
ed within the same RTP stream=C2=A0(SRST transport), each of the lay=
ers would utilize the same RtpStreamId. 
=
So pres=
umably the need for unique identification is met only where MRST transport =
is used.

So should the last sentence say:  "where layers used by a layered codec are transmitted on <=
/span>separate streams" ?
--001a1143d31880a3ac0534f22506-- From nobody Mon Jun 13 05:55:31 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 28EAB12B036; Mon, 13 Jun 2016 05:55:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160613125529.12490.86798.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2016 05:55:29 -0700 Archived-At: Cc: draft-ietf-avtext-splicing-notification@ietf.org, avtext@ietf.org, jonathan@vidyo.com, avtext-chairs@ietf.org Subject: [avtext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-avtext-splicing-notification-07=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= 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, 13 Jun 2016 12:55:29 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-avtext-splicing-notification-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a few points which I would like to have answers for before moving the doc forward (which may not even results in text changes). I happy to clear my position when answered before the telechat: - The following action does not seem to be appropriate for a specification of an end-to-end protocol: "And if the splicer wishes to prevent the downstream receivers from detecting splicing, it MUST NOT forward the message." I guess if a middlebox decides to drop the message, there is not much we can do. But I definitely would prefer to not see this specified in an RFC. - Why is just having the RTCP message not sufficient? Why are the RTP extensions needed as well? - And is the RTCP message send only once or multiple time? This is not specified. - There is some discussion about the implementation of the slicer in section 5 (where btw. the title "Failure Cases" seems inappropriate), while there is one sentence saying: "If the splicer is implemented following [RFC6828], it will have its own SSRC and will send its own RTCP reports, and will forward translated RTCP reports from the receivers." Why are alternatives discussed here, if there is already a recommendation given in RFC6828? And how would proper congestion handling be ensure in the other setups not described in RFC6828? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - As a general comment, I found it quite hard to read this doc without reading RFC6828 which is only listed as a informative reference as it is informational only. I think it is wrong. Further, RFC6828 describes some action that a slicers has to perform. However, all language in RFC6828 is non normative. This is slightly confusing to me as well. I would further recommend to briefly give an overview of the assumed scenario is this document. - Minor comment: The definition of the new SDP grouping semantic should be mentioned in the abstract and RFC4566 should be referenced. And I don't think the SDP grouping registry requires a contact. - Quick question: Maybe I'm missing something here but why do you need a splicer in a scenario where "the substitutive sender is implemented together with the main RTP sender inside a single device" (as written in section 2)? From nobody Tue Jun 14 03:10: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 E3B3712D1A7; Tue, 14 Jun 2016 03:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 wW4Ucf4Fc-8x; Tue, 14 Jun 2016 03:10:32 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 0AA3112D1A1; Tue, 14 Jun 2016 03:10:29 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id m124so115496394wme.1; Tue, 14 Jun 2016 03:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=T9Z3cOHF114Rkgmvwi3PbZlqt6b6klNFLKNjZi43dJ0=; b=neQvMdaIZ8R+1eQt77M8pG1HlB2x01SXVprinvl/aOYD4T7kiRJOZPEtzT/7Ob5FkQ 54wrbMRi1Ny4BseOd8ZWf4/HXXo+7DyQ3OHq4Sz8h7wHHnLbDRvhqLORqsumbRPU7cBs ANjbT+50BflLMomyp/Ld9PkL/y7XnR6bu/hA88oYHF1N8yBXQnuOf172G/U1Z+v83yhH sR2UjUfAa+iFoAd42YakIS9CRsuk4u/X8ibkRT3PGSmaRqtkb1z7/TuN0G4hUAlV2c7l tAYkIufekkQFvP17no+77J2aSYymuROB8x0ufRFSnjVaU9zBS/ywTGU1i6w3pvx+9w/f 4tMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=T9Z3cOHF114Rkgmvwi3PbZlqt6b6klNFLKNjZi43dJ0=; b=S+5CMhoh5/kVvOhbnBjiqY20AAQfTjJxE32xBB9eW0IH1b8mFIUixtJk1oQmvsUqfU +gfPZ3xuekKu6lpKKOlQtHonhR9UaBAiCVJMkk6EP0q+7MobxjWQphReoQaLkBKi9gfq FQUogRed3P22C7anro07Aflussm08txVcnfCsXBAnhOX367LYHJv9kyQXaZbDeFx2MPm wt0Qef9KydbDQFtMb2S+AkD0Y2M2NBwEAsZ9qHyNanO1NpclZQ6W0PBd/H8GTWh57gpX bbXnO4wMu3eO/XIg0fUCYqDV6cPW8cXCPsoIr3yb9MycDb8gMyBiC9iI6v24qeWBjsk7 x1tw== X-Gm-Message-State: ALyK8tLs5RbMc6JEKAcRJKBjjmBx2jpycTVcsABhH7VsYNmJUiSHQhfJLnqVDVq8aZJHJg== X-Received: by 10.194.221.37 with SMTP id qb5mr5169067wjc.171.1465899027393; Tue, 14 Jun 2016 03:10:27 -0700 (PDT) Received: from RoniPC (bzq-79-179-194-235.red.bezeqint.net. [79.179.194.235]) by smtp.gmail.com with ESMTPSA id z1sm28716371wju.32.2016.06.14.03.10.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Jun 2016 03:10:25 -0700 (PDT) From: "Roni Even" To: "'Mirja Kuehlewind'" , "'The IESG'" References: <20160613125529.12490.86798.idtracker@ietfa.amsl.com> In-Reply-To: <20160613125529.12490.86798.idtracker@ietfa.amsl.com> Date: Tue, 14 Jun 2016 13:09:05 +0300 Message-ID: <0da801d1c624$c95ea380$5c1bea80$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJldgWrVetIR8KROcYJrObkyk7d8J7BWkUQ Content-Language: he Archived-At: Cc: draft-ietf-avtext-splicing-notification@ietf.org, avtext@ietf.org, jonathan@vidyo.com, avtext-chairs@ietf.org Subject: Re: [avtext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-avtext-splicing-notification-07=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= 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, 14 Jun 2016 10:10:39 -0000 Hi Inline Roni > -----Original Message----- > From: Mirja Kuehlewind [mailto:ietf@kuehlewind.net] > Sent: Monday, June 13, 2016 3:55 PM > To: The IESG > Cc: draft-ietf-avtext-splicing-notification@ietf.org; = avtext-chairs@ietf.org; > jonathan@vidyo.com; avtext@ietf.org > Subject: Mirja K=C3=BChlewind's Discuss on = draft-ietf-avtext-splicing-notification- > 07: (with DISCUSS and COMMENT) >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-avtext-splicing-notification-07: Discuss >=20 > When responding, please keep the subject line intact and reply to all = email > addresses included in the To and CC lines. (Feel free to cut this = introductory > paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/= >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I have a few points which I would like to have answers for before = moving the > doc forward (which may not even results in text changes). I happy to = clear > my position when answered before the telechat: >=20 > - The following action does not seem to be appropriate for a = specification of > an end-to-end protocol: > "And if the splicer wishes to prevent the downstream receivers from > detecting splicing, it MUST > NOT forward the message." > I guess if a middlebox decides to drop the message, there is not much = we can > do. But I definitely would prefer to not see this specified in an RFC. [Roni Even] This is a requirement, the spliced information may be a = commercial and the splicer may want to prevent the end user from = identifying easily that he is now receiving a commercial=20 >=20 > - Why is just having the RTCP message not sufficient? Why are the RTP > extensions needed as well? [Roni Even] RTP and RTCP are unreliable protocols, so if you want higher = probability for getting the information you send both (this is done is = other similar usages) >=20 > - And is the RTCP message send only once or multiple time? This is not > specified. [Roni Even] This is implementation, once. >=20 > - There is some discussion about the implementation of the slicer in = section 5 > (where btw. the title "Failure Cases" seems inappropriate), while = there is one > sentence saying: "If the splicer is implemented following [RFC6828], = it will > have its > own SSRC and will send its own RTCP reports, and will forward > translated RTCP reports from the receivers." > Why are alternatives discussed here, if there is already a = recommendation > given in RFC6828? [Roni Even] Since these are message definition, RFC6828 is one option = but people may use other models And how would proper congestion handling be ensure in > the other setups not described in RFC6828? [Roni Even] This is regular RTP so congestion is as in RTP >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > - As a general comment, I found it quite hard to read this doc without > reading RFC6828 which is only listed as a informative reference as it = is > informational only. I think it is wrong. Further, RFC6828 describes = some > action that a slicers has to perform. However, all language in RFC6828 = is non > normative. This is slightly confusing to me as well. I would further > recommend to briefly give an overview of the assumed scenario is this > document. [Roni Even] RFC6828 is an implementation example >=20 > - Minor comment: The definition of the new SDP grouping semantic = should > be mentioned in the abstract and RFC4566 should be referenced. And I = don't > think the SDP grouping registry requires a contact. [Roni Even] Grouping is in RFC5888 and not in RFC4566 (RFC5888 = references RFC4566) You are right - contact is not needed according to RFC5888 >=20 > - Quick question: Maybe I'm missing something here but why do you need = a > splicer in a scenario where "the > substitutive sender is implemented together with the main RTP = sender > inside a single device" (as written in section 2)? From nobody Tue Jun 14 04:19:57 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3475112D591; Tue, 14 Jun 2016 04:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 0mgQniqTnoMt; Tue, 14 Jun 2016 04:19:48 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [46.235.227.24]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F2212D58C; Tue, 14 Jun 2016 04:19:48 -0700 (PDT) Received: from [130.209.247.112] (port=51322 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bCmNk-0008NG-85; Tue, 14 Jun 2016 12:19:45 +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: <20160613125529.12490.86798.idtracker@ietfa.amsl.com> Date: Tue, 14 Jun 2016 12:19:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <65EAADDF-EE7F-414B-AF3F-45BA4B729500@csperkins.org> References: <20160613125529.12490.86798.idtracker@ietfa.amsl.com> To: Mirja Kuehlewind X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: avtext-chairs@ietf.org, draft-ietf-avtext-splicing-notification@ietf.org, avtext@ietf.org, The IESG , jonathan@vidyo.com Subject: Re: [avtext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-avtext-splicing-notification-07=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= 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, 14 Jun 2016 11:19:50 -0000 > On 13 Jun 2016, at 13:55, Mirja Kuehlewind = wrote: >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-avtext-splicing-notification-07: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I have a few points which I would like to have answers for before = moving > the doc forward (which may not even results in text changes). I happy = to > clear my position when answered before the telechat: >=20 > - The following action does not seem to be appropriate for a > specification of an end-to-end protocol: > "And if the splicer wishes to prevent the downstream receivers from > detecting splicing, it MUST > NOT forward the message." > I guess if a middlebox decides to drop the message, there is not much = we > can do. But I definitely would prefer to not see this specified in an > RFC. This isn=E2=80=99t an end-to-end protocol. It=E2=80=99s a protocol for a = sender to communicate with an RTP middlebox that=E2=80=99s performing = splicing. RTP middleboxes are expected to modify RTCP, and discarding or = modifying RTCP packets that don=E2=80=99t make sense for some = participants is normal behaviour for such middleboxes. > - Why is just having the RTCP message not sufficient? Why are the RTP > extensions needed as well? RTP and RTCP are unreliable. The usual practice for these types of = extension is to send data both in RTCP, and in some number of RTP = packets, to increase the chances of it arriving in a timely manner. The = draft is following standard practice here. > - And is the RTCP message send only once or multiple time? This is not > specified. That=E2=80=99s implementation dependent, and based on the expected = packet loss rate, the importance of the data, and the frequency with = which updates need to be sent.=20 > - There is some discussion about the implementation of the slicer in > section 5 (where btw. the title "Failure Cases" seems inappropriate), > while there is one sentence saying: "If the splicer is implemented > following [RFC6828], it will have its > own SSRC and will send its own RTCP reports, and will forward > translated RTCP reports from the receivers." > Why are alternatives discussed here, if there is already a = recommendation > given in RFC6828? I assume because this is not normatively requiring RFC 6828. > And how would proper congestion handling be ensure in the other setups = not described in RFC6828? If the splicer is implemented as an RTP mixer, as in RFC 6828, then = there will be three congestion control loops: original sender to = splicer, substitutive sender to splicer, and splicer to receiver.=20 If the splicer is implemented as an RTP translator, then it will be = invisible to the congestion control, and the control loops run between = original sender and receiver, or between substitutive sender and = receiver, depending which of the streams is passed by the splicer.=20 If the splicer is implemented for unicast streaming, the congestion = control loops could run the RMCAT algorithms. Perhaps more likely, = though, is that the splicer acts on a multicast (SSM) RTP flow, and you = have provisioned capacity.=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > - As a general comment, I found it quite hard to read this doc without > reading RFC6828 which is only listed as a informative reference as it = is > informational only. I think it is wrong. Further, RFC6828 describes = some > action that a slicers has to perform. However, all language in RFC6828 = is > non normative. This is slightly confusing to me as well. I would = further > recommend to briefly give an overview of the assumed scenario is this > document. >=20 > - Minor comment: The definition of the new SDP grouping semantic = should > be mentioned in the abstract and RFC4566 should be referenced. And I > don't think the SDP grouping registry requires a contact. >=20 > - Quick question: Maybe I'm missing something here but why do you need = a > splicer in a scenario where "the > substitutive sender is implemented together with the main RTP sender > inside a single device" (as written in section 2)? >=20 >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext --=20 Colin Perkins https://csperkins.org/ From nobody Tue Jun 14 08:04: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 C383412D7C7 for ; Tue, 14 Jun 2016 08:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 0OTOwBSZV5pf for ; Tue, 14 Jun 2016 08:04:51 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C2412D534 for ; Tue, 14 Jun 2016 08:04:50 -0700 (PDT) Received: (qmail 12155 invoked from network); 14 Jun 2016 16:58:07 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 14 Jun 2016 16:58:07 +0200 To: Colin Perkins References: <20160613125529.12490.86798.idtracker@ietfa.amsl.com> <65EAADDF-EE7F-414B-AF3F-45BA4B729500@csperkins.org> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <57601B7E.3070208@kuehlewind.net> Date: Tue, 14 Jun 2016 16:58:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <65EAADDF-EE7F-414B-AF3F-45BA4B729500@csperkins.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: avtext-chairs@ietf.org, draft-ietf-avtext-splicing-notification@ietf.org, avtext@ietf.org, The IESG , jonathan@vidyo.com Subject: Re: [avtext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-avtext-splicing-notification-07=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= 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, 14 Jun 2016 15:04:54 -0000 Hi, thanks for the quick reply. See below. On 14.06.2016 13:19, Colin Perkins wrote: >> On 13 Jun 2016, at 13:55, Mirja Kuehlewind wrote: >> >> Mirja Kühlewind has entered the following ballot position for >> draft-ietf-avtext-splicing-notification-07: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I have a few points which I would like to have answers for before moving >> the doc forward (which may not even results in text changes). I happy to >> clear my position when answered before the telechat: >> >> - The following action does not seem to be appropriate for a >> specification of an end-to-end protocol: >> "And if the splicer wishes to prevent the downstream receivers from >> detecting splicing, it MUST >> NOT forward the message." >> I guess if a middlebox decides to drop the message, there is not much we >> can do. But I definitely would prefer to not see this specified in an >> RFC. > > This isn’t an end-to-end protocol. It’s a protocol for a sender to communicate with an RTP middlebox that’s performing splicing. RTP middleboxes are expected to modify RTCP, and discarding or modifying RTCP packets that don’t make sense for some participants is normal behaviour for such middleboxes. Okay, thanks for the clarification that this is excepted behavior. I still find the wording a little awkward. Shouldn't this be: "The splicer MAY decide to not forward the message, e.g., if it wishes to prevent the downstream receivers from detecting splicing"? Or maybe SHOULD if that is actually the recommend behavior (but then the if part makes basically no sense)... >> - Why is just having the RTCP message not sufficient? Why are the RTP >> extensions needed as well? > > RTP and RTCP are unreliable. The usual practice for these types of extension is to send data both in RTCP, and in some number of RTP packets, to increase the chances of it arriving in a timely manner. The draft is following standard practice here. Thanks for clarification. That could be clarified in the text. Because the text says that RTCP is used because the RTP information might get lost. So I was wondering why you are not only using RTCP and make sure you send it sufficiently often. Saying that this is common practice would be helpful from my point of view. Is there a reference for this? >> - And is the RTCP message send only once or multiple time? This is not >> specified. > > That’s implementation dependent, and based on the expected packet loss rate, the importance of the data, and the frequency with which updates need to be sent. A recommendation or discussion should be provided here. > >> - There is some discussion about the implementation of the slicer in >> section 5 (where btw. the title "Failure Cases" seems inappropriate), >> while there is one sentence saying: "If the splicer is implemented >> following [RFC6828], it will have its >> own SSRC and will send its own RTCP reports, and will forward >> translated RTCP reports from the receivers." >> Why are alternatives discussed here, if there is already a recommendation >> given in RFC6828? > > I assume because this is not normatively requiring RFC 6828. As I said below, I find it hard to read this document without having read RFC6828; therefore I'd say it should be normative or more background information should be added to this doc about the assumed scenario(s). > >> And how would proper congestion handling be ensure in the other setups not described in RFC6828? > > If the splicer is implemented as an RTP mixer, as in RFC 6828, then there will be three congestion control loops: original sender to splicer, substitutive sender to splicer, and splicer to receiver. Yes, this one is find and discussed in RFC6828. > > If the splicer is implemented as an RTP translator, then it will be invisible to the congestion control, and the control loops run between original sender and receiver, or between substitutive sender and receiver, depending which of the streams is passed by the splicer. In this scenario, the RTCP feedback message MUST be passed to the right sender to make the congestion control work. This part is not clearly specified in the draft, as far as I can say. And will the splicer then forward the packets unaltered to the receiver, or could it be possible that the splicer adds additional data? > > If the splicer is implemented for unicast streaming, the congestion control loops could run the RMCAT algorithms. Perhaps more likely, though, is that the splicer acts on a multicast (SSM) RTP flow, and you have provisioned capacity. > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> - As a general comment, I found it quite hard to read this doc without >> reading RFC6828 which is only listed as a informative reference as it is >> informational only. I think it is wrong. Further, RFC6828 describes some >> action that a slicers has to perform. However, all language in RFC6828 is >> non normative. This is slightly confusing to me as well. I would further >> recommend to briefly give an overview of the assumed scenario is this >> document. >> >> - Minor comment: The definition of the new SDP grouping semantic should >> be mentioned in the abstract and RFC4566 should be referenced. And I >> don't think the SDP grouping registry requires a contact. >> >> - Quick question: Maybe I'm missing something here but why do you need a >> splicer in a scenario where "the >> substitutive sender is implemented together with the main RTP sender >> inside a single device" (as written in section 2)? >> >> >> _______________________________________________ >> avtext mailing list >> avtext@ietf.org >> https://www.ietf.org/mailman/listinfo/avtext > > > From nobody Tue Jun 14 12:24:32 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 E8F9312D91D; Tue, 14 Jun 2016 12:24:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160614192411.19187.22192.idtracker@ietfa.amsl.com> Date: Tue, 14 Jun 2016 12:24:11 -0700 Archived-At: Cc: draft-ietf-avtext-splicing-notification@ietf.org, avtext@ietf.org, jonathan@vidyo.com, avtext-chairs@ietf.org Subject: [avtext] Alissa Cooper's No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 19:24:12 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-avtext-splicing-notification-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 4 = "Either the main RTP sender or the substitutive sender SHOULD send the synchronization metadata early enough so that the receivers can play out the multimedia in a synchronized fashion." In Section 2 you gave a guideline for how to figure out how far in advance to send the splicing information. I think a similar guideline would be useful here. s/e.g., choosing media sender/e.g., choosing main RTP sender/ = Section 7 = What is undetectable splicing? = Section 8.3 = In the past when we've registered these there was no contact I don't think. Not sure what IANA would do with one here. From nobody Tue Jun 14 12:36:17 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7918F12D92D for ; Tue, 14 Jun 2016 12:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 NKwO08cC-nBP for ; Tue, 14 Jun 2016 12:36:12 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 0FACA12D928 for ; Tue, 14 Jun 2016 12:36:12 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id a186so401200qkf.0 for ; Tue, 14 Jun 2016 12:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hUh0bd3iANeh49l8W15q5tSNNwfxmfooJx8JDNwcU58=; b=jo9Qj33uJJkquX00rVVP0T/ZjkrJ80r3UdhRvsKEVlFzd58CtkzWQ/zGdQJy9AXq3q R1K1yFV9ZXR8lnCFwJm0r4co9DUrt9fZl3frhPKVkhk0BeDKjAMTE4ZaSNSiCgkQ01y6 E4tMVY6Zwna2V34QWXrML1WSCToOT3FnGybHtdQKv3GoNSfpHn1Z4ns2+gpmy7NNDXB/ 6eTWEvaxOXbDT9fFJls1J+U7f2SuO5Zg+LLX7f1ONQJJG+rX/vhBIHS+FBMV+hl0ALur AcD8rn/Piz5YuWhsmnOwLpBIhIFZPZ4WNONR50yZRO/NzpKZ/I17P0Ud/wD6Zw15R94y YP0A== 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=hUh0bd3iANeh49l8W15q5tSNNwfxmfooJx8JDNwcU58=; b=X9CgXNbzJYRDW4rQchhm0q/wqB3lHMwdwUk7l9ZNsrpxa+k71zRbs2OnJp1RQfl+jB my2YPOM17MO/GzCmyOg60Ee5a3r9LHsA1ROSEoRlINcCDHcqkQdDKWyggIlagxpI2FdA zIB8v01wK9qMTbhqigrKE4shONnTdiqHkV5xYvauiDdYElf1xNzO7/xmYnbfuy3cZrut 1MGr8yhTwt7jOALy/drlK9YyXVOWPbuV83C39JynS4JqkGxGxYxC5SGvPpMjO1DSke7p VNqKPdiExbATem5yOI3b2fMHo5eVsAtGY3VC6QxTEB6PFRtP4y9q/q/WNSqJKBbYcTXl XZwg== X-Gm-Message-State: ALyK8tJBUdlnlQ7JoCtgqbe/CU4MeEuedQgDmq47R7oVb4UaGuOLAZeK+UnKCRLJbjwlcQ6sFBU9kL46sUEsZOXv X-Received: by 10.200.51.35 with SMTP id t32mr21635932qta.91.1465932971057; Tue, 14 Jun 2016 12:36:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.189.195 with HTTP; Tue, 14 Jun 2016 12:35:31 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Tue, 14 Jun 2016 12:35:31 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a1149e7000178c20535421ef7 Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] 2nd WGLC: draft-ietf-avtext-rid-02 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, 14 Jun 2016 19:36:16 -0000 --001a1149e7000178c20535421ef7 Content-Type: text/plain; charset=UTF-8 That clarification makes sense to me. Obviously if layers share an RTP Stream, the share an RtpStreamId and need a different ID to differentiate them. On Fri, Jun 10, 2016 at 1:11 PM, Bernard Aboba wrote: > I have one comment. > > " To address this situation, we define a new RTCP SDES identifier, > > RtpStreamId, that uniquely identifies a single RTP stream. A key > motivator for defining this identifier is the ability to > differentiate among different encodings of a single Source Stream > that are sent simultaneously (i.e., simulcast). This need for unique > identification extends to dependent streams (i.e., layers used by a > layered codec)" > > > [BA] Where the layers of a layered codec are transmitted within the same RTP stream (SRST transport), each of the layers would utilize the same RtpStreamId. > > So presumably the need for unique identification is met only where MRST transport is used. > > > So should the last sentence say: "where layers used by a layered codec are transmitted on separate streams" ? > > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > > --001a1149e7000178c20535421ef7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That clarification makes sense to me.=C2=A0 Obviously i= f layers share an RTP Stream, the share an RtpStreamId and need a different= ID to differentiate them.

On Fri, Jun 10, 2016 at 1:11 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
I have one comme= nt.=C2=A0

<= div>" To address this situation, we define a new RTCP = SDES identifier,
   RtpStreamId, that uniquely identifies a single RTP stream.  A key
   motivator for defining this identifier is the ability to
   differentiate among different encodings of a single Source Stream
   that are sent simultaneously (i.e., simulcast).  This need for unique
   identification extends to dependent streams (i.e., layers used by a
   layered codec)"

[BA] =
Where the layers of a layered codec are transmitted within the same RTP=
 stream=C2=A0(SRST transport), each of the layers would utilize the =
same RtpStreamId. 
So presumably the need for unique identif=
ication is met only where MRST transport is used.
So should the last sentence say:  "where =
layers used by a layered codec a=
re transmitted on separate streams" ?

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


--001a1149e7000178c20535421ef7-- From nobody Tue Jun 14 14:21:11 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 B30BC12D978; Tue, 14 Jun 2016 14:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 dAYCHeuqoWHV; Tue, 14 Jun 2016 14:21:03 -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 95C4D12D660; Tue, 14 Jun 2016 14:20:54 -0700 (PDT) Received: from [81.187.2.149] (port=45537 helo=[192.168.0.91]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bCvEn-0002jy-3Z; Tue, 14 Jun 2016 21:47:06 +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: <57601B7E.3070208@kuehlewind.net> Date: Tue, 14 Jun 2016 21:46:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5BBF8F14-7000-4260-8996-23A5438726AF@csperkins.org> References: <20160613125529.12490.86798.idtracker@ietfa.amsl.com> <65EAADDF-EE7F-414B-AF3F-45BA4B729500@csperkins.org> <57601B7E.3070208@kuehlewind.net> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: avtext-chairs@ietf.org, draft-ietf-avtext-splicing-notification@ietf.org, avtext@ietf.org, The IESG , jonathan@vidyo.com Subject: Re: [avtext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-avtext-splicing-notification-07=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= 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, 14 Jun 2016 21:21:06 -0000 Hi Mirja, Some comments in line, but mostly I think this now needs a response from = the authors.=20 Colin > On 14 Jun 2016, at 15:58, Mirja K=C3=BChlewind = wrote: >=20 > Hi, >=20 > thanks for the quick reply. See below. >=20 > On 14.06.2016 13:19, Colin Perkins wrote: >>> On 13 Jun 2016, at 13:55, Mirja Kuehlewind = wrote: >>>=20 >>> Mirja K=C3=BChlewind has entered the following ballot position for >>> draft-ietf-avtext-splicing-notification-07: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> = https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> I have a few points which I would like to have answers for before = moving >>> the doc forward (which may not even results in text changes). I = happy to >>> clear my position when answered before the telechat: >>>=20 >>> - The following action does not seem to be appropriate for a >>> specification of an end-to-end protocol: >>> "And if the splicer wishes to prevent the downstream receivers from >>> detecting splicing, it MUST >>> NOT forward the message." >>> I guess if a middlebox decides to drop the message, there is not = much we >>> can do. But I definitely would prefer to not see this specified in = an >>> RFC. >>=20 >> This isn=E2=80=99t an end-to-end protocol. It=E2=80=99s a protocol = for a sender to communicate with an RTP middlebox that=E2=80=99s = performing splicing. RTP middleboxes are expected to modify RTCP, and = discarding or modifying RTCP packets that don=E2=80=99t make sense for = some participants is normal behaviour for such middleboxes. >=20 > Okay, thanks for the clarification that this is excepted behavior. I = still find the wording a little awkward. Shouldn't this be: >=20 > "The splicer MAY decide to not forward the message, e.g., if it wishes = to prevent the downstream receivers from detecting splicing"? >=20 > Or maybe SHOULD if that is actually the recommend behavior (but then = the if part makes basically no sense)=E2=80=A6 I=E2=80=99m not sure it needs to use normative language for either of = the points in that paragraph, but I don=E2=80=99t see that it hurts. = Essentially, if the splicing notification message is forwarded, it = wastes a trivial amount of bandwidth, and tells the downstream receivers = exactly when the splicing occurred. The latter is visible from looking = at the video content anyway, but I suppose that not giving the hint = might make things slightly harder for devices that are trying to block = adverts inserted via splicing.=20 >>> - Why is just having the RTCP message not sufficient? Why are the = RTP >>> extensions needed as well? >>=20 >> RTP and RTCP are unreliable. The usual practice for these types of = extension is to send data both in RTCP, and in some number of RTP = packets, to increase the chances of it arriving in a timely manner. The = draft is following standard practice here. >=20 > Thanks for clarification. That could be clarified in the text. Because = the text says that RTCP is used because the RTP information might get = lost. So I was wondering why you are not only using RTCP and make sure = you send it sufficiently often. Saying that this is common practice = would be helpful from my point of view. Is there a reference for this? It should be easy to clarify, but I=E2=80=99m not sure there=E2=80=99s a = reference. It=E2=80=99s a practice that=E2=80=99s evolved over time, but = I=E2=80=99m not sure it=E2=80=99s well documented.=20 >>> - And is the RTCP message send only once or multiple time? This is = not >>> specified. >>=20 >> That=E2=80=99s implementation dependent, and based on the expected = packet loss rate, the importance of the data, and the frequency with = which updates need to be sent. >=20 > A recommendation or discussion should be provided here. >=20 >>=20 >>> - There is some discussion about the implementation of the slicer in >>> section 5 (where btw. the title "Failure Cases" seems = inappropriate), >>> while there is one sentence saying: "If the splicer is implemented >>> following [RFC6828], it will have its >>> own SSRC and will send its own RTCP reports, and will forward >>> translated RTCP reports from the receivers." >>> Why are alternatives discussed here, if there is already a = recommendation >>> given in RFC6828? >>=20 >> I assume because this is not normatively requiring RFC 6828. >=20 > As I said below, I find it hard to read this document without having = read RFC6828; therefore I=E2=80=99d say it should be normative or more = background information should be added to this doc about the assumed = scenario(s). I=E2=80=99ll let the authors respond to this.=20 >>> And how would proper congestion handling be ensure in the other = setups not described in RFC6828? >>=20 >> If the splicer is implemented as an RTP mixer, as in RFC 6828, then = there will be three congestion control loops: original sender to = splicer, substitutive sender to splicer, and splicer to receiver. > Yes, this one is find and discussed in RFC6828. >>=20 >> If the splicer is implemented as an RTP translator, then it will be = invisible to the congestion control, and the control loops run between = original sender and receiver, or between substitutive sender and = receiver, depending which of the streams is passed by the splicer. > In this scenario, the RTCP feedback message MUST be passed to the = right sender to make the congestion control work. This part is not = clearly specified in the draft, as far as I can say. I agree that the RTCP needs to be passed to the right place, and that = draft should be clarified if that=E2=80=99s not clear. > And will the splicer then forward the packets unaltered to the = receiver, or could it be possible that the splicer adds additional data? It=E2=80=99s certainly possible that the splicer could rewrite the RTP = headers, or even transcode the media. That=E2=80=99s true of any RTP = middlebox, and if done, the middlebox needs to be careful to rewrite = RTCP to match, to ensure that it=E2=80=99s done transparently. The RTP = spec has some words about this, and drafts like = draft-ietf-straw-b2bua-rtcp-12 give additional recommendations (although = that=E2=80=99s not an appropriate reference to add to this document, = since it=E2=80=99s unlikely that splicing will be done with SIP). >> If the splicer is implemented for unicast streaming, the congestion = control loops could run the RMCAT algorithms. Perhaps more likely, = though, is that the splicer acts on a multicast (SSM) RTP flow, and you = have provisioned capacity. >>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> - As a general comment, I found it quite hard to read this doc = without >>> reading RFC6828 which is only listed as a informative reference as = it is >>> informational only. I think it is wrong. Further, RFC6828 describes = some >>> action that a slicers has to perform. However, all language in = RFC6828 is >>> non normative. This is slightly confusing to me as well. I would = further >>> recommend to briefly give an overview of the assumed scenario is = this >>> document. >>>=20 >>> - Minor comment: The definition of the new SDP grouping semantic = should >>> be mentioned in the abstract and RFC4566 should be referenced. And I >>> don't think the SDP grouping registry requires a contact. >>>=20 >>> - Quick question: Maybe I'm missing something here but why do you = need a >>> splicer in a scenario where "the >>> substitutive sender is implemented together with the main RTP = sender >>> inside a single device" (as written in section 2)? >>>=20 >>>=20 >>> _______________________________________________ >>> avtext mailing list >>> avtext@ietf.org >>> https://www.ietf.org/mailman/listinfo/avtext >>=20 >>=20 >>=20 --=20 Colin Perkins https://csperkins.org/ From nobody Tue Jun 14 14:59:35 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 F175612D7BA; Tue, 14 Jun 2016 14:59:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160614215932.31629.25074.idtracker@ietfa.amsl.com> Date: Tue, 14 Jun 2016 14:59:32 -0700 Archived-At: Cc: draft-ietf-avtext-splicing-notification@ietf.org, avtext@ietf.org, jonathan@vidyo.com, avtext-chairs@ietf.org Subject: [avtext] Alia Atlas' Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS) 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: Tue, 14 Jun 2016 21:59:34 -0000 Alia Atlas has entered the following ballot position for draft-ietf-avtext-splicing-notification-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I believe this is more a discussion for the IESG. First, this is way out of my area and I'm not particularly commenting on the details - but I do agree with Mirja's discuss about "- The following action does not seem to be appropriate for a specification of an end-to-end protocol: "And if the splicer wishes to prevent the downstream receivers from detecting splicing, it MUST NOT forward the message."" The full paragraph at the end of Sec 3.2 is: "When the splicer intercepts the RTCP splicing notification message, it SHOULD NOT forward the message to the down-stream receivers in order to reduce RTCP bandwidth consumption. And if the splicer wishes to prevent the downstream receivers from detecting splicing, it MUST NOT forward the message." Even more specifically to me, superficially this seems to me to be a way to change what is in the stream that a receiver has requested or subscribed to without permission or notification. In that light, the idea that the splicer is able to prevent downstream receivers from detecting the splicing does not sound good. Similarly, the end of Sec 3.1 says "After the splicer intercepts the RTP header extension and derives the Splicing Interval, it will generate its own stream and SHOULD NOT include the RTP header extension in outgoing packets to reduce header overhead." This looks like another example of making the choice to hide information from the receiver. I realize that there is probably an technical arms-race going on - of inserting advertisements and building receivers to block undesired advertisements. I am not seeing a balanced solution that considers the receivers as well as the senders. I am startled that there is no consideration of the impact of this extension on the receivers in the security considerations. The only reference I see in the Security Considerations further assumes that it is appropriate to have an undetectable splicing. " A malicious endpoint may also break an undetectable splicing. To mitigate this effect, the splicer SHOULD NOT forward the splicing time information RTP header extension defined in Section 4.1 to the receivers. And it MUST NOT forward this header extension when considering an undetectable splicing. " At a minimum, I feel like there should be a very clear consideration of the pros and cons - including from the viewpoint of a receiver. If we end up with this biased technology, then it should be clearly stated - not hidden in assumptions. From nobody Tue Jun 14 16:43:43 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 C74CC12D526; Tue, 14 Jun 2016 16:43:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160614234338.31686.99072.idtracker@ietfa.amsl.com> Date: Tue, 14 Jun 2016 16:43:38 -0700 Archived-At: Cc: draft-ietf-avtext-splicing-notification@ietf.org, avtext@ietf.org, jonathan@vidyo.com, avtext-chairs@ietf.org Subject: [avtext] Spencer Dawkins' No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 23:43:39 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-avtext-splicing-notification-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I do share the question about the definition of "undetectable splicing". From nobody Wed Jun 15 00:22: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 30B2F12D11D; Wed, 15 Jun 2016 00:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 M6A2dEgyTvPr; Wed, 15 Jun 2016 00:22:45 -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 CFEEB12D097; Wed, 15 Jun 2016 00:22:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLZ26478; Wed, 15 Jun 2016 07:22:33 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 15 Jun 2016 08:22:32 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 15 Jun 2016 15:22:29 +0800 From: "Huangyihong (Rachel)" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Colin Perkins Thread-Topic: =?utf-8?B?W2F2dGV4dF0gTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQt?= =?utf-8?B?aWV0Zi1hdnRleHQtc3BsaWNpbmctbm90aWZpY2F0aW9uLTA3OiAod2l0aCBE?= =?utf-8?Q?ISCUSS_and_COMMENT)?= Thread-Index: AQHRxXLhQkVNte5sYUSvL3qNIr+QGJ/oTEQAgAA9CgCAAZNJ8A== Date: Wed, 15 Jun 2016 07:22:28 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86ED634A@nkgeml513-mbx.china.huawei.com> References: <20160613125529.12490.86798.idtracker@ietfa.amsl.com> <65EAADDF-EE7F-414B-AF3F-45BA4B729500@csperkins.org> <57601B7E.3070208@kuehlewind.net> In-Reply-To: <57601B7E.3070208@kuehlewind.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.88.247] 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.0A090202.57610240.0020, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0d79b6ff6069befb6f8ec78ca34d1713 Archived-At: Cc: "avtext-chairs@ietf.org" , "draft-ietf-avtext-splicing-notification@ietf.org" , "avtext@ietf.org" , The IESG , "jonathan@vidyo.com" Subject: Re: [avtext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-avtext-splicing-notification-07=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= 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, 15 Jun 2016 07:22:47 -0000 SGkgTWlyamEsDQoNCkFzIG9uZSBvZiB0aGUgYXV0aG9ycywgcGxlYXNlIHNlZSBteSByZXBsaWVz IGlubGluZS4NCg0KQlIsDQpSYWNoZWwgDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7 tuS6ujogTWlyamEgS8O8aGxld2luZCBbbWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXRdDQrlj5Hp gIHml7bpl7Q6IDIwMTblubQ25pyIMTTml6UgMjI6NTgNCuaUtuS7tuS6ujogQ29saW4gUGVya2lu cw0K5oqE6YCBOiBUaGUgSUVTRzsgZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmctbm90aWZpY2F0 aW9uQGlldGYub3JnOyBhdnRleHRAaWV0Zi5vcmc7IGpvbmF0aGFuQHZpZHlvLmNvbTsgYXZ0ZXh0 LWNoYWlyc0BpZXRmLm9yZw0K5Li76aKYOiBSZTogW2F2dGV4dF0gTWlyamEgS8O8aGxld2luZCdz IERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmctbm90aWZpY2F0aW9uLTA3OiAo d2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQpIaSwNCg0KdGhhbmtzIGZvciB0aGUgcXVpY2sg cmVwbHkuIFNlZSBiZWxvdy4NCg0KT24gMTQuMDYuMjAxNiAxMzoxOSwgQ29saW4gUGVya2lucyB3 cm90ZToNCj4+IE9uIDEzIEp1biAyMDE2LCBhdCAxMzo1NSwgTWlyamEgS3VlaGxld2luZCA8aWV0 ZkBrdWVobGV3aW5kLm5ldD4gd3JvdGU6DQo+Pg0KPj4gTWlyamEgS8O8aGxld2luZCBoYXMgZW50 ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4+IGRyYWZ0LWlldGYtYXZ0 ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0wNzogRGlzY3Vzcw0KPj4NCj4+IFdoZW4gcmVzcG9u ZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFs bCANCj4+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAo RmVlbCBmcmVlIHRvIGN1dCANCj4+IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZl ci4pDQo+Pg0KPj4NCj4+IFBsZWFzZSByZWZlciB0bw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv aWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+PiBmb3IgbW9yZSBpbmZvcm1h dGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPj4NCj4+DQo+ PiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJl IGZvdW5kIGhlcmU6DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWF2dGV4dC1zcGxpY2luZy1ub3RpZmljYXQNCj4+IGlvbi8NCj4+DQo+Pg0KPj4NCj4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPj4gLQ0KPj4gRElTQ1VTUzoNCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gLQ0KPj4N Cj4+IEkgaGF2ZSBhIGZldyBwb2ludHMgd2hpY2ggSSB3b3VsZCBsaWtlIHRvIGhhdmUgYW5zd2Vy cyBmb3IgYmVmb3JlIA0KPj4gbW92aW5nIHRoZSBkb2MgZm9yd2FyZCAod2hpY2ggbWF5IG5vdCBl dmVuIHJlc3VsdHMgaW4gdGV4dCBjaGFuZ2VzKS4NCj4+IEkgaGFwcHkgdG8gY2xlYXIgbXkgcG9z aXRpb24gd2hlbiBhbnN3ZXJlZCBiZWZvcmUgdGhlIHRlbGVjaGF0Og0KPj4NCj4+IC0gVGhlIGZv bGxvd2luZyBhY3Rpb24gZG9lcyBub3Qgc2VlbSB0byBiZSBhcHByb3ByaWF0ZSBmb3IgYSANCj4+ IHNwZWNpZmljYXRpb24gb2YgYW4gZW5kLXRvLWVuZCBwcm90b2NvbDoNCj4+ICJBbmQgaWYgdGhl IHNwbGljZXIgd2lzaGVzIHRvIHByZXZlbnQgdGhlIGRvd25zdHJlYW0gcmVjZWl2ZXJzIGZyb20g DQo+PiBkZXRlY3Rpbmcgc3BsaWNpbmcsIGl0IE1VU1QNCj4+ICAgIE5PVCBmb3J3YXJkIHRoZSBt ZXNzYWdlLiINCj4+IEkgZ3Vlc3MgaWYgYSBtaWRkbGVib3ggZGVjaWRlcyB0byBkcm9wIHRoZSBt ZXNzYWdlLCB0aGVyZSBpcyBub3QgbXVjaCANCj4+IHdlIGNhbiBkby4gQnV0IEkgZGVmaW5pdGVs eSB3b3VsZCBwcmVmZXIgdG8gbm90IHNlZSB0aGlzIHNwZWNpZmllZCBpbiANCj4+IGFuIFJGQy4N Cj4NCj4gVGhpcyBpc27igJl0IGFuIGVuZC10by1lbmQgcHJvdG9jb2wuIEl04oCZcyBhIHByb3Rv Y29sIGZvciBhIHNlbmRlciB0byBjb21tdW5pY2F0ZSB3aXRoIGFuIFJUUCBtaWRkbGVib3ggdGhh dOKAmXMgcGVyZm9ybWluZyBzcGxpY2luZy4gUlRQIG1pZGRsZWJveGVzIGFyZSBleHBlY3RlZCB0 byBtb2RpZnkgUlRDUCwgYW5kIGRpc2NhcmRpbmcgb3IgbW9kaWZ5aW5nIFJUQ1AgcGFja2V0cyB0 aGF0IGRvbuKAmXQgbWFrZSBzZW5zZSBmb3Igc29tZSBwYXJ0aWNpcGFudHMgaXMgbm9ybWFsIGJl aGF2aW91ciBmb3Igc3VjaCBtaWRkbGVib3hlcy4NCg0KT2theSwgdGhhbmtzIGZvciB0aGUgY2xh cmlmaWNhdGlvbiB0aGF0IHRoaXMgaXMgZXhjZXB0ZWQgYmVoYXZpb3IuIEkgc3RpbGwgZmluZCB0 aGUgd29yZGluZyBhIGxpdHRsZSBhd2t3YXJkLiBTaG91bGRuJ3QgdGhpcyBiZToNCg0KIlRoZSBz cGxpY2VyIE1BWSBkZWNpZGUgdG8gbm90IGZvcndhcmQgdGhlIG1lc3NhZ2UsIGUuZy4sIGlmIGl0 IHdpc2hlcyB0byBwcmV2ZW50IHRoZSBkb3duc3RyZWFtIHJlY2VpdmVycyBmcm9tIGRldGVjdGlu ZyBzcGxpY2luZyI/DQoNCk9yIG1heWJlIFNIT1VMRCBpZiB0aGF0IGlzIGFjdHVhbGx5IHRoZSBy ZWNvbW1lbmQgYmVoYXZpb3IgKGJ1dCB0aGVuIHRoZSBpZiBwYXJ0IG1ha2VzIGJhc2ljYWxseSBu byBzZW5zZSkuLi4NCg0KW1JhY2hlbF06IE9rYXkuIEkgdGhpbmsgaXQgY2FuIGJlIG1vZGlmaWVk IGxpa2UgdGhpcyBpbiB0aGlzIGNhc2UuIA0KDQoNCj4+IC0gV2h5IGlzIGp1c3QgaGF2aW5nIHRo ZSBSVENQIG1lc3NhZ2Ugbm90IHN1ZmZpY2llbnQ/IFdoeSBhcmUgdGhlIFJUUCANCj4+IGV4dGVu c2lvbnMgbmVlZGVkIGFzIHdlbGw/DQo+DQo+IFJUUCBhbmQgUlRDUCBhcmUgdW5yZWxpYWJsZS4g VGhlIHVzdWFsIHByYWN0aWNlIGZvciB0aGVzZSB0eXBlcyBvZiBleHRlbnNpb24gaXMgdG8gc2Vu ZCBkYXRhIGJvdGggaW4gUlRDUCwgYW5kIGluIHNvbWUgbnVtYmVyIG9mIFJUUCBwYWNrZXRzLCB0 byBpbmNyZWFzZSB0aGUgY2hhbmNlcyBvZiBpdCBhcnJpdmluZyBpbiBhIHRpbWVseSBtYW5uZXIu IFRoZSBkcmFmdCBpcyBmb2xsb3dpbmcgc3RhbmRhcmQgcHJhY3RpY2UgaGVyZS4NCg0KVGhhbmtz IGZvciBjbGFyaWZpY2F0aW9uLiBUaGF0IGNvdWxkIGJlIGNsYXJpZmllZCBpbiB0aGUgdGV4dC4g QmVjYXVzZSB0aGUgdGV4dCBzYXlzIHRoYXQgUlRDUCBpcyB1c2VkIGJlY2F1c2UgdGhlIFJUUCBp bmZvcm1hdGlvbiBtaWdodCBnZXQgbG9zdC4gU28gSSB3YXMgd29uZGVyaW5nIHdoeSB5b3UgYXJl IG5vdCBvbmx5IHVzaW5nIFJUQ1AgYW5kIG1ha2Ugc3VyZSB5b3Ugc2VuZCBpdCBzdWZmaWNpZW50 bHkgb2Z0ZW4uIFNheWluZyB0aGF0IHRoaXMgaXMgY29tbW9uIHByYWN0aWNlIHdvdWxkIGJlIGhl bHBmdWwgZnJvbSBteSBwb2ludCBvZiB2aWV3LiBJcyB0aGVyZSBhIHJlZmVyZW5jZSBmb3IgdGhp cz8NCg0KW1JhY2hlbF06IEl0J3MgbW9yZSBsaWtlIGNvbnZlbnRpb25hbCBtZXRob2QgdG8gaW5j cmVhc2Ugcm9idXN0bmVzcy4gQXMgZmFyIGFzIEkga25vdywgdGhlcmUncyBubyBmb3JtYWwgZG9j dW1lbnQgdG8gcmVjb3JkIHRoaXMuIE1heWJlIHdlIGNhbiBhZGRyZXNzIHRoaXMgbGlrZSB0aGlz DQoNCk9MRA0KIg0KDQogICBUbyBpbmNyZWFzZSByb2J1c3RuZXNzIGFnYWluc3Qgc3VjaCBjYXNl LCB0aGUgZG9jdW1lbnQgYWxzbyBkZWZpbmVzIGENCiAgIGNvbXBsZW1lbnRhcnkgUlRDUCBwYWNr ZXQgdHlwZSB0byBjYXJyeSB0aGUgc2FtZSBTcGxpY2luZyBJbnRlcnZhbCB0bw0KICAgdGhlIHNw bGljZXIuDQoNCiINCg0KTkVXDQoiDQogICBUbyBpbmNyZWFzZSByb2J1c3RuZXNzIGFnYWluc3Qg c3VjaCBjYXNlLCB0aGUgZG9jdW1lbnQgYWxzbyBkZWZpbmVzIGENCiAgIG5ldyBSVENQIHBhY2tl dCB0eXBlIHRvIGNhcnJ5IHRoZSBzYW1lIFNwbGljaW5nIEludGVydmFsIHRvDQogICB0aGUgc3Bs aWNlci4gU2luY2UgUlRDUCBpcyBhbHNvIHVucmVsaWFibGUgYW5kIG1heSBub3Qgc28gaW1tZWRp YXRlIGFzIHRoZSBpbi1iYW5kIHdheSwgaXQncyBvbmx5IGNvbnNpZGVyZWQgYXMgYSBjb21wbGVt ZW50IHRvIFJUUCBoZWFkZXIgZXh0ZW5zaW9uLg0KIg0KDQoNCj4+IC0gQW5kIGlzIHRoZSBSVENQ IG1lc3NhZ2Ugc2VuZCBvbmx5IG9uY2Ugb3IgbXVsdGlwbGUgdGltZT8gVGhpcyBpcyANCj4+IG5v dCBzcGVjaWZpZWQuDQo+DQo+IFRoYXTigJlzIGltcGxlbWVudGF0aW9uIGRlcGVuZGVudCwgYW5k IGJhc2VkIG9uIHRoZSBleHBlY3RlZCBwYWNrZXQgbG9zcyByYXRlLCB0aGUgaW1wb3J0YW5jZSBv ZiB0aGUgZGF0YSwgYW5kIHRoZSBmcmVxdWVuY3kgd2l0aCB3aGljaCB1cGRhdGVzIG5lZWQgdG8g YmUgc2VudC4NCg0KQSByZWNvbW1lbmRhdGlvbiBvciBkaXNjdXNzaW9uIHNob3VsZCBiZSBwcm92 aWRlZCBoZXJlLg0KDQpbUmFjaGVsXTogSSB0aGluayBpbiBTZWN0aW9uIDIsIHdlIGhhdmUgYWxy ZWFkeSBwcm92aWRlZCBzb21lIGd1aWRhbmNlIG9uIGhvdyBvZnRlbiB0aGUgU3BsaWNpbmcgSW50 ZXJ2YWwgdG8gYmUgc2VudCwgd2hpY2ggaXMgbm90IGp1c3QgbGltaXRlZCB0byBSVFAgaGVhZGVy IGV4dGVuc2lvbiwgYWxzbyBpbmNsdWRlcyBSVENQIG1lc3NhZ2UuDQoNCj4NCj4+IC0gVGhlcmUg aXMgc29tZSBkaXNjdXNzaW9uIGFib3V0IHRoZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgc2xpY2Vy IGluIA0KPj4gc2VjdGlvbiA1ICh3aGVyZSBidHcuIHRoZSB0aXRsZSAiRmFpbHVyZSBDYXNlcyIg c2VlbXMgaW5hcHByb3ByaWF0ZSksIA0KPj4gd2hpbGUgdGhlcmUgaXMgb25lIHNlbnRlbmNlIHNh eWluZzogIklmIHRoZSBzcGxpY2VyIGlzIGltcGxlbWVudGVkIA0KPj4gZm9sbG93aW5nIFtSRkM2 ODI4XSwgaXQgd2lsbCBoYXZlIGl0cw0KPj4gICAgb3duIFNTUkMgYW5kIHdpbGwgc2VuZCBpdHMg b3duIFJUQ1AgcmVwb3J0cywgYW5kIHdpbGwgZm9yd2FyZA0KPj4gICAgdHJhbnNsYXRlZCBSVENQ IHJlcG9ydHMgZnJvbSB0aGUgcmVjZWl2ZXJzLiINCj4+IFdoeSBhcmUgYWx0ZXJuYXRpdmVzIGRp c2N1c3NlZCBoZXJlLCBpZiB0aGVyZSBpcyBhbHJlYWR5IGEgDQo+PiByZWNvbW1lbmRhdGlvbiBn aXZlbiBpbiBSRkM2ODI4Pw0KPg0KPiBJIGFzc3VtZSBiZWNhdXNlIHRoaXMgaXMgbm90IG5vcm1h dGl2ZWx5IHJlcXVpcmluZyBSRkMgNjgyOC4NCg0KQXMgSSBzYWlkIGJlbG93LCBJIGZpbmQgaXQg aGFyZCB0byByZWFkIHRoaXMgZG9jdW1lbnQgd2l0aG91dCBoYXZpbmcgcmVhZCBSRkM2ODI4OyB0 aGVyZWZvcmUgSSdkIHNheSBpdCBzaG91bGQgYmUgbm9ybWF0aXZlIG9yIG1vcmUgYmFja2dyb3Vu ZCBpbmZvcm1hdGlvbiBzaG91bGQgYmUgYWRkZWQgdG8gdGhpcyBkb2MgYWJvdXQgdGhlIGFzc3Vt ZWQgc2NlbmFyaW8ocykuDQoNCltSYWNoZWxdOiBTbyB5b3UncmUgc3VnZ2VzdGluZyB0aGF0IHdl IHByb3Bvc2Ugc29tZSB0ZXh0cyB0byBicmllZmx5IGludHJvZHVjZSB0aGUgUkZDNjgyOD8gSWYg dGhhdCdzIHRoZSBjYXNlLCB3ZSdsbCBwcm92aWRlIHNvbWUgdGV4dCBsYXRlci4NCg0KDQo+DQo+ PiBBbmQgaG93IHdvdWxkIHByb3BlciBjb25nZXN0aW9uIGhhbmRsaW5nIGJlIGVuc3VyZSBpbiB0 aGUgb3RoZXIgc2V0dXBzIG5vdCBkZXNjcmliZWQgaW4gUkZDNjgyOD8NCj4NCj4gSWYgdGhlIHNw bGljZXIgaXMgaW1wbGVtZW50ZWQgYXMgYW4gUlRQIG1peGVyLCBhcyBpbiBSRkMgNjgyOCwgdGhl biB0aGVyZSB3aWxsIGJlIHRocmVlIGNvbmdlc3Rpb24gY29udHJvbCBsb29wczogb3JpZ2luYWwg c2VuZGVyIHRvIHNwbGljZXIsIHN1YnN0aXR1dGl2ZSBzZW5kZXIgdG8gc3BsaWNlciwgYW5kIHNw bGljZXIgdG8gcmVjZWl2ZXIuDQpZZXMsIHRoaXMgb25lIGlzIGZpbmQgYW5kIGRpc2N1c3NlZCBp biBSRkM2ODI4Lg0KPg0KPiBJZiB0aGUgc3BsaWNlciBpcyBpbXBsZW1lbnRlZCBhcyBhbiBSVFAg dHJhbnNsYXRvciwgdGhlbiBpdCB3aWxsIGJlIGludmlzaWJsZSB0byB0aGUgY29uZ2VzdGlvbiBj b250cm9sLCBhbmQgdGhlIGNvbnRyb2wgbG9vcHMgcnVuIGJldHdlZW4gb3JpZ2luYWwgc2VuZGVy IGFuZCByZWNlaXZlciwgb3IgYmV0d2VlbiBzdWJzdGl0dXRpdmUgc2VuZGVyIGFuZCByZWNlaXZl ciwgZGVwZW5kaW5nIHdoaWNoIG9mIHRoZSBzdHJlYW1zIGlzIHBhc3NlZCBieSB0aGUgc3BsaWNl ci4NCkluIHRoaXMgc2NlbmFyaW8sIHRoZSBSVENQIGZlZWRiYWNrIG1lc3NhZ2UgTVVTVCBiZSBw YXNzZWQgdG8gdGhlIHJpZ2h0IHNlbmRlciB0byBtYWtlIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wg d29yay4gVGhpcyBwYXJ0IGlzIG5vdCBjbGVhcmx5IHNwZWNpZmllZCBpbiB0aGUgZHJhZnQsIGFz IGZhciBhcyBJIGNhbiBzYXkuDQoNCltSYWNoZWxdOiBPa2F5LiBJIHRoaW5rIHRoaXMgY2FuIGJl IGNsYXJpZmllZCBpbiB0aGUgZHJhZnQsIGFkZGluZyBhIHNlbnRlbmNlIGxpa2UgdGhpczoNCg0K IldoZW4gdGhlIHNwbGljZXIgd29ya3MgYXMgYW4gUlRQIHRyYW5zbGF0b3IsIHRoZSBjb25nZXN0 aW9uIGNvbnRyb2wgcnVucyBiZXR3ZWVuIG9yaWdpbmFsIHNlbmRlciBhbmQgcmVjZWl2ZXIsIG9y IGJldHdlZW4gc3Vic3RpdHV0aXZlIHNlbmRlciBhbmQgcmVjZWl2ZXIsIHNvIHRoZSBSVENQIGZl ZWRiYWNrIG1lc3NhZ2UgTVVTVCBiZSBwYXNzZWQgdG8gdGhlIHJpZ2h0IHNlbmRlciB0byBsZXQg dGhlIGNvbmdlc3Rpb24gY29udHJvbCB3b3JrLiINCg0KQW5kIHdpbGwgdGhlIHNwbGljZXIgdGhl biBmb3J3YXJkIHRoZSBwYWNrZXRzIHVuYWx0ZXJlZCB0byB0aGUgcmVjZWl2ZXIsIG9yIGNvdWxk IGl0IGJlIHBvc3NpYmxlIHRoYXQgdGhlIHNwbGljZXIgYWRkcyBhZGRpdGlvbmFsIGRhdGE/DQoN CltSYWNoZWxdOiBXaGVuIGl0J3Mgbm90IHNwbGljaW5nIHRpbWUsIGl0IHdpbGwgZm9yd2FyZCB0 aGUgcGFja2V0cyB1bnRvdWNoZWQuIE5vIGFkZGl0aW9uYWwgZGF0YS4gV2hlbiBpdCdzIGluIHRo ZSBzcGxpY2luZyBpbnRlcnZhbCwgdGhlIHNwbGljZXIgd2lsbCB1c2UgdGhlIHN1YnN0aXR1dGl2 ZSBjb250ZW50IGluc3RlYWQgb2YgdGhlIG9yaWdpbmFsIGNvbnRlbnQgYW5kIG1vZGlmeSB0aGUg UlRQIGhlYWRlci4NCg0KPg0KPiBJZiB0aGUgc3BsaWNlciBpcyBpbXBsZW1lbnRlZCBmb3IgdW5p Y2FzdCBzdHJlYW1pbmcsIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgbG9vcHMgY291bGQgcnVuIHRo ZSBSTUNBVCBhbGdvcml0aG1zLiBQZXJoYXBzIG1vcmUgbGlrZWx5LCB0aG91Z2gsIGlzIHRoYXQg dGhlIHNwbGljZXIgYWN0cyBvbiBhIG11bHRpY2FzdCAoU1NNKSBSVFAgZmxvdywgYW5kIHlvdSBo YXZlIHByb3Zpc2lvbmVkIGNhcGFjaXR5Lg0KPg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiAtDQo+PiBD T01NRU5UOg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiAtDQo+Pg0KPj4gLSBBcyBhIGdlbmVyYWwgY29t bWVudCwgSSBmb3VuZCBpdCBxdWl0ZSBoYXJkIHRvIHJlYWQgdGhpcyBkb2MgDQo+PiB3aXRob3V0 IHJlYWRpbmcgUkZDNjgyOCB3aGljaCBpcyBvbmx5IGxpc3RlZCBhcyBhIGluZm9ybWF0aXZlIA0K Pj4gcmVmZXJlbmNlIGFzIGl0IGlzIGluZm9ybWF0aW9uYWwgb25seS4gSSB0aGluayBpdCBpcyB3 cm9uZy4gRnVydGhlciwgDQo+PiBSRkM2ODI4IGRlc2NyaWJlcyBzb21lIGFjdGlvbiB0aGF0IGEg c2xpY2VycyBoYXMgdG8gcGVyZm9ybS4gSG93ZXZlciwgDQo+PiBhbGwgbGFuZ3VhZ2UgaW4gUkZD NjgyOCBpcyBub24gbm9ybWF0aXZlLiBUaGlzIGlzIHNsaWdodGx5IGNvbmZ1c2luZyANCj4+IHRv IG1lIGFzIHdlbGwuIEkgd291bGQgZnVydGhlciByZWNvbW1lbmQgdG8gYnJpZWZseSBnaXZlIGFu IG92ZXJ2aWV3IA0KPj4gb2YgdGhlIGFzc3VtZWQgc2NlbmFyaW8gaXMgdGhpcyBkb2N1bWVudC4N Cj4+DQo+PiAtIE1pbm9yIGNvbW1lbnQ6IFRoZSBkZWZpbml0aW9uIG9mIHRoZSBuZXcgU0RQIGdy b3VwaW5nIHNlbWFudGljIA0KPj4gc2hvdWxkIGJlIG1lbnRpb25lZCBpbiB0aGUgYWJzdHJhY3Qg YW5kIFJGQzQ1NjYgc2hvdWxkIGJlIHJlZmVyZW5jZWQuIA0KPj4gQW5kIEkgZG9uJ3QgdGhpbmsg dGhlIFNEUCBncm91cGluZyByZWdpc3RyeSByZXF1aXJlcyBhIGNvbnRhY3QuDQoNCltSYWNoZWxd OiBZZXMuIEknbGwgcmVtb3ZlIHRoZSBjb250YWN0Lg0KPj4NCj4+IC0gUXVpY2sgcXVlc3Rpb246 IE1heWJlIEknbSBtaXNzaW5nIHNvbWV0aGluZyBoZXJlIGJ1dCB3aHkgZG8geW91IA0KPj4gbmVl ZCBhIHNwbGljZXIgaW4gYSBzY2VuYXJpbyB3aGVyZSAidGhlDQo+PiAgICBzdWJzdGl0dXRpdmUg c2VuZGVyIGlzIGltcGxlbWVudGVkIHRvZ2V0aGVyIHdpdGggdGhlIG1haW4gUlRQIA0KPj4gc2Vu ZGVyIGluc2lkZSBhIHNpbmdsZSBkZXZpY2UiIChhcyB3cml0dGVuIGluIHNlY3Rpb24gMik/DQoN CltSYWNoZWxdOiBJbiBpbXBsZW1lbnRhdGlvbnMsIHNlcnZlcnMgbWF5IG5vdCBxdWl0ZSBiZSBj bG9zZSB0byBlbmQgdXNlcnMuIEZvciBhZHZlcnRpc2VtZW50IHNwbGljaW5nIGNhc2UsIHNvbWV0 aW1lcyBpdCdzIHRoZSBzcGxpY2VyJ3MgZGVjaXNpb24gdG8gY2hvb3NlIHdoaWNoIGtpbmQgb2Yg dXNlcnMgdG8gZm9yd2FyZCB0aGUgc3BsaWNlZCBjb250ZW50LCB3aGljaCBtZWFucyBkaWZmZXJl bnQgdXNlcnMgbWF5IGdldCBkaWZmZXJlbnQgc3BsaWNlZCBjb250ZW50Lg0KDQo+Pg0KPj4NCj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBhdnRl eHQgbWFpbGluZyBsaXN0DQo+PiBhdnRleHRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYXZ0ZXh0DQo+DQo+DQo+DQo= From nobody Wed Jun 15 00:54:12 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 1FD9412B037; Wed, 15 Jun 2016 00:54:12 -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 eqaF5nu8w4c2; Wed, 15 Jun 2016 00:54:10 -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 A2EC712B020; Wed, 15 Jun 2016 00:54:06 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-59-5761099cc231 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 88.BB.12926.C9901675; Wed, 15 Jun 2016 09:54:04 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.294.0; Wed, 15 Jun 2016 09:54:04 +0200 To: "Huangyihong (Rachel)" , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Colin Perkins References: <20160613125529.12490.86798.idtracker@ietfa.amsl.com> <65EAADDF-EE7F-414B-AF3F-45BA4B729500@csperkins.org> <57601B7E.3070208@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED634A@nkgeml513-mbx.china.huawei.com> From: Magnus Westerlund Message-ID: Date: Wed, 15 Jun 2016 09:54:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86ED634A@nkgeml513-mbx.china.huawei.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM2K7pe4czsRwgynHTS1e9qxkt2g/d4LF 4uO9G6wWy1+eYLTY8foVi8XxM+9YLV5c/8hssX/xeWaLpZ2n2B04Pabdv8/m0XLkLavHkiU/ mTxaPi5k9Wh7doc9gDWKyyYlNSezLLVI3y6BK2PVNO+CBtmKN0f+szQwThXvYuTkkBAwkdj+ 6ig7hC0mceHeerYuRi4OIYEjjBIr1+5ignCWM0q8/radHcQRFjjNKDHxcxMjiCMiMJlRYtX6 y+wQZS8YJX6+WA42gFlgP5PEuj3zmUEmswlYSNz80cgGYvMK2Ev8+v2ZBcRmEVCVuH73IBOI LSoQI9F4+zA7RI2gxMmZT4BqODg4BcIkNr2MBQkzA42ZOf88I4QtL9G8dTbYeCEBbYmGpg7W CYyCs5B0z0LSMgtJywJG5lWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgZFxcMtv1R2Ml984 HmIU4GBU4uFVcEsIF2JNLCuuzD3EKMHBrCTC68GaGC7Em5JYWZValB9fVJqTWnyIUZqDRUmc 1/+lYriQQHpiSWp2ampBahFMlomDU6qBMdPue236meWRUk+brrVlLGVWiJr4jSvq6dekw8uZ +1Nk0i7zpK8+2Z/vevfLr6JqsSNbnZYbcP/z/6YdnChoulp++vO2NfxzNmkUvdpmERXgVGMw 5U68u3BJbsCew5c60vxEwji/X+77rZXpP/92I5ejzfMjM6fvUbOe57XjPetE5TdnbANFlFiK MxINtZiLihMBrd1x34gCAAA= Archived-At: Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , draft-ietf-avtcore-rfc5285-bis@ietf.org, IETF AVTCore WG , "draft-ietf-avtext-splicing-notification@ietf.org" , "avtext-chairs@ietf.org" Subject: [avtext] =?utf-8?q?Additions_to_RFC5285bis=3F_was_Re=3A__Mirja_K?= =?utf-8?q?=C3=BChlewind=27s_Discuss_on_draft-ietf-avtext-splicing-notific?= =?utf-8?q?ation-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 15 Jun 2016 07:54:12 -0000 Hi, (As individual) I think we stumbled on one thing that maybe should be included in the update of RFC5285. Namely the discussion and reasoning why a sender may need to repeat a RTP header extension. See below excerpt from the discussion: Den 2016-06-15 kl. 09:22, skrev Huangyihong (Rachel): > Hi Mirja, > > As one of the authors, please see my replies inline. > > BR, Rachel > > -----邮件原件----- 发件人: Mirja Kühlewind [mailto:ietf@kuehlewind.net] 发送时 > >>> - Why is just having the RTCP message not sufficient? Why are the >>> RTP extensions needed as well? >> >> RTP and RTCP are unreliable. The usual practice for these types of >> extension is to send data both in RTCP, and in some number of RTP >> packets, to increase the chances of it arriving in a timely manner. >> The draft is following standard practice here. > > Thanks for clarification. That could be clarified in the text. > Because the text says that RTCP is used because the RTP information > might get lost. So I was wondering why you are not only using RTCP > and make sure you send it sufficiently often. Saying that this is > common practice would be helpful from my point of view. Is there a > reference for this? > > [Rachel]: It's more like conventional method to increase robustness. > As far as I know, there's no formal document to record this. Maybe we > can address this like this > > OLD " > > To increase robustness against such case, the document also defines > a complementary RTCP packet type to carry the same Splicing Interval > to the splicer. > > " > > NEW " To increase robustness against such case, the document also > defines a new RTCP packet type to carry the same Splicing Interval > to the splicer. Since RTCP is also unreliable and may not so > immediate as the in-band way, it's only considered as a complement to > RTP header extension. " > > >>> - And is the RTCP message send only once or multiple time? This >>> is not specified. >> >> That’s implementation dependent, and based on the expected packet >> loss rate, the importance of the data, and the frequency with which >> updates need to be sent. > > A recommendation or discussion should be provided here. > > [Rachel]: I think in Section 2, we have already provided some > guidance on how often the Splicing Interval to be sent, which is not > just limited to RTP header extension, also includes RTCP message. > This topic is also discussed in draft-ietf-avtext-sdes-hdr-ext-07 Section 4.2.3. From my perspective I think the general transmission issues that needs to be considered with RTP header extension should be included in the update of RFC5285. That way each extension don't have to repeat it, only discuss additions or specific considerations for their formats. To note I think that from SDES header Extension there should be included the topics of; - MTU handling - How many transmissions and if one can know it has reached the receiver - Update handling, especially for extensions with data that can be sent using both RTCP and RTP header extension. Note, this is my suggestion as an individual. Please discuss and comment. 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 Jun 15 06:08:06 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 C072712D616; Wed, 15 Jun 2016 06:08:01 -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 UFehBFrj8f3u; Wed, 15 Jun 2016 06:07:59 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F66312D648; Wed, 15 Jun 2016 06:07:59 -0700 (PDT) Received: from [130.209.157.40] (port=2156 helo=glaroam2-152-55.wireless.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 1bDAXw-0001A8-C5; Wed, 15 Jun 2016 14:07:53 +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, 15 Jun 2016 14:07:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0BA323FF-C204-43FC-9535-7F3918AEFA53@csperkins.org> References: <20160613125529.12490.86798.idtracker@ietfa.amsl.com> <65EAADDF-EE7F-414B-AF3F-45BA4B729500@csperkins.org> <57601B7E.3070208@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED634A@nkgeml513-mbx.china.huawei.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , draft-ietf-avtcore-rfc5285-bis@ietf.org, IETF AVTCore WG , "avtext-chairs@ietf.org" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , "draft-ietf-avtext-splicing-notification@ietf.org" Subject: Re: [avtext] =?utf-8?q?Additions_to_RFC5285bis=3F_was_Re=3A__Mirja_K?= =?utf-8?q?=C3=BChlewind=27s_Discuss_on_draft-ietf-avtext-splicing-notific?= =?utf-8?q?ation-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 15 Jun 2016 13:08:02 -0000 Hi Magnus, I agree that this makes sense, and is probably better than having more = general discussion in the splicing notification draft. Colin > On 15 Jun 2016, at 08:54, Magnus Westerlund = wrote: >=20 > Hi, > (As individual) >=20 > I think we stumbled on one thing that maybe should be included in the = update of RFC5285. >=20 > Namely the discussion and reasoning why a sender may need to repeat a = RTP header extension. See below excerpt from the discussion: >=20 > Den 2016-06-15 kl. 09:22, skrev Huangyihong (Rachel): >> Hi Mirja, >>=20 >> As one of the authors, please see my replies inline. >>=20 >> BR, Rachel >>=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA= =BA: Mirja K=C3=BChlewind [mailto:ietf@kuehlewind.net] =E5=8F=91=E9=80=81=E6= =97=B6 >=20 >>=20 >>>> - Why is just having the RTCP message not sufficient? Why are the >>>> RTP extensions needed as well? >>>=20 >>> RTP and RTCP are unreliable. The usual practice for these types of >>> extension is to send data both in RTCP, and in some number of RTP >>> packets, to increase the chances of it arriving in a timely manner. >>> The draft is following standard practice here. >>=20 >> Thanks for clarification. That could be clarified in the text. >> Because the text says that RTCP is used because the RTP information >> might get lost. So I was wondering why you are not only using RTCP >> and make sure you send it sufficiently often. Saying that this is >> common practice would be helpful from my point of view. Is there a >> reference for this? >>=20 >> [Rachel]: It's more like conventional method to increase robustness. >> As far as I know, there's no formal document to record this. Maybe we >> can address this like this >>=20 >> OLD " >>=20 >> To increase robustness against such case, the document also defines >> a complementary RTCP packet type to carry the same Splicing Interval >> to the splicer. >>=20 >> " >>=20 >> NEW " To increase robustness against such case, the document also >> defines a new RTCP packet type to carry the same Splicing Interval >> to the splicer. Since RTCP is also unreliable and may not so >> immediate as the in-band way, it's only considered as a complement to >> RTP header extension. " >>=20 >>=20 >>>> - And is the RTCP message send only once or multiple time? This >>>> is not specified. >>>=20 >>> That=E2=80=99s implementation dependent, and based on the expected = packet >>> loss rate, the importance of the data, and the frequency with which >>> updates need to be sent. >>=20 >> A recommendation or discussion should be provided here. >>=20 >> [Rachel]: I think in Section 2, we have already provided some >> guidance on how often the Splicing Interval to be sent, which is not >> just limited to RTP header extension, also includes RTCP message. >>=20 >=20 > This topic is also discussed in =09 > draft-ietf-avtext-sdes-hdr-ext-07 Section 4.2.3. >=20 > =46rom my perspective I think the general transmission issues that = needs to be considered with RTP header extension should be included in = the update of RFC5285. That way each extension don't have to repeat it, = only discuss additions or specific considerations for their formats. >=20 > To note I think that from SDES header Extension there should be = included the topics of; >=20 > - MTU handling > - How many transmissions and if one can know it has reached the = receiver > - Update handling, especially for extensions with data that can be = sent using both RTCP and RTP header extension. >=20 > Note, this is my suggestion as an individual. Please discuss and = comment. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 --=20 Colin Perkins https://csperkins.org/ From nobody Wed Jun 15 09:54: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 97B8A12D9E8 for ; Wed, 15 Jun 2016 09:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 ONESv-Z8P9yV for ; Wed, 15 Jun 2016 09:49:06 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A6F812D9DD for ; Wed, 15 Jun 2016 09:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1466009333; x=2329922933; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=g9xgH6GdJT3+HQJUyPSdDUD7X8vp7u8tJaKBZHdWmhM=; b=TRCj1+tbOCcPG5/7VCJLJnLjIYtcZvSTbAbXpI8Jbo9lHcI9I1RmqZNK8a9gzHOl aMK68XLA9sYwYfShviUFKsOcwCW417PjKW1wWZ2chyIB46WiF9/O9203Q8Qv5Z1u d/4jRW1mjNYKBBTzsH25bfU/M82wuwG7ygI6v50gG9uFKPoYooPdz3DpaW3yThnI XOSQ90UyiXPwEpuBA5Fm2QdI6zmEyg3CnFeegldKWgKlH5hLqv3WwzSsjbBBp8AP v967sLxePhZkKnXhN3q2G7ClS9yxploDvLKHuVLImGxNnMfsA1m8YQ1XBrKqvb86 bl0qr5xBLCBrTAF5ESpAyw==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 57.BE.25552.5F681675; Wed, 15 Jun 2016 09:48:53 -0700 (PDT) X-AuditID: 11973e16-f79bc6d0000063d0-48-576186f5eb18 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id FE.6C.29065.4F681675; Wed, 15 Jun 2016 09:48:52 -0700 (PDT) Received: from singda.apple.com (singda.apple.com [17.212.152.248]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O8T00CUJO1GFX40@nwk-mmpp-sz09.apple.com>; Wed, 15 Jun 2016 09:48:52 -0700 (PDT) Sender: singer@apple.com Content-type: multipart/alternative; boundary="Apple-Mail=_1D42522A-78DB-4517-920E-6B91C662F8C9" MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: David Singer In-reply-to: <0BA323FF-C204-43FC-9535-7F3918AEFA53@csperkins.org> Date: Wed, 15 Jun 2016 09:48:52 -0700 Message-id: <35E8DD48-11B4-43F3-8051-01DFC13D8AF8@apple.com> References: <20160613125529.12490.86798.idtracker@ietfa.amsl.com> <65EAADDF-EE7F-414B-AF3F-45BA4B729500@csperkins.org> <57601B7E.3070208@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED634A@nkgeml513-mbx.china.huawei.com> <0BA323FF-C204-43FC-9535-7F3918AEFA53@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUi2FAYofu1LTHcYN0jRouXPSvZLdrPnWCx +HjvBqvFjtevWCyOn3nH6sDqsWTJT6YAxigum5TUnMyy1CJ9uwSujJ/f5zEVrFvKWDG/8Shb A+PTPsYuRg4OCQETiVknwroYOYFMMYkL99azdTFycQgJ7GWU2LGkgx0iYSJx8eFuZhBbSGAZ k8TkD4oQRdOYJD7tvwKWEBaQkPj4cTILiM0skCTx818XE4jNK6AnMfloAxtEzStGidnNISA2 m4CqxIM5x8CO4BRwlFj0OwokzAIUXvxgJTvIfGaBx8wSf18eYYeYYyMx4eUsJojFV5kknu/a ArZABKhjx/F/jBCXyko8ObmIBaRIQuA6m8T+mZ9ZJzAKz0Jy1CwkR0HEtSWWLXzNDGFrSuzv Xs6CKa4h0fltIusCRrZVjEK5iZk5upl55nqJBQU5qXrJ+bmbGEHRM91ObAfjw1VWhxgFOBiV eHgl7BPChVgTy4orcw8xSnOwKInzevskhgsJpCeWpGanphakFsUXleakFh9iZOLglGpg7HYx XFWvNk962rYrry1qvrO7ulyPi7Zocz/2Sajz3HXmhlSruif65Ytn//ib9/HE58g5zh7TPMW+ cn9zFOjnrp0/+Zr+c4EU5Yi9Z3c/UZv7MX4x39d1q/6bLnr4/fy9Mk0dhhB3j8XGYW7X2g+a bXPvkvh/SJHR3Uzsa4/QKV4rs99nb6v/UWIpzkg01GIuKk4EAK9JTKh/AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOIsWRmVeSWpSXmKPExsUi2FAcoPulLTHcoPeImcXLnpXsFu3nTrBY fLx3g9Vix+tXLBbHz7xjdWD1WLLkJ1MAYxSXTUpqTmZZapG+XQJXxs/v85gK1i1lrJjfeJSt gfFpH2MXIyeHhICJxMWHu5khbDGJC/fWs4HYQgLLmCQmf1DsYuQCsqcxSXzafwWsSFhAQuLj x8ksIDazQJLEz39dTCA2r4CexOSjDWwQNa8YJWY3h4DYbAKqEg/mHANaxsHBKeAoseh3FEiY BSi8+MFKdpD5zAKPmSX+vjzCDjHHRmLCy1lMEIuvMkk837UFbIEIUMeO4/+grpaVeHJyEcsE RoFZSO6YheQOiLi2xLKFr5khbE2J/d3LWTDFNSQ6v01kXcDItopRoCg1J7HSVC+xoCAnVS85 P3cTIzjcCyN2MP5fZnWIUYCDUYmHt8AxIVyINbGsuDL3EKMEB7OSCO+P5sRwId6UxMqq1KL8 +KLSnNTiQ4wTGYH+nMgsJZqcD4zGvJJ4QxMTAxNjYzNjY3MTc1oKK4nzzvMGukggPbEkNTs1 tSC1COYoJg5OqQbGg0yfDlrxsdcE/3t2+d0N21yTqebTIx7//rYmS9OJ2+naTgv3N/M445Yd XWgjkubH6rZ6U5VHO78pD+frh7leenUHJXq7axv05l6+oz3na5NxuNejZ7L/AlTnvwrmtmLz SvUQOsYid1WtlYHT4sKVEsu0y13Ra9gs7iVd2F7w4ujhLzxC2xqVWIozEg21mIuKEwFOrDf9 6gIAAA== Archived-At: X-Mailman-Approved-At: Wed, 15 Jun 2016 09:54:43 -0700 Cc: "avtext@ietf.org" , draft-ietf-avtcore-rfc5285-bis@ietf.org, "jonathan@vidyo.com" , IETF AVTCore WG , "avtext-chairs@ietf.org" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , "draft-ietf-avtext-splicing-notification@ietf.org" Subject: Re: [avtext] =?utf-8?q?Additions_to_RFC5285bis=3F_was_Re=3A__Mirja_K?= =?utf-8?q?=C3=BChlewind=27s_Discuss_on_draft-ietf-avtext-splicing-notific?= =?utf-8?q?ation-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 15 Jun 2016 16:49:07 -0000 --Apple-Mail=_1D42522A-78DB-4517-920E-6B91C662F8C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Looks to me like we need to loot and pillage from at least the SDES = draft, and update (and split into sub-sections, as it=E2=80=99s already = long and a mix of topics) section 4.1 of 5285. Yes, a section on = repetition considerations and reliability seems reasonable to me. > On Jun 15, 2016, at 6:07 , Colin Perkins wrote: >=20 > Hi Magnus, >=20 > I agree that this makes sense, and is probably better than having more = general discussion in the splicing notification draft. >=20 > Colin >=20 >=20 >=20 >> On 15 Jun 2016, at 08:54, Magnus Westerlund = wrote: >>=20 >> Hi, >> (As individual) >>=20 >> I think we stumbled on one thing that maybe should be included in the = update of RFC5285. >>=20 >> Namely the discussion and reasoning why a sender may need to repeat a = RTP header extension. See below excerpt from the discussion: >>=20 >> Den 2016-06-15 kl. 09:22, skrev Huangyihong (Rachel): >>> Hi Mirja, >>>=20 >>> As one of the authors, please see my replies inline. >>>=20 >>> BR, Rachel >>>=20 >>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA= =BA: Mirja K=C3=BChlewind [mailto:ietf@kuehlewind.net] =E5=8F=91=E9=80=81=E6= =97=B6 >>=20 >>>=20 >>>>> - Why is just having the RTCP message not sufficient? Why are the >>>>> RTP extensions needed as well? >>>>=20 >>>> RTP and RTCP are unreliable. The usual practice for these types of >>>> extension is to send data both in RTCP, and in some number of RTP >>>> packets, to increase the chances of it arriving in a timely manner. >>>> The draft is following standard practice here. >>>=20 >>> Thanks for clarification. That could be clarified in the text. >>> Because the text says that RTCP is used because the RTP information >>> might get lost. So I was wondering why you are not only using RTCP >>> and make sure you send it sufficiently often. Saying that this is >>> common practice would be helpful from my point of view. Is there a >>> reference for this? >>>=20 >>> [Rachel]: It's more like conventional method to increase robustness. >>> As far as I know, there's no formal document to record this. Maybe = we >>> can address this like this >>>=20 >>> OLD " >>>=20 >>> To increase robustness against such case, the document also defines >>> a complementary RTCP packet type to carry the same Splicing Interval >>> to the splicer. >>>=20 >>> " >>>=20 >>> NEW " To increase robustness against such case, the document also >>> defines a new RTCP packet type to carry the same Splicing Interval >>> to the splicer. Since RTCP is also unreliable and may not so >>> immediate as the in-band way, it's only considered as a complement = to >>> RTP header extension. " >>>=20 >>>=20 >>>>> - And is the RTCP message send only once or multiple time? This >>>>> is not specified. >>>>=20 >>>> That=E2=80=99s implementation dependent, and based on the expected = packet >>>> loss rate, the importance of the data, and the frequency with which >>>> updates need to be sent. >>>=20 >>> A recommendation or discussion should be provided here. >>>=20 >>> [Rachel]: I think in Section 2, we have already provided some >>> guidance on how often the Splicing Interval to be sent, which is not >>> just limited to RTP header extension, also includes RTCP message. >>>=20 >>=20 >> This topic is also discussed in =09 >> draft-ietf-avtext-sdes-hdr-ext-07 Section 4.2.3. >>=20 >> =46rom my perspective I think the general transmission issues that = needs to be considered with RTP header extension should be included in = the update of RFC5285. That way each extension don't have to repeat it, = only discuss additions or specific considerations for their formats. >>=20 >> To note I think that from SDES header Extension there should be = included the topics of; >>=20 >> - MTU handling >> - How many transmissions and if one can know it has reached the = receiver >> - Update handling, especially for extensions with data that can be = sent using both RTCP and RTP header extension. >>=20 >> Note, this is my suggestion as an individual. Please discuss and = comment. >>=20 >> Cheers >>=20 >> Magnus Westerlund >>=20 >> = ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> = ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> = ---------------------------------------------------------------------- >>=20 >=20 >=20 >=20 > --=20 > Colin Perkins > https://csperkins.org/ David Singer Manager, Software Standards, Apple Inc. --Apple-Mail=_1D42522A-78DB-4517-920E-6B91C662F8C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Looks to me like we need to loot and pillage from at least = the SDES draft, and update (and split into sub-sections, as it=E2=80=99s = already long and a mix of topics) section 4.1 of 5285.  Yes, a = section on repetition considerations and reliability seems reasonable to = me.

On Jun 15, 2016, at 6:07 , Colin Perkins = <csp@csperkins.org> wrote:

Hi Magnus,

I agree that this makes sense, and is probably = better than having more general discussion in the splicing notification = draft.

Colin



On 15 Jun 2016, at 08:54, = Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Hi,
(As individual)

I think we stumbled on one thing that maybe should be = included in the update of RFC5285.

Namely = the discussion and reasoning why a sender may need to repeat a RTP = header extension. See below excerpt from the discussion:
Den 2016-06-15 kl. 09:22, skrev Huangyihong (Rachel):
Hi Mirja,

As one of the authors, please see my replies = inline.

BR, Rachel

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6= =E4=BA=BA: Mirja K=C3=BChlewind [mailto:ietf@kuehlewind.net] =E5=8F=91=E9=80=81=E6=97=B6


- Why is just having the RTCP message not = sufficient? Why are the
RTP extensions needed as well?

RTP and RTCP are unreliable. The = usual practice for these types of
extension is to send = data both in RTCP, and in some number of RTP
packets, to = increase the chances of it arriving in a timely manner.
The = draft is following standard practice here.

Thanks for clarification. That could be clarified in the = text.
Because the text says that RTCP is used because the = RTP information
might get lost. So I was wondering why you = are not only using RTCP
and make sure you send it = sufficiently often. Saying that this is
common practice = would be helpful from my point of view. Is there a
reference= for this?

[Rachel]: It's more like = conventional method to increase robustness.
As far as I = know, there's no formal document to record this. Maybe we
can address this like this

OLD = "

To increase robustness against such case, = the document also defines
a complementary RTCP packet type = to carry the same Splicing Interval
to the splicer.

"

NEW " To = increase robustness against such case, the document also
defines a new RTCP packet type to carry the same Splicing = Interval
to the splicer. Since RTCP is also unreliable and = may not so
immediate as the in-band way, it's only = considered as a complement to
RTP header extension. "


- And is the RTCP = message send only once or multiple time? This
is not = specified.

That=E2=80=99s = implementation dependent, and based on the expected packet
loss rate, the importance of the data, and the frequency with = which
updates need to be sent.

A recommendation or discussion = should be provided here.

[Rachel]: I think = in Section 2, we have already provided some
guidance on = how often the Splicing Interval to be sent, which is not
just limited to RTP header extension, also includes RTCP = message.


This = topic is also discussed in  
draft-ietf-avtext-sdes-hdr-ext-07 Section 4.2.3.

=46rom my perspective I think the general = transmission issues that needs to be considered with RTP header = extension should be included in the update of RFC5285. That way each = extension don't have to repeat it, only discuss additions or specific = considerations for their formats.

To note I = think that from SDES header Extension there should be included the = topics of;

- MTU handling
- = How many transmissions and if one can know it has reached the = receiver
- Update handling, especially for extensions with = data that can be sent using both RTCP and RTP header extension.

Note, this is my suggestion as an individual. = Please discuss and comment.

Cheers

Magnus Westerlund

---------------------------------------------------------------= -------
Services, Media and Network features, Ericsson = Research EAB/TXM
---------------------------------------------------------------= -------
Ericsson AB =             &n= bsp;   | Phone  +46 10 7148287
F=C3=A4r=C3=B6gatan 6 =             &n= bsp;   | Mobile +46 73 0949079
SE-164 80 = Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
---------------------------------------------------------------= -------




-- 
Colin = Perkins
https://csperkins.org/

David Singer
Manager, Software Standards, Apple = Inc.

= --Apple-Mail=_1D42522A-78DB-4517-920E-6B91C662F8C9-- From nobody Wed Jun 15 10:41: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 0D24512DA80; Wed, 15 Jun 2016 10:41: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 30szUuT7n4Zb; Wed, 15 Jun 2016 10:41:39 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 CB3F312DA77; Wed, 15 Jun 2016 10:41:36 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id q132so22961410lfe.3; Wed, 15 Jun 2016 10:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:thread-index :content-language; bh=UKYsWWlZ1UDFnNP1M7Axa9RHnwdiwVQL8sJ8pSZo9jU=; b=VUn6wUBiYXh3u+aH1LoGWDR0PRi/4lD939Cr1I3U3XK4zfQSJ/YD1hO5tPC5Th+o/P 3vNs3AzghpLykPiovqmEo1YJXRCNwkiLsKD3wq7rhF1Yy9qN5GL1NZ4k4AWrtkS3UYfM lalf/04LHivcNCuriBJNvPJUnQcRxgLEKyNMAU8RN4xqdfZEbQuzBCSOVsof+ka4W3Zy LrCTOONN3mW9aSkvmMhvTjbEOqOcylhuA0PPcq2gbDPqisWPsZZNsa5TrhHCs/phdZu1 6BPxRsVbB0BCmKEhQY4bTzJ1TVjD5xq4rlnDYhLokh84aVoGDV2HjNFrvAX9Wh4cRXYP vCDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :thread-index:content-language; bh=UKYsWWlZ1UDFnNP1M7Axa9RHnwdiwVQL8sJ8pSZo9jU=; b=A0EEqDjQEqsZKybwN778GQlxgO9J86Mbu1Hsm4heyshjIKheAjCVFTrBoavbDHvvYU vSI5s1WBy9eU2UC5UkM9xduEVs7XA+Nw/wYqF67A0LIe5BVpun3/X+bRV/fYKYisBQSR FIMhrI34ma2wVf5mjITQ9BRocx7C/mgFVc4fwUfIh4wdaEZTiA3PsephYV9PVGNap+Tg BIyAw7tFWpfl6k09MDYevHorfvcT+elSR4ri5+ECK0SH+0T7PVIVT2d/E4VSLDK3oN8b Nhy5/6bmlfdAb1rqv0OtZyPYlZkMi4yWeJBIKv38mg+7ImTBmHisK6Q5csC/bLGROxl2 f3OQ== X-Gm-Message-State: ALyK8tKVtzodZ4E3BOFoH6uLWfu1Kbhh1bIwPmzslPNgHUzyc9w6/jojMxcqGcjaZt9n0g== X-Received: by 10.28.29.146 with SMTP id d140mr496883wmd.27.1466012494909; Wed, 15 Jun 2016 10:41:34 -0700 (PDT) Received: from RoniPC (bzq-79-179-194-235.red.bezeqint.net. [79.179.194.235]) by smtp.gmail.com with ESMTPSA id bu7sm1468796wjc.42.2016.06.15.10.41.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Jun 2016 10:41:33 -0700 (PDT) From: "Roni Even" To: "'Colin Perkins'" , "Magnus Westerlund" Date: Wed, 15 Jun 2016 20:40:10 +0300 Message-ID: <0eea01d1c72c$f8c566f0$ea5034d0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0EEB_01D1C746.1E1473B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdHHLLimIaSZYyvFSfuqTiYcYJL0+A== Content-Language: he Archived-At: Cc: jonathan@vidyo.com, avtext@ietf.org, draft-ietf-avtcore-rfc5285-bis@ietf.org, avt@ietf.org, 'David Singer' Subject: Re: [avtext] Additions to RFC5285bis? 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, 15 Jun 2016 17:41:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0EEB_01D1C746.1E1473B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, (I removed some of the recipients =E2=80=93 discuss in avtcore) =20 As David Singer pointed out draft-ietf-avtext-sdes-hdr-ext section 4.2.3 = discuss the transmission considerations for RTP header extensions. So do you think we can that this text is the relevant one for = RFC5285-bis to discuss why and when to repeat sending RTP header = extensions since one of the difference between RFC5285 and the bis draft = is that we acknowledge that delivery of RTP header extension is crucial. =20 I also agree that it will be good to split section 4.1=20 =20 Roni =20 =20 From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of David Singer Sent: Wednesday, June 15, 2016 7:49 PM To: Colin Perkins Cc: avtext@ietf.org; draft-ietf-avtcore-rfc5285-bis@ietf.org; = jonathan@vidyo.com; IETF AVTCore WG; avtext-chairs@ietf.org; Mirja = K=C3=BChlewind; draft-ietf-avtext-splicing-notification@ietf.org Subject: Re: [avtext] Additions to RFC5285bis? was Re: Mirja = K=C3=BChlewind's Discuss on draft-ietf-avtext-splicing-notification-07: = (with DISCUSS and COMMENT) =20 Looks to me like we need to loot and pillage from at least the SDES = draft, and update (and split into sub-sections, as it=E2=80=99s already = long and a mix of topics) section 4.1 of 5285. Yes, a section on = repetition considerations and reliability seems reasonable to me. =20 On Jun 15, 2016, at 6:07 , Colin Perkins wrote: =20 Hi Magnus, I agree that this makes sense, and is probably better than having more = general discussion in the splicing notification draft. Colin On 15 Jun 2016, at 08:54, Magnus Westerlund = wrote: Hi, (As individual) I think we stumbled on one thing that maybe should be included in the = update of RFC5285. Namely the discussion and reasoning why a sender may need to repeat a = RTP header extension. See below excerpt from the discussion: Den 2016-06-15 kl. 09:22, skrev Huangyihong (Rachel): Hi Mirja, As one of the authors, please see my replies inline. BR, Rachel -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- = =E5=8F=91=E4=BB=B6=E4=BA=BA: Mirja K=C3=BChlewind = [mailto:ietf@kuehlewind.net] =E5=8F=91=E9=80=81=E6=97=B6 - Why is just having the RTCP message not sufficient? Why are the RTP extensions needed as well? RTP and RTCP are unreliable. The usual practice for these types of extension is to send data both in RTCP, and in some number of RTP packets, to increase the chances of it arriving in a timely manner. The draft is following standard practice here. Thanks for clarification. That could be clarified in the text. Because the text says that RTCP is used because the RTP information might get lost. So I was wondering why you are not only using RTCP and make sure you send it sufficiently often. Saying that this is common practice would be helpful from my point of view. Is there a reference for this? [Rachel]: It's more like conventional method to increase robustness. As far as I know, there's no formal document to record this. Maybe we can address this like this OLD " To increase robustness against such case, the document also defines a complementary RTCP packet type to carry the same Splicing Interval to the splicer. " NEW " To increase robustness against such case, the document also defines a new RTCP packet type to carry the same Splicing Interval to the splicer. Since RTCP is also unreliable and may not so immediate as the in-band way, it's only considered as a complement to RTP header extension. " - And is the RTCP message send only once or multiple time? This is not specified. That=E2=80=99s implementation dependent, and based on the expected = packet loss rate, the importance of the data, and the frequency with which updates need to be sent. A recommendation or discussion should be provided here. [Rachel]: I think in Section 2, we have already provided some guidance on how often the Splicing Interval to be sent, which is not just limited to RTP header extension, also includes RTCP message. This topic is also discussed in =20 draft-ietf-avtext-sdes-hdr-ext-07 Section 4.2.3. >From my perspective I think the general transmission issues that needs = to be considered with RTP header extension should be included in the = update of RFC5285. That way each extension don't have to repeat it, only = discuss additions or specific considerations for their formats. To note I think that from SDES header Extension there should be included = the topics of; - MTU handling - How many transmissions and if one can know it has reached the receiver - Update handling, especially for extensions with data that can be sent = using both RTCP and RTP header extension. Note, this is my suggestion as an individual. Please discuss and = comment. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=20 Colin Perkins https://csperkins.org/ =20 David Singer Manager, Software Standards, Apple Inc. =20 ------=_NextPart_000_0EEB_01D1C746.1E1473B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

(I removed some of the recipients =E2=80=93 discuss in = avtcore)

 

As David Singer pointed out draft-ietf-avtext-sdes-hdr-ext section = 4.2.3 discuss the transmission considerations for RTP header = extensions.

So do you think we can that this text is the relevant one for = RFC5285-bis to discuss why and when to repeat sending RTP header = extensions since one of the difference between RFC5285 and the bis draft = is that we acknowledge that delivery of RTP header extension is = crucial.

 

I also agree that it will be good to split section 4.1 =

 

Roni

 

 

From:= = avtext [mailto:avtext-bounces@ietf.org] On Behalf Of David = Singer
Sent: Wednesday, June 15, 2016 7:49 PM
To: = Colin Perkins
Cc: avtext@ietf.org; = draft-ietf-avtcore-rfc5285-bis@ietf.org; jonathan@vidyo.com; IETF = AVTCore WG; avtext-chairs@ietf.org; Mirja K=C3=BChlewind; = draft-ietf-avtext-splicing-notification@ietf.org
Subject: Re: = [avtext] Additions to RFC5285bis? was Re: Mirja K=C3=BChlewind's Discuss = on draft-ietf-avtext-splicing-notification-07: (with DISCUSS and = COMMENT)

 

Looks to me = like we need to loot and pillage from at least the SDES draft, and = update (and split into sub-sections, as it=E2=80=99s already long and a = mix of topics) section 4.1 of 5285.  Yes, a section on repetition = considerations and reliability seems reasonable to = me.

 

On Jun 15, 2016, at 6:07 , Colin Perkins <csp@csperkins.org> = wrote:

 

Hi = Magnus,

I agree that this makes sense, and is probably better = than having more general discussion in the splicing notification = draft.

Colin




On 15 Jun = 2016, at 08:54, Magnus Westerlund <magnus.westerlund@ericsson= .com> wrote:

Hi,
(As individual)

I think we = stumbled on one thing that maybe should be included in the update of = RFC5285.

Namely the discussion and reasoning why a sender may = need to repeat a RTP header extension. See below excerpt from the = discussion:

Den 2016-06-15 kl. 09:22, skrev Huangyihong = (Rachel):

Hi = Mirja,

As one of the authors, please see my replies = inline.

BR, Rachel

-----=E9=82=AE=E4=BB=B6=E5=8E=9F= =E4=BB=B6----- = =E5=8F=91=E4=BB=B6=E4=BA=BA= : Mirja = K=C3=BChlewind [mailto:ietf@kuehlewind.net] = =E5=8F=91=E9=80=81=E6=97=B6=





- Why is = just having the RTCP message not sufficient? Why are the
RTP = extensions needed as well?


RTP = and RTCP are unreliable. The usual practice for these types = of
extension is to send data both in RTCP, and in some number of = RTP
packets, to increase the chances of it arriving in a timely = manner.
The draft is following standard practice = here.


Thanks= for clarification. That could be clarified in the text.
Because the = text says that RTCP is used because the RTP information
might get = lost. So I was wondering why you are not only using RTCP
and make = sure you send it sufficiently often. Saying that this is
common = practice would be helpful from my point of view. Is there a
reference = for this?

[Rachel]: It's more like conventional method to = increase robustness.
As far as I know, there's no formal document to = record this. Maybe we
can address this like this

OLD = "

To increase robustness against such case, the document = also defines
a complementary RTCP packet type to carry the same = Splicing Interval
to the splicer.

"

NEW " To = increase robustness against such case, the document also
defines a = new RTCP packet type to carry the same Splicing Interval
to the = splicer. Since RTCP is also unreliable and may not so
immediate as = the in-band way, it's only considered as a complement to
RTP header = extension. "



- And is = the RTCP message send only once or multiple time? This
is not = specified.


That=E2= =80=99s implementation dependent, and based on the expected = packet
loss rate, the importance of the data, and the frequency with = which
updates need to be sent.


A = recommendation or discussion should be provided here.

[Rachel]: I = think in Section 2, we have already provided some
guidance on how = often the Splicing Interval to be sent, which is not
just limited to = RTP header extension, also includes RTCP = message.


This = topic is also discussed in  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
draft-ietf-avtext-sdes-hdr-ext-07 Section 4.2.3.

From = my perspective I think the general transmission issues that needs to be = considered with RTP header extension should be included in the update of = RFC5285. That way each extension don't have to repeat it, only discuss = additions or specific considerations for their formats.

To note I = think that from SDES header Extension there should be included the = topics of;

- MTU handling
- How many transmissions and if one = can know it has reached the receiver
- Update handling, especially = for extensions with data that can be sent using both RTCP and RTP header = extension.

Note, this is my suggestion as an individual. Please = discuss and comment.

Cheers

Magnus = Westerlund

-------------------------------------------------------= ---------------
Services, Media and Network features, Ericsson = Research = EAB/TXM
--------------------------------------------------------------= --------
Ericsson AB =             &= nbsp;   | Phone  +46 10 = 7148287
F=C3=A4r=C3=B6gatan 6 =             &= nbsp;   | Mobile +46 73 0949079
SE-164 80 Stockholm, = Sweden | mailto: magnus.westerlund@ericsson= .com
-------------------------------------------------------------= ---------



-- 
Colin = Perkins
https://cs= perkins.org/

 

David Singer

Manager, Software Standards, Apple = Inc.

 

------=_NextPart_000_0EEB_01D1C746.1E1473B0-- From nobody Wed Jun 15 11:37:40 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 38F0B12D636; Wed, 15 Jun 2016 11:37:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2016 11:37:34 -0700 Archived-At: Cc: draft-ietf-avtext-splicing-notification@ietf.org, avtext@ietf.org, jonathan@vidyo.com, avtext-chairs@ietf.org Subject: [avtext] Kathleen Moriarty's No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 18:37:34 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-avtext-splicing-notification-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I strongly support Mirja's and Alia's discuss points and would like to see more of a discussion of the capability to hide splicing in the security considerations text. My ballot would be discuss, but they pulled out the relevant sections and that would be duplication. I'd like to review agreed upon text though to address these concerns. I don't like the idea of enabling a MiTM, but do see the draft talks about how to protect headers when this happens and confidentiality is needed as well as session protection between the endpoints and the splicer (which I don't like either, but you do call out the security considerations of this and that's what is needed). From nobody Wed Jun 15 12:24:29 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 8FFEF12DB1A; Wed, 15 Jun 2016 12:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 dR6YxGEvLdej; Wed, 15 Jun 2016 12:24:22 -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 59B5512DB19; Wed, 15 Jun 2016 12:24:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMA26415; Wed, 15 Jun 2016 19:24:17 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 15 Jun 2016 20:24:16 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 16 Jun 2016 03:24:07 +0800 From: "Huangyihong (Rachel)" To: Colin Perkins , Magnus Westerlund Thread-Topic: =?utf-8?B?YWRkdGlvbnMgdG8gUkZDNTI4NWJpcz8gd2FzIFJlOiBbYXZ0ZXh0XSBNaXJq?= =?utf-8?B?YSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWF2dGV4dC1z?= =?utf-8?B?cGxpY2luZy1ub3RpZmljYXRpb24tMDc6ICh3aXRoIERJU0NVU1MgYW5kIENP?= =?utf-8?Q?MMENT)?= Thread-Index: AQHRxzt7n+4YqUlweUqhjscGtJ6bPg== Date: Wed, 15 Jun 2016 19:24:06 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86ED6560@nkgeml513-mbx.china.huawei.com> References: <20160613125529.12490.86798.idtracker@ietfa.amsl.com> <65EAADDF-EE7F-414B-AF3F-45BA4B729500@csperkins.org> <57601B7E.3070208@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED634A@nkgeml513-mbx.china.huawei.com> <0BA323FF-C204-43FC-9535-7F3918AEFA53@csperkins.org> In-Reply-To: <0BA323FF-C204-43FC-9535-7F3918AEFA53@csperkins.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.92.47] 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.5761AB62.003B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b1f1bf5c2bd6760e465c079503c95b9f Archived-At: Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "draft-ietf-avtcore-rfc5285-bis@ietf.org" , IETF AVTCore WG , "avtext-chairs@ietf.org" , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , "draft-ietf-avtext-splicing-notification@ietf.org" Subject: Re: [avtext] =?utf-8?q?addtions_to_RFC5285bis=3F_was_Re=3A__Mirja_K?= =?utf-8?q?=C3=BChlewind=27s_Discuss_on_draft-ietf-avtext-splicing-notific?= =?utf-8?q?ation-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 15 Jun 2016 19:24:24 -0000 SSB0b3RhbGx5IGFncmVlIHdpdGggdGhpcyBhcHByb2FjaC4gV2UgZG9u4oCZdCBuZWVkIGVhY2gg c3BlY2lmaWMgUlRQIGhlYWRlciBleHRlbnNpb24gZHJhZnQgdG8gcmVwZWF0ZWRseSBkaXNjdXNz IGEgY29tbW9uIGlzc3VlLg0KDQpCUiwNClJhY2hlbA0KIA0KDQotLS0tLemCruS7tuWOn+S7ti0t LS0tDQrlj5Hku7bkuro6IENvbGluIFBlcmtpbnMgW21haWx0bzpjc3BAY3NwZXJraW5zLm9yZ10g DQrlj5HpgIHml7bpl7Q6IDIwMTblubQ25pyIMTXml6UgMjE6MDgNCuaUtuS7tuS6ujogTWFnbnVz IFdlc3Rlcmx1bmQNCuaKhOmAgTogSHVhbmd5aWhvbmcgKFJhY2hlbCk7IE1pcmphIEvDvGhsZXdp bmQ7IGF2dGV4dC1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5v dGlmaWNhdGlvbkBpZXRmLm9yZzsgYXZ0ZXh0QGlldGYub3JnOyBqb25hdGhhbkB2aWR5by5jb207 IElFVEYgQVZUQ29yZSBXRzsgZHJhZnQtaWV0Zi1hdnRjb3JlLXJmYzUyODUtYmlzQGlldGYub3Jn DQrkuLvpopg6IFJlOiBBZGRpdGlvbnMgdG8gUkZDNTI4NWJpcz8gd2FzIFJlOiBbYXZ0ZXh0XSBN aXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWF2dGV4dC1zcGxpY2luZy1u b3RpZmljYXRpb24tMDc6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQoNCkhpIE1hZ251cywN Cg0KSSBhZ3JlZSB0aGF0IHRoaXMgbWFrZXMgc2Vuc2UsIGFuZCBpcyBwcm9iYWJseSBiZXR0ZXIg dGhhbiBoYXZpbmcgbW9yZSBnZW5lcmFsIGRpc2N1c3Npb24gaW4gdGhlIHNwbGljaW5nIG5vdGlm aWNhdGlvbiBkcmFmdC4NCg0KQ29saW4NCg0KDQoNCj4gT24gMTUgSnVuIDIwMTYsIGF0IDA4OjU0 LCBNYWdudXMgV2VzdGVybHVuZCA8bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPiB3cm90 ZToNCj4gDQo+IEhpLA0KPiAoQXMgaW5kaXZpZHVhbCkNCj4gDQo+IEkgdGhpbmsgd2Ugc3R1bWJs ZWQgb24gb25lIHRoaW5nIHRoYXQgbWF5YmUgc2hvdWxkIGJlIGluY2x1ZGVkIGluIHRoZSB1cGRh dGUgb2YgUkZDNTI4NS4NCj4gDQo+IE5hbWVseSB0aGUgZGlzY3Vzc2lvbiBhbmQgcmVhc29uaW5n IHdoeSBhIHNlbmRlciBtYXkgbmVlZCB0byByZXBlYXQgYSBSVFAgaGVhZGVyIGV4dGVuc2lvbi4g U2VlIGJlbG93IGV4Y2VycHQgZnJvbSB0aGUgZGlzY3Vzc2lvbjoNCj4gDQo+IERlbiAyMDE2LTA2 LTE1IGtsLiAwOToyMiwgc2tyZXYgSHVhbmd5aWhvbmcgKFJhY2hlbCk6DQo+PiBIaSBNaXJqYSwN Cj4+IA0KPj4gQXMgb25lIG9mIHRoZSBhdXRob3JzLCBwbGVhc2Ugc2VlIG15IHJlcGxpZXMgaW5s aW5lLg0KPj4gDQo+PiBCUiwgUmFjaGVsDQo+PiANCj4+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0g 5Y+R5Lu25Lq6OiBNaXJqYSBLw7xobGV3aW5kIFttYWlsdG86aWV0ZkBrdWVobGV3aW5kLm5ldF0g 5Y+R6YCB5pe2DQo+IA0KPj4gDQo+Pj4+IC0gV2h5IGlzIGp1c3QgaGF2aW5nIHRoZSBSVENQIG1l c3NhZ2Ugbm90IHN1ZmZpY2llbnQ/IFdoeSBhcmUgdGhlIA0KPj4+PiBSVFAgZXh0ZW5zaW9ucyBu ZWVkZWQgYXMgd2VsbD8NCj4+PiANCj4+PiBSVFAgYW5kIFJUQ1AgYXJlIHVucmVsaWFibGUuIFRo ZSB1c3VhbCBwcmFjdGljZSBmb3IgdGhlc2UgdHlwZXMgb2YgDQo+Pj4gZXh0ZW5zaW9uIGlzIHRv IHNlbmQgZGF0YSBib3RoIGluIFJUQ1AsIGFuZCBpbiBzb21lIG51bWJlciBvZiBSVFAgDQo+Pj4g cGFja2V0cywgdG8gaW5jcmVhc2UgdGhlIGNoYW5jZXMgb2YgaXQgYXJyaXZpbmcgaW4gYSB0aW1l bHkgbWFubmVyLg0KPj4+IFRoZSBkcmFmdCBpcyBmb2xsb3dpbmcgc3RhbmRhcmQgcHJhY3RpY2Ug aGVyZS4NCj4+IA0KPj4gVGhhbmtzIGZvciBjbGFyaWZpY2F0aW9uLiBUaGF0IGNvdWxkIGJlIGNs YXJpZmllZCBpbiB0aGUgdGV4dC4NCj4+IEJlY2F1c2UgdGhlIHRleHQgc2F5cyB0aGF0IFJUQ1Ag aXMgdXNlZCBiZWNhdXNlIHRoZSBSVFAgaW5mb3JtYXRpb24gDQo+PiBtaWdodCBnZXQgbG9zdC4g U28gSSB3YXMgd29uZGVyaW5nIHdoeSB5b3UgYXJlIG5vdCBvbmx5IHVzaW5nIFJUQ1AgDQo+PiBh bmQgbWFrZSBzdXJlIHlvdSBzZW5kIGl0IHN1ZmZpY2llbnRseSBvZnRlbi4gU2F5aW5nIHRoYXQg dGhpcyBpcyANCj4+IGNvbW1vbiBwcmFjdGljZSB3b3VsZCBiZSBoZWxwZnVsIGZyb20gbXkgcG9p bnQgb2Ygdmlldy4gSXMgdGhlcmUgYSANCj4+IHJlZmVyZW5jZSBmb3IgdGhpcz8NCj4+IA0KPj4g W1JhY2hlbF06IEl0J3MgbW9yZSBsaWtlIGNvbnZlbnRpb25hbCBtZXRob2QgdG8gaW5jcmVhc2Ug cm9idXN0bmVzcy4NCj4+IEFzIGZhciBhcyBJIGtub3csIHRoZXJlJ3Mgbm8gZm9ybWFsIGRvY3Vt ZW50IHRvIHJlY29yZCB0aGlzLiBNYXliZSB3ZSANCj4+IGNhbiBhZGRyZXNzIHRoaXMgbGlrZSB0 aGlzDQo+PiANCj4+IE9MRCAiDQo+PiANCj4+IFRvIGluY3JlYXNlIHJvYnVzdG5lc3MgYWdhaW5z dCBzdWNoIGNhc2UsIHRoZSBkb2N1bWVudCBhbHNvIGRlZmluZXMgYSANCj4+IGNvbXBsZW1lbnRh cnkgUlRDUCBwYWNrZXQgdHlwZSB0byBjYXJyeSB0aGUgc2FtZSBTcGxpY2luZyBJbnRlcnZhbCB0 byANCj4+IHRoZSBzcGxpY2VyLg0KPj4gDQo+PiAiDQo+PiANCj4+IE5FVyAiIFRvIGluY3JlYXNl IHJvYnVzdG5lc3MgYWdhaW5zdCBzdWNoIGNhc2UsIHRoZSBkb2N1bWVudCBhbHNvIA0KPj4gZGVm aW5lcyBhIG5ldyBSVENQIHBhY2tldCB0eXBlIHRvIGNhcnJ5IHRoZSBzYW1lIFNwbGljaW5nIElu dGVydmFsIHRvIA0KPj4gdGhlIHNwbGljZXIuIFNpbmNlIFJUQ1AgaXMgYWxzbyB1bnJlbGlhYmxl IGFuZCBtYXkgbm90IHNvIGltbWVkaWF0ZSANCj4+IGFzIHRoZSBpbi1iYW5kIHdheSwgaXQncyBv bmx5IGNvbnNpZGVyZWQgYXMgYSBjb21wbGVtZW50IHRvIFJUUCANCj4+IGhlYWRlciBleHRlbnNp b24uICINCj4+IA0KPj4gDQo+Pj4+IC0gQW5kIGlzIHRoZSBSVENQIG1lc3NhZ2Ugc2VuZCBvbmx5 IG9uY2Ugb3IgbXVsdGlwbGUgdGltZT8gVGhpcyBpcyANCj4+Pj4gbm90IHNwZWNpZmllZC4NCj4+ PiANCj4+PiBUaGF04oCZcyBpbXBsZW1lbnRhdGlvbiBkZXBlbmRlbnQsIGFuZCBiYXNlZCBvbiB0 aGUgZXhwZWN0ZWQgcGFja2V0IA0KPj4+IGxvc3MgcmF0ZSwgdGhlIGltcG9ydGFuY2Ugb2YgdGhl IGRhdGEsIGFuZCB0aGUgZnJlcXVlbmN5IHdpdGggd2hpY2ggDQo+Pj4gdXBkYXRlcyBuZWVkIHRv IGJlIHNlbnQuDQo+PiANCj4+IEEgcmVjb21tZW5kYXRpb24gb3IgZGlzY3Vzc2lvbiBzaG91bGQg YmUgcHJvdmlkZWQgaGVyZS4NCj4+IA0KPj4gW1JhY2hlbF06IEkgdGhpbmsgaW4gU2VjdGlvbiAy LCB3ZSBoYXZlIGFscmVhZHkgcHJvdmlkZWQgc29tZSANCj4+IGd1aWRhbmNlIG9uIGhvdyBvZnRl biB0aGUgU3BsaWNpbmcgSW50ZXJ2YWwgdG8gYmUgc2VudCwgd2hpY2ggaXMgbm90IA0KPj4ganVz dCBsaW1pdGVkIHRvIFJUUCBoZWFkZXIgZXh0ZW5zaW9uLCBhbHNvIGluY2x1ZGVzIFJUQ1AgbWVz c2FnZS4NCj4+IA0KPiANCj4gVGhpcyB0b3BpYyBpcyBhbHNvIGRpc2N1c3NlZCBpbiAgCQ0KPiBk cmFmdC1pZXRmLWF2dGV4dC1zZGVzLWhkci1leHQtMDcgU2VjdGlvbiA0LjIuMy4NCj4gDQo+IEZy b20gbXkgcGVyc3BlY3RpdmUgSSB0aGluayB0aGUgZ2VuZXJhbCB0cmFuc21pc3Npb24gaXNzdWVz IHRoYXQgbmVlZHMgdG8gYmUgY29uc2lkZXJlZCB3aXRoIFJUUCBoZWFkZXIgZXh0ZW5zaW9uIHNo b3VsZCBiZSBpbmNsdWRlZCBpbiB0aGUgdXBkYXRlIG9mIFJGQzUyODUuIFRoYXQgd2F5IGVhY2gg ZXh0ZW5zaW9uIGRvbid0IGhhdmUgdG8gcmVwZWF0IGl0LCBvbmx5IGRpc2N1c3MgYWRkaXRpb25z IG9yIHNwZWNpZmljIGNvbnNpZGVyYXRpb25zIGZvciB0aGVpciBmb3JtYXRzLg0KPiANCj4gVG8g bm90ZSBJIHRoaW5rIHRoYXQgZnJvbSBTREVTIGhlYWRlciBFeHRlbnNpb24gdGhlcmUgc2hvdWxk IGJlIA0KPiBpbmNsdWRlZCB0aGUgdG9waWNzIG9mOw0KPiANCj4gLSBNVFUgaGFuZGxpbmcNCj4g LSBIb3cgbWFueSB0cmFuc21pc3Npb25zIGFuZCBpZiBvbmUgY2FuIGtub3cgaXQgaGFzIHJlYWNo ZWQgdGhlIA0KPiByZWNlaXZlcg0KPiAtIFVwZGF0ZSBoYW5kbGluZywgZXNwZWNpYWxseSBmb3Ig ZXh0ZW5zaW9ucyB3aXRoIGRhdGEgdGhhdCBjYW4gYmUgc2VudCB1c2luZyBib3RoIFJUQ1AgYW5k IFJUUCBoZWFkZXIgZXh0ZW5zaW9uLg0KPiANCj4gTm90ZSwgdGhpcyBpcyBteSBzdWdnZXN0aW9u IGFzIGFuIGluZGl2aWR1YWwuIFBsZWFzZSBkaXNjdXNzIGFuZCBjb21tZW50Lg0KPiANCj4gQ2hl ZXJzDQo+IA0KPiBNYWdudXMgV2VzdGVybHVuZA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBTZXJ2 aWNlcywgTWVkaWEgYW5kIE5ldHdvcmsgZmVhdHVyZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVBQi9U WE0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBFcmljc3NvbiBBQiAgICAgICAgICAgICAgICAgfCBQaG9u ZSAgKzQ2IDEwIDcxNDgyODcNCj4gRsOkcsO2Z2F0YW4gNiAgICAgICAgICAgICAgICAgfCBNb2Jp bGUgKzQ2IDczIDA5NDkwNzkNCj4gU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuIHwgbWFpbHRv OiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCg0K DQoNCi0tDQpDb2xpbiBQZXJraW5zDQpodHRwczovL2NzcGVya2lucy5vcmcvDQoNCg0KDQoNCg== From nobody Wed Jun 15 12:45:53 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 D04C912DB31; Wed, 15 Jun 2016 12:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 bguhiuR7q_AD; Wed, 15 Jun 2016 12:45: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 1378212DB59; Wed, 15 Jun 2016 12:45:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMA28104; Wed, 15 Jun 2016 19:45:36 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 15 Jun 2016 20:45:35 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 16 Jun 2016 03:45:31 +0800 From: "Huangyihong (Rachel)" To: Alissa Cooper , The IESG Thread-Topic: Alissa Cooper's No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT) Thread-Index: AQHRxnJX1qlwdj/5d0ytJlTWc1T4HZ/q6rcQ Date: Wed, 15 Jun 2016 19:45:31 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86ED6597@nkgeml513-mbx.china.huawei.com> References: <20160614192411.19187.22192.idtracker@ietfa.amsl.com> In-Reply-To: <20160614192411.19187.22192.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.92.47] 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.0A090206.5761B060.0077, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6bfd8513bdc373fe85f13b3a52e0b4dd Archived-At: Cc: "draft-ietf-avtext-splicing-notification@ietf.org" , "avtext@ietf.org" , "jonathan@vidyo.com" , "avtext-chairs@ietf.org" Subject: Re: [avtext] Alissa Cooper's No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT) 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, 15 Jun 2016 19:45:46 -0000 SGkgQWxpc3NhLA0KDQpUaGFuayB5b3UgZm9yIHRoZSBjb21tZW50cy4gUGxlYXNlIHNlZSBteSBy ZXBsaWVzIGlubGluZS4NCg0KQlIsDQpSYWNoZWwsIGFzIG9uZSBvZiB0aGUgYXV0aG9ycy4NCg0K LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBBbGlzc2EgQ29vcGVyIFttYWlsdG86 YWxpc3NhQGNvb3BlcncuaW5dIA0K5Y+R6YCB5pe26Ze0OiAyMDE25bm0NuaciDE15pelIDM6MjQN CuaUtuS7tuS6ujogVGhlIElFU0cNCuaKhOmAgTogZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmct bm90aWZpY2F0aW9uQGlldGYub3JnOyBhdnRleHQtY2hhaXJzQGlldGYub3JnOyBqb25hdGhhbkB2 aWR5by5jb207IGF2dGV4dEBpZXRmLm9yZw0K5Li76aKYOiBBbGlzc2EgQ29vcGVyJ3MgTm8gT2Jq ZWN0aW9uIG9uIGRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0wNzogKHdp dGggQ09NTUVOVCkNCg0KQWxpc3NhIENvb3BlciBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJh bGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlv bi0wNzogTm8gT2JqZWN0aW9uDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1 YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVk ZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1 Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQpmb3IgbW9y ZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0K DQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4g YmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi8NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNP TU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCj0gU2VjdGlvbiA0ID0NCg0KIkVpdGhlciB0aGUgbWFp biBSVFAgc2VuZGVyIG9yIHRoZQ0KICAgc3Vic3RpdHV0aXZlIHNlbmRlciBTSE9VTEQgc2VuZCB0 aGUgc3luY2hyb25pemF0aW9uIG1ldGFkYXRhIGVhcmx5DQogICBlbm91Z2ggc28gdGhhdCB0aGUg cmVjZWl2ZXJzIGNhbiBwbGF5IG91dCB0aGUgbXVsdGltZWRpYSBpbiBhDQogICBzeW5jaHJvbml6 ZWQgZmFzaGlvbi4iDQoNCkluIFNlY3Rpb24gMiB5b3UgZ2F2ZSBhIGd1aWRlbGluZSBmb3IgaG93 IHRvIGZpZ3VyZSBvdXQgaG93IGZhciBpbiBhZHZhbmNlIHRvIHNlbmQgdGhlIHNwbGljaW5nIGlu Zm9ybWF0aW9uLiBJIHRoaW5rIGEgc2ltaWxhciBndWlkZWxpbmUgd291bGQgYmUgdXNlZnVsIGhl cmUuIA0KDQpbUmFjaGVsXTogR29vZCBwb2ludC4gSSBhZ3JlZS4gU28gSSBzdWdnZXN0IHRvIGFk ZCBmb2xsb3dpbmcgc2VudGVuY2VzIGFmdGVyIHRoZSB3b3JkcyB5b3UgcXVvdGVkLg0KDQoiVGhl IG1haW4gUlRQIHNlbmRlciBvciB0aGUgc3Vic3RpdHV0aXZlIHNlbmRlciBjYW4gZXN0aW1hdGUg d2hlbiB0byBzZW5kIHRoZSBzeW5jaHJvbml6YXRpb24gbWV0YWRhdGEgYmFzZWQgb24sIGZvciBl eGFtcGxlLCB0aGUgcm91bmQtdHJpcCB0aW1lIChSVFQpIGZvbGxvd2luZyB0aGUNCiBtZWNoYW5p c21zIGluIHNlY3Rpb24gNi40LjEgb2YgW1JGQzM1NTBdIHdoZW4gdGhlIHNwbGljZXIgc2VuZHMg UlRDUCBSUiB0byB0aGUgbWFpbiBzZW5kZXIgb3IgdGhlIHN1YnN0aXR1dGl2ZSBzZW5kZXIuDQoi DQoNCnMvZS5nLiwgY2hvb3NpbmcgbWVkaWEgc2VuZGVyL2UuZy4sIGNob29zaW5nIG1haW4gUlRQ IHNlbmRlci8NCg0KW1JhY2hlbF06IE9rYXkuDQoNCj0gU2VjdGlvbiA3ID0NCg0KV2hhdCBpcyB1 bmRldGVjdGFibGUgc3BsaWNpbmc/DQoNCltSYWNoZWxdOiBVbmRldGVjdGFibGUgc3BsaWNpbmcg bWVhbnMgdGhhdCB0aGUgUlRQIHJlY2VpdmVycyBzaG91bGQgbm90IGJlIGFibGUgdG8gZGV0ZWN0 IGFueSBzcGxpY2luZyBwb2ludHMgaW4gdGhlIFJUUCBsYXllci4gSXQgaXMgcmVxdWlyZWQgaW4g c29tZSBjYXNlcywgZm9yIGV4YW1wbGUsIGFuIElQVFYgYWR2ZXJ0aXNlbWVudCB1c2VyIGNhc2Us IHRoZSBzZXJ2aWNlIHByb3ZpZGVyIG1heSB3YW50IHRvIG1ha2UgaXQgZGlmZmljdWx0IGZvciB0 aGUgUlRQIHJlY2VpdmVyIHRvIGRldGVjdCB3aGVyZSBhbiBhZHZlcnRpc2VtZW50IGluc2VydGlv biBpcyBzdGFydGluZyBvciBlbmRpbmcgZnJvbSB0aGUgUlRQIHBhY2tldHMsIGFuZCB0aHVzIGF2 b2lkaW5nIHRoZSBSVFAgcmVjZWl2ZXIgZnJvbSBmaWx0ZXJpbmcgb3V0IHRoZSBhZHZlcnRpc2Vt ZW50IGNvbnRlbnQuDQoNCj0gU2VjdGlvbiA4LjMgPQ0KDQpJbiB0aGUgcGFzdCB3aGVuIHdlJ3Zl IHJlZ2lzdGVyZWQgdGhlc2UgdGhlcmUgd2FzIG5vIGNvbnRhY3QgSSBkb24ndCB0aGluay4gTm90 IHN1cmUgd2hhdCBJQU5BIHdvdWxkIGRvIHdpdGggb25lIGhlcmUuDQoNCltSYWNoZWxdOiBXZSds bCByZW1vdmUgdGhlIGNvbnRhY3QuDQo= From nobody Wed Jun 15 13:16: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 3897012DB9B; Wed, 15 Jun 2016 13:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 U0rw05yCfWib; Wed, 15 Jun 2016 13:15:59 -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 8B27D12DB96; Wed, 15 Jun 2016 13:15:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMA30498; Wed, 15 Jun 2016 20:15:54 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 15 Jun 2016 21:15:53 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Thu, 16 Jun 2016 04:15:47 +0800 From: "Huangyihong (Rachel)" To: Alia Atlas , The IESG Thread-Topic: Alia Atlas' Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS) Thread-Index: AQHRxogNMIC5GX2r/keO4gNcrie7K5/q8Iaw Date: Wed, 15 Jun 2016 20:15:47 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86ED65D5@nkgeml513-mbx.china.huawei.com> References: <20160614215932.31629.25074.idtracker@ietfa.amsl.com> In-Reply-To: <20160614215932.31629.25074.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.92.47] 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.0A020206.5761B77B.0329, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 15535bd2981de6cbb58904da55713efa Archived-At: Cc: "draft-ietf-avtext-splicing-notification@ietf.org" , "avtext@ietf.org" , "jonathan@vidyo.com" , "avtext-chairs@ietf.org" Subject: Re: [avtext] Alia Atlas' Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS) 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, 15 Jun 2016 20:16:01 -0000 SGkgQWxpYSwNCg0KVGhhbmsgeW91IGZvciByYWlzaW5nIHRoZSBjb25jZXJucy4gUGxlYXNlIHNl ZSBteSByZXBsaWVzIGlubGluZS4NCg0KUmFjaGVsLCBhcyBvbmUgb2YgdGhlIGF1dGhvci4NCg0K LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBBbGlhIEF0bGFzIFttYWlsdG86YWth dGxhc0BnbWFpbC5jb21dIA0K5Y+R6YCB5pe26Ze0OiAyMDE25bm0NuaciDE15pelIDY6MDANCuaU tuS7tuS6ujogVGhlIElFU0cNCuaKhOmAgTogZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmctbm90 aWZpY2F0aW9uQGlldGYub3JnOyBhdnRleHQtY2hhaXJzQGlldGYub3JnOyBqb25hdGhhbkB2aWR5 by5jb207IGF2dGV4dEBpZXRmLm9yZw0K5Li76aKYOiBBbGlhIEF0bGFzJyBEaXNjdXNzIG9uIGRy YWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0wNzogKHdpdGggRElTQ1VTUykN Cg0KQWxpYSBBdGxhcyBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBm b3INCmRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0wNzogRGlzY3Vzcw0K DQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFu ZCByZXBseSB0byBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0Mg bGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93 ZXZlci4pDQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3Rh dGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQg SUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpUaGUgZG9jdW1lbnQsIGFs b25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWF2dGV4dC1zcGxpY2luZy1u b3RpZmljYXRpb24vDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpESVNDVVNTOg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpJIGJlbGlldmUgdGhpcyBpcyBtb3JlICBhIGRpc2N1c3Npb24gZm9yIHRoZSBJRVNHLg0K DQpGaXJzdCwgdGhpcyBpcyB3YXkgb3V0IG9mIG15IGFyZWEgYW5kIEknbSBub3QgcGFydGljdWxh cmx5IGNvbW1lbnRpbmcgb24gdGhlIGRldGFpbHMgLSBidXQgSSBkbyBhZ3JlZSB3aXRoIE1pcmph J3MgZGlzY3VzcyBhYm91dA0KIi0gVGhlIGZvbGxvd2luZyBhY3Rpb24gZG9lcyBub3Qgc2VlbSB0 byBiZSBhcHByb3ByaWF0ZSBmb3IgYSBzcGVjaWZpY2F0aW9uIG9mIGFuIGVuZC10by1lbmQgcHJv dG9jb2w6DQoiQW5kIGlmIHRoZSBzcGxpY2VyIHdpc2hlcyB0byBwcmV2ZW50IHRoZSBkb3duc3Ry ZWFtIHJlY2VpdmVycyBmcm9tIGRldGVjdGluZyBzcGxpY2luZywgaXQgTVVTVA0KICAgTk9UIGZv cndhcmQgdGhlIG1lc3NhZ2UuIiINCg0KW1JhY2hlbF06IFRoaXMgaXMgbm90IGEgZW5kLXRvLWVu ZCBwcm90b2NvbC4gVGhlc2UgZXh0ZW5kZWQgbWVzc2FnZXMgYXJlIGludGVuZGVkIHRvIHNlbmQg dG8gdGhlIHNwbGljZXIsIHdoaWNoIGlzIHRoZSBtaWRkbGUgYm94IGV4cGVjdGVkIHRvIGJlIGFi bGUgdG8gbW9kaWZ5IFJUQ1AgbWVzc2FnZXMuIERpc2NhcmRpbmcgb3IgbW9kaWZ5aW5nIFJUQ1Ag cGFja2V0cyB0aGF0IGRvbuKAmXQgbWFrZSBzZW5zZSBmb3Igc29tZSBwYXJ0aWNpcGFudHMgaXMg bm9ybWFsIGJlaGF2aW91ciBmb3IgUlRQIG1pZGRsZSBib3hlcy4gSSB1bmRlcnN0YW5kIHRoZSBt b3JtYXRpdmUgbGFuZ3VhZ2UgaXMga2luZCBvZiBjb25mdXNpbmcgaGVyZS4gV2UnbGwgcmVtb3Zl IHRoZSBub3JtYXRpdmUgbGFuZ3VhZ2UuDQoNClRoZSBmdWxsIHBhcmFncmFwaCBhdCB0aGUgZW5k IG9mIFNlYyAzLjIgaXM6ICJXaGVuIHRoZSBzcGxpY2VyIGludGVyY2VwdHMgdGhlIFJUQ1Agc3Bs aWNpbmcgbm90aWZpY2F0aW9uIG1lc3NhZ2UsDQogICBpdCBTSE9VTEQgTk9UIGZvcndhcmQgdGhl IG1lc3NhZ2UgdG8gdGhlIGRvd24tc3RyZWFtIHJlY2VpdmVycyBpbg0KICAgb3JkZXIgdG8gcmVk dWNlIFJUQ1AgYmFuZHdpZHRoIGNvbnN1bXB0aW9uLiBBbmQgaWYgdGhlIHNwbGljZXIgd2lzaGVz DQogICB0byBwcmV2ZW50IHRoZSBkb3duc3RyZWFtIHJlY2VpdmVycyBmcm9tIGRldGVjdGluZyBz cGxpY2luZywgaXQgTVVTVA0KICAgTk9UIGZvcndhcmQgdGhlIG1lc3NhZ2UuIg0KDQpFdmVuIG1v cmUgc3BlY2lmaWNhbGx5IHRvIG1lLCBzdXBlcmZpY2lhbGx5IHRoaXMgc2VlbXMgdG8gbWUgdG8g YmUgYSB3YXkgdG8gY2hhbmdlIHdoYXQgaXMgaW4gdGhlIHN0cmVhbSB0aGF0IGEgcmVjZWl2ZXIg aGFzIHJlcXVlc3RlZCBvciBzdWJzY3JpYmVkIHRvIHdpdGhvdXQgcGVybWlzc2lvbg0Kb3Igbm90 aWZpY2F0aW9uLiAgIEluIHRoYXQgbGlnaHQsDQp0aGUgaWRlYSB0aGF0IHRoZSBzcGxpY2VyIGlz IGFibGUgdG8gcHJldmVudCBkb3duc3RyZWFtIHJlY2VpdmVycyBmcm9tIGRldGVjdGluZyB0aGUg c3BsaWNpbmcgZG9lcyBub3Qgc291bmQgZ29vZC4NCg0KW1JhY2hlbF06IEFzIEkgc2FpZCwgdGhp cyBtZXNzYWdlIGlzIHN1cHBvc2VkIHRvIHNlbmQgdG8gdGhlIHNwbGljZXIsIG5vdCB0aGUgcmVj ZWl2ZXJzIG9mIHRoZSBlbmQgdXNlci4gV2hlbiB0aGUgc3BsaWNlciByZWNlaXZlcyBzdWNoIG1l c3NhZ2VzLCBpdCdsbCBkbyB0aGUgc3BsaWNpbmcgYWN0aXZpdHksIHdoaWNoIGlzIHRvIHVzZSB0 aGUgc3Vic3RpdHV0aXZlIGNvbnRlbnQgcmVwbGFjZSB0aGUgb3JpZ2luYWwgY29udGVudC4gV2hl biBzcGxpY2luZyBpbnRlcnZhbCBlbmRzLCB0aGUgc3BsaWNlciB3aWxsIGNoYW5nZSBpdCBiYWNr LiBJdCdzIHVzdWFsbHkgdXNlZCBmb3IgYWR2ZXJ0aXNlbWVudCBpbnNlcnRpb24uICBJIGRvIGZp bmQgdGhlIHdvcmQgImludGVyY2VwdHMiIGhlcmUgaXMgaW1wcm9wZXIgYW5kIGNvbmZ1c2luZy4g SG93IGFib3V0IHVzaW5nICJyZWNlaXZlcyI/DQoNClNpbWlsYXJseSwgdGhlIGVuZCBvZiBTZWMg My4xIHNheXMgIkFmdGVyIHRoZSBzcGxpY2VyIGludGVyY2VwdHMgdGhlIFJUUCBoZWFkZXIgZXh0 ZW5zaW9uIGFuZCBkZXJpdmVzIHRoZQ0KICAgU3BsaWNpbmcgSW50ZXJ2YWwsIGl0IHdpbGwgZ2Vu ZXJhdGUgaXRzIG93biBzdHJlYW0gYW5kIFNIT1VMRCBOT1QNCiAgIGluY2x1ZGUgdGhlIFJUUCBo ZWFkZXIgZXh0ZW5zaW9uIGluIG91dGdvaW5nIHBhY2tldHMgdG8gcmVkdWNlIGhlYWRlcg0KICAg b3ZlcmhlYWQuIg0KDQpUaGlzIGxvb2tzIGxpa2UgYW5vdGhlciBleGFtcGxlIG9mIG1ha2luZyB0 aGUgY2hvaWNlIHRvIGhpZGUgaW5mb3JtYXRpb24gZnJvbSB0aGUgcmVjZWl2ZXIuDQoNCltSYWNo ZWxdOiBQbGVhc2Ugc2VlIGFib3ZlLg0KDQpJIHJlYWxpemUgdGhhdCB0aGVyZSBpcyBwcm9iYWJs eSBhbiB0ZWNobmljYWwgYXJtcy1yYWNlIGdvaW5nIG9uIC0gb2YgaW5zZXJ0aW5nIGFkdmVydGlz ZW1lbnRzIGFuZCBidWlsZGluZyByZWNlaXZlcnMgdG8gYmxvY2sgdW5kZXNpcmVkIGFkdmVydGlz ZW1lbnRzLiAgSSBhbSAgbm90IHNlZWluZyBhIGJhbGFuY2VkIHNvbHV0aW9uIHRoYXQgY29uc2lk ZXJzIHRoZSByZWNlaXZlcnMgYXMgd2VsbCBhcyB0aGUgc2VuZGVycy4NCg0KW1JhY2hlbF06IE9u IHRoZSBjb250cmFyeSwgaXQncyBhIG1ldGhvZCB1c2VkIGluIElQVFYgc2VydmljZXMsIHRoYXQg c2VydmljZSBwcm92aWRlciBpbnNlcnRzIGRpZmZlcmVudCBhZHZlcnRpc2VtZW50cyB0byBkaWZm ZXJlbnQgdXNlcnMuIEl0J3MgdG90YWxseSBub3QgYmxvY2tpbmcgb3IgaGlkaW5nIHNvbWV0aGlu Zy4gU29tZXRpbWUgdGhlIHNlcnZpY2UgcHJvdmlkZXIgZG9uJ3Qgd2FudCB0aGUgZW5kIHVzZXJz IHRvIGRldGVjdCB0aGUgYWR2ZXJ0aXNlbWVudCBpbnNlcnRpbmcuIFRoYXQncyB3aHkgdGhlIHNw bGljaW5nIGludGVydmFsIGFyZSBub3QgZm9yd2FyZGVkIHRvIHRoZSByZWNlaXZlcnMuDQoNCkkg YW0gc3RhcnRsZWQgdGhhdCB0aGVyZSBpcyBubyBjb25zaWRlcmF0aW9uIG9mIHRoZSBpbXBhY3Qg b2YgdGhpcyBleHRlbnNpb24gb24gdGhlIHJlY2VpdmVycyBpbiB0aGUgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMuDQoNClRoZSBvbmx5IHJlZmVyZW5jZSBJIHNlZSBpbiB0aGUgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgZnVydGhlciBhc3N1bWVzIHRoYXQgaXQgaXMgYXBwcm9wcmlhdGUgdG8gaGF2 ZSBhbiB1bmRldGVjdGFibGUgc3BsaWNpbmcuDQoNCiIgQSBtYWxpY2lvdXMgZW5kcG9pbnQgbWF5 IGFsc28gYnJlYWsgYW4gdW5kZXRlY3RhYmxlIHNwbGljaW5nLiBUbw0KICAgbWl0aWdhdGUgdGhp cyBlZmZlY3QsIHRoZSBzcGxpY2VyIFNIT1VMRCBOT1QgZm9yd2FyZCB0aGUgc3BsaWNpbmcNCiAg IHRpbWUgaW5mb3JtYXRpb24gUlRQIGhlYWRlciBleHRlbnNpb24gZGVmaW5lZCBpbiBTZWN0aW9u IDQuMSB0byB0aGUNCiAgIHJlY2VpdmVycy4gQW5kIGl0IE1VU1QgTk9UIGZvcndhcmQgdGhpcyBo ZWFkZXIgZXh0ZW5zaW9uIHdoZW4NCiAgIGNvbnNpZGVyaW5nIGFuIHVuZGV0ZWN0YWJsZSBzcGxp Y2luZy4gIg0KDQpBdCBhIG1pbmltdW0sIEkgZmVlbCBsaWtlIHRoZXJlIHNob3VsZCBiZSBhIHZl cnkgY2xlYXIgY29uc2lkZXJhdGlvbiBvZiB0aGUgcHJvcyBhbmQgY29ucyAtIGluY2x1ZGluZyBm cm9tIHRoZSB2aWV3cG9pbnQgb2YgYSByZWNlaXZlci4gDQoNCklmIHdlIGVuZCB1cCB3aXRoIHRo aXMgYmlhc2VkIHRlY2hub2xvZ3ksIHRoZW4gaXQgc2hvdWxkIGJlIGNsZWFybHkgc3RhdGVkDQot IG5vdCBoaWRkZW4gaW4gYXNzdW1wdGlvbnMuDQoNCg0KDQoNCg== From nobody Wed Jun 15 16:16:06 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 7E49A12D932; Wed, 15 Jun 2016 16:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 hbAwm_DoKnWQ; Wed, 15 Jun 2016 16:16:02 -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 9DD7B12D834; Wed, 15 Jun 2016 16:16:02 -0700 (PDT) Received: from [81.187.2.149] (port=38307 helo=[192.168.0.91]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bDJOV-00075T-0K; Wed, 15 Jun 2016 23:34:43 +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: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2016 23:34:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: avtext-chairs@ietf.org, draft-ietf-avtext-splicing-notification@ietf.org, avtext@ietf.org, The IESG , jonathan@vidyo.com Subject: Re: [avtext] Kathleen Moriarty's No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT) 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, 15 Jun 2016 23:16:04 -0000 > On 15 Jun 2016, at 19:37, Kathleen Moriarty = wrote: >=20 > Kathleen Moriarty has entered the following ballot position for > draft-ietf-avtext-splicing-notification-07: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I strongly support Mirja's and Alia's discuss points and would like to > see more of a discussion of the capability to hide splicing in the > security considerations text. My ballot would be discuss, but they > pulled out the relevant sections and that would be duplication. I'd = like > to review agreed upon text though to address these concerns. =20 >=20 > I don't like the idea of enabling a MiTM, but do see the draft talks > about how to protect headers when this happens and confidentiality is > needed as well as session protection between the endpoints and the > splicer (which I don't like either, but you do call out the security > considerations of this and that's what is needed). The mechanism described doesn=E2=80=99t work unless the receiver = explicitly chooses to receive media content delivered via the splicer. I = agree that the draft could be more clearly written, but it doesn=E2=80=99t= seem to be =E2=80=9Cenabling a MiTM=E2=80=9D attack, since the receiver = opts in. --=20 Colin Perkins https://csperkins.org/ From nobody Wed Jun 15 16:17:37 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C37512D7EA; Wed, 15 Jun 2016 16:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=Kx+Z5Qpe; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=s5DX//kK 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 YNydSfibRbET; Wed, 15 Jun 2016 16:17:28 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5837012D699; Wed, 15 Jun 2016 16:17:28 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4F95320172; Wed, 15 Jun 2016 19:17:27 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 15 Jun 2016 19:17:27 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=vnznrNpyOZa2BTjIyM1BhwRUVZ0=; b=Kx+Z5Q pe3gP5uCe0fvVPIRU+XtJmGeFTfPDECd4FDhqIK0hP2+RaN4UIqbZoPac6/TBn5d QWc9O0DSPF2UFVHtz5PnkhC0A3I2sVfBlFFDvyOIIOhHHxXV+y5SKWGUFtAA1bTv g3WiTEBdx5EW0nnOY85RB2VepvwaFJWCSrhBU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=vnznrNpyOZa2BTj IyM1BhwRUVZ0=; b=s5DX//kK5yjqQ/CpsC4PDZPT7HzAj9J635ochqUE04WCCaR OJXB2MS7kvJwVSmLCgZ+QE6o1mbVUxi4N1jLh7Fn7dUSrNPi0q6goEqOiPwbOMAF 5FdquatVtZLiFB8RJJjVc1xFokz2F+ZcwUhsklzFbKID55BnsH65rRBcO448= X-Sasl-enc: 7qoxtBngIX+Rz8mi/ZmZQ2obyJxt6b4qYEf3fBMqWJU+ 1466032646 Received: from dhcp-171-68-21-47.cisco.com (dhcp-171-68-21-47.cisco.com [171.68.21.47]) by mail.messagingengine.com (Postfix) with ESMTPA id 758D0F29FA; Wed, 15 Jun 2016 19:17:26 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20160614215932.31629.25074.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2016 16:17:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1E7F244A-2045-48E5-B817-7B87D6E5B094@cooperw.in> References: <20160614215932.31629.25074.idtracker@ietfa.amsl.com> To: Alia Atlas X-Mailer: Apple Mail (2.3124) Archived-At: Cc: avtext-chairs@ietf.org, draft-ietf-avtext-splicing-notification@ietf.org, avtext@ietf.org, IESG , Jonathan Lennox Subject: Re: [avtext] Alia Atlas' Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS) 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, 15 Jun 2016 23:17:31 -0000 A couple of thoughts here: - RTP middleboxes do all kinds of things to cleartext media that they = receive. Of course people have realized the security drawbacks of this, = which is why we have developed security technologies designed to prevent = media manipulation and why we have other WGs working on extending that = model to conferencing and defining best practices for how to secure = media end-to-end. - I agree that the MUST NOT forward language is ill-advised, and it=E2=80=99= s also unnecessary. But even if this document said MUST forward, there = is nothing in the protocol semantics that would require implementations = to do that, so I imagine that splicers that do not want to forward this = information (whether to prevent detection or to reduce overhead) won=E2=80= =99t forward it. Similarly, I would imagine that at least some of the = payload-specific mechanisms used for this purpose have the same = property, so even if systems rely on those mechanisms rather than RTP = because the RTP spec says MUST forward, there is no guarantee that the = splicing information will reach the receiver. Alissa > On Jun 14, 2016, at 2:59 PM, Alia Atlas wrote: >=20 > Alia Atlas has entered the following ballot position for > draft-ietf-avtext-splicing-notification-07: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I believe this is more a discussion for the IESG. >=20 > First, this is way out of my area and I'm not particularly commenting = on > the details - but=20 > I do agree with Mirja's discuss about > "- The following action does not seem to be appropriate for a > specification of an end-to-end protocol: > "And if the splicer wishes to prevent the downstream receivers from > detecting splicing, it MUST > NOT forward the message."" >=20 > The full paragraph at the end of Sec 3.2 is: "When the splicer = intercepts > the RTCP splicing notification message, > it SHOULD NOT forward the message to the down-stream receivers in > order to reduce RTCP bandwidth consumption. And if the splicer = wishes > to prevent the downstream receivers from detecting splicing, it MUST > NOT forward the message." >=20 > Even more specifically to me, superficially this seems to me to be a = way > to change what is in the > stream that a receiver has requested or subscribed to without = permission > or notification. In that light, > the idea that the splicer is able to prevent downstream receivers from > detecting the splicing does > not sound good. >=20 > Similarly, the end of Sec 3.1 says "After the splicer intercepts the = RTP > header extension and derives the > Splicing Interval, it will generate its own stream and SHOULD NOT > include the RTP header extension in outgoing packets to reduce = header > overhead." >=20 > This looks like another example of making the choice to hide = information > from the receiver. >=20 > I realize that there is probably an technical arms-race going on - of > inserting advertisements and > building receivers to block undesired advertisements. I am not = seeing a > balanced solution that > considers the receivers as well as the senders. >=20 > I am startled that there is no consideration of the impact of this > extension on the receivers=20 > in the security considerations. >=20 > The only reference I see in the Security Considerations further = assumes > that it is appropriate to have an undetectable splicing. >=20 > " A malicious endpoint may also break an undetectable splicing. To > mitigate this effect, the splicer SHOULD NOT forward the splicing > time information RTP header extension defined in Section 4.1 to the > receivers. And it MUST NOT forward this header extension when > considering an undetectable splicing. " >=20 > At a minimum, I feel like there should be a very clear consideration = of > the > pros and cons - including from the viewpoint of a receiver.=20 >=20 > If we end up with this biased technology, then it should be clearly > stated > - not hidden in assumptions. >=20 >=20 >=20 >=20 From nobody Wed Jun 15 17:25:26 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 E711C12DB7C; Wed, 15 Jun 2016 17:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=unavailable 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 ivZT8MQecFB3; Wed, 15 Jun 2016 17:25:22 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAFF812DA3C; Wed, 15 Jun 2016 17:25:22 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5G0PCWp033087 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 15 Jun 2016 19:25:13 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: Huangyihong Date: Wed, 15 Jun 2016 19:25:19 -0500 Message-ID: <61F2E237-E6D9-472A-84FB-49EBA6EDC7A8@nostrum.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86ED6597@nkgeml513-mbx.china.huawei.com> References: <20160614192411.19187.22192.idtracker@ietfa.amsl.com> <51E6A56BD6A85142B9D172C87FC3ABBB86ED6597@nkgeml513-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" Subject: Re: [avtext] Alissa Cooper's No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT) 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, 16 Jun 2016 00:25:24 -0000 On 15 Jun 2016, at 14:45, Huangyihong (Rachel) wrote: > What is undetectable splicing? > > [Rachel]: Undetectable splicing means that the RTP receivers should > not be able to detect any splicing points in the RTP layer. It is > required in some cases, for example, an IPTV advertisement user case, > the service provider may want to make it difficult for the RTP > receiver to detect where an advertisement insertion is starting or > ending from the RTP packets, and thus avoiding the RTP receiver from > filtering out the advertisement content. Since several people have expressed concerns here, I wonder if it would be helpful to have some text about trust and content models. I _think_ that the typical use case will be one where the splicer is operating on behalf of the content provider. In that case, one could think of the post-splicing RTP stream as the the final content being provided. One could reasonably argue that the knowledge of how that stream was composed is private to the provider, and not the business of the final recipient. On the other hand, a splicer that does not operate on behalf or (or at least with the permission of) of the content provider or recipient would be egregious, even if it did not hide the splicing interval data. From nobody Wed Jun 15 23:40:49 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 4818F12D548; Wed, 15 Jun 2016 23:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 Mbod_XNfc9aD; Wed, 15 Jun 2016 23:40:46 -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 818D612B026; Wed, 15 Jun 2016 23:40:45 -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 CMA84764; Thu, 16 Jun 2016 06:40:43 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 16 Jun 2016 07:40:42 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 16 Jun 2016 14:40:34 +0800 From: "Huangyihong (Rachel)" To: Ben Campbell Thread-Topic: Alissa Cooper's No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT) Thread-Index: AQHRxnJX1qlwdj/5d0ytJlTWc1T4HZ/q6rcQ///NZ4CAAOp7kA== Date: Thu, 16 Jun 2016 06:40:34 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86ED6715@nkgeml513-mbx.china.huawei.com> References: <20160614192411.19187.22192.idtracker@ietfa.amsl.com> <51E6A56BD6A85142B9D172C87FC3ABBB86ED6597@nkgeml513-mbx.china.huawei.com> <61F2E237-E6D9-472A-84FB-49EBA6EDC7A8@nostrum.com> In-Reply-To: <61F2E237-E6D9-472A-84FB-49EBA6EDC7A8@nostrum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.93.84] 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.0A020201.576249EC.002B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6bfd8513bdc373fe85f13b3a52e0b4dd Archived-At: Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" Subject: Re: [avtext] Alissa Cooper's No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT) 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, 16 Jun 2016 06:40:48 -0000 SGkgQmVuLA0KDQpJdCBzZWVtcyB3ZSBkbyBsYWNrIHN1Y2ggY2xhcmlmaWNhdGlvbnMgaW4gdGhl IGRyYWZ0LCB3aGljaCBtYXkgbGVhZCB0byBzb21lIG1pc3VuZGVyc3RhbmRpbmcuIFdlJ2xsIGFk ZHJlc3MgdGhpcyBpbiB0aGUgdXBkYXRlZCB2ZXJzaW9uLiBUaGFua3MuDQoNCkJSLA0KUmFjaGVs DQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBCZW4gQ2FtcGJlbGwgW21haWx0bzpiZW5A bm9zdHJ1bS5jb21dIA0Kt6LLzcqxvOQ6IDIwMTbE6jbUwjE2yNUgODoyNQ0KytW8/sjLOiBIdWFu Z3lpaG9uZyAoUmFjaGVsKQ0Ks63LzTogQWxpc3NhIENvb3BlcjsgVGhlIElFU0c7IGRyYWZ0LWll dGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbkBpZXRmLm9yZzsgYXZ0ZXh0QGlldGYub3Jn OyBqb25hdGhhbkB2aWR5by5jb207IGF2dGV4dC1jaGFpcnNAaWV0Zi5vcmcNCtb3zOI6IFJlOiBB bGlzc2EgQ29vcGVyJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5n LW5vdGlmaWNhdGlvbi0wNzogKHdpdGggQ09NTUVOVCkNCg0KT24gMTUgSnVuIDIwMTYsIGF0IDE0 OjQ1LCBIdWFuZ3lpaG9uZyAoUmFjaGVsKSB3cm90ZToNCg0KPiBXaGF0IGlzIHVuZGV0ZWN0YWJs ZSBzcGxpY2luZz8NCj4NCj4gW1JhY2hlbF06IFVuZGV0ZWN0YWJsZSBzcGxpY2luZyBtZWFucyB0 aGF0IHRoZSBSVFAgcmVjZWl2ZXJzIHNob3VsZCANCj4gbm90IGJlIGFibGUgdG8gZGV0ZWN0IGFu eSBzcGxpY2luZyBwb2ludHMgaW4gdGhlIFJUUCBsYXllci4gSXQgaXMgDQo+IHJlcXVpcmVkIGlu IHNvbWUgY2FzZXMsIGZvciBleGFtcGxlLCBhbiBJUFRWIGFkdmVydGlzZW1lbnQgdXNlciBjYXNl LCANCj4gdGhlIHNlcnZpY2UgcHJvdmlkZXIgbWF5IHdhbnQgdG8gbWFrZSBpdCBkaWZmaWN1bHQg Zm9yIHRoZSBSVFAgDQo+IHJlY2VpdmVyIHRvIGRldGVjdCB3aGVyZSBhbiBhZHZlcnRpc2VtZW50 IGluc2VydGlvbiBpcyBzdGFydGluZyBvciANCj4gZW5kaW5nIGZyb20gdGhlIFJUUCBwYWNrZXRz LCBhbmQgdGh1cyBhdm9pZGluZyB0aGUgUlRQIHJlY2VpdmVyIGZyb20gDQo+IGZpbHRlcmluZyBv dXQgdGhlIGFkdmVydGlzZW1lbnQgY29udGVudC4NCg0KU2luY2Ugc2V2ZXJhbCBwZW9wbGUgaGF2 ZSBleHByZXNzZWQgY29uY2VybnMgaGVyZSwgSSB3b25kZXIgaWYgaXQgd291bGQgYmUgaGVscGZ1 bCB0byBoYXZlIHNvbWUgdGV4dCBhYm91dCB0cnVzdCBhbmQgY29udGVudCBtb2RlbHMuIEkgX3Ro aW5rXyB0aGF0IHRoZSB0eXBpY2FsIHVzZSBjYXNlIHdpbGwgYmUgb25lIHdoZXJlIHRoZSBzcGxp Y2VyIGlzIG9wZXJhdGluZyBvbiBiZWhhbGYgb2YgdGhlIGNvbnRlbnQgcHJvdmlkZXIuIEluIHRo YXQgY2FzZSwgb25lIGNvdWxkIHRoaW5rIG9mIHRoZSBwb3N0LXNwbGljaW5nIFJUUCBzdHJlYW0g YXMgdGhlIHRoZSBmaW5hbCBjb250ZW50IGJlaW5nIHByb3ZpZGVkLiBPbmUgY291bGQgcmVhc29u YWJseSBhcmd1ZSB0aGF0IHRoZSBrbm93bGVkZ2Ugb2YgaG93IHRoYXQgc3RyZWFtIHdhcyBjb21w b3NlZCBpcyBwcml2YXRlIHRvIHRoZSBwcm92aWRlciwgYW5kIG5vdCB0aGUgYnVzaW5lc3Mgb2Yg dGhlIGZpbmFsIHJlY2lwaWVudC4NCg0KT24gdGhlIG90aGVyIGhhbmQsIGEgc3BsaWNlciB0aGF0 IGRvZXMgbm90IG9wZXJhdGUgb24gYmVoYWxmIG9yIChvciBhdCBsZWFzdCB3aXRoIHRoZSBwZXJt aXNzaW9uIG9mKSBvZiB0aGUgY29udGVudCBwcm92aWRlciBvciByZWNpcGllbnQgd291bGQgYmUg ZWdyZWdpb3VzLCBldmVuIGlmIGl0IGRpZCBub3QgaGlkZSB0aGUgc3BsaWNpbmcgaW50ZXJ2YWwg ZGF0YS4NCg0K From nobody Thu Jun 16 04:10:53 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 9F09712D135; Thu, 16 Jun 2016 04:10:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160616111046.10405.20492.idtracker@ietfa.amsl.com> Date: Thu, 16 Jun 2016 04:10:46 -0700 Archived-At: Cc: draft-ietf-avtext-splicing-notification@ietf.org, avtext@ietf.org, jonathan@vidyo.com, avtext-chairs@ietf.org Subject: [avtext] Stephen Farrell's Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS and COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 11:10:47 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-avtext-splicing-notification-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) Section 7, 3rd para: Saying that "splicer works as a trusted entity" seems wrong - you need to say who trusts whom for what I think. I also don't get what you mean by saying there'll be a security association between the splicer and the receiver, nor how that might ever be possible if the splicer wants to hide what it's doing. I think what you're after is some general statement that splicing breaks all security unless all the parties involved share the same security association. IIRC there is text like that in other RTP documents that might be copied but I forget the detail. (2) Section 7, 4th para: You say there is a case where header extension encryption SHOULD be used - how would that work? If there's a clear way to do it that'd get interop, then why is that not described? If there are ways in which might or might not work, or if some proprietary arrangements might be needed then how is it ok to have a SHOULD there? I suspect that the right thing here may be to not pretend that that can be done but to just stick with saying that splicing is inherently not going to work if you use any real security mechanisms, or something similar. (3) In discussion of RFC6828 there was some concern about possible creation of loops. I forget the issues though, but wanted to check this in case it also applies here. (See 4.5 of 6828 maybe or the history for that RFC in the tracker.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - I agree with Alia's discuss, but suspect the ship has sailed. (Sadly IMO, but sailed nonetheless.) - The security considerations here are similar to but not quite the same as those in RFC6828 which I think was the last time a similar document was before the IESG. I wondered if those differences were significant or not, it might be no harm to commpare the two (if that's not already been done) since they really ought be pretty much the same. From nobody Thu Jun 16 06:11: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 4F36D12B01E for ; Thu, 16 Jun 2016 06:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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-lIOyxcIAmw for ; Thu, 16 Jun 2016 06:11:03 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4CC112D5F0 for ; Thu, 16 Jun 2016 06:10:59 -0700 (PDT) Received: (qmail 26121 invoked from network); 16 Jun 2016 15:10:56 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 16 Jun 2016 15:10:56 +0200 To: "Huangyihong (Rachel)" , Colin Perkins , Magnus Westerlund References: <20160613125529.12490.86798.idtracker@ietfa.amsl.com> <65EAADDF-EE7F-414B-AF3F-45BA4B729500@csperkins.org> <57601B7E.3070208@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED634A@nkgeml513-mbx.china.huawei.com> <0BA323FF-C204-43FC-9535-7F3918AEFA53@csperkins.org> <51E6A56BD6A85142B9D172C87FC3ABBB86ED6560@nkgeml513-mbx.china.huawei.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <5762A55D.3030601@kuehlewind.net> Date: Thu, 16 Jun 2016 15:10:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86ED6560@nkgeml513-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "draft-ietf-avtcore-rfc5285-bis@ietf.org" , IETF AVTCore WG , "draft-ietf-avtext-splicing-notification@ietf.org" , "avtext-chairs@ietf.org" Subject: Re: [avtext] =?utf-8?q?addtions_to_RFC5285bis=3F_was_Re=3A__Mirja_K?= =?utf-8?q?=C3=BChlewind=27s_Discuss_on_draft-ietf-avtext-splicing-notific?= =?utf-8?q?ation-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 16 Jun 2016 13:11:04 -0000 Does this mean we wait with the final publication of the splicing draft until RFC5285bis is done (as this probably will be a normative reference then)? Mirja On 15.06.2016 21:24, Huangyihong (Rachel) wrote: > I totally agree with this approach. We don’t need each specific RTP header extension draft to repeatedly discuss a common issue. > > BR, > Rachel > > > -----邮件原件----- > 发件人: Colin Perkins [mailto:csp@csperkins.org] > 发送时间: 2016年6月15日 21:08 > 收件人: Magnus Westerlund > 抄送: Huangyihong (Rachel); Mirja Kühlewind; avtext-chairs@ietf.org; draft-ietf-avtext-splicing-notification@ietf.org; avtext@ietf.org; jonathan@vidyo.com; IETF AVTCore WG; draft-ietf-avtcore-rfc5285-bis@ietf.org > 主题: Re: Additions to RFC5285bis? was Re: [avtext] Mirja Kühlewind's Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS and COMMENT) > > Hi Magnus, > > I agree that this makes sense, and is probably better than having more general discussion in the splicing notification draft. > > Colin > > > >> On 15 Jun 2016, at 08:54, Magnus Westerlund wrote: >> >> Hi, >> (As individual) >> >> I think we stumbled on one thing that maybe should be included in the update of RFC5285. >> >> Namely the discussion and reasoning why a sender may need to repeat a RTP header extension. See below excerpt from the discussion: >> >> Den 2016-06-15 kl. 09:22, skrev Huangyihong (Rachel): >>> Hi Mirja, >>> >>> As one of the authors, please see my replies inline. >>> >>> BR, Rachel >>> >>> -----邮件原件----- 发件人: Mirja Kühlewind [mailto:ietf@kuehlewind.net] 发送时 >> >>> >>>>> - Why is just having the RTCP message not sufficient? Why are the >>>>> RTP extensions needed as well? >>>> >>>> RTP and RTCP are unreliable. The usual practice for these types of >>>> extension is to send data both in RTCP, and in some number of RTP >>>> packets, to increase the chances of it arriving in a timely manner. >>>> The draft is following standard practice here. >>> >>> Thanks for clarification. That could be clarified in the text. >>> Because the text says that RTCP is used because the RTP information >>> might get lost. So I was wondering why you are not only using RTCP >>> and make sure you send it sufficiently often. Saying that this is >>> common practice would be helpful from my point of view. Is there a >>> reference for this? >>> >>> [Rachel]: It's more like conventional method to increase robustness. >>> As far as I know, there's no formal document to record this. Maybe we >>> can address this like this >>> >>> OLD " >>> >>> To increase robustness against such case, the document also defines a >>> complementary RTCP packet type to carry the same Splicing Interval to >>> the splicer. >>> >>> " >>> >>> NEW " To increase robustness against such case, the document also >>> defines a new RTCP packet type to carry the same Splicing Interval to >>> the splicer. Since RTCP is also unreliable and may not so immediate >>> as the in-band way, it's only considered as a complement to RTP >>> header extension. " >>> >>> >>>>> - And is the RTCP message send only once or multiple time? This is >>>>> not specified. >>>> >>>> That’s implementation dependent, and based on the expected packet >>>> loss rate, the importance of the data, and the frequency with which >>>> updates need to be sent. >>> >>> A recommendation or discussion should be provided here. >>> >>> [Rachel]: I think in Section 2, we have already provided some >>> guidance on how often the Splicing Interval to be sent, which is not >>> just limited to RTP header extension, also includes RTCP message. >>> >> >> This topic is also discussed in >> draft-ietf-avtext-sdes-hdr-ext-07 Section 4.2.3. >> >> From my perspective I think the general transmission issues that needs to be considered with RTP header extension should be included in the update of RFC5285. That way each extension don't have to repeat it, only discuss additions or specific considerations for their formats. >> >> To note I think that from SDES header Extension there should be >> included the topics of; >> >> - MTU handling >> - How many transmissions and if one can know it has reached the >> receiver >> - Update handling, especially for extensions with data that can be sent using both RTCP and RTP header extension. >> >> Note, this is my suggestion as an individual. Please discuss and comment. >> >> 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 >> ---------------------------------------------------------------------- >> > > > > -- > Colin Perkins > https://csperkins.org/ > > > > From nobody Thu Jun 16 06:21:07 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 216E112D5F0; Thu, 16 Jun 2016 06:21:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160616132105.10512.95243.idtracker@ietfa.amsl.com> Date: Thu, 16 Jun 2016 06:21:05 -0700 Archived-At: Cc: draft-ietf-avtext-splicing-notification@ietf.org, avtext@ietf.org, jonathan@vidyo.com, avtext-chairs@ietf.org Subject: [avtext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-avtext-splicing-notification-07=3A_=28with_COMMENT=29?= X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 13:21:05 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-avtext-splicing-notification-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I moved my discuss points into the comment now assuming that the discussed changes will be applied in the next version. I still support Alia's discuss, as this point must be addressed carefully, and I would like to review the next before final publications. - The following action does not seem to be appropriate for a specification of an end-to-end protocol: "And if the splicer wishes to prevent the downstream receivers from detecting splicing, it MUST NOT forward the message." I guess if a middlebox decides to drop the message, there is not much we can do. But I definitely would prefer to not see this specified in an RFC. - Why is just having the RTCP message not sufficient? Why are the RTP extensions needed as well? - And is the RTCP message send only once or multiple time? This is not specified. - There is some discussion about the implementation of the slicer in section 5 (where btw. the title "Failure Cases" seems inappropriate), while there is one sentence saying: "If the splicer is implemented following [RFC6828], it will have its own SSRC and will send its own RTCP reports, and will forward translated RTCP reports from the receivers." Why are alternatives discussed here, if there is already a recommendation given in RFC6828? And how would proper congestion handling be ensure in the other setups not described in RFC6828? - As a general comment, I found it quite hard to read this doc without reading RFC6828 which is only listed as a informative reference as it is informational only. I think it is wrong. Further, RFC6828 describes some action that a slicers has to perform. However, all language in RFC6828 is non normative. This is slightly confusing to me as well. I would further recommend to briefly give an overview of the assumed scenario is this document. - Minor comment: The definition of the new SDP grouping semantic should be mentioned in the abstract and RFC4566 should be referenced. And I don't think the SDP grouping registry requires a contact. - Quick question: Maybe I'm missing something here but why do you need a splicer in a scenario where "the substitutive sender is implemented together with the main RTP sender inside a single device" (as written in section 2)? From nobody Thu Jun 16 06:25:26 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 E9D7D12D5F0 for ; Thu, 16 Jun 2016 06:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-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 LhKNEL03I1aX for ; Thu, 16 Jun 2016 06:25:20 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9477412D610 for ; Thu, 16 Jun 2016 06:25:19 -0700 (PDT) Received: (qmail 26259 invoked from network); 16 Jun 2016 15:18:35 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 16 Jun 2016 15:18:35 +0200 To: "Huangyihong (Rachel)" , Colin Perkins References: <20160613125529.12490.86798.idtracker@ietfa.amsl.com> <65EAADDF-EE7F-414B-AF3F-45BA4B729500@csperkins.org> <57601B7E.3070208@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED634A@nkgeml513-mbx.china.huawei.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <5762A728.5000003@kuehlewind.net> Date: Thu, 16 Jun 2016 15:18:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86ED634A@nkgeml513-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "avtext-chairs@ietf.org" , "draft-ietf-avtext-splicing-notification@ietf.org" , "avtext@ietf.org" , The IESG , "jonathan@vidyo.com" Subject: Re: [avtext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-avtext-splicing-notification-07=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= 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, 16 Jun 2016 13:25:25 -0000 Hi Rachel, please provide the suggested changes. I'll move to an no objection in my ballot position now, given that Alia still hold a discuss on the most important point. I agree here that more text to clarify the situation and assumed scenario(s) would be needed! I also would like to still review the next version (before final publication)! Mirja On 15.06.2016 09:22, Huangyihong (Rachel) wrote: > Hi Mirja, > > As one of the authors, please see my replies inline. > > BR, > Rachel > > -----邮件原件----- > 发件人: Mirja Kühlewind [mailto:ietf@kuehlewind.net] > 发送时间: 2016年6月14日 22:58 > 收件人: Colin Perkins > 抄送: The IESG; draft-ietf-avtext-splicing-notification@ietf.org; avtext@ietf.org; jonathan@vidyo.com; avtext-chairs@ietf.org > 主题: Re: [avtext] Mirja Kühlewind's Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS and COMMENT) > > Hi, > > thanks for the quick reply. See below. > > On 14.06.2016 13:19, Colin Perkins wrote: >>> On 13 Jun 2016, at 13:55, Mirja Kuehlewind wrote: >>> >>> Mirja Kühlewind has entered the following ballot position for >>> draft-ietf-avtext-splicing-notification-07: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut >>> this introductory paragraph, however.) >>> >>> >>> Please refer to >>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notificat >>> ion/ >>> >>> >>> >>> --------------------------------------------------------------------- >>> - >>> DISCUSS: >>> --------------------------------------------------------------------- >>> - >>> >>> I have a few points which I would like to have answers for before >>> moving the doc forward (which may not even results in text changes). >>> I happy to clear my position when answered before the telechat: >>> >>> - The following action does not seem to be appropriate for a >>> specification of an end-to-end protocol: >>> "And if the splicer wishes to prevent the downstream receivers from >>> detecting splicing, it MUST >>> NOT forward the message." >>> I guess if a middlebox decides to drop the message, there is not much >>> we can do. But I definitely would prefer to not see this specified in >>> an RFC. >> >> This isn’t an end-to-end protocol. It’s a protocol for a sender to communicate with an RTP middlebox that’s performing splicing. RTP middleboxes are expected to modify RTCP, and discarding or modifying RTCP packets that don’t make sense for some participants is normal behaviour for such middleboxes. > > Okay, thanks for the clarification that this is excepted behavior. I still find the wording a little awkward. Shouldn't this be: > > "The splicer MAY decide to not forward the message, e.g., if it wishes to prevent the downstream receivers from detecting splicing"? > > Or maybe SHOULD if that is actually the recommend behavior (but then the if part makes basically no sense)... > > [Rachel]: Okay. I think it can be modified like this in this case. > > >>> - Why is just having the RTCP message not sufficient? Why are the RTP >>> extensions needed as well? >> >> RTP and RTCP are unreliable. The usual practice for these types of extension is to send data both in RTCP, and in some number of RTP packets, to increase the chances of it arriving in a timely manner. The draft is following standard practice here. > > Thanks for clarification. That could be clarified in the text. Because the text says that RTCP is used because the RTP information might get lost. So I was wondering why you are not only using RTCP and make sure you send it sufficiently often. Saying that this is common practice would be helpful from my point of view. Is there a reference for this? > > [Rachel]: It's more like conventional method to increase robustness. As far as I know, there's no formal document to record this. Maybe we can address this like this > > OLD > " > > To increase robustness against such case, the document also defines a > complementary RTCP packet type to carry the same Splicing Interval to > the splicer. > > " > > NEW > " > To increase robustness against such case, the document also defines a > new RTCP packet type to carry the same Splicing Interval to > the splicer. Since RTCP is also unreliable and may not so immediate as the in-band way, it's only considered as a complement to RTP header extension. > " > > >>> - And is the RTCP message send only once or multiple time? This is >>> not specified. >> >> That’s implementation dependent, and based on the expected packet loss rate, the importance of the data, and the frequency with which updates need to be sent. > > A recommendation or discussion should be provided here. > > [Rachel]: I think in Section 2, we have already provided some guidance on how often the Splicing Interval to be sent, which is not just limited to RTP header extension, also includes RTCP message. > >> >>> - There is some discussion about the implementation of the slicer in >>> section 5 (where btw. the title "Failure Cases" seems inappropriate), >>> while there is one sentence saying: "If the splicer is implemented >>> following [RFC6828], it will have its >>> own SSRC and will send its own RTCP reports, and will forward >>> translated RTCP reports from the receivers." >>> Why are alternatives discussed here, if there is already a >>> recommendation given in RFC6828? >> >> I assume because this is not normatively requiring RFC 6828. > > As I said below, I find it hard to read this document without having read RFC6828; therefore I'd say it should be normative or more background information should be added to this doc about the assumed scenario(s). > > [Rachel]: So you're suggesting that we propose some texts to briefly introduce the RFC6828? If that's the case, we'll provide some text later. > > >> >>> And how would proper congestion handling be ensure in the other setups not described in RFC6828? >> >> If the splicer is implemented as an RTP mixer, as in RFC 6828, then there will be three congestion control loops: original sender to splicer, substitutive sender to splicer, and splicer to receiver. > Yes, this one is find and discussed in RFC6828. >> >> If the splicer is implemented as an RTP translator, then it will be invisible to the congestion control, and the control loops run between original sender and receiver, or between substitutive sender and receiver, depending which of the streams is passed by the splicer. > In this scenario, the RTCP feedback message MUST be passed to the right sender to make the congestion control work. This part is not clearly specified in the draft, as far as I can say. > > [Rachel]: Okay. I think this can be clarified in the draft, adding a sentence like this: > > "When the splicer works as an RTP translator, the congestion control runs between original sender and receiver, or between substitutive sender and receiver, so the RTCP feedback message MUST be passed to the right sender to let the congestion control work." > > And will the splicer then forward the packets unaltered to the receiver, or could it be possible that the splicer adds additional data? > > [Rachel]: When it's not splicing time, it will forward the packets untouched. No additional data. When it's in the splicing interval, the splicer will use the substitutive content instead of the original content and modify the RTP header. > >> >> If the splicer is implemented for unicast streaming, the congestion control loops could run the RMCAT algorithms. Perhaps more likely, though, is that the splicer acts on a multicast (SSM) RTP flow, and you have provisioned capacity. >> >>> --------------------------------------------------------------------- >>> - >>> COMMENT: >>> --------------------------------------------------------------------- >>> - >>> >>> - As a general comment, I found it quite hard to read this doc >>> without reading RFC6828 which is only listed as a informative >>> reference as it is informational only. I think it is wrong. Further, >>> RFC6828 describes some action that a slicers has to perform. However, >>> all language in RFC6828 is non normative. This is slightly confusing >>> to me as well. I would further recommend to briefly give an overview >>> of the assumed scenario is this document. >>> >>> - Minor comment: The definition of the new SDP grouping semantic >>> should be mentioned in the abstract and RFC4566 should be referenced. >>> And I don't think the SDP grouping registry requires a contact. > > [Rachel]: Yes. I'll remove the contact. >>> >>> - Quick question: Maybe I'm missing something here but why do you >>> need a splicer in a scenario where "the >>> substitutive sender is implemented together with the main RTP >>> sender inside a single device" (as written in section 2)? > > [Rachel]: In implementations, servers may not quite be close to end users. For advertisement splicing case, sometimes it's the splicer's decision to choose which kind of users to forward the spliced content, which means different users may get different spliced content. > >>> >>> >>> _______________________________________________ >>> avtext mailing list >>> avtext@ietf.org >>> https://www.ietf.org/mailman/listinfo/avtext >> >> >> From nobody Thu Jun 16 06:30:38 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0DA12D5F8 for ; Thu, 16 Jun 2016 06:30:36 -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 tQOWrGrqPhyu for ; Thu, 16 Jun 2016 06:30:35 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB8C12D5B9 for ; Thu, 16 Jun 2016 06:30:35 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id t129so73181985vka.1 for ; Thu, 16 Jun 2016 06:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=yAuVmPiFpDKtGxtwhYxQbHq8tD+ZFO4ih2LSZpfCP38=; b=SQBN2C7Bx30oDLdLv0cKY6DcO5PnGOLqH6rEBD/hyX23rTCdHZsCPz1MiNrpkap306 bphS6nxIhzfXeS7/vqDhwmdS5mGlNm1J5+2l7iEnA0LVlfg0/XL83FcHwqWe6iuznCoU 2qbhFaMCXM8Tt85GM4GX73v56AbvWCMfIoKZlMBnzvcQl8Beqt/mOU9d0MDGJuoSrdqv bYl4wU6UrgrAYNmb4hJ64ZzUNgHsyj9SRyJhmvueqfa6rX4ciw7M/jtK7VNFNW9qXRai Mk/LMEOJM/UE1Zzr7kgXV/p1TVYh+bSCEwsLCGWq4KqIF1S6WrSSLJGHqXfhkRU/VEci FaeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yAuVmPiFpDKtGxtwhYxQbHq8tD+ZFO4ih2LSZpfCP38=; b=DxJKt5WGeTy89HU3p6OE0P1OJmZEHa7KZcYaEdMXgGY0QDhMAr4sHzDkMSVomBOMb7 G1F6XQhXA1Vl1Lx04qbvXBV6LHDRPo7Ju9x1f8j0QIgW6X7b0yKKe6AHcf0OT0QhFaa6 NwGziuQxIgzdQJSIdpkZGbbyHyIk2x0kcCZCbq58gswJiUQeDtJ1yoW1+wdyIbbURHEP zf95H5fMy6SdQsqKclnHnPdFUnuNVp5EBc/5eACBJ/sjFcK79AMA300vzzwaEviwv7CQ 7G+7915dDXar7XTwcCXw8KMIxoLKzvcgaE14c20adBdH0+N1H/Kd6fNpINfrLN2atYCm Askw== X-Gm-Message-State: ALyK8tLfr3pGB4Xy+PCDFhOz0zQ3yHef3NMd/6whBEIFnWnbgCpZWb+KJkf0AH3+Vnfsc27+sWdFwANQELGoCw== X-Received: by 10.176.3.114 with SMTP id 105mr2049012uat.122.1466083834219; Thu, 16 Jun 2016 06:30:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.41.198 with HTTP; Thu, 16 Jun 2016 06:30:14 -0700 (PDT) From: Bernard Aboba Date: Thu, 16 Jun 2016 09:30:14 -0400 Message-ID: To: avtext@ietf.org Content-Type: multipart/alternative; boundary=001a113d15d826540f0535653e12 Archived-At: Subject: [avtext] A question about draft-ietf-avtext-rid 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, 16 Jun 2016 13:30:37 -0000 --001a113d15d826540f0535653e12 Content-Type: text/plain; charset=UTF-8 [Moving RTP-related question to the AVTEXT mailing list) Emil asked: "Are there specs that would actually allow JSEP to operate with simulcast in reception? Do we have anything that says how SSRCs should be sort-of ignored in the presence of an incoming RID and tells us what to do with sequence numbers in such scenarios?" [BA] draft-ietf-avtext-rid does not updated RFC 3550 or any other RTP-related document, so my assumption is that it does not change the treatment of RTP sequence numbers or timestamps. That is, streams with their own SSRCs will have distinct sequence number (and timestamp) spaces. In a situation where a sender is switching between simulcast streams (as opposed to sending them all continuously) and there is reordering, a receiver may begin to receive packets from another stream, and subsequently see packets arrive from the previous stream. To correctly order the incoming packets, it is helpful to use RFC 6051 rapid synchronization. --001a113d15d826540f0535653e12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[Moving RTP-related question to the AVTEXT mailing list)
Emil asked:=C2=A0

"Are there specs that wou= ld actually allow JSEP to operate with
simulcast in reception? Do we have anything that say=
s how SSRCs should
be sort-of ignored in the presence of an incoming RID and tells us=C2=A0
wh=
at to do with sequence numbers in such scenarios?"
<= div>
[BA] draft-ietf-avtext-rid does not updated RFC 3550 or = any other RTP-related document, so my assumption is that it does not change= the treatment of RTP sequence numbers or timestamps.=C2=A0 That is, =C2=A0= streams with their own SSRCs will have distinct sequence number (and timest= amp) spaces.=C2=A0

In a situation where a sender i= s switching between simulcast streams (as opposed to sending them all conti= nuously) and there is reordering, a receiver may begin to receive packets f= rom another stream, and subsequently see packets arrive from the previous s= tream.=C2=A0 To correctly order the incoming packets, it is helpful to use = RFC 6051 rapid synchronization.=C2=A0
--001a113d15d826540f0535653e12-- From nobody Mon Jun 20 02:35:06 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 BC50712B019 for ; Mon, 20 Jun 2016 02:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 qsplFc0uL9xm for ; Mon, 20 Jun 2016 02:34:59 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B394B12D0B4 for ; Mon, 20 Jun 2016 02:34:58 -0700 (PDT) Received: (qmail 17701 invoked from network); 20 Jun 2016 11:28:13 +0200 Received: from p5dec2e4f.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.46.79) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 20 Jun 2016 11:28:13 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <1E7F244A-2045-48E5-B817-7B87D6E5B094@cooperw.in> Date: Mon, 20 Jun 2016 11:28:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160614215932.31629.25074.idtracker@ietfa.amsl.com> <1E7F244A-2045-48E5-B817-7B87D6E5B094@cooperw.in> To: Alissa Cooper X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jonathan Lennox , avtext@ietf.org, avtext-chairs@ietf.org, IESG , draft-ietf-avtext-splicing-notification@ietf.org, Alia Atlas Subject: Re: [avtext] Alia Atlas' Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS) 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, 20 Jun 2016 09:35:00 -0000 Hi, > Am 16.06.2016 um 01:17 schrieb Alissa Cooper : >=20 > - I agree that the MUST NOT forward language is ill-advised, and = it=E2=80=99s also unnecessary. But even if this document said MUST = forward, there is nothing in the protocol semantics that would require = implementations to do that, so I imagine that splicers that do not want = to forward this information (whether to prevent detection or to reduce = overhead) won=E2=80=99t forward it. Similarly, I would imagine that at = least some of the payload-specific mechanisms used for this purpose have = the same property, so even if systems rely on those mechanisms rather = than RTP because the RTP spec says MUST forward, there is no guarantee = that the splicing information will reach the receiver. I still support Alia=E2=80=99s discuss here, because even if we can=E2=80=99= t change what people/splicers do, we should not write should an = ill-advise in an RFC! Mirja= From nobody Mon Jun 20 03:29:22 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836E012D5AF for ; Mon, 20 Jun 2016 03:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 4OUt3BLBnf4B for ; Mon, 20 Jun 2016 03:29:18 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3209812B02A for ; Mon, 20 Jun 2016 03:29:18 -0700 (PDT) Received: (qmail 17741 invoked from network); 20 Jun 2016 11:29:14 +0200 Received: from p5dec2e4f.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.46.79) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 20 Jun 2016 11:29:13 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Mon, 20 Jun 2016 11:29:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> To: Colin Perkins X-Mailer: Apple Mail (2.3124) Archived-At: Cc: jonathan@vidyo.com, avtext@ietf.org, avtext-chairs@ietf.org, Kathleen Moriarty , The IESG , draft-ietf-avtext-splicing-notification@ietf.org Subject: Re: [avtext] Kathleen Moriarty's No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT) 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, 20 Jun 2016 10:29:19 -0000 Hi Colin, see below. > Am 16.06.2016 um 00:34 schrieb Colin Perkins : >=20 >> On 15 Jun 2016, at 19:37, Kathleen Moriarty = wrote: >>=20 >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-avtext-splicing-notification-07: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> = https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I strongly support Mirja's and Alia's discuss points and would like = to >> see more of a discussion of the capability to hide splicing in the >> security considerations text. My ballot would be discuss, but they >> pulled out the relevant sections and that would be duplication. I'd = like >> to review agreed upon text though to address these concerns. =20 >>=20 >> I don't like the idea of enabling a MiTM, but do see the draft talks >> about how to protect headers when this happens and confidentiality is >> needed as well as session protection between the endpoints and the >> splicer (which I don't like either, but you do call out the security >> considerations of this and that's what is needed). >=20 > The mechanism described doesn=E2=80=99t work unless the receiver = explicitly chooses to receive media content delivered via the splicer. I = agree that the draft could be more clearly written, but it doesn=E2=80=99t= seem to be =E2=80=9Cenabling a MiTM=E2=80=9D attack, since the receiver = opts in. This definitely need from clarification in the draft! Mirja >=20 > --=20 > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 From nobody Mon Jun 20 03:42:34 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1745E12B025; Mon, 20 Jun 2016 03:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 83QXCiHIh4Zt; Mon, 20 Jun 2016 03:42:25 -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 5B05A12B006; Mon, 20 Jun 2016 03:42:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMG75539; Mon, 20 Jun 2016 10:42:21 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 20 Jun 2016 11:42:20 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Mon, 20 Jun 2016 18:42:14 +0800 From: "Huangyihong (Rachel)" To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS and COMMENT) Thread-Index: AQHRx7/AweW8aYmvaU+udtkKRDujUJ/yGB+g Date: Mon, 20 Jun 2016 10:42:14 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86ED8585@nkgeml513-mbx.china.huawei.com> References: <20160616111046.10405.20492.idtracker@ietfa.amsl.com> In-Reply-To: <20160616111046.10405.20492.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.128] 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.0A020204.5767C88E.005B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f1db55e820b24b535e9658bb0ceac83e Archived-At: Cc: "draft-ietf-avtext-splicing-notification@ietf.org" , "avtext@ietf.org" , "jonathan@vidyo.com" , "avtext-chairs@ietf.org" Subject: Re: [avtext] Stephen Farrell's Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS and COMMENT) 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, 20 Jun 2016 10:42:28 -0000 SGkgU3RlcGhlbiwNCg0KUGxlYXNlIHNlZSBteSByZXBsaWVzIGlubGluZS4gDQoNCkJSLA0KUmFj aGVsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU3RlcGhlbiBGYXJy ZWxsIFttYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0NCj4gU2VudDogVGh1cnNkYXks IEp1bmUgMTYsIDIwMTYgNzoxMSBQTQ0KPiBUbzogVGhlIElFU0cNCj4gQ2M6IGRyYWZ0LWlldGYt YXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbkBpZXRmLm9yZzsgYXZ0ZXh0LWNoYWlyc0BpZXRm Lm9yZzsNCj4gam9uYXRoYW5AdmlkeW8uY29tOyBhdnRleHRAaWV0Zi5vcmcNCj4gU3ViamVjdDog U3RlcGhlbiBGYXJyZWxsJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWF2dGV4dC1zcGxpY2luZy1u b3RpZmljYXRpb24tMDc6DQo+ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBTdGVw aGVuIEZhcnJlbGwgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9y DQo+IGRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0wNzogRGlzY3Vzcw0K PiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFj dCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsDQo+IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8g YW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeQ0KPiBwYXJh Z3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5p ZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUg aW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4g DQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywg Y2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi8NCj4gDQo+IA0KPiANCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiBESVNDVVNTOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiANCj4gKDEpIFNl Y3Rpb24gNywgM3JkIHBhcmE6IFNheWluZyB0aGF0ICJzcGxpY2VyIHdvcmtzIGFzIGEgdHJ1c3Rl ZCBlbnRpdHkiIHNlZW1zDQo+IHdyb25nIC0geW91IG5lZWQgdG8gc2F5IHdobyB0cnVzdHMgd2hv bSBmb3Igd2hhdCBJIHRoaW5rLiBJIGFsc28gZG9uJ3QgZ2V0IHdoYXQNCj4geW91IG1lYW4gYnkg c2F5aW5nIHRoZXJlJ2xsIGJlIGEgc2VjdXJpdHkgYXNzb2NpYXRpb24gYmV0d2VlbiB0aGUgc3Bs aWNlciBhbmQNCj4gdGhlIHJlY2VpdmVyLCBub3IgaG93IHRoYXQgbWlnaHQgZXZlciBiZSBwb3Nz aWJsZSBpZiB0aGUgc3BsaWNlciB3YW50cyB0byBoaWRlDQo+IHdoYXQgaXQncyBkb2luZy4gIEkg dGhpbmsgd2hhdCB5b3UncmUgYWZ0ZXIgaXMgc29tZSBnZW5lcmFsIHN0YXRlbWVudCB0aGF0DQo+ IHNwbGljaW5nIGJyZWFrcyBhbGwgc2VjdXJpdHkgdW5sZXNzIGFsbCB0aGUgcGFydGllcyBpbnZv bHZlZCBzaGFyZSB0aGUgc2FtZQ0KPiBzZWN1cml0eSBhc3NvY2lhdGlvbi4gSUlSQyB0aGVyZSBp cyB0ZXh0IGxpa2UgdGhhdCBpbiBvdGhlciBSVFAgZG9jdW1lbnRzIHRoYXQNCj4gbWlnaHQgYmUg Y29waWVkIGJ1dCBJIGZvcmdldCB0aGUgZGV0YWlsLg0KDQpbUmFjaGVsXTogQXJlIHlvdSBsb29r aW5nIGZvciBzdWNoIHNlbnRlbmNlcz8NCg0KT0xEDQoiDQogICBTaW5jZSBzcGxpY2VyIHdvcmtz IGFzIGEgdHJ1c3RlZCBlbnRpdHksIGFueSBSVFAtbGV2ZWwgb3Igb3V0c2lkZQ0KICAgc2VjdXJp dHkgbWVjaGFuaXNtLCBzdWNoIGFzIElQc2VjW1JGQzQzMDFdIG9yIERhdGFncmFtIFRyYW5zcG9y dA0KICAgTGF5ZXIgU2VjdXJpdHkgW1JGQzYzNDddLCB3aWxsIHVzZSBhIHNlY3VyaXR5IGFzc29j aWF0aW9uIGJldHdlZW4gdGhlDQogICBzcGxpY2VyIGFuZCB0aGUgcmVjZWl2ZXIuIFdoZW4gdXNp bmcgdGhlIFNlY3VyZSBSZWFsLVRpbWUgVHJhbnNwb3J0DQogICBQcm90b2NvbCAoU1JUUCkgW1JG QzM3MTFdLCB0aGUgc3BsaWNlciBjb3VsZCBiZSBwcm92aXNpb25lZCB3aXRoIHRoZQ0KICAgc2Ft ZSBzZWN1cml0eSBhc3NvY2lhdGlvbiBhcyB0aGUgbWFpbiBSVFAgc2VuZGVyLg0KIg0KTkVXDQoi DQpTaW5jZSB0aGUgc3BsaWNlciBicmVha3MgUlRQLWxldmVsIGVuZC10by1lbmQgc2VjdXJpdHks IGl0IG5lZWQgdG8gYmUgYSB0cnVzdGVkIGRldmljZSB0aGF0IGlzIHBhcnQgb2YgdGhlIHNpZ25h bGluZyBjb250ZXh0IGFuZCBnZXQgdGhlIG5lY2Vzc2FyeSBzZWN1cml0eSBhc3NvY2lhdGlvbnMg KGUuZy4sIFNSVFAgY3J5cHRvIGNvbnRleHRzKSBlc3RhYmxpc2hlZCB3aXRoIGl0cyBSVFAgc2Vz c2lvbiBwYXJ0aWNpcGFudHMuIFdoZW4gdXNpbmcgdGhlIFNlY3VyZSBSZWFsLVRpbWUgVHJhbnNw b3J0IFByb3RvY29sIChTUlRQKSBbUkZDMzcxMV0sIHRoZSBzcGxpY2VyIGNvdWxkIGJlIHByb3Zp c2lvbmVkIHdpdGggdGhlIHNhbWUgc2VjdXJpdHkgYXNzb2NpYXRpb24gYXMgdGhlIG1haW4gUlRQ IHNlbmRlci4NCiINCj4gDQo+ICgyKSBTZWN0aW9uIDcsIDR0aCBwYXJhOiBZb3Ugc2F5IHRoZXJl IGlzIGEgY2FzZSB3aGVyZSBoZWFkZXIgZXh0ZW5zaW9uDQo+IGVuY3J5cHRpb24gU0hPVUxEIGJl IHVzZWQgLSBob3cgd291bGQgdGhhdCB3b3JrPyBJZiB0aGVyZSdzIGEgY2xlYXIgd2F5IHRvIGRv DQo+IGl0IHRoYXQnZCBnZXQgaW50ZXJvcCwgdGhlbiB3aHkgaXMgdGhhdCBub3QgZGVzY3JpYmVk PyBJZiB0aGVyZSBhcmUgd2F5cyBpbiB3aGljaA0KPiBtaWdodCBvciBtaWdodCBub3Qgd29yaywg b3IgaWYgc29tZSBwcm9wcmlldGFyeSBhcnJhbmdlbWVudHMgbWlnaHQgYmUgbmVlZGVkDQo+IHRo ZW4gaG93IGlzIGl0IG9rIHRvIGhhdmUgYSBTSE9VTEQgdGhlcmU/IEkgc3VzcGVjdCB0aGF0IHRo ZSByaWdodCB0aGluZyBoZXJlDQo+IG1heSBiZSB0byBub3QgcHJldGVuZCB0aGF0IHRoYXQgY2Fu IGJlIGRvbmUgYnV0IHRvIGp1c3Qgc3RpY2sgd2l0aCBzYXlpbmcgdGhhdA0KPiBzcGxpY2luZyBp cyBpbmhlcmVudGx5IG5vdCBnb2luZyB0byB3b3JrIGlmIHlvdSB1c2UgYW55IHJlYWwgc2VjdXJp dHkgbWVjaGFuaXNtcywNCj4gb3Igc29tZXRoaW5nIHNpbWlsYXIuDQoNCltSYWNoZWxdOiBZZXMu IEkgYWdyZWUuIFNvIHdlIHNob3VsZCB1c2UgIk1VU1QiIGhlcmUuDQoNCk9MRDoNCiINCklmIHRo ZXJlIGlzIGEgY29uY2VybiBhYm91dCB0aGUgY29uZmlkZW50aWFsaXR5IG9mIHRoZSBzcGxpY2lu ZyB0aW1lIGluZm9ybWF0aW9uLCBoZWFkZXIgZXh0ZW5zaW9uIGVuY3J5cHRpb24gW1JGQzY5MDRd IFNIT1VMRCBiZSB1c2VkLg0KIg0KDQpORVc6DQoNCiINCklmIHRoZXJlIGlzIGEgY29uY2VybiBh Ym91dCB0aGUgY29uZmlkZW50aWFsaXR5IG9mIHRoZSBzcGxpY2luZyB0aW1lIGluZm9ybWF0aW9u LCBoZWFkZXIgZXh0ZW5zaW9uIGVuY3J5cHRpb24gW1JGQzY5MDRdIE1VU1QgYmUgdXNlZC4NCiIN Cg0KPiANCj4gKDMpIEluIGRpc2N1c3Npb24gb2YgUkZDNjgyOCB0aGVyZSB3YXMgc29tZSBjb25j ZXJuIGFib3V0IHBvc3NpYmxlIGNyZWF0aW9uIG9mDQo+IGxvb3BzLiBJIGZvcmdldCB0aGUgaXNz dWVzIHRob3VnaCwgYnV0IHdhbnRlZCB0byBjaGVjayB0aGlzIGluIGNhc2UgaXQgYWxzbw0KPiBh cHBsaWVzIGhlcmUuICAoU2VlIDQuNSBvZg0KPiA2ODI4IG1heWJlIG9yIHRoZSBoaXN0b3J5IGZv ciB0aGF0IFJGQyBpbiB0aGUgdHJhY2tlci4pDQo+IA0KPiANCg0KW1JhY2hlbF06IFllcywgeW91 J3JlIHJpZ2h0LiBIb3cgYWJvdXQgYWRkaW5nIGEgbmV3IHBhcmFncmFwaCBpbiBTZWN0aW9uIDcg dG8gZGlzY3VzcyBsb29wcz8NCg0KIg0KV2hlbiBpbXBsZW1lbnRpbmcgdW5kZXRlY3RhYmxlIHNw bGljaW5nLCBDU1JDIGxpc3QsIHdoaWNoIGNhbiBiZSB1c2VkIHRvIGRldGVjdCBSVFAtbGV2ZWwg Zm9yd2FyZGluZyBsb29wcyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gOC4yIG9mIFtSRkMzNTUwXSwg bWF5IGJlIHJlbW92ZWQgdG8gcHJldmVudCByZWNlaXZlcnMgZnJvbSBkZXRlY3RpbmcgdGhlIHNw bGljaW5nIG9jY3VycmVuY2UuIEhlbmNlLCBsb29wcyBjb3VsZCBvY2N1ciB0byBjYXVzZSBwYWNr ZXRzIHRvIGxvb3AgYmFjayB0byB1cHN0cmVhbSBvZiB0aGUgc3BsaWNlciBhbmQgbWF5IGZvcm0g YSBzZXJpb3VzIGRlbmlhbC1vZi1zZXJ2aWNlIHRocmVhdC4gSW4gc3VjaCBhIGNhc2UsIG5vbi1S VFAgbWVhbnMgTVVTVCBiZSB1c2VkIHRvIGRldGVjdCBhbmQgcmVzb2x2ZSBsb29wcyBpZiB0aGUg c3BsaWNlciBkb2VzIG5vdCBhZGQgYSBDU1JDIGxpc3Qgd2hlbiBmb3J3YXJkaW5nIHRoZSBSVFAg cGFja2V0Lg0KIg0KDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiANCj4gDQo+IA0KPiAtIEkgYWdyZWUgd2l0aCBBbGlhJ3MgZGlzY3VzcywgYnV0IHN1c3Bl Y3QgdGhlIHNoaXAgaGFzIHNhaWxlZC4NCj4gKFNhZGx5IElNTywgYnV0IHNhaWxlZCBub25ldGhl bGVzcy4pDQo+IA0KPiAtIFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBoZXJlIGFyZSBzaW1p bGFyIHRvIGJ1dCBub3QgcXVpdGUgdGhlIHNhbWUgYXMNCj4gdGhvc2UgaW4gUkZDNjgyOCB3aGlj aCBJIHRoaW5rIHdhcyB0aGUgbGFzdCB0aW1lIGEgc2ltaWxhciBkb2N1bWVudCB3YXMNCj4gYmVm b3JlIHRoZSBJRVNHLiBJIHdvbmRlcmVkIGlmIHRob3NlIGRpZmZlcmVuY2VzIHdlcmUgc2lnbmlm aWNhbnQgb3Igbm90LCBpdA0KPiBtaWdodCBiZSBubyBoYXJtIHRvIGNvbW1wYXJlIHRoZSB0d28g KGlmIHRoYXQncyBub3QgYWxyZWFkeSBiZWVuIGRvbmUpIHNpbmNlDQo+IHRoZXkgcmVhbGx5IG91 Z2h0IGJlIHByZXR0eSBtdWNoIHRoZSBzYW1lLg0KPiANCg0KW1JhY2hlbF06IE5vdCBxdWl0ZSB0 aGUgc2FtZS4gVGhpcyBkcmFmdCBpcyBhYm91dCBkZWZpbmluZyBtZXNzYWdlcy4gQW5kIFJGQzY4 MjggaXMgb25lIG9wdGlvbiBzY2VuYXJpbyB3aGVyZSB0aGVzZSBtZXNzYWdlcyBjYW4gYmUgdXNl ZC4gQnV0IHBlb3BsZSBtYXkgdXNlIG90aGVyIG1vZGVscy4gQnV0IGFzIHN1Z2dlc3RlZCBieSBN aXJqYSwgaXQncyBnb29kIHRvIGFkZCBzb21lIHdvcmRzIHRvIGRlc2NyaWJlZCB3aGF0IFJGQyA2 ODI4IGlzIGFib3V0Lg0KDQo= From nobody Mon Jun 20 03:59:06 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 298F112D53C; Mon, 20 Jun 2016 03:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 tGyDhMjHlatp; Mon, 20 Jun 2016 03:59:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 554DE12B006; Mon, 20 Jun 2016 03:59:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 82A83BDF9; Mon, 20 Jun 2016 11:58:59 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXkGag7E7SMY; Mon, 20 Jun 2016 11:58:59 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EF336BE29; Mon, 20 Jun 2016 11:58:58 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1466420339; bh=8wHCmV41OurMBu+KeANJK0AMsI4XfbCNEk3An31gFgE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=a1F4jqwbiSX+yGxjb8MX4i4jbryMHLR3SoFunPapyHFdawQ+zD5n4ZmGRdwLyPt4b VsBq6bX2jQiuBwimtxX0Go9dBDQgN6Ow+U39nCr5lriZ33879j1uZmR1c2wfgdt/Yz ytrDMO2z4pq+/vmbFplLznl3IeSgCq1CFmzsvBho= To: "Huangyihong (Rachel)" , The IESG References: <20160616111046.10405.20492.idtracker@ietfa.amsl.com> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8585@nkgeml513-mbx.china.huawei.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5767CC71.4070907@cs.tcd.ie> Date: Mon, 20 Jun 2016 11:58:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86ED8585@nkgeml513-mbx.china.huawei.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010006090401090802080605" Archived-At: Cc: "draft-ietf-avtext-splicing-notification@ietf.org" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "jonathan@vidyo.com" Subject: Re: [avtext] Stephen Farrell's Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS and COMMENT) 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, 20 Jun 2016 10:59:04 -0000 This is a cryptographically signed message in MIME format. --------------ms010006090401090802080605 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 20/06/16 11:42, Huangyihong (Rachel) wrote: > Hi Stephen, >=20 > Please see my replies inline. >=20 > BR, Rachel >=20 >> -----Original Message----- From: Stephen Farrell >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, June 16, 2016 >> 7:11 PM To: The IESG Cc: >> draft-ietf-avtext-splicing-notification@ietf.org; >> avtext-chairs@ietf.org; jonathan@vidyo.com; avtext@ietf.org=20 >> Subject: Stephen Farrell's Discuss on >> draft-ietf-avtext-splicing-notification-07: (with DISCUSS and >> COMMENT) >>=20 >> Stephen Farrell has entered the following ballot position for=20 >> draft-ietf-avtext-splicing-notification-07: Discuss >>=20 >> When responding, please keep the subject line intact and reply to >> all email addresses included in the To and CC lines. (Feel free to >> cut this introductory paragraph, however.) >>=20 >>=20 >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found >> here:=20 >> https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notificati= on/ >> >> >> >> >>=20 ---------------------------------------------------------------------- >> DISCUSS:=20 >> ----------------------------------------------------------------------= >> >> >> >>=20 (1) Section 7, 3rd para: Saying that "splicer works as a trusted entity" seems >> wrong - you need to say who trusts whom for what I think. I also >> don't get what you mean by saying there'll be a security >> association between the splicer and the receiver, nor how that >> might ever be possible if the splicer wants to hide what it's >> doing. I think what you're after is some general statement that=20 >> splicing breaks all security unless all the parties involved share >> the same security association. IIRC there is text like that in >> other RTP documents that might be copied but I forget the detail. >=20 > [Rachel]: Are you looking for such sentences? >=20 > OLD " Since splicer works as a trusted entity, any RTP-level or > outside security mechanism, such as 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. " NEW "=20 > Since the splicer breaks RTP-level end-to-end security, it need to be > a trusted device that is part of the signaling context and get the > necessary security associations (e.g., SRTP crypto contexts) > established with its RTP session participants. 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. " That's better yes, but I'd still recommend not saying "trusted device" at all since that calls into question who is trusting it for what and in this case the ultimate receiver doesn't usually know the splicer is there at all and hence cannot trust it in any meaningful sense. So I'd suggest: NEW: " Since the splicer breaks RTP-level end-to-end security, it needs to be part of the signaling context and be a part of the necessary security associations (e.g., SRTP crypto contexts) established for the RTP session participants. When using the Secure Real-Time Transport Protocol (SRTP) [RFC3711], the splicer would have to be provisioned with the same security association as the main RTP sender. " >>=20 >> (2) Section 7, 4th para: You say there is a case where header >> extension encryption SHOULD be used - how would that work? If >> there's a clear way to do it that'd get interop, then why is that >> not described? If there are ways in which might or might not work, >> or if some proprietary arrangements might be needed then how is it >> ok to have a SHOULD there? I suspect that the right thing here may >> be to not pretend that that can be done but to just stick with >> saying that splicing is inherently not going to work if you use any >> real security mechanisms, or something similar. >=20 > [Rachel]: Yes. I agree. So we should use "MUST" here. >=20 > OLD: " If there is a concern about the confidentiality of the > splicing time information, header extension encryption [RFC6904] > SHOULD be used. " >=20 > NEW: >=20 > " If there is a concern about the confidentiality of the splicing > time information, header extension encryption [RFC6904] MUST be > used. " That's clearer than a SHOULD, yes. I'm still not clear if this MUST is something that just works or not though, can you clarify that? (In general, I'd not recommend we add any MUST or SHOULD at all if we're not confident that an implementer will actually write and test that code and that it'd work.) >=20 >>=20 >> (3) In discussion of RFC6828 there was some concern about possible >> creation of loops. I forget the issues though, but wanted to check >> this in case it also applies here. (See 4.5 of 6828 maybe or the >> history for that RFC in the tracker.) >>=20 >>=20 >=20 > [Rachel]: Yes, you're right. How about adding a new paragraph in > Section 7 to discuss loops? >=20 > " When implementing undetectable splicing, CSRC list, which can be > used to detect RTP-level forwarding loops as defined in Section 8.2 > of [RFC3550], may be removed to prevent receivers from detecting the > splicing occurrence. Hence, loops could occur to cause packets to > loop back to upstream of the splicer and may form a serious > denial-of-service threat. In such a case, non-RTP means MUST be used > to detect and resolve loops if the splicer does not add a CSRC list > when forwarding the RTP packet. " That does look right to me, but since I don't understand it really, I'll just believe you that it's ok:-) Are the "non-RTP means" that could be used something that'd be clear to an implementer? If so, then that'd be fine. If not, maybe you need to say what that means? >=20 >> ----------------------------------------------------------------------= >> >>=20 COMMENT: >> ----------------------------------------------------------------------= >> >> >> >> >>=20 - I agree with Alia's discuss, but suspect the ship has sailed. >> (Sadly IMO, but sailed nonetheless.) >>=20 >> - The security considerations here are similar to but not quite the >> same as those in RFC6828 which I think was the last time a similar >> document was before the IESG. I wondered if those differences were >> significant or not, it might be no harm to commpare the two (if >> that's not already been done) since they really ought be pretty >> much the same. >>=20 >=20 > [Rachel]: Not quite the same. This draft is about defining messages. > And RFC6828 is one option scenario where these messages can be used. > But people may use other models. But as suggested by Mirja, it's good > to add some words to described what RFC 6828 is about. Fair enough, Cheers, S. >=20 --------------ms010006090401090802080605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MjAx MDU4NTdaMC8GCSqGSIb3DQEJBDEiBCBf309QuRrIYoXm+N8oBjI/7WKuXcjnBcxHniFyaoHN cDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQB023WN0MIIP9tNXjkNTWfWyrE3vd2AD/MjNcFlV8zSUY5ITZDOo+my oOXvGDGhRITQ0PkUUkh5gjPjHnGzltYxzk54sMWKzwvFqyx+/E/r7nvSxrUCoq2vFCuH/69Z rQacyhXYJzVDnxpMznxCnz1JCxmQlWy8Vh8k2SJlb3qbqgSFv035G68E0RLyLNDN9A9UmVA6 m/oGZFSwb6Wzo4damcAmWfQePhSF3KJFP78u+C2AzXMD/LqZ0o1Z9g9C44jeF/oSEwDN9IFh GLYST/8FBGLMgzsVRNEC6kynxczvgVjvyY5IbAfuwuWunq+o+sV+DHb+T2gzLqZ0zI7PrU4u AAAAAAAA --------------ms010006090401090802080605-- From nobody Mon Jun 20 06:14:30 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 3358F12D0C9; Mon, 20 Jun 2016 06:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 C2LR9OKZIRX3; Mon, 20 Jun 2016 06:14:16 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 07F0212D0A7; Mon, 20 Jun 2016 06:14:16 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id t127so38967151qkf.1; Mon, 20 Jun 2016 06:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r4hwuRISoJCReA7c199+rDoJ4EtG0WUtAGW3kipBWSk=; b=WPMzYka5ZdnQcH1km6ytj5oNV9rhxVM8oW6iJaZw0wIIBk2yVTAht97YcvuTl6wolu IdjjXBYR0pcTfeGcIgqVSRadPvshxLFN45at8si2WJcvaSnQrNwYHLxy5LR4lfw7yX11 mnQeMsxO7zP8sBSXqJf5PhiyZacgU5rCNJqkzEUm96AzeUq/chYnarPb96LeUIYTadXa hzPNsbjLnjOwfl8g9aokAUsu3I5ejcMeHo57l1RuCCH91Xmhx+85loDDcN761WhkMVUg BbXj0AXslKGiMqSlIIyxs+FaolHmGLlmJJ7IokITcAFeqP+kKsUAoT6vwjFbashcGEuS wrzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r4hwuRISoJCReA7c199+rDoJ4EtG0WUtAGW3kipBWSk=; b=Yw0engVo6aCZ73LzGXTVsczbkf/BmUj3ceZGbLVcBKWFEyKJLHNZw/GZU1DrLjHRmw msmnMdirtnRTayJA41RBX9s67LzzfzvVgMp+NpHL2fti+7qn1gISWjTVRU7Rmuzm8Ph7 TmGDNkcJHa4L0HMcDAb1Zwef+dmhppELqtl5qA+h7/FDgSHrfc/gIAc/7ev+5rPg/OR4 jBhuqUvwHLdSzDWkLbVP3wXzY22iesJOOUcgr4n+ctGU/VWmOeVGwvVLs12wvVFKDmeI fdoi2reiFk5pcoTrJKbMn8MCarlmOOgfMqsXJk35h3OmuDz9Dk5FHJzGCZ4PPFflLWlW MuJQ== X-Gm-Message-State: ALyK8tJkdcrnNpNJpN4DHLYjVqpg3JUUFCowZgcu74oG/h/LRDHskOr7d7zQ13G5p6TpXg== X-Received: by 10.55.212.133 with SMTP id s5mr20318283qks.85.1466428451300; Mon, 20 Jun 2016 06:14:11 -0700 (PDT) Received: from [192.168.1.3] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id t1sm20723674qke.18.2016.06.20.06.14.10 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Jun 2016 06:14:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (12H143) In-Reply-To: <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> Date: Mon, 20 Jun 2016 09:14:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> To: "Mirja Kuehlewind (IETF)" Archived-At: Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" , Colin Perkins Subject: Re: [avtext] Kathleen Moriarty's No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT) 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, 20 Jun 2016 13:14:21 -0000 Sent from my iPhone > On Jun 20, 2016, at 5:29 AM, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi Colin, >=20 > see below. >=20 >>> Am 16.06.2016 um 00:34 schrieb Colin Perkins : >>>=20 >>> On 15 Jun 2016, at 19:37, Kathleen Moriarty wrote: >>>=20 >>> Kathleen Moriarty has entered the following ballot position for >>> draft-ietf-avtext-splicing-notification-07: No Objection >>>=20 >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification= / >>>=20 >>>=20 >>>=20 >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>>=20 >>> I strongly support Mirja's and Alia's discuss points and would like to >>> see more of a discussion of the capability to hide splicing in the >>> security considerations text. My ballot would be discuss, but they >>> pulled out the relevant sections and that would be duplication. I'd lik= e >>> to review agreed upon text though to address these concerns. =20 >>>=20 >>> I don't like the idea of enabling a MiTM, but do see the draft talks >>> about how to protect headers when this happens and confidentiality is >>> needed as well as session protection between the endpoints and the >>> splicer (which I don't like either, but you do call out the security >>> considerations of this and that's what is needed). >>=20 >> The mechanism described doesn=E2=80=99t work unless the receiver explicit= ly chooses to receive media content delivered via the splicer. I agree that t= he draft could be more clearly written, but it doesn=E2=80=99t seem to be =E2= =80=9Cenabling a MiTM=E2=80=9D attack, since the receiver opts in. >=20 > This definitely need from clarification in the draft! Yes, can we see some proposed text? =20 Thank you, Kathleen=20 >=20 > Mirja >=20 >=20 >>=20 >> --=20 >> Colin Perkins >> https://csperkins.org/ >=20 From nobody Mon Jun 20 08:50:10 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 B4FEA12D1D1; Mon, 20 Jun 2016 08:50:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160620155008.30206.24401.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2016 08:50:08 -0700 Archived-At: Cc: avtext@ietf.org, Jonathan Lennox , avtext-chairs@ietf.org, The IESG , draft-ietf-avtext-sdes-hdr-ext@ietf.org, rfc-editor@rfc-editor.org Subject: [avtext] Protocol Action: 'RTP Header Extension for RTCP Source Description Items' to Proposed Standard (draft-ietf-avtext-sdes-hdr-ext-07.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, 20 Jun 2016 15:50:08 -0000 The IESG has approved the following document: - 'RTP Header Extension for RTCP Source Description Items' (draft-ietf-avtext-sdes-hdr-ext-07.txt) as Proposed Standard This document is the product of the Audio/Video Transport Extensions Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ Technical Summary Source Description (SDES) items are normally transported in the 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. Working Group Summary The document went through working group last call. Several people commented during last call that they had read the document but had no issues with its content. Document Quality The document got good reviews from AVText members. The document generalizes a mechanism which is used by the SDP BUNDLE mechanism, which required for all WebRTC implementations. Personnel The document Shepherd is Jonathan Lennox. The Responsible Area Director is Ben Campbell. From nobody Mon Jun 20 18:21:53 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 F161912DB00; Mon, 20 Jun 2016 18:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 7JKkW6f2GZdO; Mon, 20 Jun 2016 18:21:43 -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 E4C1B12DAF6; Mon, 20 Jun 2016 18:21:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMH70573; Tue, 21 Jun 2016 01:21:38 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 21 Jun 2016 02:21:37 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 21 Jun 2016 09:21:29 +0800 From: "Huangyihong (Rachel)" To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS and COMMENT) Thread-Index: AQHRx7/AweW8aYmvaU+udtkKRDujUJ/yGB+g//+XwYCAAXRBQA== Date: Tue, 21 Jun 2016 01:21:29 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86ED87EB@nkgeml513-mbx.china.huawei.com> References: <20160616111046.10405.20492.idtracker@ietfa.amsl.com> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8585@nkgeml513-mbx.china.huawei.com> <5767CC71.4070907@cs.tcd.ie> In-Reply-To: <5767CC71.4070907@cs.tcd.ie> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.128] 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.0A090201.576896A3.0006, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f1db55e820b24b535e9658bb0ceac83e Archived-At: Cc: "draft-ietf-avtext-splicing-notification@ietf.org" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "jonathan@vidyo.com" Subject: Re: [avtext] Stephen Farrell's Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS and COMMENT) 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, 21 Jun 2016 01:21:46 -0000 SGkgU3RlcGhlbiwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkJSLA0KUmFjaGVsDQoNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTdGVwaGVuIEZhcnJlbGwgW21haWx0 bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllXQ0KPiBTZW50OiBNb25kYXksIEp1bmUgMjAsIDIw MTYgNjo1OSBQTQ0KPiBUbzogSHVhbmd5aWhvbmcgKFJhY2hlbCk7IFRoZSBJRVNHDQo+IENjOiBk cmFmdC1pZXRmLWF2dGV4dC1zcGxpY2luZy1ub3RpZmljYXRpb25AaWV0Zi5vcmc7IGF2dGV4dEBp ZXRmLm9yZzsNCj4gam9uYXRoYW5AdmlkeW8uY29tOyBhdnRleHQtY2hhaXJzQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiBTdGVwaGVuIEZhcnJlbGwncyBEaXNjdXNzIG9uDQo+IGRyYWZ0LWlldGYt YXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0wNzogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVO VCkNCj4gDQo+IA0KPiBIaXlhLA0KPiANCj4gT24gMjAvMDYvMTYgMTE6NDIsIEh1YW5neWlob25n IChSYWNoZWwpIHdyb3RlOg0KPiA+IEhpIFN0ZXBoZW4sDQo+ID4NCj4gPiBQbGVhc2Ugc2VlIG15 IHJlcGxpZXMgaW5saW5lLg0KPiA+DQo+ID4gQlIsIFJhY2hlbA0KPiA+DQo+ID4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tIEZyb206IFN0ZXBoZW4gRmFycmVsbA0KPiA+PiBbbWFpbHRvOnN0 ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdIFNlbnQ6IFRodXJzZGF5LCBKdW5lIDE2LCAyMDE2DQo+ ID4+IDc6MTEgUE0gVG86IFRoZSBJRVNHIENjOg0KPiA+PiBkcmFmdC1pZXRmLWF2dGV4dC1zcGxp Y2luZy1ub3RpZmljYXRpb25AaWV0Zi5vcmc7DQo+ID4+IGF2dGV4dC1jaGFpcnNAaWV0Zi5vcmc7 IGpvbmF0aGFuQHZpZHlvLmNvbTsgYXZ0ZXh0QGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFN0ZXBo ZW4gRmFycmVsbCdzIERpc2N1c3Mgb24NCj4gPj4gZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmct bm90aWZpY2F0aW9uLTA3OiAod2l0aCBESVNDVVNTIGFuZA0KPiA+PiBDT01NRU5UKQ0KPiA+Pg0K PiA+PiBTdGVwaGVuIEZhcnJlbGwgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9z aXRpb24gZm9yDQo+ID4+IGRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0w NzogRGlzY3Vzcw0KPiA+Pg0KPiA+PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBz dWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0bw0KPiA+PiBhbGwgZW1haWwgYWRkcmVzc2Vz IGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8NCj4gPj4gY3V0 IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+ID4+DQo+ID4+DQo+ID4+ IFBsZWFzZSByZWZlciB0bw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVu dC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwgZm9yIG1vcmUNCj4gPj4gaW5mb3JtYXRpb24gYWJvdXQg SUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gPj4NCj4gPj4NCj4gPj4gVGhl IGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3Vu ZA0KPiA+PiBoZXJlOg0KPiA+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLWF2dGV4dC1zcGxpY2luZy1ub3RpZmljYXRpb24vDQo+ID4+DQo+ID4+DQo+ID4+DQo+ ID4+DQo+ID4+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gRElTQ1VTUzoNCj4gPj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiAoMSkgU2VjdGlvbiA3LCAzcmQgcGFyYTog U2F5aW5nIHRoYXQgInNwbGljZXIgd29ya3MgYXMgYSB0cnVzdGVkIGVudGl0eSINCj4gc2VlbXMN Cj4gPj4gd3JvbmcgLSB5b3UgbmVlZCB0byBzYXkgd2hvIHRydXN0cyB3aG9tIGZvciB3aGF0IEkg dGhpbmsuIEkgYWxzbw0KPiA+PiBkb24ndCBnZXQgd2hhdCB5b3UgbWVhbiBieSBzYXlpbmcgdGhl cmUnbGwgYmUgYSBzZWN1cml0eQ0KPiA+PiBhc3NvY2lhdGlvbiBiZXR3ZWVuIHRoZSBzcGxpY2Vy IGFuZCB0aGUgcmVjZWl2ZXIsIG5vciBob3cgdGhhdA0KPiA+PiBtaWdodCBldmVyIGJlIHBvc3Np YmxlIGlmIHRoZSBzcGxpY2VyIHdhbnRzIHRvIGhpZGUgd2hhdCBpdCdzDQo+ID4+IGRvaW5nLiAg SSB0aGluayB3aGF0IHlvdSdyZSBhZnRlciBpcyBzb21lIGdlbmVyYWwgc3RhdGVtZW50IHRoYXQN Cj4gPj4gc3BsaWNpbmcgYnJlYWtzIGFsbCBzZWN1cml0eSB1bmxlc3MgYWxsIHRoZSBwYXJ0aWVz IGludm9sdmVkIHNoYXJlDQo+ID4+IHRoZSBzYW1lIHNlY3VyaXR5IGFzc29jaWF0aW9uLiBJSVJD IHRoZXJlIGlzIHRleHQgbGlrZSB0aGF0IGluDQo+ID4+IG90aGVyIFJUUCBkb2N1bWVudHMgdGhh dCBtaWdodCBiZSBjb3BpZWQgYnV0IEkgZm9yZ2V0IHRoZSBkZXRhaWwuDQo+ID4NCj4gPiBbUmFj aGVsXTogQXJlIHlvdSBsb29raW5nIGZvciBzdWNoIHNlbnRlbmNlcz8NCj4gPg0KPiA+IE9MRCAi IFNpbmNlIHNwbGljZXIgd29ya3MgYXMgYSB0cnVzdGVkIGVudGl0eSwgYW55IFJUUC1sZXZlbCBv cg0KPiA+IG91dHNpZGUgc2VjdXJpdHkgbWVjaGFuaXNtLCBzdWNoIGFzIElQc2VjW1JGQzQzMDFd IG9yIERhdGFncmFtDQo+ID4gVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IFtSRkM2MzQ3XSwgd2ls bCB1c2UgYSBzZWN1cml0eSBhc3NvY2lhdGlvbg0KPiA+IGJldHdlZW4gdGhlIHNwbGljZXIgYW5k IHRoZSByZWNlaXZlci4gV2hlbiB1c2luZyB0aGUgU2VjdXJlIFJlYWwtVGltZQ0KPiA+IFRyYW5z cG9ydCBQcm90b2NvbCAoU1JUUCkgW1JGQzM3MTFdLCB0aGUgc3BsaWNlciBjb3VsZCBiZSBwcm92 aXNpb25lZA0KPiA+IHdpdGggdGhlIHNhbWUgc2VjdXJpdHkgYXNzb2NpYXRpb24gYXMgdGhlIG1h aW4gUlRQIHNlbmRlci4gIiBORVcgIg0KPiA+IFNpbmNlIHRoZSBzcGxpY2VyIGJyZWFrcyBSVFAt bGV2ZWwgZW5kLXRvLWVuZCBzZWN1cml0eSwgaXQgbmVlZCB0byBiZQ0KPiA+IGEgdHJ1c3RlZCBk ZXZpY2UgdGhhdCBpcyBwYXJ0IG9mIHRoZSBzaWduYWxpbmcgY29udGV4dCBhbmQgZ2V0IHRoZQ0K PiA+IG5lY2Vzc2FyeSBzZWN1cml0eSBhc3NvY2lhdGlvbnMgKGUuZy4sIFNSVFAgY3J5cHRvIGNv bnRleHRzKQ0KPiA+IGVzdGFibGlzaGVkIHdpdGggaXRzIFJUUCBzZXNzaW9uIHBhcnRpY2lwYW50 cy4gV2hlbiB1c2luZyB0aGUgU2VjdXJlDQo+ID4gUmVhbC1UaW1lIFRyYW5zcG9ydCBQcm90b2Nv bCAoU1JUUCkgW1JGQzM3MTFdLCB0aGUgc3BsaWNlciBjb3VsZCBiZQ0KPiA+IHByb3Zpc2lvbmVk IHdpdGggdGhlIHNhbWUgc2VjdXJpdHkgYXNzb2NpYXRpb24gYXMgdGhlIG1haW4gUlRQDQo+ID4g c2VuZGVyLiAiDQo+IA0KPiBUaGF0J3MgYmV0dGVyIHllcywgYnV0IEknZCBzdGlsbCByZWNvbW1l bmQgbm90IHNheWluZyAidHJ1c3RlZA0KPiBkZXZpY2UiIGF0IGFsbCBzaW5jZSB0aGF0IGNhbGxz IGludG8gcXVlc3Rpb24gd2hvIGlzIHRydXN0aW5nIGl0DQo+IGZvciB3aGF0IGFuZCBpbiB0aGlz IGNhc2UgdGhlIHVsdGltYXRlIHJlY2VpdmVyIGRvZXNuJ3QgdXN1YWxseQ0KPiBrbm93IHRoZSBz cGxpY2VyIGlzIHRoZXJlIGF0IGFsbCBhbmQgaGVuY2UgY2Fubm90IHRydXN0IGl0IGluDQo+IGFu eSBtZWFuaW5nZnVsIHNlbnNlLiBTbyBJJ2Qgc3VnZ2VzdDoNCj4gDQo+IE5FVzoNCj4gDQo+ICIN Cj4gU2luY2UgdGhlIHNwbGljZXIgYnJlYWtzIFJUUC1sZXZlbCBlbmQtdG8tZW5kIHNlY3VyaXR5 LCBpdCBuZWVkcyB0bw0KPiBiZSBwYXJ0IG9mIHRoZSBzaWduYWxpbmcgY29udGV4dCBhbmQgYmUg YSBwYXJ0IG9mIHRoZQ0KPiBuZWNlc3Nhcnkgc2VjdXJpdHkgYXNzb2NpYXRpb25zIChlLmcuLCBT UlRQIGNyeXB0byBjb250ZXh0cykNCj4gZXN0YWJsaXNoZWQgZm9yIHRoZSBSVFAgc2Vzc2lvbiBw YXJ0aWNpcGFudHMuIFdoZW4gdXNpbmcgdGhlIFNlY3VyZQ0KPiBSZWFsLVRpbWUgVHJhbnNwb3J0 IFByb3RvY29sIChTUlRQKSBbUkZDMzcxMV0sIHRoZSBzcGxpY2VyIHdvdWxkDQo+IGhhdmUgdG8g YmUNCj4gcHJvdmlzaW9uZWQgd2l0aCB0aGUgc2FtZSBzZWN1cml0eSBhc3NvY2lhdGlvbiBhcyB0 aGUgbWFpbiBSVFANCj4gc2VuZGVyLg0KPiAiDQoNCltSYWNoZWxdOiBMb29rcyBiZXR0ZXIgdGhh biBtaW5lXl4uDQo+IA0KPiA+Pg0KPiA+PiAoMikgU2VjdGlvbiA3LCA0dGggcGFyYTogWW91IHNh eSB0aGVyZSBpcyBhIGNhc2Ugd2hlcmUgaGVhZGVyDQo+ID4+IGV4dGVuc2lvbiBlbmNyeXB0aW9u IFNIT1VMRCBiZSB1c2VkIC0gaG93IHdvdWxkIHRoYXQgd29yaz8gSWYNCj4gPj4gdGhlcmUncyBh IGNsZWFyIHdheSB0byBkbyBpdCB0aGF0J2QgZ2V0IGludGVyb3AsIHRoZW4gd2h5IGlzIHRoYXQN Cj4gPj4gbm90IGRlc2NyaWJlZD8gSWYgdGhlcmUgYXJlIHdheXMgaW4gd2hpY2ggbWlnaHQgb3Ig bWlnaHQgbm90IHdvcmssDQo+ID4+IG9yIGlmIHNvbWUgcHJvcHJpZXRhcnkgYXJyYW5nZW1lbnRz IG1pZ2h0IGJlIG5lZWRlZCB0aGVuIGhvdyBpcyBpdA0KPiA+PiBvayB0byBoYXZlIGEgU0hPVUxE IHRoZXJlPyBJIHN1c3BlY3QgdGhhdCB0aGUgcmlnaHQgdGhpbmcgaGVyZSBtYXkNCj4gPj4gYmUg dG8gbm90IHByZXRlbmQgdGhhdCB0aGF0IGNhbiBiZSBkb25lIGJ1dCB0byBqdXN0IHN0aWNrIHdp dGgNCj4gPj4gc2F5aW5nIHRoYXQgc3BsaWNpbmcgaXMgaW5oZXJlbnRseSBub3QgZ29pbmcgdG8g d29yayBpZiB5b3UgdXNlIGFueQ0KPiA+PiByZWFsIHNlY3VyaXR5IG1lY2hhbmlzbXMsIG9yIHNv bWV0aGluZyBzaW1pbGFyLg0KPiA+DQo+ID4gW1JhY2hlbF06IFllcy4gSSBhZ3JlZS4gU28gd2Ug c2hvdWxkIHVzZSAiTVVTVCIgaGVyZS4NCj4gPg0KPiA+IE9MRDogIiBJZiB0aGVyZSBpcyBhIGNv bmNlcm4gYWJvdXQgdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGUNCj4gPiBzcGxpY2luZyB0aW1l IGluZm9ybWF0aW9uLCBoZWFkZXIgZXh0ZW5zaW9uIGVuY3J5cHRpb24gW1JGQzY5MDRdDQo+ID4g U0hPVUxEIGJlIHVzZWQuICINCj4gPg0KPiA+IE5FVzoNCj4gPg0KPiA+ICIgSWYgdGhlcmUgaXMg YSBjb25jZXJuIGFib3V0IHRoZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlIHNwbGljaW5nDQo+ID4g dGltZSBpbmZvcm1hdGlvbiwgaGVhZGVyIGV4dGVuc2lvbiBlbmNyeXB0aW9uIFtSRkM2OTA0XSBN VVNUIGJlDQo+ID4gdXNlZC4gIg0KPiANCj4gVGhhdCdzIGNsZWFyZXIgdGhhbiBhIFNIT1VMRCwg eWVzLiBJJ20gc3RpbGwgbm90IGNsZWFyIGlmIHRoaXMNCj4gTVVTVCBpcyBzb21ldGhpbmcgdGhh dCBqdXN0IHdvcmtzIG9yIG5vdCB0aG91Z2gsIGNhbiB5b3UgY2xhcmlmeQ0KPiB0aGF0PyAoSW4g Z2VuZXJhbCwgSSdkIG5vdCByZWNvbW1lbmQgd2UgYWRkIGFueSBNVVNUIG9yIFNIT1VMRA0KPiBh dCBhbGwgaWYgd2UncmUgbm90IGNvbmZpZGVudCB0aGF0IGFuIGltcGxlbWVudGVyIHdpbGwgYWN0 dWFsbHkNCj4gd3JpdGUgYW5kIHRlc3QgdGhhdCBjb2RlIGFuZCB0aGF0IGl0J2Qgd29yay4pDQo+ IA0KDQpbUmFjaGVsXTogU29ycnksIEkgbWlzdW5kZXJzdG9vZCB5b3VyIHBvaW50LiBJIHRoaW5r IHlvdSdyZSByaWdodCBzaW5jZSBhY3R1YWxseSBJIGNhbid0IGNsYXJpZnkgdGhhdCBbUkZDNjkw NF0gaXMgdGhlIG9ubHkgd2F5IHRvIGRvIHRoaXMuIFNvIGhlcmUncyBteSBuZXcgcHJvcG9zYWw6 DQoNCiINCklmIHRoZXJlIGlzIGEgY29uY2VybiBhYm91dCB0aGUgY29uZmlkZW50aWFsaXR5IG9m IHRoZSBzcGxpY2luZyB0aW1lIGluZm9ybWF0aW9uLCB0aGUgaGVhZGVyIGV4dGVuc2lvbiBkZWZp bmVkIGluIHRoaXMgZG9jdW1lbnQgTVVTVCBiZSBhbHNvIHByb3RlY3RlZCwgZm9yIGV4YW1wbGUs IGhlYWRlciBleHRlbnNpb24gZW5jcnlwdGlvbiBbUkZDNjkwNF0gY2FuIGJlIHVzZWQgaW4gdGhp cyBjYXNlLg0KIg0KDQo+ID4NCj4gPj4NCj4gPj4gKDMpIEluIGRpc2N1c3Npb24gb2YgUkZDNjgy OCB0aGVyZSB3YXMgc29tZSBjb25jZXJuIGFib3V0IHBvc3NpYmxlDQo+ID4+IGNyZWF0aW9uIG9m IGxvb3BzLiBJIGZvcmdldCB0aGUgaXNzdWVzIHRob3VnaCwgYnV0IHdhbnRlZCB0byBjaGVjaw0K PiA+PiB0aGlzIGluIGNhc2UgaXQgYWxzbyBhcHBsaWVzIGhlcmUuICAoU2VlIDQuNSBvZiA2ODI4 IG1heWJlIG9yIHRoZQ0KPiA+PiBoaXN0b3J5IGZvciB0aGF0IFJGQyBpbiB0aGUgdHJhY2tlci4p DQo+ID4+DQo+ID4+DQo+ID4NCj4gPiBbUmFjaGVsXTogWWVzLCB5b3UncmUgcmlnaHQuIEhvdyBh Ym91dCBhZGRpbmcgYSBuZXcgcGFyYWdyYXBoIGluDQo+ID4gU2VjdGlvbiA3IHRvIGRpc2N1c3Mg bG9vcHM/DQo+ID4NCj4gPiAiIFdoZW4gaW1wbGVtZW50aW5nIHVuZGV0ZWN0YWJsZSBzcGxpY2lu ZywgQ1NSQyBsaXN0LCB3aGljaCBjYW4gYmUNCj4gPiB1c2VkIHRvIGRldGVjdCBSVFAtbGV2ZWwg Zm9yd2FyZGluZyBsb29wcyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gOC4yDQo+ID4gb2YgW1JGQzM1 NTBdLCBtYXkgYmUgcmVtb3ZlZCB0byBwcmV2ZW50IHJlY2VpdmVycyBmcm9tIGRldGVjdGluZyB0 aGUNCj4gPiBzcGxpY2luZyBvY2N1cnJlbmNlLiBIZW5jZSwgbG9vcHMgY291bGQgb2NjdXIgdG8g Y2F1c2UgcGFja2V0cyB0bw0KPiA+IGxvb3AgYmFjayB0byB1cHN0cmVhbSBvZiB0aGUgc3BsaWNl ciBhbmQgbWF5IGZvcm0gYSBzZXJpb3VzDQo+ID4gZGVuaWFsLW9mLXNlcnZpY2UgdGhyZWF0LiBJ biBzdWNoIGEgY2FzZSwgbm9uLVJUUCBtZWFucyBNVVNUIGJlIHVzZWQNCj4gPiB0byBkZXRlY3Qg YW5kIHJlc29sdmUgbG9vcHMgaWYgdGhlIHNwbGljZXIgZG9lcyBub3QgYWRkIGEgQ1NSQyBsaXN0 DQo+ID4gd2hlbiBmb3J3YXJkaW5nIHRoZSBSVFAgcGFja2V0LiAiDQo+IA0KPiBUaGF0IGRvZXMg bG9vayByaWdodCB0byBtZSwgYnV0IHNpbmNlIEkgZG9uJ3QgdW5kZXJzdGFuZCBpdCByZWFsbHks DQo+IEknbGwganVzdCBiZWxpZXZlIHlvdSB0aGF0IGl0J3Mgb2s6LSkgQXJlIHRoZSAibm9uLVJU UCBtZWFucyIgdGhhdA0KPiBjb3VsZCBiZSB1c2VkIHNvbWV0aGluZyB0aGF0J2QgYmUgY2xlYXIg dG8gYW4gaW1wbGVtZW50ZXI/IElmIHNvLA0KPiB0aGVuIHRoYXQnZCBiZSBmaW5lLiBJZiBub3Qs IG1heWJlIHlvdSBuZWVkIHRvIHNheSB3aGF0IHRoYXQgbWVhbnM/DQoNCltSYWNoZWxdOiBTdXJl LiBTZWUgZm9sbG93aW5nIHByb3Bvc2FsDQoNCiIgSW4gc3VjaCBhIGNhc2UsIG5vbi1SVFAgbWVh bnMsIGUuZy4sIHNpZ25hbGluZyBhbW9uZyBhbGwgdGhlIHBhcnRpY2lwYW50cywgTVVTVCBiZSB1 c2VkIHRvIGRldGVjdCBhbmQgcmVzb2x2ZSBsb29wcyBpZiB0aGUgc3BsaWNlciBkb2VzIG5vdCBh ZGQgYSBDU1JDIGxpc3Qgd2hlbiBmb3J3YXJkaW5nIHRoZSBSVFAgcGFja2V0LiINCg0KPiANCj4g Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+DQo+ID4+DQo+IENPTU1FTlQ6DQo+ID4+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gLSBJIGFncmVlIHdpdGgg QWxpYSdzIGRpc2N1c3MsIGJ1dCBzdXNwZWN0IHRoZSBzaGlwIGhhcyBzYWlsZWQuDQo+ID4+IChT YWRseSBJTU8sIGJ1dCBzYWlsZWQgbm9uZXRoZWxlc3MuKQ0KPiA+Pg0KPiA+PiAtIFRoZSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBoZXJlIGFyZSBzaW1pbGFyIHRvIGJ1dCBub3QgcXVpdGUgdGhl DQo+ID4+IHNhbWUgYXMgdGhvc2UgaW4gUkZDNjgyOCB3aGljaCBJIHRoaW5rIHdhcyB0aGUgbGFz dCB0aW1lIGEgc2ltaWxhcg0KPiA+PiBkb2N1bWVudCB3YXMgYmVmb3JlIHRoZSBJRVNHLiBJIHdv bmRlcmVkIGlmIHRob3NlIGRpZmZlcmVuY2VzIHdlcmUNCj4gPj4gc2lnbmlmaWNhbnQgb3Igbm90 LCBpdCBtaWdodCBiZSBubyBoYXJtIHRvIGNvbW1wYXJlIHRoZSB0d28gKGlmDQo+ID4+IHRoYXQn cyBub3QgYWxyZWFkeSBiZWVuIGRvbmUpIHNpbmNlIHRoZXkgcmVhbGx5IG91Z2h0IGJlIHByZXR0 eQ0KPiA+PiBtdWNoIHRoZSBzYW1lLg0KPiA+Pg0KPiA+DQo+ID4gW1JhY2hlbF06IE5vdCBxdWl0 ZSB0aGUgc2FtZS4gVGhpcyBkcmFmdCBpcyBhYm91dCBkZWZpbmluZyBtZXNzYWdlcy4NCj4gPiBB bmQgUkZDNjgyOCBpcyBvbmUgb3B0aW9uIHNjZW5hcmlvIHdoZXJlIHRoZXNlIG1lc3NhZ2VzIGNh biBiZSB1c2VkLg0KPiA+IEJ1dCBwZW9wbGUgbWF5IHVzZSBvdGhlciBtb2RlbHMuIEJ1dCBhcyBz dWdnZXN0ZWQgYnkgTWlyamEsIGl0J3MgZ29vZA0KPiA+IHRvIGFkZCBzb21lIHdvcmRzIHRvIGRl c2NyaWJlZCB3aGF0IFJGQyA2ODI4IGlzIGFib3V0Lg0KPiANCj4gRmFpciBlbm91Z2gsDQo+IENo ZWVycywNCj4gUy4NCj4gDQo+IA0KPiA+DQoNCg== From nobody Tue Jun 21 07:26: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 30AAC12B017; Tue, 21 Jun 2016 05:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 JaWw9w5ed0jq; Tue, 21 Jun 2016 05:58:26 -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 AF085126B6D; Tue, 21 Jun 2016 05:58:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRF68324; Tue, 21 Jun 2016 12:58:21 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 21 Jun 2016 13:58:20 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 21 Jun 2016 20:58:16 +0800 From: "Huangyihong (Rachel)" To: "kathleen.moriarty.ietf@gmail.com" , "Mirja Kuehlewind (IETF)" , Alia Atlas , Alissa Cooper , Ben Campbell Thread-Topic: [avtext] Proposed text for Alia and other AD's DISCUSS Thread-Index: AQHRy7yTYQWJfIIlDE6y4QOBr3XSUQ== Date: Tue, 21 Jun 2016 12:58:16 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> 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.78.128] 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.576939EE.0259, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 31e6bbde0aa76b8158e00767b416a3aa Archived-At: X-Mailman-Approved-At: Tue, 21 Jun 2016 07:26:50 -0700 Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" , Colin Perkins Subject: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 21 Jun 2016 12:58:29 -0000 SGkgQWxsLA0KDQpIZXJlJ3MgbXkgcHJvcG9zYWwgZm9yIGFkZHJlc3NpbmcgQWxpYSdzIGFuZCBv dGhlciBBRCdzIHNpbWlsYXIgRElTQ1VTUy4gVGhlIG1haW4gaWRlYSBpcyB0byBhZGQgYSBuZXcg c3Vic2VjdGlvbiBpbiBTZWN0aW9uIDIsIHdoaWNoIGlzIHNob3dlZCBhcyBmb2xsb3dpbmc6DQoN CiINCjIuMSBPdmVydmlldyBvZiBSVFAgU3BsaWNpbmcNCg0KICAgUlRQIFNwbGljaW5nIGlzIHRv IHJlcGxhY2Ugc29tZSBtdWx0aW1lZGlhIGNvbnRlbnQgd2l0aCBjZXJ0YWluDQogICBzdWJzdGl0 dXRpdmUgbXVsdGltZWRpYSBjb250ZW50LCBhbmQgdGhlbiBmb3J3YXJkIGl0IHRvIHRoZSByZWNl aXZlcnMNCiAgIGZvciBhIHBlcmlvZCBvZiB0aW1lLiBUaGlzIHByb2Nlc3MgaXMgYXV0aG9yaXpl ZCBieSB0aGUgc2VydmljZQ0KICAgcHJvdmlkZXIgd2hvIHNlbmRzIHRoZSBtdWx0aW1lZGlhIGNv bnRlbnQgdG8gdGhlc2UgcmVjZWl2ZXJzLiBBDQogICB0eXBpY2FsIHVzYWdlIGlzIHRoYXQgSVBU ViBzZXJ2aWNlIHByb3ZpZGVycyB1c2UgdGhlaXIgb3duIHJlZ2lvbmFsDQogICBhZHZlcnRpc2lu ZyBjb250ZW50IHRvIHJlcGxhY2UgbmF0aW9uYWwgYWR2ZXJ0aXNpbmcgY29udGVudCBwcm92aWRl ZA0KICAgYnkgdGhlIGNvbnRlbnQgcHJvdmlkZXJzLiAgDQoNCiAgIFRoZSBzcGxpY2VyIGlzIGEg bWlkZGxlYm94IGhhbmRsaW5nIFJUUCBzcGxpY2luZy4gSXQgcmVjZWl2ZXMgbWFpbg0KICAgY29u dGVudCBhbmQgc3Vic3RpdHV0aXZlIGNvbnRlbnQgc2ltdWx0YW5lb3VzbHkgYnV0IG9ubHkgY2hv b3NlcyB0bw0KICAgc2VuZCBvbmUgb2YgdGhlbSB0byB0aGUgcmVjZWl2ZXIgYXQgYW55IHBvaW50 IG9mIHRpbWUuIFdoZW4gUlRQDQogICBzcGxpY2luZyBiZWdpbnMsIHRoZSBzcGxpY2VyIHNlbmRz IHRoZSBzdWJzdGl0dXRpdmUgY29udGVudCB0byB0aGUNCiAgIHJlY2VpdmVycyBpbnN0ZWFkIG9m IHRoZSBtYWluIGNvbnRlbnQuIFdoZW4gUlRQIHNwbGljaW5nIGVuZHMsIHRoZQ0KICAgc3BsaWNl ciBzd2l0Y2hlcyBiYWNrIHRvIHNlbmRpbmcgdGhlIG1haW4gY29udGVudCB0byB0aGUgcmVjZWl2 ZXJzLg0KDQogICBUaGUgbWlkZGxlIGJveCB3b3JraW5nIGFzIHRoZSBzcGxpY2VyIGlzIGVpdGhl ciBhIHRyYW5zbGF0b3Igb3IgYQ0KICAgbWl4ZXIuIFtSRkM2ODI4XSBzcGVjaWZpZXMgYSBzcGxp Y2VyIGltcGxlbWVudGVkIGFzIGEgbWl4ZXIgdGhhdCB1c2VzDQogICBpdHMgb3duIFNTUkMsIHNl cXVlbmNlIG51bWJlciBzcGFjZSwgYW5kIHRpbWluZyBtb2RlbCB3aGVuIGdlbmVyYXRpbmcNCiAg IHRoZSBvdXRwdXQgc3RyZWFtIHRvIHJlY2VpdmVycy4gVGhlIG1peGVyIG11c3Qgbm90IGluc2Vy dCB0aGUgU1NSQyBvZg0KICAgdGhlIG1haW4gUlRQIHN0cmVhbSBvciB0aGUgU1NSQyBvZiB0aGUg c3Vic3RpdHV0aXZlIFJUUCBzdHJlYW0gaW50bw0KICAgdGhlIGNvbnRyaWJ1dGluZyBzb3VyY2Ug KENTUkMpIGxpc3QgaW4gdGhlIG91dHB1dCBtZWRpYSBzdHJlYW0gd2hlbg0KICAgaW1wbGVtZW50 aW5nIHVuZGV0ZWN0YWJsZSBzcGxpY2luZy4gU2luY2UgaXQgd29ya3MgYXMgdGhlIG1peGVyLCBp dA0KICAgc3BsaXRzIHRoZSBSVENQIGZsb3cgYmV0d2VlbiB0aGUgc2VuZGVyIGFuZCByZWNlaXZl ciBpbnRvIHR3bw0KICAgc2VwYXJhdGUgUlRDUCBsb29wcy4gVGhpcyBpbXBsaWVzIGFkZGl0aW9u YWwgY29uc2lkZXJhdGlvbnMgc2hvdWxkIGJlDQogICB0YWtlbiBpbnRvIGFjY291bnQgd2hlbiBo YW5kbGluZyBjb25nZXN0aW9uIGNvbnRyb2wsIHNlZSBTZWN0aW9uIDQuNA0KICAgb2YgW1JGQzY4 MjhdLiANCg0KICAgQSB0cmFuc2xhdG9yIFtSRkMzNTUwXSBjYW4gYWxzbyBiZSBhIHNwbGljZXIg YnkgZm9yd2FyZGluZyB0aGUgUlRQIHBhY2tldHMgd2l0aA0KICAgdGhlaXIgU1NSQ3MgaW50YWN0 LCB3aGVyZSB0aGUgY29uZ2VzdGlvbiBjb250cm9sIHJ1bnMgYmV0d2Vlbg0KICAgb3JpZ2luYWwg c2VuZGVyIGFuZCByZWNlaXZlciwgb3IgYmV0d2VlbiBzdWJzdGl0dXRpdmUgc2VuZGVyIGFuZA0K ICAgcmVjZWl2ZXIuIEluIHN1Y2ggYSBjYXNlLCB0aGUgUlRDUCBmZWVkYmFjayBtZXNzYWdlIG11 c3QgYmUgcGFzc2VkIHRvDQogICB0aGUgcmlnaHQgc2VuZGVyIHRvIGxldCB0aGUgY29uZ2VzdGlv biBjb250cm9sIHdvcmsuIEFuZCB1bmRldGVjdGFibGUNCiAgIHNwbGljaW5nIHdpbGwgbm90IGJl IGZ1bGZpbGxlZCB3aGVuIHRoZSB0cmFuc2xhdG9yIHdvcmtzIGFzIHRoZQ0KICAgc3BsaWNlci4N CiINCg0KQmVzaWRlcyB0aGF0LCBhIG5ldyB0ZXJtaW5vbG9neSBpcyBkZWZpbmVkIGluIHNlY3Rp b24gMS4xIHRvIGRlZmluZSAiVW5kZXRlY3RhYmxlIFNwbGljaW5nIiwgc2VlIGJlbG93Og0KDQoi DQpVbmRldGVjdGFibGUgU3BsaWNpbmc6DQoNClRoZSBSVFAgcmVjZWl2ZXJzIGFyZSBub3QgYWJs ZSB0byBkZXRlY3QgYW55IHNwbGljaW5nIHBvaW50cyBpbiB0aGUgUlRQIGxheWVyLiBTb21ldGlt ZXMsIHNlcnZpY2UgcHJvdmlkZXJzIG1heSByZXF1aXJlIGFuIHVuZGV0ZWN0YWJsZSBzcGxpY2lu ZyB0byBhdm9pZCB0aGUgUlRQIHJlY2VpdmVycyBmcm9tIGZpbHRlcmluZyBvdXQgdGhlIGFkdmVy dGlzZW1lbnQgY29udGVudC4NCg0KIg0KDQpZb3VyIGZ1cnRoZXIgdGhvdWdodHMgb3IgY29tbWVu dHMgYXJlIHdlbGNvbWVkLiBXZSdsbCBicmluZyBhIG5ldyB2ZXJzaW9uIGFzIHNvb24gYXMgY29u c2Vuc3VzIGlzIGFjaGlldmVkLg0KDQpCUiwNClJhY2hlbA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbToga2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20NCj4g W21haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbV0NCj4gU2VudDogTW9uZGF5 LCBKdW5lIDIwLCAyMDE2IDk6MTQgUE0NCj4gVG86IE1pcmphIEt1ZWhsZXdpbmQgKElFVEYpDQo+ IENjOiBDb2xpbiBQZXJraW5zOyBhdnRleHQtY2hhaXJzQGlldGYub3JnOw0KPiBkcmFmdC1pZXRm LWF2dGV4dC1zcGxpY2luZy1ub3RpZmljYXRpb25AaWV0Zi5vcmc7IGF2dGV4dEBpZXRmLm9yZzsg VGhlIElFU0c7DQo+IGpvbmF0aGFuQHZpZHlvLmNvbQ0KPiBTdWJqZWN0OiBSZTogW2F2dGV4dF0g S2F0aGxlZW4gTW9yaWFydHkncyBObyBPYmplY3Rpb24gb24NCj4gZHJhZnQtaWV0Zi1hdnRleHQt c3BsaWNpbmctbm90aWZpY2F0aW9uLTA3OiAod2l0aCBDT01NRU5UKQ0KPiANCj4gDQo+IA0KPiBT ZW50IGZyb20gbXkgaVBob25lDQo+IA0KPiA+IE9uIEp1biAyMCwgMjAxNiwgYXQgNToyOSBBTSwg TWlyamEgS3VlaGxld2luZCAoSUVURikgPGlldGZAa3VlaGxld2luZC5uZXQ+DQo+IHdyb3RlOg0K PiA+DQo+ID4gSGkgQ29saW4sDQo+ID4NCj4gPiBzZWUgYmVsb3cuDQo+ID4NCj4gPj4+IEFtIDE2 LjA2LjIwMTYgdW0gMDA6MzQgc2NocmllYiBDb2xpbiBQZXJraW5zIDxjc3BAY3NwZXJraW5zLm9y Zz46DQo+ID4+Pg0KPiA+Pj4gT24gMTUgSnVuIDIwMTYsIGF0IDE5OjM3LCBLYXRobGVlbiBNb3Jp YXJ0eQ0KPiA8a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiA+Pj4N Cj4gPj4+IEthdGhsZWVuIE1vcmlhcnR5IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90 IHBvc2l0aW9uIGZvcg0KPiA+Pj4gZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmctbm90aWZpY2F0 aW9uLTA3OiBObyBPYmplY3Rpb24NCj4gPj4+DQo+ID4+PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFz ZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0bw0KPiA+Pj4gYWxsIGVt YWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVl IHRvDQo+ID4+PiBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4g Pj4+DQo+ID4+Pg0KPiA+Pj4gUGxlYXNlIHJlZmVyIHRvDQo+ID4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gPj4+IGZvciBtb3Jl IGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+ ID4+Pg0KPiA+Pj4NCj4gPj4+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3Qg cG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gPj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhDQo+ID4+PiB0 aW9uLw0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+IC0tDQo+ ID4+PiBDT01NRU5UOg0KPiA+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+IC0tDQo+ID4+Pg0KPiA+Pj4g SSBzdHJvbmdseSBzdXBwb3J0IE1pcmphJ3MgYW5kIEFsaWEncyBkaXNjdXNzIHBvaW50cyBhbmQg d291bGQgbGlrZQ0KPiA+Pj4gdG8gc2VlIG1vcmUgb2YgYSBkaXNjdXNzaW9uIG9mIHRoZSBjYXBh YmlsaXR5IHRvIGhpZGUgc3BsaWNpbmcgaW4NCj4gPj4+IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyB0ZXh0LiAgTXkgYmFsbG90IHdvdWxkIGJlIGRpc2N1c3MsIGJ1dA0KPiA+Pj4gdGhleSBw dWxsZWQgb3V0IHRoZSByZWxldmFudCBzZWN0aW9ucyBhbmQgdGhhdCB3b3VsZCBiZSBkdXBsaWNh dGlvbi4NCj4gPj4+IEknZCBsaWtlIHRvIHJldmlldyBhZ3JlZWQgdXBvbiB0ZXh0IHRob3VnaCB0 byBhZGRyZXNzIHRoZXNlIGNvbmNlcm5zLg0KPiA+Pj4NCj4gPj4+IEkgZG9uJ3QgbGlrZSB0aGUg aWRlYSBvZiBlbmFibGluZyBhIE1pVE0sIGJ1dCBkbyBzZWUgdGhlIGRyYWZ0IHRhbGtzDQo+ID4+ PiBhYm91dCBob3cgdG8gcHJvdGVjdCBoZWFkZXJzIHdoZW4gdGhpcyBoYXBwZW5zIGFuZCBjb25m aWRlbnRpYWxpdHkNCj4gPj4+IGlzIG5lZWRlZCBhcyB3ZWxsIGFzIHNlc3Npb24gcHJvdGVjdGlv biBiZXR3ZWVuIHRoZSBlbmRwb2ludHMgYW5kDQo+ID4+PiB0aGUgc3BsaWNlciAod2hpY2ggSSBk b24ndCBsaWtlIGVpdGhlciwgYnV0IHlvdSBkbyBjYWxsIG91dCB0aGUNCj4gPj4+IHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIG9mIHRoaXMgYW5kIHRoYXQncyB3aGF0IGlzIG5lZWRlZCkuDQo+ID4+ DQo+ID4+IFRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGRvZXNu4oCZdCB3b3JrIHVubGVzcyB0aGUg cmVjZWl2ZXIgZXhwbGljaXRseQ0KPiBjaG9vc2VzIHRvIHJlY2VpdmUgbWVkaWEgY29udGVudCBk ZWxpdmVyZWQgdmlhIHRoZSBzcGxpY2VyLiBJIGFncmVlIHRoYXQgdGhlDQo+IGRyYWZ0IGNvdWxk IGJlIG1vcmUgY2xlYXJseSB3cml0dGVuLCBidXQgaXQgZG9lc27igJl0IHNlZW0gdG8gYmUg4oCc ZW5hYmxpbmcgYQ0KPiBNaVRN4oCdIGF0dGFjaywgc2luY2UgdGhlIHJlY2VpdmVyIG9wdHMgaW4u DQo+ID4NCj4gPiBUaGlzIGRlZmluaXRlbHkgbmVlZCBmcm9tIGNsYXJpZmljYXRpb24gaW4gdGhl IGRyYWZ0IQ0KPiANCj4gWWVzLCBjYW4gd2Ugc2VlIHNvbWUgcHJvcG9zZWQgdGV4dD8NCj4gDQo+ IFRoYW5rIHlvdSwNCj4gS2F0aGxlZW4NCj4gPg0KPiA+IE1pcmphDQo+ID4NCj4gPg0KPiA+Pg0K PiA+PiAtLQ0KPiA+PiBDb2xpbiBQZXJraW5zDQo+ID4+IGh0dHBzOi8vY3NwZXJraW5zLm9yZy8N Cj4gPg0K From nobody Tue Jun 21 10:02:39 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 4E10A12DB0D; Tue, 21 Jun 2016 10:02:38 -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.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160621170238.17134.15811.idtracker@ietfa.amsl.com> Date: Tue, 21 Jun 2016 10:02:38 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rid-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 17:02:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions of the IETF. Title : RTP Stream Identifier Source Description (SDES) Authors : Adam Roach Suhas Nandakumar Peter Thatcher Filename : draft-ietf-avtext-rid-03.txt Pages : 7 Date : 2016-06-21 Abstract: This document defines and registers two new RTCP SDES items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream a redundancy RTP stream is to be used to repair. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-rid-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rid-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 21 12:36:59 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 D97F912DD1F; Tue, 21 Jun 2016 12:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPQeWRj-W3b8; Tue, 21 Jun 2016 12:32:31 -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 B9B0B12DD5B; Tue, 21 Jun 2016 12:32:30 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5LJWCl1091561 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 21 Jun 2016 14:32:12 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: Huangyihong Date: Tue, 21 Jun 2016 14:32:11 -0500 Message-ID: <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@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: X-Mailman-Approved-At: Tue, 21 Jun 2016 12:36:57 -0700 Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" , Alia Atlas , Colin Perkins Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 21 Jun 2016 19:32:35 -0000 Hi, some comments inline: On 21 Jun 2016, at 7:58, Huangyihong (Rachel) wrote: > Hi All, > > Here's my proposal for addressing Alia's and other AD's similar > DISCUSS. The main idea is to add a new subsection in Section 2, which > is showed as following: > > " > 2.1 Overview of RTP Splicing > > RTP Splicing is to replace some multimedia content with certain > substitutive multimedia content, and then forward it to the > receivers > for a period of time. This process is authorized by the service > provider who sends the multimedia content to these receivers. A > typical usage is that IPTV service providers use their own regional > advertising content to replace national advertising content > provided > by the content providers. I think this could be strengthened a bit. IIUC, this mechanism assumes the splicing interval is sent _by_ the main content provider. That is, this mechanism only works with the permission of the content provider. If they don't consent, they simply won't send the splicing interval. This relationship might be more clear if the example talked about the main content provider offering a time window for the regional advertising insert, rather than about replacing national advertising. While that might in fact replace national content, it should be clear that the main provider _intends_ for the insert to happen. > > The splicer is a middlebox handling RTP splicing. It receives main > content and substitutive content simultaneously but only chooses to > send one of them to the receiver at any point of time. When RTP > splicing begins, the splicer sends the substitutive content to the > receivers instead of the main content. When RTP splicing ends, the > splicer switches back to sending the main content to the receivers. > > The middle box working as the splicer is either a translator or a > mixer. [RFC6828] specifies a splicer implemented as a mixer that > uses > its own SSRC, sequence number space, and timing model when > generating > the output stream to receivers. The mixer must not insert the SSRC > of > the main RTP stream or the SSRC of the substitutive RTP stream into > the contributing source (CSRC) list in the output media stream when > implementing undetectable splicing. I suggest promoting that last sentence a bit, and removing any hint of 2119 language. For example: "The splicer, operating on behalf of the content provider, may not wish to reveal that splicing has occurred. In this case, the splicer does not insert the SSRCs from either the main or substitutive RTP streams into the CSRC list in the resulting output media stream.." > Since it works as the mixer, it > splits the RTCP flow between the sender and receiver into two > separate RTCP loops. This implies additional considerations should > be > taken into account when handling congestion control, see Section > 4.4 > of [RFC6828]. > > A translator [RFC3550] can also be a splicer by forwarding the RTP > packets with > their SSRCs intact, where the congestion control runs between > original sender and receiver, or between substitutive sender and > receiver. In such a case, the RTCP feedback message must be passed > to > the right sender to let the congestion control work. And > undetectable > splicing will not be fulfilled when the translator works as the > splicer. > " > > Besides that, a new terminology is defined in section 1.1 to define > "Undetectable Splicing", see below: > > " > Undetectable Splicing: > > The RTP receivers are not able to detect any splicing points in the > RTP layer. Sometimes, service providers may require an undetectable > splicing to avoid the RTP receivers from filtering out the > advertisement content. That particular motivation gives me a bit of heartburn. But I think the reality is that the content provider wants to provide an apparently continuous stream, and they don't think the the splicing details are the business of the recipient (any more than the splices that occur in the original media stream incident to the normal editing of the content.) > > " > > Your further thoughts or comments are welcomed. We'll bring a new > version as soon as consensus is achieved. > > BR, > Rachel > > >> -----Original Message----- >> From: kathleen.moriarty.ietf@gmail.com >> [mailto:kathleen.moriarty.ietf@gmail.com] >> Sent: Monday, June 20, 2016 9:14 PM >> To: Mirja Kuehlewind (IETF) >> Cc: Colin Perkins; avtext-chairs@ietf.org; >> draft-ietf-avtext-splicing-notification@ietf.org; avtext@ietf.org; >> The IESG; >> jonathan@vidyo.com >> Subject: Re: [avtext] Kathleen Moriarty's No Objection on >> draft-ietf-avtext-splicing-notification-07: (with COMMENT) >> >> >> >> Sent from my iPhone >> >>> On Jun 20, 2016, at 5:29 AM, Mirja Kuehlewind (IETF) >>> >> wrote: >>> >>> Hi Colin, >>> >>> see below. >>> >>>>> Am 16.06.2016 um 00:34 schrieb Colin Perkins : >>>>> >>>>> On 15 Jun 2016, at 19:37, Kathleen Moriarty >> wrote: >>>>> >>>>> Kathleen Moriarty has entered the following ballot position for >>>>> draft-ietf-avtext-splicing-notification-07: No Objection >>>>> >>>>> When responding, please keep the subject line intact and reply to >>>>> all email addresses included in the To and CC lines. (Feel free to >>>>> cut this introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer to >>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found >>>>> here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notifica >>>>> tion/ >>>>> >>>>> >>>>> >>>>> -------------------------------------------------------------------- >>>>> -- >>>>> COMMENT: >>>>> -------------------------------------------------------------------- >>>>> -- >>>>> >>>>> I strongly support Mirja's and Alia's discuss points and would >>>>> like >>>>> to see more of a discussion of the capability to hide splicing in >>>>> the security considerations text. My ballot would be discuss, but >>>>> they pulled out the relevant sections and that would be >>>>> duplication. >>>>> I'd like to review agreed upon text though to address these >>>>> concerns. >>>>> >>>>> I don't like the idea of enabling a MiTM, but do see the draft >>>>> talks >>>>> about how to protect headers when this happens and confidentiality >>>>> is needed as well as session protection between the endpoints and >>>>> the splicer (which I don't like either, but you do call out the >>>>> security considerations of this and that's what is needed). >>>> >>>> The mechanism described doesn’t work unless the receiver >>>> explicitly >> chooses to receive media content delivered via the splicer. I agree >> that the >> draft could be more clearly written, but it doesn’t seem to be >> “enabling a >> MiTM” attack, since the receiver opts in. >>> >>> This definitely need from clarification in the draft! >> >> Yes, can we see some proposed text? >> >> Thank you, >> Kathleen >>> >>> Mirja >>> >>> >>>> >>>> -- >>>> Colin Perkins >>>> https://csperkins.org/ >>> From nobody Tue Jun 21 14:09:36 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 9050912D79E; Tue, 21 Jun 2016 14:09:34 -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.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160621210934.17197.26642.idtracker@ietfa.amsl.com> Date: Tue, 21 Jun 2016 14:09:34 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rid-04.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: Tue, 21 Jun 2016 21:09:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions of the IETF. Title : RTP Stream Identifier Source Description (SDES) Authors : Adam Roach Suhas Nandakumar Peter Thatcher Filename : draft-ietf-avtext-rid-04.txt Pages : 7 Date : 2016-06-21 Abstract: This document defines and registers two new RTCP SDES items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream a redundancy RTP stream is to be used to repair. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-rid-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rid-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/ From nobody Tue Jun 21 14:39: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 A5C2412DE27; Tue, 21 Jun 2016 14:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] 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 pwRf1Mu6FkMo; Tue, 21 Jun 2016 14:36:29 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 B433D12DA3E; Tue, 21 Jun 2016 14:36:28 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id a186so40406975qkf.0; Tue, 21 Jun 2016 14:36:28 -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=JyAD8K6+xjZwDglNpJZJaS/N7GrSGk5Yi4szMqirygo=; b=ETwTNMA4tsdZJXgb0terWBiPbjwuSOSIs4HkMvmfXzwJ+Reg35AMZXDLkMRwCEkjxa Wjb/7eaTSPer75FSsd78+i+IDUHx5j1h/7S2grl/JbTVTrohfWornJSuyYusWx9H4yh+ ELDoH9ilPLNDXpQPHev3nVREtGPuCwN0UWrOkNxqjSNUYJqqGaNvWRAxkMmo+hnFVNKk VeQYNTlNHLgxOuROVUqQPr8Py5niExyWh044zKd4/9NqfM5BBum0fq13QthOHyimDLfa I449NBcmTxcKgvGFV4XzrhjUVZY4BAld/dLLtzTQRQvukaLCV8bBBP8LtjavF66hN+cs yF2Q== 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=JyAD8K6+xjZwDglNpJZJaS/N7GrSGk5Yi4szMqirygo=; b=lHEFQ1tNsFGssl6JNNPSasgmtPCk3FxbqmT4EkLGuz50de5sSYJodrmKRty8ZJke5h ZG3UAVzZONSWu0FDX0ggojc/3aQE+u709H2NPopCWcSH+YEazGvBo3TXa1iHa0R3ADkg JlJmyXe2aaNYV3u4T/gSHNaUQ3HOsebY1RnirYKCeQhWzAY6tCIhQgLmpd9vqQBdagEg uuz6sgksa7q3Yugu6mSEBukqH8lKndZU4n+t76+H+CwZnfUJdCU9QDKVto4F3BbrmdtM M8ikhOn+UftWq5NUyrxGbJRiA8P39pkR5MC62kSx9mmZW4N1wv7X27j4g2DSB3X+Yf/n MY0A== X-Gm-Message-State: ALyK8tLe+t9sggYaob2zKqIwmDQ8nlZim7sV53Cb+fByxBRjMrRlnzMVZEhPiMJ9ma6LLlT1SpZJ66UONozxwg== X-Received: by 10.55.160.132 with SMTP id j126mr31872077qke.108.1466544987631; Tue, 21 Jun 2016 14:36:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.57.81 with HTTP; Tue, 21 Jun 2016 14:36:26 -0700 (PDT) In-Reply-To: <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> From: Alia Atlas Date: Tue, 21 Jun 2016 17:36:26 -0400 Message-ID: To: Ben Campbell Content-Type: multipart/alternative; boundary=001a114fca4a08f69d0535d09dd2 Archived-At: X-Mailman-Approved-At: Tue, 21 Jun 2016 14:39:54 -0700 Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" , Colin Perkins Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 21 Jun 2016 21:36:32 -0000 --001a114fca4a08f69d0535d09dd2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is useful clarification, but it still contains no hint that the receiver has agreed. It doesn't alter the SHOULD or MUSTs associated with hiding this from receivers. I am looking for a balanced explanation - the motivations here give me more than heartburn. It's clearly deciding for the content provider. Regards, Alia On Tue, Jun 21, 2016 at 3:32 PM, Ben Campbell wrote: > Hi, some comments inline: > > On 21 Jun 2016, at 7:58, Huangyihong (Rachel) wrote: > > Hi All, >> >> Here's my proposal for addressing Alia's and other AD's similar DISCUSS. >> The main idea is to add a new subsection in Section 2, which is showed a= s >> following: >> >> " >> 2.1 Overview of RTP Splicing >> >> RTP Splicing is to replace some multimedia content with certain >> substitutive multimedia content, and then forward it to the receivers >> for a period of time. This process is authorized by the service >> provider who sends the multimedia content to these receivers. A >> typical usage is that IPTV service providers use their own regional >> advertising content to replace national advertising content provided >> by the content providers. >> > > I think this could be strengthened a bit. IIUC, this mechanism assumes th= e > splicing interval is sent _by_ the main content provider. That is, this > mechanism only works with the permission of the content provider. If they > don't consent, they simply won't send the splicing interval. > > This relationship might be more clear if the example talked about the mai= n > content provider offering a time window for the regional advertising > insert, rather than about replacing national advertising. While that migh= t > in fact replace national content, it should be clear that the main provid= er > _intends_ for the insert to happen. > > >> The splicer is a middlebox handling RTP splicing. It receives main >> content and substitutive content simultaneously but only chooses to >> send one of them to the receiver at any point of time. When RTP >> splicing begins, the splicer sends the substitutive content to the >> receivers instead of the main content. When RTP splicing ends, the >> splicer switches back to sending the main content to the receivers. >> >> The middle box working as the splicer is either a translator or a >> mixer. [RFC6828] specifies a splicer implemented as a mixer that uses >> its own SSRC, sequence number space, and timing model when generating >> the output stream to receivers. The mixer must not insert the SSRC of >> the main RTP stream or the SSRC of the substitutive RTP stream into >> the contributing source (CSRC) list in the output media stream when >> implementing undetectable splicing. >> > > I suggest promoting that last sentence a bit, and removing any hint of > 2119 language. For example: > > "The splicer, operating on behalf of the content provider, may not wish t= o > reveal that splicing has occurred. In this case, the splicer does not > insert the SSRCs from either the main or substitutive RTP streams into th= e > CSRC list in the resulting output media stream.." > > Since it works as the mixer, it >> splits the RTCP flow between the sender and receiver into two >> separate RTCP loops. This implies additional considerations should be >> taken into account when handling congestion control, see Section 4.4 >> of [RFC6828]. >> >> A translator [RFC3550] can also be a splicer by forwarding the RTP >> packets with >> their SSRCs intact, where the congestion control runs between >> original sender and receiver, or between substitutive sender and >> receiver. In such a case, the RTCP feedback message must be passed to >> the right sender to let the congestion control work. And undetectable >> splicing will not be fulfilled when the translator works as the >> splicer. >> " >> >> Besides that, a new terminology is defined in section 1.1 to define >> "Undetectable Splicing", see below: >> >> " >> Undetectable Splicing: >> >> The RTP receivers are not able to detect any splicing points in the RTP >> layer. Sometimes, service providers may require an undetectable splicing= to >> avoid the RTP receivers from filtering out the advertisement content. >> > > That particular motivation gives me a bit of heartburn. But I think the > reality is that the content provider wants to provide an apparently > continuous stream, and they don't think the the splicing details are the > business of the recipient (any more than the splices that occur in the > original media stream incident to the normal editing of the content.) > > > >> " >> >> Your further thoughts or comments are welcomed. We'll bring a new versio= n >> as soon as consensus is achieved. >> >> BR, >> Rachel >> >> >> -----Original Message----- >>> From: kathleen.moriarty.ietf@gmail.com >>> [mailto:kathleen.moriarty.ietf@gmail.com] >>> Sent: Monday, June 20, 2016 9:14 PM >>> To: Mirja Kuehlewind (IETF) >>> Cc: Colin Perkins; avtext-chairs@ietf.org; >>> draft-ietf-avtext-splicing-notification@ietf.org; avtext@ietf.org; The >>> IESG; >>> jonathan@vidyo.com >>> Subject: Re: [avtext] Kathleen Moriarty's No Objection on >>> draft-ietf-avtext-splicing-notification-07: (with COMMENT) >>> >>> >>> >>> Sent from my iPhone >>> >>> On Jun 20, 2016, at 5:29 AM, Mirja Kuehlewind (IETF) < >>>> ietf@kuehlewind.net> >>>> >>> wrote: >>> >>>> >>>> Hi Colin, >>>> >>>> see below. >>>> >>>> Am 16.06.2016 um 00:34 schrieb Colin Perkins : >>>>>> >>>>>> On 15 Jun 2016, at 19:37, Kathleen Moriarty >>>>>> >>>>> wrote: >>> >>>> >>>>>> Kathleen Moriarty has entered the following ballot position for >>>>>> draft-ietf-avtext-splicing-notification-07: No Objection >>>>>> >>>>>> When responding, please keep the subject line intact and reply to >>>>>> all email addresses included in the To and CC lines. (Feel free to >>>>>> cut this introductory paragraph, however.) >>>>>> >>>>>> >>>>>> Please refer to >>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>> >>>>>> >>>>>> The document, along with other ballot positions, can be found here: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notifica >>>>>> tion/ >>>>>> >>>>>> >>>>>> >>>>>> -------------------------------------------------------------------- >>>>>> -- >>>>>> COMMENT: >>>>>> -------------------------------------------------------------------- >>>>>> -- >>>>>> >>>>>> I strongly support Mirja's and Alia's discuss points and would like >>>>>> to see more of a discussion of the capability to hide splicing in >>>>>> the security considerations text. My ballot would be discuss, but >>>>>> they pulled out the relevant sections and that would be duplication. >>>>>> I'd like to review agreed upon text though to address these concerns= . >>>>>> >>>>>> I don't like the idea of enabling a MiTM, but do see the draft talks >>>>>> about how to protect headers when this happens and confidentiality >>>>>> is needed as well as session protection between the endpoints and >>>>>> the splicer (which I don't like either, but you do call out the >>>>>> security considerations of this and that's what is needed). >>>>>> >>>>> >>>>> The mechanism described doesn=E2=80=99t work unless the receiver expl= icitly >>>>> >>>> chooses to receive media content delivered via the splicer. I agree >>> that the >>> draft could be more clearly written, but it doesn=E2=80=99t seem to be = =E2=80=9Cenabling >>> a >>> MiTM=E2=80=9D attack, since the receiver opts in. >>> >>>> >>>> This definitely need from clarification in the draft! >>>> >>> >>> Yes, can we see some proposed text? >>> >>> Thank you, >>> Kathleen >>> >>>> >>>> Mirja >>>> >>>> >>>> >>>>> -- >>>>> Colin Perkins >>>>> https://csperkins.org/ >>>>> >>>> >>>> --001a114fca4a08f69d0535d09dd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is useful clarification, but it still contains no hin= t that the receiver has agreed.=C2=A0 It doesn't
alter the SHOULD o= r MUSTs associated with hiding this from receivers.

I am looking for a balanced explanation - the motivations here give me mo= re than heartburn.
It's clearly deciding for the content prov= ider.

Regards,
Alia

On Tue, Jun 21, 2016 at 3:= 32 PM, Ben Campbell <ben@nostrum.com> wrote:
Hi, some comments inline:

On 21 Jun 2016, at 7:58, Huangyihong (Rachel) wrote:

Hi All,

Here's my proposal for addressing Alia's and other AD's similar= DISCUSS. The main idea is to add a new subsection in Section 2, which is s= howed as following:

"
2.1 Overview of RTP Splicing

=C2=A0 =C2=A0RTP Splicing is to replace some multimedia content with certai= n
=C2=A0 =C2=A0substitutive multimedia content, and then forward it to the re= ceivers
=C2=A0 =C2=A0for a period of time. This process is authorized by the servic= e
=C2=A0 =C2=A0provider who sends the multimedia content to these receivers. = A
=C2=A0 =C2=A0typical usage is that IPTV service providers use their own reg= ional
=C2=A0 =C2=A0advertising content to replace national advertising content pr= ovided
=C2=A0 =C2=A0by the content providers.

 I think this could be strengthened a bit. IIUC, this mechanism assumes the = splicing interval is sent _by_ the main content provider. That is, this mec= hanism only works with the permission of the content provider. If they don&= #39;t consent, they simply won't send the splicing interval.

This relationship might be more clear if the example talked about the main = content provider offering a time window for the regional advertising insert= , rather than about replacing national advertising. While that might in fac= t replace national content, it should be clear that the main provider _inte= nds_ for the insert to happen.


=C2=A0 =C2=A0The splicer is a middlebox handling RTP splicing. It receives = main
=C2=A0 =C2=A0content and substitutive content simultaneously but only choos= es to
=C2=A0 =C2=A0send one of them to the receiver at any point of time. When RT= P
=C2=A0 =C2=A0splicing begins, the splicer sends the substitutive content to= the
=C2=A0 =C2=A0receivers instead of the main content. When RTP splicing ends,= the
=C2=A0 =C2=A0splicer switches back to sending the main content to the recei= vers.

=C2=A0 =C2=A0The middle box working as the splicer is either a translator o= r a
=C2=A0 =C2=A0mixer. [RFC6828] specifies a splicer implemented as a mixer th= at uses
=C2=A0 =C2=A0its own SSRC, sequence number space, and timing model when gen= erating
=C2=A0 =C2=A0the output stream to receivers. The mixer must not insert the = SSRC of
=C2=A0 =C2=A0the main RTP stream or the SSRC of the substitutive RTP stream= into
=C2=A0 =C2=A0the contributing source (CSRC) list in the output media stream= when
=C2=A0 =C2=A0implementing undetectable splicing.

 I suggest promoting that last sentence a bit, and removing any hint of 2119= language. For example:

"The splicer, operating on behalf of the content provider, may not wis= h to reveal that splicing has occurred. In this case, the splicer does not = insert the SSRCs from either the main or substitutive RTP streams into the = CSRC list in the resulting output media stream.."

Since it works as the mixer, it
=C2=A0 =C2=A0splits the RTCP flow between the sender and receiver into two<= br> =C2=A0 =C2=A0separate RTCP loops. This implies additional considerations sh= ould be
=C2=A0 =C2=A0taken into account when handling congestion control, see Secti= on 4.4
=C2=A0 =C2=A0of [RFC6828].

=C2=A0 =C2=A0A translator [RFC3550] can also be a splicer by forwarding the= RTP packets with
=C2=A0 =C2=A0their SSRCs intact, where the congestion control runs between<= br> =C2=A0 =C2=A0original sender and receiver, or between substitutive sender a= nd
=C2=A0 =C2=A0receiver. In such a case, the RTCP feedback message must be pa= ssed to
=C2=A0 =C2=A0the right sender to let the congestion control work. And undet= ectable
=C2=A0 =C2=A0splicing will not be fulfilled when the translator works as th= e
=C2=A0 =C2=A0splicer.
"

Besides that, a new terminology is defined in section 1.1 to define "U= ndetectable Splicing", see below:

"
Undetectable Splicing:

The RTP receivers are not able to detect any splicing points in the RTP lay= er. Sometimes, service providers may require an undetectable splicing to av= oid the RTP receivers from filtering out the advertisement content.

 That particular motivation gives me a bit of heartburn. But I think the rea= lity is that the content provider wants to provide an apparently continuous= stream, and they don't think the the splicing details are the business= of the recipient (any more than the splices that occur in the original med= ia stream incident to the normal editing of the content.)



"

Your further thoughts or comments are welcomed. We'll bring a new versi= on as soon as consensus is achieved.

BR,
Rachel


-----Original Message-----
From: kathleen.moriarty.ietf@gmail.com
[mailto:kathleen.moriarty.ietf@gmail.com]
Sent: Monday, June 20, 2016 9:14 PM
To: Mirja Kuehlewind (IETF)
Cc: Colin Perkins; avtext-chairs@ietf.org;
draft-ietf-avtext-splicing-notification@ietf.org; avtext@ietf.org; The IESG= ;
jonathan@vidyo.com<= /a>
Subject: Re: [avtext] Kathleen Moriarty's No Objection on
draft-ietf-avtext-splicing-notification-07: (with COMMENT)



Sent from my iPhone

On Jun 20, 2016, at 5:29 AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>
wrote:

Hi Colin,

see below.

Am 16.06.2016 um 00:34 schrieb Colin Perkins <csp@csperkins.org>:

On 15 Jun 2016, at 19:37, Kathleen Moriarty
<k= athleen.moriarty.ietf@gmail.com> wrote:

Kathleen Moriarty has entered the following ballot position for
draft-ietf-avtext-splicing-notification-07: No Objection

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


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


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc= /draft-ietf-avtext-splicing-notifica
tion/



--------------------------------------------------------------------
--
COMMENT:
--------------------------------------------------------------------
--

I strongly support Mirja's and Alia's discuss points and would like=
to see more of a discussion of the capability to hide splicing in
the security considerations text.=C2=A0 My ballot would be discuss, but
they pulled out the relevant sections and that would be duplication.
I'd like to review agreed upon text though to address these concerns.
I don't like the idea of enabling a MiTM, but do see the draft talks about how to protect headers when this happens and confidentiality
is needed as well as session protection between the endpoints and
the splicer (which I don't like either, but you do call out the
security considerations of this and that's what is needed).

The mechanism described doesn=E2=80=99t work unless the receiver explicitly=
chooses to receive media content delivered via the splicer. I agree that th= e
draft could be more clearly written, but it doesn=E2=80=99t seem to be =E2= =80=9Cenabling a
MiTM=E2=80=9D attack, since the receiver opts in.

This definitely need from clarification in the draft!

Yes, can we see some proposed text?

Thank you,
Kathleen

Mirja



--
Colin Perkins
htt= ps://csperkins.org/


--001a114fca4a08f69d0535d09dd2-- From nobody Tue Jun 21 14:50:33 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE5B12D63E; Tue, 21 Jun 2016 14:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyGlLXif77ZF; Tue, 21 Jun 2016 14:45:52 -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 745AE12DA70; Tue, 21 Jun 2016 14:45:52 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5LLjZTB003905 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 21 Jun 2016 16:45:36 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Alia Atlas" Date: Tue, 21 Jun 2016 16:45:35 -0500 Message-ID: In-Reply-To: References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.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: X-Mailman-Approved-At: Tue, 21 Jun 2016 14:50:33 -0700 Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" , Colin Perkins Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 21 Jun 2016 21:45:55 -0000 On 21 Jun 2016, at 16:36, Alia Atlas wrote: > This is useful clarification, but it still contains no hint that the > receiver has agreed. It doesn't > alter the SHOULD or MUSTs associated with hiding this from receivers. > > I am looking for a balanced explanation - the motivations here give me > more > than heartburn. > It's clearly deciding for the content provider. I'm slightly confused. Why does the receiver have an interest in how the content provider composes content? This is not (or at least should not be) a case where A produces content, B messes with it, and C wanted to receive the originally, un-messed-with content. It's a case where A provides content that happens to have real-time insertions at a splicer operating on A's behalf, and C receives it. One assumes C has the right to go somewhere else for their content, or maybe request a different, non-spliced stream if A is willing to provide it. But otherwise, why does C an interest in how A composes the stream? I suppose there's a possibility for this to be truly abused--but the notification comes in the media stream between the content provider and the splicer, not from a third party. Obviously there are security considerations to make sure that's really true, but that is true for any media stream. (It's entirely possible, nay even likely, that I am missing something. Maybe even a whole use case that looks more like a MiTM?) Thanks! Ben. > > Regards, > Alia > > On Tue, Jun 21, 2016 at 3:32 PM, Ben Campbell wrote: > >> Hi, some comments inline: >> >> On 21 Jun 2016, at 7:58, Huangyihong (Rachel) wrote: >> >> Hi All, >>> >>> Here's my proposal for addressing Alia's and other AD's similar >>> DISCUSS. >>> The main idea is to add a new subsection in Section 2, which is >>> showed as >>> following: >>> >>> " >>> 2.1 Overview of RTP Splicing >>> >>> RTP Splicing is to replace some multimedia content with certain >>> substitutive multimedia content, and then forward it to the >>> receivers >>> for a period of time. This process is authorized by the service >>> provider who sends the multimedia content to these receivers. A >>> typical usage is that IPTV service providers use their own >>> regional >>> advertising content to replace national advertising content >>> provided >>> by the content providers. >>> >> >> I think this could be strengthened a bit. IIUC, this mechanism >> assumes the >> splicing interval is sent _by_ the main content provider. That is, >> this >> mechanism only works with the permission of the content provider. If >> they >> don't consent, they simply won't send the splicing interval. >> >> This relationship might be more clear if the example talked about the >> main >> content provider offering a time window for the regional advertising >> insert, rather than about replacing national advertising. While that >> might >> in fact replace national content, it should be clear that the main >> provider >> _intends_ for the insert to happen. >> >> >>> The splicer is a middlebox handling RTP splicing. It receives >>> main >>> content and substitutive content simultaneously but only chooses >>> to >>> send one of them to the receiver at any point of time. When RTP >>> splicing begins, the splicer sends the substitutive content to >>> the >>> receivers instead of the main content. When RTP splicing ends, >>> the >>> splicer switches back to sending the main content to the >>> receivers. >>> >>> The middle box working as the splicer is either a translator or a >>> mixer. [RFC6828] specifies a splicer implemented as a mixer that >>> uses >>> its own SSRC, sequence number space, and timing model when >>> generating >>> the output stream to receivers. The mixer must not insert the >>> SSRC of >>> the main RTP stream or the SSRC of the substitutive RTP stream >>> into >>> the contributing source (CSRC) list in the output media stream >>> when >>> implementing undetectable splicing. >>> >> >> I suggest promoting that last sentence a bit, and removing any hint >> of >> 2119 language. For example: >> >> "The splicer, operating on behalf of the content provider, may not >> wish to >> reveal that splicing has occurred. In this case, the splicer does not >> insert the SSRCs from either the main or substitutive RTP streams >> into the >> CSRC list in the resulting output media stream.." >> >> Since it works as the mixer, it >>> splits the RTCP flow between the sender and receiver into two >>> separate RTCP loops. This implies additional considerations >>> should be >>> taken into account when handling congestion control, see Section >>> 4.4 >>> of [RFC6828]. >>> >>> A translator [RFC3550] can also be a splicer by forwarding the >>> RTP >>> packets with >>> their SSRCs intact, where the congestion control runs between >>> original sender and receiver, or between substitutive sender and >>> receiver. In such a case, the RTCP feedback message must be >>> passed to >>> the right sender to let the congestion control work. And >>> undetectable >>> splicing will not be fulfilled when the translator works as the >>> splicer. >>> " >>> >>> Besides that, a new terminology is defined in section 1.1 to define >>> "Undetectable Splicing", see below: >>> >>> " >>> Undetectable Splicing: >>> >>> The RTP receivers are not able to detect any splicing points in the >>> RTP >>> layer. Sometimes, service providers may require an undetectable >>> splicing to >>> avoid the RTP receivers from filtering out the advertisement >>> content. >>> >> >> That particular motivation gives me a bit of heartburn. But I think >> the >> reality is that the content provider wants to provide an apparently >> continuous stream, and they don't think the the splicing details are >> the >> business of the recipient (any more than the splices that occur in >> the >> original media stream incident to the normal editing of the content.) >> >> >> >>> " >>> >>> Your further thoughts or comments are welcomed. We'll bring a new >>> version >>> as soon as consensus is achieved. >>> >>> BR, >>> Rachel >>> >>> >>> -----Original Message----- >>>> From: kathleen.moriarty.ietf@gmail.com >>>> [mailto:kathleen.moriarty.ietf@gmail.com] >>>> Sent: Monday, June 20, 2016 9:14 PM >>>> To: Mirja Kuehlewind (IETF) >>>> Cc: Colin Perkins; avtext-chairs@ietf.org; >>>> draft-ietf-avtext-splicing-notification@ietf.org; avtext@ietf.org; >>>> The >>>> IESG; >>>> jonathan@vidyo.com >>>> Subject: Re: [avtext] Kathleen Moriarty's No Objection on >>>> draft-ietf-avtext-splicing-notification-07: (with COMMENT) >>>> >>>> >>>> >>>> Sent from my iPhone >>>> >>>> On Jun 20, 2016, at 5:29 AM, Mirja Kuehlewind (IETF) < >>>>> ietf@kuehlewind.net> >>>>> >>>> wrote: >>>> >>>>> >>>>> Hi Colin, >>>>> >>>>> see below. >>>>> >>>>> Am 16.06.2016 um 00:34 schrieb Colin Perkins : >>>>>>> >>>>>>> On 15 Jun 2016, at 19:37, Kathleen Moriarty >>>>>>> >>>>>> wrote: >>>> >>>>> >>>>>>> Kathleen Moriarty has entered the following ballot position for >>>>>>> draft-ietf-avtext-splicing-notification-07: No Objection >>>>>>> >>>>>>> When responding, please keep the subject line intact and reply >>>>>>> to >>>>>>> all email addresses included in the To and CC lines. (Feel free >>>>>>> to >>>>>>> cut this introductory paragraph, however.) >>>>>>> >>>>>>> >>>>>>> Please refer to >>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>> >>>>>>> >>>>>>> The document, along with other ballot positions, can be found >>>>>>> here: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notifica >>>>>>> tion/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> -------------------------------------------------------------------- >>>>>>> -- >>>>>>> COMMENT: >>>>>>> -------------------------------------------------------------------- >>>>>>> -- >>>>>>> >>>>>>> I strongly support Mirja's and Alia's discuss points and would >>>>>>> like >>>>>>> to see more of a discussion of the capability to hide splicing >>>>>>> in >>>>>>> the security considerations text. My ballot would be discuss, >>>>>>> but >>>>>>> they pulled out the relevant sections and that would be >>>>>>> duplication. >>>>>>> I'd like to review agreed upon text though to address these >>>>>>> concerns. >>>>>>> >>>>>>> I don't like the idea of enabling a MiTM, but do see the draft >>>>>>> talks >>>>>>> about how to protect headers when this happens and >>>>>>> confidentiality >>>>>>> is needed as well as session protection between the endpoints >>>>>>> and >>>>>>> the splicer (which I don't like either, but you do call out the >>>>>>> security considerations of this and that's what is needed). >>>>>>> >>>>>> >>>>>> The mechanism described doesn’t work unless the receiver >>>>>> explicitly >>>>>> >>>>> chooses to receive media content delivered via the splicer. I >>>>> agree >>>> that the >>>> draft could be more clearly written, but it doesn’t seem to be >>>> “enabling >>>> a >>>> MiTM” attack, since the receiver opts in. >>>> >>>>> >>>>> This definitely need from clarification in the draft! >>>>> >>>> >>>> Yes, can we see some proposed text? >>>> >>>> Thank you, >>>> Kathleen >>>> >>>>> >>>>> Mirja >>>>> >>>>> >>>>> >>>>>> -- >>>>>> Colin Perkins >>>>>> https://csperkins.org/ >>>>>> >>>>> >>>>> From nobody Tue Jun 21 14:50: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 4DA3B12DA72; Tue, 21 Jun 2016 14:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 kZzfAhf9Faqj; Tue, 21 Jun 2016 14:47:42 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE38D12DE31; Tue, 21 Jun 2016 14:47:40 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id f6so45115217lfg.0; Tue, 21 Jun 2016 14:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=XKGsm5rs1W4iyJ8WM6QBfIKi9uMJ+ZysA7Z4KAiju2c=; b=mE/RIi4zIcagI7noj0eQ4VaYLkzaEVfUMfPHg87yxWn1uHz79OIe4mWVe7jMe8w6yz 4DMqFdPs++umE/nD/3gOS5Dzc96OHNg67Yjvlyhql2ZqXj4Ag0mRaUtOGOoukOYpGMP+ ewEnESwtU4N/olNrhVlKQzflSiJPHjPf2Uzu3wRVUhOulMQtmbmyII2cdenTdGHv3gnu tdb0CgxHSgsY5a8c6oI7jXoUHKAdy7eX1mbWMMpInkbIuQ6PWjl41y5rMdtX44SoG5if PrEld0XHGIfYAsW5sFvDoGWc+hFiRLty8epuSXhsWZLKjDMw9A7g+wYVwIMf/VZHINRb g1hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=XKGsm5rs1W4iyJ8WM6QBfIKi9uMJ+ZysA7Z4KAiju2c=; b=Nlqqq4lH2iR00PGiXG3Tt5UQZsjLS6I8wj5HzhYVb0jODlZ10Q6nzlsVzkZw8MU8Y9 YqQme3ouka78rnKavXaXUFB3uNtRTYAKhNuUmuXFR/Zn6y/El/UKXijgNKfwsKG6m17G TQbGVVhl0UVExGerAYmqdmddOlfkG9cFQUwuyqLhlFBJUmhGhIriALcIuykj4+euqS3d IdzK4dS5UPy03i23JHZi3MCdNzRDC3C6o3kq6ym6WcMZXpH8QQ7ZKkAON+F8miK56xHN wnZxqNkH/cSMXDonRtyB33PFRuatLAFixWmX1EfCaCTfdgRbPLRHtjWgv88oiL9CsLi3 qMkw== X-Gm-Message-State: ALyK8tL5MGj9pbQPJPCX/LzPZe5PSnXO+1iA1YZUSpT/6UeZZaTkocfLKhLhJZ6loHBdaQ== X-Received: by 10.194.173.230 with SMTP id bn6mr12964864wjc.8.1466545658728; Tue, 21 Jun 2016 14:47:38 -0700 (PDT) Received: from RoniPC (bzq-79-179-194-235.red.bezeqint.net. [79.179.194.235]) by smtp.gmail.com with ESMTPSA id g4sm50286531wju.30.2016.06.21.14.47.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2016 14:47:36 -0700 (PDT) From: "Roni Even" To: "'Alia Atlas'" , "'Ben Campbell'" References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> In-Reply-To: Date: Wed, 22 Jun 2016 00:46:12 +0300 Message-ID: <132201d1cc06$558c1950$00a44bf0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLMM70r+h1W5iU43V9EC9lZyTXemgC2M80TAhwaUOUBXVJYnwMQYd2nAdUnZEcDUtlVkp2cYz7Q Content-Language: he Archived-At: X-Mailman-Approved-At: Tue, 21 Jun 2016 14:50:32 -0700 Cc: jonathan@vidyo.com, avtext@ietf.org, avtext-chairs@ietf.org, kathleen.moriarty.ietf@gmail.com, 'Mirja Kuehlewind' , 'The IESG' , draft-ietf-avtext-splicing-notification@ietf.org, 'Colin Perkins' Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 21 Jun 2016 21:47:45 -0000 Hi Alia, I am not sure what you mean by "the receiver has agreed" agreed to what. The receiver asked for content and he receives the content. Part of it = is advertisements that are spliced in the stream. The only consent I can think of may be in the application layer that may = tell that this content include advertisements. =20 What is hidden from the receiver is that some content is spliced in. BTW: changing the content midstream without notifying the receiver can = be done by any RFC3550 RTP mixer and this is why we have the reference = to RFC7557. Roni Even > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Wednesday, June 22, 2016 12:36 AM > To: Ben Campbell > Cc: Huangyihong; kathleen.moriarty.ietf@gmail.com; Mirja Kuehlewind; > Alissa Cooper; Colin Perkins; avtext-chairs@ietf.org; = draft-ietf-avtext- > splicing-notification@ietf.org; avtext@ietf.org; The IESG; > jonathan@vidyo.com > Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS >=20 > This is useful clarification, but it still contains no hint that the = receiver has > agreed. It doesn't alter the SHOULD or MUSTs associated with hiding = this > from receivers. >=20 > I am looking for a balanced explanation - the motivations here give me = more > than heartburn. > It's clearly deciding for the content provider. >=20 > Regards, > Alia >=20 > On Tue, Jun 21, 2016 at 3:32 PM, Ben Campbell wrote: >=20 > > Hi, some comments inline: > > > > On 21 Jun 2016, at 7:58, Huangyihong (Rachel) wrote: > > > > Hi All, > >> > >> Here's my proposal for addressing Alia's and other AD's similar = DISCUSS. > >> The main idea is to add a new subsection in Section 2, which is > >> showed as > >> following: > >> > >> " > >> 2.1 Overview of RTP Splicing > >> > >> RTP Splicing is to replace some multimedia content with certain > >> substitutive multimedia content, and then forward it to the = receivers > >> for a period of time. This process is authorized by the service > >> provider who sends the multimedia content to these receivers. A > >> typical usage is that IPTV service providers use their own = regional > >> advertising content to replace national advertising content = provided > >> by the content providers. > >> > > > > I think this could be strengthened a bit. IIUC, this mechanism = assumes > > the splicing interval is sent _by_ the main content provider. That = is, > > this mechanism only works with the permission of the content = provider. > > If they don't consent, they simply won't send the splicing interval. > > > > This relationship might be more clear if the example talked about = the > > main content provider offering a time window for the regional > > advertising insert, rather than about replacing national = advertising. > > While that might in fact replace national content, it should be = clear > > that the main provider _intends_ for the insert to happen. > > > > > >> The splicer is a middlebox handling RTP splicing. It receives = main > >> content and substitutive content simultaneously but only chooses = to > >> send one of them to the receiver at any point of time. When RTP > >> splicing begins, the splicer sends the substitutive content to = the > >> receivers instead of the main content. When RTP splicing ends, = the > >> splicer switches back to sending the main content to the = receivers. > >> > >> The middle box working as the splicer is either a translator or = a > >> mixer. [RFC6828] specifies a splicer implemented as a mixer that = uses > >> its own SSRC, sequence number space, and timing model when > generating > >> the output stream to receivers. The mixer must not insert the = SSRC of > >> the main RTP stream or the SSRC of the substitutive RTP stream = into > >> the contributing source (CSRC) list in the output media stream = when > >> implementing undetectable splicing. > >> > > > > I suggest promoting that last sentence a bit, and removing any hint = of > > 2119 language. For example: > > > > "The splicer, operating on behalf of the content provider, may not > > wish to reveal that splicing has occurred. In this case, the splicer > > does not insert the SSRCs from either the main or substitutive RTP > > streams into the CSRC list in the resulting output media stream.." > > > > Since it works as the mixer, it > >> splits the RTCP flow between the sender and receiver into two > >> separate RTCP loops. This implies additional considerations = should be > >> taken into account when handling congestion control, see Section = 4.4 > >> of [RFC6828]. > >> > >> A translator [RFC3550] can also be a splicer by forwarding the = RTP > >> packets with > >> their SSRCs intact, where the congestion control runs between > >> original sender and receiver, or between substitutive sender and > >> receiver. In such a case, the RTCP feedback message must be = passed to > >> the right sender to let the congestion control work. And = undetectable > >> splicing will not be fulfilled when the translator works as the > >> splicer. > >> " > >> > >> Besides that, a new terminology is defined in section 1.1 to define > >> "Undetectable Splicing", see below: > >> > >> " > >> Undetectable Splicing: > >> > >> The RTP receivers are not able to detect any splicing points in the > >> RTP layer. Sometimes, service providers may require an undetectable > >> splicing to avoid the RTP receivers from filtering out the = advertisement > content. > >> > > > > That particular motivation gives me a bit of heartburn. But I think > > the reality is that the content provider wants to provide an > > apparently continuous stream, and they don't think the the splicing > > details are the business of the recipient (any more than the splices > > that occur in the original media stream incident to the normal = editing > > of the content.) > > > > > > > >> " > >> > >> Your further thoughts or comments are welcomed. We'll bring a new > >> version as soon as consensus is achieved. > >> > >> BR, > >> Rachel > >> > >> > >> -----Original Message----- > >>> From: kathleen.moriarty.ietf@gmail.com > >>> [mailto:kathleen.moriarty.ietf@gmail.com] > >>> Sent: Monday, June 20, 2016 9:14 PM > >>> To: Mirja Kuehlewind (IETF) > >>> Cc: Colin Perkins; avtext-chairs@ietf.org; > >>> draft-ietf-avtext-splicing-notification@ietf.org; avtext@ietf.org; > >>> The IESG; jonathan@vidyo.com > >>> Subject: Re: [avtext] Kathleen Moriarty's No Objection on > >>> draft-ietf-avtext-splicing-notification-07: (with COMMENT) > >>> > >>> > >>> > >>> Sent from my iPhone > >>> > >>> On Jun 20, 2016, at 5:29 AM, Mirja Kuehlewind (IETF) < > >>>> ietf@kuehlewind.net> > >>>> > >>> wrote: > >>> > >>>> > >>>> Hi Colin, > >>>> > >>>> see below. > >>>> > >>>> Am 16.06.2016 um 00:34 schrieb Colin Perkins : > >>>>>> > >>>>>> On 15 Jun 2016, at 19:37, Kathleen Moriarty > >>>>>> > >>>>> wrote: > >>> > >>>> > >>>>>> Kathleen Moriarty has entered the following ballot position for > >>>>>> draft-ietf-avtext-splicing-notification-07: No Objection > >>>>>> > >>>>>> When responding, please keep the subject line intact and reply = to > >>>>>> all email addresses included in the To and CC lines. (Feel free > >>>>>> to cut this introductory paragraph, however.) > >>>>>> > >>>>>> > >>>>>> Please refer to > >>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html > >>>>>> for more information about IESG DISCUSS and COMMENT positions. > >>>>>> > >>>>>> > >>>>>> The document, along with other ballot positions, can be found = here: > >>>>>> = https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notif > >>>>>> ica > >>>>>> tion/ > >>>>>> > >>>>>> > >>>>>> > >>>>>> = ----------------------------------------------------------------- > >>>>>> --- > >>>>>> -- > >>>>>> COMMENT: > >>>>>> = ----------------------------------------------------------------- > >>>>>> --- > >>>>>> -- > >>>>>> > >>>>>> I strongly support Mirja's and Alia's discuss points and would > >>>>>> like to see more of a discussion of the capability to hide > >>>>>> splicing in the security considerations text. My ballot would = be > >>>>>> discuss, but they pulled out the relevant sections and that = would be > duplication. > >>>>>> I'd like to review agreed upon text though to address these = concern From nobody Tue Jun 21 14:55:50 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 A88E012DE3F; Tue, 21 Jun 2016 14:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 raheWPlF80UV; Tue, 21 Jun 2016 14:52:44 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [46.235.227.24]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6FE12DE42; Tue, 21 Jun 2016 14:52:44 -0700 (PDT) Received: from [81.187.2.149] (port=44985 helo=[192.168.0.91]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bFTb0-0006r0-RX; Tue, 21 Jun 2016 22:52:35 +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: <132201d1cc06$558c1950$00a44bf0$@gmail.com> Date: Tue, 21 Jun 2016 22:52:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> <132201d1cc06$558c1950$00a44bf0$@gmail.com> To: Roni Even X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: X-Mailman-Approved-At: Tue, 21 Jun 2016 14:55:49 -0700 Cc: avtext@ietf.org, jonathan@vidyo.com, Alia Atlas , kathleen.moriarty.ietf@gmail.com, Mirja Kuehlewind , The IESG , draft-ietf-avtext-splicing-notification@ietf.org, avtext-chairs@ietf.org Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 21 Jun 2016 21:52:46 -0000 > On 21 Jun 2016, at 22:46, Roni Even wrote: =E2=80=A6 > BTW: changing the content midstream without notifying the receiver can = be done by any RFC3550 RTP mixer and this is why we have the reference = to RFC7557. To be clear: this can only be done if the receiver opts to receive = content via that RTP mixer. The mixer is an application-level proxy, and = there are defined end-to-end security mechanisms that can prevent = unauthorised RTP mixers and translators from modifying the content, if = such modification is considered a threat. --=20 Colin Perkins https://csperkins.org/ From nobody Tue Jun 21 14:55:53 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 5EB9712DE2E; Tue, 21 Jun 2016 14:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rk9NU2Dytbf6; Tue, 21 Jun 2016 14:53:39 -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 2B57E12DE2B; Tue, 21 Jun 2016 14:53:39 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5LLrRax004546 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 21 Jun 2016 16:53:27 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Colin Perkins" Date: Tue, 21 Jun 2016 16:53:26 -0500 Message-ID: <9894DE50-B2C3-49EE-B932-54254573D26F@nostrum.com> In-Reply-To: References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.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: X-Mailman-Approved-At: Tue, 21 Jun 2016 14:55:49 -0700 Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" , Alia Atlas Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 21 Jun 2016 21:53:40 -0000 On 21 Jun 2016, at 16:48, Colin Perkins wrote: >> That particular motivation gives me a bit of heartburn. But I think >> the reality is that the content provider wants to provide an >> apparently continuous stream, and they don't think the the splicing >> details are the business of the recipient (any more than the splices >> that occur in the original media stream incident to the normal >> editing of the content.) > > > It’s implied, but perhaps easy to miss in Rachel’s suggested text, > that this is only talking about whether the splicing is detectable *at > the RTP layer*. A receiver that’s willing to analyse the metadata in > the payload can almost certainly tell that the content changed for the > duration of the splicing, even without decoding the video. Okay, that's a good point. But one wonders why bother with the guidance for "undetectable splices" at all? In the example, if an implementation that wants to do commercial skipping can still do it anyway, then why even talk about it? (Other than to say that undetectable splices aren't real?) Ben. From nobody Tue Jun 21 15:00: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 1460012D77E; Tue, 21 Jun 2016 14:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 Y3ymlSUvITyc; Tue, 21 Jun 2016 14:57:58 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C14F12B054; Tue, 21 Jun 2016 14:57:58 -0700 (PDT) Received: from [81.187.2.149] (port=39476 helo=[192.168.0.91]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bFTg3-0007Iv-8w; Tue, 21 Jun 2016 22:57:47 +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: <9894DE50-B2C3-49EE-B932-54254573D26F@nostrum.com> Date: Tue, 21 Jun 2016 22:57:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <01A5530D-A34F-4253-AB02-5439E3FFB99F@csperkins.org> References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> <9894DE50-B2C3-49EE-B932-54254573D26F@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: X-Mailman-Approved-At: Tue, 21 Jun 2016 15:00:51 -0700 Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" , Alia Atlas Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 21 Jun 2016 21:58:00 -0000 > On 21 Jun 2016, at 22:53, Ben Campbell wrote: >=20 > On 21 Jun 2016, at 16:48, Colin Perkins wrote: >=20 >>> That particular motivation gives me a bit of heartburn. But I think = the reality is that the content provider wants to provide an apparently = continuous stream, and they don't think the the splicing details are the = business of the recipient (any more than the splices that occur in the = original media stream incident to the normal editing of the content.) >>=20 >>=20 >> It=E2=80=99s implied, but perhaps easy to miss in Rachel=E2=80=99s = suggested text, that this is only talking about whether the splicing is = detectable *at the RTP layer*. A receiver that=E2=80=99s willing to = analyse the metadata in the payload can almost certainly tell that the = content changed for the duration of the splicing, even without decoding = the video. >=20 > Okay, that's a good point. But one wonders why bother with the = guidance for "undetectable splices" at all? In the example, if an = implementation that wants to do commercial skipping can still do it = anyway, then why even talk about it? (Other than to say that = undetectable splices aren't real?) It (slightly) simplifies the receiver if it can not care about seeing = multiple sources (either SSRC or CSRC, depending on how the splicer was = implemented) in the RTP stream.=20 --=20 Colin Perkins https://csperkins.org/ From nobody Tue Jun 21 15:07: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 3374C12DA4F; Tue, 21 Jun 2016 15:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] 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 Qh2n1FpxIsQK; Tue, 21 Jun 2016 15:07:17 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490D612D803; Tue, 21 Jun 2016 15:07:17 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id t127so41336943qkf.1; Tue, 21 Jun 2016 15:07:17 -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=7r7zXQvnpdK1P/hIZFYVAeuxkI5w6Bb+DW5sLvZRE5U=; b=U7ggVRWiPCriuIVQAJeDlVViLqGe8M1CRchY3KfyyBrlEyek6iMOsnFUaPhjRBVPdq 96N0UsC0ODZfjG9L7VGqw9QlcT29EyvzVolTb7Ecpoi2tDLyyBr0rCTHyeDJtv9djtbI xeg8Jv+Ljq56Tn7TEYqEL/A7QoAuN7Jqc4ss38drdZ0zw1+MN/BmBwae+n1rUPYwf7da mX6EqpW9p0SFN20IgLgW5BqqUcY+ubT18O52eC8Pb3OIiR3XgT/R2yFoNQiCAnT6SvoJ xhzTNpWlbwkXzXezPeqRnozfVmnmdwVc1yvtSk41LqwReRGIT9atGuV7ou+2/iuyfUz7 GbXw== 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=7r7zXQvnpdK1P/hIZFYVAeuxkI5w6Bb+DW5sLvZRE5U=; b=NWtV850AJRV44fgA5cSIEPbU90PIiI+YFkHCXOMadzdrwYm50wxG5IfUYUUr/+KzT9 vVgPClywmGg1/x6lMuHCOtru90WU3czs14Loj/dqxUct0X2yglZikXrZbNCxlGxgekfa JVxMjuMsLICYWyFVcIndV7fQXren0rbhgcPWH1TP5VKNTCitP6rIXaG/Wfq02Def8OeX GTmYRVj2M4Wuw5hYDKF3kctYMRYtnT4pWiyAzVMX4/c6EL7sac9QpWQJ1BKeY7GpEQ3J 7E2qek6noU5thnusHx4zvgCcOl0W2UaV4+vvj9exCWgK7drvo8ax4pXlTVPBX0MsyCBF FN/w== X-Gm-Message-State: ALyK8tK8ze3ublwCwZ9P190IxGYjkpkZWIv6lYyUlxM3CVVcIAJfqFWST9MZv1TQZxwhiphVAiVxU3zIXF2pCQ== X-Received: by 10.55.24.212 with SMTP id 81mr33432787qky.146.1466546834970; Tue, 21 Jun 2016 15:07:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.57.81 with HTTP; Tue, 21 Jun 2016 15:07:14 -0700 (PDT) In-Reply-To: <01A5530D-A34F-4253-AB02-5439E3FFB99F@csperkins.org> References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> <9894DE50-B2C3-49EE-B932-54254573D26F@nostrum.com> <01A5530D-A34F-4253-AB02-5439E3FFB99F@csperkins.org> From: Alia Atlas Date: Tue, 21 Jun 2016 18:07:14 -0400 Message-ID: To: Colin Perkins Content-Type: multipart/alternative; boundary=001a113eada2251e340535d10bbc Archived-At: Cc: "avtext@ietf.org" , "jonathan@vidyo.com" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 21 Jun 2016 22:07:33 -0000 --001a113eada2251e340535d10bbc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Colin, These are really useful points for me. So, indicating that the receiver has agreed to receive the stream via the splicer would help. As written, it sounds like there is a requirement to hide the splicing from the receiver - and all the motivations I've been hearing are to "force" the receiver to get the included advertisements and not be able to tell where they are. Regards, Alia On Tue, Jun 21, 2016 at 5:57 PM, Colin Perkins wrote: > > On 21 Jun 2016, at 22:53, Ben Campbell wrote: > > > > On 21 Jun 2016, at 16:48, Colin Perkins wrote: > > > >>> That particular motivation gives me a bit of heartburn. But I think > the reality is that the content provider wants to provide an apparently > continuous stream, and they don't think the the splicing details are the > business of the recipient (any more than the splices that occur in the > original media stream incident to the normal editing of the content.) > >> > >> > >> It=E2=80=99s implied, but perhaps easy to miss in Rachel=E2=80=99s sug= gested text, that > this is only talking about whether the splicing is detectable *at the RTP > layer*. A receiver that=E2=80=99s willing to analyse the metadata in the = payload > can almost certainly tell that the content changed for the duration of th= e > splicing, even without decoding the video. > > > > Okay, that's a good point. But one wonders why bother with the guidance > for "undetectable splices" at all? In the example, if an implementation > that wants to do commercial skipping can still do it anyway, then why eve= n > talk about it? (Other than to say that undetectable splices aren't real?) > > It (slightly) simplifies the receiver if it can not care about seeing > multiple sources (either SSRC or CSRC, depending on how the splicer was > implemented) in the RTP stream. > > -- > Colin Perkins > https://csperkins.org/ > > > > > --001a113eada2251e340535d10bbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colin,

These are really useful points f= or me.
So, indicating that the receiver has agreed to receive the= stream via the splicer would help.
As written, it sounds like th= ere is a requirement to hide the splicing from the receiver - and all
=
the motivations I've been hearing are to "force" the rec= eiver to get the included advertisements
and not be able to tell = where they are.

Regards,
Alia

On Tue, Jun 21, = 2016 at 5:57 PM, Colin Perkins <csp@csperkins.org> wrote:
> On 21 Jun 2016, at 22= :53, Ben Campbell <ben@nostrum.com> wrote:
>
> On 21 Jun 2016, at 16:48, Colin Perkins wrote:
>
>>> That particular motivation gives me a bit of heartburn. But I = think the reality is that the content provider wants to provide an apparent= ly continuous stream, and they don't think the the splicing details are= the business of the recipient (any more than the splices that occur in the= original media stream incident to the normal editing of the content.)
>>
>>
>> It=E2=80=99s implied, but perhaps easy to miss in Rachel=E2=80=99s= suggested text, that this is only talking about whether the splicing is de= tectable *at the RTP layer*. A receiver that=E2=80=99s willing to analyse t= he metadata in the payload can almost certainly tell that the content chang= ed for the duration of the splicing, even without decoding the video.
>
> Okay, that's a good point. But one wonders why bother with the gui= dance for "undetectable splices" at all? In the example, if an im= plementation that wants to do commercial skipping can still do it anyway, t= hen why even talk about it? (Other than to say that undetectable splices ar= en't real?)

It (slightly) simplifies the receiver if it can not care about seein= g multiple sources (either SSRC or CSRC, depending on how the splicer was i= mplemented) in the RTP stream.

--
Colin Perkins
htt= ps://csperkins.org/





--001a113eada2251e340535d10bbc-- From nobody Tue Jun 21 15:18:29 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 E72CE12DE74; Tue, 21 Jun 2016 15:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 9ZAo4iTFbv78; Tue, 21 Jun 2016 15:18:18 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9746C12DE6F; Tue, 21 Jun 2016 15:18:18 -0700 (PDT) Received: from [81.187.2.149] (port=48440 helo=[192.168.0.91]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bFTzi-0000wI-Rw; Tue, 21 Jun 2016 23:18:07 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_88626DFF-3CD3-4D40-8423-95FDC924C681" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: Date: Tue, 21 Jun 2016 23:18:04 +0100 Message-Id: <30A9FC33-3D57-4EFF-B66A-07609A9E1548@csperkins.org> References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> <9894DE50-B2C3-49EE-B932-54254573D26F@nostrum.com> <01A5530D-A34F-4253-AB02-5439E3FFB99F@csperkins.org> To: Alia Atlas X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "avtext@ietf.org" , "jonathan@vidyo.com" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 21 Jun 2016 22:18:22 -0000 --Apple-Mail=_88626DFF-3CD3-4D40-8423-95FDC924C681 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alia, > On 21 Jun 2016, at 23:07, Alia Atlas wrote: >=20 > Colin, >=20 > These are really useful points for me. > So, indicating that the receiver has agreed to receive the stream via = the splicer would help. You mean add something to the draft saying =E2=80=9Cthe sender and = receiver have to be explicitly configured to use the splicer=E2=80=9D? = Maybe also with some words in the security considerations explaining = that there=E2=80=99s a signalling relationship between sender, splicer, = and receiver that can be used to configure RTP-level security mechanisms = to prevent modifications to the streams, or insertion of splicing = notification messages by anyone other than the sender, if that=E2=80=99s = considered a threat? Colin > As written, it sounds like there is a requirement to hide the splicing = from the receiver - and all the motivations I=E2=80=99ve been hearing = are to =E2=80=9Cforce" the receiver to get the included advertisements = and not be able to tell where they are. >=20 > Regards, > Alia >=20 > On Tue, Jun 21, 2016 at 5:57 PM, Colin Perkins > wrote: > > On 21 Jun 2016, at 22:53, Ben Campbell > wrote: > > > > On 21 Jun 2016, at 16:48, Colin Perkins wrote: > > > >>> That particular motivation gives me a bit of heartburn. But I = think the reality is that the content provider wants to provide an = apparently continuous stream, and they don't think the the splicing = details are the business of the recipient (any more than the splices = that occur in the original media stream incident to the normal editing = of the content.) > >> > >> > >> It=E2=80=99s implied, but perhaps easy to miss in Rachel=E2=80=99s = suggested text, that this is only talking about whether the splicing is = detectable *at the RTP layer*. A receiver that=E2=80=99s willing to = analyse the metadata in the payload can almost certainly tell that the = content changed for the duration of the splicing, even without decoding = the video. > > > > Okay, that's a good point. But one wonders why bother with the = guidance for "undetectable splices" at all? In the example, if an = implementation that wants to do commercial skipping can still do it = anyway, then why even talk about it? (Other than to say that = undetectable splices aren't real?) >=20 > It (slightly) simplifies the receiver if it can not care about seeing = multiple sources (either SSRC or CSRC, depending on how the splicer was = implemented) in the RTP stream. >=20 > -- > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 >=20 --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_88626DFF-3CD3-4D40-8423-95FDC924C681 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Alia,

On 21 Jun 2016, at 23:07, Alia = Atlas <akatlas@gmail.com> wrote:

Colin,

These are really useful points for me.
So,= indicating that the receiver has agreed to receive the stream via the = splicer would help.

You mean add something to the draft saying =E2=80=9C= the sender and receiver have to be explicitly configured to use the = splicer=E2=80=9D? Maybe also with some words in the security = considerations explaining that there=E2=80=99s a signalling relationship = between sender, splicer, and receiver that can be used to configure = RTP-level security mechanisms to prevent modifications to the streams, = or insertion of splicing notification messages by anyone other than the = sender, if that=E2=80=99s considered a threat?

Colin



As written, it = sounds like there is a requirement to hide the splicing from the = receiver - and all the motivations I=E2=80=99ve been hearing are to = =E2=80=9Cforce" the receiver to get the included advertisements and not = be able to tell where they are.

Regards,
Alia

On Tue, Jun 21, 2016 at 5:57 PM, Colin Perkins = <csp@csperkins.org> wrote:
> = On 21 Jun 2016, at 22:53, Ben Campbell <ben@nostrum.com> = wrote:
>
> On 21 Jun 2016, at 16:48, Colin Perkins wrote:
>
>>> That particular motivation gives me a bit of heartburn. But = I think the reality is that the content provider wants to provide an = apparently continuous stream, and they don't think the the splicing = details are the business of the recipient (any more than the splices = that occur in the original media stream incident to the normal editing = of the content.)
>>
>>
>> It=E2=80=99s implied, but perhaps easy to miss in Rachel=E2=80=99= s suggested text, that this is only talking about whether the splicing = is detectable *at the RTP layer*. A receiver that=E2=80=99s willing to = analyse the metadata in the payload can almost certainly tell that the = content changed for the duration of the splicing, even without decoding = the video.
>
> Okay, that's a good point. But one wonders why bother with the = guidance for "undetectable splices" at all? In the example, if an = implementation that wants to do commercial skipping can still do it = anyway, then why even talk about it? (Other than to say that = undetectable splices aren't real?)

It (slightly) simplifies the receiver if it can not care about = seeing multiple sources (either SSRC or CSRC, depending on how the = splicer was implemented) in the RTP stream.

--
Colin Perkins
https://csperkins.org/








-- 
Colin Perkins
https://csperkins.org/



= --Apple-Mail=_88626DFF-3CD3-4D40-8423-95FDC924C681-- From nobody Tue Jun 21 15:38:25 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B0812DA8C; Tue, 21 Jun 2016 15:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 8axe6TDWTSJC; Tue, 21 Jun 2016 15:38:22 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E389712D82C; Tue, 21 Jun 2016 15:38:21 -0700 (PDT) Received: from [81.187.2.149] (port=38383 helo=[192.168.0.91]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bFTXd-0006PE-B3; Tue, 21 Jun 2016 22:49:06 +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: <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> Date: Tue, 21 Jun 2016 22:48:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" , Alia Atlas Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 21 Jun 2016 22:38:23 -0000 > On 21 Jun 2016, at 20:32, Ben Campbell wrote: >=20 > Hi, some comments inline: >=20 > On 21 Jun 2016, at 7:58, Huangyihong (Rachel) wrote: >=20 >> Hi All, >>=20 >> Here's my proposal for addressing Alia's and other AD's similar = DISCUSS. The main idea is to add a new subsection in Section 2, which is = showed as following: >>=20 >> " >> 2.1 Overview of RTP Splicing >>=20 >> RTP Splicing is to replace some multimedia content with certain >> substitutive multimedia content, and then forward it to the = receivers >> for a period of time. This process is authorized by the service >> provider who sends the multimedia content to these receivers. A >> typical usage is that IPTV service providers use their own regional >> advertising content to replace national advertising content = provided >> by the content providers. >=20 > I think this could be strengthened a bit. IIUC, this mechanism assumes = the splicing interval is sent _by_ the main content provider. That is, = this mechanism only works with the permission of the content provider. = If they don't consent, they simply won't send the splicing interval. >=20 > This relationship might be more clear if the example talked about the = main content provider offering a time window for the regional = advertising insert, rather than about replacing national advertising. = While that might in fact replace national content, it should be clear = that the main provider _intends_ for the insert to happen. Right. The other point that=E2=80=99s probably worth noting is that the = receiver knows the traffic is being routed via the middlebox, and = explicitly communicates with that middlebox via the RTCP reception = reports it returns, and possibly also via some non-RTP signalling = channel (the sender likely offers it no choice but to use the middlebox = if it wants access to the media stream, but that=E2=80=99s a different = issue=E2=80=A6). >> The splicer is a middlebox handling RTP splicing. It receives main >> content and substitutive content simultaneously but only chooses to >> send one of them to the receiver at any point of time. When RTP >> splicing begins, the splicer sends the substitutive content to the >> receivers instead of the main content. When RTP splicing ends, the >> splicer switches back to sending the main content to the receivers. >>=20 >> The middle box working as the splicer is either a translator or a >> mixer. [RFC6828] specifies a splicer implemented as a mixer that = uses >> its own SSRC, sequence number space, and timing model when = generating >> the output stream to receivers. The mixer must not insert the SSRC = of >> the main RTP stream or the SSRC of the substitutive RTP stream into >> the contributing source (CSRC) list in the output media stream when >> implementing undetectable splicing. >=20 > I suggest promoting that last sentence a bit, and removing any hint of = 2119 language. For example: >=20 > "The splicer, operating on behalf of the content provider, may not = wish to reveal that splicing has occurred. In this case, the splicer = does not insert the SSRCs from either the main or substitutive RTP = streams into the CSRC list in the resulting output media stream.." >=20 >> Since it works as the mixer, it >> splits the RTCP flow between the sender and receiver into two >> separate RTCP loops. This implies additional considerations should = be >> taken into account when handling congestion control, see Section = 4.4 >> of [RFC6828]. >>=20 >> A translator [RFC3550] can also be a splicer by forwarding the RTP = packets with >> their SSRCs intact, where the congestion control runs between >> original sender and receiver, or between substitutive sender and >> receiver. In such a case, the RTCP feedback message must be passed = to >> the right sender to let the congestion control work. And = undetectable >> splicing will not be fulfilled when the translator works as the >> splicer. >> " >>=20 >> Besides that, a new terminology is defined in section 1.1 to define = "Undetectable Splicing", see below: >>=20 >> " >> Undetectable Splicing: >>=20 >> The RTP receivers are not able to detect any splicing points in the = RTP layer. Sometimes, service providers may require an undetectable = splicing to avoid the RTP receivers from filtering out the advertisement = content. >=20 > That particular motivation gives me a bit of heartburn. But I think = the reality is that the content provider wants to provide an apparently = continuous stream, and they don't think the the splicing details are the = business of the recipient (any more than the splices that occur in the = original media stream incident to the normal editing of the content.) It=E2=80=99s implied, but perhaps easy to miss in Rachel=E2=80=99s = suggested text, that this is only talking about whether the splicing is = detectable *at the RTP layer*. A receiver that=E2=80=99s willing to = analyse the metadata in the payload can almost certainly tell that the = content changed for the duration of the splicing, even without decoding = the video.=20 --=20 Colin Perkins https://csperkins.org/ From nobody Tue Jun 21 15:40: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 B632912DE77; Tue, 21 Jun 2016 15:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLzpctYzNrCR; Tue, 21 Jun 2016 15:40:48 -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 F3B4712DA8C; Tue, 21 Jun 2016 15:40:47 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5LMeZ9l008298 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 21 Jun 2016 17:40:36 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Colin Perkins" Date: Tue, 21 Jun 2016 17:40:36 -0500 Message-ID: <947DF280-60CD-41F4-B8F6-BD9B6C16C9F8@nostrum.com> In-Reply-To: <01A5530D-A34F-4253-AB02-5439E3FFB99F@csperkins.org> References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> <9894DE50-B2C3-49EE-B932-54254573D26F@nostrum.com> <01A5530D-A34F-4253-AB02-5439E3FFB99F@csperkins.org> 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: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" , Alia Atlas Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 21 Jun 2016 22:40:50 -0000 On 21 Jun 2016, at 16:57, Colin Perkins wrote: >> On 21 Jun 2016, at 22:53, Ben Campbell wrote: >> >> On 21 Jun 2016, at 16:48, Colin Perkins wrote: >> >>>> That particular motivation gives me a bit of heartburn. But I think >>>> the reality is that the content provider wants to provide an >>>> apparently continuous stream, and they don't think the the splicing >>>> details are the business of the recipient (any more than the >>>> splices that occur in the original media stream incident to the >>>> normal editing of the content.) >>> >>> >>> It’s implied, but perhaps easy to miss in Rachel’s suggested >>> text, that this is only talking about whether the splicing is >>> detectable *at the RTP layer*. A receiver that’s willing to >>> analyse the metadata in the payload can almost certainly tell that >>> the content changed for the duration of the splicing, even without >>> decoding the video. >> >> Okay, that's a good point. But one wonders why bother with the >> guidance for "undetectable splices" at all? In the example, if an >> implementation that wants to do commercial skipping can still do it >> anyway, then why even talk about it? (Other than to say that >> undetectable splices aren't real?) > > It (slightly) simplifies the receiver if it can not care about seeing > multiple sources (either SSRC or CSRC, depending on how the splicer > was implemented) in the RTP stream. That may be the best motivation for not forwarding the input SSRCs offered so far. > > -- > Colin Perkins > https://csperkins.org/ From nobody Tue Jun 21 15:43:21 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 5E7EA12DA95; Tue, 21 Jun 2016 15:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 X-YGpESSmVkM; Tue, 21 Jun 2016 15:43:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F08512DA5C; Tue, 21 Jun 2016 15:43:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A91EDBE49; Tue, 21 Jun 2016 23:43:15 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7egkguQM1v2D; Tue, 21 Jun 2016 23:43:14 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C7BAFBE38; Tue, 21 Jun 2016 23:43:13 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1466548994; bh=b1igfKITIfzVtxsF+kBeTeygGHrNmycHgqlYsrg/i5g=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=TFNczjjkjHUj1ylTkHClHxD4+Xl0f2UcJ4YnUfP4g1j+m3ZuF1WYv1EVyMgWM589E 2SrztyNBp0NT3WFM0ujRBjNLNItPjRmPsTGwqqdLn0OWwntWvyw2RiEwSaMFZzZJAp 8WGSVaLGhWh+66Zo4JsJ38rk/2t+15LQbL/gukvo= To: Colin Perkins , Ben Campbell References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5769C301.5080908@cs.tcd.ie> Date: Tue, 21 Jun 2016 23:43:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030405080106060001010702" Archived-At: Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" , Alia Atlas Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 21 Jun 2016 22:43:20 -0000 This is a cryptographically signed message in MIME format. --------------ms030405080106060001010702 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Colin, On 21/06/16 22:48, Colin Perkins wrote: > The other point that=E2=80=99s probably worth noting is that the receiv= er > knows the traffic is being routed via the middlebox, and explicitly > communicates with that middlebox via the RTCP reception reports it > returns, and possibly also via some non-RTP signalling channel=20 Sorry if I'm taking that out of context, but I don't understand the above. How does the receiver s/w know that it is interacting with a device that is messing about with the content? I understood that it was in fact a requirement here to make it hard for the receiver to be sure of that. I ask about the receiver s/w above, as clearly the warm body that may have eyeballs pointed at content has no idea that the splicer is in the path. > (the > sender likely offers it no choice but to use the middlebox if it > wants access to the media stream, but that=E2=80=99s a different issue=E2= =80=A6) Indeed S. =2E --------------ms030405080106060001010702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MjEy MjQzMTNaMC8GCSqGSIb3DQEJBDEiBCCM6Ye28GXaEDi0Jdvbl05AeeC89Q8/QdsZfOXX6vT5 JjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAwDpkCBVPzgen1ECgccJgNp5scFrlO7ZLk8cWXAxQiMWl11l/Jaqau 87ily3fceqHAOZ2LN2y0HM81zN26iEOVuS0A7JLJGZtEu0MIbvAsNOVyD+eiSSwAFsfki3mn PAgZogrdoG/kAbPB0h/1Kx/nFWTGoW2b+5HtTTip67qmYq/go68aR9Yrx4w5VC7v/AX9grlh aLUgyiB9VaOlJ3aUs8iekgbU0i4TK8Ok4U5qiQxO1hoSV1mlUoBfZk0mgB8k51T0CqQI9wj+ FK79v48GoW1Gfel1TAgJYBcPZy0mnzg4tgRh5K7T91NkADZD7Fgiigl/4aRY02L0qu1WMRA6 AAAAAAAA --------------ms030405080106060001010702-- From nobody Tue Jun 21 15:55: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 15E7412DE28; Tue, 21 Jun 2016 15:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 m_NU6d3y_eT7; Tue, 21 Jun 2016 15:54:52 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8337B12D813; Tue, 21 Jun 2016 15:54:52 -0700 (PDT) Received: from [81.187.2.149] (port=36389 helo=[192.168.0.91]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bFUZ6-00046M-76; Tue, 21 Jun 2016 23:54:41 +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: <5769C301.5080908@cs.tcd.ie> Date: Tue, 21 Jun 2016 23:54:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> <5769C301.5080908@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "avtext@ietf.org" , "jonathan@vidyo.com" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" , Alia Atlas Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 21 Jun 2016 22:54:54 -0000 > On 21 Jun 2016, at 23:43, Stephen Farrell = wrote: > On 21/06/16 22:48, Colin Perkins wrote: >> The other point that=E2=80=99s probably worth noting is that the = receiver >> knows the traffic is being routed via the middlebox, and explicitly >> communicates with that middlebox via the RTCP reception reports it >> returns, and possibly also via some non-RTP signalling channel=20 >=20 > Sorry if I'm taking that out of context, but I don't understand the > above. >=20 > How does the receiver s/w know that it is interacting with a device > that is messing about with the content? I understood that it was in > fact a requirement here to make it hard for the receiver to be sure > of that. My point was that the receiver has to be explicitly configured to get = the media from the splicer, and the splicer can=E2=80=99t interpose = itself in the media stream unless both sender and receiver chose to use = it. > I ask about the receiver s/w above, as clearly the warm body that > may have eyeballs pointed at content has no idea that the splicer is > in the path. >=20 >> (the >> sender likely offers it no choice but to use the middlebox if it >> wants access to the media stream, but that=E2=80=99s a different = issue=E2=80=A6) >=20 > Indeed >=20 > S. >=20 > . >=20 --=20 Colin Perkins https://csperkins.org/ From nobody Tue Jun 21 15:57: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 22B1712DE28; Tue, 21 Jun 2016 15:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 eUJunngztAmF; Tue, 21 Jun 2016 15:57:43 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C553312D813; Tue, 21 Jun 2016 15:57:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6C364BE47; Tue, 21 Jun 2016 23:57:42 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaCuRmRD5QVa; Tue, 21 Jun 2016 23:57:41 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 80027BE38; Tue, 21 Jun 2016 23:57:40 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1466549861; bh=VqN8plBt5Y5mICokcWy8tXuaifu008a/2BT8qqsWWps=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=4qKMGrsFO+jxavxSU7RuQSA0JzCr5iPpTqSjSNu7L3HYgklBeoEwEovJc16CcdnjB 0LH/rMXt772BZTY3A2TXCwAtIQQvjJOHi6fFRodBKIFyUeunpUDz0bIB4OE0t89edo JVrrwzEnUYvwhceYERcoeWmzsGKylAxHQQtY8Aqg= To: Colin Perkins References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> <5769C301.5080908@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5769C664.1080607@cs.tcd.ie> Date: Tue, 21 Jun 2016 23:57:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090503020508010505080602" Archived-At: Cc: "avtext@ietf.org" , "jonathan@vidyo.com" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" , Alia Atlas Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 21 Jun 2016 22:57:45 -0000 This is a cryptographically signed message in MIME format. --------------ms090503020508010505080602 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 21/06/16 23:54, Colin Perkins wrote: >> On 21 Jun 2016, at 23:43, Stephen Farrell >> wrote: On 21/06/16 22:48, Colin Perkins >> wrote: >>> The other point that=E2=80=99s probably worth noting is that the >>> receiver knows the traffic is being routed via the middlebox, and >>> explicitly communicates with that middlebox via the RTCP >>> reception reports it returns, and possibly also via some non-RTP >>> signalling channel >>=20 >> Sorry if I'm taking that out of context, but I don't understand >> the above. >>=20 >> How does the receiver s/w know that it is interacting with a >> device that is messing about with the content? I understood that it >> was in fact a requirement here to make it hard for the receiver to >> be sure of that. >=20 > My point was that the receiver has to be explicitly configured Well, not quite configured perhaps, more that it'd directed to use the middlebox by something near the sender. > to get > the media from the splicer, and the splicer can=E2=80=99t interpose its= elf in > the media stream unless both sender and receiver chose to use it. Right. The receiver can't distinguish between a splicer and some kind of relay that helps with getting around a f/w for example. So we need to be careful in saying what is "known." S. >=20 >> I ask about the receiver s/w above, as clearly the warm body that=20 >> may have eyeballs pointed at content has no idea that the splicer >> is in the path. >>=20 >>> (the sender likely offers it no choice but to use the middlebox >>> if it wants access to the media stream, but that=E2=80=99s a differen= t >>> issue=E2=80=A6) >>=20 >> Indeed >>=20 >> S. >>=20 >> . >>=20 >=20 >=20 >=20 --------------ms090503020508010505080602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MjEy MjU3NDBaMC8GCSqGSIb3DQEJBDEiBCCOKlMKNi6KbAgVBJY3qJ3WA8JzSLjUUFUgFbAEQj4b xDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCdl8aoidUekvF3JftTCj+SpfB1fhVHrz5wMbasoD05wiXTb8+YGmRr imWF4tXZ80BEr2vkLT0SOziP7xZwWofVWejOZeXYN4tJW3pwiR36MdqXAJAwGAd0PJUXNjkJ FSKKLNptbKeNBbgEbthmqqHom7U8jh4kDE16owOq95N/DqfYHIIjKNVTtj6x20yaE8+CZM/F LHYu+7sOJGmXGJk+4npJrvleVI+1/SrOWZrgU1xjF6aWk5uP83aw+Of/NQ5QMJs5aWYgRwsU aEwy83R4za3OR1ktS9+iVZSnN8jqinMyvzREX1bGAgI1sup2YxVPuaIxpQmLG3EymCCTpvjK AAAAAAAA --------------ms090503020508010505080602-- From nobody Tue Jun 21 19:59:33 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FD512D88B; Tue, 21 Jun 2016 19:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 uVz7i7ljgJEE; Tue, 21 Jun 2016 19:59:27 -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 2D8D212D879; Tue, 21 Jun 2016 19:59:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMJ48930; Wed, 22 Jun 2016 02:59:24 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Jun 2016 03:59:23 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 22 Jun 2016 10:59:16 +0800 From: "Huangyihong (Rachel)" To: Colin Perkins , Ben Campbell Thread-Topic: [avtext] Proposed text for Alia and other AD's DISCUSS Thread-Index: AQHRy/OtoxvIWlDAtk64LHRNLjGwPJ/z714AgAC/W4A= Date: Wed, 22 Jun 2016 02:59:17 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86ED8E77@nkgeml513-mbx.china.huawei.com> References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.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.78.128] 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.0A090204.5769FF0C.00B7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5e6da0f055c9b919f1c3dcfdc0892173 Archived-At: Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" , Alia Atlas Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 22 Jun 2016 02:59:31 -0000 SGkgQ29saW4gYW5kIEJlbiwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkJSLA0KUmFjaGVsDQoN Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBDb2xpbiBQZXJraW5zIFtt YWlsdG86Y3NwQGNzcGVya2lucy5vcmddDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyMiwgMjAx NiA1OjQ5IEFNDQo+IFRvOiBCZW4gQ2FtcGJlbGwNCj4gQ2M6IEh1YW5neWlob25nIChSYWNoZWwp OyBrYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbTsgTWlyamENCj4gS3VlaGxld2luZDsg QWxpYSBBdGxhczsgQWxpc3NhIENvb3BlcjsgYXZ0ZXh0LWNoYWlyc0BpZXRmLm9yZzsNCj4gZHJh ZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmctbm90aWZpY2F0aW9uQGlldGYub3JnOyBhdnRleHRAaWV0 Zi5vcmc7IFRoZSBJRVNHOw0KPiBqb25hdGhhbkB2aWR5by5jb20NCj4gU3ViamVjdDogUmU6IFth dnRleHRdIFByb3Bvc2VkIHRleHQgZm9yIEFsaWEgYW5kIG90aGVyIEFEJ3MgRElTQ1VTUw0KPiAN Cj4gPiBPbiAyMSBKdW4gMjAxNiwgYXQgMjA6MzIsIEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0u Y29tPiB3cm90ZToNCj4gPg0KPiA+IEhpLCBzb21lIGNvbW1lbnRzIGlubGluZToNCj4gPg0KPiA+ IE9uIDIxIEp1biAyMDE2LCBhdCA3OjU4LCBIdWFuZ3lpaG9uZyAoUmFjaGVsKSB3cm90ZToNCj4g Pg0KPiA+PiBIaSBBbGwsDQo+ID4+DQo+ID4+IEhlcmUncyBteSBwcm9wb3NhbCBmb3IgYWRkcmVz c2luZyBBbGlhJ3MgYW5kIG90aGVyIEFEJ3Mgc2ltaWxhciBESVNDVVNTLg0KPiBUaGUgbWFpbiBp ZGVhIGlzIHRvIGFkZCBhIG5ldyBzdWJzZWN0aW9uIGluIFNlY3Rpb24gMiwgd2hpY2ggaXMgc2hv d2VkIGFzDQo+IGZvbGxvd2luZzoNCj4gPj4NCj4gPj4gIg0KPiA+PiAyLjEgT3ZlcnZpZXcgb2Yg UlRQIFNwbGljaW5nDQo+ID4+DQo+ID4+ICAgUlRQIFNwbGljaW5nIGlzIHRvIHJlcGxhY2Ugc29t ZSBtdWx0aW1lZGlhIGNvbnRlbnQgd2l0aCBjZXJ0YWluDQo+ID4+ICAgc3Vic3RpdHV0aXZlIG11 bHRpbWVkaWEgY29udGVudCwgYW5kIHRoZW4gZm9yd2FyZCBpdCB0byB0aGUgcmVjZWl2ZXJzDQo+ ID4+ICAgZm9yIGEgcGVyaW9kIG9mIHRpbWUuIFRoaXMgcHJvY2VzcyBpcyBhdXRob3JpemVkIGJ5 IHRoZSBzZXJ2aWNlDQo+ID4+ICAgcHJvdmlkZXIgd2hvIHNlbmRzIHRoZSBtdWx0aW1lZGlhIGNv bnRlbnQgdG8gdGhlc2UgcmVjZWl2ZXJzLiBBDQo+ID4+ICAgdHlwaWNhbCB1c2FnZSBpcyB0aGF0 IElQVFYgc2VydmljZSBwcm92aWRlcnMgdXNlIHRoZWlyIG93biByZWdpb25hbA0KPiA+PiAgIGFk dmVydGlzaW5nIGNvbnRlbnQgdG8gcmVwbGFjZSBuYXRpb25hbCBhZHZlcnRpc2luZyBjb250ZW50 IHByb3ZpZGVkDQo+ID4+ICAgYnkgdGhlIGNvbnRlbnQgcHJvdmlkZXJzLg0KPiA+DQo+ID4gSSB0 aGluayB0aGlzIGNvdWxkIGJlIHN0cmVuZ3RoZW5lZCBhIGJpdC4gSUlVQywgdGhpcyBtZWNoYW5p c20gYXNzdW1lcyB0aGUNCj4gc3BsaWNpbmcgaW50ZXJ2YWwgaXMgc2VudCBfYnlfIHRoZSBtYWlu IGNvbnRlbnQgcHJvdmlkZXIuIFRoYXQgaXMsIHRoaXMgbWVjaGFuaXNtDQo+IG9ubHkgd29ya3Mg d2l0aCB0aGUgcGVybWlzc2lvbiBvZiB0aGUgY29udGVudCBwcm92aWRlci4gSWYgdGhleSBkb24n dCBjb25zZW50LA0KPiB0aGV5IHNpbXBseSB3b24ndCBzZW5kIHRoZSBzcGxpY2luZyBpbnRlcnZh bC4NCj4gPg0KPiA+IFRoaXMgcmVsYXRpb25zaGlwIG1pZ2h0IGJlIG1vcmUgY2xlYXIgaWYgdGhl IGV4YW1wbGUgdGFsa2VkIGFib3V0IHRoZSBtYWluDQo+IGNvbnRlbnQgcHJvdmlkZXIgb2ZmZXJp bmcgYSB0aW1lIHdpbmRvdyBmb3IgdGhlIHJlZ2lvbmFsIGFkdmVydGlzaW5nIGluc2VydCwNCj4g cmF0aGVyIHRoYW4gYWJvdXQgcmVwbGFjaW5nIG5hdGlvbmFsIGFkdmVydGlzaW5nLiBXaGlsZSB0 aGF0IG1pZ2h0IGluIGZhY3QNCj4gcmVwbGFjZSBuYXRpb25hbCBjb250ZW50LCBpdCBzaG91bGQg YmUgY2xlYXIgdGhhdCB0aGUgbWFpbiBwcm92aWRlciBfaW50ZW5kc18gZm9yDQo+IHRoZSBpbnNl cnQgdG8gaGFwcGVuLg0KPiANCj4gUmlnaHQuDQoNCg0KW1JhY2hlbF06IEFjY29yZGluZyB0byB5 b3VyIHN1Z2dlc3Rpb25zLCBob3cgYWJvdXQgY2hhbmdpbmcgdGhlIGFib3ZlIHRleHQgdG8gYmVs b3cNCg0KIg0KICAgUlRQIFNwbGljaW5nIGlzIHRvIHJlcGxhY2Ugc29tZSBtdWx0aW1lZGlhIGNv bnRlbnQgd2l0aCBjZXJ0YWluDQogICBzdWJzdGl0dXRpdmUgbXVsdGltZWRpYSBjb250ZW50LCBh bmQgdGhlbiBmb3J3YXJkIGl0IHRvIHRoZSByZWNlaXZlcnMNCiAgIGZvciBhIHBlcmlvZCBvZiB0 aW1lLiBUaGlzIHByb2Nlc3MgaXMgYXV0aG9yaXplZCBieSB0aGUgbWFpbiBSVFANCiAgIHNlbmRl ciB0aGF0IG9mZmVycyBhIHNwZWNpZmljIHRpbWUgd2luZG93IGZvciBpbnNlcnRpbmcgdGhlDQog ICBzdWJzdGl0dXRpdmUgbXVsdGltZWRpYSBjb250ZW50IGluIHRoZSBtYWluIGNvbnRlbnQuIEEg dHlwaWNhbCB1c2FnZQ0KICAgaXMgdGhhdCBhIElQVFYgc2VydmljZSBwcm92aWRlciB1c2VzIGl0 cyBvd24gcmVnaW9uYWwgYWR2ZXJ0aXNpbmcNCiAgIGNvbnRlbnQgdG8gcmVwbGFjZSBuYXRpb25h bCBhZHZlcnRpc2luZyBjb250ZW50LCB0aGUgdGltZSB3aW5kb3cgb2YNCiAgIHdoaWNoIGlzIGV4 cGxpY2l0bHkgaW5kaWNhdGVkIGJ5IHRoZSBJUFRWIHNlcnZpY2UgcHJvdmlkZXIuDQoiDQoNCj4g DQo+IFRoZSBvdGhlciBwb2ludCB0aGF04oCZcyBwcm9iYWJseSB3b3J0aCBub3RpbmcgaXMgdGhh dCB0aGUgcmVjZWl2ZXIga25vd3MgdGhlDQo+IHRyYWZmaWMgaXMgYmVpbmcgcm91dGVkIHZpYSB0 aGUgbWlkZGxlYm94LCBhbmQgZXhwbGljaXRseSBjb21tdW5pY2F0ZXMgd2l0aCB0aGF0DQo+IG1p ZGRsZWJveCB2aWEgdGhlIFJUQ1AgcmVjZXB0aW9uIHJlcG9ydHMgaXQgcmV0dXJucywgYW5kIHBv c3NpYmx5IGFsc28gdmlhIHNvbWUNCj4gbm9uLVJUUCBzaWduYWxsaW5nIGNoYW5uZWwgKHRoZSBz ZW5kZXIgbGlrZWx5IG9mZmVycyBpdCBubyBjaG9pY2UgYnV0IHRvIHVzZSB0aGUNCj4gbWlkZGxl Ym94IGlmIGl0IHdhbnRzIGFjY2VzcyB0byB0aGUgbWVkaWEgc3RyZWFtLCBidXQgdGhhdOKAmXMg YSBkaWZmZXJlbnQNCj4gaXNzdWXigKYpLg0KDQpbUmFjaGVsXTogQmFzZWQgb24gdGhpcyBzdWdn ZXN0aW9uLCBJIHByb3Bvc2UgdG8gYWRkIGEgc2VudGVuY2VzIGluIHRoZSBlbmQgb2YgdGhlIDJu ZCBwYXJhZ3JhcGg6DQoNCiINCiAgIFRoZSBzcGxpY2VyIGlzIGEgbWlkZGxlYm94IGhhbmRsaW5n IFJUUCBzcGxpY2luZy4gSXQgcmVjZWl2ZXMgbWFpbg0KICAgY29udGVudCBhbmQgc3Vic3RpdHV0 aXZlIGNvbnRlbnQgc2ltdWx0YW5lb3VzbHkgYnV0IG9ubHkgY2hvb3NlcyB0bw0KICAgc2VuZCBv bmUgb2YgdGhlbSB0byB0aGUgcmVjZWl2ZXIgYXQgYW55IHBvaW50IG9mIHRpbWUuIFdoZW4gUlRQ DQogICBzcGxpY2luZyBiZWdpbnMsIHRoZSBzcGxpY2VyIHNlbmRzIHRoZSBzdWJzdGl0dXRpdmUg Y29udGVudCB0byB0aGUNCiAgIHJlY2VpdmVycyBpbnN0ZWFkIG9mIHRoZSBtYWluIGNvbnRlbnQu IFdoZW4gUlRQIHNwbGljaW5nIGVuZHMsIHRoZQ0KICAgc3BsaWNlciBzd2l0Y2hlcyBiYWNrIHRv IHNlbmRpbmcgdGhlIG1haW4gY29udGVudCB0byB0aGUgcmVjZWl2ZXJzLg0KICAgVGhpcyBpbXBs aWVzIHRoYXQgdGhlIHRyYWZmaWMgaXMgcm91dGVkIHZpYSB0aGUgc3BsaWNlciB0byB0aGUNCiAg IHJlY2VpdmVycy4gQW5kIHRoZSBzcGxpY2VyIGlzIGV4cGxpY2l0bHkgY29tbXVuaWNhdGVkIHdp dGggdGhlDQogICByZWNlaXZlcnMgdmlhIFJUQ1AgcGFja2V0cyBhbmQgcG9zc2libHkgdmlhIG5v bi1SVFAgc2lnbmFsaW5nDQogICBjaGFubmVsLg0KIg0KDQo+IA0KPiA+PiAgIFRoZSBzcGxpY2Vy IGlzIGEgbWlkZGxlYm94IGhhbmRsaW5nIFJUUCBzcGxpY2luZy4gSXQgcmVjZWl2ZXMgbWFpbg0K PiA+PiAgIGNvbnRlbnQgYW5kIHN1YnN0aXR1dGl2ZSBjb250ZW50IHNpbXVsdGFuZW91c2x5IGJ1 dCBvbmx5IGNob29zZXMgdG8NCj4gPj4gICBzZW5kIG9uZSBvZiB0aGVtIHRvIHRoZSByZWNlaXZl ciBhdCBhbnkgcG9pbnQgb2YgdGltZS4gV2hlbiBSVFANCj4gPj4gICBzcGxpY2luZyBiZWdpbnMs IHRoZSBzcGxpY2VyIHNlbmRzIHRoZSBzdWJzdGl0dXRpdmUgY29udGVudCB0byB0aGUNCj4gPj4g ICByZWNlaXZlcnMgaW5zdGVhZCBvZiB0aGUgbWFpbiBjb250ZW50LiBXaGVuIFJUUCBzcGxpY2lu ZyBlbmRzLCB0aGUNCj4gPj4gICBzcGxpY2VyIHN3aXRjaGVzIGJhY2sgdG8gc2VuZGluZyB0aGUg bWFpbiBjb250ZW50IHRvIHRoZSByZWNlaXZlcnMuDQo+ID4+DQo+ID4+ICAgVGhlIG1pZGRsZSBi b3ggd29ya2luZyBhcyB0aGUgc3BsaWNlciBpcyBlaXRoZXIgYSB0cmFuc2xhdG9yIG9yIGENCj4g Pj4gICBtaXhlci4gW1JGQzY4MjhdIHNwZWNpZmllcyBhIHNwbGljZXIgaW1wbGVtZW50ZWQgYXMg YSBtaXhlciB0aGF0IHVzZXMNCj4gPj4gICBpdHMgb3duIFNTUkMsIHNlcXVlbmNlIG51bWJlciBz cGFjZSwgYW5kIHRpbWluZyBtb2RlbCB3aGVuDQo+IGdlbmVyYXRpbmcNCj4gPj4gICB0aGUgb3V0 cHV0IHN0cmVhbSB0byByZWNlaXZlcnMuIFRoZSBtaXhlciBtdXN0IG5vdCBpbnNlcnQgdGhlIFNT UkMgb2YNCj4gPj4gICB0aGUgbWFpbiBSVFAgc3RyZWFtIG9yIHRoZSBTU1JDIG9mIHRoZSBzdWJz dGl0dXRpdmUgUlRQIHN0cmVhbSBpbnRvDQo+ID4+ICAgdGhlIGNvbnRyaWJ1dGluZyBzb3VyY2Ug KENTUkMpIGxpc3QgaW4gdGhlIG91dHB1dCBtZWRpYSBzdHJlYW0gd2hlbg0KPiA+PiAgIGltcGxl bWVudGluZyB1bmRldGVjdGFibGUgc3BsaWNpbmcuDQo+ID4NCj4gPiBJIHN1Z2dlc3QgcHJvbW90 aW5nIHRoYXQgbGFzdCBzZW50ZW5jZSBhIGJpdCwgYW5kIHJlbW92aW5nIGFueSBoaW50IG9mIDIx MTkNCj4gbGFuZ3VhZ2UuIEZvciBleGFtcGxlOg0KPiA+DQo+ID4gIlRoZSBzcGxpY2VyLCBvcGVy YXRpbmcgb24gYmVoYWxmIG9mIHRoZSBjb250ZW50IHByb3ZpZGVyLCBtYXkgbm90IHdpc2ggdG8N Cj4gcmV2ZWFsIHRoYXQgc3BsaWNpbmcgaGFzIG9jY3VycmVkLiBJbiB0aGlzIGNhc2UsIHRoZSBz cGxpY2VyIGRvZXMgbm90IGluc2VydCB0aGUNCj4gU1NSQ3MgZnJvbSBlaXRoZXIgdGhlIG1haW4g b3Igc3Vic3RpdHV0aXZlIFJUUCBzdHJlYW1zIGludG8gdGhlIENTUkMgbGlzdCBpbiB0aGUNCj4g cmVzdWx0aW5nIG91dHB1dCBtZWRpYSBzdHJlYW0uLiINCg0KW1JhY2hlbF06IFRoYW5rcyBmb3Ig dGhlIHN1Z2dlc3Rpb24uDQoNCj4gPg0KPiA+PiBTaW5jZSBpdCB3b3JrcyBhcyB0aGUgbWl4ZXIs IGl0DQo+ID4+ICAgc3BsaXRzIHRoZSBSVENQIGZsb3cgYmV0d2VlbiB0aGUgc2VuZGVyIGFuZCBy ZWNlaXZlciBpbnRvIHR3bw0KPiA+PiAgIHNlcGFyYXRlIFJUQ1AgbG9vcHMuIFRoaXMgaW1wbGll cyBhZGRpdGlvbmFsIGNvbnNpZGVyYXRpb25zIHNob3VsZCBiZQ0KPiA+PiAgIHRha2VuIGludG8g YWNjb3VudCB3aGVuIGhhbmRsaW5nIGNvbmdlc3Rpb24gY29udHJvbCwgc2VlIFNlY3Rpb24gNC40 DQo+ID4+ICAgb2YgW1JGQzY4MjhdLg0KPiA+Pg0KPiA+PiAgIEEgdHJhbnNsYXRvciBbUkZDMzU1 MF0gY2FuIGFsc28gYmUgYSBzcGxpY2VyIGJ5IGZvcndhcmRpbmcgdGhlIFJUUA0KPiBwYWNrZXRz IHdpdGgNCj4gPj4gICB0aGVpciBTU1JDcyBpbnRhY3QsIHdoZXJlIHRoZSBjb25nZXN0aW9uIGNv bnRyb2wgcnVucyBiZXR3ZWVuDQo+ID4+ICAgb3JpZ2luYWwgc2VuZGVyIGFuZCByZWNlaXZlciwg b3IgYmV0d2VlbiBzdWJzdGl0dXRpdmUgc2VuZGVyIGFuZA0KPiA+PiAgIHJlY2VpdmVyLiBJbiBz dWNoIGEgY2FzZSwgdGhlIFJUQ1AgZmVlZGJhY2sgbWVzc2FnZSBtdXN0IGJlIHBhc3NlZCB0bw0K PiA+PiAgIHRoZSByaWdodCBzZW5kZXIgdG8gbGV0IHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgd29y ay4gQW5kIHVuZGV0ZWN0YWJsZQ0KPiA+PiAgIHNwbGljaW5nIHdpbGwgbm90IGJlIGZ1bGZpbGxl ZCB3aGVuIHRoZSB0cmFuc2xhdG9yIHdvcmtzIGFzIHRoZQ0KPiA+PiAgIHNwbGljZXIuDQo+ID4+ ICINCj4gPj4NCj4gPj4gQmVzaWRlcyB0aGF0LCBhIG5ldyB0ZXJtaW5vbG9neSBpcyBkZWZpbmVk IGluIHNlY3Rpb24gMS4xIHRvIGRlZmluZQ0KPiAiVW5kZXRlY3RhYmxlIFNwbGljaW5nIiwgc2Vl IGJlbG93Og0KPiA+Pg0KPiA+PiAiDQo+ID4+IFVuZGV0ZWN0YWJsZSBTcGxpY2luZzoNCj4gPj4N Cj4gPj4gVGhlIFJUUCByZWNlaXZlcnMgYXJlIG5vdCBhYmxlIHRvIGRldGVjdCBhbnkgc3BsaWNp bmcgcG9pbnRzIGluIHRoZSBSVFAgbGF5ZXIuDQo+IFNvbWV0aW1lcywgc2VydmljZSBwcm92aWRl cnMgbWF5IHJlcXVpcmUgYW4gdW5kZXRlY3RhYmxlIHNwbGljaW5nIHRvIGF2b2lkIHRoZQ0KPiBS VFAgcmVjZWl2ZXJzIGZyb20gZmlsdGVyaW5nIG91dCB0aGUgYWR2ZXJ0aXNlbWVudCBjb250ZW50 Lg0KPiA+DQo+ID4gVGhhdCBwYXJ0aWN1bGFyIG1vdGl2YXRpb24gZ2l2ZXMgbWUgYSBiaXQgb2Yg aGVhcnRidXJuLiBCdXQgSSB0aGluayB0aGUgcmVhbGl0eQ0KPiBpcyB0aGF0IHRoZSBjb250ZW50 IHByb3ZpZGVyIHdhbnRzIHRvIHByb3ZpZGUgYW4gYXBwYXJlbnRseSBjb250aW51b3VzIHN0cmVh bSwNCj4gYW5kIHRoZXkgZG9uJ3QgdGhpbmsgdGhlIHRoZSBzcGxpY2luZyBkZXRhaWxzIGFyZSB0 aGUgYnVzaW5lc3Mgb2YgdGhlIHJlY2lwaWVudA0KPiAoYW55IG1vcmUgdGhhbiB0aGUgc3BsaWNl cyB0aGF0IG9jY3VyIGluIHRoZSBvcmlnaW5hbCBtZWRpYSBzdHJlYW0gaW5jaWRlbnQgdG8NCj4g dGhlIG5vcm1hbCBlZGl0aW5nIG9mIHRoZSBjb250ZW50LikNCj4gDQo+IEl04oCZcyBpbXBsaWVk LCBidXQgcGVyaGFwcyBlYXN5IHRvIG1pc3MgaW4gUmFjaGVs4oCZcyBzdWdnZXN0ZWQgdGV4dCwg dGhhdCB0aGlzIGlzDQo+IG9ubHkgdGFsa2luZyBhYm91dCB3aGV0aGVyIHRoZSBzcGxpY2luZyBp cyBkZXRlY3RhYmxlICphdCB0aGUgUlRQIGxheWVyKi4gQQ0KPiByZWNlaXZlciB0aGF04oCZcyB3 aWxsaW5nIHRvIGFuYWx5c2UgdGhlIG1ldGFkYXRhIGluIHRoZSBwYXlsb2FkIGNhbiBhbG1vc3QN Cj4gY2VydGFpbmx5IHRlbGwgdGhhdCB0aGUgY29udGVudCBjaGFuZ2VkIGZvciB0aGUgZHVyYXRp b24gb2YgdGhlIHNwbGljaW5nLCBldmVuDQo+IHdpdGhvdXQgZGVjb2RpbmcgdGhlIHZpZGVvLg0K PiANCj4gLS0NCj4gQ29saW4gUGVya2lucw0KPiBodHRwczovL2NzcGVya2lucy5vcmcvDQo+IA0K PiANCj4gDQoNCg== From nobody Tue Jun 21 20:13:45 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 8797012D891; Tue, 21 Jun 2016 20:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 e0ZCQkBFhc1c; Tue, 21 Jun 2016 20:13:36 -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 A0F7512D887; Tue, 21 Jun 2016 20:13:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRG52384; Wed, 22 Jun 2016 03:13:31 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Jun 2016 04:13:30 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Wed, 22 Jun 2016 11:13:21 +0800 From: "Huangyihong (Rachel)" To: Ben Campbell , Colin Perkins Thread-Topic: [avtext] Proposed text for Alia and other AD's DISCUSS Thread-Index: AQHRy/OtoxvIWlDAtk64LHRNLjGwPJ/z714AgAABSwCAAAE1gIAAC/kAgADOpiA= Date: Wed, 22 Jun 2016 03:13:21 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86ED8E92@nkgeml513-mbx.china.huawei.com> References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> <9894DE50-B2C3-49EE-B932-54254573D26F@nostrum.com> <01A5530D-A34F-4253-AB02-5439E3FFB99F@csperkins.org> <947DF280-60CD-41F4-B8F6-BD9B6C16C9F8@nostrum.com> In-Reply-To: <947DF280-60CD-41F4-B8F6-BD9B6C16C9F8@nostrum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.128] 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.0A090205.576A025C.00E9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c41ed1079ecf88d1459d989d32630bd7 Archived-At: Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" , Alia Atlas Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 22 Jun 2016 03:13:38 -0000 UGxlYXNlIHNlZSBiZWxvdy4NCg0KQlIsDQpSYWNoZWwNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJlbkBub3N0cnVtLmNvbV0N Cj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDIyLCAyMDE2IDY6NDEgQU0NCj4gVG86IENvbGluIFBl cmtpbnMNCj4gQ2M6IEh1YW5neWlob25nIChSYWNoZWwpOyBrYXRobGVlbi5tb3JpYXJ0eS5pZXRm QGdtYWlsLmNvbTsgTWlyamENCj4gS3VlaGxld2luZDsgQWxpYSBBdGxhczsgQWxpc3NhIENvb3Bl cjsgYXZ0ZXh0LWNoYWlyc0BpZXRmLm9yZzsNCj4gZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmct bm90aWZpY2F0aW9uQGlldGYub3JnOyBhdnRleHRAaWV0Zi5vcmc7IFRoZSBJRVNHOw0KPiBqb25h dGhhbkB2aWR5by5jb20NCj4gU3ViamVjdDogUmU6IFthdnRleHRdIFByb3Bvc2VkIHRleHQgZm9y IEFsaWEgYW5kIG90aGVyIEFEJ3MgRElTQ1VTUw0KPiANCj4gT24gMjEgSnVuIDIwMTYsIGF0IDE2 OjU3LCBDb2xpbiBQZXJraW5zIHdyb3RlOg0KPiANCj4gPj4gT24gMjEgSnVuIDIwMTYsIGF0IDIy OjUzLCBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbT4gd3JvdGU6DQo+ID4+DQo+ID4+IE9u IDIxIEp1biAyMDE2LCBhdCAxNjo0OCwgQ29saW4gUGVya2lucyB3cm90ZToNCj4gPj4NCj4gPj4+ PiBUaGF0IHBhcnRpY3VsYXIgbW90aXZhdGlvbiBnaXZlcyBtZSBhIGJpdCBvZiBoZWFydGJ1cm4u IEJ1dCBJIHRoaW5rDQo+ID4+Pj4gdGhlIHJlYWxpdHkgaXMgdGhhdCB0aGUgY29udGVudCBwcm92 aWRlciB3YW50cyB0byBwcm92aWRlIGFuDQo+ID4+Pj4gYXBwYXJlbnRseSBjb250aW51b3VzIHN0 cmVhbSwgYW5kIHRoZXkgZG9uJ3QgdGhpbmsgdGhlIHRoZSBzcGxpY2luZw0KPiA+Pj4+IGRldGFp bHMgYXJlIHRoZSBidXNpbmVzcyBvZiB0aGUgcmVjaXBpZW50IChhbnkgbW9yZSB0aGFuIHRoZQ0K PiA+Pj4+IHNwbGljZXMgdGhhdCBvY2N1ciBpbiB0aGUgb3JpZ2luYWwgbWVkaWEgc3RyZWFtIGlu Y2lkZW50IHRvIHRoZQ0KPiA+Pj4+IG5vcm1hbCBlZGl0aW5nIG9mIHRoZSBjb250ZW50LikNCj4g Pj4+DQo+ID4+Pg0KPiA+Pj4gSXTigJlzIGltcGxpZWQsIGJ1dCBwZXJoYXBzIGVhc3kgdG8gbWlz cyBpbiBSYWNoZWzigJlzIHN1Z2dlc3RlZCB0ZXh0LA0KPiA+Pj4gdGhhdCB0aGlzIGlzIG9ubHkg dGFsa2luZyBhYm91dCB3aGV0aGVyIHRoZSBzcGxpY2luZyBpcyBkZXRlY3RhYmxlDQo+ID4+PiAq YXQgdGhlIFJUUCBsYXllciouIEEgcmVjZWl2ZXIgdGhhdOKAmXMgd2lsbGluZyB0byBhbmFseXNl IHRoZQ0KPiA+Pj4gbWV0YWRhdGEgaW4gdGhlIHBheWxvYWQgY2FuIGFsbW9zdCBjZXJ0YWlubHkg dGVsbCB0aGF0IHRoZSBjb250ZW50DQo+ID4+PiBjaGFuZ2VkIGZvciB0aGUgZHVyYXRpb24gb2Yg dGhlIHNwbGljaW5nLCBldmVuIHdpdGhvdXQgZGVjb2RpbmcgdGhlDQo+ID4+PiB2aWRlby4NCj4g Pj4NCj4gPj4gT2theSwgdGhhdCdzIGEgZ29vZCBwb2ludC4gQnV0IG9uZSB3b25kZXJzIHdoeSBi b3RoZXIgd2l0aCB0aGUNCj4gPj4gZ3VpZGFuY2UgZm9yICJ1bmRldGVjdGFibGUgc3BsaWNlcyIg YXQgYWxsPyBJbiB0aGUgZXhhbXBsZSwgaWYgYW4NCj4gPj4gaW1wbGVtZW50YXRpb24gdGhhdCB3 YW50cyB0byBkbyBjb21tZXJjaWFsIHNraXBwaW5nIGNhbiBzdGlsbCBkbyBpdA0KPiA+PiBhbnl3 YXksIHRoZW4gd2h5IGV2ZW4gdGFsayBhYm91dCBpdD8gKE90aGVyIHRoYW4gdG8gc2F5IHRoYXQN Cj4gPj4gdW5kZXRlY3RhYmxlIHNwbGljZXMgYXJlbid0IHJlYWw/KQ0KPiA+DQo+ID4gSXQgKHNs aWdodGx5KSBzaW1wbGlmaWVzIHRoZSByZWNlaXZlciBpZiBpdCBjYW4gbm90IGNhcmUgYWJvdXQg c2VlaW5nDQo+ID4gbXVsdGlwbGUgc291cmNlcyAoZWl0aGVyIFNTUkMgb3IgQ1NSQywgZGVwZW5k aW5nIG9uIGhvdyB0aGUgc3BsaWNlcg0KPiA+IHdhcyBpbXBsZW1lbnRlZCkgaW4gdGhlIFJUUCBz dHJlYW0uDQo+IA0KPiBUaGF0IG1heSBiZSB0aGUgYmVzdCBtb3RpdmF0aW9uIGZvciBub3QgZm9y d2FyZGluZyB0aGUgaW5wdXQgU1NSQ3Mgb2ZmZXJlZCBzbw0KPiBmYXIuDQoNCg0KW1JhY2hlbF06 IEknbSB0aGluayBpZiBpdCdzIG9rYXkgdG8gbm90IHNwZWNpZnkgInVuZGV0ZWN0YWJsZSBzcGxp Y2luZyIgaW4gdGhpcyBkb2N1bWVudDogVGhpcyBkcmFmdCBpcyB0byBleHRlbmQgYSBSVFAgaGVh ZGVyIGV4dGVuc2lvbiBhbmQgUlRDUCBleHRlbnNpb24gbWVzc2FnZSBmb3Igc3BsaWNpbmcgaW50 ZXJ2YWwsIHdoaWNoIGlzIGFjdHVhbGx5IGEgbWVzc2FnZSBjb21tdW5pY2F0ZWQgYmV0d2VlbiB0 aGUgc2VuZGVyIGFuZCB0aGUgc3BsaWNlci4gU28gbWF5YmUgd2UganVzdCBuZWVkIHRvIHNwZWNp ZnkgdGhhdCB0aGUgc3BsaWNlciBNVVNUIE5PVCBmb3J3YXJkIHRoZXNlIGV4dGVuc2lvbnMgdG8g dGhlIHJlY2VpdmVycywgY2F1c2UgdGhlc2UgbWVzc2FnZXMgYXJlIHVzZWxlc3MgdG8gdGhlbS4g Rm9yIHVuZGV0ZWN0YWJsZSBzcGxpY2luZywgaXQgaGFzIGFscmVhZHkgYmVlbiB3cml0dGVuIGlu IFJGQzY4MjgsIHdoZXJlIHNwbGljZXIgd29ya3MgYXMgYSBtaXhlci4gSWYgdGhlIHNwbGljZXIg d29ya3MgYXMgYSB0cmFuc2xhdG9yLCBpdCdzIGltcG9zc2libGUgZm9yIHJlY2VpdmVycyBub3Qg dG8gZGV0ZWN0IHRoZSBzcGxpY2luZyBoYXBwZW5zIGluIFJUUCBsYXllci4gU28gSSBndWVzcyB0 aGVyZSdzIG5vIG5lZWQgdG8gc3BlY2lmeSBhbnkgdW5kZXRlY3RhYmxlIHNwbGljaW5nIGFjdGl2 aXRpZXMgaW4gdGhpcyBkb2N1bWVudC4gV2hhdCBkbyB5b3UgdGhpbms/DQoNCj4gDQo+ID4NCj4g PiAtLQ0KPiA+IENvbGluIFBlcmtpbnMNCj4gPiBodHRwczovL2NzcGVya2lucy5vcmcvDQo= From nobody Tue Jun 21 20:50:25 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C358F12DF53; Tue, 21 Jun 2016 20:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 HjuYUmz5fLsC; Tue, 21 Jun 2016 20:50: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 4531712D8B4; Tue, 21 Jun 2016 20:50:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMJ53982; Wed, 22 Jun 2016 03:50:10 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Jun 2016 04:50:09 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Wed, 22 Jun 2016 11:50:02 +0800 From: "Huangyihong (Rachel)" To: Alia Atlas , Colin Perkins Thread-Topic: [avtext] Proposed text for Alia and other AD's DISCUSS Thread-Index: AQHRy/OtoxvIWlDAtk64LHRNLjGwPJ/z714AgAABSwCAAAE1gIAAAqYAgADfH6A= Date: Wed, 22 Jun 2016 03:50:01 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86ED8ED9@nkgeml513-mbx.china.huawei.com> References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> <9894DE50-B2C3-49EE-B932-54254573D26F@nostrum.com> <01A5530D-A34F-4253-AB02-5439E3FFB99F@csperkins.org> 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.78.128] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB86ED8ED9nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.576A0AF3.0087, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5e6da0f055c9b919f1c3dcfdc0892173 Archived-At: Cc: "avtext@ietf.org" , "jonathan@vidyo.com" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 22 Jun 2016 03:50:17 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB86ED8ED9nkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxpYSwNCg0KUGxlYXNlIHNlZSBiZWxvdy4NCg0KQlIsDQpSYWNoZWwNCg0KRnJvbTogQWxp YSBBdGxhcyBbbWFpbHRvOmFrYXRsYXNAZ21haWwuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKdW5l IDIyLCAyMDE2IDY6MDcgQU0NClRvOiBDb2xpbiBQZXJraW5zDQpDYzogQmVuIENhbXBiZWxsOyBI dWFuZ3lpaG9uZyAoUmFjaGVsKTsga2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb207IE1p cmphIEt1ZWhsZXdpbmQ7IEFsaXNzYSBDb29wZXI7IGF2dGV4dC1jaGFpcnNAaWV0Zi5vcmc7IGRy YWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbkBpZXRmLm9yZzsgYXZ0ZXh0QGll dGYub3JnOyBUaGUgSUVTRzsgam9uYXRoYW5AdmlkeW8uY29tDQpTdWJqZWN0OiBSZTogW2F2dGV4 dF0gUHJvcG9zZWQgdGV4dCBmb3IgQWxpYSBhbmQgb3RoZXIgQUQncyBESVNDVVNTDQoNCkNvbGlu LA0KDQpUaGVzZSBhcmUgcmVhbGx5IHVzZWZ1bCBwb2ludHMgZm9yIG1lLg0KU28sIGluZGljYXRp bmcgdGhhdCB0aGUgcmVjZWl2ZXIgaGFzIGFncmVlZCB0byByZWNlaXZlIHRoZSBzdHJlYW0gdmlh IHRoZSBzcGxpY2VyIHdvdWxkIGhlbHAuDQpBcyB3cml0dGVuLCBpdCBzb3VuZHMgbGlrZSB0aGVy ZSBpcyBhIHJlcXVpcmVtZW50IHRvIGhpZGUgdGhlIHNwbGljaW5nIGZyb20gdGhlIHJlY2VpdmVy IC0gYW5kIGFsbA0KdGhlIG1vdGl2YXRpb25zIEkndmUgYmVlbiBoZWFyaW5nIGFyZSB0byAiZm9y Y2UiIHRoZSByZWNlaXZlciB0byBnZXQgdGhlIGluY2x1ZGVkIGFkdmVydGlzZW1lbnRzDQphbmQg bm90IGJlIGFibGUgdG8gdGVsbCB3aGVyZSB0aGV5IGFyZS4NCg0KW1JhY2hlbF06IEkgZ3Vlc3Mg dW5kZXRlY3RhYmxlIHNwbGljaW5nIGRvZXMgY2F1c2Ugc29tZSB1bmhhcHBpbmVzcy4gSSBzdWdn ZXN0IHRvIHJlbW92ZSBpdCBhbmQgcmVsYXRlZCB3b3JkcyBmcm9tIHRoaXMgZG9jdW1lbnQuDQpI b3dldmVyLCBldmVuIG5vdCBtZW50aW9uaW5nIHVuZGV0ZWN0YWJsZSBzcGxpY2luZywgaXQgc3Rp bGwgbWFrZXMgc2Vuc2UgZm9yIHRoZSBzcGxpY2VyIHRvIHJlbW92ZSB0aGUgaGVhZGVyIGV4dGVu c2lvbiB3aGVuIGZvcndhcmRpbmcgdGhlIG1lZGlhIGNvbnRlbnQgdG8gdGhlIHJlY2VpdmVycywg c2luY2UgdGhlIFJUUCBzZW5kZXIgaW50ZW5kcyB0byBzZW5kIHRoZSBzcGxpY2luZyBpbnRlcnZh bCBtZXNzYWdlcyB0byB0aGUgc3BsaWNlciwgbm90IHRoZSByZWNlaXZlcnMsIGFuZCB0aGUgc3Bs aWNlciBpcyBvbiBiZWhhbGYgb2YgdGhlIFJUUCBzZW5kZXIgdG8gZm9yd2FyZCB0aGUgY29udGVu dC4gU28gaW4gdGhhdCBjYXNlIEkgZG9u4oCZdCB0aGluayBpdOKAmXMg4oCcaGlkaW5n4oCdIG9y IOKAnGZvcmNl4oCdIHRoZSByZWNlaXZlIHRvIGdldCB0aGUgYWR2ZXJ0aXNlbWVudHMuIFRoZSB0 aW1lIHdpbmRvdyBpcyB0aGVyZSwgZXZlbiB0aGVyZeKAmXMgbm90IHN1YnN0aXR1dGl2ZSBhZHZl cnRpc2VtZW50IHNwbGljZWQgaW4sIGl0IHN0aWxsIGNvbnRhaW5zIG9yaWdpbmFsIGFkdmVydGlz ZW1lbnRzLg0KDQpSZWdhcmRzLA0KQWxpYQ0KDQpPbiBUdWUsIEp1biAyMSwgMjAxNiBhdCA1OjU3 IFBNLCBDb2xpbiBQZXJraW5zIDxjc3BAY3NwZXJraW5zLm9yZzxtYWlsdG86Y3NwQGNzcGVya2lu cy5vcmc+PiB3cm90ZToNCj4gT24gMjEgSnVuIDIwMTYsIGF0IDIyOjUzLCBCZW4gQ2FtcGJlbGwg PGJlbkBub3N0cnVtLmNvbTxtYWlsdG86YmVuQG5vc3RydW0uY29tPj4gd3JvdGU6DQo+DQo+IE9u IDIxIEp1biAyMDE2LCBhdCAxNjo0OCwgQ29saW4gUGVya2lucyB3cm90ZToNCj4NCj4+PiBUaGF0 IHBhcnRpY3VsYXIgbW90aXZhdGlvbiBnaXZlcyBtZSBhIGJpdCBvZiBoZWFydGJ1cm4uIEJ1dCBJ IHRoaW5rIHRoZSByZWFsaXR5IGlzIHRoYXQgdGhlIGNvbnRlbnQgcHJvdmlkZXIgd2FudHMgdG8g cHJvdmlkZSBhbiBhcHBhcmVudGx5IGNvbnRpbnVvdXMgc3RyZWFtLCBhbmQgdGhleSBkb24ndCB0 aGluayB0aGUgdGhlIHNwbGljaW5nIGRldGFpbHMgYXJlIHRoZSBidXNpbmVzcyBvZiB0aGUgcmVj aXBpZW50IChhbnkgbW9yZSB0aGFuIHRoZSBzcGxpY2VzIHRoYXQgb2NjdXIgaW4gdGhlIG9yaWdp bmFsIG1lZGlhIHN0cmVhbSBpbmNpZGVudCB0byB0aGUgbm9ybWFsIGVkaXRpbmcgb2YgdGhlIGNv bnRlbnQuKQ0KPj4NCj4+DQo+PiBJdOKAmXMgaW1wbGllZCwgYnV0IHBlcmhhcHMgZWFzeSB0byBt aXNzIGluIFJhY2hlbOKAmXMgc3VnZ2VzdGVkIHRleHQsIHRoYXQgdGhpcyBpcyBvbmx5IHRhbGtp bmcgYWJvdXQgd2hldGhlciB0aGUgc3BsaWNpbmcgaXMgZGV0ZWN0YWJsZSAqYXQgdGhlIFJUUCBs YXllciouIEEgcmVjZWl2ZXIgdGhhdOKAmXMgd2lsbGluZyB0byBhbmFseXNlIHRoZSBtZXRhZGF0 YSBpbiB0aGUgcGF5bG9hZCBjYW4gYWxtb3N0IGNlcnRhaW5seSB0ZWxsIHRoYXQgdGhlIGNvbnRl bnQgY2hhbmdlZCBmb3IgdGhlIGR1cmF0aW9uIG9mIHRoZSBzcGxpY2luZywgZXZlbiB3aXRob3V0 IGRlY29kaW5nIHRoZSB2aWRlby4NCj4NCj4gT2theSwgdGhhdCdzIGEgZ29vZCBwb2ludC4gQnV0 IG9uZSB3b25kZXJzIHdoeSBib3RoZXIgd2l0aCB0aGUgZ3VpZGFuY2UgZm9yICJ1bmRldGVjdGFi bGUgc3BsaWNlcyIgYXQgYWxsPyBJbiB0aGUgZXhhbXBsZSwgaWYgYW4gaW1wbGVtZW50YXRpb24g dGhhdCB3YW50cyB0byBkbyBjb21tZXJjaWFsIHNraXBwaW5nIGNhbiBzdGlsbCBkbyBpdCBhbnl3 YXksIHRoZW4gd2h5IGV2ZW4gdGFsayBhYm91dCBpdD8gKE90aGVyIHRoYW4gdG8gc2F5IHRoYXQg dW5kZXRlY3RhYmxlIHNwbGljZXMgYXJlbid0IHJlYWw/KQ0KDQpJdCAoc2xpZ2h0bHkpIHNpbXBs aWZpZXMgdGhlIHJlY2VpdmVyIGlmIGl0IGNhbiBub3QgY2FyZSBhYm91dCBzZWVpbmcgbXVsdGlw bGUgc291cmNlcyAoZWl0aGVyIFNTUkMgb3IgQ1NSQywgZGVwZW5kaW5nIG9uIGhvdyB0aGUgc3Bs aWNlciB3YXMgaW1wbGVtZW50ZWQpIGluIHRoZSBSVFAgc3RyZWFtLg0KDQotLQ0KQ29saW4gUGVy a2lucw0KaHR0cHM6Ly9jc3BlcmtpbnMub3JnLw0KDQoNCg0KDQo= --_000_51E6A56BD6A85142B9D172C87FC3ABBB86ED8ED9nkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBBbGlh LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QbGVhc2Ugc2VlIGJlbG93Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVz dGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1q dXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SYWNoZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g QWxpYSBBdGxhcyBbbWFpbHRvOmFrYXRsYXNAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IFdlZG5lc2RheSwgSnVuZSAyMiwgMjAxNiA2OjA3IEFNPGJyPg0KPGI+VG86PC9iPiBDb2xpbiBQ ZXJraW5zPGJyPg0KPGI+Q2M6PC9iPiBCZW4gQ2FtcGJlbGw7IEh1YW5neWlob25nIChSYWNoZWwp OyBrYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbTsgTWlyamEgS3VlaGxld2luZDsgQWxp c3NhIENvb3BlcjsgYXZ0ZXh0LWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1hdnRleHQtc3Bs aWNpbmctbm90aWZpY2F0aW9uQGlldGYub3JnOyBhdnRleHRAaWV0Zi5vcmc7IFRoZSBJRVNHOyBq b25hdGhhbkB2aWR5by5jb208YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFthdnRleHRdIFByb3Bv c2VkIHRleHQgZm9yIEFsaWEgYW5kIG90aGVyIEFEJ3MgRElTQ1VTUzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Db2xpbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5UaGVzZSBhcmUgcmVhbGx5IHVzZWZ1bCBwb2ludHMgZm9yIG1lLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5TbywgaW5kaWNhdGluZyB0aGF0IHRoZSByZWNlaXZlciBoYXMg YWdyZWVkIHRvIHJlY2VpdmUgdGhlIHN0cmVhbSB2aWEgdGhlIHNwbGljZXIgd291bGQgaGVscC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+QXMgd3JpdHRlbiwgaXQgc291bmRzIGxpa2UgdGhlcmUgaXMg YSByZXF1aXJlbWVudCB0byBoaWRlIHRoZSBzcGxpY2luZyBmcm9tIHRoZSByZWNlaXZlciAtIGFu ZCBhbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+dGhlIG1vdGl2YXRpb25zIEkndmUgYmVlbiBoZWFy aW5nIGFyZSB0byAmcXVvdDtmb3JjZSZxdW90OyB0aGUgcmVjZWl2ZXIgdG8gZ2V0IHRoZSBpbmNs dWRlZCBhZHZlcnRpc2VtZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5hbmQgbm90IGJlIGFibGUg dG8gdGVsbCB3aGVyZSB0aGV5IGFyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+W1JhY2hlbF06IEkgZ3Vlc3MgdW5kZXRlY3RhYmxlIHNwbGljaW5nIGRvZXMgY2F1c2Ugc29t ZSB1bmhhcHBpbmVzcy4gSSBzdWdnZXN0IHRvIHJlbW92ZSBpdCBhbmQgcmVsYXRlZCB3b3JkcyBm cm9tIHRoaXMgZG9jdW1lbnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhvd2V2ZXIsIGV2ZW4gbm90IG1lbnRpb25pbmcgdW5kZXRlY3RhYmxlIHNwbGljaW5n LCBpdCBzdGlsbCBtYWtlcyBzZW5zZSBmb3IgdGhlIHNwbGljZXIgdG8gcmVtb3ZlIHRoZSBoZWFk ZXIgZXh0ZW5zaW9uIHdoZW4gZm9yd2FyZGluZyB0aGUgbWVkaWENCiBjb250ZW50IHRvIHRoZSBy ZWNlaXZlcnMsIHNpbmNlIHRoZSBSVFAgc2VuZGVyIGludGVuZHMgdG8gc2VuZCB0aGUgc3BsaWNp bmcgaW50ZXJ2YWwgbWVzc2FnZXMgdG8gdGhlIHNwbGljZXIsIG5vdCB0aGUgcmVjZWl2ZXJzLCBh bmQgdGhlIHNwbGljZXIgaXMgb24gYmVoYWxmIG9mIHRoZSBSVFAgc2VuZGVyIHRvIGZvcndhcmQg dGhlIGNvbnRlbnQuIFNvIGluIHRoYXQgY2FzZSBJIGRvbuKAmXQgdGhpbmsgaXTigJlzIOKAnGhp ZGluZ+KAnSBvciDigJxmb3JjZeKAnSB0aGUNCiByZWNlaXZlIHRvIGdldCB0aGUgYWR2ZXJ0aXNl bWVudHMuIFRoZSB0aW1lIHdpbmRvdyBpcyB0aGVyZSwgZXZlbiB0aGVyZeKAmXMgbm90IHN1YnN0 aXR1dGl2ZSBhZHZlcnRpc2VtZW50IHNwbGljZWQgaW4sIGl0IHN0aWxsIGNvbnRhaW5zIG9yaWdp bmFsIGFkdmVydGlzZW1lbnRzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BbGlhPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBUdWUsIEp1biAyMSwg MjAxNiBhdCA1OjU3IFBNLCBDb2xpbiBQZXJraW5zICZsdDs8YSBocmVmPSJtYWlsdG86Y3NwQGNz cGVya2lucy5vcmciIHRhcmdldD0iX2JsYW5rIj5jc3BAY3NwZXJraW5zLm9yZzwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7IE9uIDIxIEp1biAyMDE2LCBhdCAyMjo1MywgQmVuIENhbXBiZWxsICZs dDs8YSBocmVmPSJtYWlsdG86YmVuQG5vc3RydW0uY29tIj5iZW5Abm9zdHJ1bS5jb208L2E+Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiAyMSBKdW4gMjAxNiwgYXQgMTY6NDgsIENv bGluIFBlcmtpbnMgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUaGF0IHBhcnRp Y3VsYXIgbW90aXZhdGlvbiBnaXZlcyBtZSBhIGJpdCBvZiBoZWFydGJ1cm4uIEJ1dCBJIHRoaW5r IHRoZSByZWFsaXR5IGlzIHRoYXQgdGhlIGNvbnRlbnQgcHJvdmlkZXIgd2FudHMgdG8gcHJvdmlk ZSBhbiBhcHBhcmVudGx5IGNvbnRpbnVvdXMgc3RyZWFtLCBhbmQgdGhleSBkb24ndCB0aGluayB0 aGUgdGhlIHNwbGljaW5nIGRldGFpbHMgYXJlIHRoZSBidXNpbmVzcyBvZiB0aGUgcmVjaXBpZW50 IChhbnkgbW9yZSB0aGFuDQogdGhlIHNwbGljZXMgdGhhdCBvY2N1ciBpbiB0aGUgb3JpZ2luYWwg bWVkaWEgc3RyZWFtIGluY2lkZW50IHRvIHRoZSBub3JtYWwgZWRpdGluZyBvZiB0aGUgY29udGVu dC4pPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEl04oCZcyBpbXBs aWVkLCBidXQgcGVyaGFwcyBlYXN5IHRvIG1pc3MgaW4gUmFjaGVs4oCZcyBzdWdnZXN0ZWQgdGV4 dCwgdGhhdCB0aGlzIGlzIG9ubHkgdGFsa2luZyBhYm91dCB3aGV0aGVyIHRoZSBzcGxpY2luZyBp cyBkZXRlY3RhYmxlICphdCB0aGUgUlRQIGxheWVyKi4gQSByZWNlaXZlciB0aGF04oCZcyB3aWxs aW5nIHRvIGFuYWx5c2UgdGhlIG1ldGFkYXRhIGluIHRoZSBwYXlsb2FkIGNhbiBhbG1vc3QgY2Vy dGFpbmx5IHRlbGwgdGhhdCB0aGUNCiBjb250ZW50IGNoYW5nZWQgZm9yIHRoZSBkdXJhdGlvbiBv ZiB0aGUgc3BsaWNpbmcsIGV2ZW4gd2l0aG91dCBkZWNvZGluZyB0aGUgdmlkZW8uPGJyPg0KJmd0 Ozxicj4NCiZndDsgT2theSwgdGhhdCdzIGEgZ29vZCBwb2ludC4gQnV0IG9uZSB3b25kZXJzIHdo eSBib3RoZXIgd2l0aCB0aGUgZ3VpZGFuY2UgZm9yICZxdW90O3VuZGV0ZWN0YWJsZSBzcGxpY2Vz JnF1b3Q7IGF0IGFsbD8gSW4gdGhlIGV4YW1wbGUsIGlmIGFuIGltcGxlbWVudGF0aW9uIHRoYXQg d2FudHMgdG8gZG8gY29tbWVyY2lhbCBza2lwcGluZyBjYW4gc3RpbGwgZG8gaXQgYW55d2F5LCB0 aGVuIHdoeSBldmVuIHRhbGsgYWJvdXQgaXQ/IChPdGhlciB0aGFuIHRvIHNheSB0aGF0DQogdW5k ZXRlY3RhYmxlIHNwbGljZXMgYXJlbid0IHJlYWw/KTxicj4NCjxicj4NCkl0IChzbGlnaHRseSkg c2ltcGxpZmllcyB0aGUgcmVjZWl2ZXIgaWYgaXQgY2FuIG5vdCBjYXJlIGFib3V0IHNlZWluZyBt dWx0aXBsZSBzb3VyY2VzIChlaXRoZXIgU1NSQyBvciBDU1JDLCBkZXBlbmRpbmcgb24gaG93IHRo ZSBzcGxpY2VyIHdhcyBpbXBsZW1lbnRlZCkgaW4gdGhlIFJUUCBzdHJlYW0uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQotLTxicj4NCkNvbGlu IFBlcmtpbnM8YnI+DQo8YSBocmVmPSJodHRwczovL2NzcGVya2lucy5vcmcvIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly9jc3BlcmtpbnMub3JnLzwvYT48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_51E6A56BD6A85142B9D172C87FC3ABBB86ED8ED9nkgeml513mbxchi_-- From nobody Tue Jun 21 22:30:59 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 B129B12D894; Tue, 21 Jun 2016 22:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 13BFHbEv_IHH; Tue, 21 Jun 2016 22:30:56 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7096412D1AF; Tue, 21 Jun 2016 22:30:56 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id f6so58593878lfg.0; Tue, 21 Jun 2016 22:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=kvkuOE3gHXjU0g8+xg2yz0BOZRgLkjALp+TL6vT3edc=; b=w/wefAxVnZJB6rRW7GvdI2++VlTIIe97rqEV3czmLJYHHdxbBmJk0rhyi9a9WHFxvL eJ0t/6TO0aKz+gCERz+jDI7WlM9kG/uUbj69qFuqa2p65DBgfwt2/sNWmaM+d3z7smzD vf1PCQbu4A2wlvIVMR2fBvrZI1d8o7XXRXY9dh3srqTZQOSyHOx4gTlyYsiuX0zxGVMQ E5EINXafz295zUIa1VK6Jf+84fBVxzXTbngGr/3OFDxzGSl/o+9lmb3qD0Jpq4NP5rEF 4Ohf+6PjAfm3WwYULpg9/aIMDdybQHXlRHL7qT8i1t1pc1xvaQPXz3CYp2ezr6lrTCoN KBbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=kvkuOE3gHXjU0g8+xg2yz0BOZRgLkjALp+TL6vT3edc=; b=TXg+1Y/065cK3qQH5dcOyRk6maZ6ATQoB7wbfPmtp8EqsRNiVRGBve/CpaqqFRUDnT D+iAg0u8GUZdyNccLku/rFBco2RgXYgpM2r2A81F7oSKtG5XTHM16bTULFom4nBbdjwZ nYyRUZ45CopGmYS2l3dqz90jZ/8eDlXuiLRvVJ7f9QDFHfm44ATzJVaobZaNlCorSdEq 8PG1svnGVyMrhuA96WicGxc9Kk45mp6RMGEjIvdgXcZBeFqaAdBaxDrogMZPypxmCNnp 4kwECu+r8o35OIxXtGEfl23O2f8w8+z31yklfzGogKhIEEQg5xAqroUsVDhmvsJzkdpo Gn1w== X-Gm-Message-State: ALyK8tKKIh2iSzN/qYX3SrG0lxRfib5m6Nf57KYFm4cUhXuJz5p9VuBuGimHJgeqmO0mgA== X-Received: by 10.28.104.214 with SMTP id d205mr6373942wmc.102.1466573454646; Tue, 21 Jun 2016 22:30:54 -0700 (PDT) Received: from RoniPC (bzq-79-179-194-235.red.bezeqint.net. [79.179.194.235]) by smtp.gmail.com with ESMTPSA id v200sm6128747wmv.4.2016.06.21.22.30.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2016 22:30:53 -0700 (PDT) From: "Roni Even" To: "'Colin Perkins'" , "'Stephen Farrell'" References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> <5769C301.5080908@cs.tcd.ie> In-Reply-To: Date: Wed, 22 Jun 2016 08:29:28 +0300 Message-ID: <136301d1cc47$0d817fb0$28847f10$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLMM70r+h1W5iU43V9EC9lZyTXemgC2M80TAhwaUOUBXVJYnwMQYd2nAdUnZEcCj0NnXAEy++LJASqjcHedkBYBUA== Content-Language: he Archived-At: Cc: avtext@ietf.org, jonathan@vidyo.com, avtext-chairs@ietf.org, kathleen.moriarty.ietf@gmail.com, 'Mirja Kuehlewind' , 'The IESG' , draft-ietf-avtext-splicing-notification@ietf.org, 'Alia Atlas' Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 22 Jun 2016 05:30:59 -0000 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Wednesday, June 22, 2016 1:55 AM > To: Stephen Farrell > Cc: Ben Campbell; jonathan@vidyo.com; avtext@ietf.org; Huangyihong; > Alissa Cooper; avtext-chairs@ietf.org; = kathleen.moriarty.ietf@gmail.com; > Mirja Kuehlewind; The IESG; = draft-ietf-avtext-splicing-notification@ietf.org; > Alia Atlas > Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS >=20 > > On 21 Jun 2016, at 23:43, Stephen Farrell = > wrote: > > On 21/06/16 22:48, Colin Perkins wrote: > >> The other point that=E2=80=99s probably worth noting is that the = receiver > >> knows the traffic is being routed via the middlebox, and explicitly > >> communicates with that middlebox via the RTCP reception reports it > >> returns, and possibly also via some non-RTP signalling channel > > > > Sorry if I'm taking that out of context, but I don't understand the > > above. > > > > How does the receiver s/w know that it is interacting with a device > > that is messing about with the content? I understood that it was in > > fact a requirement here to make it hard for the receiver to be sure = of > > that. >=20 > My point was that the receiver has to be explicitly configured to get = the > media from the splicer, and the splicer can=E2=80=99t interpose itself = in the media > stream unless both sender and receiver chose to use it. [Roni Even] This may also be a redirect by the source to splicer since = this is where all the content is coming from >=20 > > I ask about the receiver s/w above, as clearly the warm body that = may > > have eyeballs pointed at content has no idea that the splicer is in > > the path. > > > >> (the > >> sender likely offers it no choice but to use the middlebox if it > >> wants access to the media stream, but that=E2=80=99s a different = issue=E2=80=A6) > > > > Indeed > > > > S. > > > > . > > >=20 >=20 >=20 > -- > Colin Perkins > https://csperkins.org/ >=20 >=20 From nobody Wed Jun 22 08:21: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 7D33012D81B; Wed, 22 Jun 2016 08:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiWbIsqoIoMC; Wed, 22 Jun 2016 08:21:00 -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 15F0512D81C; Wed, 22 Jun 2016 08:08:51 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5MF8Mpj000214 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 Jun 2016 10:08:23 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: Huangyihong Date: Wed, 22 Jun 2016 10:08:25 -0500 Message-ID: In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86ED8E77@nkgeml513-mbx.china.huawei.com> References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8E77@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: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" , Alia Atlas , Colin Perkins Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 22 Jun 2016 15:21:01 -0000 On 21 Jun 2016, at 21:59, Huangyihong (Rachel) wrote: [...] >>>> 2.1 Overview of RTP Splicing >>>> >>>> RTP Splicing is to replace some multimedia content with certain >>>> substitutive multimedia content, and then forward it to the >>>> receivers >>>> for a period of time. This process is authorized by the service >>>> provider who sends the multimedia content to these receivers. A >>>> typical usage is that IPTV service providers use their own >>>> regional >>>> advertising content to replace national advertising content >>>> provided >>>> by the content providers. >>> >>> I think this could be strengthened a bit. IIUC, this mechanism >>> assumes the >> splicing interval is sent _by_ the main content provider. That is, >> this mechanism >> only works with the permission of the content provider. If they don't >> consent, >> they simply won't send the splicing interval. >>> >>> This relationship might be more clear if the example talked about >>> the main >> content provider offering a time window for the regional advertising >> insert, >> rather than about replacing national advertising. While that might in >> fact >> replace national content, it should be clear that the main provider >> _intends_ for >> the insert to happen. >> >> Right. > > > [Rachel]: According to your suggestions, how about changing the above > text to below > > " > RTP Splicing is to replace some multimedia content with certain > substitutive multimedia content, and then forward it to the > receivers > for a period of time. This process is authorized by the main RTP > sender that offers a specific time window for inserting the > substitutive multimedia content in the main content. A typical > usage > is that a IPTV service provider uses its own regional advertising > content to replace national advertising content, the time window of > which is explicitly indicated by the IPTV service provider. > " > I think that helps. I suggest the following (in the first sentence): s/RTP Splicing is to replace.../RTP Splicing replaces... (Or "RTP Splicing is intended to replace.." >> >> The other point that’s probably worth noting is that the receiver >> knows the >> traffic is being routed via the middlebox, and explicitly >> communicates with that >> middlebox via the RTCP reception reports it returns, and possibly >> also via some >> non-RTP signalling channel (the sender likely offers it no choice but >> to use the >> middlebox if it wants access to the media stream, but that’s a >> different >> issue…). > > [Rachel]: Based on this suggestion, I propose to add a sentences in > the end of the 2nd paragraph: > > " > The splicer is a middlebox handling RTP splicing. It receives main > content and substitutive content simultaneously but only chooses to > send one of them to the receiver at any point of time. When RTP > splicing begins, the splicer sends the substitutive content to the > receivers instead of the main content. When RTP splicing ends, the > splicer switches back to sending the main content to the receivers. > This implies that the traffic is routed via the splicer to the > receivers. And the splicer is explicitly communicated with the > receivers via RTCP packets and possibly via non-RTP signaling > channel. > " > Should the last sentence read "And the presence of the splicer..."? Otherwise it looks good. [...] From nobody Wed Jun 22 08:25: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 B90B212DAA4; Wed, 22 Jun 2016 08:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW1NoJM6-Jge; Wed, 22 Jun 2016 08:25:41 -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 657F912D8E1; Wed, 22 Jun 2016 08:13:05 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5MFCn2e000902 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 Jun 2016 10:12:50 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: Huangyihong Date: Wed, 22 Jun 2016 10:12:52 -0500 Message-ID: <6CD06201-4FCD-4934-ADF0-18ED3A3D4BF8@nostrum.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86ED8E92@nkgeml513-mbx.china.huawei.com> References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> <9894DE50-B2C3-49EE-B932-54254573D26F@nostrum.com> <01A5530D-A34F-4253-AB02-5439E3FFB99F@csperkins.org> <947DF280-60CD-41F4-B8F6-BD9B6C16C9F8@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8E92@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: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" , Alia Atlas , Colin Perkins Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 22 Jun 2016 15:25:43 -0000 On 21 Jun 2016, at 22:13, Huangyihong (Rachel) wrote: > Please see below. > > BR, > Rachel > > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Wednesday, June 22, 2016 6:41 AM >> To: Colin Perkins >> Cc: Huangyihong (Rachel); kathleen.moriarty.ietf@gmail.com; Mirja >> Kuehlewind; Alia Atlas; Alissa Cooper; avtext-chairs@ietf.org; >> draft-ietf-avtext-splicing-notification@ietf.org; avtext@ietf.org; >> The IESG; >> jonathan@vidyo.com >> Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS >> >> On 21 Jun 2016, at 16:57, Colin Perkins wrote: >> >>>> On 21 Jun 2016, at 22:53, Ben Campbell wrote: >>>> >>>> On 21 Jun 2016, at 16:48, Colin Perkins wrote: >>>> >>>>>> That particular motivation gives me a bit of heartburn. But I >>>>>> think >>>>>> the reality is that the content provider wants to provide an >>>>>> apparently continuous stream, and they don't think the the >>>>>> splicing >>>>>> details are the business of the recipient (any more than the >>>>>> splices that occur in the original media stream incident to the >>>>>> normal editing of the content.) >>>>> >>>>> >>>>> It’s implied, but perhaps easy to miss in Rachel’s suggested >>>>> text, >>>>> that this is only talking about whether the splicing is detectable >>>>> *at the RTP layer*. A receiver that’s willing to analyse the >>>>> metadata in the payload can almost certainly tell that the content >>>>> changed for the duration of the splicing, even without decoding >>>>> the >>>>> video. >>>> >>>> Okay, that's a good point. But one wonders why bother with the >>>> guidance for "undetectable splices" at all? In the example, if an >>>> implementation that wants to do commercial skipping can still do it >>>> anyway, then why even talk about it? (Other than to say that >>>> undetectable splices aren't real?) >>> >>> It (slightly) simplifies the receiver if it can not care about >>> seeing >>> multiple sources (either SSRC or CSRC, depending on how the splicer >>> was implemented) in the RTP stream. >> >> That may be the best motivation for not forwarding the input SSRCs >> offered so >> far. > > > [Rachel]: I'm think if it's okay to not specify "undetectable > splicing" in this document: This draft is to extend a RTP header > extension and RTCP extension message for splicing interval, which is > actually a message communicated between the sender and the splicer. So > maybe we just need to specify that the splicer MUST NOT forward these > extensions to the receivers, cause these messages are useless to them. > For undetectable splicing, it has already been written in RFC6828, > where splicer works as a mixer. If the splicer works as a translator, > it's impossible for receivers not to detect the splicing happens in > RTP layer. So I guess there's no need to specify any undetectable > splicing activities in this document. What do you think? I'm generally okay with that, but I want to see what others think, I do, though, wonder if the MUST NOT is still justified at this point. If the motivation is just that forwarding the messages are useless, or even a nuisance, MUST seems a bit strong. That is, it doesn't seem to impact interoperability, or otherwise create a real problem. This seems better stated without 2119 keywords. > >> >>> >>> -- >>> Colin Perkins >>> https://csperkins.org/ From nobody Wed Jun 22 09:15:24 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 11A8F12D7E0 for ; Wed, 22 Jun 2016 09:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBodQ3sOFdJR for ; Wed, 22 Jun 2016 09:15:19 -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 C80D112D89E for ; Wed, 22 Jun 2016 09:09:06 -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 u5MG0j3B012946; Wed, 22 Jun 2016 12:09:05 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 23kfmh49wh-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 22 Jun 2016 12:09:05 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Wed, 22 Jun 2016 11:09:03 -0500 From: Jonathan Lennox To: Adam Roach Thread-Topic: RID needs proper header extension registrations Thread-Index: AQHRzKBk2yD418DZTkO02fvQ/fgCug== Date: Wed, 22 Jun 2016 16:09:02 +0000 Message-ID: <12858949-AD94-4B45-B383-9D5396DA16D0@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.3, 0.0.0000 definitions=2016-06-22_10:2016-06-22,2016-06-22,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1603290000 definitions=main-1606220165 Archived-At: Cc: "avtext@ietf.org" , "Suhas Nandakumar \(snandaku\)" Subject: [avtext] RID needs proper header extension registrations X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 16:15:22 -0000 SGksIEFkYW0g4oCUDQoNCkkgcmVhbGl6ZWQgb24gd3JpdGluZyB1cCB0aGUgUHViUmVxIGZvciBS SUQgdGhhdCBpdCBuZWVkcyBwcm9wZXIgcmVnaXN0cmF0aW9uIGZvciB0aGUgc2Rlcy1oZHItZXh0 IGl0ZW1zIOKAlCB3ZSBuZWVkIHRvIG1lbnRpb24gdGhlIFNERVMgaGVhZGVyIGV4dGVuc2lvbiBJ QU5BIHJlZ2lzdHJ5LCBleHBsaWNpdGx5IHN0YXRlIHRoZSBVUk5zIGltcGxlbWVudGF0aW9ucyBz aG91bGQgdXNlLCBldGMuDQoNClNlZSB0aGUgZGlzY3Vzc2lvbiBvZiBNSUQgb24gTU1VU0lDIGlu IHRoZSBsYXN0IGZldyBkYXlzLg0KDQpJdCBwcm9iYWJseSBuZWVkcyBtb3JlIGV4cGxhbmF0aW9u IG9mIHRoZSBwcml2YWN5IGFuZCB0aW1lbGluZXNzIGNvbnNpZGVyYXRpb25zIGZvciB0aGUgU0RF UyBpdGVtcywgdG9vLCBhcyBNYWdudXMgcG9pbnRlZCBvdXQgZm9yIE1JRC4NCg0KU29ycnkgSSBk aWRu4oCZdCBjYXRjaCB0aGlzIHNvb25lci4NCg0KLUpvbmF0aGFuDQoNCg== From nobody Wed Jun 22 09:19: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 2756112D8B1; Wed, 22 Jun 2016 09:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] 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 ZIPtvDN3NyBo; Wed, 22 Jun 2016 09:19:44 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 7E46012D67A; Wed, 22 Jun 2016 09:16:22 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id t127so71614662qkf.1; Wed, 22 Jun 2016 09:16:22 -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=gZYZQvDmQiGVH25amSqUW5949c9BJcYGmFD9vf4WDfM=; b=WIkQyV7QfV89g/lVZ23+zFtBYhiExfdZl2nbdiba+wvjSpefqgDpC0DBvHxwK9qiKy 00QwXNjH0B7psAg8R5sk4KilfTpz4xWK5uKL+9Tmei6DE/8dJ07lJIq2Q4A9c2ypz5xr q4XLq9t2KM6PL5D/GiVmqmpHlMJ8ZhCfRmXxoX0ZreD9aO4UkZ27cx0qnGfVp+Lxle4h Eq95P8JDKU5dHQf0E6pow3vJwQ7U7x7rgDFfRH+cHMYelGsYX1GoeXPXHHYEN+XZlVDG drc1tBw1XOCnkRiWlCoWGJobQuS2TS+KNUTgKmgTX+3SdqEVnatJxqZGYX2s0X1xt/9h eodg== 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=gZYZQvDmQiGVH25amSqUW5949c9BJcYGmFD9vf4WDfM=; b=I+xLbbnUeaKUkrHV57caDt5hdz9KHsdu0RuyoyOs+k7c91qZPGWAFH/8CHiDNBa0Bv kCJ3YRxyFBLk8F/ZhE27OFMeUR32PNYBJ+39lCz4V7L5VLOg2kBb8BbhfgWAwOepQb8U KMBNPSCnlhOyx1weSITOsHL1PgvRMGWdydMSx/CWTmH1n4MibdXITl9bKjyTSgYtkmWr ivkRoymcL3ArIjSW5t9WGYTQz7Qq8W3ataVcAtMCKZN8XuKBlHs/fvXekhYnouSACKY4 1N4gSt3/PNFDE+YjVVV41xaGgG3FKqSN+MvYuOjGp9CXsjRhsgbh4lpoau7XttjyfscC cNgA== X-Gm-Message-State: ALyK8tKnXzgV0sJXLmZ6rYPpGOhrem9Qf0jLVl4RujOE1Q6bpU4y1AzFg9urxXA5cb+xGn7qmn5VgbulFJ8UXw== X-Received: by 10.200.48.207 with SMTP id w15mr38327876qta.50.1466612181464; Wed, 22 Jun 2016 09:16:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.57.81 with HTTP; Wed, 22 Jun 2016 09:16:20 -0700 (PDT) In-Reply-To: <30A9FC33-3D57-4EFF-B66A-07609A9E1548@csperkins.org> References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> <9894DE50-B2C3-49EE-B932-54254573D26F@nostrum.com> <01A5530D-A34F-4253-AB02-5439E3FFB99F@csperkins.org> <30A9FC33-3D57-4EFF-B66A-07609A9E1548@csperkins.org> From: Alia Atlas Date: Wed, 22 Jun 2016 12:16:20 -0400 Message-ID: To: Colin Perkins Content-Type: multipart/alternative; boundary=001a1147b6721982b50535e04293 Archived-At: Cc: "avtext@ietf.org" , "jonathan@vidyo.com" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 22 Jun 2016 16:19:46 -0000 --001a1147b6721982b50535e04293 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Colin, On Tue, Jun 21, 2016 at 6:18 PM, Colin Perkins wrote: > Alia, > > On 21 Jun 2016, at 23:07, Alia Atlas wrote: > > Colin, > > These are really useful points for me. > So, indicating that the receiver has agreed to receive the stream via the > splicer would help. > > > You mean add something to the draft saying =E2=80=9Cthe sender and receiv= er have > to be explicitly configured to use the splicer=E2=80=9D? Maybe also with = some words > in the security considerations explaining that there=E2=80=99s a signalli= ng > relationship between sender, splicer, and receiver that can be used to > configure RTP-level security mechanisms to prevent modifications to the > streams, or insertion of splicing notification messages by anyone other > than the sender, if that=E2=80=99s considered a threat? > Yes - that would be useful. My concern was triggered by the "undetectable splicing" and MUST NOTs around letting the receiver know that the splicing was happening. Having some text that makes it clear that the receiver is a voluntary participant and reducing suggestions to not forward the messages to SHOULD NOT (or even MAY NOT or no fixed 2119 language) with an explanation of this being to simplify the receiver would be very helpful. Regards, Alia > Colin > > > > As written, it sounds like there is a requirement to hide the splicing > from the receiver - and all the motivations I=E2=80=99ve been hearing are= to > =E2=80=9Cforce" the receiver to get the included advertisements and not b= e able to > tell where they are. > > Regards, > Alia > > On Tue, Jun 21, 2016 at 5:57 PM, Colin Perkins wrote: > >> > On 21 Jun 2016, at 22:53, Ben Campbell wrote: >> > >> > On 21 Jun 2016, at 16:48, Colin Perkins wrote: >> > >> >>> That particular motivation gives me a bit of heartburn. But I think >> the reality is that the content provider wants to provide an apparently >> continuous stream, and they don't think the the splicing details are the >> business of the recipient (any more than the splices that occur in the >> original media stream incident to the normal editing of the content.) >> >> >> >> >> >> It=E2=80=99s implied, but perhaps easy to miss in Rachel=E2=80=99s su= ggested text, >> that this is only talking about whether the splicing is detectable *at t= he >> RTP layer*. A receiver that=E2=80=99s willing to analyse the metadata in= the >> payload can almost certainly tell that the content changed for the durat= ion >> of the splicing, even without decoding the video. >> > >> > Okay, that's a good point. But one wonders why bother with the guidanc= e >> for "undetectable splices" at all? In the example, if an implementation >> that wants to do commercial skipping can still do it anyway, then why ev= en >> talk about it? (Other than to say that undetectable splices aren't real?= ) >> >> It (slightly) simplifies the receiver if it can not care about seeing >> multiple sources (either SSRC or CSRC, depending on how the splicer was >> implemented) in the RTP stream. >> >> -- >> Colin Perkins >> https://csperkins.org/ >> >> >> >> >> > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > --001a1147b6721982b50535e04293 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colin,


On Tue, Jun 21, 2016 at 6:18 PM, Colin Perkins <csp@c= sperkins.org> wrote:
Alia,

On 21 Jun 2016, at 23:07, Alia Atlas <akatlas@gmail.com> wrote:

Colin,

These are really useful points = for me.
So, indicating that the receiver has agreed to receive th= e stream via the splicer would help.
You mean add something to the draft saying =E2=80=9Cthe = sender and receiver have to be explicitly configured to use the splicer=E2= =80=9D? Maybe also with some words in the security considerations explainin= g that there=E2=80=99s a signalling relationship between sender, splicer, a= nd receiver that can be used to configure RTP-level security mechanisms to = prevent modifications to the streams, or insertion of splicing notification= messages by anyone other than the sender, if that=E2=80=99s considered a t= hreat?


Yes - that would be useful. =C2=A0=C2=A0
=C2=A0
My c= oncern was triggered by the "undetectable splicing" and MUST NOTs= around letting the receiver know that the
splicing was happening= .

Having some text that makes it clear that the re= ceiver is a voluntary participant and reducing suggestions to not forward t= he messages
to SHOULD NOT (or even MAY NOT or no fixed 2119 langu= age) with an explanation of this being to simplify the receiver would be ve= ry
helpful.

Regards,
Alia
=C2=A0
Colin
<= /font>



As written, it sounds like there = is a requirement to hide the splicing from the receiver - and all the motiv= ations I=E2=80=99ve been hearing are to =E2=80=9Cforce" the receiver t= o get the included advertisements and not be able to tell where they are.

Regards,
Alia

On Tue, Jun 21, 2016 at 5:57 PM, = Colin Perkins <csp@csperkins.org> wrote:
> On 21 Jun 2016, at 22:53, Ben Campbell <ben@nostrum.com> wrote:
>
> On 21 Jun 2016, at 16:48, Colin Perkins wrote:
>
>>> That particular motivation gives me a bit of heartburn. But I = think the reality is that the content provider wants to provide an apparent= ly continuous stream, and they don't think the the splicing details are= the business of the recipient (any more than the splices that occur in the= original media stream incident to the normal editing of the content.)
>>
>>
>> It=E2=80=99s implied, but perhaps easy to miss in Rachel=E2=80=99s= suggested text, that this is only talking about whether the splicing is de= tectable *at the RTP layer*. A receiver that=E2=80=99s willing to analyse t= he metadata in the payload can almost certainly tell that the content chang= ed for the duration of the splicing, even without decoding the video.
>
> Okay, that's a good point. But one wonders why bother with the gui= dance for "undetectable splices" at all? In the example, if an im= plementation that wants to do commercial skipping can still do it anyway, t= hen why even talk about it? (Other than to say that undetectable splices ar= en't real?)

It (slightly) simplifies the receiver if it can not care about seein= g multiple sources (either SSRC or CSRC, depending on how the splicer was i= mplemented) in the RTP stream.

--
Colin Perkins
htt= ps://csperkins.org/








--=C2=A0
Colin Perkins





--001a1147b6721982b50535e04293-- From nobody Wed Jun 22 10:44:19 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 3706D12D991 for ; Wed, 22 Jun 2016 10:44:17 -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 OgOB4RcpAUPP for ; Wed, 22 Jun 2016 10:44:15 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C25612B04A for ; Wed, 22 Jun 2016 10:44:15 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id u64so72018114vkf.3 for ; Wed, 22 Jun 2016 10:44:15 -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=7GEkn1jOWCrMzJ2EFXYb/38/6cy9ZdrtIM5rF2B00uw=; b=xv6pw40KLZoK4hcKuxHNcfT/aFcAjptcPtEGwYELR0NO9Xky3NgLVJ+lmLgDHKIpLr Yixpe6CYM+yPLFmaWlcX5i4YHXHR4m96f0mfonq9N44hjgfYA7C40VyCJpt0Hq06RYBO A9sa6gUxtaEGevtQ/md+G6bVBSW9Ztd6PtolZ+5A9omZdmK/+ceJMV3uDymgM2s4kj/g 5MKsv+H8pScFU14WHW8ZuwI+7CYrJSD9VcuozJ0vz8OdsG9b/mP4WGhRzzpbmW2+hJEq 70vWSEbzfFI0DX/zfCTRjUcap9d0F4f48MPXPe3KsUs7isW2aw8IHKfACLCpr2tHOCDi jKHg== 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=7GEkn1jOWCrMzJ2EFXYb/38/6cy9ZdrtIM5rF2B00uw=; b=Hy0l3MxRZxL1WClb+zEyHiAvOs+ZXWPDDbRCRGNXcZBAM4MTcU7Y1O+oEcF5YBwYjc dOasz0BgEXPOln8GpujOqWcDI11sbsUfcQfq7zBLWe7Wb5Bu0wQCBbu6+sjaSQi1TmcE 8LNAo1rS7Y4JBdbLtjwb56jM1xN2vt0ao8SLg9VaOvuyKfu8WsOIIoZcHOsTjOjxmbyu JF8L/ZS1OylAbv1XdoYyuS6N+sen+u1JkCnIWhgs6oO7Q8y8oP2Q9qFD5GJWGYxQ0S+y lMfKQS08d+bezpYzF5n1CZLdwf83yvdI1jzP74O4sgf0uReGI4DZu30Nh8L3gskZ6BvH ML4Q== X-Gm-Message-State: ALyK8tJHFH841HK4dXcOtyTmCaOrO8K27w4XdMSlgf4XUv2Ap6SdfaNkUSMDcGDAmRZcIcLQe0Br0gUE0GxtFw== X-Received: by 10.31.7.78 with SMTP id 75mr13926246vkh.74.1466617454315; Wed, 22 Jun 2016 10:44:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.41.198 with HTTP; Wed, 22 Jun 2016 10:43:54 -0700 (PDT) In-Reply-To: <12858949-AD94-4B45-B383-9D5396DA16D0@vidyo.com> References: <12858949-AD94-4B45-B383-9D5396DA16D0@vidyo.com> From: Bernard Aboba Date: Wed, 22 Jun 2016 10:43:54 -0700 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a1143d2dc62ddca0535e17c2a Archived-At: Cc: "avtext@ietf.org" , "Suhas Nandakumar \(snandaku\)" Subject: Re: [avtext] RID needs proper header extension registrations X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 17:44:17 -0000 --001a1143d2dc62ddca0535e17c2a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jonathan said: "explicitly state the URNs implementations should use" [BA] Yes. Is the intent for the SDP to indicate support for both the base URN (urn:ietf:params:rtp-hdrext:sdes) or only the individual extensions? On Wed, Jun 22, 2016 at 9:09 AM, Jonathan Lennox wrote= : > Hi, Adam =E2=80=94 > > I realized on writing up the PubReq for RID that it needs proper > registration for the sdes-hdr-ext items =E2=80=94 we need to mention the = SDES > header extension IANA registry, explicitly state the URNs implementations > should use, etc. > > See the discussion of MID on MMUSIC in the last few days. > > It probably needs more explanation of the privacy and timeliness > considerations for the SDES items, too, as Magnus pointed out for MID. > > Sorry I didn=E2=80=99t catch this sooner. > > -Jonathan > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > --001a1143d2dc62ddca0535e17c2a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jonathan said:=C2=A0

"explicitly state the URNs implementations should use<= /span>"

[BA] Yes. Is the intent for the SDP t= o indicate support for both the base URN (urn:ietf:params:rtp-hdrext:sdes) or only the ind= ividual extensions?=C2=A0

On Wed, Jun 22, 2016 at 9:09 AM, Jonathan Lennox <jon= athan@vidyo.com> wrote:
Hi,= Adam =E2=80=94

I realized on writing up the PubReq for RID that it needs proper registrati= on for the sdes-hdr-ext items =E2=80=94 we need to mention the SDES header = extension IANA registry, explicitly state the URNs implementations should u= se, etc.

See the discussion of MID on MMUSIC in the last few days.

It probably needs more explanation of the privacy and timeliness considerat= ions for the SDES items, too, as Magnus pointed out for MID.

Sorry I didn=E2=80=99t catch this sooner.

-Jonathan

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

--001a1143d2dc62ddca0535e17c2a-- From nobody Wed Jun 22 15:44:34 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D2412B010; Wed, 22 Jun 2016 15:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 BWOW4Qdw9Bao; Wed, 22 Jun 2016 15:44:31 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A7E612DD86; Wed, 22 Jun 2016 15:44:31 -0700 (PDT) Received: from [81.187.2.149] (port=33267 helo=[192.168.0.91]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bFqic-0008CA-W9; Wed, 22 Jun 2016 23:34:00 +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: <51E6A56BD6A85142B9D172C87FC3ABBB86ED8E77@nkgeml513-mbx.china.huawei.com> Date: Wed, 22 Jun 2016 23:33:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <89FC3AF6-DA07-4213-A805-B480B7E22BC8@csperkins.org> References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8E77@nkgeml513-mbx.china.huawei.com> To: "Huangyihong (Rachel)" X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "avtext@ietf.org" , "jonathan@vidyo.com" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" , Alia Atlas Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 22 Jun 2016 22:44:33 -0000 Hi Rachel, One quick response inline. Colin > On 22 Jun 2016, at 03:59, Huangyihong (Rachel) = wrote: >=20 > Hi Colin and Ben, >=20 > Please see inline. >=20 > BR, > Rachel >=20 >=20 >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: Wednesday, June 22, 2016 5:49 AM >> To: Ben Campbell >> Cc: Huangyihong (Rachel); kathleen.moriarty.ietf@gmail.com; Mirja >> Kuehlewind; Alia Atlas; Alissa Cooper; avtext-chairs@ietf.org; >> draft-ietf-avtext-splicing-notification@ietf.org; avtext@ietf.org; = The IESG; >> jonathan@vidyo.com >> Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS >>=20 >>> On 21 Jun 2016, at 20:32, Ben Campbell wrote: >>>=20 >>> Hi, some comments inline: >>>=20 >>> On 21 Jun 2016, at 7:58, Huangyihong (Rachel) wrote: >>>=20 >>>> Hi All, >>>>=20 >>>> Here's my proposal for addressing Alia's and other AD's similar = DISCUSS. >> The main idea is to add a new subsection in Section 2, which is = showed as >> following: >>>>=20 >>>> " >>>> 2.1 Overview of RTP Splicing >>>>=20 >>>> RTP Splicing is to replace some multimedia content with certain >>>> substitutive multimedia content, and then forward it to the = receivers >>>> for a period of time. This process is authorized by the service >>>> provider who sends the multimedia content to these receivers. A >>>> typical usage is that IPTV service providers use their own = regional >>>> advertising content to replace national advertising content = provided >>>> by the content providers. >>>=20 >>> I think this could be strengthened a bit. IIUC, this mechanism = assumes the >> splicing interval is sent _by_ the main content provider. That is, = this mechanism >> only works with the permission of the content provider. If they don't = consent, >> they simply won't send the splicing interval. >>>=20 >>> This relationship might be more clear if the example talked about = the main >> content provider offering a time window for the regional advertising = insert, >> rather than about replacing national advertising. While that might in = fact >> replace national content, it should be clear that the main provider = _intends_ for >> the insert to happen. >>=20 >> Right. >=20 >=20 > [Rachel]: According to your suggestions, how about changing the above = text to below >=20 > " > RTP Splicing is to replace some multimedia content with certain > substitutive multimedia content, and then forward it to the = receivers > for a period of time. This process is authorized by the main RTP > sender that offers a specific time window for inserting the > substitutive multimedia content in the main content. A typical usage > is that a IPTV service provider uses its own regional advertising > content to replace national advertising content, the time window of > which is explicitly indicated by the IPTV service provider. > " >=20 >>=20 >> The other point that=E2=80=99s probably worth noting is that the = receiver knows the >> traffic is being routed via the middlebox, and explicitly = communicates with that >> middlebox via the RTCP reception reports it returns, and possibly = also via some >> non-RTP signalling channel (the sender likely offers it no choice but = to use the >> middlebox if it wants access to the media stream, but that=E2=80=99s = a different >> issue=E2=80=A6). >=20 > [Rachel]: Based on this suggestion, I propose to add a sentences in = the end of the 2nd paragraph: >=20 > " > The splicer is a middlebox handling RTP splicing. It receives main > content and substitutive content simultaneously but only chooses to > send one of them to the receiver at any point of time. When RTP > splicing begins, the splicer sends the substitutive content to the > receivers instead of the main content. When RTP splicing ends, the > splicer switches back to sending the main content to the receivers. > This implies that the traffic is routed via the splicer to the > receivers. And the splicer is explicitly communicated with the > receivers via RTCP packets and possibly via non-RTP signaling > channel. > =E2=80=9C Yes, but the last sentence might be clearer if written something like = =E2=80=9CThe receiver is explicitly configured to receive the traffic = via the splicer, and will return any RTCP feedback to the splicer=E2=80=9D= . >>>> The splicer is a middlebox handling RTP splicing. It receives main >>>> content and substitutive content simultaneously but only chooses = to >>>> send one of them to the receiver at any point of time. When RTP >>>> splicing begins, the splicer sends the substitutive content to the >>>> receivers instead of the main content. When RTP splicing ends, the >>>> splicer switches back to sending the main content to the = receivers. >>>>=20 >>>> The middle box working as the splicer is either a translator or a >>>> mixer. [RFC6828] specifies a splicer implemented as a mixer that = uses >>>> its own SSRC, sequence number space, and timing model when >> generating >>>> the output stream to receivers. The mixer must not insert the SSRC = of >>>> the main RTP stream or the SSRC of the substitutive RTP stream = into >>>> the contributing source (CSRC) list in the output media stream = when >>>> implementing undetectable splicing. >>>=20 >>> I suggest promoting that last sentence a bit, and removing any hint = of 2119 >> language. For example: >>>=20 >>> "The splicer, operating on behalf of the content provider, may not = wish to >> reveal that splicing has occurred. In this case, the splicer does not = insert the >> SSRCs from either the main or substitutive RTP streams into the CSRC = list in the >> resulting output media stream.." >=20 > [Rachel]: Thanks for the suggestion. >=20 >>>=20 >>>> Since it works as the mixer, it >>>> splits the RTCP flow between the sender and receiver into two >>>> separate RTCP loops. This implies additional considerations should = be >>>> taken into account when handling congestion control, see Section = 4.4 >>>> of [RFC6828]. >>>>=20 >>>> A translator [RFC3550] can also be a splicer by forwarding the RTP >> packets with >>>> their SSRCs intact, where the congestion control runs between >>>> original sender and receiver, or between substitutive sender and >>>> receiver. In such a case, the RTCP feedback message must be passed = to >>>> the right sender to let the congestion control work. And = undetectable >>>> splicing will not be fulfilled when the translator works as the >>>> splicer. >>>> " >>>>=20 >>>> Besides that, a new terminology is defined in section 1.1 to define >> "Undetectable Splicing", see below: >>>>=20 >>>> " >>>> Undetectable Splicing: >>>>=20 >>>> The RTP receivers are not able to detect any splicing points in the = RTP layer. >> Sometimes, service providers may require an undetectable splicing to = avoid the >> RTP receivers from filtering out the advertisement content. >>>=20 >>> That particular motivation gives me a bit of heartburn. But I think = the reality >> is that the content provider wants to provide an apparently = continuous stream, >> and they don't think the the splicing details are the business of the = recipient >> (any more than the splices that occur in the original media stream = incident to >> the normal editing of the content.) >>=20 >> It=E2=80=99s implied, but perhaps easy to miss in Rachel=E2=80=99s = suggested text, that this is >> only talking about whether the splicing is detectable *at the RTP = layer*. A >> receiver that=E2=80=99s willing to analyse the metadata in the = payload can almost >> certainly tell that the content changed for the duration of the = splicing, even >> without decoding the video. >>=20 >> -- >> Colin Perkins >> https://csperkins.org/ >>=20 >>=20 >>=20 >=20 --=20 Colin Perkins https://csperkins.org/ From nobody Wed Jun 22 19:25: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 637F912DEBC; Wed, 22 Jun 2016 19:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 jV_qLGuedk3u; Wed, 22 Jun 2016 19:25: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 6C59712DEC5; Wed, 22 Jun 2016 19:25:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRI20362; Thu, 23 Jun 2016 02:25:46 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 23 Jun 2016 03:25:45 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Thu, 23 Jun 2016 10:25:37 +0800 From: "Huangyihong (Rachel)" To: Ben Campbell Thread-Topic: [avtext] Proposed text for Alia and other AD's DISCUSS Thread-Index: AQHRy/OtoxvIWlDAtk64LHRNLjGwPJ/z714AgAC/W4CAAGMcgIABNqRg Date: Thu, 23 Jun 2016 02:25:36 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86ED939A@nkgeml513-mbx.china.huawei.com> References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8E77@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.78.128] 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.0A090205.576B48AB.0031, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c41ed1079ecf88d1459d989d32630bd7 Archived-At: Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" , Alia Atlas , Colin Perkins Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 23 Jun 2016 02:25:53 -0000 DQoNCj4gPg0KPiA+IFtSYWNoZWxdOiBBY2NvcmRpbmcgdG8geW91ciBzdWdnZXN0aW9ucywgaG93 IGFib3V0IGNoYW5naW5nIHRoZSBhYm92ZQ0KPiA+IHRleHQgdG8gYmVsb3cNCj4gPg0KPiA+ICIN Cj4gPiAgICBSVFAgU3BsaWNpbmcgaXMgdG8gcmVwbGFjZSBzb21lIG11bHRpbWVkaWEgY29udGVu dCB3aXRoIGNlcnRhaW4NCj4gPiAgICBzdWJzdGl0dXRpdmUgbXVsdGltZWRpYSBjb250ZW50LCBh bmQgdGhlbiBmb3J3YXJkIGl0IHRvIHRoZQ0KPiA+IHJlY2VpdmVycw0KPiA+ICAgIGZvciBhIHBl cmlvZCBvZiB0aW1lLiBUaGlzIHByb2Nlc3MgaXMgYXV0aG9yaXplZCBieSB0aGUgbWFpbiBSVFAN Cj4gPiAgICBzZW5kZXIgdGhhdCBvZmZlcnMgYSBzcGVjaWZpYyB0aW1lIHdpbmRvdyBmb3IgaW5z ZXJ0aW5nIHRoZQ0KPiA+ICAgIHN1YnN0aXR1dGl2ZSBtdWx0aW1lZGlhIGNvbnRlbnQgaW4gdGhl IG1haW4gY29udGVudC4gQSB0eXBpY2FsDQo+ID4gdXNhZ2UNCj4gPiAgICBpcyB0aGF0IGEgSVBU ViBzZXJ2aWNlIHByb3ZpZGVyIHVzZXMgaXRzIG93biByZWdpb25hbCBhZHZlcnRpc2luZw0KPiA+ ICAgIGNvbnRlbnQgdG8gcmVwbGFjZSBuYXRpb25hbCBhZHZlcnRpc2luZyBjb250ZW50LCB0aGUg dGltZSB3aW5kb3cgb2YNCj4gPiAgICB3aGljaCBpcyBleHBsaWNpdGx5IGluZGljYXRlZCBieSB0 aGUgSVBUViBzZXJ2aWNlIHByb3ZpZGVyLg0KPiA+ICINCj4gPg0KPiANCj4gSSB0aGluayB0aGF0 IGhlbHBzLiBJIHN1Z2dlc3QgdGhlIGZvbGxvd2luZyAoaW4gdGhlIGZpcnN0IHNlbnRlbmNlKToN Cj4gDQo+IHMvUlRQIFNwbGljaW5nIGlzIHRvIHJlcGxhY2UuLi4vUlRQIFNwbGljaW5nIHJlcGxh Y2VzLi4uDQo+IA0KPiAoT3IgIlJUUCBTcGxpY2luZyBpcyBpbnRlbmRlZCB0byByZXBsYWNlLi4i DQoNCltSYWNoZWxdOiBPa2F5Lg0KDQo+ID4NCj4gPiBbUmFjaGVsXTogQmFzZWQgb24gdGhpcyBz dWdnZXN0aW9uLCBJIHByb3Bvc2UgdG8gYWRkIGEgc2VudGVuY2VzIGluDQo+ID4gdGhlIGVuZCBv ZiB0aGUgMm5kIHBhcmFncmFwaDoNCj4gPg0KPiA+ICINCj4gPiAgICBUaGUgc3BsaWNlciBpcyBh IG1pZGRsZWJveCBoYW5kbGluZyBSVFAgc3BsaWNpbmcuIEl0IHJlY2VpdmVzIG1haW4NCj4gPiAg ICBjb250ZW50IGFuZCBzdWJzdGl0dXRpdmUgY29udGVudCBzaW11bHRhbmVvdXNseSBidXQgb25s eSBjaG9vc2VzIHRvDQo+ID4gICAgc2VuZCBvbmUgb2YgdGhlbSB0byB0aGUgcmVjZWl2ZXIgYXQg YW55IHBvaW50IG9mIHRpbWUuIFdoZW4gUlRQDQo+ID4gICAgc3BsaWNpbmcgYmVnaW5zLCB0aGUg c3BsaWNlciBzZW5kcyB0aGUgc3Vic3RpdHV0aXZlIGNvbnRlbnQgdG8gdGhlDQo+ID4gICAgcmVj ZWl2ZXJzIGluc3RlYWQgb2YgdGhlIG1haW4gY29udGVudC4gV2hlbiBSVFAgc3BsaWNpbmcgZW5k cywgdGhlDQo+ID4gICAgc3BsaWNlciBzd2l0Y2hlcyBiYWNrIHRvIHNlbmRpbmcgdGhlIG1haW4g Y29udGVudCB0byB0aGUgcmVjZWl2ZXJzLg0KPiA+ICAgIFRoaXMgaW1wbGllcyB0aGF0IHRoZSB0 cmFmZmljIGlzIHJvdXRlZCB2aWEgdGhlIHNwbGljZXIgdG8gdGhlDQo+ID4gICAgcmVjZWl2ZXJz LiBBbmQgdGhlIHNwbGljZXIgaXMgZXhwbGljaXRseSBjb21tdW5pY2F0ZWQgd2l0aCB0aGUNCj4g PiAgICByZWNlaXZlcnMgdmlhIFJUQ1AgcGFja2V0cyBhbmQgcG9zc2libHkgdmlhIG5vbi1SVFAg c2lnbmFsaW5nDQo+ID4gICAgY2hhbm5lbC4NCj4gPiAiDQo+ID4NCj4gDQo+IFNob3VsZCB0aGUg bGFzdCBzZW50ZW5jZSByZWFkICJBbmQgdGhlIHByZXNlbmNlIG9mIHRoZSBzcGxpY2VyLi4uIj8N Cg0KW1JhY2hlbF06IE9rYXkuIEJhc2VkIG9uIENvbGluJ3Mgc3VnZ2VzdGlvbiwgaG93IGFib3V0 IGNoYW5naW5nIHRoZSBsYXN0IHNlbnRlbmNlIHRvIA0KDQoiIEluIHRoZSBwcmVzZW5jZSBvZiB0 aGUgc3BsaWNlciwgdGhlIHJlY2VpdmVyIGlzIGV4cGxpY2l0bHkgY29uZmlndXJlZCB0byByZWNl aXZlIHRoZSB0cmFmZmljIHZpYSB0aGUgc3BsaWNlciwgYW5kIHdpbGwgcmV0dXJuIGFueSBSVENQ IGZlZWRiYWNrIHRvIGl0LiINCg0KPiANCj4gT3RoZXJ3aXNlIGl0IGxvb2tzIGdvb2QuDQo+IA0K PiBbLi4uXQ0K From nobody Wed Jun 22 19:45: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 9B26612DEE1; Wed, 22 Jun 2016 19:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 q-eBw72Drh4K; Wed, 22 Jun 2016 19:45:49 -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 02F9212DEDE; Wed, 22 Jun 2016 19:45:47 -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 CRI22078; Thu, 23 Jun 2016 02:45:45 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 23 Jun 2016 03:45:44 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Thu, 23 Jun 2016 10:45:37 +0800 From: "Huangyihong (Rachel)" To: Ben Campbell Thread-Topic: [avtext] Proposed text for Alia and other AD's DISCUSS Thread-Index: AQHRy/OtoxvIWlDAtk64LHRNLjGwPJ/z714AgAABSwCAAAE1gIAAC/kAgADOpiCAAEaWAIABQi+Q Date: Thu, 23 Jun 2016 02:45:36 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86ED93BA@nkgeml513-mbx.china.huawei.com> References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> <9894DE50-B2C3-49EE-B932-54254573D26F@nostrum.com> <01A5530D-A34F-4253-AB02-5439E3FFB99F@csperkins.org> <947DF280-60CD-41F4-B8F6-BD9B6C16C9F8@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8E92@nkgeml513-mbx.china.huawei.com> <6CD06201-4FCD-4934-ADF0-18ED3A3D4BF8@nostrum.com> In-Reply-To: <6CD06201-4FCD-4934-ADF0-18ED3A3D4BF8@nostrum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.128] 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.0A090205.576B4D5A.00EE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c41ed1079ecf88d1459d989d32630bd7 Archived-At: Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" , Alia Atlas , Colin Perkins Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 23 Jun 2016 02:45:50 -0000 DQoNCkJSLA0KUmFjaGVsDQoNCj4gPg0KPiA+DQo+ID4gW1JhY2hlbF06IEknbSB0aGluayBpZiBp dCdzIG9rYXkgdG8gbm90IHNwZWNpZnkgInVuZGV0ZWN0YWJsZQ0KPiA+IHNwbGljaW5nIiBpbiB0 aGlzIGRvY3VtZW50OiBUaGlzIGRyYWZ0IGlzIHRvIGV4dGVuZCBhIFJUUCBoZWFkZXINCj4gPiBl eHRlbnNpb24gYW5kIFJUQ1AgZXh0ZW5zaW9uIG1lc3NhZ2UgZm9yIHNwbGljaW5nIGludGVydmFs LCB3aGljaCBpcw0KPiA+IGFjdHVhbGx5IGEgbWVzc2FnZSBjb21tdW5pY2F0ZWQgYmV0d2VlbiB0 aGUgc2VuZGVyIGFuZCB0aGUgc3BsaWNlci4gU28NCj4gPiBtYXliZSB3ZSBqdXN0IG5lZWQgdG8g c3BlY2lmeSB0aGF0IHRoZSBzcGxpY2VyIE1VU1QgTk9UIGZvcndhcmQgdGhlc2UNCj4gPiBleHRl bnNpb25zIHRvIHRoZSByZWNlaXZlcnMsIGNhdXNlIHRoZXNlIG1lc3NhZ2VzIGFyZSB1c2VsZXNz IHRvIHRoZW0uDQo+ID4gRm9yIHVuZGV0ZWN0YWJsZSBzcGxpY2luZywgaXQgaGFzIGFscmVhZHkg YmVlbiB3cml0dGVuIGluIFJGQzY4MjgsDQo+ID4gd2hlcmUgc3BsaWNlciB3b3JrcyBhcyBhIG1p eGVyLiBJZiB0aGUgc3BsaWNlciB3b3JrcyBhcyBhIHRyYW5zbGF0b3IsDQo+ID4gaXQncyBpbXBv c3NpYmxlIGZvciByZWNlaXZlcnMgbm90IHRvIGRldGVjdCB0aGUgc3BsaWNpbmcgaGFwcGVucyBp bg0KPiA+IFJUUCBsYXllci4gU28gSSBndWVzcyB0aGVyZSdzIG5vIG5lZWQgdG8gc3BlY2lmeSBh bnkgdW5kZXRlY3RhYmxlDQo+ID4gc3BsaWNpbmcgYWN0aXZpdGllcyBpbiB0aGlzIGRvY3VtZW50 LiBXaGF0IGRvIHlvdSB0aGluaz8NCj4gDQo+IEknbSBnZW5lcmFsbHkgb2theSB3aXRoIHRoYXQs IGJ1dCBJIHdhbnQgdG8gc2VlIHdoYXQgb3RoZXJzIHRoaW5rLA0KPiANCj4gSSBkbywgdGhvdWdo LCB3b25kZXIgaWYgdGhlIE1VU1QgTk9UIGlzIHN0aWxsIGp1c3RpZmllZCBhdCB0aGlzIHBvaW50 Lg0KPiBJZiB0aGUgbW90aXZhdGlvbiBpcyBqdXN0IHRoYXQgZm9yd2FyZGluZyB0aGUgbWVzc2Fn ZXMgYXJlIHVzZWxlc3MsIG9yIGV2ZW4gYQ0KPiBudWlzYW5jZSwgTVVTVCBzZWVtcyBhIGJpdCBz dHJvbmcuIFRoYXQgaXMsIGl0IGRvZXNuJ3Qgc2VlbSB0byBpbXBhY3QNCj4gaW50ZXJvcGVyYWJp bGl0eSwgb3Igb3RoZXJ3aXNlIGNyZWF0ZSBhIHJlYWwgcHJvYmxlbS4gVGhpcyBzZWVtcyBiZXR0 ZXIgc3RhdGVkDQo+IHdpdGhvdXQgMjExOSBrZXl3b3Jkcy4NCg0KDQpbUmFjaGVsXTogWWVzLiBN VVNUIE5PVCBjYW4gYmUgY2hhbmdlZCB0byAic2hvdWxkIG5vdCIuIFRoZSBpbnRlbnNpb24gaXMg anVzdCB0byBwcm92aWRlIGEgZ3VpZGFuY2UgZm9yIGltcGxlbWVudGluZyB0aGUgc3BsaWNlciBv biBob3cgdG8gZGVhbCB3aXRoIHRoZSBzcGxpY2luZyBub3RpZmljYXRpb24gZXh0ZW5zaW9uIG1l c3NhZ2Ugd2hlbiBmb3J3YXJkaW5nIHRvIHRoZSByZWNlaXZlcnMuIA0KDQo+IA0KPiA+DQo+ID4+ DQo+ID4+Pg0KPiA+Pj4gLS0NCj4gPj4+IENvbGluIFBlcmtpbnMNCj4gPj4+IGh0dHBzOi8vY3Nw ZXJraW5zLm9yZy8NCg== From nobody Wed Jun 22 20:40:53 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 A0D5212DE77; Wed, 22 Jun 2016 20:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dzNsDJRN4ON; Wed, 22 Jun 2016 20:40:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E0112D895; Wed, 22 Jun 2016 20:40:43 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5N3eRdB083442 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 Jun 2016 22:40:28 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: Huangyihong Date: Wed, 22 Jun 2016 22:40:32 -0500 Message-ID: In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86ED939A@nkgeml513-mbx.china.huawei.com> References: <20160615183734.26197.55835.idtracker@ietfa.amsl.com> <6BB6D77A-579F-4690-8582-A6B41A70CB4C@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8BD9@nkgeml513-mbx.china.huawei.com> <0B7CD9BF-8C01-4CED-AE2F-202DB6B477ED@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB86ED8E77@nkgeml513-mbx.china.huawei.com> <51E6A56BD6A85142B9D172C87FC3ABBB86ED939A@nkgeml513-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "jonathan@vidyo.com" , "avtext@ietf.org" , "avtext-chairs@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , Mirja Kuehlewind , The IESG , "draft-ietf-avtext-splicing-notification@ietf.org" , Alia Atlas , Colin Perkins Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS 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, 23 Jun 2016 03:40:47 -0000 On 22 Jun 2016, at 21:25, Huangyihong (Rachel) wrote: > Should the last sentence read "And the presence of the splicer..."? > > > [Rachel]: Okay. Based on Colin's suggestion, how about changing the > last sentence to > > " In the presence of the splicer, the receiver is explicitly > configured to receive the traffic via the splicer, and will return any > RTCP feedback to it." WFM. From nobody Fri Jun 24 09:03:30 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 DDE1C12DC93; Fri, 24 Jun 2016 09:00:43 -0700 (PDT) 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.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160043.10933.84480.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:43 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] avtext - Requested session has been scheduled for IETF 96 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, 24 Jun 2016 16:00:44 -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 (1:30:00) Tuesday, Afternoon Session II 1620-1820 Room Name: Charlottenburg I size: 80 --------------------------------------------- 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): 1.5 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: avtcore mmusic dispatch rmcat rtcweb perc payload netvc cellar Second Priority: tsvwg sipcore tram apparea artarea taps Special Requests: --------------------------------------------------------- From nobody Mon Jun 27 18:20:10 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 1492A12DACE; Mon, 27 Jun 2016 18:20:09 -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.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160628012009.5285.243.idtracker@ietfa.amsl.com> Date: Mon, 27 Jun 2016 18:20:09 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-splicing-notification-08.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: Tue, 28 Jun 2016 01:20:09 -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-08.txt Pages : 21 Date : 2016-06-27 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-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-splicing-notification-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 27 18:27: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 CAF2312DACC for ; Mon, 27 Jun 2016 18:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 Sgzc3CpvTr7e for ; Mon, 27 Jun 2016 18:26: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 D224012DACB for ; Mon, 27 Jun 2016 18:26:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMT10314; Tue, 28 Jun 2016 01:26:53 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 28 Jun 2016 02:26:52 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 28 Jun 2016 09:26:46 +0800 From: Xiajinwei To: "avtext@ietf.org" Thread-Topic: New Version Notification for draft-ietf-avtext-splicing-notification-08.txt Thread-Index: AQHR0Ns5kuydC+Bu5k2YgZ7ZRMa2rJ/+Fkgg Date: Tue, 28 Jun 2016 01:26:46 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.76] 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.0A090205.5771D25E.0011, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6d445b0d3554e377f7df428a346f3399 Archived-At: Subject: [avtext] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?utf-8?q?for_draft-ietf-avtext-splicing-notification-08=2Etxt?= 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, 28 Jun 2016 01:26:59 -0000 RGVhciBhbGwsDQoNClRoaXMgdmVyc2lvbiBpcyB0byBhZGRyZXNzIElFU0cgRElTQ1VTU2VzLiBZ b3VyIGZlZWRiYWNrIGlzIHdlbGNvbWVkLg0KDQpCUg0KSmlud2VpDQoNCi0tLS0t6YKu5Lu25Y6f 5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCuWPkemAgeaXtumXtDogMjAxNuW5tDbmnIgyOOaXpSA5 OjIwDQrmlLbku7bkuro6IERlbmcgTGluZ2xpOyBSb25pIEV2ZW47IFhpYWppbndlaTsgSHVhbmd5 aWhvbmcgKFJhY2hlbCk7IExpbmdsaSBEZW5nDQrkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmctbm90aWZpY2F0aW9uLTA4LnR4dA0K DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLWF2dGV4dC1zcGxpY2luZy1ub3Rp ZmljYXRpb24tMDgudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJhY2hl bCBIdWFuZyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFm dC1pZXRmLWF2dGV4dC1zcGxpY2luZy1ub3RpZmljYXRpb24NClJldmlzaW9uOgkwOA0KVGl0bGU6 CQlSVFAvUlRDUCBleHRlbnNpb24gZm9yIFJUUCBTcGxpY2luZyBOb3RpZmljYXRpb24NCkRvY3Vt ZW50IGRhdGU6CTIwMTYtMDYtMjgNCkdyb3VwOgkJYXZ0ZXh0DQpQYWdlczoJCTIxDQpVUkw6ICAg ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt YXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0wOC50eHQNClN0YXR1czogICAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWF2dGV4dC1zcGxpY2luZy1u b3RpZmljYXRpb24vDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0wOA0KRGlmZjogICAgICAg ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWF2dGV4dC1z cGxpY2luZy1ub3RpZmljYXRpb24tMDgNCg0KQWJzdHJhY3Q6DQogICBDb250ZW50IHNwbGljaW5n IGlzIGEgcHJvY2VzcyB0aGF0IHJlcGxhY2VzIHRoZSBjb250ZW50IG9mIGEgbWFpbg0KICAgbXVs dGltZWRpYSBzdHJlYW0gd2l0aCBvdGhlciBtdWx0aW1lZGlhIGNvbnRlbnQsIGFuZCBkZWxpdmVy cyB0aGUNCiAgIHN1YnN0aXR1dGl2ZSBtdWx0aW1lZGlhIGNvbnRlbnQgdG8gdGhlIHJlY2VpdmVy cyBmb3IgYSBwZXJpb2Qgb2YNCiAgIHRpbWUuIFRoZSBzcGxpY2VyIGlzIGRlc2lnbmVkIHRvIGhh bmRsZSBSVFAgc3BsaWNpbmcgYW5kIG5lZWRzIHRvDQogICBrbm93IHdoZW4gdG8gc3RhcnQgYW5k IGVuZCB0aGUgc3BsaWNpbmcuDQoNCiAgIFRoaXMgbWVtbyBkZWZpbmVzIHR3byBSVFAvUlRDUCBl eHRlbnNpb25zIHRvIGluZGljYXRlIHRoZSBzcGxpY2luZw0KICAgcmVsYXRlZCBpbmZvcm1hdGlv biB0byB0aGUgc3BsaWNlcjogYW4gUlRQIGhlYWRlciBleHRlbnNpb24gdGhhdA0KICAgY29udmV5 cyB0aGUgaW5mb3JtYXRpb24gaW4tYmFuZCBhbmQgYW4gUlRDUCBwYWNrZXQgdGhhdCBjb252ZXlz IHRoZQ0KICAgaW5mb3JtYXRpb24gb3V0LW9mLWJhbmQuDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNl Y3JldGFyaWF0DQoNCg==